00:52fdobridge_: <enigma9o7> And again.
00:53fdobridge_: <enigma9o7> https://cdn.discordapp.com/attachments/1034184951790305330/1185384076073500762/shot-2023-12-15_16-39-48.png?ex=658f69f3&is=657cf4f3&hm=8a86306d9a8c119e5283498e5fb1355d1747ca5c5bce706691241723eb1c18b9&
00:55soreau: enigma9o7: Are you able to possibly try another OS with 3D drivers enabled to see if it might be bad hw?
00:55fdobridge_: <enigma9o7> It never locks up when using nvidia-340 prop driver.
00:56fdobridge_: <enigma9o7> Goes for months, only have to reboot when I wanna update kernel normally.
00:57fdobridge_: <enigma9o7> (However, I'm using old OS to keep that nvidia-340 supported and want to update; plus nouveau has better EGL support, and works in TTY which nvidia-340 doesn't)
00:59fdobridge_: <enigma9o7> I self-built the 6.6 kernel to test to see if perhaps newer version solved problems, which would give me confidence to upgrade OS.
00:59fdobridge_: <enigma9o7> On the 5.4 kernel, it only freezes every day or two.... this 6.6 is doing it every few hours or less.
02:14fdobridge_: <karolherbst🐧🦀> @gfxstrand fyi, the `.I` on `CCTL` means instruction and `.C` means constant
02:14fdobridge_: <karolherbst🐧🦀> `.U` is an alias for `.D` and means data
02:16fdobridge_: <karolherbst🐧🦀> ohhh.. mhh
02:16fdobridge_: <karolherbst🐧🦀> mhhhh
02:16fdobridge_: <karolherbst🐧🦀> it looks like the min latencies are only needed if `CCTL` is executed without a target address
02:18fdobridge_: <karolherbst🐧🦀> ehh those are the `.*ALL*` flags
02:18fdobridge_: <karolherbst🐧🦀> pain
02:19fdobridge_: <karolherbst🐧🦀> some invalid combinations of `CCTL` won't generate `ILLEGAL_INSTRUCTION_ENCODING` errors, but just act as `NOPs`...
02:19fdobridge_: <karolherbst🐧🦀> anyway...
04:35fdobridge_: <gfxstrand> @karolherbst Yeah, there's some plumbing we need to do in NIR before we can use addresses. It's on my TODO list but IDK when it'll happen.
04:36fdobridge_: <gfxstrand> I also need to spend some time thinking through things. I honestly don't know if it will result in valid memory-model-correct code if we put them on instructions.
04:36fdobridge_: <gfxstrand> Like sure it's great to make the one store available but I'm not sure if that's vk_mm correct or not
05:41fdobridge_: <gfxstrand> @asdqueerfromeu Is there an easy link to your AUR for Arch? I'm putting together an NVK Holiday Update blog post and would like to provide a link for folks wanting to try NVK out early.
05:42fdobridge_: <gfxstrand> @airlied If you wanted to add it to your copr, I'll add a link for that as well.
05:42fdobridge_: <gfxstrand> @airlied Also, do you mind if I mention our Fedora 40 plans?
07:01fdobridge_: <esdrastarsis> https://aur.archlinux.org/packages/vulkan-nouveau-git and https://aur.archlinux.org/packages/lib32-vulkan-nouveau-git
08:13fdobridge_: <!DodoNVK (she) 🇱🇹> DXVK should be all good with features once variableMultisampleRate is supported and Vulkan 1.3 is advertised (there's FL12 stuff but that's basically vkd3d, not DXVK)
08:23fdobridge_: <esdrastarsis> pipeline caching would be nice as well
09:19fdobridge_: <esdrastarsis> @gfxstrand The item `VK_EXT_multi_draw` should be marked here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9477
10:30fdobridge_: <!DodoNVK (she) 🇱🇹> I have a MMU fault now after fixing the segfaults in the pipeline caching patch
10:48fdobridge_: <!DodoNVK (she) 🇱🇹> Could umr be ported to nouveau? :nouveau:
15:26fdobridge_: <gfxstrand> UMR?
15:27fdobridge_: <pixelcluster> debugging tool for amd GPUs
15:27fdobridge_: <pixelcluster> Porting it would probably come close to rewriting
15:29fdobridge_: <gfxstrand> Yeah, IDK what our tools story is going to look like. GSP has been a bit of a regression there, sadly. 🫤
15:54fdobridge_: <gfxstrand> Variable multisample rate is probably happening soon.
15:54fdobridge_: <gfxstrand> January
16:11xiphmont: airlied: Finally sent you a small FreeCAD model that is a reliable trigger here for the nv50 IB-mode DMA bug.
16:22fdobridge_: <!DodoNVK (she) 🇱🇹> I might have to disable it for now (until @ phomes or someone else rebases it)
16:43fdobridge_: <gfxstrand> FYI: I'm planning to rewrite all the pipeline code in January, at which point we'll get all the caching toys.
16:44fdobridge_: <!DodoNVK (she) 🇱🇹> Will it make that part of the code cleaner?
16:48fdobridge_: <gfxstrand> Yes
16:48fdobridge_: <gfxstrand> And it'll move most of it into common code.
16:49fdobridge_: <gfxstrand> The plan is to basically just implement VK_EXT_shader_object in the driver and implement pipelines on top of that in the common runtime.
16:50fdobridge_: <gfxstrand> And the common implementation will have GPL and all the pipeline caching features.
16:50fdobridge_: <!DodoNVK (she) 🇱🇹> GPL in the common code? 🤔
16:50fdobridge_: <gfxstrand> Similar to how we implement render passes on top of dynamic rendering today
16:51fdobridge_: <gfxstrand> VK_KHR_graphics_pipeline_library, not GNU General Public License.
16:52fdobridge_: <!DodoNVK (she) 🇱🇹> I of course meant the extension (I definitely made some jokes from this ambiguous initialism before)
16:52fdobridge_: <gfxstrand> hehe
16:52fdobridge_: <gfxstrand> It's good to clarify sometimes.
16:53fdobridge_: <!DodoNVK (she) 🇱🇹> So what will Vulkan drivers need to implement to have EXT_GPL support after the EXT_GPL common implementation stuff? 🤔
16:53fdobridge_: <gfxstrand> Well, they can either implement GPL themselves or they can switch to the common framework and then it just happens.
16:55fdobridge_: <rhed0x> does Nvidia need any driver heroics for shader_objects or is it a straightforward fit for the hardware?
16:55fdobridge_: <gfxstrand> It's just how the hardware works
16:56fdobridge_: <gfxstrand> Our fragment shader key has exactly two bits (force per-sample and Z/S self-dep) and everything else is totally stateless.
16:57fdobridge_: <gfxstrand> There will be a bit of pain around task/mesh, too
16:57fdobridge_: <marysaka> (For mesh/task shaders we only need one bit too)
16:57fdobridge_: <gfxstrand> But nothing compared to what AMD or Intel have to deal with.
16:57fdobridge_: <marysaka> well that and the extra GS header :vReiAgony:
16:57fdobridge_: <rhed0x> seems like NV is the easiest hardware to write drivers for
16:57fdobridge_: <gfxstrand> It kinda is...
16:59fdobridge_: <marysaka> btw I did a attempt a rebase yesterday on top of your cbuf changes and had new failures, is there anything I need to hook up for that to work fine?
17:02fdobridge_: <gfxstrand> Mostly we need to make sure that we have competent stage->group mappings.
17:02fdobridge_: <gfxstrand> Right now, I'm using `gl_shader_stage` as the group but we'll need a proper remap table for task/mesh.
17:02fdobridge_: <!DodoNVK (she) 🇱🇹> How well do mesh shaders work in CTS/tests?
17:05fdobridge_: <marysaka> Only targeting mesh shader with no task support for the first MR but:
17:05fdobridge_: <marysaka> ``Pass: 722, Fail: 1, Crash: 40, Skip: 28800, Duration: 23, Remaining: 0``
17:05fdobridge_: <marysaka> knowing that the crashes are related to a regression caused by some int64 changes (ipa failing)
17:05fdobridge_: <marysaka> and the failure is going to be fun to deal with, but will try to deal with it at the start of next week hopefully
17:06fdobridge_: <marysaka> With task shader enabled (I only touched that part for an hour):
17:06fdobridge_: <marysaka> ```Pass: 1220, Fail: 204, Crash: 81, Skip: 28058, Duration: 51, Remaining: 0```
17:06fdobridge_: <marysaka> With task shader enabled (I only touched that part for an hour):
17:06fdobridge_: <marysaka> ``Pass: 1220, Fail: 204, Crash: 81, Skip: 28058, Duration: 51, Remaining: 0`` (edited)
17:07fdobridge_: <marysaka> I see, my other guess was around my MME macros but I guess I will dig into that on monday
17:10fdobridge_: <marysaka> knowing that the crashes are related to a regression caused by some int64 changes (ipa failing on frag with int64 loads) (edited)
17:13fdobridge_: <!DodoNVK (she) 🇱🇹> This could be nice for supporting GL_NV_mesh_shader but the zink developers NACKed it to oblivion: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7192
17:14fdobridge_: <marysaka> I don't think VK_EXT_mesh_shader map very well with the NV specific extension
17:15fdobridge_: <mohamexiety> It doesn't yeah
17:15fdobridge_: <!DodoNVK (she) 🇱🇹> So should nouveau OpenGL driver support GL_NV_mesh_shader directly? 🍩
17:15fdobridge_: <mohamexiety> The comments on that issue go into it
17:15fdobridge_: <dadschoorse> I think nobody wants to add NV_mesh code back to NIR
17:17fdobridge_: <mohamexiety> NV_mesh was supported in the past? \:o
17:19fdobridge_: <rhed0x> to prepare for a cross vendor ext
17:19fdobridge_: <mohamexiety> Ahh I see. I was surprised because nothing used it iirc
17:23fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1185633406915195010/Screenshot_20231216_192248.png?ex=65905228&is=657ddd28&hm=03fd2e3e3d3eac73598f0e54b3ff061666e8a232e835200e4d95888cc19bf253&
17:25fdobridge_: <!DodoNVK (she) 🇱🇹> So a ~23% gain compared to the last time I ran this benchmark on NVK
17:48fdobridge_: <karolherbst🐧🦀> probably the UBO stuff, no?
17:48fdobridge_: <karolherbst🐧🦀> ohh and did loop unrolling land?
17:48fdobridge_: <!DodoNVK (she) 🇱🇹> i think so
17:52fdobridge_: <triang3l> Will drivers be strongly discouraged from using their own pipeline implementations when that happens, by the way, or will it still be fine to take advantage of them? Like on AMD many rasterization state setters modify fields of the same PA_SU_SC_MODE_CNTL dword, and thus in my driver I just generate clear/set bits for the whole register based on all related non-dynamic state in the pipeline instead of marking a lot of state as dirty for the
17:53fdobridge_: <!DodoNVK (she) 🇱🇹> Is it possible to implement ESO on TeraScale? 🪳
17:53fdobridge_: <dadschoorse> ofc, you can even implement ESO on top of vulkan 1.0. it just doesn't make sense 🐸
17:54fdobridge_: <gfxstrand> @airlied @karolherbst If one of you wanted to give another crack at copr, I can build with system packages only with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26726
17:55fdobridge_: <triang3l> In R600g, vertex shader compilation accepts the geometry shader for VS>GS ring buffer data layout, but I think the universal solution of adding one layer of indirection can help here too. Aside from that, it seems like shader stages can be fully independent
17:56fdobridge_: <gfxstrand> I've got an e-mail thread going with Fabio to try and get us into the Oibaf PPA as well.
17:57fdobridge_: <!DodoNVK (she) 🇱🇹> I can't seem to find Rust packages on Arch
17:58fdobridge_: <triang3l> In R600g, vertex shader compilation accepts the geometry shader for VS>GS ring buffer data layout, but I think the universal solution of adding one layer of indirection can help here too. Aside from that, it seems like shader stages can be fully independent. GCN-style pixel shader epilogs are also not needed as the export format is configured in a context register (edited)
18:14fdobridge_: <dadschoorse> unless you have to you have to deal with descriptors, then AMD is the simplest
18:16fdobridge_: <!DodoNVK (she) 🇱🇹> Let's see if I can hang my CPU again :triangle_nvk:
18:20fdobridge_: <!DodoNVK (she) 🇱🇹> vkd3d-proton tests completed again
18:20fdobridge_: <!DodoNVK (she) 🇱🇹> https://cdn.discordapp.com/attachments/1034184951790305330/1185647596207870073/message.txt?ex=65905f5f&is=657dea5f&hm=76f2b7fe4164b412fec3e3d53a43afb1b1a2016bc41bcb73fc44cbb70c940492&
18:36fdobridge_: <!DodoNVK (she) 🇱🇹> Most Wanted 2012 instantly did it 💥
18:38fdobridge_: <!DodoNVK (she) 🇱🇹> I wonder what happened here?: `Dec 16 20:00:26 RenoirBeast kernel: nouveau 0000:01:00.0: gsp: cli:0xc1d00002 obj:0x00730000 ctrl cmd:0x00731341 failed: 0x0000ffff` (this isn't related to the CPU hang)
18:57fdobridge_: <gfxstrand> Descriptors are really easy on NV. It's descriptor buffer that's impossible.
18:58fdobridge_: <gfxstrand> IDK how to parse those yet. 😭
19:01fdobridge_: <dadschoorse> with amd everything you could come up with is possible 🐸
19:02fdobridge_: <dadschoorse> mantle for example had crazy things like linked list of descriptor sets, and that works just fine without extra indirection on amd
19:03fdobridge_: <dadschoorse> mantle for example had crazy things like linked lists of descriptor sets, and that works just fine without extra indirection on amd (edited)
19:09fdobridge_: <!DodoNVK (she) 🇱🇹> Maybe Dave knows more about this?
19:10fdobridge_: <!DodoNVK (she) 🇱🇹> *Only with GSP though
19:17fdobridge_: <triang3l> And with NGG