cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

sandyandr
Adept I

OpenGL-OpenCL Interoperability

Dear AMD,

Could you clarify, please, the right way to access GL-CL interop. in this system:

Windows environment (Windows 7 x64).

One or several AMD GPUs.

Primary display can be not an AMD one (integrated - Intel or something else).

There should be possible to start application over RDP.

My goal is to create interconnected GL-CL contexts for each GPU to build some geometry (OpenCL) and render it into FBO (OpenGL). There is no need to show anything (except console messages - no problem here).

The problem is that while spending a huge amount of time, playing with OpenGL, OpenCL, Win32, I found no way to do it properly. Is the only chance to create these contexts - to make fake windows all over the infinitely stretched desktop with dummy plug in each of the card to keep them switched on? And still I'm not pretty sure, that it will work in all cases (RDP) of aforementioned environment.

So, what I know for now:

1. GL context cannot be created from CL one - this is the most disappointing fact;

2. wgl_amd_gpu_association - it needs one window-related GL context to generate others, but the main problem is that these others are useless(CL_INVALID_SHAREGROUP_REFERENCE_KHR) for CL context creation - I don't know the reason, but this is the second disappointing fact.

3. Last chance - try to access windows display devices, find an AMD one and use CreateDC instead of GetDC(window handle). Works fine with AMD as a primary display. As a secondary - access violation exception in ChoosePixelFormat and no GL context as a result.

P. S. By the way, please, look into SimpleGL sample (and AMD APP OpenCL Programming Guide, Appendix G - 7.1.1.1, step 😎 - what ZeroMemory(&pfd,... there for ? After pfd initialization? And it works somehow!

Please, help.

0 Likes
4 Replies
nou
Exemplar

RDP can be huge pain with GPU acceleration. It just doesn't work with OpenGL. test it only localy.

I can live with that. Although, I'll try to connect to active console session - I think, there is some chances it might work. But the main goal is to find the fault-tolerant way to load task into GPUs with minimal dependence from active desktop layout, current modes of possible displays and other unimportant details which can vary. It would be the best to launch it in a headless configuration or with just one small local display on internal graphics for console. The task is important and will be processed continuously.

0 Likes
sandyandr
Adept I

Answering to my own question.

So, tried everything, I can confirm: it seems there is no other way here. All devices should be enabled and included into desktop area. Moreover, primary device should be from AMD (al least - not an Intel one). Actually, fake windows are not necessary - thanks for that - CreateDC works fine. But two things leave questions and, I think, could be improved:

1. clCreateContext needs CL_WGL_HDC_KHR in properties - what for? It makes impossible to attach to GL contexts, created with wgl_amd_gpu_association;

2. wgl_amd_gpu_association doesn't show any GPUs not included into desktop area - even in a case they enabled with display plugged in. I think, this useful extension loose its key benefits this way, no? I know, it better be asked in an OpenGL thread but still.

It would be great if AMD driver team clarified at least one of this.

0 Likes

I am moving this post to the Graphics Programming forum.  You might gather some additional insights there.

0 Likes