02:19 <icecream95> Fun fact: SuperTuxKart uploads about 1MB of push constants per second

02:22 <HdkR> That's not terrible

02:24 <icecream95> It all gets uploaded twice, but it shouldn't be too hard to fix that...

03:01 <alyssa> whistle

03:43 <cyrozap> alyssa: Thanks! And yeah, I'll probably try to figure out the other fields first, since I don't even know the meaning of the value being used as the input to the function.

03:45 <cyrozap> adjtm: When you say "posits", are you referring to this? https://en.wikipedia.org/wiki/Unum_(number_format)#Unum_III

06:47 <bbrezillon> alyssa: sure, I can take care of indirect compute dispatch

08:15 <bbrezillon> alyssa: regarding the AFBC issue, I don't really have a clean solution

08:18 <bbrezillon> applying the format fixup when the importer and exporter pass it to the GPU is okay, but you have a problem when one of them is a different piece of HW

09:10 <bbrezillon> alyssa: not sure that's what we want, but this seems to fix the problem => https://gitlab.freedesktop.org/bbrezillon/mesa/-/commit/ea1ba92530783ba73bc0d750d8fbaa9b8ba78e07

12:35 <alyssa> bbrezillon: That's definitely what we want :+1:

12:50 <daniels> this means that AFBC is disallowed for XRGB and only allowed for XBGR, if I read correctly?

12:56 <bbrezillon> it's actually only allowed for RGBX/RGBA

12:57 <bbrezillon> not XRGB

12:57 <bbrezillon> and yes, BGR is rejected

12:58 <bbrezillon> daniels: do you have a better option?

12:58 <daniels> right, RGBX/RGBA == ABGR/XBGR in DRM_FORMAT_* nomenclature

12:59 <daniels> I don't have a better option, just wanted to confirm what I was seeing :)

12:59 <bbrezillon> oh, ok

13:41 <adjtm> cyrozap, yes, I'm referring to unum III

13:42 <adjtm> the way it uses the first consecutive ones in the input value is like posits encode the regime

13:43 <adjtm> but sure it's not a posit, and maybe not even using it for floating point numbers

15:09 <robclark> bbrezillon, daniels: UBWC (and tiled non-UBWC) is similar on adreno.. we just define the modifier as "native swizzle" since it is an opaque format.. although I guess in your case you need to get all the display drivers that support AFBC to go along with the scam

15:09 <robclark> so UBWC RGBx and xBGR, etc, are all the same thing

15:13 <bbrezillon> robclark: yep, that's the problem, I don't know what display controllers do when you tell them it's AFBC(BRG)

15:13 <bbrezillon> if they interpret it as AFBC(RGB) we're good

15:14 <robclark> I guess since there are (presumably) some display controllers already supporting the existing modifier, you could use the existing modifier for native swizzle (as you do), but then introduce a new modifier for "fake swizzle"..

15:15 <robclark> *but*.. do existing display controllers advertise support for AFBC with all swizzles? If no, that might be an escape hatch to salvage the current modifier

15:16 <bbrezillon> I might have found another solution => https://gitlab.freedesktop.org/bbrezillon/mesa/-/commit/ec647a237d09925068498d5462ac62f12ec2e4a5

15:16 <bbrezillon> alyssa, daniels: ^

15:16 <bbrezillon> it seems to pass CI, which is weird because I remember trying the same trick when adding AFBC support to Bifrost

15:16 <bbrezillon> and it was failing

15:18 <daniels> but CI won't ever be testing shared or scanout surfaces, no?

15:23 <bbrezillon> nope, but even internal usage was failing with this swizzle trick

15:25 <bbrezillon> and what's for sure is that we are applying the pipe_format swizzle on Midgard when emitting the render-target descriptor

15:26 <bbrezillon> and I guess alyssa tested it on T860 when toggling AFBC-sharing on by default

15:29 <bbrezillon> which means, the swizzling is either ignored or applied, but the behavior is consistent (the display controller and the GPU do the same thing)

15:51 <bbrezillon> daniels, robclark: looks like component order is ignored here => https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/meson/meson_osd_afbcd.c#L200

15:56 <chewitt> @narmstrong ^

15:57 <daniels> well, that's just for programming the afbc decoder, right? presumably the decoder doesn't care about the R/B channel order (modulo YTR), so it just emits them straight through, then the display controller swizzles if required?

15:57 <narmstrong> bbrezillon: it is not `/* YTR is forbidden for non XBGR formats */`

15:58 <narmstrong> bbrezillon: it's unclear, the decoder emits whatever channels it founds and it's the pixel encoder who can re-order them

15:58 <narmstrong> bbrezillon: the decoder doesn't know what are R, G ou B channels

15:59 <narmstrong> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/meson/meson_viu.c#L341

15:59 <bbrezillon> ok

16:15 <alyssa> YTR stuff only makes this more "fun"

16:34 <bbrezillon> ok, so I'd need to add support for split-mode or 32x8 mode to test AFBC on Amlogic :'-(

16:57 <macc24> bbrezillon: is panvk supposed to display vkcube on g72?

17:24 <bbrezillon> macc24: I didn't test on g72

17:27 <macc24> bbrezillon: let me know when complaining about something being broken is useful :p

17:34 <bbrezillon> macc24: sure

17:56 <archetech> macc24: when you're unaware of it ?

17:57 <macc24> archetech: what?

18:00 <bbrezillon> alyssa, daniels: I confirm https://gitlab.freedesktop.org/bbrezillon/mesa/-/commit/ec647a237d09925068498d5462ac62f12ec2e4a5 does the right thing on Bifrost

18:01 <bbrezillon> and now I have a patch to enable support AFBC_SPLIT :)

18:01 <bbrezillon> s/enable//

18:55 <alyssa> Huzzah!

18:55 <alyssa> bbrezillon: That patch breaks border colours.

18:56 <alyssa> Also, can an RTD have AFBC and a nonidentity swizzle? (in the MFBD)

18:56 <alyssa> (on v7)

18:56 <alyssa> IIRC those were the reasons we have the fixup soln to begin with

22:14 <daniels> bbrezillon: can you elaborate on 'right thing' please? :)