13:49tjaalton: is there a way to limit the kernel to load nouveau only on a subset of hw? like for i915 there are gpu generations which can be made to require an extra boot option to load
13:52imirkin: tjaalton: not without patches which implement such a feature
13:52imirkin: tjaalton: a long while ago i made it configurable which generations would get built
13:53imirkin: but the patch was never upstreamed
13:53imirkin: tjaalton: what's the use-case?
13:53tjaalton: imirkin: ok, there are some issues with i+n hybrids with "new" dGPU's where nouveau loading causes issues
13:54tjaalton: making it impossible to install the system
13:54imirkin: ah right. you could add some rules based on pci id, no?
13:54imirkin: i don't know how fancy modprobe has gotten these days
13:55imirkin: anyways, having a blacklist in the kernel also seems like it could make sense
13:55imirkin: i.e. nouveau is broken for these devices, enable extra config option if you want it anyways
13:56imirkin: and stick all the GP10xM pci id's into the broken list
13:56tjaalton: or the other way around, load it where it's known to work
13:57tjaalton: as those id's shouldn't change
13:57imirkin: that's a LONG list of id's
13:58imirkin: and they get allocated left and right. nouveau tends to work in general on those
13:58imirkin: we don't have access to 95% of the hardware, so a whitelist isn't a practical option
13:59imirkin: i.e. it's not 1 id per chip
13:59imirkin: it's like ... 32 id's per chip. or more.
14:00imirkin: i think we know if it's mobile based on the vbios though -- so we could blacklist an entire chip if it's mobile, for example
14:00imirkin: we'd have to do a bit of "live" research though to make sure that bit correlates with the mobile-ness of the chip
14:25karolherbst: imirkin: maybe we could add a mode to nouveau which only turns the GPU off and does nothing on top of that, maybe?
14:27karolherbst: tjaalton: one of the issues is, that on some laptops you need the nvidia GPU to be able to drive external displays
14:27imirkin: karolherbst: well, i think the idea is to blacklist it on just those super-broken GP10x's
14:28karolherbst: sure, but then you have the GPU burn away your battery
14:28imirkin: the ones where it's not really nouveau's fault
14:28imirkin: but more like touching the _PR3 thing destroys everything
14:28karolherbst: it doesn't directly
14:28karolherbst: devinit is the actual cause
14:28karolherbst: if we dodn't do devinit, we would be fine
14:29imirkin: yeah, dunno. i haven't really kept up.
14:29karolherbst: yeah.. I digged into it, and devinit messes with the PCIe link config
14:29imirkin: i think distros would do well to just disable nouveau entirely, esp on EFI boots.
14:29karolherbst: and then makes the GPU unhappy
14:29karolherbst: imirkin: sure, but then you have those users which complain about sucky battery
14:30imirkin: esp on an install cd? it's all downside.
14:30karolherbst: best thing is really a module which just turns on the runpm stuff
14:30karolherbst: and nothing else
14:30karolherbst: but you can do that in userspace as well though
14:31imirkin: tjaalton: --^ why not just disable nouveau entirely on install cds?
14:32imirkin: esp in the modern age of efifb
14:32tjaalton: imirkin: that's one option
14:33imirkin: tbh, i dunno if enabling nouveau by default on a newbie-targeted distro like ubuntu is a good idea in the first place.
14:34tjaalton: the nvidia driver doesn't work on old hw though
14:34karolherbst: tjaalton: why not?
14:34karolherbst: just use the legacy branches
14:34tjaalton: because it doesn't support them anymore
14:34tjaalton: they're dropping legacy branches too
14:34karolherbst: you know what's the oldest supported hw?
14:35imirkin: tjaalton: sure, but just have them use vesa or whatever. (or efifb if the box has efi boot...)
14:35imirkin: tjaalton: well, not my call. just an opinion based on some recent events.
14:35karolherbst: allthough kernel support ist a big tricky with the legacy branches :/
14:36imirkin: karolherbst: esp for a binary distro
14:36tjaalton: karolherbst: 340 is the oldest one that supports current xserver
14:36karolherbst: which is fine
14:36imirkin: that gets you down to G80, released in 2008? or 2006?
14:36tjaalton: we had to drop 304 :)
14:37tjaalton: which also got dropped by nvidia
14:37karolherbst: mid 2007
14:37imirkin: The 8800 series, codenamed G80, was launched on November 8, 2006
14:37karolherbst: ahh, high end nes
14:37karolherbst: tjaalton: I am sure you don't have to worry that much for hw older than 13 years :p
14:37karolherbst: the users usually have completly different things to worry about in such cases
14:38tjaalton: you'd think, someone will complain in any case
14:39tjaalton: oh well, I don't care that strongly myself tbh, if there's a clean way to still build it but not load by default that'd be fine by me
22:05Lyude: skeggsb: in the atomic modesetting code for nv50, you name the new CRTC atomic state asyh, then asyc for connectors, etc. what do those abbreviations stand for?
22:06imirkin_: (i ask every time, and every time he explains it, and it makes sense for 30 seconds, and i forget again)
22:06imirkin_: i always want to read those as "async" but that's totally not it
22:06Lyude: yeah same
22:06Lyude: sometimes it feels like I'm reading acpi code..
22:07imirkin_: maybe h = head, c = core
22:07imirkin_: asy = ... no clue
22:07imirkin_: i've asked for a comment section at the top which explains all this
22:08Lyude: i'm understanding most of this now at least, minus some of the abbreviations
22:08imirkin_: i'm 99% sure that h = head, and c = core
22:09Lyude: yeah that part I'm sure of as well
22:09imirkin_: which themselves are weird concepts, related to how the nvidia stuff is configured
22:09Lyude: its just the asy I don't get, atomic state y?
22:09Lyude: oh yeah nvidia modesetting is very cute tbh
22:09imirkin_: atomic state, yes? :)
22:09Lyude: imirkin_: hehe
22:16skeggsb: (arm)ed state, (as)sembl(y) state
22:16Lyude: that makes sense :)
22:17imirkin_: see, i told you it made sense
22:17imirkin_: but i'll forget again very soon
22:17Lyude: skeggsb: btw, need reviews for that WARN_ON() fix I sent to the ML
22:17skeggsb: pretty sure i merged it already
22:18Lyude: oh ok! didn't get any message so I wasn't sure
22:21karolherbst: skeggsb: did you see my nouveau ops I posted a few days ago?
22:24karolherbst: any ideas?
22:25karolherbst: or was it already fixed and my build is just outdated?
22:25karolherbst: I was on your 4.19 branch
22:38skeggsb: can you reproduce it?
22:38karolherbst: I don't think so
22:38karolherbst: I just now it happens from time to time
22:39karolherbst: I was under the impresion that imirkin_ also hit it a few times?
22:39karolherbst: maybe it was a different issue
22:39skeggsb: nope, that's completely different
22:39imirkin_: not that one
22:39imirkin_: yours is the sec engine taking a dump
22:39skeggsb: would be nice to find out why that one's happening too, but it's actually harmless
22:39karolherbst: imirkin_: sure?
22:40imirkin_: i have no sec engine :)
22:40karolherbst: it was in the middle of a piglit run
22:40karolherbst: could be sec related.. dunno
22:56Lyude: skeggsb: is there a reason we don't just use the depth from the nv50_head_atom->base.depth in nv50_msto_enable() instead of mstc->connector.display_info.bpc?
22:56Lyude: erm, *instead of calculating it from mstc->connector.display_info.bpc
22:57skeggsb: i *think* so, but, i can't remember what/why... however, i'm going to rework all the depth stuff through there once this new monitor arrives
22:58imirkin_: display_info.bpc comes from edid, no?
22:58imirkin_: (well really, display_info)
22:58Lyude: skeggsb: alright, jfyi: long story short I'm working on this because some regressions came from my vcpi helpers ( https://patchwork.freedesktop.org/series/55932/ was my original fix, but that isn't going to work) and it looks like the easiest way to fix them is going to be to lock pbn/vcpi slot allocations in duplicated states (e.g. through suspend/resume)
22:59Lyude: would be OK to move that depth calculation into nv50_msto_atomic_check() and assign it to asyh->base.depth?
23:01Lyude: imirkin_: also-yes it does come from the edid, but using an edid (if it isn't cached from the start of the atomic check at least) to determne that info during the atomic check probably isn't a great idea
23:02imirkin_: Lyude: well, thing is that the bpc of the display might be 16bpc, but we're only driving it at, say, 8bpc
23:02Lyude: imirkin_: yep-another reason we shouldn't just go off the edid :)
23:03imirkin_: i've been pondering some of this stuff as i'm trying to get HDR going
23:09imirkin_: if you need me to test stuff, let me know -- i have a HDR tv at home.
23:09Lyude: OH! ok, I think I found the reason we have seperate depths
23:10Lyude: nv50_head_atomic_check_dither() explains it
23:20Lyude: looks like i probably can ignore it for what i'm doing as well, nice
23:23HdkR: Lyude: How does HDR support work in Linux atm? I've never hooked up any of my HDR panels to a Linux device
23:23Lyude: HdkR: I haven't kept up with the HDR business but I don't think it really works atm?
23:23HdkR: Makes sense
23:26HdkR: I ask mainly because I just got a new 10bit panel today :P
23:28pmoreau: HdkR: “any of my HDR panels”, you have more than one HDR display? :o I’d like to get my hands on one; I should try to motivate such a purchase for research purposes. :-D
23:29HdkR: I have a cheap TCL HDR TV that I'm replacing because it is partially dying
23:30imirkin_: HdkR: poorly, atm
23:30imirkin_: HdkR: if you use DP, you'll get the actual 10/12bpc over the wire
23:30imirkin_: if you use HDMI, only 8bpc
23:30imirkin_: there's 30bpp framebuffer support too
23:30HdkR: ah, I see
23:30imirkin_: and moderately soon, fp16 too
23:30imirkin_: but all relatively early days
23:31imirkin_: on intel, ville had a branch that did a bunch of hdr stuff across a bunch of the stack
23:31imirkin_: since you also need to indicate to the tv that the content is bt.2020 or whatever
23:31imirkin_: the pieces are falling together slowly
23:31imirkin_: i expect that this time next year, the situation will be at least moderately sorted
23:32HdkR: Considering Microsoft also doesn't have a perfect solution yet, I figure it is going to take a while :P
23:32imirkin_: it's not an easy problem ... lots of things in the middle
23:34HdkR: Good thing is that HDR doesn't need to work on Linux for me. Making my terminal look "better" would be silly
23:35pmoreau: What about that higher contrast in TTY? :-D
23:35HdkR: Got to have those super dark backgrounds and have the white font be 10k nits
23:36imirkin_: HdkR: mostly for movie content, obviously
23:37loonycyborg: or games I guess? :P
23:37loonycyborg: to encourage them to better use dynamic range
23:37loonycyborg: instead of being all brown and dark :P