<p>&quot;Panel fitter&quot; appears to be a very specific <a href="https://www.x.org/docs/intel/BYT/intel_os_gfx_prm_vol10_-_display.pdf#page=145" rel="nofollow noreferrer">Intel hardware</a> denomination that Microsoft <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dxgiddi/ne-dxgiddi-dxgi_ddi_multiplane_overlay_flags" rel="nofollow noreferrer">adopted</a>.</p>
<p>From a description of its purposes it wouldn't seem any particularly different from the normal GPU scaling you can find in any video adapter since forever, but given this supposed &quot;screen subregion capability&quot; they mention on your MSDN link I would guess it's more featureful than competitors (probably in an effort to shave power consumption anywhere possible, which may also explain how they could be the first vendor to roll out MPO).</p>
<p>And in this sense, it's not hard to imagine why CRTC magic has hardwired <a href="https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/v1.29/tools/intel_panel_fitter.c#L189" rel="nofollow noreferrer">limits</a> (they can be checked in the dxdiag extended log, together with the <a href="https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/ns-d3dkmthk-_d3dkmt_multiplane_overlay_caps" rel="nofollow noreferrer">PanelFitter Caps</a>).</p>
<hr />
<p>As for the second question, they obviously were talking about separating the concepts of <em>3D rendering</em> resolution and <em>display output</em> resolution. The point wasn't that &quot;a list is provided&quot; (be it limited to a few standard resolutions, or with the full results returned by <code>EnumAdapterModes</code>) but that you are just offering one single knob.</p>
<p>Like.. it's not that there couldn't be reasons to switch the actual resolution, even on a fixed-grid display (e.g. perhaps higher refresh rates or bit depths require enabling chroma subsampling) but the great majority of users just wants to lower the performance requirements. And if not any in a modern GPU world where <a href="https://www.intel.com/content/www/us/en/developer/articles/training/tutorial-migrating-your-apps-to-directx-12-part-4.html" rel="nofollow noreferrer">merging</a> entire separate image planes is itself a trivial operation, making this possible is a no-brainer.</p>
<p>Besides the often manifested in-game benefit of unblurred subtitles or UI no matter how slow the system may be, if you are multi-tasking you can still enjoy the rest of your desktop windows at their maximum resolution.</p>
<blockquote>
<p>displays with the ability to seamlessly begin scaling content</p>
</blockquote>
<p>Though I'm still not exactly sure what was meant here. I'm not aware of any big display-side image scaling advancement in the last decade (or ever FWIW). So, I thought it can be either:</p>
<ul>
<li>a typo, meaning instead &quot;display controllers&quot; (in the sense they are what allows for the nicest stuff here)</li>
<li>a metonymy while thinking of laptops, where the display control logic is one and the same with the gpu</li>
<li>&quot;seamless scaling&quot; in a <em>physical visual acuity</em> way rather than a <em>digital image processing</em> one, i.e. screens today can be so pixel dense that just because a frame is undersampled it doesn't mean it still couldn't pack enough detail to be indistinguishable at least from the right distance (and while applications just settling for the evergreen bilinear interpolation would be neutral in this regard, if they reworked their presentation pipeline there are <a href="https://www.intel.com/content/dam/develop/external/us/en/documents/checkerboard-rendering-for-real-time-upscaling-on-intel-integrated-graphics.pdf" rel="nofollow noreferrer">long ways</a> they could go to lower the perceptual transparency threshold)</li>
</ul>

CC BY-SA 4.0
2024-10-19T01:22:32.447Z
2024-11-22T17:01:06.103Z
2024-11-22T17:01:06.103Z
mirh
<p>What they're saying is you don't have to <em>render</em> the game at the same resolution that it's displayed. For example you could be in a display mode of 1920×1080, but have the game rendering at only 1280×720, to run faster. The OS and display hardware can automatically upscale the frames to the display resolution under the hood.</p>

<p>Usually, the OS runs a window compositor, a background process that draws the desktop, all app windows, menus, etc and presents them to the display. In windowed mode, any upscaling needed would be done by the compositor. However if the game's window is covering the whole display ('borderless fullscreen') and nothing else is on top, then the OS can switch off the compositor and let the game present to the display directly.</p>

