GL2 and GL4 problem on AMD card

[bosoni]

Tested newest h3d develop w10 x64.

I got these errors:

[h3d] Initializing GL4 backend using OpenGL driver '4.0.14736 Core Profile Context 20.9.1 27.20.12029.1000' by 'ATI Technologies Inc.' on 'Radeon RX550/550 Series' [h3d-err] Could not find all required OpenGL function entry points [h3d-err] Failed to init renderer backend (OpenGL 4.0), retrying with legacy OpenGL 2.1 backend [h3d] Initializing GL2 backend using OpenGL driver '4.0.14736 Core Profile Context 20.9.1 27.20.12029.1000' by 'ATI Technologies Inc.' on 'Radeon RX550/550 Series' [h3d-warn] Render target depth precision limited to 16 bit [h3d-err] Failed to create shadow map

HACK #1: In utOpenGL.cpp : initModernExtensions( bool &r ) when I put return; just before if ( glExt::KHR_debug ) then GL4 works.

HACK #2: This brokes GL2 on my AMD graphics card: https://github.com/horde3d/Horde3D/commit/35b510cf535fe50281250205228eb8fb9e1535b0
when I commented out ASSERT(pixels); and got back uploadTextureData() functions, GL2 works (but it might not work on Nvidia cards).

[algts]

Hello. About GL4: I don't have access to Windows machine with amd card currently, so I can't test the situation myself. Does the engine correctly find extension KHR_debug and cannot get function pointers? Or it cannot find KHR_debug extension? About GL2: I'll take a look and test on Intel and Nvidia, maybe this commit should be reverted.

Thanks.

[bosoni]

Yes, KHR_debug is found but any of these functions arent found:

  r &= ( glDebugMessageCallbackKHR = ( PFNGLDEBUGMESSAGECALLBACKKHRPROC ) platGetProcAddress( "glDebugMessageCallbackKHR" ) ) != 0x0;
  r &= ( glDebugMessageControlKHR = ( PFNGLDEBUGMESSAGECONTROLKHRPROC ) platGetProcAddress( "glDebugMessageControlKHR" ) ) != 0x0;
  r &= ( glDebugMessageInsertKHR = ( PFNGLDEBUGMESSAGEINSERTKHRPROC ) platGetProcAddress( "glDebugMessageInsertKHR" ) ) != 0x0;
  r &= ( glGetDebugMessageLogKHR = ( PFNGLGETDEBUGMESSAGELOGKHRPROC ) platGetProcAddress( "glGetDebugMessageLogKHR" ) ) != 0x0;

All these puts r to false.

[algts]

I've probably found the cause (from extension spec): NOTE: when implemented in an OpenGL ES context, all entry points defined by this extension must have a "KHR" suffix. When implemented in an OpenGL context, all entry points must have NO suffix, as shown below.

So for opengl khr suffix should be removed from function names.

[bosoni]

Removing KHR works.

There is one more problem I just found. Now I can use GL4 and GL2 BUT if I use GL4+GL2 and GL4 fallbacks to GL2, then there are only black screen. I havent found yet which causes this, think that maybe somewhere OpenGL4 (flag) is still used even h3d window uses OpenGL2...

[algts]

Ok I'll try to simulate this situation later today.

[algts]

@bosoni It seems that currently there are three different implementations for createTexture and uploadTextureData (one for each render interface). It should probably be reduced to one implementation, but it would require additional round of thorough testing. I think that for now we can revert the commit you've posted for GL2 backend and make one implementation for later versions of Horde. I'll prepare pull requests shortly that should fix the issues. Thanks for reporting.

[bosoni]

About that GL4 fallback to GL2 (and using sampleframework): It seems that window is created only once. So if one creates gl4 window and getting function pointers failed, it will use gl2 shaders but on gl4 window (does that matter, dont know, but I think this is why black screen).

This 'bug' appear only when some function doesnt found (because if there is no gl4 support at the first place, then gl4 window isnt opened).

So, dont know if this is a bug or not.

[algts]

I've simulated gl4 fallback to gl2 on Linux+mesa and found out that engine cannot initialize because the context was created with core profile that does not provide extensions, required for gl2 backend. So, one of the workarounds is to use compatibility profile when creating the context (but it will work only for closed source drivers). Basically, we have to rework the path of failure - we should not automatically try to init gl2 backend in case of failure in the engine - h3dInit has to return false and sample framework has to recreate window with gl2 context and try initing engine again (if is allowed to do it).

[algts]

@bosoni Can you please test the latest develop branch to check whether it fixes gl4->gl2 fallback path on windows + amd? Thanks.

[bosoni]

Hi. Yes, tested newest dev branch GL2, GL4, GL2+GL4 and GL2+GL4(forced to fail, fallback GL4->GL2) and all paths works. I think this can be closed then.

[algts]

@bosoni Thanks for the help!