09:13OftenTimeConsuming: Noveau seems to be broken on the latest versions of Linux? The latest I can get to modeswitch is: 6.0.8-gnu and even then I get some sort of error and wayland doesn't work: https://termbin.com/kjqn I can unlock the same error in that version if I enable displayport/hdmi audio.
09:15DodoGTA: OftenTimeConsuming: HDMI audio still works on nouveau with 6.3.3 kernel (GTX 1650 Ti)
09:16OftenTimeConsuming: s/same error/same hanging issue/ I'm sure if I passed modeswitch, HDMI audio would work.
09:20OftenTimeConsuming: Libreboot seems to be pretty bad at initing things, but the same .config works fine on another computer with the same setup - but even then, I can't get seabios to init a 780 Ti without at least 12 tries, when it works fine in the other computer.
11:29karolherbst: OftenTimeConsuming: you need firmware
11:30karolherbst: not using firmware is not a supported setup at all
11:30karolherbst: libreboot users are on their own
11:33karolherbst: ehh wait
11:33karolherbst: libre linux users I mean
11:34karolherbst: but anyway, if the bug only happens with libreboot it's a libreboot bug
11:35juri_: as much as it pains me to defend the libreboot folks, knowing what's going on may be useful. at least libreboot is a consistent BIOS implementation, unlike the random bios of various motherboards.
11:36karolherbst: that might be true, but if they fail to init the GPU, they failt to init the GPU
11:36juri_: it's also handy to be able to do A/B testing, where A is a known quantity, and B is <whatever>.
11:36karolherbst: *fail
11:36juri_:nods.
11:37juri_: it's also worth checking coreboot on the same hardware. yet-another-known-quantity.
11:39karolherbst: yeah.. though I don't really know what's the difference between coreboot and libreboot anymore... does libreboot execute the GPUs VBIOS stuff?
11:40karolherbst: executing and running the VBIOS stuff is crucial though. Though in theory nouveau should be able to do the POST parts itself, but that also requires having the _original_ GPUs VBIOS
11:41karolherbst: I wouldn't be surprised if libreboot messes around on that level
11:41juri_: i think they make this stuff optional nowadays.
11:41juri_: i too, am a bit confused.
11:41karolherbst: there was some issue around where a user got a different/false VBIOS on libreboot
11:44karolherbst: but in either case, it's most of the time a waste of my time to figure out what's wrong there. If a BIOS implementation doesn't behave compatible to stock BIOS, it's buggy, end of story.
12:17OftenTimeConsuming: The init issue was with a different GPU to the one I'm using right now. SeaBIOS can init the 960 just fine.
12:21karolherbst: OftenTimeConsuming: okay, but you still don't have the required firmware to use that GPU
12:21OftenTimeConsuming: Seems to be working fine.
12:21karolherbst: well.. software only
12:22OftenTimeConsuming: glxgears does work.
12:22karolherbst: yeah, software only
12:22OftenTimeConsuming: I guess I'll start with Trisquel's .config and do shotgun surgery on it.
12:23karolherbst: you need GPU firmware
12:23karolherbst: that's the issue
12:24OftenTimeConsuming: Trisquel is fully functional you know?
12:24OftenTimeConsuming: Stop peddling nvidia's malware.
12:24karolherbst: what do you mean by "Noveau seems to be broken on the latest versions of Linux?" then?
12:25karolherbst: Are you running into an issue or not?
12:26OftenTimeConsuming: The version of Trisquel I have uses an older version of Linux that works fine. But I want to use a custom kernel config on a newer version of Linux and strange things are happening. Don't worry, I'm sure I can work it out myself.
12:27karolherbst: and I say you'll need the GPU's firmware, otherwise it's not supported and won't work properly. If you refuse to do that you are entirely on your own and I ask you to not waste our time
12:45OftenTimeConsuming: Is this firmware free, or?
12:46karolherbst: It's irrelevant to my statement
12:47karolherbst: It's either using the firmware or you can't use Nouveau on the GPU, it's really that simple. We don't have signing keys to use our own firmware anyway, so....
12:48OftenTimeConsuming: I accept your challenge.
12:48karolherbst: there is no challenge
12:49karolherbst: the maintanence cost would be too high for us to support other firmware, so any patches towards that direction will be rejected
12:49karolherbst: does it suck? yes, do we have another option? no
12:50karolherbst: on Turing+ the firmware we have to use is 25MB+ in size. We don't have the people to write that stuff ourselves.
13:19juri_: and you won't get them with that attitude.
13:20juri_: *sigh*
13:20juri_: oh well. i have enough of my own fires. thanks for the memories.
15:40tertl8: he's just being honest
15:43tertl8: maybe you can use Trisequel with amd or intel gpus
15:43tertl8: or just use software rendering
15:44karolherbst: intel and amd also require firmware blobs
15:44karolherbst: even earlier than nvidia did
15:44karolherbst: there is a reason why libreboot and linux-libre are irrelevant today and nobody wants to fix bugs while using either project
15:45tertl8: yeah
15:45tertl8: when I was looking into it, they all seemed to be either forgotten about or vaguely supported
15:46tertl8: if I was going to go that route I would use OpenBSD
15:46karolherbst: it's good enough on systems where you don't need any firmware, but for nvidia that's already hardware from before 7.5 years ago
15:47tertl8: openBSD doesnt even use the virtual cores on Intel cpus by default
15:47karolherbst: would it be better if we could use open source firmware? yes. Does it help making it a pain for upstream project to maintain? no
15:47karolherbst: heh
15:47karolherbst: but that's because of security and working around those issues is hard
15:48karolherbst: and also because BSD is a server OS
15:48tertl8: true
15:48karolherbst: on a desktop you rather use those virtual cores because the only case where it's sec relevant is for VMs
17:10tertl8: i want to get my hands on a tenstorrent card
17:11tertl8: i requested to buy one but got no respnose
21:00averne: Hi all, I'm working on hardware acceleration for the Nintendo Switch (Tegra X1 w/ 2nd gen Maxwell). It's a bit of a pain since I can't use system libraries, so I have to interact directly with the driver through ioctls. At this point it's functional for most codecs, but I'm having some trouble with a VC1 video. I was hoping to use my gtx950 as a reference since it presumably uses the same NVDEC engine, so how would I go about
21:00averne: capturing ioctls and dma buffers? I came accross valgrind-mmt, is this what I'm looking for?
21:01averne: In particular I'm looking for this structure: https://github.com/NVIDIA/open-gpu-doc/blob/master/classes/video/nvdec_drv.h#L750-L879
21:03averne: For other codecs I used my jetson nano since it's also built on a Tegra X1, and built an LD_PRELOAD stub to capture stuff. However on desktop dpus, the ioctl interface is different and undocumented so I'm a bit lost.
21:05averne: (The reason I can't use my nano for VC1 reverse engineering is because NV doesn't distribute a driver for it, since it's a patented codec. You have to message them with a proof you're licensed by Microsoft, lol)
21:09karolherbst: averne: video acceleration uses the same mechanism as all the other subchannels (3d, 2d, copy, etc...). Nvidia even released "documentation" for those: https://github.com/NVIDIA/open-gpu-doc/tree/master/classes/video. Sadly, it's just for newer GPUs.
21:10karolherbst: we also have some blob ioctl parsing code in valgrind-mmt: https://github.com/envytools/valgrind
21:10karolherbst: but that's kinda out of date
21:11karolherbst: and much have changed, probably
21:12karolherbst: but yeah... so in theory you still capture the command buffers and parse their content
21:12karolherbst: just some parts of the driver moved towards userspace command submission
21:12karolherbst: and I have no idea how one would even capture that
21:14averne: Thanks, yeah I'm aware of those docs and referenced them while working on this project. Afaik the structures haven't changed from Maxwell to Ampere+, they just append new extensions so they are still accurate for Maxwell.
21:14karolherbst: yeah, for the nvdec/nvenc API I kinda expect that
21:14karolherbst: but on the hardware level things might have changed
21:15averne: Command submission shouldn't be much of a problem since it's presumably the same as for other codecs which I have working. I'm really looking for the metadata sent to the NVDEC controller.
21:15averne: So inside dma bufs
21:19karolherbst: ohh right.. that stuff had another layer of indirection..
21:20karolherbst: averne: we have some support for that stuff for really really old GPUs, but that's before nvdec/nvenc existed
21:22tertl8: karolherbst: rusticl is a compiler right?
21:22karolherbst: compiler in what sense?
21:24tertl8: well, I would like to possibly try to extend PyOpenCL
21:24tertl8: maybe starting with something like cupy but using openCL instead of cuda
21:26tertl8: i know its a can of worms, but Im curious
21:27karolherbst: rusticl is an OpenCL implementation
21:29tertl8: I think Im gonna try to install rusticl tonight
21:29averne: karolherbst: Thanks for the info, looks like I'll have to put some time into understanding valgrind-mmt and adapting for my needs. You're not aware of any other prior research into nvdec stuff, by any chance?
21:42karolherbst: I'm not
21:44airlied: also tegra and dgpu have some subtle differences around video apparaently
21:44airlied: enough that I was told implementing video on dgpu with those class headers will have some tricky bits
21:49averne: They might. Afaik those classes were open sourced to serve for a VAAPI driver for Tegra that didn't really go anywhere. I don't even know if their UAPI was merged. https://github.com/cyndis/vaapi-tegra-driver (see in engine_headers)
21:50airlied: I was told by nvidia's video team :-) I did ask them to open dgpu class headers
21:51airlied: but yeah there is always the problem of those metadata tables in decoders that need documenting