[SOLVED] Problems with shaders

[bzt]

Hi,

I've updated my distro, and I'm unable to run SuperTuxKart any more. It plays the music, but all I can see is a gray screen, nothing else.
If I start it from a terminal, I can see dozens of error messages like these complaining about the shaders:

{l Code}: {l Select All Code}

[info   ] ShaderFilesManager: Compiling shader: /usr/share/supertuxkart/data/shaders/screenquad.vert
[error  ] ShaderFilesManager: Error in shader /usr/share/supertuxkart/data/shaders/screenquad.vert
[error  ] ShaderFilesManager: 0:1(10): error: GLSL 4.50 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.50, 3.30, 1.00 ES, and 3.00 ES

[info   ] ShaderFilesManager: Compiling shader: /usr/share/supertuxkart/data/shaders/motion_blur.frag
[error  ] ShaderFilesManager: Error in shader /usr/share/supertuxkart/data/shaders/motion_blur.frag
[error  ] ShaderFilesManager: 0:1(10): error: GLSL 4.50 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.50, 3.30, 1.00 ES, and 3.00 ES

[error  ] Shader: Error when linking these shaders :
[error  ] shader: screenquad.vert
[error  ] shader: motion_blur.frag
[error  ] Shader: error: no shaders attached to the program
...


Interestingly on my smaller boy's computer SuperTuxKart works (same distro, same package versions, updated at the same time, etc. but different video card.) The video card on the faulting machine

{l Code}: {l Select All Code}

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV610/M74 [Mobility Radeon HD 2400 XT]


Any idea how to fix this? STK was working up until recently, only the latest update messed it up. GLX version 1.2, 1.3 and 1.4 are all installed and available.
If you say to patch and compile STK myself, that's okay, I can do that if that helps.

Cheers,
bzt

[benau]

Try start stk with MESA_GL_VERSION_OVERRIDE=3.3 /usr/bin/supertuxkart (whatever path)

[drummyfish]

Yeah, seems like GPU+drivers aren't supporting the newest OGL, and STK team states in its FAQ they don't want to support old computers because they prioritize features.

My computer is too old to run SuperTuxKart. What should I do?

You can try your luck and run the game. If it works, great! If it doesn't, we're sorry for you, but we can't support everything. We have a limited amount of manpower and time to support old GPUs. If we did try to support old GPUs, it would basically mean no new and advanced features. Please do not open bug reports because your computer is too old to run SuperTuxKart!

Time to buy a new computer I guess.

[benau]

If you are not helping then go away

Up until now you caused nothing but trouble here

[benau]

And for bzt cases seems like the new distro incorrectly reports wrong supported ogl version then being an old one

[bzt]

And for bzt cases seems like the new distro incorrectly reports wrong supported ogl version then being an old one

My understanding of the message is that my distro ships a newer ogl version for this card than what STK supports. Anyway, your suggested workaround with the environment variable worked like a charm!

Thank you very very much, my boy is extremely happy that he can play STK again! He insisted that I should say thanks to you! We probably will have a soccer party right away! :-D Thanks!

Cheers,
bzt

[benau]

Partially correct, stk should work with latest (4.5) ogl drivers, but seems that your amd card should not support 4.5 due to its architecture (too old), and the drivers told stk wrongly

https://en.m.wikipedia.org/wiki/Radeon_HD_2000_series

Anyway if my workaround works then it's great

[bzt]

Partially correct, stk should work with latest (4.5) ogl drivers, but seems that your amd card should not support 4.5 due to its architecture (too old), and the drivers told stk wrongly

https://en.m.wikipedia.org/wiki/Radeon_HD_2000_series

Thanks for the info. Yeah, my hardware is definitely old, unfortunately I can't afford a new one. Looks like the latest update have introduced a bug in the video card driver.

Anyway if my workaround works then it's great

Yep, it does!

Just for the records, sometimes the workaround crashes the game, right at start the screen blinks (changes resolution) then the game quits and on the terminal it says

{l Code}: {l Select All Code}

..:: Antarctica Rendering Engine 2.0 ::..
X connection to :0 broken (explicit kill or server shutdown).


There's no other message, and nothing in the Xorg.log either. I don't know why this is happening (the X server is still running for sure and I haven't killed the game either), and it happens only occasionally. I believe this must be driver related too, a kernel buffer not freed properly or a lock not released under some circumstances or something like that. No biggie at all btw, I've told my boy if the game doesn't start, just click on it again, that solves the problem.

Thank you again!
bzt

[bzt]

Update: now the "sometimes crashes on startup" problem is gone too. Unfortunately I cannot tell if it was a kernel driver update or if it was an STK update that fixed the problem, but it is working properly every time now. It went away after an update, that's for sure.

On another machine, which has an AMD/ATI video card, I got problems with larger tracks / more carts. The game crashed and the message was (displayed on terminal as well as in dmesg):

{l Code}: {l Select All Code}

amdgpu: Not enough memory for command submission!


It looks like I wasn't alone with this issue, see here for example, yet so far I was unable to find any solution on the internet.

According to the Linux GPU Driver Developer’s Guide, the GPU driver should allocate some RAM automatically on its own, however in reality this isn't working! Specifying the amount manually fixes the problem. If you have the same issue, this is how I've fixed it: the machine has 16G of RAM, half of which I've assigned manually to the GPU:

{l Code}: {l Select All Code}

# cat >/etc/modprobe.d/amdgpu.conf
options amdgpu gartsize=8192
options amdgpu gttsize=8192
^D
# reboot

To see if the above workaround is indeed working, type glxinfo | grep memory, and check if the "Total available memory" line is bigger than the value in the "Dedicated video memory" line.

{l Code}: {l Select All Code}

$ glxinfo | grep memory
   ...
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 1024 MB
    Total available memory: 9216 MB
   ...


Now this won't solve the kernel's memory leak issue, but it gives enough space to live with it. If you are running STK for a long time, and you keep switching tracks one after another, then sooner or later you'll still face the memory error; but if you restart STK then the unused memory gets freed (my guess is, if the process goes away, then the kernel brute-force frees all the memory assigned to that process, no matter how and which driver allocated those).

Hope this is going to be useful to other STK users with AMD cards too.
bzt