<p>But then if the game is at a lower resolution than the display, it still needs to be upscaled. The GPU can do this in hardware (scanout) <em>as long as</em> the scaling factor isn't too big. For instance, there may be a limit of 4x scaling. So, if your rendering resolution is more than 4x smaller than the display, the OS can't use the hardware upscaling and would need to keep using the window compositor instead. All of this stuff happens automatically in Windows 10, without the app needing to know about it or do anything special.</p>

<p>Given all this, they point out that there's no real reason for the <em>rendering</em> resolution of the game to be limited to the classic display modes like 800×600, 1024×768, 1280×720, etc. You might as well have a continuous resolution slider instead of a fixed set of modes. There's no problem with choosing a "weird" resolution like, say, 1000×562 or something. The upscaler/compositor will just take care of it.</p>

<p>This what they mean by "consider providing users with the ability to choose a rendering resolution for performance scaling, independent from an output resolution". In other words, in your game's options screen, you should give the user a slider to control rendering resolution, so they can tune it for performance vs visual quality. But it need not be tied to the actual display resolution.</p>

CC BY-SA 3.0
2018-04-12T21:34:46.770Z
2018-04-12T21:34:46.770Z
Nathan Reed
<p>I'm reading <a href="https://blogs.msdn.microsoft.com/directx/2018/04/09/dxgi-flip-model/" rel="nofollow noreferrer">DXGI flip model</a> article and some parts are not clear:</p>

<ul>
<li><blockquote>
  <p>DirectFlip with panel fitters: Your window client region covers the screen, and your swapchain buffers are within some hardware-dependent scaling factor (e.g. 0.25x to 4x) of the screen. The GPU scanout hardware is used to scale your buffer while sending it to the display.</p>
</blockquote>

<p>What is this hardware-dependent scaling factor? What it does? Why?</p></li>
<li><blockquote>
  <p>The traditional pattern for apps in the past has been to provide the user with a list of resolutions to choose from when the user selects exclusive fullscreen mode. With the ability of modern displays to seamlessly begin scaling content, consider providing users with the ability to choose a rendering resolution for performance scaling, independent from an output resolution, and even in windowed mode.</p>
</blockquote>

<p>I understand what they mean by the <em>traditional pattern</em>, it's pretty common - I'm selecting a resolution in the options screen and enjoying fullHD 800*600 picture. But I have no clue what are they describing next - <em>displays seamlessly scaling content</em>, <em>resolution for performance scaling</em>, <em>output resolution</em>. Could someone explain the same with simple words and examples (I bet there are already games out there that uses the technology)?</p></li>
</ul>

<pixels>
What is a scaling factor of the screen?
nikitablack
# What is a scaling factor of the screen?

(Asked by: username_0 on 2018-04-09)

I'm reading [DXGI flip model](https://blogs.msdn.microsoft.com/directx/2018/04/09/dxgi-flip-model/) article and some parts are not clear:

* > DirectFlip with panel fitters: Your window client region covers the screen, and your swapchain buffers are within some hardware-dependent scaling factor (e.g. 0.25x to 4x) of the screen. The GPU scanout hardware is used to scale your buffer while sending it to the display.

  What is this hardware-dependent scaling factor? What it does? Why?
* > The traditional pattern for apps in the past has been to provide the user with a list of resolutions to choose from when the user selects exclusive fullscreen mode. With the ability of modern displays to seamlessly begin scaling content, consider providing users with the ability to choose a rendering resolution for performance scaling, independent from an output resolution, and even in windowed mode.

  I understand what they mean by the *traditional pattern*, it's pretty common - I'm selecting a resolution in the options screen and enjoying fullHD 800\*600 picture. But I have no clue what are they describing next - *displays seamlessly scaling content*, *resolution for performance scaling*, *output resolution*. Could someone explain the same with simple words and examples (I bet there are already games out there that uses the technology)?

**Tags:** pixels


---

## 2 answers

### Answer by username_2 on 2018-04-12. Score: 4 | Accepted answer

What they're saying is you don't have to *render* the game at the same resolution that it's displayed. For example you could be in a display mode of 1920×1080, but have the game rendering at only 1280×720, to run faster. The OS and display hardware can automatically upscale the frames to the display resolution under the hood.

