GeezerVison is showing github.com — Float data loaded from host to gpu texture gets values clipped to range [0...1] · Issue #288 · glumpy/glumpy
Float data loaded from host to gpu texture gets values clipped to range [0...1] #288DescriptionThis behavior is OpenGL default (to clamp floats uploaded to texture). I just though since Glumpy is used for scientific visualization, it would be common for people to upload float data to texture in range beyond [0...1]. Especially because classes named TextureFloat*D which solve this are implemented already.
The I found was to change a line in file variable.py (in gloo), in the method set_data of class Uniform, lines 226 and 227.
The line changed was
(...)
if data.dtype in [np.float16, np.float32, np.float64]:
self._data = data.astype(np.float32).view(Texture1D)
and became
(...)
if data.dtype in [np.float16, np.float32, np.float64]:
self._data = data.astype(np.float32).view(TextureFloat1D)
EDIT: if its the case to make this change or somehow allow for the user to choose whether to clamp values, then changes to the Texture2D case should also be implemented. Activitychanged the title [-]Float data loaded from host to gpu texture gets values clamped to range [0...1][/-] [+]Float data loaded from host to gpu texture gets values clipped to range [0...1][/+] on Jun 21, 2021rougier commented on Jun 21, 2021 Thanks for the report. Glumpy is trying to stick to Open GL ES 2.0 (which is quite old now) that does not offer natively float texture and this is the reason I'm using Texture1D only. But I agree it would make sense to have an option to use float texure. Not sure on the best way to do that. jstreibel commented on Jun 21, 2021 ContributorAuthor More actions No worries.
In terms of user interface my guess is that the simplest way is to have in gloo.Program.__init__ an option to clamp_texture_float_values or similar. __init__ would then pass this information to gloo.Program._build_uniforms, which then would setup the uniforms accordingly. In this case, class Uniform should keep track on whether to use Texture1D or TextureFloat1D for float arrays. rougier commented on Jun 29, 2021 Or we can check if TextureFloat1D / TextureFloat2D are bounded (i..e not equal to None) and use them when available. If you use the default configuration, they shoudl be equal to None but if you specify a GL 3.2 context, that should work. jstreibel commented on Jul 6, 2021 ContributorAuthor More actions Is it as simple as if TextureFloat1D is not None: ...? rougier commented on Jul 12, 2021 Maybe even more simpler: Texture1D = TextureFloat1D or Texture1D. But the question is whether this would break things, i.e. shaders that assume implicitely that values are bound between 0 and 1. jstreibel commented on Jul 12, 2021 ContributorAuthor More actions It would likely break something somewhere.
Also, it could be counter intuitive to have different behavior for different GL context version. Say you make a program with default GL context then at some point move to a newer version. In this case, (my opinion is that) the least different everything looks and behaves, the better.
OTOH I particularly use them unclamped 99% of time.
Design-wise: because it's already been running clamped, I suggest make it optional (where compatible) and clamped by default. rougier commented on Jul 26, 2021 Sorry for the delay. I think you're right and I don't see an automatic solution. Question is then how to offer the option for unbounded texture. Maybe a command line argument? jstreibel commented on Jul 27, 2021 ContributorAuthor More actions I think command-line.
Here's a summary of options:
- Automatic: bind texture according to GL version;
- Manual: don't bind unless explicit in command line. Something like ''clamp_float_textures".
You decide @rougier :) rougier commented on Aug 19, 2021 Maybe manual would be the most prudent moves, else, it might break a bunch of demo. This where unit tests would be useful.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|