05:55 marysaka[d]: gfxstrand[d]: Amazing I will have to check this when I’m back 😄
08:48 pac85[d]: airlied[d]: Mmm yeah makes sense, I guess we'll see what amd is doing with buffers when the new hw comes out
08:58 ahuillet[d]: you'd like to compress vertex buffers?
08:59 ahuillet[d]: I wouldn't assert that they're not compressible, but they definitely wouldn't lend themselves well to color or depth compression algorithms
09:45 HdkR: The short distance compression that RT BVHs do is pretty interesting but would probably be hard to apply to generic vertex buffers
09:46 pac85[d]: ahuillet[d]: It's not really about the value of compressing buffers. This just stems from a discussion in a different server. The point was that if you have transparent compression that only works for images then it's not truly transparent. If the compression works for both regardless and just happens to be optimal for images then it is truly transparent. The idea is that perhaps this would allow
09:46 pac85[d]: to enable compression for images even when the api usage pattern makes it non obvious whether a bit of memory is being used for images or for buffers (eg. By aliasing a buffer and an image and then making sure to only use one at once)
09:46 mohamexiety[d]: yeah ultimately what sparked all this was gfx12 enablement patches showing that AMD will have DCC on by default on buffers and images
09:47 mohamexiety[d]: and the buffer part is what's interesting/weird in the sense of how do you compress that, what would you gain, etc
09:48 HdkR: Should be fairly trivial to attempt that today, spin up a compute job that consumes an uncompressed vertex buffer, imageStore the entire thing to a 1DImage or something, then do a render task where the vertex shader does an image fetch with vertex ID? :D
09:48 pac85[d]: Yeah the point is. If dcc on everything gives no benefits, but also no drawbacks, it makes things somewhat easier as now the driver doesn't have to treat compresses images in any special way
09:51 dadschoorse[d]: HdkR: dcc is mostly about write bandwidth, not read performance as far as I understand
09:51 dadschoorse[d]: at least before gfx12, it won't be enabled for images that can't be used as render targets
09:52 dadschoorse[d]: although it might also make sense for storage images, but iirc the results are a bit mixed there
09:53 HdkR: It's a fairly new feature for NVIDIA as well, Around Turing or Ampere where you get compression on imageStore
09:55 dwfreed: karolherbst[d]: the default limit for connections that applies here is 50, so you've got some margin before you hit that, but also the link f_ gave details how to get that raised (just email us); for moderation issues, you could set +R and then +I your bridge subnet (+I bypasses +R requirements)
09:55 karolherbst: dwfreed: ahh thanks. Yeah, I was thinking about reaching out sooner or later anyway, at this point I'm mostly just testing how well it works in practise (the bridge I mean)
09:55 HdkR: But then you'd not getting any benefit from the input assembler since you'll no longer be binding vertex attributes but instead an image so meeh
09:56 dwfreed: karolherbst: so far seems to work great :)
09:56 karolherbst: yeah
09:56 karolherbst: much better than the old one
09:56 f_: afaict
09:56 karolherbst: or rather, it looks better on the IRC side
09:56 f_: On IRC side, yeah
09:56 f_: I guess it's dibridge?
09:56 karolherbst: yeah
09:56 f_: IIRC it can only bridge one channel at a time
09:57 dwfreed: yes
09:57 karolherbst: my server is a VPS and at first it didn't work, because the machines don't annouce the entire IPv6 prefix, but only individual IPs :')
09:57 f_: so if you wanted to bridge more you'd need to run multiple dibridges
09:57 karolherbst: yeah...
09:57 karolherbst: and they'd need to use a different suffix
09:58 karolherbst: and that's even more connections
09:58 f_: <karolherbst[d]_____> yeah...
09:58 karolherbst: dwfreed: one thing I was wondering about was how can I make the channel +R, but allow the bridge puppets to still speak without registration
09:58 dwfreed: yeah, that's the only downside
09:58 karolherbst: or is that the +I +R stuff?
09:58 f_: yes
09:58 dwfreed: +R only prevents joining
09:58 dwfreed: the +I would then bypass that requirement
09:58 karolherbst: ohh, that it was +M
09:59 dwfreed: yeah, the channel was +M before
09:59 dwfreed: and the only bypass to that is voice, unfortunately
09:59 f_: `//mode +RI *!*@2a0a:4cc0:0:1278:*` ?
09:59 karolherbst: and autovoice only works on nicks, not masks
09:59 karolherbst: at least the chanserv one
09:59 dwfreed: correct to all of the above
10:00 f_: Atheme chanserv can voice on masks IIRC
10:00 dwfreed: Yes, but we don't have Atheme at present
10:00 f_: in the future? :P
10:00 dwfreed: karolherbst: should I see if I can talk the dibridge maintainer into making it work with multiple channels?
10:01 dwfreed: I see fdobridge also does #rusticl
10:01 karolherbst: I had the new bridge running on #rusticl for a while before
10:01 dwfreed: and another channel
10:01 karolherbst: but this channel here has way more throughput
10:02 f_: Could be interesting too https://github.com/qaisjp/go-discord-irc
10:02 karolherbst: dwfreed: but anyway, I think the bridge maintainers don't really have time. I even filed an issue so that the puppets report and error or respond on attempts of direct messages (because those aren't relayed), but then told me if I have time to work on it 🙃
10:02 karolherbst: *asked me
10:03 karolherbst: so I think all those neat features would need somebody from us to work on it,
10:04 karolherbst: f_: oh, didn't know about that one
10:04 f_: For one channel the bridge works great though ... (full message at <https://matrix.org/_matrix/media/random>)
10:04 karolherbst: uhhh
10:04 tiredchiku[d]: ?
10:05 karolherbst: f_: you are on matrix right? Because you wrote this: "<f_> For one channel the bridge works great though ... (full message at <https://matrix.org/_matrix/media/random>)"
10:05 f_: karolherbst: I am not on matrix, just wanted to demo that "full message at" annoyance
10:05 karolherbst: ahhh
10:05 karolherbst: :D
10:05 f_: I do have f_[mtrx] laying around but I don't use it
10:05 karolherbst: I don't know what happens with long messages yet
10:06 f_: they get truncated and have "... (full message at" appended
10:07 f_: if the message is longer than 2 lines..
10:07 karolherbst: I've seen that from the matrix one, but I wodner what dibridge would do
10:07 f_: AFAICT dibridge doesn't do it at all
10:07 karolherbst: mhhhh
10:08 dwfreed: go-discord-irc is not going to be usable on oftc
10:08 f_: Matrix folks have said this was to "prevent users from getting kicked by a flood prevention bot"
10:08 karolherbst: sounds like circumventing moderation tools
10:09 dwfreed: yeah, it's annoying at times when it's used for spam, or worse
10:09 f_: by which I responded with `<f_[mtrx]> But now sending "full message at" can also cause a new form of kick, 'stop this is annoying' kick`
10:09 karolherbst: I mean.. IRC clients will split long messages anyway
10:09 dwfreed: the issue is matrix users like to write paragraphs
10:09 karolherbst: so if your matrix bots triggers that stuff, then you probably will also
10:09 karolherbst: ahhh....
10:10 dwfreed: or just paste their logs into the chat
10:10 karolherbst: right...
10:10 f_: dwfreed: that is frowned upon in some matrix channels such as #postmarketos
10:10 karolherbst: discord has a 4000 char limit anyway
10:10 karolherbst: so not much you can post in one go anyway
10:11 karolherbst: 2000 actually
10:11 f_: karolherbst: I guess dibridge bridges messages via webhook on discord?
10:11 karolherbst: yes
10:11 f_: <- not a discord user
10:11 f_: ok so it looks great on both sides :)
10:11 karolherbst: yeah
10:12 tiredchiku[d]: test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test
10:12 tiredchiku[d]: message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message
10:12 tiredchiku[d]: test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test
10:12 tiredchiku[d]: message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message
10:12 tiredchiku[d]: test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message test message
10:12 f_: woah
10:12 f_: good thing there's no FloodServ in here
10:12 karolherbst: yeah, so it simply splits
10:12 Sid127: so that's what happens
10:12 Sid127: :D
10:12 karolherbst: f_: can it be configured per channel?
10:13 f_: yes `/msg ChanServ SET #nouveau FLOODSERV ON`
10:13 dwfreed: FloodServ? yes
10:13 dwfreed: that
10:13 karolherbst: I mean
10:13 karolherbst: configuring the limits
10:13 f_: no idea, sorry
10:13 f_: unless you mean the matrix bridge?
10:13 karolherbst: nah, I meant floodserv
10:14 f_: ah
10:14 dwfreed: No
10:14 dwfreed: but I don't think that message would have actually triggered it
10:14 karolherbst: but spam isn't really an issue so far
10:14 karolherbst: so no point in enabling it really
10:14 f_: yeah
10:15 karolherbst: and doing registered only and excempting the bridge is probably a better tool
10:15 f_: Anyway, that's a really nice bridge you set up
10:15 karolherbst: thanks
10:16 karolherbst: but yeah.. I always disliked the old one, but on the other hand the benefits were kinda worth it... I think... don't know actually :)
10:16 f_: I think it converts discord pings too
10:16 f_: karolherbst[d]: test
10:16 dwfreed: it does, yes
10:16 f_: nice
10:17 karolherbst: there is just one bug with it
10:17 karolherbst: when a discord uses pings somebody not having a puppet yet
10:17 karolherbst: so that won't get translated
10:17 f_: ah, that's fine
10:17 karolherbst: yeah, it's not terrible
10:18 dwfreed: if you know their puppet nick, it will translate
10:18 dwfreed: even if that puppet is not in the channel
10:18 karolherbst: I mean, if a discord user pings another discord user, but isn't puppeted yet
10:18 dwfreed: ah
10:18 f_: karolherbst: I guess the old fdobridge was just matterbridge, right?
10:18 karolherbst: I think so
10:19 f_: in my short time with WeeChat (and without a bouncer, heh) I was having trouble parsing its messages to turn "<fdobridge> <karolherbst> test" into "<#karolherbst> test"
10:20 karolherbst[d]: test
10:20 f_: karolherbst[d]: fail
10:20 karolherbst: mhhh
10:21 karolherbst: that's what I wnated to do
10:21 karolherbst[d]: anyway
10:21 f_: you set +M then unset it?
10:21 dwfreed: ChanServ unset it
10:21 karolherbst: ohh wait
10:21 karolherbst: :D
10:21 karolherbst: ahhh
10:21 f_: ah right senpai doesn't show mode changes sender
10:21 dwfreed: the channel mode lock is now -M
10:22 karolherbst: yeah...
10:22 karolherbst: I'm always confused about doing that via the bot
10:23 f_: /msg ChanServ SET #nouveau MLOCK - I think
10:23 karolherbst: yeah..
10:24 karolherbst: but anyway
10:24 karolherbst: +I won't overwrite the +M, will it?
10:24 f_: no, it won't
10:24 karolherbst: I think it's fine for unregistered nicks to join and listen
10:25 f_: +R tends to be annoying too as OFTC doesn't have SASL yet
10:25 karolherbst: ahh yeah.. I'm using a client cert
10:25 dwfreed: can be sometimes, yeah
10:25 karolherbst: and uhm... there are IRC clients not supporting client certs
10:25 f_: I also use certfp
10:26 f_: But there's a tiny window between "connected" and "identified", and as it turns out my bouncer tends to join channels in that window..
10:26 karolherbst: the worst part is, when you can't change your nick, because you are in a moderated/restricted channel
10:26 karolherbst: and the server just errors
10:26 dwfreed: link your altnick
10:26 karolherbst: yeah
10:27 karolherbst: I did all of that :D
10:27 f_: I've patched soju specifically because of this
10:27 f_: so that it uses "funderscore" as alt nick rather than "f__"
10:27 karolherbst: and with client cert auth I don't run into this issue anymore
10:27 f_: then comes matrix
10:28 karolherbst: but anyway, I kinda need a solution which isn't +R.. I think
10:28 f_: +M and have a bot that auto-voices?
10:29 karolherbst: yeah.. probably that
10:29 dwfreed: I can do the autovoice part for now
10:29 f_: dwfreed: there's a bot/service for that already?
10:29 dwfreed: my trigger.pl in my client :D
10:29 karolherbst: :')
10:30 dwfreed: I will also add it to my list of features for OFTCServ, which will exist before we move to Atheme
10:31 karolherbst: any ETA on the move?
10:31 f_: OFTCServ?
10:31 f_: oftc-ircservices I guess
10:31 dwfreed: no, oftcserv will be a separate thing
10:32 f_: ah
10:32 dwfreed: karolherbst: not really; the current task is getting OFTCServ written to take over all of our custom bots in oftc-ircservices, like FloodServ
10:32 karolherbst: personally I kinda want to move away from IRC, but sadly we don't really have an alternative I'm actually happy enough with 🙃
10:32 karolherbst: I see
10:33 dwfreed: I have added a trigger to autovoice the discord puppets
10:33 karolherbst: to your client?
10:33 dwfreed: yeah
10:34 dwfreed: but you have to give me ops for it to work
10:34 karolherbst: I can ping you once it's necessary, not sure I want that to rely on you being connected (even if that's like 100% of the time)
10:34 karolherbst: the "spam" we get the most won't be blocked with +M anyway
10:35 dwfreed: yeah, most of the spam is joss
10:36 dwfreed: that's also a goal of OFTCServ, taking care of that
10:37 karolherbst: how would it be able to do that?
10:37 karolherbst: or just being able to group channels?
10:37 karolherbst: and then bans get applied to multiple ones
10:37 dwfreed: well, there's some identification that can be done
10:38 dwfreed: and then it'll be able to use the network level approach I use that's more effective at slowing him down
10:38 dwfreed: and I can also make it easier for affected chanops to report him
10:39 karolherbst: I see
10:39 dwfreed: OFTCServ is basically going to be trigger.pl on steroids, with a better network view
10:39 karolherbst: we also have a coc team (well, I'm also part of it) for all of freedesktop. So we could at least from a governance pov say "this person isn't allowed on all of our channels", would be nice to have also some tooling around that
10:40 dwfreed: That'll be easiest when we move ircd further down the road
10:41 dwfreed: But I could make something for OFTCServ to apply bans in multiple channels in the meantime
10:41 f_: dwfreed: any eta for switching to solanum?
10:42 dwfreed: after Atheme
10:43 karolherbst: dwfreed: yeah.. that might help. We could probably maintain/create a list of such channels. Or add channels once it's needed or something. But I guess you'll still have to figure out the UX for all of this
10:44 dwfreed: We have GroupServ; I'd probably tie it into that
10:44 karolherbst: sounds interesting
10:44 karolherbst: I didn't know about GroupServ
10:46 karolherbst: dwfreed: what can groupserv do anyway? Or is there some documentation on it?
10:46 dwfreed: it's basically a way of consolidating ChanServ access list management across multiple channels
10:46 karolherbst: I see
10:47 karolherbst: so a channel grants permissions to the group and then each members gets them in that channel?
10:47 dwfreed: yes
10:47 karolherbst: nice
10:47 dwfreed: eg, you could make a @freedesktop-coc group (all groups start with @), put everybody in the coc team in it, and then give @freedesktop-coc master access to freedesktop channels
10:48 karolherbst: yeah, that's what I'm thinking about
10:48 karolherbst: but then we'd still have to ban a person in each group individually, right?
10:48 dwfreed: right now, yes
10:48 karolherbst: would be nice to have a "for each channel" function :)
10:55 f_: dwfreed: and is there an ETA for switching to Atheme?
10:55 dwfreed: > not really; the current task is getting OFTCServ written to take over all of our custom bots in oftc-ircservices, like FloodServ
10:55 f_: or is it "when it's ready"
10:55 f_: ah
10:56 dwfreed: when it's ready would be an accurate ETA, yes :P
10:56 f_: so "when it's ready" :)
10:59 f_: so OFTCServ would exist alongside atheme?
10:59 f_: or the custom bots would be atheme modules?
11:00 dwfreed: alongside atheme, it will be its own psuedo server
11:00 f_: cool
11:33 ahuillet[d]: oh, gitlab maintenance
11:34 HdkR: For 48 hours even
11:34 tiredchiku[d]: they're gonna split the DB
11:34 tiredchiku[d]: to keep the CI DB separate from the rest of the DB
11:35 tiredchiku[d]: which should speed up the UI <a:excited:1022260893846872076>
12:33 karolherbst[d]: yeah, hopefully everything will be way quicker now
12:44 gfxstrand[d]: pac85[d]: Yeah, that makes sense. NVIDIA compression is going to turn into a giant PITA, I fear, because you can't just turn it on and walk away.
12:58 pac85[d]: gfxstrand[d]: Uhm I see, does it require to provide extra metadata besides what is on the pte?
13:24 gfxstrand[d]: pac85[d]: A bit. But the bigger problem is that the PTE kind depends on the image format and there are issues with eviction to system RAM. I'm still not sure how it'll all work out.
13:44 pac85[d]: Uhm I see
15:17 gfxstrand[d]: That's a problem for future me, though. Probably not that far into the future me but future me. 😅
15:26 redsheep[d]: Hmm there don't seem to be enough emojis to make a twin pine reference to back to the future
15:26 pac85[d]: Future me will ask future you how you solved it then
15:26 pac85[d]: redsheep[d]: Lol
18:12 gfxstrand[d]: karolherbst[d]: I'm sure you've answered this before and I should write down the answer but how do you usually chuck ptx through the blob?
18:12 karolherbst[d]: gfxstrand[d]: https://github.com/ljbade/clcc
18:13 karolherbst[d]: and this script
18:13 karolherbst[d]: https://gist.github.com/karolherbst/2b07364246ab7e101e7eebca3086921a
18:13 gfxstrand[d]: sweet!
18:14 karolherbst[d]: it needs a libnvidia-compiler.so thing tho
18:14 gfxstrand[d]: It looks like I need to figure out how all the weird branch instructions work.
18:14 karolherbst[d]: and I _think_ that got removed
18:14 karolherbst[d]: `530.41.03` is what I have installed atm
18:14 karolherbst[d]: and I _think_ in newer updates nvidia reworked their internal interfaces
18:14 karolherbst[d]: and I have no idea if anybody figured something out for the new versions 🙂
18:15 gfxstrand[d]: Oh, that turns CL into PTX. I need to turn PTX into a binary
18:15 karolherbst[d]: ehh wait
18:15 karolherbst[d]: that's just ptxas 😄
18:15 karolherbst[d]: I invoke it inside the script
18:16 karolherbst[d]: but writing CLC code is generally easier than writing PTX code
18:16 karolherbst[d]: 😄
18:27 gfxstrand[d]: Ugh... I don't have it in my driver. 😢
18:28 karolherbst[d]: it's part of cuda
18:28 karolherbst[d]: `ptxas` that is
18:29 gfxstrand[d]: karolherbst[d]: I meant this.
18:29 karolherbst[d]: ahh yeah
18:29 gfxstrand[d]: I'm trying to get a simple PTX file to start from
18:29 karolherbst[d]: try 530
18:30 karolherbst[d]: or give me the code and I'll compile for you 😄
18:33 gfxstrand[d]: Just give me the PTX for a `*c = *a + *b` kernel and I'll go from there
18:33 gfxstrand[d]: Or maybe something with control-flow
18:33 gfxstrand[d]: so how about `if (c != NULL) *c = *a + *b`
18:36 karolherbst[d]: mhh
18:38 gfxstrand[d]: I'm trying to figure out what the predicate and GPR sources for `bra` actually do
18:38 karolherbst[d]: just like I do, nvidia ignores `-cl-opt-disable` 😄
18:38 karolherbst[d]: ahh
18:39 karolherbst[d]: that's the output: https://gist.github.com/karolherbst/2fa64209dd9ebb775cceb12089d24dbf
18:39 karolherbst[d]: not sure you'll like it
18:39 gfxstrand[d]: Beautiful!
18:40 karolherbst[d]: there is `-cl-nv-opt-level=`
18:41 karolherbst[d]: mhhh
18:41 karolherbst[d]: setp.ne.s64 %p1, %rd3, 0;
18:41 karolherbst[d]: not.pred %p2, %p1;
18:41 karolherbst[d]: @%p2 bra BB0_2;
18:41 karolherbst[d]: bra.uni BB0_1;
18:42 karolherbst[d]: at least it might tell you how `.uni` works 😄
18:42 karolherbst[d]: though I think they might always turn it into a predicate with ptx?
18:42 karolherbst[d]: does ptx actually have structured CFG operations?
18:42 karolherbst[d]: or is it always labels?
18:44 karolherbst[d]: anyway, have fun
18:44 karolherbst[d]: yooooooo what?
18:44 karolherbst[d]: that compile.sh gist already got spammed :ferrisUpsideDown:
18:49 karolherbst: sintayew4[m]: why that comment on my gist?
18:51 gfxstrand[d]: I don't know how to get the NVIDIA compiler to dump out a `bra` that uses more than just the predicate. 😭
18:56 karolherbst: dwfreed: any idea what to do about bridged users from matrix spaming my gist I post links here to? :D
18:57 karolherbst: or rather, do you know if they have a stable IPv6 address?
19:31 redsheep[d]: Aww gitlab maintenance means I can't stalk the gfxstrand/mesa branches to see what all this branch business is about
19:33 gfxstrand[d]: hehe
19:33 gfxstrand[d]: You'll have to wait until Wednesday to spy on me, I guess. 😂
19:33 tiredchiku[d]: it also means faith can't push new changes, so
19:33 tiredchiku[d]: :wolfFIRE:
19:35 redsheep[d]: Yeah Wednesday is probably going to be a really good stress test
23:00 gfxstrand[d]: I think we have a WaR race where LDC runs faster than PLOP3 can read the source. 🤯
23:37 gfxstrand[d]: Yup! That was it. LDC is so fast that it can return faster than the previous instruction can read its registers. Woof.
23:40 karolherbst[d]: yeah.. those things can happen
23:41 gfxstrand[d]: I'm going to need a more accurate model of execution before long.
23:41 karolherbst[d]: yes
23:41 karolherbst[d]: especially because different sources might be read at different times even 😛
23:41 gfxstrand[d]: Yup
23:43 gfxstrand[d]: The thing that really scares me is how this is probably also tied to codegen in some way. Like, I could imagine the op -> form mapping mattering. 🙀
23:43 karolherbst[d]: it's worse
23:43 karolherbst[d]: random bits can impact it even
23:44 karolherbst[d]: like.. all those HI versions read the source later
23:44 karolherbst[d]: imad wide is also special
23:46 gfxstrand[d]: 😩
23:46 karolherbst[d]: like..
23:46 karolherbst[d]: imad wide is special enough to have its own chapter
23:47 gfxstrand[d]: lol
23:47 karolherbst[d]: it's a pretty bonkers instruction
23:53 gfxstrand[d]: I'm hoping my "all sources are read in the first 4 cycles, right?" will be good enough for now. If not, I'll bump it up to the full latency of the instruction.
23:53 karolherbst[d]: haha
23:53 karolherbst[d]: no
23:53 karolherbst[d]: :ferrisUpsideDown:
23:54 karolherbst[d]: but it depends
23:54 karolherbst[d]: and you'll probably won't hit the corner cases where it amtters
23:56 HdkR: Turns out that reading constants is hella fast on NV :P
23:57 karolherbst[d]: the issue is also, that there are some instructions writing in multiple phases, but that's just an optimization to really care about that
23:57 HdkR: I do love the wacky late read instructions though, makes scheduling them fun
23:57 karolherbst[d]: the best part if a vec2 reg is read in different phases :ferrisUpsideDown:
23:58 HdkR: Of course