Similarly to the modulus operator, d3dbc results with constant folding
are different from results when constant folding cannot be applied, and
different from tpf results.
Note that in d3dbc target profiles it gives different results when this
operation is constant folded compared to when it is not.
This suggests that whatever pass lowers the modulus operation to d3dbc
operations doesn't do it before constant folding.
Also note that when constant folded, d3dbc results differ from tpf
results for negative operands, because of the loss of precision that
happens when NEG is constant folded.
So the same integer modulus expression can have 3 different results
depending on the context.
As far as I know there is no way to implement this properly on
Vulkan, and all the other Vulkan implementations essentially work
by luck. In Vulkan the initial layout of a resource must always be
UNDEFINED or PREINITIALIZED and it must be transitioned away from
before any meaningful use of that image is done. Therefore it's
possible to alias two images and let the second one inherit the
content in the first one only if both already exist (and are in
the same layout) before the first writing is done. If, as in this
example, the second image is created after the first one has
already been written to, the obligatory transition away from
UNDEFINED or PREINITIALIZED will potentially wipe out the content.
Therefore I am marking this as todo, not as a bug. I might also be
that there is a bug in MoltenVK, and ultimately that's the reason
why we're reading invalid data, but technically the Vulkan
commands we generate are incorrect anyway.
When textures[1] is read for the second time it is aliased to
textures[0]. But textures[0] was left in COPY_DEST state (since
its creation), and textures[1] is currently recreated in COPY_SOURCE
state, which AFAIU is invalid. So recreate textures[1] in COPY_DEST
state and then transition it before reading it.
I haven't investigated the actual problem here, but the generated
Vulkan commands look correct (and work with basically all other
Vulkan implementations) and MoltenVK is known to have incomplete
tessellation support, so it's likely that the problem is there.
Similarly to 5d4edba925, it seems
that sometimes MoltenVK returns 0 to timestamp queries. It
doesn't happen deterministically and it might depend on the
hardware (I have seen differences between the M2 I used some
time ago and the M3 Max I have now).
My main motivation to this is avoiding generating a lot of useless
log lines from other executors when I'm interested in just one of
them, but I can imagine this also somewhat improving efficiency.
