02:04chillfan: what would be a suitably recent distro for nouveau testing and info gathering for reverse engineering? I don't mind so long as it doesn't use that canonical spyware really, as the install would only be used for nouveau stuff
02:08chillfan: not for hacking purposes that's not my skillset, just so I can provide some test data as I know the chip in my laptop has a lot of work left on there
03:58gnurou: rektide_: 3d on X1 is working (and no, the PMU stuff was not blocking, although it makes things more convenient). Slow currently, but once hakzsam comes with his shader scheduler you should get a nice perf boost. Reclocking is already working.
07:38hakzsam: yep, I'm working on it :)
10:33bloblo: hi, i want try lastest nouveau, you have nouveau github ? thanks
13:04chillfan: is there a possible fix for a flickering screen on a prime setup? the console *and* the xserver both flicker
14:15karolherbst: chillfan: dri3 and vsync
14:16karolherbst: chillfan: there are a few games which still manage to flicker somehow, no idea how they manage to
14:19imirkin: chillfan: flickering on the console is the intel driver, afaik. nothing to do with nouveau.
14:28chillfan: so I should blacklist that driver?
14:40chillfan: eh seems like it's little more than an annoyance anyway
14:50chillfan: nvidias linux driver seems to be lacking a lot for the mobile chip anyway heh
15:04imirkin_: the display is attached to the onboard intel chip, usually
15:04imirkin_: so any flickering is a result of that
15:09karolherbst: chillfan: you actually need a compositor with tearfree functionality
15:12chillfan: hm alright, will have a go with compton
15:16karolherbst: that poma …. he isn't serious, is he?
15:17imirkin_: it's best not to touch anything he touches
15:17karolherbst: did you check his email?
15:17karolherbst: did you check the CC list?
15:17imirkin_: the unfortunate part is that he does have legit issues
15:17imirkin_: but everything he does to resolve them is ... very annoying to the people he's trying to work with.
15:17karolherbst: be basically put a lot of nvidia engineers on CC
15:17imirkin_: yeah, i saw
15:18imirkin_: like i said - best not to touch it.
15:18imirkin_: or anything else he touches
15:20karolherbst: we need more devs to work on the userspace parts of nouveau :(
15:20imirkin_: "we need more devs" is probably enough of a comment
15:22karolherbst: well, we don't actually have to do _that_ much on the kernel side
15:22karolherbst: anyway, ben does there a lot
15:22karolherbst: and mupuf and me when we have time
15:22karolherbst: and roy
15:23karolherbst: but there is a lot more to do in userspace
15:23imirkin_: except in the one area that matters - recovery
15:23imirkin_: [in fairness, ben has done a bunch of stuff there, but he probably spends 1/20th of his time overall on that, at most]
15:25karolherbst: but the list of things we actually should do on the kernel side is rather small
15:26karolherbst: sure stability is important, but I doubt we actually would need more devs here
15:29mupuf: karolherbst: aside from PM?
15:30karolherbst: mupuf: well sure, pm is a big part, but I can think of dozens of things we should do inside mesa and not that many pm related
15:32karolherbst: if we implement the missing pm bits and increase stability, we are petty much done on the kernel side. Of course there are random things like display stuff or other things, but overall it looks pretty solid now, at least for tesla and kepler that is
15:38karolherbst: well, the PMU rework will take some time though
15:38karolherbst: and it would be really good to have the fuc llvm compiler ready by then :)
15:38karolherbst: or is it already ready?
15:39mupuf: mwk: ^^ nudge nude wink wink
15:41karolherbst: I think I will simply begin rewrite the pmu part
15:41karolherbst: less critical than gr
15:41karolherbst: and we could have a switch config=UseAwesomePMUCode=1
15:47mupuf:would say that having an interface to talk to multiple PMU versions would be better
15:47mupuf: but we need to have sort of the same way of generating the scripts
15:47mupuf: as nvidia
15:47mupuf: I mean, sort of the same ISA
15:50karolherbst: I don't plan to support both things actually
15:50karolherbst: if nvidia changes it all the time we need some kind of layer to map this anyway
15:50karolherbst: and I don't plan on writing this myself
16:49pmoreau: karolherbst: I think (I could be wrong) that most issues on the bugzilla are related to kernel issues.
16:51pmoreau: And for the "looks pretty solid now, at least for tesla and kepler", you are forgetting about all the issues with GK106 and GK107, some of which aren’t even solved by using the firmware from the blob.
16:54pmoreau: "if we implement the missing pm bits and increase stability, we are petty much done on the kernel side" vs "if we implement the missing OpenGL extensions and make the compiler better, we are pretty much done on the userspace side"
16:54pmoreau: who wins?
16:55pmoreau: (Sure, there is also Vulkan and OpenCL on the userspace side, but those are details. ;-D )
17:00karolherbst: well yeah, but I doubt that are as hard issues as all the stuff we actually need to do within userspace
17:01karolherbst: not saying it isn't important, but actually I would say in the end we will need more time on the userspace in total
19:26bloblo: hi, i have gainward gt 630 NVIDIA GF108 (0c1000a1) bios: version 70.08.ae.00.00, kernel 4.9-rc6, mesa 13.0.1-1, how i can have pstate working ?
19:26imirkin_: you can't
19:27imirkin_: not supported on fermi
19:28imirkin_: GFxxx = fermi
19:28imirkin_: GKxxx = kepler, where reclocking is supported
19:28bloblo: i am limited this setting ?: AC: core 405 MHz memory 162 MHz
19:29imirkin_: it may not be too difficult to allow core reclocking, but it's not really worth it - memory clock is so low
20:17NanoSector: heh I wonder if nouveau on a GT750M with the lowest clocks would give me any advantage over the HD 4400 in games
20:17imirkin_: NanoSector: you can't reclock?
20:17NanoSector: it hangs if I reclock memory
20:17karolherbst: NanoSector: 4.10?
20:18karolherbst: you need 4.10
20:18NanoSector: karolherbst, did you include any other kepler related fixes in 4.10 except from your branch that worked in 4.7/4.8?
20:18NanoSector: because we had tested your branch together and it didn't work
20:25NanoSector: oh boy, input went crazy with Wayland :x
20:29karolherbst: NanoSector: uhh true
20:29karolherbst: NanoSector: did you make a mmiotrace with nouveau?
20:29karolherbst: Because I would need that
20:32NanoSector: just the tiny one before it hung
20:35NanoSector: karolherbst, start mmiotrace, load nouveau, run game/thing and reclock right?
20:36NanoSector: also on default clocks nouveau does not help :x i'd say it's worse
20:39karolherbst: NanoSector: yes
20:39karolherbst: NanoSector: on low clocks it is slower than intel, yes
20:40karolherbst: NanoSector: no game needed to run though
20:40NanoSector: is on 4.8 okay? or do you want it on 4.10
20:40karolherbst: NanoSector: just reclock once to 0f
20:40karolherbst: NanoSector: mhhhh, shouldn't matter
20:40NanoSector: aight, i'll do it on 4.8
20:41NanoSector: don't really feel like recompiling a kernel right now :P
20:44karolherbst: k starting konqueror now
20:44karolherbst: things will get funny I suppose
20:45NanoSector: shit, modprobe'd nouveau and thought my system hanged, then it worked and suspended while i held the power button :'(
20:45NanoSector: mmiotrace take #2
20:45karolherbst: NanoSector: yeah, currently the modprobe command will hang, but everything should still work
20:45karolherbst: except that shell
20:46NanoSector: well it hung for a while but it worked after that
20:46NanoSector: couldn't move my pointer in the meantime
20:48karolherbst: NanoSector: that's X doing silly things
20:49NanoSector: then it worked, 10 seconds later it hung my DE
20:53karolherbst: NanoSector: try without X
20:57NanoSector: yeah tried with a TTY and that worked better
20:57NanoSector: it hung completely while reclocking to 0f
20:57NanoSector: thing is 123,9 MB large so that's promising
20:58NanoSector: 20 kb compressed :x
20:59NanoSector: noooooo did I overwrite it
21:00NanoSector: let's do it again
21:02karolherbst: imirkin_: well, running two qtwebengine based browser now, and no single freeze
21:05NanoSector:first makes a copy of said log now :x
21:07NanoSector: karolherbst, https://drive.google.com/open?id=0B2F3P3d66S-1N1lHeW1RRWdZSDA
21:08NanoSector: no problem
21:08karolherbst: now let the fun start :O
21:08NanoSector: you can add it to your log collection you've got from me, lol :P
21:09NanoSector: i still have them if you ever miss anything btw
21:09karolherbst: demmio is broken for files with spaces in the name :O
21:09NanoSector: oh the space i added, sorry
21:10NanoSector: you have a tool to decompile that in something useful?
21:10NanoSector: heh i was already wondering how the hell someone would read that :P
21:11karolherbst: something is strange
21:12karolherbst: ohh no, it is fine
21:12karolherbst: did you reclock?
21:12NanoSector: I tried putting it in 0f but it froze immediately when I entered the command
21:12karolherbst: I need that
21:13NanoSector: I let it run to a while hoping that it might still capture the mmio stuff
21:13NanoSector: *run for a while
21:13karolherbst: ssh helps
21:13karolherbst: and sync
21:13NanoSector: I don't have another device to ssh with right now ;9
21:14karolherbst: well there is some reclocking in there though, let me check
21:14NanoSector: maybe the part where it tries to put it in a higher clock? just guessing
21:16karolherbst: mupuf: any reason why we write tons of "0" into the pmu?
21:18karolherbst: NanoSector: mind booting with nouveau.debug=pmu=trace and try to fetch a dmesg from this when reclocking to 0f?
21:19imirkin_: helps to be ssh'd in from another box and running 'dmesg -w'
21:19NanoSector: karolherbst, do you mind if I take another look tomorrow or later this week? I have to go off now
21:19karolherbst: yeah, no problems
21:21NanoSector: aight, thanks so far anyway, i'll have another go at this tomorrow night
21:22karolherbst: you trace doesn't make much sense to me
21:22karolherbst: the hell
21:22NanoSector: you can PM me if you find anything
21:23karolherbst: pcie WIDTH = 4
21:24karolherbst: ohh wait
21:24karolherbst: okay, I see
21:24karolherbst: NanoSector: okay, so the reclocking parts aren't inside the trace
22:37Arbition: So, if I run the kernel parameter nouveau.runpm=0 is that enough to force the system to use discrete graphics over integrated graphics in an optimus system?
22:39imirkin_: that is enough to force nouveau to stop from auto-suspending the gpu when it's not in use
22:42Arbition: Hmm ok, so I should be able to use the DRI_PRIME=1 thing. Though when I did that just now, it has blocked something. Anyway, I'm going to reboot with runpm=0 and see if that persists
22:43imirkin_: pastebin dmesg
22:46Arbition: ok cool. runpm=0 doesn't lockup when I run glxinfo with DRI_PRIME=1 now
22:46imirkin_: probably an issue with the gpu suspend/resume then
22:47Arbition: yeah, I was in here 9 months ago or something trying to work some of that stuff out. I gave up for a while because it was acting in a manner which was not replicated by anyone else.
22:48Arbition: Running 4.9.0-rc0 at the moment
22:48imirkin_: ah ok. what gpu do you have?
22:48imirkin_: or rather, what laptop?
22:48Arbition: GK208 (730M)
22:48imirkin_: some newer laptops have been having various trouble
22:48Arbition: Lenovo t540p
22:48imirkin_: Lekensteyn: is that one of the problem laptops?
23:27Lekensteyn: imirkin_: there is a known problem with an Acer laptop (GT 750M from NanoSector) and a Lenovo IdeaPad Z510 (GT 750M), but it is a very specific issue not seen elsewhere
23:28Lekensteyn: issue is being investigated at https://bugs.acpica.org/show_bug.cgi?id=1333 (there are patches, so NanoSector could try them), but I had issues with verifying them
23:28imirkin_: Lekensteyn: what was the immediate advice given? pcie_something=off?
23:28Lekensteyn: Arbition: can you upload your acpidump somewhere?
23:29Lekensteyn: imirkin_: that pcie_port_pm=off advice could be tried here, but it seemed not to fully work (system resume still fails) when NanoSector tested it
23:29imirkin_: ah ok
23:29Arbition: Sure. Can I do it with runpm=0 or does this need to be run with default settings?
23:30Lekensteyn: I think acpi_osi="!Windows 2013" worked around the issue by completely disabling the problematic ACPI code
23:30imirkin_: Arbition: acpidump can be done anytime
23:30Lekensteyn: Arbition: if you are going to dump it somewhere, please consider https://bugs.launchpad.net/lpbugreporter/+bug/752542
23:31Lekensteyn: the script there also collects lspci (includes GPU model) and dmidecode (includes BIOS version)
23:39Arbition: Is there anything in the comment I should state, or is the attachment sufficient?
23:39imirkin_: mention that runpm is broken for you
23:43Lekensteyn: link to laptop info site could be helpful for quickly finding newer bios
23:44Lekensteyn: (manufacturer site.) Copy of BIOS version and year can also be nice
23:51Arbition: oh sorry I completed it before you said this
23:52Lekensteyn: no problem, can always look it up later
23:54Lekensteyn: ok, it does not seem to be the same problem as ACPICA bug 1333
23:55Arbition: That isn't great news
23:56Lekensteyn: do you have a dmesg of the event where it fails?
23:56Lekensteyn: without runpm=0, can you also trigger the issue by invoking "lspci"? What kernel version?
23:57Arbition: no I don't think lspci triggers it
23:57Lekensteyn: (to clarify, can you trigger a hang when you invoke "lspci" after the Nvidia GPU is runtime suspended?)
23:58Lekensteyn: runtime suspend kicks in after 5 seconds
23:58Lekensteyn: check dmesg for that