Description
Nicola
2009-02-04 15:56:08 UTC
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? |