Announcement

Collapse
No announcement yet.

The Linux 2.6.36 Kernel Will Have Some Fun DRM

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

  • The Linux 2.6.36 Kernel Will Have Some Fun DRM

    Phoronix: The Linux 2.6.36 Kernel Will Have Some Fun DRM

    Now that the Linux 2.6.35 kernel was released a few days ago, Linus Torvalds has begun pulling in new code for the Linux 2.6.36 kernel as the various developers begin submitting pull requests of their new work. Dave Airlie, the maintainer of the Direct Rendering Manager (DRM) code in the Linux kernel, overnight sent in his first Git pull request of his DRM tree. This pull request brings many new features for Intel, ATI, and NVIDIA/Nouveau graphics hardware...

    http://www.phoronix.com/vr.php?view=ODQ3NQ

  • #2
    i wonder how much difference does hyperz make, in raw numbers.

    Comment


    • #3
      The ATI Radeon DRM driver changes are most prominent and include R600/700 tiling support, R300/500 Hyper-Z support, support for reading thermal sensors on most R600 ASICs, R600 kernel bit state emission minimization, ioport accessors for BIOS scripts, under-scan support for HDMI TVs, and RS690 HDMI audio support.
      Yay! Sounds good

      Comment


      • #4
        Not pulled into mainline yet and due to build failures in the linux-next tree I can't check this stuff out from there.
        I'm gonna try myself and merge Dave's tree with my local mainline tree. Can't wait for Linus and it's an opportunity to learn something new.

        Comment


        • #5
          R800/Evergreen

          Great to see so many nice new features on the graphics front coming. BTW, is there any info available when we might start to see some support for AMD/ATI Radeon R800/Evergreen based hardware?

          Comment


          • #6
            Originally posted by yoshi314 View Post
            i wonder how much difference does hyperz make, in raw numbers.
            It's hard to put a single number on it because the performance diff depends so much on what else is going on. The purpose of HyperZ is to reduce the video memory bandwidth required for Z buffer operations and to allow earlier depth-based culling of triangles and (IIRC) quads. Not sure how much of this is turned on yet.

            Some apps do a great job of identifying the visible triangles before sending anything to the GPU so the impact of HyperZ is much less. I think most of the quake engines do this, for example.

            Finally, HyperZ uses a fixed-size on-chip buffer to store a low-resolution "summary" of the Z buffer contents, so usually only a single app can take advantage of the feature. It was designed primarily for fullscreen apps but using it effectively in an environment with a compositor running is more of a challenge (since the natural thing is for the compositor to hog the HyperZ cache and not let the app have it), and IIRC that's been a great source of "fun" for the developers. This restriction may have been relaxed on newer chips but not sure.

            When HyperZ was first introduced (on the original Radeon) I think we were seeing 5-15% improvement on average.

            Comment


            • #7
              Originally posted by Tsiolkovsky View Post
              Great to see so many nice new features on the graphics front coming. BTW, is there any info available when we might start to see some support for AMD/ATI Radeon R800/Evergreen based hardware?
              In this pull request I can see one commit from Alex Deucher:
              drm/radeon/kms: Add crtc tiling setup support for evergreen

              You can check out the link below where you can see the current state of development for all AMD/ATI chipsets supported by kernel/Xorg. The table includes features based on kernel, DRI and MESA:
              X.Org Wiki - RadeonFeature

              Comment


              • #8
                I might be wrong here, but I think that the kernel portion of Evergreen is basically already in place. What we're waiting for is the userspace (Mesa + DDX) portion.

                Comment


                • #9
                  Originally posted by pingufunkybeat View Post
                  I might be wrong here, but I think that the kernel portion of Evergreen is basically already in place. What we're waiting for is the userspace (Mesa + DDX) portion.
                  Yep. The EXA/Xv and 3D accel is now working to the point where we feel we have a pretty good idea how to program the chip (I haven't seen a single email starting with "I hate this chip" for almost 2 weeks), and IP review is in progress.

                  If you can tell me what new urgent tasks will arrive over the next few weeks and their approximate size I can tell you when we will be likely to release

                  Comment


                  • #10
                    Originally posted by pingufunkybeat View Post
                    I might be wrong here, but I think that the kernel portion of Evergreen is basically already in place.
                    Almost. There is still support for HDMI Audio output to do and that is related to kernel. But yeah, most of the fancy kernel-based stuff like KMS, power management, suspend support - they appear to be completed.

                    Comment


                    • #11
                      Originally posted by trapDoor View Post
                      In this pull request I can see one commit from Alex Deucher:
                      drm/radeon/kms: Add crtc tiling setup support for evergreen

                      You can check out the link below where you can see the current state of development for all AMD/ATI chipsets supported by kernel/Xorg. The table includes features based on kernel, DRI and MESA:
                      X.Org Wiki - RadeonFeature
                      Wow that list has come a long way in a very short time. Well done AMD and everyone else.

                      Why is it that Antialiasing is unknown?

                      Comment


                      • #12
                        Re: R800/Evergreen

                        Oh,great to hear kernel is mostly ready and userspace is progressing nicely and all. Thank you very much guys for the info and for all the work. Can't wait untill I can use and help test the open-source drivers on the laptop.

                        Comment


                        • #13
                          Originally posted by bridgman View Post
                          The EXA/Xv and 3D accel is now working to the point where we feel we have a pretty good idea how to program the chip
                          I know what you mean. Still, coming from somebody with the "AMD Linux" tag it sounds hilarious.

                          Comment


                          • #14
                            Originally posted by xir_ View Post
                            Why is it that Antialiasing is unknown?
                            IIRC there was a thread about Antialiasing, and noone had the right answers, so someone decided to add that line as a reminder.

                            Unfortunately the matrix doesn't say whether it's about primitive antialiasing, FSAA or MSAA.
                            FSAA is a software-feature (use a bigger, rotated framebuffer, scale back after drawing) so if would be a mesa feature, not driver-specific. MSAA requires hardware support. Primitive AA.. no idea, probably done with shaders (-> mesa feature), but I don't think anyone uses that any more.

                            Comment


                            • #15
                              AA support is just not implemented yet. The hw details are in the reg specs and accel guides.

                              Comment

                              Working...
                              X