Wednesday, January 18, 2012 9:59 PMIs there any way to render data which generated with AMP using OpenGL without copying the data through the cpu?
- Edited by nagy89 Wednesday, January 18, 2012 9:59 PM
Thursday, January 19, 2012 6:43 PMOwner
We have interop between C++ AMP and DirectX so you can avoid the copy through the CPU:
We do not have any equivalent interop APIs for OpenGL, and frankly nobody here has experience with OpenGL. Sorry that I don't have a better response for you... I'll keep asking around and if anybody has more to share we'll update this thread.
- Marked As Answer by DanielMothMicrosoft Employee, Owner Friday, April 06, 2012 7:29 AM
Saturday, November 17, 2012 7:55 PM
I hate to bump old posts.
I was investigating using c++amp to port some of my code onto the GPU, and the inability to work with our existing graphics system was a big turnoff as this would mean that we would need to rewrite all the render code to an API that none of had experience with.
I am aware Microsoft want to keep everything on its platform, but using amp already provides the Windows only lockdown, and many developers don't have time to learn a new graphics api.
Is there any hope for this kind of interoperability?
- Edited by lednakashim Tuesday, January 22, 2013 3:25 AM
Thursday, January 17, 2013 6:14 AM
Does anyone have any news regarding this?
I thought it could go with C++ AMP -> DirectX Interop and then DirectX -> OpenGL Interop. VBut doesn't seem to be the case.
The other alternative I've been considering is whether C++ AMP -> CUDA interop and then CUDA -> OpenGL interop has any possibilities in this matter?This is pretty much a deal breaker for me. The application I'm working is very transfer heavy and cannot afford doing unnecessary round trips to the CPU.
- Edited by Dragon89 Thursday, January 17, 2013 11:07 AM
Thursday, January 17, 2013 11:20 PMI think that the only path available is to go from C++ AMP to DX, from DX to OpenCL and from OpenCL to OpenGL. All orered 2-tuples in that enumeration have valid interop mechanisms, although it will definitely be interesting to see if the drivers don't explode when faced with the task. You could substitute CUDA for OpenCL in the above list, but that is not vendor agnostic, which may be important depending on your goals.