Announcement

Collapse
No announcement yet.

Catalyst 8.6 + Cedega = graphics corruption

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

  • #51
    8.7 fixes the mirc issue - i dont know what you did ati but thankyou

    Both mirc 6.33 and 6.32 are fine under wine.

    checkerboard still popping up after opening system monitor :S

    crossover games still checkerboarding with steam

    aisleriot solitaire still sluggish...
    Last edited by hmmm; 22 July 2008, 01:05 AM.

    Comment


    • #52
      Originally posted by hmmm View Post
      checkerboard still popping up after opening system monitor :S

      crossover games still checkerboarding with steam
      What distribution / X version are you using?

      For me (on Gentoo amd64) settting the ~amd64 keyword for all X packages (not just the server, also all the different libraries and protocol headers) and removing and then re-emerging all those packages removed the corruption for me with Catalyst 8.7 on a Radeon HD 4850.

      Comment


      • #53
        Originally posted by dscharrer View Post
        What distribution / X version are you using?

        For me (on Gentoo amd64) settting the ~amd64 keyword for all X packages (not just the server, also all the different libraries and protocol headers) and removing and then re-emerging all those packages removed the corruption for me with Catalyst 8.7 on a Radeon HD 4850.
        hardy (8.04.1) & 7.3 - with crossover games 7.1 steam still corupts :S

        i wasn't expecting anything special from a rebase to wine 1.0 though - at least i can focus on uni work until cats 8.8 comes round.

        Thankfully wine 1.1.2 hasn't broken mirc 6.33 either - i'm a bit worried as the gdi+ n richedit stubs get replaced it'll kill it again...
        Last edited by hmmm; 26 July 2008, 04:52 AM.

        Comment


        • #54
          A workaround

          It seems atleast it is possible start blender without causing the corruption:

          1) Switch to a smaller view (Ctrl-Alt-+, 1280x1024 here)
          2) Start blender
          3) Switch back to 1680x1050
          * You'll notice now that the opengl view isn't fully scaled to the window
          4) Resize the blender window to fit your needs.

          Comment


          • #55
            Switching to a lower resolution worked for me.
            I can start Blender with corruption. Also Foobar on Wine works fine too.

            Comment


            • #56
              It seems that at least for me (on Gentoo amd64 multilib, Radeon HD 4850) substituting the xorg-x11 libGL.so for the ATI one while using the fglrx driver is a quick&dirty fix for this.

              Starting Kaffeine (opengl output) with
              'LD_PRELOAD=/usr/lib64/opengl/ati/lib/libGL.so kaffeine'
              and then switching to fullscreen and back corrupts the screen, while when starting with
              'LD_PRELOAD=/usr/lib64/opengl/xorg-x11/lib/libGL.so kaffeine'
              there is no corruption.

              'eselect opengl set xorg-x11' has the same effect but system wide and permanent.

              glxinfo reports the same info for both the ati and xorg-x11 libGL.so (direct rendering, OpenGL version 2.1.7769 Release) except for the GLX_MESA_copy_sub_buffer extension, which is only reported for the xorg-x11 version.

              There is also no corruption in wine and native OpenGL games seem to run stable (at 1920x1200).

              Can anyone else confirm this?

              Comment


              • #57
                Originally posted by dscharrer View Post
                It seems that at least for me (on Gentoo amd64 multilib, Radeon HD 4850) substituting the xorg-x11 libGL.so for the ATI one while using the fglrx driver is a quick&dirty fix for this.

                *snip*

                glxinfo reports the same info for both the ati and xorg-x11 libGL.so (direct rendering, OpenGL version 2.1.7769 Release) except for the GLX_MESA_copy_sub_buffer extension, which is only reported for the xorg-x11 version.

                There is also no corruption in wine and native OpenGL games seem to run stable (at 1920x1200).

                Can anyone else confirm this?
                WTF? Your post both excites and confuses me. I must not be understanding something somewhere, but I was certain that using the xorg-x11 GL libs put you solidly into software Mesa land. You're still getting functional hardware acceleration??

                I'm on ~amd64 myself, I'll be trying this later tonight. If it works the way you describe, I'll name my nextborn child after you.

                Comment


                • #58
                  Originally posted by Forge View Post
                  WTF? Your post both excites and confuses me. I must not be understanding something somewhere, but I was certain that using the xorg-x11 GL libs put you solidly into software Mesa land. You're still getting functional hardware acceleration??
                  Unless glxinfo is lying AND software acceleration can get sauerbraten with all settings to highest and 1920x1200 pixels over / close to the 200fps cap, yes, I'm getting full HW acceleration.

                  Originally posted by Forge View Post
                  I'm on ~amd64 myself, I'll be trying this later tonight. If it works the way you describe, I'll name my nextborn child after you.
                  Wish you luck.

                  Comment


                  • #59
                    AFAIK libgl.so can connect to either a direct rendering driver (via Direct Rendering Interface aka DRI) or can encode the GL commands through the X protocol to run the commands indirectly on the X server. The X server, in turn, can load an accelerated driver, giving you Accelerated Indirect GL X aka AIGLX.

                    The LIBGL_ALWAYS_INDIRECT option forces libgl.so to chose the indirect path. Unfortunately almost all of the documentation refers to this as the "indirect, unaccelerated" path but that is of course no longer the case, since AIGLX is all about having the X server connect to the accelerated HW driver rather than good 'ol Mesa.

                    If the accelerated HW driver fails to open, either because it is not there or because the kernel module (drm) did not load properly, then presumably both direct (libGL => 3d driver) and indirect (libGL => X server => 3d driver) could fall back to Mesa but I don't know the details of that fallback (yet).

                    The libgl included with fglrx usually (but not always) behaves the same as the X libgl (remember that the xorg libgl supports direct and indirect accelerated 3d too) so it's certainly possible that this could work with acceleration and if it addresses the Wine issues is a useful clue.
                    Last edited by bridgman; 04 August 2008, 03:41 PM.
                    Test signature

                    Comment


                    • #60
                      Dscharrer - You are my hero.

                      Last night I put the 4850 in, unmerged all my NV crap, merged fglrx, and then reset the GL libs back to the stock xorg ones.

                      Poof, everything just magically works.

                      Left the system remerging world to re-establish coherency last night, should be ready for real testing tonight.

                      Non-sequiteur: It's really surprising just how many packages in Gentoo link in dependency against fglrx/nvidia. I removed the Nvidia drivers and hand-remerged half a dozen others, and STILL things were trying to pull in the nvidia drivers.


                      Bridgman : No offense intended to the fglrx devs, but using xorg's libs instead of ATI's appeals to me, plus it has solved a *lot* of little issues already. Might want to make a note of this usage of AIGLX+Xorg libs as a possible troubleshooting step in the future.

                      Comment

                      Working...
                      X