Announcement

Collapse
No announcement yet.

Whoops, ATI's Evergreen Will Bring A New Driver

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

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