Page MenuHome

New option to reduce the Eevee/LookDev viewport resolution
Needs ReviewPublic

Authored by Tomoaki Kawada (yvt) on Mar 23 2019, 1:05 AM.

Details

Summary

This patch introduces a user preference setting for reducing the Eevee viewport resolution.

This feature has been requested in this Right-Click Select submission (which I found after I started writing the patch). It's highly desirable for GPUs which are not powerful enough to keep up with the resolution of the display. For instance, this applies to many of the mainstream Macintosh models with a Retina Display (including the one I have) and without it editing in the LookDev/Rendered mode can be very difficult.

This video demonstrates the feature in action. Note that the video is based on an older version of the patch and has glitch adjusting the rendering scale. The version posted here doesn't have the glitch.

Diff Detail

Repository
rB Blender
Branch
patch-render-scale (branched from master)
Build Status
Buildable 3507
Build 3507: arc lint + arc unit

Event Timeline

Tomoaki Kawada (yvt) edited the summary of this revision. (Show Details)Mar 23 2019, 1:11 AM

Always render the depth in full-resolution

This update adds a full-res depth pass which is enabled when the render resolution is smaller than the viewport size.

Completely eliminates Z-fighting issues with overlay rendering.

  • Update code comments

Thanks for proposing this! We thought of something like this for some time already.

I do have some problem with the implementation:

  • I think having a float slider is not adequate. I prefer having a rounded multiplier list (Original resolution, Half Resolution, Quarter Resolution) to avoid some weird cases and strange interpolation when upscalling.
  • I think that we should do that at a higher level and reduce the size of the whole GPUViewport. This would be less intrusive for draw engines and would benefit all fullscreen passes. Also this would avoid the cost of a fullscreen depth pass.

This however does introduce problems due to UI scalling and fullscreen coordinate for UI elements. One way we could avoid these issues is to create another framebuffer with native resolution and blit / resolve the lower resolution framebuffer after the drawing of all the draw engines but before the UI elements (gizmos etc...). The downside is that it would use quite a bit more Vram. These changes would be isolated to the Draw manager.

Clément Foucault (fclem) requested changes to this revision.Mar 25 2019, 8:07 PM
This revision now requires changes to proceed.Mar 25 2019, 8:07 PM

@Clément Foucault (fclem) Thank you for the review! And sorry for the delay...

  • I think having a float slider is not adequate. I prefer having a rounded multiplier list (Original resolution, Half Resolution, Quarter Resolution) to avoid some weird cases and strange interpolation when upscalling.

I think by "strange interpolation" you meant the dirty aliasing artifact with non-integral scaling like the following photoshopped image:


It's usually imperceivable if bilinear filtering is used and antialiasing is applied on the original image. I don't know what you meant by "some weird cases".
(This video gives close-up on the scaling quality)

In addition, fractional scaling factor provides users with more performance trade-offs to explore. The number of pixels shaded is quadratically proportional to the scaling factor. There is so huge difference in performance between original resolution and quarter resolution compared to their respective perceived quality and users should be given freedom of choosing an arbitrary point (not just from three predetermined points).

  • I think that we should do that at a higher level and reduce the size of the whole GPUViewport. This would be less intrusive for draw engines and would benefit all fullscreen passes. Also this would avoid the cost of a fullscreen depth pass.

This however does introduce problems due to UI scalling and fullscreen coordinate for UI elements. One way we could avoid these issues is to create another framebuffer with native resolution and blit / resolve the lower resolution framebuffer after the drawing of all the draw engines but before the UI elements (gizmos etc...). The downside is that it would use quite a bit more Vram. These changes would be isolated to the Draw manager.

Personally, I don't like other fullscreen passes to be affected by scaling for various reasons:

  • Overlay passes have much lower per-pixel rendering cost and don't benefit much from resolution reduction.
  • Overlay passes often include thin lines that would lose crispness and information density when downscaled.
    • This is especially problematic for low-end GPUs such as Intel HD Graphics series because the scale has to be lowered significantly.
  • Using nearest-neighbor upsampling preserves crispness, but then the quality of fractional scaling would be atrocious as described before.
  • Feature parity with Cycles' viewport resolution reduction.
  • Merge remote-tracking branch 'origin/master' into patch-render-scale
Harbormaster completed remote builds in B3402: Diff 14868.
  • Merge remote-tracking branch 'origin/master' into patch-render-scale
  • Eevee/LookDev: Fix the source depth buffer of the velocity resolve pass
  • Eevee/LookDev: Apply render scale on LookDev overlay's TAA jitter