Hi,
If you are going to remove .gpudata, why make two access point? Why
not just make .bytes and by definition this can be strided data?
People will only have to check for gpu_array.flags.forc or similar. As
it will be told from the start, I have no problem with this. You you
want to have 2 and one of them the a transparent copy if needed this
is also good, but it can make multiple copy if we don't cache the
result and this raise problem of keeping them in sync.
But we could just let the user do gpuarray.{ascontiguousarray(defined
as c order),asfortranarray}(my_gpu_array). Those function name are the
same as numpy. If my_gpu_array respect the condition, it return it,
otherwise it make a copy.
I didn't read much on CL. I will try to make a first proposition about
CUDA and look at this after. As I will keep the lists and you in the
loop, people that used CL should be able to catch potential problem.
thanks
Fred
2011/5/1 Andreas Kloeckner <li...@informa.tiker.net>:
> On Sun, 01 May 2011 13:50:56 -0400, Andreas Kloeckner
> <li...@informa.tiker.net> wrote:
>> I'm leaning towards .bytes and .contig_bytes. Opinions?
>
> When designing this interface, we should take into account that in CL,
> we probably need to accommodate two bits of data in the general case:
> buffer and offset from start of buffer. (CL doesn't directly support
> host-side pointers). There is such a thing as a sub-buffer, but that
> doesn't offer sufficient flexibility for negative-stride arrays.
>
> Andreas
>
_______________________________________________
PyCUDA mailing list
PyCUDA@tiker.net
http://lists.tiker.net/listinfo/pycuda
