On Fri, Jul 8, 2016 at 12:14 PM, Rob Clark <robdcl...@gmail.com> wrote: > One of the annoying things, since pipe_resource is per-screen, not > per-context, I end up having to push batch_cache down into screen. > Which means that, for example, one context switching fb state could > force flushing a batch from another context. Eventually if I push of > gmem+submit to a per-context helper thread, that should help keep > things properly serialized. Although I still need some (currently > missing) mutexes to serialize batch_cache access, etc. Also it means > that the upper limit on # of batches is per-screen, not per-context. > Not really sure what to do about that. I really wish resources were > not shared across contexts (but rather just use flink or dmabuf when > you need to share), but I guess it is too late for that now :-(
so what sorts of scenarios do I have to care about multiple contexts sharing a pipe_resource? Pushing batch_cache down into screen is awfully painful. I more or less have it working, but not terribly happy with all the extra locking and complexity. If I restrict things so that a pipe_resource could only be active (ie. pending read or write) by a single context at a time (without blocking on a fence when switching between contexts) I can move batch_cache back up to the context, and make a whole lot of pain go away.. BR, -R _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
