03:38 matt_schwartz[d]: hmm, this seems a bit spooky (trying to play clair: obscur on nvk):
03:38 matt_schwartz[d]: [ 557.660747] nouveau 0000:01:00.0: gsp: mmu fault queued
03:38 matt_schwartz[d]: [ 557.662305] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:40 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000003dde2e8000 fault_type:00000002
03:38 matt_schwartz[d]: [ 557.662309] nouveau 0000:01:00.0: fifo:d00000:0028:0028:[GameThread[25946]] errored - disabling channel
03:38 matt_schwartz[d]: [ 557.662314] nouveau 0000:01:00.0: GameThread[25946]: channel 40 killed!
03:39 chikuwad[d]: average nvk issue
03:40 matt_schwartz[d]: star citizen seems to work fine, somewhat surprisingly
03:42 chikuwad[d]: actually, no..
03:42 chikuwad[d]: that's a PTE fault
03:42 chikuwad[d]: most ones I've seen are PDE faults
03:44 matt_schwartz[d]: I’m on Blackwell if that matters
03:45 chikuwad[d]: that does make a difference, iirc on blackwell all PTEs are generic
03:45 chikuwad[d]: i.e. there's no more PTE types anymore
03:45 chikuwad[d]: hm
03:49 chikuwad[d]: ah yeah, PTE not found error
03:49 chikuwad[d]: funny
03:50 chikuwad[d]: iirc mohamexiety[d] ran into it on the CTS suite a while ago too
03:52 mhenning[d]: matt_schwartz[d]: are you on a recent mesa version? some blackwell fixes landed last week
03:54 matt_schwartz[d]: hmm, looks like its a couple weeks old. i'll rebuild that now.
03:54 matt_schwartz[d]: was using a distro-packaged mesa-git snapshot
04:05 matt_schwartz[d]: seems to work 🥳
04:20 mhenning[d]: fwiw, the same fixes should also be in 25.2.2, but that was just released a few hours ago so I imagine not everyone has updated yet
06:12 gfxstrand[d]: matt_schwartz[d]: Looks like you hit the bug I fixed last week. Gotta keep those drivers updated!
06:18 gfxstrand[d]: But yeah, I wish we'd caught that one during Blackwell enabling but I was too busy just trying to get everything landed before the branch point to actually test any games. So it came in as a bug fix. <a:shrug_anim:1096500513106841673>
06:18 gfxstrand[d]: Glad it's working for you now! 💜
06:24 matt_schwartz[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1413047045438050415/Screencast_20250903_231108.mp4?ex=68ba821c&is=68b9309c&hm=80027ab2e0ebc011c33ae1a694d9de32762b8b9b5fb846fc0eda30c4f6658485&
06:24 matt_schwartz[d]: (warning: bit of flashing) ran into a trippy graphical issue in star citizen associated with one specific animation, grabbed some renderdoc captures of it and will put them in a mesa issue tomorrow
06:27 matt_schwartz[d]: maybe this could be advertised as a feature... wormholes are rendered so realistically they even eat your graphics
07:25 asdqueerfromeu[d]: karolherbst[d]: You don't even need OpenCL to make a raytracer though: https://www.youtube.com/watch?v=N8elxpSu9pw
08:34 chikuwad[d]: https://www.youtube.com/watch?v=rY413t5fArw
08:52 karolherbst[d]: yeah.. simple ray tracers aren't hard, but it gets complicated real quick if you want to support all the corner cases
09:15 chikuwad[d]: progress!
09:16 chikuwad[d]: assert no longer pops
09:16 chikuwad[d]: CTS just segfaults :D
09:16 esdrastarsis[d]: Finally, segmentation fault! 🎉
09:21 asdqueerfromeu[d]: esdrastarsis[d]: https://youtu.be/s7wLYzRJt3s?t=68
09:23 HdkR: It's a glorious day when debugging a seg fault.
09:41 chikuwad[d]: hm wtf
09:42 chikuwad[d]: why is `dEQP-VK.glsl.atomic_operations.add_f16vec4_compute_shared` panicking with `Invalid uint atomic type: 16 bits`
09:43 chikuwad[d]: I might've messed up somewhere :doomthink:
09:46 chikuwad[d]: oh I see
09:57 chikuwad[d]: hmmm
10:01 chikuwad[d]: I'm just confused where uint16 atomic type comes into the mixe here
14:32 phomes_[d]: !35507 should be ready to merge
15:01 snowycoder[d]: karolherbst[d]: I might have a stupid idea to make this a bit faster.
15:01 snowycoder[d]: If we delay the register read in the second block, we could lower the instruction delay in the hot loop.
15:03 snowycoder[d]: How can we do this automagically? No idea.
15:03 snowycoder[d]: But it could shave off some cycles in a lot of loop-heavy shaders
15:04 snowycoder[d]: I'm working on the cross-block patch.
15:04 snowycoder[d]: Steam servers crashed and I'm bored.
15:55 mhenning[d]: gfxstrand[d]: want to take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37153 ? I think it's an important fix.
15:55 mhenning[d]: also cc marysaka[d] since you touched cond rendering most recently
15:56 marysaka[d]: oh right I started looking at it yesterday a bit and forgot to continue
15:56 marysaka[d]: I got lost checking that the size of a component was truly 1 byte but seems like it 🙃
15:57 marysaka[d]: One thing that we really should figure out someday is how is NV blobs implementing it because they really don't use that method at least on Turing
15:57 marysaka[d]: might have to do with the whole MME shadow memory and the control related to it
15:59 mhenning[d]: They do have the guarantee that pages are zero-initialized from the kernel (and we don't)
16:01 marysaka[d]: that would explain things but what I mean is last time I checked, nothing used SET_RENDER_ENABLE_A for cond rendering with blobs
16:01 marysaka[d]: maybe envyhooks was missing some pushbufs back then I should recheck...
16:01 mhenning[d]: oh, yeah that's interesting
16:03 mhenning[d]: although I am a bit surprised that they wouldn't use RENDER_ENABLE for that purpose
16:04 marysaka[d]: yeah it might be some dumping issue anyway
16:05 marysaka[d]: also one thing about that MR we could save one dword by using CONST_B instead of CONST_A mhenning[d]
16:05 marysaka[d]: As SET_REMAP_COMPONENTS is right after SET_REMAP_CONST_B
16:06 marysaka[d]: looking good otherwise
16:09 gfxstrand[d]: mhenning[d]: So, with all that, do we still need to force conditional render to GART?
16:10 gfxstrand[d]: Or was GART just giving us extra zeros
16:10 mhenning[d]: I don't know. I don't understand why it was in gart in the first place.
16:11 gfxstrand[d]: It was GART because that was the hack Dave came up with to get it working.
16:16 marysaka[d]: marysaka[d]: I think I have some patches lying around for that actually, I will just rebase and open an MR probably tomorrow
19:24 airlied[d]: I actually forgot I wrote that code
19:26 gfxstrand[d]: I'm glad Mel wrote good tests and actually figured out how it worked.
19:26 gfxstrand[d]: "two 64-bit values, 16 bytes apart" was not the behavior I was expecting.
19:26 gfxstrand[d]: I guess it makes sense if it was optimized to take the results of GL queries or something. But still...
19:27 mhenning[d]: Yeah, the semantics are kind of bizarre
19:28 triang3l[d]: gfxstrand[d]: Are they per-depth-unit-something like on AMD?
19:29 triang3l[d]: suddenly got the need to rewrite all the shaders working with them when I noticed that sample counts from each render backend had a stride of 16 bytes rather than 8 (I guess it's so that you can sample the starting values to +0 and the ending values to +8)
19:30 triang3l[d]: (on AMD)
20:06 mhenning[d]: gfxstrand[d]: Nope, looks like we can move it out of gart https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37187
20:13 airlied[d]: mhenning[d]: the one where you memset in the begin command seems wrong, vulkan command recording shouldn't have side effects
20:14 airlied[d]: it at least needs a comment saying why having a side effect in command recording is okay
20:37 kicchou: hello powers that be, i'm trying to submit a simple kernel patch to the nouveau mailing list but i haven't heard a response in about 10 days. i think it's because i forgot to cc the relevant maintainers; who should I cc for such a patch?
20:37 kicchou: i'm working on the nouveau kernel module
20:39 chikuwad[d]: that'd be airlied
20:40 chikuwad[d]: the kernel MAINTAINERS file also contains info on where patches should go :)
20:42 kicchou: thanks! so i would cc airlie, paul, and krummrich?
20:46 chikuwad[d]: actually, hang on
20:46 chikuwad[d]: iirc I'd submitted my patch to dri-devel@lists.freedesktop.org
20:47 chikuwad[d]: yeah, that was it
20:49 kicchou: understood; any specific people or just raw mailing list energy?
20:51 chikuwad[d]: just the ml was enough for me
20:51 chikuwad[d]: that and notifying dave
20:51 chikuwad[d]: right in this channel
20:52 kicchou: epic, thanks for the help!
20:59 mhenning[d]: kicchou: also take a look and see if your message is in the public mailing list archive. if it's missing it might have been automatically marked as spam and karol can un-mark it as spam for you
21:01 mhenning[d]: airlied[d]: by that measure, allocating memory is also a side effect and we do that the line before. I'm not really sure what to say about it that the comment doesn't already say
21:02 kicchou: i think my submission may have been marked as spam; i submitted from lxrmrz732@rocketmail.com on 24 aug and i don't see it in the archives
21:03 mhenning[d]: karolherbst[d]: want to take a look at the spam queue? ^
21:04 karolherbst[d]: not at home atm
21:04 mhenning[d]: ah, okay. does anyone else have access?
21:04 karolherbst[d]: probably
21:05 karolherbst[d]: I'll be home in like 30 minutes tho
21:06 gfxstrand[d]: mhenning[d]: Okay. I've got to dash off to a hair appointment. I'll look either tonight or tomorrow. Commit messages look good, though.
21:16 airlied[d]: mhenning[d]: oh if we allocate it out of cmdbuf attached memory it should be fine, I thought it was an external memory alloc
21:17 airlied[d]: But I still feel it is broken if you resubmit a recorded cmd buffer
21:18 mhenning[d]: oh yeah, we're just initializing the cmdbuf attached memory we alloc the previous line
21:18 airlied[d]: Since nothing will memset it on resubmit unless we are.okay with prev values
21:19 mhenning[d]: we're okay with previous values - that's what the "invariant" comment is trying to get at
21:19 mhenning[d]: the parts that need to be zero are never written to for the lifetime of the buffer
21:19 mhenning[d]: that is, between that initialization and dealloc
21:36 gfxstrand[d]: airlied[d]: If the same command buffer gets submitted multiple times, each time will update the same 8 bytes and leave the zeros alone.
21:49 karolherbst[d]: kicchou: they bounced because you weren't subscribed to the nouveau ML