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.