[Mesa-dev] OpenCL Image Support Question about 'soft_copy_op'

[Francisco Jerez]

"Dorrington, Albert" <albert.dorrington at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140331/8b0b8690/attachment.sig>