Catalyst 9.1 is out

[überl33t]

Any information/experiences whether ATI has fixed the dual-head bug in 9.1?

I'm referring to the bug when, if you try to use anything OpenGL-acceleration-related on a system with xorg-server >=1.4 and dual-head without BigScreen (as configured by aticonfig --initial=dual-head), you get an instant system freeze...

I'm currently stuck with xorg-server-1.3/ati-drivers-8.543 (on Gentoo) because of that bug!

[hpestilence]

fixme:d3d_shader:shader_glsl_load_constants >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUniform4fvARB @ glsl_shader.c / 524
fixme:d3d_shader:shader_glsl_load_constantsI >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUniform4ivARB @ glsl_shader.c / 401
fixme:d3d_shader:shader_glsl_select >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUseProgramObjectARB @ glsl_shader.c / 3570
fixme:d3d_shader:shader_glsl_load_constants >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUniform4fvARB @ glsl_shader.c / 524
fixme:d3d_shader:shader_glsl_load_constantsI >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUniform4ivARB @ glsl_shader.c / 401
fixme:d3d_shader:shader_glsl_load_constants >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUniform4fvARB @ glsl_shader.c / 524

Stuff like this. With NVidia it works fine (EvE Online here).

This is going to be a problem once CCP ends the classic client on March 10th. Currently I get no stations or ship models on the premium client on my HD4850 using wine through a chroot. I get the same errors as above and some errors about fragment shader(s) successfully compiled but failing to link. This on wine 1.1.15 and the 9.1 catalyst driver.

[blabub]

This is going to be a problem once CCP ends the classic client on March 10th. Currently I get no stations or ship models on the premium client on my HD4850 using wine through a chroot. I get the same errors as above and some errors about fragment shader(s) successfully compiled but failing to link. This on wine 1.1.15 and the 9.1 catalyst driver.

Yes. this is a problem. If there is no solution until march, I have to quit eve online (and no, I do not want to buy a nv card!).

[hpestilence]

Apparently the cedega beta eve client for mac supports premium and ati, so I wonder if it's a wine issue. I put a bug report up on what causes the invalid operation, all the shaders compile correctly but then fail to link according to the wine debug log.

[blabub]

Apparently the cedega beta eve client for mac supports premium and ati, so I wonder if it's a wine issue. I put a bug report up on what causes the invalid operation, all the shaders compile correctly but then fail to link according to the wine debug log.

For some weeks there was a discussion in the mailing list about this and it seems to be a problem with the ati driver, or better between wine and ati.

I tried to hack some stuff into wine but never got a usable result.
Maybe I try it again this weekend, I know for some month it was working under ati.

Same thing with pbuffer, for a while it was working very well and now only problems with it.

If you hav enough time and/or the skills for hack wine, it would be very nice if you could help.

[hpestilence]

http://bugs.winehq.org/show_bug.cgi?id=17437

The problem is found, now to wait for a decent fix .

Hi,

I think there's a problem with the driver. My technical guess on this follows:

The troublesome line in the log attached to the winehq bug seems to be this:

fixme:d3d_shader: print_glsl_info_log Error received from GLSL shader #1:
"Fragment shader(s) failed to link, vertex shader(s) failed to link. \n "

