"Dorrington, Albert" <albert.dorring...@lmco.com> writes: >[...] > Then, in the soft_copy_op routine, instead of passing in the slice > pitch size, I pass in MAX2(region[0],region[1]). I'd rather pass in > the entire vector for the region, but I didn't want to rework the > other mapping get routines in the template quite yet... > The latter is probably the right thing to do here, _map::get() should take origin and region vectors as arguments instead of the raw addresses, otherwise there's no good way for _map::get() to calculate the mapping parameters.
> This works, as long as my images are square... but once I move to > different dimensions (ie 32x64, 64x128) my second row of data is off > again... I'm assuming this is because of passing the largest > dimension in for the mapping get routine, rather than the width and > height.... > > I feel like I'm misunderstanding how these mapping routines are > supposed to be working. I think your understanding was correct, it's just that the _map helper wasn't designed with images in mind. Fixing it shouldn't be too difficult: define a new specialization for image objects that passes the origin and region vectors untouched as parameters, and have the other ones calculate offset and size in the same way that soft_copy_op does it now. > I'm also concerned that as the image sizes grow, that the use of the > 'memcpy' will be very inefficient (as opposed to a DMA copy) > That's hardly a concern. clEnqueueRead/WriteImage and friends take an arbitrary user pointer as either the source or destination argument of the copy, which (in the current architecture) isn't the kind of memory you can DMA to. If the user wants to write directly to GPU-accessible memory avoiding an unnecessary copy it should be using clEnqueueMapImage/Buffer instead, otherwise memcpy() needs to happen. > I'm hoping someone might be able to explain a bit about these mapping > routines, and perhaps shed some light on the OpenGL image transfer > routines and how they might be accessible from the OpenCL side. > OpenGL has the same limitation. > Thanks for reading my rambling message! :) > Thanks. > Al Dorrington > Software Engineer Sr > Lockheed Martin, Mission Systems and Training > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgphNOAG5plo8.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
