Archives Discussions

[utsavgupta]

First of all I would like to say hello to the AMD Developer community as this is my first post.

I always had interest in parallel processing hence after getting a Radeon card I wanted to experiment with AMD APP. I was a following the tutorial in http://www.thebigblob.com/getting-started-with-opencl-and-gpu-computing/ .

I have installed the latest AMD Catalyst Drivers as well as AMD APP 2.6 (32 bits) on a system with Radeon HD 5450. I don;t get any compilation error while compiling the host. However the program receives a SIGSEGV while executing. While debugging I noticed that clGetPlatformIDs was causing the problem.

Here is a screenshot of kdbg debugging the host:

Can't understand where it's breaking. I am running kernel 3.2.9 on ARCH and I have installed the latest version of catalyst-total from AUR.

Cheers,

Utsav

[djohn]

I'm not sure if this could help, but have you tried not writing the " = NULL" in lines 37 and 38?

[utsavgupta]

Nope that did not work.

Those NULL assignments shouldn't really cause a segmentation fault in this case since clGetPlatformIDs wouldn't use the value passed rather use the reference to set the value.

After looking at the stack trace it seems libamdocl32.so is causing the problem. As soon as the host program calls a function from the library it produces a segmentation error, strangely it's not the library itself but libstdc++.so.6. Which makes me suspect whether libamdocl32.so is broken or not.

By the way the author of the tutorial mentioned

Next you need to register the ICD (note that in AMD APP 2.5, the installer does this for you). To do this open the icd-registration.tgz from the downloaded SDK and decompress it in the root folder so that you will you have a folder at /etc/OpenCL/vendors containing two .icd files.

I assumed that the author meant AMD APP 2.5 or better and skipped the aforementioned step. Can that cause the problem ??

[notzed]

the icd registration is required, but it depends on how you installed if, if you have the files in /etc/OpenCL/vendors, then that's all that matters.

The backtrace looks useless, it might be pointing to the wrong thing: if you've followed the example the command line doesn't include debugging, add -g to the compiler arguments.  Put in some printf's on the return codes, or check them to see if any function is failing.

The example could be a bit better in general, e.g. check the return codes, and not hard-coded the cl source file-size - stat() is really not that difficult to call and it's such a dangerous habit to get into (hello buffer overflows and security nightmares).

FWIW I just installed the sdk and compiled that example: and it worked fine.

[utsavgupta]

notzed wrote:

the icd registration is required, but it depends on how you installed if, if you have the files in /etc/OpenCL/vendors, then that's all that matters.

The backtrace looks useless, it might be pointing to the wrong thing: if you've followed the example the command line doesn't include debugging, add -g to the compiler arguments.  Put in some printf's on the return codes, or check them to see if any function is failing.

The example could be a bit better in general, e.g. check the return codes, and not hard-coded the cl source file-size - stat() is really not that difficult to call and it's such a dangerous habit to get into (hello buffer overflows and security nightmares).

FWIW I just installed the sdk and compiled that example: and it worked fine.

Both compilation and linking was done with -g. The problem is caused by line 41, the control is not returning to the program, I can confirm that.

I'm not at home right now but as far as I remember I only have libamdocl32.so in /etc/OpenCL/vendors. Will reinstall the SDK once I return.

Btw which distro are you using ?? Installing Catalyst on Arch was a pain to say the least.

[utsavgupta]

?

[notzed]

yeah sorry, i tried replying using email, but it seems thunderbird is even worse at editing html than this thing is, i'm not sure what it sent.

re: using -g:

Ok, pity the bt isn't showing much useful.

All I can think of is checking the errors to find out what's up, and if it isn't that, making sure you don't have some conflicting opengl library installed that it's finding instead.  use "strace -e open testprogram" to debug that.

re: which distro:

I'm using fedora - i relied on the rpmfusion packages.  I have had a lot of trouble in the past which is why I tried to avoid using the downloaded version - the 'build scripts' supplied in the download are wildly out of date and/or totally broken.  Last time I did it successfully manually I started with a build script from a freshrpm rpm (as far as i can recall).

[utsavgupta]

hmm ... Even I think it's caused by conflicting libraries. I kept on switching between Catalyst and xf86-video-ati for 2 months since fglrx wasn't working properly. And now it's OpenCL .... Aaaaargh !!

[utsavgupta]

The code is working fine with the same set of drivers on my other system.

There has to be some problem with the drivers on my Arch system.

Anyway thanks for your help notzed.

Cheers !!

[jross]

Which Catalyst drivers are you using?  I noticed with Catalyst 12.2, that AMD is now shipping libOpenCL.so, libamdocl32.so, and libamdocl64.so.  They're located in /usr/lib[64].  So if you're using the libraries that shipped with AMD APP SDK 2.6, you might be getting a segfault.  Remove $AMDAPPSDKROOT/lib/x86[_64] from your LD_LIBRARY_PATH or renaming the libraries to something else so it defaults to what is in /usr/lib[64]

[utsavgupta]

I see ... Will try it.

Thanks

[utsavgupta]

And yeah I have Catalyst 12.2

[utsavgupta]

Still ain't working ....

[jross]

What is your OS?

Run "ldd YOUR_EXECUTABLE" and tell me what it says

[utsavgupta]

Arch 32 bit

linux-gate.so.1 =>  (0xb771d000)

        /usr/lib/libamdocl32.so (0xb61ad000)

        libc.so.6 => /lib/libc.so.6 (0xb5fe1000)

        libGL.so.1 => /usr/lib/libGL.so.1 (0xb5ef5000)

        libX11.so.6 => /usr/lib/libX11.so.6 (0xb5dbf000)

        libpthread.so.0 => /lib/libpthread.so.0 (0xb5da3000)

        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb5cba000)

        librt.so.1 => /lib/librt.so.1 (0xb5cb1000)

        libdl.so.2 => /lib/libdl.so.2 (0xb5cac000)

        libm.so.6 => /lib/libm.so.6 (0xb5c80000)

        /lib/ld-linux.so.2 (0xb771e000)

        libXext.so.6 => /usr/lib/libXext.so.6 (0xb5c6c000)

        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb5c4f000)

        libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb5c31000)

        libXau.so.6 => /usr/lib/libXau.so.6 (0xb5c2d000)

        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb5c26000)

[jross]

I'm not sure why you have GL, X11, Xext, xcb, Xau, and Xdmcp unless these were automatically included with your IDE.  That shouldn't cause your problem, however.  Are you able to build and run anything that comes with the AMD APP SDK?

Your problem might be that you're not running on one of the supported Linux distributions: Linux® (openSUSE™ 11.*, Ubuntu® 10.0*, Red Hat® Enterprise Linux® 6.*).  Arch might work, but no guarantees.  I've had success with Redhat/CentOS/Scientific Linux 5.7/5.8/6/6.1 and older versions of Ubuntu.  libstdc++ might be just different enough to cause trouble.

[notzed]

        libGL.so.1 => /usr/lib/libGL.so.1 (0xb5ef5000)

Where is that libGL.so from?  If using catalyst it should be the catalyst gl (mine is in /usr/lib64/catalyst/libGL.so.1).

But this is a real problem:

        /usr/lib/libamdocl32.so (0xb61ad000)

ldd shouldn't show you linking to libamdocl*.so - the device drivers are loaded at run-time by libOpenCL.so and that is the *only* opencl library you should be linking to.  The drivers aren't designed to be called directly.

[utsavgupta]

I  installed openSUSE 11.4, installed the drivers and SDK and now its working on the system. Maybe Arch is not well supported by AMD !!

Anyway thank you notzed and jross .

Cheers !!