GPU Next vs GPU

Known limitations / missing options

Not yet implemented

• --blend-subs (#9870)
• --gamma-factor and --gamma-auto
• --cscale: currently, gpu-next uses the --scale filter for everything, without the ability to tune it by plane type; subject to change by popular request
• --dither=error-diffusion (#9415)
• libmpv integration (#9475)
• Presentation feedback

Difficult / impossible to support, by design

• --fbo-format: the best we can currently do is disable FBOs (--gpu-dumb-mode=yes) or force 8-bit FBOs (option not yet implemented)
• --icc-force-contrast: ICC/3DLUT color management is currently in a state of flux and will be rewritten soon, no idea what will happen to this option as a result

Deliberate omissions

• --sharpen: Very low quality and easily replaced by (better) custom shaders (#9387, #9845)
• ewa_lanczossharp / ewa_lanczossoft: Easily replicated by tuning ewa_lanczos (see below for further justification)
• haasnsoft: Easily replicated by tuning ewa_lanczos
• --tone-mapping-max-boost: crutch for bad tone-mapping functions and lack of black point handling
• --vf=format:light=...: OOTFs are tied to the EOTF in gpu-next, and can no longer be adjusted independently
• --scaler-resizes-only: enabled by design in gpu-next, so the option does nothing

Differences in behavior

General differences

• gpu-next should be generally faster across the board, owing to refactors and rewrites of many key algorithms (EWA scaling, frame interpolation, color management, PRNG/debanding, etc.)
• gpu-next aggressively merges shader passes wherever possible, leading to a significant reduction in the number of full-screen draw calls required per frame; in addition to this it also more aggressively reuses internal frame caches
• gpu-next, unlike gpu, performs black point compensation during color management, leading to subtly different results for many of the tone mapping-related options
• gpu-next generally defaults to bt.1886 instead of gamma2.2 for the display output, due to the better/different black point handling
• gpu-next doesn't rotate/flip frames until the final output pass, whereas gpu applied this during the main scaling pass. This generally makes it more robust when combining custom user shaders with rotated videos

Differences in option behavior

• ewa_lanczos defaults to using radius 3.2383... in gpu-next, rather than the radius 3.0 of gpu. Note that the (deleted) ewa_lanczossharp prefix also used the 3.2383 radius instead of 3.0, which was the main reason for the difference between those two presets in the first place. So, since ewa_lanczos now uses the larger radius by default, the difference between it and the "sharper" preset is almost nonexistant.
• --tone-mapping=auto: chooses between spline, bt.2446a and bt.2390, instead of always picking bt.2390
• --tone-mapping=gamma: scaling of the parameter has been changed slightly
• --tone-mapping=bt.2390: knee point is now tunable, defaulting to 1.0 instead of the hard-coded 0.50 from gpu
• --tone-mapping=linear: is now perceptually linear instead of linear light
• --tone-mapping-mode=auto: chooses the new mode luma by default, in most circumstances
• --tone-mapping-mode=hybrid: uses a different hard-coded tradeoff function
• --gamut-mapping-mode=auto: picks the new mode darken by default
• --gamut-mapping-mode=warn: makes out-of-gamut pixels magenta, instead of inverting them
• --hdr-compute-peak: gpu-next generally uses frame-exact results, rather than delaying detected peaks by a frame
• --scale=box is no longer resizable, but see:
• --scale can now be used directly on window functions, removing the need for --scale-window + --scale=box combo; in addition, a few new functions are available while others have been removed

Custom shader support

• TEXTURE_rot is no longer needed (it still exists for compatibility, but it's defined as an identity matrix)
• The distinction between MAIN and MAINPRESUB no longer exists - either name can be used to refer to the same texture
• Two new macros linearize and delinearize are available in all shader stages, resolving to GLSL functions for going back and forth between the video's native color space and linear light

New features only supported by GPU Next

New functionality

• Support for Dolby Vision content (reshaping only)

New options

• --interpolation-preserve
• --lut, --image-lut, --target-lut
• --target-colorspace-hint: cross-platform HDR passthrough, with metadata forwarding and automatic tone-mapping
• --tone-mapping=bt.2446a
• --tone-mapping=spline
• --inverse-tone-mapping
• --tone-mapping-crosstalk
• --tone-mapping-mode=luma
• --allow-delayed-peak-detect

Bugs fixed only in gpu-next

• #8223
• #9863
• #5727
• lots more that I forgot about