[Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal

[Daniel Stone]

On Tue, 20 Apr 2021 at 17:25, Marek Olšák <maraeo at gmail.com> wrote:

> Daniel, imagine hardware that can only do what Windows does: future fences
> signalled by userspace whenever userspace wants, and no kernel queues like
> we have today.
>
> The only reason why current AMD GPUs work is because they have a ring
> buffer per queue with pointers to userspace command buffers followed by
> fences. What will we do if that ring buffer is removed?
>

I can totally imagine that; memory fences are clearly a reality and we need
to make them work for functionality as well as performance. Let's imagine
that winsys joins that flying-car future of totally arbitrary sync, that we
work only on memory fences and nothing else, and that this all happens by
the time we're all vaccinated and can go cram into a room with 8000
other people at FOSDEM instead of trying to do this over email.

But the first couple of sentences of your proposal has the kernel
monitoring those synchronisation points to ensure that they complete in
bounded time. That already _completely_ destroys the purity of the simple
picture you paint. Either there are no guarantees and userspace has to
figure it out, or there are guarantees and we have to compromise that
purity.

I understand how you arrived at your proposal from your perspective as an
extremely skilled driver developer who has delivered gigantic performance
improvements to real-world clients. As a winsys person with a very
different perspective, I disagree with you on where you are drawing the
boundaries, to the point that I think your initial proposal is worse than
useless; doing glFinish() or the VkFence equivalent in clients would be
better in most cases than the first mail.

I don't want to do glFinish (which I'm right about), and you don't want to
do dma_fence (which you're right about). So let's work together to find a
middle ground which we're both happy with. That middle ground does exist,
and we as winsys people are happy to eat a significant amount of pain to
arrive at that middle ground. Your current proposal is at once too gentle
on the winsys, and far too harsh on it. I only want to move where and how
those lines are drawn, not to pretend that all the world is still a
single-context FIFO execution engine.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20210420/9ea9b804/attachment.htm>