topic Sounds like a bug in our CPU in OpenCL* for CPU

Different printf() behavior between CPU and GPU?

Adrian_H_ — Mon, 29 Dec 2014 03:15:04 GMT

I have a very simple kernel with printf statement like:

printf("id: %d\n", id);

I am using the latest Intel SDK, on a 64-bit Windows system.

When I run the kernel on the CPU, the "\n" results in a single 0x0A byte at the end of the printed string.

When I run the kernel on GPU (Intel as well), the "\n" results in the two bytes 0x0A 0x0D.

Is this the expected behavior? Is there any way to make both devices produce the same output?

This is of course reminiscent of the differences between regular C/C++ on Linux and Windows, but here both devices are being used under Windows.

Thanks in advance for any help or pointers - am I missing something obvious?

Robert_I_Intel — Wed, 07 Jan 2015 17:26:41 GMT

Sounds like a bug in our CPU implementation. I'll talk to our CPU folks. Workaround is of course to use something like this:

#ifdef CPU

printf("....\r\n",...);

#else

printf("...\n",...);

#endif

You can also just outright switch to \r\n.

See http://programmers.stackexchange.com/questions/29075/difference-between-n-and-r-n

Adrian_H_ — Thu, 08 Jan 2015 20:00:30 GMT

Robert,

Thanks for the reply.

I tried a quick test with AMD's SDK, on both CPU and GPU, and found that their implementation always translates to a single LF (0x0A) byte.

So, in one sense the Intel GPU is the "odd man out", using 0x0D 0x0A. In summary:

Intel SDK, CPU: "\n" gives 0x0A (LF)

Intel SDK: GPU: "\n" gives 0x0D 0x0A (CR,LF)

AMD SDK, CPU: "\n" gives 0x0A (LF)

AMD SDK, GPU: "\n" gives 0x0A (LF)

The OpenCL standard does not refer to control characters at all in its discussion of printf(), so all implementations are "correct".

(The stackexchange link was interesting. I've been around since CP/M days, so it's all familiar!)

Thanks again,

Adrian