Benjamin Herrenschmidt wrote:
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.
Actually, the TTM memory manager already does this,
but also changes the caching policy of the linear kernel map.
Unfortunately this leads to rather costly cache and TLB flushes.
Particularly on SMP.
I think Keith was referring to the drawbacks with buffers pinned in AGP
or VRAM space.
/Thomas.
-------------------------------------------------------------------------
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
|
-------------------------------------------------------------------------
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
