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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #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.
            Test signature

            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
                  Test signature

                  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

                    Working...
                    X