Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed

[Stefan Dösinger]

> +        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)

[PATCH] [try 4] ddraw: Grow indexbuffer as needed

[Henri Verbeet]

On 24 June 2010 17:40, Stefan Dösinger <stefandoesinger(a)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.

[PATCH] [try 4] ddraw: Grow indexbuffer as needed

[Stefan Dösinger]

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.