Rearchitecting the d3dx DLLs

[Matteo Bruni]

On Wed, Jun 23, 2021 at 4:27 PM Henri Verbeet <hverbeet at gmail.com> wrote:
>
> 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.

True, but we are usually in a worse spot WRT address space usage and
if we can do something "better" than native I don't see why we
shouldn't.

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

LOL, yeah, except when it doesn't (see the #ifdefs).

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