Something similar to GPU vector type, but more general. Instead of GPU - any desired device, available ATM. instead of vector - any data type, supported by OpenCL. The whole point is to hide OpenCL under intuitive D-interface, so that the GPU data and computation would be as close to CPU (D) computation as possible.
On Wed, Sep 28, 2011 at 4:14 PM, Dmitry Olshansky <[email protected]> wrote: > 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 >
