Announcement

Collapse
No announcement yet.

R600/r700 kms + 3d dri1/dri2

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

  • #46
    Originally posted by rampage7 View Post
    I've just installed 2.6.31-rc9 kernel from drm-next branch (DRI2, KMS), master Mesa, master ATI DDX and master libdrm (all, except kernel from x11 Gentoo Portage overlay).
    Might be a better idea to pull drm-next over 2.6.31, then you get all the fixes for other components in the kernel for the final version.

    Comment


    • #47
      Will dual monitor setups work with KMS by the time .32 is finished?
      Currently, when using KMS I'm restricted to one screen.

      Also, I'm still slightly getting text corruption in Kwin. It really only happens if I backspace what I type. And for some reason b's aren't working.

      Edit: Just to clarify on the dual monitor bit. Xrandr sees both screens, and within the KDE4 Settings I can switch between screens. By default it uses my smaller screen, but I can switch it to use my larger screen, but I can't use both at the same time.

      It sees that both are there, but if I set the small screen to 1280x1024 while the other is at 1680x1050, I notice the light on the monitor goes from orange to green, but it still only displays black. And either way I can't move my mouse to the other screen.
      Last edited by pvtcupcakes; 09-21-2009, 09:17 PM.

      Comment


      • #48
        multi-head should work fine with kms. If it doesn't, file a bug
        (https://bugs.freedesktop.org) and attach your xorg log and dmesg.

        Comment


        • #49
          Originally posted by rampage7 View Post
          Some performance info (Radeon 4850, Core2Quad @ 3200MHz, Gentoo AMD64)
          Since glxgears isn't using multithreading, you're limited to the speed of a single core though. In a hypothetical world where it would, you'd probably get those amounts multiplied by two or more. (not that it makes any sense to do so)

          Comment


          • #50
            Originally posted by agd5f View Post
            multi-head should work fine with kms. If it doesn't, file a bug
            (https://bugs.freedesktop.org) and attach your xorg log and dmesg.
            Done.

            https://bugs.freedesktop.org/show_bug.cgi?id=24095

            Comment


            • #51
              Hi All!
              Yesterday I tried to run all recent KMS+DRI2+3D stuff on my HD4870. I took linux-2.6.31-git14, mesa master git, ati ddx master git, and libdrm 2.4.14. In general it was successful, except small "buts"...

              The biggest issue I've observed is Xv... It is not tear-free with KMS. There are visible artifacts (some color lines) appear on the video in both, windowed and full-screen modes. Switching Mplayer from full-screen to windowed mode and back removes them, but in a second or two these lines appear again...

              3D for me is quite OK (checked with ioqake3), except some artifacts in the bottom and rightmost 1-pixel lines. Probably this is already fixed in mesa.

              Are those bugs of my setup or features for now?

              Comment


              • #52
                Originally posted by Aostrich View Post
                Hi All!
                Yesterday I tried to run all recent KMS+DRI2+3D stuff on my HD4870. I took linux-2.6.31-git14, mesa master git, ati ddx master git, and libdrm 2.4.14. In general it was successful, except small "buts"...

                The biggest issue I've observed is Xv... It is not tear-free with KMS. There are visible artifacts (some color lines) appear on the video in both, windowed and full-screen modes. Switching Mplayer from full-screen to windowed mode and back removes them, but in a second or two these lines appear again...

                3D for me is quite OK (checked with ioqake3), except some artifacts in the bottom and rightmost 1-pixel lines. Probably this is already fixed in mesa.

                Are those bugs of my setup or features for now?
                http://bugs.freedesktop.org/show_bug.cgi?id=22007

                Maybe this is the right bug for you

                Comment


                • #53
                  Perry3D,

                  Yes, this is exactly the artifacts I see.
                  Do you also observe the vsync tearing?

                  Comment


                  • #54
                    Originally posted by Aostrich View Post
                    3D for me is quite OK (checked with ioqake3), except some artifacts in the bottom and rightmost 1-pixel lines. Probably this is already fixed in mesa.
                    http://cgit.freedesktop.org/mesa/mes...85b8d1231aae63 Sounds similar to the bug this fixed. Try updating and comment again if it persists.

                    Comment


                    • #55
                      Yes, today I saw a lot of commits to Mesa which could fix such off-by-one bugs.
                      Will update and recheck tonight.

                      Anyway this bug is not as annoying as tearing in Xv...

                      Comment


                      • #56
                        I know... I just don't have any idea what the problem might be related to there. I don't think I'm getting artefacts with Xv myself, just a horizontal visible line (might count as tearing) in the video every now and then.

                        Comment


                        • #57
                          I believe the non-KMS Xv driver accesses hardware directly to avoid tearing; that approach would probably not have been used in the KMS paths since one of the goals is to let X run without direct hardware access. I think there will be a discussion at XDC next week to try and standardize an approach for handling sync-to-vblank in the kernel driver.

                          Disclaimer - I haven't actually confirmed this by looking at code yet.

                          Comment


                          • #58
                            Originally posted by bridgman View Post
                            I believe the non-KMS Xv driver accesses hardware directly to avoid tearing; that approach would probably not have been used in the KMS paths since one of the goals is to let X run without direct hardware access. I think there will be a discussion at XDC next week to try and standardize an approach for handling sync-to-vblank in the kernel driver.
                            Well, with luck it'd be using the same vsync method as OpenGL in KMS and would Just Work with Alex's upcoming interrupt code. :3 (I'd suspect we won't be that lucky but it's among the main reasons why I don't think I'm going to even search the applicable code section before the interrupts code is done - right next to the fact that vsync probably would be way out of my league )

                            Comment


                            • #59
                              Hi,

                              how about some power management with kms?, my pc wyth radeon hd4870 hangs afther one hour or two, and cooler from card is very very hot!!

                              Comment


                              • #60
                                The anti-tearing Xv stuff for r6xx/r7xx doesn't work with KMS right now. It needs support in the drm command checker similar to what we did for r1xx-r5xx.

                                Comment

                                Working...
                                X