dll load failed #450
Milestone
Comments
|
Further comment on the py3.8 cahnge to
|
|
Installed python 3.9.4, and didn't get this problem. So it's either a python minor version bug, or a quirk with James's machine. For the time being, I don't think this is worth fixing unless we can reproduce it easily. |
|
Closing as labelled as |
|
This has reared it's head again for James, including using the initial alpha python wheels we distribute (built using CUDA 11.0), but again still only impacts him so far. Potentially using conda for distribution might resolve issues re: cuda .dll's on windows #649. One potential improvement for windows python builds might be to use the
Struggling to find the docs on
So it's intentionally undocumented so hard to tell if it's a good idea or not.
Re: the Visual C++ redistributable, TF (as the high profile example CUDA + python project) just lists |
|
Edit: Different missing dlls are their problem. |
|
I'm having the same issue. Windows 11 10.0.22621 I've also run DependencyGui on the _pyflamegpu.pyd file to see if there were missing DLLs, but there aren't. Also it would seem strange if they were missing when I could build pyflamegpu without errors. I'm really not sure what the issue is here :/ Just in case it was some weird overlapping issue, I've also uninstalled all python versions and miniconda, and now just have miniconda installed with a python 3.10 environment so there should be no library conflict, but I still get the same issue: |
Whilst we never discovered the root cause, as stated in the OP the offending DLL was the one for nvrtc ( You're the second person this has affected, and we can't reproduce it locally so I'm afraid it's not something we can investigate for a better solution at this time. I would advise copying DLLs to the working directory until you find the one it's having trouble with. |
|
Thanks for the quick response!
That's a real shame, I will see if that fixes the issue. For posterity, here is the output of the dependency tree: Full dependency tree output (depth 3)UPDATE: Yes! Indeed, copying This is very strange as the DLL is obviously found where it was before - the clue might be in the dependency tree output " Thanks again though, happy it's working even if I aged a little in the process ;) |
We looked at that too in the original case, and as you found it didn't help, besides more clearly confirming the required DLLs.
Curious that it's the same DLL at fault again.
Yup
I've found some older issues for anaconda, which suggest anaconda is doing weird stuff and rewriting the path variable to try and improve DLL loading and inadvertently breaking stuff. It's possible that's still flawed (in certain versions?). ContinuumIO/anaconda-issues#10628 This is what I'm using locally. No idea about versions on the many other machines I've had pyflamegpu work. I'm glad you've been able to sort it out, sorry there's still not a smoother solution. |
|
Ok you were right on the money with the python update. this fixed the issue for me without needing to copy the DLL. import os
os.add_dll_directory('C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.7/bin')from the
But it is also mentioned:
Which must be modified by I'm using I was really surprised that I've never encountered this issue before, even though I've used plenty of packages that require CUDA (e.g. pytorch). I think perhaps the key difference here is that for those packages, specifically within a conda environment, they also required the Anyway, this clearly isn't an issue with flamegpu, and apparently doesn't occur that often, but I wanted to note this for documentation as well as in case some poor soul in the future tries to google for the same problem :) |
Do you mean anaconda/conda?
This could be relevant, CUDA is on both of those paths for me locally, and don't believe it's something we investigated with the first person who reported it. Thanks for all your input, has helped narrow it down a little more. |
This is something we might actually be able to address by adding it to the package init (albeit with something to detect the correct CUDA version and selectively do it on Windows). |
Both actually, I'm guessing this wasn't a problem with python 3.7 (which is the one version I didn't try haha) even under anaconda, which you highlighted here #450 (comment) .
That would be be a nice little fix. Something like this should be somewhat robust and platform independent (and allow for people who have the cuda package in their conda environment as well): import os
try:
import pyflamegpu
except ImportError:
if not os.environ['CUDA_PATH']:
raise ImportError('Please set the CUDA_PATH environment variable to point to the root of the CUDA SDK')
os.add_dll_directory(os.sep.join([os.environ['CUDA_PATH'], 'bin']))
import pyflamegpu |
We previously thought it was a Python version issue, due to add_dll, however I wasn't able to reproduce it with the same Python version as the original person that had the issue.
It would be more stable if we set it based on the version of CUDA which the library was built with/for. I think that file is copied with CMake at some point, so we can probably dynamically replace the path based on the CUDA version. Thanks for your input, I'll discuss it more with my team and hopefully we can put forwards a fix for this. |
Robadob
added a commit
that referenced
this issue
Jun 28, 2022
…port. Required for some Windows installs where Python >=3.8. Fix inspired by zeyus Closes #450
Robadob
added a commit
that referenced
this issue
Jun 28, 2022
…port. Required for some Windows installs where Python >=3.8. Fix inspired by zeyus Closes #450
|
Two users who suffered this bug have now confirmed the fix works. One however also raised that they subsequently received a similar issue for |
If we were to dist the py pacakges by pypi we'd need to do that anyway / we should probably be doing it already. (IIRC the only lib we depend on that we can't redist is libcuda.so, which is the most faff to resolve for pypi compliance other than file sizes being too large already) |
Context: libpng is one of 4? "optional" dependencies of freetype. If it can find them it will use them, if it can't it won't (unless you explicitly say it must be built with). There isn't a clear way to disable support explicitly, other than not having it available, which I doubt the CI does. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
A small number of users on Windows receive
dll load failederror when importing thepyflamegpupackage.Whilst the root cause of this rare issue has not been identified, in affected cases so far the dll for nvrtc has been at fault.
A solution for this is to use the below code before importing
pyflamegpu. You may need to update the path to the location returned bywhere nvrtc64_112_0.dll, for your specific CUDA install.Current speculation is that the issue relates to Anaconda (and a change in how DLLs are loaded with Py 3.8+). We aim to fix this soon by adding this to the package's
__init__.py, however haven't yet decided the appropriate way to locate the most suitable CUDA version (without requiring manual changes in future).JPyle had an issue using flamegpu2 locally, dll load failed would occur when executing any python model on Windows.
After alot of debugging we solved that the nvrtc dll
nvrtc64_112_0.dllwas not being found. This is despite the cuda 11.2 directory containing it clearly being onPATHandwhere nvrtc64_112_0.dllreturning the corresponding path.This was solved by copying the dll to the working directory (alongside
glew32.dllandSDL2.dll).Unclear the actual cause of this, so until we can gather more information it's worth keeping this issue around should it surface again.
Possibly related (although I think James was affected by non-python runs too, but had python 3.9.2, whilst I'm on 3.7): https://docs.python.org/3/library/os.html#os.add_dll_directory
The text was updated successfully, but these errors were encountered: