SDL2: adjust software-gl check to allow hardware accelerated Mesa

[ryan-sg]

Here is the only other difference I have really noticed on the SDL2 branch vs SDL1 branch. The problem isn't really a problem :-)

When launching the game, there is a 1-2 second extra delay from when the program output shows in a terminal window, to when the window starts to draw/go fullscreen. After this, the game performs as normal with no noticeable difference whatsoever 👍 (aside from #824, of course!)

I do notice I get this message:

===========================================================================
WARNING: it looks like you are using a software GL implementation.
To improve performance, try setting force_software_renderer in your
configuration file.
===========================================================================

...which seems strange as I certainly don't have software GL:

20:04 ryan@iddqd:~/games/doom2$ glxinfo|grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV770 (DRM 2.29.0)
OpenGL core profile version string: 3.1 (Core Profile) Mesa 11.2.2
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.2.2
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

Setting the recommended setting seems to make no difference, gameplay runs good regardless of setting.

[ryan-sg]

aaaaaaand I was not observant enough. I just realized that the SDL2 branch is using the XDG standard $HOME/.local/share/ location for its config files now, so obviously setting force_software_renderer in $HOME/.chocolate-doom/ did nothing.

I can now say setting the option in the proper config file does make a difference, the game opens just as fast as it did with SDL1. Still not sure why it thinks I have software GL though.

I tried using the following Mesa options:
$ MESA_GL_VERSION_OVERRIDE=3.3 MESA_GLSL_VERSION_OVERRIDE=330 chocolate-doom
as a random stab in the dark, but all it got me was a black screen to blindly exit from, and still getting the software GL warning.

[chungy]

...which seems strange as I certainly don't have software GL:

The check just looks for "Mesa" -- I've argued against it because it's a perfectly valid driver in many hardware accelerated configurations (namely, ones using free software drivers only).

[ryan-sg]

I've changed the topic of this to suggesting relaxation of assuming Mesa means software GL. I've since seen some linux guys also notice this, and as @chungy indicates hes already mentioned that there are legit hardware accelerated senarios with Mesa GL. The issue goes away entirely if one sets force_software_renderer as mentioned, but I don't see any reason for it to not work with the GL mode either...

Any other consensus?

EDIT: @chungy i don't think i can remove the OpenBSD tag, can you strip it out? I don't think we're OpenBSD specific on this one anymore.. :-)

[jmtd]

What we need is a counter-proposal to the Mesa check. I don't think we would want to just remove it, since the message is useful to many people (and merely misleading to others), so I'd prefer it if we had a better suggested check instead.

[ryan-sg]

why not look for whether direct rendering is enabled or not? if not, its using mesa software. if yes, there is some hardware acceleration available.

10:57 ryan@bofh:~$ glxinfo|grep 'direct rendering'
direct rendering: Yes

[jmtd]

why not look for whether direct rendering is enabled or not? if not, its using mesa software. if yes, there is some hardware acceleration available.

I think the issue is we are relying on what SDL exposes. At the moment we use SDL_GL_GetProcAddress to get a pointer to the glGetString. So we can use information that SDL or GL APIs expose. I'm not sure whether we can determine 'direct rendering' via this method, but I will look closer.

glxinfo uses the glXIsDirect which is part of the GLX api (which would only be available on X Windows platforms, and not guaranteed to be either). That makes things a bit tricky for us...

We might be able to use SDL_GL_GetAttribute (SDL_GL_ACCELERATED_VISUAL,...

[fragglet]

SDL_GL_ACCELERATED_VISUAL certainly looks like a better option. I'm going to add this for the 3.0 milestone.

[jmtd]

This returns 1 for me on OS X with direct rendering but also in a Linux VM with no 3D accelaration enabled (or 2D video acceleration). glxinfo in that VM returns

direct rendering: Yes
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI

[fabiangreffrath]

Nowadays, VMs are able to do miraculous things, e.g. share the hosts 3D acceleration with the guest. Are you sure that this isn't the case here?

[jmtd]

Nowadays, VMs are able to do miraculous things, e.g. share the hosts 3D acceleration with the guest. Are you sure that this isn't the case here?

I'm not certain it isn't, but I had explicitly not ticked the '3d acceleration' option in Virtual Box, and I'm running LXDE in the VM not something like GNOME shell with a compositor. So as best as I can tell, it shouldn't. Argh. I have a powerpc here, I might see what that does.

Edit: oh, I could try the VNC trick

[jmtd]

...direct rendering: yes even in a vnc session.

[jmtd]

Can we take a step back. Does anyone know of a concrete, real situation where SDL2 branch does not perform well, accelerated or not? Even in a VM, or via VNC, or on my Pi, I've not had any performance problems. So perhaps we don't even need the warning.

[RestlessRodent]

I noticed this also.

Note that on modern X with Gallium, A software rasterizer will be something such as Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits) and may also be softpipe.

I believe "Direct rendering" means that commands and such can directly be sent to the GPU and that memory mapping can be used, rather than sending stuff over the X connection (which is a bit slow) via GLX. So, you can have hardware acceleration when there is no direct rendering, just that it has more overhead because it has to travel through a pipe. On my systems running Debian sid, you cannot even force indirect rendering anymore (via LIBGL_ALWAYS_INDIRECT) because it is slower and nobody ever uses indirect rendering anyway.

[jmtd]

I've pushed two tests branches

• 825-hw-accel-detect is a mergeable patch that just changes the test over to SDL_GL_ACCELERATED_VISUAL
• 825-hw-accel-debug is a debug patch that prints out whatever the old and new methods find on stderr

I would appreciate anyone interested try the second and report what they get, in conjunction with what kind of performance they get from the branch. I'm particularly interested in any situation where choco performs poorly.

[RestlessRodent]

With the first branch the warning goes away. However, if I force software rendering by setting LIBGL_ALWAYS_SOFTWARE=1, I get no message and the title screen takes about 5 seconds to appear. Otherwise with software rendering not forced, it runs very smooth in a window at my native resolution.

My guess would be that SDL2 either checks a string with a non-matching value or just does not care at all and returns true if OpenGL is being used (at least on Linux) even if it is a software rasterizer.

[ryan-sg]

Seems to run decently here, no delay or anything for game start:

17:47 ryan@iddqd:~$ chocolate-doom -iwad games/doom2/doom2.wad
                        Chocolate Doom 2.999.0
Z_Init: Init zone memory allocation daemon. 
zone memory: 0x80d009f0000, 1000000 allocated for zone
Using /home/ryan/.local/share//chocolate-doom/ for configuration and saves
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /home/ryan/.local/share//chocolate-doom/default.cfg
W_Init: Init WADfiles.
 adding games/doom2/doom2.wad
===========================================================================
                         DOOM 2: Hell on Earth
===========================================================================
 Chocolate Doom is free software, covered by the GNU General Public
 License.  There is NO warranty; not even for MERCHANTABILITY or FITNESS
 FOR A PARTICULAR PURPOSE. You are welcome to change and distribute
 copies under certain conditions. See the source for more information.
===========================================================================
I_Init: Setting up machine state.
Failed to get raise I/O privilege level: check that you are running as root.
OPL_Init: Using driver 'SDL'.
NET_Init: Init network subsystem.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [......................................]
P_Init: Init Playloop state.
S_Init: Setting up sound.
D_CheckNetGame: Checking network game status.
startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
player 1 of 1 (1 nodes)
Emulating the behavior of the 'Doom 1.9' executable.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.
DEBUG: 3.0 Mesa 13.0.2
===========================================================================
WARNING: it looks like you are using a software GL implementation.
To improve performance, try setting force_software_renderer in your
configuration file.
===========================================================================
DEBUG: SDL_GL_ACCELERATED_VISUAL=1

[jmtd]

With the first branch the warning goes away. However, if I force software rendering by setting LIBGL_ALWAYS_SOFTWARE=1, I get no message and the title screen takes about 5 seconds to appear. Otherwise with software rendering not forced, it runs very smooth in a window at my native resolution.

Thanks that's very useful feedback. It seems this check is useless.

My guess would be that SDL2 either checks a string with a non-matching value or just does not care at all and returns true if OpenGL is being used (at least on Linux) even if it is a software rasterizer.

I think you are right. The documentation on these attributes is very sparse but I think it's possible that SDL doesn't initialise it to anything useful in the read-only case; it's really designed for writing to and signalling to SDL you want a particular behaviour.

Seems to run decently here, no delay or anything for game start:

Cheers!

[fabiangreffrath]

This is what is printed when I run the first branch:

DEBUG: 3.0 Mesa 13.0.3
===========================================================================
WARNING: it looks like you are using a software GL implementation.
To improve performance, try setting force_software_renderer in your
configuration file.
===========================================================================
DEBUG: SDL_GL_ACCELERATED_VISUAL=1

When run from the second branch both DEBUG messages disappear.

Both branches perform exactly 577 fps with -timedemo demo1 -window -2.
If I run the same command with LIBGL_ALWAYS_SOFTWARE=1, the demo takes considerably longer and performs 207 fps.

Current master branch performs at about 470 fps. Should have tried with fullscreen, maybe...

[fabiangreffrath]

Fullscreen mode: 405 fps with sdl2, 165 fps with master.