00:01fdobridge: <gfxstrand> IDK if the code I wrote today is brilliant or evil....
00:09fdobridge: <marysaka> I would say both as proc macros are always evil 😄
00:49fdobridge: <karolherbst🐧🦀> I think proc macros are inherently a good thing though
00:49fdobridge: <karolherbst🐧🦀> because the alternatives are even worse
00:49fdobridge: <karolherbst🐧🦀> allows you to ease development without adding painful macros or other silly things
00:50fdobridge: <karolherbst🐧🦀> and I think I'd also like to use them for some things
01:06fdobridge: <gfxstrand> Yeah, proc macros are a bit evil but if you're choice is between a proc macro and writing a bit of python code to attempt to parse rust and generate more rust or if you're considering moving a bunch of stuff to XML and generating rust, maybe consider a proc macro.
01:07fdobridge: <karolherbst🐧🦀> I really want to use serde in rusticl though.. I don't want to write my own serialization code 🥲
01:08fdobridge: <karolherbst🐧🦀> (or something less huge)
01:11fdobridge: <marysaka> Oh yeah totally, proc macro is a necessary evil, I just still have nightmares of syn before 1.0… but the situation is definitely not the same as 5-6 years ago and I still need to accept that :nya_panic:
01:12fdobridge: <marysaka> Oh I suppose you cannot have vendored crates? :nya_sad:
01:14fdobridge: <karolherbst🐧🦀> it's more like I don't want to pull in tons of deps
01:15fdobridge: <karolherbst🐧🦀> though it seems that serde on its own isn't all that huge actually
01:15fdobridge: <karolherbst🐧🦀> uhh.. it gets worse
01:15fdobridge: <karolherbst🐧🦀> ehh wait
01:16fdobridge: <karolherbst🐧🦀> `unicode-ident` + `proc-macro2` + `quote` + `syn`
01:16fdobridge: <karolherbst🐧🦀> that's not soo much
01:16fdobridge: <karolherbst🐧🦀> (and syn pulls in the former anyway)
01:16fdobridge: <karolherbst🐧🦀> @gfxstrand okay.. if you depend on `syn` I won't feel bad for using `serde` because that's just +1 dep 😄
01:16fdobridge: <gfxstrand> Heh
01:17fdobridge: <karolherbst🐧🦀> I suspect it gets worse once I want to use some fancy data formats, like json or something
01:17fdobridge: <karolherbst🐧🦀> but I really just want to dumb a blob
01:17fdobridge: <gfxstrand> You can't write proc macros without syn. I mean, you can but.... No. Don't do that.
01:18fdobridge: <karolherbst🐧🦀> well.. I don't want to write a proc macro, I just want to use serde, which implements one
01:18fdobridge: <gfxstrand> Yup
01:18fdobridge: <karolherbst🐧🦀> `#[derive(Serialize, Deserialize)` is quite nice
01:18fdobridge: <karolherbst🐧🦀> do we have proper crate support in meson yet or is it still a pita?
01:19fdobridge: <gfxstrand> I'm depending on a meson branch right now.
01:19fdobridge: <karolherbst🐧🦀> right.. which is fine for you to do, but not for me 😦
01:20fdobridge: <karolherbst🐧🦀> well.. now you can deal with all the missing features, I've done so in the past already 🙃
01:20fdobridge: <gfxstrand> Yeah...
01:20fdobridge: <karolherbst🐧🦀> ehh wait.. serde can deserialize token streams? 😄
01:20fdobridge: <karolherbst🐧🦀> fun
01:21fdobridge: <gfxstrand> Why not?
01:22fdobridge: <gfxstrand> But, yeah, I generally consider serde to be an acceptable dependency.
01:22fdobridge: <karolherbst🐧🦀> better than writing the dump code yourself anyway
01:22fdobridge: <karolherbst🐧🦀> better than writing the dumb code yourself anyway (edited)
01:23fdobridge: <gfxstrand> The next step is to rework NAK with my fancy new trait and see how I like it.
01:33i509vcb: A bit off topic, it would be neat to see a Vulkan ICD in Rust as well
01:35i509vcb: But that's not a thing Mesa could easily adopt
02:01fdobridge: <gfxstrand> There's chatter of that.
02:01fdobridge: <gfxstrand> I'd like to see it happen.
02:03i509vcb: I did play with the idea, what I ended up with was a Driver trait with a bunch of assoicated types to represent objects. Then a macro invocation to deal with all the dispatch madness. Extensions would just be implemented with extension traits and another macro for dispatch
02:04i509vcb: Although it was a simple "hello world" icd with no physical devices or any implementation
02:04i509vcb: Maybe some day I'll experiment with a compute only driver to test the idea I had fully
02:07i509vcb: And maybe figure out if I could use the allocator for objects without resorting to frankly absurd amounts of unsafe
03:04fdobridge: <gfxstrand> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20298
14:35ilgaz: nouveau 22.3.3 has many multi threading enhancements on nvidia 9400 right? Interestingly firefox vaapi video acceleration still shows same quirks and eventually freezes the OS :-(
14:36i509vcb: Wouldn't it make more sense to use ash for the Rust vulkan infrastructure? It has a match_struct macro for the sType matching
14:41karolherbst: ilgaz: I see.. I guess I have to check that out and see what's missing there. But would you still say the situation improved a lot overall? Could also be that I was just testing nv50 less than nvc0
14:42ilgaz: karolherbst: It takes a long time to freeze now, the glitchy blue/green decoding is still there. I have seen something like "vaapi error 7", I will test further
14:42karolherbst: okay
14:42karolherbst: probably just some error in the code then
14:43karolherbst: having a quick reproduce of that issue would help though
14:43ilgaz: It was 3-4 secs and entire system freeze before. Now I can see console errors etc on journalctl -f
14:44karolherbst: right.. I suspect we just push garbage or wrong things into the command buffer and crash the GPU.. but now that we actually have the class headers for video as well, it might be easier to track those down
14:44karolherbst: ehh wait
14:44karolherbst: those headers are turing+ :')
14:48ilgaz: omg it worked now
14:48ilgaz: This is the worst thing eh? no changes, it works
14:49ilgaz: I was able to reproduce the exact same graphics lol
14:49karolherbst: mhh, maybe some unitialized memory or something
14:51ilgaz: when video recycled (I think), glitch came back. I see "Jan 20 17:49:11 mbt kernel: nouveau 0000:02:00.0: imem: OOM: 00100000 00001000 -28" and "Jan 20 17:51:04 mbt kernel: nouveau 0000:02:00.0: fifo: CACHE_ERROR - ch 3 [systemd-logind[787]] subc 0 mthd 0060 data beef0201"
14:51karolherbst: ohhh
14:51karolherbst: right...
14:52karolherbst: so that probably means we are running out of imem
14:52ilgaz: but I am used to CACHE_ERROR while using wayland/kde
14:52karolherbst: and the cache error might be a weird timeout thing...
14:52karolherbst: ilgaz: mind ramping up the pstate thing to max? that might help with the CACHE_ERRORs
14:52ilgaz: karolherbst: btw KDE guys did an amazing job recently. It is totally usable with wayland now
14:53ilgaz: karolherbst: how do I do it? pstate?
14:53karolherbst: /sys/kernel/debug/dri/0/pstate
14:54karolherbst: cat it to see what perf states are available
14:58ilgaz: karolherbst: I notice "Jan 20 17:53:19 mbt plasmashell[12383]: libva info: va_openDriver() returns 2" sometimes. It does not indicate an error right?
15:04Ilgaz: sorry. system frozen because of video.
15:04Ilgaz: karolherbst: I can easily say it was way worse before.
15:05Ilgaz: I should install firefox nightly and test with it.
15:13Ilgaz: karolherbst: with firefox nightly video is played all fine
15:13Ilgaz: I will keep testing and report to this place https://bugzilla.mozilla.org/show_bug.cgi?id=1780962
15:14Ilgaz: I better tell so they don`t change anything lol
15:23Ilgaz: karolherbst: heh 20-23% CPU with embedded 720p h264 video.
16:36karolherbst: yeah... nouveau does some stupid stuff