On Tue, Feb 23, 2021 at 7:50 PM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > Hi Brian, > > On Tue, 23 Feb 2021 at 18:34, Brian Starkey <brian.starkey@xxxxxxx> wrote: > > On Tue, Feb 23, 2021 at 05:10:16PM +0000, Alyssa Rosenzweig wrote: > > > But it seems to me allowing > > > both BGR+YTR and RGB+YTR upstream is the better route than simply > > > preventing hardware from using AFBC at all, and there are natural > > > encodings for both with fourcc modifiers. > > > > Are those the only options? I see XBGR8888, ABGR8888, BGR888 and > > BGR565 are all handled in vop_convert_afbc_format(), which are all > > "valid" for use with YTR, and all except XBGR are on the "preferred" > > AFBC format list in afbc.rst. > > The issue is a userspace one though, not a kernel one. Userspace (e.g. > GNOME Shell, Weston, Xorg) decides ahead of time that it's going to > use XRGB8888, then use the modifiers available to it for that format. > There's no logic in those projects to look at the list of 8bpc > non-alpha formats, examine XRGB vs. XBGR, decide that XBGR is 'better' > since it has more modifiers available, then go use XBGR. That sounds a bit like userspace being too simple. Since if they're ok with dealing with modifiers accessing the raw buffer is out the window anyway, so bgr vs rgb shouldn't matter. > So whilst removing XRGB+AFBC wouldn't technically remove the > possibility to use AFBC, the practical effect is that it wouldn't be > used. But also this ofc. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
