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@xxxxxxxxx > > <mailto:airlied@xxxxxxxxx>> wrote: > > > > On Tue, 27 Apr 2021 at 22:06, Christian König > > <ckoenig.leichtzumerken@xxxxxxxxx > > <mailto:ckoenig.leichtzumerken@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
