Bug 94820

Summary: Nearest neighbor scaling?
Product: xorg Reporter: N. W. <nw9165-3201>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: enhancement    
Priority: medium    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description N. W. 2016-04-04 14:49:11 UTC
Hello,

would it be possible that you add a nearest-neighbor scaling mode to the driver, so that one could display 1920x1080 natively on a 3840x2160 monitor or 1280x720 natively on a 2560x1440 monitor and so on (one pixel becomes four pixels)?

There is some information on this topic over there:

https://forums.geforce.com/default/topic/844905/geforce-drivers/integer-scaling-mode/

Regards
Comment 1 Michel Dänzer 2016-04-05 03:57:07 UTC
Looks like everything necessary for this is already available to clients via the RandR extension.

*** This bug has been marked as a duplicate of bug 94816 ***
Comment 2 Grigori Goronzy 2016-04-05 06:44:37 UTC
I don't believe so. It should be possible to configure filter kernels for the hardware scalers, but this isn't exposed anywhere. The default seems to be some bicubic variant on my card. It's all set up by ATOMBIOS.
Comment 3 Michel Dänzer 2016-04-05 07:01:34 UTC
Grigori, see the patch and discussion on bug 94816.
Comment 4 N. W. 2016-04-05 13:22:42 UTC
(In reply to Michel Dänzer from comment #3)
> Grigori, see the patch and discussion on bug 94816.

Why are you pointing him to the xrandr patch?

I think Grigori means something else.

With the xrandr patch, the scaling happens in software, right?

What Grigori most likely means is, that AMD GPUs/APUs most probably have a dedicated hardware scaler in their GPU which could be used for image scaling instead of xrandr?

I'm fairly sure the GPU must have a dedicated hardware scaler, otherwise it could not scale up the image on POST.

AMD GPUs even default to underscan on POST (on a lot of displays), so there must be a hardware scaler in use/available.

In his case this hardware scaler seems to be using a bicubic filter.

What he (and me) would like to know is how one could tell the hardware scaler to use nearest neighbor filtering instead of bicubic/bilinear filtering.

Or does xrandr actually utilize the dedicated hardware scaler inside the GPU?

Can anyone comment on this please?

Regards
Comment 5 Alex Deucher 2016-04-05 13:35:16 UTC
(In reply to nw9165-3201 from comment #4)
> (In reply to Michel Dänzer from comment #3)
> > Grigori, see the patch and discussion on bug 94816.
> 
> Why are you pointing him to the xrandr patch?
> 
> I think Grigori means something else.
> 
> With the xrandr patch, the scaling happens in software, right?

It's done on the 3D engine.

> 
> What Grigori most likely means is, that AMD GPUs/APUs most probably have a
> dedicated hardware scaler in their GPU which could be used for image scaling
> instead of xrandr?
> 
> I'm fairly sure the GPU must have a dedicated hardware scaler, otherwise it
> could not scale up the image on POST.
> 
> AMD GPUs even default to underscan on POST (on a lot of displays), so there
> must be a hardware scaler in use/available.
> 
> In his case this hardware scaler seems to be using a bicubic filter.
> 
> What he (and me) would like to know is how one could tell the hardware
> scaler to use nearest neighbor filtering instead of bicubic/bilinear
> filtering.
> 
> Or does xrandr actually utilize the dedicated hardware scaler inside the GPU?
> 

The randr scale options use the 3D engine.  Picking a non-native mode to display on the panel uses either the scaler in the monitor (default for external monitors) or the scaler on the GPU's display controller (default for fixed laptop panels).
Comment 6 N. W. 2016-04-05 13:43:01 UTC
(In reply to Alex Deucher from comment #5)
> The randr scale options use the 3D engine.  Picking a non-native mode to
> display on the panel uses either the scaler in the monitor (default for
> external monitors) or the scaler on the GPU's display controller (default
> for fixed laptop panels).

Thanks for the swift reply. Okay, so first question:

You said the scaler on the GPU's display controller is only used for fixed laptop panels by default.

Why is that?

And is it possible to use the scaler on the GPU's display controller for external monitors as well?

If yes: How?

And, to come back to what Grigori and me were hinting at: Is it possible to tell the scaler on the GPU's display controller to use nearest neighbor scaling? Is it possible to change the filter of the scaler on the GPU's display controller?

If yes: How?

Regards
Comment 7 Alex Deucher 2016-04-05 13:53:32 UTC
(In reply to nw9165-3201 from comment #6)
> (In reply to Alex Deucher from comment #5)
> > The randr scale options use the 3D engine.  Picking a non-native mode to
> > display on the panel uses either the scaler in the monitor (default for
> > external monitors) or the scaler on the GPU's display controller (default
> > for fixed laptop panels).
> 
> Thanks for the swift reply. Okay, so first question:
> 
> You said the scaler on the GPU's display controller is only used for fixed
> laptop panels by default.
> 
> Why is that?

Some people prefer the monitor's scaler.  It's not always clear which mode is the monitors native mode so you could theoretically end up with double scaling (once on the monitor, once on the GPU).

> 
> And is it possible to use the scaler on the GPU's display controller for
> external monitors as well?
> 
> If yes: How?

Yes:
xrandr --output <output> --set "scaling mode" "<scaling mode>"
Where scaling mode is one of:
None, Full, Center, Full aspect
E.g.,
xrandr --output DVI-0 --set "scaling mode" "Full aspect"

> 
> And, to come back to what Grigori and me were hinting at: Is it possible to
> tell the scaler on the GPU's display controller to use nearest neighbor
> scaling? Is it possible to change the filter of the scaler on the GPU's
> display controller?
> 
> If yes: How?

I'm not sure what algorithm(s) the display scaler uses or can use off hand.  We just use whatever the default is.

Alex
Comment 8 N. W. 2016-04-05 14:16:38 UTC
(In reply to Alex Deucher from comment #7)
> I'm not sure what algorithm(s) the display scaler uses or can use off hand. 
> We just use whatever the default is.

Hi Alex, thanks again for the swift reply, much appreciated :).

Well, could you please please find out what algorithms the display scaler uses or can use?

I have always been very interested in this. The scaler on the GPU's display controller is a bit mysterious, because there is not much information available on this topic at all. It would be really nice if you could bring some light into this.

Actually, in the Xbox 360 era, there was some talk about the scaler inside the Xbox 360 (AMD GPU). It's documented in the following thread on the Beyond3D forum, see:

https://forum.beyond3d.com/threads/list-of-rendering-resolutions.41152/

> 360
>
> Xenos is the hardware scaler, not HANA/ANA, which are just the video
> output chips dealing with digital/analog output to the various
> connections made with the display. Dave Baumann
>
> AVIVO takes more samples for scaling so it is expected that the
> scaling is better [strike](the algorithm also appears to be
> some form of bicubic, not a simple bilinear)[/strike]
> Update: see below
>
> Hardware scaling to the output resolution chosen in the dashboard is
> [strike]automagically performed[/strike] :?:.
>
> In upscaling to 1080p, some games may first scale to 720p in software
> before the GPU scales to a 1080p output. e.g. RR6, SCIV, VF5,
> CoD4, H3, TR:L...
>
> Some games let the GPU handle the scaling to 1080p directly
> from the arbitrary resolution. e.g. MotoGP 06, PGR3, ESIV:O...
>
> "lanczos is just one of the selectable filters. Ultimately each game
> 'could' opt to use a different filter/sample count combination
> (though I suspect most don't bother)." -Fafalada

So, as you can see, there was even a mention that the algorithm (filter) could be changed from Bicubic to Lanczos and so on...

Now it would be interesting to know if all AMD GPUs have this capability and how it can be utilized.

And does the scaler on the GPU's display controller have a dedicated name? In the talk above it seems to be referred to as "AVIVO"?

Also, it would be nice if you could clarify if AMD's VSR (Virtual Super Resolution) is performed on the scaler on the GPU's display controller or if it is performed elsewhere.

Again, would be really nice if you could clarify all those things, the AMD GPUs have a hardware scaler that is sitting there, but nothing is really known about it, which is unfortunate.

Regards
Comment 9 Alex Deucher 2016-04-05 14:25:03 UTC
It's just called the scaler.  The registers are pre-fixed with SCL for scaler.  There is one per display controller.  You can take a look at the registers and DAL implementation for more info:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.7-wip-polaris
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/include/asic_reg/dce?h=drm-next-4.7-wip-polaris
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/amd/dal?h=drm-next-4.7-wip-polaris
Comment 10 N. W. 2016-04-05 14:53:31 UTC
(In reply to Alex Deucher from comment #9)
> It's just called the scaler.  The registers are pre-fixed with SCL for
> scaler.  There is one per display controller.  You can take a look at the
> registers and DAL implementation for more info:

Thanks, but how does this tell me if and how I could change the filter used by the scaler on the GPU's display controller?

Sorry, not a programmer.
Comment 11 Martin Peres 2019-11-19 07:55:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/156.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.