[Mesa-dev] [RFC] New gallium flags for using different contexts in several threads

[Nicolai Hähnle]

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