Announcement

Collapse
No announcement yet.

Catalyst 9.1 is out

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

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

    Comment


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

      Comment


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


        • #94
          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


          • #95
            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


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

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

              Comment


              • #97
                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, 08:56 AM.

                Comment


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


                  I'll try it out at home.

                  Comment


                  • #99
                    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


                    • 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, 10:43 AM.

                      Comment


                      • 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


                          • Also tried the Crysis demo (a bit optimistic maybe)

                            insane corruption of course and:

                            Code:
                            fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1130: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supported "
                            fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1135: "Fragment shader was successfully compiled to run on hardware.\nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supporte"
                            fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1133: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supportedWARNING: built-in varying gl_TexCoord [5] has mismatched access semantics between the vertex and fragment shader\nWARNING: built-in varying gl_TexCoord [5] has mismatched access semanti"...
                            lots of stuff like this with the shader # increasing through the log.


                            glxinfo claims that GL_ARB_draw_buffers is a supported OpenGL extension however...
                            I think AMD should look at GL_ARB_draw_buffers, and their GLSL support in the driver.
                            Last edited by poofyyoda; 02-19-2009, 03:53 PM.

                            Comment


                            • http://www.eveonline.com/ingameboard...hreadID=998390 How to install

                              http://www.eveonline.com/ingameboard...readID=1001885
                              Is the patch for the Singularity copy your Program Files/CCP/EVE installation to EVE2. The patch will ask which directory to install in. Copy the RTP file elsewhere or the patcher will delete it if it errors out then copy back to try again. I've went through GB's of bandwidth because the new patcher doesn't work as nice as the old one.



                              fixme:d3d_shaderrint_glsl_info_log Error received from GLSL shader #1130: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supported " is just a warning whenever the extension is called into the shader seems to work though.

                              The easiest way to debug shader issues is to run a game with:
                              WINEDEBUG="d3d_shader" wine game.exe &> gameshaders.log

                              It creates some big log files though so make sure you have space for them. For eve-online I get about 100 - 200 MB logs. Then searching for "INVALID" should bring you to the first opengl error and scrolling up from that look for shaders that weren't successfully compiled or linked.

                              Looks like the shaders for Crysis are compiled and linked successfully since there isn't any GL_INVALID_OPERATION. Not sure what's with the corruption though.

                              Comment


                              • So I worked around that shader compile error (I put in a value of 512 to be safe, a 8800gts can do 1024 and my card outperforms a 8800gtx) for the Apocrypha client and still didn't get any models the only error I seem to get is the same as the crysis one.

                                Code:
                                fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #1: "Fragment shader(s) linked, vertex shader(s) linked. \nWARNING: 0:2: extension 'GL_ARB_draw_buffers' is not supportedWARNING: built-in varying gl_TexCoord [5] has mismatched access semantics between the vertex and fragment shader\nWARNING: built-in varying gl_TexCoord [5] has mismatched access semanti"...
                                For some reason wine is getting that I support only this
                                Code:
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_SHADER float constants: 128
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_SHADER float constants: 128
                                If you subtract the few that wine uses it comes to 107.

                                while a 8800gts reports it can do this
                                Code:
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_SHADER float constants: 1024
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_SHADER float constants: 512

                                PS: I'm suspecting that these values are wrong or something, the 2147483647 value doesn't make sense and a 8800gts has higher values.
                                Code:
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM float constants: 256  <-- this might be correct
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM native temporaries: 256  <-- 8800gts supports 4096
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_PROGRAM native instructions: 2147483647  <-- 8800gts supports 8192
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM float constants: 256  <-- this might be correct
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM native temporaries: 256  <--  8800gts supports 4096
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_PROGRAM native instructions: 2147483647 <-- 8800gts supports 8192
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_VERTEX_SHADER float constants: 128  <-- 8800gts supports 1024 and this is the cause of the shader failing to compile
                                trace:d3d_caps:IWineD3DImpl_FillGLCaps Max ARB_FRAGMENT_SHADER float constants: 128  <-- 8800gts supports 512
                                Last edited by hpestilence; 02-20-2009, 03:09 AM.

                                Comment

                                Working...
                                X