Page 10 of 11 FirstFirst ... 891011 LastLast
Results 91 to 100 of 107

Thread: Catalyst 9.1 is out

  1. #91
    Join Date
    Nov 2008
    Location
    Finland
    Posts
    5

    Default

    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!

  2. #92
    Join Date
    Feb 2009
    Posts
    23

    Default

    Quote Originally Posted by blabub View Post
    Code:
    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.

  3. #93
    Join Date
    Aug 2008
    Posts
    26

    Default

    Quote Originally Posted by hpestilence View Post
    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!).

  4. #94
    Join Date
    Feb 2009
    Posts
    23

    Default

    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.

  5. #95
    Join Date
    Aug 2008
    Posts
    26

    Default

    Quote Originally Posted by hpestilence View Post
    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.

  6. #96
    Join Date
    Feb 2009
    Posts
    23

    Default

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

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

    Quote Originally Posted by Stefan Dösinger
    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.
    Last edited by hpestilence; 02-19-2009 at 10:32 AM.

  7. #97
    Join Date
    Feb 2009
    Posts
    23

    Default

    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.
    Last edited by hpestilence; 02-19-2009 at 09:56 AM.

  8. #98
    Join Date
    Aug 2008
    Posts
    26

    Default

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


    I'll try it out at home.

  9. #99
    Join Date
    Feb 2009
    Posts
    23

    Default

    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.

    Code:
    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"...

  10. #100
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,544

    Default

    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 ?
    Last edited by bridgman; 02-19-2009 at 11:43 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •