Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python312Packages.bitsandbytes: 0.43.1 -> 0.43.3 #343246

Merged
merged 1 commit into from
Oct 30, 2024

Conversation

GaetanLepage
Copy link
Contributor

@GaetanLepage GaetanLepage commented Sep 20, 2024

Description of changes

Changelog: https://github.com/TimDettmers/bitsandbytes/releases/tag/0.43.3

cc @bcdarwin

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@remexre
Copy link
Contributor

remexre commented Oct 20, 2024

The CUDA-enabled version of this no longer builds when I do:

$ NIXPKGS_ALLOW_UNFREE=1 nix repl --impure
Welcome to Nix 2.18.5. Type :? for help.

nix-repl> :lf .
Added 18 variables.

nix-repl> :b outputs.legacyPackages.x86_64-linux.python3Packages.bitsandbytes.override { torch = outputs.legacyPackages.x86_64-linux.python3Packages.torchWithCuda; }
error: builder for '/nix/store/ylwx6as34nfygmxz5lwjvcqb15p7xd5q-python3.12-bitsandbytes-0.43.3.drv' failed with exit code 1;
       last 10 log lines:
       >
       >
       > Call Stack (most recent call first):
       >   /nix/store/yzi080r2c1zn2jzrhcfdv7dmr92yw07l-cmake-3.29.6/share/cmake-3.29/Modules/CMakeDetermineCompilerId.cmake:8 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
       >   /nix/store/yzi080r2c1zn2jzrhcfdv7dmr92yw07l-cmake-3.29.6/share/cmake-3.29/Modules/CMakeDetermineCompilerId.cmake:53 (__determine_compiler_id_test)
       >   /nix/store/yzi080r2c1zn2jzrhcfdv7dmr92yw07l-cmake-3.29.6/share/cmake-3.29/Modules/CMakeDetermineCUDACompiler.cmake:131 (CMAKE_DETERMINE_COMPILER_ID)
       >   CMakeLists.txt:74 (enable_language)
       >
       > 
       > -- Configuring incomplete, errors occurred!
       For full logs, run 'nix log /nix/store/ylwx6as34nfygmxz5lwjvcqb15p7xd5q-python3.12-bitsandbytes-0.43.3.drv'.

A fix is here: GaetanLepage/nixpkgs@2af0c9e...remexre:nixpkgs:bitsandbytes

@GaetanLepage GaetanLepage force-pushed the bitsandbytes branch 2 times, most recently from 6d92bff to eee442b Compare October 20, 2024 16:40
@GaetanLepage
Copy link
Contributor Author

A fix is here: GaetanLepage/[email protected]:nixpkgs:bitsandbytes

Thanks, the patch seems to work indeed.
I will wait for @SomeoneSerge's approval as he's much more knowledgeable than me on the CUDA stuff.

@GaetanLepage GaetanLepage marked this pull request as ready for review October 20, 2024 16:47
@GaetanLepage
Copy link
Contributor Author

Well, even though it does build fine with cudaSupport = true, and the derivation is finalized successfully, it spits the following message:

Executing pythonImportsCheckPhase
Check whether the following modules can be imported: bitsandbytes
Could not load bitsandbytes native library: /nix/store/8x5i8xccb6h38iz22r8x3c4qg2pbrbg6-python3.12-bitsandbytes-0.44.1/lib/python3.12/site-packages/bitsandbytes/libbitsandbytes_cpu.so: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "/nix/store/8x5i8xccb6h38iz22r8x3c4qg2pbrbg6-python3.12-bitsandbytes-0.44.1/lib/python3.12/site-packages/bitsandbytes/cextension.py", line 104, in <module>
    lib = get_native_library()
          ^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/8x5i8xccb6h38iz22r8x3c4qg2pbrbg6-python3.12-bitsandbytes-0.44.1/lib/python3.12/site-packages/bitsandbytes/cextension.py", line 91, in get_native_library
    dll = ct.cdll.LoadLibrary(str(binary_path))
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/wfbjq35kxs6x83c3ncpfxdyl5gbhdx4h-python3-3.12.6/lib/python3.12/ctypes/__init__.py", line 460, in LoadLibrary
    return self._dlltype(name)
           ^^^^^^^^^^^^^^^^^^^
  File "/nix/store/wfbjq35kxs6x83c3ncpfxdyl5gbhdx4h-python3-3.12.6/lib/python3.12/ctypes/__init__.py", line 379, in __init__
    self._handle = _dlopen(self._name, mode)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: /nix/store/8x5i8xccb6h38iz22r8x3c4qg2pbrbg6-python3.12-bitsandbytes-0.44.1/lib/python3.12/site-packages/bitsandbytes/libbitsandbytes_cpu.so: cannot open shared object file: No such file or directory

