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

[Daniel Stone]

Hi,

On Tue, 20 Apr 2021 at 20:03, Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
wrote:

> On Tue, Apr 20, 2021 at 8:16 PM Daniel Stone <daniel at fooishbar.org> wrote:
>
>> It's a jarring transition. If you take a very narrow view and say 'it's
>> all GPU work in shared buffers so it should all work the same', then
>> client<->winsys looks the same as client<->client gbuffer. But this is a
>> trap.
>>
>
> I think this is where I think we have have a serious gap of what a winsys
> or a compositor is. Like if you have only a single wayland server running
> on a physical machine this is easy. But add a VR compositor, an
> intermediate compositor (say gamescope), Xwayland and some containers/VM,
> some video capture  (or, gasp, a browser that doubles as compositor) and
> this story gets seriously complicated. Like who are you protecting from
> who? at what point is something client<->winsys vs. client<->client?
>

As I've said upthread, the line is _seriously_ blurred, and is only getting
less clear. Right now, DRI3 cannot even accept a dma_fence, let alone a
drm_syncobj, let alone a memory fence.

Crossing those boundaries is hard, and requires as much thinking as typing.
That's a good thing.

Conflating every synchronisation desire into a single
userspace-visible primitive makes this harder, because it treats game
threads the same as other game threads the same as VR compositors the same
as embedding browsers the same as compositors etc. Drawing very clear lines
between game threads and the external world, with explicit weakening as
necessary, makes those jarring transitions of privilege and expectation
clear and explicit. Which is a good thing, since we're trying to move away
from magic and implicit.

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