Created attachment 62078 [details]
apitrace (cf. https://github.com/apitrace/apitrace/tree/1.0)
I just tried Glyphy on r600g and the output is very bad.
Don't know if its Glyphy bug or Mesa bug, but if I force software rendering in Mesa then I do see the output.
Attached screenshots of bad (r600g) and good (software render).
The bad render was obtained by:
The good one:
I tested on:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL version string: 2.1 Mesa 8.0.2
OpenGL shading language version string: 1.20
I'll try to test on mesa git later to see if its still an issue there.
Also attached is a an apitrace, and the bad render can be reproduced with:
The good render (initialization a bit slow, but works):
LIBGL_ALWAYS_SOFTWARE=1 build/glretrace lt-glyphy-demo.trace
The source code for Glyphy can be found here:
Created attachment 62079 [details]
Created attachment 62080 [details]
With the git version of Mesa I get an error, opened new bug here: https://bugs.freedesktop.org/show_bug.cgi?id=50338
EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
(In reply to comment #3)
> With the git version of Mesa I get an error, opened new bug here:
> EE r600_shader.c:140 r600_pipe_shader_create - translation from TGSI failed !
The bad render might be because the shader tries to use too many registers, some earlier version of Mesa git printed some errors about GPR count limit being exceeded.
(In reply to cyberkm from comment #5)
Have you confirmed it happens with latest Mesa git? What hardware did you try it on?
Yep, latest mesa git.
05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Antilles [Radeon HD 6990]
mesa r600 gallium.
The app works fine if i switch to software renderer.
Could you re-test with the latest mesa-git? As of mid September some patches landed that improved the register use.
I myself tried it on an AMD 6850 HD and the trace works fine now.
This should be fixed since version 17.2.
Actually, that should be v17.3.