Vertex Buffer Objects for WineD3D

[Stefan Dösinger]

> 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.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20060613/279226ed/attachment.pgp