Announcement

Collapse
No announcement yet.

Catalyst 9.1 is out

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    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!).

    Comment


    • #92
      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.

      Comment


      • #93
        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.

        Comment


        • #94


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

          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; 19 February 2009, 10:32 AM.

          Comment


          • #95
            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; 19 February 2009, 09:56 AM.

            Comment


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


              I'll try it out at home.

              Comment


              • #97
                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"...

                Comment


                • #98
                  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; 19 February 2009, 11:43 AM.
                  Test signature

                  Comment


                  • #99
                    Originally posted by hpestilence View Post
                    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.
                    Where I can get the beta? Google is not willing to tell it me.


                    The normal client runs now perfect! Thanks so much!

                    Comment


                    • No such luck here on Command and Conquer 3, HD4650 - catalyst 9.1, wine 1.1.15

                      gazillions of these:

                      fixme:d3d_shader:shader_glsl_select >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glUseProgramObjectARB @ glsl_shader.c / 3584
                      fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glDrawElements @ drawprim.c / 276
                      I turn shader detail up, then the in-game lags severely and shader-applied objects disappear.

                      Comment

                      Working...
                      X