[Dri-devel] Re: Back to work

[Leif D. <lde...@re...>]

On Tue, 28 May 2002, Jos=E9 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 t=
o
> > 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, st=
art
> > 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 writ=
ing
> > to the "ring."
>=20
> Do whatever changes you feel necessary - cosmetic or not. I'm still=20
> getting used to the new code so I'll concentrate on one or another=20
> specific detail or do general debuging - in any case I wont do much big=
=20
> changes so that you can do yours.

OK, it shouldn't take me to long to get the basic structure in.
=20
> > Also, I think we may need to modify the linked lists.
>=20
> What's the purpose of each lists?

All buffers start out in the free list.  When a buffer is requested by a=20
client, it's moved to the "empty" placeholder list.  When the buffer is=20
filled and submitted by the client it's currently moved to the queue list=
=20
to await dispatch.  When the queue is flushed, all buffers submitted from=
=20
the queue are moved to the pending list.  Freelist_get searches the=20
pending list for completed buffers.  Since we'll be moving buffers to the=
=20
ring when they're submitted, we don't need the queue.  The pending list=20
just makes for a shorter list to search for freeable buffers, rather than=
=20
iterating the entire buffer list.

> > First, we don't really need the queue list if we're emitting descript=
ors
> > immediately to the ring.  We can move buffers from the placeholder li=
st
> > (the "empty" list, which I think should be renamed) to the pending li=
st
> > 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 t=
o do
> > this with a function parameter so we can avoid using the buffer priva=
te
> > struct which doesn't exist for the PCI path.
>=20
> Ok.
>=20
> > 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 u=
sed
> > -- currenly this is stored in the descr_addr field of the list entry.
> >=20
>=20
> Is there a need for a pending list too?

As I mentioned above, this just makes a shorter list to search for=20
freeable buffers, but it's not strictly necessary.
=20
> > 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 depe=
nds
> > on the security model, but also the DDX.  I think that part of the
>=20
> But cleaning the house after the X server leaves is a responsability of=
=20
> the clients, not the DRM. The DRM should never gives control to X while=
=20
> there are buffers either being processed or queued - it should always=20
> flush the DMA first.

Leaving the X server shouldn't be a problem since the client should uploa=
d
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. =20
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 coul=
d
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.
=20
> The one that does the state emition is the DRM but is the client which=20
> marks the stuff for upload.
>=20
> > 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 th=
ink
> > this is being done by the DRI library code.  For example, the destina=
tion
> > trajectory needs to be set to the front buffer.  The most efficient w=
ay
> > to
> > do this would be adding it to the end of a DMA pass rather than resto=
ring
> > 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 p=
ass
> > just for the register reset buffer.
> >=20
>=20
> Jos=E9 Fonseca
>=20

--=20
Leif Delgass=20
http://www.retinalburn.net