Page 7 of 7 FirstFirst ... 567
Results 61 to 66 of 66

Thread: AMD Pushes Out New R600/700 3D Code

  1. #61
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    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; 06-08-2009 at 11:38 AM.

  2. #62
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote 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. ^^

  3. #63
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,578

    Default

    Quote 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 )

  4. #64
    Join Date
    Sep 2008
    Posts
    332

    Default

    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?

  5. #65
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,434

    Default

    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.

  6. #66
    Join Date
    Sep 2008
    Posts
    332

    Default

    sounds good.
    thanks for the answer

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •