An Optimization Proposed For GNOME + NVIDIA On High Refresh Rate Displays
GNOME-focused Ubuntu desktop developer Daniel Van Vugt of Canonical has proposed an optimization that could help with running NVIDIA graphics on high refresh rate displays.
For those using a high refresh rate display with NVIDIA graphics on GNOME, especially with today's 240Hz or even 360Hz displays, better handling is on the way to allow more time for rendering each frame to complete before GNOME's Mutter falls back to a slower frame interval.
Mutter has a static sync delay fallback value currently of 2ms. When running NVIDIA graphics on a 240Hz monitor where there is a ~4.1ms refresh interval, that leaves just a maximum render time of 2.1ms before falling back to a 120Hz refresh rate. But by changing that value to a fraction (value of 0.875), it won't regress behavior for common 60Hz displays but would allow a maximum render time of around 3.6ms rather than 2.1ms before falling back to a lower rate. With that extra 1.5ms of render time for each frame, there is greater chances of the deadline being met and avoid Mutter scaling down to 120Hz. Similarly, using a fraction rather than the static value should be of more help for 360Hz and other increasingly high refresh rate monitors coming to market.
The patch to change that Clutter frame clock value is currently under review for Mutter and could land for GNOME 42.
Concurrently, Daniel Van Vugt is still pursuing triple buffering for GNOME. On that front he has been working on an improved scaling algorithm and re-implemented a smoothness workaround.
For those using a high refresh rate display with NVIDIA graphics on GNOME, especially with today's 240Hz or even 360Hz displays, better handling is on the way to allow more time for rendering each frame to complete before GNOME's Mutter falls back to a slower frame interval.
Mutter has a static sync delay fallback value currently of 2ms. When running NVIDIA graphics on a 240Hz monitor where there is a ~4.1ms refresh interval, that leaves just a maximum render time of 2.1ms before falling back to a 120Hz refresh rate. But by changing that value to a fraction (value of 0.875), it won't regress behavior for common 60Hz displays but would allow a maximum render time of around 3.6ms rather than 2.1ms before falling back to a lower rate. With that extra 1.5ms of render time for each frame, there is greater chances of the deadline being met and avoid Mutter scaling down to 120Hz. Similarly, using a fraction rather than the static value should be of more help for 360Hz and other increasingly high refresh rate monitors coming to market.
The patch to change that Clutter frame clock value is currently under review for Mutter and could land for GNOME 42.
Concurrently, Daniel Van Vugt is still pursuing triple buffering for GNOME. On that front he has been working on an improved scaling algorithm and re-implemented a smoothness workaround.
4 Comments