cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

yw3410
Adept I

EGL shared context crashing AMD display driver

Hi,

I don't seem to be able to post in the OpenGL/Vulkan subspace so I've posted here.

Using the OpenGL ES SDK with context sharing between two different threads causes the AMD display driver to crash with no error messages when drawing using a program created on a secondary thread.

I'm using the HD7850 with the latest drivers (not hotfixed). However I've also tried this on a HD6670 with similar problems.

There are no errors being generated when calling eglGetError with the context creation.

There are no errors after binding the program, buffers in the main thread.

The only time in which something errors out is a call to glDrawElements in which the display driver crashes with no warning.

//secondary

egl.EGL_SAMPLES, 0,

egl.EGL_SURFACE_TYPE, egl.EGL_PBUFFER_BIT,

egl.EGL_RENDERABLE_TYPE, EGL_OPENGL_ES3_BIT,

egl.EGL_BLUE_SIZE, 8,

egl.EGL_GREEN_SIZE, 8,

egl.EGL_RED_SIZE, 8,

egl.EGL_ALPHA_SIZE, 0,

egl.EGL_BUFFER_SIZE, 32,

egl.EGL_DEPTH_SIZE, 16,

egl.EGL_NONE

//main thread

egl.EGL_LEVEL, 0,

egl.EGL_SURFACE_TYPE, egl.EGL_WINDOW_BIT,

egl.EGL_RENDERABLE_TYPE, EGL_OPENGL_ES3_BIT,

egl.EGL_BLUE_SIZE, 8,

egl.EGL_GREEN_SIZE, 8,

egl.EGL_RED_SIZE, 8,

egl.EGL_ALPHA_SIZE, 8,

egl.EGL_BUFFER_SIZE, 32,

egl.EGL_DEPTH_SIZE, 24,

egl.EGL_NONE

12 Replies
Matt_AMD
Community Manager

Hi,

You need to post here and ask for access.

Unfortunately we cannot provide technical support for developers in this section.

Since it's unlikely that anyone in the community will know what to do (as it's a driver crash), where is the correct place to report this/get some guidance on how to solve this?

I was under the impression that it was here due to some of the older threads.

0 Likes

I've added you to the developer white list so you can post in all of the developer forums. I've deleted the cross-posted message and kept this one since it is in the correct forum.

0 Likes
cgrant78
Adept III

I"m using the same hardware in terms of GPU and GPU driver with context sharing and using a program created in one context in another does not cause a crash. I've had other issue with the emulator such as no antialiasing, but never a crash. I would verify that both context are created correct and that the context is actually bound to the thread prior to making any OpenGL call. Also, without any form of synchronization your are just asking for trouble, as its not as simple as create a context on another thread, use this context to create some GL resource, then use the created resource on another thread. The thread consuming the GL resource has to guarantee that the resource is fully created prior to using it. You didn't mention what kind of synchronization you are using..

0 Likes

Both contexts are indeed created correctly (verified using eglGetError()), both are bound correctly as I can make gl calls on both threads - which shouldn't be possible if the egl context wasn't created on either of them (I verify the program state is as expected on the second thread before using it).

I am using sync objects with glFenceSync operations to do synchronization across threads, that is to create a sync object on the secondary thread and then call waitSync before using the program and vbo.

are you using the 15.12 drivers?

Also do you mind sharing which EGL configs you're using?

0 Likes

Yes, using the 15.12 Hotfix. After running into the multisampling issue with the emulator I switched to using another emulator, but I did use the AMD emulator after updating my drivers. The code that does the EGL configuration is not straight forward, as the configuration params are based on values retrieved from a private structure. The reason for the complication is that my OpenGL (ES) context creation is abstracted out so context creation params are set based on common defined values, but are handled differently internally to each context implementation. However, if you are not getting errors in regards to the program and only in the context of the draw call, then I would look elsewhere to input to the draw command, ex. buffer object, VAO etc. Remember VAO are NOT shared across context..meaning you cannot create on in a different context and use it in another.

0 Likes

Yes I know - I'm only sharing VBOs across the different contexts which according to the spec is possible (again I make sure to use sync objects to make sure that the buffers are updated).

I've been trying several different emulators with no luck (PowerVR and the ARM one as well) and varying issues, may I ask which one you're using?

The reason why I think it may be either a config issue or a driver issue is that the code works fine on the Nvidia development machine.

When you mean the 15.12 hotfix do you mean the 16.1? Since that's the current hotfix version.

0 Likes

..you are correct I'm on 16.1 ( I tried the 15.12, but the installation wouldn't complete on Windows 10 ). If you are not getting any EGL/OpenGL errors, then its kinda hard to figure out whats going on. Seems like you are experiencing the opposite as me all others emulators worked fine for me. The only one I've had issues with in the past is the AMD one, which at one point was the only one I had no issues with. In any case, I use the PowerVr, Mali, Qualcomm and AMD OpenGL ES emulator all on a regular basis. I just run a batch file with a different command to use each emulator, but I've been testing with the PowerVr emulator recently ( not for any particular reason, besides thats what the current batch file is set to ).

0 Likes

I'm still on Win 7 (though the Nvidia dev machine is on Win 10) though I doubt that's an issue. Also are you using the 64-bit or 32-bit versions?

I think I'm going to try a clean install of the 16.1 driver to see whether it helps later this week or early next week once I've closed a few other issues first.

Thanks for your help - it's good enough to know that there's someone who's using the features in the emulator because then it means that it should be solvable.

0 Likes

Glad I could share some insight. I have the 64-bit versions, but I've only used the 32-bit version of each emulators. On thing you could do is force using a single context and see if the crash still exist ( if you haven't done so yet ). But I feel confident that you are going to find that its probably a little mistake made elsewhere that is causing the issue. Chase my tail one too many times over a simple mistake ( usually during late night coding sessions and just being fatigue ). The one thing I don't feel confident about is emulator bugs getting fixed or fixed in a timely manner. I think its being a few months now that I've reported one and I've yet to have a single response to my post. I had some graphical artifacts when using the AMD OpenGLES emulator with any context whose sample count > 0. The issue did not occur in any other emulator or the previous version of this emulator. If I created the context with a sample count of 0, then it worked fine. Still haven't gotten a response like I said, so that why I started using the other emulators.

0 Likes
lukef
Adept I

I ran into the same issue, but on WGL/Desktop OpenGL - a hard driver crash on first use of a shader linked on another context/thread. I also could not resolve it with sync fences. No other hardware than AMD was affected (tested Nvidia, Intel, Qualcomm, ARM, etc)

The solution was to call glFlush() immediately after glLinkShader() on the secondary thread

0 Likes

Hello, thanks for your input. Can you provide more information about the platform/software/OS/card version you're using? Also, if you can share the minimal program(source code and the binary), I can start investigating your problem immediately.

Looking forward your more input, thanks again.

0 Likes