[Mesa-dev] Implementation of VK_KHR_draw_indirect_count extension for anv

[Danylo Piliaiev]

Hi,

Thank you for the directions!

On 9/12/18 6:13 PM, Jason Ekstrand wrote:
> Danylo,
>
> 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:
>
>  - VK_EXT_conservative_rasterization
>  - VK_EXT_conditional_render
Didn't see them, will take closer look later.
>
> 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:
>
> ## 1. The cheap and easy way
>
> 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.
I saw such implementation for i965, looked straightforward and I thought 
it will easily translate into Vulkan implementation. Didn't know that 
it's possible to do it other way on Intel.
>
> ## 2. The hard but maybe more correct way
>
> 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.
The correct way looks interesting, I'll need some time to understand 
details.
>
> 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.
I'll follow your recommendation and will start from the first method.

- Danil
>
> --Jason
>
> On Wed, Sep 12, 2018 at 6:36 AM Danylo Piliaiev 
> <danylo.piliaiev at gmail.com <mailto:danylo.piliaiev at gmail.com>> wrote:
>
>     Hello everyone,
>
>     I would like to try to implement one of the Vulkan extensions -
>     VK_KHR_draw_indirect_count for anv,
>     unless someone is already working on it.
>
>     It's a relatively minor extension and I saw that the same
>     functionality
>     is already implemented
>     for ARB_indirect_parameters in i965.
>
>     Also I would appreciate any tips if there are any known possible
>     tricky
>     parts.
>
>     - Danil
>     _______________________________________________
>     mesa-dev mailing list
>     mesa-dev at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
>     https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180912/5404cad6/attachment.html>