Achieving Integer Scaling through GPU composition

[Pekka Paalanen]

On Tue, 21 Jan 2020 16:53:51 +0530
uday kiran pichika <udaykiran.pichika at gmail.com> wrote:

> Hello,
> 
> Am working on achieving the *Integer Scaling *through GPU composition.
> 
> What is Integer Scaling ?
>         It is an up-scaling technique that simply scales up the client's
> Source data pixels by an integer multiplier using NN(Nearest Neighbor)
> scaling filter. With Integer Scaling through NN filter, low resolution
> pixel art games being scaled to high resolution displays(4k & 8k resolution
> panels) with sharp edges. Explained below with an example  what we are
> trying to achieve.
>  EX: If the pixel art game is with a resolution of 640x480 which should
> render on a 1920x1080 panel. To upscale 640x480 to an integer multiplier
> resolution, it should upscale only to 1280x960 but not to 1920x1440 because
> it is beyond the panel resolution. The up-scaled (1280*960) image should be
> displayed on 1920x1080 panel. The remaining pixel beyond the 1280x960
> should be greyed-out.
> 
> This is what we are trying to achieve by enabling Integer scaling only in
> FULL SCREEN mode. And when IS is enabled, it should use only NN as its
> scaling filter in GL Composition path.
> 
> 
> What is present in Weston currently ?
> 
>  I know that there is scaling logic already present in the Weston
> compositor in GL composition path.
> 
> *But just wanted to know whether it is Integer scaling as mentioned above ?
> If not, does it possible to implement Integer Scaling in the compositor ?*

Hi,

yeah, Weston's GL-renderer does pick between NEAREST and LINEAR sampling
filters, but I think the conditions do not detect an integer factor,
only unity factor, so you probably get NEAREST only without any
scaling. This is something that could be fixed, but doing it properly
will take effort.

Also, since there is no DRM KMS UAPI yet (only patches AFAIK) to tell
display hardware which scaling method to use, Weston will get some
driver default scaling method when using KMS planes for scaling instead
of a renderer.

There is no existing logic for integer scaling, but only for NEAREST
sampling filter.

> As i had a conversation in IRC, *Scaling needs to be done at Client itself*.
> But it is not feasible for each and every app should do necessary code
> changes to do so. Please suggest an approach to achieve this IS with in the
> compositor itself.

The main question here is: who exactly decides that one should use
integer scaling on this particular window?

If it is the client, and the client wants to guarantee the best it ever
can that it gets exactly the integer scaling method and nothing else,
then the client must do everything itself: draw with nearest-neighbor
scaling and use sub-surfaces for letter-boxing.

If it is the compositor, then it is a question of window management
policy. Letter-boxing is already a given in xdg_toplevel fullscreen
state, you just need the nearest-neighbor scaling method to achieve
integer scaling and actually scale the window. The specification
wording for xdg_toplevel.set_fullscreen does imply unscaled window, but
OTOH it does not explicitly forbid scaling either.

The compositor case assumes that the client refuses to fill the output
itself. If the client does fill the output itself by any means
(properly sized surface, wp_viewport, sub-surfaces...) then there is no
room for the compositor to scale really.

Of course, the decision comes ultimately from the end user, but will the
end user tell his compositor or the app to use integer scaling?

Since xdg_toplevel.set_fullscreen allows surfaces smaller than the
output by letter-boxing, I could see integer scaling as a feature in
Weston. Might even make sense by default.

You probably know that almost no-one uses Weston on the desktop though.
So why Weston specifically?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200121/7c2a62b9/attachment.sig>