On 2002.04.19 20:38 Leif Delgass wrote: > On Fri, 19 Apr 2002, José Fonseca wrote: > > ... > > > > 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).
I already had taken a look to that. Mine doesn't wait for the FIFO yet, but does handle multi-register writes. > > > 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 ... I know. This is exactly what I meant by saing the draw_quad was just an hack. The only reason I didn't made what you're saing is because I already got the psued DMA stuff running at the client, now I've put it in the DRM, and I don't want to do more than one change at each time otherwise if there is a error I won't know precisely what of the changes is causing that. But I agree entirely with you observations. > > 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. Yes. This of the ring buffer is copy&paste from the other drivers from what I've seen. > > The question is how to ensure this is secure if the Mesa client is > writing the commands to the buffer. This is a big question, but needs not to be answered right now. Only when we costumize the vertex buffers format to mach64 we will need to know how to address security. Until then we will have a functioning DMA driver which can be used as a testbed for our security concerns. I still don't know how to read from that DMA buffer to move on with this... > > -- > Leif Delgass > http://www.retinalburn.net > José Fonseca _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
