vkBasalt: init at 0.3.2.2 #92401
vkBasalt: init at 0.3.2.2 #92401
Conversation
| }; | ||
|
|
||
| # Currently doesn't support 32bit Vulkan games on 64bit systems | ||
| # See https://github.com/KhronosGroup/Vulkan-Loader/issues/155 |
There was a problem hiding this comment.
This will need to be absolute either way. Maybe open a PR against vkbasalt?
I am not familiar with Vulkan layers but I guess you would do something like add ${pkgsi686Linux.vkbasalt}/share to VK_LAYER_PATH environment variable for 32-bit games..
There was a problem hiding this comment.
Using an absolute path by default would break multi lib compatibility on other systems, so I don't think the vkBasalt maintainer would accept the change.
It also wouldn't work to use VK_LAYER_PATH since the Vulkan loader does deduplication and will select the first JSON file it finds for the layer name. I suppose we can try appending the architecture to the name to workaround this.
|
@jtonar Do you think the workaround I just added to support 32bit Vulkan applications is an acceptable approach? |
|
Why link it into a single package instead of using two separate ones (possibly with manifest renaming to avoid conflicts). |
|
@jtojnar It's mostly for convience and constitency with how it's packaged on Arch. Do you think it would be better to have to install both versions separately? |
|
Yeah, separate packages sound more idiomatic to me. We do not need multilib since Nix supports effortless cross-platform builds. |
kira-bruneau
force-pushed
the
vkbasalt
branch
2 times, most recently
from
d93eb1c
to
cd247e4
Compare
|
I had to do some more platform specific renaming so both the 32bit and 64bit variant can be installed together. |
|
@jtojnar After coming back to this to update it to 0.3.2.2, I'm not really sold on the idea of using separate packages. It requires more patching just so the two packages can be installed together. I think it would make sense to use separate packages if all the required functionality was provided by just one package, but vkBasalt is designed with the intention that you have both builds on a 64bit system. I'm leaving it with the separate package approach for now, but I have the single package approach up in my NUR repo for comparison. EDIT: I noticed that you mention that we don't need multilib, do you mean using something like |
|
Version 0.3.2.3 now uses For now, I will just close this PR and reopen a new one once #101597 is fixed. |
|
@MetaDark you might be interested in this: DadSchoorse/vkBasalt#123 (comment) |
|
@TheEvilSkeleton Thanks, this could be useful if we want to create a NixOS module for system-wide configuration, but right now there's still the problem with selecting the 32bit vs 64bit library when running a 32bit or 64bit executable. This can be hacked around by creating two Vulkan layers for each build like in my original commit, but a proper solution is blocked by #101597. |
Motivation for this change
Closes #84684
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)No binary files, tested through use of Vulkan game
nix path-info -Sbefore and after)Rendering The Legend of Zelda: Breath of the Wild through Cemu with ASCII shader:
