17:32edgecase: does nouveau do anything with VBIOS?
17:33imirkin_: nouevau doesn't work without i
17:33edgecase: run x86 code from vbios, or just data tables?
17:33imirkin_: never the x86 code
17:33imirkin_: data tables, as well as the init scripts
17:33imirkin_: (which one could argue are data tables, but they drive an interpreter)
17:33edgecase: i guess things like coreboot can just run the VBIOS POST code
17:34edgecase: sounds like AMD ATOM BIOS
17:34imirkin_: (and those scripts aren't just init scripts ... they're also run on reclock, display changes, etc)
17:34imirkin_: kinda ... i think atom bios is a way more complex thing
17:34imirkin_: yeah, on resume of course, since the bios won't post the board
17:35edgecase: anyone played with the new RTX boards that have USB host controller?
17:35imirkin_: see subdev/bios/init.c
17:35edgecase: and USB-C port?
17:35imirkin_: if it's not shipped for free by dell in a computer that has no need for the board, then i don't have it.
17:36edgecase: heh. i know those things.
17:36imirkin_: that's how i have GK208, GM107, and GP108
17:36edgecase: the USB-C is on the very newest boards, maybe nouveau doesn't support the gpu yet?
17:36imirkin_: no, it does
17:37imirkin_: and there were some patches from nvidia to support the usb-c thing somehow
17:37edgecase: just with the signed firmware?
17:37imirkin_: i forget the details
17:38imirkin_: naturally with firmware galore
17:38edgecase: i feel like there is an email client in there waiting to be found.
17:39edgecase: so, I found what could be the basis of VRAM useage tracking, nvkm_gpuobj_new and friends are the phys VRAM heap manager functions
17:40edgecase: then there are the bar1 and bar2 translation "heaps", for nv50+
17:40edgecase: the phys VRAM heap, I'm thinking of using the kernel's unwind function, to grab the caller's function name
17:42edgecase: otherwise, you have to add a parameter to the nvkm_gpuobj_new(....,"my name is henry") everywhere it's called, with some sort of #ifdef NV_DEBUG_TRACE_HEAP
17:54bylaws: Seems like the GTC talk is cancelled, I can no longer find it in the schedule
17:55karolherbst: bylaws: yep, looks like that
17:57bylaws: Hopefully they will announce it via a press release or something
20:05karolherbst: imirkin_: do you know if we have a pushbuf parser somewhere?
20:06karolherbst: mhhh... mhhh does that still work with nouveau?
20:06karolherbst: I thought that was always painful to use with nouveau
20:06imirkin_: if you force nvif=false
20:06karolherbst: I kind of wished we have something we could paste the libdrm syntax in
20:07karolherbst: especially know there we have the sync option and print the content on failed submission
20:07imirkin_: send patches?
20:07karolherbst: mhh.. I was under the impression I wrote something at some point
20:08imirkin_: there's also the older dedma
20:08imirkin_: perhaps it can be used for this?d unno
20:08karolherbst: yeah.. maybe
20:09karolherbst: but still I think it would be nice to be able to just parse whatever libdrm dumbs
20:09imirkin_: dedma should be adjustable for this, i think
20:09imirkin_: maybe not
20:09karolherbst: well.. the glue code is all that matters anyway
20:10karolherbst: just calling into the envytools parser is the simple part here anyway
20:11karolherbst: but I am sure I had something like this at some point... just need to find where (unless I deleted it or so)
20:49lovesegfault: karolherbst, imirkin can one of you explain to me where does mesa fall on the graphics stack?
20:49lovesegfault: I saw that mesa 20 prefers the iris driver over i965, but I don't understand how picking drivers is mesa's responsibility
20:50lovesegfault: what even is mesa
20:50karolherbst: mesa is an implementation of APIs
20:50karolherbst: and "driver" just means mesa internal drivers
20:51lovesegfault: karolherbst: oh, so it has nothing to do with kernel drivers?
20:52imirkin_: lovesegfault: aging, but still relatively accurate -- https://keyj.emphy.de/files/linuxgraphics_en.pdf
20:52lovesegfault: imirkin_: reading
20:52karolherbst: of course mesa talks to the kernel drivers through kernel interfaces, but that's a different story
20:52lovesegfault: so it goes dev -> kernel driver -> mesa driver -> app?
20:52karolherbst: more or less
20:52imirkin_: usually the arrows are reversed
20:52karolherbst: there are more parts
20:53karolherbst: btw getops is a terrible API and the people who came up with that should be ashamed of themselves forever
20:53lovesegfault: right, we talked about gallium a while back which I guess would make it app -> mesa_frontend -> mesa_backend -> dev
20:57lovesegfault: so nouveau is _just_ the kernel driver?
20:57lovesegfault: or is it also the mesa gallium backend?
20:59imirkin_: nouveau is like 5 different things
20:59imirkin_: which all work together
21:01lovesegfault: got it
21:05lovesegfault: What is mode setting?
21:05imirkin_: mode = thing that describes how the display is set
21:06imirkin_: modeline, etc
21:06lovesegfault: So like frame rate, resolution, color depth?
21:07lovesegfault: (pixel format ...)
21:07lovesegfault: got it
21:08lovesegfault: This thing is talking about KMSCON which says my ttys should have unicode support, is that accurate?
21:08lovesegfault: IME fonts kind of suck
21:08lovesegfault: (in the tty)
21:10imirkin_: kmscon never really took off
21:12lovesegfault: yikes last commit is 6 years ago
21:12imirkin_: the presentation is from 2014 :)
21:13lovesegfault: Ah :P
21:14lovesegfault: Oh, yeah, it's talking about fglrx
21:15imirkin_: but it's MOSTLY still quite good
21:15imirkin_: a few things in there didn't pan out
21:15imirkin_: but imho minor relative to the overall content of the presentation
21:16lovesegfault: yeah, I'm learning a bunch
21:16lovesegfault: it just got to wayland
21:17lovesegfault: oh I had forgotten about mir
21:47lovesegfault: I just played around with kmscon and it's a shame it didn't take off
21:47lovesegfault: it's pretty cool