Announcement

Collapse
No announcement yet.

AMD Pushes Out New R600/700 3D Code

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

  • #61
    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. ^^

    Comment


    • #62
      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 )

      Comment


      • #63
        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?

        Comment


        • #64
          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.
          Test signature

          Comment


          • #65
            sounds good.
            thanks for the answer

            Comment

            Working...
            X