"José Fonseca" wrote: > > Darryl, > > On 2002.05.12 19:11 Daryll Strauss wrote: > > On Sun, May 12, 2002 at 05:27:26PM +0100, José 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 check > > your flags to see what changed. In the tdfx driver I kept 3 flags. One > > 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 resyncronize > > the fifo in that case. The second said that the 3D state was dirty. That > > 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. Finally > > 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 that > > 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. > > > > I've been snooping in the tdfx driver source. You're referring to the > TDFXSAREAPriv.*Owner flags in tdfx_context.h and the tdfxGetLock function > in tdfx_lock.c, in the tdfx's Mesa driver. > > So let's see if I got this straight (these notes are not specific to 3dfx): > > - 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 client. > 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 the > same order they are received on the DRM. > - The DRM knows nothing about this: it's up to the client to make sure > 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). > > > 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 texture > > swapping would be required. Doing that would have required more advanced > > 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 been stolen by another client or not. Keith _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
