Goodbye, garbage collector!

[Gor Gyolchanyan]

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 <dmitry.olsh at gmail.com> 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
>> <gor.f.gyolchanyan at gmail.com>  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<b.helyer at gmail.com>
>>>  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
>