02:51 fdobridge: <a​irlied> @conan_kudo I already have a firmware copr
09:18 montjoie: hello, I bringup a new "old" PC and nouveau print an error: "nouveau 0000:01:00.0: bios: OOB 1 013f1901 013f1901"
09:18 montjoie: I didnt found any problem with X11 on it, I just want to know what means this error and if I can do something
10:51 karolherbst: montjoie: it's where read the vbios OOB, probably some buf in the vbios parser, but as long as nothing bad happens it's not really causing any issues.
10:53 montjoie: karolherbst: thanks, I believed something can be done
12:13 karolherbst: oh sure, somebody could figure out where that OOB read happens and all that, but as long as it's not really causing any issues it's kinda just something somebody would do if they feel bored or motivated enough
18:28 fdobridge: <g​fxstrand> Okay... I think I've sorted out TES now. Doing a full CTS run while I go buy groceries and then I'll do a few more cleanups and push the lot to nak/main later today.
18:28 fdobridge: <g​fxstrand> That just leaves GS
18:28 fdobridge: <g​fxstrand> (Assuming TCS actually works but it's looking really promising.)
18:30 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> And RT (but that's its own beast that might require reverse-engineering and help from Bas)
18:30 fdobridge: <g​fxstrand> Well, yes. We're ignoring RT for now
18:30 fdobridge: <g​fxstrand> RT doesn't exist. 😝
18:31 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Just like Australia
18:31 fdobridge: <p​ixelcluster> *poof*
18:34 fdobridge: <p​ixelcluster> poof *disappears* (edited)
18:37 fdobridge: <m​arysaka> I pushed earlier my nak/geometry-shader branch with the fixes for OUT.EMIT RZ mess I had and it's based on the tesselation branch
18:37 fdobridge: <m​arysaka> last commit on the branch should be revert as it was a temporary attempt when I was still trying to debug stuffs
18:39 fdobridge: <m​ohamexiety> technically, that does take care of all your problems in work too. can't have issues if there's no RT :p
18:39 fdobridge: <m​arysaka> but there seems to be something wrong with ``nir_intrinsic_load_per_vertex_input`` on GS even tho the computation for isberd *seems fine*
19:12 fdobridge: <g​fxstrand> That's believable. It took me a bit to get it right. Could be something subtle that's gone wrong.
19:15 fdobridge: <_​maide> Speaking of ISBERD, does anyone know where/how to get the idmap/odmap values? I know the imap/omap is in the SPH, so no issues there, but the patent talking about ISBE talks about needing the idmap/odmap along with it to generate a correct bmap. Does anyone know where that is, or how to generate it if it's generated?
19:41 fdobridge: <g​fxstrand> At least for tessellation, the ISBE doesn't care about the address. It just takes a adjusted index and returns another index.