02:44airlied[d]: blackwell qmd is out
02:49airlied[d]: gfxstrand[d]: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35378
02:52gfxstrand[d]: Sweet! I'll rebase on that and land the QMD bits. Maybe tomorrow?
02:58airlied[d]: now I just need to annoy people for the 3d class 🙂
02:59gfxstrand[d]: Yeah. That'd be nice
03:01gfxstrand[d]: IDK if I'll get this extension wrapped up next week or not. I'm doing lots of refactoring right now. Might be two more weeks. Then I can get back to Blackwell.
03:03airlied[d]: if you merge that branch, I'll probably have time to do some stuff next week
03:06mhenning[d]: airlied[d]: Is the 3d class significantly different? I was under the impression that the QMD was a much bigger issue
03:07airlied[d]: there are a few unknown, and I can't get depth stencil to work
03:08airlied[d]: not sure if there is another bit somewhere else that needs flipping to enable the separate stencil to work
03:08mhenning[d]: oh, yeah. I guess the old depth stencil formats are gone?
03:11airlied[d]: I'm writing the new regs just like the binary, but things are just giving me a gr error
03:31airlied[d]: gfxstrand[d]: I've rebased your nvk/blackwell in my nvk/blackwell first just to get past the sm32 changes, I'll go play with qmd now
03:31gfxstrand[d]: Okay
03:32gfxstrand[d]: I suspect there may be deeper changes than just moving bits around but I'm not sure. I saw some weird behavior. It'll be way easier to debug with actual headers, though.
03:37airlied[d]: okay my branch rebased onto it and builds, now I suppose to do some work 😛
05:34ice9: nouveau breaks system suspend/wake up on Ubuntu
06:50kar1m0[d]: ice9: Could you provide more info? Like what gpu you're using...
06:50kar1m0[d]: Some logs would also be nice
07:43ice9: kar1m0[d], GeForce MX450, unfortunately there is no logs at all as the laptop freeze upon wake up from sleep and I have to hard reset
07:51ice9: using the proprietary driver works fine
10:22kar1m0[d]: https://cdn.discordapp.com/attachments/1034184951790305330/1380491957192753253/Screenshot_20250606_131908.png?ex=684412d2&is=6842c152&hm=9e3a5636c42986ba8dacab1cce1912354a4a088816b639d0314e9d74b6f89d66&
10:22kar1m0[d]: Cyberpunk 2077 benchmark test with fsr enabled(vsync unavailable)
10:44kar1m0[d]: I would say that it's pretty impressive how cyberpunk get's more fps on high settings then assassin's creed valhalla
11:28huntercz122[d]: kar1m0[d]: kinda misleading
11:28huntercz122[d]: frame gen is enabled
11:29kar1m0[d]: huntercz122[d]: I literally said that fsr is enabled
11:29huntercz122[d]: well the upscaling part or frame gen?
11:29kar1m0[d]: Both
11:30huntercz122[d]: also i see fsr upscaling being in auto mode, which means it can go in ultra performance and run from like 360p base
11:31tiredchiku[d]: huntercz122[d]: the GPU still has to generate those frames :froge:
11:31tiredchiku[d]: but it's good to know FSR framegen works
11:31tiredchiku[d]: unfortunately it is a misleading benchmark of gpu performance
11:31kar1m0[d]: There are bigger issues than performance tbh
11:31kar1m0[d]: Like visual bugs
11:32tiredchiku[d]: mhm
11:32huntercz122[d]: my gtx 1660 ti+nvk+zink can't even handle DOOM 2016 at 60fps 😄
11:32huntercz122[d]: native vulkan runs even worse
11:33huntercz122[d]: the perf was basically same with 1440p and 1080p no matter the settings, so it's just nvk being slow
11:34kar1m0[d]: huntercz122[d]: It depends on the game as well, I am able to play most games at 45-60 fps on nvk medium-high settings
11:34kar1m0[d]: But I do have an rtx 4080(laptop gpu)
11:35tiredchiku[d]: I've definitely finished entire games on NVK
11:35tiredchiku[d]: on both my old 1660Ti laptop and this current 3070 I have
11:35kar1m0[d]: Most games are playable on nvk
11:35kar1m0[d]: Single player ones at least
11:37huntercz122[d]: from d3d9 era i think yes
11:38kar1m0[d]: tiredchiku[d]: True but I saw videos of people testing cyberpunk on nvk from months ago and it either didn't open the game for them or it was on 15fps
11:38kar1m0[d]: huntercz122[d]: Except dx12
11:38tiredchiku[d]: a lot changed in these few months, yeah
11:38kar1m0[d]: But it's also about the hardware
11:39kar1m0[d]: I mean even though I am on laptop my gpu is very powerful
11:39kar1m0[d]: Not sure how it compares to desktop gpus tho
11:40huntercz122[d]: i have rx 7800 xt on my desktop and i think it's slower than even mobile rtx 4080 i think
11:41huntercz122[d]: and i also have intel arc b580, so i just need some decent nvidia gpu to my collection to have all the main vendors 😄
11:42huntercz122[d]: i only have gt 430 and gtx 460, gtx 1660 ti is on my old gaming laptop
11:51kar1m0[d]: huntercz122[d]: Buy an rtx 5090
11:52huntercz122[d]: that would require selling my kidney
11:52kar1m0[d]: huntercz122[d]: You have 2 for a reason
11:53huntercz122[d]: sell both, then die after few hours to enjoy my rtx 5090
11:53huntercz122[d]: 😄
14:11dwlsalmeida[d]: airlied[d]: hey nvidia has replied to my questions, this might be of your interest:
14:11dwlsalmeida[d]: Q.4) Please provide some insight on nvdec_hevc_pic_s::sw_hdr_skip_length . For now, we are computing it using some heuristics, since it's not passed in by the Vulkan Video API explicitly.
14:11dwlsalmeida[d]: A.4: This parameter can be computed by the NVDEC firmware. The following sequence of methods are to be used to instruct the firmware to parse the bitstream and compute this value:
14:11dwlsalmeida[d]: 1. NVC9B0_SET_APPLICATION_ID, with the method data set to NVC9B0_SET_APPLICATION_ID_ID_HEVC_PARSER.
14:11dwlsalmeida[d]: 2. NVC9B0_SET_CONTROL_PARAMS with the codec type field i.e. NVC9B0_SET_CONTROL_PARAMS_CODEC_TYPE set to the value 12, and other fields set to the same values as in regular picture decode
14:11dwlsalmeida[d]: 3. NVC9B0_SET_IN_BUF_BASE_OFFSET, with the bitstream buffer allocation
14:11dwlsalmeida[d]: 4. NVC9B0_SET_DRV_PIC_SETUP_OFFSET, with the allocation containing the picture setup structure
14:11dwlsalmeida[d]: 5. NVC9B0_SET_PICTURE_INDEX, with the current picture's index
14:11dwlsalmeida[d]: 6. NVC9B0_EXECUTE
14:11dwlsalmeida[d]: so turns out we don't need to parse the bitstream after all
14:12dwlsalmeida[d]: (who would have thought that this is the role of NVC9B0_SET_APPLICATION_ID_ID_HEVC_PARSER)
14:13dwlsalmeida[d]: gfxstrand[d]: we should probably get back to this topic, to make use of the current momentum and ask more questions regarding AV1 and VP9
14:15dwlsalmeida[d]: as I said, I think my Rust code is a bit shitty, ngl. With all the pointer indirections required by vulkan there's a lot of `unsafe` going around. Yet it works
14:15dwlsalmeida[d]: please let me know how you want to proceed, I can rewrite this whole thing if you think it's best
14:46gfxstrand[d]: dwlsalmeida[d]: Yeah, we should
14:47gfxstrand[d]: phomes_[d]: Mind re-testing !35327? I think I found/fixed the bug.
14:55gfxstrand[d]: I don't trust myself to re-review/land the code I wrote earlier this week today. Too tired. I'll land on Monday, probably.
14:56dwlsalmeida[d]: dwlsalmeida[d]: I guess one thing we can do to make this a bit better is stealing the kernel’s Opaque type, it basically wraps a type into UnsafeCell and MaybeUninit
14:56gfxstrand[d]: dwlsalmeida[d]: Go ahead and fix AV1 (that's the one that's broken, right?) It's really not going to happen in the next two weeks but I'd like to review and see if we can clean up the rust before we toss it.
14:56gfxstrand[d]: Hopefully I'll be able to review in a couple weeks.
15:06phomes_[d]: gfxstrand[d]: the crashes I got with the first version are gone and everything now seems to work
15:06gfxstrand[d]: \o/
16:19linkmauve: dwlsalmeida[d], speaking of Rust and Vulkan, my driver has a huge amount of unsafe as well due to all of the pNext chaining stuff and general raw pointer usage in the API, but I don’t think I can do it very differently.
16:19linkmauve: At best I could hide it behind macros, but I consider that worse.
16:28karolherbst[d]: the trick I'm using in Rusticl and with OpenCL is, that I have common code to convert an API handle to the internal type, and just have the unsafe there, because you can simply state "this is safe, because anything else is a misuse of the API spec and already UB"
16:49gfxstrand[d]: Okay, this should help with the wiki situation a little bit: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/55
16:50gfxstrand[d]: Should we point people at Discord instead of IRC?
16:50gfxstrand[d]: Or should we continue using "try IRC first" as a filter?
16:59karolherbst[d]: I think it's better to stick to IRC, given discord might just uhm.. do their thing and become a bad platform
17:00karolherbst[d]: anyway.. anybody in the nouveau gitlab group has access to that repo, so you can merge your own stuff
17:02karolherbst[d]: "View exposed artifact" to find a preview in case you haven't noticed
17:03karolherbst[d]: https://nouveau.pages.freedesktop.org/-/wiki/-/jobs/77905248/artifacts/public/index.html
17:03gfxstrand[d]: I don't see a merge button. Are we using Marge or do I somehow not have access?
17:03karolherbst[d]: huh? you should have?
17:04gfxstrand[d]: Never mind. Just needed to refresh
17:04karolherbst[d]: you are Maintainer in that repo
17:04karolherbst[d]: ahh
17:04gfxstrand[d]: GItlab is bding dumb
17:04karolherbst[d]: I think the pipeline needs to pass before you can merge
17:06gfxstrand[d]: I also asked fooishbar if we can make wiki.freedesktop.org/nouveau redirect to nouveau.freedesktop.org. I got confused by that today.
17:07karolherbst[d]: ohhh
17:07karolherbst[d]: the old stuff is still available?
17:07karolherbst[d]: yeah.. we should just redirect
17:11gfxstrand[d]: Yeah. It's the same wiki, just from cgit 5 years ago. Not that much has changed in the wiki since then. 😖
17:13gfxstrand[d]: Working on the wiki is probably something that non-devs can help out with if they're interested.
17:14gfxstrand[d]: For instance, we should make sure that the installation instructions include NVK and don't tell people to use xf86-video-nouveau unless they're on really old GPUs.
17:19karolherbst[d]: yeah, that was my hope moving the wikit o gitlab, because before that you had to be part of a special httaccess file or so
17:20karolherbst[d]: gfxstrand[d]: even on old GPUs it's fine these days, we fixed a lot of the issues 🙃
17:20karolherbst[d]: like I had gnome 42 or so running on my nv42 gpu
17:20karolherbst[d]: there were just silly bugs here and there
17:21karolherbst[d]: there was at some point a "out of memory bug" but it was just a silly race condition
17:35dwlsalmeida[d]: linkmauve: Did you check Opaque<T> in the kernel? I’m on my phone otherwise I’d link
18:10linkmauve: dwlsalmeida[d], I just did, but I’m not sure what it provides over a raw *mut T which I dereference with .as_mut() or &* after checking that it is non-null in an unsafe block.
18:12linkmauve: Btw I don’t remember if I told you, but I got my first two correctly-decoded frames, tested with hantro on a rk3588 and with cedrus on an A64. \o/
18:12gfxstrand[d]: karolherbst[d]: Daniel says you can make the wiki redirect?
18:13karolherbst[d]: I do?
18:14karolherbst[d]: I know I can redirect pages
18:14karolherbst[d]: but across subdomains?
18:14karolherbst[d]: I think this needs a DNS entry update.. or apache config or whatever is hosting the wiki
18:15karolherbst[d]: mhhh
18:15karolherbst[d]: `/etc/apache2/sites-enabled/wiki.freedesktop.org.conf` on anarchy
18:16karolherbst[d]: _not sure_ I want to mess with an apache config
18:17karolherbst[d]: but yeah.. in theory we could hack the config to redirect wiki.freedesktop.org/nouveau only
18:25gfxstrand[d]: Yeah, doing it at the Apache level would probably be better. But we could make it a redirect for now.
18:25gfxstrand[d]: I think if you redirect at the HTTP layer, it updates crawlers and stuff
18:28gfxstrand[d]: But don't ask me. I don't know.
18:34karolherbst[d]: it's already updated
18:34karolherbst[d]: no idea if anything even points to the old URL tho
18:35karolherbst[d]: I'll try something out later I think..
18:44mhenning[d]: karolherbst[d]: Doesn't seem to be redirecting for me https://wiki.freedesktop.org/nouveau/
18:45karolherbst[d]: I mean the crawlers
18:45karolherbst[d]: at some I told goole web console about it and I think it only uses the new URL
18:45karolherbst[d]: but not entirely sure if it's like propagated all the way through
18:46karolherbst[d]: but dunno.. I _thought_ a redirect was in place or something.. I know I've dealt with it before
18:46karolherbst[d]: ohhhhhhh
18:46karolherbst[d]: wait...
18:46karolherbst[d]: we did.. I think it got lost with the migration
18:46karolherbst[d]: let me check that later
18:47funderscore: 21:18 <HdkR> No CTCP Version.
18:48funderscore: block?
18:48funderscore: ah wait this is not libera
18:48funderscore: don't mind me
18:49HdkR: :)
18:49funderscore: libera has a ctcp block channel mode but it seems oftc does not have it (yet)
18:50karolherbst[d]: webarchive
18:50karolherbst[d]: wiki.freedesktop.org/nouveau: Saved 7 times between June 20, 2013 and February 26, 2024.
18:50karolherbst[d]: nouveau.freedesktop.org: Saved 1,130 times between August 20, 2006 and June 3, 2025.
18:50karolherbst[d]: I think we are good 🙃
18:51karolherbst[d]: but yeah.. I thought we did something about it, or I remember talking about it with somebody
19:12jrayhawk: I'll install that redirect.
19:13karolherbst: jrayhawk: thanks! inside the apache config or somewhere else?
19:13jrayhawk: In /etc/apache2/sites-enabled/wiki.freedesktop.org.conf
19:13karolherbst: ohh that was easier than I thought 🙃
19:15karolherbst: seems to work perfectly, thanks a lot!
19:25dwlsalmeida[d]: linkmauve: you cannot build a & or a &mut from a pointer if that pointer is handed over to C code
19:26dwlsalmeida[d]: that's because the reference rules expect the underlying memory region not to change, and you have no guarantee on what the underlying C code will do
19:28dwlsalmeida[d]: so in the kernel we had this issue as of recently, the first iteration of the DmaAllocator would build a slice from the underlying memory region, but if the hardware modified it that would already break the reference rules
19:38Lyude: dwlsalmeida[d]: that's not entirely true
19:39Lyude: You can't like, build a & -directly- to a C structure most of the time but you can create a newtype that wraps the struct in Opaque<> and then build a & to that
19:41Lyude: oh - wait, I think you mentioned that I just misread your message oops
19:48dwlsalmeida[d]: yeah, that's my point, mandating Opaque<T> in our mesa code too
19:49dwlsalmeida[d]: fwiw, I just copied things back and forth, it's also a solution if you don't care about the extra work
19:50gfxstrand[d]: karolherbst[d]: 2-3 of those were probably me being confused. 😂
19:51gfxstrand[d]: jrayhawk: Thanks a bunch!
20:33gfxstrand[d]: karolherbst[d]: OMG the build instructions tell you to run `autogen.sh`. :facepalm:
20:33karolherbst[d]: 🥲
20:34HdkR: Everything must return to autotools.
20:34karolherbst[d]: we should just nuke the build instruction page 😄
20:35gfxstrand[d]: We really should. Mesa has a build instructions page. There are dozens of pages explaining how to build a kernel. That's all anyone should ever need.
20:36karolherbst[d]: holy fuck the install page has 300 hits per month 🙃
20:36karolherbst[d]: impressive
20:36gfxstrand[d]: 😬
20:36karolherbst[d]: anyway, that page was more relevant when nouveau wasn't upstream 😄
20:37gfxstrand[d]: Which has been how long now?
20:37karolherbst[d]: dunno, but the wiki is old
20:37gfxstrand[d]: Yeah...
20:38karolherbst[d]: "Configuring the X server" yeah uhm.. we aren't doing that anymore for like 15 years
20:59gfxstrand[d]: The first header on the Ubuntu page is "Ubuntu 11.10 Oneric"
20:59HdkR: That's a good vintage right there.
21:00asdqueerfromeu[d]: ~~I wonder if NVK could run the Unity desktop~~
21:04gfxstrand[d]: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/56
21:05karolherbst[d]: we had a deb file 🙃
21:06gfxstrand[d]: And an ebuild!
21:06gfxstrand[d]: The new Install page: https://nouveau.freedesktop.org/InstallNouveau.html#distro-packages
21:07gfxstrand[d]: I'm not sure what to do with things like the feature matrix. They're kinda still relevant for old hardware but they aren't pages we want people landing on today.
21:09karolherbst[d]: I have an idea
21:10karolherbst[d]: the table is too big anyway, so maybe just split it between pre GSP and GSP
21:10karolherbst[d]: doesn't even need to be a table for GSP
21:11karolherbst[d]: but like all the per generation stuff is just irrelevant there
21:14gfxstrand[d]: Yeah
21:15gfxstrand[d]: But there's also a bunch of stuff in there like "we got textures working" which, uh...
21:33karolherbst[d]: hey, it was a big achievement like 15 years ago 😄
21:55gfxstrand[d]: Oh, I'm sure was.