GPGPU with shaders

Hi guys,
I was wondering if is possible to execute non graphics algorithms on the GPU using shaders and then retrieve the data. I already posted a thread asking how to do it with ComputeShaders, but it uses directx 11 wich won't run on my machine, so I just thought if I could do the same with cG. I want to run a MarchingCubes algorithm inside the GPU, making it to calculate the mesh vertices, normals and so on, then retrieve the data from there and build the mesh in unity. Is this possible to be done with shaders ? I saw something about Render to Texture, how does that could work on my particular case? Also, would be greate to perform physics calculations on the GPU side too, like collision detection and in the future pathfindin too. Can anyone point me in the right direction, please? I'm very new/noob to shaders "world" so I'll need basic introduction to the GPGPU subject in Unity.
Thank you in advanced.

 

You can do that for sure. You have to write a Compute Shader watever this shader computes can be read with a structured buffer or a rendertexture. Sorry for misspells i just came back from an birthday party

 

Hi Sam

Sorry the short answer is no. There is no easy way to do this without compute shaders.
The stage of the graphics pipeline that can write data directly into a vertex buffer from a vert or geometry program is call transform feedback. As far as I know this never made it into Unity. Probably because it was not widely supported in SM3 and since you need dx11 to run SM4 or SM5 in Unity you have access to compute shaders instead which are more flexible than transform feedback.

You can write data directly into a render texture from a frag program (if you have Unity Pro). This data does not have to be related to rendering and can really be about anything which is what GPGPU is all about. However since you are still tied down to using the standard graphics pipeline by using the frag program what you can do is some what limited. For true GPGPU you will need compute shaders, which is what they were invented for.

Since the data in a render texture can only be used as a texture its not really going to be a practical method for performing the marching cubes algorithm on the GPU.

 

thank you for the tips guys.
But as I told you Compute Shaders are out of question since they won't work on my machine, they need dx11 (Shader Model 5) to run and at this moment I cannot afford a graphics card with dx11 support. Still I think I found a workaround solution for this.
I think that I could write a C console application wich can receive the data and then send it to the GPU to process, I can use OpenGL and cG (or GLSL) to run the algorithm inside the GPU, now if I succeed with this solution I won't be restricted by the Unity limitations, since with this program in theory I'll be able to send any kind of data and whenever I want to the GPU and then retrieve this data, just like with Compute Shaders. Then I can call the program inside my Unity project and send the data whenever I want. In theory it should work, right guys?

 

Still I think this poses a new problem wich is resources concurrency in the GPU, during the game execution time the GPU will be busy, so I don't think that this will be the best approach for the marching cubes algorithm, so for this particular problem I think multithreading will work much better, but I saw somewhere that for collision detection I can use the render texture approach, so I'll try it this way for now, the marching cubes isn't so heavy like that to use the GPU to process it, multithreading will work perfectly...

 

You can get data back from the GPU by writing to a RenderTexture and reading that data out using ReadPixels. Unfortunately the precision isn't great, your values will be saturated (values clamped between 0 and 1), and copying any kind of data between the GPU memory abd RAM accessible to the CPU is relatively slow.

I've performed simple buoyancy physics calculations partially on the GPU, sending data back to the CPU, but I'm currently trying to rewrite that to have it completely handled on the CPU, because it integrates better with the existing Physics framework used by default in Unity, and the amount of data that has to be sent from and to the GPU doesn't depend on the amount of Interacting objects. Not sure how that will work out yet.

 

Interesting... never thought about that detail, but you're right. Maybe it's better to rethink my point of view about this GPGPU stuff x)
Thanks for the tips.