<div dir="ltr"><div>Jason, both memory-based signalling as well as interrupt-based signalling to the CPU would be supported by amdgpu. External devices don't need to support memory-based sync objects. The only limitation is that they can't convert amdgpu sync objects to dma_fence.<br></div><div><br></div><div>The sad thing is that "external -> amdgpu" dependencies are really "external <-> amdgpu" dependencies due to mutually-exclusive access required by non-explicitly-sync'd buffers, so amdgpu-amdgpu interop is the only interop that would initially work with those buffers. Explicitly sync'd buffers also won't work if other drivers convert explicit fences to dma_fence. Thus, both implicit sync and explicit sync might not work with other drivers at all. The only interop that would initially work is explicit fences with memory-based waiting and signalling on the external device to keep the kernel out of the picture.<br></div><div></div><div></div><div><br></div><div>Marek<br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 27, 2021 at 3:41 PM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Trying to figure out which e-mail in this mess is the right one to reply to....<br>
<br>
On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach <<a href="mailto:l.stach@pengutronix.de" target="_blank">l.stach@pengutronix.de</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák:<br>
> > Ok. So that would only make the following use cases broken for now:<br>
> > - amd render -> external gpu<br>
<br>
Assuming said external GPU doesn't support memory fences.  If we do<br>
amdgpu and i915 at the same time, that covers basically most of the<br>
external GPU use-cases.  Of course, we'd want to convert nouveau as<br>
well for the rest.<br>
<br>
> > - amd video encode -> network device<br>
><br>
> FWIW, "only" breaking amd render -> external gpu will make us pretty<br>
> unhappy, as we have some cases where we are combining an AMD APU with a<br>
> FPGA based graphics card. I can't go into the specifics of this use-<br>
> case too much but basically the AMD graphics is rendering content that<br>
> gets composited on top of a live video pipeline running through the<br>
> FPGA.<br>
<br>
I think it's worth taking a step back and asking what's being here<br>
before we freak out too much.  If we do go this route, it doesn't mean<br>
that your FPGA use-case can't work, it just means it won't work<br>
out-of-the box anymore.  You'll have to separate execution and memory<br>
dependencies inside your FPGA driver.  That's still not great but it's<br>
not as bad as you maybe made it sound.<br>
<br>
> > What about the case when we get a buffer from an external device and<br>
> > we're supposed to make it "busy" when we are using it, and the<br>
> > external device wants to wait until we stop using it? Is it something<br>
> > that can happen, thus turning "external -> amd" into "external <-><br>
> > amd"?<br>
><br>
> Zero-copy texture sampling from a video input certainly appreciates<br>
> this very much. Trying to pass the render fence through the various<br>
> layers of userspace to be able to tell when the video input can reuse a<br>
> buffer is a great experience in yak shaving. Allowing the video input<br>
> to reuse the buffer as soon as the read dma_fence from the GPU is<br>
> signaled is much more straight forward.<br>
<br>
Oh, it's definitely worse than that.  Every window system interaction<br>
is bi-directional.  The X server has to wait on the client before<br>
compositing from it and the client has to wait on X before re-using<br>
that back-buffer.  Of course, we can break that later dependency by<br>
doing a full CPU wait but that's going to mean either more latency or<br>
reserving more back buffers.  There's no good clean way to claim that<br>
any of this is one-directional.<br>
<br>
--Jason<br>
</blockquote></div>