00:20 fdobridge: <p​homes_> is it fine to attach a 110mb renderdoc trace to an issue in gitlab?
01:32 fdobridge: <g​fxstrand> And... Merged! :triangle_nvk:
01:32 fdobridge: <g​fxstrand> Can compress it?
01:33 fdobridge: <g​fxstrand> Can you compress it? (edited)
02:04 babyfaceold: I report success in my work, finally looked, we talked, you take indexing coefficients, every entry in compressed format, has in the adder a distance bookkeeping element, that is generated based of a formula with arbitrary distance and as base index at compile time to at runtime to eliminate an entry as subtract from all the bank permutes when filling in a runtime subindex to that
02:04 babyfaceold: bookkeeping base index, the coeffs you yourself generate, we design a modern LBA addressing software layer and have memory in amounts of utter excesss. I add compiler and steady states too as the POC. That's the final gear of my supercomputer work, so I reported success already, amazing.
02:48 babyfaceold: that filtering module of super register file can also serve as a method for branching, but branching can as all the superexecution engine be implemented in operand ways too, the memory is independent of superexecution engine that is, it's execution engine agnostic as we speak.
03:45 fdobridge: <a​irlied> @gfxstrand nice work on merge!
03:46 fdobridge: <g​fxstrand> :triangle_nvk:
03:47 fdobridge: <g​fxstrand> Took long enough. Even once all the Meson stuff got sorted, it took two tries because the container rebuilds take hours and CI timed out. All don't now, though.
04:45 fdobridge: <g​fxstrand> @airlied Just saw my "Oops! Too many fences" bug on Ampere. 😭
04:49 fdobridge: <g​fxstrand> And... saw it again but only one thread is down for now. We'll see if this run can finish.
04:52 fdobridge: <g​fxstrand> I'll file a proper bug report for dakr and re-apply my `size * 8` hack in the morning.
06:01 fdobridge: <s​amantas5855> hello wonderful people
06:01 fdobridge: <s​amantas5855> how's nvk going
06:01 fdobridge: <s​amantas5855> being sometimes since I checked into it
06:02 fdobridge: <s​amantas5855> been some time since I checked into it (edited)
06:27 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> You mean NAK? What will happen with SM generations that don't support NAK? Will they fall back to codegen?
06:30 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I noticed a new commit that checks if 3D class is Turing A or greater and basically does `NVK_USE_NAK=all` automatically
06:32 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I'll really have to get the RenderDoc trace now
09:33 AndrewR: well, congratulations on merging NAK, but where I can find meson 1.3.0 ? pip3 only sets 1.2.3 ...
09:34 DodoGTA: AndrewR: It's only available as a RC right now (which is marked as a pre-release on GitHub)
09:35 DodoGTA: https://pypi.org/project/meson/1.3.0rc3/
09:42 fdobridge: <e​sdrastarsis> oh, they released rc3, nice
10:25 AndrewR: Problem encountered: NAK requires Rust 1.73.0
10:25 karolherbst: how is that a problem?
10:26 AndrewR: karolherbst, ...
10:26 karolherbst: no, seriously
10:26 karolherbst: it's available through rustup
10:26 karolherbst: and distributions will figure it out
10:26 AndrewR: karolherbst, I hope rustup exist for i686
10:26 karolherbst: it does afaik
10:26 karolherbst: let me check
10:26 AndrewR: karolherbst, not everyone runs Fedora current
10:26 karolherbst: yeah, that's why they should use rustup
10:27 karolherbst: available i686 targets: i686-linux-android i686-pc-windows-gnu i686-pc-windows-msvc i686-unknown-freebsd i686-unknown-linux-gnu i686-unknown-linux-musl
10:28 karolherbst: I kinda see the point of distributions having work to do, but that won't be a problem until next year
10:28 karolherbst: and only for those updating aggreesively
10:28 karolherbst: developers/users should use rustup anyway to compile from git
10:28 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Arch Linux does have up-to-date Rust though (which allows me to compile NAK) :ferris:
10:28 karolherbst: it's not worth the pain using distribution packaged rust
10:28 karolherbst: as it's constantly causing issues
10:29 fdobridge: <k​arolherbst🐧🦀> @asdqueerfromeu hope you'll never run into bindgen related problems, but yeah...
10:30 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I only needed to delete the build directory to compile 32-bit NAK without issues though
10:31 fdobridge: <k​arolherbst🐧🦀> I have two build directories and some magic
10:31 fdobridge: <k​arolherbst🐧🦀> meson cross files are like that
10:32 AndrewR: ..it all nice for Arch, but I still use Slackware, for 15.0 rustup exist, but in sbo. so .... wait a bit, may be it will work
10:32 karolherbst: I hope it does
10:33 karolherbst: rustup is kinda cool as it also allows you to set specific rust versions per directory, so you can easily deal with things needing different versions of rust
10:33 karolherbst: like e.g. the kernel is more strict about it
10:34 AndrewR: new python, how great
10:52 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> `qrenderdoc: ../mesa/src/nouveau/vulkan/nvk_graphics_pipeline.c:184: emit_pipeline_ct_write_state: Assertion 'cb->attachment_count == att_count' failed.` :cursedgears:
11:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> :ferris:
11:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1173941730102476810/Screenshot_20231114_130417.png?ex=6565c96f&is=6553546f&hm=fdf997285fc254adc3b93364c8cfc90840aef1ebe859513d2143884bd977d4c9&
11:07 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I'm not sure if this is a correct fix though :triangle_nvk:
11:07 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1173942200795668502/message.diff?ex=6565c9df&is=655354df&hm=e0dcca67963873ee3290938274cbb4b8bdcb19893e18e34bd4d4bc3ece64d6b9&
11:08 AndrewR: well, at least build started ....
11:12 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> @mhenning Here's a RenderDoc trace that you can mess around with: https://drive.google.com/file/d/1UIYCGnawel88wnAdPTo6TEB0vkPpPhAN/view
11:15 AndrewR: karolherbst, but on kepler I need also !26114 ?
11:16 karolherbst: I don't think it's strictly needed
11:16 karolherbst: codegen is still wired up, it's just going to be a bit slower
11:17 karolherbst: but I think this MR needs a rebase :D
11:19 karolherbst: AndrewR: also.. I think that's just Maxwell for now...
11:31 fdobridge: <o​rowith2os> karolherbst: with other Rust tools in Mesa now also relying on Rust and pushing their own desires for versioning, would you also use those as reasoning for pushing the required Rust version for rusticl?
11:34 AndrewR: also, even on kernel 6.6+ I still see GL_NVX_gpu_memory_info Total available memory: 1050617 MB It can't be true ...
11:37 fdobridge: <k​arolherbst🐧🦀> I probably should
11:53 AndrewR: https://paste.pics/adb3a27fea46485b1458a20d2105b387
11:53 karolherbst: well.. it runs at least...
11:54 AndrewR: karolherbst, so, NAK does something (?) but just as regular nvk it just ..tiled?
11:54 karolherbst: nah.. I doubt NAK does anything here and you probably still use codegen
11:54 karolherbst: did it work before?
11:54 AndrewR: karolherbst, I only recently compiled 6.6 kernel so o idea
11:54 karolherbst: I see..
11:55 karolherbst: did it work before with an older kernel?
11:55 AndrewR: karolherbst, isn't 6.6 requrement for nouveau vulkan?
11:55 karolherbst: mhhh... right.. the code for using the old UAPI got removed
12:00 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> This is the most old-school NVK setup I've seen
12:47 fdobridge: <m​ohamexiety> Huh
12:47 fdobridge: <m​ohamexiety> I installed the copr with linux-firmware but
12:47 fdobridge: <m​ohamexiety>
12:47 fdobridge: <m​ohamexiety> `[ 3.666933] nouveau 0000:01:00.0: gsp: firmware "nvidia/ga102/gsp/gsp-535.113.01.bin" unavailable`
12:48 fdobridge: <m​arysaka> is the file present in the firmware directory?
12:48 fdobridge: <m​arysaka> and if yes did you regenerate initramfs
12:48 fdobridge: <m​ohamexiety> I did it before building and installing the kernel too \:o
12:48 fdobridge: <m​ohamexiety> Will check, sec
12:50 fdobridge: <m​ohamexiety> `usr/lib/firmware/nvidia/ga102/gsp`, right?
12:50 fdobridge: <m​ohamexiety> yeah it's empty..
12:52 fdobridge: <m​ohamexiety> actually all gsp files are empty for other chips too
12:52 fdobridge: <m​ohamexiety> this is odd
12:53 fdobridge: <m​arysaka> hmm
12:54 fdobridge: <m​ohamexiety> maybe I messed up the copr? it's `linux-firmware-20231030-1.fc39.gsp.noarch`, right?
12:55 fdobridge: <m​ohamexiety> tried reinstalling just now and the files are all empty too
12:56 fdobridge: <m​arysaka> I'm not using the copr package so far 😅
12:57 fdobridge: <m​ohamexiety> yeah that's fine
13:07 fdobridge: <a​irlied> you need the nvidia rpm
13:07 fdobridge: <a​irlied> we split the firmware rpms
13:07 fdobridge: <a​irlied> nvidia-gpu-firmware
13:11 fdobridge: <m​ohamexiety> oh I see
13:11 fdobridge: <m​ohamexiety> from the copr, right? I tried getting it but I got a 404 on all mirrors
13:11 fdobridge: <m​ohamexiety> > Error: Error downloading packages:
13:11 fdobridge: <m​ohamexiety> > nvidia-gpu-firmware-20230804-153.fc39.noarch: Cannot download, all mirrors were already tried without success
13:12 fdobridge: <k​arolherbst🐧🦀> nah.. fedora
13:12 fdobridge: <k​arolherbst🐧🦀> fedora upgrades the firmware stuff quite quickly
13:12 fdobridge: <a​irlied> that looks like an older copr
13:13 fdobridge: <k​arolherbst🐧🦀> ehh wait..
13:13 fdobridge: <k​arolherbst🐧🦀> don't mind me, my local setup is scrwed up
13:13 fdobridge: <a​irlied> https://download.copr.fedorainfracloud.org/results/airlied/nouveau-gsp/fedora-39-x86_64/06610281-linux-firmware/nvidia-gpu-firmware-20231030-1.fc39.gsp.noarch.rpm
13:13 fdobridge: <m​ohamexiety> ```
13:13 fdobridge: <m​ohamexiety> dnf --showduplicates list nvidia-gpu-firmware
13:13 fdobridge: <m​ohamexiety> Fedora 39 - x86_64 - Updates 24 kB/s | 24 kB 00:00
13:13 fdobridge: <m​ohamexiety> Fedora 39 - x86_64 - Updates 400 kB/s | 1.6 MB 00:04
13:13 fdobridge: <m​ohamexiety> Last metadata expiration check: 0:00:03 ago on 2023-11-14T15:09:26 EET.
13:13 fdobridge: <m​ohamexiety> Installed Packages
13:13 fdobridge: <m​ohamexiety> nvidia-gpu-firmware.noarch 20231030-1.fc39 @updates
13:13 fdobridge: <m​ohamexiety> Available Packages
13:13 fdobridge: <m​ohamexiety> nvidia-gpu-firmware.noarch 20230804-153.fc39 copr:copr.fedorainfracloud.org:airlied:nouveau-gsp
13:13 fdobridge: <m​ohamexiety> nvidia-gpu-firmware.noarch 20230919-1.fc39 fedora
13:13 fdobridge: <m​ohamexiety> ```
13:13 fdobridge: <m​ohamexiety> huh
13:15 fdobridge: <m​ohamexiety> it worked, thanks! all files are there too. interesting it doesn't show up here though
13:16 fdobridge: <m​ohamexiety> like, `linux-firmware` shows properly in `dnf list` here as 20231030 from the copr, but when I tried `nvidia-gpu-firmware` it only listed the older one
13:17 fdobridge: <m​ohamexiety> anyways, it's fine now. thanks a lot and sorry for the confusion
14:46 fdobridge: <g​fxstrand> Yup. And we'll keep updating that as we back port NAK until we can eventually just delete codegen support from NVK.
14:48 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Would implementing the `bufferDeviceAddressCaptureReplay` feature on NVK require a change in the kernel API? 😰
14:48 fdobridge: <g​fxstrand> I'm going to do more work today to refactor the codegen stuff to make it look more like NAK. So the hand-over is eventually easier.
14:50 fdobridge: <g​fxstrand> Nope! Just a little userspace work. The new kernel API already has everything we need. (it was impossible with the old API).
14:51 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Right now RenderDoc falls back to Vulkan 1.2 if that feature isn't supported (which breaks DXVK v2.0+)
14:51 fdobridge: <g​fxstrand> Best way is to just `git clone https://GitHub.com/mesonbuild/meson`
14:53 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I hacked up Arch's `meson` package to submit `meson-rust` in the AUR (which should also work)
14:54 fdobridge: <g​fxstrand> And for those worrying about requirements, I don't intend to bump them again. The only exception is that we may hard-require meson 1.4 in the r future if that gets us Cargo support.
14:55 fdobridge: <g​fxstrand> The rust meson folks are hoping to land all the new Rust toys for 1.4. what I'm doing right now to pull in creates is a travesty. 😅 It works not it's not good.
14:55 fdobridge: <g​fxstrand> The rust meson folks are hoping to land all the new Rust toys for 1.4. what I'm doing right now to pull in crates is a travesty. 😅 It works not it's not good. (edited)
14:56 fdobridge: <k​arolherbst🐧🦀> yeah.. I suspect we'll have to bump meson a few times regularly
14:56 fdobridge: <g​fxstrand> Cross builds even work (that was entertaining to get fixed. 🙄)
14:56 fdobridge: <k​arolherbst🐧🦀> funky
14:56 fdobridge: <k​arolherbst🐧🦀> ohh right
14:56 fdobridge: <k​arolherbst🐧🦀> that reminds me
14:57 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I already compiled 32-bit NAK (as you can see from the GTA fog issues I posted)
14:57 fdobridge: <k​arolherbst🐧🦀> @gfxstrand does this ring a bell? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25775#note_2165979
14:57 fdobridge: <k​arolherbst🐧🦀> ehh
14:57 fdobridge: <k​arolherbst🐧🦀> not the comment
14:57 fdobridge: <k​arolherbst🐧🦀> the MR itself
15:00 fdobridge: <g​fxstrand> AndrewR: Wow, that screenshot takes me back...
15:01 fdobridge: <g​fxstrand> Oh, yeah... 🥵
15:01 fdobridge: <k​arolherbst🐧🦀> not really looking forward of adding a hack like that, so maybe just advising to meson 1.3 would be best here
15:01 fdobridge: <k​arolherbst🐧🦀> *use
15:02 fdobridge: <g​fxstrand> With Meson 1.3, you can just use rust.proc_macro() to compile it and then Meson will just do the right thing.
15:02 fdobridge: <k​arolherbst🐧🦀> I see...
15:03 fdobridge: <g​fxstrand> It's when you pull in crates that get used by your proc macro that things get extra spicy. 🌶️
15:03 fdobridge: <k​arolherbst🐧🦀> I just wonder how stable that workaround is
15:03 fdobridge: <k​arolherbst🐧🦀> but with meson 1.3 I'd plan to use the fancy new thing anyway
15:03 fdobridge: <g​fxstrand> Yeah
15:03 fdobridge: <k​arolherbst🐧🦀> and I'd bump to 1.3 then anyway 😄
15:04 fdobridge: <g​fxstrand> TBH, I doubt it would be that controversial to require 1.3 for rusticl
15:04 fdobridge: <k​arolherbst🐧🦀> yeah.. not sure.. some distros already build it
15:05 fdobridge: <k​arolherbst🐧🦀> so I usually wait until 1 or 2 weeks after the release before I bump
15:05 fdobridge: <k​arolherbst🐧🦀> but maybe using rc2 is already good enough 😄
15:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> rc1 is broken :ferris:
15:05 fdobridge: <k​arolherbst🐧🦀> with NAK merged it's already kinda required
15:06 fdobridge: <g​fxstrand> 1.3 should be final in a week or two and the next Mesa branch isn't for a bit. Wait two weeks, bump the req, and no distro will notice for like a month
15:06 fdobridge: <g​fxstrand> If you're really worried, bump in January.
15:06 fdobridge: <k​arolherbst🐧🦀> ohh yeah, that's fine then
15:06 fdobridge: <k​arolherbst🐧🦀> then I can just reply with that
15:06 fdobridge: <g​fxstrand> Rc2 is as well. Mesa CI is pulling a SHA from yesterday.
15:07 fdobridge: <g​fxstrand> It's really hot
15:07 fdobridge: <k​arolherbst🐧🦀> 😢
15:07 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> rc2 was the first release that could build NAK for me without weird issues or hacks
15:08 fdobridge: <k​arolherbst🐧🦀> @gfxstrand I suspect you don't plan to bump the rust version anytime soon?
15:09 fdobridge: <g​fxstrand> Whatever were requiring now should be enough for a while. It's got `u32.div_round_up()` and `u32.next_multiple_of()` which are the big things.
15:09 fdobridge: <k​arolherbst🐧🦀> I'm still on 1.66, but also don't see a good reason to bump all the way up to 1.73
15:09 fdobridge: <k​arolherbst🐧🦀> I thing those are the only things relevant to me to make that bump 😄
15:10 fdobridge: <k​arolherbst🐧🦀> ohh there is also `next_multiple of`
15:10 fdobridge: <k​arolherbst🐧🦀> ahh yeah
15:10 fdobridge: <k​arolherbst🐧🦀> you mentioned it
15:10 fdobridge: <k​arolherbst🐧🦀> I have helper for both of those as they are kinda trivial to write
15:10 fdobridge: <k​arolherbst🐧🦀> but a pain in generic code 😄
15:10 fdobridge: <k​arolherbst🐧🦀> `let one = b / b;` moment
15:19 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I made some kind of a list: https://discord.com/channels/1033216351990456371/1034796636834115584/1174005450707058718 :triangle_nvk:
15:30 fdobridge: <m​henning> rc3 released last night - we might be able to switch CI to that
15:33 fdobridge: <p​homes_> I am running with rc3 now. 'pip install meson==1.3.0rc3' worked for me
15:33 fdobridge: <g​fxstrand> We'll probably switch CI once real 1.3 is out. It's also a bit of a pain because it causes a full container rebuild which takes forever.
15:34 fdobridge: <m​henning> Fair enough
15:34 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> You should rebase the pipeline caching MR (because NAK broke it a bit)
15:40 fdobridge: <g​fxstrand> Don't rebase pipeline caching just yet. I'm going to rework all of nvk_shader.c today.
15:41 fdobridge: <g​fxstrand> @airlied My kernel survived my 2nd run last night but my GSP didn't. 😭
15:45 fdobridge: <e​sdrastarsis> Moar perf? :happy_gears:
15:51 fdobridge: <a​irlied> 😦 guess I have to do a lot more hammering on it, did it backtrace?
15:55 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I already did (so I guess I'll have to deal with quite a bit of breakage later)
15:55 fdobridge: <g​fxstrand> No, just cleanliness this time. Pulling all of the codegen-specific stuff out of the NAK path and wrapping it up so it's out of the way.
16:01 fdobridge: <e​sdrastarsis> Nice
16:05 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Hopefully NVK will still retain the title of a Vulkan reference driver :triangle_nvk:
16:39 fdobridge: <g​fxstrand> @marysaka you probably want to rebase barycentrics on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26181
16:43 fdobridge: <m​arysaka> Will do that a bit later, should I split the NIR changes in another MR once I open stuffs against mesa main?
17:01 fdobridge: <g​fxstrand> Nah
17:01 fdobridge: <g​fxstrand> I can ack NIR changes
18:49 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> :triangle_nvk:
18:49 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1174058662831075468/Screenshot_20231114_204500.png?ex=65663656&is=6553c156&hm=f7136a5c2138e0200f54e0dacf4473345b8e58e87f98a1eb3fff9f2aab042939&
19:04 fdobridge: <h​untercz122> https://www.youtube.com/watch?v=npxsD7u52qk
19:04 fdobridge: <h​untercz122> :triangle_nvk:
19:07 fdobridge: <k​arolherbst🐧🦀> noice
19:34 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Here's also the Overwatch 2 trace if you're interested: https://drive.google.com/file/d/1pn_GUq-8GdxkzwQKWVRglaEY6CT7EUcb/view
19:40 fdobridge: <k​arolherbst🐧🦀> I once again pinged on the sph thread I have :ferrisUpsideDown:
19:40 fdobridge: <k​arolherbst🐧🦀> maybe I should write a bot to do that for me
19:42 fdobridge: <k​arolherbst🐧🦀> maybe I offer to ignore mesh-shader/raytracing relevant bits for now :ferrisUpsideDown:
19:45 fdobridge: <m​arysaka> I can probably figure out the mesh shader part without much issues tbh
19:46 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Running Nvidium on nouveau would be an interesting goal
19:49 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Also when will Mesa have a proprietary NVIDIA driver emulation mode for GLSL so that Mesa drivers could run GLSL shaders made with NVIDIA drivers in mind? 🍩
19:56 fdobridge: <k​arolherbst🐧🦀> yeah.. I just want to have their header files for the sph 😄
19:57 fdobridge: <m​arysaka> That would be nice to have yeah
20:01 fdobridge: <d​adschoorse> looks like <https://gitlab.freedesktop.org/freedesktop/mr-label-maker> still needs an update for nak
20:20 fdobridge: <g​fxstrand> Yeah, it probably does
20:25 fdobridge: <g​fxstrand> https://gitlab.freedesktop.org/freedesktop/mr-label-maker/-/merge_requests/18
20:56 fdobridge: <g​fxstrand> dakr: Do we have a tracker issue for userptr? If so, can tag it in https://gitlab.freedesktop.org/mesa/mesa/-/issues/9633 ?
21:04 fdobridge: <b​enjaminl> I'm looking at subgroup ops on SM50, and the SHFL instruction encoding I have seems to work in every case _except_ `SHFL.UP`
21:04 fdobridge: <b​enjaminl> `SHFL.UP` is a nop
21:05 fdobridge: <b​enjaminl> I've got to be missing something silly here... but probably won't have time to debug it for a while
21:24 fdobridge: <b​enjaminl> okay, problem is definitely the `c` operand value...
21:26 dakr: gfxstrand: Not that I'm aware of - can create one though. Just not yet sure when I'll get to it.
21:27 olderfacebaby: Maybe infact you do not understand programming still after years or decades in row doing nonsense, which seems weird not sure what to do with such inhabitants in the world, seems neither my harassment by your dopamine and steroid munching sick dudes and slut fans nor world climate instabilities bother you, you just want to eat sausage and fart, code under your leadership is pretty weak. Lots of tyranny I got has been discontinued ever since I
21:27 olderfacebaby: started to accuse people. They no longer want to get caught, that is some side effect enough. Sure none wants to die or put lifetime in jail, you just want to harass eat sausage, do lame jokes and fart isn't it?
22:00 gfxstrand: dakr: That's fine. I'm just thinking it would be good to track this stuff so we at least have it written down somewhere. It would also give us a place to write down what we'd talked about at XDC RE the API.
22:00 gfxstrand: dakr: I'm not expecting it to happen soon. IMO, there are higher priority things from my PoV.
22:28 fdobridge: <g​fxstrand> Nice!
22:28 fdobridge: <g​fxstrand> Yeah, the c operand is weird. I wouldn't be at all surprised if the meaning has shifted a bit between generations.
22:34 fdobridge: <d​adschoorse> what is it for? cluster mask?
22:34 fdobridge: <g​fxstrand> Cluster mask and xor at the same time
22:34 fdobridge: <g​fxstrand> And another thing
22:36 fdobridge: <d​adschoorse> probably still less cursed than the zoo of shuffle ops that amd has 🐸
22:41 fdobridge: <b​enjaminl> it looks like the PTX docs mention it
22:47 fdobridge: <g​fxstrand> Yeah, it's in the PTX docs but I might have gotten it wrong even on turing.
22:47 fdobridge: <g​fxstrand> The tests pass but that doesn't always mean anything