OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU
Announcements
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1663 Discussions

Different printf() behavior between CPU and GPU?

Adrian_H_
Beginner
158 Views

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?

 

0 Kudos
2 Replies
Robert_I_Intel
Employee
158 Views

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_
Beginner
158 Views

 

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

 

Reply