Only use D3DLOCK_DISCARD if dynamic memory (was Re: d3dx9: CloneMesh test and improvements)

[Michael Mc Donnell]

On Fri, Aug 19, 2011 at 2:20 PM, Stefan Dösinger <stefandoesinger at gmx.at> wrote:
> Am 19.08.2011 um 14:04 schrieb Michael Mc Donnell:
>> Ok I see that in dlls/d3d9/tests/buffers.c. So it will fail to lock on
>> Win7 if D3DLOCK_DISCARD is specified and the vertex buffer wasn't
>> created with D3DUSAGE_DYNAMIC?
> Yes, unless Microsoft changed this again.
>
>> Am I correct in D3DLOCK_DISCARD makes a copy of the vertex buffer so
>> that the video card can keep reading the old one, and the old vertex
>> buffer memory is released after the video card releases its lock [1]?
> Sort of. It doesn't copy the old data, it just gives you a fresh, uninitialized block of memory. So if you read from the pointer you get from a DISCARD lock you'll get garbage.
>
>> In that case it does not make sense to use D3DLOCK_DISCARD at all in
>> CloneMesh, as the video card has not begun to use the new vertex
>> buffer, and it will just add memory overhead. The easiest fix would be
>> to just pass 0 instead of D3DLOCK_DISCARD. I've done that in the
>> updated patch.
> Right, the buffer is newly created in CloneMesh. Just not using DISCARD is the best fix then.
>
>>> I noticed a few more D3DLOCK_DISCARD locks in the mesh.c code.
>>
>> I guess the other methods should check the mesh options for
>> D3DXMESH_DYNAMIC, D3DXMESH_VB_DYNAMIC, and D3DXMESH_IB_DYNAMIC [2]
>> before using D3DLOCK_DISCARD? I'll write patches for those.
> Most likely yes. I haven't looked at the details. If the buffer is new in those situations as well just don't pass any flags, otherwise pass DISCARD if you lock a dynamic buffer and are going to rewrite the entire buffer contents.

All of the places with D3DLOCK_DISCARD in mesh.c were working on newly
created meshes or vertex buffers, so they should all pass 0. I've
attached patches for it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-d3dx9-Use-0-instead-of-D3DLOCK_DISCARD-in-OptimizeIn.patch
Type: text/x-patch
Size: 1431 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110819/bc730efd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-d3dx9-Use-0-instead-of-D3DLOCK_DISCARD-in-load_skin_.patch
Type: text/x-patch
Size: 1921 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110819/bc730efd/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-d3dx9-Use-0-instead-of-D3DLOCK_DISCARD-in-D3DXLoadMe.patch
Type: text/x-patch
Size: 1985 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110819/bc730efd/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-d3dx9-Use-0-instead-of-D3DLOCK_DISCARD-in-D3DXCreate.patch
Type: text/x-patch
Size: 1105 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110819/bc730efd/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-d3dx9-Use-0-instead-of-D3DLOCK_DISCARD-in-D3DXCreate.patch
Type: text/x-patch
Size: 1131 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110819/bc730efd/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-d3dx9-Use-0-instead-of-D3DLOCK_DISCARD-in-D3DXCreate.patch
Type: text/x-patch
Size: 987 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110819/bc730efd/attachment-0005.bin>