On Tue, 28 May 2002, Jos� Fonseca wrote: > On 2002.05.28 20:55 Leif Delgass wrote: > > 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." > > Do whatever changes you feel necessary - cosmetic or not. I'm still > getting used to the new code so I'll concentrate on one or another > specific detail or do general debuging - in any case I wont do much big > changes so that you can do yours.
OK, it shouldn't take me to long to get the basic structure in. > > Also, I think we may need to modify the linked lists. > > What's the purpose of each lists? All buffers start out in the free list. When a buffer is requested by a client, it's moved to the "empty" placeholder list. When the buffer is filled and submitted by the client it's currently moved to the queue list to await dispatch. When the queue is flushed, all buffers submitted from the queue are moved to the pending list. Freelist_get searches the pending list for completed buffers. Since we'll be moving buffers to the ring when they're submitted, we don't need the queue. The pending list just makes for a shorter list to search for freeable buffers, rather than iterating the entire buffer list. > > 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. > > Ok. > > > 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. > > > > Is there a need for a pending list too? As I mentioned above, this just makes a shorter list to search for freeable buffers, but it's not strictly necessary. > > 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 > > But cleaning the house after the X server leaves is a responsability of > the clients, not the DRM. The DRM should never gives control to X while > there are buffers either being processed or queued - it should always > flush the DMA first. Leaving the X server shouldn't be a problem since the client should upload everything after getting the lock back. The problem is on entering the X server, where setting up the X server is typically done in EnterServer. We only need to wait for DMA to idle in the XAA Sync (the X server can move the cursor while DMA is running), but the XAA functions assume that the X server's register state is consistent. What I found is that I could fix some problems with the 2D accel by restoring the draw registers (although I couldn't get rid of lockups yet) in the XAA Sync. I just thought that it would be more efficient to do this via DMA instead of MMIO. Of course, if a _client_ is using the ioctl to wait for DMA so it can access the framebuffer, the register reset would be overkill. > The one that does the state emition is the DRM but is the client which > marks the stuff for upload. > > > 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. > > > > 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
