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. > Also, I think we may need to modify the linked lists. What's the purpose of each 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. 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? > 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. 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 _______________________________________________________________ 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
