On Mon, Oct 14, 2019 at 09:11:17AM +0000, Brian Starkey wrote: > On Fri, Oct 11, 2019 at 07:25:02PM +0200, Daniel Vetter wrote: > > On Fri, Oct 11, 2019 at 12:56 PM Brian Starkey <Brian.Starkey@xxxxxxx> 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: > > > > > > > Are you sure the GPU supports other orders? I think any Arm driver > > > > > will only be producing DRM_FORMATs with "BGR" order e.g. ABGR888> > > > > > I'm not convinced the GPU HW actually supports any other order, but > > > > > it's all rather confusing with texture swizzling. What I can tell you > > > > > for sure is that it _does_ support BGR order (in DRM naming > > > > > convention). > > > > > > > > Well, since the Bifrost Mali blobs are closed-source and delivered > > > > by licensees, it's hard to define what is supported from a closed > > > > GPU HW, closed SW implementation to a closed pixel format implementation. > > > > > > > > > > I hear you. IMO the only way to make any of this clear is to publish > > > reference data and tests which make sure implementations match each > > > other. It's something I'm trying to make happen. > > > > *cough* igt test with crc/writeback validation *cough* > > > > And you don't even need anything that actually compresses. All you > > need is the minimal enough AFBC knowledge to set up the metadata that > > everything is uncompressed. We're doing that for our intel compression > > formats already, and it works great in making sure that we have > > end-to-end agreement on all the bits and ordering and everything. > > Yeah this was my original thinking too. Sadly, a decent number of the > AFBC parameters can't be tested with uncompressed data, as the codec > kicks into a different mode there. Hm right I guess some of the flags/parameters only matter if you deal with actual compressed data. Still, better than nothing I guess - this should at least catch stuff like color channels wired up the wrong way compared to linear, and fun stuff like that. > > Ofc > > it doesn't validate the decoder, but that's not really igts job. > > Should be possible to convince ARM to release that (as open source, in > > igt), since it would be fairly valuable for the entire ecosystem here > > ... > > I fully agree about the value proposition. I'll be waiting for patch from arm then :-) Cheers, 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
