[Bf-committers] float-upgrade to sequencer

[Peter Schlaile]

Hi,

> Well, under the current Intel architecture (and probably common under
> others as well) int-int math is faster that float-float math, but
> float-float is oddly faster
> than float-int math.  The fastest way to do float-int math is to convert
> the ints to floats in hardware and use the FPU to do a float-float.
> (Int-int has it's own hardware in the ALU.)  But the conversion isn't free,
> so it's slower.    So if you have to do float anywhere along the line, you
> should do float everywhere along the line.

You are right, that's what the code is doing right now on my private
tree. (Either let the whole pipeline run integer operations (converting
input that does not conform) or do the same using float operations.)

The question I asked was more directed in, _when_ to use float
arithmetic in the pipeline.

I first thought, that I could detect this automatically based on the input
data (images, movies, etc.).

But this is
a) ugly, since float-pipelines are semantically totally different then
   integer-pipelines. (float-pipelines clip values to the valid range at
   the end instead of clipping results all the time in each calculation.)
   It is never a good idea to change semantic based on side effects.
   (in this case for example adding an openexr-image anywhere on the
   timeline...)

b) not even, what the user wants! (Sometimes we want to run a
   float-pipeline, even if all input and output is integer!!!)

So my conclusion was:
a) add a button to the overly polluted renderbuttons
   menu, so that the user can decide, if he wants to run an
   integer-pipeline or a float-pipeline! (mixed pipelines don't make
   much sense, as you noted above...)
b) decide, that one or the other solution is the way (tm) blender will
   go. (which makes in the case of a pure float-pipeline a lot of
   video-only people totally unhappy because of loss of speed and in the
   other case kills high quality solutions.)
c) make it a userpref-value (which I personally think is totally
   misplaced, since I don't think the quality of output should depend on
   user preferences, rather on render-options.)
d) ... ?

Since my favorite solution a) will most likely change the semantic of
other render-engines (compositor / scene-rendering) too, I wanted to ask
before adding such a beast.

Any suggestions welcome!

Greetings,
Peter

----
Peter Schlaile <peter at schlaile dot de>