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