I think clang
should be added to makedepends. I had compilation error without it.
Search Criteria
Package Details: opencl-rusticl-mesa-minimal-git 24.3.0_devel.194673.5db135f66ad-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/mesa-minimal-git.git (read-only, click to copy) |
---|---|
Package Base: | mesa-minimal-git |
Description: | OpenCL support in rust for mesa drivers (git version) |
Upstream URL: | https://www.mesa3d.org |
Licenses: | MIT AND BSD-3-Clause AND SGI-B-2.0 |
Conflicts: | opencl-clover-mesa, opencl-rusticl-mesa |
Provides: | opencl-driver, opencl-rusticl-mesa |
Submitter: | shoober420 |
Maintainer: | Lone_Wolf |
Last Packager: | Lone_Wolf |
Votes: | 11 |
Popularity: | 0.010175 |
First Submitted: | 2020-12-10 00:38 (UTC) |
Last Updated: | 2024-09-11 18:17 (UTC) |
Dependencies (47)
- clang-libs-minimal-gitAUR
- clang-opencl-headers-minimal-gitAUR
- expat (expat-gitAUR)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc11-libsAUR, gcc-libs-snapshotAUR)
- glibc (glibc-gitAUR, glibc-linux4AUR, glibc-eacAUR, glibc-eac-binAUR, glibc-eac-rocoAUR)
- libclc-minimal-gitAUR
- libdrm (libdrm-gitAUR)
- libelf (elfutils-gitAUR)
- llvm-libs-minimal-gitAUR
- lm_sensors (lm_sensors-gitAUR)
- mesa-minimal-gitAUR
- spirv-llvm-translator-minimal-gitAUR
- spirv-tools (spirv-tools-gitAUR)
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compat)
- zstd (zstd-gitAUR, zstd-staticAUR)
- clang-minimal-gitAUR (make)
- clang-opencl-headers-minimal-gitAUR (make)
- elfutils (elfutils-gitAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- glslang (glslang-gitAUR) (make)
- libclc-minimal-gitAUR (make)
- libdrm (libdrm-gitAUR) (make)
- libglvnd (libglvnd-gitAUR) (make)
- libunwind (libunwind-carbonAUR, libunwind-gitAUR) (make)
- libva (libva-gitAUR, intel-media-stack-binAUR, libva-headlessAUR) (make)
- libvdpau (make)
- libx11 (libx11-gitAUR) (make)
- libxdamage (make)
- libxml2 (libxml2-gitAUR, libxml2-2.9AUR) (make)
- libxrandr (libxrandr-gitAUR) (make)
- llvm-minimal-gitAUR (make)
- meson (meson-gitAUR) (make)
- ninja (ninja-kitwareAUR, ninja-memAUR, ninja-fuchsia-gitAUR, ninja-gitAUR, ninja-jobserverAUR) (make)
- python-mako (make)
- python-packaging (make)
- python-ply (make)
- python-pyaml (make)
- rust (rust-nightlyAUR, rustup-gitAUR, rust-nightly-binAUR, rust-gitAUR, rust-beta-binAUR, rustup-stubAUR, rustup) (make)
- rust-bindgen (make)
- spirv-llvm-translator-minimal-gitAUR (make)
- spirv-tools (spirv-tools-gitAUR) (make)
- systemd-libs (systemd-chromiumos-libsAUR, systemd-libs-selinuxAUR, systemd-libs-gitAUR, systemd-libs-fmlAUR) (make)
- vulkan-icd-loader (vulkan-icd-loader-gitAUR) (make)
- wayland-protocols (wayland-protocols-gitAUR) (make)
- xcb-util-keysyms (make)
- xorgproto (xorgproto-gitAUR) (make)
- opengl-man-pages (optional) – for the OpenGL API man pages
Required by (40)
- agisoft-metashape (requires opencl-rusticl-mesa) (optional)
- agisoft-metashape-pro (requires opencl-rusticl-mesa) (optional)
- arrayfire-git (requires opencl-driver) (optional)
- computecpp (requires opencl-driver)
- cpu-x-opencl (requires opencl-driver) (optional)
- cytoscape (requires opencl-driver) (optional)
- davinci-resolve (requires opencl-driver)
- davinci-resolve-beta (requires opencl-driver)
- davinci-resolve-studio (requires opencl-driver)
- davinci-resolve-studio-beta (requires opencl-driver)
- dewobble (requires opencl-driver)
- foldingathome (requires opencl-driver) (optional)
- fusion-render-node (requires opencl-driver)
- fusion-studio (requires opencl-driver)
- gromacs (requires opencl-rusticl-mesa) (optional)
- gromacs-plumed (requires opencl-rusticl-mesa) (optional)
- gyroflow (requires opencl-driver) (optional)
- gyroflow-bin (requires opencl-driver) (optional)
- gyroflow-git (requires opencl-driver) (optional)
- khronos-ocl-icd-loader (requires opencl-driver)
- Show 20 more...
Sources (1)
amoka commented on 2021-07-04 00:55 (UTC) (edited on 2021-07-04 00:55 (UTC) by amoka)
xenu commented on 2021-03-03 08:38 (UTC)
The recently added patch '0002-fix-ac_build_atomic_rmw-with-LLVM-13.patch' can be removed again as it was merged upstream (and results in an error during prepare).
phush0 commented on 2021-02-22 13:52 (UTC)
Thank you for instructions, I have added same patch found in llvm bug tracker (proposed by you), to allow me to build.
Lone_Wolf commented on 2021-02-22 13:32 (UTC)
I've added a patch that does allow building opencl again.
Incase you still want to disable opencl , replace icd
with disabled
in the line -D gallium-opencl=icd \
phush0 commented on 2021-02-22 09:50 (UTC)
how to disable opencl building ?
Lone_Wolf commented on 2021-01-30 22:28 (UTC)
Building with opencl enabled gives a new build failure , see https://gitlab.freedesktop.org/mesa/mesa/-/issues/4200
tb0n3 commented on 2021-01-22 19:03 (UTC)
This is perfectly acceptable to me. I just wasn't aware of the change as it had worked previously and then builds suddenly required a change in dependencies. My only reason previously for maintaining llvm versus llvm-minimal-git was the complex dependency workarounds with MESA_WHICH_LLVM which didn't play well with yay, or makepkg for that matter.
Thank you for the explanation and for your work in maintaining these packages.
Lone_Wolf commented on 2021-01-22 18:36 (UTC) (edited on 2021-01-22 18:39 (UTC) by Lone_Wolf)
Why does this package hard depend on llvm-minimal-git ?
performance
archlinux repo packages are build with -march=x86-64 -mtune=generic
which works on lots of machines but makes limited use of modern processor capabilities. For many packages this has little impact, but with llvm my experience is different.
My local builds for llvm / mesa are done with -march=native
and this has a noticeable effect on their performance.
How big the benefit of this is depends heavily on the exact hardware you use. Worse, the software setup also impacts this. The only way to find out if it benefits your system/software setup is to try it out yourself.
easier maintenance and troubleshooting
Since i started my first mesa trunk package late in 2010 I have maintained versions without any llvm, one llvm implementation, split versions, singular versions, versions supporting multiple llvm implementations , switch from libgl hacks libglvnd to allow mesa & nvidia to cooperate etc.
Depending on one llvm variant in a non-splitted singular version results in a simple PKGBUILD that is easy to maintain.
Troubleshooting is also much easier if maintainer uses the same llvm variant as users.
If people feel those reasons are not good enough to hard depend on llvm-minimal-git , maybe I should transfer ownership .
tb0n3 commented on 2021-01-21 15:39 (UTC)
Is there a reason you now require llvm-minimal-git when regular llvm from the standard repos builds fine? I'd be fine if there was a bug or build reason, but I haven't seen evidence of breakage.
Lone_Wolf commented on 2021-01-09 15:02 (UTC)
Why does this exist ?
Basically mesa/mesa-git build almost everything they can build.
This package tries to build just enough so everyone can use it, but disables older and/or unused components.
Check https://bbs.archlinux.org/viewtopic.php?id=261629 for a discussion about this package.
Pinned Comments
Lone_Wolf commented on 2023-05-22 12:07 (UTC) (edited on 2024-09-06 21:16 (UTC) by Lone_Wolf)
Build order
N.B. these packages are closely tied together, make sure you build all of them in a short period of time (worst case on my system is around 3 hours) .
Build frequency
I aim to build everything (including the lib32 part) atleast once a week.
How often you build this is a personal choice, but once a month is in my opinion the absolute minimum .
In that timeframe mesa will have seen almost 1k commits, llvm/clang gets more.
Lone_Wolf commented on 2021-01-22 18:36 (UTC) (edited on 2021-01-22 18:39 (UTC) by Lone_Wolf)
Why does this package hard depend on llvm-minimal-git ?
performance
archlinux repo packages are build with
-march=x86-64 -mtune=generic
which works on lots of machines but makes limited use of modern processor capabilities. For many packages this has little impact, but with llvm my experience is different.My local builds for llvm / mesa are done with
-march=native
and this has a noticeable effect on their performance.How big the benefit of this is depends heavily on the exact hardware you use. Worse, the software setup also impacts this. The only way to find out if it benefits your system/software setup is to try it out yourself.
easier maintenance and troubleshooting
Since i started my first mesa trunk package late in 2010 I have maintained versions without any llvm, one llvm implementation, split versions, singular versions, versions supporting multiple llvm implementations , switch from libgl hacks libglvnd to allow mesa & nvidia to cooperate etc.
Depending on one llvm variant in a non-splitted singular version results in a simple PKGBUILD that is easy to maintain.
Troubleshooting is also much easier if maintainer uses the same llvm variant as users.
If people feel those reasons are not good enough to hard depend on llvm-minimal-git , maybe I should transfer ownership .
Lone_Wolf commented on 2021-01-09 15:02 (UTC)
Why does this exist ?
Basically mesa/mesa-git build almost everything they can build.
This package tries to build just enough so everyone can use it, but disables older and/or unused components.
Check https://bbs.archlinux.org/viewtopic.php?id=261629 for a discussion about this package.