I think I've seen the fragment shader before, and I think it is the shader used
to draw the models. I think I hacked the CrossOver GLSL generator some time ago
to work around a bug on my Mac driver(replace "a = b ? c : d" with "if(b) a = c;
else a = d;").

The question is why does it fail to link? The individual shaders compile
successfully, but the linking fails. Usually this indicates some troubles with
available resources. I suspect the issue here:

trace:d3d_shader:shader_addline GL HW (2, 13) : varying vec4 IN[17];
trace:d3d_shader:shader_addline GL HW (10, 236) : varying vec4 IN[17];

Your card is a D3D10 card. I think those have 16 varyings(*), but I could be
mistaken. I know from d3d9 ATI cards that the ATI driver lies about the number
of available varyings. It claims 44 single floats are available(aka 11 vec4s),
but it refuses to link any program that uses more than 32 single floats(8
vec4s). How does that come? There are 3 implicit vec4 varyings: gl_FrontColor,
gl_FrontSecondaryColor and gl_ClipPos. Our D3D wrapper knows about this driver
quirk(on dx9 cards) and limits the number of varyings it uses to 8 vec4s, and
uses gl_FrontColor and gl_FrontSecondaryColor as the 9th and 10th if the D3D
shader needs it.

Our D3D implementation always declares the maximum amount of varyings available
so all shaders are compatible with each other and can be linked together. I
suspect that something in this vertex/fragment shader combination obstructs the
driver's GLSL optimizer or forces the driver to use an implicit varying, so the
linking fails.

This is just speculation though. I'll take a mental note to investigate this
closer. If my suspicion is right, I'll be able to reproduce it in a stand-alone
test case and send a bug report to ATI. They're pretty interested in making
CrossOver / Wine work better, so hopefully they'll fix this problem. The overall
quality of the ATI driver has been steadily improving from Wine's point of view.

(*) A GLSL varying is a variable written by the vertex shader, then interpolated
and passed to the fragment(pixel) shader.

[hpestilence]

Weird, I made a reply several hours ago but it seems to got eaten. If it shows up I'll edit it.

Anyway the problem has been found, in wine bug 17347

My HD4850 is reporting to support 17 varyings but only supports 13 due to a driver bug.

A temporary workaround is to use "13" in place of "(GL_LIMITS(glsl_varyings) / 4" (remember to remove the "/ 4") everywhere in dlls/wined3d/glsl_shader.c for my card.

Using glxinfo -l to get the GL_MAX_VARYING_FLOATS_ARB value (mine is 68) and divide by 4 is how to get the max supported vec4 varyings reported to wine subtract by 4 is how to get a working varying value.

PS: This fix should work on other games that has problems with shaders too.

[blabub]

Great news! Thanks for the much information in the bug tracker.


I'll try it out at home.

[hpestilence]

Well, it'll work for the current EVE Premium client. I just tried the Apocrypha client and it failed to compile one of the shaders.

trace:d3d_shader:find_gl_vshader No matching GL shader found, compiling a new shader
trace:d3d_shader:vertexshader_compile (0x1174cd80) : Generating hardware program
trace:d3d_shader:shader_addline GL HW (1, 0) : #version 120
trace:d3d_shader:shader_addline GL HW (2, 13) : uniform vec4 VC[107];
trace:d3d_shader:shader_addline GL HW (3, 35) : uniform ivec4 VI[16];
trace:d3d_shader:shader_addline GL HW (4, 57) : uniform bool VB[16];
trace:d3d_shader:shader_addline GL HW (5, 78) : uniform vec4 posFixup;
trace:d3d_shader:shader_addline GL HW (6, 101) : void order_ps_input();
trace:d3d_shader:shader_addline GL HW (7, 124) : vec4 R0;
trace:d3d_shader:shader_addline GL HW (8, 133) : vec4 R1;
trace:d3d_shader:shader_addline GL HW (9, 142) : attribute vec4 attrib0;
trace:d3d_shader:shader_addline GL HW (10, 166) : attribute vec4 attrib1;
trace:d3d_shader:shader_addline GL HW (11, 190) : attribute vec4 attrib2;
trace:d3d_shader:shader_addline GL HW (12, 214) : attribute vec4 attrib3;
trace:d3d_shader:shader_addline GL HW (13, 238) : attribute vec4 attrib4;
trace:d3d_shader:shader_addline GL HW (14, 262) : vec4 tmp0;
trace:d3d_shader:shader_addline GL HW (15, 273) : vec4 tmp1;
trace:d3d_shader:shader_addline GL HW (16, 284) : uniform vec4 VLC0;
trace:d3d_shader:shader_addline GL HW (17, 303) : void main() {
trace:d3d_shader:shader_addline GL HW (18, 317) : R0.xyzw = ((attrib0.xyzx * VLC0.xxxy) + VLC0.yyyx);
trace:d3d_shader:shader_addline GL HW (19, 369) : R1.w = (dot(R0.xyzw, VC[19].xyzw));
trace:d3d_shader:shader_addline GL HW (20, 405) : R1.x = (dot(R0.xyzw, VC[16].xyzw));
trace:d3d_shader:shader_addline GL HW (21, 441) : R1.y = (dot(R0.xyzw, VC[17].xyzw));
trace:d3d_shader:shader_addline GL HW (22, 477) : R1.z = (dot(R0.xyzw, VC[18].xyzw));
trace:d3d_shader:shader_addline GL HW (23, 513) : gl_Position.x = (dot(R1.xyzw, VC[224].xyzw));
trace:d3d_shader:shader_addline GL HW (24, 559) : gl_Position.y = (dot(R1.xyzw, VC[225].xyzw));
trace:d3d_shader:shader_addline GL HW (25, 605) : gl_Position.z = (dot(R1.xyzw, VC[226].xyzw));
trace:d3d_shader:shader_addline GL HW (26, 651) : gl_Position.w = (dot(R1.xyzw, VC[227].xyzw));
trace:d3d_shader:shader_addline GL HW (27, 697) : gl_TexCoord[1].x = (dot(attrib2.xyz, VC[16].xyz));
trace:d3d_shader:shader_addline GL HW (28, 748) : gl_TexCoord[1].y = (dot(attrib2.xyz, VC[17].xyz));
trace:d3d_shader:shader_addline GL HW (29, 799) : gl_TexCoord[1].z = (dot(attrib2.xyz, VC[18].xyz));
trace:d3d_shader:shader_addline GL HW (30, 850) : gl_TexCoord[2].x = (dot(attrib3.xyz, VC[16].xyz));
trace:d3d_shader:shader_addline GL HW (31, 901) : gl_TexCoord[2].y = (dot(attrib3.xyz, VC[17].xyz));
trace:d3d_shader:shader_addline GL HW (32, 952) : gl_TexCoord[2].z = (dot(attrib3.xyz, VC[18].xyz));
trace:d3d_shader:shader_addline GL HW (33, 1003) : gl_TexCoord[3].x = (dot(attrib4.xyz, VC[16].xyz));
trace:d3d_shader:shader_addline GL HW (34, 1054) : gl_TexCoord[3].y = (dot(attrib4.xyz, VC[17].xyz));
trace:d3d_shader:shader_addline GL HW (35, 1105) : gl_TexCoord[3].z = (dot(attrib4.xyz, VC[18].xyz));
trace:d3d_shader:shader_addline GL HW (36, 1156) : R0.xyz = (-R1.xyz + VC[223].xyz);
trace:d3d_shader:shader_addline GL HW (37, 1190) : gl_TexCoord[5].xyz = (R1.xyz);
trace:d3d_shader:shader_addline GL HW (38, 1221) : R0.w = (dot(R0.xyz, R0.xyz));
trace:d3d_shader:shader_addline GL HW (39, 1251) : R0.w = (inversesqrt(R0.w));
trace:d3d_shader:shader_addline GL HW (40, 1279) : gl_TexCoord[4].xyz = (R0.xyz * R0.www);
trace:d3d_shader:shader_addline GL HW (41, 1319) : gl_TexCoord[0].xyzw = (attrib1.xyyy);
trace:d3d_shader:shader_addline GL HW (42, 1357) : gl_TexCoord[4].w = (VLC0.y);
trace:d3d_shader:shader_addline GL HW (43, 1386) : order_ps_input();
trace:d3d_shader:shader_addline GL HW (44, 1404) : gl_FogFragCoord = gl_Position.z;
trace:d3d_shader:shader_addline GL HW (45, 1437) : gl_Position.y = gl_Position.y * posFixup.y;
trace:d3d_shader:shader_addline GL HW (46, 1481) : gl_Position.xy += posFixup.zw * gl_Position.ww;
trace:d3d_shader:shader_addline GL HW (47, 1529) : gl_Position.z = gl_Position.z * 2.0 - gl_Position.w;
trace:d3d_shader:shader_addline GL HW (48, 1582) : }
trace:d3d_shader:shader_glsl_generate_vshader Compiling shader object 5
fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #5: "Vertex shader failed to compile with the following errors:\nERROR: 0:23: '[' :  array index out of range '224'\nERROR: 0:24: '[' :  array index out of range '225'\nERROR: 0:25: '[' :  array index out of range '226'\nERROR: 0:26: '[' :  array index out of range '227'\nERROR: 0:36: '[' :  array index o"...

[bridgman]

At first glance the Apocrypha issue looks like an error in the shader source code. This line :

trace:d3d_shader:shader_addline GL HW (2, 13) : uniform vec4 VC[107];

... defines the VC array with 107 elements, yet :

trace:d3d_shader:shader_addline GL HW (23, 513) : gl_Position.x = (dot(R1.xyzw, VC[224].xyzw));
trace:d3d_shader:shader_addline GL HW (24, 559) : gl_Position.y = (dot(R1.xyzw, VC[225].xyzw));
trace:d3d_shader:shader_addline GL HW (25, 605) : gl_Position.z = (dot(R1.xyzw, VC[226].xyzw));
trace:d3d_shader:shader_addline GL HW (26, 651) : gl_Position.w = (dot(R1.xyzw, VC[227].xyzw));

... seem to use the 224th through 227th elements of that array, and then :

trace:d3d_shader:shader_addline GL HW (36, 1156) : R0.xyz = (-R1.xyz + VC[223].xyz);

accesses the 223rd element. Those are the 5 lines rejected by the shader compiler, but they *do* seem like they should be rejected. Anyone more familiar with GLSL want to jump in here ?