(In reply to comment #1)
> I reverted it and tried glamor on my RV530. It's working fine, only having
> some corruption with Xv on some video (same as bug #72821 or bug #74811
> reported for other chipsets),

Which glamor version/tree/branch did you try? X -retro fails to start with current glamor Git on my RV350:

 Failed to link: error: shader uses too many varying components (44 > 40)

 (EE) Fatal server error:
 (EE) GLSL link failure

AFAICT this limit is the same for all GPUs supported by r300g.


> also gtkperf is slower on Lines and Circles
> (I'll try again when the 36 patches posted on glamor ML get merged),

They don't affect gtkperf according to my tests with radeonsi. But FWIW they should make core text rendering (e.g. used by xterm and some other terminal emulators by default) faster than with EXA.


> Also according to glamor source it just needs OpenGL 1.3:
> http://cgit.freedesktop.org/xorg/driver/glamor/tree/src/glamor.c#n311

Even if that's still true, r300g advertises OpenGL 2.1 support, and with that glamor uses GLSL shaders which are too complex for the hardware supported by r300g. It might be possible to fix that, but someone would have to put in the effort.

Created attachment 95093 [details]
Xorg.0.log with glamor on my RV530

I am using master git glamor from:
http://cgit.freedesktop.org/xorg/driver/glamor/
currently at: 8ad57c288d5ba6478ac9653e43c10545a6bafae1

No idea what is X -retro, I am using X.Org X Server 1.14.5 (from Ubuntu 13.10), current git mesa (git-15b4ff3) and git ati.

Xorg.0.log is attached.

I tracked the problem down to the glamor trapezoid shader. The only way I could avoid it was by building glamor with GLAMOR_TRAPEZOID_SHADER undefined in src/glamor_priv.h. Not sure why you're not running into this... What does

 glxinfo -l|grep VARYING

say for you?

Created attachment 95211 [details]
glxinfo -l on my RV530

It's 40 here:
GL_MAX_VARYING_FLOATS_ARB = 40

Also attaching full output of glxinfo -l.

(In reply to comment #4)
> It's 40 here:
> GL_MAX_VARYING_FLOATS_ARB = 40

Same as here (unsurprisingly, as r300g advertises the same value for all GPUs). So if you don't build glamor with GLAMOR_TRAPEZOID_SHADER undefined, I really don't understand why you're not getting the GLSL link failure. :(

Maybe I have a different Xorg version or applications (I am using the default Unity on Ubuntu 13.10) that don't trigger that path?

(In reply to comment #6)
> Maybe I have a different Xorg version or applications (I am using the
> default Unity on Ubuntu 13.10) that don't trigger that path?

It happens on X server startup, before any client can connect. I don't see how the Xorg version could matter either. Though one possibility is that the better shader capabilities of R(V)5xx somehow allow the GLSL compiler to stay below the varying limit...

BTW, my glamor has not GLAMOR_TRAPEZOID_SHADER undefined (or anything other special), and here is glamor compile log:
https://launchpadlibrarian.net/168488153/buildlog_ubuntu-saucy-i386.glamor-egl_0.6.0%2Bgit1403060630.cccfea~gd~s_UPLOADING.txt.gz

R300-R400 supports 2 colors and 8 generic varyings.

R500 supports the same, and if the back-face colors are unused and flat shading is disabled, it reuses unused color outputs as generic varyings, so that it can do 10 generic varyings.

In addition to that, the GLSL compiler implements varying packing, but it's only enabled if the number of supported texture indirections is greater than 8. Therefore, R500 gets the varying packing, but R300 and R400 don't, which can do only 4 texture indirections.

However, this can be easily fixed in the trapezoid shader by combining the float varyings into vec4s. Each float occupies the entire generic slot as if it was vec4.

For example, change this:

varying float trap_left_x;
varying float trap_left_y;
varying float trap_left_slope;
varying float trap_left_vertical_f;

to this:

varying vec4 trap_left;
#define trap_left_x trap_left.x
#define trap_left_y trap_left.y
#define trap_left_slope trap_left.z
#define trap_left_vertical_f trap_left.w

Etc.

commit 515bcf14d514f9dcaaf30fd0bf1ef6dd6ba9a0cd
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Tue Mar 4 12:34:26 2014 +0900

    Allow enabling glamor on R500 (and R300) class 3D engines as well.