15:10 <macc24> alyssa: is it a good idea to turn off transacation elimination in something like mpv?

15:14 <shadeslayer> alyssa: not really, I want to pick it up again time permitting

15:16 <shadeslayer> cphealy_: I think if we go with the glLabel approach (where we attach labels to BO's through the glLabel extension, and store it in the bo's through the DRM framework), we could probably make that possible

15:20 <cphealy_> shadeslayer: can you point me to this glLabel extension you are referring to? I've not yet found it.

15:22 <alyssa> macc24: Probably.. not?

15:22 <alyssa> If you're watching any sort of 2D animation, TE will be a huge win because the backgrounds are static.

15:22 <alyssa> For live action, meh. Will probably still break even.

15:22 <alyssa> shadeslayer: Ack.

15:22 <shadeslayer> cphealy_: https://docs.gl/gl4/glObjectLabel < ah it's glObjectLabel, it's been a while since I've looked at it

15:23 <macc24> alyssa: "If you're watching any sort of 2D animation" was this your first thought xD

15:27 <alyssa> macc24: Well, yeah.

15:29 <macc24> hmmmmmmmmmmmmmmmmmmmmm

15:36 <cphealy_> shadeslayer: with this approach using glLabel, would apps that use the GL API need to do anything special to work with this or would it all be internal to Mesa?

15:39 <alyssa> shadeslayer: Also in the mean time it may make sense to merge the panfrost parts of labeling without going off to the kernel

15:39 <alyssa> just for driver debug purposes (so we can diagnose page faults etc)

15:41 <shadeslayer> cphealy_: because glObjectLabel can be used by userspace too, we can cut it a few different ways imo, applications label their objects and we use those labels, since this involves extra work on the application side of things, we can add our own labels when mesa is built in debug mode to enable reporting of memory usage for textures using the mesa

15:41 <shadeslayer> gl* entry points

15:42 <shadeslayer> alyssa: -ETIME :(

15:42 <shadeslayer> alyssa: how would that work though?

15:44 <shadeslayer> alyssa: simply store them in userpsace?

15:45 <alyssa> shadeslayer: yeah, keeping everything in-process

15:46 <shadeslayer> alyssa: hm, note that we'd lose labels on BO import/export

15:46 <alyssa> so all the internal allocations get labeled appropriately, and external stuff just gets labeled "Im/exported buffer (scanout/shared/whatever)"

15:46 <alyssa> that's fine

15:46 <shadeslayer> right

15:47 <alyssa> (I mean, preserving across processes is better of course, but no need to hold up the rest in the mean time.)

15:47 <alyssa> (It's also cheaper, for something we will never import/export, to label only internally)

15:47 <shadeslayer> someone find me more than 24 hours in a day please :P

15:47 <shadeslayer> alyssa: but sure, I'll see if I can pick it up again this month :)

16:39 <amonakov> do many people understand bifrost/ISA.xml? why do the first few branch instrucitons have the same 'mask' and 'exact' attributes? I think it confuses the disassembler?

16:45 <alyssa> amonakov: Many? no, but I pretend to

16:45 <alyssa> and yeah, BRANCH encoding is horribly complex and evidently broken right now

16:46 <alyssa> they have the same mask/exact fields because... that's literally how the instructions are specced >_<

16:46 <alyssa> reading between the lines a bit, maybe the real answer is that all of those are really one +BRANCH instruction with even more horribly complex encoding

17:07 <cphealy_> shadeslayer: got it, thank you.

17:11 <amonakov> alyssa: ... so panfrost currently never emits branch.f32 (nor any other kind apart from branch.i32)?

17:16 <robmur01> alyssa: right, presumably there only needs to be one "branch" opcode and the actual data type is encoded in all the other crap

17:18 <amonakov> how authoritative is ISA.xml? apart from this goof, I noticed other issues, like missing important instructions (multiply-high)

17:18 <robmur01> ISTR someone once had an A64 assembler syntax that went "add.{w|x} r0..." vs. "add {w|x}0...", seems the same kinda deal

17:30 <alyssa> amonakov: panfrost does not emit any BRANCH.* yet, instead always using BRANCHZ.i32 (compare to zero and branch), with an explicit fcmp

17:31 <alyssa> ISA.xml isn't authoritative but aside from this goof should be complete for v7 (any G31/G51/G52/G76)

17:31 <alyssa> multiply-high is a `IMULD/IMOV_FMA` pair

17:32 <alyssa> (Doesn't exist on v6 = G71/G72, which have some weird 64-bit stuff we don't handle and that doesn't exist on v6)

17:32 <alyssa> s/v6)/v7)/

17:34 <alyssa> set malisc to output for G76 and it'll go away

17:38 <amonakov> alyssa: I have malisc 6.4 which doesn't support G76 (only up to G72), and malioc which does, but doesn't save compiled binary to a file

18:01 <amonakov> (it supports G51, but it doesn't help, the shader with multiply-high still fails to disasm properly)

18:56 <alyssa> maybe G51 is v6? 🤷

18:57 <alyssa> 64-bit clause support is highly nontrivial..