Result of nixpkgs-review pr 269639 --extra-nixpkgs-config '{ cudaSupport = true; cudaEnableForwardCompat = false; cudaCapabilities = [ "8.6" ]; allowUnfree = true; }' run on x86_64-linux 1

Eh, I ran out of disk

Result of nixpkgs-review pr 269639 --extra-nixpkgs-config '{ cudaSupport = true; cudaEnableForwardCompat = false; cudaCapabilities = [ "8.6" ]; allowUnfree = true; }' run on x86_64-linux 1

TF seems to have introduced CUDA 12 support in version 2.15.0, so if we upgrade TF we can likely get rid of cudaPackagesGoogle. I'm guessing that JAX's CUDA support is constrained by XLA/TF.

Completing a TF upgrade should not be a blocker for this PR IMHO, but just wanted to note that for future work.

TF seems to have introduced CUDA 12 support in version 2.15.0, so if we upgrade TF we can likely get rid of cudaPackagesGoogle. I'm guessing that JAX's CUDA support is constrained by XLA/TF.

I feel like TF has been generally lagging behind and offering a narrower compatibility window, compared to anything else including pytorch. That's the reason we had the overrides inheriting tensorflow-bin's cudaPackages for tensorflow and jax, isn't it? I don't expect this to change. I anticipate that with the next cuda release we'd have to reintroduce the pins

I don't quite understand the TensorRT changes. It looks to be mostly just refactoring in extension.nix, but I see generic.nix now has an enable flag argument. What happens when that is set to false?

Ok so I did it super-dirty just to get the eval fixed and nixpkgs-review running, but basically what happens here is that unless enable is true, the package gets meta.broken set and all of its dependencies are actually discarded so that they're never evaluated.

It's ugly, it's wrong, it's an overkill, and we have better prospects with the refactoring being worked on in #256324. And we haven't settled on the convention of either leaving out the unsupported attributes, or marking them "broken": #266475.

@aidalgol could you confirm I didn't break the existing trt packages? Or maybe I ask you again after the nixpkgs-review, because I'll probably have to push more fix-ups

This is how I tested TensorRT when first adding it to nixpkgs, if you want to test without having to wait for me.

$ NIX_PATH=nixpkgs=$PWD NIXPKGS_ALLOW_UNFREE=1 nix-shell -p 'python310.withPackages (pypkgs: [ pypkgs.tensorrt ])'
$ python3 -c 'import tensorrt; assert tensorrt.Builder(tensorrt.Logger())'

I think it would be the same, only with python311 in place of python310 now.

EDIT: lol it should've been cudaForwardCompat = false not cudaEnableForwardCompat

Result of nixpkgs-review pr 269639 --extra-nixpkgs-config '{ cudaSupport = true; cudaEnableForwardCompat = false; cudaCapabilities = [ "8.6" ]; allowUnfree = true; }' run on x86_64-linux 1

Catboost fails because of the unsupported architectures too. I tried overriding the cuda architectures for catboost but failed, they're hard-coded in more than one place. I guess we'll have to force it to use cudaPackages_11 directly for now

Tracking override-ability in catboost/catboost#2540

Also I can't publish the logs because Mic92/nixpkgs-review#379

The python3Packages.pymc situation is pretty ugly:

• It depends on numba which brings in the run-file based cudatoolkit-12 and the corresponding cudnn
• It depends on jaxlib and tensorflow which depend on the runfile-based cudatoolkit-11 and the corresponding cudnn
• It also implicitly depends on cupy and cutensor

Somebody's got to untangle this mess, but not in this PR I think

#275709 is somewhat of a blocker, although I'm willing to just break them

#275939 is a blocker because we can't get anything reasonable from Ofborg

@ConnorBaker I want to merge this as soon as ofborg allows. The nsight_systems fix is super ugly and I'm content with that.

Added a commit to address @samuela's notes so the checks are gone, but ofborg has passed previously: https://github.com/NixOS/nixpkgs/pull/269639/checks?check_run_id=20566378248