These system values are bound to the same allocation rules as other
semantics: they can share registers with other semantics with the same
interpolation mode and they prefer forming shorter writemasks. However,
for some reason, these don't allow further semantics to share the same
register once allocated, except among themselves.
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.
I have to admit I'm not even sure of why most of those got marked
as todo in the first place. Running again now tests on commit
dff7c0e7b8 doesn't show all those
failures.
Using ok() may result in todo's succeeding when create_shader_stage()
succeeds, but vkCreateGraphicsPipelines() fails. There's not much point
in using ok() here in the first place though, because ultimately the
draw operation is going to fail when shader compilation failed.
