00:07 fdobridge_: <c​onan_kudo> Fedora uses gcc plugins already 🙂
00:34 Lyude: (is there some other branch I should be looking for those commits from btw? I can't actually seem to figure out their original source)
00:42 airlied: the branches are I think a bit of sprawling mess
00:47 Lyude: gotcha. I'll probably have some DRM interfaces from asahi to get looked at soon as well, figuring out what all I need to get a skeleton drm driver loaded
01:56 Lyude: oh this is weird. was attempting to pull in more drm stuff from asahi and I'm hitting some rather weird compiler errors. https://dpaste.org/hksOk is what I get when trying to build https://gitlab.freedesktop.org/lyudess/linux/-/commits/rvkms-wip . The errors look sensible, but - what's really weird is the commit that makes the errors appear is this one
01:56 Lyude: https://gitlab.freedesktop.org/lyudess/linux/-/commit/cf8b38ccc9435bd4cd255531e3024a97ca1ac39e . And I don't see anything there that even touches the file in question
01:56 Lyude: I'll keep looking tomorrow since it's getting to be time for me to log off, but if anyone has any ideas what might be happening I'd appreciate it. this is very weir
01:58 airlied: Lyude: it might have dead coded maybe before seeing the problem previously
01:59 Lyude: ok - so that is a thing that can happen here
01:59 Lyude: if it's that simple then I can probably figure it out :)
02:01 airlied: not 100% sure just seems like a possibility
02:03 airlied: could also be a bindgen thing, since that's an enum on the C side
02:04 Lyude: yeah - I've gotta double check that as well, I did make sure at least that it doesn't seem like outdated bindgen files
02:04 airlied: so maybe a newer bindgen is making enum into i32 instead of u32
02:04 airlied: but yeah dir as i32 should be fine
02:05 Lyude: sgtm
02:47 noocsharp: hi, i'm looking at the nouveau code for the first time trying to understand how the graphics card initializes. i can't find where the devinit field in the nvkm_device_chip structs is actually used. any pointers?
02:59 airlied: noocsharp: all the subdevice and engines are in layout.h
03:00 airlied: they get called in order
03:00 airlied: at the end of nvkm/engine/device/base.c
03:03 noocsharp: ah i see, thanks
05:03 Ilgaz: Should I post a comment to my bug report about nouveau that I switched to some Debian/Ubuntu based distribution for the time being or it would be needless to announce it?
05:04 Ilgaz:thinking about testing etc
08:46 fdobridge_: <!​DodoNVK (she) 🇱🇹> These are the million padding variables for reference (and I still can't run vkcube with this)
08:46 fdobridge_: <!​DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1196737271811031131/message.diff?ex=65b8b76f&is=65a6426f&hm=f3e5479bfb2842215a7d5cdf391ecf9835fe8479386d923ce24ce0b2f8db2021&
09:07 fdobridge_: <t​riang3l> Is the shader cache not separate for 32-bit and 64-bit? 🥵
09:09 fdobridge_: <p​ixelcluster> why should shader code be different for 32bit vs 64bit?
09:13 fdobridge_: <!​DodoNVK (she) 🇱🇹> It of course isn't :transgears:
09:18 fdobridge_: <t​riang3l> uint64_t padding 🤷‍♂️
09:19 fdobridge_: <t​riang3l> Unless serialization of them is done with a smol #pragma pack
09:19 fdobridge_: <p​ixelcluster> whut
09:20 fdobridge_: <p​ixelcluster> you generally serialize each primitive type on its own
09:20 fdobridge_: <t​riang3l> Different alignof(uint64_t) when it's loaded using two instructions vs. one
09:21 fdobridge_: <p​ixelcluster> are you talking about gpu instructions?
09:21 fdobridge_: <p​ixelcluster> what do those have to do with whether the host is 32 or 64bit
09:22 fdobridge_: <t​riang3l> no, C structures with various metadata, but if those are serialized number by number that should be fine
11:54 fdobridge_: <k​arolherbst🐧🦀> I see that nak doesn't support `uror`/`urol` yet...
11:54 fdobridge_: <k​arolherbst🐧🦀> in case somebody wants to do some coding 😄
12:02 fdobridge_: <k​arolherbst🐧🦀> please on top of this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27090
12:03 fdobridge_: <k​arolherbst🐧🦀> so it can be 32 bit only
12:03 fdobridge_: <k​arolherbst🐧🦀> because I think the other bit sizes are not really implementable directly
12:04 fdobridge_: <k​arolherbst🐧🦀> or maybe I do it? though I wouldn't know how to test it 🥲
12:04 fdobridge_: <k​arolherbst🐧🦀> mhh.. I think there are crucible tests for it?
12:04 fdobridge_: <t​om3026> that MR hit the label jackpot
12:04 fdobridge_: <k​arolherbst🐧🦀> I've seen worse 😄
12:07 fdobridge_: <k​arolherbst🐧🦀> mhh actually, seems to tie with another MR of mine
12:39 fdobridge_: <d​adschoorse> I was about to say, maybe we don't need rotate in nir at all and instead we could have shift with funnel in, which both amd and nvidia have
12:39 fdobridge_: <d​adschoorse> but it looks like intel supports real rotate but no funnel shift 😦
12:40 fdobridge_: <k​arolherbst🐧🦀> yeah...
12:41 fdobridge_: <k​arolherbst🐧🦀> though.. isn't that the same, more or less?
12:42 fdobridge_: <k​arolherbst🐧🦀> well mhh
12:42 fdobridge_: <k​arolherbst🐧🦀> it's more a modifier thing.. like does it wrap around or doesn't it
12:42 fdobridge_: <k​arolherbst🐧🦀> mhhh
12:42 fdobridge_: <k​arolherbst🐧🦀> wait
12:43 fdobridge_: <k​arolherbst🐧🦀> that's about the shift..
12:43 fdobridge_: <k​arolherbst🐧🦀> uhhh
12:43 fdobridge_: <k​arolherbst🐧🦀> pain
12:43 fdobridge_: <k​arolherbst🐧🦀> why are there 1000 ways to shift
12:47 fdobridge_: <d​adschoorse> well rotate is a funnel shift where two input are the same
12:50 fdobridge_: <k​arolherbst🐧🦀> yeah.. fair
15:45 fdobridge_: <g​fxstrand> `util/blob.c` does `blob_align(blob, sizeof(type))`
15:45 fdobridge_: <g​fxstrand> If you have a uint64_t in a struct, though... 😬
15:49 fdobridge_: <g​fxstrand> I think the thing that saves us is that pipeline cache UUIDs usually start with some sort of build ID or timestamp. That's going to be different on the 32-bit build.
16:57 Lyude: dakr: huh https://gitlab.freedesktop.org/lyudess/linux/-/commit/cd2a7b5582bdcab80bd38e7c79ac71a944859281#bbf1006d93913190dde2cb4370743ff99401ecb6_377_372 does the kernel not have vec![] implemented yet? I noticed you've got vec! mentioned in some of the comments there
16:59 fdobridge_: <g​fxstrand> Lyude, I don't think `vec![]` is directly implementable because it allocates memory and assumes it can't fail.
17:00 fdobridge_: <g​fxstrand> Some sort of `try_vec![]` might be possible.
17:05 Lyude: ahhh
17:07 Lyude: yeah that makes sense. fwiw too we probably could use a byte array there too dakr, will leave a comment with what I mean once I go out and shovel some snow first
17:08 Fijxu: Some day nvidia will release the firmware for the pascal arch
17:08 Fijxu: I hope so
17:09 Lyude: it would be nice but don't hold your breath, there's a lot more firmware limitations on pascal then turing+
17:10 Fijxu: firmware limitations?
17:10 Fijxu: like what
17:13 dakr: Lyude: that code is from airlied originally, I just got rid of all the warnings to be able to spot stuff the compiler yells at me for new code.
17:14 dakr: If you see anything that can be improved in general, please let me know. I'm entirely new to Rust, so I might simply not know what I'm doing. :-)
17:35 fdobridge_: <b​enjaminl> @gfxstrand https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27065#note_2240737 is there a ptx instruction for frnd? I spent a bit looking for one when I was originally debugging these test failures
17:40 fdobridge_: <g​fxstrand> I think it's just `cvt`
17:40 fdobridge_: <g​fxstrand> But I'm not sure
17:55 fdobridge_: <t​tabi1> I just received about 60 messages that were two months old, apparently they were stuck in freedesktop.org's mail server:
17:55 fdobridge_: <t​tabi1> Received: from gabe.freedesktop.org (localhost [])
17:55 fdobridge_: <t​tabi1> by gabe.freedesktop.org (Postfix) with ESMTP id 0D73210E4EA;
17:55 fdobridge_: <t​tabi1> Tue, 16 Jan 2024 11:47:38 +0000 (UTC)
17:55 fdobridge_: <t​tabi1> X-Original-To: nouveau@lists.freedesktop.org
17:55 fdobridge_: <t​tabi1> Delivered-To: nouveau@lists.freedesktop.org
17:55 fdobridge_: <t​tabi1> Received: from mgamail.intel.com (mgamail.intel.com [])
17:55 fdobridge_: <t​tabi1> by gabe.freedesktop.org (Postfix) with ESMTPS id 37D4A10E288;
17:55 fdobridge_: <t​tabi1> Thu, 16 Nov 2023 12:50:33 +0000 (UTC)
18:07 Lyude: Fijxu: there's a lot less memory available to run firmware on with pascal iirc, I don't remember the details past that though
18:43 Lyude: dakr: ah nevermind, it was me that was mistaken :P
18:51 airlied: yeah I had to ask on zulip about the vec! thing, and yes it's because of memory allocations we can't have it
18:52 airlied: hence why I hacked the code to get me over the line, need to consider how a const vec of chars might look
18:55 Lyude: yeah I could have sworn there was an easier way to do bytestring constants but I might have just been thinking of b''
19:01 fdobridge_: <b​enjaminl> yeah wait... you could avoid this problem by having `findbytes` take a `&[u8]`
19:02 fdobridge_: <b​enjaminl> and then using `[u8; 5]` literals instead of a `Vec<u8>` in `probe`
19:10 fdobridge_: <a​irlied> indeed that seems like a better plan 🙂
22:19 noocsharp: in the proprietary nvidia driver, where is the firmware located for pre-gsp cards? in the kernel module?
23:01 karolherbst: yes
23:33 fdobridge_: <g​fxstrand> Yeah, `&[T]` is usually the best plan.
23:41 fdobridge_: <g​fxstrand> Shall we see what happens when I try to do a 1.3 run on Ampere? I think we shall...
23:57 fdobridge_: <g​fxstrand> I'm gonna shard it in 4, just in case.