Repository navigation
feat(agc): render 4_4_4_4 UNORM color targets through packed R16_UINT exports - #8563
Conversation
|
Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
… exports CB_COLOR_INFO format 19 with UNORM and COMP_SWAP 2 lists A, B, G, R from the least significant bits. No Vulkan device is required to render into the 4-bit formats and NVIDIA exposes none of them as color attachments, so the target is an R16_UINT image and the pixel shader packs the exports into the guest layout, as the 10_11_11 target does. Writes of fewer than four components, blending, DCC and truncating rounding are refused. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…ed words Draws 32_ABGR and FP16_ABGR exports into a linear 4_4_4_4 target and checks every pixel against the guest layout (A in bits 3..0, B in 7..4, G in 11..8, R in 15..12), including NaN, negative, infinite, denormal and rounded values, and the pixels outside the scissor. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A CB resolve from a packed color target throws, so a 2-sample 4_4_4_4 target cannot be resolved by the color block. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
24be30c to
acdbc02
Compare
|
Run on AMD hardware. Host: Arch Linux, kernel 7.2.11, AMD Radeon RX 7900 GRE (RADV NAVI31), Mesa 26.2.5, GCC 16.2.1, Release,
|
…/agc-4-4-4-4-color-target Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…/agc-4-4-4-4-color-target Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
|
Checked the diff against every user of |
What
Draws can now render into 4-bit-per-channel (4_4_4_4) colour targets on GPUs that cannot attach that format. Arcade Game Zone uses one, and the RTX 4070 SUPER (driver 610.88) exposes none of the four Vulkan 4-bit formats as a colour attachment.
The target (CB_COLOR_INFO format 19, UNORM, COMP_SWAP 2) becomes an R16_UINT attachment, and the pixel shader packs its exports into the guest layout: A in bits 3..0, B in 7..4, G in 11..8 and R in 15..12. The 10_11_11 target already works this way. The layout is the one the PS5 SDK's Agc headers define: in
registerstructs.h,CxRenderTarget::Format::k4_4_4_4(0x4c, format 19 shifted by 2) has four 4-bit channels with X in bits 3..0, Y in 7..4, Z in 11..8 and W in 15..12, andCxRenderTarget::ChannelOrder::kReversed(0x1000,COMP_SWAP2 shifted by 11) maps A, B, G, R to channels 0 to 3;kRenderTargetChannelOrderReversedin the Gnmpconstants.hlists four channels as ABGR. The PS4 SDK 8.008 (kSurfaceFormat4_4_4_4, reversed channel order) and Mesa'sac_translate_colorswap, which programsSWAP_STD_REVforA4B4G4R4_UNORM, agree. These throw:Overlap: the open "support packed 16-bit storage images" fix adds the same two
Format4_4_4_4UNormbuffer-format cases toSpirvBufferFormat.cpp, at the same anchors. Whichever lands second drops those two lines, and the two PRs do not conflict in behaviour. Each works without the other, so neither depends on the other. No other open PR implements the same functions.Arcade Game Zone (PPSA19015) on
mainbf2c63f (committed 2026-10-19 20:52 UTC) stops after 13.9 s withAGC graphics: unsupported color format 19 number type 0 component swap 2. With this PR on that commit it stops after 14.5 s withAGC graphics: partial writes of a 4_4_4_4 unorm color target are unsupported. The draw it stops at writes only the top nibble, and the follow-up PR merges such writes. This PR alone does not get the title further.Tested
Windows 11 x64, GCC 15.2 (WinLibs), NVIDIA GeForce RTX 4070 SUPER, driver 610.88.
agc_driver_graphics(unit test) covers decode, export packing, the serializer round trip, shader validation and the refusals.agc_driver_packed_unorm4444_color_target_testsdraws 32_ABGR and FP16_ABGR exports into a linear target. The exports include NaN, negative, infinite, denormal and rounded values. It compares every pixel with the guest layout, including pixels outside the scissor. The expected words are hard-coded from that layout (golden values such as (1, 0, 0, 0) → 0xF000, (0, 0, 0, 1) → 0x000F and (1, 0.5, 0, 0.25) → 0xF804), not produced by the test's packer. Reversing the nibble order, swapping R and B, or moving A to the top nibble in the driver's packing makes it fail. It needs a Vulkan device and is skipped without one.mainthe target is refused at decode, so these tests fail there.Vulkan validation: I ran the same focused tests on
mainand on this branch, on the same machine and GPU, throughctest -VwithVK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation,ANYPS5_NO_SHADER_CACHE=1andANYPS5_REQUIRE_VULKAN=1. Neither log contains "was not found but was requested by env var". The 23 existing tests report the same VUID ids with the same counts on both:agc_driver_graphics,agc_shader_memory,request_serializerandagc_multisample_guest_accessThe new execution test reports only
VUID-VkPhysicalDeviceProperties2-pNext-pNextandVUID-VkDeviceCreateInfo-pNext-pNext. Every Vulkan test among them reports these onmaintoo: the layer is the Vulkan SDK 1.3.236 build, older than the 1.4 driver, and does not know the newer structures in those chains.Linux not tested.
Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)🤖 Generated with Claude Code