Keith Packard wrote: >> OTOH, letting DRM resolve the deadlock by unmapping and remapping shared >> buffers in the correct order might not be the best one either. It will >> certainly mean some CPU overhead and what if we have to do the same with >> buffer validation? (Yes for some operations with thousands and thousands >> of relocations, the user space validation might need to stay). > > I do not want to do relocations in user space. I don't see why doing > thousands of these requires moving this operation out of the kernel.
Agreed. The original conception for this was to have valdiation plus relocations be a single operation, and by implication in the kernel. Although the code as it stands doesn't do this, I think that should still be the approach. The issue with thousands of relocations from my point of view isn't a problem - that's just a matter of getting appropriate data structures in place. Where things get a bit more interesting is with hardware where you are required to submit a whole scene's worth of rendering before the hardware will kick off, and with the expectation that the texture placement will remain unchanged throughout the scene. This is a very easy way to hit any upper limit on texture memory - the agp aperture size in the case of integrated chipsets. That's a special case of a the general problem of what do you do when a client submits any validation list that can't be satisfied. Failing to render isn't really an option, either the client or the memory manager has to either prevent it happening in the first place or have some mechanism for chopping up the dma buffer into segments which are satisfiable... Neither of which I can see an absolutely reliable way to do. I think that any memory manager we can propose will have flaws of some sort - either it is prone to failures that aren't really allowed by the API, is excessively complex or somewhat pessimistic. We've chosen a design that is simple, optimistic, but can potentially say "no" unexpectedly. It would then be up to the client to somehow pick up the pieces & potentially submit a smaller list. So far we just haven't touched on how that might work. The way to get around this is to mandate that hardware supports paged virtual memory... But that seems to be a difficult trick. Keith ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
