16b Color Processing

  • Author
  • Message
Offline

Mark Grgurev

  • Posts: 597
  • Joined: Fri Nov 03, 2017 7:22 am

16b Color Processing

PostFri May 29, 2020 1:07 am

Simple request.

There were a way to switch the Color page to work with less precision. Some plugins like NeatVideo are can be noticeably faster (20% faster on my computer) when using lower precisions. It would be great to be able to take advantage of that.

I just tested out a few ResolveFX nodes in Fusion and see that they can already work at half-precision so it shouldn't really be much a to-do.
Offline

Hendrik Proosa

  • Posts: 1132
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: 16b Color Processing

PostFri May 29, 2020 10:29 am

Not sure maintaining the code for two separate data types is reasonable in the long run. Users have an expectation that results will be identical while it can't be guaranteed due to different precision (both relative and absolute). This is my personal opinion but I think Fusion should also drop the legacy 8bit and 16bit modes.

Another can of worms it opens is that 16bit short math will clamp your data. 16bit half-float on the other hand might not give any speed benefit because half-float arithmetics units are not present in all hardware (they are in some, but I believe it is usually limited to gpgpu solutions like specific nVidia datacenter cards). Actually I don't think 16bit shorts have any real benefits in gpu too, I can be totally wrong though...
I do stuff.
Offline

Jim Simon

  • Posts: 9363
  • Joined: Fri Dec 23, 2016 1:47 am
  • Warnings: 1

Re: 16b Color Processing

PostFri May 29, 2020 2:34 pm

I would not vote for this.
Offline

Mark Grgurev

  • Posts: 597
  • Joined: Fri Nov 03, 2017 7:22 am

Re: 16b Color Processing

PostFri May 29, 2020 2:42 pm

Hendrik Proosa wrote:Not sure maintaining the code for two separate data types is reasonable in the long run. Users have an expectation that results will be identical while it can't be guaranteed due to different precision (both relative and absolute).


Doesn't matter if the results are absolutely identical if the user gets a result they're happy with.

Hendrik Proosa wrote:This is my personal opinion but I think Fusion should also drop the legacy 8bit and 16bit modes.


Those modes can not only increase speed but decrease memory usage. They have their purposes.

Hendrik Proosa wrote:Another can of worms it opens is that 16bit short math will clamp your data. 16bit half-float on the other hand might not give any speed benefit because half-float arithmetics units are not present in all hardware (they are in some, but I believe it is usually limited to gpgpu solutions like specific nVidia datacenter cards).


All of AMD's Vega and Nvidia's Turing GPUs already support double speed FP16 math and I believe both see speed ups with lower-precision integer match.

Hendrik Proosa wrote:Actually I don't think 16bit shorts have any real benefits in gpu too, I can be totally wrong though...


Even without specific hardware for it, lower precision math result in increased performance. The 20% speed up I cited for Neatvideo was from my own tests with my GTX 1070.
Offline

Hendrik Proosa

  • Posts: 1132
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: 16b Color Processing

PostFri May 29, 2020 6:14 pm

Purely my view but I think this would mean going backwards. Gpu evolution will diminish the returns faster than developers can code the corner cutting tricks. Basically the same situation as in 3d render engines world (not realtime but vfx and visualization). Pathtracers have almost killed off all other tricks because unified solution is way easier to maintain and optimize than a pile of hacks, even though pathtracing is way more costly computationally that rasterizing. Gpu power increases are simply eating away the speed differences at very high pace. It will not be any different in 2d image processing.
I do stuff.
Offline

Mark Grgurev

  • Posts: 597
  • Joined: Fri Nov 03, 2017 7:22 am

Re: 16b Color Processing

PostSat May 30, 2020 12:10 am

Hendrik Proosa wrote:Purely my view but I think this would mean going backwards. Gpu evolution will diminish the returns faster than developers can code the corner cutting tricks. Basically the same situation as in 3d render engines world (not realtime but vfx and visualization). Pathtracers have almost killed off all other tricks because unified solution is way easier to maintain and optimize than a pile of hacks, even though pathtracing is way more costly computationally that rasterizing. Gpu power increases are simply eating away the speed differences at very high pace. It will not be any different in 2d image processing.


The off-line rendering comparison isn't really relevant here though. The Color page is designed for real-time color grading of 2D footage that, at most, is 16-bit but often only 12, 10, or 8 bit and will be encoded in 10-bit or 8-bit. It's not doing HDR lighting calculations, it's not working with depth or world position buffers or anything like that. Not only is fp16 enough precision for that 99% of the time but the added performance would be appreciated. As long as GPU's continue to support packed math, it will always be twice as fast. Yes, Fusion is used in scenarios where higher precision is needed but it's also used to create titles and transitions to be used on a the Edit page. It would be nice if those could play back in real time.

To my knowledge, the reason why so many image processing applications do their processing in 32-bit is because there was no reason to do it with less since the SIMD instructions on most CPUs only have a minimum floating point precision of 32-bit and GPUs with unified shaders only worked with 32-bit data. Now that GPUs are supporting are supporting packed integer and floating point math, it should be taken advantage of.

Besides, maintaining a 16-bit and 32-bit version of an effect doesn't require completely divergent code-paths. It's nowhere near the same as maintaining separate ray-traced and raster renderers (though programs like Blender still do that).

Return to DaVinci Resolve Feature Requests

Who is online

Users browsing this forum: No registered users and 10 guests