Originally posted by bridgman
View Post
Announcement
Collapse
No announcement yet.
Intel Just Released A Crazy Fast Acceleration Architecture
Collapse
X
-
Bridgman: This is offtopic and certainly a bit on the naive side to ask you this.
I'll give it a try nevertheless.
First off, I'm really happy about the decision to release documentation of major parts of Ati/AMD GPU chipsets. Also I really liked how things evolved. Then again, while one might not care a lot about the motivation behind all this now that "it" happened, I asked myself several times how this "going open source" might be solely related to the new lines of CPUs with integrated GPU parts (out-of-the-box experience) and would not happened otherwise.
Comment
-
They are not, at least not generally. On my RV710, tiling is NOT enabled by default and hyper-Z is not even implemented. http://www.x.org/wiki/RadeonFeature
Comment
-
Originally posted by bbordwell View PostThese are all already enabled features if i can remember my Phoronix stories correctly.Last edited by bridgman; 05 June 2011, 07:26 PM.Test signature
Comment
-
Originally posted by entropy View PostBridgman: This is offtopic and certainly a bit on the naive side to ask you this.
I'll give it a try nevertheless.
First off, I'm really happy about the decision to release documentation of major parts of Ati/AMD GPU chipsets. Also I really liked how things evolved. Then again, while one might not care a lot about the motivation behind all this now that "it" happened, I asked myself several times how this "going open source" might be solely related to the new lines of CPUs with integrated GPU parts (out-of-the-box experience) and would not happened otherwise.
Definitely not "solely related" but support for Fusion parts was a consideration even back in 2007. Maybe 30-40% of the motivation, something like that...Test signature
Comment
-
Originally posted by Prescience500 View PostDoes anyone know if any of these enhancements can be ported to the open source AMD drivers or Gallium3D in general if Intel ever decides to join the rest of us?
This particular patch isn't directly related to the 3D drivers, but the same synchronization issues are still relevant in the 3D driver. None of the radeon 3D drivers (neither gallium no classic) for hardware that has a 2D engine (r1xx-r5xx) use the 2D engine in the 3D driver, so there are no synchronization issues in that respect.
This brings up a good point in general. Often hardware has features that it doesn't always make sense to use as we see in the case of this patch. On the surface have multiple asynchronous hardware engines may seem like a useful feature, but the overhead of synchronization that comes with sharing buffers between the engines is often not worth the extra functionality. That's not to say multiple engines don't have their uses, but just because you can use them doesn't always mean you should.
Comment
-
On a slightly unrelated topic... when is it planned to just retire the hardware-specific DDX's and use a generic interface exposed via Mesa, e.g. Gallium?
DDX's are the one part of the LInux graphics stack I've never at least slightly looked into. I'm assuming they're doing some direct hardware programming through the DRI2 interfaces rather than passing through the Mesa/Gallium code. Like the DDX is issuing commands for "draw opaque rectangle here" to the DRI2 interfaces rather than going through some Gallium interface to draw primitives (wrapping OpenGL is probably too much overhead to justify perhaps, but surely a 2D acceleration state tracker in Gallium would not be). I'm aware that this is basically what doing a nested X.org server over Wayland or so on would do, but why isn't X.org doing it that way internally already? Legacy support or something?
(This is a more AMD specific topic, as I know Intel doesn't use Gallium yet.)
Comment
Comment