On 18.12.2016 17:37, Axel Davy wrote:
On 18/12/2016 16:57, Nicolai Hähnle wrote:
On 18.12.2016 13:38, Axel Davy wrote:
Currently there is no real specification on what is allowed for
using different contexts in several threads, or when you
map/unmap a resource in a thread, but uses it in another for
draw calls.
For the gallium nine CSMT patchset, I've figured out it would be better
to add flags to describe what is allowed.
Please comment.
I don't see the point of this. All existing drivers must already
support the multi-threading scenarios described in the commits,
because they can happen as part of correct use of OpenGL. If drivers
don't support them, then they're already broken.
Some drivers aren't thread safe. For example nouveau isn't. I guess
other drivers may be.
Then this needs to be fixed regardless because it could have happened in
OpenGL applications all along.
I'm happy to be convinced otherwise if I missed something, but using
multiple contexts from different threads, or using Map/UnmapBuffer
from one context but sourcing the buffer from draw calls in another
context are all perfectly supported OpenGL use cases.
For some drivers and combination flags, map gives a staging buffer and
unmap does trigger a copy of it to the real buffer. This is not
neccessarily flushed. I'd like this flush to be implicit, because if we
can avoid it (most of the cases) it's better.
Is this for some internal transfers done by nine?
I _really_ don't like the "EXTERNAL_CONTEXT" naming. "External contexts"
may be a motivation for using the feature, but they're not what the
feature is really about. It's about the interaction of unmap and flush.
Remember: Even today, all resources can be mapped from context A and
drawn from using context B. You don't need a flag for that.
We really shouldn't add more places for drivers to do implicit flushes.
Reduce the magic, please. If anything, we could consider adding a
feedback mechanism where the driver tells you at transfer_map time
whether the unmap requires a flush to be effective. That has the
advantage of working with multiple such unmaps in a row.
Then again, why not just call flush unconditionally? If the flush was
unnecessary, it should be a no-op, and the driver should already have a
fast path for that anyway.
Nicolai
_______________________________________________
mesa-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
