On 15/10/2019 13:18, Brian Starkey wrote: > 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? Amlogic gave ma a libMali for miniGBM with AFBC enabled, but I haven't been able to enable AFBC yet. > > I went and asked around. An Arm gbm implementation supporting AFBC > will reject AFBC allocations for orders other than (DRM-convention) > BGR. I trust you on this point, thanks for asking around. Neil > > Thanks, > -Brian > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
