02:19tacchinotacchi: this might not be strictly related to nouveau but you should be gpu experts
02:19tacchinotacchi: i'm giving a quick look at bumblebee's source
02:20tacchinotacchi: do any of you think it's possible to pass the card to a virtualizer and get the screen output via a bridge like primus?
02:21airlied: tacchinotacchi: no
02:23tacchinotacchi: lol thanks
02:33tacchinotacchi: what about abstracted virtual hardware linked closely enough with the card to be *usable*?
02:45Weaselweb: tacchinotacchi: you mean somethin glike Virgil 3d?
03:13tacchinotacchi: Weaselweb: yes!
03:20tacchinotacchi: Weaselweb: well, actually, i thought of one more specific for nvidia or amd
03:20tacchinotacchi: so that it wouldn't have to do all the rendering in opengl
03:22Weaselweb: my uninformed guess is that then you would require a virtual hardware for each underlying driver
03:22Weaselweb: but isn't then PCIe passthrough even better?
03:23tacchinotacchi: the problem is, for that you need a IOMMU motherboard ( i have a notebook ) and a second screen
03:23tacchinotacchi: unless you can use a virtual screen and send it a an X window
03:23tacchinotacchi: but if you can do that, then i don't understand why you can't with bumblebee
04:59karolherbst: mupuf: report is invalid, because the unknown sensor might actually give us some power consumption values if we would read it out
04:59karolherbst: I thought the entire idea about the invalid reading is, that we can't trust the value at all, because the power consumption could be either higher or lower
05:00mupuf: oh right, sorry
05:01mupuf: yes, you are entirely right
05:01mupuf: there are more than one sensor
05:01karolherbst: "Unknown sensor type %x, power readingdisabled\n"
05:03Yoshimo: karolherbst: have you tried https://patchwork.freedesktop.org/patch/78448/ for your oblivion issue yet?
05:03karolherbst: Yoshimo: not yet
05:03karolherbst: I just got home
05:09karolherbst: mupuf: by the way, I fixed up the pcie speed reading out of the vbios...
05:09karolherbst: it is totally insane and completly random
05:10karolherbst: mupuf: 0x01: 2.5, 0x20: 5.0, 0x??: 8.0, default fastest, slower prefered
05:10karolherbst: if you have 0x23 in the bios: 2.5
05:10karolherbst: if you have 0x24: 5.0
05:10karolherbst: that's my data I collected: https://gist.github.com/karolherbst/1c1dfb1ea50ad2a17e76
05:10karolherbst: at first it didn't make any sense at all
05:11karolherbst: I mean, why
05:11karolherbst: it could be so simple
05:12mupuf: bit 0 unset = use 8.0
05:12mupuf: bit 1 set, use 2.5
05:12mupuf: bit 2 set, use 5.0?
05:13karolherbst: not bit 2
05:13karolherbst: bit 5
05:13mupuf: that still sounds insane
05:14karolherbst: that means there needs to be a bit for 8.0 as well
05:14karolherbst: it isn't a big problem though, because the code is safe against this
05:14mupuf: maybe bit 0 is : force to highest
05:14karolherbst: it just means that we try to set 16.0 on new boards for 8.0 cards
05:15karolherbst: mupuf: bit 0 would be 2.5
05:15karolherbst: but I have no idea, because even 0xde is 8.0
05:15mupuf: well, what if some bits were to allow masking the clock speeds not wanted
05:15karolherbst: yeah maybe
05:16mupuf: and some other bits would specify the policy?
05:16mupuf: that would make sense, right?
05:16karolherbst: it would, but why does the values doesn't look like it?
05:16karolherbst: I mean, I could try to get the pcie speed for all 256 values
05:16mupuf: bit 0 looks like a policy bit to me
05:17mupuf: that would not hurt, but you would need to also fake what the motherboard sets as the highest possible speed
05:17mupuf: and try again
05:18karolherbst: the thing is
05:18karolherbst: the pcie switching stuff is implemented on the gpu
05:19karolherbst: I could still check if nvidia changes some regs though
05:19karolherbst: but as far as I know, the driver never affects what the motherboard does
05:20karolherbst: well it doesn't to the pcie stuff at all anyway. I just sets some regs on the gpu and the gpu does all the work
05:20karolherbst: mupuf: uhh, maybe there are also latencies in that byte!
05:21karolherbst: that would actually make sense
05:21karolherbst: the L1 and L0s one
05:23mupuf: isn't that hw-dependant?
05:23mupuf: well, worth a shot
05:23karolherbst: no, you can actually change those latencies through the mmio regs
05:23karolherbst: well it depends on the hardware what may be stable or what may be a good or bad latency set, but you can somewhat tell the gpu to change it
05:25mupuf: very good, we have a lead here :)
05:26karolherbst: your boost debugfs file idea works great by the way. It made my nv_cmp_volt tool actually better, because the most cstates are still there. Before I had the problems that some high clocks weren't in the driver and the tool couldn't make the cstate right
05:27karolherbst: Yoshimo: yeah, the patch works for me
05:39imirkin: karolherbst: thanks for testing... pushed (along with a few other patches i had lying around)
05:39imirkin: karolherbst: btw, i tested 8x msaa in heaven, and it appears to be fixed
05:40imirkin: [at least on my tree... dunno if it's some other patch that fixed it or what]
05:43karolherbst: I'll try out with current master
05:44karolherbst: imirkin: what is with bug 91895 by the way?
05:44imirkin: RA fail
05:44karolherbst: ohh k
05:44karolherbst: because I have this patch applied for months now
05:44imirkin: that causes other things to break unfortunately =/
05:45karolherbst: for example?
05:45imirkin: i don't remember :)
05:45karolherbst: k, so I remove it then
05:45imirkin: but i run through a bunch of random traces i have sitting around
05:45imirkin: and some of them must not have replayed properly
05:57Yoshimo: karolherbst: nice, hopefully it should be packaged for me tomorrow night then :)
05:57karolherbst: imirkin: yeah, 8xMSAA seems to be fixed as well
06:02karolherbst: mupuf: do you think you will find some time to go through the reclocking patches?
06:03karolherbst: mupuf: I don't mind if you skip stuff you don't want to look at it :D
06:03mupuf: karolherbst: yes
06:04karolherbst: thanks a lot :)
06:04mupuf: I was in the process of looking at them when I was sent on a supply run
06:04mupuf: and I got a bug report on libwsm
06:04mupuf: after a year of silence, arduide is getting some love
06:04mupuf: and same for libwsm :D
06:07karolherbst: heaven 1920x1080/ultra/extreme/8xMSAA: 9.5 avg 6.5-20.8 fps, score 239
06:09mupuf: karolherbst: and the blob?
06:09karolherbst: benchmarking now, but seems to be only 30-40% faster
06:09karolherbst: it gets a much higher max fps though
06:09karolherbst: above 35
06:10karolherbst: I am sure nouveau has problems with complex scenese where nothing is actually shown though
06:10karolherbst: like when everything is behind the viewer
06:11karolherbst: or outside the view
06:13karolherbst: blob: 15.9 avg 9.8-38.6 fps, score 401
06:14karolherbst: mhh oh well
06:14karolherbst: more like 60% faster actually
06:15mupuf: well, there may be things related to textures that we do not do well
06:15mupuf: heaven is heavily texture limited
06:15mupuf: performance counters could shed some light on this
06:15mupuf: hakzsam: just saying :D
06:16karolherbst: looking at dragon head from above: 11 fps looking into the sky same positon: 55fps (blob)
06:17ouned: hi. https://lists.freedesktop.org/archives/nouveau/2015-November/023397.html, why is it still not in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c#n679 ?
06:18karolherbst: mupuf: same thing on nouveau: 8fps, 22fps
06:18hakzsam: mupuf, yep, but features first :)
06:19hakzsam: and by features I mean useful extensions
06:19karolherbst: mupuf: yeah well. I am really worried about the sky perf drop
06:19mupuf: hakzsam: yep yep
06:19karolherbst: the blob is more than 100% faster here
06:19karolherbst: more like 150% actually
06:19karolherbst: I am sure figuring this out why that is, will really help
06:19mupuf: karolherbst: maybe they have hi-z or early-z that we do not have yet enabled
06:20karolherbst: yeah I fear that too
06:20karolherbst: maybe it is really zcull in the end
06:20karolherbst: we really need those perf counters here
06:21mupuf: ouned: good question
06:21karolherbst: ouned: because we don't need it anymore
06:22karolherbst: ouned: the stuff is enabled by default now where needed
06:22mupuf: karolherbst: oh, I missed this
06:22karolherbst: mupuf: yeah there is some flag somewhere which tells us if we have to do that
06:23imirkin: ouned: it's no longer necessary, it's the default behaviour
06:24ouned: oh okey nice, which kernel version do i need to test it?
06:24mupuf: karolherbst: oh right! PFUSE
06:25imirkin: ouned: 4.4 or 4.5 should be new enough i think
06:25imirkin: definitely 4.5... but i think 4.4 also got that logic
06:29ouned: thanks, going to try it!
06:36librin: imirkin, thanks for fixing bug 91526
06:36librin: works like a charm now
06:36imirkin: librin: awesome :)
06:59enaken: where i can find info about nouveau support reclocking nvidia 8600M GS ?
07:01karolherbst: enaken: it is a G84, so there is no reclocking
07:01karolherbst: enaken: best source is the source of nouveau
07:05enaken: karolherbst: thanks
07:05mupuf: karolherbst: there is some reclocking support, but it is not considered super stable
07:06karolherbst: mupuf: yeah, but the same goes for fermi as well
07:06mupuf: fermi may work even better :D
07:06mupuf: tesla was a giant mess
07:07karolherbst: well we could just enable engine reclocking for fermi and see how it goes
07:07karolherbst: but well
07:07karolherbst: there is also the stupid voltage map table there
07:07karolherbst: but with three coefficients
07:09Yoshimo: sounds like exactly the challenge karol enjoys
07:11mupuf: Yoshimo: no need to spend time on fermi until kepler really works well
07:11Yoshimo: yea but he is the one messing with numbers and coefficients and trying to make sense out of unknown stuff
07:12karolherbst: yeah well
07:13karolherbst: the fermi I have it somewhat boring :D
07:13karolherbst: and without memory reclocking I can't really test engine reclocking
07:13karolherbst: because there is just not enough load for wider tests
07:14karolherbst: mhh pixmark_piano might be worth a shot, but it just worked on my fermi
07:14karolherbst: and I know why
07:14karolherbst: mupuf: on my fermi: voltage_min == voltage_max
07:15karolherbst: but this is true for so many fermis
07:15karolherbst: Yoshimo: what I did was mainly to implement GPUBoost in nouveau without actually targeting it. But in the end it was this
07:15karolherbst: Yoshimo: there are some traces of it in some fermi vbios, but nothing interessting
07:20Weaselweb: mesa will have >=llvm-3.8 support from upcoming 11.2 on?
07:20imirkin: i think so
07:21Weaselweb: is there any ETA for release?
07:23Yoshimo: wasn't the relaease guy having some familybusiness to take care of first?
07:24imirkin: Weaselweb: dunno. you can use 11.2-rc3 though
07:28Weaselweb: ic. mh, need a gentoo ebuild for rc3 though
07:30imirkin: you also don't need llvm for nouveau...
07:31Weaselweb: ah, neither do I need opencl on this box
07:31karolherbst: Weaselweb: or use 9999
07:32Weaselweb: karolherbst: yeah, but I try to avoid 9999 packages, unless I requires bleeding edge
07:33mupuf: karolherbst: ok, back to your review
07:34karolherbst: mupuf: awesome :)
07:56karolherbst: mupuf: actually I could replace your pwr_read tool with my new one, it would be actually easier to maintain in the end.
08:11mupuf: karolherbst: would be nice :D
08:11mupuf: would need to have a look :p
09:08karolherbst: shouldn't the Titan X work with nouveau?
09:09Yoshimo: gm200, do we have firmware for all gm2xx?
09:10karolherbst: well the 980 ti works
09:12karolherbst: but without proper reclocking it is a bit pointless anyway
09:12karolherbst: I just hope we get the PMU firmware fast
09:13Yoshimo: me too, i am eager to find issues
09:15karolherbst: lol, the first troll already showed up...
09:16karolherbst: you have one guess
09:17Yoshimo: ah phoronix published an article, didn't show up in my feed ;)
09:24karolherbst: seriously, how much hate can you have against... ohh right, pulse/systemd... sometimes I am too naive for this world
09:27Yoshimo: don't try to understand trolls, you simply can't figure out why they waste their time derailing discussions and insult people
09:28karolherbst: I know
12:12karolherbst: for everybody who is too lazy to build an out of tree module: https://github.com/karolherbst/linux/tree/nouveau_4.5_reclocking
12:12karolherbst: just make sure to use the correct branch
14:08mupuf: karolherbst: reading through your patches, this "put logic in the volt subdev" is really bothering me :s
14:09mupuf: but, to be honest, stuff like temperature and coeficient should not be in the clk subdev
14:09karolherbst: I am open to suggestions
14:10mupuf: and how do we continuously adjust the voltage?
14:10karolherbst: 1s intervall timer?
14:10mupuf: as to account for the temperature changes
14:10mupuf: yes, that is a given
14:10karolherbst: yeah, just in the timer then
14:10mupuf: we already poll the temperature
14:10mupuf: but who does it?
14:10karolherbst: get currently set cstate
14:10karolherbst: get currently wanted cstate
14:11karolherbst: and compare
14:11mupuf: Well, maybe the volt subdev should take a frequency as an input
14:11mupuf: and let it figure out what voltage it needs to set
14:11karolherbst: mupuf: therm timer-> pings clk subdev (nvkm_clk_reclock)->function onlyupdates something, when something has to be changed
14:12karolherbst: that was my idea somewhat
14:12mupuf: yes, I agree
14:12karolherbst: or at least what I planned to do with nvkm_clk_reclock in the end
14:12mupuf: something like: temperature_changed()
14:12karolherbst: yeah or that
14:12karolherbst: that won't work
14:13karolherbst: we might want to raise the clock
14:13karolherbst: or lower it
14:13mupuf: oh, right
14:13karolherbst: the max voltage actually depends on the temperature
14:13karolherbst: on some cards at least
14:13mupuf: yeepee :p
14:13mupuf: yep, I agree
14:13mupuf: so, therm -> clk -> volt
14:13karolherbst: we need the cstate selection logic in clk
14:14karolherbst: and we need nvkm_volt_map to be calleable from clk too
14:14karolherbst: this is all painfull, but yeah, it is the only way I think
14:14mupuf: wait, how about this? volt->set_volt_frequency(wanted_freq)?
14:15mupuf: if this fails, you know it is not possible
14:15karolherbst: there are sometimes like70 cstates
14:15karolherbst: and sometimes the 20 highest won't work
14:15mupuf: and when it does, clk can go down or up a cstate
14:15karolherbst: you really want to try-fail?
14:16mupuf: well, you are lying a little, aren't you? Since we will get rid of the cstates that we can never use
14:16karolherbst: nope, not really
14:16karolherbst: maybe we have only 5 that won't work though
14:16karolherbst: or maybe 8
14:16karolherbst: depends on the voltage map table
14:16karolherbst: but I only drop those, which volt_min is actually above max_uv
14:16karolherbst: max_uv might be 1.2V
14:17mupuf: ack, then maybe we need to do this
14:17karolherbst: the voltage table says: max is 1.0V for 80°C
14:17karolherbst: but 1.05V for 20°C
14:17mupuf: let volt understand frequencies as an input AND output
14:17mupuf: as in, with voltage X, I can get to frequency Y
14:17karolherbst: then I would put it into clk
14:17karolherbst: in the end we have something like this
14:17karolherbst: list of cstates
14:17karolherbst: selected cstate
14:18karolherbst: then we check which cstate can be actually used with the given temperature
14:18karolherbst: but we have to know, which cstate was selected
14:18karolherbst: this is an important thing to remember
14:18mupuf: that is definitely super important
14:19mupuf: the target cstate and the actual cstate need to be de-correlated and both saved
14:19karolherbst: but it is no problem to do in clk, we just get some volts out of the cstates and compare. or we just do the cstate logic in clk
14:19karolherbst: and the volt logic in volt
14:19karolherbst: like nvkm_volt_is_volt_possible(cstate->voltage, tempertature)
14:20karolherbst: and clk just has this little call
14:20karolherbst: or we call it "currently_possible
14:20karolherbst: " and drop the temperature parameter
14:20mupuf: maybe we should let volt say what is the maximum cstate or frequency achieveable
14:20karolherbst: but then we would have a therm dependency in volt
14:21karolherbst: then we could just give a list of cstates to volt and let it choose
14:21karolherbst: the problem is just, the dependency management is quite ugly then
14:21mupuf: well, a therm dependency in volt makes more sense than clk, right?
14:21karolherbst: mupuf: do you know why there are two max volt entries?
14:21mupuf: I mean, I agree, this is all fuzy
14:22karolherbst: it is quite clever in the end
14:22mupuf: I am all ears!
14:22karolherbst: max0: -- ID = 0, mode: 0 link: ff, voltage_min = 1212500, voltage_max = 1212500 [µV] c0 12125000 c1 0 c2 0 c3 0 c4 0 c5 0--
14:22karolherbst: well stupid value, but who cares
14:22karolherbst: max1:-- ID = 2, mode: 1 link: ff, voltage_min = 1137500, voltage_max = 1200000 [µV] c0 21467255 c1 0 c2 -97 c3 0 c4 0 c5 0--
14:22karolherbst: temperature dependent parameter!
14:22karolherbst: for some vbios, these create nice curves
14:22karolherbst: where both curves actually cut
14:23karolherbst: like max0 could be 1.75V
14:23karolherbst: and max1 is between 1.6 and 1.9V depending on the temperature
14:23karolherbst: or something like that
14:23karolherbst: this is part of GPU Boost 2.0
14:24karolherbst: temperature as a factor to limit the max voltage
14:24karolherbst: insane, but quite clever
14:26mupuf: Hmm, I see, makes sense!
14:26mupuf: would be nice to add a comment
14:26karolherbst: -- ID = 0, mode: 0 link: ff, voltage_min = 1137500, voltage_max = 1300000 [µV] c0 61560327 c1 -55017 c2 150763 c3 0 c4 0 c5 0--
14:26mupuf: but yeah, this is really complex
14:26karolherbst: -- ID = 1, mode: 1 link: ff, voltage_min = 1168750, voltage_max = 1225000 [µV] c0 22208000 c1 0 c2 -97 c3 0 c4 0 c5 0--
14:26karolherbst: here, a good example actually
14:27mupuf: so, to go back to where to draw the line between clk and volt
14:27karolherbst: I would say
14:27karolherbst: clk needs to choose which cstate to clock to in the end
14:28mupuf: sounds more than reasonable
14:28karolherbst: volt can decide if a selected voltage_map_id can be set
14:28mupuf: clk manages clock
14:28karolherbst: cstate->voltage is it
14:28mupuf: how about giving a cstate as an input?
14:28karolherbst: in the end, clk only needs to do that: nvkm_volt_can_volt_be_set(volt, cstate->voltage);
14:29karolherbst: then volt include clk headers
14:29karolherbst: not sure why we want that
14:29mupuf: oh, circular dependency
14:29karolherbst: and passing a number is no big deal
14:29karolherbst: maybe even a second one, we just have to decide where to get the temperature
14:29mupuf: well, we need to add a comment about why we are doing things this way then
14:29karolherbst: it might make sense to read the temperature inside volt
14:30karolherbst: volt actually changes behaviour depending on the temperature
14:30karolherbst: that's why, volt should be able to read the temperature, because it is one of its inputs
14:30karolherbst: but for simplicity we can just pass the temperature to the volt function and read it only out once
14:30karolherbst: or something
14:34mupuf: i;m back
14:35mupuf: how is it simplifying anything to put the temperature in the interface?
14:36mupuf: so, we need to decouple the computation of what voltage needs to be set and what cstate needs to be set
14:37karolherbst: in the end clk calls volt to set a voltage
14:37mupuf: so as we can make one decision and then apply it
14:37karolherbst: so clk can also ask volt if a voltage can be set
14:37mupuf: but why clk needs to know about min_id?
14:38mupuf: shouldn't clock read that out on its own?
14:38karolherbst: because it is inside the pstates
14:38mupuf: err, volt
14:38mupuf: oh fun and joy :p
14:38karolherbst: each pstates has it's own voltage_map_table id
14:38mupuf: then we have a clear dependency
14:39karolherbst: like each cstate, each pstate also has it's own voltage entry, so it really doesn't add anything new
14:39karolherbst: it is just inside pstate.base->voltage
14:40karolherbst: ... pstate->base.voltage actually
14:41mupuf: well, you convinced me
14:41mupuf: there is no other way
14:41mupuf: min and max are indeed just parameters
14:41mupuf: let me recheck the code with this perspective again
14:41karolherbst: there are always two kinds of max/mins:
14:41karolherbst: hw limit (inside volt)
14:42karolherbst: sw limit (inside clk)
14:42karolherbst: actually sw limit is inside clk/therm
14:43karolherbst: min is pstate->base.voltage, max is nvkm_volt_map(volt, max0/max1, temperature)
14:44karolherbst: is it weird that only now notice how insane this all is?
14:44karolherbst: an hour ago I was like thinking, actually this makes all sense
14:44mupuf: well, it does make sense to some degree
14:44karolherbst: in the end the max/mins are limited by two things
14:45mupuf: hw is the simple one
14:45mupuf: temperature/pstate is the new one
14:45karolherbst: though the pstate ons is a bs one. It makes no sense somewhat
14:45karolherbst: because it actually increases power consumption with no real benefit
14:45mupuf: pstate what?
14:45karolherbst: at least I don't see the benefit why to virtuall increase the voltage
14:45karolherbst: -- ID 0xf Voltage entry 8 PCIe link width 255 8.0 GT/s -- =>> -- ID = 8, mode: 0 link: 9, voltage_min = 887500, voltage_max = 1000000 [µV] c0 13988576 c1 -2710 c2 12 c3 0 c4 0 c5 0--
14:46karolherbst: and in fact
14:46karolherbst: this can also depend on the temperature....
14:46karolherbst: it is more like, each pstate has it's own temperature dependeng minimum voltage we never should go underneath
14:53karolherbst: mupuf: reworded commit https://github.com/karolherbst/nouveau/commit/81f250bb8591e1702d601e5b678375652906f34b
14:56mupuf: karolherbst: good. just don't forget the '.' after the word 'has'
14:56mupuf: oh, you never put a stop to sentences
14:57mupuf: oh well
14:57karolherbst: sometimes I do...
14:57karolherbst: the . at the end looks weird somwhat, dunno, I should decide how I do this
15:07mupuf: karolherbst: so, what about the temperature parameter? I do not think the clk subdev should care about it
15:08karolherbst: mupuf: right, but I was thinking, how often do we want to read the temperature out?
15:09karolherbst: my idea was, while we reclock, the temperature might actually not change, so we are safe to read it out once and safe some mmio accesses
15:10mupuf: saving mmio accesses is fine
15:11mupuf: as in, useless
15:11mupuf: but, I think it is safer to read it once
15:11mupuf: and then stick to it
15:11mupuf: until we check again if the state is valid
15:11mupuf: or if we need to change voltage
15:11karolherbst: which will happen in a second then anyway
15:11mupuf: or change cstate, in which case we do the full reclocking again
15:25karolherbst: mupuf: is this also reviewed-by with a reword? https://lists.freedesktop.org/archives/nouveau/2016-March/024496.html
15:27mupuf: I have an email open for this, I forgot to finish it
15:27mupuf: will do before bed
15:27karolherbst: ahh okay
15:34pecisk: karolherbst: I read phoronix and by sound of it getting re-clocking going on Maxwell is even harder than Kepler?
15:38karolherbst: pecisk: not harder
15:39karolherbst: pecisk: we just need more signed firmwares from nvidia
15:39pecisk: karolherbst: is there any hope to get them?
15:39karolherbst: yeah, we have to wait
15:40karolherbst: it is a bit more complicated than that though, cause nouveau needs to changes some interfaces internally
15:42pecisk: karolherbst: I will guess considering they will most likely keep using same method for future generations...propably worth it :)
15:42karolherbst: pascall will be all different (most likely=
15:42karolherbst: but it is nice that we don't need to do much on maxwell1
15:43RSpliet: karolherbst: pascal is rumoured to have GDDR5x instead of HBM2, it might not be so bad
15:44pecisk: talk about moving targets
15:44karolherbst: RSpliet: awesome
15:45karolherbst: with pascal we could even get day1 reclocking support then (as long as the other stuff is the same....)
15:45RSpliet: hah, if they release the PMU firmware before releasing pascal
15:45RSpliet: and we get the interface reworked in time
15:46RSpliet: only 3 months
15:46karolherbst: gnurou: how is the PMU situation going? :D
15:46RSpliet: I think Fermi reclocking is more likely to happen within 3 months than PMU firmware :-P
15:46karolherbst: ohh really
15:46karolherbst: nice to hear
15:47RSpliet: aka. don't get your hopes up too high ;-)
15:47RSpliet: (although, I judging by the script that I generate now, the middle perflvl might not be so far away)
15:48pecisk: All things considered people might be more interested in Fermi getting working than Maxwell tbh
15:49karolherbst: *Kepler :p
15:49karolherbst: but yeah
15:49RSpliet: odds are Fermi moves into legacy with the release of Pascal
15:49karolherbst: Fermi is really important
15:49RSpliet: so maybe...
15:49karolherbst: I can understand this, Fermi isn't as bad
15:49karolherbst: and some Fermis give decent performance
15:50karolherbst: pecisk: but it is really important to actually support reclocking on newest hardware though
15:50karolherbst: otherwise nouveua gets in a state like "yeah in 5 years you may want to use nouveau"
15:50pecisk: it is, but at this point Nouveau doesn't even do OpenGL 4.3 yet...so re-clocking takes second seat
15:50pecisk: so there's time
15:50karolherbst: OpenGL 4.3 is pretty unimportant
15:50karolherbst: who really needs that?
15:50pecisk: ohhh, it is important
15:50pecisk: two words - compute shaders
15:51pecisk: all big games depend on it
15:51karolherbst: and who uses that?
15:51pecisk: Bioshock Infinite, Middle Earth game
15:51karolherbst: the only "AAA" game I can't play is divinity OS
15:51karolherbst: and that's beacuse of shading_language_include
15:51karolherbst: I can play bioshock infinite with nouveau
15:51pecisk: ok, I haven't really tried it though ;)
15:52karolherbst: okay, let me rephrase, who actually _requires_ compute shaders
15:52karolherbst: all the revent AAA games run with current nouveau code
15:52karolherbst: or most of them
15:52karolherbst: most of them really crappy, but some of them even do with nvidia
15:52pecisk: because they have fallbacks I guess
15:52karolherbst: and that's why it is less important
15:53karolherbst: if there is no reclocking, you won't use nouveau for those games anyway
15:53pecisk: I would like to ditch binary river for my 760 GTX though
15:53karolherbst: and why can't you?
15:53karolherbst: my stuff seems to work now for most gpus
15:54pecisk: but if I had bought 9xx I would most likely planned to stick with binary
15:54pecisk: karolherbst: well, I can, I just haven't taken time to get it nouveau running properly :) It's still a manual switch atm right?
15:55pecisk: maybe I will upgrade to Fedora 24 and finally will say goodbye to nvidia driver
15:56karolherbst: yeah, we really need to stabilize the display stuff before we can even think about dynamic reclocking on desktops
15:56karolherbst: on laptops it will be much easier
15:57pecisk: karolherbst: what's needs to be done for stability? There's still hichkups when switching between modes?
15:57karolherbst: something like that, yes
15:57karolherbst: there is a so called linebuffer
15:58karolherbst: which buffers lines for the time the gpu can't access memory
15:59pecisk: karolherbst: is there any ETA when Kepler could have dynamic clocking?
16:00pecisk: any guestimates?
16:01karolherbst: until somebody with a desktop figures out the line buffer stuff
16:01karolherbst: for laptops? maybe this year
16:02karolherbst: I have some working prototypes, but we need benchmarks to actually check if out implementation is good
16:03pecisk: karolherbst: something I can run on my desktop?
16:04karolherbst: you could try to create those benchmarks
16:04karolherbst: games aren't the tricky part
16:04karolherbst: more like window managers
16:04karolherbst: spiky stuff like that
16:04karolherbst: which needs a short burst of perf
16:05mupuf: karolherbst: enough for today, I think the patches I left out will change a least a bit
16:05karolherbst: thanks for the comments
16:05karolherbst: regarding those coefficients: I did this more than a day on mine
16:05karolherbst: and I don't really plan to do that over ssh ...
16:05mupuf: yeah, it sucks
16:06mupuf: but have a look at pfuse at least
16:06karolherbst: I already did once, but I will have a deeper look later
16:07pecisk: karolherbst: ok, I will try to schedule time to do some real life usage benchmarking with dynamic code, most likely after 2 weeks
16:07pecisk: bb for now
16:07karolherbst: pecisk: I meant more like creathing....
16:08mupuf: karolherbst: an email to nvidia may work though, asking for the PFUSE registers used for the calibration
16:08mupuf: just the addresses
16:09mupuf: that may work
16:09karolherbst: mupuf: rb-by on this? https://lists.freedesktop.org/archives/nouveau/2016-March/024501.html
16:09karolherbst: mupuf: yeah, we can figure out the things ourselfs then
16:09karolherbst: it helps already where to actually look
16:09karolherbst: or maybe those factors are the same and I was just too sloppy...
16:09mupuf: no, no R-b because I want to have the temperature-polling part too
16:09karolherbst: ahh okay
16:10mupuf: we are getting close!
16:10mupuf: yeepee :)
16:10karolherbst: the "daemon" part is next on my list anyway
16:11mupuf: and here goes a 4-days-long week end where I once again could not look at the vbios issue
16:11mupuf: well, let's try again next week end!
16:11karolherbst: which issue?
16:15mupuf: uploading the vbios on GM2xx
16:15karolherbst: ohhh right
16:15mupuf: after this, we can start having a lot of fun with the GM2xx!
16:15mupuf: mostly related to power budgets and power lanes
16:15karolherbst: ohh did it change?
16:16mupuf: nope, but the blob exposes everything!
16:16mupuf: power usage and power cap
16:16mupuf: yep, it triggered me into buying it :p
16:16mupuf: well, if you want to have a look, you may already find it nice
16:16karolherbst: ohh I had fun with this on mine already
16:16mupuf: but faking the bios just does not work yet :s
16:17mupuf: but you are not sure about the reported power
16:17mupuf: if it is valid or not
16:17karolherbst: I know when the blob clocks down
16:17mupuf: because you do not know what power budget we should use and then you cannot validate the pwoer reading by lowering the cap
16:18karolherbst: I am sure this isn't wrong
16:18karolherbst: but it isn't everything
16:18mupuf: what the heck?
16:19mupuf: that sounds waaaayyy too insane
16:19mupuf: and just illogical
16:19karolherbst: try it out then :p
16:19karolherbst: well I did this:
16:19karolherbst: point all rails to entry 0
16:19karolherbst: point the main entry to entry 0
16:19karolherbst: put garbage into entry 1
16:19karolherbst: (for me it is 1 and 0)
16:19karolherbst: blob doesn't clock down
16:19karolherbst: mess with entry 0: blob forces min clock
16:20karolherbst: and there it is
16:20mupuf: well, you only have 2 power budgets
16:20karolherbst: it is a bit messy, because when I whipe out the entry 0 for me, blob refuses to boot
16:20mupuf: so, not a definite result
16:20mupuf: but there is something funky here
16:20karolherbst: there is a way to define a master power budget somewhat
16:20karolherbst: but I don't got the idea yet
16:21karolherbst: but those bits have an affect if you change enough
16:21mupuf: but it may simply be a flag
16:22mupuf: so, not defintie
16:22karolherbst: I couldn't change the 1st entry to be the main one
16:22mupuf: and the GM2xx will help for tis!
16:22karolherbst: but if you get this working, you could already use the information I got there
16:22mupuf: but it is time for me to sleep now
16:23mupuf: yeah, one thing at a time
16:28gnurou: karolherbst: not going anywhere for now I'm afraid :(
16:30karolherbst: gnurou: ohh why not? :(
16:30karolherbst: that's sad to hear
16:35karolherbst: gnurou: I would assume pascal is more important now, but still would be nice to know if something else is the problem
16:37gnurou: karolherbst: I cannot make any meaningful comment for now, but we are trying to find a solution
16:38karolherbst: I feared as much
16:44karolherbst: gnurou: but another question came up. I will just post the question on github
16:51karolherbst: gnurou: would be really awesome to get some kind of answer for this: https://github.com/Gnurou/nouveau/issues/13
16:51karolherbst: even if it is something like: 1. hw specific, 2. somewhere from mmio
16:51karolherbst: that would enough already
16:52gnurou: karolherbst: seen that, thanks - I will try to point the right people to it
16:52karolherbst: many thanks :)
16:52karolherbst: but is it understandable what I want to know?
16:52karolherbst: it is the Voltage map table from nvbios, but I assume you use different names