00:02 fdobridge: <k​arolherbst🐧🦀> at least we have the header now for new hardware, so it shouldn't be terribly hard anymore
00:02 fdobridge: <k​arolherbst🐧🦀> just very hard
00:43 fdobridge: <o​rowith2os> is writing the userspace here *strictly* required?
00:43 fdobridge: <k​arolherbst🐧🦀> only if you add new UAPI 😛
00:44 fdobridge: <o​rowith2os> mmm
00:44 fdobridge: <o​rowith2os> so you can get out of anything by just, not writing a uapi
00:44 fdobridge: <k​arolherbst🐧🦀> the thing is.. we kinda don't really know
00:44 fdobridge: <k​arolherbst🐧🦀> it's hard to get the kernel bits right if you don't know how userspace behaves
00:45 fdobridge: <k​arolherbst🐧🦀> the video stuff is all very funky
00:57 fdobridge: <a​irlied> what userspace to do you suggest using?
00:58 fdobridge: <o​rowith2os> none :v
00:58 fdobridge: <a​irlied> kinda hard to decode video without a video decoding api
00:58 fdobridge: <o​rowith2os> oh, are those patches for decoding video *at all*, not just for NVIDIA's funky stuff?
00:59 fdobridge: <a​irlied> maybe you have a different idea of how video decoding work
01:00 fdobridge: <o​rowith2os> nope, just misunderstanding how this bit of nouveau and the stack works
01:00 fdobridge: <a​irlied> video with vaapi or vulkan requires a userspace component just like opengl or vulkan 3d
01:02 fdobridge: <o​rowith2os> I'd like to have a bit more discussion, probably elsewhere so as to not clog this channel, about how this works for the future, if you have time to do so
01:03 fdobridge: <o​rowith2os> more information is good, and I'm lacking here
01:03 fdobridge: <k​arolherbst🐧🦀> the thing is.. it's probably quite a lot of work, not something you gonna finish in a few weeks
01:05 fdobridge: <a​irlied> just have a look at the vulkan video work for amd or intel you can see how things kinda work
01:06 fdobridge: <o​rowith2os> (actual human discussion, so I'm not just reading code)
01:06 fdobridge: <o​rowith2os> (unless it is heavily documented code)
01:06 fdobridge: <o​rowith2os> (I am also not That Good at coding, yet, probably)
01:06 fdobridge: <o​rowith2os> (I've not done anything that requires ✨ effort ✨ yet)
01:07 fdobridge: <a​irlied> video decoding involves a lot of reading unfortunately, h264 spec isn't a small document, and although you don't have to read all of it, you do have to kinda know where to look
01:09 fdobridge: <k​arolherbst🐧🦀> yeah.. I wouldn't suggest a random new contributor to dig into it unless it's for something like a GSoC/EVoC or just because you are the "fun through pain" kinda person and like to work on things over months
01:10 fdobridge: <k​arolherbst🐧🦀> if you want to start with GPU stuff it would be certainly better to start with small tasks
01:10 fdobridge: <k​arolherbst🐧🦀> video is just super huge
01:10 fdobridge: <k​arolherbst🐧🦀> especially if nothing really exists
01:10 fdobridge: <o​rowith2os> is there a third option? potentially "I am a 'fun through pain' kinda person and like to not finish anything, instead increasing my number of forks and local repo clones"
01:10 fdobridge: <o​rowith2os> :v
01:10 fdobridge: <o​rowith2os> I still have to do that rusticl printf stuff
01:11 fdobridge: <o​rowith2os> but instead I'm rearranging my room for the third time in a few days
01:11 fdobridge: <k​arolherbst🐧🦀> yeah.. if I'd have to guess, the video stuff is 1000x times the effort needed compared to the printf stuff :ferrisUpsideDown:
01:11 fdobridge: <k​arolherbst🐧🦀> video is just.. horrible
01:11 fdobridge: <k​arolherbst🐧🦀> @airlied did the work for radv, but there was also already working code for vdpau/vaapi inside gallium
01:12 fdobridge: <k​arolherbst🐧🦀> and I suspect it was still a lot of work
01:22 fdobridge: <a​irlied> yeah I don't recommend it unless you've already got a chunk of work done
04:49 airlied: Lyude: https://gitlab.freedesktop.org/drm/nouveau/-/issues/271 okay this one might need looking at
05:16 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> > H.264 videos of movie trailers often end up rendering with some artifacts. Never seen in an actual movie though.
06:38 fdobridge: <S​id> where do we have our "dirty bits" enum?
06:40 fdobridge: <S​id> or does codegen handle that
08:27 fdobridge: <a​irlied> bleh dumping the video command buffers, I see all the pipeline barriers getting recorded into a pushbuf, I can sorta work out where the h264 picture info is, but not seeing where it's recording the push buf for nvdec
08:33 fdobridge: <p​rop_energy_ball> @airlied random question, given the discussion, but is it possible to do iframe only with Vulkan video encode?
08:34 fdobridge: <a​irlied> I think you can full control over what sort of frames get encoded
16:48 TimurTabi: I've pushed a commit for linux-firmware that adds the GSP firmware, if anyone wants to try it. https://github.com/NVIDIA/linux-firmware/commit/c2ebff9387ab361e6138cb49ff680ef2fdcb94a4
16:51 DodoGTA: TimurTabi: Upstream kernel requires 535.113.01 firmware now
17:12 TimurTabi: Hmm, that commit was supposed to be 535.113.01
17:12 TimurTabi: Ah, wrong link. https://github.com/NVIDIA/linux-firmware/commit/93812ca80bb56bab8dd9436963d5da0dbe9d02b0
18:36 airlied: TimurTabi: can we make the change to just bring then two files in and link to them? so /lib/firmware/nvidia/gsp/535.113.01/
18:43 airlied: because it will make it easier to keep track off, though i do wonder if we should host a script to autogen symlinks and whence entries
18:48 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Why doesn't nouveau use atomic KMS?
19:03 fdobridge: <a​irlied> Ben never enabled it, it uses it internally, I think lyude is going to try and get it turned on
19:03 fdobridge: <a​irlied> By default going forward
19:04 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I can't reproduce this anymore for some reason (maybe some kernel update secretly fixed it?)
19:17 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> By that I mean my runpm issue (the closest thing to a fix I can find is commit d22915d22ded21fd5b24b60d174775789f173997)
19:25 TimurTabi: airlied: you're going to have to be more specific. What's in /lib/firmware/nvidia/gsp/535.113.01/ ?
19:31 fdobridge: <a​irlied> I'd like to put the two files from the .run into that directory and symlink to them from all the others
19:41 airlied: TimurTabi: https://paste.centos.org/view/2d0dc719 like that
19:51 TimurTabi: Sure, but why do you want to put those two bins in a completely different place?
19:51 airlied: because they come from a completely different place?
19:52 TimurTabi: That's just a technicality, don't you think?
19:52 TimurTabi: The .run file also contains the other binaries (booter-load, etc), they're just harder to extract.
19:53 airlied: maybe but they have names where they exist, and I'd like to have the same names here to make it obvious
19:54 airlied: it will also make it easier for someone in future to extract new fw from .run
19:54 airlied: we have the script for booter
19:54 TimurTabi: I've already updated the python script to do that
19:54 TimurTabi: Let me send you the latest script. It will be part of r550, but that's taking longer to ship than I hoped.
19:56 TimurTabi: https://paste.centos.org/view/438ac6be
19:57 TimurTabi: With the -d parameter, you can pass the 535.113.01 .run file, and it will extract the gsp_xxx.bin files as well.
19:57 TimurTabi: I was really hoping to avoid updating the script *again*
19:58 airlied: how do we make sure that script gets kept up to date?
19:58 airlied: since it seems like it's going to lag by weeks or months
19:58 airlied: maybe we could host a repo with just that script so we can do development on it in the open
19:59 TimurTabi: Well, delivering it with openrm makes it easier to conform to our release and code review process.
19:59 TimurTabi: well, easier for me.
19:59 airlied: but if you aren't actively monitoring it every release and something changes then we have to wait for a number of release cycles?
19:59 TimurTabi: But the script should not need to be updated unless there's a new firmware.
20:00 TimurTabi: I mean, unless there's a new firmware to add to the list of firmwares that Nouveau has to process
20:00 airlied: there will be new architecture
20:00 TimurTabi: Well, it is MIT licensed. You could just host it yourself somewhere.
20:00 TimurTabi: Maybe something to bring up in the next Tuesday meeting
20:01 airlied: why isn't it for example included in the latest 535 releases?
20:01 airlied: why does it have to wait for 550?
20:01 TimurTabi: Well, because I didn't back-port it to 535 since I was told that 535 was locked down and I would need to go through hoops to get permission.
20:01 TimurTabi: I was also told that 545 was short-lived.
20:02 TimurTabi: To be honest, I was expecting r550 to be released before you submitted stuff upstream.
20:04 airlied: ah well maybe just submit what you have now to linux-firmware and we can consider whether we host the script somewhere so you can keep it up to date outside the nvidia cycles
20:04 TimurTabi: ok
20:05 airlied: granted I don't expect us to change it much now, just be annoying in the future if we constantly have the script lag the nvidia release where stuff changes by weeks or months
20:05 TimurTabi: Well, if I knew in advance which release you were targeting, I could have justified the back-port to that release.
20:06 airlied: that won't work though
20:06 airlied: since we can't target 535.* or 550.*
20:06 airlied: we have to target an individual 535.x.y
20:06 airlied: and we can't know in advance which one to target
20:06 airlied: since we don't have any insight into that
20:07 airlied: if we have firmware abi stability it might be okay to do that, but we don't so here we are
20:07 airlied: so if I pick 535.113.01 and you backport the script fixes to 535.129.10, that doesn't help me
20:07 TimurTabi: Sure, but the script won't change within a release. It's not you'll need to load a completely new firmware image in 535.115 that you didn't in 535.113
20:07 TimurTabi: Oh, I see
20:08 TimurTabi: Since it's already released, a backport won't help much.
20:08 airlied: I also don't trust nvidia to not completely change the naming between 535.113.01 to 535.129.10 :-)
20:08 TimurTabi: Hmmm
20:08 airlied: because I don't think you would consider tha an external detail you'd have to care about
20:09 TimurTabi: The script today creates all the binaries you need for any version of 535 or 545 and even 550
20:09 airlied: yes so it should be good for now, until we get to the next architecture addition or firmware fork point
20:09 TimurTabi: Yes, but that's something for which we should have ample warning.
20:09 airlied: granted if architecture additions only need a symlink we can just do that in l-f manually
20:09 TimurTabi: But, I would have no problem hosting the script somewhere else.
20:10 TimurTabi: It could even be hosted in linux-firmware itself.
20:13 airlied: yeah probably be more painful to fix there :-P