08:52 <q4a> Cool. kusma already has patches for S3TC emulation: https://gitlab.freedesktop.org/kusma/mesa/-/tree/st-tc-emulation

13:31 <alyssa> > I don’t know if doing writes out from compute is going to be better or worse than the frag store unit, but could be worth a shot

13:31 <alyssa> This is a huge footgun with Mali

13:31 <alyssa> imageStore() does not support AFBC, fragment writeout does.

13:32 <alyssa> which means (for GL at least), binding a texture as a shader image triggers a decompression

13:32 <alyssa> and then (with panfrost anyway, dunno if the DDK has a magic 8-ball heuristic for this) it's decompressed for the rest of its lifetime

13:32 <alyssa> which means slow

13:33 <alyssa> by contrast, fragment writeout (even with MRT) gets you AFBC -- provided the combination of hardware/format supports

13:34 <alyssa> For this reason alone, compute image processing tends to suck on Mali, whereas on other hw it can be a massive win (for the reasons daniels said)

13:34 <alyssa> I expect (well, hope) some future Mali will eventually fix this .. but for now the advice holds.

13:51 <robmur01> for reference, Arm agrees - https://developer.arm.com/documentation/101897/0300/Compute-shading/Image-processing

14:00 <daniels> alyssa: the NV12 texture in is not AFBC

14:09 <alyssa> daniels: aha, I missed that detail

14:10 <alyssa> in that case compute kernels might win out

14:41 <bbrezillon> robmur01: Hi! I'm trying to resurrect robher patch adding support for aarch64 MMU format, and I'm wondering if you have any idea how to expose the AS_MEMATTR_AARCH64_SHARED attribute (needed for memory shared between the MCU running the firmware and the CPU)

14:44 <bbrezillon> BTW, I noticed that robher_'s patch (https://lore.kernel.org/all/CAAObsKADkCLUDSJ9aAxQ_WAotFYTuUuVhifKA5Y+dWjOfmmP4w@mail.gmail.com/T/#m3f8fb847b6699ade6c61a4fa4d87fba9e46b734c) wasn't adding mali specific MEMATTR definitions (ARM_MALI_LPAE_MAIR_ATTR_{IMP_DEF,WA,NC}) to replace the ARM_LPAE_MAIR_ATTR_ ones

14:46 <robmur01> bbrezillon: I'll have to refresh myself on Mali memory attributes next week when I'm hopefully less elbow-deep in CPU pagetable code...

14:48 <bbrezillon> robmur01: no hurries, it can wait a few more days ;-)

14:51 <robmur01> off the top of my head, I *thought* the only thing we were technically missing was the special internal-shareable encoding, but since we still haven't got round to trying to optimise GPU-private mappings that shouldn't matter

14:58 <bbrezillon> hm, AFAICT the AS_MEMATTR_AARCH64_xxx values don't match the ones used on aarch64

14:59 <greenjustin> daniels: I was thinking about this a little, and what if instead of using a compute shader, we keep using a fragment shader but we tell GL that all the planes are ARGB. Would that let us get 4 bytes/~2.7 pixels per invocation?

15:03 <robmur01> ah, right, because MEMATTR != MAIR, so we'd either have a special-case "Mali AArch64" format (which might seem to rather defeat the point), or panfrost does its own MAIR->MEMATTR translation

15:04 <daniels> greenjustin: I don't know the tradeoffs well enough to say, but it could be worth a shot

15:19 <bbrezillon> robmur01: yep, doing the MAIR -> MEMATTR conversion in panfrost would do the trick

15:30 <cphealy> Regarding textures and AFBC, when a non-compressed texture is loaded to GPU memory, does the texture get compressed to AFBC format? And, if so, is there a way that this texture in memory can be packed instead of taking the full storage space of a raw RGBA texture?

15:32 <cphealy> As an example, if I have a 1024x1024 RGBA texture that I want to load. Normally it would take 4MB of texture RAM. Is there a method using the compression/decompression capabilities of the GPU to have it take less than 4MB?

15:53 <alyssa> use astcenc at build time...

16:14 <cphealy> You mean at the build time of the textures?

16:16 <cphealy> If so, this wouldn't work with web content as I have no control over that.

16:19 <alyssa> Right, ok.

16:20 <alyssa> For any content you do have control over, anyway

16:21 <cphealy> So there's no way for the GPU to a conversion from uncompressed to ASTC in HW, correct?

16:22 <cphealy> Does the GPU convert uncompressed textures to AFBC when the format is supported to save DRAM bandwidth?

16:23 <alyssa> yes

16:24 <alyssa> in theory there's a non-sparse version of AFBC, but Mali hasn't been able to render to it since Midgard

16:24 <cphealy> What is "non-sparse"?

16:24 <cphealy> packed?

16:24 <alyssa> yeah

16:25 <alyssa> AFBC really is about DRAM bandwidth, not memory usage

16:25 <alyssa> (ASTC/ETC are about both)

16:25 <cphealy> ack

16:25 <cphealy> the tradeoff with ASTC/ETC is that it's lossy (to varying degrees)

16:25 <alyssa> Mmhmm

16:25 <cphealy> Well, that and the GPU cannot do on-the-fly conversion, right?

16:25 <alyssa> Yeah

16:25 <alyssa> Encoding ASTC/ETC is expensive

16:26 <cphealy> regarding non-sparse version of AFBC and Mali hasn't been able to render to it since Midgard, is this a HW thing or a SW thing (or both)?

16:26 <cphealy> Like an intentional change with Bifrost or a breakage?

16:29 <mop___> hi. I have a SBC with a mali G31 and a screen with a resolution of 1920x1200. unfortunately parts of the display get cut off and when I enforce a resolution of 1920x1080 I get ugly artifacts (linux fbdev is fine). I read somewhere that non standard resolution are currently somewhat broken. does it make sense to build my own kernel with the latest changes (i.e. will that make non standard resolutions work) or is

16:29 <mop___> this still known to be broken

16:32 <alyssa> mali is render-only, this would be related to your display hardware instead which will depend on your SoC, not the Mali

16:32 <alyssa> ask in #linux-rockchip or #linux-sunxi or #linux-amlogic or wherever as appropriate

16:33 <mop___> alyssa, thank you! sorry for wrong channel

16:34 <alyssa> np

16:39 <greenjustin> alyssa: Wait does that imply AFBC textures take the same amount of space they normally would, they're just encoded in a way that reduces entropy? If so...how does that help with DRAM bandwidth?

16:41 <alyssa> greenjustin: They take more space, actually

16:42 <alyssa> but they're sparse

16:42 <alyssa> with a dense header

16:42 <alyssa> so most of the body isn't actually accessed

16:43 <alyssa> (that's still hard on the caches but I digress)

16:49 <greenjustin> I see, so the sampler or something just ignores all the zero padding?

17:17 <cphealy> alyssa: with Midgard are there examples of non-spare use of AFBC? If so, is it with AFBC textures?