sounds good.
thanks for the answer
AMD Pushes Out New R600/700 3D Code
Collapse
X
-
I think the radeon implementation does a couple of extra things like reducing the number of active PCIE lanes, but "mostly" is probably a big generous. Then again, it probably is "mostly" in terms of amount of power reduction, but you pay a performance penalty when you put the card in a lowest power mode.
What's missing right now is things like on-the-fly adjustment of clocks and voltage, but that won't happen until KMS has settled a bit. The code really needs to be in the kernel and it needs access to both display and acceleration requirements. On fglrx we have additional protocols to collect all the requirements in one place but for the open drivers it seems to make more sense to build on KMS.
Leave a comment:
-
-
i know its not really the right thread to post, but since bridgman and many others seem to post here i can expect an answer
just now i looked at the radeon feature matrix and its says "MOSTLY" for the powerplay support.
the last thing a know about the open source drivers when it comes to powersaving was the "force low power" mode (or something along those lines, cant remember the correct name)
is this a more advanced implementation, or what can we expect from this?
Leave a comment:
-
-
Originally posted by Yfrwlf View PostBoth for now then, that's understandable, but I hope things heat up and progress with Gallium if that's the future and the best so far, so that it happens sooner rather than later. ^^
(Keep in mind that while Gallium progresses, we'll get to immediately benefit of all the improvements (in core and state machines) once the Gallium r600 driver is written so code useful for new cards is already getting written in even though the actual driver is still waiting to be done )
Leave a comment:
-
-
Originally posted by bridgman View PostAlso the enterprise distro users won't be switched over to KMS/GEM/TTM/DRI2 for 12-18 months and we need a solution for them. Gallium3D needs DRI2 and memory management today. It could be modified to offer subset functionality without them but nobody thinks that's a good idea.
The questions are basically "which is less wasted effort, and which gives us a cleaner solution for the future". The answers to both of those questions seem to argue in favor of doing a 6xx-7xx classic mesa implementation for users running without GEM/TTM and not putting any extra baggage into Gallium3D.
Leave a comment:
-
-
Also the enterprise distro users won't be switched over to KMS/GEM/TTM/DRI2 for 12-18 months and we need a solution for them. Gallium3D needs DRI2 and memory management today. It could be modified to offer subset functionality without them but nobody thinks that's a good idea.
The questions are basically "which is less wasted effort, and which gives us a cleaner solution for the future". The answers to both of those questions seem to argue in favor of doing a 6xx-7xx classic mesa implementation for users running without GEM/TTM and not putting any extra baggage into Gallium3D.Last edited by bridgman; 08 June 2009, 11:38 AM.
Leave a comment:
-
-
Because there is a lot of enterprise/LTS distros that won't use that gallium3d thing till it tested to death, but they want 3d support for r6xx/r7xx which will be provided old classic mesa way.
Leave a comment:
-
-
Originally posted by nanonyme View PostActually they might end up both dying and getting replaced by a lean and mean driver that taps into Gallium and KMS+memory manager for about everything.
Shouldn't 2D and 3D accel be something in progress for future (hopefully not too long) Gallium3D support?
Leave a comment:
-
-
Originally posted by monraaf View Post
Leave a comment:
-
-
Leave a comment: