cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

nou
Exemplar

ATI Stream SDK 2.3

ok we have now SDK 2.3 here. you can download packages from my thread.

just quick test show that we have working DMA now.

EDIT: i am sorry i encounter to some errors with new SDK. so do not install my packages for now.

0 Likes
39 Replies
HarryH
Journeyman III

What kind of problems, SDK not working, or problems creating your packages?

0 Likes

Anyway, just wait until the official release

0 Likes

ok find why i get that error. enviroment variable LD_LIBRARY_PATH must be set otherwise it wont work. this is stupid.

0 Likes

LD_LIBRARY_PATH can't be set system wide in Ubuntu (for security reasons). so why AMD team rely on this ugly solution.

another things is that hardcoded path to x86 x86_64 subdirectories. you can't get clean nice integration into the system.

0 Likes

As a workaround, you may export it in /etc/bash.bashrc or whatever the Ubuntu default shell uses.

0 Likes

yes but it will not set env for application which i run via doubleclickor from menu. only when irun via bash terminal. i wonder why is mandatory to have set LD_LIBRARY_PATH

0 Likes

Well I guess you won't need it if you copy all the needed shared libraries in /usr/lib. But that's not at all a good solution.

0 Likes

why not. my package is doing so. IMHO this should be a standart solution. or add it to ld.conf

0 Likes
pulec
Journeyman III

Originally posted by: nou yes but it will not set env for application which i run via doubleclickor from menu. only when irun via bash terminal. i wonder why is mandatory to have set LD_LIBRARY_PATH

 

 

I place the LD_LIBRARY_PATH variable definition into ~/.gnomerc. It is still not standard solution, but allows at least running OpenCL applications anywhere from session (not only terminal). From my point of view it is the relativelly cleanest solution.

0 Likes

Nice find! Using the 2.3 SDK (on linux) just automagically solved a bug I have been trying to hunt down for quite a while now.

0 Likes

hi,

Sorry for doing so stupid question, but... where is the download link for SDK 2.3 (the official page still shows 2.2 to me...)

best regards,

Alfonso

0 Likes

2.3 hasn't 'officially' been released yet. When it has, the page will be updated.
0 Likes

hope you change that behaviour that it expect that LD_LIBRARY_PATH is set.

0 Likes

A list of bugs/issues I found with 2.3 preview:

1) it reinstalls SIGINT handler thus messing up my signal handling. When I press ctrl-c it dies immediately with "compilation terminated" message instead of firing up my graceful shutdown function.

2) When I set GPU_DUMP_DEVICE_KERNEL=3, it dumps ISA/IL code for kernels I have not executed in the same directory (is that a feature?)

3) sdk 2.3 is slower than 2.2 for about 1.7-1.8%

4) wrong values returned by clgetdeviceinfo

5) random crashes when the runtime frees memory (hard to reproduce).

 

0 Likes

Originally posted by: nou hope you change that behaviour that it expect that LD_LIBRARY_PATH is set.

 

+1 here.

0 Likes

gat3way,
for your #2, that is because GPU_DUMP_DEVICE_KERNEL is a compiler option, not a runtime option. All it requires is that you compile the kernel, not execute it. For the other issues, please email stream.developer@amd.com with examples or more information.
0 Likes

I know but each time I run my program with that option, together with my kernels' ISA and IL dumps I get also about 10 more dumps of kernels that I think are used in MemoryOptimizations sample (like copyBufferToImage2D, copy1Dfloat4, etc). And I have not executed them. I delete all the dumps, run again my program and I get them again in the same directory. That's pretty strange.

 

 

0 Likes

Woohoo!  My program now works without making the compiler explode!  Kudos to the ATI dev team!

0 Likes

you have not updated instalation notes on the web and in linux tar.

but i found why most likely LD_LIBRARY_PATH is mandatory now. it seems that you get rid of ATISTREAMSDKROOT.

so now to get access to builtins-evergreen.bc  builtins-gpucommon.bc  builtins-7xx.bc it must in some way parse LD_LIBRARY_PATH.

0 Likes

Originally posted by: nou you have not updated instalation notes on the web and in linux tar.

 

