Package Details: vkbasalt

Git Clone URL: (read-only, click to copy)
Package Base: vkbasalt
Description: A Vulkan post-processing layer. Some of the effects are CAS, FXAA, SMAA, deband.
Upstream URL:
Licenses: zlib
Submitter: gee
Maintainer: gee
Last Packager: gee
Votes: 39
Popularity: 1.73
First Submitted: 2019-10-21 10:32 (UTC)
Last Updated: 2022-07-30 00:13 (UTC)

Latest Comments

gee commented on 2022-02-28 05:36 (UTC)

@blurgy Hey there, sure thing it's done. Please tell me if I missed something. (There's no need to duplicate messages between here and the lib32 though. :) )

blurgy commented on 2022-02-27 15:53 (UTC)

Hello, please change the command ninja install -C build to ninja -C build install in the package() function. For people using ninja-samurai (it supports SAMUFLAGS variable to set jobs), it seems that the -C option must be supplied right after ninja. Thanks!

guglovich commented on 2022-02-19 18:50 (UTC)

Please change the installation directory from /usr as this directory is on the blacklist in Proton above version 5.13.

yochananmarqos commented on 2020-11-07 01:10 (UTC)

@gee: I still think you're missing something. Whether the PKGBUILD is split or not does not change the packages themselves. The dependencies will not change, there's no transition at all. Since they won't change, you could split them apart with no pkgrel() bump because the build process did not change.

gee commented on 2020-11-07 00:55 (UTC) (edited on 2020-11-10 22:19 (UTC) by gee)

@yochananmarqos: yeah I'm more nuanced about this than you... I understand your point, and live by it to an extent, but I don't want to break functionality and waste users' time if it can be prevented. Of course, this is also AUR, not quite the best place for people that don't want to read.

So what I think I'll do is either: - give it about a week and do it, and add a note in the post-install step for 64b. - do it right away but make the dependencies circular for a week or so before removing that.

Since I'd rather not do extra work, I'll probably go with the first. Anyway, we've both spent too much time on this topic already, it is not worth it. :)

Yeah, I still think makepkg should support split package for archs, if not it's just full of redundant stuff for no reason...

yochananmarqos commented on 2020-11-06 23:15 (UTC)

@gee: We're package maintainers, not hand-holders. It's not up to use to write them a tutorial. That's what the upstream README is for. All the other lib32- packages in the Arch repos are separate packages.

I originally thought it would be easier to maintain as a split package since mangohud-git was, but you helped me realize it's not the greatest idea in the world to mix different architecture packages together.

gee commented on 2020-11-06 22:23 (UTC) (edited on 2020-11-06 22:27 (UTC) by gee)

@yochananmarqos: Hmmm I am not sure we are talking about the same thing. What I mean is that if I split this vkBasalt page (/PKGBUILD) from being a single package to having the 32b on a different page (/PKGBUILD), I'm afraid some people will see not understand why things don't work with 32b games anymore unless they manually grab the 32b PKGBUILD too. I'm talking about a single package because some people may have not yet grabbed the 32/64b package split yet, which is transparent indeed, and which is what I'm hoping will allow a smoother transition if given time.

yochananmarqos commented on 2020-11-06 22:15 (UTC)

@gee: Again, the split package is transparent. They'll still see the update no matter if the packages are split or not.

gee commented on 2020-11-06 22:10 (UTC)

@yochananmarqos: Sad :/ I guess I'll wait a little bit for people to get the current update that'll give them the 32b before doing the proper split then which hopefully should be straightforward then.

Thank you for your help!

yochananmarqos commented on 2020-11-06 21:51 (UTC)

@gee: No, they'll only appear together when they're part of a split package. Other than this page, split packages are normally transparent to the user, anyway. Just list vkbasalt as a dependency of lib32-vkbasalt as is common for packages like these.

gee commented on 2020-11-06 20:03 (UTC)

@yochananmarqos: Cool! Is there a way to somehow keep this page connected to the lib32 one with such a split? I don't want people in the future to update vkBasaslt and lose the 32b part and not know why... If not I may wait a few weeks before making this transition.

But yeah, like you I wish I could do all that in one single file, it seems clearer, and it's less stuff to download (not that this is a big software, but I want to think even here it should matter).

yochananmarqos commented on 2020-11-06 19:53 (UTC)

@gee: Good point, it appears Arch doesn't include different architectures in split packages. When I was Co-Maintainer for gamemode / lib32-gamemode, we had it as a split package, but the Arch community maintainer split it since he imported it. I've now split them: vkbasalt / lib32-vkbasalt

