Rearchitecting the d3dx DLLs

[Zebediah Figura (she/her)]

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.