2009/1/25 Claudio Ciccani klan@users.sf.net:
- WORD vertexBlendSW : 1; /* vertexBlend software fallback used */
I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding.
On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote:
2009/1/25 Claudio Ciccani klan@users.sf.net:
- WORD vertexBlendSW : 1; /* vertexBlend software fallback used */
I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding.
I can't speak towards the bitfield part, but implementing vertex blending in software will magically make a few games (two that I know of, Warhammer Online and Everquest) work without patching, and without passing through drawStridedSlow.
This is because they don't actually use the vertex blending, but produce unrecognised (by Wine) vertex data if the capability isn't there.
2009/1/26 Paul TBBle Hampson Paul.Hampson@pobox.com:
On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote:
2009/1/25 Claudio Ciccani klan@users.sf.net:
- WORD vertexBlendSW : 1; /* vertexBlend software fallback used */
I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding.
I can't speak towards the bitfield part, but implementing vertex blending in software will magically make a few games (two that I know of, Warhammer Online and Everquest) work without patching, and without passing through drawStridedSlow.
Sure, but so does just faking the device caps.
On Mon, Jan 26, 2009 at 12:19:32PM +0100, Henri Verbeet wrote:
2009/1/26 Paul TBBle Hampson Paul.Hampson@pobox.com:
On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote:
2009/1/25 Claudio Ciccani klan@users.sf.net:
- WORD vertexBlendSW : 1; /* vertexBlend software fallback used */
I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding.
I can't speak towards the bitfield part, but implementing vertex blending in software will magically make a few games (two that I know of, Warhammer Online and Everquest) work without patching, and without passing through drawStridedSlow.
Sure, but so does just faking the device caps.
I don't see that as having a chance of making it into the Wine tree.
This patch, on the other hand, isn't actually a nasty case-specific hack.
2009/1/28 Paul TBBle Hampson Paul.Hampson@pobox.com:
On Mon, Jan 26, 2009 at 12:19:32PM +0100, Henri Verbeet wrote:
Sure, but so does just faking the device caps.
I don't see that as having a chance of making it into the Wine tree.
Indeed. However, it does mean that an important part of this patch isn't used by those applications, which makes them unsuitable for testing.
This patch, on the other hand, isn't actually a nasty case-specific hack.
It isn't, but I've yet to hear a reason why it's a better approach than using vertex shaders. (And neither has the author adressed my comment about the bitfield).
On Wed, Jan 28, 2009 at 09:46:23AM +0100, Henri Verbeet wrote:
2009/1/28 Paul TBBle Hampson Paul.Hampson@pobox.com:
On Mon, Jan 26, 2009 at 12:19:32PM +0100, Henri Verbeet wrote:
Sure, but so does just faking the device caps.
I don't see that as having a chance of making it into the Wine tree.
Indeed. However, it does mean that an important part of this patch isn't used by those applications, which makes them unsuitable for testing.
Indeed. I probably should have been clearer about that:
It _happens_ to fix rendering in certain games, one of which I happen to be the AppDB maintainer for. The original bug report the patch's associated with is for a game that actually _uses_ vertex blending, which I have not tested, but others in this thread have. (Conveniently, there's a demo available)
This patch, on the other hand, isn't actually a nasty case-specific hack.
It isn't, but I've yet to hear a reason why it's a better approach than using vertex shaders. (And neither has the author adressed my comment about the bitfield).
The only position I have on this is that this code exists and if the vertex shader code exists, I am unaware of it. The last comment I thought I read regarding vertex shaders was that they had produced a marked speed decrease (in my thread late last year about this issue) but on reflection, I may have conflated two things here.
You're suggesting in effect a specialised vertex shader that can just perform this matrix blending, rather than a full shader-based FFP, right?
I'd have a poke at that. So far I've not had any luck wrapping my head around that side of wined3d, as the time I've spent looking at this has been under the assumption (based on the TODOs in the code) that the correct solution is to implement this in drawStridedSlow.
If I understand, the software-only wined3d backend is dead and gone, so doing this with vertex shaders would just involve taking alternate paths in most of the places that check/use ARB_Vertex_Blend, and providing the blend matrices to a vertex shader which the current FFP implementation would feed into? (Or something like that... My lack of knowledge is quite visible here, I suspect)
Any pointers or hints would be appreciated.
2009/1/28 Paul TBBle Hampson Paul.Hampson@pobox.com:
The only position I have on this is that this code exists and if the vertex shader code exists, I am unaware of it. The last comment I thought I read regarding vertex shaders was that they had produced a marked speed decrease (in my thread late last year about this issue) but on reflection, I may have conflated two things here.
Stefan implemented shader based fixed function vertex processing a while ago. It does have performance issues, but I think it should be possible to fix those.
You're suggesting in effect a specialised vertex shader that can just perform this matrix blending, rather than a full shader-based FFP, right?
It's not quite that easy, since we need to handle stuff like lighting and texcoord generation as well. However, we do need shader based fixed function vertex processing for things like specular alpha fog, certain combinations of material tracking and drawing pre-transformed vertices. My argument is essentially that if we're going to have shader based fixed function vertex processing anyway, that's where we should implement vertex blending, not as another drawStridedSlow() fallback.
If I understand, the software-only wined3d backend is dead and gone, so
Slightly OT, but we might need to implement software shaders at some point, although that has a rather low priority right now. Would be interesting to see if we could use Mesa swrast for that.
Il giorno mer, 28/01/2009 alle 12.34 +0100, Henri Verbeet ha scritto:
2009/1/28 Paul TBBle Hampson Paul.Hampson@pobox.com:
The only position I have on this is that this code exists and if the vertex shader code exists, I am unaware of it. The last comment I thought I read regarding vertex shaders was that they had produced a marked speed decrease (in my thread late last year about this issue) but on reflection, I may have conflated two things here.
Stefan implemented shader based fixed function vertex processing a while ago. It does have performance issues, but I think it should be possible to fix those.
You're suggesting in effect a specialised vertex shader that can just perform this matrix blending, rather than a full shader-based FFP, right?
It's not quite that easy, since we need to handle stuff like lighting and texcoord generation as well. However, we do need shader based fixed function vertex processing for things like specular alpha fog, certain combinations of material tracking and drawing pre-transformed vertices. My argument is essentially that if we're going to have shader based fixed function vertex processing anyway, that's where we should implement vertex blending, not as another drawStridedSlow() fallback.
Why not both? I mean, you could implement a hardware based vertex blending routine using a vertex shader and keep the software vertex blending routine in case vertex programs are not supported by underlying hardware. Actually this is what the patch does: fall back to software vertex blending when hardware vertex blending is not supported.
If I understand, the software-only wined3d backend is dead and gone, so
Slightly OT, but we might need to implement software shaders at some point, although that has a rather low priority right now. Would be interesting to see if we could use Mesa swrast for that.
Implementing shaders in software would be terribly slow. Doing vertex blending in software instead doesn't have a relevant impact on the performance side.
Honestly I think that we have been waiting too much for a fix to this bug. There are many games in the AppDB that could go "gold" with this patch.
2009/1/28 Claudio Ciccani klan@users.sf.net:
Why not both?
It doesn't really work that way, you have to justify adding stuff.
I mean, you could implement a hardware based vertex blending routine using a vertex shader and keep the software vertex blending routine in case vertex programs are not supported by underlying hardware. Actually this is what the patch does: fall back to software vertex blending when hardware vertex blending is not supported.
I'm fairly certain there aren't a whole lot of cards that don't support either ARB_vertex_blend or vertex shaders, but do support vertex blending on Windows.
If I understand, the software-only wined3d backend is dead and gone, so
Slightly OT, but we might need to implement software shaders at some point, although that has a rather low priority right now. Would be interesting to see if we could use Mesa swrast for that.
Implementing shaders in software would be terribly slow.
Sure, but that's not a problem, applications that create software shaders are probably aware of that. Note that this would be for software shaders as exposed by d3d, not a software implementation of hardware shaders. We currently run software shaders in hardware as well, but that imposes some limits on eg. the amount of available constants. This is unrelated to vertex blending.
On Wed, Jan 28, 2009 at 04:44:44PM +0100, Henri Verbeet wrote:
2009/1/28 Claudio Ciccani klan@users.sf.net:
I mean, you could implement a hardware based vertex blending routine using a vertex shader and keep the software vertex blending routine in case vertex programs are not supported by underlying hardware. Actually this is what the patch does: fall back to software vertex blending when hardware vertex blending is not supported.
I'm fairly certain there aren't a whole lot of cards that don't support either ARB_vertex_blend or vertex shaders, but do support vertex blending on Windows.
The other problem that results in is that the D3DX functions that check for vertex blending support produce vertex buffers that Wine doesn't understand if that support is absent.
This of course is actually an issue elsewhere (ie someone's gotta work out what the vertex element means and implement it, I guess) but it's the reason that the capabilities hack is floating around.
According to a website I forget the location of, it's only the Intel on-board graphics cards that don't claim to be able to do vertex blending with 4 matrices under D3D9.
I thought it was suggested here a while ago that DirectX9 itself or the card driver implements vertex blending if the card doesn't support it in hardware. I presume it does this with a shader.
-
Claudio Ciccani -
Henri Verbeet -
Paul TBBle Hampson