I'm not sure if this is a Mesa issue or a Dota 2 issue, but as reported here:
https://github.com/ValveSoftware/Dota-2/issues/38 , when using mesa drivers (I've tested both Ivy Bridge i965 and nouveau on Mesa git) the text is incorrectly rendered.
Please refer to the github.com URL for screenshots.
Dota 2 for linux is a 32bit binary.
Recording a trace is not possible, Dota 2 segfaults when run with apitrace.
Proprietary nVidia drivers (ver 319, 325) don't show the same issues.
Can you look at the Dota 2 issues with apitrace?
I've managed to capture the trace with the latest version of apitrace (sigh, ubuntu should really update the in-distro one).
http://mjesec.ffzg.hr/~vrodic/dota/dota_linux.225278.trim.trace.bz2 (25MB bz2). This is trimmed on the first frame where the problem can be seen, so glretrace -w is needed (or qapitrace/lookup state)
As Chris Forbes already noticed on #intel-gfx (sorry, didn't get to see that), the trace captured on Intel/Mesa machine shows the same problems when played back on a machine with Geforce 9800GT with nVidia proprietary drivers.
It suggests that the game takes a different code path on nVidia drivers. I tried capturing the trace on nVidia machine and playing it back and surely, it can't be played back because it uses features not supported on Intel/Mesa.
Since Valve commented they'll fix the bug on their side, I guess this could be closed, but I'm leaving it open till we are 100% percent certain that this can be fixed by them.
I cannot reproduce this with mesa-9.2 from git & llvm-3.4svn with a radeonsi card (HD7870) but game segfault/terminate when i try to launch a new game.
I just noticed that the text and background issues disappear with LIBGL_ALWAYS_SOFTWARE=1, however the game becomes unplayable due to very low framerate.
The trace from Comment #4 shows:
"174368) glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RED, width = 1024, height = 1024, border = 0, format = GL_RED, type = GL_UNSIGNED_BYTE, pixels = [binary data, size = 1024 kb]"
while the equivalent call with LIBGL_ALWAYS_SOFTWARE=1 shows:
"228562) glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_ALPHA, width = 1024, height = 1024, border = 0, format = GL_ALPHA, type = GL_UNSIGNED_BYTE, pixels = [binary data, size = 1024 kb])"
This is apparently the call that fills the texture with the font glyphs. In the hardware accelerated call we're left with a texture containing only the RED channel, while the software version gives us an ALPHA channel.
However, when rendering the glyphs, the same fragment shader is used uses the alpha channel in both code paths. I believe this is the problem.
I just tried to change the source of shaders 498, 500 and 502 to use the red channel instead of alpha channel, and it confirms my reasoning. This is how it looks:
Apparently the reason the engine creates a GL_RED texture is because OpenGL no longer supports GL_ALPHA after some version. Running the game with "MESA_GL_VERSION_OVERRIDE=2.1" will fix the font issue.
As a workaround, running the game with
produces correct rendering. If you don't offer the GL3 internalformats, the game doesn't break itself on them.
Sorry for the duplicate -- was testing that hunch when you posted yours.
This does put the real fix pretty firmly on Valve's side.
No harm done :)
(In reply to comment #9)
> I just tried to change the source of shaders 498, 500 and 502 to use the red
> channel instead of alpha channel, and it confirms my reasoning. This is how
> it looks:
Thanks for the analysis!
The other way to deal with GL_ALPHA being removed:
glTexImage2D(GL_TEXTURE_2D, 0, GL_RED, w, h, 0, GL_RED,
That will make it behave identically (for texturing) to an old GL_ALPHA texture.
I'm going to close this as NOTOURBUG and work with Valve to get this resolved in Dota 2.
This is confirmed to be fixed in current Dota 2 test build.