22-Jul-2013 01:19, Namespace пишет:

> I really like the idea.
> I've changed it a bit:
> I have a float[1024] buffer which is used, as long as the requested size
> is less than 1024. If it's greater, I will temporary allocate the whole
> array with new float[Size];
> Any improvements? Or is 1024 to small / big?
No one size fits all. Measure and profit.

-- 
Dmitry Olshansky

On Sunday, 21 July 2013 at 21:35:15 UTC, Namespace wrote:
> On Sunday, 21 July 2013 at 21:31:08 UTC, bearophile wrote:
>> Namespace:
>>
>>> I have a float[1024] buffer which is used, as long as the requested size is less than 1024. If it's greater, I will temporary allocate the whole array with new float[Size];
>>
>> That's one of the ways I solve similar problems.
>>
>>
>>> Any improvements? Or is 1024 to small / big?
>>
>> An idea is to add some debug{} code that computes statistics for the array sizes...
>>
>> Bye,
>> bearophile
>
> Too much effort. But if some of you have this experiences already, I would gladly profit from them. ;)

It would really help to know what your function is doing exactly.

Personally, I think you are over thinking it. Just do this:

//----
void foo ()
{
    static float[] scratchPadBuffer;
    // use scratchPadBuffer here
}
//----

And simply make buffer grow as it needs, and never shorten it. You could consider this to be "controlled leak" I guess. But at least, with this approach, you can't "guess wrong", and you'll only very rarely allocate.

It's part of Dgame and it's the shape draw method. The method collects the vertices and give them to the vertex buffer.
I will try it with my current way: static stack buffer with a size of 1024 and otherwise I will temporary allocate memory. But how much shapes grow larger than 1024 vertices ;).

Am 22.07.2013 10:41, schrieb Namespace:
> It's part of Dgame and it's the shape draw method. The method collects
> the vertices and give them to the vertex buffer.
> I will try it with my current way: static stack buffer with a size of
> 1024 and otherwise I will temporary allocate memory. But how much shapes
> grow larger than 1024 vertices ;).

This will be over 1024 vertices in no time, I am currently drawing vertices with a size of ~500MiB depending on the terrain. The CPU doesn't need to know of all vertices at once, so collect them and upload them  to the GPU if they go over a certain limit and begin to fill your buffer from the start again. I use a malloc allocated buffer, its size is never decreased, I initially allocate an educated guess + some extra to be safe, then if it really happens to run ot of memory I simple resize it depending on how much is left with another educated guess + some extra.

On 2013-07-21 12:18, Namespace wrote:

> But then I have mostly far too much and maybe a few times a bit too less
> store. It's not flexible. But maybe with a smaller granule.
> What's about this:

You said you needed between 100 and 4000 floats. My suggestion will allocate 4000 floats once per thread. Use what you need from the array.

I guess your solution with Chunk encapsulate this usage pattern.

-- 
/Jacob Carlborg

On Monday, 22 July 2013 at 09:26:33 UTC, David wrote:
> Am 22.07.2013 10:41, schrieb Namespace:
>> It's part of Dgame and it's the shape draw method. The method collects
>> the vertices and give them to the vertex buffer.
>> I will try it with my current way: static stack buffer with a size of
>> 1024 and otherwise I will temporary allocate memory. But how much shapes
>> grow larger than 1024 vertices ;).
>
> This will be over 1024 vertices in no time, I am currently drawing
> vertices with a size of ~500MiB depending on the terrain. The CPU
> doesn't need to know of all vertices at once, so collect them and upload
> them  to the GPU if they go over a certain limit and begin to fill your
> buffer from the start again. I use a malloc allocated buffer, its size
> is never decreased, I initially allocate an educated guess + some extra
> to be safe, then if it really happens to run ot of memory I simple
> resize it depending on how much is left with another educated guess +
> some extra.

Hm, but Dgame isn't designed for that sort of thing. It's more like SFML for C++. So do you think that such Framework will ever use more vertices than 1024?
Anyway, if it's larger, I allocate with malloc enough memory and free it at the end of the scope.