00:43 Lyude: dealing with a weird issue with nouveau + the chameleon. nouveau never seems to be able to read the EDID from the chameleon's DisplayPort ports properly. If I snoop the i2c transactions when it tries reading the EDID, nouveau appears to be doing the exact same thing i915 is (i915 doesn't have any trouble reading the EDID). https://paste.fedoraproject.org/paste/ODZQ5VKlU4zyE48kaPJsal5M1UNdIGYhyRLivL9gydE=
00:43 Lyude: Does anyone have any idea where that junk in front of the actual EDID header that nouveau seems to be getting from i2c might be coming from?
12:58 gnarface: hey guys so i recently found out the hardware video decoding on the G92 isn't working (still)
12:58 gnarface: how is it on the GF114 though?
12:58 gnarface: if i upgraded to a 560 Ti might it work?
12:59 gnarface: NVIDIA Corporation GF114 [GeForce GTX 560 Ti] (rev a1)
13:54 dboyan: imirkin, I've updated the comments for rcp and also the code, to make it more straightforward and different from the blob (at a little cost of efficiency)
13:55 dboyan: I also implemented a simple version of rsq with 3 rounds of newton-raphson steps
13:55 dboyan: imirkin: https://github.com/dboyan/mesa/tree/fp64-rcprsq2
13:56 dboyan: The original fp64-rcprsq1 branch is also updated without the rsq implementation
14:12 mytbk: Doesn't xf86-video-nouveau support GTX750?
14:14 dboyan: mytbk: git version seems to support GM10x
14:15 mytbk: I saw https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nv_driver.c
14:15 mytbk: The NVKnownFamilies array still doesn't have NV110.
14:17 dboyan: well, I'm not very familiar with that and I don't have a maxwell myself.
14:18 dboyan: By the way, why don't you use the modesetting driver? That should work
14:19 mytbk: I have modsetting driver installed on my system, and I haven't seen its log yet.
14:19 mytbk: My mainboard also has an integrated graphic card.
16:37 imirkin: dboyan: ok cool, will have a look later.
16:38 imirkin: gnarface: GF114 video decoding should work as well as any other generation. it's not perfect, but the imperfections are identical across generations.
16:38 imirkin: gnarface: it's just G92 that's special - only one where we can't seem to get the video decoding engine up and running
16:39 gnarface: so the imperfections are different than with the official binary driver?
16:39 gnarface: the hardware decoding doesn't look the same?
16:39 gnarface: or by imperfections do you mean other functional imperfections?
16:40 imirkin: imperfections are situations where there's something in the incoming bitstream that we don't handle properly, but the blob driver does.
16:40 gnarface: hmm
16:40 imirkin: happens on some H.264 videos.
16:40 gnarface: i wonder if any that's something i'd run into with the video stream from steam in-home streaming
16:41 imirkin: i spent a ton of time investigating it a very long time ago, with no useful findings. i now have a better example, but need to examine it. (and it's been in this state for at least a year)
16:41 imirkin: well - it has to do with the specific encoding. originally i found it happened most often with movie trailers, although since then i've seen it in regular videos as well.
16:44 gnarface: interesting, weird
16:44 imirkin: but many videos have no problems at all
16:45 imirkin: that said, the GF114 will be slow as molasses - no reclocking on fermi.
16:45 gnarface: ah, bummer
16:46 gnarface: but would that matter for the video decoding, or just opengl?
16:47 imirkin: depends on the specific board
16:48 imirkin: some of them clock to lowest perf level on boot, others to medium
16:48 imirkin: if it's medium then you're fine. if it's lowest, might be too slow.
16:48 karolherbst: well, but the engines should reclock fine though, we just need to enable it
16:49 imirkin: is that worthwhile for super-slow ram?
16:49 imirkin: i guess it might be...
16:49 karolherbst: depends on the workload
16:49 karolherbst: for some games this indeed give livek 25% perf boost
16:50 karolherbst: and for other workloads it was more like 100%
16:50 karolherbst: it's better than nothing at least
16:51 karolherbst: I think I will write a patch for fermi to at least enable engine reclocking
16:54 gnarface: i wouldn't exactly call it "super-slow" ram
16:54 gnarface: i've got many slower video cards on hand
16:54 karolherbst: it depends on the boards
16:54 karolherbst: for DDR3 cards the difference in mem clocks isn't that high actually
16:54 karolherbst: but for gddr5 it is
16:54 karolherbst: but engine clocks laways have big differences
16:54 karolherbst: afaik
16:55 karolherbst: gnarface: can you paste your pstate file?
16:55 gnarface: i don't know how
16:55 gnarface: but i'm not actually using nouveau on the 560 yet
16:55 gnarface: that machine still just has the old G92 in it
16:59 imirkin: Lyude: an observation - this sequence shows up a lot in nouveau's i2c replies: 01-00-01-00-02-00-00-00-00-00-00-00
17:01 Lyude: imirkin: yeah. I ended up figuring out the issue before I went to bed: the chameleon DP RX has a register that controls it's behavior when the source is requesting data but it's not ready. It can be switched between just mindlessly ACKing the requests (0) or actually sending defers (1), and defaults to 0
17:01 Lyude: Setting it to 1 fixed the problem entirely
17:02 karolherbst: gnarface: mhhh
17:02 karolherbst: gnarface: g92 doesn't reclock as well, right?
17:02 imirkin: Lyude: ah. presumably something should be fixed in nouveau though?
17:02 Lyude: Possibly? I would expect it should be sending defers though shouldn't it(
17:02 Lyude: *?
17:03 imirkin:has no clue about ... anything, really
17:03 imirkin: you should also avoid the assumption that anyone who knows anything about DP has touched the nouveau code
17:04 imirkin: i'm sure skeggsb figured *something* out while he was hacking DP-MST support in, but i doubt much attention was paid to small details
17:04 Lyude: It's breaking on DRM code that nouveau just happens to be calling though
17:04 Lyude: drm_get_edid
17:05 Lyude: Unless something is wrong with nouveau's handling of the GPU's i2c adaptors
17:06 Lyude: I'll look a bit more into it later, it's definitely possible
17:09 karolherbst: imirkin: do you have a fermi gpu?
18:03 Lyude: imirkin: from DP 1.1a spec: "A request transaction may not end in full-completion. The Sink may reply with NACK or DEFER when not ready for full-completion. The Policy Maker must decide on the follow-up action if the Request transaction is replied with NACK or DEFER." I'd guess the default behavior of that register is NACK, which makes me think nouveau might not be handling that
18:04 Lyude: Recongnizing that it's received a NACK on the i2c adaptor I mean
18:29 karolherbst: pmoreau: didn't you have a system with a fermi GPU?
18:30 pmoreau: I have a GF100 that I can plug in.
18:30 karolherbst: ohh, would be splendid
18:30 karolherbst: mind checking out the two newest commit from here? https://github.com/karolherbst/nouveau/commits/fermi
18:30 karolherbst: it enables reclocking in a way, that the engine clocks can be changed on fermi
18:31 karolherbst: would like to know how stable that is
18:31 pmoreau: Ok
18:32 karolherbst: pmoreau: especially because yours seems to boot at the 0x3 level
18:32 pmoreau: If you say so :-)
18:33 karolherbst: mem clock is only 135MHz though :O so yeah the benefit might be minimal :/
18:35 karolherbst: pmoreau: best would be if you benchmark with pixmark_piano, because everything else is most likely memory bottlenecked and wouldn't trigger instabilities as much
19:06 imirkin: karolherbst: i do have one, it's sitting on a shelf. GF108.
19:06 imirkin: Lyude: that's eminently likely
19:06 karolherbst: imirkin: do you know if it has multiple pstates?
19:06 imirkin: karolherbst: yeah, all fermi gpu's have multiple pstates
19:06 imirkin: or rather... i don't think i've ever seen one that has only one
19:06 karolherbst: imirkin: okay, would be nice if you also add the vbios to the repository
19:07 karolherbst: and would be also nice if you test the two patches from my fermi branch
19:07 karolherbst: if you and pmoreau say it is stable enough, we should merge it because it enables engine reclocking + pcie link stuff
19:08 imirkin: karolherbst: https://people.freedesktop.org/~imirkin/traces/nvc1/
19:08 imirkin: there's a VERY good chance that that'smine
19:08 karolherbst: thanks
19:09 pmoreau: I plugged in a NVCE (I forgot I had one of those). Let's see how it performs
19:09 karolherbst: boot level 0x7
19:09 karolherbst: lucky one
19:09 karolherbst: 324MHz mem clock
19:09 imirkin: karolherbst: most fermi's boot to a middle perf level
19:09 karolherbst: pmoreaus doesn't
19:09 karolherbst: :D
19:09 imirkin: at least the low-end ones
19:09 karolherbst: yeah
19:09 karolherbst: and your mem max clock is 500MHz
19:10 karolherbst: so on your gpu reclocking would already give a lot of performance compared to mem max
19:10 karolherbst: pmoreau: and please also add the vbios of your nvce :D
19:11 pmoreau: I tried echo'ing 0f, and it just died…
19:11 karolherbst: hum
19:11 pmoreau: Let's see what the logs say
19:11 karolherbst: maybe something super stupid
19:12 imirkin: karolherbst: i doubt i'll be plugging the GF108 in soon
19:13 karolherbst: yeah, it has time
19:13 karolherbst: should be just tested before merging
19:13 karolherbst: and 4.12 would be a nice point for this
19:13 pmoreau: Nothing in the logs, sadly
19:13 karolherbst: off
19:13 karolherbst: odd
19:14 karolherbst: pmoreau: run with debugging output enabled on clk and volt and pci
19:16 karolherbst: your voltage range also seems odd: 1213000-825500
19:16 pmoreau: On 07 it performed a bit better, running for a few seconds at 7 FPS (instead of 1 at 03) before freezing)
19:16 karolherbst: mhhh
19:17 karolherbst: I think we mess up something voltage related, but then still...
19:17 karolherbst: pmoreau: are you able to setup nvidia on this machine?
19:17 pmoreau: Yes
19:17 karolherbst: awesome_tool branch and compile in root directory on nvidia
19:17 karolherbst: then execute bin/nv_cmp_volt
19:18 karolherbst: it might be that the speedo part is wrong
19:19 pmoreau: Of your Nouveau repo?
19:19 karolherbst: yeah
19:19 karolherbst: but try to get a debug log first with the options I mentioned above
19:23 karolherbst: pmoreau: I also like your definition of "a bit better" :D
19:23 pmoreau: I get some clk output, but nothing for pci or volt
19:23 karolherbst: 7 is a lot
19:23 karolherbst: huh
19:23 karolherbst: you should
19:23 karolherbst: at least there should be a line mentioning the speedo
19:23 pmoreau: Nope
19:24 pmoreau: Oh, I made a typo
19:24 pmoreau: A ',' became a '.'
19:25 pmoreau: Looking better! :-)
19:32 ladis: Hi there. Anyonone has a clue why nouveau does not expose card0-eDP-1 sysfs file once hybrid graphics is enabled in BIOS?
19:33 imirkin: ladis: probably because it's connected to your other GPU?
19:34 ladis: So it has to be bug in gnome/wayland then?
19:35 imirkin: erm... i guess i'm not 100% sure what your situation is. at this point i'm suspecting a bug in your understanding of how things work :)
19:35 ladis: Yes, that's very probable...
19:36 pmoreau: karolherbst: Still get absolutely nothing in the logs when switching to 0f. I didn’t get any useful info for 07, because it went fine this time. Maybe because I went back to 03 first before starting pixmark_piano?
19:36 ladis: With discrete graphics enabled in BIOS, nouveau is the only driver and things just work - plugging HDMI.
19:36 karolherbst: pmoreau: maybe? But it would be good if you give me the nouveau dmesg output
19:36 karolherbst: maybe something is odd in general
19:36 imirkin: ladis: which intel and nvidia gpu's do you have?
19:37 ladis: But with both nouveau and i915 present gnome tries to read eDP-1 which is not present
19:38 pmoreau: karolherbst: Will do. I went to 07 without switching back to 03 first, and no freeze yet.
19:38 imirkin: ladis: grep . /sys/class/drm/card*-*/status -- pastebin the output of that.
19:39 ladis: imirkin: http://pastebin.com/1h2FdkEe
19:39 ladis: part of log included... HDMI connected
19:40 karolherbst: pmoreau: maybe it was a random "I drive the display freeze"
19:40 imirkin: ladis: well, note that "HDMI" is a relative term
19:40 imirkin: e.g. the connector might be DP deep down inside, but someone sticks a DP -> HDMI adapter on it
19:41 karolherbst: like intel
19:41 imirkin: so anyways, it seems like card1 is the intel gpu
19:41 pmoreau: karolherbst: https://hastebin.com/xonuvimiba.go
19:41 imirkin: and card0 is the nvidia gpu
19:41 karolherbst: afaik all intel HDMI connectors are just adapters
19:41 ladis: imirkin: well it works just well without i915
19:41 imirkin: does that sound right?
19:41 ladis: yes.
19:41 imirkin: let's try this
19:42 imirkin: grep . /sys/class/drm/card*-*/modes
19:42 karolherbst: pmoreau: hum
19:42 karolherbst: pmoreau: it doesn't fit the vbios in the repository
19:42 karolherbst: well
19:42 karolherbst: or better
19:42 pmoreau: I may not have pushed that one to the repo
19:42 karolherbst: nouveaus output doesn't match what nvbios prints
19:43 ladis: imirkin: http://pastebin.com/qGVUangU
19:43 karolherbst: pmoreau: yeah, it's a different one
19:43 karolherbst: the speedo doesn't match
19:43 imirkin: ladis: i won't bother asking what you've plugged into DP-2...
19:44 imirkin: but the modes on eDP-1 appear to be getting detected correctly
19:44 imirkin: i recommend asking for more assistance in #intel-gfx
19:44 imirkin: it sounds like an issue with i915 of some sort... and/or wayland. neither of which i'm intimately familiar with.
19:45 pmoreau: karolherbst: Which GPU nvbios were you looking at?
19:45 ladis: imirkin: Only internal display and projector is present. Both 1920x1080
19:45 imirkin: well, the thing plugged in on DP-2 definitely isn't advertising a 1920x1080 resolution :)
19:45 karolherbst: pmoreau: the nvc0 one
19:46 karolherbst: there is one from you
19:46 pmoreau: I told you I plugged in a NVCE :-p (though, I agree I said in the beginning I was going to plug a NVC0)
19:46 karolherbst: ohhh right
19:46 karolherbst: nvce isn't there
19:46 karolherbst: but I asked for the vbios already for this one
19:46 ladis: imirkin: indeed :) Lets try with i915 disabled.
19:47 pmoreau: I just need to get access to the repo, and I’ll push it
19:47 karolherbst: pmoreau: you don't have any?
19:47 karolherbst: pmoreau: but odd that your GPU also boots with the lowest perf level
19:47 pmoreau: I do, but probably for an SSH key that I no longer use, or that is used on a different device
19:50 ladis: imirkin: http://pastebin.com/tKpzDAXk
19:50 imirkin: ladis: well, it's the bios that controls where things are connected internally
19:51 ladis: imirkin: first grep is without projector connected
19:51 imirkin: yeah, makes sense
19:51 ladis: imirkin: discrete graphics, so not i915 in game
19:51 imirkin: yes
19:53 ladis: Lets see what's in i915 gfx git...
19:59 pmoreau: karolherbst: Pushed
20:00 ladis: imirkin: Nothing there. Anyway, thank you for your help.
20:01 karolherbst: pmoreau: your power budget table is small, this will be easy to RE on yours :D
20:02 karolherbst: pmoreau: mhh indeed, 0x3 and 0x7 should run stable enough on nouveau
20:03 karolherbst: pmoreau: sensors prints 0V as the minimal voltage, right?
20:03 pmoreau: Yup
20:03 karolherbst: "volt: min: 0uv max: 1212500uv" this is at least wrong, but I know why, and this shouldn't affect reclocking
20:04 pmoreau: And I get "ERROR: Can't get value of subfeature in0_min: Can't read"
20:04 karolherbst: yeah obviously, cause that values is 0
20:10 imirkin: dboyan: i'm not sure if i'm making my concerns about your code clear... there's lots of "magic" involved everywhere, and it's not very well explained. also there's lots of hex values that aren't necessarily obvious what values they are in decimal. e.g. wtf is "add b32 $r4 $r2 0xc01" for? and lots of similar instances. i guess i'm looking to be able to follow a set of comments that let me understand the implementation. right now
20:10 imirkin: only a fraction of that implementation is explained.
20:11 karolherbst: pmoreau: seems like there is no support for the "Maximum voltage to be used 1150000 µV" field in the vbios, but that's also not relevant to the freeze
20:13 karolherbst: pmoreau: I've updated the fermi branch with a fix for the min/max detection, but a second one has to be written
20:13 karolherbst: pmoreau: and I have no clue why it shouldn't work on 0xf except we do something terribly wrong regarding volting or clocking
20:13 karolherbst: pmoreau: mind stresstesting 0x7 a little and try out 0xf a little later?
20:22 pmoreau: karolherbst: Ok, I can do that.
20:23 pmoreau: Do you want the output from the nv_cmp_volt?
20:23 karolherbst: yeah
20:23 pmoreau: Ok
20:33 pmoreau: karolherbst: What are the bios: OOB? out-of-bounds?
20:34 karolherbst: pmoreau: what do you mean?
20:34 karolherbst: ohh, from dmesg
20:34 pmoreau: For example "nouveau 0000:03:00.0: bios: OOB 1 14494328 14494328"
20:34 karolherbst: no clue
20:35 pmoreau: I got one as well while running nv_cmp_volt
20:36 karolherbst: seems like it
20:36 karolherbst: if (unlikely(*addr + size >= bios->size)) {
20:36 imirkin: pmoreau: yes, when a bios script tries to read something out of bounds
20:36 pmoreau: Ok
20:37 imirkin: 0xdd2a78 -- looks pretty out of bounds to me :)
20:37 karolherbst: pmoreau: you could run gdb and print the stacktrace, maybe then we figure out what causes that
20:37 karolherbst: imirkin: yeah, but not the three others
20:37 karolherbst: "bios: OOB 1 00f11900 00f11900"
20:37 karolherbst: mhh
20:37 karolherbst: maybe they too
20:37 pmoreau: Running nv_cmp_volt: https://hastebin.com/ugiyenajuw.pl
20:38 karolherbst: pmoreau: okay, so we can rule out the voltage calculation
20:39 karolherbst: maybe we wrongly set the GPIOs
20:40 karolherbst: but I doubt this as well
20:40 karolherbst: because then we would read out the voltage wrongly
20:40 karolherbst: pmoreau: mind making a trace of nvidia after you test 0xf with nouveau again and get freezes again?
20:42 pmoreau: I can try that in a bit
21:05 pmoreau: karolherbst: Still the issue with 0f; it's not just a freeze, the screen dies completely as well.
21:06 pmoreau: i.e. I get dropped to a black screen
21:16 karolherbst: mhh
21:16 karolherbst: pmoreau: mayve just the screen dies?
21:17 karolherbst: pmoreau: worth checking if you can SSH into the machine and "repair" the screen with setting a different pstate again
21:23 pmoreau: I haven't tried SSH in, but blindly setting a different pstate did not work.
21:23 pmoreau: I’ll get you a trace tomorrow
21:23 karolherbst: okay, awesome
21:52 imirkin: dboyan: i just pushed an envydis update for gk110 - it might very lightly affect your assembly
21:53 imirkin: dboyan: btw, i'd encourage you to finalize your envydis pull req as well...