On 18/12/2016 18:34, Nicolai Hähnle wrote:
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.
If drivers flush noop very fast, I'm okay doing that (but do they ?).
My main thought relative to that was: What about persistent, coherent
and barriers ? Does it makes sense for them to flush after unmap ? It is
supposed to work using them in another context without unmap or flush ?
Is it expected for current drivers that you can map such buffers with
one context, and draw with the others ?
In case barriers are needed (nine doesn't use persistent without
coherent so doesn't need this, but it would need to be clarified), which
context should wait for the barrier ?
Axel
Nicolai
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
