On Mon, Mar 31, 2014 at 06:39:26PM +0000, Dorrington, Albert wrote:
> I am experimenting with adding image support to Mesa and am encountering
> something I don't understand with the mapping routines implemented in
> transfer.cpp, within the soft_copy_op function.
>
> We are working on 10.1 branch of Mesa which has some tweaks to let Mesa run
> OpenCL kernels build from the AMD OpenCL driver, so my issues may very well
> be an artifact of that environment.
>
> In any case, here is what I am seeing:
>
> I have a simple program which generates an image of a given size, and sets
> each pixel to a value from a given starting point with a given increment
> value.
> For example, the command "imageTest 32 32 0 1" would create a 32x32 image, in
> which pixel (0,0) would be set to 0, (0,1)=1 ... (0,31)=31, (1,0)=32 and so
> on...
> The kernel takes the x,y coordinates as parameters and returns the value at
> that location.
>
> It appears that the default soft_copy_op destination mapping does not provide
> a compatible setup for images.
>
> Given a 32x32 image of format CL_R8, INT32, the validate_object() routines in
> clEnqueueWriteImage() calculate a destination pitch of {4,128,4096}
> This results in a size of 4096 being passed to the mapping get
> (dst_pitch[2]*region[2]) this generates a staging texture of 4096x1x1 pixels.
>
If you are using an fglrx kernel with the Open Source driver it is hard
to know what might be going on. I would recommend reading and writing
the image with only clEnqueue{Read,Write}Image() to see if you still
get correct results.
> With this, I can retrieve the values from the first row of the image, but
> none of the subsequent rows return valid values.
>
> After some experimentation (with a 64x4 image) I discovered that there
> appears to be a minimum row pitch of 256bytes, so the 128 being passed in for
> the 32x32 image didn't work properly.
>
> I changed the clEnqueueWrite routine to adjust the destination pitches as
> follows:
> dst_pitch[1]= MAX2(256,dst_pitch[1]); // row pitch
> dst_pitch[2]=dst_pitch[1]*region[1]; // slice pitch
>
> That seemed to work at first, but once I started moving to different image
> sizes, things did not work right at all...
> With a 64x64 image, the subsequent rows no longer mapped properly.
>
> After more experimentation, I seem to have found a method that will work
> reliably, with testing of images up to 2048x2048. (I can't seem to go higher
> than that, due to a memory leak I have not found yet...)
>
> What I did, was add a different mapping get template for images:
>
> template<>
> struct _map<clover::image*> {
> static mapping
> get(command_queue &q, clover::image *img, cl_map_flags flags, size_t
> offset, size_t size) {
> return { q, img->resource(q), flags, true, {{offset}}, {{size, size,
> 1}} };
> }
> }
>
> 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...
>
> 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....
>
There have been a few bug-fixes to the region calculation helpers in
the last few months. You should try porting those back to 10.1 to see
if it makes a difference.
-Tom
> I feel like I'm misunderstanding how these mapping routines are supposed to
> be working.
> 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)
>
> 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.
>
> Thanks for reading my rambling message! :)
>
> Al Dorrington
> Software Engineer Sr
> Lockheed Martin, Mission Systems and Training
>
> _______________________________________________
> mesa-dev mailing list
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
