[Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

[Thomas Hellström (Intel)]

On 2020-07-22 16:23, Christian König wrote:
> Am 22.07.20 um 16:07 schrieb Daniel Vetter:
>> On Wed, Jul 22, 2020 at 3:12 PM Thomas Hellström (Intel)
>> <thomas_os at shipmail.org> wrote:
>>> On 2020-07-22 14:41, Daniel Vetter wrote:
>>>> I'm pretty sure there's more bugs, I just haven't heard from them yet.
>>>> Also due to the opt-in nature of dma-fence we can limit the scope of
>>>> what we fix fairly naturally, just don't put them where no one cares
>>>> :-) Of course that also hides general locking issues in dma_fence
>>>> signalling code, but well *shrug*.
>>> Hmm, yes. Another potential big problem would be drivers that want to
>>> use gpu page faults in the dma-fence critical sections with the
>>> batch-based programming model.
>> Yeah that's a massive can of worms. But luckily there's no such driver
>> merged in upstream, so hopefully we can think about all the
>> constraints and how to best annotate&enforce this before we land any
>> code and have big regrets.
>
> Do you want a bad news? I once made a prototype for that when Vega10 
> came out.
>
> But we abandoned this approach for the the batch based approach 
> because of the horrible performance.

In context of the previous discussion I'd consider the fact that it's 
not performant in the batch-based model good news :)

Thomas


>
> KFD is going to see that, but this is only with user queues and no 
> dma_fence involved whatsoever.
>
> Christian.
>
>> -Daniel
>>
>>
>>
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx