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

From: Daniel Vetter <daniel@ffwll.ch>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: "ML Mesa-dev" <mesa-dev@lists.freedesktop.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Marek Olšák" <maraeo@gmail.com>
Subject: Re: [Mesa-dev] [RFC] Linux Graphics Next: Explicit fences everywhere and no BO fences - initial proposal
Date: Wed, 28 Apr 2021 11:54:08 +0200	[thread overview]
Message-ID: <YIkwwD1z7r4BbEZU@phenom.ffwll.local> (raw)
In-Reply-To: <153487a3-082b-faf7-2a4d-ae15993b2a5d@gmail.com>

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@gmail.com
> > <mailto:airlied@gmail.com>> wrote:
> > 
> >     On Tue, 27 Apr 2021 at 22:06, Christian König
> >     <ckoenig.leichtzumerken@gmail.com
> >     <mailto:ckoenig.leichtzumerken@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
> drivers.

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.

But:
- 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
  nonblocking.

- You still have to touch all kmd drivers.

- For performance, you still have to glue a submit thread onto all gl
  drivers.

It is horrendous.
-Daniel

> 
> Christian.
> 
> > 
> >     Dave.
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel