<div dir="ltr"><div>Danylo,</div><div><br></div><div>You're free to implement anything not already implemented.  Here are some other (probably simpler) extensions that I think can be reasonably implemented on Intel HW:</div><div><br></div><div> - VK_EXT_conservative_rasterization</div><div> - VK_EXT_conditional_render</div><div><br></div><div>As far as VK_KHR_draw_indirect_count go, I haven't implemented it yet because the "proper" implementation is actually kind-of painful though not impossible.  In general, there are two ways it can be done:</div><div><br></div><div>## 1. The cheap and easy way</div><div><br></div><div>The spec explicitly allows for the cheap and easy way by requiring the caller to pass in a maxDrawCount.  The idea here would be to emit maxDrawCount draw calls only have each one of them predicated on draw_id < draw_count_from_buffer.  This one probably wouldn't take much to wire up but it does mean doing maxDrawCount 3DPRIMITIVE commands no matter how many of them are actually needed.</div><div><br></div><div>## 2. The hard but maybe more correct way</div><div><br></div><div>The Intel command streamer does have the ability, if used carefully, to loop.  The difficulty here isn't in looping; that can be done fairly easily on gen8+ by emitting a predicated MI_BATCH_BUFFER_START that's predicated off of the looping condition which jumps to the top of the loop.  The real difficult bit is taking your loop counter and using it to indirectly access the array of draw information.  In order to do this, you have to have a self-modifying batch buffer.  In short, you would emit MI commands which read the draw information into registers and also emit MI commands (which would probably come before the first set) which write the actual address into the location in the batch where the first set of MI commands has their address to read from.  This would be a painful to debug mess of GPU hangs but could actually be kind-of fun to implement.</div><div><br></div><div>I hope I haven't scarred you away from working on anv; I just wanted to make it clear what you're getting yourself into.  Both ways are totally implementable and I think you'd pretty much have to do the first method on gen7 if we really care about supporting it there.  The second is totally doable, it'll just involve some headaches when it's broken.  If you want to continue with this project after reading my scarry e-mail, I recommend starting with method 1 to get your feet wet and then we can look into method 2 once you have that working.</div><div><br></div><div>--Jason<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 12, 2018 at 6:36 AM Danylo Piliaiev <<a href="mailto:danylo.piliaiev@gmail.com" target="_blank">danylo.piliaiev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
I would like to try to implement one of the Vulkan extensions - <br>
VK_KHR_draw_indirect_count for anv,<br>
unless someone is already working on it.<br>
<br>
It's a relatively minor extension and I saw that the same functionality <br>
is already implemented<br>
for ARB_indirect_parameters in i965.<br>
<br>
Also I would appreciate any tips if there are any known possible tricky <br>
parts.<br>
<br>
- Danil<br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</blockquote></div>