13:10 <robmur01> beware that RK3399 only supports AFBC on one of the two display engines, so it can depend on which crtc your given display pipeline ends up using

13:11 <robmur01> otherwise, Mediatek and Amlogic seem to be the only other display drivers with upstream AFBC support at the moment

13:12 <robmur01> (the Mali displays are so rare in available silicon I'm not counting them :P)

13:22 <robmur01> ((and of course that's not to discount the newer Rockchip RK35xx SoCs either, which I believe have better AFBC support than RK3399))

13:25 <daniels> yeah, RK356[68] and 3588 do per-plane rather than per-CRTC AFBC

13:26 <daniels> though they arguably go a little bit too far, where there are some planes that _only_ support AFBC

13:26 <daniels> (either no linear at all, or linear only for RGB formats, or linear only when you're unrotated, depending on which one)

13:38 <alyssa> amazing

14:49 <robclark> linear + rotated by 90/270 isn't great for memory access patterns, so wanting some variant of tiled for that isn't too surprising

15:00 <jernej> I'm planning to upstream Allwinner H6 AFBC support, but I'm a little unsure how to test supported features

15:02 <jernej> from vendor code it's obvious that sparse, split and ytr are supported

15:03 <jernej> but then there is something unusual, called default colour, which is supposed to be white

15:04 <jernej> is there such standard AFBC feature?

15:05 <jernej> I can enable it on HW video decoder side, which is AFBC buffer producer, but there is no explanation whatsoever

15:08 <daniels> hm, I've seen solid-colour as a feature, but not 'default' colour

15:08 <daniels> I wonder if that's what gets used to fill in edges for images which aren't fully aligned to the tile size

15:10 <jernej> are there custom extensions from SoCs designers?

15:10 <jernej> well, it can be either poorly named register bit or a custom extension

15:11 <jernej> is there a way to test solid-colour feature?

15:12 <jernej> it has T720, if that helps

15:12 <daniels> at a guess, force your decoder output to be some weird dimension (e.g. odd number of pixels wide), play around with the default-colour register, and see what the output looks like when you decode it

15:13 <daniels> oh sorry, I'm wrong, I just can't grep

15:14 <jernej> I already misprogrammed those "default colour" registers in display driver and got funky looking middle of the frame. But it looked like a solid fill.

15:15 <daniels> yeah, so it looks like if there are substantial areas of a particular colour value, you can set the per-channel default colour values, and that will allow you to save some space when you're dealing with a region that has that colour

15:16 <jernej> so that's maybe AFBC_FORMAT_MOD_SC?

15:17 <daniels> nope, SC is something else

15:19 <daniels> oh wait, /me reads further

15:19 <daniels> no, it's hard-coded per format

15:20 <jernej> annoying, not sure how to properly expose it then

15:21 <jernej> but I guess it's meant to be used only between display driver and hw video decoder

15:37 <alyssa> jernej: does t720 even support afbc?

15:37 <jernej> good question

15:38 <alyssa> daniels: solid colour blocks are a much newer afbc feature, new in bifrost IIRC, and tied to tiled AFBC mode

15:38 <alyssa> jernej: iirc t760 introduced afbc but i've paged out a lot of mali

15:39 <jernej> I'll make AFBC plane primary and then run some GLES app

15:39 <jernej> mesa should then use AFBC automatically, right?

15:39 <daniels> yep, afbc is t760+

15:39 <jernej> ok, so no point then

15:40 <jernej> but then I have newer soc with G31, where test may be sensible

20:41 <anarsoul> daniels: can you please set +R mode on this channel?

20:44 <daniels> what does that do?

20:44 <anarsoul> R - client may join only when registered and identified to NickServ

20:44 <anarsoul> it looks like spammers are spamming in PM now