12:31 Lynne: why is unified image layouts only advertised for rdna3?
12:31 Lynne: is it because of msaa?
12:38 mareko: Lynne: what do you mean by "unified"?
12:41 zmike: the vulkan extension
12:50 mareko: I see, it's likely because of DCC not supporting format reinterpretation via image views prior to rdna3 and requiring DCC decompression (layout transition)
12:55 glehmann: that's not the issue, we have to disable dcc there at image creation anyway
12:56 glehmann: but fmask is incompatible with unified layouts, so yes, MSAA is the issue on gfx10
12:57 glehmann: on gfx9 and older there are likely even more issues
13:10 mareko: fast clear might be another reason why unified layouts are not supported on gfx<11
13:12 Lynne: maybe the caps should have been more verbose for once than just *unified image layouts are supported (for !video)* and *unified image layouts are supported (for video)*
13:13 Lynne: dcc images not being supported as general is pretty obvious imo
13:14 glehmann: people already complain about vulkan having to many features
13:14 mareko: DCC should be supported well on gfx<11 with general except fast clears
13:15 mareko: the image view constraint is resolved at image creation
13:16 glehmann: I think fast clear is fine on gfx10 thanks to comp to single?
13:16 mareko: comp to single isn't that fast
13:16 Lynne: I'm just interested about it on gfx10 (since I only risked packing my 6900 going away)
13:17 mareko: there is likely future work to make comp-to-single faster
13:17 glehmann: mareko: isn't that all gfx11 has?
13:17 mareko: other than 0/1, yes
13:20 glehmann: dxvk assumes that unified layout is ok on gfx10 except for msaa fwiw
13:21 glehmann: vkd3d-proton has no choice because of the barrier model mismatches, so I think it always uses GENERAL anyway
13:21 mareko: I estimate we could make comp-to-single 4x faster on GDDR and 2x faster on DDR than it is now
13:23 mareko: unified is likely not the best for Z/S even on gfx11
13:25 glehmann: I was under the impression that for radv it makes no difference as long as the hw supports tc-compat htile?
13:25 mareko: we can get stronger Z/S compression if it's declared shader-incompatible and transfer-incompatible
13:26 mareko: tc-compat HTILE is a compromise
13:27 glehmann: ah right, I remember now: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/12414
13:27 mareko: tc-compat HTILE is optimal when shader or transfer access is needed, but the compression is slightly weaker
13:28 mareko: it also implies weaker HiZ
13:29 mareko: or rather the thing that's between HiZ and per-sample Z
13:30 glehmann: but radv doesn't base the decision to enable tc-compat htile on the image layout, only on the image usage
13:30 glehmann: so unified layout doesn't change anything