Re: [Dri-devel] Client context uploads: How to implement them? / Analysis of the Gamma driver

[Keith W. <ke...@tu...>]

"Jos=E9 Fonseca" wrote:
>=20
> Darryl,
>=20
> On 2002.05.12 19:11 Daryll Strauss wrote:
> > On Sun, May 12, 2002 at 05:27:26PM +0100, Jos=E9 Fonseca wrote:
> > > I would also appreciate any ideas regarding this. This is surely an
> > issue
> > > I would like to discuss further on the next meeting.
> >
> > You're right, there's no automatic way to know what state has become
> > dirty. You need to keep some flags that tell you what state has
> > changed when you change clients. Since it is work to keep these flags=
 up
> > to date, you have to decide what granularity to keep.
> >
> > Any time you don't immediately get the hardware lock you have to chec=
k
> > your flags to see what changed. In the tdfx driver I kept 3 flags. On=
e
> > was that the fifo has changed. That basically meant some other client=
 (X
> > server, or 3D app) had written data to the card. I had to resyncroniz=
e
> > the fifo in that case. The second said that the 3D state was dirty. T=
hat
> > would only occur when a second 3D app ran (the X server never touched
> > the same state) and required that I reset all the 3D parameters. Fina=
lly
> > there was a texture dirty flag which meant that I had to reload the
> > textures on the card.
> >
> > The rationale for that breakdown was that X server context switches
> > would be common. It has to do input handling for example. So I wanted=
 a
> > cheap way to say that the X server had done stuff, but only the fifo
> > changed. Next I argued that texture swaps were really expensive. So, =
if
> > two 3D apps were running, but not using textures, it would be nice to
> > avoid paging what could be multiple megabytes of textures. Finally th=
at
> > meant 3D state was everything else. It wasn't that much data to force=
 to
> > a known state, so it wasn't worth breaking that into smaller chunks.
> >
> > The three flags were stored in the SAREA, and the first time a client
> > changed each of the areas it would store it's number into the
> > appropriate flag of the SAREA.
> >
>=20
> I've been snooping in the tdfx driver source. You're referring to the
> TDFXSAREAPriv.*Owner flags in tdfx_context.h and the tdfxGetLock functi=
on
> in tdfx_lock.c, in the tdfx's Mesa driver.
>=20
> So let's see if I got this straight (these notes are not specific to 3d=
fx):
>=20
>   - The SAREA writes are made with the lock (as Leif pointed), and
> reflects the state left by the last client that grabed it.
>   - All those "dirty"/"UPDATE" flags are only meaningfull within a clie=
nt.
> Whenever another client got into the way, the word is upload whatever
> changed  - "what" in particular depends of the granularity gauge you
> mentioned.
>   - For this to work with DMA too the buffers must be sent exactly in t=
he
> same order they are received on the DRM.
>   - The DRM knows nothing about this: it's up to the client to make sur=
e
> that the information in SAREA is up to date. (The 3dfx is an exception
> since there is no DMA so the state is sent to the card without DRM
> intervention, via the Glide library).
>=20
> > Just a small expansion on this. The texture management solution is
> > weak. If two clients each had a small texture, it would be quite
> > possible that they both would have fit in texture memory and no textu=
re
> > swapping would be required. Doing that would have required more advan=
ced
> > texture management that realized certain regions were in use by one
> > client or another. We still don't have that yet. In a grand scheme
> > regions of texture memory would be shared between 2D and multiple 3D
> > clients.

We have this for other drivers - there's a linked list of regions in the =
sarea
that let drivers know for each 'chunk' of texture memory whether it has b=
een
stolen by another client or not.

Keith