Package Details: opencl-mesa-minimal-git 25.2.0_devel.205806.64ce37b2d98-3

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-mesa, opencl-rusticl-mesa-minimal-git
Provides: opencl-driver, opencl-mesa
Submitter: shoober420
Maintainer: Lone_Wolf
Last Packager: Lone_Wolf
Votes: 12
Popularity: 0.163319
First Submitted: 2020-12-10 00:38 (UTC)
Last Updated: 2025-05-22 17:47 (UTC)

Required by (40)

Sources (1)

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

llvm-minimal-git
spirv-headers-git
spirv-llvm-translator-minimal-git
libclc-minimal-git
mesa-minimal-git

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.

Latest Comments

1 2 3 4 5 6 .. 9 Next › Last »

Lone_Wolf commented on 2025-06-07 16:14 (UTC)

@d3vilguard

Issue solved with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35399

I expect it will be merged soon.

Lone_Wolf commented on 2025-05-27 22:48 (UTC)

bug reported, see https://gitlab.freedesktop.org/mesa/mesa/-/issues/13257

Lone_Wolf commented on 2025-05-26 09:38 (UTC)

Yup, that's the same error.

It looks very much like a change in llvm trunk requiring changes in mesa trunk code, but I haven't had time to file a bug report with mesa and bisect llvm trunk to pinpoint the exact commit.

d3vilguard commented on 2025-05-26 08:43 (UTC)

Yeah, just saw the full log. Seems to be that. Will send you the full log on the mail if you want to take a look at it.

Lone_Wolf commented on 2025-05-26 08:31 (UTC)

Due to meson/ninja running multi-threaded the point were compilation stops is often not the point were the problem occurs.

I need to see the whole build log.

d3vilguard commented on 2025-05-26 04:59 (UTC) (edited on 2025-05-26 04:59 (UTC) by d3vilguard)

No. It has no problem compiling with these compiled 1-2 weeks ago:

llvm-minimal-git-21.0.0_r537099.95335fefd866
libclc-minimal-git-21.0.0_r537099.95335fefd866
spirv-headers-git-1:1.4.313.0.r7.g6d0784e
spirv-llvm-translator-minimal-git-1:r2268.011108c

Any rebases of LLVM and the gang after that lead to the same fail building mesa. It is compiling in src/amd/llvm/ and always fails at:

Compiling C++ object src/amd/llvm/libamd_common_llvm.a.p/ac_llvm_helper.cpp.o

I'm also compiling a somewhat even more minimal-minimal mesa. 

-D gallium-drivers=radeonsi,zink \
-D vulkan-drivers=amd,swrast \

Will try yet another LLVM rebase and will report back.

Lone_Wolf commented on 2025-05-25 20:13 (UTC)

Is 

../mesa/src/compiler/clc/clc_helpers.cpp: In function ‘std::unique_ptr<llvm::Module> clc_compile_to_llvm_module(llvm::LLVMContext&, const clc_compile_args*, const clc_logger*, set*)’:
../mesa/src/compiler/clc/clc_helpers.cpp:807:63: error: no matching function for call to ‘clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_string_ostream&, clang::DiagnosticOptions*)’
  807 |                                        &c->getDiagnosticOpts())
      |                                                               ^
../mesa/src/compiler/clc/clc_helpers.cpp:807:63: note: there is 1 candidate
In file included from ../mesa/src/compiler/clc/clc_helpers.cpp:54:
/usr/include/clang/Frontend/TextDiagnosticPrinter.h:41:3: note: candidate 1: ‘clang::TextDiagnosticPrinter::TextDiagnosticPrinter(llvm::raw_ostream&, clang::DiagnosticOptions&, bool)’
   41 |   TextDiagnosticPrinter(raw_ostream &os, DiagnosticOptions &DiagOpts,
      |   ^~~~~~~~~~~~~~~~~~~~~
/usr/include/clang/Frontend/TextDiagnosticPrinter.h:41:61: note: no known conversion for argument 2 from ‘clang::DiagnosticOptions*’ to ‘clang::DiagnosticOptions&’
   41 |   TextDiagnosticPrinter(raw_ostream &os, DiagnosticOptions &DiagOpts,
      |                                          ~~~~~~~~~~~~~~~~~~~^~~~~~~~
../mesa/src/compiler/clc/clc_helpers.cpp:808:4: error: no matching function for call to ‘clang::DiagnosticsEngine::DiagnosticsEngine(<brace-enclosed initializer list>)’
  808 |    };
      |    ^
../mesa/src/compiler/clc/clc_helpers.cpp:808:4: note: there is 1 candidate

the error you get ?

d3vilguard commented on 2025-05-25 05:08 (UTC)

At the moment with anything past llvm 95335fefd866 the build fails for AMD:

[773/1784] Compiling C++ object src/amd/llvm/libamd_common_llvm.a.p/ac_llvm_helper.cpp.o
ninja: build stopped: subcommand failed.

No idea if llvm, spirv or mesa fails it. With the above llvm-minimal-git and spirv g6d0784e, spirv-l-trans 011108c mesa builds.

ph34rb0t commented on 2024-12-31 01:49 (UTC) (edited on 2024-12-31 01:50 (UTC) by ph34rb0t)

Mesa-minimal (and other flavors) started building again for some reason. Maybe the downgrade and reinstall of rust (from "Extras") had some effect (I did not do anything else).

Lone_Wolf commented on 2024-12-29 10:29 (UTC) (edited on 2024-12-29 10:29 (UTC) by Lone_Wolf)

The gentoo ticket dooes seem relevant, but Archlinux rust package version is 1:1.83.0-1 , depends on llvm-libs 18.1.8-5 and works for me .

maybe there's something in your build environment that screws up things, please post the full build logs somewhere public .

1 2 3 4 5 6 .. 9 Next › Last »