AMD Pushes Out New R600/700 3D Code

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Pfanne
    replied
    sounds good.
    thanks for the answer

    Leave a comment:


  • bridgman
    replied
    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:


  • Pfanne
    replied
    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:


  • nanonyme
    replied
    Originally posted by Yfrwlf View Post
    Both 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. ^^
    Considering the fact that the Gallium implementation developers have in mind requires KMS and kernel memory manager to run, rushing a Gallium r6xx/r7xx driver at this point mean developers had less time to work on the harder (I've repeatedly heard developers saying the actual Gallium r6xx/r7xx driver is simple to write) things that need to be done first. radeon-rewrite has the benefit that it runs fine without the memory manager code so status quo devs concentrating on it and the kernel pieces benefit all users, not just the ones using older enterprise releases.
    (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:


  • Yfrwlf
    replied
    Originally posted by bridgman View Post
    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.
    Both 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. ^^

    Leave a comment:


  • bridgman
    replied
    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:


  • ssmaxss
    replied
    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:


  • Yfrwlf
    replied
    Originally posted by nanonyme View Post
    Actually 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.
    So I'm not the only one confused about why work on these is being pushed instead of work on Gallium3D drivers. If you have no 3D support, and have to start from scratch, why would you start working on something which will soon need to be replaced?

    Shouldn't 2D and 3D accel be something in progress for future (hopefully not too long) Gallium3D support?

    Leave a comment:


  • nanonyme
    replied
    Originally posted by monraaf View Post
    Latest git is looking better already, I presume it's the effect of the clear code and not the rectangle that I'm seeing here. Still only works with radeonhd and Accelmethod None though.

    Try running it twice in a row? For me the rectangle only appears on the second run. (Since your run is quite different from what I got, would be interesting to see what the second run looks like for you)

    Leave a comment:


  • monraaf
    replied
    Latest git is looking better already, I presume it's the effect of the clear code and not the rectangle that I'm seeing here. Still only works with radeonhd and Accelmethod None though.

    Leave a comment:

Working...
X