00:00orowith2os[d]: Added a comment to the Vulkan spec for a bit more context fwiw
00:04orowith2os[d]: mhenning[d]: Is it bad that I thought that the rust code in there was C
00:04orowith2os[d]: I only realized after scrolling down and seeing "extern "C"" and I was like, what the???
00:05orowith2os[d]: It just feels like C code written on top of Rust
00:05orowith2os[d]: Not really saying anything about it. But damn, threw me for a loop for a sec
00:39gfxstrand[d]: This might be a two-line Xorg patch, actually.
00:43zmike[d]: but what if I am running old xorg through flatpak ?
00:45orowith2os[d]: Then you're probably SOL there
00:45orowith2os[d]: Closed as WONTFIX + L bozo +
00:45zmike[d]: wow toxic
00:46orowith2os[d]: That last + was going to have a "ratio" next to it
00:49TranquilIty[m]: I should rejoin the fdo Discord that's bridged to here, those seem like very fun conversations
00:52gfxstrand[d]: **CALL FOR TESTING:**
00:52gfxstrand[d]: xserver: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1857
00:52gfxstrand[d]: Zink+NVK: gfxstrand/zink/all-the-fixes
00:53gfxstrand[d]: That should work with bare-metal X11, including when apps are run with either `NOUVEAU_USE_ZINK=0` and `NOUVEAU_USE_ZINK=1`.
00:53gfxstrand[d]: Hopefully it doesn't break XWayland, either.
00:54gfxstrand[d]: And with that, I'm gonna call it a day and go make supper
00:56gfxstrand[d]: Cursors seem a bit broken. I need to look into that.
00:58orowith2os[d]: gfxstrand[d]: Does xwayland even use glamor?
00:58orowith2os[d]: I don't think it does
00:59orowith2os[d]: Ah, I'm wrong
01:00gfxstrand[d]: I'm not sure. I think it still needs *something* if you use X rendering stuff.
01:00gfxstrand[d]: But if it's just a DRI3 buffer that's passed from client to compositor, I think it just passes it along.
01:03gfxstrand[d]: I feel gross writing X code but at least it's not as horrible as what I started typing
01:11zmike[d]: didn't all the mesa stuff already land
01:11zmike[d]: and yes everything uses glamor
01:14gfxstrand[d]: All what mesa stuff?
01:15zmike[d]: your zink fixes branch
01:17gfxstrand[d]: No, I've got some NVK patches in there now to not blow up on nouveau BO imports and there's a few more bugs I need to fix.
01:17gfxstrand[d]: Something's going funky with cursors for one.
01:18gfxstrand[d]: And sync is busted
01:18zmike[d]: so it's working perfectly
01:18zmike[d]: great work
01:20gfxstrand[d]: It's working better than it has any right to, that's for sure.
01:21zmike[d]: is that really true?
01:21zmike[d]: it's a graphics stack built by two of the greatest meme connoisseurs in the ecosystem
01:21zmike[d]: why wouldn't it work
01:21zmike[d]: :lul:
01:22zmike[d]: more than two considering how many hours redhat donated from airlied's timebank for reviews
01:26airlied[d]: I was going to see what the odds of gfxstrand[d] getting annoyed and rewriting zink from scratch in rust were
01:27zmike[d]: surely the glsl compiler is in more dire need of RIIR
01:27airlied[d]: needs a lot more rage built up to tackle that one
01:29gfxstrand[d]: I'd rather rewrite nouveau GL than Zink
01:32zmike[d]: don't worry it's almost time for my annual descriptor rewrite
01:32zmike[d]: that'll be ample zink rewriting for the quota
01:32TranquilIty[m]: <zmike[d]> "surely the glsl compiler is in..." <- Frontend ?
01:33TranquilIty[m]: GLSL -> NIR I mean
01:33zmike[d]: I mean everything involving glsl
01:33TranquilIty[m]: Preferably rip out all of Gallium plz
01:33zmike[d]: ???
01:34airlied[d]: you can put down the bong now, it's okay
01:34zmike[d]: hahahaha
01:35TranquilIty[m]: Unsure I follow
01:37gfxstrand[d]: Gallium isn't going anywhere. It might be more and more merged with the state tracker code but gallium is pretty solid.
01:38airlied[d]: it's like the core internal API between all of the non-vulkan mesa pieces, ripping it out would be pretty meaningless
04:04redsheep[d]: gfxstrand[d]: I would heed this call, but um. The idea of building and installing xorg git somehow feels like 30x crazier than running mesa git like I do all the time
04:37gfxstrand[d]: It's not as bad as it used to be.
04:37gfxstrand[d]: You have to build X from git and the libinput driver as well
04:37gfxstrand[d]: And they both have like zero config flags
04:39airlied[d]: as long as you don't need a working nvidia prop driver 🙂
04:40redsheep[d]: pfft who needs one of those
04:40gfxstrand[d]: Just re-install your old packages when you're done testing
04:40gfxstrand[d]: Okay, so with that Xorg patch, I can straight-up put a `panic!()` in NIL if it ever sees a linear image and X and plasma both start up fine.
04:41redsheep[d]: Honestly if the kernel could drive my displays even just a little bit better the only point of prop for me would be doing comparisons
04:42gfxstrand[d]: I would like to know what's wrong with my cursors, though.
04:42gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347429209122799616/image.png?ex=67cbcabd&is=67ca793d&hm=16570eee424c7c671fc8ebf5e80d95ca1b3360c162c6030d302dc0f5b3fa990c&
04:42gfxstrand[d]: That's clearly squished by half
04:43redsheep[d]: Somebody really needs to do wideputin with that cursor superimposed
04:44gfxstrand[d]: My GNOME cursor is also squished
04:44gfxstrand[d]: But the initial X cursor is fine.
04:44gfxstrand[d]: What gives?!?
04:45redsheep[d]: Is it switching between software and hardware cursor at some point?
04:45gfxstrand[d]: Not sure.
04:45gfxstrand[d]: I think kwin uses a SW cursor given how slow it is but I though GNOME used a HW cursor
04:45redsheep[d]: You might want to try KWIN_FORCE_SW_CURSOR=1
04:46gfxstrand[d]: It's possible they're both using HW cursor
04:49gfxstrand[d]: Doesn't seem to make a difference but I also don't know if the flag is working
04:49gfxstrand[d]: But it happens with GNOME as well so I think it's a glamor issue
04:53gfxstrand[d]: I should probably focus on the sync thing tomorrow.
04:55gfxstrand[d]: We should also throw some old school window managers at it to make sure all the xrender crap works
04:56tiredchiku[d]: testing hours? 👁️
04:56tiredchiku[d]: oh, xserver patch
04:56tiredchiku[d]: okay!
04:56redsheep[d]: Depending how my afternoon goes tomorrow I might have some time to ~~destroy my linux install~~ test that xorg branch
04:57redsheep[d]: This is one of those things where I should probably set up rsync snapshots or something in case I throughly ruin things
04:57tiredchiku[d]: yolo
04:57tiredchiku[d]: :wololo:
04:58orowith2os[d]: This is why I use nixos :RimuruFingerGuns:
04:58orowith2os[d]: Even though I might rebuild my entire system every two hours because of my patches
04:58gfxstrand[d]: https://tenor.com/view/thats-the-spirit-cuphead-the-cuphead-show-you-can-do-it-good-energy-gif-27345872
04:58tiredchiku[d]: yolo everything, if it breaks your system, just unyolo
04:58tiredchiku[d]: ez
04:59orowith2os[d]: orowith2os[d]: And when I'm done with this motorcycle for the time being, I'm gonna maintain a gnome-git flake :frog_gears:
04:59orowith2os[d]: I have like four different pull requests that got stalled because of that motorcycle
04:59gfxstrand[d]: Okay, I need to go to bed.
05:01tiredchiku[d]: gfxstrand[d]: wait faith before you go, is it just the one xorg patch or do I need any additional MRs over mesa?
05:02redsheep[d]: the all the fixes branch
05:02gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347434204866150420/image.png?ex=67cbcf64&is=67ca7de4&hm=f1bed57c2084830b55bd1f1716e6dc582960f34f4c1ed9cb84031ca478827442&
05:02gfxstrand[d]: XRender does work
05:02gfxstrand[d]: tiredchiku[d]: grab my zink/all-the-fixes branch
05:03tiredchiku[d]: :FaustOK:
05:03gfxstrand[d]: gfxstrand[d]: See also^^
05:03tiredchiku[d]: ah it was mentioned
05:03tiredchiku[d]: :derproo:
05:03tiredchiku[d]: in my defense I woke up 10m ago
05:03gfxstrand[d]: Yeah, quite a ways up the chat, though.
05:03tiredchiku[d]: also I imagine you want me to run without nouveau.atomic=1
05:04gfxstrand[d]: Or with. Or both.
05:04tiredchiku[d]: been using it for a couple days now with no issues that I can see
05:04gfxstrand[d]: https://tenor.com/view/all-the-things-hyperbole-and-a-half-do-all-the-things-excited-gif-16018689
05:05gfxstrand[d]: I think we're getting close to the final situation so the goal now is to test every combination we can, beat the shit out of it, and see if things break.
05:05tiredchiku[d]: now you're talking my language
05:05tiredchiku[d]: <a:Pepefight:1295712308789645365>
05:05gfxstrand[d]: I know about the squashed cursor bug and the sync issues. Anything that isn't those two and isn't the kernel just failing at display, I'd like to know about.
05:06tiredchiku[d]: sync issues being the flickery x11, yeah? showing parts of previous frames?
05:06gfxstrand[d]: Yeah
05:06orowith2os[d]: gfxstrand[d]: Waiting for the "remove nouveau-gl" pull request to mesa :hammy:
05:06tiredchiku[d]: okay
05:06gfxstrand[d]: bare-metal X has a lot of problems with that.
05:06tiredchiku[d]: it does
05:07tiredchiku[d]: mesa branch built, time to go build x11 :wolfFIRE:
05:07gfxstrand[d]: orowith2os[d]: We still need it for old hardware but I want to un-WIP https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29232 ASAP.
05:08orowith2os[d]: Hmm, would nouveau-gl be best with a little reworking to be only for pascal and older?
05:08tiredchiku[d]: I think it should be OK to unWIP it once the sync issues have been solved on x11
05:09gfxstrand[d]: Yeah, I think so.
05:09orowith2os[d]: orowith2os[d]: Like, with all the work done for NVK, I'm sure Maxwell could get a little love
05:09gfxstrand[d]: We're rapidly getting to the point where NVK+Zink is better than nouveau GL.
05:09gfxstrand[d]: orowith2os[d]: Honestly, Zink+NVK may be better on Maxwell at this point.
05:09orowith2os[d]: Hmm, Maxwell was actually a gen that supported reclocking without firmware, right...?
05:10bsbs83[m]: 𝐌𝐄𝐒𝐒𝐀𝐆𝐄 BlackHat_Nexus 𝐅𝐎𝐑 𝐀𝐍𝐘 𝐊𝐈𝐍𝐃 𝐎𝐅 𝐒𝐄𝐑𝐕𝐈𝐂𝐄 𝐑𝐄𝐂𝐎𝐕𝐄𝐑 𝐘𝐎𝐔𝐑 𝐀𝐂𝐂𝐎𝐔𝐍𝐓... (full message at <https://matrix.org/oftc/media/v1/media/download/AeT-0p-GIPgDu5bfL9UaMSKxiAYIud34GTJMjQaqVE6W2U6Uof6C_dwlYSqmLrlXrlU9qJI0toSov9oDk2DDT6hCeVtxu48gAG1hdHJpeC5vcmcvV2txendEZHRNSWlVa1V0aUtFWWNuYXVl>)
05:10gfxstrand[d]: Maxwell A does but not Maxwell B.
05:10gfxstrand[d]: Unfortunately, Maxwell A has broken compute shaders right now and I don't know why (though I have theories)
05:10orowith2os[d]: gfxstrand[d]: What's the difference, in kernel pov?
05:10gfxstrand[d]: <a:shrug_anim:1096500513106841673>
05:10orowith2os[d]: Just not allowing unsigned firmware to load?
05:11gfxstrand[d]: I think Maxwell A is the one where we can actually control fans.
05:11tiredchiku[d]: bsbs83[m]: oh joy
05:11gfxstrand[d]: I have a 750 Ti that actually spins up
05:11orowith2os[d]: I actually didn't realize that there was a Matrix bridge for this channel, cool
05:11gfxstrand[d]: But the 800s and 900s are kinda stuck
05:11tiredchiku[d]: orowith2os[d]: there's not
05:11tiredchiku[d]: it's a discord <-> irc bridge
05:11orowith2os[d]: gfxstrand[d]: Except for *one* 800 gen, though, right?
05:11gfxstrand[d]: There's an IRC bridge and people who join from Matrix
05:11tiredchiku[d]: and an irc <-> bridge
05:12orowith2os[d]: orowith2os[d]: Or was that GPU Maxwell B?
05:12gfxstrand[d]: I'm not sure.
05:12orowith2os[d]: Oh well
05:12tiredchiku[d]: I'm guessing I need to build libinput with the patch too
05:13gfxstrand[d]: You don't need to build libinput with a patch. You just need to build the latest version against the headers that get installed by your xserver build because there's an xserver API break that hits it.
05:13redsheep[d]: orowith2os[d]: The bot's matrix bridge is pretty bad, to be honest
05:13gfxstrand[d]: Okay, bed for real
05:14tiredchiku[d]: gfxstrand[d]: gotcha, thank :saigeheart:
05:15redsheep[d]: I am fairly sure that the 750ti (and maybe the 750? Maybe the 730, not 100%) were the only maxwell A add in cards, 800 series was all mobile, then 900 is all B
05:16redsheep[d]: But the mobile 800s I believe were all A
05:19redsheep[d]: That whole disaster was all about tsmc realizing that 20 nm vias were super messed up, I believe B and larger A was planned for 20nm but had to backport to 28 for B and drop bigger dies on A if I have my history correct
05:20redsheep[d]: Oh gross some of the 800s were kepler and one was even fermi. Eww
05:21redsheep[d]: The maxwell ones were indeed A
05:21mhenning[d]: yeah some of the naming is annoying
05:21tiredchiku[d]: x11 is a smaller compile than mesa (nvk, nouveaugl, zink, softpipe)
05:22tiredchiku[d]: somehow I expected it to be bigger 😅
05:23redsheep[d]: mhenning[d]: Much as nvidia naming is still often pretty bad I really do appreciate that they seem to have stopped mismatching the architecture and series
05:23tiredchiku[d]: building libinput now
05:25tiredchiku[d]: aaand grabbing a few x11 wms that aren't kwin or mutter
05:26tiredchiku[d]: here we go :wolfFIRE:
05:29airlied[d]: marysaka[d]: so looking at some of traces, not sure IMAD.SHL.U32 R8, R9, 0x4, RZ ; is decoded properly, there should be an immediate I think, though the docs don't mention much about it, karolherbst[d] maybe you know
05:32mhenning[d]: airlied[d]: https://kuterdinel.com/nv_isa_sm89/ has some re'd encoding information which could maybe be useful (not completely sure what you're referring to)
05:40airlied[d]: I'm not 100% sure myself, I think IMAD.SHL.U32 does r8 = (r9 * 0x4) << imm + RZ in the above but imm is missing from the decode
05:41airlied[d]: but I'm going around in some nice circles working out LDSM today
05:50gfxstrand[d]: I think the .shl is only because the multiplicand is a power of two
05:51gfxstrand[d]: That's just `r8 = r9 * 4`, I think.
05:51tiredchiku[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347446431400857661/e8ea8e8e-1070-4c35-a2a6-b944aba762c9.jpg?ex=67cbdac7&is=67ca8947&hm=e27f3e00e2da4dd2088d17cb90243ffbbdada6b0da5c3c40043c53dee7d56cde&
05:51tiredchiku[d]: this is starting to get silly
05:52gfxstrand[d]: gfxstrand[d]: The disassembler is trying to be "helpful". 🙄
05:54airlied[d]: oh that is overly helpful, so it's r9 << 4 maybe 🙂
05:55gfxstrand[d]: No, it's r9 * 4 but 4 is a power of two so you can think of it as a shift. It's dumber than you think.
05:56gfxstrand[d]: Unless there's an actual shl modifier bit that changes the behavior.
05:56airlied[d]: I don't see anything in the docs I have, but who knows 😛
05:57airlied[d]: okay I'll just curse the helpful disassembler 😛
05:58gfxstrand[d]: There's an nvfuzz tool in the shader tools package if you want to poke at bits.
05:59gfxstrand[d]: But I've spent enough time staring at imads that I'm pretty confident it's all BS.
05:59gfxstrand[d]: There's also a .mov form which is what you get when both multiplicands are rZ.
06:00tiredchiku[d]: zink/all-the-fixes without the xserver patch appears to break x11 rendering, is that intended
06:00tiredchiku[d]: wayland and xwayland is fine
06:00gfxstrand[d]: I should make my nvdis tool filter those out so they stop confusing people. :frog_upside_down:
06:01gfxstrand[d]: tiredchiku[d]: Define "break".
06:01tiredchiku[d]: wm loads up
06:01tiredchiku[d]: doesn't respond to further input
06:01tiredchiku[d]: whether it be mouse or keyboard
06:01gfxstrand[d]: Uh...
06:02gfxstrand[d]: And it's fine without the branch?
06:02tiredchiku[d]: yup
06:02tiredchiku[d]: actually, let me double check
06:02gfxstrand[d]: The branch has the Zink enable patch in it
06:02gfxstrand[d]: So it might just be that
06:02tiredchiku[d]: gfxstrand[d]: I have the env var set globally
06:03gfxstrand[d]: I don't trust env vars no matter where they're set
06:03tiredchiku[d]: I've verified they get applied (even with glxinfo(
06:03gfxstrand[d]: Kk
06:03gfxstrand[d]: That doesn't actually mean as much as you think. 😫
06:03tiredchiku[d]: fair
06:03gfxstrand[d]: Try with just the patch and not the rest of the branch
06:03tiredchiku[d]: :salute:
06:04gfxstrand[d]: Oh and not responding to input could be the input driver not loading. Check your X logs.
06:05tiredchiku[d]: oh
06:05tiredchiku[d]: :derproo:
06:05tiredchiku[d]: yeah, you were right
06:06tiredchiku[d]: why does the xorg package group on arch not pull in libinput
06:06tiredchiku[d]: has my own libinput installed instead of the distro provided one
06:06tiredchiku[d]: pebkac
06:09tiredchiku[d]: hm, no
06:12tiredchiku[d]: wtf
06:13tiredchiku[d]: I must've yolo'd too hard :D
06:14orowith2os[d]: gfxstrand[d]: GO TO BED
06:14orowith2os[d]: It's probably what. 12:15?
06:17tiredchiku[d]: ok yeah something else is busted, repro'd on nvprop too
06:20airlied[d]: doh, ldsm encoding was missing a bit, might be easier now 😛
06:23tiredchiku[d]: bunch of no input driver specified
06:27tiredchiku[d]: okay, installing xf86-input-evdev fixed it
06:27tiredchiku[d]: :ThumbsUp:
06:30gfxstrand[d]: tiredchiku[d]: You need to make sure your libinput builds against the new X server headers, which should get installed when you install the new X server.
06:30tiredchiku[d]: yeah, did that
06:30gfxstrand[d]: orowith2os[d]: I am. I promise!
06:30tiredchiku[d]: it worked fine w/ the patch, but broke when I tried to revert
06:31tiredchiku[d]: just pebkac
06:31orowith2os[d]: gfxstrand[d]: That message does not help your case
06:31orowith2os[d]: The discord mobile icon, does, however
06:32tiredchiku[d]: I wasn't able to break the zink branch and the xserver patch beyond the cursor squish and the sync issues
06:32tiredchiku[d]: I even tried running a game with wined3d and through zink
07:20asdqueerfromeu[d]: tiredchiku[d]: You should probably do `sudo pacman -S vulkan-mesa-layers` for further testing (specifically after installing that package you should try plugging/unplugging the display cable from the dedicated GPU monitor so that the GPU goes into D3cold mode if there are no applications running on it)
07:22tiredchiku[d]: :doomthink:
07:22tiredchiku[d]: and what does that achieve
07:25asdqueerfromeu[d]: tiredchiku[d]: https://discord.com/channels/1033216351990456371/1209954375766908948/1346583405155848192
07:38tiredchiku[d]: not entirely sure how that relates to the xserver patch
07:42asdqueerfromeu[d]: tiredchiku[d]: I mean to zink in general
08:48tiredchiku[d]: ah
08:48tiredchiku[d]: gotcha
08:54marysaka[d]: airlied[d]: If you are looking at the matrix layout it us already be implemented in my branch, you can ignore the modifier on that IMAD it’s just trying to shows you what that IMAD also map to
09:04airlied[d]: The matrix layout was but not the matrix count
09:23marysaka[d]: oh I see...
16:03gfxstrand[d]: Ugh... Why does GDB hate me today?!?
16:04gfxstrand[d]: I attach to kwin and GDB just hangs
16:06dwfreed: ptrace the ptracer :D
16:07gfxstrand[d]: I suspect it's something to do with debug symbols
16:11zmike[d]: Did you remember to disable automatic downloading of symbols?
16:36gfxstrand[d]: Yeah. I was enjoying those symbols for a bit but they decided to bite me today
16:48gfxstrand[d]: Ugh... I wish the Titan V wasn't $400 USD on ebay...
16:50gfxstrand[d]: That's a lot to spend on a paper weight
16:55mohamexiety[d]: yeah..
16:55mohamexiety[d]: it was far, far worse in the past
16:56mohamexiety[d]: but 12GB of RAM meant that it became undesireable for a lot of compute/ML stuff (specially when the successors are like 2-4x faster) so that pushed prices down.
17:03gfxstrand[d]: I just bit the bullet. I bought a bitcoin mining edition (old stock from some self-driving car startup) so that shaved off a few $$$
17:03gfxstrand[d]: I figure passive cooling is fine if it'll never reclock anyway.
17:03gfxstrand[d]: And, hey, no need to worry about fan controls!
17:04gfxstrand[d]: I think Volta should be conformant, actually. The Maxwell B fails are mostly shader things.
17:05gfxstrand[d]: Well, now that I fixed all the regressions I added. :frog_upside_down:
17:48snowycoder[d]: Huh, encountered a strange error.
17:48snowycoder[d]: I tried to add some basic checks in the parser as Src value and SrcType matching (so that you cannot parse, for example `iadd2 %r1 |%r3|`).
17:48snowycoder[d]: `OpCopy` doesn't really exist, but it should have SrcType `GPR` and it does not accept immediates (by `supports_type`), so we are generating some theoretically invalid NAKs before copy_prop passes.
17:49snowycoder[d]: Should we just ignore SrcType conformance while parsing?
17:50snowycoder[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347627588742545489/image.png?ex=67cc837e&is=67cb31fe&hm=bf488fa0b239d27e92d3b9cd764f00368344ece915cfaa10133173f3f623941d&
17:50snowycoder[d]: (here's a preview of the parser error)
17:56gfxstrand[d]: Ugh...
17:56gfxstrand[d]: OpCopy should probably be ALU
17:56gfxstrand[d]: rather than GPR
17:56gfxstrand[d]: It doesn't support modifiers but it very much supports immediates and cbufs
18:26redsheep[d]: gfxstrand[d]: It might not be fine, even if the die remains cool the memory might not if it's meant to be passive. You can 3d print a shroud to stick a fan onto for those though.
18:28gfxstrand[d]: Yeah, we'll find out I guess
18:49mohamexiety[d]: redsheep[d]: it's HBM, memory is on die
18:49mohamexiety[d]: well, on package but eh
18:56redsheep[d]: Oh I forgor
18:58mohamexiety[d]: yeah I used to want one since it's such a cool GPU but could never justify the price
18:59redsheep[d]: mohamexiety[d]: Gotta get the CEO edition
19:00mohamexiety[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347645029237264434/image.png?ex=67cc93bd&is=67cb423d&hm=d1633f43d822b33e578601e0a530d8971240748b684192c2f42f933db290bfde&
19:00mohamexiety[d]: go big or go home
19:04orowith2os[d]: mohamexiety[d]: And it's still cheaper than what scalpers are charging
19:06gfxstrand[d]: I just want one that'll work well enough to run the CTS.
19:07gfxstrand[d]: Because Volta is weird and I'm tired of having to ask karolherbst[d] to run things.
19:21HdkR: Volta is that fun inbetween GPU. Got the new ISA before the real cards :D
19:22HdkR: And of course its missing some instructions, because why not
20:11gfxstrand[d]: Yeah
20:15gfxstrand[d]: It's got the new ISA except it doesn't have UGPRs or bindless cbufs or imnmx (I think?)
20:15HdkR: Yea, imnmx is the funny missing one that was added back in Turing
20:16HdkR: er ampere
20:16gfxstrand[d]: Turing
20:16gfxstrand[d]: It's literally just missing on Volta
20:16HdkR: Losing my memory of the ordering of these families
20:16gfxstrand[d]: Though now I can't find the code to work around it
20:17gfxstrand[d]: Found it
20:17gfxstrand[d]: Yeah, it's literally just volta
20:17HdkR: Yea, it was a funny oops
20:20HdkR: It also doesn't have RT and Mesh shaders. Such a quirky GPU
20:22gfxstrand[d]: Yeah, they just crammed the ISA rework in there ASAP and shipped it
20:23HdkR: :D
20:23gfxstrand[d]: But that makes it a really important GPU to have in my collection for the purposes of testing because that's where all the HW generation checks break.
20:24airlied[d]: I don't think I have Volta latency timings either, but not sure id bother if I did 🙂
20:25HdkR: Sadly I'm using mine for a secondary GPU on a PC so I can have five CRTCs. It's the only reasonably new card that I could have single slot working :D
22:48gfxstrand[d]: Ugh... modesetting is probing nouveau cursor sizes wrong.
22:48gfxstrand[d]: Likely this means nouveau is reporting something wrong
22:48gfxstrand[d]: 😩
22:53gfxstrand[d]: If I hack modesetting to always use at least 64x64, the cursor issues go away
22:55gfxstrand[d]: kwin's DRM back-end is lazy and just checks `DRM_CAP_CURSOR_WIDTH/HEIGHT`
22:57gfxstrand[d]: _lyude: Any desire to chase that down?
22:58_lyude[d]: oh no the cursor terrors return
22:58_lyude[d]: i thought we had fixed this actually
22:58_lyude[d]: gfxstrand[d]: what size is it trying to use, and which generation is this?
22:58gfxstrand[d]: Turing and it's trying to use 32x32
22:59gfxstrand[d]: And this is on Ben's 570 branch so it's pretty fresh
22:59_lyude[d]: oooh, I think I only ever fixed this in the other direction actually
22:59_lyude[d]: (btw which branch is that? I need to give that branch a tr on my laptop as well)
23:05gfxstrand[d]: uh... My tree says bskeggs/03.00-r570
23:05gfxstrand[d]: I think there's a newer version now
23:05gfxstrand[d]: But just troll through his tree for r570
23:07gfxstrand[d]: Hm... `nv04_cursor_set()` returns `-EINVAL` if it's not 64x64
23:08gfxstrand[d]: oh, wait...
23:08_lyude[d]: gfxstrand[d]: yeah that's legacy modesetting though
23:08_lyude[d]: nv50 is a lot different then nv04 as well
23:08_lyude[d]: these days we would just check this sort of thing in the atomic_check
23:09_lyude[d]: i just finished setting up a worktree to write up a fix for this so gimme a sec
23:10gfxstrand[d]: _lyude[d]: Does it allow more than just the one cursor size? Or is that a minimum?
23:11_lyude[d]: gfxstrand[d]: yeah - there's a few different cursor sizes that are allowed, since on all gens cursors are sort of their own special kind of plane that's different from normal wndws
23:12_lyude[d]: (they are one of the few display things that has something akin to registers for setting their position!)
23:13gfxstrand[d]: Oh, I meant is it one cursor size per gen?
23:13gfxstrand[d]: Or is that a minimum?
23:15gfxstrand[d]: Like, Turing is 64x64 but can it do 128x128?
23:16_lyude[d]: gfxstrand[d]: so it's literally a set of sizes:
23:16_lyude[d]: #define NVC37D_HEAD_SET_HEAD_USAGE_BOUNDS_CURSOR 2:0
23:16_lyude[d]: #define NVC37D_HEAD_SET_HEAD_USAGE_BOUNDS_CURSOR_USAGE_NONE (0x00000000)
23:16_lyude[d]: #define NVC37D_HEAD_SET_HEAD_USAGE_BOUNDS_CURSOR_USAGE_W32_H32 (0x00000001)
23:16_lyude[d]: #define NVC37D_HEAD_SET_HEAD_USAGE_BOUNDS_CURSOR_USAGE_W64_H64 (0x00000002)
23:16_lyude[d]: #define NVC37D_HEAD_SET_HEAD_USAGE_BOUNDS_CURSOR_USAGE_W128_H128 (0x00000003)
23:16_lyude[d]: #define NVC37D_HEAD_SET_HEAD_USAGE_BOUNDS_CURSOR_USAGE_W256_H256 (0x00000004)
23:16_lyude[d]: ...which makes this weird, because this means 32x32 should be totally fine
23:16_lyude[d]: gfxstrand[d]: could you show me the dmesg from when this breaks?
23:17gfxstrand[d]: Nothing on dmesg
23:19gfxstrand[d]: Oh, and this is actually Ada, not Turing
23:19_lyude[d]: ooooo, ada, ok
23:19_lyude[d]: they may have dropped 32x32 support there let's see
23:22_lyude[d]: ...except that also doesn't make sense because ada seems to do 32x32 as well. gfxstrand[d] mind booting your system with:
23:22_lyude[d]: `log_buf_len=50M drm.debug=0x16 nouveau.debug=disp=trace`
23:22_lyude[d]: And then have it try to set the 32x32 cursor
23:24gfxstrand[d]: I typed a hacky patch and confirmed that bailing out of `curs507a_acquire()` fixes the modesetting driver so this is definitely a kernel bug.
23:24gfxstrand[d]: Okay, I'll revert my patch and boot with that line
23:30gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347713026123628565/dmesg?ex=67ccd310&is=67cb8190&hm=40754c99ae5bf9799f1bac0f00b7ec8a95699665fdcc9b4432f8c2f0b6296fef&
23:30gfxstrand[d]: _lyude[d]:
23:31_lyude[d]: sfdj i forgot - there is a kernel config option that needs to be enabled too
23:32_lyude[d]: Mind rebuilding with `NOUVEAU_DEBUG_PUSH=y`?
23:32gfxstrand[d]: Done. Give me a minute
23:42gfxstrand[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1347715970633830472/dmesg?ex=67ccd5ce&is=67cb844e&hm=eda295c5b80063d69a2a48e90477ca957931072e4da8cd989c70345f99ccef0d&
23:42gfxstrand[d]: _lyude[d]:
23:54_lyude[d]: huh. I don't see anything obviously wrong, gfxstrand[d] I might have to take a look at this on my own hw on monday if that's alright