Nine doesn't support Software Vertex Processing

[axeldavy]

Nine doesn't implement support for Software Vertex Processing.

#91

[axeldavy]

I found some games that need the feature:

Tron 2.0 has glitches (it has less on wine ogl) because the sw processing enables more constants, and we don't.
The sims2 has a lot of issues (see the wine bug report about it, even wine doesn't have it working)

[axeldavy]

About sw rendering:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb147296(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/bb172925(v=vs.85).aspx
state D3DRS_CLIPPING does have impact.

[axeldavy]

So according to the tests, it indicates that when in mixed mode, everything has the extended software processing limitations (you can set more constants, create shaders with more constants, etc), but eventually it should complain at draw call time if you draw with hw and the wrong limitations.

It makes sense for speed to use hw to emulate software vertex processing (because hw can have more constants now).

For ProcessVertices, it is likely better to do really sw processing (to avoid glFinish the hw rendering).
To begin the implementation, it is probably better to start using hw for that as well.

Here is what I think needs to be done:
. Add a flag for sw vs hw limitations for the vs shader. If we detect illegal things for hw, we compile first the "sw" version, instead of the sw version. The difference between "sw" and "hw" will be how the constant buffers are maintained.
. Everytime we use ProcessVertices with a new output buffer combination, we assign a new number to the combination. Use in the vs shader key a few bits to put the 'count' of the combination assigned (the streamout description needs to be provided at compilation). 0 means not streamout.
. Put in the device structure info about whether we are in mixed mode or not
. Return error if draw call with "hw" on, but using illegal constraints.
. Load the correct constant buffers for hw vs sw mode for the vs shader.

I think with these changes, the patches to add the target swvp support should be minimal. Some features will be missing (the fancy clipping features). We will have to consider using real sw for ProcessVertices.

[axeldavy]

software vertex processing is partially implemented now.

Not yet implemented:
. Allows up to 255 blend matrices in ff
. ff and vs 2 shaders in ProcessVertices
. Swvp requires textures to be in the SCRATCH pool. (and thus supports all formats)