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

[Axel Davy]

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
>