Well, I have some ideas on cleaning up the code a bit. I was going to create a ring structure similar to the r128 driver and rename some of the variables (table_start and table_end are really the head and tail, start and end should refer to the the starting and ending address of the table). I was going to make some new macros for creating descriptors and writing to the "ring." Also, I think we may need to modify the linked lists. First, we don't really need the queue list if we're emitting descriptors immediately to the ring. We can move buffers from the placeholder list (the "empty" list, which I think should be renamed) to the pending list as they are submitted. The queue space test would be replaced by a ring space test similar to the r128 macro. For re-using buffers in the vertex_dispatch, we'll need a discard flag, but I think it's better to do this with a function parameter so we can avoid using the buffer private struct which doesn't exist for the PCI path. When the discard flag is set, we need to save the bus address of the last descriptor used for the buffer, so we can check it against BM_GUI_TABLE in freelist_get. The pending list has one entry per buffer, which can span multiple descriptors, so we need to know the last descriptor in which it was used -- currenly this is stored in the descr_addr field of the list entry.
The other problem is how to handle register "reset" writes when we're constantly moving the tail of the table. What needs to be reset depends on the security model, but also the DDX. I think that part of the problem with 2D accel is that we need to restore some registers on switching context to the X server (like with the utah driver), since I don't think this is being done by the DRI library code. For example, the destination trajectory needs to be set to the front buffer. The most efficient way to do this would be adding it to the end of a DMA pass rather than restoring the registers in the XAA Sync function, but we don't know when a pass is ending until an idle ioctl is called. Perhaps we could add the reset commands as part of the flush function which would be called before a wait for idle. But if we can't add it in time, we'd need to start a new pass just for the register reset buffer. On Tue, 28 May 2002, José Fonseca wrote: > Ok. I've finally finshed the paper! (Well, it's still being reviewed, but > it's out of my hands now.) > > I'm already updating the CVS tree and rebuilding it, and keep up with > Leif's changes. > > Leif, if you didn't started already and you don't mind, I would start > implementing the descriptor table queueing. Is there any caveat one should > know of, i.e., anything that has to be taken care of first? > > Regards, > > José Fonseca > -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
