> Yes, this is really a different hardware model than we're used to > dealing with for DRI drivers, however it's not a problem for the most > part - if you don't need to take the lock, don't. But then you need > some other way of dealing with the other hacky stuff we get away with by > lock abuses eg. VT switching.
We could abuse a RW lock model here where normal command submission takes a read lock (can be shared) and big hammer like VT switch takes a write lock. > For the memory manager, I guess there are two choices: 1) make the > driver use a command-buffer approach even though the hardware supports > per-context ring buffers, or 2) extend the memory manager. > > Extending the memory manager would involve adding an ability to lock and > unlock surfaces to VRAM/AGP addresses - this would require kernel > interaction I guess. The driver would have to lock the surfaces then be > free to submit commands to the ring, then explicitly unlock the > surfaces. This is actually a pretty nasty approach - it makes it very > hard to deal with low-memory situations - it's impossible to kick out > another processes allocations. > > I wonder how NV deals with this... I've heard some of the proprietary drivers play MMU tricks. We could do something similar... when kicking a pixmap out, we "remap" the virtual mapping for that pixmap to backup memory. But that means fundamentally changing our model where we have a big mapping for the fb which we then cut into objects and instead mmap objects separately. As for kicking out mappings behind somebody's back, it works fine :) We do that for SPEs local stores on the Cell processor. A no_page() function will refill as needed from either the HW or the backing store and use unmap_mapping_range() can kick that out behind any process back. The main problem I see with that approach is that you have to either map the backup memory non-cacheable which can be trouble on some platforms (*) or cacheable which means that the same bit of memory will either be cacheable or non-cacheable depending on wether you get the HW, which might be trouble to some apps unless you are careful. (*) The kernel always keeps a cacheable linear mapping of all memory and the nasty prefetchers or speculative execution units might thus bring something from your page otherwise mapped non-cacheable into userspace in the cache that way. Some CPUs will shoke badly if you access via a non-cacheable mapping something that is present in the cache. Ben. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
