12:30 RSpliet: http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#scalar-video-instructions-vmad
12:31 RSpliet: that "plus one" mode sounds sort of interesting to know about?
13:26 imirkin_: RSpliet: yeah, plus one modes are pretty common
13:40 RSpliet: imirkin_: I recall them supported all the way back in NV30
13:41 RSpliet: just wasn't sure whether we have this stuff supported in nouveau or detected in envytools
13:41 RSpliet: also... how does a 352bit memory bus work? What the heck is the 1080 Ti doing on their memory bus?
13:42 imirkin_: well, it's usually with like the neg bits or something
13:43 RSpliet: imirkin_: yeah, adders have a spare carry in that can be used to do a free negate of integer (invert all bits +1), but apparently you can also just use the plus-one separately
13:44 RSpliet: Oh, you're referring to the opcode fmt, I guess I can take a look next time I trace a Cuda program
13:45 imirkin_: well, when both neg bits are set, you get a +1
13:45 imirkin_: or something like that
13:45 imirkin_: (so you can't just set both neg bits on a IADD)
13:48 dboyan_: imirkin_: I have tested the v2 patch before posting on gp107 and gk208. I think it's okay now.
13:49 imirkin_: dboyan_: cool
13:53 dboyan_: btw, I got a gtx 960 several days ago. I can also play with that one if I find a suitable machine in my lab and plug it in.
16:06 Marex: Hi, does the following look familiar ?
16:06 Marex: [ 365.545442] nouveau 0000:01:00.0: clk: failed to raise voltage: -22
16:06 Marex: [ 365.545450] nouveau 0000:01:00.0: clk: error setting pstate 2: -22
16:06 imirkin_: yes
16:06 Marex: imirkin_: oh hey
16:07 Marex: imirkin_: this time it's not on an arcane quadro nvs, hehe
16:07 Marex: NVIDIA Corporation GK107M [GeForce GT 650M Mac Edition]
16:08 imirkin_: are you using kernel 4.10?
16:08 Marex: imirkin_: happens when fiddling with pstates in debugfs
16:08 Marex: imirkin_: 4.9
16:08 imirkin_: use kernel 4.10
16:08 Marex: imirkin_: fixed there or something ?
16:09 imirkin_: yes.
16:09 Marex: imirkin_: ok, experimental has 4.10.7, will try that, thanks
16:46 leberus: karolherbst hi, i've sent v5 dropping the check you pointed out ;;)
17:39 rubdos: PyroSamurai not here? :(
17:39 rubdos: Anyhow, I've got NVIDIA Corporation G84GLM [Quadro FX 570M], but I'm not sure anymore that my crashes of yesterday were due to nouveau or not
17:40 imirkin_: likely that they were.
17:40 imirkin_: when in doubt, blame the project with the fewest resources and least ability to refute the claim :)
17:41 rubdos: I'm on proprietary now (shame on me!), and I don't have them anymore. But I also use another object in Pronterface, so I'm not sure :/
17:41 rubdos: Well, blame is easy: I blame nVidia :P
17:41 rubdos: It's a thinkpad, so that's probably not it (y)
17:41 imirkin_: success!
17:41 rubdos: Thanks :)
17:44 rubdos: In any case: offer is still there. If you guys want a T61p with that card, for RE, ask me. I'd gladly donate one.
18:06 pmoreau: xexaxo1: Ping
18:43 Horizon_Brave: hey everyone
18:46 pmoreau: Hello
19:40 Marex: imirkin_: nice, it works, I almost fried my laptop :)
19:42 Marex: guess I need something better to play flightgear though, either try running it natively on that card instead of DRM_PRIME or buy a better card
19:44 Marex: actually, with 4.10 and x 1.19, even the tearing on the intel card is gone
19:44 Marex: interesting
21:20 adsworth: Hi, I have a Dell Latitude E6410 with a NVIDIA GT218 running Fedora 24. Since Fedora upgraded to kernel 4.10 I get sporadic system freezes. My guess is nouveau since that has been having quirks for years on this notebook. Where can I start collecting information to check what might be wrong?
21:37 skeggsb: adsworth: what 4.10 kernel do you currently have?
21:37 skeggsb: adsworth: kernel-4.10.12-100.fc24 has a fix for an issue that could cause a number of random issues to occur
21:38 adsworth: I have 4.10.10
21:38 adsworth: I also just found a stack trace or something similar in the journal http://dpaste.com/3D6YSC2
21:39 skeggsb: yeah, it looks likt 4.10.12 will be the fix you're after
21:39 adsworth: nice!
21:40 adsworth: it's in fedora testing repo since yesterday.
21:40 karolherbst: skeggsb: when will you find some time to look over my patches again?
21:41 karolherbst: or was there something I actually should change already and I just forgot about it?
21:42 skeggsb: karolherbst: i'm slowly getting there. among other things, i'm trying to fix 100676, which is rather complicated :/
21:43 karolherbst: mhh, sounds like a messy bug indeed
21:43 skeggsb: nope, nothing as of yet, i just wanted to have a deeper look into the issues you were trying to solve before acking the approach
21:43 karolherbst: okay
21:44 Lyude: would someone mind taking a quick look at this? https://github.com/Lyude/linux/tree/wip/fermi%2B-clockgating-v2 this branch is complaining that nvkm_therm_clkgate_engine is not defined when I try to compile it. It's gotta be a matter of me not modifying some Kbuild file somewhere or something like that to expose that function to nouveau/nvkm/core/engine.o but I'm not sure what
21:45 karolherbst: skeggsb: I think this splitting up of the update function isn't required, I think my main intention was to just have simplier code on pre fermi GPUs. I could try if you prefer it to merge the code and still provide a fast path for the older models
21:45 karolherbst: Lyude: you forgot an include
21:45 Lyude: ahhh, should have guessed
21:46 Lyude: thanks!
21:46 karolherbst: mhh, but I don't know where exactly, odd
21:46 Lyude: well I only touched a couple of files, so I can just check all of them :P
21:47 karolherbst: is the warning/error inside therm/clkgate.c?
21:47 Lyude: no, it's at the end of the build process
21:47 karolherbst: ohhh
21:47 Lyude: when it tried to link nouveau.ko
21:47 Lyude: *tries
21:47 karolherbst: okay, then you indeed forgot to add the file to Kbuild
21:47 karolherbst: mhhh
21:47 karolherbst: but you added it
21:47 karolherbst: super odd
21:48 karolherbst: let me check
21:48 Lyude: yeah, that's why I'm a lil confused here. i'm sure it's something useful but I figured you guys would pick it out a lot quicker then I would since you're more familiar with this driver
21:48 Lyude: *something simple
21:55 starstuff: Nouveau driver in kernel 4.9 supports the Nvidia GTX 1070?
21:57 Lyude: new people on IRC are always so impatient
21:57 karolherbst: maybe we should have a bot
21:57 Lyude: some IRC daemons have the ability to force you to join channels…
21:57 Lyude: hehe
21:58 karolherbst: mhh, the error is inside ore/engine.c
21:59 Lyude: so it is a missing include?
21:59 karolherbst: no
22:00 karolherbst: you simply removed the function
22:00 Lyude: ...OH
22:00 Lyude: okay, haha, sorry about that
22:03 Lyude: karolherbst: btw, if I can help at all with reviewing some of those patches (not sure if I have the cred in nouveau yet) let me know
22:07 karolherbst: just leave comments if you feel like you can give valuable feedback
22:08 Lyude: gotcha
22:08 karolherbst: (get skeggsb to trust your judgments so that he just merges stuff if you tell him to merge something :p )
22:09 Lyude: hehe, to be honest I wouldn't trust myself in nouveau just yet
22:09 karolherbst: doesn't matter as long as he trusts you :p
23:35 mooch2: Lyude, i mean, mwk trusts me when it comes to envytools lol
23:36 mupuf: Lyude: thanks for your patches
23:37 Lyude: mupuf: np
23:37 mupuf: I will actually be even more drastic than Ben
23:37 mupuf: and I would say that enabling clock gating, even ELPG, is dangereous
23:37 mupuf: do you understand what brownouts are?
23:37 mupuf: and what all these registers do?
23:38 Lyude: mupuf: yeah, brownouts are when electrical components don't get enough power. and those registers control whether or not the GPU stops emitting clock signals for the respective engines when they're not being used
23:39 mooch2: hey, speaking of nouveau, what kind of opengl support can i expect on a gm107?
23:39 mooch2: or, more specifically, gtx 750ti
23:41 Lyude: i am with you though, this is dangerous if we don't do it right
23:41 RSpliet: mooch2: Think OpenGL 4.3 core profile with all the feature of GL 4.5
23:41 Lyude: went through as many mmio traces for the different gens to make sure we pretty much just followed the behavior of the nvidia driver, which looked to be just enabling clockgating while setting up each respective engine
23:42 mupuf: Lyude: ok, great. So, a few more things, just to check. Power consumption comes from two things, the static power consumption (entirely due to the leakage of transistors through the tunneling effect) and the dynamic power consumption (cost of switching the transistor's state, because the gate is actually a capacitor). So, the reason why nvidia has this hierarchy of clock-gating domains, it is to enable clock domains in a staged way, to reduce dI/dt in
23:42 mupuf: the power supply.
23:42 mupuf: the BLCG and SLPG registers control this
23:43 mupuf: they really are the configuration of a state machine defining when to go from the gated to non-gated and vice-versa
23:43 RSpliet: (mupuf: ELPG is of course Power Gating, not Clock Gating :-) )
23:44 mupuf: RSpliet: sure, but it impacts here too
23:44 mupuf: so does ELPG
23:45 mupuf: so, what I would like to say is: We should land everything at the same time
23:45 mooch2: RSpliet, ah, good
23:45 mupuf: because all the parameters influence each other
23:45 RSpliet: Yeah that's why I already warned that we must be careful. If we properly mimic the blob or the tegra android driver we should assume that NVIDIA did the risk assessment, but we don't as it stands right now!
23:45 mupuf: yeah
23:45 mooch2: RSpliet, also, are there any efforts currently to make a nouveau vulkan driver?
23:45 Lyude: mupuf: that sounds like a good plan
23:45 mupuf: I would say that we can skip ELPG, since it is complex
23:46 mupuf: but SLPG and BLCG and ELCG should land at the same time
23:46 RSpliet: mooch2: there may or may not be, I know nothing of its status
23:46 mooch2: well then
23:47 mooch2: yo, skeggsb, you still working on vulkan?
23:48 Lyude: mupuf: assuming BLCG = block level clockgating and ELCG=engine level clock gating, but what is SLPG?
23:48 mooch2: anyway, i have a new theory as to why nv3 drivers fail
23:48 mupuf: honestly, I do not know. I may even misremember the acronym
23:48 mooch2: VBLANK ISN'T IMPLEMENTED LOL
23:48 mupuf: it's been years :s
23:49 mupuf: I got these names from nvidia's nvgpu
23:49 mupuf: then I checked the bit fields
23:49 mupuf: mapped it to the desktop gpus
23:49 mupuf: and spent countless hours finding all the regs with this signature
23:49 mupuf: or, these signatures*
23:50 mupuf: and then, did so across generations
23:50 mupuf: I have not checked maxwell though
23:50 mupuf: anyway, the biggest power savings you should see are when you run a game.
23:51 mupuf: because the blocks will go to clock gated mode much faster, taking advantage of any stall
23:51 Lyude: yeah, I remember karolherbst mentioning that
23:52 mupuf: too bad he is gone, I would have said: good boy :D
23:53 mupuf: so, one thing though, please hide clock gating behind a debug parameter
23:53 mupuf: we need wide testing!
23:54 mupuf: the good thing really is that nvidia has been quite consistent with the values set in all the regs, so that should be easy-ish to create lists of registers to bash
23:55 Lyude: mupuf i've got each nv gen from fermi up. fermi was fine running all of the piglit tests with CG on, but i'll be more then happy to test everything on the other gens beyond just booting the machine and making sure it works
23:55 Lyude: i was also thinking we might want something that incurs more load anyway
23:55 Lyude: i can't imagine piglit puts that much stress on the GPU
23:55 mupuf: yes, you want more load than piglit ;)
23:55 mupuf: you probably will want access to reator at some point too
23:55 mupuf: I have a decent collection of gpus
23:56 mupuf: and I plug them as requested
23:56 Lyude: neat
23:56 mupuf: and you get root access on the machine
23:56 Lyude: mupuf: btw, do we have trello cards for the other gating stuff?
23:56 mupuf: I think there is
23:57 Lyude: Ah, "PM: Add power gating support"
23:58 skeggsb: mooch2: yes, i am, indirectly. mostly for kernel-side prerequisites. once they're done i'll push a skeleton vk driver that people can hack on
23:58 mooch2: ah, okay, good
23:58 Lyude: skeggsb: poke me when you do that, I'd really like a chance to help out with some of that :)
23:58 skeggsb: Lyude: absolutely