00:08 fdobridge_: <r​edsheep> 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:17 fdobridge_: <p​homes_> 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:17 fdobridge_: <p​homes_> Is there an easy way to get NAK_DEBUG to go directly to a file?
02:44 fdobridge_: <g​fxstrand> No, not at present. It wouldn't be too hard to fix that, though.
04:31 fdobridge_: <g​fxstrand> @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:32 Plagman: there's a driver field in the reports, but i don't know to what extent people have been testing yet
04:32 Plagman: 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:33 Plagman: 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:33 Plagman: we can also give you some testers
05:07 fdobridge_: <g​fxstrand> 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:30 Liver_K: airlied: That reduced the tearing a bit from what I can tell, but it is still visibly there during long slow pans
05:34 Liver_K: Also (to be expected) everything else is hella slow at redrawing the screen lol
06:36 fdobridge_: <p​rop_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:36 fdobridge_: <p​rop_energy_ball> There is nothing I see in dmesg... My other display works fine
06:36 fdobridge_: <p​rop_energy_ball> There is nothing I see in dmesg... My other display works fine on all builds. (edited)
06:36 fdobridge_: <p​rop_energy_ball> It's an ASUS PG32UQX
06:38 fdobridge_: <p​rop_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:39 fdobridge_: <a​irlied> nouveau.debug=trace I think might be the best option, otherwise bisecting might help
06:40 fdobridge_: <a​irlied> how is it connected? DP or HDMI?
06:40 fdobridge_: <p​rop_energy_ball> DP
06:40 fdobridge_: <p​rop_energy_ball> Both displays are DP
06:40 fdobridge_: <p​rop_energy_ball> I can try bisecting today
07:04 Plagman: if you need one pretty basic example, dark souls 3 blows up as soon as it tries to render something shaded
07:04 Plagman: which happens during character creation
07:27 fdobridge_: <!​DodoNVK (she) 🇱🇹> Overwatch 2 works pretty well
07:28 fdobridge_: <!​DodoNVK (she) 🇱🇹> Except for long stutters
07:29 fdobridge_: <!​DodoNVK (she) 🇱🇹> While some LEGO game I found an apitrace of exploded with a TRAP
07:30 fdobridge_: <!​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:05 fdobridge_: <e​sdrastarsis> GTA IV appears to perform worse than GTA V 🐸
10:05 fdobridge_: <e​sdrastarsis> I'll test Mary's MR
10:09 fdobridge_: <!​DodoNVK (she) 🇱🇹> What MR?
10:13 fdobridge_: <e​sdrastarsis> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26288
10:25 Liver_K: Anyway, no more suggestions?
10:49 fdobridge_: <g​obrosse> ```
10:49 fdobridge_: <g​obrosse> [63/1207] Compiling Rust source ../src/nouveau/compiler/nak/lib.rs
10:49 fdobridge_: <g​obrosse> FAILED: src/nouveau/compiler/libnak_rs.a
10:49 fdobridge_: <g​obrosse> 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:49 fdobridge_: <g​obrosse> error[E0432]: unresolved import `nak_bindings`
10:49 fdobridge_: <g​obrosse> --> ../src/nouveau/compiler/nak/api.rs:8:5
10:49 fdobridge_: <g​obrosse> |
10:49 fdobridge_: <g​obrosse> 8 | use nak_bindings::*;
10:49 fdobridge_: <g​obrosse> | ^^^^^^^^^^^^ maybe a missing crate `nak_bindings`?
10:49 fdobridge_: <g​obrosse> |
10:49 fdobridge_: <g​obrosse> = help: consider adding `extern crate nak_bindings` to use the `nak_bindings` crate
10:49 fdobridge_: <g​obrosse>
10:49 fdobridge_: <g​obrosse> error[E0432]: unresolved import `bitview`
10:49 fdobridge_: <g​obrosse> --> ../src/nouveau/compiler/nak/encode_sm50.rs:5:5
10:49 fdobridge_: <g​obrosse> |
10:49 fdobridge_: <g​obrosse> 5 | use bitview::*;
10:49 fdobridge_: <g​obrosse> | ^^^^^^^ maybe a missing crate `bitview`?
10:49 fdobridge_: <g​obrosse> |
10:49 fdobridge_: <g​obrosse> = help: consider adding `extern crate bitview` to use the `bitview` crate
10:49 fdobridge_: <g​obrosse>
10:49 fdobridge_: <g​obrosse> error[E0432]: unresolved import `bitview`
10:49 fdobridge_: <g​obrosse> --> ../src/nouveau/compiler/nak/encode_sm70.rs:5:5
10:49 fdobridge_: <g​obrosse> |
10:49 fdobridge_: <g​obrosse> 5 | use bitview::*;
10:49 fdobridge_: <g​obrosse> | ^^^^^^^ maybe a missing crate `bitview`?
10:50 fdobridge_: <g​obrosse> |
10:50 fdobridge_: <g​obrosse> = help: consider adding `extern crate bitview` to use the `bitview` crate
10:50 fdobridge_: <g​obrosse>
10:50 fdobridge_: <g​obrosse> error[E0432]: unresolved import `nak_bindings`
10:50 fdobridge_: <g​obrosse> --> ../src/nouveau/compiler/nak/from_nir.rs:11:5
10:50 fdobridge_: <g​obrosse> |
10:50 fdobridge_: <g​obrosse> More issues building NAK on Arch 😦
10:51 fdobridge_: <g​obrosse> Meson `1.3.0`, rustc 1.74.1, mesa 6b1fafe7164305fbdab6a2c88abf2e8f5cc88bc4
10:54 fdobridge_: <g​obrosse> ```
10:54 fdobridge_: <g​obrosse> error[E0432]: unresolved import `bitview`
10:54 fdobridge_: <g​obrosse> --> ../src/nouveau/compiler/nak/ir.rs:7:5
10:54 fdobridge_: <g​obrosse> |
10:54 fdobridge_: <g​obrosse> 7 | use bitview::BitMutView;
10:54 fdobridge_: <g​obrosse> | ^^^^^^^ help: a similar path exists: `self::bitview`
10:54 fdobridge_: <g​obrosse> ```sounds like a rust-nightly thing maybe ?
11:04 fdobridge_: <g​obrosse> uh, so it seems that setting `--prefix` breaks the build
11:04 fdobridge_: <g​obrosse> uh, so it seems that setting `--prefix` to a custom path breaks the build (edited)
11:07 fdobridge_: <g​obrosse> ~~~uh, so it seems that setting `--prefix` to a custom path breaks the build~~ (edited)
11:07 fdobridge_: <g​obrosse> 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:08 fdobridge_: <g​obrosse> 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:56 fdobridge_: <m​ohamexiety> the rust bits are really weird in meson 1.3.0 from my experience
11:57 fdobridge_: <m​ohamexiety> 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:57 fdobridge_: <p​rop_energy_ball> Uhhh wtf, so
11:57 fdobridge_: <p​rop_energy_ball> My bisect came to:
11:57 fdobridge_: <p​rop_energy_ball> ```
11:57 fdobridge_: <p​rop_energy_ball> 79fb229b8810071648b65c37382aea7819a5f935 is the first bad commit
11:57 fdobridge_: <p​rop_energy_ball> commit 79fb229b8810071648b65c37382aea7819a5f935
11:57 fdobridge_: <p​rop_energy_ball> Merge: f107ff76a8c2 78f54469b871
11:57 fdobridge_: <p​rop_energy_ball> Author: Dave Airlie <airlied@redhat.com>
11:57 fdobridge_: <p​rop_energy_ball> Date: Fri Sep 29 08:27:00 2023 +1000
11:57 fdobridge_: <p​rop_energy_ball>
11:57 fdobridge_: <p​rop_energy_ball> Merge tag 'drm-misc-next-2023-09-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
11:58 fdobridge_: <p​rop_energy_ball>
11:58 fdobridge_: <p​rop_energy_ball>
11:58 fdobridge_: <p​rop_energy_ball> ```
11:58 fdobridge_: <p​rop_energy_ball> But checking out `drm-misc-next-2023-09-27` from `git://anongit.freedesktop.org/drm/drm-misc` works fine...
11:58 fdobridge_: <p​rop_energy_ball> but this commit in linux mainline definitely is broken
11:58 fdobridge_: <p​rop_energy_ball> :l
11:59 fdobridge_: <!​DodoNVK (she) 🇱🇹> I hope you haven't mis-bisected something 🐧
12:01 fdobridge_: <p​rop_energy_ball> me too 🐸
12:01 fdobridge_: <g​obrosse> pretty sure that's what I hit yeah
12:01 fdobridge_: <g​obrosse> now fiddling with my code so it runs without external_memory_host
12:02 fdobridge_: <m​ohamexiety> hah, would be fun to see how your tests work on NVK
12:02 fdobridge_: <p​rop_energy_ball> I don't really understand how it can come back to a merge commit in the first place
12:03 fdobridge_: <p​rop_energy_ball> maybe I did fuck something up
12:03 fdobridge_: <p​rop_energy_ball> inb4 the issue is actually sporadic
12:04 fdobridge_: <p​rop_energy_ball> and that frogged up my bisect
12:04 fdobridge_: <p​rop_energy_ball> hopefully it's not some weird UB thing
12:08 fdobridge_: <g​obrosse> ayy!
12:08 fdobridge_: <g​obrosse> https://cdn.discordapp.com/attachments/1034184951790305330/1187365896319143936/image.png?ex=65969fa9&is=65842aa9&hm=2b5bca88616426e985f68c72de529d27f074ea22ab7c08d35fc791d375fc3051&
12:12 fdobridge_: <g​obrosse> oops I immediately broke it
12:12 fdobridge_: <g​obrosse> https://cdn.discordapp.com/attachments/1034184951790305330/1187367068417413161/image.png?ex=6596a0c1&is=65842bc1&hm=ed54eb10a0b4237866b6687b1b812d952f9cd21858e3fde2483e2d1bf67fe763&
12:13 fdobridge_: <m​ohamexiety> nice! I wonder if Turing+ would be better
12:13 fdobridge_: <m​ohamexiety> Maxwell compiler support is still WIP
12:13 fdobridge_: <g​obrosse> this is my fib shader, it's pretty evil
12:14 fdobridge_: <g​obrosse> 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:14 fdobridge_: <g​obrosse> 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:23 fdobridge_: <!​DodoNVK (she) 🇱🇹> https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/nak/legalize.rs#L357
12:23 fdobridge_: <g​obrosse> oh a TODO ?
12:25 fdobridge_: <g​obrosse> 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:26 fdobridge_: <p​ixelcluster> check the driverId device property?
12:26 fdobridge_: <p​ixelcluster> it’s not in the 1.0 properties iirc
12:26 fdobridge_: <g​obrosse> doesn't seem to report it in VulkanInfo
12:26 fdobridge_: <p​ixelcluster> it’s not in the 1.0 properties iirc, not sure what it’s in (edited)
12:27 fdobridge_: <g​obrosse> ah it's driverID
12:27 fdobridge_: <g​obrosse> kewl
12:29 fdobridge_: <!​DodoNVK (she) 🇱🇹> DXVK uses that to auto-enable strict float emulation for compatible drivers
12:29 fdobridge_: <g​obrosse> I have a workarround that uses shuffle instead of broadcast_first because I found the latter to be broken on NV proprietary 🐸 yes...
12:30 fdobridge_: <g​obrosse> 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:06 fdobridge_: <k​arolherbst🐧🦀> once I bisected 5 times, because....
13:09 fdobridge_: <p​ac85> Stochastic bisecting
13:09 fdobridge_: <p​ac85> It probably makes more sense to test 5 times at each steps though I think
13:10 fdobridge_: <p​ac85> Otherwise you need a run where you are lucky at each step
13:14 fdobridge_: <!​DodoNVK (she) 🇱🇹> is that the only good stochastic thing? 🐸
13:16 fdobridge_: <p​ac85> Mmm I'm not getting it
13:17 fdobridge_: <e​sdrastarsis> Does Nvidia support BC1 tex format?
13:19 fdobridge_: <!​DodoNVK (she) 🇱🇹> When I hear the word "stochastic" I think of stochastic ||terrorism||
13:33 fdobridge_: <g​fxstrand> Yeah, someone needs to go through and audit the entire legalize pass for SM50. I keep hitting stuff there in my spot testing.
13:36 fdobridge_: <g​fxstrand> Damn... That one's still $60.
13:37 fdobridge_: <!​DodoNVK (she) 🇱🇹> So Collabora doesn't have its own Steam library? 🐸
13:38 fdobridge_: <g​fxstrand> We've got some stuff somewhere. It's not extensive, though. I'll have to ask around and see what's what.
13:39 fdobridge_: <g​fxstrand> 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:40 fdobridge_: <g​fxstrand> 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:40 fdobridge_: <m​ohamexiety> I can test that one
13:41 fdobridge_: <m​ohamexiety> will need a bit more time tho since my linux install is kinda smol
13:44 fdobridge_: <d​wlsalmeida> I have some fixes in the MR
13:44 fdobridge_: <d​wlsalmeida> in particular, IAdd3 is broken as we've discussed
13:45 fdobridge_: <g​fxstrand> Yeah, I already merged the ineg one as part of fp64 because I hit it testing fp64 on Maxwell. 🙃
13:45 fdobridge_: <d​wlsalmeida> also I think you had a tiny mistake in the f20 immediates
13:45 fdobridge_: <g​fxstrand> That's entirely possible.
13:46 fdobridge_: <g​fxstrand> Though I think they at least kinda work. The fp64 `frcp` lowering uses them.
13:46 fdobridge_: <d​wlsalmeida> yeah the assert was val & 0xfffff000 == 0
13:47 fdobridge_: <d​wlsalmeida> but we want val & 0x00000fff == 0 unless I missed something
13:47 fdobridge_: <g​fxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26587/diffs?commit_id=73a1acef18fabbfc1699eb3504a3f829dbd7030f
13:47 fdobridge_: <g​fxstrand> Looks like I found and fixed it as part of fp64
13:48 fdobridge_: <d​wlsalmeida> ah yes lol
13:49 fdobridge_: <d​adschoorse> for d3d9/11 games apitraces are often good enough for debugging, and they reasonably easy to capture for users
13:49 fdobridge_: <d​wlsalmeida> @gfxstrand I know you're on vacation, but when you get back can you jump in on this discussion?
13:49 fdobridge_: <g​fxstrand> I was pleasantly surprised by how little I had to fix on order to get the fp64 tests to run on Maxwell. 🙂
13:49 fdobridge_: <!​DodoNVK (she) 🇱🇹> Unfortunately some games don't have one
13:49 fdobridge_: <!​DodoNVK (she) 🇱🇹> Like GTA 5 🐸
13:50 fdobridge_: <g​fxstrand> Yeah but if it's crashing it's hard to get a trace. Or do you mean a trace of the D3D11 API?
13:50 fdobridge_: <!​DodoNVK (she) 🇱🇹> Yes
13:51 fdobridge_: <g​fxstrand> 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:51 fdobridge_: <d​wlsalmeida> @gfxstrand I mean this discussion btw, .P vs .D
13:51 fdobridge_: <d​wlsalmeida> so SUST and SULD are working, but SUATOM is broken
13:51 fdobridge_: <g​fxstrand> Right. Yeah, I just need to read the spec and look at the things.
13:52 fdobridge_: <d​adschoorse> 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:52 fdobridge_: <g​fxstrand> @dwlsalmeida did you get `bitfield_reverse` fixed to use a new op yet?
13:52 fdobridge_: <m​arysaka> I think I have it on steam going to check that
13:52 fdobridge_: <d​wlsalmeida> no, but I can do it today if you want
13:53 fdobridge_: <d​wlsalmeida> I simply updated the PR to add your patch on top, to fix the latency
13:53 fdobridge_: <g​fxstrand> 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:55 fdobridge_: <g​fxstrand> 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:55 fdobridge_: <g​fxstrand> 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:56 fdobridge_: <d​wlsalmeida> no worries Faith, I'll work on it rn
13:56 fdobridge_: <g​fxstrand> Thanks a bunch! 💜
13:58 fdobridge_: <g​fxstrand> 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:59 fdobridge_: <g​fxstrand> Lesson learned: Make the NAK op match the hardware op and don't try to be clever. 😅
14:00 fdobridge_: <g​fxstrand> Incidentally, I'm pretty sure brev is broken in codegen because of this. 🤡
14:00 fdobridge_: <g​fxstrand> Unless there's a special case I'm not seeing
14:01 fdobridge_: <g​fxstrand> Is there a trace library somewhere I should know about?
14:01 fdobridge_: <g​fxstrand> Because that would be REALLY useful...
14:03 fdobridge_: <!​DodoNVK (she) 🇱🇹> I primarily looked at DXVK bug reports
15:26 fdobridge_: <p​rop_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:32 fdobridge_: <g​fxstrand> Okay, that'd be super helpful. Let's chat about that when I get back from holiday
15:48 fdobridge_: <!​DodoNVK (she) 🇱🇹> Is Sims 2 in there? 🐸
16:15 fdobridge_: <p​rop_energy_ball> Yes
16:15 fdobridge_: <p​rop_energy_ball> Sounds good
19:04 juri_: has anyone here used nouveau to do AI inference?
19:05 karolherbst: I'm not sure I've tried....
19:05 karolherbst: but I have rusticl running on openvino
19:05 karolherbst: uhm
19:05 karolherbst: openvino running on rusticl
19:05 karolherbst: juri_: speciifc reason for the question?
19:06 juri_: running an llm in cpu-only, have a ton of old nvidia gear, want more performance.
19:07 karolherbst: I see
19:08 fdobridge_: <r​edsheep> With how VRAM intensive LLMs are older gear might be entirely useless regardless
19:08 karolherbst: 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:08 karolherbst: there might be bugs, but you can report them and then I'm trying to fix those next year
19:08 karolherbst: it's good enough for image classification tho
19:09 karolherbst: but yeah.. bigger llms might not run :D
19:32 airlied: and when you say old nvidia gear, nouveau probably won't reclock it
19:32 karolherbst: ohh that as well
19:32 karolherbst: so it might still be slower than CPU
22:30 Lyude: Oh wow ok, vkms definitely does not seem like a bad idea to port over
22:30 Lyude: there don't seem to be any files in here that aren't less then 500 lines