17:07 karolherbst: jekstrand: https://github.com/NVIDIA/open-gpu-doc/commit/919c4fbec89bfcaea2ccfef20fa2be4825bd72ee :3
17:12 karolherbst: 48 -> 56 bit VM as it seems is the biggest change
17:12 karolherbst: local size got another bit, cool
17:12 karolherbst: jekstrand: you'll love this: SET_ZT_FORMAT_V_V8Z24 got dropped
17:12 fdobridge: <j​ekstrand> Neato
17:13 fdobridge: <j​ekstrand> Not neato
17:13 fdobridge: <j​ekstrand> Eh, actually, I don't know that we care too much which 8/24 format we use.
17:13 fdobridge: <j​ekstrand> As long as we have one of them, it'll be fine.
17:13 karolherbst: all of them are gone
17:14 fdobridge: <j​ekstrand> What do you mean?
17:14 fdobridge: <j​ekstrand> Did it switch to separate depth/stencil?
17:14 karolherbst: okay.. turing == ada, and hooper has the bigger VM and dropped mixed formats
17:14 fdobridge: <j​ekstrand> Makes sense. Hopper is the datacenter GPU.
17:16 HdkR: Hopper isn't really a rendering card anyway, only one GPC has graphics and it is mostly there for compositing :P
17:16 karolherbst: let me take another look.. maybe I messed it up.. ahh now, we still have some mixed formats around
17:16 karolherbst: just weird ones are gone
17:17 fdobridge: <j​ekstrand> @marysaka The biggest item for pre-Turing is MME support: https://gitlab.freedesktop.org/nouveau/mesa/-/issues/32
17:17 karolherbst: the tex stuff changed though :(
17:18 karolherbst: ehh no
17:18 karolherbst: just reorderings
17:18 karolherbst: yep
17:18 karolherbst: okay, so ada seems to be a noop change compared to ampere
17:19 fdobridge: <m​arysaka> oh so having the same kind of xml definition for MME macros that you have for Turing?
17:19 fdobridge: <m​arysaka> I'm not too familiar with the tooling but I guess I can give it a shot
17:19 karolherbst: yeah.. it will all be the same
17:19 karolherbst: ampere and turing are a little different, but nothing substantial
17:20 karolherbst: Hopper adds a "Texture Header V2 Blocklinear" thing
17:20 karolherbst: or well
17:20 karolherbst: V2 of everything
17:21 karolherbst: uhh
17:21 karolherbst: it's like completely different
17:21 karolherbst: jekstrand: yeah.. so what I've done for kepler in nil we need for hopper and maybe future gens
17:21 karolherbst: might want to rethink how I've done the code then
17:22 fdobridge: <j​ekstrand> More simulator + builder. I don't care about XML. I'm kinda tempted to delete the XML TBH. IDK that it buys us anything.
17:22 karolherbst: names state mostly the same, but a lot of things were moved around/resized/whatever
17:22 fdobridge: <j​ekstrand> Oh, and tests. Tests that assert that the understanding encoded in the simulator matches the hardware as best as we can tell.
17:22 fdobridge: <m​arysaka> I see
17:23 fdobridge: <j​ekstrand> karolherbst: Yeah, I assumed we'd basically have separate functions per-gen. or per time it changes significantly. I wasn't a huge fan of trying to do it interlinear like ISL.
17:24 karolherbst: yeah.. not a fan either of my code. The problem is just that there is soo much stuff just literally be the same, that's kind of annoying having to touch multiple functions
17:24 fdobridge: <j​ekstrand> It only works in ISL because we are re-compiling and we have the compiler there to check if we made an oops. Also, the genXML stuff doesn't require us to encode dword numbers in things so we can withstand a LOT of movement without writing new code.
17:24 karolherbst: genxml styles stuff might actually work but... yeah... not sure
17:25 fdobridge: <j​ekstrand> Yeah, I've though some of that. It just seems kinda pointless to write an entire python generator thing just for texture headers and samplers.
17:25 karolherbst: could use C++ and templates.....
17:25 fdobridge: <j​ekstrand> No
17:25 karolherbst: :P
17:26 fdobridge: <j​ekstrand> I don't think the bit of code duplication is that bad. If we're concerned about consistency of things like ANISO settings, we can add #defines to the top so we use the same values in all the copies.
17:26 karolherbst: the annoying parts are if names were changed, but still mean the same thing
17:26 fdobridge: <j​ekstrand> Yeah
17:27 karolherbst: yeah.. maybe I should just add alias names for some stuff and then it will work out
17:27 karolherbst: dunno...
17:27 karolherbst: might play around with it once I have some time
17:39 fdobridge: <j​ekstrand> If it starts to be a mess, just copy+paste and make a 2nd one. 🙂
17:41 karolherbst: yeah.. I won't try spending hours on it just to not having to duplicate stuff :D I also won't use macros, because that's like annoying anyway... but I kind of suspect we'll have to duplicate anyway
18:08 fdobridge: <m​arysaka> Seems like nouveau isn't liking my eGPU enclosure with my GTX 970 for some reasons
18:09 fdobridge: <k​arolherbst🐧🦀> like it doesn't work, or is hot unplugging killing your system?
18:11 fdobridge: <m​arysaka> when running vulkaninfo ``ERROR: [../src/nouveau/vulkan/nvk_physical_device.c:413] Code 0 : Unable to open device /dev/dri/renderD130: Invalid argument (VK_ERROR_INCOMPATIBLE_DRIVER)``
18:11 fdobridge: <m​arysaka> and in kernel logs:
18:11 fdobridge: <m​arysaka> ```
18:11 fdobridge: <m​arysaka> nouveau 0000:07:00.0: can't enable device: BAR 5 [io 0x0000-0x007f] not claimed
18:11 fdobridge: <m​arysaka> ```
18:11 fdobridge: <k​arolherbst🐧🦀> ehhhh
18:11 fdobridge: <k​arolherbst🐧🦀> well.. nvk won't work on that GPU anyway for now, still have to implement some stuff
18:11 fdobridge: <k​arolherbst🐧🦀> but the BAR 5 error is weird
18:12 fdobridge: <m​arysaka> yeah I know but wanted to test MME macros manually with some scripts I have around :notlikethis:
18:13 fdobridge: <m​arysaka> I do have a feeling that having the other GPU in the laptop active is messing with the other one, I think I will force disable it and reboot to see
18:13 fdobridge: <m​arysaka> (As that USB C port can be used to carry video from the RTX 2060 I have and also handle thunderbolt somehow)
18:14 fdobridge: <k​arolherbst🐧🦀> ahh, cool
18:14 fdobridge: <k​arolherbst🐧🦀> yeah.. that might cause some issues
18:14 fdobridge: <k​arolherbst🐧🦀> eGPUs on linux are kind of.. uhhh... a mess
21:42 fdobridge: <m​arysaka> so after a bit of messing around, turns out removing the pci device and rescanning does the job (without nouveau module unloaded)
21:47 fdobridge: <k​arolherbst🐧🦀> cool
21:55 fdobridge: <m​arysaka> so after a bit of messing around, turns out removing the pci device and rescanning does the job (without nouveau module loaded) (edited)