Usually, the OS runs a window compositor, a background process that draws the desktop, all app windows, menus, etc and presents them to the display. In windowed mode, any upscaling needed would be done by the compositor. However if the game's window is covering the whole display ('borderless fullscreen') and nothing else is on top, then the OS can switch off the compositor and let the game present to the display directly.

But then if the game is at a lower resolution than the display, it still needs to be upscaled. The GPU can do this in hardware (scanout) *as long as* the scaling factor isn't too big. For instance, there may be a limit of 4x scaling. So, if your rendering resolution is more than 4x smaller than the display, the OS can't use the hardware upscaling and would need to keep using the window compositor instead. All of this stuff happens automatically in Windows 10, without the app needing to know about it or do anything special.

Given all this, they point out that there's no real reason for the *rendering* resolution of the game to be limited to the classic display modes like 800×600, 1024×768, 1280×720, etc. You might as well have a continuous resolution slider instead of a fixed set of modes. There's no problem with choosing a "weird" resolution like, say, 1000×562 or something. The upscaler/compositor will just take care of it.

This what they mean by "consider providing users with the ability to choose a rendering resolution for performance scaling, independent from an output resolution". In other words, in your game's options screen, you should give the user a slider to control rendering resolution, so they can tune it for performance vs visual quality. But it need not be tied to the actual display resolution.


---

### Answer by username_1 on 2024-10-19. Score: 0

"Panel fitter" appears to be a very specific [Intel hardware](https://www.x.org/docs/intel/BYT/intel_os_gfx_prm_vol10_-_display.pdf#page=145) denomination that Microsoft [adopted](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dxgiddi/ne-dxgiddi-dxgi_ddi_multiplane_overlay_flags).

From a description of its purposes it wouldn't seem any particularly different from the normal GPU scaling you can find in any video adapter since forever, but given this supposed "screen subregion capability" they mention on your MSDN link I would guess it's more featureful than competitors (probably in an effort to shave power consumption anywhere possible, which may also explain how they could be the first vendor to roll out MPO).

And in this sense, it's not hard to imagine why CRTC magic has hardwired [limits](https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/v1.29/tools/intel_panel_fitter.c#L189) (they can be checked in the dxdiag extended log, together with the [PanelFitter Caps](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/ns-d3dkmthk-_d3dkmt_multiplane_overlay_caps)).

---

As for the second question, they obviously were talking about separating the concepts of *3D rendering* resolution and *display output* resolution. The point wasn't that "a list is provided" (be it limited to a few standard resolutions, or with the full results returned by `EnumAdapterModes`) but that you are just offering one single knob.

Like.. it's not that there couldn't be reasons to switch the actual resolution, even on a fixed-grid display (e.g. perhaps higher refresh rates or bit depths require enabling chroma subsampling) but the great majority of users just wants to lower the performance requirements. And if not any in a modern GPU world where [merging](https://www.intel.com/content/www/us/en/developer/articles/training/tutorial-migrating-your-apps-to-directx-12-part-4.html) entire separate image planes is itself a trivial operation, making this possible is a no-brainer.

Besides the often manifested in-game benefit of unblurred subtitles or UI no matter how slow the system may be, if you are multi-tasking you can still enjoy the rest of your desktop windows at their maximum resolution.

> displays with the ability to seamlessly begin scaling content

Though I'm still not exactly sure what was meant here. I'm not aware of any big display-side image scaling advancement in the last decade (or ever FWIW). So, I thought it can be either:

* a typo, meaning instead "display controllers" (in the sense they are what allows for the nicest stuff here)
* a metonymy while thinking of laptops, where the display control logic is one and the same with the gpu
* "seamless scaling" in a *physical visual acuity* way rather than a *digital image processing* one, i.e. screens today can be so pixel dense that just because a frame is undersampled it doesn't mean it still couldn't pack enough detail to be indistinguishable at least from the right distance (and while applications just settling for the evergreen bilinear interpolation would be neutral in this regard, if they reworked their presentation pipeline there are [long ways](https://www.intel.com/content/dam/develop/external/us/en/documents/checkerboard-rendering-for-real-time-upscaling-on-intel-integrated-graphics.pdf) they could go to lower the perceptual transparency threshold)


---

