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