Possible bug with atom_cmpxchg
The following code seems to be miscompiled: #pragma OPENCL EXTENSION cl_khr_global_int32_base_atomics : enable #pragma OPENCL EXTENSION cl_khr_global_int32_extended_atomics : enable int f(int a) {...
View ArticleRe: Possible bug with atom_cmpxchg
Is it actually compiling wrongly or is it just caching the read of value and hence always giving you the wrong behaviour? Both of the reads are not globally coherent, so they may read from L1. I don't...
View ArticleRe: Possible bug with atom_cmpxchg
>Does it fix the behaviour to make value = *ptr an atomic read? Replace that line with "value = atomic_add(ptr, 0)".It doesn't change anything. So I assume it isn't coherence issue. #pragma OPENCL...
View ArticleRe: Possible bug with atom_cmpxchg
Atomic_add doesn't change anything.Could you confirm(or reject) the bug?
View ArticleRe: Possible bug with atom_cmpxchg
sh, I agree it does look like a bug where the Tahiti compiler should be using the exec mask but doesn't. This is easy to test because for Cayman the compiler does use the exec mask and the loop works...
View ArticleRe: Possible bug with atom_cmpxchg
Thanks for the workaround. Let's hope this will be fixed soon.
View ArticleClik here to view.
Re: Possible bug with atom_cmpxchg
Sorry about the slow responses. I'm just too busy to actually verify this myself (I don't work with OpenCL day to day). However I have entered it into the system as a bug report against the shader...
View Article
