On Wed Nov 2 05:57:57 2022 +0000, Conor McCarthy wrote:
After reviewing the possibilities, I think converting TPF to the DXIL-like IR is a far better option in the long run, at least for SM6 (I'm not sure how this would impact HLSL work). For reference, Microsoft has released code for such a conversion. This option would mean having an extra SM6 SPIR-V backend for a while at least, until the conversion code is written. Using the current SPIR-V backend means converting DXIL to something which pretends to be TPF-like but actually isn't. For one thing it would have poorer performance. For example, in the new backend, loading a source mostly involves simply reading value->spirv_id, except when a constant must be emitted which only happens once. The existing backend has a significant overhead in vkd3d_dxbc_compiler_emit_load_reg(). A similar situation occurs for storing dst. Plus we'd have the inital overhead of DXIL conversion. In future we expect more and more use of SM 6, and if we encounter performance issues in the existing backend they may be hard to solve. Inputs/outputs are another issue. Private variables are unnecessary in the new backend, and overall the I/O code is relatively simple compared to the existing functions. Making I/O loads/stores work through the existing code is a problem I'd rather not deal with. Tessellation is another complication. There are no shader phase declarations. If we want DXIL trace output to look similar to that from 'dxc -dumpbin' we need a separate trace backend. I'd argue this is more useful for debugging that emitting something very similar to the current TPF trace.
Adding a register type VKD3DSPR_SSA may work reasonably well, combined with separate instructions for SM6 input/output and tessellation. I'd need to write enough code to compile a simple shader to get an idea of how it looks. The question of what to trace remains though.