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

[Christian König]

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.

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