On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote: > What follows is the collected requirements for the new DRI memory > manager. This list is the product of several discussions between Brian, > Keith, Allen, and myself several months ago. After the list, I have > included some of my thoughts on the big picture that I see from these > requirements. > > 1. Single-copy textures > > Right now each texture exists in two or three places. There is a copy > in on-card or AGP memory, in system memory (managed by the driver), and > in application memory. Any solution should be able to eliminate one or > two of those copies. ...
BTW, since you are looking into this, have you thought about graphic chips which can do MMU like tricks. I am not sure if the current set of graphic chips the DRI runs on do this kind of stuff, but they well may in the future. I know the gamma drm module use the gamma's virtual memory table to not need to do virtual<->physical conversion. But more importantly to you, altough there is not yet a DRI driver for it, the 3Dlabs permedia3 can use virtual memory for its textures. That is you can basically set up the graphic boards memory as a cache memory, and have the the MMU-like unit swap the memory pages from host memory, using i suppose its own page replacement algorithm. Friendly, Sven Luther ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
