D3D8 Software Vertex Processing

[Jan Havran]

Hello again!


On 16.8.2017 11:38, Stefan Dösinger wrote:
> 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 did not know about this patch. I tested it and it works!

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

The original game uses d3d8, yes. But there exist community
util (made by Brchi), which converts D3D8 calls into D3D9, so it would
be nice to have it in both d3d8 and d3d9, but it is not required.

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

The game will not crash with 128 matrices, yes, but it is a question
if it will be rendered correctly. Maybe dump question, I do not understand
D3D much.

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

Hmm, sounds kinda difficult :)

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

I am not sure, but I was told that there were some problems with default 
HWVP
value.

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

Hmm, interesting, thx for info. I will let him know.

Anyway, it is nice to see that the sollution (even not in the git at the 
moment)
was found exactly 10 years after reporting bug :)

Thank you very much for your help, I will keep watching updates of patch 
from #39057