On 28.09.2011 14:30, Gor Gyolchanyan wrote:
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
All good and well, but you certainly can't operate on pixels _directly_,
only through API calls, OpenCL kernels and other GPU specific stuff.
Otherwise you just copy them to RAM modify as you see fit and copy back.
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.
Then image processing algorithms should use OpenCL as well, and the more
I look on this idea (awesome btw) the more I think it should be just
special GPU vector type with its own framework of utility functions.
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.
--
Dmitry Olshansky
