00:02 fdobridge: <k​arolherbst🐧🦀> writing a gallium driver in rust should be pretty straightforward
00:03 fdobridge: <k​arolherbst🐧🦀> it's almost like rusticl that you just provide some API callbacks and have some bindings
00:03 fdobridge: <k​arolherbst🐧🦀> though we do have some annoying static inlines which are a pain
00:03 i509vcb: From what I saw in gallium, it's pretty much just a bit function table and some void pointer for dafa
00:03 i509vcb: *data
00:03 fdobridge: <k​arolherbst🐧🦀> yeah
00:03 i509vcb: Two typos...
00:04 fdobridge: <k​arolherbst🐧🦀> the annoying part is, that the gallium API contains lots of silly fixes for silly and broken compilers, soo...
00:05 fdobridge: <k​arolherbst🐧🦀> so things which should actually be `enum whatever` are just `unsigned`
00:05 fdobridge: <k​arolherbst🐧🦀> and that makes the binding situation a bit more of a pita
00:15 Lyude: tbh i'd love to see us have the kernel driver in rust someday too
00:16 airlied: I think a gsp one would be possible though skeggsb things I'm underestimating the pain :-P
00:16 Lyude: it would also be nice for us to actually use crates in some form if we aren't in mesa tbh, there's a lot of really useful stuff I don't think is really productive to reimplement ourselves
00:17 Lyude: airlied: if rust is involved i will go through infinite pain because i like rust that much :)
00:17 Lyude:still in disbelief over how quickly she can get stuff done with neovim-gtk in rust
00:19 airlied: gotta a day of learning soon I intend to burn on rust, just not sure where to burn it
00:21 fdobridge: <g​fxstrand> NAK requires 3 crates. That's why I'm using crazy branches.
00:22 i509vcb: Mesa is going to need cargo somewhere unless we want to reinvent the wheel
00:22 i509vcb: Or vendor everything under the sun and write a meson script for everything we vendor
00:22 airlied: the problem with mesa using cargo is distros run into problems
00:23 airlied: and mesa is a pretty core system component
00:23 airlied: esp when you get into we just need this one dep, which then has 20 deps
00:25 fdobridge: <g​fxstrand> When I say "NAK requires 3 crates" that's the entire dependency chain and they're only required at build time for a proc macro. No creates are actually linked in.
00:26 i509vcb: Firefox I think has 300 crates (including dependencies of dependenies) and seems to manage
00:26 fdobridge: <g​fxstrand> If we have to maintain meson wraps for syn, proc-macro2, and quote, that's not the end of the world.
00:27 fdobridge: <g​fxstrand> I'd like to be able to use some other crates, though.
00:27 fdobridge: <g​fxstrand> I'm definitely duplicating a bit
00:28 fdobridge: <g​fxstrand> At the moment, Dylan's plan is basically "re-implement cargo in meson" and IDK that that's a great plan but I'm choosing to focus on writing a driver, not a build system.
00:30 i509vcb: I'm skeptical that will be maintainable long term if more than a few crates will be used
00:30 Lyude: also, anything separate from cargo is in itself kind of padding upstream
00:31 Lyude: IMO it makes more sense for us to stick close to the rust community with this stuff, because yeah - we don't really want to be maintaining our own build system, or adding extra friction when it comes to using other crates
01:24 fdobridge: <g​fxstrand> Tell that to Dylan
01:24 fdobridge: <g​fxstrand> I'm staying out of it for now
01:29 fdobridge: <k​arolherbst🐧🦀> yeah.. firefox already added all the pain
01:29 fdobridge: <k​arolherbst🐧🦀> might just as well rely on that
01:29 fdobridge: <k​arolherbst🐧🦀> 😄
01:35 fdobridge: <g​fxstrand> Honestly, I'm more interested in nightly features than creates most of the time. 🫤
01:36 fdobridge: <k​arolherbst🐧🦀> that bad? I'm still sticking to 1.57, but maybe I should check what I can use to clean up some of the code, though the biggest todo thing is still using `serde`
01:36 fdobridge: <k​arolherbst🐧🦀> also `num-integer` helps not needing nightly for some things
01:36 fdobridge: <g​fxstrand> For Vulkan, I want the allocator feature.
01:36 fdobridge: <g​fxstrand> And integer rounding
01:37 fdobridge: <g​fxstrand> But that one's easy enough to just implement myself
01:37 fdobridge: <k​arolherbst🐧🦀> or use `num-integer` 😛
01:37 fdobridge: <g​fxstrand> Or that
01:37 fdobridge: <k​arolherbst🐧🦀> which I also think about using so I can drop some util code
01:37 fdobridge: <k​arolherbst🐧🦀> they usually use the same method names as the nightly stuff, so at some day you can just drop it
01:37 fdobridge: <g​fxstrand> But new_in for Box and Vec would be really nice
01:37 fdobridge: <k​arolherbst🐧🦀> yeah...
01:37 fdobridge: <g​fxstrand> Yup
01:38 fdobridge: <k​arolherbst🐧🦀> I hand waved _a_lot_ on the memory error handling in rusticl for now
01:38 fdobridge: <k​arolherbst🐧🦀> I hand waved _a lot_ on the memory error handling in rusticl for now (edited)
01:38 fdobridge: <k​arolherbst🐧🦀> but yeah... having the stuff available to catch allocation errors will be helpful
01:39 fdobridge: <g​fxstrand> That's not too hard to deal with.
01:39 fdobridge: <k​arolherbst🐧🦀> well.. atm there is no way to do with it
01:40 fdobridge: <g​fxstrand> My VkBox type returns `Result<VkBox, VkResult>`
01:40 fdobridge: <g​fxstrand> So it's hand rolled exactly the one place
01:40 fdobridge: <g​fxstrand> Everything else just uses ?
01:40 fdobridge: <k​arolherbst🐧🦀> ohh sure, but what if you allocate a Vec and it panics because of no memory?
01:41 fdobridge: <k​arolherbst🐧🦀> or well.. something else
01:41 fdobridge: <g​fxstrand> Yeah... I don't have a VkVec.
01:41 fdobridge: <k​arolherbst🐧🦀> they are working on it for the kernel anyway, but I'm not sure if that will ever find its way into normal rust
01:43 fdobridge: <k​arolherbst🐧🦀> ohh wait..
01:43 fdobridge: <g​fxstrand> Yeah, I don't think the rust folks have a plan to deal with allocation failure besides `panic!`
01:43 fdobridge: <k​arolherbst🐧🦀> there is `Vec::try_reserve` mhhh
01:44 fdobridge: <g​fxstrand> Yeah, I don't think you'd want to use that for everything.
01:44 fdobridge: <k​arolherbst🐧🦀> thinking the same
01:44 fdobridge: <g​fxstrand> IDK how you'd want vec to work. 🤔
01:45 fdobridge: <k​arolherbst🐧🦀> well Vec::new doesn't allocate storage anyway, so it's like a few bytes, but yeah...
01:45 fdobridge: <g​fxstrand> try_push, I guess
01:46 fdobridge: <k​arolherbst🐧🦀> yeah.. maybe
01:47 fdobridge: <k​arolherbst🐧🦀> I think I forgot if I asked or not, but will you be at fosdem?
01:53 fdobridge: <k​arolherbst🐧🦀> @gfxstrand `Earlier this year, rusticl merged into Mesa` you've been working on the text for a while, weren't you? 😛
01:53 fdobridge: <k​arolherbst🐧🦀> @gfxstrand `Earlier this year, rusticl merged into Mesa` you've been working on the text for a while, haven't you? 😛 (edited)
02:10 fdobridge: <g​fxstrand> Oops. I'll tell Mark to fix that
02:10 fdobridge: <g​fxstrand> No
02:15 fdobridge: <g​fxstrand> Fixed
02:36 pabs: Lyude, airlied, i509vcb, g​fxstrand, k​arolherbst: distro opinions go like this: some distros like Debian can now cope somewhat with cargo deps. never do vendoring, dep pinning or bumping dep minimum versions without reason please. Rust/LLVM's architecture support is less than GCC, although there are in-progress ways to deal with that (gccrs, rustc_codegen_gcc, mrustc). Rust isn't bootstrappable solely from source, but gccrs/mrustc can maybe he
02:36 pabs: lp. Firefox/Chromium are ridiculous but get a pass because they are too-big-to-fail
02:55 karolherbst: same would be valid for mesa
03:22 fdobridge: <g​fxstrand> No one cares about a Vulkan driver on any of the hardware Rust doesn't have 1st class support for.
03:23 fdobridge: <g​fxstrand> Or maybe I'm missing the argument
03:30 i509vcb: rust is first class (or tier 2) on pretty much all the hardware that I've seen people care about
03:30 i509vcb: x86, aarch64, riscv64gc (I did buy that little SBC with the imagination gpu), mips, ppc
03:30 i509vcb: Although I imagine there is something I haven't covered
11:53 fdobridge: <E​sdras Tarsis> I was testing DXVK on NVK yesterday and DXVK_HUD made me laugh 🐸
11:53 fdobridge: <E​sdras Tarsis> https://cdn.discordapp.com/attachments/1034184951790305330/1071035621252026429/02-02-23-193248-SCREEN.png
11:54 RSpliet: i509vcb: any luck improving imagination's open source driver to work on that SBC? :-P
16:40 i509vcb: there was a yocto image somewhere that had a heavily patched mesa and a patched kernel
21:27 fdobridge: <J​., Echo (she) 🇱🇹> @Esdras Tarsis Try NFS Most Wanted (2005) at 1080p max settings with DXVK 😈
21:29 fdobridge: <E​sdras Tarsis> Which will crash first, the gpu or xorg? 🐸
21:30 fdobridge: <J​., Echo (she) 🇱🇹> i wonder if NVK is compatible with the default Arch Linux kernel (so I can try it myself)
21:35 fdobridge: <E​sdras Tarsis> yeah is compatible, but using 00.06-gr-ampere branch from Ben's repository is recommended
21:45 fdobridge: <J​., Echo (she) 🇱🇹> I wonder what that branch adds
21:46 fdobridge: <J​., Echo (she) 🇱🇹> I know that another branch added broken GSP support (we know it's at least broken on TU117)
22:04 fdobridge: <W​aelUnix> wait, DXVK's already working???
22:04 fdobridge: <W​aelUnix> gotta compile mesa asap
22:04 fdobridge: <W​aelUnix> gotta recompile mesa asap (edited)
22:05 fdobridge: <R​hedox> ancient dxvk
22:05 fdobridge: <R​hedox> works with simple things
22:18 fdobridge: <E​sdras Tarsis> And some extensions enabled on nvk
22:19 fdobridge: <W​aelUnix> hmm since when did mesa required zstd to build 🤨
22:19 fdobridge: <E​sdras Tarsis> @WaelUnix for reference
22:21 fdobridge: <W​aelUnix> wow that is quite ancient
22:22 fdobridge: <W​aelUnix> lm_sensors too?
22:22 fdobridge: <E​sdras Tarsis> Yeah, the latest dxvk version require vulkan 1.3 and nvk is vulkan 1.0 🐸
22:22 fdobridge: <E​sdras Tarsis> 1.5.1 is the last version that supports vulkan 1.0
22:23 fdobridge: <W​aelUnix> it's 3 years old but it seems to have been running games
22:25 fdobridge: <W​aelUnix> \*fan spinning sounds\*
22:25 fdobridge: <W​aelUnix> https://cdn.discordapp.com/attachments/1034184951790305330/1071194725371097208/image.png
22:25 fdobridge: <W​aelUnix> that's totally mesa 22.0.4 😉
22:26 fdobridge: <J​., Echo (she) 🇱🇹> wael sounds familiar
22:33 fdobridge: <W​aelUnix> 🧊 vkcube 🧊
22:33 fdobridge: <W​aelUnix> https://cdn.discordapp.com/attachments/1034184951790305330/1071196681342828655/image.png
22:33 fdobridge: <W​aelUnix> gotta say it's nice having wl_roots not flicker on nvidia for once
22:34 fdobridge: <W​aelUnix> too bad this is probably nouveau and not nvk cause gles 😢
22:34 fdobridge: <W​aelUnix> so probably not as accelerated
22:35 fdobridge: <W​aelUnix> gotta say it's nice having wlroots not flicker on nvidia for once (edited)
22:46 fdobridge: <W​aelUnix> downloading dota2 atm to test nvk
22:47 fdobridge: <W​aelUnix> oh, steam doesn't run 😂
22:47 fdobridge: <W​aelUnix> it crashes at some glx call, xwayland issue?
22:57 Lyude:back on nouveau kernel work :)
22:59 Ermine: Yay!