i wonder how much difference does hyperz make, in raw numbers.
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
i wonder how much difference does hyperz make, in raw numbers.
Yay! Sounds goodThe 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.![]()
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.
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?
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.
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
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![]()