but i found why most likely LD_LIBRARY_PATH is mandatory now. it seems that you get rid of ATISTREAMSDKROOT.

 

so now to get access to builtins-evergreen.bc  builtins-gpucommon.bc  builtins-7xx.bc it must in some way parse LD_LIBRARY_PATH.

EDIT: ok, fixed it myself. the one thing to do is to put libOpencl.so in both /usr/lib and /usr/local/lib/x86_64. the same thing goes for libatiocl64.so

i don't know if they are needed in /usr/lib, maybe for linking my own opencl programs.

Hi nou.

I have updated to 2.3 and put the files according to your .deb. CAL FindNumDevices shows 2 GPUs (I have 2xHD5870). And CLInfo (run from /home//ati-sdk/samples/opencl/bin/x86_64/CLInfo) shows 3 devices, 2 gpu+1 cpu, under platform. But the device info listing gives "ERROR: clBuildProgram(-11)" after "Local memory size: 32768".

I guess that this is because of missing path to either clc, libOpencl.so or builtins*.bc. Do you know how to fix this? Thanks.

0 Likes

eklund.no you have set LD_LIBRARY_PATH? because i don't find a way to prevent from set it.

0 Likes

yes, I have set LD_LIBRARY_PATH=/usr/local/lib/x86_64

both in /etc/bash.bashrc and in ~/.bashrc

 

EDIT: my edit from previous post has been removed. here it is again:

"I got it to work by adding 'atisdk/lib/x86_64/libOpenCL.so' and 'atisdk/lib/x86_64/libatiocl64.so' to '/usr/local/lib/x86_64', not only to '/usr/lib'.

I don't know if it's needed in '/usr/lib', maybe for easy compiling and linking of own apps.

'export LD_LIBRARY_PATH=/usr/local/lib/x86_64' is added to both '/etc/bash.bashrc' and '~/.bashrc' and now it works."

0 Likes
jhabig
Journeyman III

Hi nou,

An easy efficient way to set the LD_LIBRARY_PATH globally is to create a file  /etc/ld.so.conf.d/atistreamsdk.conf containing just one line /usr/local/lib/x86_64

That solved the problems for me without messing around in .bashrc or something like this.

 

Maybe you want to include this in a future release of your package

 

 

0 Likes

oh filename must end with *.conf. i tryed create file /etc/ld.so.conf/ati-opencl-runtime but it didn't work. with conf it works. so i uploaded fixed version of my packages now. thanks

0 Likes
jhabig
Journeyman III

Hi nou, thanks for the quick integration. I already created myself a .deb and finished just hen I saw you reply

Anyway, there is still some work to do. I find myself in the situation of using nVidia graphics and intel cpu running ubuntu on a macbook. The problem is, that your package conflicts with the nVidia package, as they both intend to install the libOpenCL.so (or whatever the name is).

My package has a quick and dirty workaround, it just assumes the nVidia driver is installed, i.e. I don't include the file. This is not very comfortable. I'm not exactly new to Linux, but I don't create packages much. Maybe you know of a way to optionally not install the file, dependending on whether the nVidia (and in the future possibly intel) implementation is present?

It's quite a mess to have a package for every possible scenario,...

 

Anyway, have a nice xmas eve,

Jan

0 Likes

well one solution is move libOpenCL.so to another directory where ld can find it. for example right next to libatiocl64.so

0 Likes
ravikeshri
Journeyman III

Nou, are you able to share your DMA test with us? Or can anyone else provide a small sample that demonstrates DMA with SDK 2.3? Thanks.

0 Likes

just run PCIeBandwith from SDK examples. previous i got ~2 up 1 down GB/s now i got 4 down 4 up GB/s

0 Likes

I have downloaded win7 64 bit exe (twice) but when I run it I get "not windows exe".  I have the same problem with sdk 2.2. Can anyone offer me an idae of what I am doning wrong.

0 Likes

do you have 64 bit windows?

0 Likes
Dave_M
Journeyman III

http://newsimg.bbc.co.uk/media/images/39819000/jpg/_39819421_oliver_twist270.jpg

'Please, sir, I want some more.' OVDecode.so

it seems very Oliver Twist of The Lead AMD Developers with this Christmas SDK release to choose to Give windows developer's the Full OVDecode lib and header's as standard....

But NOT also give equal access to the poor Oliver Twist developing on  Linux, (in desperate Need of at least one  fully Working simple Open Video API and Library) this required OVDecode.so along side the headers you do actually supply in v2.3-lnx32.

to be clear: You DO Not supply this required OVDecode.so so we cant make use of the OVDecode headers you do supply 

can we please have an ETA of and when the AMD lead developers Intend to compile and  Actually supply This desperately needed OVDecode.so Open Video API library for Linux developers to finally be in an equal position to try and write and test some basic AVC HD L4.1 example OpenCL Video Decode app's as windows developers are able to do right now...

 

0 Likes

I have win 7 64bit pro

I think my problem might from a corrupted down load. I have downloaded 3 times an each one is a little different in size. I ran a program called FastSum to get the check digits but they don't match those published.

 

I just found FastSum on the net - can anyone recommend a checksum checking program that I should use please

0 Likes

Follow up

I succesffult loaded the sdk down with IE 8 - it was corrupt on each of 3 attempts with Firefox

0 Likes

tonyo_au,

I have used Firefox 3.6 to download my copy of sdk 2.3. It works fine for me. Did you use some older firefox version?

0 Likes

What happened to the 5970 support? I realise Cayman support must have taken a lot of dev time, but this is the one chance for AMD to have a top-end GPGPU card that can beat the competition, and you are throwing it away for lack of a minor driver enhancement! I have been trying to get developers in my industry to consider trying out Antilles-powered workstations for GPGPU, but if this vital driver support is still AWOL when that product comes out, I will have no choice but to write AMD off as a serious competitor.

0 Likes

http://forums.amd.com/devforum/messageview.cfm?catid=390&threadid=143851&STARTPAGE=2

it seems that it is little better now.

0 Likes

I thought that I might write my initial results of 2.3 versus 2.2 regarding performance and time.

I have made some quite extensive timing measurements on SDK 2.2 + catalyst 10.9 for two different apps with different hosts. The only thing with this combo that stuck out was the long return time of clEnqueueNDRangeKernel() in the first host. It was over 4 ms for GPU, all other types were in the 4-12 µs (CPU, nVidia, host nbr 2).

The hosts are structured in three parts: setup, kernel_run and clean_up. The setup part creates contexts/queues/kernels/mem_objects. The kernel_run part writes input data, executes kernels and read output data. The clean_up part releases stuff. This structure makes it possible to run the kernel_run part many times on different input data.

Ok, so what differences do I see between 2.2+10.9 and 2.3+10.12? The return time from clEnqueueNDRangeKernel() is fixed and is now 16 µs, so at this item 2.3 is faster. But the host setup for GPU has become slower. The setup part of host 1 took 630 ms on 2.2, now it takes 770 ms. For host 2 it took 160 ms on 2.2, now it takes 290 ms on 2.3. When I alter host 1 to use 2 devices it previously took 1200 ms on 2.2, now 1430 ms on 2.3.

The feel is that 2.3+10.12 is a more stable/even platform, but with increased overhead at host setup.

0 Likes

Originally posted by: Starglider What happened to the 5970 support? I realise Cayman support must have taken a lot of dev time, but this is the one chance for AMD to have a top-end GPGPU card that can beat the competition, and you are throwing it away for lack of a minor driver enhancement! I have been trying to get developers in my industry to consider trying out Antilles-powered workstations for GPGPU, but if this vital driver support is still AWOL when that product comes out, I will have no choice but to write AMD off as a serious competitor.

 

I would like to join Starglider's opinion. Since AMD does not follow monolithic chip strategy (which is good and bad at the same time), if it wants to compete whatsoever in the GPGPU segment, it would have to officially support both devices of dual GPU solutions. I am trying to force AMD to be considered a viable alternative to NV cards, but sometimes driver and SDK support (and performance) do get in the way. I believe the VLIW architecture can really beat the scalar architecture in NV cards, so AMD should pay a little more attention to software support of their products.

0 Likes