Framebuffer fetch on Vulkan+Quest 2/3 (Custom SRP) and DXC shader compilation pipeline questions

[tame kraken]

Wondering if anyone knows much about this, I have a custom SRP with my own rendergraph+renderpass system (fully working with native vulkan render passes).
I want to basically do programmable blending by accessing the current pixel's color and modifying it in the shader. (What I want can't be done with traditional blending)

The documentation and forum posts are all over the place about this. They mostly seem to refer to reading the output of a previous renderpass subpass as an input attachment. I already have this working, however this isn't what I'm trying to do, as it requires additional subpasses and additional attachments which create more bins which I am trying to minimize.

I have tried setting an attachment as both an input and an output for a subpass but Unity gives me errors so I assume that's not the right approach.
Not sure if there's just some magical HLSL syntax I need? Eg for subpasses I am using "[[vk::input_attachment_index(0)]] SubpassInput <float3>hlslcc_fbinput_0;" etc. (Hardcoding directly because I don't want 1000 macros, and I'm not using any of Unity's builtin CG/HLSL libraries either because we have our own, and only care about a limited number of platforms)

I've tried looking at the HLSLcc a bit, but I think this isn't used for DXC compiler anyway, does anyone know the pipeline for going from DXC to Vulkan? Is any of Unity's custom shader compiler tech used or does it just use the generic Microsoft DXC compiler to emit SPIR-V which is then compiled to Vulkan using standard tools?

Their HLSLcc does a lot of random magic for things like multi-view rendering and framebuffer attachments by finding and replacing strings etc, which I've been able to reverse engineer, but not sure what the pipeline is for using DXC. DXC to SPIR-V seems to generate much nicer Vulkan shader code which is often a lot shorter, and I assume may bring some performance benefits, which is why we're using it. (Still in the process of profiling to confirm)

Thanks

(Please no questions about "why aren't you using URP/HDRP etc", only respond if you actually understand what I'm asking about)

[loud star]

You can't read and write to a render target in the same draw. It's a hard limitation of the hardware/current graphics pipeline conventions - not a unity thing.
Fragment shaders push pixel updates to the next blending stage, so there has to be a guarantee that the render target was not tampered before that.
The only resources thta can be both read and written are UAVs(unordered access view), but you can't use them as a render target at the same time. In fact I think you can only write to them in a compute shader.
And writing to uavs is usually slower than blending into a render target.

As for the compiler questions can't really say anything. The only thing I know is that unity is using a custom version of the hlsl compiler.

[tame kraken]

You can, it's called framebuffer fetch and exists on several mobile platforms and is mentioned in Unity's documentation, meta's documentation, qualcomm's documentation, the Open GL spec and several other places.

Respectfully this is why I said "only respond if you actually understand what I'm asking about"