On Tue, Sep 18, 2018 at 5:56 AM Danylo Piliaiev <danylo.pilia...@gmail.com>
wrote:
>
>
> On 9/18/18 1:46 PM, Danylo Piliaiev wrote:
>
>
>
> On 9/18/18 1:08 PM, Jason Ekstrand wrote:
>
> On Tue, Sep 18, 2018 at 4:08 AM Danylo Piliaiev <danylo.pilia...@gmail.com>
> wrote:
>
>>
>> On 9/17/18 7:03 PM, Jason Ekstrand wrote:
>>
>> On Mon, Sep 17, 2018 at 10:08 AM Danylo Piliaiev <
>> danylo.pilia...@gmail.com> wrote:
>>
>>>
>>>
>>> On 9/17/18 5:34 PM, Jason Ekstrand wrote:
>>>
>>> On Mon, Sep 17, 2018 at 8:34 AM Danylo Piliaiev <
>>> danylo.pilia...@gmail.com> wrote:
>>>
>>>> Hi Jason,
>>>>
>>>> I have implemented the extension and it works, however before sending
>>>> the patch I decided to see how it can interact with other extension -
>>>> VK_EXT_conditional_render
>>>> and got confused:
>>>>
>>>> From the spec it is not disallowed to call functions of
>>>> VK_KHR_draw_indirect_count in conditional rendering block. So let's say
>>>> that predicate of conditional rendering
>>>> will result in FALSE, we call vkCmdDrawIndirectCountKHR which sees
>>>> that there is already a predicate emitted and it should be taken into
>>>> account, since it will be FALSE
>>>> all next predicates should result in FALSE. The issue is that I don't
>>>> see an easy way to do this.
>>>>
>>>> My current implementation uses the next predicate (it is same as in GL
>>>> implementation):
>>>>
>>>> /* While draw_index < maxDrawCount the predicate's result will be
>>>> * (draw_index == maxDrawCount) ^ TRUE = TRUE
>>>> * When draw_index == maxDrawCount the result is
>>>> * (TRUE) ^ TRUE = FALSE
>>>> * After this all results will be:
>>>> * (FALSE) ^ FALSE = FALSE
>>>> */
>>>> anv_batch_emit(&cmd_buffer->batch, GENX(MI_PREDICATE), mip) {
>>>> mip.LoadOperation = LOAD_LOAD;
>>>> mip.CombineOperation = COMBINE_XOR;
>>>> mip.CompareOperation = COMPARE_SRCS_EQUAL;
>>>> }
>>>>
>>>> But if the initial predicate state is FALSE then when draw_index equals
>>>> maxDrawCount the result will be
>>>> (FALSE) ^ TRUE = TRUE
>>>> Which isn't something we want. But without "not equal" operation or
>>>> without MI_MATH I don't see how to fix this.
>>>>
>>>
>>> First off, thanks for looking into the combination of these two
>>> features. Getting them to work together nicely is half of the difficulty
>>> of these two extensions.
>>>
>>> On platforms which support MI_MATH, I think we're probably better off
>>> just using it. For Ivy Bridge, the only thing I could think to do when
>>> both are in use would be to do two MI_PREDICATEs for every draw call. The
>>> first would be what you describe above and the second would be the
>>> MI_PREDICATE for the conditional render with COMBINE_AND. When the
>>> condition is true, the AND would have no effect and you would get the
>>> behavior above. If the condition is false, the above logic for
>>> implementing draw_indirect_count wouldn't matter because it would get ANDed
>>> with false. On Haswell and later, it's likely more efficient to just use
>>> MI_MATH and avoid re-loading the draw count and condition on every draw
>>> call. (We could just leave the draw count in CS_GPR0, for instance.) Does
>>> that work?
>>>
>>> Looks like a plan. I'll try to go this path.
>>>
>>> Also there is another interaction which wasn't thought of before:
>>> Several vkCmdDrawIndirectCountKHR in conditional render block but using
>>> MI_MATH should solve it.
>>>
>>
>> In that case, we'll have to basically re-do the conditional bit for every
>> draw call. There may be some interesting interactions here with secondary
>> command buffers as well. I don't remember what we decided about inheriting
>> conditions in secondaries. Again, if we decide we need MI_MATH, then we'll
>> just drop support for one or both extensions on Ivy Bridge.
>>
>> About the secondary command buffers:
>>
>> If inherited conditional rendering
>> <https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#features-features-inheritedConditionalRendering>
>> is supported it means that secondary buffers can be executed inside
>> conditional rendering block and commands which can be affected by
>> conditional rendering are affected by it in secondary buffer and also in
>> primary, is it right?
>> However at this point the secondary buffer is already composed without
>> commands for conditions and since our implementation depends on commands
>> emitted to the buffer making its commands to depend on condition either
>> highly tricky to do (secondary buffer needs to have certain points where to
>> inject conditions?) or just impossible.
>> And this secondary buffer may have been formed inside conditional render
>> block so they could be affected by two conditions if I understand correctly.
>>
>> Is is doable to implement?
>>
>
> I think it is. The obvious way to implement it would be to have a boolean
> in the command buffer somewhere that tells you whether or not conditional
> rendering is enabled and use that to set the PredicateEnable bit on
> 3DPRIMITIVE commands. For secondary command buffers, however, we would
> have to assume that predication is enabled and set the predicate to true in
> vkCmdExecuteCommands if conditional rendering is disabled.
>
> For primary buffers I'm already doing it this way.
> So if we want to support inherited conditional rendering all relevant
> commands in *secondary* command buffers should be constructed with
> dependency on predicate. Just to be sure: is the dependency on predicate
> cheap?
>
> Sorry, forgot *secondary*.
>
> And the last question: could conditional rendering be enabled when
> secondary buffer is constructed and another one is enable when this
> secondary buffer is executes making it depend on two conditions?
>
I don't believe so:
Conditional rendering *must* begin and end in the same command buffer. When
conditional rendering is active, a primary command buffer *can* execute
secondary command buffers if the inherited conditional rendering feature is
enabled. For a secondary command buffer to be executed while conditional
rendering is active in the primary command buffer, it *must* set the
conditionalRenderingEnable flag of
VkCommandBufferInheritanceConditionalRenderingInfoEXT, as described in
the Command
Buffer Recording section.
This seems to imply that you can't begin in the primary and then begin
again in the secondary.
--Jason
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
