agc_driver_guest_memory_lifetime_converted runs a relinked fixture that loads the ASan builds of libkernel, libc and libSceAgcDriver, so the ASan runtime is not the first library and ASan stops with 'ASan runtime does not come first in initial library list'. Set verify_asan_link_order=0 for it, as loadexec_arguments already does for its converted host. With it the test passes in an ANYPS5_ENABLE_ASAN build on Linux; other builds are unaffected.
The I/J reads take the BaryCoordSmooth input, but gl_FragCoord was declared
only for the offset kinds, so its w was read as the constant 0 and the
fragment function never read [[position]]; Apple GPUs then return the
weights unnormalized. Declare it with the built-in, and select on
gl_FragCoord.w > 0, which a compiler cannot fold as it can
min(b, b + |w|).
MoltenVK exposes VK_KHR_fragment_shader_barycentric but its MSL step
rejects PerVertexKHR, so the extension is disabled there and a pixel
shader whose I/J VGPRs outlive their v_interp_p1/p2 pairs takes the
generated barycentric stages, which accept only triangle lists without
primitive restart on a device without geometry shaders.
A new target flag, fragmentBarycentricBuiltins, enables the extension
for its built-ins only. The host interpolation check then keeps the
leftover I/J reads (all perspective or all linear, at the fragment's
default position) and reads them from BaryCoordKHR or
BaryCoordNoPerspKHR, while the interpolated attributes stay hardware
varyings. Raw vertex parameters and I/J at an offset or a sample
position still take the generated stages. Apple GPUs return
unnormalized perspective weights unless the fragment function reads
[[position]], so each perspective read keeps a neutral use of
gl_FragCoord.w, loaded as a float. Devices with the full extension are
unaffected; the request serialization moves to version 45.
Co-authored-by: yripper <[email protected]>
asinh_nid_postfix called the host libm's asinh. It now follows the branches and
thresholds of FreeBSD msun's s_asinh.c (release/11.4.0): below 2^-28 it returns x,
up to |x| = 2 it uses log1p, up to 2^28 log(2|x| + 1/(sqrt(x*x+1)+|x|)) and above
that log(|x|) + ln2. Up to |x| = 2 the results are bit-identical to msun; above 2
they depend on the host log this file still uses.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
StorageTwin asserts that a storage access promotes the rendered target
to a new image. On a device that writes the guest sample order back
(MayReorderSamples with a storage format, such as lavapipe with its 1x1
sample-location grid) the target is born storable, so the storage view
is the rendered image and the case fails with "MSAA storage promotion
kept the rendered image", the same reason StorageRemap failed. Expect
the same image there, and a new one everywhere else.
A device with programmable sample locations but only a 1x1 location grid (for example lavapipe) creates its multisampled color targets with storage usage from the start, so the guest sample order can be written back. MultisampleTargetStorageView then returns that already-storable image and makeStorable is a no-op, so there is no promotion allocation to retire and the generation does not change. StorageRemap asserted the opposite and failed deterministically with "MSAA storage promotion did not retain its source image".
Skip StorageRemap on such devices, mirroring OrderRemap, which already runs only there. The born-storable targets lifetime stays covered by OrderRemap; StorageRemap keeps covering the promotion path on devices whose MSAA targets are not born storable (for example NVIDIA, whose 4x grid is 2x2).
Dean Galvin