01:20karolherbst: mupuf, imirkin, imirkin_: you don't have any ideas left, what I could try out? Or is it just likely its not possible anymore and there is another way somehow?
03:20mupuf: karolherbst: if setting the frequency to 862 MHz is stable (no crashes), then the voltage is high-enough!
03:26karolherbst: its not stable
03:27karolherbst: or let me rephrase it: sometimes my system has a hang crash with 0a sometimes
03:27karolherbst: mupuf: but is there another reason why I don't get twice the performance?
03:27karolherbst: or more?
03:28karolherbst: oa has more than double gpu clock and doubled memory clock
03:28karolherbst: allthough with antichamber I got doubled performance, but doubled memory clock was enough to get this
03:29karolherbst: doubled gpu clock only got me like 10% more
03:30mupuf: karolherbst: well, if the game is memory-bound, increasing the core clock won't help much
03:30mupuf: and this also may be due to our really poor compiler
03:30mupuf: for instruction scheduling*
03:31mupuf: that would force a stall
03:32karolherbst1: .. mhh
03:32mupuf: power management is not the only problem of nouveau
03:33karolherbst1: this was in 07 state now
03:33mupuf: but congrats on getting reclocking working on your machine!
03:33huehner: hmm debian just enabled mmiotrace by default in their kernel images (not yet uploaded)
03:33mupuf: huehner: finally!!!
03:33karolherbst1: thing is: cstate doesn't seem to work in general
03:33mupuf: define work?
03:33karolherbst1: mupuf: do you want to test my cstate patches on other gpus?
03:33karolherbst1: not enabled
03:34mupuf: I have a ton of patches to review for hakzsam_...
03:34karolherbst1: let me reprhase that: pstate always sets to cstate with index 0
03:34karolherbst1: I see
03:34mupuf: hmm, always? I have seen this issue in my case too
03:34mupuf: looks like a regression
03:34karolherbst1: did you check cstates though?
03:34karolherbst1: also clocking isn't set if volting fails
03:35mupuf: right, this is unusual that there would be no voltage support
03:35karolherbst1: maybe cstates work if the 0 one sets to highest
03:35karolherbst1: but I have like 36 cstates
03:35karolherbst1: both in 0a and 0f
03:39karolherbst: mupuf: who could I ask to test the cstate work? Sadly the other card I have access to is a 630M :/
03:43mupuf: I can give you access to my reverse engineering machine
03:43mupuf: and plug the cards you want me to plug
03:43karolherbst: would be nice
03:43mupuf: I have an nve6 and nve7
03:44mupuf: desktop GPUs
03:44karolherbst: the cstate patches aren't architecture specific
03:44karolherbst: should work on every card tm
03:45karolherbst: the thing with my card was just, that 07 and 0a have the same lowest clock, so the clock didn*t change at all
03:46huehner: mupuf: i think debian 4.1 when it is uploaded will be first version to have it enabled, i can give it a spin then on my 960 to confirm
04:14karolherbst: seems like its a common problem, that X reacts not that good to a nouveau load
04:52karolherbst: iterating over the cstate of the clk->states opses for me when clk->pstate==NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT :/
05:01karolherbst: mupuf: but how does it work with the rev eng machine?
05:01mupuf: there is a webgui I designed that allows you to boot the machine
05:02mupuf: and see the LED state
05:02karolherbst: can I also see content of dmesg or whats inside sysfs?
05:03mupuf: you'll get root access
05:03mupuf: through ssh
05:04karolherbst: 4.1 kernel?
05:04mupuf: I will update everything
05:04karolherbst: I also ported my patches back to 3.19
05:04karolherbst: to test it on the fermi card
05:04karolherbst: but it won't work unless you can actually change the pstate :(
05:04mupuf: and you'll use nouveau out of the tree to easily load and reload the nouveau module
05:05karolherbst: scripts or insmos/modprobe calls?
05:05mupuf: I have scripts, but do your thing :D
05:05karolherbst: mhh, right I would need X to actually test the speed
05:05mupuf: not a problem again
05:05karolherbst: forget that it isn't a laptop there
05:06karolherbst: yeah, its easy for me here, because DRI3 doesn*t require DDX, so no open fd and stuff
05:06mupuf: this machine is used for this kind of work
05:06karolherbst: I can easily replace module while X is running
05:06karolherbst: yeah, I figured
05:06mupuf: but I am at work right now, so I can't do it now
05:07karolherbst: I can do other stuff anyway :D
05:09karolherbst: is there somebody online with the voltage change issue? Maybe you want to test part of the patches too
05:10mupuf: karolherbst: who is this?
05:11karolherbst: don't know, imirkin told me there were some with such issues
05:11karolherbst: but never told me who
05:12karolherbst: the issue where you get -22 from volt after changing pstate
05:14karolherbst: mupuf: [ 1786.479825] nouveau E[ CLK][0000:01:00.0] failed to raise voltage: -22 [ 1786.479827] nouveau E[ CLK][0000:01:00.0] error setting pstate 0: -22
05:14mupuf: well, you do not have any GPIO for changing the VID
05:14mupuf: so, no wonder it fails :D
05:15karolherbst: yeah I know
05:15karolherbst: but I couldn't change cstates or freqs
05:15mupuf: well, I would say that you need to patch nouveau so as trying to change the voltage wouldn't fail
05:16mupuf: but still throw a debug message, just for good measure
05:16karolherbst: allthough pstate did change, but not the cstate
05:16karolherbst: yeah, already did that
05:16karolherbst: fallback mechanism where it fallbacks to the nearest lower possible voltage
05:17karolherbst: the table didn't find a match with the requested voltage
05:17mupuf: oh, I get it, maybe the cstate does not change because the voltage does not go up
05:17mupuf: is that what you are trying to say?
05:17karolherbst: no, it was a code problem
05:18karolherbst: but basically yes
05:18mupuf: it sure is, the hw does not care
05:18mupuf: it will crash if you don't do the right thing, that's it
05:18karolherbst: this line: https://github.com/karolherbst/nouveau/blob/1b40601a51a3128ba8a5e19c124b47679be23302/drm/nouveau/nvkm/subdev/clk/base.c#L104
05:18karolherbst: set_id returned faulty
05:18mupuf: yeah, the patch you cooked look like patches mlankhorst and I wrote a while ago
05:18karolherbst: I see
05:20karolherbst: strange is, that there is a voltage table and everything in the rom for me :/
05:20mupuf: oh, dude!
05:21mupuf: I don;t know how imirkin missed this
05:21karolherbst: and each cstate has its own voltage entry
05:21mupuf: 129 = PWM based serial VID voltage control.
05:21mupuf: GPIO 0: line 0 tag 0x81 [???] OUT DEF 0 param 1 gpio: normal SPEC_OUT 0x5d [???]
05:21karolherbst: and he said I shouldn*t grep for gpio
05:22karolherbst: "GPIO 0: line 0 tag 0x81 [???] OUT DEF 0 param 1 gpio: normal SPEC_OUT 0x5d [???]"
05:22mupuf: well, I had completely forgotten about this craziness
05:22mupuf: I tried adding support for it on one of my gpu
05:22mupuf: possibly the maxzell
05:22karolherbst: you know I get errors about vid 3 and 7 though?
05:23mupuf: nouveau does not know how to handle this *at all*
05:23karolherbst: I see
05:23mupuf: so you should not care at all about what stupidity nouveau does
05:23karolherbst: so whats the issue then? nouveau just don't know how to speak to the gpios/vids?
05:24mupuf: ok, you don't see the problem properly
05:24mupuf: each GPU has a voltage regulator
05:25mupuf: and selecting the wanted voltage can be done by multiple means
05:25mupuf: i2c, gpios or ... PWM
05:25karolherbst: ahh, and my card needs the pwm method?
05:25mupuf: nvidia never used the i2c one
05:25mupuf: the vbios tells us that in the GPIO table
05:26mupuf: it says that GPIO 0 is actually PWM based serial VID voltage control.
05:26karolherbst: could it be, that pwm support is just missing in my kernel and nouveau can't pick it up because of that or because nouveau simply can't do it
05:26mupuf: we can see that because the tag is 0x81
05:26mupuf: and nvidia documented that in 2013 for us
05:26mupuf: look for 129
05:27karolherbst: I see it
05:28mupuf: so, to add support for this, we need to find the pwm controller
05:28mupuf: wait a sec.... I seem to remember to have found it ... unless it was the one for the fan
05:28mupuf: darn it
05:28mupuf: we are in for a treat!
05:28karolherbst: good thing: I can't control the fan anyway
05:29karolherbst: how does someone "search" for such a pwm
05:29karolherbst: should I look at the card?
05:29karolherbst: its a mxm one
05:29mupuf: nah, it is inside the chipset
05:29karolherbst: so the fan pwm should be labled I guess
05:29mupuf: and not documented
05:30mupuf: the way I do it, is changing the frequency and lookng for differences in the registers
05:30karolherbst: I think the fan is connected to my board anyway
05:30karolherbst: and not to the gpu
05:30mupuf: this is a laptop, so yes
05:30mupuf: it has nothing to do with the PWM-based VID
05:30mupuf: anyway, have to go! My benchmarks finished running
05:30karolherbst: ... sad ...
05:30karolherbst: way home or work?
05:32mupuf: I am at the office
05:32mupuf: but I do not work on nouveau in my day job
05:32mupuf: only on my spare time
05:32mupuf: which I do not seam to allocate a lot of to nouveau lately
05:33mupuf: still passionate about the project though, but summer is there, more or less!
05:33karolherbst: yeah :/
05:33karolherbst: would be nice to know what I have to do to figure out how to talk to the pwm
05:33mupuf: so, I take advantage of the fact that the sun stays up so long!
05:34mupuf: Well, I use my peek_diff tool usually
05:34karolherbst: I guess there is no "tutorial" site how to use a tool for testing nvidia cards :D
05:34mupuf: But hey, how about we look into this tonight?
05:34mupuf: of course not :D
05:34karolherbst: but I once devleoped on an arm board
05:35karolherbst: so its not that new to me anymore
05:35karolherbst: it also had 2! pwms :D
05:35mupuf: well, you seem definitely fit for nouveau development!
05:35mupuf: I'll try my best to get you started properly
05:35karolherbst: I like more writing server software though I think :D
05:35mupuf: ah ah, I would hate it :D
05:36karolherbst: I can't stand GUI development though
05:36karolherbst: not because its bad
05:36karolherbst: but because you always see dirty hacks and stuff which should ever be done
05:37mupuf: you mean, like web development on a server?
05:37karolherbst: no, anything UI related really
05:37karolherbst: I would like to do that though, but I know I am not good at it yet
05:38karolherbst: or do you mean the server dev part?
05:38karolherbst: there I like service based stuff the most, which always leads to service based architectures inside clients I have to write :D
05:38mupuf: meh, it was supposed to be a troll, but it did not work
05:38karolherbst: won't work on me I guess :p
06:11karolherbst: what are the pwms in nvatiming?
06:14mupuf: the fan ones
06:14mupuf: well, some of them
06:14karolherbst: look at this: https://gist.github.com/karolherbst/f3db380c5db889e02ca3
06:14mupuf: yeah, there are 4 of them
06:14mupuf: or 5 actually
06:14mupuf: nvidia keeps adding more
06:14karolherbst: I only have 2
06:14karolherbst: or at least the tool says so
06:14mupuf: nvatiming does not k now about the others
06:14karolherbst: I see
06:15karolherbst: mupuf: so to find the right one, we would "add" more pwms to the driver or just write a little bit higher values and see what happens?
06:15mupuf: karolherbst: you should be using the proprietary driver if you want to see what register we should update
06:16karolherbst: no problem with that, but I would like to know why :D
06:16mupuf: because nouveau does not change the reg :D
06:16mupuf: as simple as this
06:16mupuf: this is not done by the hw
06:16karolherbst: but in this nvatiming output you clearly see the difference because stock master and my patched ones. didn't know it was that much at all
06:16mupuf: it is handled by the kernel driver
06:21karolherbst: mhh nvatimings doesn't find my gpc
06:21karolherbst: oh well
06:21karolherbst: have to trust the kernel output then
06:22Nuc1eoN: hi i use nouveau and get errors at boot, look at this https://gist.github.com/Nuc1eoN/a925d32e8cb34d6aa432
06:22Nuc1eoN: dmesg + xoglog
06:22karolherbst: 740m huh
06:22Nuc1eoN: everything *seems* to work
06:23Nuc1eoN: karolherbst: what about it?
06:23karolherbst: which one? :D
06:23Nuc1eoN: nvidia 2gb i think
06:23karolherbst: ahh GK208
06:23Nuc1eoN: how cards under the same name are there? :P
06:24mupuf: karolherbst: nvatimings was meant for nv50-c0
06:24karolherbst: I think the errors aren't important
06:25Nuc1eoN: somebody with the same error seemed to have alreaddy sought for help on this irc channel http://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2015-02-07
06:25karolherbst: Nuc1eoN: are all of your video outputs connected intel?
06:25Nuc1eoN: and same cpu
06:25Nuc1eoN: karolherbst: what do you mean?My default card is intel
06:25karolherbst: yeah, but do you have hdmi, dvi outputs
06:25karolherbst: and do they work?
06:25karolherbst: what gives your xrandr
06:26Nuc1eoN: I never tried them
06:26karolherbst: all your outputs should be listed in xrandr
06:26karolherbst: bad thing is, some laptops have outputs connected to the dedicated card
06:27karolherbst: then the errors might be important somehow, because you might get the idea to conect a display and use the nouveau driver for them
06:27Nuc1eoN: karolherbst: I added xrandr outoput to gist;)
06:27karolherbst: ohh there are more errors
06:28karolherbst: yeah, seems like you are lucky
06:28karolherbst: DP, HDMI and VGA connected to intel
06:28Nuc1eoN: lucky? well that it works you mean ? :P
06:28karolherbst: you should have only these 3 right?
06:28Nuc1eoN: well its a thinkpad so i guess it's not the worst shit
06:29karolherbst: I can*t say much about the PIBUS errors though
06:29Nuc1eoN: actually i only have got hdmi and vga O.o
06:29Nuc1eoN: no dp
06:29karolherbst: do you know how to hardware hack? then you might add one :p
06:30Nuc1eoN: lol, so it is generally supported? :P
06:30karolherbst: I would say so
06:30karolherbst: oh wait
06:30karolherbst: nah, its DP over HDMI
06:31Nuc1eoN: ah ok :P
06:31Nuc1eoN: so what does all this mean for me? what do those errors mean?
06:31karolherbst: but you said everything works fine?
06:31Nuc1eoN: well it seems
06:31karolherbst: any performance intense stuff tested?
06:31Nuc1eoN: although i didnt try to connect externel monitors
06:32Nuc1eoN: karolherbst: nope just basic workflow on plasma5
06:32karolherbst: I see, you don't use the card usually
06:32Nuc1eoN: some apps seem to crash with xkb error but it might as well be the fault of the new plasma5 / qt5
06:32karolherbst: do you want to use the nvidia card at all?
06:33karolherbst: like for games or other GL intense stuff
06:33Nuc1eoN: Well, so far id didnt try because I feared the results :D I just bought this laptop and want to clear those errors
06:33karolherbst: I see
06:33Nuc1eoN: *it's a brand new laptop
06:34karolherbst: you could use the prop driver though if you want
06:34Nuc1eoN: becasue they look kinda scary
06:35Nuc1eoN: heh so whats the issue with those nouveau erros?
06:35karolherbst: the thing is for you know: do you for any reasons want only use the open driver, or is the nvidia one fine by you?
06:35karolherbst: don't know
06:35Nuc1eoN: I would like to use the open source one because i like open source :)
06:35karolherbst: isn't that important if you don't want to use the card anyway
06:35karolherbst: I see
06:35Nuc1eoN: if i need more intense stuff i oot win8 and its okay:P
06:35karolherbst: the thing is currently, that the card will use power
06:36karolherbst: a lot
06:36karolherbst: and its on all the time until you do something against it
06:36Nuc1eoN: actually prime should prevent that
06:37Nuc1eoN: or at least thats how i understand prime....
06:37karolherbst: yeah I know, but it can cause problems
06:37karolherbst: I don't know if runpm defaults to on for you or at all
06:37karolherbst: I don't use runpm, because its a little bit messy on my system
06:38karolherbst: mupuf: would you say all of these nouveau errors are kind of unimportant and he should simply test to use the card?
06:38Nuc1eoN: ac0:DIS: :DynOff:0000:01:00.0
06:38Nuc1eoN: cat /sys/kernel/debug/vgaswitcheroo/switch
06:38Nuc1eoN: gives me that it's off
06:39karolherbst: by the way "GPU voltage: 600000uv" :) looks suspicous
06:39Nuc1eoN: when it's not used
06:39karolherbst: then it seems to work
06:39karolherbst: my system just randomly crashed in the past with it
06:39Nuc1eoN: 600000uv ? uuh
06:40mupuf: karolherbst: sorry, can't answer right now
06:40karolherbst: its a different problem I try to fix today with mupuf maybe
06:41Nuc1eoN: what will you try to fix?
06:41karolherbst: Nuc1eoN: what you could do is this: just use the system as is and if something strange happens (system hangs, black screen forever, suspend doesn't work)
06:41karolherbst: reclocking stuff
06:42karolherbst: voltage can't be set on my card with current means
06:42karolherbst: and it seems you have the same issue
06:42karolherbst: but its unrelated to the errors
06:42mupuf: Nuc1eoN: no idea about your errors
06:42mupuf: but if everything seems fine, don't worry about it then
06:42karolherbst: the TMDS and flat panel table seems unimportant though
06:42karolherbst: becuase he has nothing connected to the card
06:43Nuc1eoN: do you think it might help to report it to the bugtracker?
06:43karolherbst: Nuc1eoN: if there is nothing wrong otherwise I don't think somebody will care enough to be honest
06:44karolherbst: so if you don't have something like: suspend messes up system if nouveau loaded, or nouveau OpenGL is messed up or anything, then its likely that not much will change directly
06:45karolherbst: these error could be fixed though through other issues
06:45karolherbst: but maybe the firmware is a little bit messed up or something
06:45karolherbst: I wouldn't bother too much until you have real problems
06:46Nuc1eoN: karolherbst: since intel is my main card i guess, there dont show any problems... maybe i shóuld try to activate the nvidia one by default and see what happens
06:46karolherbst: I won't do that
06:47karolherbst: this might help you to use the card
06:47karolherbst: there are "ways" to use the nvidia card for everything, but I really see the point in that
06:47Nuc1eoN: damn why does nouveau such so much
06:47Nuc1eoN: I would have taken an amd card but ffs there are no laptops with amd cards
06:48karolherbst: did you ever tried to use the card? maybe it works without problems
06:48Nuc1eoN: no, since i always just used the default configuration
06:48Nuc1eoN: somebidy on arch forums
06:48Nuc1eoN: told he has got rid of those rrors
06:48Nuc1eoN: by using bumblebee
06:49karolherbst: propritary driver then
06:49karolherbst: isn't nouveau anymore
06:49Nuc1eoN: karolherbst: https://bbs.archlinux.org/viewtopic.php?pid=1479490
06:49Nuc1eoN: bumblebee works with nouveau too
06:49karolherbst: yeah it does, but the guy uses the prop driver
06:49Nuc1eoN: so probably bad firmwarE?
06:50Nuc1eoN: since he has got the same issues
06:50karolherbst: could be everything until somebody with more knowledge says something
06:50Nuc1eoN: with same hw as far as i can tell
06:50karolherbst: to be really honest: I see a lot of hacky stuff in arch wikis, so I just say his system was messed up from the beginning anyway
06:51karolherbst: his X error most likely means, that his system tried to run X on the nvidia card
06:52karolherbst: you could do the followig if you want
06:52karolherbst: 1. blackloust nouveau
06:52imirkin: uhm, nouveau should auto-suspend the card when not in use
06:52karolherbst: 2. install only bbswitch
06:52karolherbst: 3. load bbswitch at boot
06:52karolherbst: this will not load nouveau and turn the card off
06:52karolherbst: then you mess a little bit around if you want to use nouveau later
06:53karolherbst: so you should decide how you want to use your nvidia card, so we can decide on a good solution
06:53karolherbst: or just leave the system as is and wait until something bad happens
06:53karolherbst: try suspending the system for example
06:53imirkin: Nuc1eoN: what is the problem with the present setup btw?
06:53karolherbst: imirkin: he doesn't have any ;)
06:53karolherbst: only some errors in dmesg
06:53imirkin: ignore them and move on
06:54Nuc1eoN: yeah it'S a new laptop and new system and i just wanted get get knowledge wtf happens :P
06:54karolherbst: imirkin: do you know what mupuf found for my gpu voltage problem?
06:54karolherbst: Nuc1eoN: come back if something really happens ;)
06:54imirkin: Nuc1eoN: double-check that the card is turning off... cat the vga switcheroo file and make sure it's in DynOff state
06:54imirkin: Nuc1eoN: if it is, then you're all set
06:54karolherbst: this works
06:54Nuc1eoN: imirkin: it is ;)
06:54Nuc1eoN: ok thx guys!
06:55imirkin: karolherbst: yeah, he found my incompetence. i thought i checked all the gpio's :( and i didn't see it futz with gpio's around the reclock in your mmiotrace.
06:55Nuc1eoN: there seem to be many with theat voltage issue
06:55karolherbst: will fix today (tm)!
06:55Nuc1eoN: just google "nouveau 600000uv"
06:56karolherbst: the issue is simple though
06:56karolherbst: nouveau can't read the voltage and falls back to the first entry in the voltage table
06:56karolherbst: which is exactly this value
06:56karolherbst: it can't set it either, so pstate doesn't really work on these cards too
06:57Nuc1eoN: ok cya guys :D
07:03mupuf: imirkin: yeah, I do not know where they do the write to the voltage controller
07:03mupuf: possibly in pdaemon
07:04mupuf: I know I spent some time trying to add support for my maxwell
07:04imirkin: could be. did you look at his trace?
07:04mupuf: I had completely forgotten about this issue
07:05mupuf: nope, I guess this is a job for tonight
07:05imirkin: i assumed it'd be in the reclock sequence
07:05Nuc1eoN: suspend seems to work corrrectly
07:05imirkin: but didn't find anything obvious in its proximity
07:05mupuf: it is
07:05karolherbst: Nuc1eoN: nice
07:05mupuf: but it may be a command sent to pdaemon
07:05imirkin: but all of the commands were known by the parser
07:05imirkin: not to say that one of them isn't supposed to do this ;)
07:06mupuf: oh, right!! the work of RSpliet landed
07:07mupuf: You are my king Roy!
07:08mupuf: 0x138000 may be of interest for this
07:08mupuf: or 0x08c384
07:08karolherbst: did I miss something?
07:08mupuf: 0x08c384 looks really good if we assume the duty cycle is fixed
07:09mupuf: well, actually, it looks good, full stop
07:09mupuf: the range sounds interesting
07:09mupuf: will check it tonight
07:10karolherbst: which time? So that I can plan it right :D
07:10karolherbst: or is it something else now?
07:10mupuf: I have work for two more hours
07:11karolherbst: okay, no problems
07:11karolherbst: I have to work too, but I work at home, so its fine :D
07:12karolherbst: html gui stuff though :(
07:12imirkin: aka the stuff you said you hated?
07:12karolherbst: I don't hate it
07:12karolherbst: I only get the feeling everything will break in a day
07:13karolherbst: its always depressive to look at gui code
07:13karolherbst: aka work in GUIThread stuff and so on :O
07:13karolherbst: then I always think: how could someone
07:13karolherbst: like in 99% in all mobile apps
07:15karolherbst: but its only for this day and one another, then its backend time again
07:23karolherbst: is there anybody working on fermi pstate stuff currently?
07:26mupuf: noone is working on reclocking except RSpliet
07:26mupuf:stoppped working on it ages ago... and never managed to get back to it
07:27karolherbst: today :p
07:27karolherbst: kind of
07:27mupuf: yeah, voltage management
07:28mupuf: kind of :D
07:28mupuf: but this is mostly REing
07:28mupuf: that, I have not stopped
07:28karolherbst: I hope we will get this working, will be awesome
07:28karolherbst: and I hope my cstate stuff will help cards with working volt stuff too. WIll be interesting
07:29imirkin: mupuf: wait, so why didn't skeggsb like the inexact match thing for voltage?
07:29imirkin: we'll need that anyways even if we find how to work the voltage regulator...
07:29mupuf: oh, was it skeggsb who turned it down?
07:30imirkin: mupuf: you said that approach was rejected
07:30mupuf: that seems to ring a bell
07:30mupuf: ah, possible
07:30imirkin: i can't imagine anyone else who would have done the rejecting :p
07:30mupuf: rejected or never submitted?
07:30imirkin: ah, maybe never submitted
07:30mupuf: mlankhorst was the one with the most complete patchset
07:30mupuf: I bugged him a lot to finish the REing of the voltage table
07:31mupuf: which is full of weird stuff
07:33mlankhorst: I have no idea where the constants came from..
07:34imirkin: mlankhorst: iirc you had a branch somewhere with nouveau patches that were never upstreamed... but i can't find it
07:34imirkin: is it gone?
07:34mlankhorst: no idea, should be master
07:36imirkin: mlankhorst: master of http://cgit.freedesktop.org/~mlankhorst/linux/ ?
07:37mlankhorst: think so
07:37karolherbst: whats that?`http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=eba67a7e007f3f79cd56379c257273b2f06f6d6f
07:38imirkin: ah yeah, there it is, off the front page. (the guard pages)
07:38karolherbst: imirkin: which one?
07:38imirkin: vm guard pages change
07:38mlankhorst: guard pages are awesome. :p
07:39karolherbst: http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=feb10f91b83c139b837ec89efcdd3022b4a457fb ?
07:39karolherbst: what does it do? :D
07:39imirkin: it adds guard pages around all allocations
07:41mlankhorst: http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=0bd462a3b50e829f964696db198f564ea5242fd7 would have identified that a flink can cause duplicate gem handles..
08:04karolherbst: on which cards are pstates currently working?
08:05mupuf: pstate = the 4 levels and cstate = boost, right?
08:05karolherbst: something like that ;)
08:06karolherbst: is this table correct?
08:06karolherbst: allthough fermi would be also "mostly"
08:07mupuf: nah, this is a bit stupid what we did
08:07mupuf: this is way too corse
08:07mupuf: and it is hard to know when we are done...
08:07karolherbst: the cstate changes should work on all cards, where you can set the pstate to the non -1 one
08:08karolherbst: even if its the 07 one, but chances are you only get one usefull cstate
08:09karolherbst: cstates currently seems pretty much tied to pstates anyway
08:09mupuf: we have no support for the pstates
08:09mupuf: err, cstates
08:09karolherbst: but before a pstate isn't set I can't get the cstates :/
08:09mupuf: well, as in, boost
08:10karolherbst: I don't talk about boost though
08:10karolherbst: its all within the pstate range without boost
08:10karolherbst: so it should be fine
08:11karolherbst: mhh but right, boosts ...
08:11karolherbst: maybe if we get it to work, I might try to get this to work, too :/
08:11karolherbst: but this will be a lot of RE
08:15mupuf: not at all
08:15mupuf: the RE is mostly done
08:15mupuf: but before boost, we need dynamic reclocking
08:15mupuf: boost is just a slightly different way of writing the reclocking algorithm
08:16karolherbst: ahh nice
08:16mupuf: we yeah, no reverse necessary
08:16mupuf: we know everything already
08:16karolherbst: also down boost reclocking?
08:16mupuf: what the heck does this mean? :D
08:16karolherbst: my card is clocked at 135MHz with blob :)
08:16karolherbst: 405MHz with nouveau
08:16mupuf: you mean downclocking
08:16mupuf: yes, it is the same feature
08:17karolherbst: that's why I said "boost" :p
08:17mupuf: dynamic reclocking, (or DVFS) is actually the concept of scaling voltage and frequency based on how much each clock domain is used
08:17karolherbst: yeah I know
08:18karolherbst: would be be possible to clock under these 405MHz yet without voltage changes or is it a hard requiernment?
08:18karolherbst: like card will be damaged otherwise or it simply won't work
08:19mupuf: why would you not want to lower the voltage?
08:19mupuf: changing the voltage is a safe operation
08:19karolherbst: yeah, I was aksing because of clocking
08:20mupuf: as long as the damn thing does not overheats
08:20karolherbst: aka what happens if some underclocks but don't undervolts
08:20mupuf: you get a higher power consumption
08:20CounterPillow: hi, this list is outdated; nvidia recently introduced a feature set F: https://wiki.freedesktop.org/nouveau/VideoAcceleration/
08:20mupuf: the goal is to always have the lowest possible voltage
08:21mupuf: because the power usage increases dramatically when increasing the voltage and/or the temperature
08:22karolherbst: okay, so if the csates are changed, voltage has to be changed as well, and if the gpu is inside the lowest "boosted" cstate, then the voltage is really low then
08:22karolherbst: or should be set really low
08:24mupuf: booster cstate?
08:24mupuf: let's put it this way
08:24mupuf: there are 4 performance levels
08:25mupuf: but then, the core clock is a bit more flexible than this
08:25mupuf: since it has something like 45 possible clocks
08:26mupuf: so, the idea is that inside a performance level, the core clock can be adjusted to keep the voltage as low as possible
08:26karolherbst: but whats about outside of these ranges
08:26mupuf: since I guess this is where the timings are the most problematic
08:26mupuf: unspecified behaviour
08:26karolherbst: but how do I get my card then to 135MHz?
08:27mupuf: overclockers usually go there
08:27karolherbst: if all pstates only say "405" is minimum
08:27mupuf: when you say your card is at 135Mhz, you mean the memory clock?
08:27karolherbst: no, gpu
08:27mupuf: an nvidia GPU has something like 16 clocks
08:27mupuf: so it is never clocked at ONE frequency
08:27mupuf: there is no GPU clock
08:28karolherbst: okay, then the thing nvidia-settings is reporting as gpu clock
08:28mupuf: unless you talk about hte crystal, and it is either 25 or 27MHz in this cae
08:28mupuf: ok, then it is the core clock
08:28karolherbst: all pstate have 405MHz minimum clock in ouveau currently
08:28karolherbst: but nvidia-settings also showed 135MHz on full idle
08:28karolherbst: max is fine
08:29mupuf: well, nvidia used to have a shader clock and a core clock
08:29karolherbst: max clock isr gith for all pstates though
08:29mupuf: but starting from kepler, they stopped doing this IIRC
08:29karolherbst: first one has also 405 max in blob
08:30mupuf: core was = shader / 2
08:31mupuf: I guess we can ignore that for the moment
08:31mupuf: I have a tool to trace what the blob is doing
08:31mupuf: we will run it on your machine to see what is going on
08:32imirkin: CounterPillow: which is even more unsupported ;)
08:33karolherbst: this is nouveau pstate: https://gist.github.com/karolherbst/28b5064c8a7687d7a7d8
08:33CounterPillow: Of course, I never intended to imply that it is.
08:33CounterPillow: Just letting you know in case you missed it
08:33imirkin: thanks :) it adds vp9 and whatnot?
08:33imirkin: ah, h.265. neat.
08:34karolherbst: strange enough: the blob driver switches PCIe modes up to 3.0
08:34karolherbst: according to pstate
08:34karolherbst: pstate 2 is always in PCIe 3.0 mode
08:34karolherbst: maybe this might cause the 0f troubles?
08:34karolherbst: or does nouveau also do 3.0?
08:36imirkin: i don't think we have logic for switching pcie modes
08:36imirkin: i highly doubt it's in any way related to stability... just more power, more speed, etc
08:36mupuf: karolherbst: I see
08:37mupuf: I agree with imirkin
08:37mupuf: should be safe
08:37mupuf: we do not support changing the number of lanes on the fly
08:37imirkin: CounterPillow: added to the list, thanks for the heads up
08:37mupuf: xexaxo had an experiment where he managed to decrease the number of lanes
08:37CounterPillow: imirkin: no problem
08:37karolherbst: but is nouveau able to use PCIe 3.0?
08:37mupuf: but increasing then led to ... a crash
08:37imirkin: karolherbst: nouveau doesn't "use" pci anything.
08:38CounterPillow: Also, I hope nouveau won't get into patents trouble if someone adds H.265 support. It's even more risky than H.264 at the moment because there are two competing patent pools.
08:38karolherbst: so its more like drm or even more lowlevel
08:38imirkin: CounterPillow: well, for now, there's no accel of any kind on GM20x
08:39imirkin: so... future problem :)
08:39CounterPillow: oh, can somebody explain the significance of this? are these header files useful that nvidia contributed? https://github.com/kfractal/nouveau/commit/f2e6c736a0d9475bc65f5d41a9df3bf56a0c823c
08:39mupuf: CounterPillow: hopefully, nvidia will allow us to redistribute the video decoding firmwares!
08:39mupuf: CounterPillow: yes, they are
08:40imirkin: useful, but limitedly so
08:40imirkin: names are nice. but nowhere near as nice as docs.
08:40mupuf: the significance: It's great but we already had this information under another form
08:43mupuf: karolherbst: going back home
08:43karolherbst: nice :)
09:27imirkin: wow, GM206 has H265 but GM204 doesn't? that's crazy.
09:28mwk: that's quite usual
09:28mwk: introducing new vdec features in the middle of a family
09:28mwk: like VP3 introduced in G98
09:29imirkin: VP3 was *totally* different too
09:30mwk: someone said the idea is that higher end cards are usually used with i7s that can deal with the crazy codecs on their own...
09:30karolherbst: but then they are useless anyway
09:31mwk: my feeling is just they they want to stagger the release of new stuff
09:31karolherbst: or low end is just too underclocked, so they are too slow for the new hot stuff
09:31karolherbst: but I thnk this is quite common to do so
09:58jhol: I don't know if this is helpful at all - I have a GeForce GTX750 if anyone needs some experiments running on a very modern GPU
10:15imirkin_: jhol: it should kinda semi-work with linux 4.1
10:15imirkin_: and modesetting
10:15imirkin_: jhol: did anything come of your efforts to get tv working on nv50-era gpu's?
10:16imirkin_: jhol: vdpau remains completely undone on there btw, if you're looking for a project :)
10:22jhol: imirkin_: so I've been rather busy for the past few months relocating to the US
10:22jhol: the TV stuff got a bit distracted
10:22jhol: first because I heard the whole back-end was going to get rewritten on atomic
10:23imirkin_: jhol: meh, the atomic thing doesn't prevent RE'ing how to operate the thing
10:23jhol: also I heard the news about nvidia releasing register listings
10:23jhol: - is that relevant to this?
10:25imirkin_: could be
10:25imirkin_: but it's mostly relevant to GK20A/GM20B
10:25imirkin_: which means most likely not
10:30Karlton: anyone know anything about dri3 and why kwin hates my nvidia card? :D
10:31imirkin_: Karlton: which gpu do you have?
10:31imirkin_: oh right, some kepler no?
10:31imirkin_: optimus or desktop?
10:31imirkin_: nouveau ddx from git?
10:31karolherbst: dri3 doesn't need ddx
10:31imirkin_: karolherbst: by that logic you don't need xf86-video-intel :p
10:32imirkin_: somewhere your logic breaks down though
10:32karolherbst: then you should ask for intel ddx ;)
10:32imirkin_: karolherbst: why? he only has an nvidia board
10:32karolherbst: my bad
10:32karolherbst: I am stupid
10:32imirkin_: or just a poor reader :p
10:32imirkin_: Karlton: what is the fail exactly?
10:33Karlton: Chipset: GK106 (NVE6) -- kwin with dri3 has memory corruption or something
10:33karolherbst: imirkin_: do you think I could run kwin through DRI_PRIME=1? :D
10:33Karlton: with the compositor turned on
10:34imirkin_: karolherbst: i don't see why not
10:34imirkin_: Karlton: can you describe the issue.
10:35Karlton: funny artifacts happpen in menus or when I type my letters disappear
10:35imirkin_: Karlton: did you enable glamor?
10:35imirkin_: if so, disable it
10:35imirkin_: its integration with nouveau is broken
10:36Karlton: oh yes, I have that installed
10:36imirkin_: it's fine for it to be installed
10:36imirkin_: just don't set AccelMethod to that. should default to EXA
10:36Karlton: I didn't change anything
10:36imirkin_: Karlton: also old xorg's have issues with dri3
10:36Karlton: just built it with mesa
10:37imirkin_: apparently 1.16.3 is safe to use though
10:39Karlton: well how do I make sure i am not using glamor?
10:39imirkin_: check your xorg log
10:39imirkin_: should say it's using EXA accel method
10:46Karlton: yeah it isn't using glamor
10:46imirkin_: ok cool
10:46imirkin_: i have no idea what's wrong, unfortunately
10:47Karlton: tried to do an apitrace of kwin but then it didn't reproduce and the trace was garbage anyway
10:51imirkin_: sorry, i dunno what dri3 does and how it's different... i suspect that some of the implicit flushing assumptions aren't maintained with dri3
10:51imirkin_: and that's why there's a lot of render fail
10:51mupuf: karolherbst: ok, I may have found the reg
10:51Karlton: everything is fine except for kwin compositioning
10:52imirkin_: which is kind of a big use-case
10:52karolherbst: mupuf: nice
10:53karolherbst: so what should I do
10:54imirkin_: mlankhorst: should nouveau_present_flip_exec wait on the pixmap bo?
10:54imirkin_: mlankhorst: or perhaps do that in present_flip_check
10:55mupuf: karolherbst: nope, that was a really possibility
10:55mupuf: but lowering the voltage does not change make the gpu crash
10:55mupuf: must be wrong :D
10:57karolherbst: to what you set it
10:58mupuf: lowest possible :D
10:58karolherbst: 0Hz, nice
10:58karolherbst: mhh 0v
10:58mupuf: I doubt it will be 0v
10:58karolherbst: but according to the voltage table the lowest entry?
10:58mupuf: possibly, yes
10:58karolherbst: bad idea
10:59karolherbst: it has 1.25V here
10:59karolherbst: and the card shouldn't go much over 1V
10:59mupuf: don't worry about the voltage, what is dangerous is power
10:59karolherbst: but it shouldn't crash immediatly anyway
10:59karolherbst: so yeah
11:00mupuf: ah ah, trust me, yes it will
11:00mupuf:has experimented with this quite q lot during his PhD
11:02karolherbst: I mean if it was the right one
11:03Karlton: imirkin_: it looks like this https://imgrush.com/JBJHxssAELNI
11:04imirkin_: Karlton: yeah looks like some sort of fail, seems likely to be in the X server
11:04imirkin_: alllthough... with full-screen compositor, dunno
11:04imirkin_: i don't really know how compositors actually work
11:05imirkin_: it's an area of the stack i've never really explored since i never use them myself
11:08karolherbst: imirkin_: dangerous knowledge: I think compositor are getting the buffer of the window contents and do something with it
11:09imirkin_: karolherbst: yeah... i mean it's _something_ like that, but the devil is in the details
11:09imirkin_: and nouveau ddx has some very questionable practices regarding when commands actually get flushed out and pushed
11:10karolherbst: I see
11:10imirkin_: so if a buffer goes through some path where that wasn't thought about, then... boom
11:10imirkin_: or rather, stale buffer contents :)
11:10karolherbst: would be nice to know what kind of artifacts are there
11:11karolherbst: will there be also content of windows
11:11karolherbst: or only the border for example
11:11imirkin_: i'm guessing just left-overs from moving down the selection list
11:11imirkin_: that are being in the process of being rendered over, but not done yet
11:11imirkin_: maybe in the texture-from-pixmap dealie, dunno
11:12imirkin_: skeggsb: does nouveau_bo_wait still work with imported dma-buf bo's?
11:12imirkin_: skeggsb: i.e. if side a is writing to the bo, and then side b wants to wait on that render
11:12imirkin_: (or mlankhorst --^)
11:14karolherbst: mupuf: any status update? Otherwise if you want I could try out the cstate changes on other cards
11:15karolherbst: ahh I thiknk you need the machine now :D
11:15imirkin_: mupuf: what do you have plugged into reator? if it's a gk10x, i should do a piglit run on it when you guys are done playing.
11:16mupuf: karolherbst: nah, still trying to understand what is going on
11:16karolherbst: I see
11:16mupuf: seems like I cannot force the GPIO to 0
11:17mupuf: let's try fuzzing areas
11:25mupuf: ah, that's what I call a conclusive result!
11:25mupuf: well, the card suddenly returning 0xfffffff to every request
11:25RSpliet: mupuf: I see what you did there ;-)
11:25RSpliet: I don't think any of the NVA0 is on it's way to drm-next just yet
11:26karolherbst: which means?
11:26mupuf: karolherbst: that the voltage went out of spec and the card just hanged
11:26imirkin_: karolherbst: generally "gpu off"
11:26karolherbst: so you found the right one basically?
11:26karolherbst: or part of it
11:27imirkin_: or just a way to nuke the gpu ;)
11:27imirkin_: as if we didn't have enough of those
11:27mupuf: imirkin_: exactly
11:27imirkin_: just try using the damn thing, and it dies
11:28mupuf: karolherbst: exactly what imirkin_ said. I just found a sure way of crashing the gpu
11:28mlankhorst: imirkin_: nouveau_bo_wait works, but only waits on ttm drivers..
11:28mupuf: and it doesn't crash as easily when X is not loaded and unigine-heaven is not running
11:28mupuf: see, conclusive result!
11:28mupuf: not that it means I found anything
11:29mupuf: but it is possible
11:29mlankhorst: driver has to implement implicit sync
11:29karolherbst: not usable at the moment (tm)
11:29mupuf: it is also possible I am accidentally enabling power gating
11:29imirkin_: mlankhorst: ok, but nouveau + nouveau it should work
11:29mupuf: who knows!
11:29mlankhorst: it will perform a wait on command submission too, instead of in hardware
11:29imirkin_: mlankhorst: could we be passing a fd without flushing the command stream on it
11:30imirkin_: i.e. we could have stuff written to the pushbuf but haven't submitted it yet
11:30imirkin_: that way a remote wait won't end up knowing about that
11:30imirkin_: while a local one would (since bo_wait checks for unsubmitted pushbufs)
11:31karolherbst: mupuf: maybe you activated boost while in 07 :p
11:31karolherbst: and boost is only for 0f
11:32imirkin_: mlankhorst: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nouveau_dri2.c#n1095 -- should that do a PUSH_KICK or something? or does nouveau_bo_set_prime handle that?
11:32mlankhorst: no need to kick there, though when your command completes you probably have to make sure its kicked
11:32mupuf: karolherbst: boost is not a hw feature
11:32mupuf: it is controlled by the CPU
11:33karolherbst: ahh okay
11:33imirkin_: mlankhorst: well, the thing is that all the EXA stuff doesn't actually do a PUSH_KICK at the end
11:33mupuf: boost is just faster and finer-grained reclocking
11:33imirkin_: instead it relies on internal libdrm cleverness
11:33karolherbst: mine reclocking is pretty dier grained already
11:33mlankhorst: imirkin_: the idle handle does? :p
11:33imirkin_: mlankhorst: let's say i don't know what that is...
11:33imirkin_: where might i find that
11:34mlankhorst: block handler or something
11:34imirkin_: in nouveau? what does it relate to?
11:35imirkin_: src/nouveau_glamor.c: glamor_block_handler(pScrn->pScreen);
11:35mlankhorst: something like that
11:35imirkin_: aha NVBlockHandler
11:36imirkin_: can't say i really understand what that is or does =/
11:36imirkin_: time to read dri2 spec?
11:37mlankhorst: it gets called when idle
11:37mlankhorst: not part of dri2 spec
11:37mlankhorst: so commands get batched
11:38imirkin_: so you're saying that it can never happen that we, say, share a dma-buf bo for a pixmap
11:38imirkin_: and then we get some rendering command to that pixmap
11:38imirkin_: and then the remtoe end of that dma-buf wants to read that data
11:39imirkin_: but the DDX won't have flushed thec ommands
11:39imirkin_: [is what i'm saying even making any sense?]
11:42mlankhorst: it can easily happen :p
11:42mlankhorst: just hopefully not likely
11:43imirkin_: ok, so... what's the way to rseolve that? if the fd has been shared then flush in the EXA*Done callback?
11:43nfk: gosh, I can't even understand which driver i'd need if i bought an amd gpu: https://www.phoronix.com/scan.php?page=news_item&px=AMD-300-Open-Source-Support i wonder how those amd zealots can understand it
11:43imirkin_: or is there some sort of server-side call for it
11:43imirkin_: nfk: i can tell you what driver you won't need -- nouveau :)
11:44karolherbst: my nvidia card was so new once, that even windows hadn't a driver
11:44karolherbst: and I just got an older patched modded driver
11:46nfk: imirkin_, don't worry if i do decide to buy an amd gpu (which is now supper unlikely as amd's value is going through the floor and i expect MS will be able to buy it with russian roubles one of their engineers got as a change few years ago next month) i'll be sure to ask you because there's no way i'm trusting an amd zealot as to what's the best driver which gpu to get
11:47imirkin_: not sure that an amd zealot would provide you a substantially different answer wrt which driver to use -- you can only use one for any given gpu
11:47nfk: amd zealots always lie
11:47Karlton: I only know of radeon and the proprietary driver for AMD
11:48imirkin_: nfk: that's great -- just do the opposite of what they say then!
11:48nfk: and they use so many codenames i can never make heads or tails of, just look at that moronix article, fiji, fuji, cerial and bonjovi, i felt lost in a limbo before i had gotten to the end of second paragraph
11:48imirkin_: only becomes an issue if they *sometimes* lie
11:48mupuf: karolherbst: pretty sure I found the right PWM controller, but it may be double buffered
11:48imirkin_: nfk: search for "amd gpu decoder ring"
11:48mupuf: or tripple buffered
11:48karolherbst: I know that I knew what that means
11:49mupuf: single buffered = write to it and the value is immediatly used
11:49mupuf: double buffered = update the value and then commit it
11:49mupuf: but for this one, there may be another level
11:49nfk: imirkin_, but there's 3 current drivers, fglrx which is actually sometimes called ati by distros, radeon, radeonhd (whatever that is) and amdgpu, wait, that's 4
11:50imirkin_: haha radeonhd
11:50imirkin_: that hasn't been a thing in ages
11:50mupuf: I mean, what I am tweaking is obviously a PWM controller
11:50mupuf: and it is located next to another one
11:50nfk: so i just know that what they're telling me is definitely out but not what is the right answer, much like playing who wants to be a millionaire
11:50mupuf: and it ramps up and down with the performance level
11:51imirkin_: nfk: anyways, your questions and concerns are better suited to #radeon than #nouveau
11:52karolherbst: mhh nice
11:52karolherbst: want have cstate stuff?
11:52karolherbst: or should I try something out?
11:53mupuf: nah, I do not need that right now
11:53mupuf: 1) Do the reverse engineering
11:53mupuf: 2) start implementing
11:53mupuf: 3) ????
11:53mupuf: 4) Fun!
11:54karolherbst: I see
11:55karolherbst: I meante like changing cstate and check if the pwm is doing something
11:55karolherbst: wouldn't make much sense though
11:55mupuf: you forgot again that this is supposed to be the driver's job to do that :D
11:55mupuf: right :D
11:55mupuf: otherwise, why would we even care about it?
11:56karolherbst: makes sense
11:56Karlton: imirkin_: so, I noticed that I can reclock my card to 0f(highest performance level) if xorg isn't running :p
11:56Karlton: but if I do startx and then launch a game like minetest, the gpu hangs
11:57imirkin_: Karlton: yeah, things only die if you use the gpu
11:57karolherbst: Karlton: strange
11:57imirkin_: the act of reclocking doesn't actually break anything
11:57karolherbst: Karlton: it sometimes randomly works here
11:57Karlton: but 0d gets all kinds of screen corruptions
11:58Karlton: even without x running
12:00karolherbst: mupuf: what values does the pwm read for each pstate?
12:01Karlton: imirkin_: actually I can run fine in kde with it as long as I don't launch a game or play a video
12:01Karlton: but this also happens at the lowest pstate, just less frequently
12:02Karlton: at 0a I run run for days before it dies
12:05Karlton: what would cause it to lockup when I put a load on it?
12:05Karlton: probably many things?
12:05imirkin_: any one of a bajillion things
12:06Karlton: https://imgrush.com/ROX3kN6kSUQM.png :)
12:07imirkin_: i'm just waiting for the ping timeout :p
12:08Karlton: I have irssi running on an arm server :p
12:08Karlton: but it hasn't died yet
12:09Karlton: I'll try to play a video...
12:12Karlton: [16840.613500] nouveau E[ PGRAPH][0000:01:00.0] TRAP ch 12 [0x023f386000 Xorg]
12:12Karlton: [16844.250554] nouveau E[ DRM] GPU lockup - switching to software fbcon D:
12:12Karlton: after playing the video for 5 seconds
12:14Karlton: actually a lot PGRAPH stuff, whatever that means
12:24mupuf: karolherbst: I managed to get e, 11 and 15
12:25mupuf: you would need my vbios though
12:25mupuf: and the divider would be 18
12:25mupuf: because every card potentially has different settigns
12:25mupuf:is rebasing his reverse tools on the newer nouveau
12:25karolherbst: then I will use them
12:25karolherbst: and figure out which ones
12:26karolherbst: somebody wanted to run piglit tests
12:26karolherbst: do we should do the cstate stuff first or piglit?
12:26karolherbst: allthough cstate isn't important yet
12:26karolherbst: regressions are more important
12:27karolherbst: imirkin_: ping
12:27karolherbst: mupuf seems to be done playing for now ;)
12:27mupuf: karolherbst: nah, still using reator
12:27karolherbst: I see
12:27imirkin_: well i can't ssh into it from here anwyays
12:27karolherbst: ahh k
12:49imirkin_: Karlton: hey, so long story short, it seems like DRI3 is only half-baked at this point, with many potential (even if not real) issues
12:49imirkin_: Karlton: i'm going to suggest not enabling dri3 by default at all in the nouveau ddx
12:51mupuf: imirkin_: wise move
12:55Karlton: imirkin_: okay, but kwin was the only thing that gave me problems :)
12:56imirkin_: only the compositor :p
12:56imirkin_: did you try other ones
12:57Karlton: imirkin_: also I get this when I play a video even if I don't reclock http://sprunge.us/JAQU
12:58Karlton: but only only happens after a minute or longer than 0f
12:59Karlton: whole system locks up and I had to get dmesg from sshing into it
12:59Karlton: well at least I couldn't get into tty2
13:00mupuf: imirkin_: you wanted a fermi?
13:01RSpliet: yes please
13:02mupuf: ok, you wanted a kepler
13:02Yoshimo: free maxwells too? :P
13:03mupuf: Yoshimo: of course, open bar!
13:03mupuf: imirkin_: I plugged a maxwell and a kepler
13:03mupuf: reator has booted
13:03mupuf: you are free to use it
13:04Yoshimo: unfortunately nvidia seems to only help with tegra chips , so most recent cards won't help much mupuf
13:04RSpliet: I would really like some Pascal cards as well...
13:04imirkin_: mupuf: yeah, i already got your fermi ;)
13:05imirkin_: mupuf: thanks!
13:05karolherbst: mupuf: so, what are we going to do now
13:05imirkin_: Karlton: hm, that sucks
13:05RSpliet: mupuf: got a Volta for me? :-P
13:05imirkin_: i think nvidia published enough enums to make sense of that PROP trap enum though
13:06mupuf: RSpliet: sure, just come here!
13:07Karlton: I don't know what any of that means :D
13:07mupuf: karolherbst: well, until we figure out how to cange the voltage, we are stuck. aren't we?
13:08karolherbst: I though you found the pwm thingy
13:12mlankhorst: imirkin_: oh btw I remember, present is braindead on gpu screens..
13:12mlankhorst: not just braindead, but awful too :D
13:13imirkin_: mlankhorst: ok, but i don't think that's Karlton's issue -- he just has the 1 gpu
13:14mlankhorst: ah, i thought you meant with nouveau/nouveau sharing between different nouveau cards
13:14imirkin_: mlankhorst: no. nouveau sharing with itself :)
13:14imirkin_: but diff channels i guess.
13:14mlankhorst: that should work normally
13:14imirkin_: it does generally work
13:14imirkin_: but there are artifacts
13:15imirkin_: but only with DRI3
13:16imirkin_: Karlton: can you give the above patch a shot?
13:16imirkin_: Karlton: note that it's a patch against X
13:16mlankhorst: flipping a screen causes the window pixmap to be changed, so every other frame it doesn't allow flipping and blits out the entire pixmap and back
13:16mlankhorst: good times. ;-)
13:16Karlton: xorg-server patch?
13:17mlankhorst: not sure if anybody else noticed or fixed it
13:18imirkin_: it seems like no one cares much about X anymore :(
13:18imirkin_: a bit unfortunate given that wayland is nowhere close to a replacement.
13:19imirkin_: [at least not in its present state]
13:19mlankhorst: it does make x more stable :P
13:19imirkin_: yeah, but then someone tries to add DRI3 and it's only like half-done :(
13:20imirkin_: and nobody around to fix it
13:20mlankhorst: I had present working with gpu screens, that was pretty cool. :P
13:21imirkin_: and then you took your patches and never sent them out :p
13:21karolherbst: DRI3 works for me
13:21eijebong: Hi, i've got some weird issues :) When I launc glxspheres or glxgears, I've got 1 FPS ( 5 frames in 5.0 seconds = 1.000 FPS ). GPU = 770M.
13:21karolherbst: to be honest, I couldn't understand how somebody doesn't want to use DRI3, because intel SNA was pretty bugged for me with DRI2 :O
13:22karolherbst: eijebong: that's my gpu :p
13:22karolherbst: eijebong: kernel?
13:22karolherbst: and do you get a pciture at all?
13:22karolherbst: also dmest
13:22eijebong: I get a picture
13:22mlankhorst: imirkin_: well I was hitting too many bugs on tegra to continue :(
13:23eijebong: And kernel g1c4c715 (I think i'm one commit late)
13:23karolherbst: g1c4c715 ?
13:24imirkin_: eijebong: lspci -nn -d 10de:
13:24eijebong: Ha yay, a g got into my message :o
13:25karolherbst: imirkin_: strange that the card works at all or isn't ben hack needed
13:25eijebong: And my dmesg is flooded, so I've got nothing but nouveau debug from like the 5 last seconds...
13:25imirkin_: karolherbst: that hack is only needed on a select number of laptops
13:25eijebong: [eijebong@poueca] ~ >>> lspci -nn -d 10de:
13:25eijebong: 01:00.0 VGA compatible controller : NVIDIA Corporation GK106M [GeForce GTX 770M] [10de:11e0] (rev a1)
13:25eijebong: 01:00.1 Audio device : NVIDIA Corporation GK106 HDMI Audio Controller [10de:0e0b] (rev a1)
13:25karolherbst: imirkin_: okay
13:25imirkin_: eijebong: pastebin dmesg
13:27eijebong: http://paste.bananium.fr/?b9cc7b68a2f949d9#5KFvMqP8VVnMLQGsCe6DWuOOxoU4pBFHMsUOZR0XKP8= As I said, I've got only 2 seconds of dmesg...
13:28imirkin_: why trace level?
13:29imirkin_: eijebong: please leave the debug setting alone for now
13:29eijebong: Because i was curious :) But eh, i'm recompiling right now
13:30imirkin_: you don't have to recompile... nouveau.debug=trace will flip trace on
13:30karolherbst: debug=info is good enough ;)
13:30imirkin_: nouveau.debug=info will flip it off
13:30imirkin_: if you have the default level set to trace
13:30imirkin_: but you should leave those defaults alone
13:30imirkin_: both that one and the max debug level should stay at their default values
13:30imirkin_: unless you _really_ know what you're doing
13:31karolherbst: logging isn't that cheap, systemd had to learn it the hard way and they overflooded the kernel with IO, so nothing worked
13:31karolherbst: while spawning a lot of stuff into dmesg
13:31imirkin_: this isn't strictly systemd's fault though... this is nouveau printing trace stuff.
13:31karolherbst: I was just saying
13:31imirkin_: happens to be systemd-logind sending the ioctl's for god-knows-what reason
13:31karolherbst: performance hit through logging is possible
13:32eijebong: Yeah, but 1.000 FPS, that's weird
13:32imirkin_: most likely due to something else
13:32imirkin_: but need to see dmesg :)
13:32Karlton: mlankhorst: no, that patch did not change anything
13:33karolherbst: imirkin_: I bet it could be related to backlight or something (why its systemd-logind) or something totally random
13:33karolherbst: ahh, the consoles maybe?
13:33karolherbst: nvm, unimportant
13:35karolherbst: mupuf: how is the work going with the RE tool?
13:37Karlton: imirkin_: I am going to put in a different card and see :)
13:43mupuf: karolherbst: it does not want to work on my maxwell
13:43mupuf: but I have other stuff to do tonight
13:43mupuf: so I put it on hold
13:44karolherbst: :/ sad
13:44eijebong: My dmesg http://paste.bananium.fr/?5fd7dd862260cb5a#g/dHknT/cV2Ys6Ej4/01Lte76SzF/pZHsg1RSPqaDuc=
13:45imirkin_: eijebong: ok, so that seems to be perfectly happy
13:45eijebong: :) Except for the crash in the middle
13:45eijebong: It says my BIOS is broken... Meh
13:46imirkin_: what, the dmar thing? meh.
13:46karolherbst: mupuf: maybe I could play around with the tool or is it not save enough and I will just brick my gpu?
13:46imirkin_: actually, could be related. try disabling it?
13:46imirkin_: should be a bios setting
13:46mupuf: karolherbst: you cannot brick the gpu easily
13:46eijebong: No idea of what it is
13:46mupuf: I never managed to brick one ... except when I put one in the oven at 200C
13:47eijebong: mupuf: Why would you do that ?
13:47mupuf: eijebong: to resolder the chipset
13:47mupuf: I bought something like 12 cards that did not work anymore
13:47karolherbst: I heard that you could repair bricked card that way :D
13:47mupuf: and I fixed them by resoldering it in my over
13:47mupuf: that was around the time of the geforce 8
13:49imirkin_: eijebong: pastebin output of "DRI_PRIME=1 glxinfo"
13:51Karlton: imirkin_: I plugged in a different card, Chipset: GT215 (NVA3), but I think it might be using dri2
13:51imirkin_: should support dri3 just fine
13:51imirkin_: at least afaik
13:52Karlton: does it say for sure in the xorg log?
13:53imirkin_: don't think so
13:53eijebong: http://paste.bananium.fr/?d0c41f95c456cab5#DfsayeUyI49XcixNff/xKwTnyCRL90U+BJOz3sgXhsI= Here, the error does not appear if I remove DRI_PRIME=1 (I'm not using my intel card, i'm using the config from here https://wiki.archlinux.org/index.php/NVIDIA_Optimus#Using_nvidia (with nouveau instead of nvidia))
13:53imirkin_: oh dear
13:53karolherbst: this is what I meant about arch
13:54imirkin_: eijebong: http://nouveau.freedesktop.org/wiki/Optimus/
13:54imirkin_: please read over that and follow its suggestions
13:54imirkin_: i have no idea about the accuracy of that arch guide for using the blob driver, but it's def not the recommended thing for the open stack.
13:55Karlton: imirkin_: well I can't reproduce that artifacts now :(
13:55karolherbst: the guide itself is fine with the prop driver
13:55eijebong: Okay' (It was working very well with the proprietary driver)
13:55karolherbst: it basically uses the intel with the modesetting driver to display stuff which got rendered by nvidia, and here everything is rendered through nvidia
13:56karolherbst: eijebong: the downside of this is: the nvidia card is always on
13:56karolherbst: and can't be turned off
13:58karolherbst: eijebong: I would recommend you a bumblebee setup with that card, its fast enough for almost everything with primus
13:59karolherbst: also you can easily switch between nvidia and nouveau that way
13:59karolherbst: also turn your card on/off manually if you wish through bbswitch (but that's done by bumblebeed automatically)
13:59eijebong: Yeah, I don't like bumblebee, it's not working well with anything that has a launcher :/
14:00karolherbst: sometimes I mess up the gpu in nouveau or nvidia and while loading the other one my system crash hangs :D
14:00karolherbst: eijebong: primusrun
14:00karolherbst: also offers better performance than the bumblebee vgl bridge
14:01eijebong: Mhh I had some bad experiences with primusrun/optirun, one would work sometimes, sometimes the other...
14:01karolherbst: yeah, it was bad at the start
14:01karolherbst: seems to be better now though
14:01eijebong: Maybe it changed, maybe my graphic card was too shitty, I don't know
14:01eijebong: I'll try with PRIME
14:01eijebong: karolherbst: No, I had a 610M before
14:01imirkin_: eijebong: yeah, no bumblebee/optirun or whatever
14:01karolherbst: yeah, that one is indeed bad
14:01eijebong: "shitty" :D
14:02imirkin_: eijebong: just nouveau. it should auto-shut the gpu off when it's not in use
14:02karolherbst: yeah if you not plan to use bumblebee at all and only nouveau, its autopm stuff is most likle the best option
14:03karolherbst: imirkin_: tells me a lot not to use bbswitch with nouveau :)
14:03imirkin_: look, if you know exactly what you're doing, you can use whatever
14:03imirkin_: but if you're not sure, stay away from that stuff
14:03imirkin_: just complicates matters and makes things worse for the simpler use-cases
14:06eijebong: Works so much better o_o
14:07eijebong: And 0 config
14:07eijebong: And X starts faster
14:07eijebong: And each time
14:08eijebong: But I think the nvidia card is not down
14:09karolherbst: cat /sys/kernel/debug/vgaswitcheroo/switch
14:10karolherbst: eijebong: if that file doesn't exist: you need CONFIG_VGA_SWITCHEROO enabled
14:10eijebong: Yep, doesn't exist, i'll flip that on
14:10eijebong: And should I do xrandr --setprovideroutputsource nouveau Intel ?
14:10eijebong: It works without
14:11karolherbst: not with DRI3
14:11karolherbst: but it depends
14:11karolherbst: do you use DRI3 or DRI2?
14:11karolherbst: then DRI3 it is
14:11karolherbst: you only need this with DRI2
14:11eijebong: Yep, ok
14:11imirkin_: read the wiki page, it has all that info
14:12Karlton: imirkin_: all I did was plugin a different card and now the problem is gone?
14:14Karlton:wishes he could make an apitrace of it :(
14:21Karlton: imirkin_: btw I replayed my old flightgear trace and it looks fine on this card
14:22Karlton: no green stuff
14:23imirkin_: Karlton: a few bugs have been fixed too, might try it on your kepler too
14:23eijebong: Mhh I think I missed something... My nvidia card is down now, but OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile event with DRI_PRIME=1
14:23Karlton: imirkin_: okay, i'll reboot...
14:24imirkin_: eijebong: did you follow the steps in the wiki?
14:27eijebong: What steps are you talking about ? Because for DRI3 I see some requirements
14:27imirkin_: eijebong: pastebin dmesg again
14:28imirkin_: [ 29.987294] nouveau E[ PGRAPH][0000:01:00.0] HUB_INIT timed out
14:28imirkin_: ok, so you have the same issue as karolherbst and a bunch of other people with a GK106
14:28eijebong: Yep, just saw that
14:28eijebong: Okay' :/
14:29imirkin_: surprising that it worked in the old config
14:29imirkin_: although i guess it's probabilistic
14:29imirkin_: there's a hack branch, but it doesn't work with runpm too well
14:29imirkin_: specifically this patch: http://cgit.freedesktop.org/~darktama/nouveau/commit/?h=hack-gk106m&id=64b75967fe13499f12876ec10a31d9141e828714
14:30imirkin_: seems to help people. but you have to turn runpm off.
14:30imirkin_: which means the gpu won't auto-suspend
14:30skeggsb: imirkin_: airlied mentioned some kind of patch he has that might help that issue
14:30imirkin_: skeggsb: which one?
14:30skeggsb: i don't know, i never asked, but he mentioned it when it came up a little while back
14:31skeggsb: i think he's out on PTO at the moment
14:31imirkin_: skeggsb: i mean... which issue? :)
14:31skeggsb: adding some kind of delay after the power-on, or something
14:34imirkin_: btw. reminder about bios codes patch.
14:35Karlton: imirkin_: no, I see green stuff now
14:35Karlton: and artifacts from kwin compositor -.-
14:35imirkin_: heh ok
14:36Karlton: difference between NV50 and NVE0
14:37skeggsb: imirkin_: thanks, pushed
14:38imirkin_: i'm sure TNT and TNT2 owners the world over will rejoice :)
14:39karolherbst: imirkin_: fun fact: it kind of works for me with runpm now, but I think it can cause troubles nethertheless, so I am not sure
14:39karolherbst: will keep it on and see how long it goes well
14:40mupuf: skeggsb: wasn't it airlied who added the 200us delay after the power-off or power-on to make it work better?
14:41skeggsb: mupuf: ah, that's been merged?
14:42skeggsb: ah yes, i see it
14:43eijebong: When has it been merged ?
14:45mupuf: eijebong: it is in linux 4.1
14:45mupuf: imirkin_: don't forget to turn off reator when you are done :)
14:45imirkin_: but you probably want ben's hackpatch too
14:45imirkin_: mupuf: i won't
14:45eijebong: Ha ok, so it doesn't work for me
14:45imirkin_: mupuf: or rather, i'll try not to
14:46imirkin_: i was going to try running on the maxwell again when the kepler was done
14:46mupuf: have fun :)
14:50karolherbst: skeggsb: I have an issue with my 770M, that prevents the pstate change mechanism to set any cstate, because the voltage can't be set on my card. I wrote some patches to get by this issue and also added a mechanism to select cstate manually through the same means like the pstate thing currently. Would you like to look over it?
14:51karolherbst: switching pstates gives me only like 10%-20% more performance with swithcing cstate gives another 10%
14:53skeggsb: karolherbst: did you change memory frequency too?
14:54karolherbst: psate does change it itself already
14:54karolherbst: antichamber got a 400% boost to 0f state
14:54karolherbst: but it was the only application with such a boost
14:54karolherbst: that's why I think its only memory limited
14:54karolherbst: stuff like talos or borderlands only got these 20%, 10% increases
14:55skeggsb: the voltage stuff needs a lot of love, i suspect some kind of merge between gk20a's cvb code and how we currently use the bios "voltage map" table needs to happen
14:55karolherbst: also the pstate files tells me, that the gpu core clock sticked to the old value
14:55skeggsb: but it requires a lot of reverse-engineering
14:55karolherbst: yeah mupuf was there already
14:56karolherbst: he found out, that its done through a pwm controller
14:56skeggsb: there's loads of things that need fixing in that whole area
14:56karolherbst: now I thiknk I am able to clock my gpu core up through cstates, but will stay at low voltage
14:56skeggsb: yeah, i seen that, that's another issue that needs to be addressed on top of the bios tables :)
14:57karolherbst: I was thinking if the cstate could improve performance for cards, where setting voltage already worked, because for me the pstate code always set to the slowest cstate
14:57karolherbst: even after I fixed that
14:57skeggsb: it'd be real nice if nvidia would give some kind of help here, particularly since they have no problem implementing it for gk20a, but i wouldn't hold my breath.. we'll probably have to figure it out ourselves
14:58skeggsb: generally the highest *should* get picked.. it's *supposed* to be automatic based on various factors
14:59karolherbst: yeah, I thought so too
14:59karolherbst: I could test again with the little workaround applied to get around the volt stuff
15:01karolherbst: ohhh I think I know not what I've done
15:02karolherbst: ahh now I understand
15:03karolherbst: yeah, that the pstate method selects the lowest is a regression here, because I enabled the possibility to manually select a cstate
15:04karolherbst: but with stock nouveau and your hack only, it fails to set the cstate anyway
15:04karolherbst: so I stick with lowest clock on master
15:08karolherbst: skeggsb: seems like the last cstate inside the list was used always. The nvkm_cstate_prog function has a cstatei parameter, which is currently doing nothing. pstate selects 0, which kinda means the first one, which is the lowest cstate, so by fixing the selection, the lowest possible cstate is then selected by nvkm_pstate_prog
16:38imirkin_: skeggsb: gm107 seeing lots of "fail set_domain" on random-seeming shader tests.
16:39imirkin_: kernel 4.0-rc4 it seems
16:39imirkin_: same kernel was fine with kepler and fermi though
16:40imirkin_: [and it's using blob ctxsw fw]
19:59boxfire: skeggsb: just poking you about TMDS > 165 MHz
22:27ebrasca: nouveau E[ PIBUS][0000:01:00.0] HUB0: 0x614900 0x00800000 (0x19408200)
22:29imirkin: is there an actual problem, or just an annoying message?
22:32ebrasca: imirkin: i have problem
22:35ebrasca: imirkin: i can run intel graphic but i can't run nvidia graphic
22:35imirkin: ebrasca: lspci -d 10de: -nn
22:37ebrasca: 01:00.0 VGA compatible controller : NVIDIA Corporation GM107 [GeForce GTX 750 Ti] [10de:1380] (rev a2)
22:37ebrasca: 01:00.1 Audio device : NVIDIA Corporation Device [10de:0fbc] (rev a1)
22:37imirkin: you need a 4.1 kernel if you want out-of-the box accel with that
22:37ebrasca: i have 4.1.1
22:38imirkin: ebrasca: how are you using this... this looks like a desktop card
22:38imirkin: are you using it as your primary card? or secondary?
22:41ebrasca: imirkin: are you mean on BIOS?
22:42imirkin: ebrasca: i mean... why is this card inserted into your machine
22:43imirkin: are you driving screens off of it? are you using it as an accelerator? replacement for your intel card?
22:49ebrasca: imirkin: secondary card are nvidia . primary card are intel
22:49imirkin: so you want to do a prime sort of thing?
22:49imirkin: take a look at http://nouveau.freedesktop.org/wiki/Optimus/
22:50imirkin: all the stuff about switcheroo and runpm won't apply to you, but the other stuff will
23:47gnurou: finally, GM20B renders with Mesa!
23:47gnurou: turns out the issue was with tiling
23:48gnurou: nouveau_gart_manager_new() would set the node's memtype, but only up to kepler
23:48gnurou: for maxwell it would not do anything
23:49gnurou: GM206 uses video memory primarily, so it did not hit this issue
23:49gnurou: but poor Tegra relies exclusively on gart, so that explains the difference in behavior
23:50gnurou: that one made me run quite far!
23:50gnurou: I'll send a patch to address this
23:54skeggsb: gnurou: i'm shocked the mmu didn't complain
23:55gnurou: skeggsb: well isn't 00 a valid memtype?
23:57gnurou: skeggsb: I am thinking of making nouveau_gart_manager_new() a little bit more robust in that aspect if you agree
23:57gnurou: like printing a warning for non-handled card families instead of silently going on