0

OpenCL 1.1, using Cloo 0.9.1.0.

For a certain CL module I get a crash at the following line:

program.Build(null, null, null, IntPtr.Zero);

Visual Studio 2010 tells me this:

An unhandled exception of type 'System.AccessViolationException' occurred in Cloo.dll

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

I have trace the error to a certain line of code.

int offset = 1000000 * (input == 0); // This is the culprit!
const sampler_t smp = CLK_NORMALIZED_COORDS_FALSE | CLK_ADDRESS_CLAMP | CLK_FILTER_NEAREST;
int4 pixel = read_imagei(image, smp, (int2)(offset + x, y));

I'm using the trick above to avoid branching. It works perfectly in all but one situation where the above yields an access violation at compile-time. If I remove the conditional multiplication it works. E.g.

int offset = 1000000;
// -or-
int offset = (input != 0 ? 0 : 1000000);

Am I facing a compiler bug here? How do I work around this error?

Some details about my Graphics card/driver:

Driver Packaging Version: 8.85.7.2-110901a1-125827C-Fujitsu Technology

Solutions Provider: ATI Technologies Inc. 2D Driver Version: 8.01.01.1152

l33t
  • 18,692
  • 16
  • 103
  • 180
  • I think you won't avoid branching with that code, the branching will still be there after it's compiled. – ardiyu07 Jun 05 '12 at 09:17
  • Well, empirical testing shows that it is indeed a lot faster to use the trick above. Anyway, the problem is not the code itself. The problem is that the compiler bails out... – l33t Jun 05 '12 at 09:20
  • Have you tried running a kernel with only (int offset = 1000000 * (input == 0);)? If it runs fine, maybe your bug is in a different place.. – ardiyu07 Jun 05 '12 at 09:29
  • Even if it runs fine it's no guarantee that the bug is somewhere else. Altering the code yields a new code tree to be optimized by the compiler, which could mean that the potential bug is avoided. – l33t Jun 05 '12 at 10:35

1 Answers1

0

It's a compiler bug. Hopefully it will get fixed some day. For now, I will just avoid that specific optimization trick.

l33t
  • 18,692
  • 16
  • 103
  • 180