Announcement

Collapse
No announcement yet.

Whoops, ATI's Evergreen Will Bring A New Driver

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

  • #16
    Originally posted by Qaridarium View Post
    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


    • #17
      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


      • #18
        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


        • #19
          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


          • #20
            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


            • #21
              so it goes like this

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

              Comment


              • #22
                Originally posted by V!NCENT View Post
                @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'?
                AtomBIOS only handles the functions where performance is non-critical, eg initialization and display mode setting. Acceleration always goes directly to the hardware.

                Note that rather than writing registers directly, the drivers normally queue up register write commands in the ring buffer so that the relative sequence of register updates and drawing commands stays correct.

                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?
                In DRI1 there was a lock associated with each GPU which protected the hardware and the current client state (the sum of all register writes by a client since it took ownership of the GPU), which IIRC helped with serializing accesses (a contending client would wait on the lock). I don't remember off the top of my head how DRI2 handles serialization but I think it's basically "each client call is completed before the next one starts" and "all the information needed to set state, draw, and wait for the results comes down as a single block". Bottom line is that the mechanism is somewhat different for DRI2, I don't remember the details, and I have to hit the road so won't be looking it up right now

                Originally posted by Wingfeather View Post
                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?
                Yes, if you look in the PM4 chapter of either the 5xx or 6xx/7xx acceleration guide you can see a summary of the language. It's mostly a mix of "write xxx to register yyy" and "draw a bunch of triangles" command packets. The shared "thing" is actually a ring buffer in system memory, which the driver writes commands to and the GPU reads commands from.

                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? 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?
                Yes and no. In principle you can write a generic X driver using kernel calls for modesetting and Gallium3D calls for acceleration. In practice the implementation of things like memory management tends to be driver-specific (the GEM API has a mix of common and driver-specific calls) so current thinking seems to be that the drivers will still be hardware-specific but much simpler than they are today.

                For now, of course, nothing changes since user modesetting will still be supported in the driver for a while.

                Comment


                • #23
                  In the second para I mentioned waiting for results; don't think that's part of every drawing interaction between userspace and kernel driver - more like draw/draw/draw/draw/wait etc....

                  Comment


                  • #24
                    Originally posted by bridgman View Post
                    This is to make things quicker and easier, not harder.
                    Uhm... I'm not a developer but I don't like code duplication, even if it makes things quicker.
                    ## VGA ##
                    AMD: X1950XTX, HD3870, HD5870
                    Intel: GMA45, HD3000 (Core i5 2500K)

                    Comment


                    • #25
                      Originally posted by darkbasic View Post
                      Uhm... I'm not a developer but I don't like code duplication, even if it makes things quicker.
                      what in particular don't you like?

                      It seems to be a smart move to me.

                      Comment


                      • #26
                        Two points :

                        1. If the classic driver code base is going to be retired in favour of Gallium3D drivers who cares ?

                        2. It's not a question of duplication or no duplication, the question is what kind of duplication :

                        - two clean copies of the source
                        - one copy of the source but 4x the size because of ifdefs and doubled lines
                        - one copy of the source but 4x the size because of runtime branching

                        Some of the code had to be duplicated anyways because the programming sequences are simply different. When you have something like :

                        ...common code
                        if (evergreen)
                        evergreen-specific code
                        else
                        6xx/7xx-specific code
                        ... common code
                        you're duplicating that part of the code anyways.

                        I expect we'll settle on a clean way to let the two sets of addresses coexist that can also work for the other driver components, but I would rather see us spend time on that *after* you have working Evergreen code in public repos, not *before*.

                        Comment


                        • #27
                          Originally posted by xir_ View Post
                          so it goes like this

                          user
                          |
                          xserver
                          |
                          mesa
                          |
                          gallium3d - which is just a framework
                          |
                          kernel
                          Two part answer. Ignoring hardware drivers for a minute, direct rendering is :

                          user program
                          mesa
                          kernel

                          indirect rendering is :

                          user program
                          x server
                          mesa
                          kernel

                          There are actually GL and X libs in there as well, plus libdrm between mesa and kernel, but that's the main stuff.

                          Staying with direct rendering and adding hw drivers, "classic" mesa is :

                          user program
                          mesa common code
                          classic mesa hw driver
                          kernel

                          "gallium" is :

                          user program
                          mesa common code
                          gallium3d hw driver
                          kernel

                          Either way it's still Mesa that understands GL.

                          Comment


                          • #28
                            Originally posted by bridgman View Post
                            I expect we'll settle on a clean way to let the two sets of addresses coexist that can also work for the other driver components, but I would rather see us spend time on that *after* you have working Evergreen code in public repos, not *before*.
                            I'd assume refactoring could also enable having more common code but who the heck would really want to do another round of refactoring at this point...

                            Comment


                            • #29
                              Yeah, but the whole idea is that we may end up replacing the classic driver code with a Gallium3D driver anyways, and if that happens refactoring the to-be-replaced code isn't a great use of time

                              Comment


                              • #30
                                Yeah, what I meant to say was Carry On (tm).

                                Comment

                                Working...
                                X