00:00 alyssa: nir-to-tgsi, you're up
00:02 alyssa:drives to figure out how to force softpipe and not llvmpipe
00:04 alyssa: GALLIUM_DRIVER=softpipe apparently
00:38 alyssa: can't tell if radeonsi bug or weird intended asymmetry
01:17 Kayden: alyssa: here's a link to what dj-death was mentioning: https://gitlab.freedesktop.org/kwg/mesa/-/commits/compiler-lsc-opcode-blocks - sorry it's still a mess, but if you look at the patches with "intel/fs: Introduce new MEMORY_*_LOGICAL opcodes" and the next few, you'll get the idea (rest is bug fixes)
01:17 alyssa: eyes
01:18 Kayden: alyssa: I'm reworking the intel backend to not have 28 different opcodes for reading/writing memory, instead just having 1 (well, 3 - load/store/atomic), with lots of parameters for... typed/untyped/scratch/SLM? how many components? what kind of address? 64-bit pointer? 32-bit pointer? pointer to surface state? pointer directly to memory? image load with coordinates with components?
01:18 alyssa: neato
01:18 Kayden: and then just lowering that to the actual messages in a pass
01:19 Kayden: a couple things definitely struck me as odd in the NIR intrinsics, namely
01:19 alyssa: I'm scared of both your ISA and your backend so IDK if that's the right call but seems legit :D
01:19 Kayden: - we kind of duplicate the hell out of the atomics rather than parameterizing the type of thing
01:20 Kayden: - how are there no helpers for "is this a load?" "is this a store?" "is this an atomic?" given that there are switch statements 100 lines long to determine those things
01:20 Kayden: or even "is this an SSBO operation"
01:20 alyssa: uff, yeah
01:20 alyssa: In general I'd like to move a lot of that metadata out of switch statements and into nir_intrinsics.py and nir_opcodes.py
01:21 alyssa: but that's orthogonal to what I'm working on now
01:21 alyssa: which is a big enough rework that I'm not inclined to add another
01:21 alyssa: honestly this is just a warmup for the really big cross-tree NIR hell I have in store :~P
01:22 Kayden: looks like you've got two atomic intrinsics now with a parameter for what operation it is? one with swap (extra suorces), one for the others?
01:22 Kayden: that is way nicer :)
01:24 Kayden: alyssa: another thing you might be interested in for NIR patches... I was looking at nir_intrinsic_can_reorder the other day, and noticed it was hardcoding some intrinsics and assumptions
01:24 Kayden: https://gitlab.freedesktop.org/kwg/mesa/-/commits/nir-reorder-fixes cleans that up
01:24 Kayden: but it didn't actually make a difference on any of the shaders I was looking at
01:25 Kayden: so wasn't sure if it was actually that much of an improvement
01:26 Kayden: but yeah, anyway, I like your new intrinsics, I will be happy to use them :)
01:28 alyssa: Kayden: I'll put your down for writing the intel patches then :D
01:28 Kayden: sure :)
01:29 alyssa: 15 files changed, 496 insertions(+), 897 deletions(-)
01:29 alyssa: not bad for an afternoon :D
01:30 alyssa: (adding the core stuff, and then converting agx/bifrost/midgard/llvmpipe/ntt/amd)
01:30 alyssa: 6 backends down, ??? to go
01:31 alyssa: v3d, ir3, intel, nouveau, aco
01:31 alyssa: (those I skipped because they seemed not entirely trivial)
01:31 alyssa: and dxil, why is dxil not showing up in my grep
01:32 alyssa: oh becuase it's not global based
01:32 alyssa: also have r600/sfn, zink, and dxil
01:32 alyssa: so 6 down, 8 to go
01:32 alyssa: with Kayden and jenatali volunteering for Intel and DXIL respectively
01:33 jenatali: Sounds good
01:33 alyssa: Probably I should do aco/ir3/zink so the powers that be don't ask why I wrote an AGX patch today ;-p
01:33 alyssa: leaving only v3d, nouveau, and r600 unclaimed
01:34 alyssa: of those only v3d doesn't scare me (-:
01:34 alyssa: but, should probably get what I already wrote reviewed and landed first
01:34 alyssa: in case somebody bikesheds it and I need to rewrite history hard
01:38 alyssa: that is to say, if you would like to see backend code deleted, please review !22914 :D
01:57 zmike: I think zink is effectively already unified using a macro
02:08 alyssa: ok, should be a very easy patch then :)
02:08 alyssa:will do it
07:18 airlied: zmike: what's the pipeline destroy thing actually meant to do in lavapipe? it really doesn't close the race
07:21 airlied: or maybe it's just messed up with task/mesh, but not sure why yet
09:39 hakzsam: anholt_: hi, can you reply here please https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20024#note_1868955 ?
10:06 T_X: hi, I'm seeing some issues in Wine run games when VRAM usage gets higher than 95% of the available 8GB VRAM. and when GTT is starting to be used. mostly in DCS World, but also had this in No Man's Sky a few times after jumping from one solar system to another. anyone knowing what the current status of TTM or GEM for the opensource amdgpu driver is? (TTM and GEM would be able to track active vs. inactive
10:06 T_X: allocations and move it between VRAM and GTT accordingly, right?)
10:08 T_X: I'm also using an Thunderbolt 3 eGPU enclosure over a 40gbit/s USB4 port here, so I believe that makes GTT usage especially painful (/ making the game unusable) for me
10:47 tomeu: have started getting this error from bindgen after updating to fedora 38 (even if I use rustup):
10:47 tomeu: thread 'main' panicked at 'Not able to resolve vector element?: Continue', /home/tomeu/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.59.2/src/ir/ty.rs:1135:22
10:47 tomeu: any ideas?
10:53 karolherbst: how would people feel about requiring mesa to be rebuilt on every single update to clang?
10:54 karolherbst: this is the most likely outcome if https://github.com/llvm/llvm-project/issues/60849 doens't get resolved, because I'm done playing silly games
10:55 karolherbst: distributions carry downstream patches to fix it as my only way of fixing would be to run `clang -print-resource-dir` at runtime
10:58 karolherbst: maybe I need to write the patch myself and figure out an API for it :(
11:29 zmike: airlied: pretty sure it fixes the race
13:03 alyssa: zink you're up
13:14 alyssa: and there we go
13:14 alyssa: zmike: the fact that zink+lavapipe is a reasonable way for me to test cross-tree changes is bizarre and hilarious
13:14 alyssa: :D
13:15 zmike: shhhh don't tell everyone my secret
13:15 alyssa: also did deqp-vk + radv + https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21892 this morning
13:16 alyssa: RADV_DEBUG=llvm,shaders i can has shaders!
13:16 alyssa:should probably do aco next
13:16 alyssa: zink: Use unified atomics
13:16 alyssa: 2 files changed, 46 insertions(+), 195 deletions(-)
13:16 alyssa: *49
13:18 alyssa: ~i am once again asking for code review~
13:18 kode54: would it be a kernel or userspace bug if all compositors I throw at this driver randomly cause render bugs such as geometry blinking out of existence for a few frames?
13:18 kode54: (Xe, not the atomics thing above)
13:19 zmike:only reviews MRs with subscribed tags
13:20 HdkR: kode54: Both
13:20 kode54: and how the heck would I debug that?
13:20 alyssa: zmike: oh gah i forgot the bot doesnt tag draft MRs
13:21 HdkR: kode54: Get hired at Intel and learn the codebase :P
13:25 kode54: I am so glad that VM_BIND got put on the back burner for i915, and that DG2 is a second class citizen in Xe
13:32 sima: kode54, it's actually kinda annoying because no vm_bind in i915 means it's much rougher to port to xe
13:32 sima: since you can't tell xe bugs from vm_bind bugs in the userspace
13:33 sima: plus lack of vm_bind does block some features you really want on vk for gaming
13:34 pq: smells like sarcasm, but where is it coming from...
13:41 kode54: sorry for the sarcasm
13:41 kode54: I'm just mildly annoyed
13:42 kode54: and I don't know how I can help
13:42 kode54: devs have the hardware
13:42 kode54: all I can do is throw unknown software at it
13:43 HdkR: i can understand how frustrating it is when realities don't match with expectations around video drivers.
13:46 alyssa: eric_engestrom: apinheiro: itoral: Any chance one of you is up for deleting code from nir-to-vir?
13:46 alyssa: looking to sign up someone for the v3d side of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22914
13:46 alyssa: karolherbst: How about you for codegen?
13:48 apinheiro: alyssa, you got me right now disconnecting
13:48 apinheiro: and itoral is already afk right now
13:48 apinheiro: but I will take a look later
13:48 alyssa: apinheiro: :+1: those patches are for after that MR settles and merges
13:48 alyssa: but would like to get all the drivers converted sooner than later
13:48 apinheiro: and then check if there is anyone of us avaiaiable for that
13:48 alyssa: :+1:
13:48 alyssa: thanks!
13:49 apinheiro: thanks to you for keeping us on the loop
13:49 alyssa: if so that just leaves r600/sfn as unclaimed
13:49 alyssa: and since Gert is away and that code has a bus factor of 1.. sigh
14:09 karolherbst: alyssa: yeah, should be trivial
14:10 karolherbst: more or less
14:11 alyssa: :+1:
14:11 alyssa: will pencil you in for that
14:13 alyssa: zmike: how is deqp-gles31 + zink + radv + amdgpu drm-shim a valid way to debug a radeonsi crash on my macbook
14:14 alyssa: i mean it worked, gdb gave me the backtrace I needed
14:15 alyssa: Incidentally, dEQP-GLES31.functional.image_load_store.early_fragment_tests.no_early_fragment_tests_depth crashes with zink + radv + RADV_DEBUG=llvm
14:15 alyssa: backtrace deep inside llvm
14:15 alyssa: going to guess that one's a wontfix
14:28 daniels: alyssa: Gert’s back
14:28 alyssa: daniels: Ooh, good to know :)
14:28 alyssa: After !22914 is merged can I borrow him for an hour of gfx r&d time then? ;-p
14:36 jenatali: alyssa: Think you'll be able to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22913? I think I can work around this bug by just running nir_opt_remove_phis in my backend before lower_returns, but it seems like this is the right fix
14:37 jenatali: Not sure what to do about that test though :(
14:42 daniels: alyssa: sure, he does r600 anyway, I’m sure he’ll be thrilled to have a community
14:42 robclark: alyssa: you could test more of mesa incl ntt (plus virglrenderer) if you used virgl -> vtest -> zink ->lavapipe
14:50 alyssa: daniels: :-D
14:50 alyssa: thanks =)
14:52 alyssa: jenatali: minimally ack but not in a headspace to review SSA voodoo right now
14:52 alyssa: robclark: oh boy :p
15:24 jenatali: I'm also looking for a Vulkan runtime reviewer for the first patch of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22879
16:16 karolherbst: alyssa: entirely untested https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/36380706884bf2d265fdfc193b48eba625a93614
16:16 karolherbst: mhh, not entirely, I did compile it
16:40 alyssa: Eyyy
16:40 alyssa: thanks karolherbst :)