Re: radeon-pre-2

[Eric Anholt <eta@lclark.edu>]

On Sat, 2004-09-11 at 10:13, Jon Smirl wrote:
> Coprocessor 3D mode is deeply pipelined
> 2D mode is immediate
> 
> How can you build a system that process swaps between these two modes?
> The 3D pipeline has to be emptied before you can enter 2D immediate
> mode.
> 
> My solution is to leave the coprocessor always running and convert
> everything to use the DMA based commands.

Now, I'll admit that I've only really worked on three sets of hardware
(SiS 300-series, Radeon, Rage 128), but they don't have any "3d mode"
and "2d mode" concept.  On SiS both 3d and 2d go through a FIFO, so for
switching between clients you just have to check how much free space
there is in the fifo.  For Radeon and Rage 128 you can send rendering
commands either through the CP/CCE (DMA) or an MMIO FIFO.  You can do 2d
and 3d commands both ways.  In fact, you can send DMA commands through
an MMIO aperture as well.  But there is nothing "immediate" about 2d. 
It goes through the FIFO or the CP just like 3d rendering.  If I'm not
mistaken about other hardware I've poked at (3dfx, mach64), they don't
have any "2d mode" and "3d mode" either.

To summarize, there is no "2d mode" and "3d mode."  Please stop
referring to it.  If you were actually trying to talk about
synchronization for MMIO vs DMA command submission (which is and would
be a very rare case anyway), well, I don't see why that can't be done
using Linus' example, which seemed like what Alan Cox has been driving
toward for a long time.

If you want to avoid idling to switch from DMA to MMIO in that rare
case, then have whatever client in question write all commands into a
DMA buffer, then dispatch it through either the DRM or decoding into
MMIO writes.  Xati is an example of doing just that, and it's not that
hard.   Or, you could go the route that the XFree86 X Server has and
just have two sets of your acceleration functions, generated through
macros, which write to MMIO or write DMA buffers depending on which has
been set up.

But I see nothing in this issue that requires all the drivers live in
one module together, which would only make life a little more convenient
for some developers, at the expense of all the users who don't want all
of those drivers necessarily.

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org