gee commented on 2020-11-05 04:45 (UTC)


  • Alright for meson install, when I started this package it had to be manually done and I never kept up with the changes.

  • Well that's for split packages built in one go, in this case we double build, once for 32b and once for 64b, all that is shared is the initial source, similarly to how split the mesa and lib32-mesa sources are.

I'd be happy to have the rest of your comments when you have the time.

Thank you!

yochananmarqos commented on 2020-11-05 04:02 (UTC)

@gee: I updated my PKGBUILD, forgot dependency arrangement.

For split packages, there is one build() function for multiple packages with one source. That's the whole point.

It's been a long day, I wanted to point out some more things, but now I'm too tired. Please look over my PKGBUILD again. If you have questions, see the Arch wiki and feel free to ask me any questions you may have.

gee commented on 2020-11-04 21:19 (UTC)

@yochananmarqos: Alright it's done. I think in the future it'd probably be good to also split the build parts so that people that don't care about 32b don't have to install 32b dependencies or manually mess with the PKGBUILD. What do you think?


gee commented on 2020-11-04 19:26 (UTC)

@yochananmarqos: that's a good idea I think, when I update the package in a bit I'll do this if you don't mind. Thanks!

yochananmarqos commented on 2020-11-04 18:58 (UTC)

@gee: I've created a split package, see my PKGBUILD.

gee commented on 2020-06-26 23:42 (UTC)

As written before, there is no need to flag the package, I get the notification as soon as a new version is released.

gee commented on 2020-05-17 13:45 (UTC)

@DadSchoorse awesome, thank you!

If you ever feel like taking this over, feel free to ask since it's your baby. :)

DadSchoorse commented on 2020-05-17 11:28 (UTC) (edited on 2020-05-17 11:28 (UTC) by DadSchoorse)

Just a few notes: the reshade source is unnecessary, everything has been moved into the main repo and the dependency on vulkan-tools isn't needed

gee commented on 2020-05-17 02:32 (UTC)

This isn't supposed to be a dev package, so I didn't want to update it again till a release came about, but it seems it doesn't build anymore, probably because of GCC 10, so might as well.

Thank you @frankyboy for giving me a summary of the changes and saving me the time!

I have not tried the 32b version yet or even the 64b extensively, so please tell me if I made a mistake somewhere.

frankyboy commented on 2020-05-16 20:09 (UTC)

build type changed to meson :) Also includes the shaders in the binary so a shader directory isn't needed anymore.

gee commented on 2020-04-09 19:53 (UTC) (edited on 2020-04-09 19:53 (UTC) by gee)

@I'm happy this work for you now @bajczyk, but please remember the real heros are the ones writing the code to make it work/build, not the ones doing the simple PKGBUILD stuff. :)

bajczyk commented on 2020-04-09 19:06 (UTC)

Hi guys, I just want to thank you for this work, you're awesome :D it compiles now, so thanks to you I can finally enjoy image sharpening!

gee commented on 2020-04-08 01:26 (UTC)

@yochananmarqos It's all good.

Well, I didn't want to force the newer dev version onto people that had a fine stable build, that's why I didn't do what you're suggesting. But maybe I shouldn't worry too much about that and let people ignore this or not as they want.

As for reshade, that's cool, it was annoying and error-prone to do it manually thank you!

yochananmarqos commented on 2020-04-08 01:18 (UTC)

@gee: Ha, I commented without even looking at the changes. Sorry, my mind is on other things.

What you did of course is what I was talking about. However, since its a release tag + a commit after, add a pkgver() function:

pkgver() {
  cd ${srcdir}/vkBasalt
  git describe --tags | sed 's/^v//;s/-/+/g'

You don't have to specify a commit for reshade since it's a nested submodule. It will automatically pull the right commit.

Hooray, it builds!

gee commented on 2020-04-08 01:06 (UTC)

@yochananmarqos wow that was super quick! Well that's kind of what I did, but I didn't want to force people with a working build to now use a dev one, in case there are issues. Not sure if the releases are actually tested and supposed to be more stable that your everyday commit though.

What do you think?

Thank you very much!

yochananmarqos commented on 2020-04-08 01:02 (UTC)

@gee You can still maintain this package as a "stable" release, but use a specific commit instead of the release tarball. See the gtk3 package for an example.

gee commented on 2020-04-08 01:00 (UTC)

I grabbed your change bpierre since it's the 2nd time you mention this, but it won't fix any problem with building, and all you need to do to see the actual error is scroll up. I think you should start that discussion upstream though. :)

