The Linux 2.6.36 Kernel Will Have Some Fun DRM

[xir_]

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?

[Tsiolkovsky]

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.

[yotambien]

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.

[rohcQaH]

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.

[agd5f]

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

[bridgman]

I know what you mean. Still, coming from somebody with the "AMD Linux" tag it sounds hilarious.

Yep. The knowledge already exists, of course, it's just spread around tens of millions of lines of code and (temporarily, at least) the heads of hundreds of developers, and it would take dozens of people to find and extract that information. Alex and Richard do work with the hardware and proprietary driver teams but since most of the design work for a new chip happens 1-2 years before launch it's hard to find anyone who remembers the details -- and the proprietary driver code is *way* too big to be much help when looking for the "one bit you missed".

Now that we are more or less caught up with new hardware introduction we're going to see if we can combine the open source driver design effort with the proprietary driver design activities, so we can find "the right heads" more efficiently. Don't know how well that will work but hopefully over the next year we can make that happen.

[Nille]

Alex and Richard do work with the hardware and proprietary driver teams but since most of the design work for a new chip happens 1-2 years before launch it's hard to find anyone who remembers the details

Sounds like this is now the time for Alex or Richard to ask Question about SI, NI and Fusion

[yotambien]

Yep. The knowledge already exists, of course, it's just spread around tens of millions of lines of code and (temporarily, at least) the heads of hundreds of developers, and it would take dozens of people to find and extract that information. Alex and Richard do work with the hardware and proprietary driver teams but since most of the design work for a new chip happens 1-2 years before launch it's hard to find anyone who remembers the details -- and the proprietary driver code is *way* too big to be much help when looking for the "one bit you missed".

Now that we are more or less caught up with new hardware introduction we're going to see if we can combine the open source driver design effort with the proprietary driver design activities, so we can find "the right heads" more efficiently. Don't know how well that will work but hopefully over the next year we can make that happen.

In that case, I didn't know what you meant. I thought the situation was something like, "we now know how to correctly program these chips within the OSS design". Instead, it seems that you were actually missing hardware details.

Now, this comment obviously comes from somebody whose coding skills go no further than solving equations in python, but, if some OSS developers have access to the millions of lines of code you talk about, i.e. they work not only from the released documentation but also from closed code, how do they manage to restrict themselves and not implement the solutions adopted in the closed driver? Are the drivers so different in complexity, size and design that there are no low hanging fruits to be taken from that information? Not that I doubt of their professional integrity, of course : )

[LinuxID10T]

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.

Hopefully, this will put the performance in the range of the 4xxx series. On the open source drivers, the 5xxx is significantly slower on Fedora than the 4xxx. None the less, I love my Radeon HD 5750.

[RealNC]

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

Nothing major. At some point in the past, I disabled Hyper-Z in Windows using a tweak tool. It was with a Radeon 9800Pro. There was no difference in performance, at least when using 3DMark.