Announcement

Collapse
No announcement yet.

Whoops, ATI's Evergreen Will Bring A New Driver

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

  • #11
    Originally posted by bridgman View Post
    Now that most of the rearchitecture work has finished the stack is getting pretty simple :

    - kernel driver (aka drm) initializes the GPU, manages memory, and sets up the display. Having the kernel driver handle display setup is relatively new, and is referred to as Kernel ModeSetting (KMS)

    - X driver (aka xf86-video-ati) hooks into the X server, passes display changes from the X server down to the kernel driver, and turns acceleration commands from the X server into GPU commands which are passed to the chip via the kernel driver

    - Mesa driver turns OpenGL commands into HW driver calls; HW driver turns those calls into GPU commands which are passed to the chip via the kernel driver.

    There are two types of Mesa HW drivers -- "classic" and Gallium3D -- and the transition from one to t'other is maybe half completed. Gallium3D drivers have the advantage of being able to support more than just 3D operations - things like OpenVG, OpenCL, 2D and video acceleration. Mesa is used for OpenGL in both cases, ie it's not "Mesa vs Gallium" it's "Mesa with classic HW drivers vs Mesa with Gallium3D HW drivers".

    Older GPUs (r1xx, r2xx) will probably only ever use the classic drivers. More recent GPUs (r3xx-r5xx) are currently using a classic driver but a new Gallium3D driver is getting close to being able to replace the classic driver. The newest GPUs (6xx and higher) use a classic driver and work is just beginning on a Gallium3D driver.

    Programming documentation for the chips is available at http://www.x.org/docs/AMD

    Design documentation for the graphics drivers is available at http://www.x.org/wiki but be careful because most of it refers to the driver stack before the recent rearchitecture work completed.

    OK so far ?
    Thats a brilliant description (i've been very stuck with this too).

    Its because of replies like this that i will only ever buy ATI from now on.

    Comment


    • #12
      @Bridgman
      If there is an AtomBIOS, why the hell does the 'new copy' driver require changing register adresses?
      And also wouldn't writing directly to the registers speed up 'the card'?

      Comment


      • #13
        You are right, I have an ATI 5850, the fglx drivers are really slow even scrolling web pages in firefox.... and the open source drivers are always "coming".... For me, the solution I've found is to execute Linux in a Virtualbox machine inside Windows 7. No more problem with graphics, suspend / hibernate, I can make a backup of the whole system, and I dont have to reboot to play some games.

        Comment


        • #14
          And also wouldn't writing directly to the registers speed up 'the card'?
          AFAIK, modern GPU drivers shouldn't be spending a lot of time touching registers. If they are, the optimization is generally to touch registers less often, not to touch them faster.

          Comment


          • #15
            Originally posted by Qaridarium
            you know? bridgman its amd's secret weapon...

            i think bridgman isn't a human i think he is a openCL based KI runs on a R900!

            the secret plan is to fire all humans out and let the work be done by R900 chips!

            bridgman is just the first prototype of a really smart KI based on R900!

            I think its very good of AMD to hang out on these forums, it really shows that they care about what customers and community think.

            I'm not expert on linux, but i've compiled my own kernels and been playing with systems for about 4 years. Still the way that these graphics drivers work seems to be so incredibly complicated. (also i'm a theoretical chemist by trade not a programmer)


            I really would like to see someone come up with some good documentation, maybe a flow chart or two, to help people understand the development process.

            Comment


            • #16
              Thanks for the help

              @bridgman
              Thank you very much - that realy helped me to understand how it works. :-)
              I think i will start over with trying some OpenGl coding as soon as possible :-)

              Comment


              • #17
                Originally posted by chrisrock View Post
                @bridgman
                Thank you very much - that realy helped me to understand how it works. :-)
                I think i will start over with trying some OpenGl coding as soon as possible :-)
                +1. Great explanation, thanks!

                Quick further question:
                The "GPU commands" - are these a stream of binary data which passes between the HW driver and the DRM, with the DRM forwarding it to the actual hardware? If so, how does it handle the case when both the X driver and the mesa HW driver wants to talk to the card simultaneously?

                Do the X drivers and the mesa HW drivers speak the same "language" to the DRM, meaning it does some kind of shared-bus arbitration type thing? Or do they both have separate interfaces to the DRM?

                I think this is the major bit of the puzzle still for me.

                Ah, ANOTHER quick question:
                Given that we hear about X-type state trackers for gallium3d, does this mean that in the end the dedicated X driver as we know it will be phased out? It *sounds* like when gallium3d and all its various state trackers is/are complete, it will be able to handle every kind of graphics API out there, convert it into these low-level GPU commands, and thus get it rendered (presumably in a thoroughly accelerated manner). Is that the case?

                Thanks a lot!

                Comment


                • #18
                  Originally posted by Wingfeather View Post
                  Quick further question:
                  The "GPU commands" - are these a stream of binary data which passes between the HW driver and the DRM, with the DRM forwarding it to the actual hardware? If so, how does it handle the case when both the X driver and the mesa HW driver wants to talk to the card simultaneously?
                  Afaik this happens by that DRM mostly consisting of KMS and X driver and Mesa driver are both KMS clients. As to exactly how KMS architecture works, there might be more information about that somewhere but in a nutshell KMS allows multiple clients to use the card at the same time and handles memory and other stuff in such a way that clients won't end up eg getting each other's data.

                  Comment


                  • #19
                    Originally posted by Wingfeather View Post
                    Ah, ANOTHER quick question:
                    Given that we hear about X-type state trackers for gallium3d, does this mean that in the end the dedicated X driver as we know it will be phased out?
                    In a way it already was phased out with the coming of KMS since that took hardware functionality out of the X drivers.

                    Comment


                    • #20
                      so it goes like this

                      user
                      |
                      xserver
                      |
                      mesa
                      |
                      gallium3d - which is just a framework
                      |
                      kernel

                      Comment

                      Working...
                      X