3
$\begingroup$

I was under the impression that the frame buffer resolution always has to be the same as the physical screen resolution, so changing the software resolution settings would not affect rasterization. But after I made a demo and ran a profiler against it, the profiler told me that the frame buffer resolution changed according to my settings and fewer pixels were rasterized.

This brings up other questions I am unable to figure out. Which part of the rendering pipeline does re-sample the frame buffer to match the screen resolution? And the re-sampling stage does not show up in the profiler (Intel GPA for Android), is it so fast that I can safely ignore it or I am missing something that would cost me here?

Thank you.

Improve this question
$\endgroup$

2 Answers 2

Reset to default
2
$\begingroup$

For PCs with discrete displays, the resampling to the screen resolution may happen either on the computer prior to the signal being sent to the display, as part of window compositing, or on the display side. I don't think it's anything to worry about in terms of FPS, in either case, but it possibly could affect latency.

It depends whether you're in "true" fullscreen (exclusive) mode or not. If the app renders to a window, including a borderless fullscreen window, then the window compositor (part of the OS) will be running each frame, and any upsampling needed can happen "for free" as part of that operation. In other words, I wouldn't expect an upsample during compositing to cost noticeably more than it does to do compositing in general (which is very cheap).

On the other hand, if you're in true fullscreen and your app has exclusive control of the display, it's possible to set the video mode to something non-native and send your rendered image directly to the display, in which case the display's scaler chip will handle it, again without performance cost to you, since it's happening in parallel to anything going on with the GPU.

You mentioned Android, so I assume you're working on a mobile device. In that case, I'm not sure if there is a scaler chip, or if the mobile GPU is just expected to always output at native resolution, in which case scaling would always be done on the GPU by the compositor software. (By the way, the reason the scaling doesn't show up in profiling is likely because it's being done by the OS rather than by your app.)

That being said, though upscaling is very cheap, it does imply an extra pass that could increase input latency. With a borderless fullscreen window, if no other windows are visible on top of your app, and no scaling is required, the compositor could be short-circuited so that your app writes directly to the display output rather than passing through the compositor. (This is an optimization that the OS would have to perform when it detects that all the conditions are right.) Similarly, on the display, if no extra image processing is required including scaling, color correction, etc. then some stages of the display hardware might be bypassed. In either case, you could see lower latency when you render directly to native resolution than when you require scaling. This is a matter of concern for VR in particular.

Improve this answer
$\endgroup$
1
$\begingroup$

This is the screen's video scaler module. Essentially, it is a dedicated piece of silicon that allows the user to use non-native screen resolutions.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.