Vertex Buffer Objects for WineD3D
stefan at codeweavers.com
Tue Jun 13 03:56:43 CDT 2006
> It will be better to move VBO creation and binding on vertexbuffer.c. (its
> why GetMemory didn't provide VBO id before, no need for that)
> Have you planned to use ti for index buffers too ?
That was my first idea(just bind the vertex buffer in GetMemory and return the
offset), but the problem is that dx apps may split vertices on multiple
buffers. They may store the position in buffer 1 and the colors of vertices
in buffer 2. GetMemory is called when the FVF or declaration is converted
into strided data. The strided data contains pointers to the vertex data
which may come from many different VBs. I have to bind the VBO the data is
stored in when I pass the data pointer to gl in LoadVertexArrays. This is
perfectly ok for GL(and not a performance issue), but I need the VBO number
in the strided data to know where each data comes from.
> > The vertex conversion is slow, and it turned out that if the app Locks
> > the Buffer every frame then drawStridedSlow is faster Converting +
> > drawStridedSlow. Because of that VBOs and the conversion aren't used for
> > vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not
> > loaded into a vbo.
> For that problem i had a prototype who remembered too many lock (in small
> times) and active the no-VBO flag :)
I considered the same thing, considering that the app may be bad-behaved and
set bad flags. Remembering the application's behavior seemed to be better.
However, I noticed that even well behaved apps(e.g. battlefield 1942) don't
keep all the geometry they use in a map in vertex buffers at all time.
Instead they load the area around the player, and load new stuff and throw
away the old while the player moves through the map. As a result wined3d gets
a bunch of IWineD3DVertexBuffer::Lock calls sporadically. Depending on the
behavior of the player that is different. E.g. if a sniper stays at one place
all the time there isn't much reload, but if he's flying a plane there is
constantly new data. I couldn't think of any good heurisitics which could
detect all that stuff, so I decided to rely on the flags set by the app.
After all, the application developers know best what happens, and D3D8 and
D3D9 apps are quite well-behaved compared to DDraw / D3D7 apps.
(Even if we can find a good way to handle the bf1942 and hl2 cases perfectly,
who can say if we won't find a game which does something perfectly valid and
fools our algorithms)
The same problem applies to textures and render targets, btw. For textures it
can be solved quite well, render targes are more tricky.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060613/279226ed/attachment.pgp
More information about the wine-devel