<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue., Mar. 17, 2020, 06:02 Michel Dänzer, <<a href="mailto:michel@daenzer.net">michel@daenzer.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes. If there is any waiting, or should be done in the GPU scheduler, not in the command buffer, so that independent command buffers can use the GFX queue.</div><div dir="auto"><br></div><div dir="auto">Marek</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">
<br>
<br>
-- <br>
Earthling Michel Dänzer               |               <a href="https://redhat.com" rel="noreferrer noreferrer" target="_blank">https://redhat.com</a><br>
Libre software enthusiast             |             Mesa and X developer<br>
</blockquote></div></div></div>