As for the build break, that's the joy of using a bleeding edge distribution. I switched to a newer commit that builds fine, but now the version is lying... It'd be cleaner to switch to a git package but it'd also be annoying to go back and forth the two as one works and not the other. I didn't want to increment the version because for people that already have it built, they shouldn't change anything. I hope that's acceptable for now.

bpierre commented on 2020-04-07 21:50 (UTC)

Patch to not use the top-level makefile compile rule:

 PKGBUILD | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git i/PKGBUILD w/PKGBUILD
index 6f92ec2..d50582a 100644
@@ -28,7 +28,10 @@ prepare() {
 build() {
   cd ${srcdir}/vkBasalt

+  for subdir in src shader;
+  do
+    CXXFLAGS="$CXXFLAGS -fPIC" make -C $subdir
+  done

 package() {

bpierre commented on 2020-04-07 21:45 (UTC)

From what I remember, when I had issue installing vkbasalt, the top-level makefile is crap: the default compile rules ignore the error codes of running make recursively for src and shaders, and so the build will proceed as normal until makepkg tries to package a library that was never built. So check the full log for earlier errors. Note that the install rule is similarly borked.

damachine commented on 2020-04-07 21:39 (UTC)

any fix solution for :: "install: cannot stat 'build/': No such file or directory"

sklorpion commented on 2020-03-29 05:00 (UTC)

I've got the same error as damachine and bajczyk(pozdro). install: cannot stat 'build/': No such file or directory

bajczyk commented on 2020-03-28 15:37 (UTC)

I've got the same error as damachine. install: cannot stat 'build/': No such file or directory

damachine commented on 2020-03-24 20:58 (UTC)

install fails.

==> Betrete fakeroot Umgebung... ==> Beginne package()... install: der Aufruf von stat für 'build/' ist nicht möglich: Datei oder Verzeichnis nicht gefunden ==> FEHLER: Ein Fehler geschah in package(). Breche ab... :: Unable to build vkBasalt - makepkg exited with code: 4

PedroHLC commented on 2020-03-15 15:56 (UTC)

With 0.3.1 libx11 and lib32-libx11 were added as dependencies.

PedroHLC commented on 2020-03-08 00:49 (UTC)

==> ERROR: Cannot find the git package needed to handle git sources.

Please add git to makedepends, so it builds in clean containers.

gee commented on 2020-02-03 01:29 (UTC)

I added a package for reshade-shaders. I quickly tested it and it works for some shaders but not others.

I hope that's an acceptable state of things for now.

gee commented on 2020-02-02 22:09 (UTC)

Great, thank you for the confirmation @termuellinator .

termuellinator commented on 2020-02-02 22:02 (UTC)

-3 is now building for me, thank you! :)

gee commented on 2020-02-02 21:08 (UTC)

Thank you @rodrigo21 ! I was wondering if there was a simple hack possible but did not feel like investigating so late. :)

You don't need spirv-headers though, glslang includes those files as well (not sure why we need multiple packages with the same headers though, even glslang has multiple paths for them).

Does the current PKGBUILD work for you?

rodrigo21 commented on 2020-02-02 21:00 (UTC) (edited on 2020-02-02 21:02 (UTC) by rodrigo21)

The reshade submodules are not needed. Just add spirv-headers to depends() and add this sed to prepare(): sed -i 's|../reshade/deps/spirv/include/spirv/unified1|/usr/include/spirv/unified1|g' src/makefile

gee commented on 2020-02-02 20:43 (UTC) (edited on 2020-02-02 20:44 (UTC) by gee)

Just in case others hit this issue, I added @bpierre's workaround.

kgg15 commented on 2020-02-02 16:42 (UTC)

@bpierre: thank you, everything worked out

bpierre commented on 2020-02-02 16:23 (UTC) (edited on 2020-02-02 16:25 (UTC) by bpierre)

@kgg15: you may be hitting the same issue as me: if CXXFLAGS is set in the environment, part of the default in vkBasalt/src/makefile are ignored. This result in vkBasalt being compiled without -fPIC (unlike spirv and reshade). As a result, linking build/ fails, but because vkBasalt top-level makefile is crap (sub-directories calls to make ignore errors), the build continues...

I just patched the PKGBUILD locally:

diff --git i/PKGBUILD w/PKGBUILD
index 7ddc198..d305a13 100644
@@ -49,7 +49,7 @@ prepare() {
 build() {
   cd ${srcdir}/vkBasalt

-  make

 package() {

gee commented on 2020-02-02 13:13 (UTC)

Well I got it to build, I think it's pretty ugly though so I welcome any fix to the PKGBUILD but now I'm going to sleep, I got to wake up soon :/

I'm wondering though, would it be a good idea to add a separate PKGBUILD for reshade shaders now? It's purely data and it'd be a git package so it might be easier to just do a local pull, what do you guys think? We could also make it part of this PKGBUILD but it's like 8Mb, a lot more than this for people that are not interested...

gee commented on 2020-02-02 12:29 (UTC) (edited on 2020-02-02 12:48 (UTC) by gee)

I'm trying to update to current version, but I'm having trouble building reshade and it's getting too late for me to continue right now.

Here's my current PKGBUILD:

I'm guessing reshade is missing some sort of path but not sure where.

I'm hopeful by the time I get back to this someone else will know the fix. :)

edit: I think I know, I'm not getting all the deps for reshade. Unfortunately I don't know how to get a submodule of a submodule. Here's the current wrong PKGBUILD: if someone can fix that little issue, it'll work, well at least it builds but I didn't test.

As for the person flagging this package, you don't need to, I also get the GH notifications.

gee commented on 2019-12-03 16:27 (UTC)

@PedroHLC it should be fixed now.

PedroHLC commented on 2019-12-03 16:05 (UTC)

fatal error: gnu/stubs-32.h: No such file or directory

When building from a clean chroot...

dron1885 commented on 2019-11-29 19:24 (UTC)

Description is kinda outdated: vkBasalt currently supports CAS, FXAA, SMAA and Deband/Dithering. Otherwise pacakge seems to work fine.

Faalagorn commented on 2019-11-02 11:49 (UTC) (edited on 2019-11-02 12:15 (UTC) by Faalagorn)

EDIT: Nevermind, it works after updating vulkan-headers-git from 1.1.123 to 1.1.126 :)

@gee thanks for reply. It's probably something on my side (missing/outdated dependeny from AUR instead of repos?)

make[1]: *** [makefile:22: ../build/graphics_pipeline.64.o] Error 1
make[1]: Leaving directory '/tmp/makepkg/vkbasalt/src/vkBasalt-0.1.0/src'
make[1]: Entering directory '/tmp/makepkg/vkbasalt/src/vkBasalt-0.1.0/shader'
glslangValidator -V fxaa.frag.glsl -o ../build/tmp/fxaa.frag.spv
glslangValidator -V full_screen_rect.vert.glsl -o ../build/tmp/full_screen_rect.vert.spv
spirv-opt ../build/tmp/full_screen_rect.vert.spv -O -o ../build/shader/full_screen_rect.vert.spv
spirv-opt ../build/tmp/fxaa.frag.spv -O -o ../build/shader/fxaa.frag.spv
rm ../build/tmp/fxaa.frag.spv ../build/tmp/full_screen_rect.vert.spv
make[1]: Leaving directory '/tmp/makepkg/vkbasalt/src/vkBasalt-0.1.0/shader'
==> Entering fakeroot environment...
==> WARNING: Cannot find the sudo binary. Will use su to acquire root privileges.
==> Starting package()...
install: cannot stat 'build/': No such file or directory
==> ERROR: A failure occurred in package().

It works only when I comment both the and (they don't even get created) but then it'd be useless. :)

Kinda funny how it worked before the update? I'll try to update everything.

gee commented on 2019-11-02 02:38 (UTC)

Done, thank you @rodrigo21 !

rodrigo21 commented on 2019-11-02 02:22 (UTC) (edited on 2019-11-02 02:23 (UTC) by rodrigo21)

You can now also use a FXAA shader if you enable it in the config file, but it is not installed with this package. Add this line in package() to install the shader:

install -Dm 644 build/shader/fxaa.frag.spv "${pkgdir}/usr/share/vkBasalt/shader/fxaa.frag.spv"

gee commented on 2019-11-01 22:58 (UTC)

@Faalagorn hmmm I am not sure, I just did a clean build and it worked fine. It'd be useful to know whether the file is not there or the script is in a wrong directory.

Faalagorn commented on 2019-11-01 22:45 (UTC)

Since the most recent update, I get the:

install: cannot stat 'build/': No such file or directory

Not 100% sure it's not something on my side, but might be worth looking into.