mirror of
https://github.com/boykopovar/AnyPS5.git
synced 2026-10-22 00:22:57 -05:00
8_8_8_8 and 16_16_16_16 targets with COMP_SWAP 2 or 3 keep the exported alpha in their first channel and red or blue in their fourth, so a plain Vulkan blend would run the alpha equation on a color channel. Such draws threw "blending into a color target with a reversed component order is not implemented" (Gran Turismo 7, #4782). The AMD SI and CIK register references describe CB_TARGET_MASK in the order of components after blending and before COMP_SWAP is applied, and RADV programs CB_BLENDn_CONTROL without regard to the swap while it renders R4G4B4A4, B4G4R4A4, R5G5B5A1 and B5G5R5A1 through SWAP_STD_REV and SWAP_ALT_REV and passes the CTS blend tests on Navi10. The color block is therefore taken to blend in export order: the alpha equation and source-alpha factors use the exported alpha and the destination alpha is the first channel. TranslateReversedBlend keeps the factor pairs Vulkan applies per channel in the pipeline. Other source factors are computed by the pixel shader from its MRT0 export (clamped for UNORM targets, as BLEND_CLAMP says) and handed to the blend as a dual-source second color, which the fragment output post-pass adds at location 0 index 1; when both positions need it, the export is premultiplied by its source factor. The code is a pipeline specialization, serialized in request version 26, and stays out of the prepared shader key. sRGB, SNORM and integer targets, constant and second-source factors, destination alpha in the color equation, destination factors the two equations do not share, different color and alpha operations, MIN or MAX with factors other than ONE, other color exports when the shader computes factors, and devices without dualSrcBlend still throw, now with the blend control, mapping and format in the message. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>