On Mon, Sep 29, 2014 at 10:20:44AM -0700, James Jones wrote: > Additionally, I think the goal is to move to a model where some higher-level > object such as a working set, rather than individual buffers, are assigned > counters or sync primitives on a per-submission basis. Versioning off tags > for individual buffers then moves to working set modification time. This is > more feasible if the only thing that needs precise fencing of individual > surfaces is lifetime management.
Yeah, there's always ways to make the fence assignment and tracking a bit more efficient, we're playing around with working-set tricks for i915 ourselves. But fundamentally you still have fences for each buffer object (just can't directly access them). And for buffers exported with dma_buf you still need the direct link I think, at least when you care about implicit syncing somewhat. > The trend seems to be towards establishing a relatively large working set up > front and then submitting many command buffers against it, perhaps with > incremental modifications to the working set along the way. This may be > what's referred to as the Android model above, but I view it as the > "non-glitchy graphic" model going forward. Nah, that's something different. Afaik Android drivers don't really bother a lot with swap and page migration and having a working shrinker for gpu objects. At least our android guys need to disable the lowmemory killer since that thing just goes bananas if we driver i915 memory usuage against the wall and into swap. I'm not really sure what you mean by "non-glitchy graphics", for me this can mean anything from avoiding stalls to proper syncing with vblanks to anything else really ... So might be good to elaborate here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
