On Fri, 19 Apr 2002, José Fonseca wrote:
> On 2002.04.19 04:37 Leif Delgass wrote:
> > On Thu, 18 Apr 2002, José Fonseca wrote:
> >
> > [snip]
> >
> > > I didn't take over the DMA part, but that will eventually happen. For
> > now
> > > I'm moving all register programming from GL driver to the DRM, but
> > faking
> > > DMA at the same time. This will allow to prepare and debug everything
> > very
> > > well making the DMA programming much more straightforward. The downside
> > is that the DMA-emulation is very slow.
> > > This is taken a greate deal of changes.
> >
> > I can imagine. It's great that you're starting this effort.
> >
> > > At this moment I'm trying to debug to make things work barely before
> > I'll
> > > make a new branch: mach64-0-0-4-branch. But tommorrow I'll create it
> > > anyway, so that others can help on this work as well - I'm thinking on
> > > Leif, but Frank is welcome to join to and commit whatever he has done
> > so
> > > far. I just don't see point to wait any further for doing this work, as
> > > it's the next logic step to take.
> >
> > I eagerly await the commit message... :)
>
> It's commited. As I'm stuck in this point, there is no reason to delay any
> further.
>
> I've commited in steps to document the changes in the several parts.
>
> As I still don't know how to read from DMA buffer, so the code at
> .../kernel/mach64_state.c:333 is disabled to avoid segfault.
>
> After the DMA emulation is working, the next step is to move the state
> emits to the DRM as well.
I think we should implement pseudo-DMA similar to utah-glx by using the
DMA* macros (currently used for swaps/clears) and reimplement the macros
using a FlushPseudoDMA function. This function needs to wait for the fifo
every 16 writes and check for multi-register writes (see below).
> Another thing that is required is to make the other primitive drawing
> functions other than draw_quad to use the DMA buffers as well, this should
> be done more efficiently (e.g., as is done in Utah-GLX) than is done in
> draw_quad because it was just an hack, but there is no much point in
> achieving the ultimate performance here, because that will only be
> achieved by costumizing the vertex buffer template to produce the vertices
> in a format more close to what mach64 expects.
We don't need to interleave a register address for each dword of vertex
data, you can have just one address preceding each series of sequential
register writes. The format utah-glx uses is 8 dwords per-vertex (12
dwords per multitexture vertex) and 2 dwords to kick off each primitive:
1 dword VERTEX_1_S
7 dwords vertex data
if multitexture
1 dword VERTEX_1_SECONDARY_S
3 dwords vertex data
(Repeat for all verts in primitive)
1 dword ONE_OVER_AREA_UC
1 dword one over area data
If we want to use the NOTEX and TINY vertex formats, we can use 5
and 3 dwords of vertex data respectively instead of 7 per vertex.
For pseudo-DMA we flush the buffer as I described above. If we're doing
DMA, we'll need to set up the descriptor tables (in a ring buffer area) to
dispatch the command buffers.
The question is how to ensure this is secure if the Mesa client is writing
the commands to the buffer.
--
Leif Delgass
http://www.retinalburn.net
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
