On 6/23/21 9:44 AM, Matteo Bruni wrote:
Incidentally, how much of d3dx can/should live in vkd3d-shader? Off the top of my head:
- D3DX{Assemble,Compile,Preprocess}Shader() obviously, but that's
already forwarding to d3dcompiler anyway. Also D3DXDisassembleShader() and ID3DXEffectCompiler::Compile{Effect,Shader}().
- The ID3DXConstantTable implementation probably shouldn't, but maybe
parse_ctab_constant_type() should? But given the extra translation it may not in fact save us any work.
Fragment linking? I don't know how fragment linking works.
Texture shaders? I don't know how texture shaders work.
d3dx_parse_effect()?
Anything else? I can't immediately think of anything else related to
shaders.
Also this. I didn't mention it explicitly but one could think of moving the bulk of d3dx over to vkd3d[-shader] (an option 3.1, if you will). I agree that, aside from some more shader stuff, most of it doesn't seem to be a good fit for vkd3d IMHO.
We wouldn't want to put it in libvkd3d-shader or libvkd3d, but I don't think there's any reason we couldn't e.g. introduce a libvkd3d-math library. That kind of thing would certainly be useful for doing source ports from Direct3D.
Also true. It would be preferable to have that available in PE format for d3dx though, to avoid the PE<->unix overhead. Which would make this a variant of option 2 with mostly the same pros and cons. Unless there is any reason we don't want to do that.
Yeah, this sounds right to me, we should be able to compile the whole thing as PE.