summaryrefslogtreecommitdiffstats
path: root/src/mapi
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2019-01-18 12:26:41 -0800
committerKenneth Graunke <[email protected]>2019-02-21 10:26:11 -0800
commit4801af2f26ced530b6a8c86a79a16857e670959a (patch)
tree1a3981a5fc951128c7c7bc19c1f40bd986267ab1 /src/mapi
parent0f33204f0524390b7428ea68fcc024063e4ef358 (diff)
iris: Do binder address allocations per-context, not globally.
iris_bufmgr allocates addresses across the entire screen, since buffers may be shared between multiple contexts. There used to be a single special address, IRIS_BINDER_ADDRESS, that was per-context - and all contexts used the same address. When I moved to the multi-binder system, I made a separate memory zone for them. I wanted there to be 2-3 binders per context, so we could cycle them to avoid the stalls inherent in pinning two buffers to the same address in back-to-back batches. But I figured I'd allow 100 binders just to be wildly excessive/cautious. What I didn't realize was that we need 2-3 binders per *context*, and what I did was allocate 100 binders per *screen*. Web browsers, for example, might have 1-2 contexts per tab, leading to hundreds of contexts, and thus binders. To fix this, we stop allocating VMA for binders in bufmgr, and let the binder handle it itself. Binders are per-context, and they can assign context-local addresses for the buffers by simply doing a ringbuffer style approach. We only hold on to one binder BO at a time, so we won't ever have a conflicting address. This fixes dEQP-EGL.functional.multicontext.non_shared_clear. Huge thanks to Tapani Pälli for debugging this whole mess and figuring out what was going wrong. Reviewed-by: Tapani Pälli <[email protected]>
Diffstat (limited to 'src/mapi')
0 files changed, 0 insertions, 0 deletions