AMD stream sdk 1.3_beta has been released and I've been working to get it (compile when needed) install and run. I also created patches for gcc >= 4.3 I decided to split the installation into two ebuilds: one for the CAL stuff (primarly headers, since libraries are now integrated into the ATi drivers), and another that builds and installs Brook+ (the compiler) First of all because someone may just need CAL and not brook, second because it's simpler to build Brook+ against CAL, doing so. I am now going to upload the ebuilds. (Forgot to specify: on AMD64 it works (for me :)) ) Reproducible: Always
Created attachment 180924 [details] The AMD - Cal ebuild Here it is the ebuild that installs CAL (headers, docs and samples). It doesn't actually build samples. Should I move samples to a pertinent /usr/share/{PN}/ directory??
Created attachment 180926 [details, diff] Patch to compile samples and brook agains CAL using gcc >= 4.3 Here is the patch that makes everything that build against CAL compile. Can I make it optional, looking at the compiler that will actually compile the whole thing?
Created attachment 180928 [details] Brook+ ebuild Here it is the ebuild that (patches and) compiles Brook+. The examples are put into /usr/local/amdbrook/ Shuold I move that destination to a /usr/share pertinent directory like for CAL samples??
Created attachment 180930 [details, diff] Patch that makes Brook+ compile by gcc >= 4.3 Here is the patch for the brook compiler.
Created attachment 180933 [details, diff] Patch for compiling Brook samples with gcc >= 4.3 here it is the patch for brook samples with gcc 4.3
Oooh shiny :)
Created attachment 181011 [details, diff] Patch to compile samples and brook agains CAL using gcc >= 4.3 (revised) I'm sorry, but with the previous patch I introduced a silent but inappropriate modification. Not sure it could have malicious behaviour, since it was just a "unsigned int" => "int", but to be fair I corrected it.
The ebuilds form amd-stream-brook and amd-stream-cal are missing a build-time dependency to app-arch/rpm2targz. Unpacking fails if the package is not installed... Also compiling amd-stream-brook fails for me due to 'utils' not being a valid target when building 'platform'. The 'utils' directory does - in fact - not include a Makefile on it's own but is referenced in the primary Makefile.
Created attachment 203466 [details] atistream-cal-1.4.0_beta.ebuild
Created attachment 203467 [details, diff] gcc-4.3-atical.patch patch file needed for atistream-cal-1.4.0_beta.ebuild
Created attachment 203468 [details] atistream-brook-1.4.1.ebuild
Created attachment 203470 [details, diff] gcc-4.3-atibrook-platform.patch needed by atistream-brook-1.4.1.ebuild
Created attachment 203472 [details, diff] gcc-4.3-atibrook-samples.patch needed by atistream-brook-1.4.1.ebuild
http://developer.amd.com/gpu/ATIStreamSDK/Pages/default.aspx#five Upstream released 2.0 version :( Ebuild why this does not include a tree?
Current sdk release is 2.4 (based on ati-drivers 11.4) Time permitting, I'll look into getting a working ebuild (based on existing ebuilds in this bug and in the pentoo overlay) some time later this month.
I think a AMD APP SDK 2.4 ebuild has already been submitted in the following bug http://bugs.gentoo.org/show_bug.cgi?id=304903
*** Bug 304903 has been marked as a duplicate of this bug. ***
Just as side note, amd implementation AMD-APP-SDK-2.4 seems to lack clGetProgamInfo, so it is useless for dependency purposes where the wrapper expects a complete api.
Nvm, seems that no one ever has bothered to actually link haskell openclraw wrappers, as they have typos in function names...
Created attachment 282789 [details] amd-app-sdk v2.5 ebuild Updated ati-stream-sdk-bin-2.4.ebuild diff: add x86 sources and keyword (not tested) add src_unpack due to archive is double gziped
Created attachment 296511 [details] amd-app-sdk-2.5.ebuild I modified the parent ebuild (still probably not useful for portage, until it is decided whether or not to add eselect-opencl or not). Removed redundant files found in other packages (eg. >=ati-drivers-11.11). Moved the CL includes to /usr/. Repoman fixes. Added OpenCL.so symlinks. At least wine[opencl] builds fine with lib symlinks and headers.
Created attachment 296715 [details] amd-app-sdk-2.6.ebuild Well, here goes my first submitted ebuild (based off of emil karlson's) CHANGELOG: -Updated links and files SDK 2.6 -Updated ati-drivers requirement to >=11.12 -Updated section in src_install() -Updated include/OVDecode to include/OpenVideo -Fixed a syntax error that prevented unpacking in src_unpack()
Created attachment 309633 [details] Ebuild for version 2.6 (dev-util/amdapp/amdapp-2.6-r1.ebuild) I use AMD APP on machines without an AMD gpu to run OpenCL code on the CPU. I keep my development on github: https://github.com/nbigaouette/ebuilds/tree/master/dev-util/amdapp and is available in my overlay too (nbigaouette). I'm uploading here the version I am using, both on a workstation with nvidia cards and on a cluster without any video cards. Main differences with Petronio Coelho's amd-app-sdk-2.6.ebuild: 1) Uses EAPI=4 2) Store variables for the different packages/architectures at top instead of duplicating it in the functions 3) No livecd use flag. This one shouldn't be used according to http://www.gentoo.org/dyn/use-index.xml and is also not used in the ebuild... 4) Installs in /usr/lib/amd instead of /opt/amd-app-sdk. I cannot use the package on my cluster if it is installed in /opt as /usr is NFS exported but not /opt. 5) More use flags: -examples: Compile the OpenCL examples -profiler: Install the profiler provided -eselect: Will use app-admin/eselect-opencl to provide libOpenCL.so 6) RESTRICT += mirror because it's not on the mirrors... 7) Two patches (from https://aur.archlinux.org/packages.php?ID=21933) 8) Creates an /etc/ld.so.conf.d/ entry so it can find its libraries There is an issue though. Creating an OpenCL command queue will fail with: ../../../thread/semaphore.cpp:87: sem_wait() failed This is an issue with v2.6 and is caused by a conflict between AMD and Nvidia drivers. A workaround is to use LD_LIBRARY_PATH to point to mesa's directory containing libGL.so. For example: $ LD_LIBRARY_PATH=/usr/lib64/opengl/xorg-x11/lib ./my_code will work fine. See http://devgurus.amd.com/thread/158568 I think such a workaround could go into the ebuild, but I'm not sure how. Any comments?
Created attachment 310087 [details] dev-util/amdapp/amdapp-2.6-r3.ebuild Uploaded an updated version (see commit f4728a10a0de866d08485016a84346d548797a23 from https://github.com/nbigaouette/ebuilds/tree/master/dev-util/amdapp ) Changes from amdapp-2.6-r1.ebuild to amdapp-2.6-r3.ebuild: -Add entry in /etc/revdep-rebuild/ to prevent revdep_rebuild from always trying to rebuild. -Add a "mesa" use flag to fix the "semaphore.cpp:87: sem_wait() failed" issue when Nvidia drivers is installed (and "eselect opengl" is set to nvidia). For this, uses dev-util/patchelf to patch libamdocl{32,64}.so for setting explicitly their RPATH to point to Mesa's libGL.so. There might be a better way to set the /etc/revdep-rebuild/ entries...
What's the status? I see 2.8.1 on "anyc" overlay: http://gpo.zugaina.org/dev-util/amd-app-sdk Also, URL on amd.com has changed: it redirects to http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/
Hey there, I appreciate your efforts in getting AMD Accelerated Parallel Processing SDK up and running, especially with the new package release. It's great that you've created patches for gcc >= 4.3 and split the installation into two ebuilds for CAL and Brook+ to provide users with more flexibility. Regarding the issue you've encountered, it's crucial to address these dependency and compilation problems. The missing build-time dependency to app-arch/rpm2targz seems like a straightforward fix, and your initiative to upload the ebuilds is commendable. As for the 'utils' not being a valid target during the compilation of amd-stream-brook, it appears to be a structural problem within the Makefile. To resolve this, you might want to investigate the Makefile references and ensure that 'utils' is correctly defined as a target or included as part of another target's build process. You can explore this: https://andersenlab.de/services/andersen-saas-development-services I've faced similar issues in the past, and my advice would be to double-check your environment variables, paths, and the AMD SDK version you're using. Sometimes, minor adjustments in your development environment can make a significant difference. Or has that already been decided?
