OpenCL

[somefoo]

Hey

When reading from an image3d_t (base type being short) with any sampler (any combination of allowed values), accessing the position using the overloaded read_imagei(image3d_t, sampler_t, float4), odd things start to happen. See attached image. It doesn't matter if you floor/ceil the position first. If you cast the position to an int4 and use read_imagei(image3d_t, sampler_t, int4) instead, all works fine. Also, the issue doesn't seem to be the read itself, but the read in combination with a follow-up read in an env-map. This problem does not occur on GPUs made by competitors.

Explanation of the image:

This is a basic volume renderer (using ray-marching), which draws a background if nothing is hit, and draws a background (with 1/2 * intensity) if a voxel with a specific value is hit.

If drawing a constant color when hitting a voxel of interest, no issues can be observed.

*EDIT: I have attached a minimal example containing a basic application which produces this issue and writes an image to a out.ppm file. The folder also contains my clinfo. Thanks

System:

CPU: Dual Xeon E5 2630 v3

RAM: 32GB DDR4

GPU: AMD Vega 56

OS: Ubuntu 20.04

OpenCL user space driver: amdgpu-pro-20.30-1109583-ubuntu-20.04

[dipak]

Hi  somefoo‌

Thank you for reporting it. I've whitelisted you and moved this post to AMD OpenCL forum.

Please provide a minimal reproducible test-case and attach the clinfo output.

Thanks.

[somefoo]

Done

[dipak]

Thank you for providing the repro. We'll look into this and get back to you.

Thanks.

[dipak]

Sorry for this delayed reply.

I was able to reproduce it. As per my observations, it seems like a compiler optimization issue. If the optimization is disabled during kernel compilation, the kernel seems to be producing expected result. I've reported it to the concerned team.

Could you please try to compile the kernel without optimization and share your findings?

Thanks.

[somefoo]

Heya,

glad to receive feedback  Yes, indeed it seems to be the optimizer. When I compile the kernel with -O0 I have no issues. There are further ways to solve/cause the issue (as indicated in the kernel-source <renderer.cl> file). I hope this helps the concerned team to find a solution  

Many thanks.

Notes:

clBuildProgram(m_program, 0, NULL, "-cl-std=CL1.2", NULL, NULL); //Issue

clBuildProgram(m_program, 0, NULL, "-O0 -cl-std=CL1.2", NULL, NULL); //No issue

[dipak]

Thank you for the confirmation. I already had a discussion with the OpenCL team regarding the kernel. I'll file a bug ticket against this issue. 

Thanks.

[dipak]

I would like to mention one point here regarding the vector literals used in the kernel. As per OpenCL C, the correct syntax is like below:

(float4)( float, float, float, float )
(float4)( float3, float )

I would suggest you to use the OpenCL C style vector initializer in the kernel.

Thanks.

[somefoo]

Indeed my usage assumes they are C99 like structs, perhaps not a good assumption to make. I will use your suggested vector initializers going forward. I truly appreciate that you took some time to write this feedback.

Many thanks.