Announcement

Collapse
No announcement yet.

AMD Catalyst 9.10 dropped in Ubuntu 9.10

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

  • #11
    Originally posted by AdrenalineJunky View Post
    installed karmic to try it out, seems much improved - compiz + mplayer is working flawlessly so far, nexuiz and sauerbraten also worked well with compositing on.
    But the 1-2s freezes when maximizing windows/etc. are still there.

    Comment


    • #12
      Originally posted by d2kx View Post
      But the 1-2s freezes when maximizing windows/etc. are still there.
      I don't think this will ever be fixed. It's been like that for at least 14 driver releases (like the xv-showing-washed-colors issue) and several xorg releases. Some blame xorg, some blame ATI and nobody finds a solution valid for Intel and ATI cards.

      So the options are patching xorg, using the open source driver (works great with 2D effects) or disabling composite. Waiting for a driver to fix this is too optimistic.

      Comment


      • #13
        Originally posted by Fran View Post
        I don't think this will ever be fixed. It's been like that for at least 14 driver releases (like the xv-showing-washed-colors issue) and several xorg releases. Some blame xorg, some blame ATI and nobody finds a solution valid for Intel and ATI cards.

        So the options are patching xorg, using the open source driver (works great with 2D effects) or disabling composite. Waiting for a driver to fix this is too optimistic.
        Well, it's there since the latest Ubuntu 9.04 release earlier this year. The opensource r6xx/r7xx 3D stack is not affected and offers better Composite performance already, so hopefully it gets stabilized very soon :P

        Comment


        • #14
          Hopefully they can fix that Xv flickering and it's washed out colors at some point, because phonon-xine under KDE4 defaults to Xv and it can't be changed unfortunately :'( and that renders latest kaffeine and dragon player practically useless.

          Comment


          • #15
            I couldn't find a bugzilla ticket for the "washed out colours". I didn't go through every single ticket with "Xv" but I did go through all the ones with likely sounding descriptions (and more). Can someone file a ticket with an example, preferably with a link to the (legal) video file ?

            I know we went through a *lot* of discussion regarding the open source drivers and what was actually "correct" - the specs are kind of vague about when each conversion matrix should be used so the devs tried a series of different heuristics until everyone seemed happy with the results.

            There doesn't seem to be a clear "right and wrong" here, just a variety of opinions. IIRC part of the problem is that video files are not tagged to identify which conversion matrix was used for encoding, so the driver has to guess based on things like video resolution (eg SD is usually encoded one way, HD is usually encoded another way).
            Last edited by bridgman; 06 September 2009, 11:08 AM.
            Test signature

            Comment


            • #16
              Do you think XV will be ever usable (without EXTREME flickering) or will somebody be forced to use OpenGL forever? At least i found a way to show the vdr menu with fglrx a while ago. In .xine/config i needed to set this:

              video.output.opengl_renderer:2D_Tex

              The default seems to be 2D_Tex_Fragprog which does not show the vdr menu.

              Comment


              • #17
                Is it actually flickering or just lack of sync-to-vblank ?
                Test signature

                Comment


                • #18
                  Originally posted by bridgman View Post
                  I couldn't find a bugzilla ticket for the "washed out colours". I didn't go through every single ticket with "Xv" but I did go through all the ones with likely sounding descriptions (and more). Can someone file a ticket with an example, preferably with a link to the (legal) video file ?

                  I know we went through a *lot* of discussion regarding the open source drivers and what was actually "correct" - the specs are kind of vague about when each conversion matrix should be used so the devs tried a series of different heuristics until everyone seemed happy with the results.

                  There doesn't seem to be a clear "right and wrong" here, just a variety of opinions. IIRC part of the problem is that video files are not tagged to identify which conversion matrix was used for encoding, so the driver has to guess based on things like video resolution (eg SD is usually encoded one way, HD is usually encoded another way).
                  I never filed a bug because for me it's SO OBVIOUS that I assumed everybody knew and nobody cared / knew how to solve it. For example, I find it impossible to find a #000000 colored pixel with fglrx + xv. The lowest color I can find is a greyish #101010. Just play a video with a black start and notice the difference between the bands and the image:



                  With fglrx + gl, fglrx + x11 or EVERY other video driver (radeon, nouveau, nvidia and intel, I also have intel and nvidia chips) it looks like this:



                  The same happens with whites or other strong colors. And it has been like this since I bought my 3850... 21 months ago.

                  Comment


                  • #19
                    Well it is a vsync error - which is extra funny when it looks much better with xv and oss driver...

                    Comment


                    • #20
                      That's not a fglrx specific bug it happens with Windows too. ATI always uses Video-Level for Videos and there ist no way to configure it to PC-Level.

                      Comment

                      Working...
                      X