cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

gagcl
Journeyman III

CL-GL interop not properly displaying texture on CPU

Please, consider the simple example https://code.google.com/p/opencl-book-samples/source/browse/trunk/src/Chapter_10/GLinterop/GLinterop....

While the program generates properly output on GPU (gradient texture), the texture is black on Intel CPU and garbage on AMD CPU. The screenshots are attached.

Is this a bug in AMD's opencl?

Thanks.

0 Likes
11 Replies
Wenju
Elite

I'm sorry, I can't open the link, I'll forward it to right person.

0 Likes

Try to reproduce the issue...

Which OS system/hardware are you using?

0 Likes

I'm using Debian GNU/Linux (Wheezy) with the latest APP SDK. Feel free to try this also on Win.

Hardware? As I've mentioned, on my GPU is all OK.

But on CPUs:

- AMD Phenom II x4 850,

- Intel Pentium 4 3.2GHz,

- mobile Intel Core2Duo T7250 and

- mobile Intel Core i3 1st-generation

it produces broken output.

0 Likes

I don't think it's a bug, try to change some values of the kernel arguments or modify the kernel(for example: i++; --> i+=2;). Just speculating.

0 Likes

I've tried just to put the printf() in the texture kernel. And... there is no output! Then I've tested printf in the first (working) kernel, printf is OK. So the texture kernel is not running at all! But I don't see any != CL_SUCCESS.

0 Likes

Dear Wenju and binying,

could you figure out the reason for such behavior and possible fix?

It's hard to investigate closed source library on my own. Here are my results:

Using GPU and printf:

$ ./debug.sh
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from <...>/openclprogrammingguide-build/opencl-book-samples-read-only/src/Chapter_10/GLinterop/GLinterop...done.
(gdb) r
Starting program: <...>/openclprogrammingguide-build/opencl-book-samples-read-only/src/Chapter_10/GLinterop/GLinterop
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Ready for OpenGL 2.1
[New Thread 0x7fffeecd2700 (LWP 4530)]
Performing queries on OpenGL objects:
Queried a texture object succesfully.
Object name is: 1
Texture rectangle ARB is being used.
waiting for event texture...
coord: (0,0), color: (0.000000,0.000000,0.000000,0.000000)
coord: (1,0), color: (0.003906,0.000000,0.000000,0.000000)
coord: (2,0), color: (0.007812,0.000000,0.000000,0.000000)
coord: (3,0), color: (0.011719,0.000000,0.000000,0.000000)
coord: (4,0), color: (0.015625,0.000000,0.000000,0.000000)
coord: (5,0), color: (0.019531,0.000000,0.000000,0.000000)
coord: (6,0), color: (0.023438,0.000000,0.000000,0.000000)
coord: (7,0), color: (0.027344,0.000000,0.000000,0.000000)
coord: (8,0), color: (0.031250,0.000000,0.000000,0.000000)
coord: (9,0), color: (0.035156,0.000000,0.000000,0.000000)
coord: (10,0), color: (0.039062,0.000000,0.000000,0.000000)
coord: (11,0), color: (0.042969,0.000000,0.000000,0.000000)
coord: (12,0), color: (0.046875,0.000000,0.000000,0.000000)
coord: (13,0), color: (0.050781,0.000000,0.000000,0.000000)
coord: (14,0), color: (0.054688,0.000000,0.000000,0.000000)
coord: (15,0), color: (0.058594,0.000000,0.000000,0.000000)
coord: (16,0), color: (0.062500,0.000000,0.000000,0.000000)
coord: (17,0), color: (0.066406,0.000000,0.000000,0.000000)
coord: (18,0), color: (0.070312,0.000000,0.000000,0.000000)
coord: (19,0), color: (0.074219,0.000000,0.000000,0.000000)
coord: (20,0), color: (0.078125,0.000000,0.000000,0.000000)
coord: (21,0), color: (0.082031,0.000000,0.000000,0.000000)
coord: (22,0), color: (0.085938,0.000000,0.000000,0.000000)
coord: (23,0), color: (0.089844,0.000000,0.000000,0.000000)
coord: (24,0), color: (0.093750,0.000000,0.000000,0.000000)
coord: (25,0), color: (0.097656,0.000000,0.000000,0.000000)
coord: (26,0), color: (0.101562,0.000000,0.000000,0.000000)
coord: (27,0), color: (0.105469,0.000000,0.000000,0.000000)
coord: (28,0), color: (0.109375,0.000000,0.000000,0.000000)
coord: (29,0), color: (0.113281,0.000000,0.000000,0.000000)
coord: (30,0), color: (0.117188,0.000000,0.000000,0.000000)
coord: (31,0), color: (0.121094,0.000000,0.000000,0.000000)
coord: (0,1), color: (0.000000,0.000000,0.000000,0.000000)
coord: (1,1), color: (0.003906,0.000000,0.000000,0.000000)
coord: (2,1), color: (0.007812,0.000000,0.000000,0.000000)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeecd2700 (LWP 4530)]
0x00007ffff704df4b in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0  0x00007ffff704df4b in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1  0x00007ffff02d6393 in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#2  0x00007ffff02d6d01 in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#3  0x00007ffff02f00b5 in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#4  0x00007ffff02f030d in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#5  0x00007ffff0288608 in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#6  0x00007ffff02892ae in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#7  0x00007ffff02950ae in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#8  0x00007ffff029bfbd in ?? () from /usr/lib/x86_64-linux-gnu/libamdocl64.so
No symbol table info available.
#9  0x00007ffff6558b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
__res = <optimized out>
pd = 0x7fffeecd2700
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737199810304, -5931401599312134437, 140737488347152, 140737199811008, 140737354125376, 3, 5931434437508136667, 5931382549652504283},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
freesize = <optimized out>
__PRETTY_FUNCTION__ = "start_thread"
#10 0x00007ffff684670d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#11 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)

