On Tue, Feb 12, 2002 at 12:35:55PM -0800, Allen Akin wrote: > Just a side comment on Ian's excellent summary... > > On Tue, Feb 12, 2002 at 11:45:58AM -0800, Ian Romanick wrote: > | - If an allocation (via the memHeap_t) fails when texture space is allocated > | (radeonUploadTexImages in lib/GL/mesa/src/drv/radeon/radeon_texmem.c), > | blocks at the end of the texList queue are freed until the allocation can > | succeed. This may be an area where the algorithm could be improved. For > | example, it might be better to find the largest free block (in the > | memHeap_t) and release memory around that block in LRU or least-often-used > | fashion until the allocation can succeed. > > I spent some time last year looking into memory management issues for > OpenGL. One of the things I noticed was that most apps render the > primitives in a scene in roughly the same order from frame to frame. > Consequently textures are referenced in roughly the same order each time > a frame is drawn: T0, T1, T2, ...; T0, T1, T2, ... and so on.
Right. In Windows, and probably other systems as well, driver vendors have found a "sollution" to this problem. Basically they provide several different algorithms for things (like texture management) and use the moral equivalent of environment variables to tune the selection. Some drivers even go so far as to select a tuning based on the name of the app, but we won't go there. :) *cough*ATI*cough* In terms of DRI, we should be able to implement a "good" general texture management policy and several special case policies as well. We'd then just use env variables to select among them. The only catch is that all of this would be per-context, so multiple contexts may not play together optimally. -- Tell that to the Marines! _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
