while(size < IndexCount * sizeof(WORD))
{
size <<= 1;
}
Thinking about it, is there a reason for growing the buffer in power of two sizes, and not simply set it to the size required for the draw call? E.g. if the app passes index data with a size somewhere between 2^31 and 2^32-1(which still still fits in the UINT variable) the power of two growing will try to create a 2^32 byte buffer which overflows and fails. So you're cutting the possible index buffer size in half.
(Of course if an app actually tries to create a >2GB index buffer we have bigger problems than the UINT, especially in a 32 bit process)
On 24 June 2010 17:40, Stefan Dösinger stefandoesinger@gmx.at wrote:
Thinking about it, is there a reason for growing the buffer in power of two sizes, and not simply set it to the size required for the draw call? E.g. if the app passes index data with a size somewhere between 2^31 and 2^32-1(which still still fits in the UINT variable) the power of two growing will try to create a 2^32 byte buffer which overflows and fails. So you're cutting the possible index buffer size in half.
If we really cared about those cases we could explicitly handle them, (e.g. by growing in smaller increments once we're over half the limit) but I don't think we do. There's also the (more likely) consideration that creating an index buffer of a certain size will fail due to running out of memory / address space, while a slightly smaller buffer might succeed, but I don't think we really care about that one either.
Am Donnerstag 24 Juni 2010 17:56:07 schrieb Henri Verbeet:
If we really cared about those cases we could explicitly handle them, (e.g. by growing in smaller increments once we're over half the limit) but I don't think we do. There's also the (more likely) consideration that creating an index buffer of a certain size will fail due to running out of memory / address space, while a slightly smaller buffer might succeed, but I don't think we really care about that one either.
Sounds reasonable
Besides, this index buffer here is an ugly thing, and I am surprised it survived this long. It'll need a better solution after Wine 1.2, maybe a method in wined3d to draw from a vertex buffer with user pointer index data, or a special user pointer index buffer. I have played with the latter idea a while ago but ran into some issues.