Closed wsphillips closed 3 years ago
GDF - channelCombineRGB.txt
run sample
runvx -affinity:cpu channelCombineRGB.txt
runvx -affinity:gpu channelCombineRGB.txt
Test Package - channelCombineRGB.zip
@LakshmiKumar23 - attached is the OpenCL code & out.rgb (480x360) generated for the above graph for reference - cl-buffer.zip
@kiritigowda I don't see this issue on windows. Also, in attached OpenCL code, lines 14&15 redefine uint8.
Test
GDF - channelCombineRGB.txt
run sample
- Test CPU Flow
runvx -affinity:cpu channelCombineRGB.txt
- Test GPU Flow
runvx -affinity:gpu channelCombineRGB.txt
Test Package - channelCombineRGB.zip
@hansely can you try this test case and verify the issue is fixed?
@kiritigowda The channel combine is fixed. However, the problem still remains due to channel extract issue. I am working on the fix for it.
@kiritigowda Verified with the test package above and works fine.
There appears to be an issue with graphs that use the channel combine node. Resulting RGB images have periodic artifacts.
I ran into this issue when using the filter code example from the official OpenVX Programming Guide. (i.e. it can be used as a reproducer)
Removing the convolution/filter nodes from the above example and creating a graph that only does a RGB channel extract to 3 virtual U8 images and recombining to an RGB output image is enough to trigger the bug.
The
canny
example from this repo does not cause a problem either (therefore unlikely that split channel data is corrupted during extraction).Manually recreating the graph pipeline with immediate mode functions (e.g.
vxuChannelCombine
) does NOT result in corrupted images--resulting RGB composites are fine.This was run on CentOS 8.1 / ROCm 3.5.1 using
mivisionx
AMD repo binaries (and also building frommaster
to be sure). (GPU is gfx906 -- Radeon VII)