[Linux] [TF2] mat_bumpmap "0" and mat_phong “0” cause black polygon corruption

[shoober420]

System Information: https://github.com/shoober420/linux-scripts/blob/main/home/shoober420/sysinfoamd

When setting mat_bumpmap "0" in console, my screen will bug out and black polygons are drawn all across the screen at random times.

[LavaDesu]

This issue started occurring after mesa 20.2, here's the issue on the mesa bugtracker.

[shoober420]

Interesting, that’s the black polygon corruption I see, but it’s not triggered by mat_phong “0”. That setting didn’t bug out TF2 in my case. I also have phong disabled, but it’s disabling bumpmaps that caused the black polygons for me.

I created a mesa issue on gitlab about this yesterday.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/3864

[shoober420]

I must mention that a combination of both mat_bumpmap “1” and mat_phong “1” must be set for the black polygons to disappear. Enabling or disabling one or the other will still produce black polygons.

[sweglord227]

this issue was fixed in the 64bit update. i previously had the same problem, and now it works as expected.

[Ristovski]

@sweglord227 I suspect the issue was fixed merely as a byproduct of the switch from Valves ToGL to DXVK (and thus might still be present under the Legacy OpenGL launch option).

[Tiagoquix]

OP, can you retest this on the new Vulkan version?

[shoober420]

I havent been on my Linux machine in over a year. Its an AMD system with wayland, but I cant launch sway on it currently. It uses wayland and sway git master builds. Ive been using my girlfriends Windows 11 machine with a 4090, so I havent given it much attention.

I miss using Linux and its been on my heart to go back to Linux for quite some time. I should be able to test in like a week. ToGL is probably the reason for this and other little graphical bugs Ive posted about.

[kisak-valve]

Closing pending feedback.

[TailsFanLOL]

Closing pending feedback.

Still broken for me (Mesa 24.1.5-arch1.2.1 Intel(R) HD Graphics 4400 (HSW GT2))

[Tiagoquix]

@TailsFanLOL Which render are you using?

[TailsFanLOL]

@TailsFanLOL Which render are you using?

As in API? OpenGL, obvious.

[Tiagoquix]

ToGL is deprecated (called "Legacy OpenGL") by Valve on Team Fortress 2 specifically. I doubt this will be fixed, since the same problem does not exist on DXVK.

[TailsFanLOL]

ToGL is deprecated (called "Legacy OpenGL") by Valve on Team Fortress 2 specifically. I doubt this will be fixed, since the same problem does not exist on DXVK.

Unrelated, but why do Source games still even use translation layers to DX? Is it really that deep into the codebase?

[shoober420]

@TailsFanLOL Source games used Direct3D as opposed to OpenGL back then. Fortunately, Source games now have an option for Vulkan which avoids the need for a Direct3D wrapper like ToGL. I would use the -vulkan launch option for all Source titles, on Linux and even on Windows. Vulkan is a superior graphics API compared to both Direct3D and even OpenGL.

[TailsFanLOL]

Fortunately, Source games now have an option for Vulkan which avoids the need for a Direct3D wrapper like ToGL.

Now tell me what DX in DXVK stands for.

[Tiagoquix]

All Source 1 games on Linux either use or used the ToGL (Direct3D-to-OpenGL) or DXVK (Direct3D-to-Vulkan) translation layer.

What exists is that there is a way to use DXVK natively, without needing Wine, but still is DXVK and not a native Vulkan render. As far as I can tell, no Source 1 game has any native rendering on Linux; all of them are just translation layers.

Native Vulkan only exists on Source 2 games (at the moment, Dota 2 and CS2).

[shoober420]

My apologize, I thought the Source games used native Vulkan when using the -vulkan launch option, but thats not the case. Youre right @Tiagoquix, Source 1 engine games use DXVK when the -vulkan option is used. I guess theres no Vulkan (DXVK) in Counter-Strike: Source yet.

https://developer.valvesoftware.com/wiki/Vulkan