00:30gfxstrand[d]: marysaka[d]: Not sure. It came out of a Dell. I know that much. But I thought it was GT/GTX
00:30gfxstrand[d]: I haven't plugged it in yet
00:31redsheep[d]: gfxstrand[d]: https://tenor.com/view/getting-a-dell-gaming-pc-dude-gif-14395733393982085552
00:31gfxstrand[d]: The eBay seller claims it's a GTX 645
00:54gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1353894659033796649/rn_image_picker_lib_temp_72ea3bb2-f9ea-4663-8779-86a8e8d59be3.jpg?ex=67e35028&is=67e1fea8&hm=25bf4f95dc553b82e246c0ee57edc752e76fa61c30775b812599af4c1f51481e&
00:54gfxstrand[d]: marysaka[d]
00:55marysaka[d]: how is it not probing for you on nouveau then whaaat :painpeko:
00:56gfxstrand[d]: https://tenor.com/view/i-don%27t-know-idk-idk-about-that-gif-7336250873949261946
01:00gfxstrand[d]: Apparently the Nvidia kernel uses iommu group 22. I don't think that data point matters.
01:02marysaka[d]: Maybe I should test on my other board and see how it goes tomorrow
01:02gfxstrand[d]: You have another TX1?
01:07gfxstrand[d]: Ugh... This thing is turning into such a boondoggle...
01:07gfxstrand[d]: I hate arm
01:09marysaka[d]: yeah I have another one around
01:48gfxstrand[d]: I'm gonna have to printk this mess...
03:02gfxstrand[d]: I'm gonna end up doing Arm kernel dev for this... I hate that even more than x86 kernel dev. ðŸ˜
03:07airlied[d]: oops I'm sad I gave the TX1 I had away (not sad)
03:08gfxstrand[d]: It would be less of a pain if my TX1 would play nice like Mary's. As is, I need printk just to figure out why it's blowing up trying to enumerate.
03:09gfxstrand[d]: Though maybe I can smash some log options on?
03:12gfxstrand[d]: "Get a TX1," she said.
03:12gfxstrand[d]: "It just works," she said...
03:18HdkR: :D
03:35HdkR: Jetsons at least have a uart so debugging low-level problems isn't a complete PITA
03:54gfxstrand[d]: HdkR: https://social.treehouse.systems/@gfxstrand/114218506981533966
04:07gfxstrand[d]: Yeah, I might be a little salty.
04:09airlied[d]: I've had to look up how to use netconsole again this week
04:28gfxstrand[d]: Pain
04:29gfxstrand[d]: Don't get me wrong, UART is nicer than netconsole, usually. But also pain.
04:41tiredchiku[d]: rise and grind
04:41HdkR: gfxstrand[d]: You're not wrong. I hate needing to dive in to uart debugging, but I'm salty about most ARM devices not even having that :D
04:42HdkR: All these WoA Snapdragon devices, something goes wrong in the bootloader? nah, get wrecked.
04:50airlied[d]: I got a mini m2 to dfu debug the mini m4
06:02airlied[d]: 5080 in the same country at least
06:04tiredchiku[d]: I think I have spotted my issue
06:04tiredchiku[d]: DEBUG: BEFORE IOCTL NV_ESC_RM_ALLOC(NVOS21_PARAMETERS { hRoot: 3251634745, hObjectParent: 3404726273, hObjectNew: 0, hClass: 218, pAllocParms: 0x7ffd1d3031e0, paramsSize: 0, status: 0 } (unknown class_id: see cl00da.h))
06:04tiredchiku[d]: DEBUG: AFTER IOCTL NV_ESC_RM_ALLOC(NVOS21_PARAMETERS { hRoot: 3251634745, hObjectParent: 3404726273, hObjectNew: 3404726297, hClass: 218, pAllocParms: 0x7ffd1d3031e0, paramsSize: 0, status: 59 } (unknown class_id: see cl00da.h))```
06:05tiredchiku[d]: `paramsSize: 0`
06:06tiredchiku[d]: wait no it says that for everything in envyhooks output
06:35airlied[d]: skeggsb9778[d]: in your branch the kpmu_reserved_alignment is too big btw 0x200000 vs 0x20000 in nvrm
06:49airlied[d]: also you put the boot_gsp_fmc msg on the stack and don't zero it
08:54tiredchiku[d]: I got it
08:54tiredchiku[d]: my semaphore code isn't working right, the semaphore never updates
08:54tiredchiku[d]: commented it out, and
08:54tiredchiku[d]: Devices:
08:54tiredchiku[d]: ========
08:54tiredchiku[d]: GPU0:
08:54tiredchiku[d]: apiVersion = 1.4.309
08:54tiredchiku[d]: driverVersion = 25.0.99
08:54tiredchiku[d]: vendorID = 0x10de
08:54tiredchiku[d]: deviceID = 0x2484
08:54tiredchiku[d]: deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
08:54tiredchiku[d]: deviceName = NVIDIA GeForce RTX 3070 (NVK GA104)
08:54tiredchiku[d]: driverID = DRIVER_ID_MESA_NVK
08:54tiredchiku[d]: driverName = NVK
08:54tiredchiku[d]: driverInfo = Mesa 25.1.0-devel (git-c236341626)
08:54tiredchiku[d]: conformanceVersion = 1.4.0.0
08:54tiredchiku[d]: deviceUUID = 7401de10-8424-0000-0100-000100000000
08:54tiredchiku[d]: driverUUID = c1d55a00-a43a-2a01-2e20-a4ac73db5517
08:54tiredchiku[d]: GPU1:
08:54tiredchiku[d]: apiVersion = 1.4.303
08:54tiredchiku[d]: driverVersion = 570.133.7.0
08:54tiredchiku[d]: vendorID = 0x10de
08:54tiredchiku[d]: deviceID = 0x2484
08:54tiredchiku[d]: deviceType = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
08:54tiredchiku[d]: deviceName = NVIDIA GeForce RTX 3070
08:54tiredchiku[d]: driverID = DRIVER_ID_NVIDIA_PROPRIETARY
08:54tiredchiku[d]: driverName = NVIDIA
08:54tiredchiku[d]: driverInfo = 570.133.07
08:54tiredchiku[d]: conformanceVersion = 1.4.1.0
08:54tiredchiku[d]: deviceUUID = f99ac1b2-9d52-4531-e270-a600a6ebd8af
08:55tiredchiku[d]: driverUUID = a312329b-a338-5885-bebf-8b95ca9ae741
08:55tiredchiku[d]: Segmentation fault (core dumped)```
09:36tiredchiku[d]: that last segfault has also been fixed (double free moment)
09:36tiredchiku[d]: now to figure out why this semaphore won't update
09:43esdrastarsis[d]: tiredchiku[d]: Semaphores and fences are on the haiku dev's TODO list, btw
09:46tiredchiku[d]: mhm
09:47skeggsb9778[d]: airlied[d]: thanks! fixed locally now
09:55pavlo_kozlenko[d]: snowycoder[d]: Hello, how are you?
10:00pavlo_kozlenko[d]: tiredchiku[d]: Two drivers?
10:00pavlo_kozlenko[d]: How
10:00pavlo_kozlenko[d]: or you have 2 nvidia
10:03tiredchiku[d]: working on getting NVK running on openrm
10:40tiredchiku[d]: esdrastarsis[d]: went through the thread, they're talking about vulkan semaphores
10:41tiredchiku[d]: while I'm trying to figure out a semaphore in the nvkmd abstraction
11:00marysaka[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1354047316528594995/image.png?ex=67e3de55&is=67e28cd5&hm=ba9e8beb88c7c3ceccc9e065459b128553d7f8091c3061a0882bad657b17d6d0&
11:00marysaka[d]: gfxstrand[d]: also fine on the other TX1 (tho GART as always is completely busted?)
11:01HdkR: GART doesn't exist on Host1x does it?
11:02marysaka[d]: yeah
11:03HdkR: I expect the GB10 with the C2C-NVLink thing to also not touch it :D
11:04marysaka[d]: I have 2 difference compared to the other board: 1) when I modprobe on the other one I get one EMEM address decode error and one read fault before it init properly 2) ... there is two additional red light on this board that I don't have on the first one, hopefully it's nothing serious
11:05marysaka[d]: (hopefully the max pmic didn't go on some rampage or something... I really can't trust that chip even on NX)
11:05Jasper[m]: marysaka[d]: Was there something borked? I think this never worked well on my Pixel
11:05marysaka[d]: gfxstrand[d]: can't get nouveau to probe on her Jetson TX1
11:06marysaka[d]: and it's not any kind of busted power rail because her board probe the GPU fine on L4T with nvgpu
11:07marysaka[d]: so maybe there is something different like a different revision but as far as I remember the "EOL" variant of the board was the last variant of it
11:07marysaka[d]: (and that's what I tested on just now)
11:08marysaka[d]: might be worth finding the board revision info, I think it can be grabbed via I2C but haven't touched that in years...
11:08Jasper[m]: GPU is disabled in the upstream DTS
11:08Jasper[m]: Only the Jetson Nano and Pixel (smaug) have it enabled
11:08marysaka[d]: yes, I have a patch for that but it doesn't matter much
11:09marysaka[d]: uboot pass another device tree that have it on
11:09marysaka[d]: (I suppose cboot modify it and uboot passthrough that one)
11:10Jasper[m]: Ah, I forced a different DTB with grub on my TX2. Didn't know how to flash a different dtb to cboot
11:11marysaka[d]: I did that initially and we found out that somehow uboot have another one that enable the GPU...? in any cases both approach work fine for me, and Faith cannot get any of them working
11:11marysaka[d]: I know that nouveau on 6.11 is completely busted on that device, but on 6.13 it is completely fine
11:12Jasper[m]: Yes, I think @_oftc_airlied[d]:matrix.org fixed that after a bug report from Diogo Ivo.
11:15Jasper[m]: I remember testing it and immediately landing in black screen with blinking console cursor purgatory which means the GPU at least probed
11:16marysaka[d]: that would be vi not the GPU?
11:17marysaka[d]: I haven't tested display out as most of the time I do thing headlessly on those boards
11:18Jasper[m]: No it was the GPU, but something happens to where it will only barely render lightdm and just xorg, but everything else just crashes
11:18Jasper[m]: It's just xorg/wayland freezing when switching tty basically
12:27tiredchiku[d]: wtf
12:27tiredchiku[d]: ```(gdb) print userD->GPPut
12:27tiredchiku[d]: $50 = 0
12:27tiredchiku[d]: (gdb) print ctx->gpPut
12:27tiredchiku[d]: $51 = 2
12:27tiredchiku[d]: this is _after_
12:27tiredchiku[d]: ```c
12:27tiredchiku[d]: struct nvkmd_ctx_exec semExec = {
12:27tiredchiku[d]: .addr = ctx->cmdBuf->va->addr,
12:27tiredchiku[d]: .size_B = 4*nv_push_dw_count(&p),
12:27tiredchiku[d]: };
12:27tiredchiku[d]: #if 1
12:27tiredchiku[d]: for (uint32_t i = 0; i < exec_count; i++) {
12:27tiredchiku[d]: write_gp_fifo_entry(ctx, &execs[i]);
12:27tiredchiku[d]: }
12:27tiredchiku[d]: #endif
12:27tiredchiku[d]: write_gp_fifo_entry(ctx, &semExec);
12:27tiredchiku[d]: userD->GPPut = ctx->gpPut;
12:27tiredchiku[d]: volatile NvU32 *doorbell = (void*)((NvU8*)dev->usermodeMap.address + NVC361_NOTIFY_CHANNEL_PENDING);
12:27tiredchiku[d]: *doorbell = submitTokenNotifier->info32;``` happens
12:29marysaka[d]: As soon as you kickoff the doorbell the hardware will start executing the GPFIFO entries so the value will change
12:29marysaka[d]: if you want the current position I think you should grab GPGet
12:31tiredchiku[d]: I see
12:34tiredchiku[d]: put a breakpoint at the `userD->GPPut` assignment line
12:35tiredchiku[d]: and
12:35tiredchiku[d]: ```349 userD->GPPut = ctx->gpPut;
12:35tiredchiku[d]: (gdb) print userD
12:35tiredchiku[d]: $1 = (KeplerBControlGPFifo *) 0x7ffff4b5d000
12:35tiredchiku[d]: (gdb) print *userD
12:35tiredchiku[d]: $2 = {Ignored00 = {0 <repeats 16 times>}, Put = 0, Get = 0, Reference = 0, PutHi = 0, Ignored01 = {0, 0}, TopLevelGet = 0, TopLevelGetHi = 0, GetHi = 0,
12:35tiredchiku[d]: Ignored02 = {0, 0, 0, 0, 0, 0, 0}, Ignored03 = 0, Ignored04 = {0}, GPGet = 0, GPPut = 0, Ignored05 = {0 <repeats 92 times>}}
12:35tiredchiku[d]: (gdb) print ctx->gpPut
12:35tiredchiku[d]: $3 = 2
12:35tiredchiku[d]: :wat:
12:35tiredchiku[d]: https://tenor.com/view/it%27s-completely-blank-andrew-baena-it%27s-empty-gif-4122587417200590592
12:35tiredchiku[d]: am I insane, or should that not be blank
12:36tiredchiku[d]: `vkRes = nvkmd_dev_alloc_mapped_mem(_dev, log_obj, 0x80000, 0x10000, NVKMD_MEM_LOCAL, NVKMD_MEM_MAP_RDWR, &ctx->userD);`
12:36tiredchiku[d]: I have a feeling that should be in GART
12:36tiredchiku[d]: though it doesn't error out
12:37tiredchiku[d]: hm
12:37tiredchiku[d]: `KeplerBControlGPFifo *userD = ctx->userD->map;`
12:38tiredchiku[d]: ctx->userD looks fine
12:39tiredchiku[d]: ctx->userD->map is also the same memory address as userD
12:39tiredchiku[d]: so that's fine too
12:45tiredchiku[d]: spooky
12:45tiredchiku[d]: it's 0 even after `set userD->GPPut = 2` in gdb
12:45tiredchiku[d]: maybe some required mem region isn't being mapped?
13:27blisto[d]: Find the X on the map. It will lead you to the hidden things
13:32tiredchiku[d]: notthatclippy[d]: hello again :3
13:33tiredchiku[d]: any idea why userD is all zeroes even after I do `userD->GPPut = ctx->gpPut;` (the latter is 2)
13:34tiredchiku[d]: I tried putting ctx->userD on GART, and also explicitly giving ctx->userD->map a mmap'd address
13:35tiredchiku[d]: https://gitlab.freedesktop.org/Sid127/mesa/-/blob/nvk-openrm/src/nouveau/vulkan/nvkmd/nvrm/nvkmd_nvrm_ctx.c?ref_type=heads
13:58avhe[d]: tiredchiku[d]: what happens after poking the doorbell?
13:58avhe[d]: also i guess make sure your channel token is non-zero
14:02avhe[d]: i don't see you calling NVC36F_CTRL_CMD_GPFIFO_SET_WORK_SUBMIT_TOKEN_NOTIF_INDEX, if you get the submit token from notifier memory i believe you have to do so
14:03avhe[d]: you can also get it from NVC36F_CTRL_CMD_GPFIFO_GET_WORK_SUBMIT_TOKEN which is what i do in my code
14:03tiredchiku[d]: https://gitlab.freedesktop.org/Sid127/mesa/-/blob/nvk-openrm/src/nouveau/vulkan/nvkmd/nvrm/nvkmd_nvrm_ctx.c?ref_type=heads#L122-134
14:05avhe[d]: ah sorry, i missed it
14:05tiredchiku[d]: all good
14:05tiredchiku[d]: avhe[d]: I'll check this in a bit, having dinner rn
14:07avhe[d]: on volta+ the host engine doesn't snoop gpput writes, you have to signal it explicitely with the usermode doorbell thing
14:12tiredchiku[d]: I'm not entirely sure I follow
14:12tiredchiku[d]: (still learning!)
14:14tiredchiku[d]: NvNotification *notifiers = ctx->notifier->map;
14:14tiredchiku[d]: NvNotification *submitTokenNotifier = ¬ifiers[NV_CHANNELGPFIFO_NOTIFICATION_TYPE_WORK_SUBMIT_TOKEN];
14:14tiredchiku[d]: . . .
14:14tiredchiku[d]: volatile NvU32 *doorbell = (void*)((NvU8*)dev->usermodeMap.address + NVC361_NOTIFY_CHANNEL_PENDING);
14:14tiredchiku[d]: *doorbell = submitTokenNotifier->info32;```
14:14tiredchiku[d]: tiredchiku[d]: tokenParams.workSubmitToken comes back nonzero
14:17avhe[d]: tiredchiku[d]: you can check the code around here <https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/common/unix/nvidia-push/src/nvidia-push.c#L1119> and the UserDKickoff/DoorbellKickoff methods
14:17avhe[d]: tiredchiku[d]: so is the usermode gpget updated after you write to the doorbell?
14:18avhe[d]: also for sanity you should put a store barrier around there
14:19tiredchiku[d]: avhe[d]: it appears to be, yeah
14:19tiredchiku[d]: ```$14 = {Ignored00 = {0 <repeats 16 times>}, Put = 541589536, Get = 541589536, Reference = 0, PutHi = 1, Ignored01 = {0, 0}, TopLevelGet = 541589536,
14:19tiredchiku[d]: TopLevelGetHi = 2147483649, GetHi = 1, Ignored02 = {0, 0, 0, 0, 0, 0, 0}, Ignored03 = 0, Ignored04 = {0}, GPGet = 2, GPPut = 2, Ignored05 = {
14:19tiredchiku[d]: 0 <repeats 92 times>}}
14:20tiredchiku[d]: so I was just looking at the wrong time
14:58tiredchiku[d]: tiredchiku[d]: looks like that fixed the semaphore
14:58tiredchiku[d]: tiredchiku[d]: so I was right
14:59tiredchiku[d]: onto the next mystery
15:00tiredchiku[d]: segfault at
15:00tiredchiku[d]: Thread 1 "vkcube" received signal SIGSEGV, Segmentation fault.
15:00tiredchiku[d]: 0x00007ffff6c0a101 in wsi_common_get_images (_swapchain=0x0, pSwapchainImageCount=0x7fffffffdc90, pSwapchainImages=0x0)
15:00tiredchiku[d]: at ../mesa/src/vulkan/wsi/wsi_common.c:1130
15:00tiredchiku[d]: 1130 for (uint32_t i = 0; i < swapchain->image_count; i++) {
15:00tiredchiku[d]: oh
15:00tiredchiku[d]: swapchain memory addr is 0x0
15:00tiredchiku[d]: huh
15:06tiredchiku[d]: you know maybe this mystery is for later
15:08marysaka[d]: did you push that somewhere btw?
15:09asdqueerfromeu[d]: tiredchiku[d]: I assume vkCreateSwapchainKHR() has silently failed (which the app didn't exit on)
15:10gfxstrand[d]: gfxstrand[d]: Kepler confirmed!
15:10gfxstrand[d]: `01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 645 OEM] (rev a1)`
15:10tiredchiku[d]: marysaka[d]: I haven't made any changes since I pushed to my fork
15:11tiredchiku[d]: gfxstrand[d]: oh! in case you missed it: https://discord.com/channels/1033216351990456371/1034184951790305330/1354015604406878228
15:12tiredchiku[d]: asdqueerfromeu[d]: most likely, yeah
15:13tiredchiku[d]: inb4 it's vulkan/wsi_common.c:1044
15:14tiredchiku[d]: `/* We assume here that a driver exposing present_wait also exposes VK_KHR_timeline_semaphore. */`
15:14tiredchiku[d]: i.e. vulkan semaphores
15:14tiredchiku[d]: but that should return an error, so idk
15:14tiredchiku[d]: asdqueerfromeu[d]: app in question is good ol' vkcube btw
15:16tiredchiku[d]: https://gitlab.freedesktop.org/Sid127/mesa/-/tree/nvk-openrm/
15:16tiredchiku[d]: marysaka[d]
15:19tiredchiku[d]: here thar be dragons :D
15:20tiredchiku[d]: very hardcordey atm
15:20tiredchiku[d]: I wanna get vkcube working, after which I'll get rid of the hardcoded stuff
15:29Jasper[m]: @_oftc_gfxstrand[d]:matrix.org did you use the patched dtb with that Fedora tutorial?
15:34Jasper[m]: The one shipped with the image (if you specify it with grub over serial) will not have it enabled.
15:45gfxstrand[d]: marysaka[d]: Does the fan on your TX1 ever spin?
15:46marysaka[d]: gfxstrand[d]: no :blobcatnotlikethis:
15:46marysaka[d]: I wanted to look what needed to be done to get it to spin because it get toasty
16:04marysaka[d]: I think I have an idea to get the fan spinning :aki_thonk:
16:05marysaka[d]: might be some missing device tree mapping
16:12magic_rb[d]: Just spin the fan manually, like in the good old days :P
16:13marysaka[d]: I think the issue is that it is missing power
16:13asdqueerfromeu[d]: tiredchiku[d]: Apparently OGK has a hardcoded engine class list based on the GPU chip (the GSP support code for nouveau has that too but in a cleaner way)
16:13asdqueerfromeu[d]: `NV2080_CTRL_CMD_GPU_GET_ENGINES` command might work to query that information though
16:22tiredchiku[d]: I do know how to get all the info I need, thanks to averne's Envideo project 😅
16:22tiredchiku[d]: I still want to get vulkan samples running before doing that
16:22tiredchiku[d]: and then submit a draft MR
16:24avhe[d]: asdqueerfromeu[d]: that gets you members of the NV2080_ENGINE_TYPE_ enum
16:25avhe[d]: which you can query corresponding class ids for using NV2080_CTRL_CMD_GPU_GET_ENGINE_CLASSLIST
16:26avhe[d]: that way you avoid relying on the low 8 bits of the class id
17:20avhe[d]: notthatclippy[d]: notthatclippy[d] (hopefully not too late) ping
17:20avhe[d]: i'm seeing funny behavior where unmapping cached memory seems to be more expensive than uncached
17:20avhe[d]: and i wonder if that's because the firmware only does the full L2 flush for cached memory
17:26gfxstrand[d]: Note to self: Don't use `make localmodconfig` with nouveau blocklisted
17:28Jasper[m]: W-whas that it?
17:28gfxstrand[d]: Because they it doesn't build nouveau
17:29gfxstrand[d]: Because the module isn't loaded
17:43tiredchiku[d]: might wanna look into https://github.com/graysky2/modprobed-db
17:43gfxstrand[d]: Okay, custom kernel also panics
17:43gfxstrand[d]: woo
17:52Jasper[m]: <gfxstrand[d]> "Okay, custom kernel also panics" <- Did you reflash the dtb in cboot? If yes, just to check, I'd stop grub booting and manually specify a mainline'ish DT
17:53Jasper[m]: The default kernel and DT at least got me to userspace, enabling the GPU or not. It's just that u-boot will pass the downstream DT by default, that doesn't work at all
18:08marysaka[d]: gfxstrand[d]: I got the fan to spin!
18:12gfxstrand[d]: \o/
18:12gfxstrand[d]: patch?
18:13marysaka[d]: pushing that...
18:13marysaka[d]: gfxstrand[d]: https://gitlab.freedesktop.org/marysaka/linux/-/tree/tx1-dev see the top two patches
18:23gfxstrand[d]: Jasper[m]: I don't know what dtb cboot is using. I'll try specifying the dtb I got from my build once I've built with marysaka[d] 's new patches
18:27gfxstrand[d]: I'm really suspecting it's devicetree issues
18:29karolherbst[d]: flash the uefi firmware and your issues will all be gone or something 😛
18:31Jasper[m]: karolherbst[d]: Board 2EOL4UEFI
18:31Jasper[m]: they only pushed that update to xavier and newer sadly
18:32karolherbst[d]: older ones also have uefi support
18:32marysaka[d]: no they don't sadly
18:32karolherbst[d]: well
18:32karolherbst[d]: mine uses uefi
18:32karolherbst[d]: and it's older than xavier
18:32marysaka[d]: it's the good old cboot bootflow
18:32karolherbst[d]: yeah, you need to flash it
18:32marysaka[d]: uboot would be your UEFI I guess buuut
18:33marysaka[d]: For the X1 there is nothing public at least on jetson download section
18:33karolherbst[d]: you don't need anything public, just flash an uefi enabled uboot
18:33gfxstrand[d]: My fan is spinning so I know I have the right DTB
18:33karolherbst[d]: fedora ones is even good enough for that
18:33karolherbst[d]: *are
18:34karolherbst[d]: https://nullr0ute.com/2020/11/installing-fedora-on-the-nvidia-jetson-nano/
18:34karolherbst[d]: nano, tx1 and tx2
18:35karolherbst[d]: (one of the things we talked with nvidia about to end up doing 🙃)
18:35gfxstrand[d]: gfxstrand[d]: And... hang
18:35karolherbst[d]: but yeah
18:35gfxstrand[d]: karolherbst[d]: Yeah, that's what marysaka[d] and I have been following
18:36karolherbst[d]: only xavier has real official nvidia full vendor support, everything below that is just "uhh yeah, we can do it, but it won't support all the things"
18:36karolherbst[d]: gfxstrand[d]: ahh
18:36karolherbst[d]: but why do you have device tree issues then?
18:36gfxstrand[d]: My board is cursed?
18:36karolherbst[d]: maybe?
18:37karolherbst[d]: I only tried the above on my nano and it worked without issues at least
18:37gfxstrand[d]: It worked without issues for both of Mary's TX1s
18:38karolherbst[d]: maybe ping Peter, might know something
18:39karolherbst[d]: pbrobinson I mena
18:40Jasper[m]: gfxstrand[d]: Same with a `devicetree` line on grub?
18:41Jasper[m]: karolherbst[d]: iirc Peter is nullroute right?
18:41karolherbst[d]: yes
18:41marysaka[d]: I think initially that's what I asked her to try but might be worth trying again
18:42marysaka[d]: also I scripted my full setup in case we needed more people to test and see if they could reproduce the issue that Faith is seeing https://github.com/marysaka/fedora_bringup_jetson_tx1
18:42marysaka[d]: (it just auto handle flashing of eMMC and prepare the Fedora image on an sdcard nothing too fancy but you know)
18:43gfxstrand[d]: Jasper[m]: Yup.
18:51gfxstrand[d]: So I'm definitely getting the new DTBs now because the fans spin
18:52gfxstrand[d]: And I've gut a custom kernel build so I can turn on all the logging if I want
18:53gfxstrand[d]: But IDK how much that'll help. It fails REALLY early.
19:00marysaka[d]: gfxstrand[d]: hmm just in case for good measure try booting with `clk_ignore_unused pd_ignore_unused`
19:17tiredchiku[d]: hecking
19:17tiredchiku[d]: matrix strikes again
19:18tiredchiku[d]: it's been 5 mins and this chat won't load
19:18tiredchiku[d]: (trying to reach out to haiku's nvk on nvrm dev)
19:18karolherbst[d]: do you know if they plan to upstream whatevr they have?
19:18esdrastarsis[d]: tiredchiku[d]: btw, your fork has some ampere specific code, right?
19:19tiredchiku[d]: karolherbst[d]: exactly why I'm reaching out
19:19tiredchiku[d]: esdrastarsis[d]: kinda? I replacedd their turing specific stuff with stuff specific to my device
19:19tiredchiku[d]: you know
19:19tiredchiku[d]: hardcode for the device you have as a prototype
19:20karolherbst[d]: well.. kinda wasn't a big fan of anybody doing the porting work, but maybe it's late enough, and nova already a solid plan that it's fine 😄
19:20tiredchiku[d]: there is a demand for NVK on nvrm, even outside of our spaces
19:20gfxstrand[d]: Oh, Nova is happening. NVK isn't going to hard-depend on out-of-tree modules.
19:21gfxstrand[d]: Any nvrm porting isn't a replacement for Nova
19:21tiredchiku[d]: yup
19:21tiredchiku[d]: just another kernel driver option for the driver
19:22gfxstrand[d]: What nouveau log options should I set to try and make sense of this lockup?
19:23airlied[d]: nouveau.debug=trace is where I usually start
19:24tiredchiku[d]: I could go to bed andd wake up tomorrow and matrix will still not be done loading this chat
19:24asdqueerfromeu[d]: tiredchiku[d]: Maybe we'll have NVK running on Nouveau, Nova, OGK and WDDM kernel drivers if things go really well
19:24airlied[d]: hope you got serial fast 🙂
19:33gfxstrand[d]: `nouveau.debug=trace` does nothing
19:33gfxstrand[d]: It's dying REALLY early
19:34marysaka[d]: It's dying on first IO access I think
19:34airlied[d]: it dies before trace I've no idea
19:35marysaka[d]: and giving async serror
19:35mohamexiety[d]: karolherbst[d]: one problem with depending on nova is that some stuff (e.g. compression) is a pain and having to wait for a year+ is kind of not an ideal situation. sure we're now working on it on nouveau but to say it's hard (and not in the fun type of hard) is an understatement
19:35karolherbst[d]: yeah, fair
19:42gfxstrand[d]: Ugh... Installing the prop driver totally screwed up my session. ðŸ˜
19:42gfxstrand[d]: Might be my fault for switching to Zink. <a:shrug_anim:1096500513106841673>
19:44tiredchiku[d]: :Stitch_lurk:
19:44tiredchiku[d]: you have to specify the vulkan icd
19:44tiredchiku[d]: if you're running znvk with the prop driver on-system
19:45gfxstrand[d]: Oh, it's worse...
19:45gfxstrand[d]: #0 0x00007fe47d0f43c4 in poll () from /lib64/libc.so.6
19:45gfxstrand[d]: #1 0x00007fe47cb57670 in _xcb_in_read_block () from /lib64/libxcb.so.1
19:45gfxstrand[d]: #2 0x00007fe47cb5b36b in xcb_connect_to_fd () from /lib64/libxcb.so.1
19:45gfxstrand[d]: #3 0x00007fe47cb5bd79 in xcb_connect_to_display_with_auth_info () from /lib64/libxcb.so.1
19:45gfxstrand[d]: #4 0x00007fe47cdb577a in _XConnectXCB () from /lib64/libX11.so.6
19:45gfxstrand[d]: #5 0x00007fe47cda5c7c in XOpenDisplay () from /lib64/libX11.so.6
19:45gfxstrand[d]: #6 0x00007fe475b740c5 in ?? () from /lib64/libGLX_nvidia.so.0
19:45gfxstrand[d]: #7 0x00007fe475b75262 in vk_icdNegotiateLoaderICDInterfaceVersion () from /lib64/libGLX_nvidia.so.0
19:45gfxstrand[d]: #8 0x00007fe475e3c620 in ?? () from /lib64/libvulkan.so.1
19:45gfxstrand[d]: #9 0x00007fe475e48062 in ?? () from /lib64/libvulkan.so.1
19:45gfxstrand[d]: #10 0x00007fe475e4e2c3 in vkEnumerateInstanceExtensionProperties () from /lib64/libvulkan.so.1
19:45gfxstrand[d]: #11 0x00007fe471cdc5b7 in zink_create_instance (screen=0x249f03b0, instance_info=0x7fe4751a57f0 <instance_info>)
19:45gfxstrand[d]: at src/gallium/drivers/zink/zink_instance.c:41
19:45tiredchiku[d]: some qt bug I couldn't find the source of that makes zink attempt to load the proprietary userspace driver even with NOUVEAU_USE_ZINK=1
19:45gfxstrand[d]: XWayland is opening Zink which is enumerating devices which enumerates on the prop driver which tries to connect to X which is what's trying to load Zink.
19:45tiredchiku[d]: oh
19:46tiredchiku[d]: oh it's not qt?
19:47tiredchiku[d]: unrelated, talking to the haiku dev right now
19:47tiredchiku[d]: they're pretty much denying my requests to join either here (banned on discord [?]), or the IRC, or the OFTC-Matrix bridged room
19:48tiredchiku[d]: and I quote
19:48tiredchiku[d]: Any help is welcomed, but I am not good at team work organization.
19:48tiredchiku[d]: I am focused on Haiku, but it should also work for Linux with minor changes. I later plan to make it working for both Linux and Haiku.
19:48tiredchiku[d]: Yes if it is possible. (re upstreaming)
19:48tiredchiku[d]: I am not sure about your plans, but Haiku NVK port have some specifics:
19:48tiredchiku[d]: - It should be buildable without libdrm.
19:48tiredchiku[d]: - Vulkan fences and semaphores should be reimplemented using NVRM abstractions (semsurf?), DRM syncobj can't be used. But on Linux DRM syncobj can be used in theory because of nvidia-drm.ko.```
19:48x512[m]: Hello.
19:49tiredchiku[d]: ah, hello :D
19:53gfxstrand[d]: RE: libdrm. If we have an nvrm back-end, that should use libdrm if it makes sense. Of course, nvrm isn't really a DRM driver. It's only barely enough of a DRM driver to do KMS and prime FD sharing. But we can probably enumerate as a DRM device so we should probably use it at least that far? <a:shrug_anim:1096500513106841673>
19:54gfxstrand[d]: RE: fences. Yeah, we don't have syncobj on nvrm anyway. I don't know how shared fences/semaphores are supposed to work on nvrm but we'll have to figure it out. They do claim to support sync_file (which is a bit of a lie) and we may want to support that on Linux.
19:55gfxstrand[d]: RE: upstreaming. I'm not thrilled about carrying code which we can't build in CI. If we can carry most of it as an nvrm driver and then Haiku carries some patches or a wrapper, that's fine. If we can somehow CI build the Haiku code, that's fine, too. I just don't want to be responsible for not breaking things I can't test.
20:00gfxstrand[d]: gfxstrand[d]: ahuillet notthatclippy[d] Mind forwarding this on to someone on your team? Trying to connect to the X server during `vk_icdNegotiateLoaderICDInterfaceVersion` is kinda mean and there's not much we can do to work around it.
20:03x512[m]: It will be no libdrm on Haiku, so device enumeration should be done using NVRM. It should also work on Linux, so no problems with CI here.
20:04airlied[d]: I'd also suggest enumeration ignore libdrm, and we only use it for direct display and interactions with other drm thing
20:04airlied[d]: in theory you can load the nvidia driver on linux without the drm driver
20:05x512[m]: Not on theory, but also in practice when using X.Org.
20:08gfxstrand[d]: That's fine. We have helpers for libdrm enumeration but we can also provide an old-fashioned enumeration hook and load that wy
20:09x512[m]: Am I visible here? I am using Matrix that may be not visible from IRC.
20:09tiredchiku[d]: you are, yes
20:09tiredchiku[d]: could also enumerate differently based on preprocessor guards
20:10tiredchiku[d]: just go down the non-libdrm path if it's running on haiku
20:11gfxstrand[d]: enumerating via nvrm is probably a good idea on Linux as well.
20:11gfxstrand[d]: That way we're not dependent on their funky DRM driver
20:12tiredchiku[d]: got you
20:12gfxstrand[d]: But keep going with whatever you have for now. We can get the loading situation right later
20:14tiredchiku[d]: mhm
20:15tiredchiku[d]: unfortunately I'm not gonna be very available until the 6th
20:15tiredchiku[d]: starting saturday
20:18redsheep[d]: gfxstrand[d]: I imagine this approach also helps if and when someone goes to see if this stuff works on windows too?
20:18gfxstrand[d]: Nah, Windows will have to use the LUID path
20:19tiredchiku[d]: there's some windows Vista references in openrm however
20:19tiredchiku[d]: :D
20:19gfxstrand[d]: But if they all share a bunch of ring handling code, that's fine.
20:23asdqueerfromeu[d]: tiredchiku[d]: I accidentally discovered that comment when browsing through unrelated OGK code
20:28mhenning[d]: gfxstrand[d]: pls review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32311 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34161 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33861
20:32redsheep[d]: I didn't realize you had working zcull
20:34tiredchiku[d]: mel is cool
20:34tiredchiku[d]: :saigeheart:
20:35mhenning[d]: aww, thanks
20:36gfxstrand[d]: How much faster does zcull make everything?
20:36mhenning[d]: redsheep[d]: yeah, zcull's been working for a few weeks. You can try it out if you want to build a custom kernel
20:37mhenning[d]: gfxstrand[d]: It's a somewhat minor improvement in my tests - eg. 3% on horizon zero dawn
20:38mhenning[d]: haven't tested to carefully with different games though
20:38redsheep[d]: It's probably going to depend on the gpu, where the bottlenecks are and all that
20:39mhenning[d]: Yeah, zcull can even vary from scene to scene - it depends on a lot of factors
20:40x512[m]: NVK is absurdly slow with MESA_VK_WSI_DEBUG=sw. Fixed by adding VK_MEMORY_PROPERTY_HOST_CACHED_BIT to wsi_select_host_memory_type.
20:40x512[m]: Is it a bug of Mesa Vulkan WSI or NVK memory types reporting?
20:41tiredchiku[d]: nvk doesn't expose an uncached sysmem type, so that kinda makes sense to me
20:41tiredchiku[d]: the nouveau kernel module doesn't support it
20:42x512[m]: VK_MEMORY_PROPERTY_HOST_COHERENT_BIT is currently resolved to VRAM in NVK.
20:42redsheep[d]: I am so excited for all of the things that will be easier to isolate and test with a second kmd to leverage
20:57gfxstrand[d]: mhenning[d]: 3% is nothing to shake a stick at
20:58mohamexiety[d]: airlied[d]: gfxstrand[d] in nouveau_bo.c, during bo init, how should the page sizing be done? the current code uses the first page size where the buffer's size is bigger than the page size. but is this what we want? (because the VM side of things chooses instead the biggest size that is aligned with the VA address, range, and bo_offset)
20:58gfxstrand[d]: x512[m]: Sounds like a WSI bug. We should be looking for CACHED for WSI since it's doing downloads.
20:59mohamexiety[d]: I am kinda curious about verifying this because I think me relaxing the GART requirement has led to me forcing the use of the huge pages (1 GiB+) everywhere which would explain everything dying I guess
21:00mohamexiety[d]: mohamexiety[d]: what nvbo->page sets afaiu is a maximum, so they don't need to match but nvbo->page needs to be >= the VM page
21:00mohamexiety[d]: at least afaiu that's the only restriction
21:01airlied[d]: gfxstrand[d]: oh and please review and not merge the mesa zcull mr, need the review to push the kernel patches first
21:03airlied[d]: mohamexiety[d]: that's why I wanted to get rid of ->page because I don't think it makes sense to fix that size at that point, I think you need to take all info into account to decide
21:03airlied[d]: whatever you pick are bo create is only informational, I think making it some sort of bitmask of allowed page sizes might be better, but also having a max but saying anything below this should be fine is also okay
21:12mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1354201318754877460/image.png?ex=67e46dc2&is=67e31c42&hm=e84d66ddc8e881ca2fa58ea8f2a67ab97ffe61a03eecdc967260d7974a9d3250&
21:12mohamexiety[d]: it is already effectively a bitmask. the issue is figuring out the starting point correctly (these are page shifts. S = sparse, V = VRAM, H = Host, C = Compression)
21:15airlied[d]: you start from the biggest page size that fits the bo and vm contstraints
21:16mohamexiety[d]: yeah which is easy on the vm side but not sure about the bo side
21:16airlied[d]: I think you pick the biggest page size < bog size
21:16airlied[d]: bo size
21:17airlied[d]: and use the constraint later
21:18airlied[d]: so yes nvbo->page should be the largest page that could be used with that bo if the vm constraints let it
21:21orowith2os[d]: gfxstrand[d]: It's enough to make zmike cry
21:22mohamexiety[d]: airlied[d]: I see, so basically how things currently are. (just with a little bug I introduced and fixed) thanks!
21:22mohamexiety[d]: anything vulkan still crashes/mmu faults though which is disappointing.
21:23airlied[d]: I think the theory is all good, just tracking down what isn't following it
21:25mohamexiety[d]: what's weird is that things worked fine on your end when you removed the LOCAL flag in nvk. I just changed the semantics of GART in the kernel which should be equivalent to what you did but instead everything explodes
21:50mohamexiety[d]: not sure if this is any helpful but I added a `printk` to print the chosen page_size in `nouveau_bo_init` in the page sizing loop right before it breaks and I am getting this:
21:50mohamexiety[d]: [ 91.395345] ogl page_size: 65536
21:50mohamexiety[d]: [ 91.397200] vm page_size: 4096
21:50mohamexiety[d]: [ 91.401966] nouveau 0000:01:00.0: gsp: mmu fault queued
21:50mohamexiety[d]: [ 91.405485] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:80 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000008020010000 fault_type:00000002
21:50mohamexiety[d]: [ 91.405488] nouveau 0000:01:00.0: fifo:c00000:000a:0050:[vulkaninfo[5180]] errored - disabling channel
21:50mohamexiety[d]: [ 91.405490] nouveau 0000:01:00.0: vulkaninfo[5180]: channel 80 killed!
21:50mohamexiety[d]: [ 91.431430] ogl page_size: 65536
21:50mohamexiety[d]: [ 91.433152] vm page_size: 4096
21:50mohamexiety[d]: [ 91.437559] nouveau 0000:01:00.0: gsp: mmu fault queued
21:50mohamexiety[d]: [ 91.440888] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:80 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000008020010000 fault_type:00000002
21:50mohamexiety[d]: [ 91.440891] nouveau 0000:01:00.0: fifo:c00000:000a:0050:[vulkaninfo[5180]] errored - disabling channel
21:50mohamexiety[d]: [ 91.440893] nouveau 0000:01:00.0: vulkaninfo[5180]: channel 80 killed!
21:50mohamexiety[d]: [ 91.449151] ogl page_size: 65536
21:50mohamexiety[d]: [ 91.450898] vm page_size: 4096
21:50mohamexiety[d]: [ 91.451177] vm page_size: 4096
21:50mohamexiety[d]: [ 91.451324] vm page_size: 4096
21:50mohamexiety[d]: [ 91.451385] vm page_size: 65536
21:50mohamexiety[d]: [ 91.451447] ogl page_size: 65536
21:50mohamexiety[d]: [ 91.453092] vm page_size: 4096
21:50mohamexiety[d]: [ 91.455681] vm page_size: 4096
21:50mohamexiety[d]: [ 91.455702] vm page_size: 65536
21:50mohamexiety[d]: [ 91.455892] vm page_size: 4096
21:50mohamexiety[d]: [ 91.456034] nouveau 0000:01:00.0: gsp: mmu fault queued
21:50mohamexiety[d]: [ 91.459181] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:88 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000008020039000 fault_type:00000002
21:50mohamexiety[d]: [ 91.459185] nouveau 0000:01:00.0: fifo:c00000:000b:0058:[vulkaninfo[5180]] errored - disabling channel
21:50mohamexiety[d]: [ 91.459188] nouveau 0000:01:00.0: vulkaninfo[5180]: channel 88 killed!
21:50mohamexiety[d]: [ 91.467800] nouveau 0000:01:00.0: gsp: mmu fault queued
21:50mohamexiety[d]: [ 91.470915] nouveau 0000:01:00.0: gsp: rc engn:00000001 chid:80 gfid:0 level:2 type:31 scope:1 part:233 fault_addr:0000008020010000 fault_type:00000002
21:50mohamexiety[d]: [ 91.470921] nouveau 0000:01:00.0: fifo:c00000:000a:0050:[vulkaninfo[5180]] errored - disabling channel
21:50mohamexiety[d]: [ 91.470924] nouveau 0000:01:00.0: vulkaninfo[5180]: channel 80 killed!
21:50mohamexiety[d]: "ogl page_size" is for the non VM path, and vm page_size is for the vm path (`if (!nouveau_cli_uvmm(cli) || internal)` and the opposite, respectively)
21:51mohamexiety[d]: I am even more confused now because it seems the vm path rarely goes above 4KiB so why does it crash when all I did is just relax the GART thing. and for that matter why does the vm path rarely go above 4KiB :thonk:
21:57mohamexiety[d]: maybe it does crash because there's a mismatch from the uvmm code, but that also makes no sense; the uvmm code should always return a size smaller than the one that nouveau_bo_init sets
21:57airlied[d]: probably want to dump the domains to see
21:58mohamexiety[d]: domains?
21:58airlied[d]: but also compression might make a difference since the vm path doesn't look at that
21:58mohamexiety[d]: yeah right now it doesnt look at it at all
22:00mohamexiety[d]: I did comment out the check on `pi` though. `pi` is always = to `i` now
22:02mohamexiety[d]: (on both sides, so compression shouldnt matter)
22:03mohamexiety[d]: ..wait is `nvif_vmm->page` ordered ascendingly or descendingly? i.e. is page[0] the largest or smallest?
22:05mohamexiety[d]: (I thought that page[0] was the largest)
22:07airlied[d]: pretty sure the first is largest
22:09mohamexiety[d]: yeah which makes sense. but then why does it still loop to the smallest size in that case? it should only do that if the buffer is small
22:10mohamexiety[d]: that said I guess one thing I could try is only change things in the vm path, and leave the ogl path as is
22:10mohamexiety[d]: since afaik that was already working properly, even with the GART restriction
22:42x512[m]: Where dev_info.chipset value come from? Is it Nouveau-specific or defined by hardware itself?
22:44gfxstrand[d]: karolherbst[d]: ^^
22:53mohamexiety[d]: mohamexiety[d]: h-huh.. that.. worked. I am even more confused because vulkan things should be using the vm path. what is going on
22:54Jasper[m]: @_oftc_gfxstrand[d]:matrix.org that lockup you're experiencing, is it panicking? Is output just stopping?
22:54Jasper[m]: (for the tx1)
22:54mohamexiety[d]: even vkcube is working now?? but I am seeing _a lot_ of `ogl_page_size` spam in dmesg, almost nothing `vm_page_size` :thonk:
22:55mohamexiety[d]: (also ogl_page_size interestingly is mostly 4KiB too; rarely 64KiB)
23:05mohamexiety[d]: the vulkan smoke tests also run, but those seem to be using the non vm bind path so I am not sure what's at play here
23:07mhenning[d]: x512[m]: x512: The chipset value comes from the hardware. see https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c?h=v6.14#n3112
23:08mhenning[d]: It also corresponds to nvidia's internal engieering name for the card eg. an NV10 is chipset 0x10
23:11airlied[d]: make sure you have the printfs in the right paths :-), there should definitely be some vm path ones
23:12x512[m]: What about dev_info.sm value? I see that it is converted from "chipset" value in a long switch-case in NVK code.
23:13mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1354231649348485230/image.png?ex=67e48a01&is=67e33881&hm=73c5e899a2a199ecf80164b9bfa701db448920836536e386493a4642bf37895c&
23:13mohamexiety[d]: airlied[d]: I did think of this but.. doesn't this catch the non vm and vm ones right as they get chosen?
23:14mhenning[d]: For dev_info.sm , I'd guess that there's a way to read it out of hardware, but I'm not really sure. That corresponds to cuda's gencode option for a given card
23:14gfxstrand[d]: x512[m]: That's supposed to correspond to NVIDIA's CUDA shader model number.
23:21mohamexiety[d]: mohamexiety[d]: (to be clear -- there are vm page outputs, and they are 64KiB. they're just much much fewer than the non-vm ones that I feel this isn't correct somehow)
23:22mohamexiety[d]: the non vm outputs are also mostly 4KiB with comparatively much fewer 64KiB ones which is also confusing
23:24mohamexiety[d]: either way I think the idea was to change the semantics for both, so there's still some investigating to be done. I am just not sure why everything really explodes when I change the semantics on the non vm side
23:27airlied[d]: I definitely would dig into what is going on there, granted I think context creation creates some bos, but they should be on the vma for vma ones
23:27gfxstrand[d]: Anyone else poking about with the proprietary driver and getting weird modesetting? It looks like the simple-framebuffer driver is taking over my display and not giving it up
23:32mohamexiety[d]: airlied[d]: Do you have any pointers on where to begin here? I am not really seeing anything that stands out tbh
23:33mohamexiety[d]: And the mmu fault type being “PTE not found” doesn’t really say much
23:36redsheep[d]: gfxstrand[d]: Tbh I think modesetting is broken for me even on windows, takes a huge amount of time and blinks like crazy throughout so if it's broken on openrm I wouldn't notice
23:37redsheep[d]: It got a lot worse after getting my 4k240 panel, maybe to do with DSC, dunno
23:38redsheep[d]: redsheep[d]: Unless you're seeing issue sbad enough you never reach a working desktop, in which case no I am not hitting that on prop
23:38gfxstrand[d]: I get a 640x480 desktop with no acceleration
23:41redsheep[d]: Hmm. I think I did see that at one point but I'm not sure it matches and not sure what I did to fix it, it was mixed in with a lot of other troubleshooting and bugs
23:42mhenning[d]: gfxstrand[d]: I didn't have that issue when testing yesterday
23:43redsheep[d]: Is your display manager Wayland or x? Or are you seeing that after launching a session?
23:45gfxstrand[d]: Arch wiki to the rescue! `nvidia_drm.modeset=1`
23:45gfxstrand[d]: It's so nice of the Arch folks to document all of Linux.