You are not logged in.

#1 2011-11-28 11:08:45

toffyrn
Member
Registered: 2008-10-07
Posts: 221

OpenCL problems when including <CL/cl.hpp>

When upgrading to catalyst-utils 11.11, it conflicted with amdstream (from aur), so I removed it.
As far as I understand catalyst-utils should now include OpenCL library, and I have also installed opencl-headers.

However, even compiling the simplest program fails:

[toffyrn@bohr Test]$ cat cltest.cpp
#include <CL/cl.hpp>
#include <iostream>

int main(int argc, char** argv)
{
    std::cout << "hei\n";

    return 0;
}

The error seems to be somewhere in the header file:

[toffyrn@bohr Test]$ g++ cltest.cpp 
In file included from cltest.cpp:1:0:
/usr/include/CL/cl.hpp: In function ‘cl_int cl::UnloadCompiler()’:
/usr/include/CL/cl.hpp:1465:12: error: ‘::clUnloadCompiler’ has not been declared
/usr/include/CL/cl.hpp: In constructor ‘cl::Image2D::Image2D(const cl::Context&, cl_mem_flags, cl::ImageFormat, size_t, size_t, size_t, void*, cl_int*)’:
/usr/include/CL/cl.hpp:2109:19: error: ‘::clCreateImage2D’ has not been declared
/usr/include/CL/cl.hpp: In constructor ‘cl::Image2DGL::Image2DGL(const cl::Context&, cl_mem_flags, GLenum, GLint, GLuint, cl_int*)’:
/usr/include/CL/cl.hpp:2154:19: error: ‘::clCreateFromGLTexture2D’ has not been declared
/usr/include/CL/cl.hpp: In constructor ‘cl::Image3D::Image3D(const cl::Context&, cl_mem_flags, cl::ImageFormat, size_t, size_t, size_t, size_t, size_t, void*, cl_int*)’:
/usr/include/CL/cl.hpp:2208:19: error: ‘::clCreateImage3D’ has not been declared
/usr/include/CL/cl.hpp: In constructor ‘cl::Image3DGL::Image3DGL(const cl::Context&, cl_mem_flags, GLenum, GLint, GLuint, cl_int*)’:
/usr/include/CL/cl.hpp:2254:19: error: ‘::clCreateFromGLTexture3D’ has not been declared
/usr/include/CL/cl.hpp: In member function ‘cl_int cl::CommandQueue::enqueueMarker(cl::Event*) const’:
/usr/include/CL/cl.hpp:3544:13: error: ‘::clEnqueueMarker’ has not been declared
/usr/include/CL/cl.hpp: In member function ‘cl_int cl::CommandQueue::enqueueWaitForEvents(const std::vector<cl::Event>&) const’:
/usr/include/CL/cl.hpp:3551:13: error: ‘::clEnqueueWaitForEvents’ has not been declared
/usr/include/CL/cl.hpp: In member function ‘cl_int cl::CommandQueue::enqueueBarrier() const’:
/usr/include/CL/cl.hpp:3666:13: error: ‘::clEnqueueBarrier’ has not been declared

I would appreciate if anyone could point me in the right direction smile

Last edited by toffyrn (2011-11-28 11:09:33)

Offline

#2 2011-12-01 10:20:38

toffyrn
Member
Registered: 2008-10-07
Posts: 221

Re: OpenCL problems when including <CL/cl.hpp>

Decided now to post a bug report: https://bugs.archlinux.org/index.php?do … k_id=27384
Could it be a simple bug in opencl-headers?

Offline

#3 2011-12-05 15:57:26

toffyrn
Member
Registered: 2008-10-07
Posts: 221

Re: OpenCL problems when including <CL/cl.hpp>

All headers downgraded to 1.1, fixes it for me.

Offline

#4 2011-12-05 17:59:47

kralyk
Member
Registered: 2009-04-27
Posts: 72

Re: OpenCL problems when including <CL/cl.hpp>

toffyrn, is there a problem in my pkg? Do I need to update it or have you concluded the problem's elsewhere?

Offline

#5 2011-12-05 18:09:32

toffyrn
Member
Registered: 2008-10-07
Posts: 221

Re: OpenCL problems when including <CL/cl.hpp>

@kralyk: Sry for missing feedback to you. ATM neither amdstream nor libopencl is installed, only opencl-headers (1.1 version) and catalyst-utils are installed.
I can develop OpenCL programs both for cpu and AMD GPU. amdstream and catalyst-utils both seems to include clinfo, giving a conflict.
The profiling tools, however are not included in catalyst-utils...

Offline

#6 2011-12-05 18:45:44

Vi0L0
Member
From: Poland
Registered: 2009-06-24
Posts: 1,349
Website

Re: OpenCL problems when including <CL/cl.hpp>

