07:29tomeu: amazing, somebody has already started REing of the rockchip NPU, and got pretty far already!
07:29tomeu: https://blog.tomeuvizoso.net/2024/01/etnaviv-npu-update-15-we-are-upstream.html?showComment=1707596385130#c657337005734939189
07:34tomeu: !whois tomeu
07:34tomeu: grr
07:47tomeu: afaics, OFTC's ChanServ doesn't have the TOPIC command, and the matrix bridge will eat the /topic commands
08:41f_[xmpp]: tomeu: the bridge can't even bridge bans
08:50f_[xmpp]: a ban on matrix only results in a kick on IRC, it's annyoing
08:51f_[xmpp]: annoying
08:51tomeu: yeah, I don't see how one can be an op via the bridge
08:53f_[xmpp]: I learned this the hard way in #postmarketos
09:21pH5: I think I have understood enough of the v8 bitstream format to start writing an encoder.
09:22tomeu: wow!
09:22pH5: non-zrle at first, I still need to figure out how run length is picked from the table in the header
09:22tomeu: really looking towards the first convolution :)
09:22tomeu: cool, you know how to disable zrle in the blob, right?
09:28pH5: tomeu: could you remind me how? I've just used 5x5 weight buffers without zeros, that disabled it.
10:57tomeu: sorry, was afk
10:58tomeu: pH5: on my setup, this works: NN_EXT_ZERO_RUN_LEN
10:58tomeu: so export NN_EXT_ZERO_RUN_LEN=0
10:59tomeu: if you intercept getenv in a LD_PRELOAD shim, you may find some other interesting env vars
10:59f_: tomeu-test: is that you?
10:59tomeu: yep, from oftc's web irc
11:00f_: I told you to consider using IRC without the matrix bridge before lol
11:00f_: this...(and other reasons) is why :P
11:01f_: and yeah I didn't see you on libera anymore since the libera<->matrix bridge got permanently shut down
11:02tomeu: I would ask in #freedreno for a hosted instance of thelounge, but I think they have already too much in their plates
11:04f_: chat.sr.ht?
11:05f_: tomeu: oh yeah, if you have XMPP you can use biboumi
11:07tomeu: hmm, will give sourcehut a look
11:08f_: tomeu: For the most part it's literally just a soju + gamja instance
11:09f_: soju is such a fantastic bouncer TBH
11:09pH5: tomeu: thank you, this env var is evaluated (among many others), but seems to be ignored
11:09pH5: tomeu: could gcFEATURE_BIT_NN_COMPRESSION_BYPASSS being 0 be related to this?
11:09tomeu: hmm, so I think that one thing is weight compression, and the other is zero bypass
11:10tomeu: maybe your blob has other env vars specific to HUFFMAN compression?
11:12pH5: tomeu: VIV_VX_ENABLE_HUFFMAN, but setting that to zero doesn't seem to make a difference either
11:12tomeu: hmm, that's a pity
11:13tomeu: it was really handy to force no compression and leave compression for later
11:14tomeu: I don't know much about huffman compression, but I wonder why zero-specific compression would be used with it
11:26pH5: the huffman compression is using a fixed code book of 8 (2-5 bit long) codes that encode the length of a following variable length value.
11:27pH5: they are always stored as either 3 or (3+2) bits in the bitstream (and for 2-bit and 4-bit huffman codes the remaining bit is already used for the sign)
11:27pH5: so at minimum there's a fixed 3-bit value per zero. at some amount of zeros storing run lengths still starts making sense.
11:35tomeu: oh, you mean zeroes as in actual zeros?
11:36tomeu: zrl in at least v7 is about compressing the unquantized zero, so the zero point
11:46pH5: I think it's the same on v8. It's just that the quantized value 0x00 is the shortest that can be expressed (among with 0x01 and 0xff).
11:47pH5: If it takes more bits to encode a zero-point coefficient, zrle just becomes important earlier.
11:53tomeu: ok, I see
11:54tomeu: it's really a pity one cannot simplify this and attack it in phases
11:54tomeu: having to go with the full-compressed mode right away
11:54tomeu: it is something that must be implemented anyway, but it can help to soften a bit the learning curve
12:07f_[mtrx]2: Meh, tomeu try msg'ing chanserv to get +o
12:08f_[mtrx]2: then send a raw TOPIC command: /msg @oftc-irc:matrix.org !raw TOPIC #ml-mainline :Doing accelerated machine learning with the mainline kernel. Archived at https://people.freedesktop.org/~cbrill/dri-log/
12:09f_[mtrx]2: tomeu: Does that work?
12:32tomeu: if you meant !cmd, I tried that already this morning
12:33tomeu: doesn't seem to work :/
12:34tomeu: maybe easiest would be to give you +o :)
14:08f_[xmpp]: oh :/
14:09f_[xmpp]: I guess sure feel free (+o f_, not f_[xmpp])
14:29tomeu: /msg ChanServ OP #ml-mainline tomeu
14:30tomeu: ahem
14:30tomeu: \o/
14:55f_[xmpp]: there
14:58f_[xmpp]: >ChanServ (services@services.oftc.net): 2: f_ CHANOP
14:58f_[xmpp]: oh my
14:59f_[xmpp]: tomeu: thanks lol
14:59tomeu: thanks for volunteering! ;)
14:59f_[xmpp]: Np
15:00f_[xmpp]: Just need to have access to my computer lol (I should properly authenticate this connection.....)
16:00f_: ok it works tomeu
16:02tomeu: nice!
16:05f_: tomeu: shall AUTOOPS be enabled?
16:12f_: tomeu: Let me show you something. Connect an IRC client in here
16:21f_: yeah anyway....
17:03tomeu: f_: sorry, was playing mineclone with the kids
17:04tomeu: I can now, though I need to go cook dinner :)
17:04f_: lol, hope you had fun :D
17:04tomeu: we found a great mine :)
17:05f_: tomeu: connect an IRC client in here
17:05annoying_ml-mainline_spammer: It's me BTW.
17:06f_: Now watch:
17:06f_: ^ ban on matrix results in just a kick on IRC
17:06f_: and:
17:07annoying_ml-mainline_spammer: I can still rejoin and chat again, messages just won't be visible on Matrix...
17:07f_: <annoying_ml-mainline_spammer> I can still rejoin and chat again, messages just won't be visible on Matrix...
17:07tomeu2: oh, itneresting
17:08tomeu: ok, let's see how things go from now on
17:08f_: I would've expected the bridge to `/mode +b annoying_ml-mainline_spammer*!*@*` but so far...not implemented
17:08f_: Anyway..
17:08tomeu: yeah
17:08f_: now go away f_[mtrx]1
17:09f_: hope it gets fixed ASAP, except it was like this since the bridge got created so..hopes are very low
17:11f_: Now let's actually talk about ML on mainline :)