14:37 naptastic: is there anything I can do to accelerate the development of acceleration support for NV110 devices? (Anyone at whom I can throw hardware, perhaps?)
14:49 imirkin: naptastic: is there an issue you're running into?
14:50 naptastic: imirkin, my whole DE just feels "sluggish"; full-screen video is super chunky; CPU usage for rendering anything at all is near 100% across 4 of my 6 cores, since I upgraded my video card.
14:51 naptastic: And let me just say, please don't take it as a complaint--I completely understand and appreciate everything that's gone into Nouveau. I really do genuinely want to know if there's any helpful action I can take.
14:51 naptastic: (Short of learning C and familiarizing myself with the codebase, because I just can't allocate that much time.)
14:52 imirkin: naptastic: sounds like you're not getting any acceleration
14:52 imirkin: naptastic: pastebin dmesg and xorg log
14:52 naptastic: imirkin, exactly. Which makes sense given https://nouveau.freedesktop.org/wiki/FeatureMatrix/
14:52 naptastic: Ok, lemme get those.
14:53 naptastic: do you have a preferred pastebin site?
14:53 naptastic: imirkin, ^
14:53 imirkin: whatever you like
14:53 imirkin: i tend to use hastebin
14:54 imirkin: but it _really_ makes no difference to me
14:54 imirkin: just as long as the information is communicated
14:55 naptastic: imirkin, here is dmesg: https://paste.fedoraproject.org/362159/22872831/
14:55 naptastic: and here is Xorg.0.log: https://paste.fedoraproject.org/362160/87309146/
14:56 imirkin: naptastic: you have a GK104...
14:56 naptastic: oh hell
14:56 imirkin: aka NVE4
14:56 naptastic: I did this all on the wrong machine
14:56 naptastic: DERP
14:57 imirkin: oh
14:57 imirkin: coz i was gonna say that everything looks just fine :)
14:59 naptastic:sets up his SSH tunnel...
15:05 naptastic: that host's not even on right now, and my roommate isn't awake to turn it on.
15:06 naptastic: I'll be back later. imirkin, thanks for your help.d
15:30 karolherbst: imirkin: just a heads up: it seems like there are problems reclocking ddr3 maxwell cards, but gddr5 seems to work just fine
15:30 karolherbst: mupuf: do you have any ddr3 based gm10xgpu?
15:37 imirkin: karolherbst: neat
15:39 karolherbst: well I kind of hoped DDR3 also just works
15:39 imirkin: my guess is it's some minor thing
15:40 imirkin: since it sounds like they didn't redesign the memory controller
15:40 imirkin: but who knows
15:40 karolherbst: yeah
15:40 imirkin: i think the gm108 guys have gddr3 vram
15:40 karolherbst: or maybe it is something which is also broken for kepler
15:40 imirkin: there are some mmiotraces
15:40 imirkin: that you could glance at
15:40 imirkin: well, it def worked with my GK208 - i know that much
15:41 karolherbst: yeah, but sometimes issue only trigger for a few cards
15:41 karolherbst: because it usually is fine as it is
15:41 imirkin: sure
15:41 imirkin: and fwiw my GK208 didn't work out of the box, i had to add some CAS latency settings for it iirc
15:41 karolherbst: ohh
15:41 karolherbst: but it is upstreamed already?
15:42 imirkin: ya a long time ago
15:42 karolherbst: okay
15:42 imirkin: but perhaps an updated standard has higher latencies... who knows
15:42 imirkin: depends on the failure mode
15:42 karolherbst: nice, all gm108 are ddr3 except the quadro one
15:43 karolherbst: and gm107 is usually gddr5
15:43 imirkin: except probably some mobile laptop models
15:43 karolherbst: nope, doesn
15:43 karolherbst: 't matter
15:45 karolherbst: one desktop gm107 is ddr3, the two others are gddr5, 850m is partly ddr3/gddr5, 860m is gddr5, same situation for 950m and 960m and then one desktop quadro is ddr3, all others are gddr5
15:45 karolherbst: even all mobile quadros are gddr5
15:45 imirkin: hm ok. gtg.
15:47 qqz: [ 1084.518190] nouveau 0000:01:00.0: Direct firmware load for nouveau/nv84_xuc00f failed with error -2
15:47 qqz: help; this file is missing at me.
15:47 imirkin: you only need it if you want to use vdpau
15:47 qqz: I have already tried to compile mesa myselg
15:47 imirkin: have a look at https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
15:52 karolherbst: imirkin: mhh looks nearly the same (comparing gk107 and gm108)
15:53 karolherbst: it even looks more the same if I consider the differences between those SEQ scripts
15:53 karolherbst: for the same gpu
15:54 karolherbst: yeah well, maybe just bad luck then
16:14 imirkin_: karolherbst: what was the failure mode?
16:14 karolherbst: what do you mean?
16:14 imirkin_: you said it didn't work
16:15 imirkin_: how did it express this non-working-ness?
16:15 karolherbst: well, disabled memory reclocking and then highest pstate worked
16:15 imirkin_: and with it enabled...
16:15 karolherbst: it froze immediatly
16:15 imirkin_: ah ok
16:16 karolherbst: of course this can mean anything else, it was just a quick test
16:32 karolherbst: uhh desktop isis
16:33 karolherbst: i5 for 255$, that sounds reasonable somewhat
16:34 karolherbst: meh, but no LGA1151 socket....
16:34 karolherbst: seriously?
17:40 imirkin_: finally grabbed a pci NV3x on ebay. should finally be able to test every driver without swapping cards
17:41 imirkin_: although i guess getting nouveau_vieux to run on it might take some doing
17:46 mupuf: karolherbst: hey, no sorry, I only have one GM1xx
17:46 mupuf: no idea what it is using though
18:00 mupuf: imirkin_: nice!
18:01 mupuf: so, turns out I have a night off tonight, I will resume the piglit activities on the tk1
18:01 imirkin_: (nv3x still has the compatibility BS in it, which means it should be able to run as a NV2x thing)
18:04 mupuf: lol
18:12 RSpliet: imirkin_: it seems I have a GeForce 4 here... no idea which one
18:12 imirkin_: that's probably a nv18
18:12 imirkin_: either way, i needed a nv3x (geforce fx) so that i could run nv30 and nouveau_vieux on it :)
18:12 RSpliet: probably, it looks rather low-end :-)
18:13 imirkin_: i guess it could be gf4 ti (nv25)
18:13 imirkin_: but... unlikely
18:13 imirkin_: those were all AGP
18:13 imirkin_: (in fact all nv2x's were AGP, if you discount nv2a)
18:15 RSpliet: hmm, from the looks of it it's AGP... but I do have an AGP machine with motherboard if you ever desire access to old cruft like it
18:15 imirkin_: hehe
18:15 imirkin_: thanks
18:16 imirkin_: mostly i just want to be able to test stuff without rebooting
18:16 imirkin_: coz i'm lazy
18:16 RSpliet: (plus NV34 and NV4B)
18:16 RSpliet: fair enough
18:17 imirkin_: i have a nv5, nv17, nv34 (pcie), nv42, nv44, nv84, nv96, nva3, nvc1, nv108 - i'm not hurting for test targets. just fitting all of them in at once is tricky :)
18:17 imirkin_: [oh, and nvea, although that one doesn't like to stay up]
18:19 RSpliet: sounds like you have most bases covered, although I recall there are some differences between NV44 and NV4B (I never dived deep enough to know what these differences actually are)
18:20 RSpliet: and I recall NV34 to be "the GeForce FX with the weird ancient FB register layout" :-D
18:20 RSpliet: but that
18:20 RSpliet: 's probably not applicable to what you're trying to do
18:20 imirkin_: well, nv42 and nv44 cover both of the graph classes
18:20 imirkin_: i.e. 4097 and 4497
18:20 imirkin_: iirc nv4b is 4097, although i don't remember
18:21 imirkin_: and yeah, nv34 has some hilariously weird config wrt... something. but it doesn't matter to what i'm doing.
18:21 imirkin_: like a nv1x memory controller. or something.
18:21 RSpliet: yes
18:21 imirkin_: but i'm not looking to run bitcoin mining on it... just testing nouveau ;)
18:22 mupuf: hey, never thought about plugging my PCI gpus into reator
18:22 imirkin_: do you have any?
18:22 RSpliet: don't underestimate a GeForce FX bitcoin mining cluster... it might save you significantly on your heating bill
18:22 imirkin_: RSpliet: yeah, but it feels weird to put the A/C full-blast in the middle of winter...
18:24 RSpliet: mupuf: if my father finally retires his machine, I'll dibs the NV03
18:24 RSpliet: although... it might be AGP
18:24 imirkin_: lol
18:24 mupuf: imirkin_: AFAIR, yes
18:24 mupuf: let me check
18:26 mupuf: I found a nv17
18:26 mupuf: the bios is as big as the GPU :D
18:27 imirkin_: neat
18:27 pmoreau: Yeah! … my discrete G96 is the only card I can’t plug because it’s a reduced witdth one (the connectors bar is half the usual length). And I don’t plan to take the motherboard out (nor have I the tools for that).
18:28 pmoreau: s/witdth/width
18:28 imirkin_: mupuf: well, i haven't tested on a nv17 in ages
18:28 imirkin_: and back when i did, i found tons of problems, some of which i semi-fixed
18:28 mupuf: ah ah, ok, I can try to plug it
18:28 imirkin_: mostly i had gotten it to figure out why X accel was broken for people
18:28 imirkin_: that was a fun little exercise
18:29 imirkin_: but i suspect i'm the only person who uses nouveau_vieux with any sort of frequency, with rare upgrades by the actual users
18:29 imirkin_: so it's good for me to be able to test it on a more regular basis
18:29 imirkin_: to make sure nothing gets totally broken
18:30 imirkin_: and with nv30 i really should fix the situation where rendering is all broken on it if you don't select the idea fbconfig
18:30 imirkin_: ideal*
18:30 mupuf: ah ah, the fan really needs love!
18:30 imirkin_: just take it off
18:30 imirkin_: that'll fix it right up
18:31 mupuf: I guess I can just get rid of it and put a real heatsink
18:31 mupuf: or yeah, cut the wire
18:31 mupuf: yep, the 3 cards are there, in nvalist
18:32 mupuf: let'a just cut the wire of the fan, I can always resolder if needed
18:35 mupuf: imirkin_: here we go, this card should be a permanent resident of reator now
18:35 imirkin_: cool :)
18:36 imirkin_: unfortunately no dri3 with nouveau_vieux
18:36 imirkin_: or gbm or anything like that
18:37 karolherbst: mupuf: if you got time you could trace the LEDLogo thing :D
18:37 karolherbst: super important
18:38 mupuf: karolherbst: well, I was thinking about this
18:38 karolherbst: well only you can do it
18:38 mupuf: (on my way to the uni)
18:38 mupuf: and I checked out the hwmon interface
18:38 mupuf: we could pretend it is a fan and expose it this way
18:38 karolherbst: I was already thinkingabout a webcam and microphone so that we can have a look over the fans and the noise :D
18:38 karolherbst: mupuf: why should we?
18:38 mupuf: karolherbst: expose it?
18:39 karolherbst: there is a LED device class in the kernel
18:39 mupuf: oh!
18:39 karolherbst: yeah
18:39 karolherbst: /sys/class/LED
18:39 mupuf: right right, let's see
18:39 karolherbst: or something
18:39 karolherbst: *leds
18:39 karolherbst: usually you have something like "input6::capslock" in there
18:40 mupuf: nothing for me, but it seems to support PWM
18:40 mupuf: ok, then it can be exposed :D
18:41 karolherbst: ohh pwm based LEDs are also supported by the led subsystem?
18:41 karolherbst: nice
18:41 karolherbst: but yeah
18:41 karolherbst: should make sense
18:42 karolherbst: ohh wait
18:42 karolherbst: there is alsothe backlight subsystem
18:42 karolherbst: but I think it is the same code in the end
18:42 karolherbst: because the leds also have "brightness" and "max_brightness"
18:43 mupuf: karolherbst: so, that means we also need to write a trigger driver?
18:43 karolherbst: mhh
18:43 mupuf: to expose whatever we want? (temperature, gpu load)
18:43 karolherbst: I don't think we have
18:44 karolherbst: the user can use the already existing ones
18:44 karolherbst: but yeah, we could
18:44 karolherbst: or use no trigger at first
18:44 mupuf: well, that would really be a uselessly nice feature :D
18:44 mupuf: sure, no triggers at first
18:44 karolherbst: and let the user change it to whatever they want
18:44 karolherbst: right
18:44 karolherbst: as I said: super important
18:44 karolherbst: how can we even dare competing on a performance level, if we don't even support custom LED lights
18:45 karolherbst: ...
18:45 Yoshimo: interesting priorities you have there
18:46 karolherbst: yeah, the other one is "should be fixed" and "whenever I have time"
18:46 karolherbst: *are
18:48 mupuf: karolherbst: so, at least, I can indeed change the brightness
18:48 karolherbst: with the nvidia-settings option?
18:48 karolherbst: awesome
18:48 mupuf: yes
18:48 karolherbst: I guess there are a range of regs we can use for it
18:49 karolherbst: and if we know one
18:49 karolherbst: maybe we know all
18:49 karolherbst: at least that was my idea
18:58 mupuf: karolherbst: well, no REing necesserary
18:59 karolherbst: how so?
18:59 karolherbst: i2c bus?
18:59 mupuf: [0] 668.988108 MMIO32 R 0x61c884 0x40020f58 PDISPLAY.SOR[0x1].PWM_CTL => { DUTY = 0x20f58 | CLOCK_SELECT = UNK1 }
18:59 karolherbst: :D
18:59 mupuf: as expected
18:59 karolherbst: the voltage pwm caused more troubles than those, I am disappointed
19:00 mupuf: well, now, let's figure out the clock tree for this horror
19:00 mupuf: oh, we are not done dude!
19:00 karolherbst: "GPIO 19: line 19 tag 0x84 [LOGO_LED_PWM] IN DEF 0 param 1 gpio: normal SPEC_OUT 0x84 [SOR1_PANEL_BACKLIGHT_LEVEL]"
19:00 karolherbst: so you have only one LED?
19:00 mupuf: we just know the PWM controller
19:00 mupuf: and that there is nothing fancy
19:00 karolherbst: I through there was some fancy multicolor thing
19:00 mupuf: nope
19:00 mupuf: one LED
19:00 karolherbst: meh, boring
19:00 mupuf: now, we need to compute the divider
19:01 mupuf: not that any value would work though
19:01 karolherbst: well
19:01 mupuf: lol
19:01 mupuf: well, I already finished
19:01 karolherbst: :D
19:01 mupuf: the divider is 270000
19:01 karolherbst: surprise
19:01 mupuf: so, the frequency is 1 kHz
19:02 mupuf: wait, no, 100 Hz
19:02 mupuf: which seems fast enough
19:02 mupuf: karolherbst: ok, shall I or should you add support for this?
19:02 karolherbst: mhh
19:02 karolherbst: this needs a new subsystem?
19:03 mupuf: yep
19:03 karolherbst: I mean, subdev
19:03 mupuf: hmm, good question
19:03 karolherbst: well I never added one, I used your iccsense subdev add code
19:03 karolherbst: :D
19:03 mupuf: I would say it needs to end up in pdisp in the end
19:03 karolherbst: why?
19:03 mupuf: and it is likely there
19:03 karolherbst: well we need a nouveau_led.c file anyway
19:04 mupuf: nouveau_led cannot be in core/
19:04 karolherbst: right
19:04 karolherbst: though I think a subdev might make sense, allthough it will be a really cheap one :/
19:04 mupuf: so, I would say, let's expose the SOR PWM controllers
19:04 karolherbst: in fact
19:04 karolherbst: it will have the same code as the backlight stuff
19:04 mupuf: through PDISP, since this is where it is
19:04 karolherbst: or nearly the same
19:04 mupuf: yes, it will
19:04 mupuf: so, pretty sure it is already done
19:04 mupuf: want to have a look?
19:05 dcomp: Anyone know the purpose of PIBUS.MMIO_HUB[0].CFG[0x7] ... Nvidia blob doesnt touch it but nouveau does
19:05 karolherbst: mupuf: well for backlights you use backlight_device_register
19:05 karolherbst: but leds.. let me check
19:06 mupuf:thinks we will get a ton of negative comments for this, but whatever
19:06 karolherbst: led_classdev_register
19:06 karolherbst: ...
19:06 mupuf: comments along the line of : "they have nothing else to do?"
19:06 mupuf: karolherbst: seems easy-enough!
19:06 karolherbst: yeah
19:06 mupuf: let's go for it :D
19:06 karolherbst: easier interface
19:07 karolherbst: struct led_classdev
19:07 karolherbst: lol
19:07 karolherbst: how cheap that is
19:07 karolherbst: some constants
19:07 karolherbst: and like one func pointer required
19:07 karolherbst: ohh wait
19:07 karolherbst: three if you want it to be usefull
19:07 RSpliet: karolherbst: the challenge is not relying on external APIs in NVKM ;-)
19:08 karolherbst: RSpliet: that's for nouveau_led.c
19:08 RSpliet: exactly! :-D
19:08 karolherbst: RSpliet: I think it will just put inside the display engine where the backlight is
19:08 karolherbst: same code in the end
19:08 karolherbst: just a type flag or something
19:09 mupuf: karolherbst: no type flag
19:09 mupuf: no need
19:09 mupuf: expose the PWM controllers
19:09 mupuf: and leave it there
19:09 karolherbst: ahh right
19:09 mupuf: just take two parameters: frequency, duty
19:10 karolherbst: and nouveau_led.c will just search for a LOGO_LED_PWM
19:10 mupuf: for the LEDs, that will be 100 Hz
19:10 mupuf: yes, and look for the right PWM controller to drive
19:10 karolherbst: right
19:10 karolherbst: maybe we should add a PWM subdev
19:10 karolherbst: :D
19:11 mupuf: that would be called a convinience library
19:11 mupuf: not really a subdev
19:11 karolherbst: mhhokay
19:11 mupuf: oh, and use the clock source 1, since it is apparently the one connected to the crystal
19:11 mupuf: I wonder what the other clocks arre
19:13 karolherbst: mupuf: well in the end you should write the stuff, because can't test it anyway
19:13 mupuf: ack
19:13 karolherbst: but 780 Tis should also have those LED stuff
19:14 karolherbst: Tom^: why didn't you say anything!
19:14 karolherbst: :D
19:14 Tom^: i know nothing of these accusations.
19:14 karolherbst: you have a LED on your gpu
19:14 karolherbst: and nouveau will add support for it!
19:14 karolherbst: killer feature for 4.8
19:14 Tom^: uhm
19:15 karolherbst: mupuf: any idea what is the difference between SLI_LED_PWM and LOGO_LED_PWM ....
19:15 Tom^: only if it can blink intune with my mpd music
19:15 karolherbst: do I really asked that?
19:15 karolherbst: Tom^: no idea if you can add userspace triggers
19:15 karolherbst: but maybe alsa has something fancy
19:15 mupuf: karolherbst: yes
19:15 karolherbst: mupuf: the titan also has both
19:16 mupuf: the SLI LED is when you have two gpus in SLI, there is an SLI bridge
19:16 karolherbst: playing with the SLI LED ...
19:16 mupuf: and this one has an LED
19:16 karolherbst: ahhh
19:16 karolherbst: the bridge has the LED then?
19:16 mupuf: Tom^: you can always write that script in the userspace :p
19:16 mupuf: karolherbst: yes
19:17 karolherbst: but I am sure you can do a lot of fancy stuff in windows with the logo led
19:17 mupuf: ok, how do you debug the frequency used? Well, slow down the frequency enough so as watches can time them :D
19:17 mupuf: and here I stand, doing PWM at roughly one second :D
19:17 mupuf: err, 1Hz
19:18 mupuf: 1.6 Hz, to be precise
19:18 karolherbst: oh no...
19:19 karolherbst: only maxwell adds more colors to the LEDs
19:19 karolherbst: mupuf: guess more work for you then
19:19 mupuf: AHAH
19:20 mupuf: ok, set it to 2 Hz, let's verify that
19:21 karolherbst: I just found out what 125 and 126 GPIO types are :D
19:21 karolherbst: allthough they are "reserved"
19:21 mupuf: ok, verified that it was indeed 2 Hz
19:21 mupuf: what are they?
19:21 mupuf: they were reserved in 2013
19:21 karolherbst: mupuf: what do you think? "GPIO 25: line 25 tag 0x7d [???] OUT DEF 0 param 1 gpio: normal SPEC_OUT 0x59 [PWM_1]" and "GPIO 26: line 26 tag 0x7e [???] OUT DEF 0 param 1 gpio: normal SPEC_OUT 0x5c [PWM_0]"
19:21 karolherbst: on a gm200
19:21 mupuf: does not mean they have not been allocated since then
19:21 RSpliet: R and B?
19:21 karolherbst: :)
19:21 karolherbst: pmoreau: it is yours :p
19:23 karolherbst: I know those maxwells have multicolor support in the logo LED
19:23 karolherbst: and it would be weird if it wouldn't be those two
19:23 pmoreau: karolherbst: ? My GM206 would have multicolor logo LEDs?
19:23 karolherbst: pmoreau: gm200
19:23 pmoreau: Oh, that one
19:23 karolherbst: you added a gm200 vbios :p
19:23 karolherbst: yeah
19:23 karolherbst: that one
19:24 karolherbst: those LEDS are expensive!
19:24 pmoreau: :-D
19:24 karolherbst: that's why they are only in x70+ gpus
19:24 mupuf: karolherbst: ... clock source 0 is ... unconnected?
19:24 mupuf: I wonder if it really is a clock source and not simply an enable bit
19:24 mupuf: that would make more sense
19:24 karolherbst: mupuf: no idea?
19:25 mupuf: especially sicne it is consistent with nvidia's design
19:25 mupuf: (enable bit on bit 30)
19:25 mupuf: 31 for commit
19:25 karolherbst: pmoreau: do you think you can do some REing on the gm200?
19:26 RSpliet: mupuf: there goes your "no REing necesserary" plan
19:27 mupuf: RSpliet: well, yeah, that was for "no REing necessary" for the PWM part
19:27 pmoreau: mupuf: I have seen a 980 (or was it 980 Ti) which had LEDs on each power connector: red if unplugged, white if plugged :-D
19:27 mupuf: but the clock tree needed love
19:27 mupuf: and ... seems like it is not needed and they were freaking sensible
19:27 mupuf: hook the PWM directly to the crystal clock
19:27 mupuf: and be done with it
19:28 pmoreau: karolherbst: Theoretically, I’m not allowed to. Pratically, even if I could, I do not have time… :-/
19:28 mupuf: pmoreau: yes, I have them too, but this is hardwired logic
19:28 pmoreau: Right, would be really weird to have the driver take care of that
19:29 karolherbst: pmoreau: I see
19:33 mupuf: hmm, funny
19:35 karolherbst: at least with that added nobody can say that nouveau doesn't support controling those LEDs! This is like suport important for some
19:36 mupuf: mwk: Hey, do you remember anything about this 1ff31796808a35bb6d6de9a8ab58f738c6e03e27 ?
19:36 mupuf: it is SOR.PWM.CLOCK_SOURCE
19:37 mupuf: I see that mjg59 clears this bit in his nouveau_backlight.c driver, but on my kepler, doing so kills the clock, which makes me believe this is just an enable bit
19:38 mupuf: no idea if it is used on GT215+ though, so noone may have seen this issue in practice
19:38 Tom^: but what usefulness does the led have?
19:38 Tom^: Ò_o
19:38 mupuf: Tom^: giggles
19:38 karolherbst: Tom^: only the worthy ones know!
19:38 Tom^: haha
19:39 mupuf: Tom^: see, I may have found a bug in the backlight code :p
19:39 karolherbst: right those code isn't really that much tested anymore
19:40 karolherbst: *this
19:42 mjg59: mupuf: I was just copying that from somewhere else, IIRC
19:42 mupuf: mjg59: yeah, nvbios
19:42 mupuf: never looked at the code myself since we did not want to contaminate nouveau
19:42 mupuf: but it seemed to be pretty hackish :p
19:44 mupuf: mjg59: thanks for the info anyway
19:53 mupuf: do we even care enough to expose the PWM controllers through core/?
19:55 karolherbst: I doubt it
19:56 mupuf: the vbios repo only shows SOR1 being used
20:03 karolherbst: mupuf: well from a nouveau_led.point of view we just need to know how many leds there are and what is the value range
20:03 mupuf: what do you mean by range of value?
20:03 karolherbst: min/max
20:03 mupuf: what the heck? We are using an LED, the range is always 0->100%
20:04 mupuf: fans have a min because they are mechanical
20:04 karolherbst: yeah I know, but the linux API wants this
20:04 mupuf: well, it will get 0-100
20:04 karolherbst: mhh, low accuracy
20:04 mupuf: or 0-255, for increased accuracy
20:04 karolherbst: :p
20:04 karolherbst: my intel backlight has like 0-4770 or something
20:05 mupuf: well, then I could expose the entire accuracy
20:05 karolherbst: ohh wait, that was my old laptop
20:05 karolherbst: this one has 0-976
20:05 karolherbst: mupuf: yeah, userspace is suppose to handle it
20:05 mupuf: 270000
20:05 mupuf: that is bigger than 16 bits though
20:05 karolherbst: ohh 16 bit is max?
20:05 mupuf: I think I will stick to 32k that should be enough
20:06 mupuf: nope, it is not, but stupid userspace may rely on 16 bits
20:06 karolherbst: mhhh
20:06 mupuf: and I will make it a signed int16, just to be sure
20:06 karolherbst: they shouldn't? :D
20:06 mupuf: yeah, right
20:06 mupuf: but seriously, there is no point in having a better resolution
20:06 karolherbst: ohh wait
20:06 mupuf: 1000 would be a good number anyway
20:06 karolherbst: led subdev does something differently
20:06 karolherbst: http://lxr.free-electrons.com/source/include/linux/leds.h#L28
20:07 karolherbst: ...
20:07 karolherbst: the heck
20:07 karolherbst: why expose max then
20:07 karolherbst: ....
20:08 karolherbst: this could be soo simple and then they do stuff like that
20:08 karolherbst: ....
20:08 mupuf: right :D
20:08 mupuf: Oh well, 255 it will be then!
20:08 mupuf: that should be accurate enough
20:08 karolherbst: you know what?
20:09 karolherbst: we just ignore this stupidness on the nouveau_led level
20:09 karolherbst: and deal with it there
20:09 karolherbst: maybe there are some OS with saner interfaces out there
20:09 mupuf: nope, let's be compliant
20:09 karolherbst: mupuf: well we can map values in nouveau_led
20:09 karolherbst: that's what I meant
20:09 mupuf: nouveau_led.c is linux-only
20:09 karolherbst: ohh okay
20:09 mupuf: so, no, seriously
20:09 karolherbst: yeah, k
20:14 karolherbst: but seriously, why they do this...
20:15 karolherbst: well maybe the first user was really those caps lock things
20:15 karolherbst: and more specilized LEDs are usually inside backlight
20:17 mupuf: possible, yes
20:34 Tom^: karolherbst: i dont think i have an led
20:34 Tom^: it seems to be the logo on the heat sink? , ive sort of replaced the original heat sink with a custom one
20:37 karolherbst: yeah
20:37 karolherbst: the logo it is
20:38 karolherbst: but hte original one should have some wires or some connectors for the LEDs
20:39 Tom^: if so it uses one of the pins where the fan was plugged in
20:39 Tom^: because i didnt notice anything special when i replaced it with this one https://www.arctic.ac/eu_en/accelero-xtreme-iv.html
20:40 karolherbst: "high end" and no LED?
20:40 karolherbst: cheap stuff
20:40 karolherbst: wouldn't buy it
20:41 Tom^: =D
20:41 Tom^: dont make me solder one on to it
21:02 hakzsam_: imirkin, they are some compute precision tests from deqp which fail, but I don't remember exactly which ones
21:07 imirkin_: hakzsam_: i think ldexp, which is due to glsl ir, which i think was fixed
21:07 imirkin_: hakzsam_: and i think the rest is like acos or atan
21:07 imirkin_: which is due to stupid polynomial issues, not to worry about imo
21:09 hakzsam_: oh okay
21:09 hakzsam_: yeah, I remember now
21:10 hakzsam_: so, it's definitely not related to that tomb raider
21:17 imirkin_: and the ldexp thing was only weird inf cases, so... probably not the cause of the issues
21:22 hakzsam_: yeah
21:52 karolherbst: mupuf: any other troubles so far?
21:52 mupuf: karolherbst: the driver is written ... just untested. Struggling with the last linuxism.
21:52 mupuf: how to go from a struct device to a nouveau_drm
21:53 karolherbst: I do something nifty in debugfs
21:53 karolherbst: mupuf: can you pass data?
21:53 mupuf: nope, you cannot give driver data
21:53 mupuf: this is retarded :s
21:54 karolherbst: then the hwmon way
21:54 mupuf: so, I need to take the parent device of the led device
21:54 imirkin_: mupuf: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nouveau_drm.c#L644
21:54 imirkin_: that's to get a drm_device
21:54 imirkin_: and then you can just do nouveau_drm(drm_dev)
21:54 karolherbst: I don'tthink device has to be the pcie node in this case
21:54 mupuf: imirkin_: ah! Thanks!
21:54 imirkin_: not sure what pcie has to do with it
21:54 imirkin_: it does have to be a pci device though
21:55 imirkin_: so this won't work for the platform device case
21:55 karolherbst: ohh, no,the led class uses the same device node
21:55 imirkin_: there's a way to handle it for platform devices as well (i.e. gk20a/gmb20b)
21:56 imirkin_: [you can look in nouveau_platform.c for how that's handled]
21:56 karolherbst: dev_get_drvdata?
21:57 karolherbst: in hwmon: https://github.com/karolherbst/nouveau/blob/master_4.5/drm/nouveau/nouveau_hwmon.c#L494
21:57 imirkin_: right, that works too i guess
22:05 mupuf: oh well, it did something :D
22:05 mupuf: looks like it crashed when trying to read the registers :D
22:08 karolherbst: mhh, odd :D
22:13 naptastic: imirkin, are you still around? I'm in front of my affected machine now and would love some assistance if you're still able to help.
22:14 naptastic: dmesg here: https://dpaste.de/EVug
22:14 naptastic: Xorg.0.log here: https://dpaste.de/CVvg
22:15 RSpliet: naptastic: start with this one: [    3.853787] nouveau 0000:08:00.0: Direct firmware load for nvidia/gm206/fecs_inst.bin failed with error -2
22:15 naptastic: Ah hah! What's error -2? ENOENT?
22:15 naptastic:goes looking
22:15 RSpliet: probably "file not found"
22:16 RSpliet: you'll need NVIDIAs provided firmware for that
22:16 naptastic: Google suggests I need firmware-misc-nonfree (Debian Sid).
22:16 naptastic: and there it is.
22:16 RSpliet: possibly, the firmware is not OSS unfortunately
22:16 naptastic: I'm guessing I'll need to restart X?
22:16 naptastic: or the whole system?
22:16 RSpliet: reboot
22:16 naptastic: kk, bbiam then
22:20 karolherbst: well
22:20 karolherbst: let's hope the package is new enough
22:23 naptastic: RSpliet, I'm getting the same message; I didn't read closely enough. Installing firmware-misc-nonfree gave me a file by that name, but in a different directory.
22:23 naptastic: /lib/firmware/nvidia/gk20a/fecs_inst.bin instead of nvidia/gm206/fecs_inst.bin
22:23 RSpliet: ah right, that's not the same firware
22:24 RSpliet: (this one's for the Tegra K1)
22:24 naptastic: Hm, interesting.
22:24 naptastic: What I have is: 08:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)
22:24 RSpliet: the firmware files you need have only been released a few days ago, you might want to ask the debian folks for help here
22:25 naptastic: I'm on Sid; maybe I just need an update / dist-upgrade
22:25 naptastic: I can try that, then go get dinner ;)
22:26 imirkin_: naptastic: you need firmware for gm20x
22:26 imirkin_: naptastic: linux-firmware should contain the relevant data
22:26 imirkin_: naptastic: also note that you'll need linux-4.6-rc1 or later in order to get it to load
22:27 naptastic: oh, hm
22:27 imirkin_: naptastic: you are the proud owner of a super-locked-down gpu which requires firmware supplied by nvidia, because it has to be signed
22:27 naptastic: that's hilarious and tragic.
22:27 imirkin_: aka the GM20x series
22:27 naptastic: I do my own kernels, so I'll roll up a 4.6 here shortly.
22:28 naptastic: Where do I get the firmware blob, and where do I put it? It's not in firmware-misc-nonfree, and I'm not sure...
22:28 naptastic:looks around
22:29 mupuf: naptastic: distro problem, not our problem ;)
22:29 naptastic: lawl, ok
22:29 mupuf: it is in linux-firmware, as imirkin_ said
22:30 naptastic: let me ask this, then: if Debian doesn't provide it (and apt is locked atm so I can't look) can I extract it from the Nvidia installer?
22:30 mupuf: it is a pretty recent addition, so if you are running distros like debian, it will not be there yet
22:30 mupuf: nope, just dowload it from cgit
22:30 naptastic: URL?
22:31 mupuf: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/nvidia
22:31 naptastic: <3
22:31 naptastic: (that probably saved me 10 minutes of wandering around like John Travolta looking for his jacket)
22:32 mupuf: ah ah
22:35 karolherbst: mupuf: I'll guess we have to wait for 4.8 for the reclocking stuff :/
22:36 karolherbst: mupuf: ohh wait, did you saw my findings about the rail table?
22:36 mupuf: karolherbst: yes, this is way too late now
22:36 mupuf: what findings?
22:36 karolherbst: https://github.com/envytools/envytools/commit/f29db85c12ead892aea0c0e9da21375604ef7ba5
22:36 karolherbst: this :D
22:36 mupuf: I saw some, for sure
22:37 mupuf: what does config mean?
22:37 karolherbst: extdev config
22:37 karolherbst: you know, the 0x0 i2c reg
22:37 mupuf: oh, fun!
22:37 karolherbst: yeah
22:37 karolherbst: and I think they use one sense entry for the ina3221
22:37 mupuf: very hacky too
22:38 karolherbst: because there are place for three mohm values
22:38 karolherbst: "05 00 05 00 05 00" on the titan
22:38 karolherbst: first byte is 0x5
22:38 karolherbst: (index)
22:38 mupuf: ...
22:38 karolherbst: exactly
22:38 mupuf: I wonder what the heck the rest is
22:38 karolherbst: yeah, no clue
22:38 karolherbst: it is 40 something forme
22:39 mupuf: so, the drvdata thingy is not gonna fly
22:39 karolherbst: 0a40
22:39 mupuf: reason: leds already uses it
22:40 mupuf: and ... they call functions before I can set it up
22:40 mupuf: so... no wonder it crashed
22:40 karolherbst: ohhh
22:40 mupuf: well, container_of it will be then
22:41 karolherbst: is 16394 some special value regardin resistors?
22:41 karolherbst: :/
22:41 karolherbst: I don't know if the ohm value is 8 or 16 bit though, couldn't really check
22:41 karolherbst: I think though
22:41 naptastic: probably more convenient to manufacture, like 4.70 * 10^x
22:41 karolherbst: mupuf: fun fact though, and this is no joke, if you disable a channel on the ina3221, the old value just stays forever
22:42 karolherbst: second funny thing: even after I copied my rail entries into the titan vbios, and faked it, nvidia still read all three channels (even when I disable one, two or all in the config red)
22:42 karolherbst: *reg
22:42 karolherbst: the channels are disabled, but old data is still there
22:43 karolherbst: and nvidia just reads it out
22:43 karolherbst: on all three channels
22:43 naptastic: ok, cool, firmware for my card is (probably?) where it should be. Now for a 4.6 kernel...
22:47 mupuf: karolherbst: ah ah, that explains!
22:47 karolherbst: yeah somehwat
22:47 mupuf: 8 bits is enough for the resistor
22:47 karolherbst: nouveau reads the same value when I just read out all three channels
22:47 karolherbst: yeah, but what could the other byte be
22:48 mupuf: if it is always 00, then it is a 16 bit value
22:48 karolherbst: "05 00" when "enabled"and "0a 40" when disabled
22:48 mupuf: here you go, it is a 16 bit value with flags
22:49 karolherbst: ....
22:49 karolherbst: meh
22:49 mupuf: and bit 14 is likely: disabled
22:49 karolherbst: and that's why there are 8 more bytes
22:49 karolherbst: which are usually empty
22:50 karolherbst: mhh
22:50 karolherbst: mupuf: well as I said: I couldn't bring nvidia to not read the channels
22:50 karolherbst: maybe it does an initial read on the i2c bus and checks for non 0?
22:50 karolherbst: no clue
22:51 karolherbst: it isn't in the extdev or sense table
23:07 karolherbst: mmiotrace fix is queued up for 4.3 4.4 and 4.5 kernels
23:08 mupuf: karolherbst: yeepee!
23:08 mupuf: the driver seems to work also for the LED
23:08 karolherbst: yay
23:08 karolherbst: what went wrong?
23:09 mupuf: nothing
23:09 mupuf: I just went with the container_of approach
23:09 karolherbst: okay
23:09 mupuf: but I got hungry and went for a snack
23:09 karolherbst: :D
23:09 karolherbst: and in a few das, the sun would still shine
23:10 karolherbst: *days
23:10 mupuf: div = 27000, duty = 13447
23:10 mupuf: I think I put one 0 too many for the frequency
23:10 karolherbst: now we can do funny things with that LED :)
23:11 mupuf:is also losing a lot of time because the nv17 fails to idle channel 0 on unload
23:11 karolherbst: well it is up to the user doing something usefull with it anyway
23:11 karolherbst: mhh
23:11 karolherbst: odd
23:12 karolherbst: well unloading nouveau isn't the most tested thing
23:12 karolherbst: sometimes
23:12 karolherbst: it just crashes my kernel
23:12 mupuf: nv17 is not tested at all
23:13 imirkin_: hm?
23:13 imirkin_: oh, nouveau module unload
23:13 imirkin_: just remove it
23:13 mupuf: remove the card?
23:13 imirkin_: ya
23:13 mupuf: ack
23:14 mupuf: don't you want to have a look soonish?
23:14 mupuf: it just slows down the unload
23:14 mupuf: it eventually works
23:14 imirkin_: hm, well i don't remember that happening before
23:14 imirkin_: maybe skeggsb has some ideas why
23:14 imirkin_: i was going to stick the NV34 into my box and then teach nouveau_vieux to work with it
23:14 karolherbst: mupuf: could you check where it hangs?
23:14 imirkin_: so that i could do some testing with it
23:15 imirkin_: and also maybe fix the color + depth junk on nv30
23:15 mupuf: karolherbst: nouveau 0000:04:02.0: DRM: failed to idle channel 0 [DRM]
23:15 karolherbst: I know there are some worker related race conditions on unload
23:15 karolherbst: where a new task is schedule while nouveau already began unloading
23:15 imirkin_: mupuf: well, try to grab skeggsb's attention maybe
23:15 mupuf: imirkin_: I think this is already done ;)
23:16 karolherbst: mupuf: yeah I mean where does the corresponding kworker is stuck
23:18 mupuf: ok, let's test suspend / resume and we should be good to go
23:26 mupuf: seems like testing is gonna be hard
23:26 mupuf: the machine fails to resume
23:26 mupuf: even without nouveau loaded
23:27 karolherbst: meh :/
23:27 karolherbst: well somebody will report something
23:27 karolherbst: Tom^ can tests though
23:39 mupuf: the heartbeat trigger is fun!
23:39 mupuf: it makes the LED blink like a heart beat
23:39 mupuf: and the heart beat rate is taken from the loadaverage 1 minute
23:45 naptastic: ok, so I'm on Linux 4.6.0-rc6 now; the nouveau module is loaded; there are no firmware errors in dmesg (actually no firmware-related messages at all)
23:46 imirkin_: cool, you should be good
23:47 naptastic: glxinfo still says the vendor is SGI, 3D is still being handled by LLVMpipe, and video is still choppy :(
23:48 naptastic: Lemme try VLC though.
23:48 imirkin_: naptastic: pastebin xorg
23:48 naptastic: https://dpaste.de/szZX
23:49 imirkin_: [ 4.097] EGL_MESA_drm_image required.
23:49 imirkin_: [ 4.099] (EE) modeset(0): glamor initialization failed
23:49 imirkin_: what version of mesa do you have?
23:50 naptastic: Whatever sid is shipping. How do I find out? (about to dpkg-query)
23:50 imirkin_: glxinfo | grep Mesa
23:50 naptastic: 11.1.3, looks like?
23:51 naptastic: yeah, 11.1.3
23:51 naptastic: do I need a newer one?
23:51 imirkin_: yeah
23:51 imirkin_: you need 11.2 for GM20x
23:52 naptastic: hmm... if I remove the Debian-provided mesa, how much other stuff will have to disappear? Or, if I compile my own and install over Debian's, how much damage might I do?
23:52 imirkin_: dunno, i don't do debian
23:52 naptastic: Roger. Digging...