<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019, 4:15 AM Koenig, Christian <<a href="mailto:Christian.Koenig@amd.com">Christian.Koenig@amd.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-4107032735876451030moz-cite-prefix">Am 10.01.19 um 00:39 schrieb Marek Olšák:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Wed, Jan 9, 2019 at 1:41 PM Christian König <<a href="mailto:ckoenig.leichtzumerken@gmail.com" target="_blank" rel="noreferrer">ckoenig.leichtzumerken@gmail.com</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">
<div bgcolor="#FFFFFF">
<div class="m_-4107032735876451030gmail-m_-7810855682144448022moz-cite-prefix">Am 09.01.19 um 17:14 schrieb Marek Olšák:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Wed, Jan 9, 2019 at 8:09 AM Christian König <<a href="mailto:ckoenig.leichtzumerken@gmail.com" target="_blank" rel="noreferrer">ckoenig.leichtzumerken@gmail.com</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">
<div bgcolor="#FFFFFF">
<div class="m_-4107032735876451030gmail-m_-7810855682144448022m_8930908994027207900m_-7323258551939539738gmail-m_4443106390953893387gmail-m_-3252015337124169842moz-cite-prefix">
Am 09.01.19 um 13:36 schrieb Marek Olšák:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Jan 9, 2019, 5:28 AM Christian König <<a href="mailto:ckoenig.leichtzumerken@gmail.com" target="_blank" rel="noreferrer">ckoenig.leichtzumerken@gmail.com</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">
Looks good, but I'm wondering what's the actual improvement?<br>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">No malloc calls and 1 less for loop copying the bo list.</div>
</div>
</blockquote>
<br>
Yeah, but didn't we want to get completely rid of the bo list?<br>
</div>
</blockquote>
<div><br>
</div>
If we have multiple IBs (e.g. gfx + compute) that share a BO list, I think it's faster to send the BO list to the kernel only once.</div>
</div>
</div>
</blockquote>
<br>
That's not really faster.<br>
<br>
The only thing we safe us is a single loop over all BOs to lockup the handle into a pointer and that is only a tiny fraction of the overhead.<br>
<br>
The majority of the overhead is locking the BOs and reserving space for the submission.<br>
<br>
What could really help here is to submit gfx+comput together in just one CS IOCTL. This way we would need the locking and space reservation only once.<br>
<br>
It's a bit of work in the kernel side, but certainly doable.<br>
</div>
</blockquote>
<div><br>
</div>
<div>OK. Any objections to this patch?</div>
</div>
</div>
</blockquote>
<br>
In general I'm wondering if we couldn't avoid adding so much new interface.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There are Vulkan drivers that still use the bo_list interface.</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"><div text="#000000" bgcolor="#FFFFFF">
<br>
For example we can avoid the malloc() when we just cache the last freed bo_list structure in the device. We would just need an atomic pointer exchange operation for that.</div></blockquote></div></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"><div text="#000000" bgcolor="#FFFFFF">
<br>
This way we even don't need to change mesa at all.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There is still the for loop that we need to get rid of.</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"><div text="#000000" bgcolor="#FFFFFF">
<br>
Regarding optimization, this chunk can be replaced by a cast on 64bit:<br>
<blockquote type="cite">
<pre class="m_-4107032735876451030moz-quote-pre">+      chunk_array = alloca(sizeof(uint64_t) * num_chunks);
+       for (i = 0; i < num_chunks; i++)
+               chunk_array[i] = (uint64_t)(uintptr_t)&chunks[i];</pre></blockquote></div></blockquote></div></div><div dir="auto">It can't. The input is an array of structures. The ioctl takes an array of pointers.</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"><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
</blockquote>
<br>
Regards,<br>
Christian.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Thanks,<br>
</div>
<div>Marek</div>
</div>
</div>
</blockquote>
<br>
</div>

</blockquote></div></div></div>