Reputation: 2869
In Metal when using the visibility result feature (by invoking setVisibilityResultMode
on a command encoder), I am using the MTLVisibilityResultModeBoolean
mode to get a boolean telling me if any fragments passed the visibility tests.
After wrestling with this for a bit, I noticed that I am not actually getting a boolean using this API. I seem to be getting a uint
counting the number of fragments (pixels??) that passed the visibility test. I'm also not sure about the length of this counter: is it 32-bit? 64-bit?
It actually seems like this is behaving like MTLVisibilityResultModeCounting
, but I am definitely specifying MTLVisibilityResultModeBoolean
.
Is this a Metal bug? I am worried it might be a driver bug on my laptop though it is happening in the same way on both GPUs on my MacBook Pro (both the Radeon Pro 460 and the Intel HD Graphics 530).
Here's how I am extracting the BOOL
:
uint32 *resultBuffer = [visibilityResultBuffer contents];
BOOL result = (*resultBuffer != 0);
This works correctly in my tests, but I am concerned that this might not work correctly on other GPUs/drivers since it doesn't seem to match the documentation. Any ideas anyone?
Upvotes: 2
Views: 363
Reputation: 90571
I believe it's a 64-bit value because of this part of the docs for the offset
parameter of -setVisibilityResultMode:offset:
:
Must be a multiple of 8 bytes.
That alignment would typically only be necessary for an 8-byte (64-bit) type. So, you should use uint64_t
rather than uint32_t
.
Given your code for fetching the value, I assume you're using an offset of 0, is that right? Otherwise, you're reading from the wrong place.
Upvotes: 1
Reputation: 31782
Per the documentation, this is working as expected:
In
MTLVisibilityResultModeBoolean
mode, when a sample passes, the device writes a nonzero value to the buffer. If no samples pass, the device writes zero.
Upvotes: 3