[Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
daniel at ffwll.ch
Wed Apr 28 09:54:08 UTC 2021
On Wed, Apr 28, 2021 at 08:59:47AM +0200, Christian König wrote:
> Hi Dave,
> Am 27.04.21 um 21:23 schrieb Marek Olšák:
> > Supporting interop with any device is always possible. It depends on
> > which drivers we need to interoperate with and update them. We've
> > already found the path forward for amdgpu. We just need to find out how
> > many other drivers need to be updated and evaluate the cost/benefit
> > aspect.
> > Marek
> > On Tue, Apr 27, 2021 at 2:38 PM Dave Airlie <airlied at gmail.com
> > <mailto:airlied at gmail.com>> wrote:
> > On Tue, 27 Apr 2021 at 22:06, Christian König
> > <ckoenig.leichtzumerken at gmail.com
> > <mailto:ckoenig.leichtzumerken at gmail.com>> wrote:
> > >
> > > Correct, we wouldn't have synchronization between device with
> > and without user queues any more.
> > >
> > > That could only be a problem for A+I Laptops.
> > Since I think you mentioned you'd only be enabling this on newer
> > chipsets, won't it be a problem for A+A where one A is a generation
> > behind the other?
> Crap, that is a good point as well.
> > I'm not really liking where this is going btw, seems like a ill
> > thought out concept, if AMD is really going down the road of designing
> > hw that is currently Linux incompatible, you are going to have to
> > accept a big part of the burden in bringing this support in to more
> > than just amd drivers for upcoming generations of gpu.
> Well we don't really like that either, but we have no other option as far as
> I can see.
> I have a couple of ideas how to handle this in the kernel without
> dma_fences, but it always require more or less changes to all existing
Yeah one horrible idea is to essentially do the plan we hashed out for
adding userspace fences to drm_syncobj timelines. And then add drm_syncobj
as another implicit fencing thing to dma-buf.
- This is horrible. We're all agreeing that implicit sync is not a great
idea, building an entire new world on this flawed thing doesn't sound
like a good path forward.
- It's kernel uapi, so it's going to be forever.
- It's only fixing the correctness issue, since you have to stall for
future/indefinite fences at the beginning of the CS ioctl. Or at the
beginning of the atomic modeset ioctl, which kinda defeats the point of
- You still have to touch all kmd drivers.
- For performance, you still have to glue a submit thread onto all gl
It is horrendous.
> > Dave.
Software Engineer, Intel Corporation
More information about the mesa-dev