gfx: error reported when calling _sg_gl_append_buffer

[tanis2000]

I have some code that is working correctly with Metal (and it was working fine with OpenGL, too while using a version of sokol_gfx from some months ago).

Now I am experiencing a weird behavior. On macOS when I turn on OpenGL I see no errors but the screen is completely black (and I have no way to debug it as I am on Silicon and the OpenGL Profiler no longer works on that platform).

On Windows it breaks on this line https://github.com/floooh/sokol/blob/72de62c89c56502c1af9710641a60d8cae94a21e/sokol_gfx.h#L9504

But there is no error logged anywhere. Is there any way to figure out what is the underlying OpenGL error? Trying to run glGetError() from a watch in MSVC debugger is not an option as it just says The evaluation was aborted because an unhandled exception occurred.

[tanis2000]

It looks like that function does no calls before reaching out to getGlError(), which means that the previous call is the one generating the error but it is not checked. And the previous call is sg_apply_uniforms. If I comment that out everything works and the application does not crash (of course the shader does not work correctly but that is expected as I am not passing the uniforms).

I would suggest to move that glGetError call somewhere in sg_apply_uniforms so that it can be caught in the right place 😄

I have added a call to _SL_GL_CHECK_ERROR at line 9438, right after the switch statement in _sg_gl_apply_uniforms and this is where it breaks. Now I am off to figure out what the actual error is as I still can't see that 😦

[floooh]

Oki, most functions in the GL backend have an _SG_GL_CHECK_ERROR() both at the front and back exactly to prevent that confusion that an error might have leaked from a previous GL call. I guess I didn't add error checking in _sg_gl_apply_uniforms() because GL error checking slows down rendering a lot, or maybe I just didn't expect that the glUniform calls can go wrong (that's the only thing that _sg_gl_apply_uniforms() does).

Note that you probably also should add an _SG_GL_CHECK_ERROR at the front of _sg_gl_apply_uniforms() just to make sure that GL isn't already in an error state.

If it turns out to be one of the glUniform calls, I guess the reason is some discrepancy between the shader code and the reflection information in the sg_shader_desc struct passed into sg_make_shader().

Are you using sokol-shdc to generate the sg_shader_desc or provide a manually populated struct to sg_make_shader?

There's also a tricky behaviour of GL shader compilers that they may remove unused uniforms from the shader interface, which then causes the glGetUniformLocation() call here to return -1:

https://github.com/floooh/sokol/blob/4bda1469d3b311af03a34dd956460776c920dc2e/sokol_gfx.h#L8552-L8556

...however, _sg_gl_apply_uniforms() ignores such unknown uniforms so that shouldn't cause any issues:

https://github.com/floooh/sokol/blob/4bda1469d3b311af03a34dd956460776c920dc2e/sokol_gfx.h#L9401-L9403

Also please let me know what the reason is when you find it. Maybe it's something that can be checked already in the sokol-gfx validation layer.

[floooh]

PS: if your code also runs on WebGL, that typically has very helpful error logging :)

Also, there's the KHR_debug extension: https://www.khronos.org/opengl/wiki/Debug_Output, but I didn't bother to support that yet because AFAIK it's not supported on macOS anyway.

If you're on Linux it might be an option to directly call the functions of that extension outside the sokol-gfx implementation (on Windows it's a bit trickier because you'd need to extend the GL loader, there was a recent fix though which makes it easier to 'inject' new functions into the GL loader without messing around in sokol_gfx.h:

https://github.com/floooh/sokol/pull/993

[tanis2000]

This is driving me nuts. The WebGL version does not rise any errors and it works but the colors of the blended geometry are off.

On Windows it keeps crashing in the same assert but only if I debut line by line. If I let it run it does not even hit my breakpoint but if I do a "retry" when the assertion pop up is shown, I end up in the same place where there is the assert with my breakpoint.

I added the same check at the beginning of the _sg_gl_apply_uniforms but it is not being triggered. So it really looks like it's the glUniform4fv setting the error.

It's so weird.

And now I am also thinking that it might be due to a bug in the OpenGL driver of Parallels as I am running everything on an ARM Windows in Parallels and I had to update to the latest version becuase it did not support OpenGL 4.1 till version 19.x

I have to get hold of a PC with a real graphics card on an Intel CPU to at least rule out this case.

[tanis2000]

Ok I just had a friend give it a try on an Intel+Nvidia box and it does not crash, thus I have discovered a but in the OpenGL implementation of Parallels, most likely :smile:

The blended colors are correct on Windows but I see some other "tearing" issues in the next scene that I need to figure out why they are only happening on OpenGL.

[floooh]

Can you check that Parallels actually supports at least GL 4.1 or 4.3?

But yeah, GL running in a VM causing issues isn't very surprising unfortunately...

re GL version, nvm, you already mentioned that...

[tanis2000]

According to Parallels changelog:

Parallels Desktop 19 for Mac 19.0.0 (54570)

Graphics: Adds support for OpenGL up to version 4.1 in Windows, enabling you to run ArcGIS CityEngine 2023, Vectorworks Vision 2023, VariCAD, and more. This version also improves performance for ArcGIS Pro software. 

In theory 4.1 is supported. With that being said, the truth is that most likely their driver does not handle some edge-cases.

BTW are you aware of any differences between GL Core and GL ES regarding blending? I thought they would behave the same way but on WebGL (where I am using the GL ES shaders compiled by shdc) the blending is off... it's like it's using different blend parameters even though I set them in a single place independently from the backend.

[floooh]

BTW are you aware of any differences between GL Core and GL ES regarding blending?

Hmm, no. Can you post comparison screenshots, maybe that rings a bell then...

[tanis2000]

Sure, here they are:

The correct one (Metal but OpenGL 4.1 on Windows is the same)

And the wrong one (WebGL)

[floooh]

Penis... tehehe.

The wrong screenshot might look like the WebGL canvas is alpha-blended with the browser background, and alpha values from your rendering are written into the frame buffer (which then might be alpha-blended and the browser background peeks through in framebuffer pixels with an alpha value < 1).

Are you using sokol_app.h to setup the WebGL context?

When setting up the WebGL context directly via Emscripten, blending with the background is enabled by default, but when using sokol_app.h, blending will be disabled, unless you explicitly set sapp_desc.alpha = true in sokol_main().

(just a shot in the dark though, but IMHO the most obvious thing to check first)

[tanis2000]

I am not using sokol_app.h, just plain SDL plus some of my own glue. The glue part for the canvas is the following:

#ifdef __EMSCRIPTEN__
  EmscriptenWebGLContextAttributes attrs;
  emscripten_webgl_init_context_attributes(&attrs);
  attrs.alpha = 0;
  attrs.depth = true;
  attrs.stencil = true;
  attrs.antialias = 0;
  attrs.premultipliedAlpha = 0;
  attrs.preserveDrawingBuffer = 0;
  attrs.enableExtensionsByDefault = true;
  attrs.majorVersion = 2;
  EMSCRIPTEN_WEBGL_CONTEXT_HANDLE ctx = emscripten_webgl_create_context("canvas", &attrs);
  emscripten_webgl_make_context_current(ctx);
#endif

I did try to change the background color of the canvas to check if anything changes but no, no good luck there.

[floooh]

Hmm, so it's not blending against the background...

I'm out of ideas then tbh... You could check what's going on with the Spectre.js Chrome extension (simple WebGL debugger): https://chromewebstore.google.com/detail/spectorjs/denbgaamihkadbghdceggmchnflmhpmk?hl=en

Safari also has a simple WebGL debugger integrated.