00:08fdobridge_: <redsheep> Actually, if you end up tonemapping a 10 bit surface then I suppose 12 isn't so crazy, so if the driver clamps there then that's probably good. My display does support a 12bpc mode.
00:17fdobridge_: <phomes_> I am trying to figure out why X4 Foundations is crashing. NAK_DEBUG=print is not showing anything. Nor is any printf so I guess the game eats the output
00:17fdobridge_: <phomes_> Is there an easy way to get NAK_DEBUG to go directly to a file?
02:44fdobridge_: <gfxstrand> No, not at present. It wouldn't be too hard to fix that, though.
04:31fdobridge_: <gfxstrand> @plagman does proton-db have a way to track games with NVK? Are there queries set up that will let me see, say, games that work on RADV but not NVK? I think it's probably better to point users there than asking for individual Mesa but reports on everything.
04:32Plagman: there's a driver field in the reports, but i don't know to what extent people have been testing yet
04:32Plagman: i think if we get to a point where we want folks to report in what's broken and what's not, we can put together some packages repositories and put together a call to action
04:33Plagman: right now my experience is most dx11 games seem to be broken so i expect you're not looking for reports, but let me know if you are :-)
04:33Plagman: we can also give you some testers
05:07fdobridge_: <gfxstrand> Okay, if most D3D11 stuff is broken, that's a starting point. I know some D3D11 stuff does work but we probably have some pretty basic bugs that are blowing up lots of stuff. I just don't know what yet.
05:30Liver_K: airlied: That reduced the tearing a bit from what I can tell, but it is still visibly there during long slow pans
05:34Liver_K: Also (to be expected) everything else is hella slow at redrawing the screen lol
06:36fdobridge_: <prop_energy_ball> @airlied If I have a display that works on 6.6 + Nouneau but not 6.7rc5 or linux-git, what's the best way I can get info for you on that?
06:36fdobridge_: <prop_energy_ball> There is nothing I see in dmesg... My other display works fine
06:36fdobridge_: <prop_energy_ball> There is nothing I see in dmesg... My other display works fine on all builds. (edited)
06:36fdobridge_: <prop_energy_ball> It's an ASUS PG32UQX
06:38fdobridge_: <prop_energy_ball> GSP also doesn't work but I see you gave a patch in https://gitlab.freedesktop.org/drm/nouveau/-/issues/283, Dave. I will get that logging for you :)
06:39fdobridge_: <airlied> nouveau.debug=trace I think might be the best option, otherwise bisecting might help
06:40fdobridge_: <airlied> how is it connected? DP or HDMI?
06:40fdobridge_: <prop_energy_ball> DP
06:40fdobridge_: <prop_energy_ball> Both displays are DP
06:40fdobridge_: <prop_energy_ball> I can try bisecting today
07:04Plagman: if you need one pretty basic example, dark souls 3 blows up as soon as it tries to render something shaded
07:04Plagman: which happens during character creation
07:27fdobridge_: <!DodoNVK (she) 🇱🇹> Overwatch 2 works pretty well
07:28fdobridge_: <!DodoNVK (she) 🇱🇹> Except for long stutters
07:29fdobridge_: <!DodoNVK (she) 🇱🇹> While some LEGO game I found an apitrace of exploded with a TRAP
07:30fdobridge_: <!DodoNVK (she) 🇱🇹> HunterCZ has managed to run GTA 5 and it seems to look fine (but Hunter has also noted some GPU hangs; not sure if they're PRIME-related)
10:05fdobridge_: <esdrastarsis> GTA IV appears to perform worse than GTA V 🐸
10:05fdobridge_: <esdrastarsis> I'll test Mary's MR
10:09fdobridge_: <!DodoNVK (she) 🇱🇹> What MR?
10:13fdobridge_: <esdrastarsis> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26288
10:25Liver_K: Anyway, no more suggestions?
10:49fdobridge_: <gobrosse> ```
10:49fdobridge_: <gobrosse> [63/1207] Compiling Rust source ../src/nouveau/compiler/nak/lib.rs
10:49fdobridge_: <gobrosse> FAILED: src/nouveau/compiler/libnak_rs.a
10:49fdobridge_: <gobrosse> rustc -C linker=cc --color=always -C debug-assertions=yes -C overflow-checks=no --crate-type staticlib -C opt-level=2 -g --crate-name nak_rs --emit dep-info=src/nouveau/compiler/nak_rs.d --emit link=src/nouveau/compiler/libnak_rs.a --out-dir src/nouveau/compiler/libnak_rs.a.p -C metadata=ed48680@@nak_rs@sta -Dclippy::all -Aclippy::assertions_on_constants -Aclippy::redundant_field_names -Aclippy::too_many_arguments -Aclippy::type_complexity
10:49fdobridge_: <gobrosse> error[E0432]: unresolved import `nak_bindings`
10:49fdobridge_: <gobrosse> --> ../src/nouveau/compiler/nak/api.rs:8:5
10:49fdobridge_: <gobrosse> |
10:49fdobridge_: <gobrosse> 8 | use nak_bindings::*;
10:49fdobridge_: <gobrosse> | ^^^^^^^^^^^^ maybe a missing crate `nak_bindings`?
10:49fdobridge_: <gobrosse> |
10:49fdobridge_: <gobrosse> = help: consider adding `extern crate nak_bindings` to use the `nak_bindings` crate
10:49fdobridge_: <gobrosse>
10:49fdobridge_: <gobrosse> error[E0432]: unresolved import `bitview`
10:49fdobridge_: <gobrosse> --> ../src/nouveau/compiler/nak/encode_sm50.rs:5:5
10:49fdobridge_: <gobrosse> |
10:49fdobridge_: <gobrosse> 5 | use bitview::*;
10:49fdobridge_: <gobrosse> | ^^^^^^^ maybe a missing crate `bitview`?
10:49fdobridge_: <gobrosse> |
10:49fdobridge_: <gobrosse> = help: consider adding `extern crate bitview` to use the `bitview` crate
10:49fdobridge_: <gobrosse>
10:49fdobridge_: <gobrosse> error[E0432]: unresolved import `bitview`
10:49fdobridge_: <gobrosse> --> ../src/nouveau/compiler/nak/encode_sm70.rs:5:5
10:49fdobridge_: <gobrosse> |
10:49fdobridge_: <gobrosse> 5 | use bitview::*;
10:49fdobridge_: <gobrosse> | ^^^^^^^ maybe a missing crate `bitview`?
10:50fdobridge_: <gobrosse> |
10:50fdobridge_: <gobrosse> = help: consider adding `extern crate bitview` to use the `bitview` crate
10:50fdobridge_: <gobrosse>
10:50fdobridge_: <gobrosse> error[E0432]: unresolved import `nak_bindings`
10:50fdobridge_: <gobrosse> --> ../src/nouveau/compiler/nak/from_nir.rs:11:5
10:50fdobridge_: <gobrosse> |
10:50fdobridge_: <gobrosse> More issues building NAK on Arch 😦
10:51fdobridge_: <gobrosse> Meson `1.3.0`, rustc 1.74.1, mesa 6b1fafe7164305fbdab6a2c88abf2e8f5cc88bc4
10:54fdobridge_: <gobrosse> ```
10:54fdobridge_: <gobrosse> error[E0432]: unresolved import `bitview`
10:54fdobridge_: <gobrosse> --> ../src/nouveau/compiler/nak/ir.rs:7:5
10:54fdobridge_: <gobrosse> |
10:54fdobridge_: <gobrosse> 7 | use bitview::BitMutView;
10:54fdobridge_: <gobrosse> | ^^^^^^^ help: a similar path exists: `self::bitview`
10:54fdobridge_: <gobrosse> ```sounds like a rust-nightly thing maybe ?
11:04fdobridge_: <gobrosse> uh, so it seems that setting `--prefix` breaks the build
11:04fdobridge_: <gobrosse> uh, so it seems that setting `--prefix` to a custom path breaks the build (edited)
11:07fdobridge_: <gobrosse> ~~~uh, so it seems that setting `--prefix` to a custom path breaks the build~~ (edited)
11:07fdobridge_: <gobrosse> ok I figured it out, somehow I had `rust_std` misconfigured in my first build, I think that happened because I first ran meson without `rustc` installed ?
11:08fdobridge_: <gobrosse> ok I figured it out, somehow I had `rust_std` misconfigured (to `none`) in my first build, I think that happened because I first ran meson without `rustc` installed ? (edited)
11:56fdobridge_: <mohamexiety> the rust bits are really weird in meson 1.3.0 from my experience
11:57fdobridge_: <mohamexiety> like every now and then it just likes to literally report every single line in NAK as an error and the only way to fix it is by doing a wipe and building again
11:57fdobridge_: <prop_energy_ball> Uhhh wtf, so
11:57fdobridge_: <prop_energy_ball> My bisect came to:
11:57fdobridge_: <prop_energy_ball> ```
11:57fdobridge_: <prop_energy_ball> 79fb229b8810071648b65c37382aea7819a5f935 is the first bad commit
11:57fdobridge_: <prop_energy_ball> commit 79fb229b8810071648b65c37382aea7819a5f935
11:57fdobridge_: <prop_energy_ball> Merge: f107ff76a8c2 78f54469b871
11:57fdobridge_: <prop_energy_ball> Author: Dave Airlie <airlied@redhat.com>
11:57fdobridge_: <prop_energy_ball> Date: Fri Sep 29 08:27:00 2023 +1000
11:57fdobridge_: <prop_energy_ball>
11:57fdobridge_: <prop_energy_ball> Merge tag 'drm-misc-next-2023-09-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
11:58fdobridge_: <prop_energy_ball>
11:58fdobridge_: <prop_energy_ball>
11:58fdobridge_: <prop_energy_ball> ```
11:58fdobridge_: <prop_energy_ball> But checking out `drm-misc-next-2023-09-27` from `git://anongit.freedesktop.org/drm/drm-misc` works fine...
11:58fdobridge_: <prop_energy_ball> but this commit in linux mainline definitely is broken
11:58fdobridge_: <prop_energy_ball> :l
11:59fdobridge_: <!DodoNVK (she) 🇱🇹> I hope you haven't mis-bisected something 🐧
12:01fdobridge_: <prop_energy_ball> me too 🐸
12:01fdobridge_: <gobrosse> pretty sure that's what I hit yeah
12:01fdobridge_: <gobrosse> now fiddling with my code so it runs without external_memory_host
12:02fdobridge_: <mohamexiety> hah, would be fun to see how your tests work on NVK
12:02fdobridge_: <prop_energy_ball> I don't really understand how it can come back to a merge commit in the first place
12:03fdobridge_: <prop_energy_ball> maybe I did fuck something up
12:03fdobridge_: <prop_energy_ball> inb4 the issue is actually sporadic
12:04fdobridge_: <prop_energy_ball> and that frogged up my bisect
12:04fdobridge_: <prop_energy_ball> hopefully it's not some weird UB thing
12:08fdobridge_: <gobrosse> ayy!
12:08fdobridge_: <gobrosse> https://cdn.discordapp.com/attachments/1034184951790305330/1187365896319143936/image.png?ex=65969fa9&is=65842aa9&hm=2b5bca88616426e985f68c72de529d27f074ea22ab7c08d35fc791d375fc3051&
12:12fdobridge_: <gobrosse> oops I immediately broke it
12:12fdobridge_: <gobrosse> https://cdn.discordapp.com/attachments/1034184951790305330/1187367068417413161/image.png?ex=6596a0c1&is=65842bc1&hm=ed54eb10a0b4237866b6687b1b812d952f9cd21858e3fde2483e2d1bf67fe763&
12:13fdobridge_: <mohamexiety> nice! I wonder if Turing+ would be better
12:13fdobridge_: <mohamexiety> Maxwell compiler support is still WIP
12:13fdobridge_: <gobrosse> this is my fib shader, it's pretty evil
12:14fdobridge_: <gobrosse> i can't make a proper issue right now because I accidentally regressed on passing validation, just capability declaration jank afaict but it should be clear to not distract
12:14fdobridge_: <gobrosse> i can't make a proper issue right now because I accidentally regressed on passing `spirv-val`, just capability declaration jank afaict but it should be clear to not distract (edited)
12:23fdobridge_: <!DodoNVK (she) 🇱🇹> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/nak/legalize.rs#L357
12:23fdobridge_: <gobrosse> oh a TODO ?
12:25fdobridge_: <gobrosse> also dumb Q but ... how do I know whether I'm talking to nvk or nv proprietary ? I have some stupid workarrounds for driver bugs
12:26fdobridge_: <pixelcluster> check the driverId device property?
12:26fdobridge_: <pixelcluster> it’s not in the 1.0 properties iirc
12:26fdobridge_: <gobrosse> doesn't seem to report it in VulkanInfo
12:26fdobridge_: <pixelcluster> it’s not in the 1.0 properties iirc, not sure what it’s in (edited)
12:27fdobridge_: <gobrosse> ah it's driverID
12:27fdobridge_: <gobrosse> kewl
12:29fdobridge_: <!DodoNVK (she) 🇱🇹> DXVK uses that to auto-enable strict float emulation for compatible drivers
12:29fdobridge_: <gobrosse> I have a workarround that uses shuffle instead of broadcast_first because I found the latter to be broken on NV proprietary 🐸 yes...
12:30fdobridge_: <gobrosse> I have a workarround that uses subgroup shuffle instead of broadcast_first because I found the latter to be broken on NV proprietary 🐸 yes... (edited)
13:06fdobridge_: <karolherbst🐧🦀> once I bisected 5 times, because....
13:09fdobridge_: <pac85> Stochastic bisecting
13:09fdobridge_: <pac85> It probably makes more sense to test 5 times at each steps though I think
13:10fdobridge_: <pac85> Otherwise you need a run where you are lucky at each step
13:14fdobridge_: <!DodoNVK (she) 🇱🇹> is that the only good stochastic thing? 🐸
13:16fdobridge_: <pac85> Mmm I'm not getting it
13:17fdobridge_: <esdrastarsis> Does Nvidia support BC1 tex format?
13:19fdobridge_: <!DodoNVK (she) 🇱🇹> When I hear the word "stochastic" I think of stochastic ||terrorism||
13:33fdobridge_: <gfxstrand> Yeah, someone needs to go through and audit the entire legalize pass for SM50. I keep hitting stuff there in my spot testing.
13:36fdobridge_: <gfxstrand> Damn... That one's still $60.
13:37fdobridge_: <!DodoNVK (she) 🇱🇹> So Collabora doesn't have its own Steam library? 🐸
13:38fdobridge_: <gfxstrand> We've got some stuff somewhere. It's not extensive, though. I'll have to ask around and see what's what.
13:39fdobridge_: <gfxstrand> NVK isn't exactly an internally well funded project, though, so people are likely to start looking at my funny if I ask for a $500/month game budget. 😂
13:40fdobridge_: <gfxstrand> NVK isn't exactly an internally well funded project, though, so people are likely to start looking at me funny if I ask for a $500/month game budget. 😂 (edited)
13:40fdobridge_: <mohamexiety> I can test that one
13:41fdobridge_: <mohamexiety> will need a bit more time tho since my linux install is kinda smol
13:44fdobridge_: <dwlsalmeida> I have some fixes in the MR
13:44fdobridge_: <dwlsalmeida> in particular, IAdd3 is broken as we've discussed
13:45fdobridge_: <gfxstrand> Yeah, I already merged the ineg one as part of fp64 because I hit it testing fp64 on Maxwell. 🙃
13:45fdobridge_: <dwlsalmeida> also I think you had a tiny mistake in the f20 immediates
13:45fdobridge_: <gfxstrand> That's entirely possible.
13:46fdobridge_: <gfxstrand> Though I think they at least kinda work. The fp64 `frcp` lowering uses them.
13:46fdobridge_: <dwlsalmeida> yeah the assert was val & 0xfffff000 == 0
13:47fdobridge_: <dwlsalmeida> but we want val & 0x00000fff == 0 unless I missed something
13:47fdobridge_: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26587/diffs?commit_id=73a1acef18fabbfc1699eb3504a3f829dbd7030f
13:47fdobridge_: <gfxstrand> Looks like I found and fixed it as part of fp64
13:48fdobridge_: <dwlsalmeida> ah yes lol
13:49fdobridge_: <dadschoorse> for d3d9/11 games apitraces are often good enough for debugging, and they reasonably easy to capture for users
13:49fdobridge_: <dwlsalmeida> @gfxstrand I know you're on vacation, but when you get back can you jump in on this discussion?
13:49fdobridge_: <gfxstrand> I was pleasantly surprised by how little I had to fix on order to get the fp64 tests to run on Maxwell. 🙂
13:49fdobridge_: <!DodoNVK (she) 🇱🇹> Unfortunately some games don't have one
13:49fdobridge_: <!DodoNVK (she) 🇱🇹> Like GTA 5 🐸
13:50fdobridge_: <gfxstrand> Yeah but if it's crashing it's hard to get a trace. Or do you mean a trace of the D3D11 API?
13:50fdobridge_: <!DodoNVK (she) 🇱🇹> Yes
13:51fdobridge_: <gfxstrand> Yeah, we need to get your fixes merged. I may have some time to look at it The next week or so but I can't promise anything.
13:51fdobridge_: <dwlsalmeida> @gfxstrand I mean this discussion btw, .P vs .D
13:51fdobridge_: <dwlsalmeida> so SUST and SULD are working, but SUATOM is broken
13:51fdobridge_: <gfxstrand> Right. Yeah, I just need to read the spec and look at the things.
13:52fdobridge_: <dadschoorse> yeah, d3d11 trace. Those also have the added benefit that they are driver agnostic unlike renderdoc, so you can capture with a working driver and replay on a broken one
13:52fdobridge_: <gfxstrand> @dwlsalmeida did you get `bitfield_reverse` fixed to use a new op yet?
13:52fdobridge_: <marysaka> I think I have it on steam going to check that
13:52fdobridge_: <dwlsalmeida> no, but I can do it today if you want
13:53fdobridge_: <dwlsalmeida> I simply updated the PR to add your patch on top, to fix the latency
13:53fdobridge_: <gfxstrand> Yeah, if someone wanted to pull a D3D11 trace of DS3 and send it to me, I can definitely take a look when I get back.
13:55fdobridge_: <gfxstrand> Please. My patch breaks Turing pretty badly so we need two different ops. That also makes the generation differences more clear throughout the compiler. I really don't like the "call it A bit encode it as B" thing. It ends up biting us every time...
13:55fdobridge_: <gfxstrand> Please. My patch breaks Turing pretty badly so we need two different ops. That also makes the generation differences more clear throughout the compiler. I really don't like the "call it A but encode it as B" thing. It ends up biting us every time... (edited)
13:56fdobridge_: <dwlsalmeida> no worries Faith, I'll work on it rn
13:56fdobridge_: <gfxstrand> Thanks a bunch! 💜
13:58fdobridge_: <gfxstrand> I already reworked a few different SM50 things for this. I also screwed it up myself for `iadd3` where I tried to shove all the advanced use cases into `OpIAdd3X` and ended up splitting it wrong so modifiers didn't work half the time.
13:59fdobridge_: <gfxstrand> Lesson learned: Make the NAK op match the hardware op and don't try to be clever. 😅
14:00fdobridge_: <gfxstrand> Incidentally, I'm pretty sure brev is broken in codegen because of this. 🤡
14:00fdobridge_: <gfxstrand> Unless there's a special case I'm not seeing
14:01fdobridge_: <gfxstrand> Is there a trace library somewhere I should know about?
14:01fdobridge_: <gfxstrand> Because that would be REALLY useful...
14:03fdobridge_: <!DodoNVK (she) 🇱🇹> I primarily looked at DXVK bug reports
15:26fdobridge_: <prop_energy_ball> You mean like a db of game traces you can just replay? I have a whole suite I can share of DX9 and some DX12 ones (needs my apitrace fork tho) -- and I think there's a bunch for DX11 in Valve CI.
15:32fdobridge_: <gfxstrand> Okay, that'd be super helpful. Let's chat about that when I get back from holiday
15:48fdobridge_: <!DodoNVK (she) 🇱🇹> Is Sims 2 in there? 🐸
16:15fdobridge_: <prop_energy_ball> Yes
16:15fdobridge_: <prop_energy_ball> Sounds good
19:04juri_: has anyone here used nouveau to do AI inference?
19:05karolherbst: I'm not sure I've tried....
19:05karolherbst: but I have rusticl running on openvino
19:05karolherbst: uhm
19:05karolherbst: openvino running on rusticl
19:05karolherbst: juri_: speciifc reason for the question?
19:06juri_: running an llm in cpu-only, have a ton of old nvidia gear, want more performance.
19:07karolherbst: I see
19:08fdobridge_: <redsheep> With how VRAM intensive LLMs are older gear might be entirely useless regardless
19:08karolherbst: most of that is CUDA, but if you have anything opencl based, you can try to use it with rusticl va `RUSTICL_ENABLE=nouveau` and see how it works out
19:08karolherbst: there might be bugs, but you can report them and then I'm trying to fix those next year
19:08karolherbst: it's good enough for image classification tho
19:09karolherbst: but yeah.. bigger llms might not run :D
19:32airlied: and when you say old nvidia gear, nouveau probably won't reclock it
19:32karolherbst: ohh that as well
19:32karolherbst: so it might still be slower than CPU
22:30Lyude: Oh wow ok, vkms definitely does not seem like a bad idea to port over
22:30Lyude: there don't seem to be any files in here that aren't less then 500 lines