This is not direct related to the main problem but also interesting. Are there any buffer overflow in printf()? Must something like flush() be called time to time?

And here is on CPU:

Modifying GLinterop.cpp as follows:
cl_int computeTexture()
...
errNum = clEnqueueNDRangeKernel(commandQueue, tex_kernel, 2, NULL,
tex_globalWorkSize, tex_localWorkSize,
0, NULL, &events[0]);
if (errNum != CL_SUCCESS)
std::cerr << "Error queuing kernel for execution." << std::endl;

std::cerr << "waiting for event texture... " << std::endl;
errNum = clWaitForEvents(1, events);
if (errNum != CL_SUCCESS)
std::cerr << "Error waiting for events = " << errNum << std::endl;
std::cerr << "                         ... done." << std::endl;
...

I've got CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST (-14) on CPU:

$ ./run.sh
Ready for OpenGL 2.1
Performing queries on OpenGL objects:
Queried a texture object succesfully.
Object name is: 1
Texture rectangle ARB is being used.
waiting for event texture...
Error waiting for events = -14
... done.
waiting for event texture...
Error waiting for events = -14
... done.
waiting for event texture...
Error waiting for events = -14
... done.
waiting for event texture...
Error waiting for events = -14
... done.
waiting for event texture...
Error waiting for events = -14
... done.
waiting for event texture...
Error waiting for events = -14
... done.

Any thoughts why it fails on CPU?

0 Likes

errNum = clWaitForEvents(1, events);  --> errNum = clWaitForEvents(1, &events[0]);

Can you offer the kernel file?

0 Likes

The kernel is the one from the 1st post: http://code.google.com/p/opencl-book-samples/source/browse/trunk/src/Chapter_10/GLinterop/GLinterop....

I've attached this file. And also .cpp.

0 Likes

I add following after kernel execution:

errNum = clFlush(commandQueue);
  if (errNum != CL_SUCCESS)
                std::cerr << "Error clFlush." << std::endl;

    // wait for the kernel call to finish execution
cl_int eventStatus = CL_QUEUED;
 
    while(eventStatus != CL_COMPLETE)
    {
        errNum = clGetEventInfo(
                        event[0],
                        CL_EVENT_COMMAND_EXECUTION_STATUS,
                        sizeof(cl_int),
                        &eventStatus,
                        NULL);
       if (errNum != CL_SUCCESS)
                std::cerr << "Error get info." << std::endl;
    }

the event status would never complete. I'll check it later.

0 Likes

Wenju, thanks for trying it out! Were you able to get any further info? Is the info in this topic enough for AMD to fix the issue, or should I write the same to bug tracker/support directly?

0 Likes

Sorry! Before kernel execution, clEnqueueAcquireGLObjects is never completed. So the kernel has never been executed when the device is cpu.

0 Likes