07:50 RSpliet: imirkin_: f->allWarp in emitFlow() on gk110, is that the flag used for "only jump if all warps unanimously shouldn't take the if-codepath and execute the else-path instead"?
08:11 gnurou: mmm, anyone knows if there is a way to make xserver recognize a new device which module has been inserted *after* it was started?
08:12 gnurou: i.e. I start X, run "modprobe nouveau", and "xrandr --listproviders" lists it
08:12 gnurou:discovers the joys of Optimus
08:14 karolherbst: gnurou: I do it all the time :p
08:14 karolherbst: gnurou: use DRI3
08:15 karolherbst: xrandr wont show it, but that doesnt matter
08:15 karolherbst: gnurou: https://nouveau.freedesktop.org/wiki/Optimus/ "DRI3"
08:16 karolherbst: gnurou: and if you want to unload nouveau, use this config: https://gist.github.com/karolherbst/1f1bdd1a3822df74097f
08:17 karolherbst: that was Xorg wont even claim the device
08:18 gnurou: karolherbst: mmm I think I meet all these requirements, yet the Intel driver is used even when using DRI_PRIME=1
08:18 karolherbst: with that you can rmmod nouveau even while X is running
08:18 karolherbst: gnurou: you need to tell intel to use dri3
08:18 karolherbst: see the xorg.conf
08:18 gnurou: ah, I see
08:18 gnurou: thought it would do this by default...
08:18 karolherbst: nope
08:19 karolherbst: apperantly, there are many users with issues
08:19 karolherbst: (dri3 works better here than dri2 actually)
08:19 karolherbst: ...
08:19 karolherbst: but the dummy ddx hack is really handy
08:19 gnurou: wow, I haven't messed with an Xorg config file in *ages* :)
08:19 karolherbst: :D
08:19 karolherbst: well
08:20 karolherbst: if you load nouveau at runtime, xorg claims the device immediatly
08:20 gnurou: oooh they are now using a xorg.conf.d!
08:20 karolherbst: which makes unloading it impossible
08:20 karolherbst: yeah
08:21 karolherbst: chances are that your kernel crashes when you unload nouveau, but it happens with a <1% chance
08:21 karolherbst: but at least I know why :/
08:26 gnurou: thanks, restarting X to try this...
08:27 karolherbst: well
08:27 karolherbst: do you have the dummy ddx installed
08:27 karolherbst: forgot about that, sometimes it is missing
08:28 gnurou: that was missing, thanks!
08:30 karolherbst: with that it is actually possible to switch between Prime-nouveau/bumblebee-nvidia without restarting X :3 makes things a lot easier for development on the same machine
08:30 gnurou: annnd working perfectly! thanks a lot
08:30 gnurou: interesting that DRI3 needs to be explicitly enabled
08:30 karolherbst: np
08:30 karolherbst: yeah
08:31 karolherbst: I think it got enabled later
08:31 karolherbst: but distributions default to 2
08:31 karolherbst: there is a compile flag actually
08:32 karolherbst: --with-default-dri=
08:32 karolherbst: and some distribution set this to 2
08:35 gnurou: mm? suddently it ceased working
08:36 karolherbst: mhh odd
08:36 gnurou: ah, that's because nouveau failed to probe my chip after I inserted/removed the proprietary driver
08:36 karolherbst: ahhh
08:37 karolherbst: pro tip: install bbswitch
08:37 karolherbst: and turn off/on the gpu manually
08:38 gnurou: ah, seems like things went south after bbswitch got inserted (probably by optirun)
08:38 karolherbst: ohh
08:38 karolherbst: yeah
08:38 gnurou: that should be easy to handle
08:38 karolherbst: it turns the gpu off
08:38 karolherbst: /proc/acpi/bbswitch
08:38 karolherbst: echo ON or OFF
08:39 karolherbst: nouveau only powers on the gpu for me the first time
08:39 karolherbst: never really investigated why, but the saved pci stuff changed later
08:40 gnurou: again, problem solved
08:40 gnurou: now I feel guilty
08:40 karolherbst: why :D
08:40 gnurou: I wish we were as fast to answer your questions >_<
08:40 karolherbst: :D
08:40 karolherbst: I should have created a wiki page for that
08:41 karolherbst: "pro tips for nouveau develpment on prime setups " :p
08:41 gnurou: you should open a github issue tracker for me, and only allow yourself to make 1 post every second week
08:41 karolherbst: :D
08:42 karolherbst: well, at least you got the gp100 firmware out pretty fast, allthough it is pretty much useless too :D
08:43 gnurou: yeah, I may just as well posted the output of /dev/random, nobody would have noticed
08:44 karolherbst: *will
08:44 gnurou: well except skeggsb
08:44 karolherbst: ohh, I doubt that :D
08:44 karolherbst: well, no clue what he has anyway
08:44 karolherbst: so maybe he would have
08:45 karolherbst: gnurou: anyhow, did you get any reply rearding the thanks from my side regarding the super usefull vpstate table :p
08:46 gnurou: thanks anyway, I don't know what more I can do to make the Kepler reclocking advance, but I will wave my whip next week
08:46 karolherbst: well
08:46 gnurou: I made sure to transmit your feelings on the topic... with my own words
08:46 karolherbst: :D
08:47 karolherbst: so something like "we knew it all along" became "many thanks for the documentation, so that we could verify our theories and guesses on that topic" :p
08:52 gnurou: the slide was actually towards the opposite end of the courtesy spectrum
08:57 karolherbst: :D
08:58 karolherbst: XDC will be much fun, if we have time, we could even inclue benchmarks where we are pertty close to nvidia :p :D
08:58 karolherbst: but I doubt this is the general idea of the nouveau XDC talk
08:58 gnurou: by all means, do it
08:59 karolherbst: allthough... showing off with working reclocking might fit actually
09:06 karolherbst: gnurou: but you know what? I doubt they really looked into the stuff I wrote, because that should have at least create one big wtf moment, especially if they think that giving us the vpstate table is "enough" for us
09:06 karolherbst: or they think, this is clearly what we need now
09:07 karolherbst: because thats like the very core of gpu boost as far as I can understand all that stuff related to turbo boost
09:07 karolherbst: *gpu boost
09:08 karolherbst: well, + the "max" entries in the other table, but I wont ask for trivial stuff like that :p
09:22 karolherbst: gnurou: actually, releasing the vpstate docs caused _more_ work for me now, because I have to rename stuff :/
09:22 karolherbst: :D
10:23 Tom^: karolherbst: you were right cs:go 64bit client fixed bunch of stuff
10:24 Tom^: now im only facing a tiny issue where a texture on the arms dissapears after a while but that i can live with :p
10:31 Lekensteyn: What is the appropriate category on bugs.fdo for DRM/nouveau bugs? There is only a Xorg Driver/nouveau and DRI DRM/other (even the new amdgpu got its own category :/)
10:31 karolherbst: Tom^: yay
10:32 karolherbst: Lekensteyn: https://nouveau.freedesktop.org/wiki/Bugs/
10:33 Lekensteyn: karolherbst: thanks, and applied the category :)
13:33 Tom^: this is boring, no issues in all my games. and nouveau simply just works :(
13:33 Tom^: what todo!
13:35 inglor: karolherbst: the latest HEAD of the stable branch with the patch for the sensors = reduced the power about 1W \o/
13:35 inglor: thanks!
13:36 karolherbst: wut
13:36 karolherbst: it shouldnt
13:36 karolherbst: :D
13:36 karolherbst: Tom^: :D
13:36 karolherbst: Tom^: buy games?
13:37 karolherbst: inglor: I guess this is just random
13:37 karolherbst: inglor: also, the higher the temperature of the gpu, the higher the power consumption
13:38 inglor: well one of the cores came down to 14.96W but temp still @ the forties..
13:38 inglor: this is with the nvapoke -c1 0x20200 0x60 27722455 in place
13:38 karolherbst: yeah, well
13:38 karolherbst: the more idle your gpu, the higher the power savings too
13:39 inglor: yeah maybe I should start using the i7 gpu :D
13:39 inglor: then can become really idle
13:39 inglor: (but then again then it's losing the point of a dedicated gpu..)
13:57 Tom^: karolherbst: hm shouldnt the * in the boost file be after the entries a bit like the pstate file?
13:58 Tom^: karolherbst: so they are uh aesthetically similiar :p
13:58 Calinou: I just donated to Mesamatrix :)
14:03 imirkin: gnurou: fwiw my recommendation is that unless you're looking to flip between nouveau and nvidia, to not use bumblebee at all.
14:04 imirkin: Tom^: get different games. the stuff i'm procrastinating debugging are things that just hang my whole system =/
14:04 Tom^: heh those sucks
14:05 imirkin: extremely.
14:05 imirkin: esp without a separate for-debug-only system
14:06 Tom^: get a rpi and a monitor :D
14:06 imirkin: ... and plug an nvidia gpu into it?
14:06 Tom^: well i thought more you needed a system to netconsole / ssh but fair enough.
14:07 imirkin: i want a system that i don't care if it hangs and reboots
14:08 Tom^: i wonder how well it would work to have two nvidia cards in the system non sli, and passthrough the second in kvm and run linux and nouveau on that and debug
14:08 imirkin: i have 3 cards :)
14:09 imirkin: i've thought about pushing stuff through to kvm
14:09 imirkin: but haven't gotten that past the thought stages
14:09 Tom^: its an interesting concept atleast if it works
14:09 imirkin: i have a GK208, GT215, and NV34 plugged in right now :)
14:15 inglor: imirkin: I hope someone else pays the electric bill ;)
14:16 imirkin: RSpliet: tbh i have no clue what allWarp does. i don't think it's ever set (by nouveau). pretty sure it's not what you said - for that nvidia generally does a "vote" to determine whether everyone has the same value for the predicate.
14:16 imirkin: inglor: meh ... they're not super-powerful gpu's
14:16 imirkin: the a/c tends to dominate my power bill
14:16 Tom^: i bet my 780ti wastes more power then all of your three combined.
14:18 inglor: probably my 690 is more than your three combined..
14:19 imirkin: seems eminently likely
14:19 imirkin: the GT215 is actually semi-beefy - it's a GT 240 with GDDR5 vram, but ... not in comparison to actual beefy gpu's :)
14:21 karolherbst: Tom^: huh, why?
14:21 karolherbst: Tom^: :D
14:21 imirkin: Tom^: btw, in re "what to do", now you can enjoy playing the various games :)
14:22 imirkin: [reminds me of the world of warcraft south park...]
14:24 Tom^: imirkin: haha
14:24 Tom^: karolherbst: oh it itches my OCD
14:25 Tom^: karolherbst: http://i.imgur.com/qSFmokN.png see! im going insane.
14:25 karolherbst: start a petition if that's so important for you :p
14:25 Tom^: haha
14:25 karolherbst: well having the * in front is the better design anyway
14:25 karolherbst: imagine having checkboxes _after_ the sentence
14:30 Tom^: karolherbst: https://www.change.org/p/karolherbst-unified-design-of-pstate-and-boost-file-in-nouveau
14:30 karolherbst: ....
14:31 karolherbst: yeah well, I won't care anyway :p
14:31 Tom^: =D =D
14:31 karolherbst: 100...
14:31 karolherbst: funny
14:31 karolherbst: maybe more like 100.000
14:32 karolherbst: you have to expect that 95% being only "followers", and those I ignore anyway
14:33 inglor: if you get more than 5 signs I will sign as well!
14:33 karolherbst: like there are only bs petitions on that site...
14:33 inglor: I will even suggest a patch to fix that :D
14:33 Tom^: karolherbst: haha i googled "create free petition" or similiar
14:34 inglor: Tom^: I wanted to do the same for a joke for a friend
14:34 inglor: but almost all of them want paypal and email
14:34 inglor: :/
14:34 karolherbst: :D
14:34 karolherbst: yeah well, they have to make money somehow
14:38 karolherbst: mupuf: do you think this patch makes sense at all? https://github.com/karolherbst/nouveau/commit/774dd8d7c31bca61af63ecfae747d34c073434ba
14:38 karolherbst: mupuf: I could also just get the last cstate in the list and get the baseclock domain clock out of that
14:38 karolherbst: *vpstate now anyway
14:39 karolherbst: but I guess this is a cleaner design, because it removes the for loop we would need without that
15:48 imirkin: Lekensteyn: thanks for doing the analysis. i guess we were both right - the hdmi audio device does come up a lot, but hardly always. and never with _PR3 (or at least not sufficiently often)
15:48 imirkin: Lekensteyn: you can consider my objection lifted
15:52 imirkin: Lekensteyn: one small suggestion, if it's easy, detect the situation where you're breaking runpm, and notify about it. it's pretty hard to tell why runpm isn't working, and this would be a nice simplification. dunno if it's easy though.
15:53 Lekensteyn: imirkin: the user can tell this my checking the runtime_status and runtime_usage fields in sysfs
15:53 imirkin: that tells them *why* it's not suspending?
15:53 Lekensteyn: in the case of PR3, it is because the pcieport is busy and cannot suspend
15:53 Lekensteyn: in other cases, it should always suspend using the DSM method
15:54 imirkin: what will runtime_status/runtime_usage say?
15:54 imirkin: just "i'm not working, and i won't tell you why", right?
15:54 Lekensteyn: if runtime_usage drops to 0, then runtime_status might show "suspended" if "control" is set to auto (done by default in nouveau)
15:54 Lekensteyn: and starting with (probably) 4.8, this will also be the case for the pcieport devices
15:55 imirkin: my point is, most users aren't experts in runpm
15:55 Lekensteyn: unfortunately it is a bit harder to track down why the runtime_usage count might be non-zero
15:55 Lekensteyn: right
15:55 imirkin: hence my suggestion for the print saying "i'm breaking your shit"
15:55 Lekensteyn: btw, are you considering the case where an audio device is present?
15:55 imirkin: yes
15:56 imirkin: you didn't find one in your db, but that's hardly exhaustive
15:56 Lekensteyn: it could probably be detected while nouveau is suspending, check the runtime usage count of the audio client (registered via switcheroo)
15:56 Lekensteyn: and print a warning if this is non-zero
15:57 imirkin: anyways, if it's easy, i'd recommend doing it
15:57 karolherbst: but that's a really rare corner case, isn'T it?
15:57 imirkin: since it'll make users' life easier
15:57 imirkin: karolherbst: hard to tell - Lekensteyn's analysis only saw 20 examples
15:57 karolherbst: I mean
15:57 karolherbst: hdmi audio in use, but not the nvidia gpu
15:57 imirkin: karolherbst: from the sounds of it, it's "audio subfunction exists"
15:57 karolherbst: that would mean I plug an audio system on the nvidia gpu on the hdmi port
15:58 imirkin: not "audio is in use"
15:58 karolherbst: ahhh
15:58 karolherbst: I see
15:58 karolherbst: mhhh
15:58 imirkin: so either your setup hits it or doesn't, depending on decisions the platform integrators made
15:58 Lekensteyn: let me see if the switcheroo infrastructure allows me to get the audio client
15:58 karolherbst: I think the proper fix would be to unregister the audio subfunction from alsa and suspend completly
15:58 karolherbst: or is that, what you plan?
15:59 Lekensteyn: I think it seemed more logical not to suspend when the audio device is busy (e.g. playing hdmi audio)
15:59 karolherbst: Lekensteyn: read again^^
16:00 imirkin: Lekensteyn: agreed
16:00 imirkin: Lekensteyn: actually i'm not 100% sure nouveau will allow you to play hdmi audio without a video signal
16:00 imirkin: i believe it's technically possible, but in practice it's a sub-usecase of a sub-usecase
16:00 Lekensteyn: karolherbst: I read it again, what is the point? Removing a device from alsa will result in nobody managing the device
16:01 karolherbst: will the nvidia gpu suspend if the display goes into suspend mode except audio?
16:01 Lekensteyn: I read the HDMI spec, but it seems that a video signal is mandatory for the audio to function
16:01 imirkin: if a link is up, nouveau shouldn't suspend it
16:01 karolherbst: Lekensteyn: yeah well. How much sense does it make to have the gpu suspended, but a display with audio system plugged in playing audio, when the display isn't in use
16:01 Lekensteyn: or, it suggests that the bandwidth available for audio depends on the clock/bandwidth for video
16:01 karolherbst: and the only case this happens is, when the link is down anyway
16:01 imirkin: although ... if the crtc isn't going, i think it will
16:01 imirkin: since you might have a monitor plugged in but not be using it
16:01 karolherbst: right
16:02 karolherbst: but can you use the displays audio in that case?
16:02 karolherbst: or are there audio only HDMI devices?
16:02 imirkin: karolherbst: i think you have to have a dummy video signal if you want that
16:03 imirkin: and i don't think nouveau supports creating such a dummy signal
16:03 karolherbst: anyway, I don't see the use case for this
16:03 imirkin: karolherbst: audio receiver
16:03 karolherbst: so audio only hdmi devices?
16:04 imirkin: yes. although technically they'd have to support video as well
16:04 imirkin: just wouldn't have to do antyhign with that video
16:04 karolherbst: mhhh
16:04 imirkin: i believe they come up as a regular ol' monitor as far as the video card is concerned
16:04 karolherbst: if I would have such a device I could have at least check how mac os x does in that situation, sadly I don't
16:04 imirkin: there might be an EDID bit that indicates they're audio-only, dunno
16:05 karolherbst: Lekensteyn: you know what I would do? Unregister the audio device when video goes into suspend and wait for user to complain, that they actually need this use case, because I am sure it doesn't exist at all
16:05 karolherbst: anyway, you won't connect an audio system via hdmi but S/PDIF
16:06 karolherbst: and also not on your gpu
16:06 imirkin: most laptops don't have a S/PDIF output
16:06 karolherbst: breaking suspend is worse than supporting audio only hdmi is good for in my opinion
16:06 imirkin: but most laptops *do* have HDMI/DP outputs
16:08 karolherbst: mhh right, didn't thought about that, because like every laptop of mine had at least one S/PDIF :/
16:08 Lekensteyn: I wonder how radeon/i915 handles this stuff
16:08 karolherbst: well
16:08 karolherbst: it fact it shouldn't matter with a proper design
16:08 karolherbst: because
16:08 karolherbst: if hdmi is in use the ref count goes up on the subdevice
16:08 imirkin: Lekensteyn: i believe "poorly"
16:09 karolherbst: and the parent device only goes into suspend if the parent has no use, and all its subdevs
16:10 Lekensteyn: the parent device is the pcie port, the subdevices are video and audio functions of the nvidia device
16:10 karolherbst: I think hacking around for that in alsa or nouveau is just a really bad solution to this problem
16:10 karolherbst: Lekensteyn: so the audio isn't a subdevice of the gpu?
16:10 Lekensteyn: have you seen Lukas's post about vga switcheroo vs audio?
16:10 karolherbst: not yet
16:10 Lekensteyn: unfortunately no :(
16:10 karolherbst: :/
16:10 karolherbst: Lekensteyn: "[Nouveau] vga_switcheroo audio runpm"?
16:11 imirkin: Lekensteyn: anyways, my main goal here is to reduce the situation where people come here and say "my gpu isn't autosuspending", and me being "uhhh, no clue why"
16:11 Lekensteyn: l1k basically proposes to use (a not yet merged) "device links" functionality to make the video device the "supplier" (of power) and the audio device a "consumer"
16:11 Lekensteyn: yes tht one
16:12 Lekensteyn: imirkin: I would always suggest sudo sh -c 'echo 1 > /sys/bus/pci/devices/0000:01:00.1/remove'
16:12 karolherbst: mhhhh
16:12 Lekensteyn: my main monitor (connected via miniDP anyway) does not even have hdmi audio, so no functionality is lost
16:12 Lekensteyn: not ideal, but it is a workaround
16:13 karolherbst: this really should be implemented in the kdev runpm area and not in the drivers :/
16:14 Lekensteyn: what exactly? The dependency between two PCI functions?
16:14 karolherbst: yeah
16:14 karolherbst: if it is the same device, but reported as two, then this information should be known on a deeper layer
16:15 karolherbst: and if one of those reported ones is unused but the other not, no suspend
16:15 karolherbst: but ...
16:16 karolherbst: somehow the kernel would have to detect such dependencies. Allthough the audio driver could tell it
16:17 karolherbst: but I guess that's also the idea of the device links
16:19 Lekensteyn: device links are a generic idea, but if PCI somehow can somehow treat multi-function PCI devices in an automatic way that would also be great
16:20 Lekensteyn: currently reading through the PCI specs if I can find something on this
16:20 karolherbst: yeah, it would be much better if we could detect this out of the pci devices directly without needing to detect that in the drivers
16:21 karolherbst: but isn't the gpu at like 01:00.0 and the audio device at 01:00.1?
16:21 karolherbst: or would the audio be at 02:00.0?
16:21 karolherbst: mhhh
16:21 karolherbst: I don't have 02:00.0, but 03:00.0
16:22 Lekensteyn: the audio is a subfunction at .1 (video is at .0 indeed)
16:22 karolherbst: ahh okay
16:22 karolherbst: at least something
16:22 Lekensteyn: and if you happen to have a separate bus or device ID, then it is probably a separate device
16:23 karolherbst: so the topology is somehow there already
16:25 karolherbst: for me "01:00.0" is a subdev of 00:01.0 anyway
16:26 karolherbst: Lekensteyn: can you check the output of "ls -lah /sys/bus/pci/devices" ?
16:26 Lekensteyn: yes, 00:01.0 is the pcie port
16:26 Lekensteyn: you can see the topology with lspci -tvv
16:26 karolherbst: ahhh
16:26 karolherbst: can I see your output of tvv?
16:27 Lekensteyn: http://sprunge.us/YLGG (also added -nn to lspci)
16:27 karolherbst: ohh you don't have an audio thing...
16:28 karolherbst: funny that tvv doesn't show the "00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller"
16:28 karolherbst: ohh
16:28 karolherbst: it always removes the controller
16:28 karolherbst: ...
16:28 karolherbst: yeah well
16:28 Lekensteyn: I do have the audio thing if I runtime resume, remove and rescan (and keep the pcie port non-suspended while doing that)
16:28 karolherbst: ahh nice
16:29 karolherbst: would be interessting to know how it looks like in that case
16:29 karolherbst: Lekensteyn: "echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/rescan" is enough?
16:31 Lekensteyn: no, remove eis needed first, see https://bugs.freedesktop.org/show_bug.cgi?id=75985
16:33 karolherbst: mhhh
16:33 karolherbst: why do I remove my nvidia gpu while it is turned off
16:33 karolherbst: ....
16:33 Lekensteyn: this is my lspci -xxxxnnvvv when booting in discrete-only mode http://sprunge.us/bUhH (tip: you can use lspci -F lspci.txt ... to read it)
16:33 Lekensteyn: euh
16:33 Lekensteyn: removing while it is off with nouveau should work?
16:34 karolherbst: yeah well, without nouveau
16:34 Lekensteyn: oh, bbswitch?
16:34 karolherbst: can't handle the situation
16:35 karolherbst: https://gist.github.com/karolherbst/9f5f6178fbef947f81eae882b8a5fc3f
16:35 karolherbst: would have to make the acpi call by hand or something
16:35 karolherbst: or I just remove those pci calls
16:36 Lekensteyn: weird formatting. If you run kernel 4.6 or newer with acpi debugger enabled, you can also use "acpidbg" in the kernel tools tree
16:36 karolherbst: Lekensteyn: okay, both devices are bound to 01
16:36 karolherbst: not 01.00 as I would have thought
16:36 karolherbst: but maybe they are
16:36 Lekensteyn: after executing "acpidbg" you can execute something like "Eval \_SB.PCI ..." (not sure if it handles arguments though)
16:36 karolherbst: and lspci only prints it wierd
16:36 karolherbst: yeah, I would need to pass arguments
16:37 Lekensteyn: not 01:00.0 and 01:00.1? can you post the output?
16:37 karolherbst: nope
16:37 karolherbst: https://gist.github.com/karolherbst/cb93d7aa6a25d36edcac20bbbbfef09f
16:37 karolherbst: I mean, their parent is 01
16:38 Lekensteyn: that seems to work?
16:38 Lekensteyn: or well, that is what I currently expect
16:38 karolherbst: so the audio chip isn't a chile of 00:01.0, but 01: indeed
16:38 Lekensteyn: 01 is the shared bus id
16:39 karolherbst: maybe that lspci outout is just silly and tries to visualize smart
16:39 karolherbst: that's why I asked for that ls -la output :p
16:39 Lekensteyn: I think it should be read as child of 00:01.0, bus 01 with subdevices 00.0 and 00.1
16:39 karolherbst: make that ls call and we will know for sure
16:39 Lekensteyn: see also the top level [0000:00] (domain 0000, bus 00)
16:42 karolherbst: 97
16:43 karolherbst: ...
16:43 karolherbst: guess I have to reboot
16:51 karolherbst: Lekensteyn: okay, so bbswitch cant handle it, when the pci device gets removed
16:51 Lekensteyn: ah right
16:51 Lekensteyn: indeed it should not be done
16:52 Lekensteyn: bbswitch keeps a struct pci_dev * around, but that is invalidated when you remove it..
16:52 karolherbst: right
16:52 Lekensteyn: I have a branch where I turn bbswitch into a pci device driver so it is basically nouveau without video handling
16:53 Lekensteyn: not finished yet since I want to focus on nouveau first
16:53 karolherbst: mhh
16:53 karolherbst: can it be loaded alongside nouveau in that case
16:53 Lekensteyn: yes, no problem
16:53 karolherbst: nice
16:53 Lekensteyn: oh
16:54 Lekensteyn: the new version?
16:54 karolherbst: yeah
16:54 Lekensteyn: only if it is ON
16:54 karolherbst: huh
16:54 Lekensteyn: if it is off, then it will be claimed (I think it is a nice feature)
16:54 karolherbst: ahh okay
16:54 karolherbst: then it is fine
16:54 karolherbst: I dont have nouveau loaded while the gpu is off
16:54 karolherbst: usually
16:55 Lekensteyn: one pain point at the moment is to provide backwards compatibility via the /proc/acpi/bbswitch interface
16:55 Lekensteyn: the new pci device works best when using the bind, unbind (and maybe new_id) interfaces in sysfs
16:57 karolherbst: well, I dont have any nvidia audio device no matter how hard I try
16:58 karolherbst: still I have no 02:00 device at all+
16:58 Lekensteyn: but you do have an hdmi port? What laptop do you have?
16:58 karolherbst: all my ports are on intel
16:59 Lekensteyn: ... well then it makes sense that you cannot get an audio function :P
16:59 karolherbst: clevo p150sm or something like that
16:59 karolherbst: :D
16:59 karolherbst: well, the device could be still there
16:59 karolherbst: in the nvidia vbios I also have 10 connectors and one signal thing
17:00 karolherbst: and in xrandr I have on intel already 7 ports :D
17:00 Lekensteyn: insane :p
17:00 karolherbst: and nouveau really treats my gpu as if it had displays partly
17:01 karolherbst: fun fact, allthough my display+ is connected via a DVI to miniDP adapter, it is listed under HDMI1
17:02 karolherbst: not DP1 or DP2 as you might would think
17:03 Lekensteyn: euhh, parsing error?
17:03 karolherbst: no clue
17:05 karolherbst: Lekensteyn: maybe you know this
17:06 Lekensteyn: dunno how nouveau parses this information
17:07 karolherbst: Lekensteyn: any ida what PX5.0 is
17:08 Lekensteyn: Power Express?
17:08 Lekensteyn: AMD's hybrid graphics solution
17:08 Lekensteyn: (muxless)
17:08 karolherbst: ahh
17:09 karolherbst: because in my vbios it is called+ PX 5.0 and there is a BACO and another mode
17:10 karolherbst: well BACO is a mode where the bus is still active, even when the gpu should be turned off (to enable temp readings and stuff)
17:10 Lekensteyn: BACO is an abbreviation of BACON
17:11 karolherbst: sure
17:12 Lekensteyn: nvm not sure, maybe I have read too many specs today
17:36 Lekensteyn: karolherbst: where did you see PX 5.0 btw? In the vbios of nvidia..?
17:36 Lekensteyn: or in ACPI?
17:40 karolherbst: uefi
18:03 t-ask: hi, how yould I determine GPU temp again?
18:05 imirkin: sensors
18:07 t-ask: I think texture issue is better today, CPU is only 3ß-50% running with all threads
18:07 t-ask: temp: 62Ĉ
18:09 t-ask: bump mapping resolutions still looks like lower resolution.
18:43 t-ask: https://github.com/iXit/Mesa-3D/issues/224#issuecomment-233144232
18:46 optraz: hi, when i run optirun glxgears -info
18:46 optraz: i got the followings
18:46 optraz: [ 1107.643951] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Unknown chipset: NV117
18:46 optraz: [ 1107.643969] [ERROR]Aborting because fallback start is disabled.
18:46 optraz: anyone can help here?
18:48 imirkin: optraz: what's your goal?
18:48 imirkin: (whatever that is, chances are using optirun is your first mistake)
18:50 optraz: this new laptop (which i got today) has two vga, the intel and nvidia and i woudl like to use the nvidia vga
18:50 imirkin: vga like "db-15 vga port", or vga like "video graphics adapter"
18:51 optraz: well, i just want to use the 3d driver.
18:51 optraz: right now it is using intel vga which is very slow in games
18:52 imirkin: either way, without reclocking, chances are that your intel gpu will be just as fast as the nvidia gpu. so your choices are to load nouveau and let it auto-suspend the gpu (so you get the powersavings), or deal with one of the ways to get the nvidia blob working in an optimus setup
18:52 imirkin: if you really want to get nouveau going so that you can use it for offloading, start by reading https://nouveau.freedesktop.org/wiki/Optimus/
18:53 imirkin: (note - you do not have a hardware mux, so ignore those bits)
18:54 optraz: chances are that your intel gpu will be just as fast as the nvidia gpu. // i have not try the nvidia gpu, so i cannot tell you if this is the case.
18:54 optraz: load nouveau // yes, module nouveau is loaded i believe
18:54 optraz: yes, it does
19:02 optraz: An updated graphic stack (Kernel, xserver and mesa).
19:02 optraz: KMS drivers for both GPUs loaded.
19:02 optraz: DDX drivers for both GPUs loaded.
19:02 optraz: what are the equivalent package name in debian?
19:03 Lekensteyn: KMS is the nouveau kernel module (ok)
19:03 imirkin: the nouveau ddx does not support your GPU anyways, and with DRI3 you don't even need a DDX in the first place
19:04 optraz: imirkin: how do you mean does not support my gpu?
19:05 Lekensteyn: the latest maxwell cards are not supported by the nouveau DDX driver (xserver-xorg-video-nouveau)
19:06 Lekensteyn: you have to use xserver-xorg-video-modesetting instead
19:06 imirkin: ... which is built into xorg
19:06 imirkin: although for all i know it might be distributed as a separate package by your distro of choice
19:06 Lekensteyn: ...but since we are talking about debian, we have split packages.
19:06 imirkin:doesn't do distro support
19:07 Lekensteyn: oh, now debian has merged it into xserver-xorg-core
19:07 Lekensteyn: (in stretch and sid, not wheezy stable)
19:07 optraz: so i have xserver-xorg-core and xserver-xorg-video-nouveau install
19:08 imirkin: and that's why i don't do distro support :)
19:10 imirkin: karolherbst: if you get a chance, mind testing https://patchwork.freedesktop.org/patch/99103/ on your kepler gpu?
19:11 t-ask: Looks like not setting "thread_submit=false" hides all NPC names. Setting it to flase, shows all names even if covered by wall.
19:12 imirkin: t-ask: i think you want to be reporting this stuff in #d3d9
19:12 t-ask: yes, I'm experimenting a bit more and then I add this to the issue report
19:13 imirkin: t-ask: nothing you've provided indicates there's any bug in nouveau
19:13 t-ask: What I did I patched the latest nouveau patch of KArol
19:14 imirkin: hakzsam: if you're around, check https://patchwork.freedesktop.org/patch/99103/ on your fermi (using the test i refer to in that patch)
19:14 t-ask: new kernel version and newest nouve git
19:34 t-ask: How to determine the Nvidia VideoPciDeviceId?
19:35 Lekensteyn: t-ask: don't know the context, but you can see the numeric device id using lspci -nnd10de:
19:39 t-ask: SO I assume the first number is the vendorID NVIDIA Corporation GK110B [GeForce GTX 780 Ti] [10de:100a] (rev a1)
19:40 imirkin: 10de is the vendor id, 100a is the device id
19:43 t-ask: ahh, Segmentation fault (core dumped)
19:47 Lekensteyn: imirkin: I was mistaken with the year btw, the BIOS cutoff date for using _PR3 in Linux is not 2013 (Windows 8) but >= 2015 (Windows 10)
19:48 Lekensteyn: officially 2013 should also be working, but the Linux PCI devs seem conservative here
19:55 t-ask: I guess this si d3d9 related https://pastee.org/e2qz3
19:56 imirkin: i'd definitely start with that.
20:12 TA5K: Slowly I think the "dx9single" option of GW2 is improving graphics quality as it should be.
20:15 TA5K: ok, NO .)
20:46 karolherbst: imirkin: do you still need somebody to test this
20:50 karolherbst: skeggsb: yeah, I think I will change my code to follow at least the nvkm_clk_tstate idea, because it makes actually more sense than what I do
20:51 karolherbst: in the end we should also save the current voltage and only change that, same as the temperature
20:51 imirkin: karolherbst: would be great, yeah. on SM30 and SM20
20:51 imirkin: i guess you only have SM30 at hand
20:52 karolherbst: I also have my mcp79
20:52 karolherbst: no idea if thats sm20
20:52 imirkin: don't worry about that - only affects fermi+
20:52 imirkin: SM20 = fermi
20:52 karolherbst: so sm20 is fermi
20:52 karolherbst: k
20:52 imirkin: SM30 = kepler1
20:52 imirkin: SM35 = kepler2
20:52 imirkin: SM50 = maxwell
20:52 imirkin: SM60 = pascal
20:52 karolherbst: yeah, the last things I knew
20:52 imirkin: SM1x = teslas
20:53 karolherbst: I wasnt sure about below sm30
20:54 karolherbst: I hope I will be finished with the reclocking stuff tomorrow :/ though I highly doubt ben will pull it for 4.8 and pulling it partially doesnt make much sense
20:54 imirkin: anyways, i only have a GK208 plugged in, so i can only test SM35. pretty sure it'll work the same on SM30, but worth checking
20:54 karolherbst: except some minor things, which wont change a thing
20:54 imirkin: SM20 is the bigger question mark, but ... should work ;)
20:54 karolherbst: :D
20:55 imirkin: [famous last words]
20:55 karolherbst: well
20:55 karolherbst: will anybody care before reclocking works on fermi
20:55 imirkin: when pbo downloads break - i assume so :)
20:55 karolherbst: ohh right
20:55 karolherbst: thats pretty basic functionality
20:56 imirkin: besides, i regard any sort of breakage to be serious for kepler and below
20:57 imirkin: or at least worth understanding
20:57 karolherbst: right
20:57 Yoshimo: what is this SM stuff about ?
20:57 karolherbst: its maxwell2 we dont care much about :p
20:57 karolherbst: shader model
20:57 imirkin: karolherbst: dunno about 'we', but definitely 'i'
20:58 karolherbst: :p
20:58 karolherbst: right
20:58 karolherbst: will be fun
20:58 imirkin: and sadly, maxwell1 also falls into that group. i might change my mind if we get reclocking going on it.
20:58 karolherbst: okay, so what does your patch change
20:58 imirkin: but at least i feel bad about ignoring maxwell1 :)
20:58 karolherbst: yeah :D you should
20:59 karolherbst: well
20:59 karolherbst: reclockings works on maxwell1
20:59 karolherbst: :p
20:59 imirkin: mem reclock?
20:59 karolherbst: and also on maxwell2
20:59 karolherbst: yes
20:59 imirkin: really?
20:59 karolherbst: yes
20:59 imirkin: i was unaware
20:59 karolherbst: :D
20:59 karolherbst: it is the same as kepler
20:59 karolherbst: imirkin: this is the needed patch: https://github.com/karolherbst/nouveau/commit/3bd7ebb11cd0a329dc63c4403a3241e2858bd835
20:59 imirkin: so ... GM10x reclocking fully works on your branch? (or at least as well as kepler)?
20:59 karolherbst: if I would fix it
20:59 karolherbst: ...
20:59 karolherbst: :D
21:00 karolherbst: yeah
21:00 imirkin: i thought you only did core
21:00 karolherbst: there are little differences, but there are also differences between kepler cards
21:00 karolherbst: look at the patch
21:00 imirkin: ok, but not in the stable_reclocking_v5 or whatever
21:00 karolherbst: no, but that maxwell_reclocking branch +is based on it
21:01 karolherbst: and only contains this
21:01 karolherbst: and a cleanup patch
21:01 karolherbst: so basically it just works
21:01 karolherbst: and I think ben would merge it too
21:01 imirkin: ok
21:01 karolherbst: ... yeah, I try to get this merged in 4.9 then
21:01 imirkin: you should try to get people to test it
21:01 karolherbst: I already did
21:01 imirkin: i've been telling people there was no GM10x reclocking
21:02 karolherbst: huh, I am telling that it works for 3 or 4 months already :P
21:02 karolherbst: :O
21:02 karolherbst: the patch is from end of february
21:02 imirkin: i guess i'm behind the times
21:02 karolherbst: well
21:02 karolherbst: those 4 cards
21:03 imirkin: optraz: once you get prime going on your setup, might want to check karol's repo out - should help you achieve higher gpu performance levels.
21:03 imirkin: karolherbst: anwyays, for that patch, just run the one test i reference in the comments
21:06 karolherbst: imirkin: I pushed the maxwell cards on the kepler branch too now
21:07 karolherbst: imirkin: well, it passes without and with the patch
21:08 imirkin: karolherbst: ok thanks for checking
21:08 imirkin: now just have to get some sucker with a fermi...
21:11 karolherbst: well at least I know that pascal reclocking wont work easily because a lot of display stuff got moved around and the SEQ scripts are competly different :/
21:12 imirkin: "yay"?
21:12 karolherbst: mupuf: also, it would be nice if a maxwell2 gpu would be in reator, I might want to try some things out on that one
21:14 karolherbst: well, at least pascal will be a lot of fun
21:15 orbea: karolherbst: is this still useful for your stable reclocking branch? https://github.com/karolherbst/nouveau/commit/ad52418a53a8196605650e38829c01989ac7e0f8
21:16 karolherbst: well, this is usefull if you want to get the right value out of the power sensor
21:16 orbea: right
22:15 imirkin: skeggsb: any suggestions on filling http://hastebin.com/xuvodovaga.scala >
22:15 imirkin: skeggsb: totals are easy, do we have a way to get the other stuff?