[Mesa-dev] OpenCL Image Support Question about 'soft_copy_op'
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.
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 _mapclover::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
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
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL Image Support Question about 'soft_copy_op'
On Mon, Mar 31, 2014 at 06:39:26PM +, 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 _mapclover::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
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL Image Support Question about 'soft_copy_op'
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
Re: [Mesa-dev] OpenCL Image Support
Hi Tom, Do I need to have an AMD GPU for compute images to R600? Thank you! On Tue, Mar 18, 2014 at 9:14 PM, Tom Stellard t...@stellard.net wrote: On Mon, Mar 17, 2014 at 10:50:18PM -0400, Aditya Avinash wrote: Hi, I am a student. I have experience in OpenCL for 3 years. I would like to know what need to be done exactly. Hi, The first thing you need to do is write a proposal. I would recommend writing a rough draft, uploading it to the Google Summer Code site and then mailing a copy to the list for review. You can edit your proposal on the Google Summer of Code site right up until the deadline, so you don't need to wait until you have a final draft to upload it. The more feedback you can get on your proposal before the deadline (which is in about two days) the better your proposal will be. If you have any specific questions about this project or need help getting started, don't be afraid to ask. At a high level, this project can be broken down like this: 1. Find and/or write simple OpenCL programs (preferably piglit[1] tests) that use images. 2. Add image builtins to libclc[2] 3. Implement the gallium callbacks used by clover[3] for images. 4. Add support for compute images to the R600 LLVM[4] backend. -Tom [1] http://cgit.freedesktop.org/piglit [2] http://libclc.llvm.org/ [3] http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clover [4] https://github.com/llvm-mirror/llvm/tree/master/lib/Target/R600 -- Regards, *Atluri Aditya Avinash*, India. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL Image Support
On Wed, Mar 19, 2014 at 11:30:54AM -0400, Aditya Avinash wrote: Hi Tom, Do I need to have an AMD GPU for compute images to R600? Thank you! Yes, you will need an evergreen or new AMD GPU (see the decoder ring http://xorg.freedesktop.org/wiki/RadeonFeature/#index5h2 for specific model numbers). Don't worry if you don't have a supported AMD GPU. If your proposal is accepted there will be plenty of time for you to get one and many of the older Evergreen GPUs can be obtained very inexpensively. -Tom On Tue, Mar 18, 2014 at 9:14 PM, Tom Stellard t...@stellard.net wrote: On Mon, Mar 17, 2014 at 10:50:18PM -0400, Aditya Avinash wrote: Hi, I am a student. I have experience in OpenCL for 3 years. I would like to know what need to be done exactly. Hi, The first thing you need to do is write a proposal. I would recommend writing a rough draft, uploading it to the Google Summer Code site and then mailing a copy to the list for review. You can edit your proposal on the Google Summer of Code site right up until the deadline, so you don't need to wait until you have a final draft to upload it. The more feedback you can get on your proposal before the deadline (which is in about two days) the better your proposal will be. If you have any specific questions about this project or need help getting started, don't be afraid to ask. At a high level, this project can be broken down like this: 1. Find and/or write simple OpenCL programs (preferably piglit[1] tests) that use images. 2. Add image builtins to libclc[2] 3. Implement the gallium callbacks used by clover[3] for images. 4. Add support for compute images to the R600 LLVM[4] backend. -Tom [1] http://cgit.freedesktop.org/piglit [2] http://libclc.llvm.org/ [3] http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clover [4] https://github.com/llvm-mirror/llvm/tree/master/lib/Target/R600 -- Regards, *Atluri Aditya Avinash*, India. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] OpenCL Image Support
Hi, I am a student. I have experience in OpenCL for 3 years. I would like to know what need to be done exactly. Thank you -- Regards, *Atluri Aditya Avinash.* ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL Image Support
On Mon, Mar 17, 2014 at 10:50:18PM -0400, Aditya Avinash wrote: Hi, I am a student. I have experience in OpenCL for 3 years. I would like to know what need to be done exactly. Hi, The first thing you need to do is write a proposal. I would recommend writing a rough draft, uploading it to the Google Summer Code site and then mailing a copy to the list for review. You can edit your proposal on the Google Summer of Code site right up until the deadline, so you don't need to wait until you have a final draft to upload it. The more feedback you can get on your proposal before the deadline (which is in about two days) the better your proposal will be. If you have any specific questions about this project or need help getting started, don't be afraid to ask. At a high level, this project can be broken down like this: 1. Find and/or write simple OpenCL programs (preferably piglit[1] tests) that use images. 2. Add image builtins to libclc[2] 3. Implement the gallium callbacks used by clover[3] for images. 4. Add support for compute images to the R600 LLVM[4] backend. -Tom [1] http://cgit.freedesktop.org/piglit [2] http://libclc.llvm.org/ [3] http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clover [4] https://github.com/llvm-mirror/llvm/tree/master/lib/Target/R600 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
