00:19mareko: karolherbst: if some drivers expect passes to be run by frontends, they will use NIR_PASS_ASSERT_NO_PROGRESS
10:29rcv11x: Hello Mesa devs, I have a question. For Mesa 26.0, which will be released in February, are there any plans or active/merged PRs to improve ray tracing in RDNA4? I have a 9070 XT, and I'm curious because Mesa 25.3 improved things somewhat, but there is still a lot of room for improvement, and it would be great.
10:30K900: There's a bunch of things yes
10:30K900: You can go through the list of PRs if you really want to
10:34rcv11x: Yes, I usually check out the active PRs and such, but since I'm not a developer, I don't know much about it, haha. There's still a long way to go, but I trust all of you to make Mesa 26 huge and full of improvements. So far, I've been very happy.
10:34rcv11x: What I'm most looking forward to is better ray tracing in RDNA 4 and performance improvements. Thank you all, and great job!
10:43K900: I'm not sure what you mean by "better"
10:43K900: There have been some perf improvements
10:44K900: But there's only so much the hardware can actually do at the end of the day
10:53rcv11x: Of course, I understand. I was referring to performance improvements and ray tracing. I've been looking at this PR, but I don't know if it's valid for my GPU or not. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29580
10:56K900: It affects generic radv code so it should affect all GPUs
10:57K900: But also, please don't comment on random PRs with questions like that
10:57K900: That conversation is for people working on the code
11:01rcv11x: @k900
11:01rcv11x: You're right, sorry.
11:01rcv11x: It's just that I like to stay informed. Can I ask questions like this on this IRC instead of doing so in a PR?
11:03K900: IRC is definitely the less bad option, at least
11:30llyyr: there's incremental improvements being made all the time, no one MR is going to give you a noticeable bump though
14:24anonymix007[m]: Any ideas why tgsi_to_nir doesn't seem to work on these seamingly trivial shaders? https://katb.in/cijukedaniz
14:24anonymix007[m]: SPIR-V dumps are basically no-ops either which is probably expected
14:43ManDay: Hello, I'm experiencing freezes and memory corruption since "a while ago". Someone gave me a new kernel config and explained to me that I had some missing options which led to the GPU being underpowered which caused the freezes, and the freezes have since then stopped, but I'm still getting frequent bugs which seem related to the pipeline. The mpv UI frequently fails to display, or
14:43ManDay: shows artefacts, subtitles randomly display only a fraction of their entries. Sometimes MPV issues "spill over" and other apps start showing artefacts or swap errorneous buffers. ( Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]) . Can anyone help with this please?
14:43ManDay: I *think* the problems started with a mesa update, 2 months back roundabout
16:29kallisti5: anyone know where _mesa_glapi_tls_Context is supposed to come from in mesa now? Started getting missing symbols for the glapi stuff in 25.x
16:38kallisti5: nevermind, think i figured it out :-)
18:40anholt: NIR behavior question: should an fsat be able to return -0.0?
18:46anholt: looks like nir_op_fmin/fmax are more opinionated on signed zeroes than C, and fsat should follow suit.
18:52cwabbott: anholt: yes, that should be right, since fsat comes from fmin/fmax
19:56glehmann: ieee-754-2008 was a mistake
22:40alyssa: anholt: right - I don't think fsat can return -0.0
22:41anholt: sounds like consensus. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076 is getting close, I think. except that emulating nir_constant_folding.c is so slow that getting CI to pass on our cross builds is some whack-a-mole.
22:41alyssa: really good work :)
22:41alyssa: thanks for doing that
22:42anholt: most of the credit should go to Konstantin, I'm just doing some grunt work polishing it.
22:42alyssa: konstantin: thank you too :)
22:42alyssa: i'll review next week when i'm back in office
22:43alyssa:has alive2 envy
22:47alyssa: anholt: tangentially but we probably need some way to check that *backends* are correctly implmenting fsat(-0.0), I don't pretend to know what random hw in the wild does there
22:47alyssa: not your problem of course. just mumbling
22:48anholt: One would hope (ha) that CTS would have fmax(x, 0.0) and fmin(fmax(x, 0), 1) with likely input values.
22:48alyssa: I want to assume hardware does fsat(-0.0) = +0.0 because the alternative is more gates. but i know better than to assume things about random ISAs.
22:49anholt: pretty sure my best bet for figuring out if the cts does would be to make a backend explicitly fail that case.
22:50alyssa: that sounds about right, yeah..
22:51alyssa: (re my alive2 envy) I've daydreamed about nir algebraic -> z3 translation to prove correctness of rules... but pretty far down the todo list, and hopefully the unit tests get most of the win for a fraction of the effort.
22:53alyssa: at some point we'll need to pin down NIR's undefined value semantics (ideally we'd add poison/freeze matching LLVM semantics and drop our current nir_undef) .. manually catching the rules that would need freezes inserted sounds fraught
22:54alyssa: (('bcsel', a, 'b@1', False), ('iand', a, b)) is the classic example of a rule we have that's broken under llvm semantics
22:54alyssa: [It should be (('bcsel', a, 'b@1', False), ('iand', a, ('freeze', b))) ]
22:55alyssa: I think the unit testing stuff would catch that though, once taught about poison/freeze (and extended to shove poison in various inputs)
22:55alyssa: so - very happy to see that work finished off
22:56alyssa: [for the following along at home, if a=False and b=Poison, the lhs is False but the rhs of the broken rule is Poison. freezing b fixes that.]