[Beignet] [PATCH] utests: Add test case for image box blur.

[Dag Lem]

Zhigang Gong <zhigang.gong at linux.intel.com> writes:

> On Mon, May 20, 2013 at 05:21:33PM +0200, Dag Lem wrote:
>> This test case can be used to demonstrate two bugs:
>> 
>> * clCreateImage(ctx, CL_MEM_COPY_HOST_PTR, ...) makes a garbled copy -
>>   replace "#if 0" with "#if 1" in compiler_box_blur_image.cpp to demonstrate.
> I can't reproduce this bug. I get the same output with the two different code path
> one is using CL_MEM_COPY_HOST_PTR and the other is using write image.

Please find attached the output image generated on my laptop (ASUS UX31A).

I can only assume that some other form of tiling is used - perhaps it
would be better to simply map tiled images in GTT mode to copy data to
them, rather than using specialized functions (cl_mem_copy_data_tilex/tiley)?

>> * Kernel float4 arithmetics don't work -
>>   replace "#if 0" with "#if 1" in compiler_box_blur_image.cl to demonstrate.
>>   For now, int4 arithmetics are used in the kernel.
> This bug is a limitation of Gen platform. If you create an image with int type,
> you will have to use read/write_imagei to access it. If you create an image with
> unorm type, you will have to use read/write_imagef to access it. So if you want
> to use float4 in the kernel, you need to modify the cpu side code to set the
> channel data type to CL_UNORM_INT8. Then you need to enable the float4 code path
> on OCL kernel side.

Thanks, reading the OpenCL spec I see that this is actually not a bug at
all! Sorry for the confusion.

-- 
Best regards,

Dag Lem

-------------- next part --------------
A non-text attachment was scrubbed...
Name: compiler_box_blur_image.bmp
Type: image/bmp
Size: 49206 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/beignet/attachments/20130521/78d2760a/attachment-0001.bin>