00:46 gfxstrand[d]: The more wiki pages I read, the more I want to burn the whole thing. 😂
00:52 gfxstrand[d]: Like how is https://nouveau.freedesktop.org/FeatureMatrix.html useful? It's all either complete, implementable, or never been touched on any GPUs. Literally the only thing where the per-generation analysis is interesting is power management.
00:55 gfxstrand[d]: The three things that are totally unimplemented should be issues on DRM/nouveau and we should delete the matrix.
01:00 gfxstrand[d]: _lyude[d]: is the missing display stuff there tracked anywhere else? Is it still relevant?
05:04 i509vcb[d]: honestly kill the table imo
06:06 karolherbst[d]: gfxstrand[d]: dsc and flr are missing tho
06:07 karolherbst[d]: *frl
06:07 karolherbst[d]: even with gsp those things aren't automatic
06:09 karolherbst[d]: but yeah, we should be more high-level, like hdmi 2.1 support instead of low level tech terms
06:42 mupuf: yeah, feature matrices are useful, by they need to be at the appropriate level of details. otherwise it is just messy and hard to understand
06:42 mupuf: +1 for the split between pre and post GSP
08:12 kar1m0[d]: Cyberpunk 2077 is unplayable for now on nvk unfortunately
08:13 kar1m0[d]: There are just too many visual bugs which make the game unplayable, such as the mouse disappearing, textures disappearing and some parts of the menu as well
08:13 kar1m0[d]: Just felt like it is important to let you guys know
09:45 mohamexiety[d]: gfxstrand[d]: yeah sadly. we don't have DSC and pretty much no HDMI 2.1 support which makes a couple of displays complete no go on nouveau
12:00 karolherbst[d]: shouldn't be _that_ hard to wire up FRL at least.. just some GSP calls placed at the right place
12:15 mohamexiety[d]: the code is really, really, really difficult to read so I wouldnt be so sure about that
12:50 karolherbst[d]: it's like 2 GSP calls
12:50 karolherbst[d]: it's not even complicated, you just set the FRL mode and maybe something else, it's just unclear in which order it has to happen
13:56 gfxstrand[d]: mupuf: But is it useful as a matrix? The matrix only makes sense if you're going to have fairly scattered support. But anything where it's either all GPUs with support work or nothing's implemented, IDK that it makes much sense.
13:58 gfxstrand[d]: It's sometimes useful to track "yeah, XYZ works on the newer stuff but it's a PITA on chip Q so we haven't enabled it there yet."
13:58 gfxstrand[d]: But I only see a couple of lines where that's what we're doing.
13:59 karolherbst[d]: cutting most of those lines does indeed make sense, I'd just say that some features are asked enough that it does make sense
14:00 gfxstrand[d]: And when it comes to display stuff, things like variable refresh rate or HDR are features. Anything that makes it so that plugging in XYZ monitor results in black isn't a feature, it's a bug.
14:01 gfxstrand[d]: I mean, you can maybe make a case for dual-link being a feature but that's right on the line.
14:04 gfxstrand[d]: But again, this all comes down to who the wiki is for and what we're trying to do.
14:06 gfxstrand[d]: If it's for users, they need a good default experience and they need to know how to try out new stuff and where to file bug reports if their default experience isn't so great. A matrix which, upon careful inspection will explain to them exactly what part of their GPU isn't working is of no use.
14:08 karolherbst[d]: that's fair, that's why I mentioned it shouldn't be tech terms, like HDMI 2.1 support is more useful than "FRL, DSC"
14:08 karolherbst[d]: but might want to list resolutions, which is kinda a can of worms for
14:08 karolherbst[d]: *though
14:16 gfxstrand[d]: I mean, it depends on what it is. Like, maybe we should have DSC as an issue and then have an HDMI 2.1 tracker issue that points to a couple technical things. But again, that all belongs in the bug tracker. And ideally, we'd just fix it if it's not too terrible.
14:16 gfxstrand[d]: Like, matrices are kind useful as a kanban but not useful for users.
14:19 karolherbst[d]: yeah, fair
14:19 gfxstrand[d]: And the best way to get rid of rough corners is just to fix them, not to improve the documentation so people know better than to ask. There are some things like reclocking where the best we can do is to explain the limitations and apologize. But the best thing to do is to just fix the bugs.
14:19 karolherbst[d]: right..
14:20 karolherbst[d]: and HDMI 2.1 shouldn't be too hard (tm), just needs somebody with a good understanding of the display code and figure out where to add those 2 GSP calls
14:21 gfxstrand[d]: And yes, I know we're operating with really limited people power here. But if we want nouveau to actually be good, we need to get out of the "document the bugs" mindset.
14:30 gfxstrand[d]: And someone who besides just lyude needs to learn how to write display code.
14:31 karolherbst[d]: I did a bit...
14:32 karolherbst[d]: not that it's _that_ helpful 🙃 but yeah... am comfortable enough fixing bugs, but implementing features I'll have to dig more into the code
14:33 karolherbst[d]: but yeah.. we need more devs
14:34 karolherbst[d]: I think HDMI 2.1 support would be a good starting point for disp related stuff
14:35 gfxstrand[d]: Yeah, and unfortunately display isn't sexy, at least not most of the time. HDR and FSR are cool but most of it is like "Yay! More monitors work." Don't get me wrong. It's really frickin important. It's just maybe not as attractive to work on.
14:36 gfxstrand[d]: IDK. Maybe there's something we can do to change that?
14:36 karolherbst[d]: I mean
14:37 karolherbst[d]: if you have a 4K@165Hz display, you want to use 4K@165Hz 😄
14:37 karolherbst[d]: ask me how I know
14:37 gfxstrand[d]: Oh, I know.
14:38 karolherbst[d]: if my main system would be nvidia, I'd already implemented it 😄
14:41 gfxstrand[d]: Heh.
14:46 mohamexiety[d]: yeah my monitor is running at 4k60 and I think 6bit due to this
14:46 mohamexiety[d]: I tried to look at it but it was just too much at the time :/
14:50 karolherbst[d]: oh right...
14:50 karolherbst[d]: I've added that workaround 🙃
14:51 karolherbst[d]: had a display that was really nasty
14:51 karolherbst[d]: so it was 4K@30 at best and that sucked
14:52 karolherbst[d]: mohamexiety[d]: with GSP it should be like 2 RPC calls
14:52 karolherbst[d]: I have a WIP patch somewhere
14:52 karolherbst[d]: https://gitlab.freedesktop.org/karolherbst/nouveau/-/commit/eba81849b9310e6bb06c3543a9d562ff6548d235
14:53 karolherbst[d]: I think there is another relevant RPC call, but...
16:01 mupuf: gfxstrand[d]: of course the driver needs to work well and be feature complete, but it is also important to tell savvy-ish users what is expected to work or not. Especially for a reverse engineered driver
16:04 karolherbst: that was certainly true 10 years ago, but "reverse engineered" becomes a bit less relevant these days. I'm sure we'll end up in a spot soon where we don't do much more reverse engineering than other drivers do, because docs are wrong or just trying to understand the hardware better
16:04 mupuf: so, no need to get into insane details, but a line item per function (display, video decoding, encoding, API version, pwr mgmt) would be an effective tool to document the state across families
16:05 mupuf: karolherbst: it will still be relevant for features like video encoding and decoding
16:06 mupuf: or crypto engines,...
16:06 karolherbst: yeah I mean, we should document something
16:06 mupuf: the GSP doesn't solve everything
16:07 karolherbst: true
16:08 mupuf: so target audience for the wiki, power users that are not developers
16:09 karolherbst: I'm just wondering whether stating it's a reverse engineered driver will hold true as a proper characteristic of the project. Not saying it's a bad thing, but we might eventually end up in a spot like AMD sooner or later
16:09 karolherbst: but I agree that we shouldn't ignore that power users exist
16:10 karolherbst: sure the docs we get could be better and everything
16:10 karolherbst: but nvidia opened up a lot since the project started
16:10 gfxstrand[d]: I think it's good to document stuff. The video section, for instance, still makes sense, I think.
16:10 mupuf: true that, the distinction between AMD and NVIDIA is getting blurry, with both companies working on upstream kernel divers
16:11 karolherbst: sometimes it feels like it gets ignored too much how much nvidia is helping
16:11 mupuf: karolherbst: submit a talk!
16:11 karolherbst: heh
16:11 karolherbst: "thanks nvidia" lightning talk :D
16:12 mupuf: lol, get Alex and Ben on stage... good luck 🤣
16:13 mupuf: just a status update would be good though
16:13 mupuf: how life as a nouveau dev changed on the past couple of years
16:13 gfxstrand[d]: I still don't have docs. 🙃
16:14 mupuf: Nouveau is prob the most interesting driver again, so no excuses
16:14 gfxstrand[d]: But having registers helps a lot
16:14 mupuf: complete reg dumps?
16:14 mupuf: of the whole MMIO range?
16:15 mupuf: or just 3D regs?
16:17 karolherbst: gfxstrand[d]: well.. not my problem 🙃
16:18 karolherbst: mupuf: we get the full class headers
16:18 karolherbst: with sometimes things left out
16:18 gfxstrand[d]: Most MMIO regs. 3D, compute, etc.
16:18 karolherbst: nvk uses nvidia supplied headers to program push buffers
16:18 gfxstrand[d]: karolherbst: Well, yes, and I think we've about got it sorted, but still...
16:19 karolherbst: good luck with that
16:19 karolherbst: mupuf: https://github.com/NVIDIA/open-gpu-doc/tree/master/classes
16:20 karolherbst: there is also some MMIO regs
16:20 karolherbst: but
16:20 karolherbst: with GSP that became quite irrelevant
16:21 karolherbst: anyway
16:21 mupuf: sweet, thanks!
16:21 karolherbst: it's not really important what they publish
16:21 karolherbst: what's important is, we can _ask_ and that they react on it
16:21 karolherbst: like if we explain why we need something, there is a high chance we'll eventually get it
16:22 karolherbst: helped with some really annoying bugs
16:22 karolherbst: like the fp helper invocation load thing :D
16:22 mupuf: and they must be more reactive now that ben and Alex are there
16:22 karolherbst: nah even before that
16:23 karolherbst: but yeah.. there is an open channel to nvidia, and we can make use of it :)
16:23 karolherbst: I think it would be the right thing to at least give them some thanks for opening up like that, and it should come from the community, it's really appreciated
16:24 karolherbst: and I think it's unfair that people still repeats the "nvidia sabotages nouveau" points, but I guess that's just the internet (tm)
16:34 mupuf: true, but that was also the last message we really put out, didn't we?
16:34 mupuf: before the GSP came out
16:35 karolherbst[d]: maybe? probably?
16:35 karolherbst[d]: I don't think we accused them of active sabotage tho
16:35 mupuf: no
16:36 karolherbst[d]: I know we were a bit annoyed at fosdem when the signed firmware stuff happened
16:36 mupuf: never did that
16:36 karolherbst[d]: I think we were reasonably annoyed
16:41 gfxstrand[d]: https://youtu.be/fsDNGaSLOws
16:47 mangodev[d]: mupuf: "a day in the life of a nouveau developer" >:) (jk)
16:49 mhenning[d]: "I'm just wondering whether stating it's a reverse engineered driver will hold true as a proper characteristic of the project." -> I mean, the driver is certainly a lot less reverse engineered than it used to be, but I still end up reaching for reverse engineering all the time
16:49 funderscore: karolherbst Oh that's good to know, I thought y'all were all staring at a blackbox
16:50 gfxstrand[d]: Wake up. Make breakfast, maybe? Get on the Metro. Change trains. Walk to the office. Join a Khronos meeting. Avoid looking at my email. Write patches. Get bugged and/or feel guilty for not reviewing mhenning[d]'s patches and go review some. They're mostly fine, of course. Write more code.
16:50 gfxstrand[d]: It's really pretty boring.
16:51 gfxstrand[d]: mhenning[d]: Yes, but also it would surprise most people just how reverse engineered the Intel drivers are, too. 😅
16:57 karolherbst[d]: yeah...
16:57 karolherbst[d]: would be nice to be able to rely on actually correct docs 😛
16:59 gfxstrand[d]: That's why I've been so insistent on things like simulators for the MME and `Foldable`. We're writing our own docs over here.
17:01 karolherbst[d]: ohh right the MME stuff
17:01 karolherbst[d]: yeah that would have been nice
17:01 karolherbst[d]: there are certainly hidden things in it we don't know about probably?
17:02 gfxstrand[d]: Oh, absolutely
17:03 gfxstrand[d]: But those are the things that are annoying to test, like control flow corners.
17:04 karolherbst[d]: I'm sure "extended" has a few hidden things as well
17:05 karolherbst[d]: oh no.. I have a cursed idea
17:05 karolherbst[d]: please stop me
17:05 karolherbst[d]: ~~emulate shaders on the mme~~
17:08 gfxstrand[d]: The number of times I've considered writing a NIR backend...
17:08 gfxstrand[d]: "But wouldn't it be great if we could write MME macros in OpenCL C?..."
17:08 karolherbst[d]: ...
17:08 karolherbst[d]: look
17:09 karolherbst[d]: though I think a NIR backend wouldn't be too terrible 😄
17:09 karolherbst[d]: we even have scratch memory!
17:10 gfxstrand[d]: :blobcatnotlikethis:
17:10 gfxstrand[d]: Having real RA for pre-Turing would be nice.
17:29 _lyude[d]: gfxstrand[d]: it is definitely useful for codenames, which are pretty much accurate. I think I tried to update the feature matrix the other day but that was a while ago
17:45 mupuf: _lyude[d]: "the other day"... 5 years ago :D
17:57 _lyude[d]: oh wow has it really been that long? lol
17:58 gfxstrand[d]: 🤣
18:14 gfxstrand[d]: _lyude[d]: Yeah, the codenames page is really good. It's kind of a duplicate of a similar Wikipedia page but I like how ours is organized better.
18:15 gfxstrand[d]: (Specifically because it's organized by chip and has a list of marketing names rather than being organized by marketing name.)
19:08 soreau: maybe make the features in the matrix update automatically by CI ;)
19:09 karolherbst[d]: oh no
22:20 snowycoder[d]: mhenning[d]: gfxstrand[d] The texdepbar MR from last week is ready, sorry for the delay https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35403 .
22:20 snowycoder[d]: It's marked as Draft as it needs the commits from Mel's branch.
22:20 gfxstrand[d]: Woo
22:21 snowycoder[d]: I misused register alignment to sort RegRefs into buckets of four registers, eheheh.
22:21 snowycoder[d]: It's strange but fast
22:21 HdkR: I saw a PR that was allocating a fixed VA region. Is that a fixed VA region for the kernel or userspace? I would assume that is kernel space.
22:24 HdkR: I should probably just look at it closelier but laziness :D