Bug 66833 - Text rendering problems on Dota 2, all mesa drivers
Summary: Text rendering problems on Dota 2, all mesa drivers
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2013-07-11 19:53 UTC by Vedran Rodic
Modified: 2013-07-17 11:13 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Description Vedran Rodic 2013-07-11 19:53:41 UTC
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.
Comment 1 Vedran Rodic 2013-07-11 19:54:10 UTC
Recording a trace is not possible, Dota 2 segfaults when run with apitrace.
Comment 2 Vedran Rodic 2013-07-11 19:56:23 UTC
Proprietary nVidia drivers (ver 319, 325) don't show the same issues.
Comment 3 Ian Romanick 2013-07-11 21:14:25 UTC

Can you look at the Dota 2 issues with apitrace?
Comment 4 Vedran Rodic 2013-07-12 14:05:14 UTC
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)
Comment 5 Vedran Rodic 2013-07-12 15:35:46 UTC
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.
Comment 6 Laurent carlier 2013-07-12 15:51:49 UTC
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.
Comment 7 Micael Dias 2013-07-13 14:22:31 UTC
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.
Comment 8 Micael Dias 2013-07-13 21:58:38 UTC
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.
Comment 9 Micael Dias 2013-07-13 22:25:49 UTC
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:

Comment 10 Micael Dias 2013-07-13 23:12:53 UTC
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.
Comment 11 Chris Forbes 2013-07-13 23:20:02 UTC
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.
Comment 12 Chris Forbes 2013-07-13 23:38:38 UTC
Sorry for the duplicate -- was testing that hunch when you posted yours.

This does put the real fix pretty firmly on Valve's side.
Comment 13 Micael Dias 2013-07-13 23:44:24 UTC
No harm done :)
Comment 14 Ian Romanick 2013-07-15 18:11:35 UTC
(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!

> https://dl.dropboxusercontent.com/u/87650/dota_linux.225278.trim.trace.
> edited_call_180410-1_0.png

The other way to deal with GL_ALPHA being removed:

    glTexImage2D(GL_TEXTURE_2D, 0, GL_RED, w, h, 0, GL_RED,
                 GL_UNSIGNED_BYTE, pixels);

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.
Comment 15 Vedran Rodic 2013-07-17 11:13:43 UTC
This is confirmed to be fixed in current Dota 2 test build.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.