00:09 RSpliet: imirkin, skeggsb: isn't it easier to read the (max) tdms link bandwidth from the PLL limits table?
00:09 skeggsb: it's got nothing to do with pll capability
00:32 karolherbst: how bad is it in the kernel to return an unitiliazed value?
00:33 karolherbst: *uninitialized
01:06 RSpliet: karolherbst: unacceptable, they could lead to impossible-to-debug issues
01:07 RSpliet: (hence compiler warnings shouldn't be silenced)
01:07 karolherbst: yeah, I was wondering, because I found some in nouveau
01:07 mupuf: karolherbst: sounds fun!
01:08 RSpliet: skeggsb: surely there must be *some* correlation. A PLL must be able to provide a clock high enough for the TMDS to operate in a given frequency
01:08 RSpliet: but granted, it's not necessarily the bottleneck :-)
01:08 karolherbst: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c?id=refs/tags/v4.1.1
01:08 karolherbst: return ret; in all functions
01:09 hakzsam_: ret is initialized in nvif_unpack IIRC
01:09 karolherbst: ahh
01:09 karolherbst: macro?
01:09 hakzsam_: yes
01:09 karolherbst: mhh
01:09 RSpliet: this was explained on the mailinglist last week ;-)
01:09 karolherbst: :D
01:10 karolherbst: I see
01:10 hakzsam_: RSpliet, on dri-devel?
01:10 RSpliet: yep
01:10 sooda: those magic macros are just crazy if you ask me
01:10 sooda: was also completely puzzled for a while
01:11 karolherbst: yeah, this should have been more explicit
01:11 RSpliet: sooda: we're not asking you though :-P but yes, you're absolutely right
01:11 karolherbst: ret = nvif_unpack is no big deal...
01:11 sooda: just commenting that i also don't like it :)
01:12 sooda: the macro assumes that you have variables named data, size and ret :/ not a big deal if it were documented properly and if the macro name would be in caps to signify that it really is a magic macro
01:15 karolherbst: do you know a good way to extrace information about "safe" clockings from a card while only using generic code?
01:15 xexaxo: sooda: glad to hear that I'm not the only one thinking that way :-)
01:16 karolherbst: or should that be done through C states?
01:17 mupuf: sooda: how is your project coming along? Are you waiting for some feedback?
01:17 sooda: good code is concise, but i prefer readability over almost everything. :P there must be good reasons for several odd coding practices i've encountered besides just this, lack of docs just makes it worse than it probably actually is :/ i'd like to help with that, but that'd require lots of time which i don't yet have
01:18 sooda: mupuf: thanks for asking, some folks here internally are also reviewing some of my patches, but i plan to post to the mailing list too when i get several of them ready. they only make sense together really :/
01:19 sooda: i just got my head wrapped around the nvif thing and got a proof-of-concept working with our internal libdrm-replacement
01:19 sooda: one odd thing tho
01:19 sooda: i needed to bypass the security thing that disallows userspace ("usif") to call mthds on objects created from the kernel
01:20 sooda: because i need to call mthds on those fifo channel objects that are NEW'd from kernel
01:20 sooda: nvkm/core/ioctl.c:
01:20 sooda: if (owner != NVIF_IOCTL_V0_OWNER_ANY && owner != handle->route) {
01:20 sooda: - nv_ioctl(object, "object route != owner\n");
01:20 sooda: - return -EACCES;
01:21 mupuf: sooda: well, i guess having a bitfield to store the access rights on a method or object would make more sense than using a boolean then :D
01:21 sooda: that's something i've been trying to ask but haven't got my question phrased correctly
01:21 mupuf: do you need RW access to the object?
01:21 sooda: nouveau_channel.c does lots of stuff already but that path is marked deprecated, so maybe it's slowly moving to userspace?
01:21 sooda: yeah i do
01:22 mupuf: well, I have no clue about context management, as I already told you
01:22 sooda: need to write some regs too, but the features are nicely separated so it's not like userspace would want to write some arbitrary regs
01:22 mupuf: but I know a thing or two about security (got my masters in it)
01:22 mupuf: so we can have a look at the security model
01:22 sooda: k, i'll probably ask this in the mailing list too at some point
01:23 mupuf: definitley, the wider the exposure, the better
01:23 sooda: starting a three-week vacation next week tho :/
01:23 mupuf: then I guess you should aim for submitting your patch series before the end of the week
01:23 sooda: yes :)
01:28 mupuf: sooda: hopefully, we will have time to review your code in the 3 weeks timeframe! :D
01:28 sooda: hehhee
01:28 mupuf: The first review always takes the longest
01:29 sooda: that's not much in number of lines though, it's just taken time to understand all that is required for me as a newcomer
01:30 sooda: and the new features wouldn't probably be accepted before they are supported in upstream mesa or something, but any comments would be nice :p
02:36 karolherbst: is somebody here with some knowledge about the pstate sysfs code?
02:36 karolherbst: or pstate handling inside the driver?
02:43 RSpliet: karolherbst: do you have any specific questions?
02:43 karolherbst: yeah, I would like to know the current frequency of the gpu
02:44 karolherbst: and what shows the pstate behind NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT
02:44 karolherbst: is attr.min and attr.max from the struct fetched with NVIF_CONTROL_PSTATE_ATTR_V0_STATE_CURRENT also the current clock?
02:47 karolherbst: I want to write a little debugfs or sysfs interface, which shows the current pstate and its available frequencies, so that someone can manually set the frequencies according the the values "allowed" by the pstate
02:48 RSpliet: I *think* mlankhorst RE'd parts of this
02:49 RSpliet: I never dealt with clocks newer than Tesla, where there's only a single clock defined
02:49 karolherbst: ohh, I saw the gk104_clk_read functions
02:50 karolherbst: I suppose nv_clk_src_gpc is the gpuclock?
02:50 karolherbst: mhh, I see, but I want to write it a generic way, without requiring changes in the device specific code paths
02:51 RSpliet: I *think* right now it just takes the pstate from sysfs and always sets the high clock for it
02:51 RSpliet: you can verify with nvatiming
02:52 RSpliet: it would surprise me if the official driver does anything differently (rather I'd expect them to take the low freq als their lower bound for clock gating); but that's speculation
02:54 karolherbst: currently if I set the pstate the lowest clock is set
02:55 karolherbst: which isn't the "real" lowest one either
02:55 karolherbst: the pstate interfaces says 405MHz, but through blob it says 135MHz for the min freq
04:43 karolherbst: yeah
04:46 karolherbst: mhh strange
04:46 karolherbst: ahh no, memory clocking has to be doubled.
06:30 thopiekar: Hi, I've got a problem here with our driver. It is related to bug 70390 and it happends very often when using KDE Plasma 5 desktop. Just wanted to tell that here, as I don't own an account at freedesktop.org and someone said in the bug report that this problem is not easy to reproduce..
06:31 mupuf: thopiekar: yes?
06:31 mupuf: thopiekar: what hw do you use?
06:31 mupuf:does not seem to have any probs with nouveau and kde plasma 5
06:32 mupuf: I mostly run it on an nva8 though
06:32 thopiekar: Actually, here on Plasma 5 (with compositor enabled!) it happens very often! Just had to restart 10mins before because I get a bluescreen - just the cursor was left and I wasn't able to switch to a tty
06:32 thopiekar: mupuf: moment, will pastebin my dmesg | grep nouveau
06:33 mupuf: thopiekar: seems serious
06:33 mupuf: however, I doubt it is linked to bug 70390
06:33 mupuf: same symptoms, different reasons
06:34 thopiekar: http://pastebin.com/CVj7m7cD
06:34 thopiekar: mupuf: but as in 70390 I get: nouveau E[ PFIFO][0000:02:00.0] CACHE_ERROR - ch 6 [kwin_x11[1654]] subc 0 mthd 0x0060 data 0xbeef0201
06:35 mupuf: yep, as I said, same symptoms, does not have to be the same reason
06:35 mupuf: NVAA, that is rare-enough
06:37 thopiekar: Btw. and when resizing windows (they get transpartent and animated during compositor usage) the complete monitor screen is flickering.. have to move the window allover the screen to redraw the old fragments
06:38 mupuf: I see
06:38 mupuf: I already had this problems when working on DRI2
06:38 thopiekar: well, it is a simple onboard GPU, but I really don't need more performance ;)
06:39 mupuf: sure, that should be fast-enough
06:40 mupuf: how easy is it to reproduce the flickering issue?
06:40 thopiekar: Totally easy just need to double click any window border I want
06:41 mupuf: ok, great!
06:41 thopiekar: btw. I'm using Ubuntu wily (currently under heavy development)
06:41 mupuf: oh, xmir, that is a potential problem here
06:42 thopiekar: XMir? I'm should be using clean X11. At least didn't noticed they switched to that
06:43 mupuf: hmm
06:44 mupuf: Can you check how many patches they applied on top of different projects?
06:44 mupuf: xserver, drm, mesa, linux?
06:45 thopiekar: I beleave it is more than I can think about :/
06:45 thopiekar: checked my installation for xmir packages.. none of them are installed..
06:46 imirkin: thopiekar: what kernel are you on?
06:47 thopiekar: mainline kernel: 4.0.5
06:48 imirkin: hm ok. that's well after the nvac patches went in...
06:49 imirkin: thopiekar: did nouveau ever work well on your hw btw?
06:49 thopiekar: Hopefully unpatched.. I also hoped it might fix that. Is there a chance that my problem is fixed on newer kernel versions?
06:49 imirkin: the patches i'm thinking of went into like 3.17 or so
06:50 thopiekar: imirkin: it worked on Ubuntu Utopic: kernel 3.16
06:52 imirkin: the patches went into 3.19 it seems
06:52 thopiekar: looks like these patches made something broken.. Will be downgrading to 3.16 enough to verify?
06:52 thopiekar: or in this case 3.18
06:53 imirkin: haha, what makes you say it's THOSE patches? just coz they touched nvaa?
06:53 imirkin: since the issue is easy to repro, a bisect would be ideal
06:54 thopiekar: imirkin: well, would be useful to have a timeline were we can find the patch that causes that problem, isn't it?
06:54 imirkin: exactly. that's what the bisect is for
06:55 imirkin: (search for "git bisect" if you don't know what i'm talking about)
06:59 thopiekar: never heard about this git command.. how does it work? Will I have to rebuild the kernel for every commit made on the nouveau driver?!
07:00 imirkin: no, just log of the commits made to nouveau
07:00 imirkin: log2 to be precise
07:03 mupuf: imirkin: what makes you think the bug is in the kernel?
07:03 imirkin: mupuf: it's just a thought
07:04 mupuf: thopiekar: I would suggest trying different versions of the linux kernel
07:04 imirkin: given the combination of "nvaa", "flickering" and "we messed around with NISO"
07:04 mupuf: and see if you can reproduce the issue
07:04 imirkin: mupuf: aka a bisect, but less efficient?
07:04 mupuf: more efficient than recompiling :)
07:04 mupuf: at least on arch and its rollback machine
07:04 imirkin: meh, recompile takes just a few minutes
07:05 imirkin: unless you're building a distro kernel, but... why would anyone (other than a distro) do such a thing
07:05 mupuf: recompiling a kernel on ubuntu is not as trivial as gentoo
07:05 imirkin: i fail to see how the distro is related to kernel compilation
07:05 imirkin: i assume it's relatively simple to install gcc on ubuntu
07:06 mupuf: I assume he does not know what drivers he need
07:06 imirkin: which has little to do with the distro one is using :p
07:07 mupuf: it does, /me doesn't care about this because I compile a full kernel with an initramfs because it is trivial on arch
07:07 imirkin: it's trivial anywhere... just takes a year to build
07:08 imirkin: and you get to deal with initramfs issues down the line
07:09 mupuf: issues?
07:09 imirkin: you're telling me you've never had to spend time debugging an issue that boiled down to something being messed up with the initramfs?
07:10 imirkin: either what was in it, or loading it, or something
07:11 mupuf: A few times, I copied the initramfs to the linux image and vice versa, that's it
07:12 imirkin: well, when there's an actual issue with it... let me tell ya -- good times. anyways, i aim to have simple systems that i can understand. the fewer complexities the better.
07:19 karolherbst: wow, there are a lot of cstates on my card :/
07:19 thopiekar: imirkin, mupuf: sorry, but I was afk and X11 just started..
07:21 thopiekar: here the pastebin again (with new dmesg's): http://pastebin.com/CVj7m7cD
07:22 karolherbst: so I hacked now a little interface together to extract the different cstates from the currently active pstate: https://gist.github.com/karolherbst/5aae00917719646f8282
07:22 karolherbst: in theory I should be able to set the gpu to one of these cstates, right?
07:23 karolherbst: whats weird, that the gpu clock is doubled
07:23 imirkin: thopiekar: well, 0x60 is DMA_SEMAPHORE which is the dma object for fences. dunno why you'd be getting a CACHE_ERROR there =/
07:24 thopiekar:is installing now kernel 4.0.7 and 3.16.x and 3.18.x for testing
07:25 karolherbst: ...
07:25 karolherbst: wait a second
07:25 karolherbst: could it be, that the amount of cstates stored are limited? Because I think there are some missing
07:26 imirkin: karolherbst: perhaps you'd be interested in the 'nvbios' utility in envytools
07:26 thopiekar: imirkin: flickering on window resize now disappeard for some reason o.O'
07:28 karolherbst: how can I print something random to dmesg? :D
07:29 karolherbst: imirkin: yeah, I know, but somehow I never managed to get the right offsets :/
07:31 martm: karolherbst: i belive they call such user inclined, there is a minor weirdo method too, since windows tool can clock all cards, there is a possible hack to bring in a windows driver, mmiotrace this one
07:32 martm: https://www.youtube.com/watch?v=xXpLd4Sk2oQ they have such gui tool, notskrnl hack needs to be done via ndiswrapper
07:32 karolherbst: martm: can't just gk104_clk_calc clock to a known cstate
07:32 karolherbst: ?
07:33 imirkin: karolherbst: nvbios should be able to decode that stuff as-is...
07:33 karolherbst: I see
07:33 karolherbst: martm: I don't think that works on my card anymore
07:33 karolherbst: martm: https://forums.geforce.com/default/topic/668461/gtx-770m-overclock/
07:33 karolherbst: they also use only offsets for overclocking
07:34 martm: allright. so this tool no longer works, hmm
07:34 karolherbst: never tried it though
07:34 karolherbst: but even the blob driver uses only offsets
07:34 karolherbst: and it took a long time until they added the option
07:35 karolherbst: but its fine as it is now
07:35 martm: karolherbst: and yeah you can hardcode stuff to some sort of bios, to use some higher default state
07:36 karolherbst: I just think, that if I select a pstate through sysfs, it will stay at the lowest possible clock
07:36 martm: there are tools that do this, some dos mode tools you know
07:36 karolherbst: mhh
07:36 karolherbst: but its a laptop
07:36 karolherbst: :D
07:37 karolherbst: the thing is just, that nouveau driver performance doesn't come nearly to 25% of blob driver currently
07:37 karolherbst: and I think its beacuse of the gpu clock
07:38 martm: yeah it is because of a clock:)
07:38 martm: reflash the vbios, or load the binary and change the state
07:39 martm: binary/blob driver, but you told you could not do that, then some windows driver is needed
07:39 martm: windows drivers definitely have all sort of tools
07:39 karolherbst: why can*t I simply set the cstate?
07:40 karolherbst: even if somebody can do it manually through a sysfs/debugfs interface, it should be better than requiering blob/windows
07:42 martm: i dunno how can't you understand:) to set it it requires code to be implemented:)
07:42 martm: some mmio magic that those guys here try to trace
07:43 thopiekar: flickering still here: 3.18
07:44 thopiekar: now getting so far four times: [ 225.151579] nouveau E[ VM][0000:02:00.0] failed to create 0x04000000, -28
07:44 karolherbst: martm: ahh okay, I see
07:45 imirkin: afaik we can set cstates just fine.
07:45 martm: karolherbst: you just leave some default from vbios on
07:45 imirkin: all the reclocking issues are around getting the memory to be happy. we can set the clocks to 100ghz for all we care.
07:45 martm: well i dunno much, just some ideas, so bye
07:58 thopiekar: sorry, but had another freeze here on 3.18
07:58 thopiekar: http://pastebin.com/Bt4ZWxkE
08:00 tobijk: thopiekar: please test kernel 4.0 or even better 4.1 and see if it freezes
08:01 thopiekar: tobijk: already tested it on 4.0.5 at the beginning of this conversation here.. ok, will get the latest 4.1.x kernel
08:02 imirkin: 4.1 is unlikely to make any difference
08:02 thopiekar: tobijk: what about v4.2-rc1-unstable?
08:02 imirkin: retest with 3.16
08:02 tobijk: thopiekar: in fact nobody will really hunt patches in old kernels im afraid
08:02 tobijk: *bugs
08:03 imirkin: tobijk: but it's important to validate assumptions like "problem started happening in version X"
08:04 tobijk: was a bit quick to answer after joining, i did not see the previous conversation here...
08:14 thopiekar:is rebooting to 3.16 now..
08:21 thopiekar: i'm now on kde5 + kernel 3.16.7 + glxgears running + projectm running + played with windows (maximizing and back)
08:21 thopiekar: [ 158.735552] nouveau E[ PFIFO][0000:02:00.0] CACHE_ERROR - ch 6 [kwin_x11[1706]] subc 0 mthd 0x0060 data 0xbeef0201
08:21 thopiekar: [ 165.593954] nouveau E[ PFIFO][0000:02:00.0] CACHE_ERROR - ch 1 [DRM] subc 0 mthd 0x0060 data 0x80000002
08:22 thopiekar: seems to be a much older problem, but (!) no flickering or whatever
08:24 tobijk: you could test 4.1 or 4.2rc, but i doubt it got fixed there :/
08:26 thopiekar: I really had to report that earlier :(
08:28 tobijk: did it ever work? (i guess imirkin already asked this)
08:29 thopiekar: Well, I never cared about that before 3.19 were I had first problems with it including kde5..
08:30 thopiekar: first of all I blamed it on kde5 but then read the dmesg
08:30 thopiekar:seems to be forced to use the closed-source nvidia driver :/
08:30 tobijk: kde5 may hit corner cases with some strange shaders, but sure novueau should not crash on encountering those :)
08:31 thopiekar: tobijk: well, since 3.19 I use MATE as a fallback desktop. Feel good with it as it was my first desktop I used on Linux (Gnome2)
08:32 tobijk: at least we havent destroyed your workflow then ;-)
08:32 karolherbst: so, I think I am finished
08:33 karolherbst: does anybody want to try out some cstate setting patch?
08:33 thopiekar: tobijk: well, using Linux long enough to know about alternatives ^^
08:33 karolherbst: I can't test it, because nouveau can't raise the voltage of my gpu :/
08:33 thopiekar:is rebooting now (again)
08:33 thopiekar: see you :)
08:39 karolherbst: is there any voltage work done for gpus like nve6?
08:43 thopiekar: Well, works now.. Linus really has to show middlefingers often.. Think there was something missing in the docs you got by nvidia..
08:43 tobijk: huh?
08:43 tobijk: with 4.1?
08:44 karolherbst: my card also started to work with 4.1
08:44 thopiekar: tobijk: using the closedsource driver now..
08:44 tobijk: ah :/
08:47 karolherbst: ...
08:47 karolherbst: :D
08:50 tobijk: yay there we go again ~_~
08:52 tobijk: imirkin: did skeggsb say something about the crash i posted a few days ago?
08:52 imirkin_: not to me
08:52 imirkin_: nor do i have any recollection of any such crash
08:53 imirkin_: but then my memory is most similar to a sieve
08:53 tobijk: https://homepages.thm.de/~tjkl80/nve_fault.txt
08:53 tobijk: https://homepages.thm.de/~tjkl80/nve_fault2.txt
08:57 imirkin_: ah right
08:57 imirkin_: but i have no clue what they mean, beyond the obvious
08:57 tobijk: happens suddeny while nouveau is not in use
08:57 tobijk: i guess X wakes it up for some reason
08:58 tobijk: after X restarted nouveau is usable again
09:04 imirkin_: mogorva: can you file a new bug for the tomb raider issue? fairly sure that one's in nouveau
09:04 imirkin_: and totally unrelated to anything shader-related
09:05 mogorva: imirkin: Hi! sure...do you need a new trace?
09:05 imirkin_: mogorva: no, please use the same one. i actually created a cut-down version that still repros the issue.
09:05 imirkin_: i'll put that up somewhere later
09:06 imirkin_: i think it has to do with something very annoying like face culling. or depth compares.
09:06 karolherbst: maybe stupid question, but how imporant is the voltage regulator for clocking the card?
09:07 imirkin_: aka things that i have a much harder time debugging than simple shader failures :)
09:07 imirkin_: karolherbst: well, chances are the people who designed the circuits know something about voltage
09:08 imirkin_: it'd be fine to create a config flag that skipped it, but it'd be very much a "use at your own risk" type situations
09:08 imirkin_: underdriving circuits is probably going to be fine, but overdriving... who knows
09:08 imirkin_: (by "fine", i mean "no physical damage")
09:09 imirkin_: you just get a glitchy clock or no clock at all
09:09 karolherbst: yeah, but I mean, if I skip the voltage steps while setting a cstate, should it work, aka does the gpu clock increases, or will nothing change
09:09 karolherbst: ahh I see
09:09 imirkin_: or you could spend a bit of time and figure out why the voltage reclock fails
09:09 imirkin_: er, set
09:09 karolherbst: I could
09:09 karolherbst: at least I got the bios now
09:10 imirkin_: it was in /sys/kernel/debug fyi
09:10 karolherbst: I used the envytool tool
09:10 imirkin_: that will only work if it's on the card
09:10 imirkin_: which it often isn't, esp in laptops
09:10 karolherbst: seems to have worked
09:10 imirkin_: although i guess nouveau will stick it into PRAMIN on init, so i guess it's ok
09:11 karolherbst: the tool said my card had even two
09:11 karolherbst: "Card has second bios"
09:11 imirkin_: yeah, that's a different thing
09:11 imirkin_: it's 2 in one place
09:11 imirkin_: not 2 in diff places
09:11 imirkin_: :)
09:11 karolherbst: PRAMIN didn't work though
09:11 karolherbst: I see
09:12 imirkin_: anyways, if you want to use the very same thing nouveau sees, grab the one from debugfs
09:13 karolherbst: "/sys/kernel/debug/dri/1/" ?
09:13 imirkin_: yep
09:13 karolherbst: there are 6 directories in dri
09:13 imirkin_: usually /0 but it's on the second card for you, so /1 makes sense
09:13 imirkin_: the ./64+ stuff is... there to confuse you :)
09:14 karolherbst: k
09:14 karolherbst: but how do I verify if the csate stuff is right? can the nvbios tell be wrong about the cstates inside the bios?
09:15 imirkin_: of course
09:15 imirkin_: the only thing that never lies is the gpu hw when you read registers from it
09:15 karolherbst: k
09:15 imirkin_: but there isn't exactly docs for any of this stuff, so... :)
09:16 imirkin_: it's all RE'd and subject to being wrong or being right for only certain GPUs or VBIOS versions
09:16 karolherbst: I also have a 4th pstate in the bios, but this might be gpuboost related
09:16 karolherbst: "3: pstate 0 index 0"
09:17 tobijk: meh this starts to get annoying :/
09:17 imirkin_: if the pstate id is 0xff, then that means "skip"
09:17 imirkin_: that's how we force the blob to clock to a particular level -- just 0xff-out all the other ones
09:17 imirkin_: (+ nvafakebios)
09:18 imirkin_: which sticks a faked copy of the vbios in vram which is the first place the blob checks
09:18 karolherbst: the boost table looks interesting
09:19 karolherbst: https://gist.github.com/karolherbst/0338cd0e503aea5c4f47
09:19 karolherbst: at least there are the right clocks if you devide it by 2
09:22 imirkin_: pmoreau: see what happens when you open your big mouth? :p
09:40 karolherbst: imirkin_: it returns EINVAL somewhere, I don't think the driver is even trying, maybe just if(unsupported) return -EINVAL or something
09:40 imirkin_: karolherbst: maybe. or maybe it can't find the GPIO.
09:41 imirkin_: fyi, nvidia were kind enough to provide a DCB spec, which is part of the vbios. as part of it, they also listed out what all the various gpio's were for...
09:41 karolherbst: I can't control the fan either
09:41 imirkin_: that's coz it's not hooked up -- you're on a laptop, where it's all integrated
09:41 karolherbst: okay
09:41 karolherbst: yeah I heard about the pm stuff
09:42 imirkin_: this is the dcb spec: ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html
09:42 imirkin_: specificlaly the GPIO assignment table bits
09:43 imirkin_: it has all the vsel bits and fbvref
09:44 karolherbst: thanks for the link
09:49 karolherbst: imirkin: do you know a bit about the nvkm_volt_set bits?
09:49 imirkin_: not beyond being able to pull it up and read it
09:50 karolherbst: I hacked some nv_debugs in the code: https://gist.github.com/karolherbst/2784b27d45e86c743ad3
09:50 karolherbst: the different values are part of the volt->vid table
09:50 karolherbst: I think it tries to set it to an "unsupported" value
09:51 imirkin_: and so it never hits the right value
09:51 karolherbst: maybe some calculations have to be corrected?
09:51 imirkin_: maybe. or maybe just set it to the first voltage value > request
09:51 imirkin_: if it's within a mv or so maybe?
09:51 karolherbst: mhh strange is, that its always the same voltage requested
09:51 karolherbst: even if I try to set a different cstate
09:52 imirkin_: i guess track where that's coming from?
09:52 karolherbst: also 07 missed, but different value
09:52 imirkin_: i think a lot of people have had issues with the voltage setting not working thing
09:52 imirkin_: so this isn't just a you thing
09:52 karolherbst: k
09:53 imirkin_: which somewhat negates the benefits of reclocking :)
09:53 karolherbst: nvkm_cstate_prog should be the right function to set the pstate, or do you not know?
09:53 imirkin_: not offhand
09:53 imirkin_: check the sysfs pstate thing
09:53 imirkin_: and trace from there :)
09:53 imirkin_: the code is a total maze
09:53 karolherbst: ahh right, pstate also uses it
09:54 karolherbst: but with a 0 index
09:54 karolherbst: as the cstate
09:54 karolherbst: nah, its fine
09:54 karolherbst: imirkin_: do you know http://lxr.free-electrons.com/ ?
09:54 imirkin_: yea
09:54 karolherbst: :)
09:54 imirkin_: and i know ctags
09:54 karolherbst: nice site
09:55 karolherbst: k
09:55 imirkin_: that doesn't make it not a maze :p
09:55 imirkin_: those are just tools to navigate a maze
09:55 karolherbst: ....
09:55 karolherbst: wait
09:55 karolherbst: the cstate parameter isn't used?
09:55 karolherbst: yeah, well
09:56 karolherbst: no wonder my cstate setter always tried to set the same voltage...
10:01 karolherbst: imirkin_: https://github.com/karolherbst/nouveau/commit/f8e698632cb2bf0696a8f5015bcaeaa63844471d
10:01 karolherbst: maybe there is a better list function for this
10:01 karolherbst: also validation needed I guess
10:03 imirkin_: you basically want to get list[n] right?
10:03 karolherbst: yeah
10:04 karolherbst: but this patch won't fix anything, yet
10:04 karolherbst: but its important if someone want tos elect an explicit cstate
10:05 imirkin_: hm yeah, i don't see any way to get the Nth list item. but since it's a linked list, what you have seems fine.
10:05 karolherbst: I also saw it in other places
10:06 imirkin_: the cstate doesn't know what number item it is?
10:06 karolherbst: no
10:06 imirkin_: k
10:07 karolherbst: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/include/nvkm/subdev/clk.h#L50
10:09 karolherbst: the voltage table in nvbios is too short
10:09 karolherbst: there are only 8 entries
10:09 imirkin_: yeah, nvbios and the kernel parser are probably out of sync by now
10:10 karolherbst: k
10:10 imirkin_: ben was mentioning that he was hoping to unify that at some point
10:12 karolherbst: imirkin_: " return id ? id * 10000 : -ENODEV;"
10:13 karolherbst: and id is 10 for pstate 0a
10:13 karolherbst: this function seems to give the wrong value: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nvkm/subdev/volt/base.c#L64
10:13 karolherbst: I guess vmap is empty
10:14 imirkin_: or is parsed wrong :)
10:14 karolherbst: this would be a big cooincidence :D
10:14 karolherbst: allthough
10:15 karolherbst: yeah, right
10:18 karolherbst: imirkin_: do you think I could set it to the nearest lower voltage as a workaround to try stuff?
10:18 imirkin_: my personal guess would be next highest...
10:19 imirkin_: as long as it's reasonably close
10:19 imirkin_: like 1 or 10mV
10:19 imirkin_: as opposed to like 10V ;)
10:19 karolherbst: the highest cstate already sets it to a value higher then inside the table
10:19 karolherbst: cstate: 1250000uv, highest inside table: 1190208uv
10:20 imirkin_: take a look at the vbios with a hex editor
10:20 imirkin_: perhaps there are more entries and the number of entries is misunderstood or misapplied
10:20 karolherbst: sadly the blob driver doesn't tell me the voltage :(
10:22 karolherbst: but I think its safe to say, that something is wrongly parsed
10:23 imirkin_: don't give the vbios writers too much credit
10:23 imirkin_: it's not nvidia putting the vbios together, it's the board manufacturer.
10:24 imirkin_: (obviously using a nvidia-written tool, but i think it gives a lot of leeway)
10:32 hakzsam_: imirkin_, do you know why notifier BO are unecessary for Fermi+?
10:33 imirkin_: hakzsam_: all that dma stuff is gone
10:33 imirkin_: but tbh, no. i never quite understood what the notifier object was.
10:33 imirkin_: seemed to work!
10:34 imirkin_: but iirc fences & co had to go into the notifier object?
10:34 hakzsam_: okay, because on nv50 I use a notifier BO to read back perf counters, how can I do that on nvc0?
10:35 hakzsam_: yes
10:35 imirkin_: just use a plain ol' bo
10:35 hakzsam_: what do you mean by "plain ol' bo" ?
10:35 imirkin_: nouveau_bo_new
10:36 hakzsam_: ah ok
10:36 hakzsam_: this seems to be simpler then :)
10:36 imirkin_: right.
10:37 imirkin_: the notifier thing isn't even really used on nv50 either
10:37 imirkin_: it's just used coz we have to create a notifier object
10:37 imirkin_: otherwise nothign works
10:37 imirkin_: but it's not used like it is on nv30 for example
10:38 hakzsam_: so, from nouveau DRM I could directly write perf counters to that plain BO?
10:38 imirkin_: where's the nv50 code?
10:38 hakzsam_: http://cgit.freedesktop.org/~hakzsam/nouveau/commit/?h=nouveau_perfmon&id=4e62e344dcdc993f6cc010ee0db3b9ebd091a246
10:39 hakzsam_: look at nv50_priv_ctxdma_wr32() which writes data to the notifier BO
10:40 imirkin_: erm
10:40 imirkin_: wtf is this interface
10:40 hakzsam_: I think nothing is going to change for nvc0 if I pass the handle like on nv50
10:41 hakzsam_: this interface allows to tie perf counters to the command stream instead of using ioctls
10:41 imirkin_: no, i get *that*
10:41 imirkin_: so how dose is it work in the cmdstream? i.e. what are the commands?
10:41 imirkin_: here's how everything else works:
10:41 imirkin_: bo address; offset; commands;
10:42 imirkin_: there's also some dma notifier bs because that's how the GRAPH engine works, but if you're the one doing the writing, you don't care about any of that.
10:42 hakzsam_: just have to send a command with SUBC_SW(0xXXX)
10:42 imirkin_: right :p but what are the commands?
10:42 imirkin_: like, what do they do
10:43 imirkin_: how do you use them to do something useful?
10:44 hakzsam_: SUBC_SW(0x608) in begin_query(), SUBC_SW(0x60c) and USBC_SW(0x700) in query_end()
10:44 hakzsam_: these command are used in the series which implements nv50 perf counters IIRC
10:44 imirkin_: yeah, but i wasn't paying attention to that :p
10:44 hakzsam_: ah ok :)
10:44 imirkin_: so... how does it know where to return results?
10:45 imirkin_: also what are 608, 60c, and 700?
10:45 imirkin_: i.e. what is it that they do?
10:45 hakzsam_: it computes an offset with the sequence number and write results to the notifier BO
10:46 hakzsam_: 608, 60c and 700 are sw mthds ID
10:46 hakzsam_: they are declared in the sw mthd interface (ie. nouveau DRM)
10:46 hakzsam_: this is arbitrary
10:48 hakzsam_: you also have to remember that this notifier BO is actually a ring buffer used to store N last results
10:49 hakzsam_: btw, ben is still looking at the sw mthd interface, he should give me some feedbacks in the next few weeks
10:49 imirkin_: ok, so here's the thing ... i have no idea how your thing works or what it does at any level, tbh
10:50 imirkin_: your explanations make absolutely no sense to me
10:50 imirkin_: which... is fine -- they don't have to. but if you want feedback from me, you have to write up a thing that explains how the whole thing works
10:51 imirkin_: i know about methods. i know about sw methods. and i understand the concepts involved. what i don't understand is the *specific* API you've implemented
10:51 imirkin_: i.e. what do i write to these methods, what does writing to them end up doing, etc
10:52 imirkin_: how do i ask for data, how do i get it back
10:54 hakzsam_: okay, let me explain again :)
10:54 imirkin_: hakzsam_: write it up somewhere
10:54 imirkin_: irc is not the proper place for such things
10:55 hakzsam_: imirkin_, np, I will send you a pastebin link or something once I have finished to explain all of that stuff
10:57 imirkin_: sgtm
11:01 imirkin_: tobijk: if you could run piglit on your nve7 against HEAD on both mesa and piglit trees, i'd appreciate it. i'm going to update my piglit page, and i already have a gf108 and gk208 piglit run.
11:02 hakzsam_: and my nvd9 report
11:02 imirkin_: tobijk: do run with '-1 --dmesg' as well
11:02 imirkin_: hakzsam_: mmm.... dunno if the d9 will make it. my nvc1 run is more recent, and i think they're generally the same.
11:03 hakzsam_: sure
11:03 imirkin_: it'd be nice to refresh the nv50 thing though
11:03 imirkin_: which ideally would be 4 runs -- nv50, nv84-nv98, nva0/nvaa/nvac, nva3-nva8
11:04 hakzsam_: I have almost all nv50 ;)
11:04 imirkin_: hakzsam_: full piglit runs?
11:04 hakzsam_: only cards right now, but I could do some piglit runs if you want
11:05 imirkin_: if you could cover those 4 categories, that'd be pretty sweet
11:05 imirkin_: do make sure to update piglit (and mesa)
11:05 imirkin_: i.e. 1 from each category
11:05 hakzsam_: okay, let me plug my nva8 first
11:05 hakzsam_: yeah sure :)
11:09 imirkin_: hakzsam_: let me know what command line you're using to do piglit-run
11:10 imirkin_: so you don't waste time doing the wrong thing :)
11:10 hakzsam_: imirkin_, the command you provide on your page, is that okay?
11:10 imirkin_: yeah, that's fine :)
11:12 hakzsam_: piglit and mesa are building, this should take ~15 minutes, it's only a core2duo :)
11:12 imirkin_: no rush :)
11:12 hakzsam_: yep
11:12 imirkin_: i'm still doing my gk208 run
11:13 imirkin_: unfortunately the gm107 run on mupuf's card failed pretty miserably
11:13 hakzsam_: did you figure out why it fails?
11:13 hakzsam_: btw, I commented the z32f_s8 stencil blits broken issue this morning
11:14 hakzsam_: I can't reproduce the issue on nve6
11:14 hakzsam_: this is fermi only
11:14 imirkin_: hakzsam_: yeah i saw that. and it also confirms my piglit results.
11:14 imirkin_: but... still broken on fermi :)
11:15 hakzsam_: yeah, don't know why, I tried to take a quick look yesterday, but not results yet
11:15 hakzsam_: btw, it works fine with the blob
11:15 imirkin_: tangentially, i saw some *weird* stuff going on with fast-cleared zeta buffers in qapitrace
11:16 imirkin_: i suspect that we need to do something before we can sample from fast-cleared zeta buffers
11:16 imirkin_: but i have no idea what :)
11:16 imirkin_: should do a trace
11:17 hakzsam_: I should still have a mmt trace from the blob
11:17 imirkin_: well i dunno if that's the issue going on here
11:17 hakzsam_: btw, you should take a look at nvc0_surface.c:192, this is going to be strange for me :)
11:17 imirkin_: i just happened to see it in an apitrace i was debugging
11:18 hakzsam_: I think src->ms_x should be src->ms_y (according to nv50)
11:18 imirkin_: MOFOS!
11:18 hakzsam_: MOFOS?
11:18 imirkin_: yes! good find! iirc xexaxo even fixed the same thing on nv50
11:18 hakzsam_: but this doesn't fix that issue, unfortunately
11:18 imirkin_: i'm sure urban dictionary can help you with your confusion
11:19 hakzsam_: I'll take a look at it then
11:19 hakzsam_: do you want a patch for that ms_x stuff ?
11:19 imirkin_: yes please!
11:19 imirkin_: i bet it fixes some dumb piglits too
11:20 hakzsam_: probably
11:20 imirkin_: e.g. if things oddly worked with ms=4 but not ms=2 or ms=8
11:20 hakzsam_: well, time to dinner, see you a bit later
11:20 karolherbst: imirkin_: so fallback to lower voltage make sense nethertheless, because it might be broken for specific cards anyway
11:21 imirkin_: well, in that case it might just be the highest voltage
11:21 imirkin_: rather than "lower"
11:22 karolherbst: couldn't that be dangerous, if the parsed voltage is too high?
11:22 imirkin_: yeah, i dunno what the right thing is =/
11:22 imirkin_: sorry
11:22 imirkin_: you could trace your blob and see what it does
11:23 karolherbst: I have really bad experiences with tracing blob
11:23 karolherbst: building kernel with mmiotrace bringt up errors inside the kernel :/
11:23 karolherbst: in the blob driver
11:23 imirkin_: hm weird
11:25 karolherbst: I think the fallback make sense with a "max diff" value
11:25 karolherbst: like the voltage isn't allowed to be 0.01V higher than requested
11:25 imirkin_: seems reasonable.
11:45 xexaxo: imirkin: wohoo another 20+ fixes coming in a single letter change :)
11:46 imirkin_: does it fix a lot of tests?
11:46 imirkin_: i remember your change did, but this is in a diff place
11:52 xexaxo: haven't checked - (making up and) going with the crowd.
11:53 imirkin_: this appears to only get called for copy_region, which i don't think can actually get called on MS surfaces
11:57 karolherbst: imirkin_: seems to work :)
11:57 karolherbst: maybe
11:57 karolherbst: yeah
11:58 imirkin_: is it any faster?
11:58 imirkin_: with maor volts
11:58 karolherbst: imirkin_: what ya say: https://gist.github.com/karolherbst/d94e895588800c46e859
11:58 karolherbst: didn't test
11:58 karolherbst: but pstates changes freqs
11:58 karolherbst: I guess so
11:59 karolherbst: the volt function returns 0 now
11:59 imirkin_: yay
11:59 imirkin_: before it was at 405 i assume?
12:00 karolherbst: yeah
12:00 karolherbst: https://github.com/karolherbst/nouveau/commit/646666dc31be5cc5ffdf4268c6131c265254ba49
12:00 karolherbst: nice!!!
12:00 karolherbst: talos 18 fps :)
12:00 karolherbst: high setting
12:01 karolherbst: ...
12:01 karolherbst: or
12:01 karolherbst: wait :D
12:01 imirkin_: but now the walls are *really* green :p
12:02 karolherbst: mhh, seems like false alarm :/ the game set the gpu speed to low again :(
12:02 karolherbst: this makes me sad
12:03 imirkin_: oh, i noticed a bug that could cause a lot of stalls to happen...
12:03 karolherbst: allthough
12:03 imirkin_: depending on what the game was doing
12:03 karolherbst: no, something changes
12:03 karolherbst: 418 MHz, glxpsheres 270 fps
12:03 imirkin_: like if it maps a giant range but then only flushes a small bit of it, we ended up marking the whole thing used
12:04 karolherbst: 849 MHz, glxpsheres 295fps
12:04 imirkin_: heh, not quite 2x
12:04 karolherbst: not the big thing, but still
12:05 karolherbst: glxgears drops by around 8% fps
12:05 karolherbst: maybe the clock is set right all the time or wrong all the time
12:05 karolherbst: but the voltage is raised
12:06 karolherbst: highest voltage doesn*t work though
12:06 karolherbst: so I stick at 906250uv max
12:06 karolherbst: or maybe
12:07 karolherbst: yeah don't know
12:07 imirkin_: that nv_debug should probably print the actual voltage being set rather than the requested one
12:08 karolherbst: with the two highets cstate nothing chnages
12:08 karolherbst: and these will increase voltage to 1250000uv
12:08 karolherbst: maybe I will get them to work
12:19 karolherbst: mhh, there is a second call
12:22 hakzsam_: imirkin_, X has crashed during the piglit run :/
12:22 imirkin_: hakzsam_: doh :(
12:22 imirkin_: did you have -1 --dmesg?
12:23 hakzsam_: yeah
12:23 imirkin_: hrmph
12:23 imirkin_: and -x glx i assume
12:23 imirkin_: well that's all rather unfortunate =/
12:23 hakzsam_: I think it's related to my install because I have no swap on that machine http://hastebin.com/awacasupuv.sm
12:24 imirkin_: oh crap... i usually throw in -x max-texture-size as well
12:24 imirkin_: to avoid issues like that
12:25 hakzsam_: what value do you use for max-texture-size?
12:25 imirkin_: huh? i just don't run it
12:25 imirkin_: -x max-texture-size will tell piglit-run to skip it
12:25 hakzsam_: ah ok
12:25 imirkin_: throw it in with the other -x's
12:26 karolherbst: imirkin_: but again. plain master: 270 fps, my master: 292 fps
12:26 karolherbst: its something
12:26 imirkin_: yea
12:26 imirkin_: cool :)
12:26 karolherbst: but it looks like the difference in voltage though
12:27 karolherbst: not clock
12:27 imirkin_: could be. or could be a difference in generated shader code.
12:27 karolherbst: with glxgears and glxspheres?
12:27 imirkin_: no
12:27 imirkin_: glxgears is diff to compare though
12:27 karolherbst: yeah, but same perf increase
12:27 imirkin_: since the gpu basically does nothing
12:27 karolherbst: a little under 10%
12:27 imirkin_: it's all about xfer speeds
12:28 imirkin_: but for real games... their optimizer is way better
12:28 imirkin_: among other things, we don't schedule instructions
12:28 imirkin_: but also they just optimize the code better
12:28 karolherbst: but look, voltage increases from 793750uv to 906250uv
12:28 karolherbst: this could leade to 8% more performance
12:29 imirkin_: which... you know... makes sense. they've probably put over a man-millenium into their compiler, while nouveau has probably had 1-2 man-years total in the compiler
12:29 imirkin_: if that
12:29 karolherbst: setting 12500000 fails though
12:29 karolherbst: sadly
12:29 imirkin_: well, presumably the voltage has nothing to do with the perf
12:29 imirkin_: it has to do with the cstate you set
12:30 karolherbst: mhh
12:30 imirkin_: which in turn requires some sort of voltage increase
12:30 karolherbst: I think its not the voltage now :/
12:30 karolherbst: allthough
12:30 karolherbst: nvkm_volt_get has the same issue
12:33 karolherbst: nvkm_voltgpio_get returns 0
12:33 hakzsam_: imirkin_, same problem with -x max-texture-size ..
12:33 imirkin_: hrmph
12:34 karolherbst: also nvkm_volt_get returns always 600000 uv :/
12:34 imirkin_: hakzsam_: perhaps we should limit GART to MIN(VRAM * 2, RAM / 4) or something
12:35 hakzsam_: yeah, maybe
12:36 imirkin_: right now it's limited to 1TB and if it overallocates, it tries to swap it out, but then... no swap
12:36 imirkin_: and i think it's not properly accounted in the killing decisions
12:36 imirkin_: or... something
12:37 hakzsam_: well, I'll try with my other machine which has more RAM :)
12:41 imirkin_: preferably more than 1TB ;)
12:41 karolherbst: can somebody explain what this function does? http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nvkm/subdev/volt/gpio.c#L54
12:41 karolherbst: nvkm_voltgpio_set
12:42 karolherbst: "int ret = gpio->set(gpio, 0, tags[i], 0xff, vid & 1);" is never called for me
12:43 imirkin_: like beyond the obvious? vid is a mask, vid_mask is also a mask, and it toggles based on those
12:43 karolherbst: and volt->vid_mask is 0
12:43 karolherbst: yeah ...
12:43 imirkin_: that might be the problem
12:43 karolherbst: I meant more like practically
12:43 hakzsam_: imirkin_, I don't have 1TB ;)
12:43 imirkin_: karolherbst: yeah i kinda figured
12:43 karolherbst: but anyhow
12:43 karolherbst: volt->vid_mask shouldn't be 0
12:43 karolherbst: otherwise it will always fail
12:44 imirkin_: looks like it comes from the vbios somewhere
12:44 karolherbst: how dangerous would it be to remove this check?
12:44 imirkin_: no clue
12:44 imirkin_: it's to program in the VSEL0..7
12:44 imirkin_: some GPUs only have a few of them
12:45 imirkin_: do you have a gpio external entry type 6 or 7?
12:46 karolherbst: I get "VID bit 7 has no GPIO" and "VID bit 3 has no GPIO"
12:46 karolherbst: imirkin_: how do I check?
12:46 imirkin_: run nvbios on your thing
12:46 imirkin_: it should print that sort of thing out
12:46 karolherbst: grep against gpio?
12:47 karolherbst: https://gist.github.com/karolherbst/9e4f5c0ab1caf44700cd
12:47 imirkin_: i'd avoid grepping
12:47 imirkin_: greps leave lots of stuff out
12:47 imirkin_: can you just put the whole thing up?
12:47 karolherbst: yeah
12:48 karolherbst: https://gist.github.com/karolherbst/9e4f5c0ab1caf44700cd
12:51 imirkin_: hm, well your voltage table talks about tags 0x1a and 0x76
12:52 karolherbst: yeah
12:52 imirkin_: which are VSEL3 and VSEL7 respectively
12:52 imirkin_: i dunno if nvbios just prints that though
12:53 karolherbst: it reads the default voltage right though
12:53 karolherbst: at least the kernel module
12:53 imirkin_: ah i see... hm. it prints the mask.
12:53 karolherbst: 600000 is returned by the gpio fuction
12:53 imirkin_: the mask shows that 3 and 7 should be enabled i guess
12:53 karolherbst: okay
12:54 imirkin_: however in both of the cases, id has that bit set to 0
12:54 imirkin_: mask = 0x88
12:54 karolherbst: hardcode for testing?
12:54 imirkin_: so that's what you ought to be seeing
12:55 imirkin_: look at the nvbios.c source for where to read it from based on the header version
12:55 imirkin_: although for versions 0x40 and 0x50 it's a guess
12:55 karolherbst: I have 80, which is something :D
12:56 karolherbst: 50
12:56 imirkin_: right
12:56 imirkin_: so... the thing in nvbios could be wrong
12:56 karolherbst: what is the worst what could happend if I hardcode the mask 0x88 in?
12:56 karolherbst: and try to set the voltage a bit
12:56 imirkin_: hrm
12:56 imirkin_: info->vidmask = nv_ro08(bios, volt + 0x06);
12:56 imirkin_: for 0x50
12:57 imirkin_: which is exactly what nvbios does
12:57 imirkin_: so i dunno why it'd get 0
12:57 karolherbst: path?
12:57 imirkin_: drm/nouveau/nvkm/subdev/bios/volt.c:nvbios_volt_parse
12:57 karolherbst: imirkin_: did you look at nvkm_voltgpio_init?
12:57 karolherbst: there is a "volt->vid_mask &= ~(1 << i);"
12:58 imirkin_: yeah, if it can't find the GPIO
12:58 imirkin_: which makes sense
12:58 imirkin_: can it not find those gpio's?
12:58 karolherbst: 3 and 7
12:58 karolherbst: yeah
12:58 imirkin_: oh lol
12:59 karolherbst: I said so above :p
12:59 imirkin_: yeah, but i wasn't paying attention :p
12:59 karolherbst: :D
12:59 karolherbst: so, any reason why it can't find those?
12:59 imirkin_: they're not in the table ;)
13:00 karolherbst: maybe I forgot some kernel options?
13:00 karolherbst: :D
13:00 imirkin_: checking if you have any of them...
13:00 hakzsam_: patch sent
13:00 hakzsam_: and no crash after ~7000 tests :)
13:00 imirkin_: karolherbst: ok, you have none of them
13:01 imirkin_: i bet it's an external situation
13:01 karolherbst: how can I find out which gpios to use?
13:01 karolherbst: or VID bits in that case
13:02 imirkin_: see "External GPIO Assignment Master Table" in that dcb doc
13:03 karolherbst: oh fun, embedded stuff
13:03 imirkin_: although hm, i think that's the EXTDEV table
13:03 imirkin_: which only lists the INA3221
13:03 imirkin_: which is used for... i forget. fan stuff?
13:03 karolherbst: who knows
13:03 karolherbst: the prop driver can't control the fans though
13:04 karolherbst: I have a MXM card if that makes a big difference
13:04 imirkin_: er no. EXTDEV is the i2c device table entry
13:04 imirkin_: so this is a diff table
13:04 imirkin_: one we don't decide
13:05 imirkin_: one of the "unknown BIT table" ones
13:05 karolherbst: I guess I won't see anythig on the gpu itself? :D
13:06 karolherbst: imirkin_: I used the bios file fetched from PROM now and something changed, but not much: https://gist.github.com/karolherbst/9e4f5c0ab1caf44700cd/revisions
13:06 karolherbst: won't help I guess
13:07 imirkin_: right
13:08 karolherbst: so to sum it all up: the issue is, nouveau can't find the pins to set the voltage
13:09 imirkin_: yes
13:09 imirkin_: karolherbst: can you make your vbios available? i might poke at it
13:09 imirkin_: see if i can find that external gpio table
13:10 karolherbst: whats the best way?
13:10 karolherbst: the PROM one is 1M big
13:10 imirkin_: the vbios.rom from debugfs should be considerably smaller
13:10 karolherbst: yeah 95K
13:10 imirkin_: you can email it to mmio.dumps@gmail.com or put it up on filebin.ca or something
13:12 karolherbst: imirkin_: http://filebin.ca/27jVBXGDUqWC
13:12 hakzsam_: I'm looking at the fbo-stencil issue (will send you explanations about perf counters tomorrow at work ;))
13:12 karolherbst: how likely is it, that other have the same problem of those with the voltage issues?
13:13 imirkin_: extremely
13:13 karolherbst: I see
13:14 karolherbst: btw: does anybody want to test my cstate clocking stuff on boards where changing voltage works?
13:14 imirkin_: what kind of gpu is it again? gk106?
13:14 karolherbst: yeah
13:14 karolherbst: imirkin_: https://gist.github.com/karolherbst/9abd37717e1c08ab699a
13:14 imirkin_: it was mostly for filing purposes ;)
13:15 karolherbst: I see
13:15 karolherbst: allthough do have older gpus have clock ranges inside their pstates?
13:15 karolherbst: would be nice to know if the clocking stuff helps
13:15 imirkin_: i'm sure GK104's had it
13:15 karolherbst: :D
13:16 karolherbst: I see
13:16 karolherbst: I have here another laptop with a 630M
13:16 karolherbst: GF108
13:16 imirkin_: no reclocking on fermi
13:16 karolherbst: I think the GDDR5 version
13:17 karolherbst: k
13:19 imirkin_: ok so looks like it was called the XPIO table in nvbios
13:21 imirkin_: and you don't have any
13:21 karolherbst: mhh
13:21 imirkin_: which means some other mechanism, or it's expected that setting voltage has no effect
13:22 karolherbst: mhh
13:22 imirkin_: mmiotrace would make that apparent
13:22 karolherbst: as I said: coolbits only allow me to set offsets, maybe the card handles all this stuff itself now
13:23 karolherbst: would it be enough to trace the nvidia-settings tool with enable coolbits?
13:23 karolherbst: I could try it out, but the kernel throws some errors
13:23 imirkin_: any trace should have the relevant info
13:24 karolherbst: but wait
13:24 imirkin_: since the first thing the blob does is clock to max speed
13:24 karolherbst: I have a trace from the 343.22 module
13:24 karolherbst: 29M
13:24 imirkin_: that should be fine
13:24 imirkin_: xz -9 it ;)
13:24 imirkin_: should become a lot smaller
13:25 karolherbst: yeah
13:25 karolherbst: without -9: 2.2M
13:27 karolherbst: imirkin_: http://filebin.ca/27jZzOKjpmcL
13:38 karolherbst: y
13:39 imirkin_: i don't see anything obvious futzing with gpio's/etc
13:39 imirkin_: so it might be fine
13:40 karolherbst: which means?
13:41 imirkin_: no voltage changes
13:41 imirkin_: dunno :)
13:41 karolherbst: mhh
13:41 karolherbst: wouldn't make sense I think
13:43 karolherbst: in the overclocking thread there is some talk about increasing voltage
13:44 karolherbst: ahh it seems like the tdp is locked somehow
14:00 karolherbst: imirkin_: so nothing can be done or what does it mean now?
14:01 imirkin_: dunno sorry
14:03 karolherbst: mhh, :/
14:03 karolherbst: at least I got like 8% fps more
14:03 karolherbst: I will try if I also get them in talos
14:08 karolherbst: mhh
14:08 karolherbst: from the scene I tested: 6.2 fps to 7.5 fps
14:09 imirkin_: 20%... better i guess
14:09 karolherbst: 16.5 to 18 fps with low settings
14:09 imirkin_: still shy of the 2x
14:10 karolherbst: yeah
14:10 karolherbst: I think its because the voltage isn't set then :/
14:10 karolherbst: maybe something else has to be done
14:13 karolherbst: imirkin_: what about https://github.com/karolherbst/nouveau/commit/a41f62639b14bab1f306241445398f525f8e47b7 ? might this help me with 0f?
14:13 karolherbst: or is it for newer gpus?
14:14 imirkin_: older, actually
14:14 imirkin_: GT215
14:14 imirkin_: tesla
14:14 karolherbst: I see
14:14 imirkin_: marketing name GT 240
14:15 imirkin_: i have one plugged in, might try to make it work ;)
14:15 imirkin_: but i'm still a long ways
14:18 pmoreau: imirkin_: Yeah… Samuel linked it to me
14:19 pmoreau: Anyway, I won't be working on it while I am in Japan, so it will wait until the end of July.
14:33 karolherbst: imirkin_: how fast should the gpu hang with 0f pstate?
14:33 karolherbst: or after which time its safe to assume it works?
14:34 imirkin_: karolherbst: dunno... normally fast, but normally the display is being driven off vram
14:35 karolherbst: mhh
14:35 karolherbst: it worked for about 20 seconds in talos until I switched pstates
14:35 karolherbst: I think low cstate + 0f pstate hangs immediatly
14:35 karolherbst: but high cstate does't
14:35 karolherbst: I got like 8.5 fps with high settings in talos
14:36 karolherbst: directly oafter a new 0f > pstate it hanged, because the cstate is reseted to lowest, maybe?
14:37 karolherbst: will let the game run in background a bit
14:38 karolherbst: okay, hangs nethertheless
14:46 karolherbst: imirkin_: do you know who might more about the voltage issue?
14:46 imirkin_: as with all things, skeggsb.
14:47 karolherbst: k, thanks
14:49 imirkin_: and maybe RSpliet actually, although he's mostly stuck to tesla's so far.
14:49 imirkin_: and perhaps even mupuf?
14:49 karolherbst: RSpliet tried to help me with something else yesterday
14:49 karolherbst: the cstate clokcing stuff a bit
14:50 imirkin_: karolherbst: btw, i'd be very much in favor of a patch which made it default to the highest cstate when switching pstates rather than lowest
14:50 karolherbst: mhhh
14:50 karolherbst: difficult currently
14:51 karolherbst: imirkin_: is this patch okay as it is? https://github.com/karolherbst/nouveau/commit/f8e698632cb2bf0696a8f5015bcaeaa63844471d
14:52 karolherbst: this adds the ability to select a cstate at all
14:52 karolherbst: so its quite important to have this first :D
14:52 imirkin_: fine by me
14:53 karolherbst: then this line has to be changed: https://github.com/karolherbst/nouveau/blob/f8e698632cb2bf0696a8f5015bcaeaa63844471d/drm/nouveau/nvkm/subdev/clk/base.c#L200
14:53 imirkin_: i think the usual patch prefix is somethign like "volt: " though
14:53 karolherbst: maybe except 0 just -1 and it will work?
14:53 imirkin_: and then when ben imports it into the linux tree, he'll prefix that with drm/nouveau too
14:53 imirkin_: right, but the nvkm_pstate should probably just have a default cstate
14:53 imirkin_: i dunno. maybe not.
14:54 karolherbst: the thing is, in the future it should be done automagically
14:54 karolherbst: depending on load
14:54 imirkin_: yes, well, we can worry about that future later.
14:54 karolherbst: so these bits will be gone in the future anyway
14:54 karolherbst: if -1 works, I think its okay
14:54 imirkin_: https://www.youtube.com/watch?v=jQvvmT3ab80
14:57 karolherbst: funny thig is, the last entry is 0 :/
14:57 karolherbst: this is kind of annoying
14:58 imirkin_: erm... that one should probably get skipped
14:58 karolherbst: the first one is 0, too
15:07 karolherbst: imirkin_: https://github.com/karolherbst/nouveau/commit/dc54209a916cda1039dfda889499dd2499d1ed80
15:07 imirkin_: so i was just looking over this
15:08 imirkin_: i think there are some things missing
15:08 imirkin_: 8: freq 993 MHz unkn[0] 0 unkn[1] 1 voltage 19
15:08 imirkin_: which corresponds to
15:08 imirkin_: -- ID = 19, link: 32, voltage_min = 800000, voltage_max = 856250 [µV] --
15:08 imirkin_: 0x89ae: 00 32 00 35 0c 00 ba 10 0d 00 a6 9e 96 00 2b 00 00 00 2d e6 ff ff 00 00 00 00 00 00 00 00 00 00 00 00
15:08 imirkin_: so that's how you know what voltage to set it to
15:09 karolherbst: but I don't have 993MHz
15:10 karolherbst: ahh devided by 2
15:10 karolherbst: "cstate: {index: 9, gpc: 993000, mem: 810000, voltage: 19}"
15:10 imirkin_: i randomly picked a low one
15:10 karolherbst: "[28907.875995] nouveau W[ CLK][0000:01:00.0] set gpu to cstate: {gpc: 1020000, mem: 810000, voltage: 20}"
15:10 karolherbst: "[28907.876071] nouveau D[ VOLT][0000:01:00.0] set 800000uv: 0 vid: 19 new value: 600000"
15:10 imirkin_: i think it's better to identify cstates by id
15:10 karolherbst: yeah
15:10 karolherbst: maybe I will add this
15:10 imirkin_: than by index
15:11 karolherbst: the right volt is selected already
15:11 karolherbst: 37 should be 1250...0uv
15:11 karolherbst: and voltage 47
15:12 imirkin_: -- ID = 47, link: 34, voltage_min = 900000, voltage_max = 1037500 [µV] --
15:12 karolherbst: mhhh
15:12 imirkin_: -- ID = 37, link: 35, voltage_min = 825000, voltage_max = 950000 [µV] --
15:12 karolherbst: wiat, it was the 0 issue
15:12 imirkin_: (just getting this from your vbios)
15:12 imirkin_: sure, but let's forget about that for asec
15:13 karolherbst: its 906250uv now anyway
15:13 karolherbst: k
15:13 imirkin_: right, so then there's never any reason to switch
15:13 imirkin_: at least for voltage id 30+
15:14 karolherbst: which means?
15:14 mupuf: imirkin_: voltage, on fermi?
15:14 mupuf: mlankhorst had patches for that
15:14 mupuf: our implementation was wrong
15:14 imirkin_: mupuf: kepler
15:14 mupuf: well, we do not parse the table properly
15:14 imirkin_: that's generally a true statement :p
15:14 karolherbst: table seems to be right here
15:14 karolherbst: or "kind of right"
15:15 imirkin_: or "not entirely wrong" :)
15:15 mupuf: karolherbst: how do you check that?
15:15 karolherbst: stuff I wrote
15:15 karolherbst: these are the cstates I get: https://gist.github.com/karolherbst/c731b244707aaea45086
15:15 mupuf: try setting the voltage to max and see if it works better
15:15 imirkin_: mupuf: he doesn't have any VSEL gpio's
15:15 karolherbst: :)
15:15 imirkin_: so it's msotly academic
15:15 mupuf: what?
15:15 karolherbst: right
15:15 karolherbst: I can*t set the voltage
15:15 karolherbst: setting cstates works though
15:16 karolherbst: and give me like 10% more performance
15:16 imirkin_: mupuf: https://gist.githubusercontent.com/karolherbst/9e4f5c0ab1caf44700cd/raw/bbb4dcea7307df6b9e2a9b558656b3ca5356a5d8/gistfile1.txt
15:16 mupuf: only 10?
15:16 imirkin_: yeah, i suspect there's something funky going on
15:16 imirkin_: past experience suggests a 2x+ improvement between 07 and 0a pstates
15:17 mupuf: well, going from 405MHz to 2GHz should provide more than 2x+ improve,ent
15:17 imirkin_: karolherbst: http://www.phoronix.com/scan.php?page=article&item=linux316_nouveau_clocks&num=3
15:18 imirkin_: for the gddr5 boards it almsot exclusively was 2x perf improvement
15:21 karolherbst: mupuf: voltage stays at 0.6V or something
15:21 karolherbst: I can't change the voltage
15:21 mupuf: right! factor of 4 between the stock and max
15:21 karolherbst: so it basically runs at 862MHz core with 0.6V
15:21 mupuf: 0.6 is ridiculously low
15:21 karolherbst: 770M
15:21 karolherbst: mobile chip
15:22 karolherbst: lowest clock is 135MHz
15:22 karolherbst: allthough nouveau can't find it
15:22 karolherbst: and sticks to 405MHz
15:22 mupuf: Kepler? which chipset?
15:22 karolherbst: GK106
15:22 karolherbst: https://gist.github.com/karolherbst/9abd37717e1c08ab699a
15:28 karolherbst: mupuf: there are my patches: https://github.com/karolherbst/nouveau/commits/master_karol
15:28 karolherbst: https://github.com/karolherbst/nouveau/commit/9526609ca057fd0bb3cc29585ee42a4f1f26f2a1 is for manually setting cstates
15:30 mupuf: hmm
15:33 mupuf: .6V is really low though
15:33 mupuf: that;s the lowest voltage for my nve6
15:33 mupuf: GK106*
15:36 karolherbst: mupuf: the thing is, all pstates have the min freq of 405MHz
15:36 karolherbst: so setting a pstate only increases memory clock for me with stock nouveau
15:37 mupuf: well, the memory will never work at this voltage, so there must be a second level
15:37 mupuf: but you are right, 810MHz may be low-enough
15:37 karolherbst: mupuf: that's my pstate file: https://gist.github.com/karolherbst/cde54795daa6194ad387
15:38 mupuf: and the process is different too between mobile and not desktop gpus
15:38 karolherbst: and these are the cstates for 0a: https://gist.github.com/karolherbst/c731b244707aaea45086
15:38 karolherbst: and the stock nouveau driver only selected the lowest one
15:38 mupuf: GPIO 10: line 10 tag 0x2e [MEM_VREF] OUT NEG DEF 1 gpio: normal
15:39 imirkin_: right, for memory
15:39 imirkin_: but not the engine stuff
15:39 imirkin_: i.e. VID0..7
15:39 karolherbst: clocking memory through pstates gives me already 10% more perf with same core clock
15:39 imirkin_: or VSEL as they're called in the dcb docs
15:39 karolherbst: I don't know if one can expect more
15:40 mupuf: imirkin_: yes, I wonder what those GPIO tags are
15:40 imirkin_: i looked all of them up, nothing related
15:40 mupuf: ok
15:40 mupuf: would be nice to add them at some point
15:40 imirkin_: yes...
15:40 karolherbst: mhh
15:41 karolherbst: I think there have to be at least two
15:41 karolherbst: 1. for cpu offset
15:41 karolherbst: 2. for memory offset
15:41 karolherbst: clock
15:41 mupuf: anyway, +10% perf improvement, that means you are heavily core-limited
15:41 karolherbst: yeah
15:41 karolherbst: talos 7.5 fps at gpu high settings
15:41 mupuf: looking forward to using the perf counters to have a look at that more easily!
15:41 imirkin_: can you try something lighter than talos?
15:41 imirkin_: like portal or tf2 or something else dumb?
15:41 karolherbst: antichamber runs smoothly
15:41 karolherbst: pretty good actually
15:42 karolherbst: imirkin_: with fps counter an play with pstates/cstates?
15:42 imirkin_: yea
15:42 imirkin_: and turn things way up to slow them down :)
15:42 imirkin_: so that you see more difference
15:42 imirkin_: hehe
15:42 karolherbst: how do I enable fps counters in portal 2 or portal
15:42 imirkin_: mmm... dunno
15:43 imirkin_: cl_showfps 1
15:43 imirkin_: in the console
15:43 karolherbst: -fps
15:43 karolherbst: maybe
15:43 karolherbst: :D
15:44 karolherbst: mupuf: also I use dri3 with nouveau
15:44 karolherbst: strange tearing issues I got there
15:44 mupuf: hmm, that is unrelated
15:44 karolherbst: I know
15:45 karolherbst: I am stupid
15:45 karolherbst: GALLIUM_HUD for fps
15:45 karolherbst: good idea?
15:47 hakzsam_: yeah, works fine
15:47 hakzsam_: use GALLIUM_HUD_PERIOD=0 to refresh at each frame
15:49 karolherbst: for some reasons portal 2 won't load nouveau
15:51 karolherbst: antichamber
15:51 karolherbst: 07: 16 fps
15:54 karolherbst: 0a: 32 fps with stock nouveau
15:55 karolherbst: 0a: 35 fps with patched nouveau
15:55 karolherbst: which means highest cstate
15:55 karolherbst: these +3 fps are stable enough to be noticable
15:56 imirkin_: ok, so i think something dumb's going on in talos
15:56 karolherbst: I don't think antichamber is gpu core limited actually
15:56 karolherbst: I will try out 0f :D
15:57 karolherbst: 60 fps :)
15:57 imirkin_: hah
15:57 karolherbst: in 0f
15:57 imirkin_: with super-tearing?
15:57 karolherbst: nope
15:57 karolherbst: othing
15:57 karolherbst: seems fine
15:57 imirkin_: nice
15:57 karolherbst: I do't know tearing on my setup
15:57 karolherbst: full scene repaints in kwi
15:58 imirkin_: yeah, but you had that funny tearing with nouveau right
15:58 imirkin_: of course the fun question is how fast does it go on the built-in intel chip
15:58 karolherbst: you won't see such in antichamber
15:59 karolherbst: very unlikely
15:59 karolherbst: do you know it?
15:59 imirkin_: no
15:59 karolherbst: http://vignette2.wikia.nocookie.net/antichamber/images/4/4a/Stuck_In_A_Rut_-_start.jpg/revision/latest?cb=20131201063258
15:59 karolherbst: it looks like that
15:59 karolherbst: sometimes with colors
15:59 karolherbst: http://vignette1.wikia.nocookie.net/antichamber/images/b/bb/Green_gun_stand.png/revision/latest?cb=20130217070822
16:00 karolherbst: but yeah I could try to see these tearings
16:00 karolherbst: but with higher fps they are gone pretty fast
16:00 karolherbst: because they only laste on frame
16:00 karolherbst: and are gone for maybe some seconds
16:00 karolherbst: so antichamber is memory limited I guess
16:00 imirkin_: seems like that sort of rendering should be pretty fast on intel too...
16:00 karolherbst: actually portal 2 is pretty fast on my intel too
16:01 karolherbst: but I think I need something more gpu challanging than that
16:01 karolherbst: borderlands :)
16:04 karolherbst: 11/18/22 fps
16:05 imirkin_: and intel?
16:05 karolherbst: nouveau
16:05 karolherbst: borderlands 2 actually
16:05 karolherbst: ahh intel
16:05 karolherbst: will try it after pre-sequel
16:06 karolherbst: but should be worse
16:06 imirkin_: is that like two days before the day after tomorrow?
16:06 karolherbst: its like the prequel to the sequel
16:06 imirkin_: aka the original?
16:06 karolherbst: no borderlands 2 is the sequel to boderlands
16:06 karolherbst: and the pre-sequel is between
16:07 imirkin_: heh
16:07 karolherbst: but released after ;)
16:07 karolherbst: 2
16:07 karolherbst: its the newest version
16:07 imirkin_: so 1.5 basically
16:07 karolherbst: yeah, but also like 3
16:07 karolherbst: good linux port though
16:08 karolherbst: woho
16:08 karolherbst: rendering issues
16:08 karolherbst: its looks like old frames are displayed again
16:09 karolherbst: mhh weird
16:09 karolherbst: 12/19/25 fps
16:10 karolherbst: pstate 07 / pstate 0a, cstate 0/pstate0a cstate 35
16:10 karolherbst: biggest cstate increase
16:10 imirkin_: depends a lot on what these things are doing
16:10 imirkin_: and how nouveau is driving it
16:11 imirkin_: i bet calim did a bunch of tuning on this stuff back in the day
16:11 karolherbst: testing intel
16:11 imirkin_: but i've done nothing with trying to optimize performance
16:11 imirkin_: just trying to get the damn thing to work is hard enough. heh
16:11 karolherbst: wow
16:11 karolherbst: intel has same performance basically
16:12 imirkin_: ;)
16:12 karolherbst: maybe I am crazy and try 0f again
16:12 imirkin_: as the highest of those numbers?
16:12 karolherbst: no
16:12 karolherbst: highest ist 0a with highest cstate
16:12 imirkin_: and intel is same as...
16:13 karolherbst: don't know, don't have gallium fps counter
16:13 imirkin_: you said "same performance"
16:13 karolherbst: yeah
16:13 imirkin_: i assume it was same as something
16:13 karolherbst: I mean you can see it
16:13 karolherbst: it looked as fast as
16:13 imirkin_: why not enable the in-game one? valve games have the cl_showfps thing
16:13 imirkin_: as fast as nouveau on which setting?
16:14 karolherbst: the fastest
16:14 imirkin_: k :) that's what i was trying to establish
16:14 imirkin_: there's a INTEL_SHOW_FPS iirc
16:14 imirkin_: LIBGL_SHOW_FPS=1
16:14 imirkin_: i was close
16:15 mupuf: numbers seem good
16:15 mupuf: 16 -> 60fps, that shows that this app was entirely memory-limited
16:16 imirkin_: guess 0f didn't pan out? :)
16:17 karolherbst: nope
16:17 karolherbst: sometimes it just messes up my entire system
16:18 karolherbst: so basically cstates can give a furthor speed bump :)
16:19 imirkin_: good to know :)
16:19 karolherbst: 10% across the board I would say
16:19 imirkin_: btw you can use LIBGL_SHOW_FPS=1 for intel
16:19 karolherbst: but thats only because voltage doesn't work here
16:19 karolherbst: k
16:19 imirkin_: prints to stderr
16:20 karolherbst: ...
16:20 imirkin_: [the fps]
16:20 karolherbst: yeah
16:20 karolherbst: this helps a lot with steam :D
16:23 karolherbst: starting from cli
16:24 karolherbst: yeah intel is somewhere between 16 and 22
16:24 karolherbst: borderlands pre-sequel
16:24 imirkin_: what about that memory-bound one?
16:25 imirkin_: intel tends to do quite poorly on memory-bound things, since it only has DDR3
16:29 karolherbst: I don't think thats a problem
16:29 karolherbst: but yeah
16:29 karolherbst: only 24 fps
16:30 karolherbst: nouveau had 30 on 0a
16:30 karolherbst: but 60 on 0f, which would totally make sense
16:31 karolherbst: will try talos again
16:33 karolherbst: of lowest gpu setting I have 60 fps wiht 07 by the way
16:33 karolherbst: sometimes only 40
16:34 karolherbst: gpu lowest, memory: ultra testing
16:34 karolherbst: mhh
16:35 karolherbst: 15/16.5/18.5
16:35 karolherbst: with gpu low
16:37 karolherbst: 5.2/6.6/8 on gpu ultra
16:39 karolherbst: so anymore testing or is it enough?
16:39 karolherbst: :D
16:42 imirkin_: haha
16:42 imirkin_: you can test as much or as little as you like
16:45 karolherbst: talos is buggy
16:46 karolherbst: really
16:46 imirkin_: yeah, there's a bug about that
16:46 karolherbst: if you set gpu to something other than lowest you get a big performance hit
16:47 karolherbst: but if you select lowest and customized the hell out of it
16:47 karolherbst: no problem
16:47 karolherbst: full hd, 2xmsaa
16:47 karolherbst: shadows
16:47 karolherbst: anything
16:47 karolherbst: still at 30 fps
16:47 imirkin_: heh
16:47 karolherbst: shadows ultra, no big deal
16:48 imirkin_: does it actually flip that on though
16:48 karolherbst: okay, SSAA is a big deal
16:49 karolherbst: ahhh
16:49 karolherbst: dynamic light is the culprit
16:49 karolherbst: if you enable "no dynamic light" you get insane performance
16:50 imirkin_: i wonder what they do
16:50 imirkin_: for all the 3d driver stuff i've done, i still have no clue how you use OpenGL to do anything useful :)
16:50 karolherbst: ultra + no dynamic light now
16:50 karolherbst: 12 fps
16:52 karolherbst: also the green walls are gone
16:53 karolherbst: so dynamic light is doing something bad
16:54 imirkin_: and slow :)
16:55 karolherbst: 16/20/24 fps
16:55 karolherbst: medium + no dynamic light
16:55 karolherbst: yeah
16:55 karolherbst: okay so talos doesn't behave much differetly than the others
16:56 karolherbst: only dynamic lights are doing something crazy
16:56 karolherbst: maybe some cpu crazy stuff inside mesa?
16:56 karolherbst: would explain the framerates
16:57 imirkin_: probably does something dumb that causes nouveau to wait for bufs to become available
16:57 karolherbst: strange is, that the green walls are also gone
16:57 karolherbst: so its related somehow
16:58 imirkin_: not necessarily
16:58 imirkin_: bbl
16:58 karolherbst: wow
16:58 karolherbst: gome freeze with 0a
16:58 karolherbst: *game
16:59 karolherbst: benh: hi, do you have some time to look over some patches? regarding pstate/cstate stuff?
17:00 benh: me ?
17:00 karolherbst: no?
17:00 karolherbst: are you the wrong ben?
17:01 benh: which ben are you after ? :-)
17:01 karolherbst: the responsible one :p
17:02 karolherbst: imirkin said I should check with ben before doing a bunch of work
17:04 karolherbst: benh: did you wrote the c800 patch hack?
17:04 karolherbst: ahh no
17:04 benh: doens't ring a bell/
17:04 karolherbst: nah, now I get it
17:04 karolherbst: wrong ben indeed
17:04 karolherbst: skeggsb is the right one
17:04 karolherbst: silly me
17:05 karolherbst: I am new here, so I have to learn
17:17 imirkin: karolherbst: so close ;)
17:18 karolherbst: :(
17:19 karolherbst: mhh these clocking stuff is still annoying :(
17:19 imirkin: benh is the ppc maintainer, and occasionally tries to get nouveau to work on macs
17:19 karolherbst: ahhh
17:19 karolherbst: I have a mac too somewhere somehow
17:19 imirkin: ppc macs, obviously :)
17:19 imirkin: but i guess his attention is mostly shifted towards POWER8 and whatnot nowadays
17:20 karolherbst: right
17:20 karolherbst: its an intel one anyway
17:20 karolherbst: but I had PPC once
17:20 imirkin: but no m68k one?
17:20 karolherbst: no
17:20 karolherbst: I am too young for that
17:21 imirkin: but old enough to know what an m68k is
17:21 karolherbst: yeah well
17:21 karolherbst: older than G3 I guess
17:21 imirkin: (and if you tell me it's the chip that powers the TI-89, then... i'll revise that comment)
17:22 karolherbst: really don't know
17:22 imirkin: m68k macs were the LC series... and the apple 2's as well i think
17:22 karolherbst: allthough my first computer was an atari 1040 ST
17:23 karolherbst: but then I was really young and I got it from my dad
17:24 imirkin: ooh, and nextstations were also m68k
17:24 karolherbst: yeah
17:24 karolherbst: I think everything before G3 is m68k
17:25 imirkin: mmmmmaybe
17:25 imirkin: i feel like there was something stupid before the G3 and after the LC series
17:26 imirkin: ah no, looks like you're right. G3.
17:26 karolherbst: but before were already some powerpc cpus
17:27 karolherbst: yeah
17:27 karolherbst: a lot
17:27 karolherbst: https://en.wikipedia.org/wiki/List_of_Macintosh_models_grouped_by_CPU_type :)
17:27 imirkin: of course
17:29 karolherbst: anyway
17:29 karolherbst: I found https://wiki.freedesktop.org/nouveau/PowerManagement/
17:29 karolherbst: and "voltage adjusting" is marked as "internal only"
17:29 imirkin: by now you know substantially more than what is written there.
17:29 karolherbst: :D
17:30 imirkin: at least as pertains to kepler
17:30 karolherbst: engine reclocking, memory reclocking: done :p
17:31 karolherbst: though there is still this one issue :(
17:31 karolherbst: the thing is I can't trust nouveau printin the right voltage, if there is no pin to read it from
17:32 imirkin: well, check where it reads the voltage from
17:37 karolherbst: nvkm_voltgpio_get returns 0
17:37 karolherbst: and the value comes from the tables
17:38 karolherbst: yeah
17:38 karolherbst: vid == 0
17:38 karolherbst: which is true for the first one
17:38 karolherbst: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nvkm/subdev/volt/base.c#L30
17:38 karolherbst: int ret = volt->vid_get(volt) always 0
17:45 karolherbst: imirkin: can anythig gpio related in the kernel help?
17:48 karolherbst: imirkin: do you know anybody with a testing setup with kepler gpus?
17:48 karolherbst: would like to test the cstate stuff there, too
17:48 karolherbst: maybe it helps other cards as well
17:48 imirkin: mupuf has a box
17:49 karolherbst: but it should work for any nouveau gpu with multiple C-states for p-states
22:28 mlankhorst: mupuf: those patches got rejected though
22:35 boxfire: skeggsb: just checking in, did you see the bug report for the TMDS greater than 165 MHz?
22:35 boxfire: there is an error in the dmesg output from the card after trying to change the mode
23:26 karolherbst: skeggsb: hi, maybe you can help me with a problem I have: since your "c800" hack, my gtx 770m card works with nouveau. One problem though: plain pstates only increase performance by 10-20% across the board (antichamber 100%, but 0f even increased by 400%, which indicates heavily memory bottleneck in that game). Then I noticed, that the gpu core frequencies stays the same in all pstates (405MHz), so I wrote support for setting cstates, to a value from
23:26 karolherbst: the cstates table. Now I can set the frequency to 862MHz, but performance only increases by further 10% "only"
23:27 karolherbst: then imirkin and I found out, that I can't set or read the voltage of my card
23:27 karolherbst: and the lowest possible value is 0.6V, so this might be the problem
23:29 karolherbst: on the side note: the cstate patches should work for every card with many cstates in one or more pstates, so it may increases performance even for cards, where a higher pstate already increases performance