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