00:14 <alyssa> For as silly as this patch set has been, at least there are only 4 register modes :p

01:36 <alyssa> HdkR: So, I'm totally rethinking how we want to handle half-regs

01:36 <alyssa> I think it might actually be better to have 8-channel masks

01:36 <alyssa> hr0.xyz = hr0.xyz

01:36 <alyssa> Er

01:36 <alyssa> hr0.xyz => hr0.xyz

01:36 <alyssa> hr1.xyz => hr0.rgb

01:36 <alyssa> hr2.xyz => hr1.xyz

01:36 <alyssa> hr3.xyz => hr1.rgb

01:37 <alyssa> Benefits:

01:37 <alyssa> - It's immediately obvious what you're subdividing. "hr27" is actually just the upper part of r13

01:38 <alyssa> - It's how masks actually work in the hardware. We have 8-bits for masks. Theoretically, the hardware can do 16-bit vec8 compute.

01:38 <alyssa> And at some point, maybe even get rid of the r's

01:39 <alyssa> (Like, make r the prefix for 32-bit. h for 16-bit. q for 8-bit. d for 64-bit.)

01:39 <robclark> fwiw, since half-reg aliasing of full reg wasn't introduced until a6xx on adreno side, I just added something so disasm w/ --verbose arg prints regs like hr1.x (r0.y) so I can more easily see what the half-reg aliases..

01:39 <alyssa> Point is, r3 = h3 = q3 = d3, so there's no wackiness there

01:40 <robclark> (ofc rN.c notation is kinda silly since in my case a vec4 can live in r1.w-r2.z)

01:40 <alyssa> robclark: Sadly half-reg is embedded deep into Midgard, so getting it right notationally is worth it if I ever want to support beyond 32-bit

01:41 <robclark> my point is just add it as a --verbose disasm arg to show both the half reg location and the conflicing full reg location

01:43 <alyssa> robclark: Seems a little clunky... If half-regs were a novel feature, then sure, but when they're _everywhere_, I want it to be clean

01:46 <robclark> meh.. do what is useful in the end..

01:46 <robclark> in my case it was kinda bolted on after the fact, but it has proved useful

01:46 <alyssa> Mm

03:43 <alyssa> There, 13 patches (across two series) sent to the list. Alyssa out.

03:52 <HdkR> harvesting the mindshare

04:12 <anarsoul> alyssa: why not gitlab MR?

06:46 <tomeu> bbrezillon: regarding panfrost_device_fini, I think that was on purpose at some iteration, but it's a bug now

06:46 <tomeu> AFAICS :)

06:46 <tomeu> bbrezillon: what do you think?

07:10 <bbrezillon> tomeu: I also think it's a bug (I fixed it in my tree when working on the perfcnt stuff), but wanted to make sure I didn't miss something important

07:11 <tomeu> at some point during development, most fini functions were empty because code was moved from the init functions to power_on ones

08:08 <tomeu> alyssa: the instruction that is causing problems during live analysis due to dest == -1 is m_store_vary_32

08:14 <tomeu> intrinsic store_output (r0, ssa_0) (0, 15, 0) /* base=0 */ /* wrmask=xyzw */ /* component=0 *//* gl_Position */

08:14 <tomeu> st_vary_32 -1, r0, -1

14:26 <alyssa> anarsoul: Gitlab is too slow

14:27 <alyssa> tomeu: Aaaaaaa, gotcha, that makes sense

14:28 <alyssa> Yeah, the way we're representing stores in the IR is a huge hack right now.

14:28 <alyssa> (dest == -1) is probably right, because it _doesn't_ contribute to liveness of anything, though.

14:28 <alyssa> The r0 is wrong -- it should be an r26 (or r27 vs r1) and the fixup should happen at emit time, I think.

22:46 <alyssa> Reading is wonderful :)

22:58 <anarsoul> reading what?

22:58 <alyssa> Books!

23:47 <alyssa> ((31*B) << 25) | ((63*G) << 14) | ((31*R) << 5)

23:47 <alyssa> To encode an RGB565 color

23:47 <alyssa> Anyone recognize that encoding

23:48 <alyssa> The multiplies are as you would expect [31 = (2^5 - 1) ; 63 = (2^6 - 1)], but the shifts are a lot larger than they need to be

23:48 <alyssa> If you shift everything >> 5:

23:48 <alyssa> ((31*B) << 20) | ((63*G) << 9) | (31*R)

23:48 <alyssa> We still see jumps of 9- and 11-bits, rather than the expected 5- and 6-bits. 2*n-1

23:49 <alyssa> What up?

23:49 <alyssa> HdkR: ^^ You know random GPU trivia, any thoughts? =p

23:49 <HdkR> What is this encoding for? A texture format or something?

23:50 <alyssa> HdkR: Clear color

23:50 <HdkR> Programming of a register's clear colour on API side?

23:50 <alyssa> That's a 32-bit word. For RGBA8888, it's just exactly as you expect. For RGB565 it's all weird and not the expected weird (it still fills all 32-bit, just half are zeroes interspersed)

23:51 <alyssa> HdkR: Yeah, how glClearColor gets sent in the cmdstream

23:52 <HdkR> Looks like it is just decoded the RGB565 values in to RGB?

23:52 <HdkR> er, RGB888

23:53 <alyssa> HdkR: How say?

23:53 <alyssa> *so

23:54 <anarsoul> alyssa: (31*b) << 25 doesn't make a lot of sense, it overflows 32-bit value with b = 31

23:55 <anarsoul> what's the value for white color?

23:56 <alyssa> anarsoul: It doesn't overflow?

23:56 <alyssa> r,g,b are 0.0-1.0 range

23:56 <anarsoul> oh, OK

23:57 <HdkR> Oh, I didn't realize those were floats :P

23:57 <HdkR> I was assuming integer encoding

23:58 <alyssa> Sorry, sloopy

23:59 <HdkR> How does it determine format of this register? Is that encoded elsewhere?