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