Running GZDoom 3.4.0 on SDL2 on KMSDRM

[vanfanel]

Hi,

I have just build this version and I get:

Code: Select all

Using video driver KMSDRM
Failed to load OpenGL functions.

...when trying to run it outside Xorg server using the KMSDRM driver of SDL2. I am using a Pi3 where SDL2 runs on GLES2.
In the past, "+vid_renderer=0" was needed for this to work, then "+vid_renderer=0" was not needed, and now it does not work at all.
I believe it has to do with the software surface removal in this new version, but I believe that makes no sense in SDL2 since SDL2 uses GLES/GL surfaces ONLY.

[Rachael]

The removals were actually a part of a clean up effort to make the code more manageable on all platforms. The code such as it is can be extended upon if needed to provide support for additional display backends, as long as they're not old and deprecated, but it definitely shouldn't be reverted. That being said, using anything besides X11 was never officially supported by the GZDoom team, and it's kind of one of those things that was on the support status of "oh, it worked? cool!"

[vanfanel]

@Rachael: So, are you going only OpenGL (aka desktop GL) specific now? No way to run the software renderer on SDL2 anymore?
That really makes no much sense... Why would you leave all other platforms using SDL2 but not desktop GL?

[Rachael]

That is correct. The entire rendering backend was switched over to hardware rendering - the software renderer uses it as well to display the screen 2D elements - only the game view is rendered by the CPU. If you want to use any of it in an unaccelerated framebuffer - it'll have to be emulated.

That being said, I am surprised KMS doesn't support OpenGL directly.

[vanfanel]

It DOES support OpenGL, but not desktop GL but GL_ES (GLES1, GLES2, GLES3...)
So I guess it depends on what you are trying to init and how. Are you using SDL2 to init GL? Where and how? What version are you trying to init?

[Rachael]

Luckily GZDoom does support GL_ES - simply set the "gl_es" CVAR to true. Your GPU drivers must support GL_ES 3.0 for this to work, however, or GZDoom will simply fail to load.

The main init code is done in /src/posix/sdl/sdlglvideo.cpp - but some of it will be done in /src/gl_load/gl_interface.cpp

[Graf Zahl]

That really makes no much sense... Why would you leave all other platforms using SDL2 but not desktop GL?

It depends what one considers "making sense".

The main problem was that the engine had 3 different backends for the software renderer plus the hardware accelerated backend. Our recent survey clearly shows that the number of users relying on those other backends was far less than 1 %.

If you now consider that maintaining these backends costs time, things will look a lot different. We had to cope with 4 sets of code rendering the 2D stuff and they had wildly differing feature sets and limitations. And the worst of the bunch was in fact the pure software backend which was in a state that it genuinely started blocking the addition of new features.

Sometimes old legacy features need to be removed to make code maintainable again and this was a classic case for that.

[vanfanel]

Ok, makes sense, Graf.
Tried my luck with the latest MESA and GLES:

Code: Select all

./gzdoom -iwad doomu.wad +gl_es true

But since the MESA GLES implementation of the Pi only supports GLES2, I get:

Code: Select all

Using video driver KMSDRM
GL_VENDOR: Broadcom
GL_RENDERER: VC4 V3D 2.1
GL_VERSION: OpenGL ES 2.0 Mesa 18.1.1 (Compatibility profile)
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.0.16

Max. texture size: 2048
Max. texture units: 16
Max. varying: 16
Max. uniform block size: 16
Uniform block alignment: 16
Unable to load shader Default:
Init Shader 'Default':
Vertex shader:
0:1(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.00 ES

Fragment shader:
0:1(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.00 ES

Linking:
error: linking with uncompiled/unspecialized shadererror: linking with uncompiled/unspecialized shader

So I guess there's no hope for GZDoom on the Pi anymore. Are you using any GLES3 specific features? Maybe forcing GLES2 would be enough otherwise...

[Rachael]

I suspected this was about the Pi, but you didn't say it outright so I didn't want to assume.

Yes, GL_ES is not supported on GZDoom on the Pi, currently. I removed the ARM-specific definition in case someday that changes.

You need to see this post: viewtopic.php?f=49&t=60837

Anyway - X11 works fine on the Pi - and you'll have to use regular OpenGL for it to work (GZDoom uses the Legacy path for VideoCore4 chipsets) - if you can get that running with acceleration, for now, GZDoom will continue working.

[drfrag]

Alternatively you can try the legacy branch, it should still work as before on the Pi:
https://github.com/drfrag666/gzdoom/tree/g3.3mgw

[vanfanel]

@drfrag: Thanks for that fork! I will try it!

@Rachael: In sdlglvideo.cpp, you set the GLES version numbers like this:

Code: Select all

        if (gl_es)
        {
                SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
                SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2); 
                SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0); 
         }

I believe that you are trying to use version 2 then? Why doesn't GLES2 work in that case?