[RFC] Port of Stefan Dösinger's ARB_vertex_program fixed-function vertex pipeline replacement to 1.1.18
Hi.
I've rebased the arb_vertex_program ffp vertex pipeline patchset to 1.1.18.
This time I managed to get the fog correct, and all the d3d9 tests pass.
I also did some benchmarks this time in both 3DMark 2000 and 2001SE, and have attached the results. Generally there's a fairly large slowdown in the fixed-function code, particularly in 3DMark 2000. Some of 2001SE's tests appear unaffected, which isn't surprising since some of them are D3D8 shader-based tests, not FFP tests. The fillrate tests appeared unaffected too.
This is on a Core 2 Duo machine with an nVidia 8600M GT, if it makes a difference.
I wasn't watching too carefully, but I did't notice any visual artefacts in the tests.
As I understand it, Stefan's not got the time or inclination to work on this at the moment, and my knowledge of ARB vertex programs and the D3D fixed-function pipeline is rather limited, so in all likelihood getting this going faster will require someone to get stuck into gen_arbvp_ffp_shader and its callees in arb_program_shader.c and get it feature-complete and sufficiently optimised to be on-par with the ffp-based vertex pipeline. I guess a GLSL-based vertex pipeline might be desired too...?
Then people can add features such as vertex-blending, and get No One Lives Forever 2 and bug #6955 cleared up.
As before, the code is entirely Stefans, but bugs may certainly have been introduced by me. Since it now passes the unit tests, it might be reasonable to actually consider this for mainline, with a registry key or env var to force a specific choice of fixed-function vertex pipeline.
Am Sonntag, 29. März 2009 06:39:38 schrieb Paul TBBle Hampson:
As before, the code is entirely Stefans, but bugs may certainly have been introduced by me. Since it now passes the unit tests, it might be reasonable to actually consider this for mainline, with a registry key or env var to force a specific choice of fixed-function vertex pipeline.
Its probably a reasonable goal to get this in, but disabled by default until the performance problems are resolved(I guess that lighting is the main bottleneck). That will make it easier for others to implement vertex blending in a proper fashion.
That said, I don't really remember the state of the code, and if it is clean enough to be committed.
2009/3/29 Paul TBBle Hampson Paul.Hampson@pobox.com:
fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexSubImage2D @ ../../../dlls/wined3d/surface.c / 349
These are a problem, I think.
2009/3/29 Stefan Dösinger stefandoesinger@gmx.at:
Its probably a reasonable goal to get this in, but disabled by default until the performance problems are resolved(I guess that lighting is the main bottleneck). That will make it easier for others to implement vertex blending in a proper fashion.
That said, I don't really remember the state of the code, and if it is clean enough to be committed.
It will need some work, but I think getting it merged is a good idea.
On Sun, Mar 29, 2009 at 02:23:42PM +0200, Henri Verbeet wrote:
2009/3/29 Paul TBBle Hampson Paul.Hampson@pobox.com:
fixme:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glTexSubImage2D @ ../../../dlls/wined3d/surface.c / 349
These are a problem, I think.
Co-incidentally, I just saw some of these errors from an unpatched 1.1.17 build in Warhammer Online, which is a D3D9X-based game.
I'll look into it, but I'm actually having trouble getting 3DMark2000 to do it again, I suspect it's just me running low on video ram, since I'd just had an error to that effect in Warhammer Online when I saw this error in that.
2009/3/29 Stefan Dösinger stefandoesinger@gmx.at:
Its probably a reasonable goal to get this in, but disabled by default until the performance problems are resolved(I guess that lighting is the main bottleneck). That will make it easier for others to implement vertex blending in a proper fashion.
That said, I don't really remember the state of the code, and if it is clean enough to be committed.
It will need some work, but I think getting it merged is a good idea.
Any suggestions on the work that is needed? Apart from the above GL_INVALID_VALUE, I'm unaware of any failures apart from it being slow.
I guess a registry entry check in select_vertex_implementation would be a good start.
2009/3/30 Paul TBBle Hampson Paul.Hampson@pobox.com:
Any suggestions on the work that is needed? Apart from the above GL_INVALID_VALUE, I'm unaware of any failures apart from it being slow.
I'd need to do a proper review, but eg. "can_convert_d3dcolor" is something that needs a bit more thought to be properly integrated. Properly handling GL_VERTEX_PROGRAM_POINT_SIZE_ARB looks like another, although that should probably be done separately from this patch set in the first place (that's essentially bug 8826).
-
Henri Verbeet -
Paul TBBle Hampson -
Stefan Dösinger