@GaetanLepage
Copy link
Contributor Author

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 343246


x86_64-linux

✅ 4 packages built:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

aarch64-linux

✅ 4 packages built:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

x86_64-darwin


aarch64-darwin

Copy link
Member

@samuela samuela left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

diff lgtm

@samuela
Copy link
Member

samuela commented Oct 26, 2024

OSError: /nix/store/8x5i8xccb6h38iz22r8x3c4qg2pbrbg6-python3.12-bitsandbytes-0.44.1/lib/python3.12/site-packages/bitsandbytes/libbitsandbytes_cpu.so: cannot open shared object file: No such file or directory

This looks like a job for LD_DEBUG=libs

@GaetanLepage
Copy link
Contributor Author

GaetanLepage commented Oct 26, 2024

Ok, I investigated some more.

Problem

When cudaSupport is enabled, the cuda variant of the library is built libbitsandbytes_cuda124.so instead of the native CPU one libbitsandbytes_cpu.so.
However, at runtime, they decide whether to load the cuda library or not depending on torch.cuda.is_available(). However, this will return False on any system where there is no GPU available.
Hence, it falls back to trying to load the native _cpu.so library, which has not been built and thus doesn't exist.

Relevant code

In this function, cuda_specs will evaluate to None and the whole if statement will not trigger.

Solution

The best solution I found was to:

  1. ignore the get_cuda_specs() result and enter the if statement unconditionally.
  2. bypass the call to get_cuda_bnb_library_path(cuda_specs) and hardcode the library path here (PACKAGE_DIR / "libbitsandbytes_cuda124.so").

Now everything builds and imports fine. No more error messages.

Result (with cudaSupport = true)

bitsandbytes> Running phase: pythonImportsCheckPhase
bitsandbytes> Executing pythonImportsCheckPhase
bitsandbytes> Check whether the following modules can be imported: bitsandbytes
┏━ Dependency Graph:
┃ ✔ python3.12-bitsandbytes-0.44.1 ⏱ 3m26s
┣━━━ Builds
┗━ ∑ ⏵ 0 │ ✔ 1 │ ⏸ 0 │ Finished at 12:21:35 after 3m29s
/nix/store/5n0nma25svsbw15x0qcj4sqyl8syrnyp-python3.12-bitsandbytes-0.44.1

@GaetanLepage GaetanLepage force-pushed the bitsandbytes branch 2 times, most recently from d7f6384 to b1037b5 Compare October 26, 2024 10:27
@GaetanLepage
Copy link
Contributor Author

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 343246


x86_64-linux

✅ 4 packages built:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

aarch64-linux

✅ 4 packages built:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

x86_64-darwin


aarch64-darwin

preBuild =
if cudaSupport then
''
export NVCC_APPEND_FLAGS="-I${cuda-native-redist}/include -L${cuda-native-redist}/lib"
Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cudaSetupHook sets NVCC_APPEND_FLAGS too. Use appendToVar or prependVar

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to the same approach as in mistral-rs. Is it fine now ?

if cudaSupport then
''
export NVCC_APPEND_FLAGS="-I${cuda-native-redist}/include -L${cuda-native-redist}/lib"
cmake -DCMAKE_CXX_FLAGS="-I${cuda-native-redist}/include" -DCOMPUTE_BACKEND=cuda -S .
Copy link
Contributor

