05:21imirkin: online nvbios parser
17:51lovesegfault: imirkin, karolherbst Thanks again for the help yesterday
17:51lovesegfault: I've been running on nouveau with absolutely no issues now
17:57Lyude: Anyone know if any cards >= gf119 actually had any kind of PIORs?
17:57Lyude: nvidia definitely seems to mention PIORs in gf119+, but I'm not sure if that actually means there were any cards that had them
17:58Lyude: (skeggsb maybe?)
17:58imirkin_: Lyude: remind the group what PIOR is used for?
17:59Lyude: imirkin_: programmable input/output resource, basically just one of nvidia's equivalents to a video encoder that's off-chip (SORs, serial output resources e.g. on-chip encoders are more common, and of course you also have DACs)
17:59imirkin_: oh right
17:59imirkin_: i don't think i've seen anything like that on kepler
17:59imirkin_: (or newer)
17:59imirkin_: it's all SOR's from what i've seen.
18:00Lyude: hm, imirkin_ - just leaves the gf119 then i'm assuming?
18:00imirkin_: even that ... seems unlikely
18:00imirkin_: why do you ask?
18:00imirkin_: note that there are a lot of boards out there
18:00imirkin_: with all kinds of weird shit
18:00Lyude: wondering since i got bored at some point and actually went and hooked up more display cap probing
18:01Lyude: oh wait, lyude, you have access to the vbios repo
18:01Lyude: why not just check that
18:01imirkin_: Lyude: btw, dunno if you saw, but: https://people.freedesktop.org/~imirkin/nvbios/
18:01imirkin_: should probably hook it up to github gists somehow
18:01Lyude: imirkin_: no I haven't, neat o:
18:01imirkin_: i did it for edid-decode too
18:02Lyude: imirkin_: btw, the thing in particular I hooked up with caps probing is the ability to probe for the highest supported pixel clock, so you might find that useful for 4k over hdmi :)
18:02imirkin_: hdmi2.0 already works...
18:03Lyude: yeah, but i thought you had to enable it via some kernel parameter?
18:03Lyude: ah, lol
18:03Lyude: well, it's a nice thing to have anyway
18:03imirkin_: if you want to do something that's out of spec, you have to use a kernel param
18:03imirkin_: e.g. if you want to drive your 165mhz tmds at 300mhz
18:03imirkin_: or if we "detect" it wrong
18:04imirkin_: like for fermi, we just set it to 225, but i've seen strong evidence that blob driver allows 297 on some fermi boards
18:05Lyude: yeah, having the max clk stuff might fix cases where we detect it wrong
18:09karolherbst: Lyude: I see you've implemented the interlaced checks as well
18:09karolherbst: I think there are also some clock caps somewhere around as well
18:09karolherbst: not sure if for fermi though
18:10Lyude: karolherbst: yep-that's the part I'm looking at :)
18:10karolherbst: I wrote some patches a while ago.. let me check if I had anything
18:10Lyude: karolherbst: there is for gf119, for earlier we should just hardcode the max clock
18:10karolherbst: Lyude: https://github.com/karolherbst/nouveau/commits/fix_interlaced_reject
18:10Lyude: karolherbst: ah lol, I was wondering if you still had that around. I've got most of the stuff written except for the hardcoded values before you could query for max clock caps
18:11karolherbst: https://github.com/karolherbst/nouveau/commit/d837208d5e6b805ce8444b3511fd4cbacf9af9ce is the commit to read out the caps
18:12karolherbst: which gen was 90 again?
18:12Lyude: ahh, yeah i've got it done a little more simply - just moved the evo channel init into nouveau_display_create(), call the caps function from there (I don't think you need to actually wait for the 0x8c method to complete? but maybe i'm wrong on that
18:12Lyude: karolherbst: gf119+
18:12karolherbst: mhh, okay
18:13imirkin_: so kepler+ is 297mhz
18:13imirkin_: so it's basically not worth checking the maximums
18:13karolherbst: yeah no idea, I didn't really spend much time investigating as much
18:13karolherbst: imirkin_: well, we read the data anyway
18:13Lyude: imirkin_: meh, may as well. i'm assuming if they're there there's probably a reason for it
18:13imirkin_: Lyude: yeah, if the limits are reliable
18:13karolherbst: but yeah...
18:14imirkin_: which they might not be :)
18:14karolherbst: I think I have some limits somewhere saved...
18:14karolherbst: and it was weird
18:14karolherbst: let me search a little
18:14Lyude: i'd actually assume they're more reliable then anywhere else we can read them from, just based on some of the docs i've got from nvidia
18:14karolherbst: Lyude: I think they are weird
18:19karolherbst: heh.. apparently I didn't save the data... maybe it's somewhere else
18:20karolherbst: oh well
18:20karolherbst: Lyude: I remember that there were some weird values reported, but I don't remember
18:20karolherbst: anyway, worth checking that on some gpus
18:24Lyude: karolherbst: huh, interesting, just because I'm pretty sure that's the value that the fe itself actually validates the clock against
18:24Lyude: also, confirmed basically no piors gf119+
18:25karolherbst: well, we don't get 297MHz reported, but 300MHz eg
18:25karolherbst: but maybe it doesn't matter
18:25karolherbst: but there were some other oddities I think
19:35imirkin_: tbh i don't remember where 297 comes from
19:37Lyude: imirkin_: vbios apparently
19:37imirkin_: yeah, i've seen it there
19:38imirkin_: but i couldnt convince myself that it was reliable
19:38Lyude: karolherbst: jfyi, the runtime PM issue doesn't affect the P50
19:38imirkin_: back when i was investigating, i thought the vbios values could be wrong
19:38imirkin_: and/or indications of something else
19:38karolherbst: Lyude: yeah.. I am midly aware
20:21lovesegfault: imirkin_: You cursed me yesterday, now I'm trying to understand ACPI
20:28imirkin_: don't worry, you'll get over it
20:29lovesegfault: Why is it that running glxinfo shows info for my iGPU only, not the nv card?
20:29imirkin_: glxinfo only shows the gpu it runs on
20:29lovesegfault: c.f. https://gist.github.com/747ea9a38e7fa8677f0271c8c3aadbfb
20:29lovesegfault: Oh, I see
20:29imirkin_: you could run DRI_PRIME=1 glxinfo
20:29imirkin_: which will spin up the nvidia gpu
20:30lovesegfault: imirkin_: bingo :)
20:34lovesegfault: Interesting, why does it seem like glxgears with vsync off runs _way_ faster on the iGPU than on nouveau?
20:34lovesegfault: like, 10x more fps
20:34imirkin_: because PCIe bandwidth is finite
20:34imirkin_: glxgears with vsync off on a remote gpu is a measure of pcie bandwidth, basically
20:35lovesegfault: Oh, I see!
20:35imirkin_: you can transfer so many frames per second given PCIe speeds
20:35lovesegfault: I had never thought of that, but it makes perfect sense
20:35imirkin_: (whether nouveau hits that, i don't know for sure, but it seems probable)
20:37lovesegfault: Also, what the hell is this gallium thing I see mentioned all over mesa-related discussions?
20:37imirkin_: it's an abstraction that makes it possible to write a single hardware driver with various API layers on top
20:38imirkin_: (and to have the idiosyncracies of those APIs be normalized so the drivers don't care)
20:39lovesegfault: Oh, is it a similar effort to this but at a lower level of the stack?
20:39lovesegfault: : https://github.com/gfx-rs/gfx
20:39imirkin_: the inverse of that :)
20:40imirkin_: i.e. allows multiple APIs to be used as input to a single hw driver
20:41lovesegfault: I see, that must make you guys' lives easier!
20:42imirkin_: it allows a nice separation of concerns
20:42imirkin_: one could *probably* make a more optimal driver without it, but it'd be a lot harder, and less shareable across backends
21:02Lyude: imirkin_: many have said that about gallium, but every time I worry about that I just remind myself that iris exists because it's faster then the non-gallium i965 driver ;)
21:02Lyude: (there's more reasons then just gallium for that speed boost i'm sure, but it's a pretty good case in point imo)
21:15lovesegfault: Lyude: What's iris?
21:15lovesegfault: Oh, is it a gallium-based intel driver?
21:15lovesegfault: (assuming since you compared it to i965)
21:31imirkin_: which is more performant in many cases
21:31imirkin_: but just coz they did something dumb with i965 (or more likely, were sunk under the weight of some bad decisions)
21:31imirkin_: doesn't mean that one couldn't make a more optimal drier by integrating GL + backend more closely
21:32imirkin_: that said, it's definitely not worth it given the amount of developer time available
21:32imirkin_: but e.g. back in the bad old days, glVertex* would just submit a command
21:32imirkin_: this is more optimal than having layers.
21:35Lyude: imirkin_: yeah, I think they made a bunch of big mistakes with RA iirc
21:35imirkin_: that's unrelated
21:35imirkin_: compiler is the same
21:35imirkin_: they made mistakes in their command emission strategy
21:35imirkin_: which weren't fixable without rewriting the whole driver
21:35imirkin_: also iris takes advantage of some stuff htat wouldn't be possible if you supported pre-gen8
21:36lovesegfault: Is skylake post-gen8?
21:36imirkin_: skl = gen9
21:36lovesegfault: Oh, then maybe I can use iris?
21:36imirkin_: bdw = gen8
21:36imirkin_: you definitely can
21:37lovesegfault: Do I need some special version of mesa?
21:37lovesegfault:wonders what his version of mesa is
21:37Lyude: mesa collector's edition with added dlc only
21:37imirkin_: while iris is available in that version
21:37imirkin_: it's not enabled by default
21:37imirkin_: it's enabled by default in 20.0
21:37lovesegfault: Lyude: lol
21:38lovesegfault: 20.0 isn't stable yet, right?
21:38imirkin_: it's released
21:38imirkin_: i dunno what you mean by stable
21:38imirkin_: bug-free? i don't think any version achieves that
21:39lovesegfault: I mean that it isn't an RC or a pre-release, etc
21:39imirkin_: it's not
21:40imirkin_: wow, that's so sad ... a total of 7 changes from me for that whole release
21:40imirkin_: (since 19.3, presumably)
23:01Lyude: karolherbst: you still around by chance?