D3D8 Software Vertex Processing

[Stefan Dösinger]

Hi,

Good work isolating the issue :-)

Am 2017-08-15 um 20:57 schrieb Jan Havran:
> How hard would be to fix it for D3D8 (and D3D9)?
It's not an evening task, but certainly doable. The feature has example
code in the dx8 and 9 sdk. Someone even started a patch and attached it
to bug 39057. MSDN documents the feature here:
https://msdn.microsoft.com/de-de/library/windows/desktop/bb174594(v=vs.85).aspx

I had a quick look at the patch attached to bugzilla. Here is a
non-exhaustive list of concernes I have:

*) The test should be extended to cover cases of conflicting pipeline
configuration, e.g. D3DRS_INDEXEDVERTEXBLENDENABLE is enabled but
D3DRS_VERTEXBLEND is not, or both states are enabled but no weight data
is contained in the vertices. The test doesn't test vertex declarations
and if it is indeed the case that only D3DDECLTYPE_UBYTE4 index values
are valid. The existing D3DFVF_LASTBETA_D3DCOLOR definition suggests
that at least D3DDECLTYPE_D3DCOLOR is valid too.

The answer to some of those issues may be "it depends on the driver", in
which case a comment describing the outcome is fine and the test doesn't
have to actively check the feature.

*) Porting the test to d3d8 and ddraw would be a good idea, especially
since the game you have is a d3d8 game. It shouldn't be too difficult to
adapt, and it can wait until the d3d9 version of the test is agreed on.

*) I am torn on its use of UBOs for the matrices. The 256 shader
constants (256 vec4's aka 1024 uniforms) of d3d9 GPUs should be enough
for 32 matrices (this leaves 128 constants for other parameters). Those
GPUs don't have UBOs anyway. I think d3d10 GPUs (necessary for UBO
support) advertise 1024 constants or more (4096 uniforms), which should
give you the 128 matrices you need for your game.

If however there are games that need the 255 matrices that SWVP offers
and there are still drivers that have less than 2048 old-style uniforms
you need a UBO codepath. If in addition there is no game that is happy
with <= 32 matrices you might as well drop the codepath for legacy uniforms.

*) For the UBO path glBufferSubData may be worth a try, or mapping the
buffer with GL_MAP_INVALIDATE_BUFFER_BIT and always re-uploading
everything. Doing a GL_WRITE_ONLY map like it currently does will stall
the pipeline.

*) I don't think it is necessary to run the test for SW, HW and mixed
VP, doing it once should be ok since the result appears to be the same
in all cases.

Am 2017-08-15 um 21:55 schrieb Jan Havran:
> Small update, value of MaxVertexBlendMatrixIndex in HWVP on both Windows
> and Wine is not real value from GetDeviceCaps, but, as Brchi told me,
> this function was hooked in VCStarter (that Vietcong community util) to
> set this variable to 126. Anyway, SWVP value should be real.
Why does VCStarter set the value to 126 when it's known to cause a
crash? I guess it is between a Rock (crash) and a hard place (broken
rendering because the real HWVP value is much smaller).

Fwiw, wined3d.dll and d3d9.dll can be compiled for Windows, so with
indexed blending support in Wine VCStarter could ship wined3d (under the
terms of the LGPLv2)