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

importing xformers.ops implicitly initializes CUDA context #1030

Open
function2-llx opened this issue Apr 20, 2024 · 3 comments
Open

importing xformers.ops implicitly initializes CUDA context #1030

function2-llx opened this issue Apr 20, 2024 · 3 comments

Comments

@function2-llx
Copy link

Currently, importing xformers.ops will implicitly initializes CUDA context. This has an unpleasant effect that we cannot use the "fork" multi-processing method.

The line of code that initializes CUDA context is as follows:

if torch.cuda.get_device_capability("cuda") < (8, 0):

@danthe3rd
Copy link
Contributor

Hi,
Thanks for reporting this issue. Unfortunately it might be more effort than just this line, as we check for device capabilities in multiple places as well...
@fmassa @bottler any idea?

@bottler
Copy link
Contributor

bottler commented May 2, 2024

Fixing this would be good for cutting import times.

We need _is_triton_available to be only called when a public function is called, not at import time of public modules. I think we could do that.

facebook-github-bot pushed a commit that referenced this issue May 7, 2024
See #1030

(I am not updating xformers/components here.)

ghstack-source-id: 56136b9a2d20448cbd9546fa4182e10c0ae83d51
Pull Request resolved: fairinternal/xformers#1094

__original_commit__ = fairinternal/xformers@df89e3c
@bottler
Copy link
Contributor

bottler commented May 7, 2024

It's possible that the commit 737c2e6 just now will fix this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants