Access violations in multiple cases (GL_LIGHTING or certain GLSL function calls)

[mid]

Hi,

I've been having trouble with one piece of test hardware on which my software is very susceptible to failure, though I don't believe I'm doing anything too heinous in them.

In the interest of wide hardware compatibility I try to support fixed-function practices in addition to modern ones though extensions, but in both code flows are things that simply lead to crashes, even if using the true, core endpoints, instead of the extensions.

Here is a minimal verifiable example with multiple tests switched through with the TEST macro: https://mid.net.ua/git/mid/broken-gl

I compile, for example, test 0 with MinGW from Linux using `i686-w64-mingw32-gcc -g -DTEST=0 -o test main.c -lglfw3 -lm -pthread -lgdi32`.

I'm not sure if the use of GLAD and GLFW disqualifies it as a minimal example. Sorry if it does.

All of them first create a window with a debug, OpenGL 4.6, compatibility, non forward-compatible context, do something specific, then enter a loop until the window is closed.

• Test 0 tries to call `glEnable(GL_LIGHTING)`, which produces a warning about fixed-function lighting being deprecated, before the process simply quits.
• Test 1 tries to call `glDisable(GL_LIGHTING)`, which leads to the same thing as test0.exe, even though lighting should be disabled by default anyway.
• Test 2 creates a shader program, in which the fragment shader contains a call to `dFdx`. This works fine and produces a white screen as intended.
• Test 3 creates a shader program, in which the fragment shader contains a call to `dFdy`. Upon starting the draw call with `glDrawArrays`, a warning is produced about recompiling the fragment shader, before the process quits. Notice how the value of `dFdy` isn't used; just existing causes the problem.
• Test 4 creates a shader program, in which the fragment shader contains a call to `imageLoad`. While the existence of this call -- and other image load-store functions -- causes the process to quit in my main project, I was not able to reproduce it in the above minimal example. I leave it in just in case I find the right state in which it happens.

I've tried the OEM-provided drivers and the latest Iris/Xe drivers that is visible in the attached SSU report (SSU.txt).

Apologies if I forgot to add anything.

Thanks in advance.

[mid]

It appears the use of `gl_FragCoord` itself causes the exact same crash as does the use of `dFdy`.

[Esteban_Intel]

Hi @mid,

Thanks for posting! We will try to reproduce this issue with the code you provided and report back.