You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Up to now, processing multi-dimensional single precision floating point data is the main target of the UFO framework, however support for element types other than that has been proposed. Here are some issues that we (@Tomago, @rshkarin, @ashkarin, @kamer16) should discuss before implementing it:
What types are absolutely necessary? I suppose it's at least double.
How should arbitrary kernels know about this? My first idea would be to compile the kernels with -Dbtype=double and use btype for all global arguments.
What should we do if a certain type is not supported by the device? Especially double is a big problem on GPUs. We could convert implicitly but that's ... not what people would expect.
Where do we set the desired buffer type? Per task? For the entire graph?
The text was updated successfully, but these errors were encountered:
absolutely necessary is ushort because of the cameras. But the more the merrier
exactly
I know, then don't execute the graph and tell the user why and what they can do. If I do high-precision calculations I certainly don't want the framework to implicitly change my data type.
Per task I would say, another attribute in the ufo-buffer structure. Use case: camera data (ushort) -> filtering (2x float, or, better yet, complex) -> backprojection (float) -> normalization (ubyte) -> writer
Yes and no, e.g. flat correction has to output floats, sure. But what if the user wants it as a double? Or what if we have a normalize node? Then if I set it up to normalize to [0..255] I can convert it to ubyte from float or so. But for this we can make a converting node and the user can just use that one if they want full control.
Up to now, processing multi-dimensional single precision floating point data is the main target of the UFO framework, however support for element types other than that has been proposed. Here are some issues that we (@Tomago, @rshkarin, @ashkarin, @kamer16) should discuss before implementing it:
-Dbtype=double
and usebtype
for all global arguments.The text was updated successfully, but these errors were encountered: