lkml.org 
[lkml]   [2007]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH] DRM TTM Memory Manager patch
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-04 18:19    [W:3.573 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site