If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

@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

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

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

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.

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