Announcement

Collapse
No announcement yet.

Catalyst 8.6 + Cedega = graphics corruption

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

  • #46
    Originally posted by aelschuring View Post
    Just got bitten by the same issue, on AMD64 (Ubuntu 8.04). Just bought a new HD4850, but if I'd known the card was unusable with MythTV I'd not have bought it just yet...

    <--snip-->
    As pointed out by someone in another thread, with Mythtv, if you use a non standard resolution, the problem is solved.

    Start Mythtv with something like 'mythfrontend --geometry 1680x1049'

    Comment


    • #47
      Cool. Must have missed that one. Indeed, telling mythtv to use 1359x768+1+0 fixes the corruption, but also makes it appear below the taskbar. But at least it's usable. Makes me curious about what the real reason for this bug is...

      Curious thing: running mythfrontend in a window (using mythfrontend.real -w) causes the same corruption unless you provide the geometry workaround. So it's not (just) a full-screen issue.

      Anyone else noticed screen flicker before the corruption sets in? It's almost like fglrx tries to switch to a new resolution, then decides that it can't or won't, and corrupts the screen in the process...

      Comment


      • #48
        Originally posted by aelschuring View Post
        Cool. Must have missed that one. Indeed, telling mythtv to use 1359x768+1+0 fixes the corruption, but also makes it appear below the taskbar.

        <--snip-->
        Check to see if your taskbar has an option 'keep below'. I use that setting with kiba-dock to get around that issue.

        Comment


        • #49
          New instance of checkerboard of death that might help spot where the regression is :S

          (still on 8.04 i386 with cats 8.6 & hd3870)

          Mirc 6.32 under wine 1.1.0 runs perfectly fine
          Upgrade to wine 1.1.1 - checkerboard :S

          I think the new Richedit or gdi+ fixes enable certain functionality that trigger the checkerboard.

          BTW anyone notice super sluggish performance in Aisleriot Solitaire when maximised?

          Hope it helps.

          Comment


          • #50
            In general Catalyst 8.6 seems much slower on my mobile X1200 (RX690M) based ATi graphics chip. 8.5 was a tad faster (not by much, though), and feels especially sluggish in 2D (and even AIGLX, like some effects with Compiz Fusion [rotate-cube, close-window-effect [fire], etc])

            Comment


            • #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; 07-22-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; 07-26-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; 08-04-2008, 03:41 PM.

                              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