00:00fdobridge_: <gfxstrand> The cases that are failing are +/-0 and +/-inf
00:00fdobridge_: <karolherbst🐧🦀> I guess you've read https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions-rcp-approx-ftz-f64 ?
00:01fdobridge_: <gfxstrand> Yup. Staring it at it now.
00:01fdobridge_: <karolherbst🐧🦀> feels like a check against subnormals
00:01fdobridge_: <karolherbst🐧🦀> let's see what value that actuall is
00:01fdobridge_: <gfxstrand> There's a table right there in the docs that says it's well-behaved for subnormals and +/-inf
00:01fdobridge_: <gfxstrand> And unless I'm going crazy, it's not.
00:02fdobridge_: <gfxstrand> 😩
00:03fdobridge_: <gfxstrand> I'm at a loss as to where a NaN would come from in that sequence if not from the `mufu.rcp64h`.
00:04fdobridge_: <karolherbst🐧🦀> mhh
00:04fdobridge_: <karolherbst🐧🦀> the constant is `0xfe400000`
00:04fdobridge_: <karolherbst🐧🦀> and...
00:04fdobridge_: <karolherbst🐧🦀> it's checking the `|upper bits + 0x300402|`
00:05fdobridge_: <karolherbst🐧🦀> unless `R5` is written do for "reasons"
00:05fdobridge_: <karolherbst🐧🦀> well..
00:05fdobridge_: <karolherbst🐧🦀> shouldn't matter...
00:06fdobridge_: <gfxstrand> Hrm...
00:06fdobridge_: <gfxstrand> That's a thought, actually.
00:06fdobridge_: <gfxstrand> Maybe it does take a vec2
00:06fdobridge_: <karolherbst🐧🦀> treat is as fp64 for now and see if it changes anything
00:06fdobridge_: <karolherbst🐧🦀> it's weird tho
00:06fdobridge_: <gfxstrand> it's got to detect nans somehow
00:06fdobridge_: <karolherbst🐧🦀> ohh wait...
00:06fdobridge_: <karolherbst🐧🦀> mhhh
00:06fdobridge_: <karolherbst🐧🦀> but I have nvidia print `MUFU.RCP64H R7, R5 ;`
00:06fdobridge_: <karolherbst🐧🦀> and it's 5 and 7 in the encoding
00:07fdobridge_: <karolherbst🐧🦀> though the hardware silently aligns 🥲
00:07fdobridge_: <gfxstrand> 😢
00:07fdobridge_: <karolherbst🐧🦀> I think...
00:07fdobridge_: <karolherbst🐧🦀> yeah soo nvidia writes to R6 in the very next instruction
00:07fdobridge_: <karolherbst🐧🦀> mhhhh
00:08fdobridge_: <karolherbst🐧🦀> better safe than sorry I guess
00:11fdobridge_: <gfxstrand> Well, yeah. That's because the PTX thing works on 64 bits but `mufu` only works on 32 bits and they have to write zeros to the low bits to satisfy the PTX semantics.
00:12fdobridge_: <karolherbst🐧🦀> ahh no, that's on the real rcp
00:12fdobridge_: <gfxstrand> I think I just need to fuzz this monster and see what I can get out of it
00:13fdobridge_: <karolherbst🐧🦀> yeah
00:13fdobridge_: <karolherbst🐧🦀> sounds like a good idea
00:14fdobridge_: <karolherbst🐧🦀> mhh.. btw `MUFU.op.F16` exists since turing
00:14fdobridge_: <gfxstrand> Nice
00:14fdobridge_: <gfxstrand> Yeah, they added lots of F16 on Turing
00:15fdobridge_: <gfxstrand> Given what I'm seeing, I think the lines in the table about inf/0 handling are just lies.
00:15fdobridge_: <airlied> yeah that one is https://gitlab.freedesktop.org/drm/nouveau/-/issues/280
00:15fdobridge_: <karolherbst🐧🦀> so input and output dernorms are flushed to sign preserving 0.0
00:15fdobridge_: <airlied> no real ideas yet
00:15fdobridge_: <airlied> seems to be some sort of eviction race maybe
00:15fdobridge_: <karolherbst🐧🦀> (except for `.TANH`)
00:16fdobridge_: <karolherbst🐧🦀> also F16 is not flushed
00:16fdobridge_: <gfxstrand> Fortunately, all we really need out of the MuFu is an approximation. If I can do a couple comparisons and a SEL to first clamp the input to something that works, that's probably good enough.
00:16fdobridge_: <gfxstrand> newton will take care of the rest
00:17fdobridge_: <karolherbst🐧🦀> ohhh the FP16 MUFU calculates internally as fp32 and then truncates to fp16, which is different than wrapping with `F2F`
00:17fdobridge_: <karolherbst🐧🦀> but none of this should matter for the issue you are seeing
00:18fdobridge_: <karolherbst🐧🦀> possibly
00:19fdobridge_: <gfxstrand> What really worries me is that the Mesa lowering is also broken and that does `f2f64(frcp(f2f32(x)))`
00:21fdobridge_: <karolherbst🐧🦀> yeah... could be some weird corner case on the hardware
00:21fdobridge_: <karolherbst🐧🦀> or some weird bit somewhere we have to flip
00:21fdobridge_: <gfxstrand> Yeah, if normal frcp is broken, that's worrying.
00:22fdobridge_: <karolherbst🐧🦀> actually...
00:22fdobridge_: <karolherbst🐧🦀> let's see what they do for fp32 rcp
00:22Lyude: karolherbst: I -think- this should cleanly fix it https://gitlab.freedesktop.org/lyudess/linux/-/commits/nv-validate-modes-in-outp-check
00:22fdobridge_: <gfxstrand> Like, it being a bit imprecise is annoying. Throwing random NaNs is bad.
00:22fdobridge_: <karolherbst🐧🦀> pain
00:23fdobridge_: <karolherbst🐧🦀> @gfxstrand fp32 CL C `1/a`: https://gist.github.com/karolherbst/77aa676d45eadcdcb6222935799404c0
00:23fdobridge_: <karolherbst🐧🦀> wondering if that's because of CL/PTX or because of hardware
00:23fdobridge_: <karolherbst🐧🦀> it's `rcp.approx.f32` in PTX
00:24fdobridge_: <karolherbst🐧🦀> `rcp.approx.f32 implements a fast approximation to reciprocal. The maximum absolute error is 2-23.0 over the range 1.0-2.0.`
00:25fdobridge_: <karolherbst🐧🦀> yo... precise rcp is just pure madness
00:26fdobridge_: <karolherbst🐧🦀> actual rcp: 3
00:26fdobridge_: <karolherbst🐧🦀> https://gist.github.com/karolherbst/a0e495f5b443ff3e9f29555ba7b82860
00:27karolherbst: Lyude: cool, will try it tomorrow or so
00:28Lyude: sgtm. hopefully that should work since the reality is on most modern nv hardware connectors are more or less hardcoded to an encoder
00:28karolherbst: yeah...
07:01airlied: Lyude: just fyi that branch seems to work on my ga107 laptop panel
07:32airlied: actually scrap that, something else gone wrong
07:36airlied: okay seems to work fine with gsp enabled
07:44airlied: but then a bunch of memory corruptions
11:50karolherbst: Lyude: okay, with your patch `xrandr` properly returns "xrandr: Configure crtc 0 failed" on those doublescan modes
11:51karolherbst: the reason modesetting fails is that nouveau thinks scrambling is required and other nonsense
11:51karolherbst: "DRM: [DRM/00000002:kmsOutp] [HDMI head:0 enable:1 max_ac_packet:6 rekey:56 khz:148500 scdc:1 scdc_scrambling:1 scdc_low_rates:0] (ret:-22)"
11:52karolherbst: and if not, nouveau reduces the max clock supported on HDMI e.g.
11:52karolherbst: anyway
11:52karolherbst: your patch helps
11:53karolherbst: it's still incredible how broken those modes are
11:54karolherbst: 320x180@59.84
11:54karolherbst: [HDMI head:0 enable:1 max_ac_packet:6 rekey:56 khz:148500 scdc:1 scdc_scrambling:1 scdc_low_rates:0] (ret:-22)
11:57karolherbst: and how drm_hdmi_info just has scdc enabled...
12:00karolherbst: ehh wait..
12:00karolherbst: that's the display side
12:00karolherbst: oops
12:05karolherbst: mhh
12:05karolherbst: we also have a min_clock of 25000 and one reason why low resolution modes fail...
12:05karolherbst: pain
13:27pavlo: hello
13:28pavlo: I want to help develop a driver. I'm new to this topic. What should I be familiar with and what programming language should I know?
13:33DodoGTA: pavlo: What driver specifically?
13:34pavlo: nvc0
13:34pavlo: or тмл
13:34pavlo: or nvk*
13:35DodoGTA: pavlo: NVK is the more active one these days (you probably need knowledge of C (Rust for the compiler part) and Vulkan for that)
13:38pavlo: thank you
13:42pavlo: There are still questions about PowerManagement for video cards NV130-140. What is currently preventing the development of this driver function (can I help)? Does everything now depend only on NVIDIA itself?
13:44pavlo: (Is it not at all possible to write code without a signed nvidia firmware?)
13:45DodoGTA: pavlo: Without the signed firmware some things aren't available (like fan control or memory reclocking)
13:45DodoGTA: karolherbst knows more about this
13:48karolherbst: pavlo: yeah.. nothing we can do about it
13:48karolherbst: on maxwell2 fan control is locked behind signed firmware
13:48karolherbst: on pascal it's also voltage regulation
14:18fdobridge_: <!DodoNVK (she) 🇱🇹> I wonder why these lockups happen so often now: `Dec 12 16:06:36 RenoirBeast kernel: watchdog: Watchdog detected hard LOCKUP on cpu 3`
14:25fdobridge_: <karolherbst🐧🦀> phase of the moon
14:26fdobridge_: <karolherbst🐧🦀> it's new moon today
14:26fdobridge_: <karolherbst🐧🦀> so that figures
14:26fdobridge_: <karolherbst🐧🦀> 😄
14:27fdobridge_: <!DodoNVK (she) 🇱🇹> I've had this issue at least 3 times when playing NFS Most Wanted 2012
14:28fdobridge_: <!DodoNVK (she) 🇱🇹> Also there's a NAK regression in a D3D9 game :cursedgears:
14:29fdobridge_: <karolherbst🐧🦀> sure, but only today or like.. the last couple of days? 😄
14:30fdobridge_: <!DodoNVK (she) 🇱🇹> Complete system hangs are definitely a bigger issue but I'm trying to guess what commit caused that regrssion
14:44fdobridge_: <!DodoNVK (she) 🇱🇹> I reverted two commits and the game works again :ferris:
14:49fdobridge_: <!DodoNVK (she) 🇱🇹> Commit 3955e596df06f4f1b904d932b61520154f6c5389 is the problematic one
14:49fdobridge_: <!DodoNVK (she) 🇱🇹> Here's the errors it causes
14:49fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1184144975060008960/message.txt?ex=658ae7f2&is=657872f2&hm=07cdc9c510400be884305ad871a23cb4f663999af21726ab59868a87a4b1196a&
14:58fdobridge_: <karolherbst🐧🦀> what tree is that from?
14:59fdobridge_: <karolherbst🐧🦀> ohh mesa...
14:59fdobridge_: <!DodoNVK (she) 🇱🇹> mesa/mesa
14:59fdobridge_: <karolherbst🐧🦀> mhhhhhhhhhhhhhhhhhh
14:59fdobridge_: <karolherbst🐧🦀> guess the encoding is wrong then 🙂
14:59fdobridge_: <karolherbst🐧🦀> @gfxstrand ^^
15:38fdobridge_: <gfxstrand> Funky...
15:40fdobridge_: <gfxstrand> Does that repro with the GTA3 trace?
15:41fdobridge_: <!DodoNVK (she) 🇱🇹> That's a D3D8 game (I don't think DXVK uses fmulz for that D3D version)
15:43fdobridge_: <karolherbst🐧🦀> @gfxstrand the issue could be the hardware not liking both flags to be set
15:43fdobridge_: <karolherbst🐧🦀> should be quick to verify
15:46fdobridge_: <gfxstrand> Try nak/fmulz-fix in my tree
15:46fdobridge_: <gfxstrand> It's just one patch. You can cherry-pick it into another tree if you need to.
15:48fdobridge_: <!DodoNVK (she) 🇱🇹> Compiling now
15:50fdobridge_: <!DodoNVK (she) 🇱🇹> I still get the same issue with your patch 🤔
15:51fdobridge_: <gfxstrand> 😢
15:51fdobridge_: <gfxstrand> Can you take a trace?
15:51fdobridge_: <!DodoNVK (she) 🇱🇹> RenderDoc one?
15:52fdobridge_: <!DodoNVK (she) 🇱🇹> I can only do it with NAK disabled I think
15:52fdobridge_: <karolherbst🐧🦀> pain
15:57fdobridge_: <!DodoNVK (she) 🇱🇹> The trace does crash the driver with NAK as expected 🐸
15:57fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1184162212395356260/Screenshot_20231212_175717.png?ex=658af800&is=65788300&hm=2c30a2393998b1d21568a47fe92f473623d060efb4a0dc28047edbf830efb50d&
15:59fdobridge_: <!DodoNVK (she) 🇱🇹> Is it possible to work with this trace?
16:06fdobridge_: <!DodoNVK (she) 🇱🇹> I guess I should make a shader assembly dump instead then :ferris:
16:13Ilgaz: Don't ban me, my distribution told me to post my weird nouveau/intel issue to your gitlab :-) https://gitlab.freedesktop.org/drm/nouveau/-/issues/295
16:17karolherbst: why should we ban you?
16:19DodoGTA: karolherbst: Maybe the person is thinking that this channel is as harsh as the RenderDoc Discord?
16:23fdobridge_: <!DodoNVK (she) 🇱🇹> Is `ffma.sat.dnz` a valid instruction on SM75? :opencl:
16:27fdobridge_: <!DodoNVK (she) 🇱🇹> For now enjoy this assembly dump :nouveau:
16:27fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1184169734296584282/nfsmw_nvk_nakfmulzencoding.log?ex=658aff01&is=65788a01&hm=d4a32f35ce5ede34b521409df8865e613e84da8995dc9e54b62db3bb2c0a0420&
16:27fdobridge_: <karolherbst🐧🦀> huh...
16:27fdobridge_: <karolherbst🐧🦀> good question
16:54fdobridge_: <dadschoorse> why would it not be valid?
16:55fdobridge_: <karolherbst🐧🦀> because hardware
17:21fdobridge_: <gfxstrand> @mhenning If you wanted to push things along a bit, a review on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26526 would be appreciated.
17:22fdobridge_: <gfxstrand> Oh, that's a good question!
17:22fdobridge_: <gfxstrand> Let me throw you another patch
17:23fdobridge_: <gfxstrand> Check the branch again. Your `.sat` theory sounds really juicy
17:27fdobridge_: <mhenning> Sure, I'll take a look in a few hours.
17:33fdobridge_: <!DodoNVK (she) 🇱🇹> Still broken 🤔
17:38fdobridge_: <gfxstrand> Can you upload that trace somewhere? IDK what the discord upload limit is.
17:41fdobridge_: <dadschoorse> you have a typo in your branch, you the second comparison should be != nir_op_fmulz
17:41fdobridge_: <!DodoNVK (she) 🇱🇹> https://drive.google.com/file/d/1lnc_6eYRUKqaC0f_zpu_L7UPNw9sV8_m/view
17:45fdobridge_: <!DodoNVK (she) 🇱🇹> The driver still explodes with that mistake fixed
18:41fdobridge_: <gfxstrand> @asdqueerfromeu https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26654
18:42fdobridge_: <gfxstrand> First patch was right in spirit, I just mistyped it. The trace works for me with that MR.
18:43pavlo: @karolherbst and video codecs also depend on the signed firmware.. right?
18:44fdobridge_: <gfxstrand> FTR: Sat isn't a problem. It was FTZ+DNZ blowing things up.
18:53fdobridge_: <!DodoNVK (she) 🇱🇹> This fixed my issue
19:00fdobridge_: <!DodoNVK (she) 🇱🇹> And my laptop froze _again_
19:00fdobridge_: <karolherbst🐧🦀> @gfxstrand btw, anything you want to see solved for the volta MR or should we just merge it?
19:13fdobridge_: <gfxstrand> Let me give it one final look
19:22fdobridge_: <!DodoNVK (she) 🇱🇹> Unigine Heaven somehow survived :triangle_nvk:
19:22fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1184213663758946304/Screenshot_20231212_212136.png?ex=658b27eb&is=6578b2eb&hm=ce29550a8bf83ea5d896608599a51264e64fb627fe35e4965c11533dddc4db14&
19:25fdobridge_: <karolherbst🐧🦀> kinda slow 😢
19:25fdobridge_: <karolherbst🐧🦀> ohh wait, the GPU also kinda is
19:25fdobridge_: <karolherbst🐧🦀> nvm then
19:39fdobridge_: <!DodoNVK (she) 🇱🇹> I'll try the proprietary driver too
19:52Tom^: are you guys on an matrix channel too?
19:54Lyude: airlied: oh hey I was wondering if that might happen
19:54Lyude: i was thinking last night and realized that the issues i'm seeing now might not actually be link training at this point, although I'm not totally sure
19:54Lyude: Tom^: I don't think so but I'd love for us to have one, I just am not sure where to find a host
19:55Tom^: Lyude: what is this fdobridge then? :o
19:55soreau: Tom^: There's a discord bridge though
19:55Tom^: oh okay
19:55soreau: that is the fdobridge
20:00fdobridge_: <!DodoNVK (she) 🇱🇹> Here's the proprietary driver for reference
20:00fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1184223289040703549/Screenshot_20231212_215856.png?ex=658b30e1&is=6578bbe1&hm=d311d90362d72b5c30c2a13b8f54b53f2ebbd467e0126eb88e020e8f42e4f17b&
20:01karolherbst: Lyude: my only concern about matrix is the instability (bricked rooms) and poor moderation tools or ban enforcement
20:01Lyude: ah right, I always forget about that :(
20:01karolherbst: yeah...
20:01karolherbst: I know that gnome uses matrix though.. might make sense to talk with Carlos about the experience there
20:02karolherbst: but I had a chat with some grapheneOS folks on fedi and they were like.. uhm... disappointed
20:02karolherbst: Lyude: fyi: https://grapheneos.social/@GrapheneOS/111462435958479656
20:02karolherbst: so yeah.. uhh
20:02karolherbst: pain
20:02Lyude: sheesh
20:03Lyude: stuck again in the infinite loop of "well maybe someone should make a new protocol"
20:03Lyude: and then no one does because then we would have another protocol
20:03karolherbst: yeah...
20:03karolherbst: matrix went too far tbh
20:03Lyude: matrix seems like a lot of people really in love with the bad parts of IRC :(
20:03karolherbst: it's not surprising that a lot of FOSS projects move to discord, because at least it has strong moderation tools
20:03karolherbst: which matrix is just a dumpsterfire with
20:04karolherbst: good luck banning people who just create a new acc
20:04karolherbst: on matrix.org
20:04karolherbst: and we _do_ have those issues
20:04karolherbst: and if matrix makes it worse, then uhmm... yeah
20:04karolherbst: *sigh*
20:06karolherbst: anyway.. I kinda played around with evertyhing and the discord server just sticked because that's the least I hated
20:06Lyude: airlied: btw, could you get me a photo of the corruption issues you're seeing?
20:06karolherbst: *hated the least
20:06Lyude: curious if it's anything like the machine I've got here where it seems like only 1/4 of the screen is lit up, and it's corrupted looking
20:06airlied: Lyude: oh by memory corruption I mean wierd oops in slab code
20:06Lyude: ooooooh! so the display actually just turns on then?
20:06airlied: yes
20:06Lyude: oh that's awesome
20:08airlied: I'll see if I can track down the memory stuff once I get to sit down
20:09fdobridge_: <gfxstrand> Nice! I mean those FPS aren't amazing but seeing it render correctly is kinda nice.
20:17fdobridge_: <gfxstrand> Also, at Intel I would have killed to get 52 FPS *without* MSAA enabled. 😭
20:23Lyude: I will try to finalize some of these patches a bit and send them onto the ML for now, since I've got some other stuff I need to look at (and I need to start experimenting with rust/kernel stuff)
20:29fdobridge_: <esdrastarsis> @karolherbst https://github.com/spacebarchat/spacebarchat
20:30fdobridge_: <esdrastarsis> I think this is an alternative to matrix
20:31fdobridge_: <karolherbst🐧🦀> it's still using the official servers as the self written one are kinda.. not really there yet
20:32fdobridge_: <karolherbst🐧🦀> ohh it's literal Fosscord
20:34fdobridge_: <Sid> it is fosscord, yes, they rebranded
20:38RedSheep: How does one get access to the discord server that connects here? I've actually been lurking around here and the gitlab hacking around with nvk almost since it was first announced and I would much rather be using discord
20:42DodoGTA: RedSheep: https://discord.gg/aAGVC4SUDU
20:43fdobridge_: <redsheep> Awesome, thank you. Much better.
20:45pavlo: is this link only for fosscord? Because it says that the link is not valid
20:48fdobridge_: <esdrastarsis> Pavlo, we use the official discord, you can use my link: https://discord.com/invite/tRtWfQgY
20:50fdobridge_: <Sid> "official"
21:19fdobridge_: <karolherbst🐧🦀> I just deny having any involvement
21:40fdobridge_: <enigma9o7> Is this bridge one way?
21:40fdobridge_: <gfxstrand> It's two-way when it works
21:40fdobridge_: <enigma9o7> Now I understand why I don't get many replies... it isnt relaying my messages to this bridge 🙂
21:51Tom^: i recall back in the day there was an way to build nouveau out of tree, but the skeggsb repo https://nouveau.freedesktop.org/InstallNouveau.html hinted at here seems to be out of date
21:51karolherbst: yeah...
21:51karolherbst: it was never really supported, and also kinda a mess
21:52karolherbst: should probabaly remove that section
21:52Tom^: gotta figure out some git fu and make a patchset i can apply ontop of my kernel then heh
21:53karolherbst: yeah...
21:53karolherbst: in theory if you ahve the same source you can only build one module and all that
21:53karolherbst: but it's all very fragile
21:53karolherbst: and these days machines are fast enough so that compiling your kernel doesn't even take too long
21:53karolherbst: it takes like 10 minutes for me
21:54karolherbst: and that's with the distros config
21:54Tom^: well im applying lto and stuff on this poor laptop it takes its time
21:54karolherbst: I see
21:58Tom^: those earlier unigine fps screenshot have me nostalgia tripping, so yeah i gotta get in on the action again haha, il post some pics later on a 3060 dgpu if i get it running heh
21:59karolherbst: cool
21:59karolherbst: hopefully with GSP running
21:59Tom^: well yeah
21:59fdobridge_: <redsheep> That way we won't get another depressing phoronix article...
21:59Tom^: :D yeah saw that one
22:00karolherbst: still waiting on a proper benchmark from Michael
22:01fdobridge_: <redsheep> I can't tell whether I'm GPU bound or not but Talos principle running at 40% the speed of the blob seems pretty good
22:02karolherbst: talos principle at least on gl and the gl driver was bound by pcie
22:02karolherbst: it has weird patterns of repeated data uploads
22:03karolherbst: not sure if it's the case for you
22:03fdobridge_: <redsheep> I'm pretty sure they removed that renderer. I tried for like an hour to use it for comparison the other day
22:03karolherbst: I'm also wondering if GSP also controls the PCIe lane config
22:04Tom^: is the nouveau-next branch the one i should use
22:04karolherbst: mhhh
22:04fdobridge_: <gfxstrand> You could always try https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26622
22:04Tom^: roger, building now.
22:04karolherbst: in theory, however
22:04karolherbst: just use drm-next
22:04fdobridge_: <gfxstrand> That should improve PCIe bandwidth
22:04karolherbst: ehh
22:04karolherbst: drm-misc
22:04karolherbst: Tom^: https://cgit.freedesktop.org/drm/drm-misc/
22:05fdobridge_: <gfxstrand> Oh, there will be plenty more depressing Phoronix articles to go. 😅
22:05karolherbst: preferably you want to use drm-misc-fixes
22:05Tom^: the more experimental the better karolherbst :D
22:05karolherbst: yeah.. or upstream linux
22:05fdobridge_: <gfxstrand> TBH, having a really bad Phoronix article only makes the next benchmark sweep look better.
22:05karolherbst: need at least 6.6 for GSP
22:05Lyude: airlied: by the way meeting is going on
22:05Lyude: danilo: ^
22:06Tom^: karolherbst: not 6.7?
22:06fdobridge_: <esdrastarsis> 6.6 for uAPI and 6.7 for GSP
22:07karolherbst: Tom^: mhhh.. maybe 6.7...
22:09fdobridge_: <redsheep> If you're on arch I've had an easy time just letting the linux-git aur do all the work to get the latest release candidate
22:09fdobridge_: <redsheep> And if you're not a derp and use the patch list right it can do local patches
22:09Tom^: yeah im on arch, i grabbed that aur package changed source to drm-misc and branch drm-misc-fixes
22:23diagonal1x: I just want to program next year the needed extensions and then we dive into the core problems in my own life, I hope to get lots of help from various sources to deal with terrorists to treat them according to their very ill actions. It's so far that I have all the needed modules, it's yeah backed up by science anyways mit opencourseware proves the same things, I took a look at those educational academic lectures, very neat stuff. It takes me x month
22:23diagonal1x: to release a compiler extension out of those modules, and then I react with my people to the scum that has been harassing me.
22:35Tom^: wait didnt i play a little bit of divinity original sin with you karolherbst or was that someone else hrm
22:35karolherbst: yeah, that was with me
22:35karolherbst: :D
22:35Tom^: oh damn pepperidge farm remembers
22:36karolherbst: it was literally 100 years ago
22:36Tom^: yeah xD
22:38fdobridge_: <gfxstrand> @karolherbst does the HW expect the offset in `ldc` to be uniform?
22:38fdobridge_: <gfxstrand> It's a GPR so I would hope not
22:41fdobridge_: <karolherbst🐧🦀> it doesn't, but it can be slower than global memory if it's different in each thread in a wave
22:41fdobridge_: <karolherbst🐧🦀> ehh
22:41fdobridge_: <karolherbst🐧🦀> warp
22:42fdobridge_: <karolherbst🐧🦀> so yes, if you care about performance you want it to be uniform
22:42fdobridge_: <enigma9o7> `Device-1: NVIDIA GT216M [GeForce GT 330M] driver: nouveau v: kernel`
22:42fdobridge_: <enigma9o7> **[117124.523533] nouveau 0000:01:00.0 DRM: GPU lockup - switching to software fbcon**
22:43fdobridge_: <enigma9o7> How do I tell what version of nouveau I'm using? How would I test a new version?
22:43fdobridge_: <karolherbst🐧🦀> kernel version
22:43fdobridge_: <enigma9o7> I get a lockup every day or two when using nouveau.
22:44fdobridge_: <enigma9o7> So the only way is to build a new kernel (if my distro doesnt offer something newer)?
22:44fdobridge_: <enigma9o7> Is there a changelog I can look at to see if it looks like anything was done that might affect me?
22:45fdobridge_: <enigma9o7> I read an article that said a lot of changes/fixes for nouveau went into kernel 6.2
22:45fdobridge_: <karolherbst🐧🦀> not really, best bet is to try out older packages/kernels or simply file a bug with the crash report
22:46fdobridge_: <karolherbst🐧🦀> you might also be running into fixed issues, so there is that as well
22:46fdobridge_: <karolherbst🐧🦀> kinda depends on the actual error you are hitting and what version you are running at
22:46fdobridge_: <karolherbst🐧🦀> the output of `dmesg` generally helps
22:48fdobridge_: <enigma9o7> I'm not expert at logs. Does dmesg only output log since I last booted?
22:49fdobridge_: <karolherbst🐧🦀> correct
22:49fdobridge_: <enigma9o7> ```bash
22:49fdobridge_: <enigma9o7> $ dmesg|grep nouveau
22:49fdobridge_: <enigma9o7> [ 4.810429] fb0: switching to nouveaufb from VESA VGA
22:49fdobridge_: <enigma9o7> [ 4.810658] nouveau 0000:01:00.0: NVIDIA GT216 (0a5480a2)
22:49fdobridge_: <enigma9o7> [ 4.834009] nouveau 0000:01:00.0: bios: version 70.16.45.00.05
22:49fdobridge_: <enigma9o7> [ 4.837012] nouveau 0000:01:00.0: fb: 1024 MiB DDR3
22:49fdobridge_: <enigma9o7> [ 4.930779] nouveau 0000:01:00.0: DRM: VRAM: 1024 MiB
22:49fdobridge_: <enigma9o7> [ 4.930782] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
22:49fdobridge_: <enigma9o7> [ 4.930789] nouveau 0000:01:00.0: DRM: TMDS table version 2.0
22:49fdobridge_: <enigma9o7> [ 4.930793] nouveau 0000:01:00.0: DRM: DCB version 4.0
22:49fdobridge_: <enigma9o7> [ 4.930797] nouveau 0000:01:00.0: DRM: DCB outp 00: 010003f3 00010036
22:49fdobridge_: <enigma9o7> [ 4.930801] nouveau 0000:01:00.0: DRM: DCB outp 01: 02011300 00000000
22:49fdobridge_: <enigma9o7> [ 4.930805] nouveau 0000:01:00.0: DRM: DCB outp 02: 02422362 00020010
22:49fdobridge_: <enigma9o7> [ 4.930809] nouveau 0000:01:00.0: DRM: DCB conn 00: 00000040
22:49fdobridge_: <enigma9o7> [ 4.930812] nouveau 0000:01:00.0: DRM: DCB conn 01: 00000100
22:49fdobridge_: <enigma9o7> [ 4.930815] nouveau 0000:01:00.0: DRM: DCB conn 02: 00001261
22:49fdobridge_: <enigma9o7> [ 4.930825] nouveau 0000:01:00.0: DRM: BIOS FP mode: 2048x1536 (200000kHz pixel clock)
22:49fdobridge_: <enigma9o7> [ 4.933383] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
22:49fdobridge_: <enigma9o7> [ 5.014946] nouveau 0000:01:00.0: DRM: allocated 1920x1080 fb: 0x70000, bo (____ptrval____)
22:49fdobridge_: <enigma9o7> [ 5.016406] fbcon: nouveaudrmfb (fb0) is primary device
22:49fdobridge_: <enigma9o7> [ 5.016412] nouveau 0000:01:00.0: fb0: nouveaudrmfb frame buffer device
22:49fdobridge_: <enigma9o7> [ 5.108750] [drm] Initialized nouveau 1.3.1 20120801 for 0000:01:00.0 on minor 0
22:49fdobridge_: <enigma9o7> [39101.857938] nouveau 0000:01:00.0: Direct firmware load for nouveau/nva5_fuc084 failed with error -2
22:49fdobridge_: <enigma9o7> [39101.857978] nouveau 0000:01:00.0: Direct firmware load for nouveau/nva5_fuc084d failed with error -2
22:49fdobridge_: <enigma9o7> [39101.857982] nouveau 0000:01:00.0: msvld: unable to load firmware data
22:49fdobridge_: <enigma9o7> [39101.857987] nouveau 0000:01:00.0: msvld: init failed, -19
22:49fdobridge_: <enigma9o7> ```
22:50fdobridge_: <enigma9o7> so when it locks up I have to hard reboot, so I wouldn't be able to see anything in dmseg I guess?
22:50fdobridge_: <enigma9o7> the time I caught that message I pasted later, it seemed locked up, i try to go to tty, and then that message popped up in tty.
22:50fdobridge_: <enigma9o7> but other times it locks up it doesnt let me to tty, just does nothing
22:50fdobridge_: <karolherbst🐧🦀> with journald you can look up dmesg from older boots, like `journalctl --dmesg --boot -1` (would be dmesg from the previous one)
22:50fdobridge_: <enigma9o7> the time I caught that message I pasted ealier, it seemed locked up, i try to go to tty, and then that message popped up in tty. (edited)
22:50fdobridge_: <karolherbst🐧🦀> add `--no-hostname` to shorten it a little
22:51fdobridge_: <pavlo_it_115> I also had system freezes on my gt 240
22:51fdobridge_: <pavlo_it_115> (now I don't have it)
22:52fdobridge_: <pavlo_it_115> when playing or using a browser
22:52fdobridge_: <enigma9o7> I don't freeze when using nvidia-340 prop, but when using that, most new gnome stuff and some other stuff doesnt work cuz they're using EGL instea dof GLX
22:52fdobridge_: <karolherbst🐧🦀> yeah.. I've fixed a few issues there
22:53fdobridge_: <gfxstrand> I wonder if I have to torch the constant cache after re-binding constant buffers. 🤔
22:53fdobridge_: <enigma9o7> nouveau also makes tty work, with nvidia-340 its invisible (I can login blind, but thats not super useful for anything besides reboot)
22:54fdobridge_: <gfxstrand> I hope not. That would suck.
22:54fdobridge_: <karolherbst🐧🦀> they have an invalidate bit
22:54fdobridge_: <enigma9o7> so I really really really wanna make it stop locking up. but it happens right when I'm in the middle of stuff every time, even tho its only every day or two, its too often for me. The latest mainline kernel I was able to boot (from ubuntu mainline kernels) was 6.1.66
22:54fdobridge_: <pavlo_it_115> Everything is fine on my blob too. Only obs didn't want to work) (there weren't enough OpenGL extensions) And I bought myself a 1050) But it didn't get better... For some reason, the maximum opengl 4.3 (although on mesamatrix the nvc0 driver has OpenGL 4.5), thank you very much to the nvidia company for the "signed" firmware.
22:54fdobridge_: <enigma9o7> And if the fixes are in 6.2, that doesnt help.
22:55fdobridge_: <karolherbst🐧🦀> yeah.. but for that it would be useful to know what's the error
22:56fdobridge_: <pavlo_it_115> Everything is fine on my blob too. Only obs didn't want to work) (there weren't enough OpenGL extensions) And I bought myself a 1050) But it didn't get better... For some reason, the maximum opengl 4.3 (although on mesamatrix the nvc0 driver has OpenGL 4.5). And thank you (nvidia company) very much for the "signed" firmware. (edited)
22:56fdobridge_: <enigma9o7> yep, i'll work on finding more logs, thanks for the advice on journal, I'll surely report back on this later.
22:56fdobridge_: <karolherbst🐧🦀> okay, cool
22:56fdobridge_: <!DodoNVK (she) 🇱🇹> Hopefully missing AVX support isn't the issue here 🐸
22:56fdobridge_: <enigma9o7> I have no AVX.
22:57fdobridge_: <enigma9o7> first gen i7
23:12fdobridge_: <gfxstrand> Ugh... color write masks is regressing 16 tests. They all have at least 17 subpasses. 😩
23:41fdobridge_: <Tom^> hm 2fps in unigine heaven, dmesg prints kernel: nouveau 0000:01:00.0: heaven_x64[1595]: nv50cal_space: -16
23:43fdobridge_: <Tom^> oh i probably need nouveau.config=NvGspRm=1 i think
23:45fdobridge_: <pavlo_it_115> does zink work now through nvk?
23:46fdobridge_: <pavlo_it_115> ```
23:46fdobridge_: <pavlo_it_115> [pavlo@archlinux ~]$ MESA_LOADER_DRIVER_OVERRIDE=zink glxinfo
23:46fdobridge_: <pavlo_it_115> name of display: :1
23:46fdobridge_: <pavlo_it_115> MESA: error: ZINK: vkEnumeratePhysicalDevices failed (VK_ERROR_INITIALIZATION_FAILED)
23:46fdobridge_: <pavlo_it_115> MESA: error: ZINK: failed to choose pdev
23:46fdobridge_: <pavlo_it_115> libGL error: glx: failed to create drisw screen
23:46fdobridge_: <pavlo_it_115> libGL error: failed to load driver: zink
23:46fdobridge_: <pavlo_it_115> X Error of failed request: BadValue (integer parameter out of range for operation)
23:46fdobridge_: <pavlo_it_115> Major opcode of failed request: 150 (GLX)
23:46fdobridge_: <pavlo_it_115> Minor opcode of failed request: 24 (X_GLXCreateNewContext)
23:46fdobridge_: <pavlo_it_115> Value in failed request: 0x0
23:46fdobridge_: <pavlo_it_115> Serial number of failed request: 31
23:46fdobridge_: <pavlo_it_115> Current serial number in output stream: 32
23:46fdobridge_: <pavlo_it_115>
23:46fdobridge_: <pavlo_it_115> [pavlo@archlinux ~]$ uname -a
23:46fdobridge_: <pavlo_it_115> Linux archlinux 6.6.6-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Mon, 11 Dec 2023 11:47:45 +0000 x86_64 GNU/Linux
23:46fdobridge_: <pavlo_it_115> ```
23:46fdobridge_: <pavlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1184280140751048724/message.txt?ex=658b65d4&is=6578f0d4&hm=8b1dd2bbfab69c83de4a73998ef2041cc0d50d7eee451d1e02e86e67c6e85af3&
23:46fdobridge_: <pavlo_it_115> it's in a wayland session
23:48fdobridge_: <pavlo_it_115> (vulkaninfo)
23:48fdobridge_: <pavlo_it_115> https://cdn.discordapp.com/attachments/1034184951790305330/1184280676313342002/message.txt?ex=658b6654&is=6578f154&hm=a5b11c359e554172c070faf928342eaef208e147402a8fb1be61bd84fb972ccc&
23:54fdobridge_: <Tom^> cool i got it up and running https://i.imgur.com/0BOdPe5.jpeg
23:55fdobridge_: <karolherbst🐧🦀> not even terrible performance
23:55fdobridge_: <karolherbst🐧🦀> nvidia probably be like 3x the perf
23:55fdobridge_: <Tom^> well it seems im getting close to the 1650 blob performance
23:55fdobridge_: <Tom^> so its a bit behind hehe but it runs!
23:56fdobridge_: <karolherbst🐧🦀> what gpu was that agian?
23:56fdobridge_: <Tom^> and even more nostalgia i think im hitting almost exact numbers that 780ti did on 1920x1080 lol
23:56fdobridge_: <Tom^> 3060 80w one
23:56fdobridge_: <karolherbst🐧🦀> it's kinda the same ballpark, yeah
23:56fdobridge_: <karolherbst🐧🦀> ahh so not that far away actually
23:56fdobridge_: <Tom^> but has some kind of "dynamic boost" which nvidia-powerd ups it to 90 or 95
23:57fdobridge_: <Tom^> on blob that is
23:57fdobridge_: <karolherbst🐧🦀> ehh.. maybe 3x wasn't that far off
23:58fdobridge_: <karolherbst🐧🦀> but at least it's not slow
23:58fdobridge_: <Tom^> 2fps without gsp, ~46 with
23:59fdobridge_: <karolherbst🐧🦀> massive
23:59fdobridge_: <karolherbst🐧🦀> @gfxstrand ^^ fyi 😄
23:59fdobridge_: <karolherbst🐧🦀> but that's on the gl driver
23:59fdobridge_: <Tom^> yeah