> > Can you please explain how all this relates to Dave's work on the KMS? He > mentioned that he implemented paging there as well. Well we won't be using the KMS driver in RHEL6, so we need to improve the old UMS driver for that use case. Though I expect UMS eviction will hit the same problems I hit with KMS, drawables that never get released, until you poke OOM. I think the interfaces you suggested would work okay, ssp from my testing with cairo-perf traces we got some 14MB allocations, if we can't evict one of those for some reason you are pretty much locked out. The other problem is that surface create cmds are implicitly pinned while the surface is active, which can create some pretty brutal fragmentation in the non-surface RAM area. I ended up suballocating all the surface creates/destroys in their own area and pinning them in KMS land, brutal but the only way I could make it work. Best explained I suppose as you don't get surface create cmd in signalled in the release ring until after the surface destroy command is sent. So having infinite surfaces just means you are going to run out of non-surface command RAM after another while. I'm not really sure the amount of information that is stored in surface create command really justifies it being pinned, the server should probably duplicate it and release the cmd ring area for the create. Dave. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel