On Wed, 11 Aug 2021 at 18:08, Jan Sikorski jsikorski@codeweavers.com wrote:
On 11 Aug 2021, at 14:25, Henri Verbeet hverbeet@gmail.com wrote:
I think we have a number of options, each with their advantages and disadvantages:
I’m generally partial to just doing what needs to be done and skipping the higher level machinery, even if that’s a bit more implementation work. With the first approach I’d be worried about being too slow. The state tweaking sound adventurous, but yeah, maybe it’s fine for compute.. For the direct option, I’m not quite sure what would the preferred way of talking to the shader backend be - are you thinking a new backend operation that takes the byte code with extra info and returns a VkShaderModule (through some opaque integer that gets cast)? Going further, I wonder if it's preferable to just provide SPIR-V up front and skip the shader translation step too?
Something along those lines, yes.
I don't think we want to put compiled SPIR-V in the source. We don't actually want to put D3D bytecode in there either, but hopefully we'll actually have a HLSL compiler one of these days, and then we'll be able to just generate HLSL.