@SomeoneSerge SomeoneSerge Oct 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is normally done in confgiurePhase which pkgs.cmake in nativeBuildInputs would set automatically. Istead of specifying the -D flags in here, maybe move them to the nix attrset as cmakeFlags so the hook passes them on as a bash variable. If for some reason you choose not to use the hook but to call cmake yourself, reimplement the flagsArray=(...) ; concatTo ... functionality from the hook. The cmake hook respects dontUseCMake....Directory flag and you can pass -S . in cmakeFlags too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was able to successfully rely on the cmake hook.
I still manually run make in the preBuild phase.

Comment on lines 61 to 66

postPatch =
''
substituteInPlace Makefile --replace "/usr/bin/g++" "g++" --replace "lib64" "lib"
substituteInPlace bitsandbytes/cuda_setup/main.py \
--replace "binary_path = package_dir / self.binary_name" \
"binary_path = Path('$out/${python.sitePackages}/${pname}')/self.binary_name"
''
+ lib.optionalString torch.cudaSupport ''
substituteInPlace bitsandbytes/cuda_setup/main.py \
--replace "/usr/local/cuda/lib64" "${cuda-native-redist}/lib"
'';
# By default, which library is loaded depends on the result of `torch.cuda.is_available()`.
# When `cudaSupport` is enabled, bypass this check and load the cuda library unconditionnally.
# Indeed, in this case, only `libbitsandbytes_cuda124.so` is built. `libbitsandbytes_cpu.so` is not.
# Also, hardcode the path to the previously built library instead of relying on
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow this really sounds like a bug in bitsanbytes, I'm surprised they're not reacting to the issue

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW on our side we could actually make their presumably-inteded behaviour work, only at double the cost: we could just make the cuda-version depend on the cpu-version.

The question is, is the xxxxx_cuXXX.so library usable in absence of GPUs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this current approach is fine. If you set cudaSupport = true, it means that you want to use cuda.

The question is, is the xxxxx_cuXXX.so library usable in absence of GPUs?

I don't think so.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this current approach is fine. If you set cudaSupport = true, it means that you want to use cuda.

Well the upstream has implemented this (broken?) dynamic dispatching logic so I guess they intended it the other way. Anyway, implementing that logic from scratch is not in-scope here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well the upstream has implemented this (broken?) dynamic dispatching logic so I guess they intended it the other way. Anyway, implementing that logic from scratch is not in-scope here

Yes, indeed.

Comment on lines 30 to 31
(lib.getLib libcusparse)
libcusparse.lib
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

drop the last? Btw getDev libcusparse has .lib in propagatedBuildInputs, I forget if that matters to symlinkJoin

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, well the last line libcusparse.lib is clearly a mistake and is not needing because I have added lib.getLib libcusparse above.
Now, having said that, you suggest also getting rid of that and only keeping lib.getDev libcusparse right ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It works with lib.getDev libcusparse alone.

@GaetanLepage
Copy link
Contributor Author

Ok I was able to make it build in the end.
However, I am not sure that the cuda-native-redist and cuda-common-redist are as lean as they can be.
Can you double check my changes @SomeoneSerge please ?

@SomeoneSerge
Copy link
Contributor

However, I am not sure that the cuda-native-redist and cuda-common-redist are as lean as they can be.

That matters fairly little when using symlinkJoin: the closure will be huge regardless.

@GaetanLepage
Copy link
Contributor Author

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 343246


x86_64-linux

✅ 4 packages built:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

aarch64-linux

✅ 4 packages built:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

x86_64-darwin

⏩ 4 packages marked as broken and skipped:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

aarch64-darwin

⏩ 4 packages marked as broken and skipped:
  • python311Packages.bitsandbytes
  • python311Packages.bitsandbytes.dist
  • python312Packages.bitsandbytes
  • python312Packages.bitsandbytes.dist

@SomeoneSerge SomeoneSerge merged commit 67858a3 into NixOS:master Oct 30, 2024
27 of 28 checks passed
@GaetanLepage GaetanLepage deleted the bitsandbytes branch October 30, 2024 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants