[PATCH 1/3] wined3d: Shadow buffers in sysmem when software vertexprocessing is used

Stefan Dösinger stefan at codeweavers.com
Tue Jan 15 07:03:18 CST 2013

Fixes bug 29731.

ToEE creates the device with software vertexprocessing and expects the
buffer contents to remain intact in DISCARD locks. The following tests
show that SWVP devices not only retain the data but also always return
the same pointer when mapping buffers.

An argument could be made that we should not create VBOs at all with
SWVP. I decided against this because of OpenGL 3 core contexts.
 dlls/wined3d/buffer.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c
index c8217e6..415b5e5 100644
--- a/dlls/wined3d/buffer.c
+++ b/dlls/wined3d/buffer.c
@@ -1207,6 +1207,15 @@ static HRESULT buffer_init(struct wined3d_buffer *buffer, struct wined3d_device
     TRACE("size %#x, usage %#x, format %s, memory @ %p, iface @ %p.\n", buffer->resource.size, buffer->resource.usage,
             debug_d3dformat(buffer->resource.format->id), buffer->resource.allocatedMemory, buffer);
+    if (device->create_parms.flags & WINED3DCREATE_SOFTWARE_VERTEXPROCESSING)
+    {
+        /* SWvp always returns the same pointer in buffer maps and retains data in DISCARD maps.
+         * Keep a system memory copy of the buffer to provide the same behavior to the application.
+         * Still use a VBO to support OpenGL 3 core contexts. */
+        TRACE("Using doublebuffer mode because of software vertex processing\n");
+        buffer->flags |= WINED3D_BUFFER_DOUBLEBUFFER;
+    }
     dynamic_buffer_ok = gl_info->supported[APPLE_FLUSH_BUFFER_RANGE] || gl_info->supported[ARB_MAP_BUFFER_RANGE];
     /* Observations show that drawStridedSlow is faster on dynamic VBs than converting +

More information about the wine-patches mailing list