Announcement

Collapse
No announcement yet.

Whoops, ATI's Evergreen Will Bring A New Driver

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

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

    Comment


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

      Comment


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


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


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

            Comment


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

              Comment


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


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

                  Comment


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

                    Comment


                    • #30
                      Originally posted by xir_ View Post
                      what in particular don't you like?
                      Code duplication means bugs duplication, and you will have to fix them twice. I never saw it as a smart programming tecnique...

                      Originally posted by bridgman View Post
                      Some of the code had to be duplicated anyways because the programming sequences are simply different
                      Yes, but probably only a little part of it.
                      ## VGA ##
                      AMD: X1950XTX, HD3870, HD5870
                      Intel: GMA45, HD3000 (Core i5 2500K)

                      Comment

                      Working...
                      X