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. This would mean that the texture management would had to be made by the DRM or, perhaps even better, X. Surely something to look in the future. Thanks for your reply. It was very informative. José Fonseca _______________________________________________________________ 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
