On Fri, 29 Apr 2011 17:12:33 -0400, Frédéric Bastien <[email protected]> wrote: > I'm ok with that definition. I don't find it bad behaved to have the > transfer change the stride > on the gpu when needed, but I don't have problem requesting that this > is done explicitly. > > What made me think that you wanted to be done automatically is that in > gpuarray.py in the function set(), there is those 2 lines: > if not ary.flags.forc: > ary = ary.copy() > > There where placed in a way that make then never used, but if moved in > the function to_gpu() would work.
Not sure what made that snippet of code 'never used', but you're right, this contradicts what I said. I appear to have changed my mind since then, and I've changed this to an error condition instead. > We can work directly on GPUArray if you prefer. In some past work we > did, we used extensively advanced feature of python to access data. We > moved away from this as it was very time consumming... I will try to > check the overhead of your solution. Please do check. If you find things worth complaining about, I'm always open towards making them better. :) > Do you see any reason why removing gpudata(only when not contiguous) > would be a problem? The only reason is for a better error message. I'm thinking of deprecating .gpudata outright, because as much as possible, I would like PyOpenCL's and PyCUDA's arrays to have the same interface. .data is not an option because that was PyOpenCL's .gpudata equivalent, so that seems to be on the way out as well. I'm leaning towards .bytes and .contig_bytes. Opinions? > My suggestion will try to mimic as much as possible numpy.ndarray. Yup, that sounds like a good plan. Andreas
pgpW1ENMaQz8w.pgp
Description: PGP signature
_______________________________________________ PyOpenCL mailing list [email protected] http://lists.tiker.net/listinfo/pyopencl
