I am working on vertex blending support for WineD3D. First I implemented it using GL_ARB_vertex_blend in hardware, an extension that is unfortunately only supported by ati cards, and not nvidia. So I took Frank Richter's started software emulation for vertex blending, with that it works everywhere.
The question is wether we should report support for this feature in our d3d caps. Because it is software emulated it forces wined3d into the drawStridedSlow path which is, well, slow. Enabling this may cause a game to choose this slower render path over something else, like vertex shaders. On the other hand it can get applications run that wouldn't work without this feature.
For vertex blending it doesn't matter much. Its hardly used, and all games using it provide a vertex shader path too and prefer it(exception are the dx sdk demos). The other alternative the apps have is to either disable the feature entirely, thus have lower graphics quality, or calculate it themselves, which won't be slower than wined3d doing it. So I think we should advertize vertex blending, but the general question remains.
What do you think?
PS: Ideally we'd have a vertex pipeline replacement in form of a vertex shader, but that wouldn't invalidate the point of this since not all cards support vertex shaders. (And I personally dislike the idea of a pipeline replacement for this reason).
On 27/04/07, Stefan Dösinger stefan@codeweavers.com wrote:
I am working on vertex blending support for WineD3D. First I implemented it using GL_ARB_vertex_blend in hardware, an extension that is unfortunately only supported by ati cards, and not nvidia. So I took Frank Richter's started software emulation for vertex blending, with that it works everywhere.
The question is wether we should report support for this feature in our d3d caps. Because it is software emulated it forces wined3d into the drawStridedSlow path which is, well, slow. Enabling this may cause a game to choose this slower render path over something else, like vertex shaders. On the other hand it can get applications run that wouldn't work without this feature.
For vertex blending it doesn't matter much. Its hardly used, and all games using it provide a vertex shader path too and prefer it(exception are the dx sdk demos). The other alternative the apps have is to either disable the feature entirely, thus have lower graphics quality, or calculate it themselves, which won't be slower than wined3d doing it. So I think we should advertize vertex blending, but the general question remains.
What do you think?
PS: Ideally we'd have a vertex pipeline replacement in form of a vertex shader, but that wouldn't invalidate the point of this since not all cards support vertex shaders. (And I personally dislike the idea of a pipeline replacement for this reason).
I'd rather not report caps we don't properly support, for the reasons you just mentioned. As for the pipeline replacement, I don't really see the issue. There are lots of things that older cards don't support. If it provides advantages for newer cards, I don't think that should be held back because older cards don't support it.
Am Freitag 27 April 2007 09:02 schrieb H. Verbeet:
On 27/04/07, Stefan Dösinger stefan@codeweavers.com wrote:
I am working on vertex blending support for WineD3D. First I implemented it using GL_ARB_vertex_blend in hardware, an extension that is unfortunately only supported by ati cards, and not nvidia. So I took Frank Richter's started software emulation for vertex blending, with that it works everywhere.
The question is wether we should report support for this feature in our d3d caps. Because it is software emulated it forces wined3d into the drawStridedSlow path which is, well, slow. Enabling this may cause a game to choose this slower render path over something else, like vertex shaders. On the other hand it can get applications run that wouldn't work without this feature.
For vertex blending it doesn't matter much. Its hardly used, and all games using it provide a vertex shader path too and prefer it(exception are the dx sdk demos). The other alternative the apps have is to either disable the feature entirely, thus have lower graphics quality, or calculate it themselves, which won't be slower than wined3d doing it. So I think we should advertize vertex blending, but the general question remains.
What do you think?
PS: Ideally we'd have a vertex pipeline replacement in form of a vertex shader, but that wouldn't invalidate the point of this since not all cards support vertex shaders. (And I personally dislike the idea of a pipeline replacement for this reason).
I'd rather not report caps we don't properly support, for the reasons you just mentioned. As for the pipeline replacement, I don't really see the issue. There are lots of things that older cards don't support. If it provides advantages for newer cards, I don't think that should be held back because older cards don't support it.
I take that "It won't be slower than the app emulating it" back. The skinnedmesh demo runs twice as fast with the apps "software skinning" than with wined3d's emulation. I have to investigate why that happens, the mesh doesn't look worse with the sw skinning.
I think I'll add a registry key for this. I do not think we should take users the possibility to use existing and working features which may get their applications running. This key does not enable / disable vertex blending, just the caps. Thus if an app doesn't check the caps properly it will get vertex blending even if this key is disabled(and a warning printed asking the user to enable vertex shaders)
-
H. Verbeet -
Stefan Dösinger