Re: Achieving Integer Scaling through GPU composition
On Wed, 22 Jan 2020 11:27:00 +0530 uday kiran pichika wrote: > On Tue, Jan 21, 2020 at 7:35 PM Pekka Paalanen wrote: > > > Right. Expecting a compositor to show your window unchanged is somewhat > > reasonable, but adding protocol to control the details of how a > > compositor should composite your surfaces becomes awkward fast on the > > usual desktop. > > > > I say somewhat reasonable, because things like fractional scaling, > > referring to HiDPI support with non-integer scaling factors, is a thing > > and happens mostly behind the client's back. > > > > When referrring to fractional scaling for HiDPI screens, i think wayland is > already providing the support as per the below link. Not very sure whether > this is implemented in weston compositor. > https://wiki.archlinux.org/index.php/HiDPI > > can you please elaborate on the below line from your comment "happens > mostly behind the client's back" ? do you mean that the client does not > aware how the scaling is happening down the line ? Wayland does not support fractional scaling. Wayland core protocol only supports integer output and buffer scale factors. Fractional scaling is implemented in the compositors that want to do it, like GNOME (Mutter). Clients are largely unaware that it is happening, they only see the integer output scale the compositor is telling them. What actually happens then is that clients draw in scale=1 or scale=N, and then the compositor automatically scales that to achieve the fractional scaling factor compared to scale=1. This necessarily causes some aliasing or blurring, but some people prefer particular size over quality so they want it. This is common when using monitors with "middle-sized" pixels-per-inch (a solution is to not buy such monitors in the first place). There is an optional unstable protocol extension xdg-output that delivers some information to reveal fractional scaling, but that is intended mainly for Xwayland due to Xwayland needing to know about the compositor global coordinate system so that it can translate to/from X11 coordinates. Thanks, pq pgpeNcbkYQ_X6.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Achieving Integer Scaling through GPU composition
On Tue, Jan 21, 2020 at 7:35 PM Pekka Paalanen wrote: > On Tue, 21 Jan 2020 18:54:51 +0530 > uday kiran pichika wrote: > > > Thanks Pekka for your reply. > > > > I work for an OEM company. We have given the support of Integer Scaling > > though NN in Windows environment though System Settings. > > So we are providing the similar support even in Linux environment as > well. > > This is the reason, I have chosen Weston compositor as a POC for Integer > > Scaling through NN. > > Hi, > > alright. > > > And our Display hardware supports the Scaling with multiple scaling > > filters. If we make the modifications to do the support with DRM planes, > we > > should consider the fallback option as well. So the default fallback is > GPU > > composition. > > Yes, indeed. Are you aware of the on-going work in the kernel or > perhaps participating in it? > > https://patchwork.freedesktop.org/series/68378/ is one revision of it, > I'm not sure if it is still the latest. > I'm aware of these patches and some enhancements are being made on top of these. Changes are under validation. It may take some more time to float the patches on top of these. > > > In order to provide the support to GPU composition, have started > exploring > > this Integer Scaling functionality in GL composition. > > > > As per your comments, App can't inform to the compositor about the > Integer > > Scaling for a specific window until and unless we should add an extra > > variable or some request to the surface. I think this is very bad idea of > > adding. > > Right. Expecting a compositor to show your window unchanged is somewhat > reasonable, but adding protocol to control the details of how a > compositor should composite your surfaces becomes awkward fast on the > usual desktop. > > I say somewhat reasonable, because things like fractional scaling, > referring to HiDPI support with non-integer scaling factors, is a thing > and happens mostly behind the client's back. > When referrring to fractional scaling for HiDPI screens, i think wayland is already providing the support as per the below link. Not very sure whether this is implemented in weston compositor. https://wiki.archlinux.org/index.php/HiDPI can you please elaborate on the below line from your comment "happens mostly behind the client's back" ? do you mean that the client does not aware how the scaling is happening down the line ? > > > can you please suggest, any other compositor which we can chose for the > > desktop functionality ? > > Pick any desktop environment on Linux that uses Wayland under the hood, > and it will have its own compositor. > > Weston is fine if you want to experiment with new technology, if you > need to prove a new kernel UAPI, or if you have an embedded system use > case. But if you aim for end users' desktops, then Weston does not > provide for that. > Sure Pekka. I will check for other compositor which can helpful in the desktop environment. > > > Thanks, > pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Achieving Integer Scaling through GPU composition
On Tue, 21 Jan 2020 18:54:51 +0530 uday kiran pichika wrote: > Thanks Pekka for your reply. > > I work for an OEM company. We have given the support of Integer Scaling > though NN in Windows environment though System Settings. > So we are providing the similar support even in Linux environment as well. > This is the reason, I have chosen Weston compositor as a POC for Integer > Scaling through NN. Hi, alright. > And our Display hardware supports the Scaling with multiple scaling > filters. If we make the modifications to do the support with DRM planes, we > should consider the fallback option as well. So the default fallback is GPU > composition. Yes, indeed. Are you aware of the on-going work in the kernel or perhaps participating in it? https://patchwork.freedesktop.org/series/68378/ is one revision of it, I'm not sure if it is still the latest. > In order to provide the support to GPU composition, have started exploring > this Integer Scaling functionality in GL composition. > > As per your comments, App can't inform to the compositor about the Integer > Scaling for a specific window until and unless we should add an extra > variable or some request to the surface. I think this is very bad idea of > adding. Right. Expecting a compositor to show your window unchanged is somewhat reasonable, but adding protocol to control the details of how a compositor should composite your surfaces becomes awkward fast on the usual desktop. I say somewhat reasonable, because things like fractional scaling, referring to HiDPI support with non-integer scaling factors, is a thing and happens mostly behind the client's back. > can you please suggest, any other compositor which we can chose for the > desktop functionality ? Pick any desktop environment on Linux that uses Wayland under the hood, and it will have its own compositor. Weston is fine if you want to experiment with new technology, if you need to prove a new kernel UAPI, or if you have an embedded system use case. But if you aim for end users' desktops, then Weston does not provide for that. Thanks, pq pgphmw4PNLAHz.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Achieving Integer Scaling through GPU composition
On Tue, 21 Jan 2020 14:16:09 +0200 Pekka Paalanen wrote: > On Tue, 21 Jan 2020 16:53:51 +0530 > uday kiran pichika wrote: > > > 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. I found some related issues filed: - for computing an end-to-end transformation matrix for analysis so that decision between NEAREST and LINEAR takes all combinations into account: https://gitlab.freedesktop.org/wayland/weston/issues/47 - but since that is a high risk change, we need screenshooting based tests in the test suite: https://gitlab.freedesktop.org/wayland/weston/issues/52 The latter I have finally started on, now that https://gitlab.freedesktop.org/wayland/weston/merge_requests/344 is more or less done except for one Mesa bug. This depends on https://gitlab.freedesktop.org/wayland/weston/merge_requests/287 which should be ready to merge as soon as the release freeze is lifted. However, we probably should write screenshooting tests for wp_viewport first, as well. Thanks, pq pgpmPOcr5WpGU.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Achieving Integer Scaling through GPU composition
On Tue, 21 Jan 2020 16:53:51 +0530 uday kiran pichika 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 pgpDHnOfUQPnR.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
