I'm asking for std.allocator to be used in the language to be able to use graphics card memory when doing image processing. I would like to create allocators for allocating graphics card memory. Perhaps even texture memory. This would allow one to directly operate on pixels on the graphics card and draw those pixels without ever copying them, which would lead to incredible performance boost, when dealing with giant pixel buffers, that get modified programmatically. I would then use that graphics memory allocator with built-in arrays and send those arrays over to some image processing algorithms. Having such awesome integration with graphics hardware will lure lots of graphics programmers over to D. The back-end for that allocator will probably be OpenCL, as I see it.
On Wed, Sep 28, 2011 at 2:18 PM, Gor Gyolchanyan <[email protected]> wrote: > I assume when the allocators come along, the flexibility of those > constructs will increase, no? > Also, wouldn't it be cleaner to allow reuse of the incredibly > convenient syntax of built-in arrays and enable one to replace it's > allocators? > Some properties, maybe? Something like this: > > ----- > int[] array; > assert(is(array.allocator == DynamicAllocator)); // This equals to > GCAllocator().dynamicAllocator(). > array.allocator = RegionAllocator.dynamicAllocator(). > ----- > > And the functions of the allcoators, that create arrays, using that > allcoator would write the above statements. > How about this? And how much the performance would drop if we > introduced DynamicAllocators to do all the allocations? > Is there any other solution you could suggest, that would allow using > built-in array syntax? > What about stack frames, that get moved to heap? > > On Wed, Sep 28, 2011 at 1:57 PM, Bernard Helyer <[email protected]> wrote: >> Using Array!T in place of T[] would work, if you don't mind malloc/free. >> Also, overriding new and delete (and delete itself) are going -- relying >> on them is not advisable. Use emplace and clear, instead. >> >
