<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu., Mar. 19, 2020, 06:51 Daniel Vetter, <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote:<br>
> On 2020-03-16 7:33 p.m., Marek Olšák wrote:<br>
> > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer <<a href="mailto:michel@daenzer.net" target="_blank" rel="noreferrer">michel@daenzer.net</a>> wrote:<br>
> >> On 2020-03-16 4:50 a.m., Marek Olšák wrote:<br>
> >>> The synchronization works because the Mesa driver waits for idle (drains<br>
> >>> the GFX pipeline) at the end of command buffers and there is only 1<br>
> >>> graphics queue, so everything is ordered.<br>
> >>><br>
> >>> The GFX pipeline runs asynchronously to the command buffer, meaning the<br>
> >>> command buffer only starts draws and doesn't wait for completion. If the<br>
> >>> Mesa driver didn't wait at the end of the command buffer, the command<br>
> >>> buffer would finish and a different process could start execution of its<br>
> >>> own command buffer while shaders of the previous process are still<br>
> >> running.<br>
> >>><br>
> >>> If the Mesa driver submits a command buffer internally (because it's<br>
> >> full),<br>
> >>> it doesn't wait, so the GFX pipeline doesn't notice that a command buffer<br>
> >>> ended and a new one started.<br>
> >>><br>
> >>> The waiting at the end of command buffers happens only when the flush is<br>
> >>> external (Swap buffers, glFlush).<br>
> >>><br>
> >>> It's a performance problem, because the GFX queue is blocked until the<br>
> >> GFX<br>
> >>> pipeline is drained at the end of every frame at least.<br>
> >>><br>
> >>> So explicit fences for SwapBuffers would help.<br>
> >><br>
> >> Not sure what difference it would make, since the same thing needs to be<br>
> >> done for explicit fences as well, doesn't it?<br>
> > <br>
> > No. Explicit fences don't require userspace to wait for idle in the command<br>
> > buffer. Fences are signalled when the last draw is complete and caches are<br>
> > flushed. Before that happens, any command buffer that is not dependent on<br>
> > the fence can start execution. There is never a need for the GPU to be idle<br>
> > if there is enough independent work to do.<br>
> <br>
> I don't think explicit fences in the context of this discussion imply<br>
> using that different fence signalling mechanism though. My understanding<br>
> is that the API proposed by Jason allows implicit fences to be used as<br>
> explicit ones and vice versa, so presumably they have to use the same<br>
> signalling mechanism.<br>
> <br>
> <br>
> Anyway, maybe the different fence signalling mechanism you describe<br>
> could be used by the amdgpu kernel driver in general, then Mesa could<br>
> drop the waits for idle and get the benefits with implicit sync as well?<br>
<br>
Yeah, this is entirely about the programming model visible to userspace.<br>
There shouldn't be any impact on the driver's choice of a top vs. bottom<br>
of the gpu pipeline used for synchronization, that's entirely up to what<br>
you're hw/driver/scheduler can pull off.<br>
<br>
Doing a full gfx pipeline flush for shared buffers, when your hw can do<br>
be, sounds like an issue to me that's not related to this here at all. It<br>
might be intertwined with amdgpu's special interpretation of dma_resv<br>
fences though, no idea. We might need to revamp all that. But for a<br>
userspace client that does nothing fancy (no multiple render buffer<br>
targets in one bo, or vk style "I write to everything all the time,<br>
perhaps" stuff) there should be 0 perf difference between implicit sync<br>
through dma_resv and explicit sync through sync_file/syncobj/dma_fence<br>
directly.<br>
<br>
If there is I'd consider that a bit a driver bug.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Last time I checked, there was no fence sync in gnome shell and compiz after an app passes a buffer to it. So drivers have to invent hacks to work around it and decrease performance. It's not a driver bug.</div><div dir="auto"><br></div><div dir="auto">Implicit sync really means that apps and compositors don't sync, so the driver has to guess when it should sync.</div><div dir="auto"><br></div><div dir="auto">Marek</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Daniel<br>
-- <br>
Daniel Vetter<br>
Software Engineer, Intel Corporation<br>
<a href="http://blog.ffwll.ch" rel="noreferrer noreferrer" target="_blank">http://blog.ffwll.ch</a><br>
</blockquote></div></div></div>