-
-
Notifications
You must be signed in to change notification settings - Fork 410
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
Float dtypes no longer work on some hardware (without float textures) as of 0.4.13 #3988
Comments
Tried to copy your env as closely as possible (on a mac though, which is a big caveat), and couldn't reproduce. Can you perhaps give us a bit more info on your |
one thing I'm wondering: I believe this is the first release using float textures directly on the GPU (instead of downscaling first to 8 bit). So, depending on the size of your volume, it's conceivable that it's exceeding your GPU vram whereas 0.4.12 wasn't. @brisvag, do you know how that error is going to manifest itself? (I don't think it would look like this, but not sure). |
Hi Talley, Thanks for looking into this. Made a fresh environment with nothing but napari.
still getting the same behavior and traceback. |
this is on the cluster I assume right? |
Not really. It's a server that's running CentOS but isn't a part of a bigger cluster. |
gotcha. I guess my suspicion then is perhaps on |
Yeah that GL version is not promising. Check: import vispy
print("texture_float"` in vispy.sys_info()) |
thanks! as a bare minimum, it seems like we'll definitely want to expose that |
@djhoese, one more q: do you think it would make sense, either in napari or in vispy, to have |
in direct communication, can confirm that @alonyan's config doesn't support float textures, here's the full output of
one solution would be to fall back to |
It wouldn't be terrible for it to be added to vispy, but since the default is already 8-bit maybe this should be a downstream (napari) check? Eh I guess a nice loud warning would work in vispy and force it to legacy 8-bit mode. However, that doesn't really help in the cases where napari might be making the user think that everything is working fine, but their output isn't as they expect. Napari wouldn't show a UserWarning from vispy in its UI anywhere, right? Edit: To clarify, I would accept a PR that implements this in vispy, but not sure if that helps napari in the long run. Also how many users does this effect (just curious, not saying they shouldn't be considered)? |
thanks for your input @djhoese, yeah, it's tricky. While so I can certainly see an argument either way.
it certainly could... currently actually all
probably not many, I agree. but i do think if there's a case that's easy enough to check (e.g. tl;dr: I'm torn, so I guess I'm going to add this to napari unless you specifically ask me to make a PR to vispy :) |
…#6652) # Description In #6411, we missed these lines: https://github.com/napari/napari/blob/4f4c063ae5dd79d6d188e201d44b8d57eba71909/napari/_vispy/layers/image.py#L25-L32 These were added in #3990 because 'auto' has a slightly different meaning in VisPy than *really* fully auto: it chooses the default texture dtype for the input NumPy array's dtype. For float arrays, this is float. However, if your OpenGL implementation doesn't support float textures, VisPy will raise. Instead, passing `texture_format=None` when creating the ImageNode tells VisPy to transform the data to whatever texture format it sees fit. In #6411, when getting the VisPy node for a given dtype, we only check for `texture_format != 'auto'` as the "catch-all" texture format. But, in fact, if we are on a machine that doesn't support float32 textures, by this point in the code the format has been changed to None, incorrectly triggering these lines: https://github.com/napari/napari/blob/89f8194d3fa4eef620755804806ac69ef684df63/napari/_vispy/layers/image.py#L59-L73 and causing a ValueError. This PR fixes that by also checking for None in that same clause. This PR also adds a test by monkeypatching the function that checks for float32 texture support. # References #3988 #3990 --------- Co-authored-by: Juan Nunez-Iglesias <jni@fastmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
…#6652) # Description In #6411, we missed these lines: https://github.com/napari/napari/blob/4f4c063ae5dd79d6d188e201d44b8d57eba71909/napari/_vispy/layers/image.py#L25-L32 These were added in #3990 because 'auto' has a slightly different meaning in VisPy than *really* fully auto: it chooses the default texture dtype for the input NumPy array's dtype. For float arrays, this is float. However, if your OpenGL implementation doesn't support float textures, VisPy will raise. Instead, passing `texture_format=None` when creating the ImageNode tells VisPy to transform the data to whatever texture format it sees fit. In #6411, when getting the VisPy node for a given dtype, we only check for `texture_format != 'auto'` as the "catch-all" texture format. But, in fact, if we are on a machine that doesn't support float32 textures, by this point in the code the format has been changed to None, incorrectly triggering these lines: https://github.com/napari/napari/blob/89f8194d3fa4eef620755804806ac69ef684df63/napari/_vispy/layers/image.py#L59-L73 and causing a ValueError. This PR fixes that by also checking for None in that same clause. This PR also adds a test by monkeypatching the function that checks for float32 texture support. # References #3988 #3990 --------- Co-authored-by: Juan Nunez-Iglesias <jni@fastmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
🐛 Bug
Hi All, Just upgraded to 0.4.13 and got some unpleasant bug. If I try to add an image layer and the underlying data is not an integer I get a black napari and the attached traceback. Same code works well on previous versions.
To Reproduce
Steps to reproduce the behavior:
img is a numpy array
viewer.add_image(img.astype('float'))
Expected behavior
Show the image
Environment
napari: 0.4.13
Platform: Linux-3.10.0-1160.45.1.el7.x86_64-x86_64-with-glibc2.17
Python: 3.9.6 | packaged by conda-forge | (default, Jul 11 2021, 03:39:48) [GCC 9.3.0]
Qt: 5.12.9
PyQt5: 5.12.3
NumPy: 1.20.3
SciPy: 1.7.1
Dask: 2021.08.1
VisPy: 0.9.4
OpenGL:
Screens:
Plugins:
The text was updated successfully, but these errors were encountered: