<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 9/18/18 1:46 PM, Danylo Piliaiev
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b3700cf8-3ed2-1cb7-9d8f-26da02039097@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br>
<br>
<div class="moz-cite-prefix">On 9/18/18 1:08 PM, Jason Ekstrand
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOFGe95G0BsJ5nzXzh-aDcyPGp560Z0s25eWxMumR+908y9SMg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Tue, Sep 18, 2018 at 4:08 AM Danylo
Piliaiev <<a href="mailto:danylo.piliaiev@gmail.com"
moz-do-not-send="true">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"><br>
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_-6732043544054597089moz-cite-prefix">On
9/17/18 7:03 PM, Jason Ekstrand wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Mon, Sep 17, 2018 at 10:08 AM
Danylo Piliaiev <<a
href="mailto:danylo.piliaiev@gmail.com"
target="_blank" moz-do-not-send="true">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">
<div text="#000000" bgcolor="#FFFFFF"> <br>
<br>
<div
class="m_-6732043544054597089m_8653083740311233362moz-cite-prefix">On
9/17/18 5:34 PM, Jason Ekstrand wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Mon, Sep 17, 2018 at
8:34 AM Danylo Piliaiev <<a
href="mailto:danylo.piliaiev@gmail.com"
target="_blank"
moz-do-not-send="true">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">
<div text="#000000" bgcolor="#FFFFFF">
Hi Jason,<br>
<br>
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<br>
and got confused:<br>
<br>
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<br>
will result in FALSE, we call <span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684blob-code-inner
m_8653083740311233362m_8153322649885267684blob-code-marker-addition"><span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684pl-s">vkCmdDrawIndirectCountKHR
which sees that there is already
a predicate emitted and it
should be taken into account,
since it will be FALSE<br>
all next predicates should
result in FALSE. The issue is
that I don't see an easy way to
do this.<br>
<br>
My current implementation uses
the next predicate (it is same
as in GL implementation):<br>
<br>
<tt> /* While draw_index
< maxDrawCount the
predicate's result will be</tt><tt><br>
</tt><tt> * (draw_index
== maxDrawCount) ^ TRUE = TRUE</tt><tt><br>
</tt><tt> * When
draw_index == maxDrawCount the
result is</tt><tt><br>
</tt><tt> * (TRUE) ^
TRUE = FALSE</tt><tt><br>
</tt><tt> * After this
all results will be:</tt><tt><br>
</tt><tt> * (FALSE) ^
FALSE = FALSE</tt><tt><br>
</tt><tt> */</tt><tt><br>
</tt><tt>
anv_batch_emit(&cmd_buffer->batch,
GENX(MI_PREDICATE), mip) {</tt><tt><br>
</tt><tt>
mip.LoadOperation =
LOAD_LOAD;</tt><tt><br>
</tt><tt>
mip.CombineOperation =
COMBINE_XOR;</tt><tt><br>
</tt><tt>
mip.CompareOperation =
COMPARE_SRCS_EQUAL;</tt><tt><br>
</tt><tt> }</tt><br>
<br>
But if the initial predicate
state is FALSE then when
draw_index equals maxDrawCount
the result will be<br>
<tt>(FALSE) ^ TRUE = TRUE</tt><br>
Which isn't something we want.
But without "not equal"
operation or without MI_MATH I
don't see how to fix this.<br>
</span></span></div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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?</div>
</div>
</div>
</blockquote>
Looks like a plan. I'll try to go this path.<br>
<br>
Also there is another interaction which wasn't
thought of before:<br>
Several <span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684blob-code-inner
m_8653083740311233362m_8153322649885267684blob-code-marker-addition"><span
class="m_-6732043544054597089m_8653083740311233362m_8153322649885267684pl-s">vkCmdDrawIndirectCountKHR
in conditional render block but using
MI_MATH should solve it.<br>
</span></span></div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
About the secondary command buffers:<br>
<br>
If <a
href="https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#features-features-inheritedConditionalRendering"
target="_blank" moz-do-not-send="true">inherited
conditional rendering</a> 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?<br>
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.
<br>
And this secondary buffer may have been formed inside
conditional render block so they could be affected by
two conditions if I understand correctly.<br>
<br>
Is is doable to implement?<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
For primary buffers I'm already doing it this way. <br>
So if we want to support inherited conditional rendering all
relevant commands in <u>secondary</u> command buffers should be
constructed with dependency on predicate. Just to be sure: is the
dependency on predicate cheap?<br>
</blockquote>
Sorry, forgot *secondary*.<br>
<br>
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?<br>
<blockquote type="cite"
cite="mid:b3700cf8-3ed2-1cb7-9d8f-26da02039097@gmail.com">
<blockquote type="cite"
cite="mid:CAOFGe95G0BsJ5nzXzh-aDcyPGp560Z0s25eWxMumR+908y9SMg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>The second issue is in communicating the predicate
value. If we don't have secondaries, we can just hang on
to the condition buffer and re-read it whenever needed.
If we're going to use secondaries, we won't have it
available in the secondary. One obvious option would be
to simply reserve one of the CS_GPR registers, say
CS_GPR15, for storing the predicate value. On Ivy Bridge,
the CS_GPRs don't exist and we'd have to pick some other
RW register. Digging through the docs, I found the
MI_PREDICATE_DATA which seems to exist for just this sort
of thing. :-) Exactly what register we use will have to
depend on how we want to compute predicate values; I could
see CS_GPR15 being more convenient if we use MI_MATH, for
instance.<br>
</div>
</div>
</div>
</blockquote>
Thanks for suggestion!<br>
<blockquote type="cite"
cite="mid:CAOFGe95G0BsJ5nzXzh-aDcyPGp560Z0s25eWxMumR+908y9SMg@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
--Jason<br>
</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>