03:16 fdobridge: <r​edsheep> Do I need an environment variable to test this, like the no cbuf one did? I just tested main against this branch and I am seeing 0 performance difference in the witness
03:20 fdobridge: <g​fxstrand> Yeah, you need `NVK_DEBUG=no_cbuf` again. Once I get bindless working for real, I'll probably permanently turn off the bound CBuf optimization on Turing+.
03:20 fdobridge: <r​edsheep> Ok let me see what that does
03:34 fdobridge: <r​edsheep> Okay with that environment variable set on both main and your branch I see 6% improvement in the witness.
03:34 fdobridge: <r​edsheep>
03:34 fdobridge: <r​edsheep> With talos no_cbuf is a 11% regression regardless of whether I am testing main or the bindless-ubo branch. That probably isn't overly surprising since you said more stuff needs to get wired up to use your new bindless stuff.
03:35 fdobridge: <g​fxstrand> Yeah. The real win will be when we combine bindless with the inline UBO branch.
03:36 fdobridge: <g​fxstrand> I've not built the one on the other. I want to get all the pieces working separately first.
03:37 fdobridge: <g​fxstrand> And it may be that we want the bound UBO path sometimes even with push cbuf0
03:37 fdobridge: <g​fxstrand> Oh, and I still need to figure out bound textures. I have an old branch for that but it also really sucked in some cases.
06:50 fdobridge: <a​irlied> @skeggsb9778 did you have some plan for 0xff connector types? https://lore.kernel.org/dri-devel/20240528064730.9907-1-airlied@gmail.com/T/#u
06:52 fdobridge: <a​irlied> seems like GSP gives them back sometimes
07:13 fdobridge: <s​keggsb9778> @airlied it's also entirely possible i need to parse NV0073_CTRL_CMD_SPECIFIC_GET_CONNECTOR_DATA better
07:13 fdobridge: <s​keggsb9778> i'll try and have a look at it sometime soon
07:32 fdobridge: <a​irlied> looking at the open driver, it seems they get 0xff back and just drop the connecter
07:34 fdobridge: <a​irlied> https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia-modeset/src/nvkms-rm.c#L704
07:38 eisemsi2: Client: HexChat 2.16.0 • OS: Ubuntu "jammy" 22.04 • CPU: AMD Ryzen 7 6800H with Radeon Graphics (400MHz) • Memory: 14.5 GiB Total (12.1 GiB Free) • Storage: 46.3 GB / 218.8 GB (172.5 GB Free) • VGA: NVIDIA Corporation GA107M [GeForce RTX 3050 Mobile] @ Advanced Micro Devices, Inc. [AMD] PROXIM Inc • Uptime: 55m 30s
07:45 DodoGTA: elsemsi2: Why are you posting your system specs? Is that for some nouveau/NVK issue you're trying to report?
08:00 eisemsi2: apologies! Didn't know sysinfo sends to the channel. I am a student looking for resources to become a developer. It would be nice if someone could mentor me into it. Thanks
21:45 fdobridge: <a​irlied> @skeggsb9778 https://gitlab.freedesktop.org/drm/nouveau/-/issues/362 just wondered if this is something you've ever heard or seen anywhere else?
21:47 fdobridge: <s​keggsb9778> Oh wow. No. I'd also be very interested in learning which case(s) trigger this
21:49 fdobridge: <s​keggsb9778> I think it must be the instmem cases
21:49 fdobridge: <s​keggsb9778> (looking at the fix patch)
21:50 fdobridge: <a​irlied> yeah I can see the other two matter, I wonder if it's just a slow down or speedup breaking something, it's very unusual
23:12 fdobridge: <g​fxstrand> Ugh... These uniform ALU encodings are getting annoying.
23:12 fdobridge: <g​fxstrand> I'm starting to think you can't actually use a cbuf with a uniform ALU which is super annoying.
23:12 fdobridge: <g​fxstrand> You can do LDC
23:12 fdobridge: <g​fxstrand> But not directly reference a cbuf
23:13 fdobridge: <g​fxstrand> At least it's not obvious how with the bit fiddling I'm currently doing with PLOP3