06:22karolherbst: mupuf: okay, it seems like the FSRM sets either a divider of 2 or a divider of e depending on the temperature with the blob
06:23karolherbst: https://gist.github.com/karolherbst/1854da8068b510d4cc14#file-gistfile1-txt-L17-L21 this is the behaviour with the blob on my gpu: https://gist.github.com/karolherbst/1854da8068b510d4cc14#file-gistfile1-txt-L17-L21
06:23karolherbst: I don't know if these thresholds really mean the thing I think they mean, but maybe the do
06:23mupuf: did you read the doc in rnndb?
06:24mupuf: looks like you are doing REing right now :o
06:24karolherbst: well I just ramped up the temp step by step and checked how that behaves, because I didn't find any reason why I didn't get the divider below 8
06:27karolherbst: mupuf: what does it mean when only the low value is set of the windows but not the high?
06:28karolherbst: ohh most likley that the window never ends
06:29mupuf: no, the FSRM does not care about the window
06:29karolherbst: ohh okay
09:30sobukus: Any hints about a PCI Quadro NVS 280 with two monitors in addition to one connected to a PCIe Radeon being awfully slow and CPU-hogging in simple scrolling in graphical applications?
09:31sobukus: I run a Zaphod setup, offloading with xrandr providers is not workable (even with an older PCI radeon card sharing the driver with the primary one).
09:33sobukus:just provoked another Xorg crash by trying Option NoAccel, when trying to rotate with xrandr
09:42karolherbst: sobukus: why do you use zaphod?
09:42karolherbst: usually xrandr offloading should work provided that everything is setup the right way
09:42sobukus: karolherbst: Because anything else didn't work at all and I didn't mind having separate screens.
09:43sobukus: karolherbst: I have the suspicion that the old PCI cards I'm trying to use just aren't tested anymore.
09:43sobukus: Is offloading really supposed to be a stable feature?
09:44sobukus: I have a Radeon 7500, too, which works better than the Quadro in Zaphod, but has corruption issues unless I disable EXAPixmap.
09:46karolherbst: sobukus: well reverse prime is more of a hack with dRI2
09:47karolherbst: sobukus: it could be that some driver isn't loaded properly or something, without the xlogs or dmesg there will be only guessing here
09:50sobukus: karolherbst: Thing is that I had a working config with a mobo with radeon on-chip and both the PCI Quadro and later a PCIe Quadro … after replacing the mainboard because of hardware failure, the setup with PCIe Radeon HD5450 and the PCI Quadro worked, but slowly.
09:52sobukus: karolherbst: I just tried reverse prime again (if that's the correct term): Provider 0 is radeon, Provider 1 is nouveau; xrandr --setprovideroutputsource 1 0; xrandr --output DVI-I-2 --auto --left-of VGA-0 <--- screens turn black, but still active with a corrupted cursor
09:52sobukus: nouveau: kernel rejected pushbuf: Invalid argument
09:52sobukus: And several of those in terminal
09:54karolherbst: okay, that may be a nouveau issue then
09:55karolherbst: what kernel are you running?
09:55karolherbst: mupuf: okay, I figured it out now
09:55karolherbst: PTHERM.I2C_SLAVE.THRESHOLD_6 indeed triggers a "first" divider on the fsrm
09:55karolherbst: in the range of 1-8
09:55karolherbst: and PTHERM.I2C_SLAVE.THRESHOLD_2 triggers a second stage
09:55karolherbst: and then you get divs between 9 and f
09:56karolherbst: mupuf: so we could just use both and configure them the first one to do only a 2 clock divide and teh second one f
09:57sobukus: karolherbst: http://dpaste.com/34GYQWQ Xorg.log
09:57sobukus: karolherbst: It's vanilla 3.14.51.
09:57karolherbst: 3.14 is a bit old though
09:57sobukus: It's the stable one;-)
09:57karolherbst: yeah well
09:57karolherbst: nouveau doesn't backport
09:58karolherbst: so you are better of with the newest kernel with nouveau
09:58sobukus: Fair enough, I might have to try that for those modern features … hence the attempt to get away with Zaphod.
09:58karolherbst: mhh right
09:59karolherbst: sobukus: did you follow this? http://nouveau.freedesktop.org/wiki/Optimus/
09:59karolherbst: "Using outputs on discrete GPU"
10:00karolherbst: you could also try to reverse the offloading scenario though
10:00karolherbst: use radeon as the main thing
10:00karolherbst: and offload the nouveau display on top of the radeon one
10:00karolherbst: ohh that's what you did, well then try radeon on nouveau :D
10:00sobukus: Eh? I imagined I already tried to render stuff on radeon and output on nouveau.
10:01karolherbst: but first you should try out a newer kernel
10:01karolherbst: there might be important fixes
10:01sobukus: I actually also can booth with two Quadro NVS (PCIe and PCI) and try to offload them to each other;-)
10:01sobukus: I see that for this graphics stuff, the 3.14 kernel seems ancient.
10:01karolherbst: PCI might be a little slow though for offloading :/
10:02sobukus: Yes. Another reason why I would be happy for Zaphod to still work.
10:02sobukus: I cannot use two PCIe cards as I only have PCIe x1 slots free.
10:02karolherbst: are they x1 only or x1+?
10:03karolherbst: the NVS280 doesn't seem to draw that much power, so a plain x1 slot should be enough
10:03sobukus: Well, they are mechanical x1 slots, so without a saw I don't see the option of plugging in the second PCIe x16 video card
10:04karolherbst: ohh okay, so they are closed :/
10:04karolherbst: some slots have an openning on one side
10:04sobukus: The NVS280 is PCI, I got a NVS290 with PCIe
10:04karolherbst: ohh oka
10:05sobukus: I wonder if offloading can possibly work through PCI with it's 133 MB/s (or 266, dunno if it's 66 MHz).
10:05sobukus: It's two 1024x768 displays.
10:05sobukus: could reduce it to one.
10:05karolherbst: 64bit and 66MHz has 533 MB/s
10:06karolherbst: but yeah maybe you only got 133MB/s
10:06karolherbst: pcie v1 x1 has already 250MB/s
10:07karolherbst: sobukus: mhhh I will put it that way: on my laptop here, increaseing the pcie bus from 2.5GT/s to 8.0GT/s increases fps in games by around 10% in general and this is with width x16
10:07karolherbst: and I offload it on my intel card
10:07karolherbst: so PCI might be really just too slow
10:08sobukus: Well, XGA with 24 bit pixels and 60 Hz is 135 MB/s net data rate.
10:09karolherbst: yeah but you also have to copy that to the pcie card and wait until the copy is finished and stuff
10:09sobukus: I also got a PCIe x1 Matrox G550 card, but that's no fun under linux anyway.
10:10karolherbst: well you could try out the newest kernel and then play around a bit with the cards wich combination works best or something
10:10sobukus: So … can I expect fixes for Zaphod mode with upgrades or is nobody using that anyway?
10:12MichaelLong: I'm still using it.
10:12MichaelLong: I thought I'm the only one left.
10:13sobukus: I now wonder: Should I try the very latest stable kernel (4.3.2) or is longterm 4.1.14 more appropriate?
10:13MichaelLong: ahrg 4.3.2 is out?
10:13sobukus: Hm, so that's a no for this one, then?
10:14MichaelLong: you're right, I right now just upgrading to 4.3.1
10:14MichaelLong: sobukus, no
10:28Dezponia: Would anyone here be interested in having some info from a GTX TITAN Black? (GK110B) I'm trying one out right now on Arch GNU/Linux with nouveau and having some crashes if I use opengl (stock Arch packages, no fancy things built from git or such)
10:31sobukus: karolherbst: This is getting weird. Suddenly the NVS280 doesn't find the connected monitors anymore. I wonder if it picked this moment to seize up.
10:35Tom^: Dezponia: mesa version and kernel version?
10:37Dezponia: Tom^: mesa 11.0.7, linux 4.2.5 and nouveau 1.0.12
10:38Tom^: both mesa and the kernel has some kepler fixes above that
10:39Tom^: so fetch 4.3 and mesa-git :p
10:40Dezponia: Tom^: Yeah I figured as much :) I'll seee if I can run some tests on git but otherwise I'm just happy to know they'll reach me eventually. In unrelated news would you know if I could take a graphics bios from say... the GIGABYTE GTX TITAN Black GigaHertz Edition and flash it onto my regular GIGABYTE GTX TIAN Black since they're the same reference board in every way except for clocks :P
10:41Tom^: *shrug* ive got no clue about such things.
10:41Dezponia: Oh well, I guess it'll have to be fast enough. A new one of those cards costs like 1888$ USD so unless they show up on Ebay I'll stick to this one with the stock clocks :P
10:43Tom^: overpriced crap tho, the 780ti costs like half of it and runs almost the same
10:45Dezponia: Tom^: Sure, but I'm building the best, most powerful freedom respecting system I can for the fun of it (and to bunker up in case no future, better freedom respecting gear comes available :P). Think of it as "what would you build if money was not a problem" sort of thing
10:46Dezponia: And as far as I'm aware at any rate the GTX TITAN Black is the most powerful graphics card that from any vendor that can run without blobs in the kernel, right?
10:55Tom^: Dezponia: http://www.bit-tech.net/hardware/graphics/2014/02/26/nvidia-geforce-gtx-titan-black-review/6 its like a 0.5% gain for double the money. :p
10:55Tom^: Dezponia: but yes
10:56Dezponia: Tom^: Well yeah, but as I said I'm not too concerened about it :) You're talking to someone who already has a titan black and is concidering buying another one just because its 13% higher clocked out of the box :P
10:56mlankhor1t: its for the double float multiply performance.. whch only affects gpgpu
10:57Dezponia: That is also true, it has some extra features which may or may not be useful someday :P
10:57Dezponia: Besides last time I checked no one around here had a GTX TITAN Black so if anyone is interested I'll certainly help test stuff on it. Should be similar to the 780ti but cant hurt :)
11:11karolherbst: Dezponia: vbios pls :p
11:11karolherbst: and dmesg
11:12karolherbst: Dezponia: well you can modify the vbios from the gpu yourself and reflash it
11:12karolherbst: I wouldn't use a vbios from another card ever, because some bits might be different
11:12karolherbst: and then you run into issues you don't notice first, but only when its too late :p
11:13karolherbst: sobukus: no idea
11:14karolherbst: mupuf: are these thresholds in some way "configured" or are they statically linked with the consumer?
11:14Dezponia: karolherbst: I will admit to not knowing how to pull a vbios from the card but if there is a guide or you're willing to help me I'll gladly provide it :)
11:15karolherbst: Dezponia: there are two "good" ways: nvagetbios (from envytools) or /sys/kernel/debug/dri/0/vbios (when nouveau is loaded)
11:15karolherbst: Dezponia: ohh you mean you get only crashes with opengl?
11:16karolherbst: Dezponia: glxinfo output then
11:16karolherbst: imirkin: are GK110B handled in some wierd way in mesa? or handled at all?
11:16Dezponia: karolherbst: Yepp, for example I can start KDE in XRender but I cant set it to OpenGL, as an example :)
11:16karolherbst: ohh wait
11:16karolherbst: gk110b is also like hte 780 ti
11:17karolherbst: okay, it should work
11:17Dezponia: Yepp, same GPU but some minor differences in the black (double float, twice the vram, probably some other stuff thats not relevant to gamers)
11:17mlankhor1t: tagr: getting spurious errors when making my webcam stream..
11:17mlankhor1t: [23167.638100] uvcvideo: Failed to query (SET_CUR) UVC control 6 on unit 1: -32 (exp. 2).
11:17karolherbst: Tom^: which mesa version do you have installed?
11:17mlankhor1t: [23194.839689] tegra-xusb-mbox 70098000.usb:mailbox: RX message 0x6:0x7e
11:17mlankhor1t: [23194.844691] tegra-xusb-mbox 70098000.usb:mailbox: RX message 0x6:0x5a
11:17Tom^: karolherbst: 11.2.0_devel.74897.0ef5c8a-1 somewhere around where imirkin landed his shader patches a few days ago
11:18karolherbst: Dezponia: which mesa do you have installed?
11:19Tom^: "Dezponia | Tom^: mesa 11.0.7, linux 4.2.5 and nouveau 1.0.12"
11:19Tom^: im 1 step ahead of you. :p
11:19Dezponia: What Tom^ qouted :P
11:20Dezponia: I've not poked at the git builds yet but that was the next thing to try
11:20karolherbst: yeah, it could be that you need a newer mesa
11:21karolherbst: Dezponia: but nethertheless, it would be really helpfull if you would install envytools, grab your vbios, upload it somewhere, and run nvapeek 101000 and give me the output
11:21karolherbst: we only have Tom^s nvf1 vbios and having more usually helps
11:22Dezponia: karolherbst: Sure thing, I'll get right on it once I'm done with my soup here :P
11:24karolherbst: Dezponia: Tom already got like 70 fps in unigine heaven with max settings ;) so nouveau can possible make good use of your gpu :D
11:24Dezponia: karolherbst: Nifty! Looking forward to testing it :)
11:25Dezponia: karolherbst: I also have a GTX680 4GB if thats of any use
11:26Dezponia: The card I upgraded from :P
11:26karolherbst: Dezponia: only if you have problems under nouveau with the gtx680
11:26karolherbst: we have tons of nve4 vbios
11:27Dezponia: karolherbst: I actually never tried that one under nouveau so no idea :P Might as well plug it in again and see what happens I guess just for goot QA messures :)
11:27karolherbst: problematic are usually those high end cards
11:28Dezponia: karolherbst: Not enough users interested in the free drivers I'm guessing? :)
11:28karolherbst: well there is not that high interest in such cards when you are running linux
11:29Dezponia: Probably a lot of "well if I bought a card for several hundred $ I'm going to get the most performance I can out of it, freedom be damned" going around :)
11:29Dezponia: karolherbst: Well theres more now with Steam and games comming but again, those who are interested in those things probably follow the above reasoning
11:31Dezponia: karolherbst: Alright, got envytools installed, now what?
11:32karolherbst: Dezponia: nvagetbios
11:33Yoshimo: for me it is rather more "as long as nvidia hasn't released the maxwell firmware, fuck freedom, without acceleration i am screwed anyway ;)
11:34Dezponia: Yoshimo: Thats why I got the best kepler card I could, since I dont want to get stuck in such a situation ever ;)
11:34Yoshimo: if i am in a different mood there is always a 560ti to go back to from the 980
11:34Yoshimo: which is well supported
11:38karolherbst: "well" :D
11:46karolherbst: Dezponia: and then nvapeek 101000
11:47Yoshimo: karol so you claim the 560ti isn't?
11:48karolherbst: with well supported I mean, there is also reclocking support ;)
11:52MichaelLong: I've also a 560ti, it was a damn good card used for a long time
11:53MichaelLong: but it couldn't reclock and s2ram was not possible, so I used it in a vga-passthrough setup
11:56Yoshimo: wasnt RSpliet working on memory for the fermi cards?
12:05RSpliet: ssshhh.... don't wake up sleeping dogs
12:10Yoshimo: he shouldn't have given hints in trello entries
12:12RSpliet: anyway, fwiw, nothing I have is in a remotely working state (yet)
12:12RSpliet: I hope to soon claim otherwise, but with only a single Fermi card in my collection that might be a long stretch
12:13Tom^: Dezponia: i more of bought this to compensate for the lower fps you usually got in wine with linux.
12:14Yoshimo: RSpliet: what is more difficult the engine ticket or the memory one? does one of them bring more fps than the other?
12:14RSpliet: the memory reclocking bit
12:14RSpliet: and that is generally the biggest bottleneck
12:15RSpliet: it's also the bit where I have my eyes on currently
12:16imirkin: Dezponia: a number of people have reported issues with kde5, although i haven't really had the opportunity to investigate
12:16Dezponia: RSpliet: So what you're saying is we should dump all our fermi based cards on you?
12:17RSpliet: Dezponia: and time, hookers and beer yes
12:17imirkin: Dezponia: a bunch of issues around suspend/resume should be solved with fresh kernels, but i doubt those are the ones you're experiencing
12:17Dezponia: imirkin: Dont think they are but cant hurt to try a later kernel regardless, right?
12:18Dezponia: I wonder what fermi based cards sell for these days, which one you got RSpliet?
12:18RSpliet: NFI, but it has GDDR5
12:18RSpliet: and I have to return it to it's rightful owner on Monday
12:18Dezponia: Aaahhh, not your card, then I understand :)
12:18imirkin: right. your gpu should be quite similar to Tom^'s and his seems to work largely ok. there's a patch i need to push out that'll actually fix random issues on all keplers, but that's only rendering artifacts, not hangs
12:19imirkin: Dezponia: that said, if you have a ton of vram, i wouldn't exclude the possibility that we got something wrong somewhere. most gpu's that are tested have less than 4GB
12:22Dezponia: imirkin: Speaking of which is there a way to verify the integrity of the vram somehow? Like a memtest for VRAM? :) nouveau or nvidias propriatary blob doesnt matter at the moment since it would be a one time process just to check it
12:22imirkin: not currently, but shouldn't be too difficult to write for an interested party
12:23Dezponia: Would be nifty to have since no such thing seems to exist right now from my research
12:23Dezponia: At least no such thing that works past 512MB of VRAM which is essentially useless today
13:16sobukus: karolherbst, MichaelLong: The new kernel doesn't change anything; nvs280 as secondary card is unbearably slow in scrolling (fine moving windows around), radeon 7500 as second card is fast, but corrupts memory after some time … offloading is broken
13:17sobukus: I'm realizing that I don't really _have_ to use 3 displays here; I'll make do with two of them connected to the main card, with the faint memory that using multiple cards at once used to work, before everything was rendered in 3D.
13:18sobukus: Thanks for your support, though.
13:30karolherbst: sobukus: ohh so it worked before only without 3d accell?
13:30imirkin: sobukus: it can all definitely be made to work... chances are you've got something misconfigured
13:31imirkin: sobukus: zaphod also works for plenty of folk
13:31imirkin: sobukus: but don't expect to be able to run a full 3d-accelerated workload + xinerama... that just won't end well
13:31imirkin: and keep in mind that things like to randomly use opengl for no reason now
13:32karolherbst: especially stuff like scrolling :D
14:03RSpliet: hmm, Fermi memPLL quite restrictive
14:03RSpliet: -- VCO1 - freq [300-600]MHz, inputfreq [8-27]MHz, M [15-15], N [21-22], P [1-1] --
14:03RSpliet: ^ when they say between 300 and 600MHz, they mean 300 OR 600 MHz
14:06sobukus: karolherbst: I mean it seem to recall that running multiple displays worked well in the times where drivers used the 2D engine of video chips, before Xinerama became widespread, even.
14:06sobukus: I seem to recall
14:07karolherbst: well zaphod should work nethertheless, but the downsides of that are really high
14:08sobukus: imirkin: Not a lot to misconfigure for the offloading case ... staring without xorg.conf and just doing xrandr --setprovideroutputsource, then xrandr --output ... --auto ...
14:09sobukus: Oh, I think that it would work in principle, just not with the PCI video cards I have. The Quadro might even have hardware issues, who knows.
14:10sobukus: The Radeon 7500 seems to suffer from some driver bug with the memory corruption. That stuff happens with the pace of driver development and hardware over a decade old that still could work but is not tested.
14:10sobukus:is trying to pick his battles and remember that he wants to get work done with the computer, not just on it
14:12karolherbst: sobukus: well if you just use the radeon card and it still gets memory corruptions, you may want to open a bug for that
14:12sobukus: I did have it working; Zaphod with the PCI Quadro before my mainboard broke (PCI ports stopped working o.O, then more subtle failures), then with onboard Radeon and PCIe Radeon.
14:13sobukus: karolherbst: I may, but is it worth it, in the end? I spent so much time on fixing up Linux/general computer stuff stuff (also as distro maintainer) … at some point, the fun is gone.
14:14karolherbst: I know :/
14:14sobukus: It's not like many thousand people want to use PCI Radeon 7500 cards on modern Linux desktops.
14:14karolherbst: it should still work though
14:15sobukus: Hehe, I applaud your persistence in bugging me to (help to) fix this;-)
14:16sobukus: But really, this whole project of fixing up this particular desktop system is already part of a subconscious avoidance scheme for real work I have to do.
14:16karolherbst: 2 displays are enough anyway
14:17karolherbst: if you really wanted to use three, then you would have bought a gpu which supports three displays ;)
14:17sobukus: I do run 3 displays on a HD5450 card at work; using VGA, DVI and DP.
14:17sobukus: The onboard Intel also supports it, but the driver did not like suspend to disk last time I tried.
14:17sobukus: It gets something I call Alzheimer-Epilepsy.
14:18sobukus: Buying a card that works was less effort than spending time on intel bugtracker again … it wouldn't be my first GPU instability bug hunt. With intel, even.
14:18karolherbst: I never used suspend to disk, so I have no clue there
14:19sobukus: It all gets interesting once you start combining functionality that works as such, alone.
14:19karolherbst: well you mostly don't have to hunt for bugs with intel, because usually intel can retest it themself :D
14:19karolherbst: I already reported some intel issues and most of the time I had to do nearly nothing
14:19sobukus: I have a history with intel graphics on my laptops. Intermittend GPU hangs. Very random, sometimes weeks apart, but persistent.
14:19karolherbst: besides testing a patch or something
14:20karolherbst: yeah I know, it was a pain
14:20karolherbst: but it seems to be getting better actually
14:20sobukus: Yes, now I see GPU hangs logged in dmesg but the system works around them somehow:-/
14:21sobukus: Simple framebuffers with a quick path to system memory would be so simple.
14:21karolherbst: ohh with prime I also see some intel hangs, but that's more because the stuff doesn't seem to be seperated that well inside core drm
14:21karolherbst: so the nouveau driver can mess up the i915 driver
14:21karolherbst: yeah well
14:22karolherbst: efifb :D
14:22sobukus: I'm not sure when I actually needed a 3D feature the last time with Linux.
14:22karolherbst: or vesafb or how that old thingy is called
14:22sobukus: Gaming was back then with Unreal Tournament … nowadays I'd start DOSBox with Tie Fighter. It's a 3D engine, even;-)
14:23sobukus: Trouble with the plain framebuffers is that they actually are too slow at 2D stuff. Scrolling.
14:23karolherbst: but as imirkin already said: most GUI application will use hardware acceleration
14:23karolherbst: Qt5 and GTK3 are using OpenGL for sure
14:23karolherbst: maybe GTK3 not and you can disable opengl accel in qt5
14:23karolherbst: but usually they will use it
14:24sobukus: Not sure how good nouveau framebuffer console is now, but I remember source code compilation being throttled by the nvidia console being slow in drawing the compiler command lines from make..
14:24karolherbst: well I think even the modern gpus don't have a seperated 2d engine anymore anyway
14:25sobukus: karolherbst: The Matrox Millenium II also had hardware acceleration that got used by toolkits … in 2D.
14:25karolherbst: well you can do a lot of 2d stuff with OpenGL
14:25sobukus: Yes, the last time I had video playback without tearing was with proper XV 2D video scaling engines that got removed nowadays.
14:26karolherbst: mac os x is doing this since 10.2 I think?
14:26karolherbst: ohh no, with 10.4 they used opengl
14:26sobukus: Since that video stuff switched to OpenGL, I always have horizontal tearing (Radeon, dunno about nvidia).
14:26karolherbst: sobukus: then you need to enable vsync ;)
14:26sobukus: Believe me, I tried.
14:27karolherbst: and you should use a window compositor
14:27karolherbst: even a simple one like xfwm4 will do the trick
14:27sobukus: Will a compositor cause a video window from mplayer being treated differently?
14:28sobukus: even -vo opengl?
14:28karolherbst: it depends on the surface used
14:28karolherbst: you can bypass the window manager in certain circumstances
14:29sobukus: It might be possible, but I hope you agree that it was somewhat simpler back when you used the video engine of the gpu using Xvideo where it was positively impossible for the video driver to introduce tearing.
14:29karolherbst: and what about all the windows?
14:30karolherbst: with a new kernel, tearing prevention doesn't has much overhead anyway, there is this new thing :D
14:30sobukus: Yeah, always new things.
14:31karolherbst: well I didn't see any tearing on my laptop for a year or something, so I don't really care about that anymore
14:31sobukus: Too bad that old things tend to break when new things arrive. There is too much that Linux already can do. You got a good chance to break stuff because there is so much of it.
14:33karolherbst: it is a bit sad, that simple stuff like window movements are creating a really high cpu load :/
14:33karolherbst: I get 20% on one core just because I move a window
14:33karolherbst: this is insane
14:33karolherbst: okay well, teh window turns transparent while I move it, but still :D
14:35karolherbst: oh that transparent effect doesn't do a thing to the cpu usage
14:36sobukus: Yes, when I activate opaque window movement in fluxbox, I can get 20 % cpu usage (at minimal freq, though).
14:36Tom^: which is why you simply dont use compositing :p
14:36sobukus: But normal setup is drawing a frame that moves while rest of display is frozen. That's rather cheap;-)
14:36karolherbst: ohhh I found the culprit
14:36Tom^: its bloat!
14:36karolherbst: redrawing the entire screen just produces 20% cpu usage
14:36karolherbst: and if nothing changes you don't redraw
14:38karolherbst: ohh my tearing prevention produces that load :(
14:38karolherbst: well but it works to be honest
14:38sobukus: Ah, right, my current tearing issue is not about videos, but about my 3-way setup at work; two rotated displays. Vertical scrolling on a rotated display really sucks.
14:39sobukus: I think I wasn't even able to get this fixed with the sync/tear options … work in progress in the driver.
14:39Tom^: make sure you are vsyncing toward the correct monitor
14:39Tom^: you sort of can only vsync towards one at a time
14:39sobukus: And: I acutally have performance issues where my display is hogged by a terminal window with scrolling text:-/
14:40sobukus: damn, you made me think about the problems I tried not to think about all the time
14:44karolherbst: yeah well, somebody has to figure out all those issues :p
14:44RSpliet: karolherbst: let me tell you a little something mindboggling about NVIDIA
14:44RSpliet: I just adjusted the VBIOS, correctly, to set the memclk to 1080MHz
14:45RSpliet: nvidia-settings reports for the perflvl that the mem rate is 2160MHz
14:45RSpliet: it however decides to set it to 648MHz
14:45RSpliet: the rate that is, the clock is set to 324MHz
14:45karolherbst: yeah but this is for the lower pstate right?
14:46karolherbst: well why should you get 648MHz on the highest?
14:46imirkin: sobukus: i can't tell if you're looking for assistance... if you are, pastebin xorg log
14:46RSpliet: because I said in the VBIOS that it was supposed to be 2160
14:46RSpliet: (instead of the stock 3600)
14:46karolherbst: RSpliet: yeah but is the driver on the highest pstate?
14:47karolherbst: you need to set it to something lower actually I think
14:47karolherbst: try 1400MHz
14:47RSpliet: no, I very specifically chose 1080/2160
14:47RSpliet: because that's a value that can be reached without a PLL
14:47RSpliet: (using only a postdiv)
14:47karolherbst: fermi that is?
14:48RSpliet: don't worry, I don't ask you to solve this mystery ;-)
14:48karolherbst: yeah I know
14:48karolherbst: I only found out that there are ranges the blob just don't want to use
14:48RSpliet: but my conclusions so far: 1) it completely ignores the "bypass PLL" bit in the VBIOS
14:48karolherbst: you could check if 1998 works though
14:49karolherbst: that's like the highest frequency I found for the "low" clock mode
14:49karolherbst: on fermi that is
14:49karolherbst: on kepler like all freqs between 2200 and 2400 were unstable as hell for whatever reasons
14:49karolherbst: or 2300 and 2400
14:49sobukus: imirkin: No, I settled for two displays now and the Nvidia card is stowed away. The past exchange was just chatter with karolherbst.
14:49karolherbst: and 2400 is the point where you use the second PLL
14:50imirkin: sobukus: ok cool
14:50sobukus: At least I can say that the nouveau channel is rather nice and helpful (was so before, too). I don't blame you for my NVS280 not playing nice.
14:51karolherbst: RSpliet: I also played with the clock with coolbits and nvidia-settings, and I think it also decides upon the clock how to clock to it
14:51karolherbst: RSpliet: and everything below that "reclock differently" point is a weird place
14:51RSpliet: 1240 gets rounded up to 1254
14:51karolherbst: maybe it isn't on fermi, who knwos
14:51RSpliet: conveniently within the PLL limits :-P
14:51karolherbst: the blob uses big steps
14:52karolherbst: expect steps like 20MHz
14:53karolherbst: RSpliet: there seems to be no fermi card with a memory clock ebtween 1998 and 3200 MHz and I am sure for a reason ;)
14:53RSpliet: karolherbst: 1200 gets rounded to 1254
14:53karolherbst: though the 1998 might be actually 4000 because that is a gddr5 card
14:54karolherbst: 1800 seems to be the fastest ddr3 clock on fermi
14:54RSpliet: 1150 is rounded to 324
14:55karolherbst: try 900 then ;)
14:55RSpliet: so the point is, there's a couple of bits where I want to learn of whether they mean "fuck knows, but enable me when using a PLL"
14:55karolherbst: RSpliet: but maybe with coolbits you get a bit further with your experiments though
14:55RSpliet: or "enable me when the clock goes above XXX"
14:56karolherbst: you want to RE the vbios a bit
14:56RSpliet: no, coolbits can be useful for this
14:56RSpliet: if it wasn't for the case that I'd have to install a driver that no longer supports NV50
14:56karolherbst: RSpliet: well, nouveau checks against 2400MHz roughly for kepler
14:56karolherbst: above that: double PLL, below that single PLL
14:57karolherbst: I don't think nvidia decides that upon what it finds in the vbios, because whatever you try, 3000MHz without the PLL won't work even when the vbios tries to tell this
14:58karolherbst: also the blob stoped using the second PLL when I downclocked to 2000MHz within nvidia-settings
15:01karolherbst: RSpliet: so did you try 900? :D
15:02karolherbst: I am pretty sure it will work, but I have no clue how that will help you
15:20karolherbst: mupuf: I have no clue where to set the divider for a temperature past PTHERM.I2C_SLAVE.THRESHOLD_6 though :/
15:21karolherbst: and the PTHERM.I2C_SLAVE.THRESHOLD_4 bit also doesn't seem to work (maybe it has to be activated somewhere?)
15:23karolherbst: anyway, the CURRENT_DIV is 0x8 + div set in PTHERM.FSRM_CFG_5 for THRESHOLD_2 when PTHERM.I2C_SLAVE.THRESHOLD_2 is hit
15:23karolherbst: and upon this information I will implement it then
15:23karolherbst: I will also arm the div 2 mode, because that also reduces power consumption by around 16% here
17:09imirkin: calim: i pushed that horrid texbar patch... sorry :)
17:22glennk: a texture walks into a bar, and says ow
19:43chillfan: when trying to use the video acceleration for my card (extfw from nvida blob) I get the following from the extract_firmware.py script: Unknown PGRAPH archive order in this version. is it important or can I just continue and disregard it?
20:02chillfan: ok got that working
20:02chillfan: nvm :)
20:02imirkin: chillfan: if you ran it on the version that the wiki page talks about you wouldn't get that message
20:03imirkin: however the extraction scripts serves a dual purpose
20:03imirkin: the second one being extracting PGRAPH firmware. you don't need that.
20:04chillfan: oh, but the binary produced is always the same right?
20:04chillfan: no matter which version..
20:04imirkin: they made minor updates
20:04imirkin: but it doesn't really matter
20:04chillfan: oh ok, so I should use the latest version
20:05imirkin: don't know of any actual differences in practice
20:06chillfan: fair enough, i'll use the latest supported 'just cause' instead of expecting any change :)
20:06imirkin: note that some h264 videos render poorly. others work fine.
20:07imirkin: figuring this stuff out has sucked the life out of me though, so i gave up figuring out why.
20:07chillfan: I would too, but that is beyond my skill set to figure out probably
20:09imirkin: and apparently beyond mine as well :)
20:09chillfan: speaking of the firmware, and driver, my card is supported but are there some documented ways I can provide information to help further it somehow?
20:10imirkin: what gpu do you have?
20:10chillfan: gtx 780ti
20:11imirkin: ah cool. Tom^ has one too and has been helping improve the reclocking situation with karolherbst (who is not here right now)
20:11imirkin: if you could retrieve a copy of your vbios and post it somewhere, i suspect that'd be interesting
20:11chillfan: yeah if it's not too difficult or way out there, I could have a go. Alright, how might I do that?
20:12imirkin: if you have nouveau loaded, cat /sys/kernel/debug/dri/0/vbios.rom > my-vbios.rom
20:13chillfan: ah okay, should it be the latest nouveau? edge?
20:13imirkin: doesn't matter
20:13imirkin: the vbios is what it is
20:14imirkin: if you're normally running the blob, you could get envytools and extract it that way
20:14chillfan: ah missing the debug thing, guess I need some debug feature from the kernel, will have a look at recompiling
20:15imirkin: you should talk to karol when he's around, he'll get you set up with reclocking too
20:15imirkin: you'll need to build a custom kernel
20:15imirkin: [if that's something that's of interest to you]
20:16chillfan: oh hm, I guess I could try that a little later on, if it's more involved, otherwise I can just put any info that's wanted/needed for now
20:19chillfan: eh tell you what i'll reboot to distro stock kernel as i'm not sure of the debug interface brb
20:23chillfan: okay i have the debug interface but there is nothing in there
20:24chillfan: nouveau is loaded
20:25chillfan: kernel is 3.16 stock debian kernel
20:26imirkin: same command as before :)
20:26chillfan: cat: /sys/kernel/debug/dri/0/vbios.rom: No such file or directory
20:26chillfan: dri is missing in /sys/kernel/debug/
20:26imirkin: is there anything in there?
20:26imirkin: perhaps debugfs isn't mounted
20:27chillfan: aha, how can I mount it?
20:27imirkin: mount -t debugfs none /sys/kernel/debug
20:28chillfan: mounted and stuff is there, no vbios
20:28imirkin: is there a dri?
20:29chillfan: yeah, under that directory subdirs 0,1,64,65
20:29imirkin: try /1/
20:29chillfan: ah there's a vbios in 1 :)
20:30chillfan: ok, got that. The issue with reclocking on 780ti, is it erm, something about voltage? I found a dmesg error for that on my other kernel (4.4-rc4)
20:31chillfan: and i guess i should just stick the vbios somewhere on an upload site, and mail someone with the link?
20:36imirkin: you can email it to email@example.com
20:36chillfan: alright, will do
20:45chillfan: Alright, just sent it :) If there's any more info I could grab from the card or the blob and it's simple enough, I could try now, will probably help more later on
20:54chillfan: brb actually
20:58chillfan: I guess this means the reclocking level doesn't work right? http://pastebin.com/WdrcbrdN
20:58chillfan: (0a no issue, 0f gives that error)
20:59imirkin: right. you probably want one of karol's branches...
20:59imirkin: not sure which one tbh
21:02chillfan: ah i'll check with them later then
21:03chillfan: I guess you don't need mmiotraces for cards not listed under 'TestersWanted'? I could try to send stuff for a few driver versions on my card if i can set that up
21:03chillfan: assuming that's still helpful
21:09imirkin: someone may make more targeted requests if you're looking to get reclocking to work better
21:09imirkin: i suspect that the issue with the highest perf level may be that we try to go too high and there's no voltage entry, and there's no logic presently to scale back
21:09imirkin: karol has patches to nix cstates without associated voltage entries iirc
21:10chillfan: ah alright, my cards voltages might be different.. it is a 'superclocked' model rather than a reference model
21:25chillfan: is the vbios from that interface the full thing? i actually found two, one in 1/ and one in /65
21:26imirkin: the 65 thing is identical to 1
21:27chillfan: alright, it was 64k, according to some references it's bigger than that
21:29chillfan: ah nvm, guess it's right heh
21:48chillfan: alright later, will try to help more tomorrow :)