00:07gfxstrand[d]: We'll see once it's finished
00:08gfxstrand[d]: But I also threw a patch on top to hammer uncached maps even harder
02:46gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1432923476263571456/0001-nouveau-Use-WC-maps-instead-of-uncached.patch?ex=6902d17b&is=69017ffb&hm=20269d1ab8b31c9874a5475abdad68bbd6405320b530118bc15fc73ebf9805df&
02:46gfxstrand[d]: steel01[d]: This might unblock us:
02:47steel01[d]: And this works even with much of ttm blocked behind CONFIG_X86?
02:47gfxstrand[d]: Yeah
02:47gfxstrand[d]: And roll back minigbm to bb0e401c7bb10fcd91032f45781f51471510e92e
02:48gfxstrand[d]: That combination might do the trick. There's still a bunch of CTS fails but coherent maps should mostly work.
02:48steel01[d]: gfxstrand[d]: Is this before the refactor?
02:49gfxstrand[d]: yeah
02:49gfxstrand[d]: If UC maps work through nouveau, there's no point in doing anything through tegra
02:50steel01[d]: Alright, cool.
02:50steel01[d]: I'm shuffling some other kernel stuff atm. Once I get that working again, I'll pull this all in and see what I see.
02:55gfxstrand[d]: cool
02:56gfxstrand[d]: I'm hoping that and a bugfix or two will get us to where we can run apps and I can actually try to land AHB support for real, which is my actual main goal.
03:04x512[m]: What is the difference between UDMABUF and SHM? Is it possible to import UDMABUF to NVK?
03:14gfxstrand[d]: Yeah, should work. UDMABUF is just a dma-buf driver that just lets you create dma-bufs. That's all it is.
03:15gfxstrand[d]: And they're backed by regular every day system memory
03:18x512[m]: What about SHM FD?
04:11gfxstrand[d]: No. That's not a dma-buf
04:12gfxstrand[d]: On other drivers you might be able to use external_memory_host but we don't have support for that in the nouveau kernel.
09:08phomes_[d]: mhenning[d]: I ran my tests but did not see any noticeable perf improvements
12:00jja2000[d]: gfxstrand[d]: Damn
12:01jja2000[d]: gfxstrand[d]: That's half the fails compared to last time^
12:06jja2000[d]: Is this, bar any other issues, a full solution to the cache coherency problem? Or is it a fix before the actual solution is implemented like it is with panfrost?
12:10gfxstrand[d]: Oh, my kernel patch is a total hack. I honestly don't believe it at all.
12:11gfxstrand[d]: Like, I believe that it's whacking bits in PTEs and that the new bits are somehow less crashy. But I have no idea why WC would be safe when UC throws SIGBUS.
12:12gfxstrand[d]: And I'm not convinced it's actually 100% properly coherent.
12:12gfxstrand[d]: But I'm gonna look into a few more of the fails once I get to the office and maybe it'll turn out they're all silly userspace bugs.
12:14jja2000[d]: Fingers crossed
12:15gfxstrand[d]: I did find one such "clearly a me problem" bug last night. We'll see if I find more.
12:52gfxstrand[d]: Full 10% run from last night:
12:52gfxstrand[d]: Pass: 128365, Fail: 62, Crash: 2, Warn: 1, Skip: 155301, Timeout: 5, Flake: 187, Duration: 3:01:21
13:04jja2000[d]: gfxstrand[d]: Last time^
13:05jja2000[d]: Insane
13:49karolherbst[d]: you always wonder when is the time people stop using like old gpus and then you see issues like this: https://gitlab.freedesktop.org/drm/nouveau/-/issues/457
13:54x512[m]:waiting for Milk-V Titan to run Haiku on it with Nvidia GPU.
14:20gfxstrand[d]: Ugh... CTS bugs. Looks like Boris beat me to them.
14:58mohamexiety[d]: karolherbst[d]: this isn't just old gpus, this is also with _SPARC_ O_O
15:04gfxstrand[d]: Why are cooperative vector tests trying to run on Tegra?!?
15:06marysaka[d]: are you running deqp-runner?
15:06gfxstrand[d]: yes
15:06marysaka[d]: if some test crash it sometime gets some false positives like that
15:06marysaka[d]: even tho they will appears as skips
15:06marysaka[d]: had that randomly it's annoying :nya_flop:
15:07marysaka[d]: (like if deqp-runner crash)
15:09gfxstrand[d]: Ugh... deqp-runner was running 8x, not 4x
15:09gfxstrand[d]: So things were OOMing
15:11gfxstrand[d]: I don't think this kerne has a working tx1 fan support
15:12gfxstrand[d]: That might be part of why things are so slow
15:12gfxstrand[d]: marysaka[d]: didn't you have a patch for that?
15:12marysaka[d]: uuum yeah give me a sec
15:13marysaka[d]: gfxstrand[d]: two last commits https://gitlab.freedesktop.org/marysaka/linux/-/commits/tx1-dev?ref_type=heads
15:14marysaka[d]: thermal zone might be wrong but the fan spin with that at least 😄
15:14marysaka[d]: actually shouldn't it be working? https://github.com/torvalds/linux/commit/01f11ffdfd909e870c3863af60875e8de328790a
15:14marysaka[d]: it's in 6.16 it seems
15:15marysaka[d]: hmm no one defined thermal zones tho urgh
15:17gfxstrand[d]: Yeah, it's not spinning
15:19marysaka[d]: if you are on 6.16+ I guess you just need top commt
15:20gfxstrand[d]: 6.12
15:22marysaka[d]: so you have none of that I guess grab my patches they would do the job just fine
15:23marysaka[d]: (they were on top of 6.13)
15:23gfxstrand[d]: Booting
15:23gfxstrand[d]: in theory
15:24gfxstrand[d]: Yay! Fan!
16:44leftmostcat[d]: Not entirely following how https://kuterdinel.com/nv_isa/PLOP3.html lines up with `encode()`. Seems like mostly fields line up with the first instruction there, but there are some differences (in particular, the LUT seems to write into areas the diagram says are for operand 3), but also I'm not sure how I would condition for a separate opcode. It seems to use opcode 0x21f, which is unique to all
16:44leftmostcat[d]: sources being R0.SIGN, so check that in a manner similar to the `self.is_uniform()`?
16:51leftmostcat[d]: (https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/nouveau/compiler/nak/sm70_encode.rs#L2268)
16:59mhenning[d]: "in particular, the LUT seems to write into areas the diagram says are for operand 3" - I suppose it's possible that's a bug. Maybe write an nvdisasm_test for plop3 to begin with and see if everything encodes correctly
17:32steel01[d]: gfxstrand[d]: You're on 6.12 on fedora? That seems awful old for a current rootfs.
17:42steel01[d]: gfxstrand[d]: Oh, also. This is before you added the shrink modifier thing. I'm adding it back, but typoed stuff a couple times. >< Hopefully I got it straight this build.
18:24gfxstrand[d]: `Pass: 128317, Fail: 42, Crash: 2, Warn: 1, Skip: 155370, Timeout: 6, Flake: 185, Duration: 2:50:00, Remaining: 0`
18:25rislingsinreif: I place very high demands on my thinking and it has been successful, only very strong persons can do this, i mean i have strong organs to guard/weight down the risk taken. I want to commit the data access routines soon, so from there the execution is easy but will not be committed by me, it will start the world war III otherwise. I spotted a major issue which had been suspected for years
18:25rislingsinreif: as i was talking, out of specification's band radio. However it can be committed once the infrasystem is good enough to catch or detect and filter out those evil attempts. How radio works is magical, but cosmologically i admit i do not know why radio waves work the way they do, i know there is electro and magnet components, i had looked into lienard wiechert formulas, bluetooth and such
18:25rislingsinreif: specifications are there to stay, and they will be de facto standards and taking a huge leap forward when the stream gets compressed heavily. Current hw did not yet account very fast duty cycles, and can not demanufactured you know or banned industrially like say automatic guns/firearm from us market.
18:39steel01[d]: 01-01 00:00:27.034 0 0 E : [ C0] nouveau 57000000.gpu: fifo: fault 01 [WRITE] at 0000003efd63c000 engine 00 [gr] client 0f [GPC0/PROP_0] reason 02 [PTE] on channel 5 [04003e4000 BootAnimation[643]]
18:39steel01[d]: 01-01 00:00:27.051 0 0 E : [ C0] nouveau 57000000.gpu: fifo:000000:0005:[BootAnimation[643]] rc scheduled
18:39steel01[d]: 01-01 00:00:27.059 0 0 E : [ C0] nouveau 57000000.gpu: fifo:000000: rc scheduled
18:39steel01[d]: 01-01 00:00:27.065 9 9 E nouveau 57000000.gpu: fifo:000000:0005:0005:[BootAnimation[643]] errored - disabling channel
18:39steel01[d]: 01-01 00:00:27.076 9 9 W nouveau 57000000.gpu: BootAnimation[631]: channel 5 killed!
18:39steel01[d]: Mmm, so angle still implodes.
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : ANGLE Warn:MemoryTracking.cpp:50 (OutputMemoryLogStream): Currently allocated size for memory allocation type (TextureImage): 4194304 | Count: 2
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : --> Heap index 0: 4194304 | Count: 2
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : ANGLE Warn:MemoryTracking.cpp:50 (OutputMemoryLogStream): Currently allocated size for memory allocation type (Buffer): 8487168 | Count: 6
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : --> Heap index 0: 8487168 | Count: 6
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : ANGLE Warn:MemoryTracking.cpp:50 (OutputMemoryLogStream): Memory heap info
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL :
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : * Available memory heaps:
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : 0 | Heap size: 3051356160 | Flags: 0x1
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL :
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : * Available memory budget and usage per heap:
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : 0 | Heap budget: 2349858816 | Heap usage: 15073280
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL :
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : * Available memory types:
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : 0 | Heap index: 0 | Property flags: 0xb
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : 1 | Heap index: 0 | Property flags: 0x7
18:39steel01[d]: 01-01 00:00:26.504 631 643 W libEGL : ANGLE Warn:ContextVk.cpp:7225 (handleError): Internal Vulkan error (-4): The logical or physical device has been lost.
18:39steel01[d]: 01-01 00:00:26.505 631 643 W libEGL : ANGLE Warn:Debug.cpp:186 (insertMessage): GL error: HIGH: Error: 0x00000507, in external/angle/src/libANGLE/renderer/vulkan/CommandQueue.cpp, queueSubmitLocked:1006. Internal Vulkan error (-4): The logical or physical device has been lost.
18:40steel01[d]: Running a build to try pure vulkan rendering.
19:01gfxstrand[d]: Cursed: We can implement `iadd_sat@32` in 4 instructions and `iadd_sat@64` with 6 instructions with predication
19:16airlied[d]: Uncached vs writecombine makes sense from the underlying macros but no idea what the WC mapping actually means on arm CPUs, the NC is definitely a device mapping which will be bad for userspace
19:24jja2000[d]: gfxstrand[d]: That's a bit less no?
20:02steel01[d]: 10-29 18:39:53.454 482 482 E [minigbm:nouveau_bo_create_for_modifier(681)]: Allocating new BO: 48x48, fourcc = AB24, size = 12288 domain = 0xc, pte_kind = 0xfe, tile_mode = 0x0, modifier = 0x0
20:02steel01[d]: 10-29 18:39:53.455 665 688 E [minigbm:nouveau_bo_map(782)]: DRM_NOUVEAU_GEM_INFO failed with No such file or directory
20:02steel01[d]: 10-29 18:39:53.455 665 688 E system_server: Mapping failed.
20:02steel01[d]: 10-29 18:39:53.455 665 688 W Gralloc4: lock(0xb400002bd743d9b0, ...) failed: 3
20:02steel01[d]: 10-29 18:39:53.455 665 688 W Surface : failed locking buffer (handle = 0xb400002bd743d9b0)
20:02steel01[d]: 10-29 18:39:53.455 665 688 E system_server: Error -38 locking sprite surface before drawing.
20:02steel01[d]: Trying to render the normal ui with skiavk gets this. The bootani renders fine, but when it tries to bring up the pairing screen, this happens.
20:02steel01[d]: Iirc, this is the same error as before, which started you down the path of copying stuff between the drivers.
20:15HerryJames[m]: https://t.me/+jLJNhUzVTUphODVk
20:25karolherbst: dwfreed: I wished I could create a shared akick list for multiple channels, because it appears that I'll probably have to ban the same ranges on other channels soonish :')
20:30dwfreed: yeah, something coming with the ircd upgrade eventually
20:31karolherbst: nice
20:32karolherbst: maybe I should set up a spam bot... I got my hands on a couple of IPs used by VPNs and it's a lot and I need a better way to manage it...
21:02leftmostcat[d]: How do I build the nvdisasm tests? I have `-Dbuild-tests=true` and `-Dgallium-drivers=nouveau`—and `libnak_rs.a` builds—but I don't see any related test executables.
21:12marysaka[d]: leftmostcat[d]: gallium doesn't use nak tho :aki_thonk:
21:12marysaka[d]: so build NVK too maybe
21:12marysaka[d]: I do build with -Dtools=nouveau also
21:16leftmostcat[d]: Heh, silly me. That said, config does say it's building nouveau under Vulkan drivers (and nak builds, just not the tests).
21:18leftmostcat[d]: (`-Dtools=nouveau` doesn't seem to help.)
21:39gfxstrand[d]: Soooooo many CTS bugs....
21:40gfxstrand[d]: 5 CLs and counting
21:40mhenning[d]: leftmostcat[d]: "NAK’s instruction encodings are tested against nvdisasm using src/nouveau/compiler/nak/nvdisasm_tests.rs (build with -D build-tests=true and run src/nouveau/compiler/nak nvdisasm_tests from the build dir)"
21:40mhenning[d]: from https://docs.mesa3d.org/drivers/nvk/external_hardware_docs.html
21:42leftmostcat[d]: Ahh, thank you.
21:46leftmostcat[d]: Do I need to use an older version of nvdisasm? Using 13.0.85 and SM70 isn't available as an option for `--binary`.
21:47mhenning[d]: oh,yeah recent versions dropped sm70 support
21:47mohamexiety[d]: why do you want 70?
21:47mohamexiety[d]: that's Volta
21:47mhenning[d]: you can remove sm70 from the array
21:47mhenning[d]: or you can downgrade to 12.x
21:48mhenning[d]: mohamexiety[d]: The disasm tests run against a bunch of different architectures by default, including volta
21:48mohamexiety[d]: ohh sorry
21:49leftmostcat[d]: Okay, tests running successfully.
21:49steel01[d]: gfxstrand[d]: From tegra or something else?
21:55gfxstrand[d]: tegra
21:56steel01[d]: Whee. So if nothing else, the test get more robust out of this. 😛
21:57gfxstrand[d]: yeah
21:57steel01[d]: 10-29 20:53:42.236 1369 1383 F HWUI : Assertion failed: queueProps[i].queueFamilyProperties.queueCount < kRequestedQueueCount
21:57steel01[d]: Okay, I've gotten this in a few cases. It's the only error I'm seeing atm in my log using the newer minigbm code with split tegra/nouveau stuff. A search seems to indicate this is vulkan related, even though I see nothing in the text to indicate that. 0o
21:58steel01[d]: "The code attempted to request more queues from a specific queue family than the device physically supports."
22:00mhenning[d]: Oh, yeah we only expose one queue right now, although we could support more
22:00steel01[d]: https://android.googlesource.com/platform/frameworks/base/+/main/libs/hwui/renderthread/VulkanManager.cpp#252
22:00steel01[d]: Appears to be this.
22:00marysaka[d]: steel01[d]: HWUI requires 2 queues since Android 15
22:00marysaka[d]: or was it 16 can't remember
22:00steel01[d]: Ahhh, so this is gonna need to be another thing on the android support list ticket.
22:00steel01[d]: This is 16.
22:01mhenning[d]: If you want to hack at it you can increase the queue count - last time I tried that it worked correctly although it degraded perf in some benchmarks
22:01steel01[d]: If you point me to the general code location, I can try later tonight.
22:02mhenning[d]: Something like
22:02mhenning[d]: diff --git a/src/nouveau/vulkan/nvk_physical_device.c b/src/nouveau/vulkan/nvk_physical_device.c
22:02mhenning[d]: index b51f2b5912c..7c2e1335cf2 100644
22:02mhenning[d]: --- a/src/nouveau/vulkan/nvk_physical_device.c
22:02mhenning[d]: +++ b/src/nouveau/vulkan/nvk_physical_device.c
22:02mhenning[d]: @@ -1538,7 +1538,7 @@ nvk_create_drm_physical_device(struct vk_instance *_instance,
22:02mhenning[d]: VK_QUEUE_COMPUTE_BIT |
22:02mhenning[d]: VK_QUEUE_TRANSFER_BIT |
22:02mhenning[d]: VK_QUEUE_SPARSE_BINDING_BIT,
22:02mhenning[d]: - .queue_count = 1,
22:02mhenning[d]: + .queue_count = 2,
22:02mhenning[d]: };
22:02mhenning[d]: assert(pdev->queue_family_count <= ARRAY_SIZE(pdev->queue_families));
22:03mhenning[d]: marysaka[d]: Is it 2 graphics queues or does it just need eg. a graphics queue and a transfer queue?
22:05mhenning[d]: From the code snippet it looks like it's 2 graphics queues
22:05leftmostcat[d]: Bad news is that my quick-and-dirty PLOP3 test failed, good news is that it's because I forgot a semicolon at the end.
22:06steel01[d]: Quick and easy. Kicked a build. Not sure it'll be done before I have to go afk for a while, though.
22:07steel01[d]: Is the queue count semi-arbitrary? Or is the a real physical limitation somewhere?
22:08mhenning[d]: somewhere inbetween
22:08steel01[d]: Performance degrades with each increase and the tradeoff becomes not worth it at some point?
22:08mhenning[d]: in theory we could probably expose an arbitrary number of queues but we can only actually have one graphics program running at a time
22:09marysaka[d]: what do we do on nouveau side around TSG?
22:10steel01[d]: Mmm. So if aosp requires 2. But only 1 has been needed to date. Is there any normal Linux distro use case for more? If this does 'just work', wondering how a real patch would look. Just eat the performance loss, or guard on ANDROID?
22:10mhenning[d]: It's not even that performance is expected to degrade (I think that's a driver issue in this case) so much as it doesn't make sense to support more if you can't actually run in parallel
22:10marysaka[d]: actually on non-gsp that concept just doesn't exist I suppse as it was always the driver responsability to handle that on nvgpu from what I recall...
22:11steel01[d]: Ah, so c) fix the bug you saw earlier. 😛
22:12mhenning[d]: marysaka[d]: I don't know. I think we do need to do more work around it if we want to use simultaneous compute and graphics, which is on my todo list, but I'm not sure the current state
22:13marysaka[d]: mhenning[d]: the blobs does report 16 queues here so maybe very arbitrary? I should really dig into openrm and GSP interactions for context creation at some point tbh
22:14marysaka[d]: One of the thing on my list is actually defining all magical values on the GSP side of nouveau code and commenting stuffs to get a full understanding of what is going on there and then compare with openrm
22:14steel01[d]: On a tangential topic, marysaka[d]. Had any chance to look at the probe failures on the tx1 unit you traded?
22:14marysaka[d]: I have a feeling we have a bit of different around that could be mistake ect
22:15marysaka[d]: steel01[d]: no have been busy with $stuffs, might poke at it next month or in december will see
22:15steel01[d]: It baffles me. No idea what's going on. I've got a nano unit that sometimes fails, sometimes doesn't.
22:16marysaka[d]: probably related to Max PMIC
22:16marysaka[d]: the whole failures are literally what you get when the TSEC domain is busted/off
22:16steel01[d]: Maybe. The best idea I had was speedo values, which affect the frequency clock tables. But those didn't help either.
22:17marysaka[d]: yeah the fact being that L4T works fine
22:17marysaka[d]: so there must be something different enough
22:17marysaka[d]: do we get the same issue on NX?
22:18steel01[d]: TSEC? Mmm. That's something I hadn't thought of. Though, I know the term for the general tegra security engine. Is that what you're talking about?
22:18marysaka[d]: TSEC A/B yes
22:18marysaka[d]: those are actually used by the GPU side
22:18steel01[d]: marysaka[d]: Some units, yes. Including Faith's. Hence the issues for her being able to do anything on tegra. 😛
22:18marysaka[d]: I know that nvgpu does drive them
22:18steel01[d]: Mmm. Trying to think if I've even got them fired up atm. I don't think so.
22:19marysaka[d]: and load some of the blobs there, can't remember what blob tho it has been years
22:19marysaka[d]: it might be for HDCP/Widevine stuffs tho so maybe we don't need them but who knows
22:19steel01[d]: I tried to use the... rsa? engine and the driver was corrupting verity hashes. >< So I ripped it back out. Need to report that bug sometime.
22:19steel01[d]: marysaka[d]: This sounds right. Afaik, it shouldn't be necessary in general.
22:25marysaka[d]: steel01[d]: right no it's nvhost (aka host1x) that drives it
22:25marysaka[d]: is host1x active?
22:26steel01[d]: Oh yes. The display controller is under host1x, so there'd be no pixels on screen otherwise.
22:27steel01[d]: Until orin, anyways. There's something different there.
22:28steel01[d]: I'm rather completely lost what happened to orin. There's the display controller. Then the display control engine. Then the gpu. Then... who knows what else. ><
22:28marysaka[d]: hmm we have the two TSEC defined in dts but no drivers for them
22:28marysaka[d]: will have to check BSP kernel at some point for diff anyway
22:28steel01[d]: Is there not? Ohhhhh... memory tingling. There's only support for t234 tsec, right.
22:29marysaka[d]: you mean "cheese" configuration?
22:29steel01[d]: And it's only for rsa/hmac/etc. It's a small slice of what the engine is capable of.
22:29marysaka[d]: that can be configured on T210 actually
22:29steel01[d]: Cheese? Doesn't ring a bell in this context.
22:29marysaka[d]: the whole caveat configuration for TSEC
22:30marysaka[d]: what is covered as secure ect
22:30marysaka[d]: but anyway unrelated
22:30steel01[d]: The mainline support for tegra is all unsecure. Like nvdec doesn't support the secure firmware at all afaik. Similar for everything else.
22:31steel01[d]: There's stuff showing up recently to handle vpr for orin/t234. But it's... kinda piecemeal.
22:31steel01[d]: I wouldn't think any of the secure stuff would be required to put accelerated pixels on screen. If it is, I'd say someone goofed in design.
22:39leftmostcat[d]: Miraculously, I got plop3.lut with three .sign params to disasm correctly. I'll definitely need some feedback on how to handle a couple of the places where `SrcMod` is matched, though.
22:40marysaka[d]: steel01[d]: did you touch any of the clock setup code in nouveau to try to debug that mess?
22:41marysaka[d]: nvgpu setup code looks different than nouveau https://nv-tegra.nvidia.com/r/plugins/gitiles/linux-nvgpu/+/570f03764fa9f3e014b9c90a48aa7635edf4c0ac/drivers/gpu/nvgpu/os/linux/platform_gk20a_tegra.c#476
22:41marysaka[d]: gm20b follow gk20a logic ect
22:42leftmostcat[d]: But that's a problem for tomorrowmost.
22:42marysaka[d]: on nouveau we only setrate for one clock sometime https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c#L247
23:02steel01[d]: marysaka[d]: Not really. I added clocks for gp10b, but that's only gpcclk. Set that and bpmp does the rest. Matches nvgpu. Beyond that, the clock code breaks my brain. Like gm20b scaling... Ow.
23:08steel01[d]: steel01[d]: Squeaking in right under the wire. Looky there, let there be pixels. Got the setup wizard rendering now after bumping the queue count. I'll have to do further verification later.
23:57phomes_[d]: mhenning[d]: I tested this quickly. I did not see a change in perf on my tests. I did get two games crashing with an error like this: `nouveau 0000:01:00.0: AtomicHeart-Win[281822]: Failed to find syncobj (-> in): handle=52`