Page 3 of 9 FirstFirst 12345 ... LastLast
Results 21 to 30 of 90

Thread: Whoops, ATI's Evergreen Will Bring A New Driver

  1. #21
    Join Date
    Mar 2010
    Posts
    60

    Default

    so it goes like this

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

  2. #22
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    Quote 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.

    Quote 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

    Quote 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.

    Quote 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.

  3. #23
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    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....

  4. #24
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    957

    Default

    Quote 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.

  5. #25
    Join Date
    Mar 2010
    Posts
    60

    Default

    Quote 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.

  6. #26
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    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*.

  7. #27
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    Quote 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.

  8. #28
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,633

    Default

    Quote 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...

  9. #29
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,464

    Default

    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

  10. #30
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,633

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •