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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
