Rearchitecting the d3dx DLLs

[Henri Verbeet]

On Wed, 23 Jun 2021 at 16:10, Matteo Bruni <matteo.mystral at gmail.com> wrote:
> On Tue, Jun 22, 2021 at 9:32 PM Zebediah Figura (she/her)
> <zfigura at codeweavers.com> wrote:
> > Personally I'm a strong proponent of option 2. I know Wine is very
> > reticent to add custom DLLs where not necessary, and I'm not sure I
> > understand why—maybe there are historic reasons for this?
> >
> > And if there are reasons we can't use a shared library, we could at
> > least use a static library.
>
> Yeah, a static library would be yet another option, although I'd
> really prefer if we could share code (on disk AND at runtime, it's
> really common to find games that have 2 or more d3dx9 DLLs mapped in
> their process).
>
Sure, but those application would have that problem on Windows too.

> > For the record, d3dx* is huge as-is. Each DLL is already large (for
> > 64-bit, 3 MB), and the sum total is the largest single chunk of the
> > system32 directory (62 MB out of 437 MB. For comparison, all of the
> > msvcrt modules together are 31 MB, and so is all of msvcp.) And then
> > compilation is very slow...
>
> Yes, absolutely. It's also very wasteful, we're recompiling basically
> the same code 20 times. It just doesn't feel right...
>
It does help improve my ccache stats.

> > 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.