07:13jfalempe: Hi, can someone review https://patchwork.freedesktop.org/series/133963/ ? It has been tested on Tesla, Pascal and Turing.
12:41clarifiedonce: I set the lifetime ban for the abuse sluts and her animals like gloria and nigerian wank spammers, if any of them them join their criminal clan, will be lifetime banned from our alliance, without any negotiation , so i swallow nothing you got the facts wrong, i was not doing the swollowing there, you are banned to enter my territory, plain and simple the test period of abuse was 2.5 years
12:41clarifiedonce: in a tropical area, no person ever will visit that country again, due to such clans parasites there. You do not tell me what to do.
12:41clarifiedonce: my dad was the one putting million dollars to the business , and it is likely locked for some periods of time now.
12:49clarifiedonce: the decision is justified and placed very firmly against such people, cause the abuse in 2.5 years time i got was "impressive" hence the lifitime ban setting was evident.
12:52clarifiedonce: so we do not talk about mental issues, or some bored or motivated or unmotivated people typing or accidentally leaking some of the companies secrets, it was the most inconvenient abuse ever met to anyone, and a range of poisonous personalities earned a lifetime ban from me.
13:02clarifiedonce: I really hope that my actions are worth more in the moral world, and the dads million dollar possible loss can be overcome, but definitely without such people involved as to who made it possible in the first place with a yeah very horrific tyranny and very braindead one.
19:25gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1293293207194439700/9626xl.png?ex=6706d8a8&is=67058728&hm=8c4ac6ae3a7b74f170c5a371295380af45f1c5eebcc6095e1770b2162e20ff2a&
19:27blockofalumite[d]: :O is there an open issue for it ?
19:27gfxstrand[d]: IDK if there's an open issue or not, honestly.
19:28gfxstrand[d]: I just keep bitching about it and hoping that skeggsb9778[d] will take pity on me one day. 😅
19:28blockofalumite[d]: Is the issue within GSP firmware or the driver ?
19:29gfxstrand[d]: It's an issue with the driver getting the info out of the GSP
19:30gfxstrand[d]: I'm sure the GSP firmwares have support. I can't imagine the NVIDIA engineers being okay with not having that info for their development.
19:30gfxstrand[d]: But no one has figured out how to wire it up in nouveau
19:31blockofalumite[d]: Ah, so it's a task of reverse engineering what the API is in GSP ?
19:31gfxstrand[d]: Something like that.
19:31gfxstrand[d]: I'm not sure how much work is involved or where to start, though.
19:35airlied[d]: we have to bump to a new GSP revision
19:36gfxstrand[d]: 😢
19:36airlied[d]: also NVIDIA engineers have access to the gsp log decoder ring
19:36gfxstrand[d]: Yeah
19:36airlied[d]: so they didn't actually care about it initially, but they fixed up the API somewhere in 555 land
19:36gfxstrand[d]: Cool. More toys whenever we bring up Blackwell
19:39gfxstrand[d]: Which is looking like it'll drop in January if the rumors are to be believed.
19:40gfxstrand[d]: For now I'll just have to wait until this CTS run is done and stuff a Turing in my test box and run without GSP
19:57blockofalumite[d]: nouveau stuff always seems so cool but so intimidating
20:06notthatclippy[d]: There should be support for extracting gsp logs via debugfs now. Wr can decode that and give you the summary.
20:07notthatclippy[d]: Also, if you wanna run a hacked up kernel we can work something out for the short term.
20:08notthatclippy[d]: A lot of the data is there in 535 too, just a massive pain to get out and no point in doing that work if 570 has a nicer API for it
20:13airlied[d]: it's a pity the debug dumps weren't at least parseable without all the encoded strings, would have made it possible to at least pull out just the fault address 😛
20:26notthatclippy[d]: We could probably publish a small gsp_log.bin that just contains the few prints. Especially for 535 that'd be a one-off thing that could be built manually.
20:26airlied[d]: I think the problem was you need each string to work out where the next one was
20:27airlied[d]: so a reduced set would have to leave the format identifiers and strip out the string info and even that was messy
20:27notthatclippy[d]: Oh. Right. The format of this thing is different from the proprietary kernel side which is what I was thinking about.
20:28notthatclippy[d]: I think all args are 64bit so it would only need to know the arg count of every print
20:29notthatclippy[d]: I'll take a look. But from an effort standpoint, it might be easier to just hack up GSP protobuf decoding into the kernel and give those patches to Faith. She's probably the only one who'd ever use this anyway?
20:55notthatclippy[d]: Hang on a sec, we're overthinking this. The goal is to make development faster/easier and not necessarily give 100% accurate info. Kernel can just read the faulting data when it receives the event from GSP.
20:56notthatclippy[d]: There's a race condition in case multiple faults happen in succession, in which case you'll 99.9999% of the time get one that is accurate twice, and once in a blue moon you'll get an invalid one
20:57notthatclippy[d]: But that is absolutely fine for what Faith needs, no? Add a disclaimer about it and print it best effort and everyone is happy.
21:03djdeath3483[d]: You don't have the pagefault address on your kernel driver yet?
21:10airlied[d]: notthatclippy[d]: for replayable faults I thought that was okay, but for non-replayable I didn't think we had access to read it, unless we can directly get it from the gpu I suppose
21:16gfxstrand[d]: Of course validation dies on NVC597_DRAW_VERTEX_ARRAY. 🤦🏻♀️
21:16gfxstrand[d]: Why did I think this would be useful? 🤷🏻♀️
21:18gfxstrand[d]: Best part is that it only fails if I run multiple tests
21:19notthatclippy[d]: airlied[d]: I think both types should have their info in <https://github.com/NVIDIA/open-gpu-doc/blob/master/manuals/turing/tu104/dev_vm.ref.txt#L212-L279>
21:22notthatclippy[d]: You can even get access to both buffers and decode the full fault with no losses. The buffer format should be <https://github.com/NVIDIA/open-gpu-doc/blob/master/manuals/turing/tu104/dev_mmu_fault.ref.txt>
21:31gfxstrand[d]: I would love to be able to expose the device fault extension
21:33airlied[d]: well we should already be accessing that buffer in non-GSP mode, just whether we can find it in GSP mode since we won't set it up
21:33airlied[d]: I think skeggsb9778[d] looked at this recently
21:44mhenning[d]: notthatclippy[d]: uh, for what it's worth faith isn't the only person who ever does userspace development. I very much miss our pre-gsp kernel logging at times.
21:44skeggsb9778[d]: no, i'd never even considered trying to read the HW fault buffers when running on top of RM
21:46skeggsb9778[d]: i guess one could, though yeah, it'd be racy (and RM would have updated the GET pointer by the time we got the notification, though we could assume "the last one")
21:53skeggsb9778[d]: notthatclippy[d]: the faults in question won't be in those regs you linked to in dev_vm.ref either, most of the ones that'd be wanted appear in the non-replayable fault buffer (NV_VIRTUAL_FUNCTION_PRIV_MMU_FAULT_BUFFER())
22:10gfxstrand[d]: Nobody get too excited but I think I just implemented FSR
22:10gfxstrand[d]: Which means my XDC talk is already out of date. 😂
22:12Ermine: btw, will be XDC streamed online?
22:12gfxstrand[d]: Yup!
22:12Ermine: great
22:12mohamexiety[d]: yes should be on the YT page
22:13gfxstrand[d]: https://indico.freedesktop.org/event/6/page/29-attending-xdc-2024
22:13gfxstrand[d]: I'll be attending by stream this year
22:13gfxstrand[d]: And it's just YouTube so it works on every device you own
22:13gfxstrand[d]: Then there's a Matrix room
22:15Ermine: thank you!
22:20mohamexiety[d]: thankfully the schedule is pretty good for both NA and the euro/middle east timezones (didn't actually convert to local time until now), so should be watchable live for most
22:39gfxstrand[d]: gfxstrand[d]: Might have spoken too soon. 😅 Lots of tests passing but something is still failing validation
22:42esdrastarsis[d][d]: On the bright side, your XDC Talk is still up to date 🐸
22:46Ermine: Also, do you mean FidelityFX Super Resolution by FSR?
22:49gfxstrand[d]: VK_KHR_fragment_shading_rate
22:50Ermine: ah
23:05redsheep[d]: Oh was gonna say it sounds like you're talking about Radeon super resolution where the driver implements fsr1, fragment shading rate makes more sense
23:06redsheep[d]: And you can get fsr1 with gamescope
23:08redsheep[d]: I think most publications call it vrs, but maybe that's the d3d name
23:08AshiskumarNaik[m]: <AshiskumarNaik[m]> "Hi..." <- > <@ashiskumarnaik:matrix.org> Hi... (full message at <https://matrix.org/oftc/media/v1/media/download/AcRYAYXIdghAqv6nxLR96v3Dmg-YlOhvcLsgVoOpx7ywePf1mLc4KCcpVMKUZIFo75MaIr3XMnGQ6gwcJw-ZpfVCeScBvAHAAG1hdHJpeC5vcmcvUG1DdnVqY1REckpzd0ZuZmlNTFVWZEpY>)
23:11redsheep[d]: That matrix bridge is really awkward, I guess that's just what a self reply looks like
23:13redsheep[d]: You'll probably have better success if you join the discord or IRC, nobody outside matrix is seeing that message in plain text
23:17redsheep[d]: redsheep[d]: It's kind of unclear where that name came from actually, maybe from the nvidia vr stuff from like a decade ago?
23:17mohamexiety[d]: yeah the way it just.. gives up and yeets the message into a link is awkward
23:18mohamexiety[d]: redsheep[d]: variable rate shading, it makes sense given what it does I guess
23:19redsheep[d]: Right, I just can't find anything solid that ties the origin of the term to that, just looks like some of the earliest references
23:19gfxstrand[d]: redsheep[d]: Yeah, that's the D3D feature
23:20gfxstrand[d]: AshiskumarNaik[m]: That's not really a question. What do you want to know?
23:22gfxstrand[d]: Ugh... If I set the INDEX_TO_RATE tables with MSAA, the draw fails. No idea why.
23:23redsheep[d]: Does that only come up when trying to mix msaa and fragment shading rate? Is that even valid to do?
23:23redsheep[d]: I don't think I have ever seen a game with actual msaa and VRS implemented together
23:23gfxstrand[d]: Yes it does and yes it is
23:23redsheep[d]: Hmm actually I think forza might do it
23:27redsheep[d]: How is MSAA meant to interact with it? Does it shrink the little blocks that get shaded, or does it actually sample the entire block multiple times?
23:28gfxstrand[d]: Okay, I need to put this down and make supper
23:34redsheep[d]: Maybe I am missing a better doc, and I might be mixed up, but this reads to me like mixing the two just means doing fewer invocations per pixel, so like a lower msaa rate? https://docs.vulkan.org/spec/latest/chapters/primsrast.html#_extended_fragment_shading_rates
23:38redsheep[d]: I realize now that might be what you meant with the index to rate part, sorry none of this is overly easy to research
23:52gfxstrand[d]: I *think* FSR effectively overrides the sample rate so you end up shading multiple pixels and applying that to all those pixels' samples instead of shading once per pixel and applying that to all samples.
23:53gfxstrand[d]: NVIDIA hardware can also adjust the MSAA shading rate but I think that got yeeted from the Vulkan feature.
23:53gfxstrand[d]: So on NVIDIA with, say, 4x MSAA you can go from 2x2 coarse to 4x MSAA, all controlled by the shading rate.
23:55redsheep[d]: What is the table you were referring to? I am reading the headers now, do you just mean all of the different indices rates being set as being the table?
23:57redsheep[d]: Like a table with 16 elements for indices 0-15?
23:57gfxstrand[d]: Search for INDEX_TO_RATE
23:58redsheep[d]: Yeah I am looking at line 4409 of NVC597 since I remembered you mentioned that earlier
23:59gfxstrand[d]: That part I'm pretty sure is right
23:59gfxstrand[d]: But it's conflicting with some other state and IDK what