00:11 avoidr: Is there possibly any emergency trick to fix a display freeze? Would it be possible at all?
01:55 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19543 probably does
01:55 karolherbst: I just didn't get to properly test it yet
01:57 karolherbst: though I might even change it so I get rid of the allocation in each fence...
01:57 karolherbst: anyway
01:57 karolherbst: that probably helps
03:11 fdobridge: <a​irlied> @Mr Fall🐧 oh yeah Ben is reworking the nonstall irqs on gsp patch so it should be all fine when he pushes his next batch out
10:23 fdobridge: <k​arolherbst🐧🦀> okay, cool
19:17 fdobridge: <a​irlied> @gfxstrand you know anything about changes to the local memory sizings on ampere?
19:17 fdobridge: <a​irlied> gsp: Xid:13 Graphics Exception: SKEDCHECK05_LOCAL_MEMORY_TOTAL_SIZE failed is a thing I'm seeing with gsp on my ampere
19:26 airlied: skeggsb: ^ you aware of any ampere related changes around shader local memory sizing?
19:54 karolherbst: is the value properly aligned?
19:55 karolherbst: because I don't see how SKEDCHECK could know that the size is plain wrong, it can only check alignment afaik
19:56 karolherbst: and it's a per thread value anyway
19:56 karolherbst: what could be the case is that the size is too big for the bound tls buffer
19:56 airlied: yeah I've no idea what it complains about, resizing random things doesn't make it go away
19:56 karolherbst: so in gl we align the size to 0x100
19:56 karolherbst: also, you might want to check if the aligned size * thread count is smaller than the bound tls buffer
19:57 karolherbst: maybe there is a max size per thread.. mhh
19:58 karolherbst: airlied: 512 KiB is the max size per thread
19:58 karolherbst: which is kinda huge
19:59 airlied: I also don't see it on tu10x so I wonder what changed for ampere
20:00 karolherbst: yeah.. weird
20:00 karolherbst: might be worth diffing the QMD headers
20:02 airlied: well I'm using QMD V3 on ampere but pretty sure I saw it using QMD 2.4
20:04 karolherbst: I think we don't really check what the hw actually supports
20:04 karolherbst: we should do that at some point
20:05 karolherbst: but I was more wondering about new fields.. anyway
20:05 airlied: yeah didn't spot any with LOCAL in them
20:05 karolherbst: might be that the resize of the tls buffer is kinda wrong
20:05 karolherbst: does the resize take alignment into account?
20:05 karolherbst: and did you check what values are wrong?
20:06 airlied: not sure how to check what values are wrong, all I get is the SKEDCHECK05 error
20:06 airlied: I've resized various things and realigned them to no avail
20:06 karolherbst: mhh, fair point
20:06 karolherbst: well, if you don't figure something out I can take a look next week
20:07 fdobridge: <g​fxstrand> Nope
23:13 fdobridge: <g​fxstrand> Doing my first CTS run on NAK. 😄
23:16 fdobridge: <k​arolherbst🐧🦀> 100% first try or I'll be disappointed
23:16 fdobridge: <g​fxstrand> 😝
23:17 fdobridge: <g​fxstrand> So far, seems to be about a 5% crash rate with NAK enabled for CS only.
23:18 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Compute Shaders?
23:20 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> That's what zmike got with Faith's private branch of NVK /s
23:20 fdobridge: <g​fxstrand> Yes
23:22 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Are other types of shaders more complex?
23:26 fdobridge: <k​arolherbst🐧🦀> yes, they require linking
23:27 fdobridge: <k​arolherbst🐧🦀> nvidia has this fully configurable I/O stuff going on where you declare in/out attributes
23:28 fdobridge: <M​ohamexiety> 😮 that sounds interesting.. what do you mean?
23:30 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I didn't expect shaders to be linked 🐸
23:30 fdobridge: <k​arolherbst🐧🦀> well..
23:30 fdobridge: <k​arolherbst🐧🦀> cross stage linking exists
23:30 fdobridge: <k​arolherbst🐧🦀> so e.g. VS out attributes have to be linked to FS in attributes
23:30 fdobridge: <k​arolherbst🐧🦀> and the hw has slots and you can kinda mix and match
23:31 fdobridge: <M​ohamexiety> so similar to how e.g. in glsl you also define your inputs and outputs, and one input to a stage can be the output to the other.. but this is native to the HW itself
23:32 fdobridge: <M​ohamexiety> so similar to how e.g. in glsl you also define your inputs and outputs, and one input to a stage can be the output from the other.. but this is native to the HW itself (edited)
23:32 fdobridge: <k​arolherbst🐧🦀> yeah
23:33 fdobridge: <k​arolherbst🐧🦀> anyway, it's more work than running compute shaders 😄
23:40 fdobridge: <g​fxstrand> No linking is required. Not really. Just declaring inputs/outputs. I've got some of that code typed but not all.
23:40 fdobridge: <g​fxstrand> But yeah, there's lots of header crap to fill out. 😫
23:42 fdobridge: <M​ohamexiety> really awesome progress so far tho! ❤️
23:58 fdobridge: <k​arolherbst🐧🦀> yeah I guess it's dynamic enough on the hardware level that you don't really do any of the fancy linking other drivers are doing 😄