00:26Lyude: hm, actually i was wrong - i think we can use libdrm for this pretty easily (and also want to apparently)
08:11cabbaged: Hi. I'm trying to understand the nouveau code a little. I'm new to DRM. I was trying to trace out how nouveau communicates with ALSA, but as I was tracing it out I realized I couldn't find any place that component_bind_all() is called from. How does the audio component get bound? Thanks.
09:01AndrewR: cabbaged, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/dispnv50/disp.c?id=72923e24f98aa5d99adeb83b7b4f0ec1496e5b5e - may be somewhere there? (nv50_audio_component_bind) Just looked at tree via web search function ....
19:54cabbaged: AndrewR, that's the call to bind the device from the bind op, but compenent_add_all is never called in order to actually execute that op, at least that I can find
20:00imirkin: cabbaged: that component stuff was done by takashi (sp?), the alsa maintainer. i don't think any of us know anything about it.
20:01imirkin: things generally seem to work though ... what's the issue that you're seeing?
20:02cabbaged: I'm not seeing an issue. I want to understand how the link works, and where the binding takes place between ALSA and Nouveau.
20:03imirkin: i'd recommend looking at the commits which added this stuff. they were relatively recent (5.x)
20:03cabbaged: Good idea, thanks.
20:04imirkin: cabbaged: https://github.com/skeggsb/nouveau/commit/0eeefc8d8a66dbb0836b8976db05e497112ab6a8
20:04imirkin: there was some later follow-up too to fix a few things, but the general idea didn't change i think
20:05imirkin: specifically https://github.com/skeggsb/nouveau/commit/957c3b17a95f55b9f8dc17e72e6537586a47f376
20:21RSpliet: cabbaged: a few high-level hints (no in-depth knowledge)
20:22RSpliet: the NVIDIA GPU exposes an "azalia" sound card. It's like there's multiple devices in the same PCI-E slot, one for graphics and one for audio. The driver managing that device is snd_hda_intel
20:22imirkin: (aka PCI functions)
20:24RSpliet: AFAIK the only bits that nouveau does are 1) enable that audio device such that it shows up on the bus, 2) forward monitor hotplug events to the intel hda driver such that it knows which ports to use, and 3) set up a bit of routing to send the right audio over the right DP or HDMI port
20:25imirkin: also forwards ELD data
20:25imirkin: which describes the audio capabilities of the sink
20:26imirkin: (number of channels, frequencies, formats)
20:42cabbaged: Perfect, this is plenty for me to brows through, thank you!
21:24Lyude: cabbaged: btw-not sure if DP audio actually works, I know DP MST audio doesn't work yet at least (it's on my todo list, but it'll be a good while till I get there)
21:24Lyude: but HDMI audio should work fine
21:24Lyude: on most machines, I think there's a few I've heard there's issues on (I think they're mostly newer turing laptops, and it doesn't have issues on all of them)
21:29Lyude: also, do any mesa folks know what (if anything) we use the ce engine for? I originally thought it might have been what mesa would use for moving textures and such around, but looking at src/gallium/drivers/nouveau/nvc0/nvc0_screen.c it looks like we use something called m2mf? (or is that the same thing?)
21:31Lyude: oh-from the open-gpu-docs it would look like they're different classes
21:35Lyude: skeggsb: btw, do you have any plans on moving the m2mf stuff in mesa over to the open-gpu-docs headers like you did with evo/nvd in the kernel?
22:00imirkin: Lyude: DP audio definitely *used* to work
22:01imirkin: Lyude: we use it for ... copying
22:01imirkin: Lyude: look at nvc0_transfer.c
22:02imirkin: there are different transfer methods for different things
22:02imirkin: the nvc0 variant of the copy engine is controlled by firmware, and in our infinite wisdom we didn't make the methods line up to the blob's impl
22:02imirkin: starting with nve4, we use p2mf for that stuff
22:02imirkin: which is built-in
22:04Lyude: imirkin: it probably does then, i just haven't tested it myself
22:05Lyude: imirkin: ahh, that answers a lot of what I was curious about
22:05imirkin: the copy engine is also used by the ddx, btw
22:05imirkin: (in gens where available)
22:06Lyude: i'm wondering which one would be easier to use in igt in order to implement untiled → block linear and vice-versa conversion for fbos
22:06imirkin: iirc copy engine can do that.
22:07imirkin: note that there are several instances of copy engines
22:07Lyude: i guess i'll have to look at the ddx at some point to see what it does with it (would be nice if nvidia actually described how to set this thing up in their docs…)
22:07imirkin: and ce2 is different than ce0/1
22:07Lyude: imirkin: yeah that makes sense
22:08imirkin: not that you'd use this, but some fermi's also had a gunzip-accelerator engine
22:08imirkin: i don't think it ever got used
22:08Lyude: Any idea what this was intended for?
22:09imirkin: the idea might have been to save on pcie bandwidth for transferring frames with display gpu
22:09imirkin: but we've never gotten confirmation on that
22:09imirkin: (maybe it did both gzip and gunzip, or just one, not sure)
22:10imirkin: and it took the spot of one of the copy engines
22:10imirkin: so it was very confusing when the copy engine would randomly not work :)
22:10imirkin: and then we realized our mistake...
22:10imirkin: "this ain't a copy engine" :)
22:25skeggsb: please *don't* write any new userspace code using fermi ce, we have nothing that does by default afaik, and i want to implement nvidia's class in fw instead
22:25skeggsb: can't if it becomes abi :P
22:25skeggsb: >=gk104, go for it
22:27imirkin: skeggsb: i thought ddx and mesa did use it...
22:28skeggsb: ddx has code to, it's never been default though, and had buggy sync with the gr channel iirc
22:28skeggsb: i'm happy to pretend it doesn't exist
22:28skeggsb: i didn't think mesa did.. i swear i looked..
22:28imirkin: skeggsb: huh ok. and looking at mesa, doesn't look like we use it.
22:28skeggsb: oh phew
22:28imirkin: i was sure we did, but the code disagrees :)
22:28skeggsb: yeah, i recall being surprised by that too
22:28skeggsb: fermi has m2mf still, yeah?
22:29imirkin: which is what we use
22:29imirkin: and then for nve4+ we use copy
22:29skeggsb: grce basically replaces that there, so, yeah
22:29karolherbst: ahh so p2mf is copy and m2mf is some legacy stuff?
22:29skeggsb: p2mf is InlineToMemory
22:29skeggsb: that exists still
22:29karolherbst: ohh, I see
22:29skeggsb: MemoryToMemoryFormat went away after fermi, existed since nv04
22:29imirkin: skeggsb: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nouveau_copy90b5.c
22:30skeggsb: err, earlier
22:30imirkin: what would prevent that from being used?
22:30Lyude: skeggsb: there's exactly one fermi gpu (gf119) that's relevant here
22:31skeggsb: imirkin: pNv->ce_enabled =
22:31skeggsb: xf86ReturnOptValBool(pNv->Options, OPTION_ASYNC_COPY, FALSE);
22:32skeggsb: Lyude: changing the method interface in our ce ucode to match nvidia's shouldn't be *too* difficult i don't think
22:32skeggsb: ours is basically a subset, but otherwise fairly similar.. i hope, anyway.. because i hate writing falcon asm
22:33imirkin: skeggsb: should we enable CE on kepler+?
22:33skeggsb: imirkin: in the ddx?
22:33Lyude: skeggsb: would we need to do that before using CE in igt?
22:33imirkin: skeggsb: yes
22:33skeggsb: no, the async copy code never worked properly
22:33imirkin: ah ok
22:33skeggsb: it was put there as an experimental option, and forgotten
22:33imirkin: too bad
22:33skeggsb: probably just a matter of throwing a few semaphores around
22:37skeggsb: Lyude: if you want to use fermi, yues
22:37skeggsb: bonus though, you can write the code for kepler, and it'll work for fermi when the fw changes
22:38Lyude: skeggsb: yeah I was about to sayit sounds like it'd be easier to skip fermi at first
22:38Lyude: which is fine since I don't think I have a gf119 anyway? i'd have to check
22:38skeggsb: yeah, my remaining gf119 barely likes to boot anymore, always a fight to get it to POST
22:39Lyude: one of my personal kepler cards started doing that :\, but bizarrely it's only doing it in one specific machine
22:39Lyude: porygon's test machine boots up with it fine :(
22:39skeggsb: bad combo of worn traces on both :P
22:39Lyude: oh probably
22:40imirkin: pcie slots / cards aren't designed to be constantly plugged in/out
22:40imirkin: it's not like USB connectors
22:40skeggsb: though, using the other pcie slot doesn't help my gf119 either
22:40Lyude: imirkin: yeah :(
22:40Lyude: a sad truth I've known all too well
22:40imirkin: i try to minimize it as much as possible
22:40imirkin: esp since my current comp (motherboard) is 10 years old by now
22:41skeggsb: hard to avoid sometimes when i have to go through and test everything :P
22:41imirkin: right. when it's basically your job - yes ;)
22:41skeggsb: but yeah, i tend to try and group those events together
22:42imirkin: although i'm surprised you never just set up a small farm with stuff plugged in. perhaps practical considerations didn't allow for it?
22:42skeggsb: so it's less frequent, and stick to whatever board makes the most sense at the time otherwise
22:42Lyude: i wonder if those pci bridge cables would help with this sort of thing, so you wear out the bridge cables before the actual traces on the board
22:46Lyude: skeggsb: btw, should I try to avoid relying on the ddx for reference w/ bringing up the ce in igt then?
22:48skeggsb: the kepler stuff is probably fine, just ignore anything using <KeplerDmaCopyA
22:49skeggsb: unless you want to take a crack at modifying the fw? :P
22:49Lyude: skeggsb: I would-but probably at a later point :P (it would be a nice refresher on the silly thing that is falcon asm though)
22:50Lyude: since we only really have the gf119 that we can do crc readback on
22:50Lyude: i'm a little surprised cards with earlier versions of evo didn't have it implemented the same way (or I'd assume so since it's not documented, I haven't actually tried it myself)
22:52skeggsb: i wouldn't be shocked if it does, but they just haven't documented it openly
23:00Lyude: skeggsb: another thing I was wondering about, would you prefer we try to use some sort of macros like the ones we use with evo/nvd in the kernel along with nvidia's docs in igt? (hence why I asked about converting headers earlier)
23:00skeggsb: it's up to you i guess, but i intend to for the vulkan driver from the beginning
23:01skeggsb: hopefully threed class headers will magically appear at some point
23:03Lyude: skeggsb: btw-have you gotten any progress on the vulkan driver? or stuck waiting for stuff from nvidia
23:03karolherbst: was it ever been stuck on nvidia?
23:04skeggsb: i'm waiting on me to finish ampere bring-up to get back to it, i'm sorta working towards the kernel stuff for it in the background
23:04skeggsb: we're not stuck on nvidia for that
23:04karolherbst:should finish his finally working multi threading fix....
23:04Lyude: (also partly wondering if there's some libdrm-compatible nvidia register macros anywhere that I should be using :P)
23:04imirkin: skeggsb: btw, did you see there was an oops with current nouveau on ampere
23:04skeggsb: well, i guess there's no huge rush until we one day have decent clocks, so, meh
23:05skeggsb: imirkin: no?
23:05skeggsb: we should bail on the unknown chipset
23:05karolherbst: skeggsb: caused by my vGPU rework and apparently only is hit for unknown chipsets I think
23:05imirkin: skeggsb: we do bail, but not hard enough
23:06imirkin: skeggsb: https://lists.freedesktop.org/archives/nouveau/2020-October/037067.html
23:06skeggsb: yeah, i forgot the vgpu stuff happened which could have destabilised that :P
23:06karolherbst: skeggsb: I also saw this today: https://gitlab.freedesktop.org/drm/nouveau/-/issues/11
23:06karolherbst: skeggsb: do you already have a local patch for that or should I write some up tomorrow?
23:06skeggsb: no, haven't seen that, so go for it
23:07karolherbst: I meant patch for my vgpu fix regression :D
23:07karolherbst: don't have a patch for that gitlab bug
23:07skeggsb: oh, sorry :P not enough coffee yet it seems
23:08skeggsb: but, same answer, i don't have a patch for it, because i haven't hit an issue there
23:08karolherbst: well.. the order of my sentences could also have been better :p
23:08karolherbst: I think this is just suspend+resume stuff happening randomly though
23:08skeggsb: c51 is just awful anyway
23:08karolherbst: but let's wait for the user to confirm it's super reliably reproduciable anyway
23:09karolherbst: skeggsb: btw... I have stuck processes on the GPU...
23:09karolherbst: I think those were from some OpenCL CTS test doing allocation stuff, but I killed the processes...
23:10karolherbst: now there are... still there, but their proc stuff is already gone
23:10karolherbst: heh.. maybe I can still gdb attach to them, but I suspect that will break my kernel
23:10karolherbst: ahh yeah.. ptrace gone too
23:10karolherbst: ever seen anything like that?
23:12karolherbst: I also have no idea on how to debug this...
23:13karolherbst: the processes are gone as far as I am concerned, but those are still there and they prevent the GPU from suspending
23:21imirkin: so ... when i tested danvet's patches on a nv5, i also saw some funny business
23:21imirkin: but it was hard to quantify, and i wasn't sure if it was just due to the fact that it was an nv5
23:23karolherbst: btw.. in case anybody wondered, the CodeNames page on our wiki is the one clicked the most
23:24Lyude: i click that a lot, so that sounds about right :)
23:24karolherbst: google even uses it in their fancy boxes
23:24imirkin: i used to initially. now it's all memorized.
23:24karolherbst: "General code names" :p
23:24imirkin: i'm weak on the older family names...
23:24imirkin: celsius, kelvin, rankine...
23:25imirkin: rankine is nv30 iirc, curie is nv40?
23:25imirkin: and celsius is nv10, kelvin must be nv20?
23:26karolherbst: still don't have the backlink data :/