Re: D3D: Implement vertex blending in drawStridedSlow
Claudio Ciccani wrote: > Il giorno lun, 26/01/2009 alle 12.12 +0100, Claudio Ciccani ha scritto: > >> Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto: >> >>> 2009/1/25 Claudio Ciccani >>> >>> The patch implements a software fallback for vertex blending >>> in >>> drawStridedSlow, fixing Bug #6955. >>> Although vertex blending is an old and outdated extension, >>> there are >>> still many applications(games) relying on it nowadays. This >>> because the >>> extension is generally supported by Direct3D, either directly >>> in >>> hardware (using vertex programs) or in software. >>> >>> >>> >>> >>> >>> This patch makes NOLF2 demo crashes. >>> >>> >>> Register >>> dump: >>> CS:0073 SS:007b DS:007b ES:007b FS:0033 >>> GS:003b >>> EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 >>> -RIZP1) >>> EAX:00ec1b28 EBX:7e6bbc54 ECX:014c >>> EDX: >>> ESI:0048 >>> EDI: >>> Stack >>> dump: >>> 0x0033f0b4: >>> 3f80 >>> 0x0033f0c4: 0033f110 7d05e000 7c03d008 >>> 7c7aa346 >>> 0x0033f0d4: 0003 7e6bc7a0 >>> 7e69ee95 >>> 0x0033f0e4: 7e69e648 0001 000c >>> 0010 >>> 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 >>> 00ebd44c >>> 0x0033f104: 00eba698 00ebd7a8 >>> 0007 >>> Backtrace: >>> >>> =>0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, >>> NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, >>> minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] >>> in wined3d (0x0033f1ec) >>> 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, >>> NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=>> available>, idxData=(nil), minIndex=0) >>> [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d >>> (0x0033f55c) >>> >>> 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive >>> +0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, >>> minIndex=0, NumVertices=24, startIndex=0, primCount=24) >>> [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) >>> 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive >>> +0x96(iface=, >>> PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, >>> startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] >>> in d3d8 >>> (0x0033f5fc) >>> 0x7e6095c7 drawStridedSlow+0x697 >>> [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds >>> 0x0(%ecx) >>> 307 m = >>> &stateBlock->transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : >>> 0))].u.m[0][0]; >>> Modules: >>> >> Really strange! Tested the patch against other games and it worked. >> With NOLF2 I'm getting a crash too, but at a different location: >> >> 1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4, >> NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2, >> idxData=0x3d871e0, minIndex=0) >> [/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d >> (0x) >> 0x7d2b3771: movl0x0(%ecx),%edx >> >> 540 for (texture = 0; tmp_tex_mask; tmp_tex_mask >>= 1, ++texture) >> >> >> >> >> >> >> >> >> >> >> I found that the reason of the crash was that VBOs were not removed when >> using drawStridedSlow for vertex blending. >> Attached is the modified patch, which doesn't make NOLF2 crash. >> >> Patches have to be submitted to Wine-patches. James McKenzie
Re: D3D: Implement vertex blending in drawStridedSlow
On Wed, Jan 28, 2009 at 04:44:44PM +0100, Henri Verbeet wrote: > 2009/1/28 Claudio Ciccani : >> 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. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgplgsG1lpCDm.pgp Description: PGP signature
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/28 Claudio Ciccani : > 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.
Re: D3D: Implement vertex blending in drawStridedSlow
Il giorno mer, 28/01/2009 alle 12.34 +0100, Henri Verbeet ha scritto: > 2009/1/28 Paul TBBle Hampson : > > 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. http://appdb.winehq.org/viewbugs.php?bug_id=6955
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/28 Paul TBBle Hampson : > 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.
Re: D3D: Implement vertex blending in drawStridedSlow
On Wed, Jan 28, 2009 at 09:46:23AM +0100, Henri Verbeet wrote: > 2009/1/28 Paul TBBle Hampson : >> 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. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpZOFCM3Lkfp.pgp Description: PGP signature
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/28 Paul TBBle Hampson : > 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).
Re: D3D: Implement vertex blending in drawStridedSlow
On Mon, Jan 26, 2009 at 12:19:32PM +0100, Henri Verbeet wrote: > 2009/1/26 Paul TBBle Hampson : >> On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote: >>> 2009/1/25 Claudio Ciccani : +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. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpc1CG7mpdKX.pgp Description: PGP signature
Re: Re: Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/26 Claudio Ciccani > I found that the reason of the crash was that VBOs were not removed when > using drawStridedSlow for vertex blending. > Attached is the modified patch, which doesn't make NOLF2 crash. > > > Il giorno lun, 26/01/2009 alle 12.12 +0100, Claudio Ciccani ha scritto: > > Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto: > > > > > > > > > 2009/1/25 Claudio Ciccani > > > > > > The patch implements a software fallback for vertex blending > > > in > > > drawStridedSlow, fixing Bug #6955. > > > Although vertex blending is an old and outdated extension, > > > there are > > > still many applications(games) relying on it nowadays. This > > > because the > > > extension is generally supported by Direct3D, either directly > > > in > > > hardware (using vertex programs) or in software. > > > > > > > > > > > > > > > > > > This patch makes NOLF2 demo crashes. > > > > > > > > > Register > > > dump: > > > CS:0073 SS:007b DS:007b ES:007b FS:0033 > > > GS:003b > > > EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 > > > -RIZP1) > > > EAX:00ec1b28 EBX:7e6bbc54 ECX:014c > > > EDX: > > > ESI:0048 > > > EDI: > > > Stack > > > dump: > > > 0x0033f0b4: > > > 3f80 > > > 0x0033f0c4: 0033f110 7d05e000 7c03d008 > > > 7c7aa346 > > > 0x0033f0d4: 0003 7e6bc7a0 > > > 7e69ee95 > > > 0x0033f0e4: 7e69e648 0001 000c > > > 0010 > > > 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 > > > 00ebd44c > > > 0x0033f104: 00eba698 00ebd7a8 > > > 0007 > > > Backtrace: > > > =>0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, > > > NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, > > > minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] > > > in wined3d (0x0033f1ec) > > > 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, > > > NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize= > > available>, idxData=(nil), minIndex=0) > > > [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d > > > (0x0033f55c) > > > 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive > > > +0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, > > > minIndex=0, NumVertices=24, startIndex=0, primCount=24) > > > [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) > > > 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive > > > +0x96(iface=, > > > PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, > > > startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] > > > in d3d8 > > > (0x0033f5fc) > > > 0x7e6095c7 drawStridedSlow+0x697 > > > [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds > > > 0x0(%ecx) > > > 307 m = > > > &stateBlock->transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : > > > 0))].u.m[0][0]; > > > Modules: > > > > Really strange! Tested the patch against other games and it worked. > > With NOLF2 I'm getting a crash too, but at a different location: > > > > 1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4, > > NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2, > > idxData=0x3d871e0, minIndex=0) > > [/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d > > (0x) > > 0x7d2b3771: movl0x0(%ecx),%edx > > > > 540 for (texture = 0; tmp_tex_mask; tmp_tex_mask >>= 1, ++texture) > > > > > > > > > > > > > -- > Claudio Ciccani > k...@users.sf.net > k...@directfb.org > http://directfb.org > Great, the patch works like a charm. I hope that it will bw accepted by D3D gurus and Alexandre . David
Re: Re: Re: D3D: Implement vertex blending in drawStridedSlow
I found that the reason of the crash was that VBOs were not removed when
using drawStridedSlow for vertex blending.
Attached is the modified patch, which doesn't make NOLF2 crash.
Il giorno lun, 26/01/2009 alle 12.12 +0100, Claudio Ciccani ha scritto:
> Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto:
> >
> >
> > 2009/1/25 Claudio Ciccani
> >
> > The patch implements a software fallback for vertex blending
> > in
> > drawStridedSlow, fixing Bug #6955.
> > Although vertex blending is an old and outdated extension,
> > there are
> > still many applications(games) relying on it nowadays. This
> > because the
> > extension is generally supported by Direct3D, either directly
> > in
> > hardware (using vertex programs) or in software.
> >
> >
> >
> >
> >
> > This patch makes NOLF2 demo crashes.
> >
> >
> > Register
> > dump:
> > CS:0073 SS:007b DS:007b ES:007b FS:0033
> > GS:003b
> > EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00
> > -RIZP1)
> > EAX:00ec1b28 EBX:7e6bbc54 ECX:014c
> > EDX:
> > ESI:0048
> > EDI:
> > Stack
> > dump:
> > 0x0033f0b4:
> > 3f80
> > 0x0033f0c4: 0033f110 7d05e000 7c03d008
> > 7c7aa346
> > 0x0033f0d4: 0003 7e6bc7a0
> > 7e69ee95
> > 0x0033f0e4: 7e69e648 0001 000c
> > 0010
> > 0x0033f0f4: 795a5f68 7d09c0ac 0002d008
> > 00ebd44c
> > 0x0033f104: 00eba698 00ebd7a8
> > 0007
> > Backtrace:
> >
> > =>0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c,
> > NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2,
> > minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307]
> > in wined3d (0x0033f1ec)
> > 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4,
> > NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize= > available>, idxData=(nil), minIndex=0)
> > [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d
> > (0x0033f55c)
> >
> > 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive
> > +0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST,
> > minIndex=0, NumVertices=24, startIndex=0, primCount=24)
> > [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc)
> > 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive
> > +0x96(iface=,
> > PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24,
> > startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419]
> > in d3d8
> > (0x0033f5fc)
> > 0x7e6095c7 drawStridedSlow+0x697
> > [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds
> > 0x0(%ecx)
> > 307 m =
> > &stateBlock->transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] :
> > 0))].u.m[0][0];
> > Modules:
>
> Really strange! Tested the patch against other games and it worked.
> With NOLF2 I'm getting a crash too, but at a different location:
>
> 1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4,
> NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2,
> idxData=0x3d871e0, minIndex=0)
> [/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d
> (0x)
> 0x7d2b3771: movl0x0(%ecx),%edx
>
> 540 for (texture = 0; tmp_tex_mask; tmp_tex_mask >>= 1, ++texture)
>
>
>
>
>
>
--
Claudio Ciccani
k...@users.sf.net
k...@directfb.org
http://directfb.org
diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c
index 478c216..7b2a010 100644
--- a/dlls/wined3d/directx.c
+++ b/dlls/wined3d/directx.c
@@ -3387,8 +3387,13 @@ static HRESULT WINAPI IWineD3DImpl_GetDeviceCaps(IWineD3D *iface, UINT Adapter,
pCaps->MaxUserClipPlanes = GL_LIMITS(clipplanes);
pCaps->MaxActiveLights = GL_LIMITS(lights);
-pCaps->MaxVertexBlendMatrices = GL_LIMITS(blends);
-pCaps->MaxVertexBlendMatrixIndex = 0;
+if (GL_SUPPORT(ARB_VERTEX_BLEND)) {
+pCaps->MaxVertexBlendMatrices= GL_LIMITS(blends);
+pCaps->MaxVertexBlendMatrixIndex = 0;
+} else {
+pCaps->MaxVertexBlendMatrices= 4;
+pCaps->MaxVertexBlendMatrixIn
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/25 Claudio Ciccani > > The patch implements a software fallback for vertex blending in > drawStridedSlow, fixing Bug #6955. > Although vertex blending is an old and outdated extension, there are > still many applications(games) relying on it nowadays. This because the > extension is generally supported by Direct3D, either directly in > hardware (using vertex programs) or in software. > This patch makes NOLF2 demo crashes. > > > Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 -RIZP1) EAX:00ec1b28 EBX:7e6bbc54 ECX:014c EDX: ESI:0048 EDI: Stack dump: 0x0033f0b4: 3f80 0x0033f0c4: 0033f110 7d05e000 7c03d008 7c7aa346 0x0033f0d4: 0003 7e6bc7a0 7e69ee95 0x0033f0e4: 7e69e648 0001 000c 0010 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 00ebd44c 0x0033f104: 00eba698 00ebd7a8 0007 Backtrace: =>0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d (0x0033f1ec) 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=, idxData=(nil), minIndex=0) [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d (0x0033f55c) 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive+0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, minIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive+0x96(iface=, PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] in d3d8 (0x0033f5fc) 0x7e6095c7 drawStridedSlow+0x697 [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds 0x0(%ecx) 307 m = &stateBlock->transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : 0))].u.m[0][0]; Modules:
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/26 Paul TBBle Hampson : > On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote: >> 2009/1/25 Claudio Ciccani : > >>> +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.
Re: Re: D3D: Implement vertex blending in drawStridedSlow
Il giorno dom, 25/01/2009 alle 23.19 +0100, David Adam ha scritto: > > > 2009/1/25 Claudio Ciccani > > The patch implements a software fallback for vertex blending > in > drawStridedSlow, fixing Bug #6955. > Although vertex blending is an old and outdated extension, > there are > still many applications(games) relying on it nowadays. This > because the > extension is generally supported by Direct3D, either directly > in > hardware (using vertex programs) or in software. > > > > > > This patch makes NOLF2 demo crashes. > > > Register > dump: > CS:0073 SS:007b DS:007b ES:007b FS:0033 > GS:003b > EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 > -RIZP1) > EAX:00ec1b28 EBX:7e6bbc54 ECX:014c > EDX: > ESI:0048 > EDI: > Stack > dump: > 0x0033f0b4: > 3f80 > 0x0033f0c4: 0033f110 7d05e000 7c03d008 > 7c7aa346 > 0x0033f0d4: 0003 7e6bc7a0 > 7e69ee95 > 0x0033f0e4: 7e69e648 0001 000c > 0010 > 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 > 00ebd44c > 0x0033f104: 00eba698 00ebd7a8 > 0007 > Backtrace: > > =>0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, > NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, > minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] > in wined3d (0x0033f1ec) > 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, > NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize= available>, idxData=(nil), minIndex=0) > [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d > (0x0033f55c) > > 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive > +0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, > minIndex=0, NumVertices=24, startIndex=0, primCount=24) > [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) > 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive > +0x96(iface=, > PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, > startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] > in d3d8 > (0x0033f5fc) > 0x7e6095c7 drawStridedSlow+0x697 > [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds > 0x0(%ecx) > 307 m = > &stateBlock->transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : > 0))].u.m[0][0]; > Modules: Really strange! Tested the patch against other games and it worked. With NOLF2 I'm getting a crash too, but at a different location: 1 0x7e6217ca drawPrimitive+0x112a(iface=0xec7660, PrimitiveType=4, NumPrimitives=18, numberOfVertices=20, StartIdx=0, idxSize=2, idxData=0x3d871e0, minIndex=0) [/home/klan/src/wine/dlls/wined3d/drawprim.c:540] in wined3d (0x) 0x7d2b3771: movl0x0(%ecx),%edx 540 for (texture = 0; tmp_tex_mask; tmp_tex_mask >>= 1, ++texture)
Re: D3D: Implement vertex blending in drawStridedSlow
On Mon, Jan 26, 2009 at 09:16:12AM +0100, Henri Verbeet wrote: > 2009/1/25 Claudio Ciccani : >> +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. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpEVVs3qKqpC.pgp Description: PGP signature
Re: D3D: Implement vertex blending in drawStridedSlow
2009/1/25 Claudio Ciccani : > > +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.
