12:39 <alyssa> bbrezillon: I think !8774 is probably ready to go

12:40 <alyssa> Sample variable stuff is ES3.2 (or an extension), whoops.

12:42 <bbrezillon> alyssa: I don't feel like reviewing another 30+ patch series right now, but if you think it's good to go, feel free to merge it

12:43 <alyssa> bbrezillon: Valid. So.... acked-by? 😇

12:43 <bbrezillon> sure

12:45 <alyssa> thanks o:)

12:45 <alyssa> will kick it at CI again

12:49 <amonakov> a question about the infamous Mali datasheet https://developer.arm.com/-/media/Arm%20Developer%20Community/PDF/Mali%20GPU%20datasheet/Arm%20Mali%20GPU%20Datasheet%202020.pdf

12:49 <amonakov> when it says 2 fragments/pixels/texels per clock per core, what is that supposed to mean exactly?

12:49 <amonakov> that L1 cache in a core serves 8 bytes per clock? or 32 bytes per clock?

12:49 <alyssa> if you figure it out tell me :|

12:53 <bbrezillon> alyssa: on a side note, I'd appreciate if we could merge !8963 (or something similar) to simplify the rebase of the panvk branch: everytime we change something on the compiler side that impacts the renderer state or blend desc emission, I have to make sure to report those changes on the panvk side...

12:53 <alyssa> bbrezillon: ack

12:54 <alyssa> let me look at 8963

13:21 <alyssa> tomeu: PAN_MESA_DEBUG=sync just saved the day for me... belated thank you!

13:21 <tomeu> happy to hear that!

13:23 <macc24> alyssa: ya need a test for 8774?

13:29 <alyssa> macc24: sure, it's lknown buggy on midgard though (todo for today)

14:11 <macc24> alyssa: how do i test this

15:38 <macc24> bbrezillon: remember that random mpv issues on g72?

15:45 <bbrezillon> macc24: nope :)

15:46 <bbrezillon> but I'm expecting a good news :)

15:46 <macc24> okay, it was a long time ago and you couldn't "fix" it

15:46 <macc24> my brain has came up with a reason why that apitrace was exiting after one/couple of frame

20:23 <icecream95> alyssa: Any ideas why this causes INSTR_INVALID_ENC faults when nosched isn't used? https://gitlab.freedesktop.org/-/snippets/1587

20:32 <amonakov> in GCC we use "debug counters" to investigate this sort of issues:

20:32 <amonakov> increment a counter each time a scheduler selects an instruction, and once it reaches N, restrict scheduling (no reordering)

20:32 <amonakov> then bisect by N and find which transformation creates failing code

20:45 <alyssa> icecream95: Nothing jumps out as broken..

20:46 <alyssa> Try runnign with PAN_DBG=trace and checking the fault pointer

20:47 <alyssa> (n.b.: the fault pointer is shifted by 4 for bifrost shaders, this contains no loss of generality since everything is quadword aligned.)

20:51 <icecream95> alyssa: The fault pointer is 0x100000300318, which means clause_24 in the disassembly?

20:52 <alyssa> icecream95: the posted disassembly doesn't have nosched set...

20:52 <alyssa> but yeah, that'd be clause_24 (assuming the shader is at 0x1000003003000)

20:52 <icecream95> The fault was without nosched

20:53 <alyssa> oh wait I misread

20:53 <alyssa> uh

20:54 <alyssa> it looks right wth

20:58 <alyssa> icecream95: amonakov's suggestion might bear fruit

20:58 <alyssa> I note clause_24 has 8 tuples, which is the max. Maybe we're failing a size constriant of some kind

21:04 <alyssa> I don't see anything off.

21:05 <icecream95> It seems to be the MKVEC.v2i16 / V2U8_TO_V2U16 instructions causing the fault

21:06 <icecream95> amonakov: Thanks for the suggestion :)

21:12 <alyssa> I see nothing architecturally wrong with those instructions...