On Wed, 23 Jun 2021 at 16:10, Matteo Bruni matteo.mystral@gmail.com wrote:
On Tue, Jun 22, 2021 at 9:32 PM Zebediah Figura (she/her) zfigura@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.