The graphics pipeline triggers an internal error in the Metal
pipeline compiler, with a completely generic error message. I have
no idea what the actual problem is.
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).
Some test programs, particularly the shader runner, are built from
many different files nowadays, and a line number is relatively
cumbersome to use if you don't know which file that line comes from.
Similarly to RADV, this is a kind of perverted situation: in
principle Vulkan doesn't allow vkCmdResolveImage() to be
executed conditionally (i.e., it is unaffected by conditional
execution), which means that vkd3d cannot implement conditional
rendering for ResolveSubresource(), hence the todo. However,
like RADV, llvmpipe apparently violates the specification and
still executes the image resolution command conditionally. So
that's a llvmpipe bug, even if one that helps us doing the right
thing.
Vulkan doesn't mandate whether sampling exactly in the middle between
two levels should resolve to one or the other, while D3D specifies
that it should result into sampling the higher level. llvmpipe
happens to choose the lower one instead, at least in some cases.
On virtual heaps, SRV/UAV unbounded ranges are implemented using two
descriptor sets, one for buffers and another for textures, and this case
should be tested.
