01:43 airlied: Lyude: so if I use a 2080 card it brings up this monitor, but the 2080Ti doesn't
03:38 fdobridge: <g​fxstrand> airlied: It turns out you can take down this kernel. 🙂
03:39 fdobridge: <g​fxstrand> Just have to throw enough shader infinite loops at it.
04:24 fdobridge: <a​irlied> any nice crashes or just goes away and stops talking?
08:41 fdobridge: <n​anokatze> <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/vulkan/nvk_cmd_draw.c#L1475> this comment seems kinda wrong?
08:48 fdobridge: <m​arysaka> no it's valid as it does `uint32_t nv9097_face = 0x900 | (1 - vk_face);` so:
08:48 fdobridge: <m​arysaka> - `VK_FRONT_FACE_COUNTER_CLOCKWISE` (0) will be `NV9097_OGL_SET_FRONT_FACE_V_CCW` (0x901)
08:48 fdobridge: <m​arysaka> - `VK_FRONT_FACE_CLOCKWISE` (1) will be `NV9097_OGL_SET_FRONT_FACE_V_CW` (0x900)
08:49 fdobridge: <n​anokatze> well the number makes sense but the enum name is the right one
08:50 fdobridge: <n​anokatze> the way I interpreted it was that it was saying that for vk ccw you'd want hw cw enum
08:50 fdobridge: <r​hed0x> the comment doesn't match the lookup table that's used for the assert though
08:50 fdobridge: <r​hed0x> at least the way I read it
08:50 fdobridge: <n​anokatze> the comment is apparently talking about the integer value of the enum
08:51 fdobridge: <m​arysaka> the index isn't really the enum value here
08:51 fdobridge: <m​arysaka> imo the lut should probably just have the correct value instead of that weird invert thing
08:52 fdobridge: <n​anokatze> :confusion:
08:52 fdobridge: <m​arysaka> (like what we have everywhere else, see vk_to_nv9097_cull_mode for example)
08:53 fdobridge: <m​arysaka> yeah no I'm confused now :nya_confused:
08:55 fdobridge: <m​arysaka> we could just use the lut directly and update the comment I guess? :aki_thonk:
08:55 fdobridge: <n​anokatze> yes, the comment part at least 🐸
08:56 fdobridge: <m​arysaka> I will do a quick MR later then 👍
09:10 fdobridge: <!​DodoNVK (she) 🇱🇹> I managed to find a table of actual GPU names in the nouveau driver 🐸
09:19 fdobridge: <S​id> do you mean the kernel driver?
09:19 fdobridge: <!​DodoNVK (she) 🇱🇹> Yes
09:21 fdobridge: <S​id> huh
09:24 fdobridge: <!​DodoNVK (she) 🇱🇹> The catch is that it only has old-ish hardware
09:42 fdobridge: <!​DodoNVK (she) 🇱🇹> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28262 :nouveau:
09:49 fdobridge: <S​id> we could add (NVK chipsetName) by default
09:50 fdobridge: <S​id> again, to maintain consistency with other drivers
09:54 fdobridge: <!​DodoNVK (she) 🇱🇹> `chipsetName (NVK chipsetName)` feels weird
09:54 fdobridge: <S​id> oh I meant
09:54 fdobridge: <S​id> marketingName (NVK chipsetName)
09:58 fdobridge: <S​id> like
09:59 fdobridge: <S​id> NVIDIA GeForce GTX 1660Ti Mobile (NVK TU116M)
10:05 fdobridge: <!​DodoNVK (she) 🇱🇹> That's what that patch should do
10:06 fdobridge: <S​id> ah okie
13:53 mupuf: Good call, DodoNVK
14:23 fdobridge: <k​arolherbst🐧🦀> @gfxstrand did anybody ever check what nvidia is doing around those priv_reg mme calls? Maybe that explains how the other path works? maybe they just put up a semaphore or something
14:27 fdobridge: <m​arysaka> I have some dump somewhere if you want but from what I recall the parser start acting weird a bit after those calls
14:28 fdobridge: <k​arolherbst🐧🦀> mhhh...
14:28 fdobridge: <m​arysaka> https://paste.centos.org/view/61c4eb8b
14:28 fdobridge: <m​arysaka> they load macros and then do the calls (see `NVC597_CALL_MME_MACRO(35)` calls)
14:29 fdobridge: <k​arolherbst🐧🦀> mhhh...
14:29 fdobridge: <k​arolherbst🐧🦀> `NVC597_SET_MME_SHADOW_SCRATCH(26)` mhhh
14:29 fdobridge: <k​arolherbst🐧🦀> that's the one we also use, no?
14:29 fdobridge: <m​arysaka> yeah it set to 0, maybe the if was inverted :nya_panic:
14:30 fdobridge: <k​arolherbst🐧🦀> they set some of them explicitly
14:30 fdobridge: <k​arolherbst🐧🦀> but also what is macro 99 doing...
14:31 fdobridge: <k​arolherbst🐧🦀> `[0x000010ec] HDR 1fff0 subch 7 mthd 3fc0 ` uhh pain
14:31 fdobridge: <k​arolherbst🐧🦀> I think the parser might not handle unknown subchannels very well
14:31 fdobridge: <k​arolherbst🐧🦀> but uhhh
14:31 fdobridge: <k​arolherbst🐧🦀> that also looks like a float
14:31 fdobridge: <m​arysaka> do you want the blob of it?
14:32 fdobridge: <k​arolherbst🐧🦀> not really
14:32 fdobridge: <k​arolherbst🐧🦀> but yeah.. the parser is acting up
14:33 fdobridge: <m​arysaka> what would sub channel 7 be...?
14:33 fdobridge: <k​arolherbst🐧🦀> nahh.. I think that's already running into a bug
14:34 fdobridge: <k​arolherbst🐧🦀> mhhh
14:34 fdobridge: <k​arolherbst🐧🦀> maybe not?
14:34 fdobridge: <k​arolherbst🐧🦀> @marysaka 7 is probably software
14:35 fdobridge: <m​arysaka> from what I can see we hardcode each subchannel atm
14:35 fdobridge: <m​arysaka> do we have headers for that channel?
14:35 fdobridge: <k​arolherbst🐧🦀> there are no headers fo that, because it's defined in software
14:36 fdobridge: <k​arolherbst🐧🦀> do you know the `SET_OBJECT` they invoke on the subchannel 7?
14:36 fdobridge: <k​arolherbst🐧🦀> but anyway.. it's all defined in the kernel
14:36 fdobridge: <k​arolherbst🐧🦀> or GSP... dunno
14:36 fdobridge: <k​arolherbst🐧🦀> the kernel gets an interrupt and handles the method
14:36 fdobridge: <k​arolherbst🐧🦀> at least that's what nouveau does on 7
14:40 fdobridge: <m​arysaka> There is no SET_OBJECT
14:41 fdobridge: <m​arysaka> There is no SET_OBJECT for it (edited)
14:41 fdobridge: <k​arolherbst🐧🦀> pain
14:42 fdobridge: <m​arysaka> tho the parser shouldn't really be breaking apart on it it's weird...
14:42 fdobridge: <m​arysaka> sure the detail is missing but the parsing should be working like normal...
14:42 fdobridge: <k​arolherbst🐧🦀> yeah...
14:43 fdobridge: <k​arolherbst🐧🦀> maybe there is just random nonsens...
14:45 fdobridge: <k​arolherbst🐧🦀> it's a bit weird that the header is `0x0001fff0`
14:45 fdobridge: <k​arolherbst🐧🦀> mhh.. let's see...
14:46 fdobridge: <k​arolherbst🐧🦀> ohh yeah...
14:46 fdobridge: <k​arolherbst🐧🦀> that's not handled at all
14:46 fdobridge: <m​arysaka> what is that for?
14:46 fdobridge: <k​arolherbst🐧🦀> `type == 0` is not handled
14:46 fdobridge: <k​arolherbst🐧🦀> type is bits 31:29
14:47 fdobridge: <k​arolherbst🐧🦀> let's see...
14:48 fdobridge: <m​arysaka> ``GRP0_USE_TERT`` :nya_confused:
14:48 fdobridge: <k​arolherbst🐧🦀> yeah...
14:48 fdobridge: <k​arolherbst🐧🦀> 2 as well
14:48 fdobridge: <m​arysaka> oh is that the thing that redirect to the secondary opcode
14:48 fdobridge: <k​arolherbst🐧🦀> no idea what it does
14:49 fdobridge: <k​arolherbst🐧🦀> ehhh mhhh
14:49 fdobridge: <k​arolherbst🐧🦀> I have no idea
14:49 fdobridge: <k​arolherbst🐧🦀> but anyway.. that's the issue 😄
14:49 fdobridge: <k​arolherbst🐧🦀> should probably print an error and bail for now
14:50 fdobridge: <m​arysaka> I have some ideas actually considering the headers
14:50 fdobridge: <m​arysaka> tho it might talk to something weird...
14:52 fdobridge: <k​arolherbst🐧🦀> yeah.... maybe?
14:52 fdobridge: <k​arolherbst🐧🦀> sooo
14:52 fdobridge: <k​arolherbst🐧🦀> let's look at it from a data perspective
14:52 fdobridge: <k​arolherbst🐧🦀> 0x0001fff0
14:53 fdobridge: <k​arolherbst🐧🦀> 0x0
14:53 fdobridge: <k​arolherbst🐧🦀> 0x04237030
14:53 fdobridge: <k​arolherbst🐧🦀> 0x1
14:53 fdobridge: <k​arolherbst🐧🦀> 0xf010
14:53 fdobridge: <k​arolherbst🐧🦀> 0x1fff0
14:53 fdobridge: <k​arolherbst🐧🦀> _then_ the next valid header is found: 0x80000451
14:55 fdobridge: <k​arolherbst🐧🦀> ehh wait
14:55 fdobridge: <k​arolherbst🐧🦀> there is a value skipped
14:55 fdobridge: <k​arolherbst🐧🦀> right after `0x0001fff0`
14:55 fdobridge: <k​arolherbst🐧🦀> but anyway... no idea
14:55 fdobridge: <k​arolherbst🐧🦀> it's doing _something_
14:55 fdobridge: <k​arolherbst🐧🦀> and we don't know how long that something is?
14:55 fdobridge: <k​arolherbst🐧🦀> unless the next value says so...
14:56 fdobridge: <k​arolherbst🐧🦀> @marysaka what's at `0x000010ed`?
14:56 fdobridge: <k​arolherbst🐧🦀> bit it looks like sub device stuff...
14:56 fdobridge: <k​arolherbst🐧🦀> `NV_FIFO_DMA_TERT_OP_GRP0_SET_SUB_DEV_MASK` 🥲
14:57 fdobridge: <k​arolherbst🐧🦀> so it might be that NVC56F_DMA_SET_SUBDEVICE_MASK_VALUE stuff
14:57 fdobridge: <m​arysaka> `20 42 01 10 `
14:57 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_TERT_OP 17:16`
14:57 fdobridge: <k​arolherbst🐧🦀> soo...
14:58 fdobridge: <k​arolherbst🐧🦀> mhh
14:58 fdobridge: <k​arolherbst🐧🦀> `0x0001fff0` 17:16 is 1
14:58 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_TERT_OP_GRP0_SET_SUB_DEV_MASK (0x00000001)`
14:58 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_SET_SUBDEVICE_MASK_VALUE 15:4`
14:58 fdobridge: <k​arolherbst🐧🦀> 15:4 would be...
14:58 fdobridge: <k​arolherbst🐧🦀> 0x011
14:58 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_SET_SUBDEVICE_MASK_OPCODE 31:16`
14:58 fdobridge: <k​arolherbst🐧🦀> that would be .. 0x2042
14:59 fdobridge: <k​arolherbst🐧🦀> doesn't make sense
15:00 fdobridge: <k​arolherbst🐧🦀> maybe it's fine though?
15:00 fdobridge: <k​arolherbst🐧🦀> 0x2042 could be the method...
15:00 fdobridge: <k​arolherbst🐧🦀> `0x108`
15:01 fdobridge: <k​arolherbst🐧🦀> and type == inc
15:01 fdobridge: <k​arolherbst🐧🦀> but no idea how often that would inc... maybe just 0?
15:01 fdobridge: <k​arolherbst🐧🦀> I dunno 🙂
15:01 fdobridge: <k​arolherbst🐧🦀> anyway
15:01 fdobridge: <k​arolherbst🐧🦀> I think it's the sub device stuff
15:01 fdobridge: <m​arysaka> Isn't that like the old interface?
15:01 fdobridge: <m​arysaka> like old FIFO stuffs
15:01 fdobridge: <k​arolherbst🐧🦀> nah
15:01 fdobridge: <k​arolherbst🐧🦀> or maybe?
15:01 fdobridge: <m​arysaka> it remind me of the fifo you have on Tegra a bit tho
15:01 fdobridge: <k​arolherbst🐧🦀> I dunno
15:02 fdobridge: <k​arolherbst🐧🦀> but anyway.. I think the first one we hit is whatever is below `/* dma set sub-device mask format */`
15:04 fdobridge: <m​arysaka> hopefully nothing after is important...
15:05 fdobridge: <k​arolherbst🐧🦀> well.. there seems to be more macro calls I think? but it looks like there is some stuff going on there
15:35 fdobridge: <m​arysaka> I got something mostly working so far
15:36 fdobridge: <!​DodoNVK (she) 🇱🇹> Is the timestampPeriod actually supposed to be 1 on NVIDIA? 🤔
15:36 fdobridge: <!​DodoNVK (she) 🇱🇹>
15:36 fdobridge: <!​DodoNVK (she) 🇱🇹> But anyway https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28274 passes CTS (so I guess it actually is)
15:57 fdobridge: <m​arysaka> Do we happen to have documentation of the format before the unified FIFO interface?
15:57 fdobridge: <k​arolherbst🐧🦀> nope
15:57 fdobridge: <m​arysaka> I think the value after are actual commands
15:57 fdobridge: <k​arolherbst🐧🦀> just whatever is in those headers
15:57 fdobridge: <m​arysaka> ``/* dma legacy incrementing/non-incrementing formats */``
15:57 fdobridge: <m​arysaka> the values seems to parse nicely to that
15:57 fdobridge: <m​arysaka> the values seems to parse nicely to that format thing (edited)
15:57 fdobridge: <k​arolherbst🐧🦀> yeah.. whatever works here 😄
15:58 fdobridge: <m​arysaka> ``[0x000010ec] HDR 1fff0 subch N/A GRP0 mthd 3fc0 SET_SUBDEVICE_MASK .VALUE = 0x200406c0``
16:00 fdobridge: <m​arysaka> anyway for the matter of your initial question @karolherbst https://paste.centos.org/view/3a114083
16:00 fdobridge: <m​arysaka> there is a wait for idle at the end
16:04 fdobridge: <k​arolherbst🐧🦀> hah! that sounds important 😄
16:04 fdobridge: <k​arolherbst🐧🦀> and there are also semaphorse...
16:04 fdobridge: <k​arolherbst🐧🦀> *semaphores
16:04 fdobridge: <k​arolherbst🐧🦀> I wonder if macro 99 sets one up
16:05 fdobridge: <k​arolherbst🐧🦀> and stores the pointer
16:05 fdobridge: <k​arolherbst🐧🦀> or whatever
16:05 fdobridge: <m​arysaka> no MME 99 is a simple DWRITE
16:05 fdobridge: <k​arolherbst🐧🦀> mhhh
16:05 fdobridge: <m​arysaka> ... I should probably publish my notes about macro somewhere isn'it
16:05 fdobridge: <m​arysaka> ... I should probably publish my notes about macro somewhere isn't it (edited)
16:06 fdobridge: <m​arysaka> https://gist.github.com/marysaka/dd0a44319623625d01c3687acd665971
16:06 fdobridge: <m​arysaka> for 99, it's really cute
16:07 fdobridge: <k​arolherbst🐧🦀> heh...
16:07 fdobridge: <k​arolherbst🐧🦀> so it writes `0xffffffff` to `0x405`
16:08 fdobridge: <k​arolherbst🐧🦀> and 0 to 4
16:08 ilgaz: nv9400 (mcp79) brightness issue was fixed before I could report but it is back now :-( kernel 6.7.9 opensuse tw
16:08 fdobridge: <k​arolherbst🐧🦀> mhh @marysaka sure that `0x80000451` isn't a header?
16:09 fdobridge: <k​arolherbst🐧🦀> because that being an immd would make sense
16:10 ilgaz: to report any issue I need to switch to "vanilla kernel" on opensuse I guess
16:11 fdobridge: <m​arysaka> could be but then where would the values for SET_SUBDEVICE_MASK be stored?
16:11 fdobridge: <m​arysaka> or maybe nothing collide and me assuming it was next dword was a wrong assumption wrong
16:11 fdobridge: <k​arolherbst🐧🦀> `0x200406c0` also looks more like a header...
16:12 fdobridge: <k​arolherbst🐧🦀> yeah... mhhh
16:12 fdobridge:<k​arolherbst🐧🦀> actually
16:12 fdobridge: <k​arolherbst🐧🦀> I think it's in the same thing
16:12 fdobridge: <k​arolherbst🐧🦀> but also weird...
16:12 fdobridge: <m​arysaka> maybe it's the old DMA commands 😄
16:13 fdobridge: <k​arolherbst🐧🦀> ehh wait...
16:13 fdobridge: <k​arolherbst🐧🦀> it actually makes sense
16:13 fdobridge: <k​arolherbst🐧🦀> `1fff0` => Value = `0xfff` and `opcode` = 1
16:14 fdobridge: <k​arolherbst🐧🦀> it looks like a mask and the opcode to be one matches the VALUE = 1 thing 😄
16:14 fdobridge: <k​arolherbst🐧🦀> then you have `0x200406c0`
16:15 fdobridge: <k​arolherbst🐧🦀> which are 4 items
16:15 fdobridge: <k​arolherbst🐧🦀> then another `1fff0`
16:15 fdobridge: <k​arolherbst🐧🦀> then `0x80000451`
16:15 fdobridge: <k​arolherbst🐧🦀> so yeah.. that also perfectly matches
16:17 fdobridge: <k​arolherbst🐧🦀> ohh wait.. yes
16:17 fdobridge: <k​arolherbst🐧🦀> I'm so silly
16:17 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_SET_SUBDEVICE_MASK_OPCODE_VALUE (0x00000001)`
16:17 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_STORE_SUBDEVICE_MASK_OPCODE_VALUE (0x00000002)`
16:17 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_USE_SUBDEVICE_MASK_OPCODE_VALUE (0x00000003)`
16:18 fdobridge: <k​arolherbst🐧🦀> and
16:18 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_TERT_OP_GRP0_INC_METHOD (0x00000000)`
16:18 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_TERT_OP_GRP0_SET_SUB_DEV_MASK (0x00000001)`
16:18 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_TERT_OP_GRP0_STORE_SUB_DEV_MASK (0x00000002)`
16:18 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_TERT_OP_GRP0_USE_SUB_DEV_MASK (0x00000003)`
16:18 fdobridge: <k​arolherbst🐧🦀> that perfect aligns
16:18 fdobridge: <k​arolherbst🐧🦀> @marysaka so yeah.. I'm 100% sure it doesn't read from the next value
16:19 fdobridge: <m​arysaka> ooh that makes sense...
16:19 fdobridge: <k​arolherbst🐧🦀> and the high bit is also 0, because tert is 0
16:19 fdobridge: <m​arysaka> it's very confusing to have them defined two times buut yeah
16:19 fdobridge: <k​arolherbst🐧🦀> the other methods also have it
16:19 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_IMMD_OPCODE_VALUE (0x00000004)`
16:19 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_SEC_OP_IMMD_DATA_METHOD (0x00000004)`
16:20 fdobridge: <k​arolherbst🐧🦀> so it's even consistent 😄
16:21 fdobridge: <k​arolherbst🐧🦀> I wonder what one can do with those sub device thingies...
16:23 fdobridge: <k​arolherbst🐧🦀> it also explain why submitting garbage commands messes up the entire state so much
16:23 fdobridge: <m​arysaka> So to sum up: we have those TERT things to handle and also the "old" increment and non-increment format to handle if we want the thing to be parsing correctly?
16:23 fdobridge: <k​arolherbst🐧🦀> nah.. it's just multilevel stuff going on
16:23 fdobridge: <k​arolherbst🐧🦀> `31:29` is the first thing to look at
16:24 fdobridge: <k​arolherbst🐧🦀> and it defines the layout
16:24 fdobridge: <m​arysaka> yeah ``#define NVC76F_DMA_OPCODE3_NONE (0x00000000)``
16:24 fdobridge: <m​arysaka> with `NVC76F_DMA_OPCODE_METHOD`
16:24 fdobridge: <k​arolherbst🐧🦀> there are already enough overlapping fields 😄
16:26 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_SUBDEVICE_MASK 15:4` :ferrisUpsideDown:
16:26 fdobridge: <m​arysaka> yeah but it means there is two form of increment tho when `31:29` is 0 or 2
16:26 fdobridge: <m​arysaka> so that mean the thing we need to do is just handle that and add the subdevice part probably?
16:26 fdobridge: <k​arolherbst🐧🦀> sure
16:27 fdobridge: <k​arolherbst🐧🦀> I wonder what GRP0 vs GRP2 is
16:27 fdobridge: <k​arolherbst🐧🦀> ohh.. `NVC56F_DMA_TERT_OP_GRP2_NON_INC_METHOD`
16:27 fdobridge: <k​arolherbst🐧🦀> mhhh
16:27 fdobridge: <k​arolherbst🐧🦀> whatever
16:28 fdobridge: <k​arolherbst🐧🦀> maybe just ignore/assert on those?
16:28 fdobridge: <k​arolherbst🐧🦀> the `SUB_DEV_MASK` is the things we actually have data on and how it looks like
16:28 fdobridge: <k​arolherbst🐧🦀> I'd rather wait until we hit the others to also have some data on them
16:29 fdobridge: <m​arysaka> I was right it is the old DMA format
16:29 fdobridge: <k​arolherbst🐧🦀> ahh
16:29 fdobridge: <m​arysaka> https://github.com/NVIDIA/open-gpu-kernel-modules/blob/3bf16b890caa8fd6b5db08b5c2437b51c758ac9d/src/common/sdk/nvidia/inc/class/cl506f.h#L109
16:29 fdobridge: <m​arysaka> everything is reserved on SEC_OP
16:29 fdobridge: <k​arolherbst🐧🦀> ohh.. indeed...
16:30 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_SEC_OP_GRP0_USE_TERT (0x00000000)`
16:30 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_OPCODE_METHOD (0x00000000)`
16:30 fdobridge: <k​arolherbst🐧🦀>
16:30 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_SEC_OP_GRP2_USE_TERT (0x00000002)`
16:30 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_OPCODE_NONINC_METHOD (0x00000002)`
16:30 fdobridge: <k​arolherbst🐧🦀> soo yeah...
16:30 fdobridge: <k​arolherbst🐧🦀> `/* dma legacy incrementing/non-incrementing formats */`
16:30 fdobridge: <k​arolherbst🐧🦀> 17:16 being 0 on both...
16:31 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_OPCODE3 17:16`
16:31 fdobridge: <k​arolherbst🐧🦀> `#define NVC56F_DMA_OPCODE3_NONE (0x00000000)`
16:31 fdobridge: <k​arolherbst🐧🦀> matches
16:31 fdobridge:<k​arolherbst🐧🦀> fun ky
16:32 fdobridge: <m​arysaka> what a headache
16:32 fdobridge: <k​arolherbst🐧🦀> anyway.. it's some weird way to do unions :ferrisUpsideDown:
16:32 fdobridge: <k​arolherbst🐧🦀> tagged unions be like
16:55 fdobridge: <z​mike.> hmmm some kind of big regression in the zink/nvk matrix which is hard hanging my cts runs now
16:55 fdobridge: <z​mike.> but only on full runs
16:55 fdobridge: <z​mike.> :stressheadache:
16:58 fdobridge: <m​arysaka> should do the job https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28277
17:14 fdobridge: <k​arolherbst🐧🦀> does it parse correctly now? 😄
17:14 fdobridge: <m​arysaka> https://paste.centos.org/view/c4c57723
17:15 fdobridge: <m​arysaka> That seems good to me 😄
17:15 fdobridge: <k​arolherbst🐧🦀> yeah, perfect 🙂
17:15 fdobridge: <m​arysaka> not sure why they use that here ngl
17:16 fdobridge: <k​arolherbst🐧🦀> yeah.. me neither
17:16 fdobridge: <k​arolherbst🐧🦀> mhhhh
17:16 fdobridge: <k​arolherbst🐧🦀> unless...
17:17 fdobridge: <k​arolherbst🐧🦀> I wonder how that works if you indeed have sub devices and mess with the gr context like this
17:17 fdobridge: <m​arysaka> I also have other part that use it apart from here related to DMA copies
17:18 fdobridge: <k​arolherbst🐧🦀> but anyway.. I think setting 0xfff is a nop and we can ignore it until nvk starts to partitioning devices or something?
17:18 fdobridge: <k​arolherbst🐧🦀> I have no idea
17:18 fdobridge: <k​arolherbst🐧🦀> mhh
17:18 fdobridge: <k​arolherbst🐧🦀> @marysaka `mthd 3fc0 SET_SUBDEVICE_MASK` I think we might want to reconsider the mthd value there 😄
17:19 fdobridge: <m​arysaka> uuurgh that mean changing the while logic :nya_sad:
17:19 fdobridge: <m​arysaka> I could also hardcode some print and make it continue the loop I guess
17:19 fdobridge: <k​arolherbst🐧🦀> nah
17:19 fdobridge: <k​arolherbst🐧🦀> just reuse `mthd` 😄
17:19 fdobridge: <k​arolherbst🐧🦀> soo.. instead of adding `tert_op` just use `mthd`
17:19 fdobridge: <m​arysaka> oh the value oops
17:20 fdobridge: <m​arysaka> sorry I need to do my afternoon tea still 😅
17:20 fdobridge: <k​arolherbst🐧🦀> 😄
17:21 fdobridge: <k​arolherbst🐧🦀> maybe having `tert_op` makes sense, so you could set `mthd` later to it
17:21 fdobridge: <k​arolherbst🐧🦀> or something
17:22 fdobridge: <k​arolherbst🐧🦀> @marysaka I think it makes also sense to instead of printing `(SET_SUBDEVICE_MASK)` in the header
17:22 fdobridge: <k​arolherbst🐧🦀> ehh
17:22 fdobridge: <k​arolherbst🐧🦀> wait
17:22 fdobridge: <k​arolherbst🐧🦀> that would become complicated
17:22 fdobridge: <m​arysaka> I can remove that part and print it only for NINC
17:22 fdobridge: <k​arolherbst🐧🦀> whatever.. I only find the mthd value confusing
17:23 fdobridge: <k​arolherbst🐧🦀> maybe use `SUB_DEVICE_OP` for those three values
17:23 fdobridge: <k​arolherbst🐧🦀> *methods
17:23 fdobridge: <k​arolherbst🐧🦀> ```
17:23 fdobridge: <k​arolherbst🐧🦀> [0x000010ec] HDR 1fff0 subch N/A SUB_DEVICE_OP
17:23 fdobridge: <k​arolherbst🐧🦀> mthd 1 SET_SUBDEVICE_MASK
17:23 fdobridge: <k​arolherbst🐧🦀> .VALUE = 0xfff
17:23 fdobridge: <k​arolherbst🐧🦀> ```
17:24 fdobridge: <k​arolherbst🐧🦀> that would look very natural and fitting with the others
17:24 fdobridge: <k​arolherbst🐧🦀> I think?
17:24 fdobridge: <k​arolherbst🐧🦀> yeah
17:26 fdobridge: <m​arysaka> I think that would be clean yeah
17:27 fdobridge: <k​arolherbst🐧🦀> what a hack tho 😄 I mean.. how nvidia added that stuff there
17:27 fdobridge: <k​arolherbst🐧🦀> I hope they have good reasons for this
17:27 fdobridge: <m​arysaka> yeah 😅
17:27 fdobridge: <m​arysaka> it should be fixed now
17:27 fdobridge: <k​arolherbst🐧🦀> have a new paste?
17:29 fdobridge: <m​arysaka> ```
17:29 fdobridge: <m​arysaka> [0x000010f2] HDR 1fff0 subch N/A SUB_DEVICE_OP
17:29 fdobridge: <m​arysaka> mthd 0001 SET_SUBDEVICE_MASK
17:29 fdobridge: <m​arysaka> .VALUE = 0xfff
17:29 fdobridge: <m​arysaka> ```
17:29 fdobridge: <k​arolherbst🐧🦀> nice
20:44 fdobridge: <z​mike.> is `nouveau_sched` supposed to consume my entire cpu
20:46 fdobridge: <t​om3026> unused cpu is wasted cpu
20:46 fdobridge: <!​DodoNVK (she) 🇱🇹> `nouveau_croissantcoin_miner` (real)
20:47 fdobridge: <a​irlied> @zmike. are you running CTS, then possibly
20:48 fdobridge: <z​mike.> :hypertensionheadache:
20:48 fdobridge: <z​mike.> this is one of the bisects of all time
20:52 fdobridge: <k​arolherbst🐧🦀> zmike, you seem to suffer from headaches quite a lot recently, are you alright?
20:53 fdobridge: <z​mike.> I will be once zink+nvk jobs get into ci and actually work
20:53 fdobridge: <z​mike.> and once I claw my way free of nir hell again
20:57 fdobridge: <!​DodoNVK (she) 🇱🇹> How painful is NIR?
20:59 fdobridge: <z​mike.> it depends if you're weak to a dull, throbbing sort of pain that never goes away
21:14 fdobridge: <z​mike.> I'm closing in on the culprit
21:54 fdobridge: <z​mike.> https://c.tenor.com/BKk0-I2aA78AAAAd/tenor.gif
21:54 fdobridge: <z​mike.> ```
21:54 fdobridge: <z​mike.> 133c73da8560f689f8d560b30b1557a353b44995 is the first bad commit
21:54 fdobridge: <z​mike.> commit 133c73da8560f689f8d560b30b1557a353b44995
21:54 fdobridge: <z​mike.> Author: Dave Airlie <airlied@redhat.com>
21:54 fdobridge: <z​mike.> Date: Wed Mar 13 12:22:23 2024 +1000
21:54 fdobridge: <z​mike.>
21:54 fdobridge: <z​mike.> nvk: enable a mappable bar heap when rebar is disabled.
21:54 fdobridge: <z​mike.>
21:54 fdobridge: <z​mike.> Now that we've resolved the kernel side issues, this should be fine
21:54 fdobridge: <z​mike.> to expose on non-rebar systems.
21:54 fdobridge: <z​mike.>
21:54 fdobridge: <z​mike.> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28144>
21:54 fdobridge: <z​mike.> ```
21:55 fdobridge: <z​mike.> am I supposed to have an ultra new kernel or something?
21:55 fdobridge: <z​mike.> I'm on 6.7.3
21:55 fdobridge: <!​DodoNVK (she) 🇱🇹> Do you watch Last Week Tonight?
21:55 fdobridge: <z​mike.> I might
21:56 fdobridge: <z​mike.> the content of a gif is all that matters, not the context
21:59 fdobridge: <a​irlied> yeah magic kernel time
22:00 fdobridge: <z​mike.> What version is required now
22:01 fdobridge: <!​DodoNVK (she) 🇱🇹> 6.8 isn't enough I think
22:01 fdobridge: <!​DodoNVK (she) 🇱🇹> https://patchwork.freedesktop.org/patch/582274/
22:02 fdobridge: <z​mike.> 🤕
22:02 fdobridge: <z​mike.> Is there anything supported by mainline fedora usable?
22:07 fdobridge: <m​agic_rb.> I take me being able to run nvk on a 6.7.9 kernel is quite lucky? I cant update due to zfs currently
22:13 fdobridge: <a​irlied> @zmike. reverting that commit 🙂
22:16 fdobridge: <z​mike.> If I have to? Ideally I'd like to be using a real driver with BAR
22:41 fdobridge: <r​inlovesyou> oh, do i have to update my kernel for nvk again?
22:42 fdobridge: <r​inlovesyou> :Hehe:
23:01 fdobridge: <a​irlied> the bleeding edge is where the bleeding be at 🙂
23:18 fdobridge: <i​509vcb> Has anyone ever tried an RTX A2000 under nouveau or tried to make it work?
23:21 fdobridge: <m​ohamexiety> that's ampere, so it should work
23:23 fdobridge: <i​509vcb> Yeah I did see it's ampere
23:23 fdobridge: <i​509vcb> The fact that it is smol is actually quite interesting
23:24 fdobridge: <i​509vcb> (although I have even more smol ga10b as well but that's in chaos at the moment)
23:25 fdobridge: <m​ohamexiety> yeah they have some neat small sized quadros
23:26 fdobridge: <m​ohamexiety> another one part of the Ada lineup is the RTX 4000 SFF which is surprisingly small for a big chip
23:28 fdobridge: <z​mike.> I'd prefer if the bleeding edge could check my kernel version so I don't spend hours bisecting :fullheadache:
23:29 fdobridge: <a​irlied> the problem is it's just a fix in the kernel, it's not an API change, it'll get bcakporte dto lots of kernels
23:45 fdobridge: <z​mike.> Hopefully I can distro-sync tomorrow and pick it up