@toffyrn:
thanks for your research, good job.
I decided to add opencl-headers-1.1.20110526-1 package into [catalyst] repo.

@kralyk:
i recommend you to just wait until new version of amd stream get released. It should arrive in same time as catalyst 11.12, afaik in the middle of this month. Then situation should be more clear.

Last edited by Vi0L0 (2011-12-05 19:10:48)

Offline

#7 2011-12-05 20:07:59

kralyk
Member
Registered: 2009-04-27
Posts: 72

Re: OpenCL problems when including <CL/cl.hpp>

Oh I see the problem now. I'll try to resolve this asap.

EDIT: oh, you posted in the meantime Violo.
Is there some major structure change in the upcoming update?
I think we'll still have to decide what goes where, this mainly concerns libOpenCL.so, clinfo and the ICD file.
You've added these recently in catalyst-utils am I right? I think that's ok with me as long as there exists alternative providing newer OpenCL API newer than 1.0 lib for use on non-AMD hw.
(I guess I'll just remove aur/libopencl or substitue it with Intel's)

The nvidia's one (the one in [extra]) is kind of ambigous to me... they say on the website that OpenCL 1.1 is included in the newest driver, but the shared object is still named .1.0.0 why is that? Does anyone know?

EDIT 2:
I inspected nvidia's libOpenCL.so.1.0.0 with readelf and I can't find some of OpenCL 1.1 functions...

Last edited by kralyk (2011-12-05 21:11:49)

Offline

#8 2011-12-05 21:02:34

toffyrn
Member
Registered: 2008-10-07
Posts: 221

Re: OpenCL problems when including <CL/cl.hpp>

kralyk wrote:

The nvidia's one (the one in [extra]) is kind of ambigous to me... they say on the website that OpenCL 1.1 is included in the newest driver, but the shared object is still named .1.0.0 why is that? Does anyone know?

.so numbering does not in general follow the version of the software behind, and Its a fact that nvidia has official support for OpenCL 1.1 (since this summer).  That said, I know nothing about what is the case for libcl in extra. (Never tried nvidia on arch...)
See for example http://www.gnu.org/s/libtool/manual/htm … -info.html

Last edited by toffyrn (2011-12-05 21:05:27)

Offline

#9 2011-12-05 21:41:10

Vi0L0
Member
From: Poland
Registered: 2009-06-24
Posts: 1,349
Website

Re: OpenCL problems when including <CL/cl.hpp>

kralyk wrote:

Is there some major structure change in the upcoming update?

Dunno, but both catalyst and sdk should be released in same day. I guess that some fusion will take place, so both pieces of software would cooperate better.

kralyk wrote:

I think we'll still have to decide what goes where, this mainly concerns libOpenCL.so, clinfo and the ICD file.
You've added these recently in catalyst-utils am I right?

Yes i did it basing on nvidia packages from our repos (well... and mainly on original catalyst installer). Should be fine, though.

Last edited by Vi0L0 (2011-12-05 21:51:13)

Offline

#10 2011-12-05 22:02:55

kralyk
Member
Registered: 2009-04-27
Posts: 72

Re: OpenCL problems when including <CL/cl.hpp>

Okay,
I checked again and it seems libcl from nvidia actually does export all the OpenCL 1.1 functions.
So we're fine there and I think I can remove all that stuff from amdstream as well as the libopencl pkg...

edit: There's still some weirdness like libamdocl.so being in both Catalyst and AMD APP SDK, but I guess they'll clean it up when new versions come out. I hope.
For now I'm gonna just remove the conflicting files...

Last edited by kralyk (2011-12-05 22:09:32)

Offline

#11 2011-12-06 07:04:14

toffyrn
Member
Registered: 2008-10-07
Posts: 221

Re: OpenCL problems when including <CL/cl.hpp>

I have one more thing to consider in the upcoming packages.
I am also using OpenCL on a couple of machines without an AMD GPU, just running amdstream on CPU. In this case it would serve me best to have the APP SDK as a standalone package, as catalyst is not usable there. When it comes to performance, I have experienced AMD's implementation to be faster then intels, even in many cases on intel processors.

That said, the CPU implementation is mostly for testing purpouses in comparison to OpenMP. In the end, my programs will need to run on other machines (non-arch GPU boxes) anyway, so it is not a big issue for me.

Offline

#12 2011-12-06 11:04:04

kralyk
Member
Registered: 2009-04-27
Posts: 72

Re: OpenCL problems when including <CL/cl.hpp>

Well, I've always designed amdstream as a standalone pkg, I sometimes use it on non-AMD hw too. I'll try to keep it that way for the next release.
All depends on the structure of the new release; I suppose I could always create some kind of substitute pkg for catalyst-utils on non-amd machines...

Offline

Board footer

Powered by FluxBB