Hi Neil, On Fri, Oct 11, 2019 at 02:07:01PM +0200, Neil Armstrong wrote: > On 11/10/2019 12:56, Brian Starkey wrote: > > Hi, > > > > On Fri, Oct 11, 2019 at 11:14:43AM +0200, Neil Armstrong wrote: > >> Hi Brian, > >> > >> On 11/10/2019 10:41, Brian Starkey wrote: > >>> Hi Neil, > >>> > >>> On Thu, Oct 10, 2019 at 03:41:15PM +0200, Neil Armstrong wrote: [snip] > >> You'll have to tell us if the closed libMali handling AFBC would accept > >> ARGB8888 as format to render with AFBC enabled, if not you're right > >> I'll discard XRGB8888/ARGB8888 for AFBC buffers completely. > >> > >> But it the libMali chooses tt generate an ARGB8888 buffer whatever > >> ARGB8888/XRGB8888/ABGR888/XBGR888 is asked, then no I'll keep it that way. > >> > > > > Yeah, I'll try and get clarity on this. It's not at all clear to me > > either. When you say "accept ARGB8888 as format to render with AFBC > > enabled", which API are you referring to, just so I can be clear? Do > > you have an example of some code you're using to render AFBC with the > > GPU blob? > > Let's take kmscube using EGL and GBM. > > The buffer is allocated using gbm_surface_create_with_modifiers(), > but the gbm implementation is vendor specified. > > Then the surface is passed to eglCreateWindowSurface(). > Then the format is matched using eglGetConfigAttrib() with the > returned configs. > > Here support on the gbm and EGL implementation. > Is this a use-case that works on your platform today? I went and asked around. An Arm gbm implementation supporting AFBC will reject AFBC allocations for orders other than (DRM-convention) BGR. Thanks, -Brian _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
