04:03 koz_: I have a two-monitor setup (1920 x 1080) with DRI3, NvBoost=2 and reclock state 15. I suspect I might be overheating my card, because when I try to start X, I get as far as the loading screen, and then both monitors power down.
04:03 koz_: Is this what's happening?
07:11 leberus: karolherbst: unfortunately I don't have a git tree. I might be able to create one with my changes, but not today. I'm moving to Nuremberg, I'll be busy the next couple of days I think. Is there something wrong with the patches?
07:15 karolherbst: leberus: I just would like to test them and run some scripts through them, that's all
07:30 leberus: karolherbst: https://github.com/leberus/linux/commits/nouveau_hwmon
07:30 leberus: I've created in a hurry
07:30 leberus: hope it's fine
07:31 leberus: karolherbst: this one, soz: https://github.com/leberus/linux/tree/nouveau_hwmon
07:47 mupuf: karolherbst: I plugged the nvc8
08:06 karolherbst: mupuf: thanks
08:06 mupuf: I will soon go to the center
08:07 mupuf: and get the GTX 1050 Ti
08:07 karolherbst: yeah
08:07 karolherbst: how lucky that you can do that on sundays :( I can't
08:10 karolherbst: mupuf: but it makes sense, that the VID_PWM got a new out type in the GPIO table
08:10 karolherbst: probably doesn't mean PWM_1, but PWM_PMU or so
08:10 mupuf: there are already 2 PWM controllers controllable by the PMU
08:10 mupuf: so, what, there is anpother one?
08:11 karolherbst: uhm
08:11 karolherbst: I am talking about the voltage pwm
08:11 karolherbst: normally the SPEC_OUT was 0x5c
08:11 karolherbst: but on pascal it is 0x5d
08:11 karolherbst: it's still the same pwm though
08:11 karolherbst: just not set on the host, but the PMU
08:13 karolherbst: argh....
08:13 karolherbst: mupuf: the fermi isn't detected again
08:13 mupuf: RRRrrrr
08:13 mupuf: Let me put it in the second slot
08:14 karolherbst: I am quite sure that the spec_out 0x5d means PWM_PMU or we could call it PMU_PWM
08:14 karolherbst: maybe even PMU_PWM_0
08:14 karolherbst: maybe in maywell2 vbios something like this is also done for the fans?
08:17 koz_: karolherbst: I think I'm getting overheating issues on my card when I try to drive 2 1920x1080 monitors in DRI3 and max everything.
08:17 karolherbst: koz_: what GPU?
08:17 koz_: GTX 680.
08:17 karolherbst: koz_: mind you, that you overheat keplers around 110°C
08:18 karolherbst: but they will shutdown before that usually
08:18 koz_: I dunno if it's an overheat - when I try to start my system at those settings, it goes as far as the DE loading screen, then both monitors shut down.
08:18 karolherbst: clean out your xrandr settings
08:18 karolherbst: mhh
08:18 koz_: karolherbst: How do I do that?
08:18 karolherbst: does it happen on lower pstate as well?
08:19 koz_: I haven't tried.
08:19 karolherbst: what DE are you using?
08:19 koz_: KDE.
08:19 karolherbst: plasma5? or kde4?
08:19 koz_: Plasma 5.
08:20 koz_: How do I clean out my xrandr settings exactly?
08:20 karolherbst: koz_: remove .local/share/kscreen/
08:21 koz_: OK.
08:21 koz_: What'll this do?
08:21 karolherbst: reset kdes display settings
08:22 koz_: karolherbst: Will that help me get DRI3 back up without overheating?
08:22 karolherbst: you don't even know that you have an overheating issue
08:22 karolherbst: kscreen is just stupid
08:22 koz_: Yeah - I disabled it.
08:22 koz_: So what, re-enable DRI3, restart, and pray?
08:22 karolherbst: if it tries to load an invalid xrandr profile, the screens go black
08:23 karolherbst: I had the same issue, and it isn't related to anything except kscreen being silly
08:23 koz_: karolherbst: I will give that a go and see. Thanks for the advice!
08:24 karolherbst: "GPU core: +0.91 V (min = +0.82 V, max = +1.10 V)" much better :)
08:25 karolherbst: "-- Maximum voltage 1213000 µV, voltage step -12500 µV, Maximum voltage to be used 1112500 µV --" and the highest valid entry is -- Vid 0, voltage 1213000 µV --
08:25 karolherbst: ...
08:25 karolherbst: I meant -- Vid 9, voltage 1100500 µV --
08:26 koz_: karolherbst: I can only get a single screen up consistently.
08:26 koz_: It powers up one display for a while, and then loses it.
08:26 karolherbst: mhhh
08:26 karolherbst: might be a driver problem? dunno
08:27 karolherbst: !
08:27 koz_: karolherbst: Is there any kind of log I can send you?
08:27 karolherbst: airlied: on unloading nouveau on a SSH based machine: https://gist.github.com/karolherbst/36ba840e4257c72984d8713ade0e6777
08:27 karolherbst: dunno if that's fixed with a recent kernel
08:28 karolherbst: uhm, I meant that machine has do display or anything
08:28 karolherbst: and no prime support or so
08:28 koz_: Also, karolherbst: When I run in DRI3, I get pretty noticeable pixellation which is not present under DRI2.
08:29 karolherbst: mhhh
08:29 karolherbst: can you do a screenshot of it?
08:30 koz_: Argh, screenshooter is in the inactive window...
08:30 koz_: Which is weird.
08:31 koz_: OK, this is *weird*. Now both displays work, but they're in the wrong arrangement.
08:32 karolherbst: well
08:32 karolherbst: your computer can't know in which order they stand on your desk :p
08:34 koz_: ... and I just had *both* fail.
08:34 koz_: It seems multiple monitors + DRI3 + all the rest is not stable.
08:36 koz_: It went literally: 0 monitors -> 1 monitor -> 2 monitors -> 0 monitors...
08:36 karolherbst: mupuf: I sent out an alternative fix for the voltage reading
08:36 koz_: And the pixellation on DRI3, while not new, is worse in that case.
08:37 koz_: I think I'll just leave DRI3 off for now.
08:37 mupuf: karolherbst: will check it out today!
08:37 karolherbst: nice, thanks :)
08:37 karolherbst: it's a much better solution actually than the last one
08:37 mupuf: cool
08:37 mupuf: reator works, btw
08:37 karolherbst: I already tested my patch there
08:38 karolherbst: okay, now the power sensor
08:39 karolherbst: airlied: loading with runpm=0 obviously fixes that problem
08:40 karolherbst: mupuf: can this be right? ~22W for your fermi idling around?
08:40 karolherbst: it's getting to look nice on Fermis as well: https://gist.githubusercontent.com/karolherbst/f73a839340adbda28a5960277e410910/raw/976b425d839ac2e991855acfd99a72c6a8dedaa9/gistfile1.txt
08:42 karolherbst: ohhh well, I just reclocked the engine, voltage stayed the same... ups
08:42 karolherbst: wrong GPU
08:43 karolherbst: 36W on 0f and that's without reclocking the memory
08:44 mupuf: karolherbst: yep, looks OK
08:44 karolherbst: okay nice
08:46 karolherbst: second patch out :)
09:26 dboyan: got compute shader working with pascal, all piglit test passed
09:26 mupuf: yeepee!
09:28 dboyan: still need to implement dumping of launch desc. Although it'll look like a copy-paste of the existing nve4 conterpart
09:32 karolherbst: or don't copy paste and do it properly :p
09:33 karolherbst: today I wanna get those volt and power readings working for pascal :)
09:34 karolherbst: volt looks easy, but power might be odd
09:34 karolherbst: mupuf: I tried with Lyude to get the power sensors working on Pascal, but we only got garbage out of the i2c bus
09:34 Teklad: Evening everyone.
09:34 karolherbst: I doubt much has change though
09:35 karolherbst: mupuf: what kind of pascal do you want to get? 1050?
09:35 karolherbst: ohh 1050 ti
09:35 karolherbst: mhh
09:35 mupuf: karolherbst: actually, I think I will go for the 1060
09:35 karolherbst: yeah
09:36 karolherbst: I just wanted to suggest that
09:36 karolherbst: the 1060 has a power sensor
09:36 Teklad: mupuf: Yes... do that.
09:36 mupuf: more likely to have morei nteresting features
09:36 karolherbst: most likely
09:36 Teklad:also has a 1060
09:36 mupuf: Teklad: which one?
09:36 Teklad: sec
09:36 dboyan: karolherbst: The two desc formats have similar fields, but they shifted things a bit and some fields got more bits. Well, C is C where different structs *are* different, no matter how similar they are.
09:36 karolherbst: mupuf: Teklads has also a power sensor
09:37 karolherbst: dboyans gp107, doesn'
09:37 karolherbst: t
09:37 Teklad: err
09:37 Teklad: I forgot how to pull my exact model information from the command line.
09:38 karolherbst: dboyan: saying "I can't share code because of C" is a silly argument
09:38 mupuf: Teklad: just the brand would already help
09:38 karolherbst: ;)
09:39 karolherbst: dboyan: but we don't really have the fitting architecture for that in mesa anyway, so there is a lot of duplicate code afaik
09:39 karolherbst: or we simply don't care enough
09:39 Teklad: Device: pci 0x1c03 "GP106 [GeForce GTX 1060 6GB]"
09:39 Teklad: SubVendor: pci 0x3842 "eVga.com. Corp."
09:42 dboyan: well, I'll post my code as rfc after I've got time to clean up a little and see what you guys can come up with ;)
09:42 dboyan: I personally don't see benefit of code sharing here
09:43 karolherbst: dboyan: if it's different enough, then it is fine
09:45 dboyan: it's somewhere in between, not substantially different, but different enough to make code sharing hard
09:53 hakzsam: that code is for debugging only, no need to waste your time at sharing it
09:53 karolherbst: true
09:53 dboyan: actually I don't think I will :p
09:54 hakzsam: fine by me :)
12:24 pmoreau: xexaxo1: Did you had some time to look at adding SPIRV-Tools as a dependency for clover?
12:28 pmoreau: imirkin: Mesa indeed has some nice functions for changing endianness. :-) And I realised that I was wrong to call my variable `is_little_endian`, as it tracks whether the SPIR-V binary and the CPU use the same endianness. So both of them could have been in BE, and `is_little_endian` would still have been true. :-D
13:06 imirkin: dboyan: the descriptor formats are driven off rnndb -- add it to rnndb as a new domain, and then just add code to load it up. you should be able to reuse the same compute class logic, just switch on the class itself for which header domain to use.
13:07 imirkin: decode_gf100_p_header(x, header, gk104_cp_header_domain);
13:07 imirkin: that's hardcoded now -- so you'd optionally use gp100_cp_header_domain or whatever
13:07 imirkin: [as well as the various logic to load that]
13:08 dboyan: yeah, there are actually more work to do if we want to parse mmt trace of the blob properly
13:08 dboyan: taking into account of "inline qmd"
13:08 dboyan: but the desc format is definately the first thing to do
13:09 imirkin: ah yeah. that may be worth copying object_gk104_compute.c into a object_gp100_compute.c.
13:10 dboyan: well, although I got compute shader work within nouveau. How the blob launches compute is still beyond me
13:10 skeggsb: i don't suppose it's the inline qmd that launches too?
13:11 imirkin: yeah, could be the last qmd byte launches it
13:12 dboyan: I tend to guess this way
13:12 dboyan: inline qmd are method 0x320-0x41c
13:13 dboyan: The last action before GP104_COMPUTE.GRAPH.SERIALIZE is GP104_COMPUTE.0x41c = 0
13:13 dboyan: so it might be
13:14 imirkin: skeggsb: can you think of ANY difference between ARGB8 and XRGB8 drm formats for dispnv04?
13:14 imirkin: [for the primary plane]
13:14 skeggsb:doesn't even know how pre-g80 modesetting works
13:14 skeggsb: like, at all
13:14 skeggsb: aside from that it's awful
13:14 imirkin: well we all know *that*
13:15 imirkin: it's quite odd that XRGB8 works and ARGB8 displays all black
13:15 imirkin: but i can't see anything in the code that cares
13:19 imirkin: i'm going to double-check by flipping modetest to use the ARGB8 buffer generation but XRGB8 format
13:19 imirkin: my guess is i'll get the same fail
13:22 imirkin: nope. something special about ARGB8888
13:23 imirkin: aha. depth == 24 vs depth == 32
13:23 imirkin: and xf86-video-nv didn't support depth == 32.
13:24 imirkin: and there's all kinds of stuff that uses depth in math that assumes depth <= 24
14:32 RSpliet: karolherbst: your patch "bios/volt: Parse min and max for Version 0x40", does that supersede and replace "volt: Improve min/max deteaction of range based volting"?
14:32 karolherbst: yes
14:36 RSpliet: skeggsb: ^
14:37 RSpliet: karolherbst: thanks. Looks good to me
14:42 mupuf: Gpu acquired
14:42 karolherbst: \o/
14:42 mupuf: 1060
14:42 karolherbst: nice
14:42 karolherbst: upload the vbios :p
14:43 mupuf: Will do when I'm home
14:43 mupuf: I'm on my way to it
14:43 karolherbst: :)
14:43 karolherbst: I hope it has a power sensor
14:44 karolherbst: but I don't get why Nvidia doesn't add them to every GPU now, they obviously dumped the idea of producing low end GPUs
14:44 mupuf: If it doesn't, i'll return it, saying it does not.work on my pc
14:44 karolherbst: :)
14:45 karolherbst: if you think about this: the slowest 10 Series GPU is 10x faster than the slowest 700 series one
14:45 mupuf: I bought an asus one. All the asus I have have a power sensor
14:45 mupuf: Hehe
14:46 dboyan: mine is mobile gpu, any chance it is related?
14:46 karolherbst: dboyan: there is no difference anymore
14:46 karolherbst: or not really
14:47 karolherbst: the mobile 1080 is a gp104 though
14:47 dboyan: there actually is, double precision is slower on mobile gpu
14:47 karolherbst: which is odd
14:47 karolherbst: why?
14:47 karolherbst: it shouldn't be
14:47 dboyan: according to the data on wikipedia
14:47 karolherbst: check again
14:48 karolherbst: ohh, the 1080 is gp104 on both versions
14:48 karolherbst: the 1080 ti is gp102
14:48 karolherbst: okay, so mobile chips are identical indeed
14:48 karolherbst: just worse fans and lower clocks sometimes
14:49 mupuf: Obviously, the power budget cannot be the same
14:49 karolherbst: why not?
14:49 karolherbst: the power budgets are a joke on pascal
14:49 karolherbst: compared to previous gens
14:49 dboyan: gtx 1050 desktop fp64 is 54Gflops, mobile conterpart is only half of it
14:49 karolherbst: desktop 1080: 180W, notebook 1080: 180W
14:50 dboyan: !
14:50 karolherbst: uhh
14:50 karolherbst: I think this is a mistake on wikipedias side
14:50 karolherbst: because for 1060 it is normal
14:50 karolherbst: maybe gp107 has lower doubled precision perf
14:51 karolherbst: mupuf: not saying it makes sense, but there are aptops with 2x 150W budget GPUs....
14:51 mupuf: :o
14:51 karolherbst: yeah
14:51 karolherbst: SLI laptops
14:51 dboyan: surprising
14:51 karolherbst: maybe not 150W
14:52 mupuf: But then' tgey get thermally limited
14:52 karolherbst: but highest end GPUs
14:52 karolherbst: and those are around 120W mobile
14:52 karolherbst: I could have choosen a 780M for mine and this one has 128W already
14:52 karolherbst: the 770M has a 80W budget
14:52 karolherbst: (75M is the normal one for a 770M)
14:52 karolherbst: *75W
14:52 karolherbst: so even higher than the normal specs
14:53 karolherbst: mupuf: well, those "laptops" are alos 7cm high
14:55 karolherbst: mupuf: but anyway, this step is a good one. Now you can expect a notebook 1070 being as fast as a desktop 1070, just with the thermal problems ignored
14:55 karolherbst: but still
14:55 karolherbst: it's compareable now
15:05 Teklad: I had the most amazing omelet/sandwich.
15:05 Teklad: Generous amounts of cheese and chives
15:06 Teklad: I'll pay for it later.
15:06 mupuf: Wanna use your laptop to grill it?
15:08 Teklad: mupuf: I already made it cajun style! I got confused in the kitchen and couldn't decide whether I wanted an omelet or a sandwich so I combined both.
15:08 Teklad: Worth every bit of pain I pay for later.
15:37 imirkin: dboyan: heh, so i'm guessing that the nve4 size is also size/16 -- check how the bits line up -- the nve4 size just starts 4 bits lower.
15:38 dboyan: no, size field has 4 more bits in qmd v0 and v1 than v2 in nvidia docs
15:39 imirkin: ah
16:22 mupuf: karolherbst: EXTDEV 0: type 0x4e [INA3221] at 0x80 defbus 0
16:23 karolherbst: yay
16:23 mupuf: let's get a mmiotrace too
16:23 khronosschoty: hi I'm getting this error when my laptop wakes from suspend mode
16:23 khronosschoty: [92667.301816] nouveau 0000:04:00.0: bus: MMIO write of 0000807f FAULT at 100c18
16:23 khronosschoty: it prevents the screen from waking up
16:23 khronosschoty: but if I console switch if works fine
16:23 mupuf: khronosschoty: when reclocking?
16:23 khronosschoty: again
16:24 khronosschoty: no reclocking as far as I know
16:24 karolherbst: khronosschoty: that error isn't the cause of the screen not waking up, most likely
16:24 mupuf: karolherbst: please get the emails of people for the vbios repo
16:24 mupuf: not irc nicks
16:24 imirkin: khronosschoty: i doubt that error is related to any issues you're seeing
16:24 khronosschoty: well it happens at that time
16:24 karolherbst: mupuf: okay...
16:24 khronosschoty: so idk
16:24 imirkin: right. lots of things happen at that time :)
16:25 khronosschoty:shrugs
16:25 khronosschoty: I thought it was related
16:25 mupuf: I mean, lyude is not going away easily, but think about people who come in the future and do not know who to contact
16:25 khronosschoty: I'm not noticing any issues other than that
16:25 imirkin: can you confirm that the laptop panel is connected to the nvidia board?
16:25 khronosschoty: how can I do that
16:25 karolherbst: mupuf: true, I can start to ask for that as well
16:25 mupuf: karolherbst: thanks!
16:25 imirkin: khronosschoty: grep . /sys/class/drm/*-*/status
16:26 mupuf: so, let's see how easy it is to use the blob with libglvnd
16:26 karolherbst: mupuf: the vbios.rom.fixed files are modded files so that nvbios can read them without changes. I yet have to add the additional logic for the odd parts
16:26 khronosschoty: /sys/class/drm/card0-DP-1/status:disconnected
16:26 khronosschoty: /sys/class/drm/card0-LVDS-1/status:connected
16:26 mupuf: karolherbst: oh, what do you change to make them readable?
16:26 karolherbst: mupuf: in the second part, I cut of the lenght of the second part. a few bytes after the start
16:27 karolherbst: like 0x40 or so
16:27 mupuf: Hmm, odd
16:27 karolherbst: and the length is like 0x11000 most of the time
16:27 karolherbst: no, skeggsb knows what is going on
16:27 karolherbst: nouveau can handle it
16:27 karolherbst: maybe some kind of signature?
16:27 karolherbst: dunno
16:27 imirkin: khronosschoty: cat /sys/class/drm/card0/device/{vendor,device}
16:28 karolherbst: mupuf: so I usually cut 0x11000 starting at 0xf240
16:28 khronosschoty: 0x10de
16:28 khronosschoty: 0x08a0
16:28 mupuf: karolherbst: ok, I guess it would be easier to fix nvbios
16:28 imirkin: khronosschoty: ok cool. so it's the nvidia board (and i guess the intel igp is disabled? surprising)
16:28 mupuf: anyway, I pushed my vbios, let's try what the blob says
16:28 karolherbst: mupuf: yeah, somehow
16:29 khronosschoty: idk about an intel igp
16:29 khronosschoty: but I guess its there
16:29 imirkin: oh. it's a MCP89 with a mac.
16:29 khronosschoty:shrugs
16:29 imirkin: that would have been useful information...
16:29 khronosschoty: I did not even know there was an intel igp
16:29 imirkin: macs are weird. sorry, i'm not sure what the deal is.
16:29 khronosschoty: but I guess that makes sense
16:29 imirkin: there isn't on yours
16:29 imirkin: i made assumptions based on the modicum of information you provided
16:30 khronosschoty: ahh
16:30 imirkin: pmoreau has a similar laptop afaik, perhaps he can help. maybe l1k as well (not in this chan at m)
16:30 imirkin: which mac is this precisely?
16:30 khronosschoty: macbook pro mid 2010 13
16:31 khronosschoty: 13"
16:31 imirkin: and did this ever work/
16:31 khronosschoty: did what ever work
16:31 imirkin: panel coming back on after resume
16:31 khronosschoty: I never had the issue I'm having atm until I upgraded to 4.10.12 kernel and latest mesa
16:31 khronosschoty: yeah it always worked
16:31 imirkin: well mesa is most likely unrelated. the kernel likely is.
16:32 karolherbst: mupuf: this is odd: "power rail 0: unk0 = 0x1, extdev_id = 0, shunt resistors = {0 mOhm (unk 5), 0 mOhm (unk 5), 0 mOhm (unk 5)}, config = 0x7407"
16:32 imirkin: figure out what the preivously-workign kernel was, and do a bisect.
16:32 khronosschoty: how would I do that
16:32 khronosschoty: I know what kernel worked
16:32 khronosschoty: but bisect?
16:32 imirkin: search for "linux kernel git bisect guide" online
16:32 khronosschoty: kk
16:33 imirkin: ideally one targeted to your distro if you don't build your own kernel normally
16:33 khronosschoty: I normally build my own kernels
16:33 khronosschoty: using my distro's config
16:33 mupuf: karolherbst: ....
16:33 imirkin: do you have a git checkout?
16:33 imirkin: if so, it's going to be very simple.
16:33 imirkin: if not, you'll have to get one
16:34 khronosschoty: as in did I git clone the kernel?
16:34 mupuf: karolherbst: Power Draw : 30.44 W
16:34 khronosschoty: I just did wget
16:34 khronosschoty: kernel source
16:34 imirkin: right, so you'll have to get a git checkout
16:34 khronosschoty: kk
16:34 imirkin: check any guide - should have the details
16:34 imirkin: you mark versions as good and bad to start, and then build and test kernels, reporting results
16:35 imirkin: it's a bit tedious, but shouldn't require more than 10-15 test attempts.
16:35 karolherbst: mupuf: k...
16:35 karolherbst: that's a lot
16:35 mupuf: it is!
16:35 imirkin: khronosschoty: oh actually... before you do that...
16:35 karolherbst: we can do better :3
16:36 khronosschoty: yeah?
16:36 imirkin: khronosschoty: the issue MIGHT have been due to a bug in xf86-video-nouveau. fixed in 1.0.14.
16:36 imirkin: specifically this bugfix: https://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=924083938c8f209d8f6ff472caf8692a644f7e78
16:37 khronosschoty: this looks like the plausible issue to me
16:38 khronosschoty: ty imirkin I got stuff to work with
16:46 karolherbst: mupuf: when you are done, I want to take a look at the sensor stuff on the pascal
16:48 mupuf: sure
16:56 khronosschoty: hey imirkin updating the nouveau driver fixed the issue
16:56 khronosschoty: thanks for all the help
16:58 imirkin: cool
17:17 mupuf: karolherbst: go for it1
17:26 karolherbst: ....
17:26 karolherbst: the heck
17:26 karolherbst: mupuf: nouveau does odd things
17:26 karolherbst: it doesn't really load
17:26 karolherbst: and dmesg only prints "MXM: GUID detected in BIOS"
17:29 mupuf: hmm, I did manage to load nouveau once
17:30 mupuf: oh, dude, the nvidia module is loaded
17:30 karolherbst: ....
17:30 karolherbst: is it the nvidia partition?
17:31 mupuf: no, I will do away with this partition now that loading nouveau or the blob is so easy
17:31 karolherbst: ahh
17:31 karolherbst: right
17:31 mupuf: just reboot, I blacklisted the nvidia modules
17:32 karolherbst: I need to uipdate linux-firmware as well
17:33 karolherbst: mupuf: how do I update linux-firmware-git?
17:33 mupuf: ok, check now
17:33 mupuf: wait
17:33 mupuf: still downloading
17:34 mupuf: yep, here you go
17:34 mupuf: I just had an old git snapshot
17:42 karolherbst: mhhh
17:42 karolherbst: on one channel: vshunt: -5 vbus: -5
17:51 Lyude: karolherbst: btw, do you know if the engine blocks we have for clockgating pre-fermi are more or less the same? (just figuring out how I should design the internal nouveau api for this)
17:52 karolherbst: it's a guess
17:52 karolherbst: you can verify with a mmiotrace
17:52 karolherbst: the regs are set whenever the engine is setup as well
17:53 Lyude: unfortunately I don't have any pre-fermi hw
17:53 karolherbst: uhh, I still have a bug inside the fermi iccsense patch
17:54 Lyude: karolherbst: oh?
17:54 karolherbst: only two out of three rails are read out
17:54 karolherbst: no idea why
17:55 Lyude: if you need a machine to play with again feel free to ask
17:55 karolherbst: I have mupufs now, but thanks
17:55 Lyude: np
17:55 karolherbst: Lyude: you can ask mupuf how he has setup his ;)
17:55 karolherbst: it has a fancy frontend where you can remotely turn them on/off and everything
17:56 Lyude: yeah! i would set something up that's a little more complex like that but I don't have enough machines to dedicate for it
17:56 Lyude: i only ever can really use 2 towers at a time
17:56 karolherbst: mupuf has one :p
17:56 karolherbst: I think
17:56 karolherbst: maybe he has a second now
17:56 Lyude: Oh, you mean just remotely controlling machines in general
17:56 karolherbst: yeah
17:57 Lyude: yeah, I've got stuff like that setup here but my setup is somewhat exotic
17:57 karolherbst: uhm, I doubt that matters
17:57 Lyude: oh no i'm just saying
17:57 karolherbst: I see
17:58 karolherbst: the last time we figured out how to setup a laptop and use the dock station pins for it, this was fun
17:58 Lyude: i use a chamelium for screen grabbing and stuff, and am hopefully eventually going to do something with my beaglebone similar to what mupuf did for remote power button control
17:58 Lyude: something a little crazy i've also been considering is getting a little servo to press power buttons for me since that would be a lot easier to setup with laptops
17:58 karolherbst: okay, what is wrong here? "nvbios_rd08(bios, entry + 0x1) & 0xf8 == 0xf8"
17:58 karolherbst: input: 0xff, 0xfd and 0xfc
17:59 karolherbst: ohhhh
17:59 karolherbst: silly C
17:59 karolherbst: "(nvbios_rd08(bios, entry + 0x1) & 0xf8) == 0xf8" fixes it
18:00 karolherbst: why would I ever int & bool, when int & int == int is the input
18:00 Lyude: hm, also looking at the tegra example code and it seems like subdev/pmu might be a better place to stick the clockgating stuff
18:00 karolherbst: like, when
18:00 karolherbst: Lyude: maybe? but coding on the PMU is a different kind of fun
18:12 karolherbst: mupuf: would be funny if they have locked i2c down to the PMU as well
18:30 mupuf: Lyude: it is much easier to just hook on the docking port
18:36 karolherbst: mhh
18:36 karolherbst: I get EIO
18:36 karolherbst: int ret = i2c_transfer(adap, msgs, ARRAY_SIZE(msgs)); is != 2
18:39 karolherbst: mhh
18:39 karolherbst: I get -ENXIO
18:39 karolherbst: odd
18:40 karolherbst: skeggsb: something is totally broken with the i2c communication on Pascal, do you know anything about it?
18:42 mupuf: karolherbst: given that the EDID just works, I guess it must depend on the bus
18:42 karolherbst: no idea,most likely
18:42 mupuf: nvaspyi2c works?
18:42 karolherbst: kind of? didn
18:42 karolherbst: 't try on your machine
18:42 karolherbst: will check it out later
18:47 Lyude: btw, what are the commands you guys use to reload nouveau and get it to reinit the card? unbinding the vt, removing the drm device, unloading and reloading nouveau doesn't seem to bring the card back up
18:51 mupuf: Lyude: that worked on older models
18:51 mupuf: we really need to get IGT running on nouveau too
18:51 mupuf: still a little more work needed to get there
18:54 karolherbst: Lyude: on machines with prime you can power off the GPU in between, you can also force a POST of the GPU as well
18:54 Lyude: ah, haven't played around yet to see if prime works on this machine or not
18:55 karolherbst: I meant optimus
18:55 Lyude: i figured, also when you say optimus are you just talking about forcing runpm on or machines with actual optimus stuff
18:57 Lyude: also nice. Not as much as I expected (I also didn't play with all the clockgate control registers just yet) but it's a start: GF110 ~27.9W without clockgating, ~26.8W with clockgating on PGRAPH-PCOPY2
18:58 karolherbst: yeah, PGRAPH is the most important one
18:58 karolherbst: you get higher results on higher clocks, but that's a little unstable on fermi
18:58 karolherbst: on mine it's more like 10W -> 9,5W
18:59 Lyude: i keep thinking I'm missing something but I'm mostly sure it's because this took very little time compared to what I expected...
18:59 karolherbst: without knowing how well nvidia does, the numbers sound bad
18:59 karolherbst: but on my GPU nvidia is around 9W
18:59 karolherbst: and wich clock gating we would be at 9,5W
18:59 karolherbst: soo
19:00 Lyude: bleh, those non-clockgating readings are just what sensors was giving me, it could be that we're just not reading the wattage properly?
19:00 karolherbst: maybe?
19:00 karolherbst: but I am sure they are kind of right
19:02 karolherbst: Lyude: mind you, that the engines are still idling
19:03 Lyude: karolherbst: right, they should be idling here as well since I don't even have a gui loaded
19:03 karolherbst: Lyude: that clock gating thing is really just not emiting any clock signals I think, or anything like that
19:03 Lyude: karolherbst: huh?
19:03 karolherbst: *something
19:04 karolherbst: not quite sure
19:04 karolherbst: I think it just stops the clock or so
19:04 karolherbst: because an engine doing nothing also needs no clock
19:06 Lyude: btw karolherbst current WIP branch https://github.com/Lyude/linux/tree/wip/fermi%2B-clockgating
19:07 karolherbst: Lyude: you don't need the hack, only for fermi
19:07 karolherbst: ...
19:07 karolherbst: *pascal
19:08 Lyude: karolherbst: ah
19:08 karolherbst: Lyude: you forgot to add the gf100 file
19:08 Lyude: yep, just fixed that :P
19:08 Lyude: and the clkgate.c file, but something feels wrong about a file so small
19:08 karolherbst: and nvkm_therm_clkgate_init belongs inside base.c
19:09 karolherbst: ohh
19:09 karolherbst: you put it into a seperate file
19:09 karolherbst: okay, fine
19:09 karolherbst: no, it's fine
19:09 karolherbst: I rather have more small files than a few big ones
19:09 Lyude: yeah
19:09 karolherbst: and it gets super complicated with pre fermi hardware
19:09 Lyude: it's nice not having to edit 15,000+ line files
19:10 karolherbst: like with other drm drivers? *cough*
19:10 Lyude: yep *cough* maybe even intel's *cough*
19:18 Lyude: btw karolherbst, I'm assuming I'll just get a fault if I try enabling any of the powergating regs that don't exist for this generation correct/
19:19 karolherbst: no
19:19 karolherbst: nothing happens afaik
19:19 Lyude: oh
19:20 karolherbst: I just force enable bit 1 on every clock gating reg. _maybe_ it is different for the power gating stuff
19:20 Lyude: Oh, wasn't aware we had both clock gating and power gating
19:21 Lyude: ah, I see
19:21 Lyude: ENG_CLK, BLK_CLK, ENG_PWR, and BLK_PWR
19:21 karolherbst: no idea if those names are right as well
19:39 mupuf: karolherbst: they are based on nvidia's names
19:39 mupuf: so yes, they should be accurate
19:40 mupuf: I spent a lot of time on this
19:45 Lyude: interesting, switching all of them to auto (0x20200-0x2025c) doesn't show any noticeable power saving above just turning on clock gating
19:46 karolherbst: mupuf: I see
19:46 mupuf: Lyude: I had the same results on kepler
19:46 karolherbst: Lyude: yeah, that fits my results
19:48 Lyude: cool. btw, unless we're planning on figuring out what all of the clockgate control registers control I'm not sure how we'd only enable clockgating for each generation's applicable blocks vs. all of them like you mentioned earlier karolherbst
19:48 Lyude: which, I'm fine trying to do that if we think it's a good idea
19:49 karolherbst: Lyude: I think it's save to just enable the lower bit, we have nvkm_mask for that
19:49 karolherbst: ohh
19:49 karolherbst: mhh
19:49 karolherbst: you can check which engines we enable/disable
19:49 karolherbst: that should be okay then
19:50 karolherbst: mhh, I am not aware of the specifics sadly. There is a function we can use, no idea how it is called though
19:55 mupuf: Lyude: just do what nvidia does
19:55 pmoreau: imirkin: I have a MBP with MCP79+G96, but I left it in Sweden. I considered bringing it along to France, but I had no space left for it.
19:55 mupuf: poke all the registers like nvidia does
19:55 mupuf: and be content
19:56 Lyude: yeah, that's what I was planning on
19:56 mupuf: we DO NOT want to fiddle with them
19:56 mupuf: because that is the cause of browouts
19:56 mupuf: brownouts
19:56 mupuf: and that will be impossible to debug
19:56 mupuf: so, better be safe
19:57 Lyude: True. mupuf, btw, nvidia just toggles the lower bits for clockgating correct?
19:57 karolherbst: well, if nvidia does anything else except just enabling that one bit, this might get more interesting :)
19:57 karolherbst: Lyude: check your trace :p
19:57 Lyude: oh right, I honestly forgot to even do one
19:57 mupuf: Lyude: nope, it bashes the entire register
19:57 mupuf: Lyude: I pushed my mmiotrace in the vbios repo
19:57 mupuf: just check it out
19:57 austriancoder: can somebody explain the concept behind the sequence number used in nvc0_query_hw? https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw.h#n25
19:57 Lyude: mupuf: where is the bvios repo?
19:57 Lyude: *vbios
19:58 mupuf: Lyude: oh, it is private, send me your ssh key, I will add you to it
19:58 Lyude: mupuf: https://lyude.net/~lyudess/id_rsa.pub
20:00 mupuf: Here ya go!
20:37 Lyude: Can demmt be used with mmiotraces as well as mmt traces?
20:37 karolherbst: Lyude: demmio
20:37 Lyude: ahhh, ok
20:38 karolherbst: find and grep are both very important tools with that repository
20:40 karolherbst: I usually do things like "find nve* nvf* -iname "*trace*.xz" | while read trace; do echo $trace; demmio -f $trace 2>/dev/null | grep " 0x0202[012345][048c]"; done"
20:40 karolherbst: and then you can always play around with -A and -B in grep
20:41 karolherbst: mhh putting a space after the reg makes also sense
21:47 skeggsb: karolherbst: the "management bus(s)" have been locked down since gm20x, it's one of the first things they locked down
21:47 skeggsb: (they even told us that when they gave the first "details" on priv security)
21:47 karolherbst: .....
21:47 karolherbst: I guessed as much
21:48 karolherbst: but
21:48 karolherbst: it works on maxwell2
21:48 skeggsb: hmm, are you sure about that?
21:48 karolherbst: yes
21:48 karolherbst: we even have it enabled for maxwell2
21:48 skeggsb: i get priv ring faults on at least one of my gm20x boards where nouveau touches a register that's involved there
21:48 karolherbst: well might be, but we can use the power sensors
21:49 karolherbst: I actually reed quite a lot on those maxwells, maybe it was 1st gen, but I am sure it works
21:49 skeggsb: "I2C bus C writes are restricted to a secure context, to prevent misprogramming thermal sensors."
21:49 skeggsb: from ftp://download.nvidia.com/open-gpu-doc/Falcon-Security/1/Falcon-Security.html
21:49 karolherbst: skeggsb: what maxwell2 gpus do you have access to?
21:50 karolherbst: the power sensor readins is enabled for all maxwell2 GPUs
21:50 skeggsb: hmm, gm200,gm204 and gm206 of some description
21:50 karolherbst: so should be easy to just try it
21:50 Lyude: s/misprogramming/nouveau programming/
21:50 karolherbst: the gm200 has it for sure
21:50 karolherbst: and gm204 most likely as well
21:50 skeggsb: Lyude: exactly ;)
21:50 karolherbst: skeggsb: can you run nouveau on those and check it?
21:50 karolherbst: I am 90% it works there
21:50 karolherbst: otherwise I would have noticed already
21:51 karolherbst: we can even write into the power sensor registers
21:52 karolherbst: skeggsb: we know that we can't control the fans, that's for sure, but power sensors work
21:52 skeggsb: yeah, i've already tried a few dodgy ways around the fan control restrictions, without success :P
21:52 karolherbst: mupuf did so as well
21:53 skeggsb: personally, i think it's really fucked up that nvidia think they have a right to control what people do with hardware they pay for... it's *really* irritating me
21:53 karolherbst: ....
21:53 karolherbst: you are not the only one
21:53 Lyude: i feel exactly the same way
21:53 karolherbst: you already know my perspective on future involvement of nvidia in nouveau
21:53 Lyude: nvidia hates open source and honestly I think they might save themselves some time by just telling us that outright
21:53 Lyude: and save us a lot of time
21:54 karolherbst: skeggsb: your gm206 has also a power sensor
21:54 karolherbst: skeggsb: now that I think of it, the rail table is different on pascal
21:54 mupuf: yes, the i2c buses were not limited on maxwell
21:54 karolherbst: skeggsb: most likely it contains a flag for telling "PMU duh", the same we have that for the VID_PWM
21:55 karolherbst: SPECT_OUT 0x5d probably means PWM_0_SECURED or so
21:55 RSpliet: Lyude: let's not get dragged into generalising conclusions and talk about the "individuals in power @ NVIDIA" rather than the whole company. There's too much divisive generalisation happening in the world already ;-)
21:55 karolherbst: RSpliet: I am sure this was a statement about the company :p
21:55 mupuf: skeggsb, Lyude: yep... it is really fucked up also that they don't provide at least a firmware with support for all features
21:56 mupuf: no fan management on nouveau is ... a joke?
21:56 mupuf: do we need to threaten them of not merging patches for tegra until they fix this situation?
21:56 karolherbst: mupuf, skeggsb: we announce no future patches from nvidia until they get their shit togeter on XDC2017?
21:56 karolherbst: risky step
21:56 karolherbst: but any better ideas?
21:56 mupuf: yes, it is so stupid...
21:56 mupuf: but what can we do aside from trying to crack it?
21:56 karolherbst: nothing?
21:57 karolherbst: waiting is no option for me
21:57 karolherbst: not anymore
21:57 mupuf: basically, they say fuck to desktop GPUs
21:57 karolherbst: and even if they provide anything, I would say fuck you except we get 100% docs about the API
21:57 karolherbst: no wholes
21:57 mupuf: and twice did they magically have the firmwares ready right before the code for tegra was ready
21:57 karolherbst: no leaving details out
21:57 mupuf: yeah, you can dream about it :s
21:57 airlied: write firmware extract script
21:57 karolherbst: let's invite Linus :3 hurhur
21:58 mupuf: airlied: we already have it IIRC
21:58 mupuf: nvagetpmu
21:58 karolherbst: :/
21:58 karolherbst: this doesn't work
21:58 RSpliet: mupuf: that doesn't work post-kepler
21:58 mupuf: hmm, darn it
21:58 mupuf: I see
21:59 mupuf: airlied: we still would have to deal with unversioned firmwares
21:59 karolherbst: well there are theoretical ways, but nothing is practical for endusers
21:59 karolherbst: mupuf: dumping scripts could add versions in theory
21:59 RSpliet: mupuf: they're versioned by the blob you're extracting them from
21:59 mupuf: I guess this could work, yes
22:00 RSpliet: the script can encode that info in the firmware filename or something
22:00 RSpliet: makes them as unfriendly to use as broadcom wifi cards, but meh...
22:00 mupuf: that could work. I guess if we use one of their firmwares and figure out the security flaws they are so afraid of, maybe they won't take as long anymore to release their firmwares?
22:01 mupuf: or figure it is just a waste of time
22:01 karolherbst: well we support quite a lot of versions already
22:01 mupuf: karolherbst ?
22:01 karolherbst: 352, 361, 364, 367 and 375
22:01 mupuf: karolherbst: this script will never find the pmu firmware, IIRC
22:02 mupuf: we can try again though, but it is possible some of it is generated on the fly
22:02 mupuf: imirkin never found the PMU IIRC
22:02 mupuf: what annoys me the most is the fact that right now, we can flash the bios, but we cannot upload it to PRAMIN
22:02 mupuf: at least, I never managed to make it work
22:02 mupuf: skeggsb: any success on this on your side?
22:03 skeggsb: negatory
22:03 skeggsb: though, i'm actually not 100% sure i've tried
22:04 karolherbst: mhh, well I am sure we will be able to figure a way out, at some point
22:04 RSpliet: I don't think there's a fundamental reason why nvagetpmu can't be fixed up to extract the final PMU from a running system. Intercepting intermediate bootloaders is another story though...
22:06 RSpliet: iirc it currently only works on a blob so old that it doesn't support Kepler+
22:07 RSpliet: (or second gen kepler, or something like that)
22:07 RSpliet: because they changed the way they fill in the page table slightly.
22:07 RSpliet: and I never got round REing any of that further
22:11 karolherbst: RSpliet: I am sure you can't dump it
22:11 karolherbst: like 95%
22:11 karolherbst: not while the PMU is fully running
22:11 karolherbst: the secure falcons are super protected
22:11 karolherbst: you can hardly do anything with them
22:12 RSpliet: karolherbst: one way or the other this super secure falcon needs access to the binary in a form that nouveau can upload it
22:12 RSpliet: and a pointer to it
22:13 skeggsb: once it's uploaded, pmu will lock down that area of memory so it can't be touched by the host anymore
22:13 RSpliet: skeggsb: is it in VRAM or system DRAM?
22:13 skeggsb: vram, can't really lock down system memory :P
22:13 karolherbst: RSpliet: it should be all inside the mmiotraces ;)
22:14 RSpliet: skeggsb: can you really lock down VRAM though? If you manually walk the page tables and do that dance?
22:14 skeggsb: yes, pmu can prevent the vram access somehow
22:15 RSpliet: PMU can block RAM access based on it's physical address... funky
22:16 Lyude: everything about this screams very intentional prevent everyone else from touching our power management forever
22:16 Lyude: ugh
22:17 RSpliet: skeggsb: what about the source of the DMA transfer from system RAM to VRAM? Can that be derived easily and chased?
22:17 skeggsb: i suspect you could probably intercept it like that still
22:17 Lyude: hm, but it does only lock down access to the vram AFTER the upload
22:17 Lyude: why not cold boot attack it?
22:18 Lyude: assuming you could cool down the GPU long enough you could just have nvidia's blob setup the GPU, cut power off to the machine, start it up with nouveau and see what's in the parts of the vram the PMU blocked access to
22:18 RSpliet: skeggsb: they might unmap it though. Wouldn't it be cool to be able to insert kdb breakpoints on MMIO actions?
22:18 Lyude: unless the GPU itself clears memory on init
22:19 karolherbst: well I think our best shot is to look at traces until we find something we can use to get the image
22:19 karolherbst: shouldn't be that hard
22:19 Lyude: in that case it would also be pretty obvious where the firmware is, since it would just be the parts of the vram the PMU blocked access to
22:20 karolherbst: Nvidia might own their GPU and firmeware
22:20 karolherbst: but we still own our own machines
22:20 Lyude: and if we end up finding something they didn't want being public. well, that's their fault ;)
22:20 RSpliet: karolherbst: the firmware itself will not show up in mmiotrace, and we already kind of know how the "DMA upload" procedure looks in mmiotrace
22:21 skeggsb: Lyude: the funny thing is, i'm sure someone will eventually find something like that - and their motivation will be primarily because nvidia didn't play ball and provide an alternative
22:21 skeggsb: it *will* be their own fault
22:21 Lyude: skeggsb: sounds like encouragement :)
22:23 RSpliet: can we offer a bounty? :-P
22:23 karolherbst: RSpliet: the process shows up though
22:24 RSpliet: (either the coconut chocolate bar or the kitchen roll... whatever they'd take)
22:51 airlied: mupuf: I doubt they generate it on the fly
22:51 airlied: since that would mean the driver could sign it
22:52 mupuf: fair point
23:39 imirkin: austriancoder: can you elaborate at to your question... it's a number... and it's a sequence :)
23:39 imirkin: basically the nvidia hw is pretty asynchronous
23:40 imirkin: so just coz you sent commands doesn't mean they get executed
23:40 imirkin: the sequence number lets you know when the command is executed
23:41 imirkin: you can also throw a wrench into the command processor to wait for a particular sequence number to get reached