00:00 <Ntemis> i see

00:00 <HdkR> If a bug is found in mesa then most always a piglit test is created around it

00:01 <Ntemis> ppsspp can bring soem color in and make the debugging more joyful but ok

00:01 <HdkR> chrisf: Which bit of ASTC is gross for you? I'm personally grossed out by how large the hardware texture decoders need to be

00:01 <chrisf> HdkR: that, really

00:01 <chrisf> "you can see this thing from space"

00:01 <HdkR> :D

00:02 <Ntemis> anw you guys are doing us a big favor working on this driver and i want to thank you for that

00:02 <icecream95> Well, we haven't found the ASTC format codes yet, so you won't have to worry for a while

00:02 <HdkR> Oops, added ASTC and now our texture decoders are 2x the size

00:02 <Ntemis> keep up the amazing work

00:03 <chrisf> HdkR: even etc2 is wacky, but astc is on a whole different level

00:03 <icecream95> Maybe the ASTC block size is encoded in the anisotropic filtering field (which hasn't been found yet...)?

00:04 <icecream95> If I remember correctly ETC2 has a decoder size only about 25% more than S3TC.

00:04 <chrisf> icecream95: i could believe etc1 being marginally larger than s3tc, but etc2 adds a bunch of crazy special case encodings

00:05 <icecream95> Only about 5 or 6 more modes...

00:07 <HdkR> If only it was possible to deprecate compressed textures sanely without breaking apps

00:08 <chrisf> i dont want them gone, just sensible

00:09 <HdkR> Well that would be nice too

00:10 <icecream95> It could have been worse: http://www.jacobstrom.com/publications/lightMapComp.pdf

00:10 <HdkR> But we already have insane formats, so we've lost that

00:10 <chrisf> cant afford not compressing

00:12 <HdkR> Definitely, don't want to lose the compression

00:12 <HdkR> Especially when you don't have 2.3TB/s memory bandwidth

00:16 <HdkR> (Which I think is somewhere in the limit of 4/6-site HBM2e/HBM3)

00:30 <icecream95> For some reason, enabling ETC2_RGB8 breaks software decompression for ETC2_R11_*

00:30 <icecream95> (I haven't got the R11 ETC formats working properly, but all the other ones including RG11 are fine)

00:31 <icecream95> So it looks like somewhere the R11 I pass in is getting "converted" to RGB8...

00:34 <icecream95> The decision of whether to software-decode ETC2 is based on whether ETC2_RGB8 is supported during init

00:34 <icecream95> Maybe I could just try and fix the R11 formats...

01:16 <icecream95> ...and it turns out I was returning RG11 formats for PIPE_FORMAT_ETC2_R11_*. Whoops!

01:53 <icecream95> ETC support is done, time to make an MR for negative LOD bias support...

01:53 <icecream95> alyssa: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3325

01:58 <alyssa> icecream95: Awesome stuff, thank you for that! will review tomorrow!

02:00 <anarsoul> PIPE_FORMAT_ETC1_RGB8 and PIPE_FORMAT_ETC2_RGB8 use the same internal format?

02:01 <anarsoul> that's weird :)

02:01 <icecream95> They are backwards compatible

02:02 <icecream95> ETC1 can use differential colours (e.g. c1 = 25; c2 = c1-3), and negative values actiave ETC2 modes.

02:04 <anarsoul> I see, thanks for explanation

02:04 <anarsoul> are there any tests in deqp for ETC?

02:25 <chrisf> indeed there are

02:28 <chrisf> on the GLES side there are a few weak corners though

02:38 <icecream95> alyssa: I created a MR for negative lod bias: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3326

02:38 <icecream95> Now what?...

05:24 <icecream95> For formats like GL_RGBA32I that don't seem to work on t760, I wonder if there's some secret hidden flag for enabling them.

05:25 <icecream95> I tried looking at the unknown values in mali_texture_format, and didn't find much more than a kernel panic.

05:28 <icecream95> The 32F formats seem to work, so maybe the blob driver emulates 32-bit per channel integer formats in the shader.

06:08 <icecream95> Let's see if I can get tiling for comrpessed textures working...

07:37 <icecream95> Getting tiling working is as simple as dividing bytes_per_pixel by 4 instead of 2.

07:40 <icecream95> Would there be any problem if ETC textures were always tiled?

07:42 <HdkR> glCopyImageSubData might end up being interesting

07:45 <anarsoul> I guess you can't map it directly

07:45 <anarsoul> and you'll have to do tiling/untiling manually

07:52 <icecream95> I guess I'll just have to un-adjust the stride if it turns out the texture won't be tiled....

08:02 <icecream95> Although that causes all the tiles to show up, they aren't necessarily in the right order, and non-square textures cause a segfault...

08:05 <bbrezillon> robher: do you plan to send a v3 for "drm/panfrost: Add the panfrost_gem_mapping concept" ?

08:07 <icecream95> And now I have a segfault that only shows up when I'm not using gdb...

13:34 <alyssa> icecream95: I mean, do you expect GL_RGBA32I to mipmap nicely?

13:34 <alyssa> I'd have to check the spec, but..

13:36 <alyssa> Can't find much

13:39 <alyssa> Okay, here

13:39 <alyssa> 3.8.11 Texture Completeness (GL 3.1 spec)

13:39 <alyssa> "If the internal format of the arrays is integer... TEXTURE_MAG_FILTER must be NEAREST and TEXTURE_MIN_FILTER must be NEAREST or NEAREST_MIPMAP_NEAREST"

13:40 <alyssa> So mipmapping would let you select from different images and the integer part of the lod bias would help index, but it wouldn't interpolate like the float/norm would

15:33 <mearon> alyssa: re freezes on kevin: IIRC I have experienced freezes only when running sway so far. Today I was able to unfreeze my kevin two times by pressing the lock key (top-right); I have mapped it in my sway config to `exec killall -SIGUSR1 swayidle`, which locks the screen. After pressing it, I was able to unlock my screen normally, just like if no freeze happened.

15:34 <alyssa> mearon: hm, that'd be a different issue from what I was seeing, which would happen even with no graphics (X or Wayland), just a tty prompt

15:34 <alyssa> but has not happened even once since returning to Canada

15:34 <alyssa> So I'm assuming Kevin was just unhappy with crossing the border? :P

15:34 <mearon> maybe your kevin was just missing home

15:34 <mearon> ya :P

15:35 <alyssa> Funny thing is, I got Kevin in the US originally... :p

15:36 <alyssa> Honestly, this doesn't negate the theory that it was some bad interaction with wifi

15:36 <alyssa> Or maybe it was just supremely unhappy about the clock being off by 3 hours

15:36 <alyssa> Kevin was jetlagged? :P

21:52 <icecream95> Here is an example of the incorrect ordering when tiling ETC: https://gitlab.com/snippets/1928572

21:55 <anarsoul> do you actually do tiling and untiling in transfer_map/transfer_unmap callbacks?

21:55 <anarsoul> you may need to teach tiling/untiling routines how to deal with ETC

22:04 <icecream95> It looks like the problem is that tiling really is done based on pixels, not blocks, so we should be doing 4x4 tiling instead of 16x16...

22:10 <icecream95> I have tiling working now. The only problem is that it breaks tiling for everything else...

22:12 <anarsoul> yeah, so you have to fix it :)

22:13 <anarsoul> or implement separate routine for ETC tiling/untiling

22:14 <icecream95> I think that would be the easiest option.

22:44 <icecream95> I've pushed a commit getting tiling for ETC working: https://gitlab.freedesktop.org/mesa/mesa/commit/9ab0e0baeae2527b4333d1b3314fc39c3e680198

22:46 <anarsoul> you also need to benchmark original implementation and yours

23:03 <icecream95> The stack usage for panfrost_store_tiled_image went up from 24 bytes to 40 bytes, which isn't great...

23:04 <icecream95> Can someone explain this? movne r10, #3

23:04 <icecream95> moveq r10, #15

23:04 <icecream95> mvnne r3, #3

23:04 <icecream95> mvneq r3, #15

23:04 <icecream95> GCC is doing the same two instructions twice in a row, but on different target registers...

23:05 <Stary> mvn loads the complement

23:05 <icecream95> Whoops... Didn't see that.

23:44 <icecream95> Looks like the deqp failures are because the height and width haven't been divided by 4...