08:23 airlied[d]: marysaka[d]: over here then, of if there is a limit of 15 on delays that might explain it if I need a longer one
08:23 airlied[d]: I'll take a closer look tomorrow
08:23 marysaka[d]: yes exactly that 👍
08:24 karolherbst[d]: airlied[d]: there are two limits, one is 15, the other is 11 or 12
08:25 karolherbst[d]: it's weird, but yes
08:25 airlied[d]: ah yes this one is 22 🙂
08:25 karolherbst[d]: did I give you the ampere scoreboarding docM
08:25 karolherbst[d]: ?
08:25 airlied[d]: yup, though I'm playing on Turing, I did look for mentions of NOPs today but didn't find it
08:26 karolherbst[d]: it explains the layout of the scheduling bits
08:26 airlied[d]: but it makes sense now
08:26 karolherbst[d]: airlied[d]: yeah, so that was my assumption that nvidia might do nops to implement proper waits
08:27 karolherbst[d]: normally you'd be able to use the bypass latency which is quite a lot lower
08:27 airlied[d]: I think they just delay 15 then delay 7 in a nop
08:27 airlied[d]: I see we have some unexplained nop adding code in the instr latency coded
08:27 airlied[d]: " // It's unclear exactly why but the blob inserts a Nop with a delay of 2
08:27 airlied[d]: // after every instruction which has an exec latency. Perhaps it has
08:27 airlied[d]: // something to do with .yld? In any case, the extra 2 cycles aren't worth
08:27 airlied[d]: // the chance of weird bugs.
08:28 karolherbst[d]: .yld doesn't exist
08:29 karolherbst[d]: it's part of the wait count and there are two different types of waits you can encode
08:45 airlied[d]: I can probably drop that section if I fix nop emission
08:58 airlied[d]: then its time to figure out the 9 vs 27 TFlops difference on the coop matrix benchmark
09:23 marysaka[d]: airlied[d]: it might be related to the store modifier
09:23 karolherbst[d]: airlied[d]: do you take bypass into account?
09:24 marysaka[d]: I don't support that so far
09:24 marysaka[d]: like it's some kind of ST.X4/X2 ect
09:24 marysaka[d]: (my memory is quite vague around that but I saw those used with coop matrix stores)
09:25 karolherbst[d]: bypass I think is, if you use the dest reg in the next mma instruction in the C slot, but I might be wrong
09:25 karolherbst[d]: dest from another mma
09:25 karolherbst[d]: allows you to reduce the wait quite a lot
09:25 karolherbst[d]: though that alone shouldn't explain 9 vs 27 😄
09:30 marysaka[d]: oh so like the "chaining" happening? I suppose that would manifest a lot with Turing right now if you use M16N16K32/M16N8K32 with the lowering I have here https://gitlab.freedesktop.org/mesa/mesa/-/blob/6abe19882ef65734e70fd7ffd9995b629df161de/src/nouveau/compiler/nak_nir_lower_cooperative_matrix.c#L437
10:01 karolherbst[d]: marysaka[d]: yeah
10:01 karolherbst[d]: it makes a massive difference
10:02 karolherbst[d]: it's like 4 vs 13 or 10 cycles of waits
10:14 airlied[d]: I think ldsm will bump it a little, and I think the current load and stores could be vectored better
13:32 gfxstrand[d]: I think the dep tracker can do big delays. It just inserts nops as needed.
13:38 gfxstrand[d]: airlied[d]: Yeah, there's a bit of 🤷🏻‍♀️ in there.
13:39 gfxstrand[d]: Barriers and a few things like that needed something. Wasn't clear what from looking at the blob output.
17:22 snowycoder[d]: Do you have any NAK regressions tests that could be useful?
17:22 snowycoder[d]: Like some recently added/fixed NAK optimization or lowering?
17:24 _lyude[d]: gfxstrand[d]: got it btw 🙂
17:24 _lyude[d]: just waiting for the upgrade to finish now
17:24 gfxstrand[d]: yay
17:25 gfxstrand[d]: snowycoder[d]: Tests for copy-prop and modifiers would be good. And maybe the `i2b(b2i(x))` optimization
17:35 _lyude[d]: Hey - where coulc I get the r570 firmware btw?
17:36 gfxstrand[d]: bskeggs' linux-firmware tree on gitlab
17:36 _lyude[d]: gotcha
18:52 Lyude: TimurTabi: do you have a more up to date version of your gsp dump patch that works with the latest gsp series that ben has sent out? Trying to get some logs from my laptop with ben's GSP branch since it seems like I can actually get the GPU up far enough finally to get some useful information
18:52 Lyude: runtime PM is still broken fwiw, but i'm hoping this can give us some more information
18:56 TimurTabi: Lyude: eh, my patches are in Nouveau already, and I'm not aware of any conflict with Ben's stuff.
18:56 Lyude: oh I didn't realize. where are the debugfs directories these days? I didn't see anything when I built ben's branch
18:57 TimurTabi: /sys/kernel/debug/nouveau/
18:58 TimurTabi: I had to move them there because the normal Nouveau debugfs path didn't stick around long enough.
19:00 Lyude: TimurTabi: i sssume maybe I need something on the kernel commandline to get it to make a log then?
19:00 TimurTabi: only if you're debugging a GSP-RM startup crash
19:00 TimurTabi: otherwise, it should exist always until the device shuts down.
19:01 Lyude: gotcha, it's definitely not present on ben's branch then :p. the main reason I asked was because looking at the code, pretty much all of it references r535
19:01 Lyude: which isn't the gsp version on ben's latest branch
19:01 TimurTabi: oh, that's because Ben is switching to r570
19:02 TimurTabi: are you asking for the binaries for r570, so that you can boot?
19:02 TimurTabi: his code should still support r535
19:02 Lyude: no, I was asking because I wanted to get debugging logs from r570 as the GPU is able to initialize a lot further on this machine then r535
19:03 airlied: Lyude: pretty sure Ben's branch has the code
19:03 TimurTabi: ah, well, you need to do the same thing as before. Send me or Ben the debugfs entries so that we can run our internal tool on them and generate logs.
19:05 Lyude: to be clear, https://gitlab.freedesktop.org/bskeggs/nouveau/-/commits/03.00-r570?ref_type=heads is the latest branch right
19:05 TimurTabi: No, I think it's 03.01-gb20x
19:05 airlied:is using the gb20x branch on my gb20x
19:06 TimurTabi: Ben's work is mostly about adding support for Hopper and Blackwell, and for that we need r570
19:06 TimurTabi: That also requires new firmware images. I've updated the Python script to generate them, but that's still going through internal testing, so I can't quite publish them.
19:06 TimurTabi: That also requires new firmware images. I've updated the Python script to generate them, but that's still going through internal testing, so I can't quite publish it.
19:07 TimurTabi: But, if you need it, I can send a copy directly. We're transitioning the FMC images from a simple binary blob to an ELF image.
19:07 TimurTabi: The script generates the ELF
19:08 TimurTabi: Ben's current public branch does uses the old FMC image format.
19:22 redsheep[d]: airlied: You have a Blackwell card? Which one?
19:51 airlied[d]: I have no idea what the marketing name is, but also it's a laptop so not really a card 🙂
19:57 redsheep[d]: I assume that is still not able to boot all of the way? I am still hoping to get mine soon but it's not looking good. I would have hoped that 6 weeks later we'd be past the stage where 5090's are only really available in $6000 bundles with a bunch of overpriced crap I don't need
20:02 redsheep[d]: Had I known the only reasonably appealing way to purchase the card would be a bundle with a 4k240 oled I would have held off buying one...
20:02 mohamexiety[d]: time for a dual monitor setup
20:02 redsheep[d]: dual 4k240 LOL yeah that's necessary
20:04 redsheep[d]: Hmmmm... It would be a really good way to stress the new display engine
20:04 mohamexiety[d]: ~~I am sorry in advance~~
20:15 redsheep[d]: Buying a new gpu ⚖️ Down payment on a house
21:00 _lyude[d]: gfxstrand[d]: btw - does the cursor issue happen outside of X? (also kinda curious why you're running X11)
21:02 gfxstrand[d]: _lyude[d]: No. Most wayland compositors look at the DRM caps and just use that. Nouveau advertises 64x64 as the recommended cursor resolution so they never attempt a 32x32 cursor. The X11 modesetting driver, on the other hand, tries to get clever and find the smallest cursor size.
21:02 gfxstrand[d]: Why am I running X? To find all the X bugs, of course!
21:03 _lyude[d]: gfxstrand[d]: which cap are you talking about btw? I don't know of any cap that recommends a specific cursor size, only a maximum cursor size
21:05 gfxstrand[d]: `DRM_CAP_CURSOR_WIDTH/HEIGHT`. It's not a min or a max. It's just a size that's guaranteed to work. Most Wayland compositors seem to follow that.
21:06 _lyude[d]: ah i see
21:06 _lyude[d]: case DRM_CAP_CURSOR_WIDTH:
21:06 _lyude[d]: if (dev->mode_config.cursor_width)
21:06 _lyude[d]: req->value = dev->mode_config.cursor_width;
21:06 _lyude[d]: else
21:06 _lyude[d]: req->value = 64;
21:07 _lyude[d]: break;
21:07 _lyude[d]: i honestly didn't even know this ioctl was a thing
21:08 gfxstrand[d]: Neither did I until a week ago. 😅
21:08 gfxstrand[d]: I asked the exact same question you just asked and then went digging through kwin code until I found that.
21:09 _lyude[d]: tbh it definitely isn't terribly helpful that `cursor_width` seems to be a, pretty vague name for this. it's not even clear to me if it's actually supposed to be a min or a max, so honestly I'm not sure the modesetting driver is doing the wrong thing by trying to figure out the size like it does
21:10 gfxstrand[d]: Oh, check `drm.h`. It's explicitly neither a min nor a max!
21:10 gfxstrand[d]: It's great
21:10 gfxstrand[d]: 🤡
21:10 jannau: struct drm_mode_config.cursor_{width,height} are documented as max though
21:11 tiredchiku[d]: gfxstrand[d]: I have a collection of emoji, you can pick which would be the appropriate reaction here
21:11 tiredchiku[d]: :Clown:: :clowncar: :clownbus: :clownplane: :clowntrain:
21:11 tiredchiku[d]: /j
21:12 redsheep[d]: It's a 2d surface, so clearly it is the clownplane
21:14 tiredchiku[d]: tiredchiku[d]: I actually use this as a clownery rating scale of some kind, because the number of people gets larger across the scale :ha:
21:16 gfxstrand[d]: We need a clown mouse to use for cursor issues
21:17 _lyude[d]: freedesktop downloadable free cursor pack
21:18 _lyude[d]: comes with a free toolbar
21:18 redsheep[d]: So is the actual root issue here that the kernel just shouldn't claim 32x32 can work after a certain generation, or what?
21:18 _lyude[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349129431603740754/image.png?ex=67d1fa32&is=67d0a8b2&hm=5035d4db84ee105d2f1a06b129c7aa237b777471a952baf46709e83dad5ce180&
21:18 _lyude[d]: no dnf no nonono you cannot do that???
21:18 _lyude[d]: what
21:19 marysaka[d]: that's a new one :nya_confused:
21:19 _lyude[d]: yeah
21:19 _lyude[d]: this machine really does not want me looking at its cursors
21:20 _lyude[d]: thankfully it doesn't seem like it broke anything so hopefully I should have kde running in a second to take a look at this
21:22 _lyude[d]: bonus at least: I think for the first time in months using ben's latest nouveau branch seems to have finally stopped my nv gpu from crashing on this machine
21:22 _lyude[d]: hooray for no longer doing a speedrun of my battery health by having my laptop at 50c always 🥲
21:22 redsheep[d]: Has anyone figured out why an x session on nouveau gl doesn't have the exact same cursor breakage?
21:22 _lyude[d]: does it not?
21:22 _lyude[d]: fwiw: gl shouldn't know what a cursor is
21:22 _lyude[d]: it's too innocent for such things
21:22 redsheep[d]: Not for me, and never heard anyone else mention an issue like that
21:23 _lyude[d]: I mean are you on KDE? I can see that gnome's cursor behavior seems to be to go straight to max cursor size
21:23 redsheep[d]: I am
21:23 _lyude[d]: sus
21:24 _lyude[d]: redsheep[d]: can you get the output of `/sys/class/drm/debug/dri/0/state`?
21:24 redsheep[d]: any perticular kernel or drivers or session I need to boot to get you the right data? I assume not if just getting some sysfs
21:25 _lyude[d]: just the X11 setup where you aren't seeing the cursor issue
21:25 _lyude[d]: but also your kernel version and such would be appeciated
21:25 _lyude[d]: since I know that faith is running R570 iirc
21:25 _lyude[d]: (i super doubt that's the issue but you never know…)
21:26 redsheep[d]: I don't have that branch ready to go for me, but I can maybe get that going in a bit. I will grab from r535 on 6.14rcSomething in a sec
21:28 tiredchiku[d]: gfxstrand[d]: okay, which one
21:28 tiredchiku[d]: :clowncursor:: :clownmouse:
21:29 _lyude[d]: ... gfxstrand[d] this is a silly question but how exactly does one start a KDE session with X. I see plasma listed in GDM but I don't see any option for wayland/no wayland
21:29 tiredchiku[d]: ...did I get out of bed and boot up my PC at nearly 3 am for this?... maybe
21:29 tiredchiku[d]: _lyude[d]: install plasma-x11-workspace
21:29 _lyude[d]: thank you
21:30 tiredchiku[d]: or is it plasma-workspace-x11
21:30 tiredchiku[d]: idk, one of the two, I don't use fedora .-.
21:30 _lyude[d]: latter
21:30 tiredchiku[d]: :birdnotes:
21:31 _lyude[d]: ngl i really wish I didn't already have a lot of time invested in a gtk application I maintain because every time I load up KDE I'm like wow this is so nice and they even have a cute furry mascot (thanks tysontan)
21:31 _lyude[d]: all gnome gets is a foot.
21:31 _lyude[d]: a foot.
21:32 tiredchiku[d]: I like kde plasma because
21:32 tiredchiku[d]: uh
21:32 tiredchiku[d]: :PlasmaRifle:
21:32 tiredchiku[d]: /j
21:33 redsheep[d]: My system taking soooo long to reboot is a real drag for doing this kind of thing
21:35 redsheep[d]: Ok I've booted rc6 mainline
21:35 tiredchiku[d]: _lyude[d]: no such file or dir :doomthink:
21:38 _lyude[d]: tiredchiku[d]: try 1?
21:39 _lyude[d]: gfxstrand[d]: so at least on the r535 branch on my test machine with AD107 I'm not seeing any cursor issues
21:39 tiredchiku[d]: _lyude[d]: is your xserver built with that glamor patch?
21:40 _lyude[d]: no clue but it's using a pretty big cursor
21:40 tiredchiku[d]: the squished cursor doesn't occur without it
21:40 redsheep[d]: oh that requires the glamor patch to see? that explains a few things
21:40 tiredchiku[d]: _lyude[d]: there's no /sys/class/drm/debug to begin with
21:40 _lyude[d]: wat
21:41 redsheep[d]: yeah I am seeing I have to go to a card in drm
21:41 _lyude[d]: OH
21:41 tiredchiku[d]: <a:kittynod:1081663261046489169>
21:41 tiredchiku[d]: and even in it there's no debug
21:41 _lyude[d]: /sys/kernel/debug/dri/0/state try that
21:42 _lyude[d]: honestly wonder if I'll have better luck just trying modetest here
21:42 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349135386550603786/output.log?ex=67d1ffbd&is=67d0ae3d&hm=490c0380678bb859d9c40ad34cfc536d6facc5bcc1988e473e1c8e8ad9fcb631&
21:42 redsheep[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349135485812998194/cursedor.txt?ex=67d1ffd5&is=67d0ae55&hm=355f092cdec25f450fce55a2b008748782ff633ded6370ae6b2f42a60e8054fa&
21:42 _lyude[d]: my telekinesis says your cursor is invisible right now
21:42 tiredchiku[d]: _lyude[d]: false
21:43 tiredchiku[d]: oh
21:43 tiredchiku[d]: oh yeah it goes invis over the terminal
21:43 tiredchiku[d]: hang on
21:43 _lyude[d]: yeah my telekinesis is always spot on
21:43 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349135759843659796/outputDeux.log?ex=67d20016&is=67d0ae96&hm=7e3988a38fe4487820d1847baaa4d5f1bfc2f5b875c2d96acde6f83d6f58f60a&
21:43 tiredchiku[d]: that should be it
21:44 redsheep[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349135855255687290/cursedor2.txt?ex=67d2002d&is=67d0aead&hm=69e240a331c93b55cd7e0bb3715468c55d76ed2426c9cfa3dc65ba2470f25c12&
21:44 redsheep[d]: sid you keep being faster
21:44 tiredchiku[d]: I am speed
21:44 redsheep[d]: you're supposed to be asleep, not faster
21:44 tiredchiku[d]: KACHOW MF
21:44 _lyude[d]: !! so your cursor is 32x32
21:45 tiredchiku[d]: _lyude[d]: so you need this patch: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1857 on xserver to reproduce
21:45 tiredchiku[d]: it's comical I tell you
21:45 _lyude[d]: oh dear
21:45 _lyude[d]: this is very comical i don't like that this is the patch in question
21:45 _lyude[d]: let me patch up an RPM real quick
21:46 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349136358861705226/rn_image_picker_lib_temp_80062877-3202-437c-9325-46f4f30f5faf.jpg?ex=67d200a5&is=67d0af25&hm=efeaf10feb0d3749969e8845bae4a6115378ca28f65288c45b5cb0c566125ee8&
21:46 tiredchiku[d]: squimch
21:46 redsheep[d]: Why in the world does that patch even impact the cursor rendering to begin with
21:46 tiredchiku[d]: my phone camera has astigmatism, ignore that
21:46 _lyude[d]: oh yay that photo gives me a vague idea of what's going on
21:46 _lyude[d]: downside: the thing that looks like is going on should really not be possible anymore
21:47 tiredchiku[d]: there's a zombie on your lawn~
21:48 tiredchiku[d]: the black region on the bottom is actually
21:49 tiredchiku[d]: black and transparent lines, alternating
21:49 tiredchiku[d]: one pixel wide each
21:49 redsheep[d]: Also I suppose in my case having display scaling means I am setting my cursor to 48 so it probably wouldn't try 32x32 to begin with. When I have had 24 set because that is what works for wayland I also did not see the bug with the microscopic cursor but... well obviously I didn't have the glamor patch at any point
21:49 tiredchiku[d]: if I revert to xorg release the cursor is fine again
21:52 tiredchiku[d]: anyway, I go bed
21:58 gfxstrand[d]: redsheep[d]: Maybe it's not using modesetting? IDK. Is nouveau X11 still a thing?
22:00 redsheep[d]: Still a thing? I am not sure I follow. Until recently it was the best kind of session for me, still kind of is
22:00 tiredchiku[d]: the ddx driver still exists, yes
22:00 gfxstrand[d]: tiredchiku[d]: Wait, you need that to get broken cursors?!? wut?
22:00 gfxstrand[d]: I was pretty sure I had broken cursors without that
22:00 tiredchiku[d]: gfxstrand[d]: yeah, cursor is fine for me without that
22:00 tiredchiku[d]: nouveau, the gift that keeps on giving
22:00 gfxstrand[d]: :blobcatnotlikethis:
22:00 redsheep[d]: let me try making my cursor all tiny and try again
22:01 redsheep[d]: Yep completely fine on ngl plasma x11
22:02 redsheep[d]: and very difficult to see on my monitor lol
22:02 tiredchiku[d]: I'm just using KDE's default cursor size
22:02 tiredchiku[d]: which, according to the cursor settings, is "24"
22:02 redsheep[d]: Same, 24x24. Or at least I am now. I have to enlarge it so that it matches display scaling most of the time
22:02 tiredchiku[d]: though I've seen the same on gnome, i3, and awesomewm
22:05 gfxstrand[d]: tiredchiku[d]: Either but the cursor one is even more cursory
22:09 _lyude[d]: yeah tbh this really has me wondering if something that isn't directly kernel related is happening here but I guess we'll see, rpm should be done now
22:09 redsheep[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349142176595968112/cursedor3.txt?ex=67d20610&is=67d0b490&hm=644b9320996b2d9c4f8924fb50cd65f4c41507f2117981447a34c7a0c9006dc8&
22:09 redsheep[d]: ?????? Am I reading this right? It's saying this session is using a 256x256 cursor?!?
22:09 redsheep[d]: Maybe if I could actually get it to make the cursor plane 32x32 I would see it but it appears it just... isn't doing that
22:10 _lyude[d]: yes
22:10 _lyude[d]: that's what peetty much all of my setups seem to default to
22:10 redsheep[d]: Yeah, I don't get it. How can Sid see a 32x32 cursor, let alone dependent on that patch
22:11 tiredchiku[d]: single 27 inch 1440p monitor on my end
22:11 tiredchiku[d]: if that matters at all
22:11 redsheep[d]: Are you getting 256 when not using the glamor patch?
22:11 tiredchiku[d]: something something pixel density
22:11 tiredchiku[d]: redsheep[d]: I dunno
22:11 tiredchiku[d]: could check
22:11 _lyude[d]: aaaand no dice
22:11 redsheep[d]: it just seems like these things should really be unrelated
22:12 tiredchiku[d]: https://tenor.com/view/getting-out-of-bed-daniel-labelle-waking-up-wake-up-from-sleep-im-up-gif-27186874
22:12 _lyude[d]: though it still seems like it's defaulting to a 256x256 cursor
22:12 _lyude[d]: i'm going to just try modeset
22:15 tiredchiku[d]: ooh yeah
22:15 tiredchiku[d]: getting a 256x256 cursor on xserver 21.1.16
22:15 redsheep[d]: Wait. You're testing the previous release vs the branch for the glamor patch, right?
22:16 tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1349143888031649873/outputDrei?ex=67d207a8&is=67d0b628&hm=c88e4df7e6a69a39dcbbc74dac8ce13d15575b71eb0924cb29d5b23c4ac1ec25&
22:16 redsheep[d]: Meaning the actual difference between the two... is the entirety of that release
22:16 tiredchiku[d]: bah I forgot the file extension
22:16 tiredchiku[d]: redsheep[d]: hm.. yeah
22:17 tiredchiku[d]: there's not too many commits since that release
22:17 tiredchiku[d]: I can maybe bisect it tomorrow
22:17 redsheep[d]: There could be code literally anywhere in the xorg release breaking the cursor size picker. So yeah I am sure there is a kernel bug making 32x32 a bad idea and that would be good to fix, another core issue is picking it to begin with
22:18 redsheep[d]: or hardware issue even, idk
22:18 tiredchiku[d]: tiredchiku[d]: 21.1.16 was tagged in mid-february
22:19 tiredchiku[d]: will bisect
22:19 _lyude[d]: is there a newer xorg server tag?
22:19 tiredchiku[d]: not yet, no
22:20 tiredchiku[d]: the gitlab repo has no tags
22:20 tiredchiku[d]: like, at all
22:21 tiredchiku[d]: I went through the threads for each month here: https://lists.x.org/archives/xorg-announce/
22:21 tiredchiku[d]: to determine when the last xserver release was
22:21 tiredchiku[d]: :froge:
22:23 _lyude[d]: oh yay now the nvidia card in my laptop dies with a segfault
22:23 _lyude[d]: was nice while it lasted
22:24 tiredchiku[d]: it is 0353 I better get my ass to bed
22:24 tiredchiku[d]: you nerds are fun though 🩷
22:27 _lyude[d]: going to take a break from this for a little bit so I can figure out how to fix the new issue on my laptop, this is turning out to be a royal pain to reproduce
22:33 mhenning[d]: gfxstrand[d]: nouveau ddx is only for older cards - it's not a thing on more recent gens
22:34 redsheep[d]: Do you mean like the xf86nouveau driver that blows things up?
22:35 mhenning[d]: uh does it blow things up?
22:35 redsheep[d]: I remember having to uninstall something like that a while back to get my nouveau working, yeah. No idea what the status is for that more recently though
22:36 mhenning[d]: Yeah, it's the xf86-video-nouveau package in arch
22:36 redsheep[d]: Was told distros should not be installing that
22:36 mhenning[d]: Well, installing it is supposed to not do anything for recent cards
22:36 mhenning[d]: but also we don't support it super well
22:42 mhenning[d]: Looks like the ddx supports up to pascal (which is actually more recent than I remembered)
22:42 mhenning[d]: but yeah, no ddx on volta+
22:45 gfxstrand[d]: Oh, for those trying to repro the bug: It doesn't appear with just the default X cursor. You have to fire up a compositor. Why? I don't know. :blobcatnotlikethis:
22:53 redsheep[d]: gfxstrand[d]: Do you have to composite to end up with a separate cursor plane? I would imagine not, and I would bet that the default cursor is just doing a larger plane if you look at the `/sys/kernel/debug/dri/0/state` info we looked at earlier
22:56 gfxstrand[d]: plane[63]: curs-0
22:56 gfxstrand[d]: crtc=head-0
22:56 gfxstrand[d]: fb=121
22:56 gfxstrand[d]: allocated by = X
22:56 gfxstrand[d]: refcount=1
22:56 gfxstrand[d]: format=AR24 little-endian (0x34325241)
22:56 gfxstrand[d]: modifier=0x0
22:56 gfxstrand[d]: size=32x32
22:56 gfxstrand[d]: layers:
22:56 gfxstrand[d]: size[0]=32x32
22:56 gfxstrand[d]: pitch[0]=128
22:56 gfxstrand[d]: offset[0]=0
22:56 gfxstrand[d]: obj[0]:
22:56 gfxstrand[d]: name=0
22:56 gfxstrand[d]: refcount=3
22:56 gfxstrand[d]: start=001050af
22:56 gfxstrand[d]: size=262144
22:56 gfxstrand[d]: imported=no
22:56 gfxstrand[d]: crtc-pos=32x32+782+559
22:56 gfxstrand[d]: src-pos=32.000000x32.000000+0.000000+0.000000
22:56 gfxstrand[d]: rotation=1
22:56 redsheep[d]: Ok, so a genuine 32x32
22:56 gfxstrand[d]: normalized-zpos=1
22:56 gfxstrand[d]: color-encoding=ITU-R BT.601 YCbCr
22:56 gfxstrand[d]: color-range=YCbCr limited range
22:56 gfxstrand[d]: color_mgmt_changed=0
22:56 redsheep[d]: That's with the default cursor that works?
22:57 gfxstrand[d]: Not sure what you mean
22:57 gfxstrand[d]: That's just kwin
22:57 redsheep[d]: I mean the default x cursor you were referring to when not running a compositor
22:57 gfxstrand[d]: No, that's with kwin
22:57 gfxstrand[d]: IDK what it is with the default X cursor
22:58 redsheep[d]: gfxstrand[d]: Ok, so the broken case, that makes sense
23:02 airlied[d]: I think the default X cursor is bigger than 32x32
23:03 redsheep[d]: Yeah, I would bet without the compositor it would show 64x64 or 256 there, so having it work is no mystery