OpenCL vs. GLSL fragment shader - much difference?
category: code [glöplog]
Would an OpenCL SDF ray marcher / sphere tracer be considerably faster than a GLSL fragment shader one? Or does the fragment shader sufficiently parallelize the task already? Does anyone have some experience with that?
Also, I'm looking for a way to teach Bullet Physics to handle collisions with implicit surfaces (SDF functions). Perhaps someone has dabbled with this already?
Also, I'm looking for a way to teach Bullet Physics to handle collisions with implicit surfaces (SDF functions). Perhaps someone has dabbled with this already?
Fragment/Pixel Shader will in most cases be faster than OpenCL/Compute Shader.
As for collisions with distance functions, I played a bit with sphere-SDF collision detection/response and it worked reasonably well.
The algorithm was like this:
1. Start from center of the sphere.
2. Compute distance function and its gradient.
3. Do a step in direction of the gradient (preferably not the whole distance).
4. Go to 2 if iteration count/epsilon not reached.
After all of this you have found point that is closest to the center of the sphere (or something like that - algorithm makes no guarantee). Now you can go forth and get collision normal, penetration depth and other collision stuff.
As for collisions with distance functions, I played a bit with sphere-SDF collision detection/response and it worked reasonably well.
The algorithm was like this:
1. Start from center of the sphere.
2. Compute distance function and its gradient.
3. Do a step in direction of the gradient (preferably not the whole distance).
4. Go to 2 if iteration count/epsilon not reached.
After all of this you have found point that is closest to the center of the sphere (or something like that - algorithm makes no guarantee). Now you can go forth and get collision normal, penetration depth and other collision stuff.
I did some SDF collision stuff a while ago - and it's great, has a really nice smooth collision response and it can be alot faster than bog standard tri collision. Because the response is so smooth - it's used for cloth sim collision. The collision code is dead also - it's a win all round :P
In this vid the objects are compound SDF's objects that have been converted to meshes with a MC algo - but the collision is pure SDF functions.
http://www.youtube.com/watch?v=56NqVpYVd-0&feature=g-upl
In this vid the objects are compound SDF's objects that have been converted to meshes with a MC algo - but the collision is pure SDF functions.
http://www.youtube.com/watch?v=56NqVpYVd-0&feature=g-upl
With OpenCL you add another dependency to your project + you have to add a context switch if you are rendering your stuff already somehow.
It completely depends on how coherent and well suited for a GPU target your code executions are. It basically doesn't matter whether you use some compute language or fragment shader stuff - if using a compute shader can make your executions more coherent than a fragment shader execution (for whatever algorithmic reason) - that will be faster - depending on how big your context switching overhead is (e.g. using OpenCL/CUDA will introduce such a context switching overhead - with GLSL CS & HLSL CS you don't have that kind of context switch).
It completely depends on how coherent and well suited for a GPU target your code executions are. It basically doesn't matter whether you use some compute language or fragment shader stuff - if using a compute shader can make your executions more coherent than a fragment shader execution (for whatever algorithmic reason) - that will be faster - depending on how big your context switching overhead is (e.g. using OpenCL/CUDA will introduce such a context switching overhead - with GLSL CS & HLSL CS you don't have that kind of context switch).
paniq: Compute shaders allow for some pretty cool optimizations that traditional fragment shaders doesn't. However, OpenGL 4.3 added support for compute shaders without OpenCL, and IIRC also added most of the snack back to the fragment shader pipeline as well. So I don't think it matters that much in reality. If you're doing some form of ratracing, I'd go for compute shaders if I were you; you don't have to shoe horn it into the rest of the graphic pipeline any more.
If you're doing ratracing, save it for retirement. There's the boss to butter first if you want that promotion.
"her blir det liv, rai rai"-tracing.
Hey thanks for all the nice feedback :)
KK: Alright. I started doing some collision work, it's indeed pretty sweet.
Shabby: the link doesn't work :( would have loved to see that.
kusma, las: alright. the fragment shader is already perfoming really great, maybe I add a CS path later for comparison (also, I'm currently using transform feedback for collision queries, and that's probably not very cool.)
KK: Alright. I started doing some collision work, it's indeed pretty sweet.
Shabby: the link doesn't work :( would have loved to see that.
kusma, las: alright. the fragment shader is already perfoming really great, maybe I add a CS path later for comparison (also, I'm currently using transform feedback for collision queries, and that's probably not very cool.)
paniq: come on, that youtube link is not that hard to fix :)
