I've got a couple of things that are bothering me if we're looking at finalizing the TTM interface in the near term.
Specifically I'm concerned that we don't have a recoverable way to deal with out-of-memory situations. Consider a driver that tries to submit whole frames of q3, which is running on say a 32mb card. There's nothing to stop the driver specifying textures in excess of what is available to the memory manager. If the driver does do this, there's no feedback from the kernel that this is a band idea until after it's done. Also, all the geometry is now gone, so it's too late to restructure the command stream or even fall back to software. Note this is a different situation to using 8 huge textures to draw a single triangle, where nothing can be done to help. In the case above, the scene could be split and rendered on hardware, although at the expense of texture thrashing. We've benefited from the flexibilty with IGPs to avoid this so far, but we do want to cope with VRAM and it seems like we are currently missing some of the necessary mechanisms... So the issues are: - how does the driver know ahead of time it is running out of texture space? - if the answer to the above is "it doesn't", then how do we rescue submitted command streams that exceed texture space? - relatedly, on cards with texture-from-vram and texture-from-agp, how does the driver know which pool to use for a particular texture? At worst, I can imagine something like the kernel pushing out to userspace a size for each pool which is guarenteed to be available for validated buffers. Eg, on a 32 mb card, we could say that there is a maximum no-evict space of 8mb, meaning that at all times there is at least 24 mb available for validated buffers. There may be more than that. The userspace driver would be responsible for ensuring that all the buffers it wants to validate to that pool do not exceed 24mb (given some alignment constraints???). When it approaches that limit, it can either switch to other pools or flush the command stream. If some of the 8mb is free, it can be used by the memory manager to avoid evicts. In the worst case, it just means that the userspace driver flushes more often than it strictly has to. It can even try and exceed the 24mb if it wants to, but has to live with the possibility of the memory manager saying 'no'. It still has access to the full amount of memory on the card not taken by no-evict buffers. So summarizing: - Enforce a limit on no-evict buffers. Keep these to a contigous region of the address space (XXX: note this makes pageflipping private backbuffers more complex). - Advertize the size of the remaining space. - Drivers monitor the total size of buffers referenced by relocations, and flush before it reaches the available space in any pool. - Drivers may try to reference more as long as they are prepared for failure. - The memory manager uses any extra space to avoid evicts. This seems like it can be implemented in the time available with minimal kernel changes. It also seems like it will probably work, and pushes most of the responsibility into the userspace driver, and allows it to make decisions as the stream is being built rather than trying to fix it up afterwards... Keith ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel