00:00imirkin: a hypothetical fancy version could use aalib to show previews of texture uploads :)
03:55pmoreau: l1k: I am going to try again your patches serie on top of current Nouveau. Do you have a newer version than the one from 12 Aug.?
04:20Pwkay: morning. Someone got glitches while render opengl on nouveau on 850M card?
04:21Pwkay: cuz proprietary driver crashes my xorg and, if i ll find way to fix nouveau, i have no reasons to use proprietary driver
04:23pmoreau: Which version of Linux was he using?
04:24pmoreau: Hum, sorry misunderstood what you were saying.
04:24Pwkay: debian jessie
04:26pmoreau: By version, I mean a version number like 4.1 not on which version of a distribution you are. :-)
04:26Pwkay: i've got lines on the middle of display, while playing every game (teeworlds, for example)
04:26Pwkay: oh... wait, i ll google, which version of kernel jessie uses, cuz im noob :D
04:27pmoreau: you can run `uname -r` to know what is the current version you are running
04:27Pwkay: i cant actually, cum im tryed proprietary driver and its crashed xorg :'D
04:28Pwkay: amd 64 3.16, i think
04:29pmoreau: You need at least Linux 4.1 if you want acceleration support for that card
04:29l1k: pmoreau: sorry I was AFK. yes I'm working on it all the time, I'll send you a patch with yesterday's release.
04:30pmoreau: l1k: No problem :-)
04:31pmoreau: I looked at your github repo, but it didn't seem to have anything new on it.
04:31l1k: pmoreau: it's based on drm-next, I'm not sure which branch you're working on
04:32pmoreau: drm-next for the kernel part, and master from Ben's repo for the Nouveau part
04:32Pwkay: okie, i ll reinstall debian, cuz i spend one day to fix and going to debian channel with my question. Thanks!
04:32pmoreau: Pwkay: And quite sure you need at least 3.18-3.19 to get Nouveau to correctly identify and load for that card. But you should go for 4.1 at least for a better experience :)
04:33pmoreau: Pwkay: You could blacklist the nvidia driver from the kernel command line before booting, and then from the console remove it, without having to reinstall everything.
04:33l1k: pmoreau: I'm kind of in a dilemma with pushing stuff to github because I rewrite history numerous times every day in my local repo, I could force-push that to github but it's not great if someone else has cloned it. and I'm loathe to start a new branch all the time.
04:35pmoreau: You could have a branch "wip_dont-use-unless-you-know-what-youre-doing" and force-push on it :D
04:35l1k: pmoreau: sorry I was mistaken, the patch I have here is not based on drm-next but 4.2.
04:35pmoreau: Ok, I guess it should still work on drm-next
04:35l1k: I sent that patch to bruno bierbaumer yesterday to test it on his retina.
04:36l1k: I backported the whole thing to 4.2 for him to test it.
04:36pmoreau: But maybe the one for Nouveau will not as there was a quite large re-write that landed recently
04:36l1k: yes you're right I should make a wip branch.
04:36l1k: yes you're right.
04:37Pwkay: @pmoreau, nvidia driver crashed my xauthotiry too (i have no idea, why its happens, lol), and idk, how to fix it. So - easier way is reinstalling, cuz im still have backups of files
04:37l1k: I've tried to rebase the patch set on drm-intel-nightly just a few minutes ago and they seem to have ben's latest nouveau stuff and it didn't apply at all, ben seems to have rewritten it completely.
04:38l1k: ben's newstuff isn't in drm-next so I wasn't affected by that until today.
04:59Pwkay: and... its offtop, but... need i bumblebee for free driver, if my card supports optimus?
04:59pmoreau: Pwkay: You should not need it
05:00pmoreau: l1k: I thought the rewriting had landed in drm-next
05:03pmoreau: l1k: It landed 4 days ago on drm-next ;)
05:17pmoreau: l1k: Do you happen to have your patch for drm-next? O:-)
05:32l1k: pmoreau: oh... I guess I was working on an older version of drm-next then. mine was 1 or 2 days older. :-)
05:33l1k: pmoreau: I'll see to it that I pull latest drm-next and rebase on that maybe tomorrow
05:34l1k: pmoreau: but thanks for pointing that out... oops... :-)
05:34pmoreau: Ok. I'm currently editing the patch to get it applying on drm-next; it was more if you had it handy already prepared.
05:41l1k: pmoreau: the patch for AUX proxying in nouveau is not really necessary on your machine. and the one for the timer is just to fix unloading the module while the GPU is asleep, so also optional. and apart from that there are just conflicts in two patches affecting nouveau_connector.c and those are trivial to fix (like changing nv_probe to nvkm_probe).
05:41pmoreau: l1k: Maybe if you could send the patch you had for drm-next, even if it is a bit old, hopefully it doesn't include all the fb helper rework that you had to backport for 4.2
05:43l1k: I don't have it handy on this machine unfortunately and have to leave in a few minutes for an appointment so I'll only be able to send it tonight or tomorrow. :(
05:44pmoreau: Ok, no problem. :) I'll have to do some shopping in the meantime, and could then work back on fixing the G96, so no rush.
07:05Pwkay: old nouveau works with newer kernels, or i must update it too?
07:06Pwkay: cuz im on debian. 4.1.0-0 backported kernel and got a lot of nouveau errors when boot
07:07karolherbst: Pwkay: why are you using an "old" nouveau module?
07:13Pwkay: im on debian stable. Updated kernel to 4.1.0-0 from backports cuz of problems with opengl render on older versions, but got some nouveau errors at start
07:14karolherbst: can you paste the dmesg somewhere?
07:15Pwkay: emmh... idk, how to paste smthing, got at launch - im noob :c
07:16karolherbst: run dmesg in terminal and copy output here: http://pastebin.com/
07:16Pwkay: as root?
07:20karolherbst: Pwkay: you are using a laptop with hybrid graphics, right?
07:21Pwkay: 850M videocard
07:21karolherbst: sadly your dmesg output is a bit too small, because nouveau printed a lot of stuff
07:21Pwkay: what should i do?
07:21karolherbst: oaky, but runpm is a problem
07:21karolherbst: hard to tell whats wrong in the first place
07:22karolherbst: what version of nouveu are you using?
07:22Pwkay: how to find it?
07:23karolherbst: maybe /var/log/dmesg has it
07:24karolherbst: is there something when running this as root? cat /var/log/dmesg | grep "Initialized nouveau"
07:25Pwkay: it says "nothing had been logged yet"
07:26Pwkay: someone in debian irc told me about add nouveau.modeset=0 to kernel parameters. Will it work?
07:27karolherbst: don't think so
07:27RSpliet: Pwkay: no, old nouveau didn't work
07:27Karlton: how do you not have logs? :D
07:28RSpliet: old nouveau refused to do anything, whereas now nouveau tries to do things (poorly)
07:28karolherbst: he has a problem with runpm
07:28Pwkay: so....? what should i do to fix errors?
07:28karolherbst: and " nouveau E[ PFIFO][0000:01:00.0] SCHED_ERROR [ UNK06 ]" for some reasons
07:28karolherbst: but the card doesn't do anything?
07:28karolherbst: you could try this: "nouveau.runpm=0"
07:28karolherbst: but mhhh
07:29Pwkay: no more ideas?
07:29karolherbst: wow, this runpm error si strange
07:30karolherbst: Pwkay: do you have some kind of LED indicating power state of your gpu?
07:30Pwkay: i have steelseries keyboard with led
07:31RSpliet: it looks like "the card is suspended while still trying to do things"
07:31karolherbst: RSpliet: why should it do things in the first place?
07:31karolherbst: that's what bothers me most here
07:31Pwkay: and some wifi/bluetooth/etc indicators also, as every laptop
07:31RSpliet: well, it does do some device detection on boot
07:32Pwkay: so - i can work with these errors?
07:32RSpliet: set up data structures, configuration etc
07:32RSpliet: Pwkay: my standard reply is "try a newer kernel", to make sure it hasn't been taken care of already
07:32karolherbst: I thought the SCHED_ERROR are usually only there when trying to do something serious with the card?
07:32RSpliet: karolherbst: cards being offline could trigger arbitrary problems
07:32Pwkay: @rspliet, but its newer kernel, debian have
07:33karolherbst: 4.1.3 should be fine "somehow" ?
07:33RSpliet: Pwkay: "Debian" and new kernel in one sentence usually has an odd number of negations
07:33Pwkay: other kernals are in sid and have bugs
07:33RSpliet: known bugs, or the standard "unstable" fearmongering?
07:33karolherbst: every kernel has bugs
07:33Pwkay: i think. Didnt see
07:35Pwkay: nvm. Is this errors dangerous, or i can work fine?
07:36RSpliet: as long as you don't use the NVIDIA GPU, your system will run fine
07:36RSpliet: (which sounds like your previous situation)
07:42Pwkay: im on 4.1.3-1 right now. And...
07:42Pwkay: should i try this again?
07:44karolherbst: Pwkay: do you intent to use your nvidia gpu?
07:45karolherbst: oh wow, your pstates :D
07:46Pwkay: emmh... idk, what you means ._.
07:46Pwkay: so... is this ok? i did nothing - only rebooted pc
07:46karolherbst: nothing serious, its just a bit odd
07:46karolherbst: its okay for now
07:46Pwkay: and nvidia card ll work?
07:46karolherbst: try dmesg again, it should print some more stuff
07:47Pwkay: my laptop lagged
07:47Pwkay: and i cant do smthing
07:47karolherbst: nouveau will put the nvidia card into sleep state if you don't do anything
07:47Pwkay: and cant ctrl+alt+f1 too
07:48Pwkay: how to bring it back?
07:48karolherbst: RSpliet: seems like runpm is really borked for him?
07:50karolherbst: ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure, AE_NOT_FOUND (20150410/psargs-359)
07:50karolherbst: and ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEG0.PEGP.DD02._BCL] (Node ffff8802270e8d60), AE_NOT_FOUND (20150410/psparse-536)
07:50karolherbst: ohh the former is for intel
07:50karolherbst: the latter one is an issue
07:51karolherbst: Pwkay: nouveau.runpm=0 should help
07:51karolherbst: but then your nvidia card is always on
07:51karolherbst: and will suck battery life when on battery
07:53Pwkay: its ok - its strange, but im not using my laptop with battery
07:53RSpliet: yes, well... I'm not sure how much has been fixed upstream already; this problem goes beyond nouveau (and I recall reading something similar on the ML somewhere...)
07:53Pwkay: cuz it eats it so fast
07:53RSpliet: as if ACPI puts it to sleep behind nouveaus back
07:53Pwkay: how to make command you said?
07:53karolherbst: Pwkay: yeah when the nvidia card is off you have a lot more battery life
07:54karolherbst: Pwkay: ever installed bumblebee? if not, then we don't care about it yet
07:54Pwkay: im installed, but not on this machine
07:55Pwkay: but didnt use
07:55karolherbst: then its no problem
07:55Pwkay: im installed bumblebee for proprietary driver, got a lot of problems and then reinstalled system
07:55karolherbst: I was just worried, that there is some strange bbswitch setup
07:55Pwkay: what should i do?
07:55karolherbst: seems like its a serious ACPI issue then
07:56karolherbst: I poked in bumblebee channel already, maybe they know about this error
07:56Pwkay: okie, i ll wait
07:57RSpliet: Bumblebee is supposed to be deprecated in favour of prime
07:57karolherbst: ohhhh wait
07:57karolherbst: RSpliet: https://bugs.launchpad.net/ubuntu/+source/linux-lts-saucy/+bug/1281966/comments/3
07:57karolherbst: last part
07:58RSpliet: so these ACPI errors are unrelated
07:58Pwkay: if they r not dangerous, nvm
07:58Pwkay: what should i do right now?
08:00karolherbst: ohh right, seems like they are EC related those errors
08:01RSpliet: Pwkay: boot with nouveau.runpm=0 and see if the warning disappears; try a newer kernel (4.2 I guess) without nouveau.runpm=0 as a kernel param and see if your problem disappears; if it doesn't disappear, file a bug
08:02Pwkay: there are no 4.2 in backports :c
08:02RSpliet: then you might want to build your own
08:02Pwkay: how to but with it?
08:03RSpliet: reboot, in grub, instead of selecting a kernel press e, navigate to the line that starts with linux, and at the end of the line add the parameter
08:03RSpliet: or... there's some modules.conf system of which I don't know how it works
08:03Pwkay: not to last line?
08:03RSpliet: or... edit your grub configuration file to do something similar
08:03RSpliet: not necessarily
08:04Pwkay: there are echo "linux kernel boot' and linux /path-to-kernel lines
08:04Pwkay: where i must add my own?
08:04RSpliet: the second one
08:05Pwkay: before it?
08:05RSpliet: at the end of it, along with all the other parameters
08:06Pwkay: there are linux /vmlinuz-"kernel's number" root=/dev/mapper/snow- -vg-root ro quiet
08:06Pwkay: after last word?
08:06RSpliet: without quotation marks
08:07Pwkay: or before quiet?
08:07RSpliet: don't be afraid, it won't bite if you do it wrong first time ;-) (although if you edit a config file rather than using grub live, you could be in trouble :-P)
08:08Pwkay: and then press ctrl+x?
08:09Pwkay: error - cant find command esetparams
08:09RSpliet: then you probably accidentally added a letter in front of the existing "setparams" command
08:09RSpliet: I'm guessing... an e!
08:10Pwkay: what? oO
08:10RSpliet: ctrl+alt+delete and try again
08:11Pwkay: i ll paste dmsg
08:20RSpliet: that doesn't show any serious error messages
08:20Pwkay: paste again?
08:20RSpliet: if there's more info
08:20Pwkay: or... what should i do right now?
08:21RSpliet: well, if it silenced the problem you can choose between being productive on your laptop or digging on to find the underlying cause to help out the community
08:22Pwkay: how to save this setting?
08:22RSpliet: add it to /etc/default/grub in the "GRUB_CMDLINE_LINUX_DEFAULT" property
08:23RSpliet: then run grub-mkconfig -o /boot/grub/grub.cfg as root
08:23Pwkay: emm... wait
08:24Pwkay: im open nautilus as root, edit grub file and then save. Whats next?
08:24RSpliet: run grub-mkconfig -o /boot/grub/grub.cfg as root
08:26Pwkay: im on GRUB_CMDLINE_LINUX_DEFAULT='quiet'.
08:26Pwkay: where to place nouveau setting?
08:28Pwkay: after "quiet"?
08:55pmoreau: Pwkay: You can put it after quiet, like "quite nouveau.runpm=0"
08:56pmoreau: karolherbst: Hey! Did you encountered/played with 0x8841c on some Tesla cards while you were having fun with other PPCI regs?
08:58Pwkay: already. and errors back
08:59Pwkay: and its cant boot right now
09:00Pwkay: cuz im stuck on errors. No more errors and no more updates
09:02pmoreau: If you have another computer, you could try to ssh or set up netconsole could get all boot messages on the extra computer
09:02Pwkay: [ 30.016943] nouveau E [ PFIFO (or 0, idk)] [0000:01.00.0] SCHED_ERROR [ UNK06 ]
09:02Pwkay: and nothing happens
09:04Pwkay: im out of ideas. Removed line i added, but still cant boot
09:04Pwkay: nvm, booted right now
09:04Pwkay: i ll paste
09:05pmoreau: I think I have seen the PIBUS errors somewhere else... Have to remember where... :D
09:06RSpliet: pmoreau: well, there is this
09:08Pwkay: problem is back
09:08pmoreau: RSpliet: Maybe... But I was thinking of something more recent, and on Maxwell as well
09:08Pwkay: (i removed nouveau setting to load)
09:09pmoreau: Problem with this paste is we miss all the beginning.
09:11pmoreau: Could you redo it by blacklisting nouveau (either specify rd.blacklist=nouveau iirc, or add "blacklist nouveau" in /etc/modprobe.d/*.conf), `cat /dev/kmsg > some_text_file.txt` and then `modprobe nouveau`
09:11Pwkay: im out of ideas
09:12Pwkay: im removed added line on grub, cuz i cant load with it
09:14karolherbst: pmoreau: could be
09:14karolherbst: have to check
09:14karolherbst: pmoreau: why?
09:15pmoreau: I would be interested by bits 7 to 0 if you managed to undertand what they mean
09:15pmoreau: Cause, if I reset them to 0 before loading Nouveau, everything is fine
09:15karolherbst: okay, wait a moment
09:15pmoreau: otherwise, I get https://bugs.freedesktop.org/show_bug.cgi?id=86537 , can't suspend the G96, and some more
09:15Pwkay: @pmoreau, wait, i ll
09:16karolherbst: pmoreau: ohh interessting
09:16karolherbst: a problem I didn't thought about
09:17karolherbst: I never had suspend problems on my kepler card until now, but maybe for older cards its needed to do something with the pcie regs
09:17pmoreau: I tried modifying the reg while the blob was loaded, but he didn't seem to care at all!
09:17Pwkay: there are fbdev-blacklist.conf and modesetting.conf
09:17Pwkay: which one i must change?
09:17karolherbst: pmoreau: usually the blob does care, but there are a lot of regs which are interacting with each other
09:17karolherbst: some PPCI regs even change three or four others as well
09:18karolherbst: I think most of the PCIe stuff is implemented in the gpu itself, so the driver doesn't have to do as much as in the spec is described
09:18Pwkay: what should i do right now?
09:18pmoreau: Pwkay: Any of them, it doesn't matter
09:19pmoreau: Pwkay: All .conf file in /etc/modprobe.d will be read
09:19imirkin: Pwkay: what are you attempting to achieve? do you actually want to make use the nvidia gpu? seems like you'd be better off just forgetting it existed.
09:19Pwkay: i must add "backlist nouveau" to fbdev?
09:20karolherbst: pmoreau: mhh this reg only shows up in fermi traces
09:20Pwkay: i want to play on linux. Switched from windows cuz of rootkit backports
09:20Pwkay: so - yes, i need nvidia gpu
09:21imirkin: Pwkay: ok, well nouveau on that maxwell isn't going to get you any higher performance than the intel gpu
09:21pmoreau: karolherbst: Really? Interesting! I do have it in my traces though; maybe only on mobile GPU?
09:21imirkin: Pwkay: so if you're looking to use it for gaming, the nvidia blob driver is the only way to go
09:21karolherbst: there is also bumblebee , but then you have to use the blob driver ;)
09:21Pwkay: and proprietary driver crashes xorg
09:21karolherbst: Pwkay: I assume the main one?
09:21karolherbst: then its bad config
09:21imirkin: Pwkay: not sure how that's connected to what i'm saying
09:22Pwkay: im tryed on default kernel and cant boot
09:22karolherbst: Pwkay: most distrubtions can't handle hybrid gpu setups and just do stupid xorg config stuff
09:22karolherbst: if your "main" x server crashes, then something is just wrongly setup
09:22karolherbst: like trying to use the nvidia card on the intel display or something
09:23karolherbst: or using the nvidia libGL for the intel card
09:23Pwkay: yes, i did it wrong, cuz didnt installed xorg setup when installed proptietary driver
09:23karolherbst: you don't do that
09:23karolherbst: never install nvidia driver directly on hybrid setup
09:23karolherbst: distributions can't handle that
09:23Pwkay: what. What should i do?
09:23karolherbst: usually the bumblebee installer handles everything itself, but then you use bumblebee
09:24Pwkay: what i needs to do?
09:24Pwkay: right now?
09:24karolherbst: there are tons of bumblebee howtos ;)
09:24karolherbst: just find the one for debian and you should be good to go
09:24Pwkay: i must install bumblebee and it ll download proprietary driver too?
09:25Pwkay: ir what?
09:25karolherbst: something like that
09:25Pwkay: i ll google, which package i need
09:25karolherbst: it usually sets all the libGL insanity the right way
09:25Pwkay: can i install bumblebee by synaptic or only by terminal?
09:25karolherbst: pmoreau: found the reg in a trace called "suspend-resume.txt.xz" :D
09:26pmoreau: karolherbst: Could be mine :D Which card was it?
09:26karolherbst: mlankhorsts one
09:27karolherbst: Pwkay: please follow bumblebee howtos, I really don't know how to do that on plain debain
09:27pmoreau: Ah, so not mine then! :D
09:27karolherbst: and ask in #bumblebee if something goes wrong, its their domain the ;)
09:27pmoreau: But which chipset? (I don't have the repo at hand)
09:27Pwkay: lol. My kernel now is newer than bumblebee's kernel headers
09:28karolherbst: follow howtos and just don't install stuff ;)
09:29karolherbst: pmoreau: ohh stupid me, forgot to grep with the missing 0 :/
09:30karolherbst: 7 and 0 mhh
09:30karolherbst: 0 seems to be always 1 on the one card here
09:30karolherbst: and 7 is 0
09:31Pwkay: @karol, the are nothing in debian's bumblebee howto about this
09:31karolherbst: pmoreau: I see values of 0x02778403 and 0x02f78403 for this reg
09:31Pwkay: my kernel is 4.1.3 now, and bumblebee needs 3.16 kernel headers. It wont work?
09:31karolherbst: but this is fermi
09:31karolherbst: Pwkay: refer to bumblebee howtos, it doesn't have to be the debian one, you know?
09:31Pwkay: or i needs to switch back to my default kernel?
09:32Pwkay: i know. But... kernel isnt part of debian :/
09:32karolherbst: sure it is, every distributions ships their own kernel configured differently
09:33karolherbst: Pwkay: https://github.com/Bumblebee-Project/Bumblebee/wiki
09:34pmoreau: karolherbst: Quite different from mine then, I get 0x000284f1
09:34karolherbst: pmoreau: does it work with reg value 0x00008480 ?
09:34karolherbst: this is strange
09:34karolherbst: all the nv9* cards seem to have 0x00008480
09:34karolherbst: wait a moment
09:35pmoreau: But if I set it to 0x00028400, it works
09:35karolherbst: yeah, makes sense
09:35karolherbst: 0x00028480 should work too?
09:35pmoreau: As the blob uses 284f1, I guess I am deactivating something, but dunno what
09:35pmoreau: Maybe... I don't recall if I tried that value
09:35karolherbst: ohh found your trace
09:36karolherbst: 0x00028471 and 0x000284f1
09:36pmoreau: Though it happens to be the current value atm
09:36karolherbst: this is the oddest value for all nv9* traces
09:36karolherbst: but there is a GEN2_DIS flag
09:38karolherbst: pmoreau: your card seems to be more like a nva3+
09:38karolherbst: for this reg at least
09:39pmoreau: Weird card... :D
09:39karolherbst: yeah well
09:39karolherbst: I think 0x70 is the problem somehow
09:39karolherbst: 0x00028481 should work
09:41karolherbst: but this is just plain wierd
09:41karolherbst: okay mhh
09:41pmoreau: So, apparently after setting 8841c to 28400, the blob decided to put it at 28480 for some reasons, but not immediately after X was started
09:42pmoreau: I'll try setting to 28480 and 28481 before loading Nouveau
09:42karolherbst: there is also a card with 0xd8
09:43karolherbst: and 0x58
09:43karolherbst: I think the 0x20 bit is somehow bad?
09:44karolherbst: assumption: 0x000284d1 will also work
09:45karolherbst: ohh on kepler there is also this reg
09:45karolherbst: 00360400 is my value
09:48pmoreau: 0x00028480 works! Trying the other values
09:49karolherbst: okay, I can change my devCap latencies with that reg
09:50karolherbst: L1_LAT = 0x6 means <2^6us L1 DevCap latency
09:51pmoreau: 0x00028481 too, but not 0x000284d1
09:52karolherbst: then the 0x40 bit is the bad guy
09:52karolherbst: does 0x000284a1 work?
09:52karolherbst: ohh wrong
09:54pmoreau: 0x000284b1 didn't work
09:56karolherbst: ohh wait :/ I have to get used to hex bit thingies :/ long time ago I did this
09:57karolherbst: does 0x000284e1 work?
09:58karolherbst: the the three bits are a bit odd
09:59karolherbst: we could try 0x00028491, 0x000284a1 and 0x000284c1
09:59karolherbst: but I assume all will fail
09:59karolherbst: which would mean, that bits 4-6 are somehow related to this
10:06pmoreau: 284a1, 284c1 are bad, but not 28491
10:07karolherbst: mhh k
10:07karolherbst: then bits 5 and 6
10:08karolherbst: mhh sadly at least lspci doesn't change :/
10:08imirkin: lspci caches info
10:08karolherbst: ? how
10:08imirkin: you can pass it a flag to read the "real" thing out of the pci config space
10:09karolherbst: -H ?
10:09imirkin: sure, why not
10:09imirkin: [i have no idea]
10:10karolherbst: but how does lspci caches stuff?
10:10karolherbst: other bits does change something in lspci, allthough its always the documented ones
10:12karolherbst: mhh, no idea what these bits are for :/
10:13karolherbst: I think its safe to remove those bits for nv84+ cards?
10:14pmoreau: I'll have another look later tonight, I have to run.
10:14pmoreau: karolherbst: Thanks for the help! :)
10:47Pwkay: thanks you guys - im installed bumblebee and it works awesome! next time, i ll read documentation :D
13:38pmoreau: Really interesting! Huge swaths of PDISP regs are set to the value poked at 0x8841c... O.O
13:39pmoreau: And so, even if 0x8841c only accepts 0x0002ffff on my card, but I poke 0xffffffff, a huge amount of PDISP regs will contain 0xffffffff after that poke!
13:40imirkin: that means "card gone"
13:40pmoreau: I'm not sure about that: if I poke 28400, it will contain 28400, and so on
13:41pmoreau: I just poked ffff0000, and paf, I get a lot of ffff0000 in PDISP
13:42pmoreau: I have no idea why they would want to copy the value of 0x8841c to so many different regs
13:43tobijk: default initalizer? :>
13:44pmoreau: Most likely, but for that many using the same default initialiser?
13:44airlied: does it come back when you program it normally?
13:45imirkin: maybe the value is stuck on the bus
13:46pmoreau: airlied: Sorry, I'm not sure what "it" refers to.
13:49airlied: pmoreau: the rest of the address space
13:52pmoreau: If I program it normally (not poking reg 0x8841c), PDISP becomes unhappy at some point and the laptop locks up. Not sure how the different regs evolve during Nouveau init. I could try to dump them.
13:52airlied: yeah most likely you just lock the card up and it mirrors the last thing written
13:53pmoreau: I'll have to try while running the blob how it goes
13:53pmoreau: But if I poke the reg to remove bits 5 and 6, laptop won't lockup when using Nouveau
13:57pmoreau: Ok, while running the blob, they all stay at the same value, which has nothing to do with the value I poke
14:00pmoreau: airlied: So you're right :)
14:00karolherbst: I can write pretty much everything into the reg and the card won't lock up :/
14:01pmoreau: With a driver running?
14:01karolherbst: mhh I am running headless anyway
14:01karolherbst: so the card doesn't have any pressure
14:01karolherbst: this reg also sets the L1 latency
14:01karolherbst: and other stuff
14:02karolherbst: at least the card doesn't die for me and the PCIe controller isn't unhappy with the card either
14:02karolherbst: also the PCIe regs are also changing according to some bits written into this reg
14:03karolherbst: also this reg doesn't sound like a reg you wanna play with
14:03karolherbst: it also sets some routes and stuff
14:04RSpliet: you mean like the FBVDDQ volage GPIO or the memory clock PLL? :-P
14:04RSpliet:likes to live dangerously
14:04karolherbst: you can set the INTR_ROUTE to either PMC or DAEMON
14:04karolherbst: whatever that means
14:04tobijk: karolherbst: dont forget about my card which locks up frequently when changing width
14:04karolherbst: but it sounds dangerous
14:04karolherbst: tobijk: I will take care about widths after I finish the speed
14:04tobijk: ah allright :)
14:04karolherbst: maybe I just drop the width stuff entirely
14:04pmoreau: I found one or two that would cause the display to die completely, and I had to reboot as even the blob couldn't bring it back (was just trying to scan it)
14:05karolherbst: this has less priority
14:05mupuf: karolherbst: INTR_ROUTE is pretty simple
14:05mupuf: either the IRQs should go straight to the host
14:05mupuf: or PDAEMON will receive them first
14:05karolherbst: ahh I see
14:05karolherbst: there is also a CLKPM bit
14:05mupuf: and then can fire it back to the OS
14:05mupuf: pdaemon really can do anything the host can do
14:06karolherbst: I see
14:06karolherbst: I bet you don't have any ideas about the 5th and 6th bit?
14:06karolherbst: and also this "GEN2_DIS" bit looks kind of not like a "GEN2_DIS" bit
14:07karolherbst: I would assume after setting it gen2 should be disabled? but its not the case for me
14:07karolherbst: maybe kepler is different, but still then its kind of wrong?
14:08mupuf: nope, I have not paid attention to this. I was out the entire week end, again
14:09karolherbst: no worries
14:09karolherbst: what worries me most is, that I don't see any noticeable effect after setting bit 5 and 6
14:09karolherbst: and don't know, maybe its fine to just set them to 0 for all cards
14:10karolherbst: but maybe there are cards which are working with them set?
14:11tobijk: as we/you havent encountered such cards, stick 0 into it and move on :)
14:11karolherbst: mwk: added this flag to rnndb
14:12karolherbst: mhh "<doc>Set to 3 to disable gen2</doc>", totoaly didn't see that
14:14karolherbst: ohh, that value works
14:14pmoreau: tobijk: Well, Nouveau doesn't touch that reg currently, so who knows what might happen! (Apart from my laptop getting to a working state ^^)
14:15tobijk: i say that is a bonus we should not leave untouched :P
14:16karolherbst: maybe I will play with that reg a bit
14:17pmoreau: I won't complain ;)
14:21karolherbst: sadly the blob doesn't do much with the reg
14:21karolherbst: bits 0-7 are the most obvious changes
14:21karolherbst: but else, nothing
14:21karolherbst: ahh right, INTR_ROUTE
14:24tobijk: mh llvm 3.7 is out, i should check if my llvm mesa but still persists...
14:40pmoreau: Damn it, by disabling those two damn bits, everything works and I can switch as many time as I want between the two cards without any problems! And suspend/resume them as I'd like.
14:47karolherbst: pmoreau: wanna a dirty way to patch it into nouveau? :D
14:47karolherbst: mupuf: by the way. I found something nice
14:48pmoreau: I already have a dirty way to patch it :)
14:48karolherbst: mupuf: https://github.com/karolherbst/envytools/commit/8c7cb00b8425011f056f536acee1b3da617382b1 your card helped
14:48karolherbst: okay, I meant less dirty then
14:48pmoreau: But I'd be interested by your method as well ;)
14:48mupuf: karolherbst: nice :_
14:49karolherbst: this was 5.0 on your card and the cap was dropped to 5.0 as well (from 8.0)
14:49karolherbst: didn't checked if the blob reacts to it though or if the bit is writeable
14:50karolherbst: pmoreau: add a nvkm_mask write here: https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/pci/base.c#L113
14:51pmoreau: karolherbst: I went this way: https://bugs.freedesktop.org/attachment.cgi?id=118038
14:51karolherbst: I see
14:51karolherbst: but I am already thinking about something mergeable :D
14:51karolherbst: I don't see any harm in disabling those for all cards
14:52karolherbst: there is rarely any card with these two bits
14:52karolherbst: 2 traces max?
14:52karolherbst: in the entire trace git repo
14:53karolherbst: ohh wait
14:53karolherbst: it seems to be quite vommon for nv86
14:53karolherbst: 0x000004d8 for nv86
14:53karolherbst: or 0x00000458
14:53karolherbst: and yours nv96
14:54karolherbst: but nothing else
14:55imirkin: fwiw on my nva3: 00778403, nvc1: 00378403
14:55mupuf: karolherbst: good finding
14:55mupuf: to be verified though :p
14:55karolherbst: mupuf: wanna test my pcie patches?
14:55karolherbst: should work on kepler+
14:56mupuf: not now, and reator is taken by hakzsam_ :D
14:56mupuf: it is dodo time for me!
14:56karolherbst: I was just kidding
14:56karolherbst: its in WIP state currently
14:56mupuf: ack! Glad to see you are managing to write code for nouveau now :)
14:57karolherbst: mupuf: https://github.com/karolherbst/nouveau/commit/b4224088f66e848b01caa3eac35fd6e4d390968f
14:57karolherbst: this is nearly please merge state
14:57karolherbst: still RFC though
14:57karolherbst: but I think this is stable enough
14:57karolherbst: didn't found anybody for which it didn't work
14:57mupuf: ah, right, need to test this one!
14:57karolherbst: nice :)
14:58mupuf: see you!
14:58imirkin: pmoreau: you should see if the nv96's vbios has some logic for setting that reg
15:00pmoreau: mupuf: 'Night! o/
15:00pmoreau: imirkin: I think I had a look, but... I forgot what I found... --"
15:01karolherbst: would be nice if there would be something in nv86 vbios as well
15:01karolherbst: all three nv86 cards get those bits set in the trace repo
15:04pmoreau: imirkin: nothing in the vbios, or at least in the output from nvbios
15:04imirkin: pmoreau: hm ok
15:06karolherbst: I found another thingy I could do after finishing pcie :/ https://bugs.freedesktop.org/show_bug.cgi?id=70354
15:06pmoreau: Ah, that one... :)
15:06karolherbst: skeggsb patch is outdated now
15:07karolherbst: and my update to it, is kind of messed up
15:07karolherbst: timeouts at loading time
15:07karolherbst: still works though
15:08karolherbst: I think I messed up the nvkm_msec call
16:02karolherbst: pmoreau: any luck so far?
16:03pmoreau: Well, apart from playing with the patch I linked, not so much
16:05pmoreau: I did find that the blob enables EXT_TAG in 0x88080 before turning bit 6 on of 0x8841c. Could be just a coincidence though
16:06pmoreau: And I have no idea what EXP_DEV_CMD_STA or EXT_TAG is supposed to be.
16:06pmoreau: There's a few PPCI/PBUS writes around that block, but... All unk regs :/
16:08pmoreau: s/bit 6/bit 7
16:10karolherbst: EXP_DEV_CMD_STA is important for the pcie speed
16:12karolherbst: ohh no, wrong
16:13karolherbst: pmoreau: which write do you mean especially?
16:14pmoreau: I have a mask(0x88080, 0x0, 0x100), followed by mask(0x8841c, 0x0, 0x80)
16:14pmoreau: And before that I have some writes to 0x88424, 0x88430, 0x88190, etc.
16:14karolherbst: why do you want to clear 0x100 ?
16:15pmoreau: I (the blob)'m not clearing it, I'm adding it to the value
16:15karolherbst: ahh I see
16:16pmoreau: mask(a, b, c) -> a = (a & ~b) | c
16:16karolherbst: its also set on my card
16:17pmoreau: I could upload the trace I'm looking at if you want
16:17karolherbst: its fine, I think I have one already
16:18karolherbst: 0x088190 is unrelated
16:19karolherbst: the blob writes it before pcie speed change
16:19pmoreau: There are also 0x88490 before touching 0x8841c, and then 0x881e0, 0x881e4, 0x881e8 and 0x88150
16:19karolherbst: and reads from 194?
16:21pmoreau: 194 is read only once just before reading P2P_OUT_WRITE_SETUP_ADDR_LOW and a bunch of other PPCI regs, but it doesn't seem to change speed there
16:21karolherbst: 0x088150 is strange
16:21karolherbst: unrelated, but strange
16:25karolherbst: your system is v1 only?
16:27pmoreau: The iGPU yes, but not the dGPU
16:28pmoreau: "Capabilities:  Express (v2)" for my G96
16:29karolherbst: this bothers me a bit: "SYSTEM_SPEED = 2_5GT"
16:29karolherbst: lnkcap is at 2.5 for you?
16:29karolherbst: and 0x088460 contains 0xb0601220 ?
16:30karolherbst: ohh, now thats like super wierd
16:30karolherbst: lnkSta is 2.5?
16:30pmoreau: But the value is 0xb0601220
16:30karolherbst: nvapoke 0x088460 0xb0601221
16:30karolherbst: and check if lnksta switches to 5.0
16:31karolherbst: because if it does, it kind of destroys my plan :D
16:31pmoreau: It doesn't
16:31karolherbst: I was worried for a second
16:31pmoreau: And now 0x88460 = 0x03021220
16:31karolherbst: so the card won't do 5.0 even with blob?
16:32pmoreau: I don't remember; will check
16:32karolherbst: the reg content is a bit strange now
16:32karolherbst: seems like error state?
16:33pmoreau: I swapped two digits xD
16:33karolherbst: this is bad somehow
16:33karolherbst: try nvapoke 0x088460 0xb0601222
16:33karolherbst: and read reg again
16:33pmoreau: Ok, value is now back to b0601220
16:34karolherbst: and lnkSta is at 2.5?
16:34karolherbst: I know that the blob does sometimes this 0x2 write
16:34karolherbst: wasn't sure what this is about
16:35karolherbst: but this 0x4 on your card is like super wierd
16:35pmoreau: Rebooting to test the blob
16:35karolherbst: never saw it again
16:35karolherbst: you need to reboot?
16:35pmoreau: it doesn't take long
16:35karolherbst: yeah, still
16:36karolherbst: allthough I had a hard time to figure it out how I can change drivers without even restarting X here
16:36karolherbst: its worth it though :D
16:37pmoreau: Apparently, maximum link speed is 2.5GT/s
16:38karolherbst: I bet your motherboard just can't do 5.0
16:38pmoreau: Could be
16:38karolherbst: this 0x460 reg is pretty informative if you want it to be
16:38karolherbst: SYSTEM_SPEED= max speed of current hardware configuration, CARD_SPEED what the card can do, TARGET_SPEED= what the card should do
16:38pmoreau: But at least the link width can be increased on that card
16:39karolherbst: isn't it at x8 already?
16:39karolherbst: or x16?
16:39karolherbst: or was it this x1 <=> x16 card?
16:39pmoreau: It is I guess
16:40pmoreau: I didn't see the blob go through x8
16:40karolherbst: somehow I think its the best to stay at max width at all time
16:40karolherbst: there are some cards really unhappy about width change
16:40pmoreau: It switch from x1 to x16 when going from perflvl 0 to 1
16:40marcosps1: Hi guys :)
16:40pmoreau: hello :)
16:40karolherbst: pmoreau: do you think x1 can decrease pwoer consumption?
16:41pmoreau: karolherbst: TARGET_SPEED=5.0, CARD_SPEED=5.0, SYSTEM_SPEED=2.5
16:41karolherbst: yeah, I know
16:41marcosps1: There is some kind of debug method to print the inst->op for example? It kind of tricky to keep looking for OPs in that big enum when trying to figure out what is the OP being parsed :)
16:42karolherbst: marcosps1: you could check inside func->print()
16:42pmoreau: karolherbst: That's the kind of question you should ask mupuf about :) I just know he says most power saving would be achieved through power/clock gating
16:42karolherbst: I am just thinking if its worth the trouble caring about width
16:43karolherbst: if there are cards booting at x1 it would be a different thing, but otherwise?
16:43pmoreau: Which reg stores the width?
16:43karolherbst: ohh I totally forgot :D
16:44marcosps1: karolherbst: Hum... good, I'll take a look!
16:44karolherbst: marcosps1: I just know that this function dumps the entire instruction list for the func object
16:44karolherbst: somewhere there it has to have this op => name translation
16:45karolherbst: pmoreau: 0x088140 and apperantly 0x088088
16:45karolherbst: currently I don't see really through these all regs, there are a lot of doubled information
16:46pmoreau: Boot width is 16 then :)
16:46karolherbst: 0x088140 is gone on kepler though
16:46pmoreau: I would guess you have one storing the hardcoded capabilities of the card, and another one to store the current state
16:46pmoreau: That's the case with EVO capabilities
16:47karolherbst: there is more to it
16:47karolherbst: on kepler you have like to mess with 3 regs at worst, just to set the speed
16:48karolherbst: allthough most of the stuff can be done at loading time
16:48pmoreau: the more the merrier! ;)
16:48karolherbst: and you only mess with one reg in the end
16:48karolherbst: and usually you don't have to set the others
16:48karolherbst: but I was thinking, why not pushing my card to a v1 state with everything set to 2.5
16:49karolherbst: and try to bring the card back to 8.0 :D
16:50karolherbst: but I don't know
16:50karolherbst: there are so many regs with all that stuff
16:51karolherbst: and then there is this pci version thingy, then link cap, link control and link status and other crap :/
16:51karolherbst: I think the nvidia devs complained too, beause on kepler a lot of pci regs just vanished
16:57pmoreau: Could be nice to have nvapeek's output formatted like lookup, or at least have an option to enable that
16:59imirkin: i looked into it once
16:59imirkin: didn't seem simple, sadly
16:59karolherbst: bash for the win
16:59imirkin: esp coz nvapeek can print multiple things
16:59karolherbst: pmoreau: lookup $1 $(nvapeek $1 | cut -d\ -f2)
17:00karolherbst: imirkin: ohh right
17:01pmoreau: If the lookup option is enabled, nvapeek could default to printing one value per line
17:02karolherbst: for r in $@; do lookup $r $(nvapeek $r | cut -d\ -f2); done
17:02karolherbst: this should do the trick :)
17:03pmoreau: What about a range peek? O:-)
17:03pmoreau: like nvapeek 8800 1000
17:03karolherbst: okay, this is more complicated
17:04pmoreau: Oh, maybe I have part of it somewhere
17:05karolherbst: can I let nvapeek print 0 instead of ... ?
17:06imirkin: it's a bit annoying for ranges
17:07imirkin: i'd rather you write a new tool
17:07imirkin: which was expressly designed for single-register access
17:11marcosps1:caused a sigsegv by calling instruction->print()
17:13marcosps1: imirkin: do you think there is some problem with print() method or it's just me messing all up? :)
17:15imirkin: marcosps1: make sure to do that with NV50_PROG_DEBUG=1
17:15imirkin: otherwise some stuff doesn't get initialized
17:15marcosps1: imirkin: Yes, I'm doing it...
17:16marcosps1:goes to gdb...
17:17marcosps1: imirkin: PRINT("%s", colour[TXT_INSN]); this is the vilain.
17:17imirkin: coz you don't have NV50_PROG_DEBUG=1 set, the colors aren't initialized
17:17karolherbst: pmoreau: https://gist.github.com/karolherbst/5e4bffe5a7e4e6bd372d
17:18karolherbst: marcosps1: you need NV50_PROG_DEBUG set for print() to work
17:19marcosps1: imirkin, karolherbst: http://pastebin.com/em2XyFfs
17:20marcosps1: I'll keep looking, but it seems I'm initializing it...
17:20karolherbst: pmoreau: update the script, added a nice printf
17:20marcosps1: imirkin, karolherbst: If I comment the print, it shows the generated code for my nvc0, as it needs to be...
17:20imirkin: marcosps1: perhaps it's a non-debug build
17:20imirkin: in which case the debug env var has no effect
17:21pmoreau: karolherbst: Iterating over a range is weird
17:21marcosps1: imirkin: sadly enough: http://pastebin.com/yzSZ8Nyu
17:22karolherbst: pmoreau: :p
17:22marcosps1: I have --enable-debug set... =/
17:22karolherbst: it works
17:22imirkin: marcosps1: very weird, dunno
17:23imirkin: fwiw no need for the LD_LIBRARY_PATH/DRI_PRIME when using nouveau_compiler
17:23marcosps1: imirkin: Me and my weird env to make you all crazy ;)
17:23imirkin: it's not a graphics application
17:24marcosps1: imirkin: Hum, thanks for the tip.
17:25karolherbst: these python calls slow the script down pretty much :/
17:25karolherbst: but using bc is ugly in that case somehow
17:25marcosps1: I'll take a look i this weird problem, since ::print will help me to verify how coming from parser
17:26pmoreau: karolherbst: Ah, I didn't saw you were printing nothing when it was zero
17:26karolherbst: I though it makes sense somehow :D
17:27karolherbst: this sounds liek a fun reg to play with: "PPCI.GPU_RESET"
17:28marcosps1: imirkin: prog::print() initializes the colors...
17:28imirkin: marcosps1: yes
17:28karolherbst: but I like how nvidia uses badf1300
17:30marcosps1: imirkin, karolherbst: I need to specify NV50_PROG_DEBUG=2 to be able to use print... it's weird and not documented heheh
17:32marcosps1: imirkin: it's worth making a commit adding some documentation about using NV50_PROG_DEBUG...?
17:37pmoreau: karolherbst: Added chipset detection and multi-card support https://phabricator.pmoreau.org/P17
17:42karolherbst: this line has to be optimized: reg_new=$(python -c print\(hex\(0x$reg+0x4*\($i-2\)\)\))
17:42karolherbst: this python call is pretty expensive
17:42karolherbst: but I never really figured out how to use bc efficiently in hex mode
17:44pmoreau: I was using $(echo 16o$((0x$reg + 0x10))p | /usr/bin/dc) in another script
17:44pmoreau: I guess $(echo 16o$((0x$reg + 0x4 * ($i * 2)))p | /usr/bin/dc) could work maybe?
17:45karolherbst: seems to work
17:45imirkin: marcosps1: i have no idea what's going on to make that so... normally i just use =1 and it works fine. you must have changed something
17:45karolherbst: it is still slow
17:46karolherbst: maybe the lookup call is even slower?
17:46karolherbst: because of that xml parsing
17:47imirkin: doesn't help
17:47karolherbst: pmoreau: the dc variant is around 15% faster
17:47marcosps1: imirkin: but, if you take a look in nv50_ir.c you'll see "if (prog->dbgFlags & NV50_IR_DEBUG_VERBOSE)", winch implies to have NV50_PROG_DEBUG=2 to enter in this conditions. If this condition is true, thus prog->print() is called.
17:48imirkin: marcosps1: hmmmmm
17:49pmoreau: karolherbst: Ah ah! Well, optimising that script is probably not really important. But it could be fun :)
17:49karolherbst: pmoreau: I had a printf value wrong too https://gist.github.com/karolherbst/5e4bffe5a7e4e6bd372d
17:49imirkin: marcosps1: aha, but later there's one that uses NV50_IR_DEBUG_BASIC
17:49karolherbst: pmoreau: I am sure lookup needs time to parse the XML stuff
17:49imirkin: marcosps1: anyways, if you want to fix this inconvenience somehow, by my guest
17:50marcosps1: imirkin: yes, but I'm in optimizeSSA (who calls LoadPropagation), so colours aren't initialized...
17:50marcosps1: imirkin: can I change all of then to be DEBUG_BASIC?
17:51marcosps1: *all of them
17:52imirkin: marcosps1: no
17:52pmoreau: Damned! Enabling EXT_TAG seems to solve things!
17:53marcosps1: imirkin: just the one who cames before optimizeSSA...?
17:54karolherbst: pmoreau: interessting
17:54imirkin: marcosps1: no
17:54marcosps1:is failing miserably today...
17:55pmoreau: I can switch, I can suspend, and it doesn't crash!! \o/
17:55pmoreau: (and it loads, but, that's just a detail ;))
17:56marcosps1: pmoreau: sorry, but, what you solved..? :)
17:57pmoreau: marcosps1: The G96 in my laptop (that laptop has two Nvidia cards: one integrated (MCP79) and one discrete (G96)). And the G96 was causing Nouveau to crash upon init
17:58marcosps1: pmoreau: Awesome :)
17:58marcosps1: nvidia making linux users to cry every single day...
17:58pmoreau: That laptop might be usable with Nouveau for the first time in... 6 years? :D
17:58marcosps1: pmoreau: You deserv a place in heaven :)
17:59marcosps1: pmoreau: just when you die, of course.
18:00pmoreau: It's thanks to karolherbst and imirkin that I managed to found something interesting (and another user too)
18:00karolherbst: pmoreau: what cards are in the laptop?
18:00karolherbst: 9600M and 9400M?
18:00pmoreau: 9400M (MCP79) + 9600M GT (G96)
18:00karolherbst: sometimes you can really overdo stuff :D
18:00marcosps1: imirkin: when you have some time, please let me know what places I need to change to be able to use NV5-_PROG_DEBUG=1 instead of 2 in this case :)
18:00karolherbst: but I guess intel was really bad at this time
18:01karolherbst: pmoreau: so it seems we have a relatvion about those 5,6 bits and EXT_TAG?
18:02pmoreau: Most likely
18:02pmoreau: Which one though?
18:03karolherbst: don't know
18:03pmoreau: I'll have to look what this EXT_TAG could be in envytools
18:03marcosps1: pmoreau: while guys like you work hard on these problems, guys from nvidia are just sending patches removing whitespaces...
18:03karolherbst: pmoreau: look into pcie spec
18:04pmoreau: karolherbst: I'll probably have a look at my bed quite soon ;)
18:07karolherbst: pmoreau: good job anyway, didn't thought ext_tag has anything todo with that, at least I wouldn't have checked that
18:07karolherbst: maybe the pcie specs are helping in some way here
18:08karolherbst: these regs sometimes just mirror stuff inside the pcie regs of the card
18:08karolherbst: even if the order is sometimes different
18:18pmoreau: skeggsb: Do you think this would be an acceptable patch to bug #86537? https://bugs.freedesktop.org/attachment.cgi?id=118042 Still need some polishing, like putting the code in a proper location, and if hardware does not support EXT_TAG, disable bits 5 and 6 of 8841c to avoid any troubles
18:22skeggsb: pmoreau: what is EXT_TAG?
18:22karolherbst: pmoreau: are you sure about 0x0008807c ?
18:24pmoreau: skeggsb: No idea... It is a flag set by the blob just before enabling bit 7 of 8841c
18:25pmoreau: karolherbst: Bit 5 of 8807c is EXT_TAG also, and that reg represents the hardware capabilities, so quite sure about it
18:25karolherbst: pmoreau: yeah saw it now :/
18:25imirkin: pmoreau: seems a tad off to do it for everything...
18:26karolherbst: pmoreau: I saw it oly on nv86 and your nv94
18:26karolherbst: but it should be in the pcie specs somewhere what it does
18:27skeggsb: karolherbst: the binary driver seems to do it pretty much everywhere from what i can see grepping traces for nv50/g8x/g9x
18:27skeggsb: fermi too
18:28karolherbst: yeah but not bit 5 and 6
18:28karolherbst: maybe enabling EXT_TAG is fine
18:28pmoreau: karolherbst: If I enable EXT_TAG, I don't need changing bits 5 and 6
18:28karolherbst: but I am not sure about these bits in the other reg
18:28karolherbst: I see
18:29pmoreau: So it's more like: if EXT_TAG is not available on your card, then unset bits 5 and 6 if you want to be safe
18:29karolherbst: EXT_TAG is here enabled by defualt though
18:29pmoreau: Yeah, most likely my mac vbios the culprit
18:30karolherbst: you also can set width to 1 :D
18:30karolherbst: this is pretty rare from what I saw
18:30pmoreau: Had the same problem with the MCP79: all other computers were setting some bits in PFB, except on this MBP...
18:30pmoreau: Caused it to lockup on boot as well
18:31karolherbst: strange card
18:31pmoreau: Strange vbios or computer I would say
18:31pmoreau: Or you mean for the PCI width?
18:32karolherbst: also the way the gpus are hardwired to the display ...
18:33karolherbst: was this macbook reboot to change?
18:33pmoreau: Well, if it wasn't a weird laptop, I would most likely not be working on Nouveau today. :)
18:33karolherbst: oh well
18:34karolherbst: skeggsb: your hack would be the reason that I do stuff today :p
18:34karolherbst: maybe I will find time and take a deeper look or did you get any respond from nvidia :P
18:40skeggsb: no, i've pinged them a few times now on it, we'll likely figure it out ourselves before we get a reply
18:41aaronp: Sorry about that. We've been really swamped lately.
18:41aaronp: Plus you guys are asking questions that take a lot of time to track down the answer to. :)
18:42karolherbst: well easy question would be boring because they are most likely to RE pretty easy ;)
18:42imirkin: aaronp: perhaps you guys are making more of the questions than we mean to?
18:42skeggsb: aaronp: that's because it's the tricky/subtle things we get stuck on :P
18:42karolherbst: skeggsb: did you saw that on nve7 its a bit different?
18:43skeggsb: karolherbst: yeah, there's a new version of the patch in master fwiw
18:43karolherbst: ohhh where?
18:43imirkin: aaronp: most of the questions have a "how do we make nouveau work" subtext... not necessarily the complete hw specs :)
18:43skeggsb: i merged it in before the rework
18:43karolherbst: I reworked your patch so it works on current master :/
18:44karolherbst: skeggsb: this one? http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a1d7077da37dfe2c3f89d1445f5b78e63de5666c
18:44skeggsb: karolherbst: yep, that's the one
18:45karolherbst: War00C800_0=1 required?
18:45skeggsb: yeah, unless your device is white-listed for it already
18:45karolherbst: I am pretty sure its not
18:46skeggsb: i was able to make the GPU fall off the PCI bus by screwing up that stuff, so I didn't want to make it unconditional and accidentally something
18:46karolherbst: I managed the same
18:47karolherbst: seems like it has to be like this and nothing is allowed to be a bit different
18:48karolherbst: skeggsb: any way, do you have any comment on my gddr5 stuff so far? really want to get it into a proper state
18:49skeggsb: i've been meaning to look more fully into it, but haven't as of yet sorry :/ we should definitely get that issue fixed one way or another for 4.4
18:50skeggsb: the commit message needs modifying, it implies it fixes all the issues in that area, when it really doesn't :P
18:50karolherbst: I was hoping for 4.3 :D but this could be a bit tricky
18:50karolherbst: it also says WIP in the title ;)
18:50karolherbst: but yeah
18:50skeggsb: i can see phoronix jumping the gun and doing a sensationalist article about it, and then another saying how much we suck :P
18:51karolherbst: I sometimes manage to mess the card up by changing pstates a lot
18:51karolherbst: because it doesn't work for him without issues
18:51karolherbst: but while running bioshock infinite I could like change the psatate 400 times
18:51karolherbst: or more
18:51karolherbst: but gpu core voltage doesn't get increased for me
18:51karolherbst: so don't know if that was a gddr5 issue at all
18:52karolherbst: without that, after one or two changes the card was already messed up
18:52skeggsb: well, the issue you fixed isn't exactly a gddr5 thing either, it's just that ddr3 doesn't have clocks that go high enough to hit it :P
18:52karolherbst: I think the issue is, that two plls are involved
18:52karolherbst: and some combination of clocks are just not stable enough
18:52skeggsb: yeah, that's not because of gddr5 though, that's because of the high clock
18:53marcosps1: imirkin: busy right now?
18:53karolherbst: having a high clock into the second pll doesn't seem to be as bad though
18:53karolherbst: it was also working with the 800MHz refclock for me (from the 07 pstate)
18:53karolherbst: M=1 is the real deal here
18:54karolherbst: having it set to 2 or 4, like it was done before really messed up the PLL I assume
18:54karolherbst: do't know why, but it didn't work
18:55karolherbst: I should leave a comment about this though ...
18:55karolherbst: /* M do not touchy! Never */
18:58karolherbst: skeggsb: new version: https://github.com/karolherbst/nouveau/commit/1953fbfc01224099accd41031b05528de89cbce7
19:00karolherbst: skeggsb: but if you want to add it for 4.4 I may also implement the fN part as well
19:03karolherbst: I was already thinking to target gddr5 fix +0.1 kernel version, so that we get seperated benchmarks at phoronix for this :D
19:07pmoreau: Even suspend/resume works!
19:08karolherbst: I was scared that it doesn't work for me, too, but then it just happend and it was fine :)
19:08karolherbst: was runpm enabled for you?
19:08karolherbst: this is most of the time the real issue
19:08karolherbst: suspending while a card is turned off
19:09pmoreau: I think the two only issues left with the laptop now are: 1) reclocking for G96 but Roy is working on it, and 2) some terrible flickering when doing OpenGL on external screen
19:09karolherbst: for example: when I kexec a kernel while my nvidia card is off, the card is gone and I can't get it to be shown again
19:09pmoreau: runpm wasn't disabled
19:09karolherbst: but was the card off?
19:09pmoreau: And i suspended/resumed with one card off
19:10pmoreau: When I switch between cards, the other is automatically put to sleep thanks to vgaswitcheroo
19:10karolherbst: ohh right, you have these one card only gmux thing
19:10pmoreau: Ah, 3) Need to get Nouveau to detect the laptop gmux thingy and enable auto-suspend
19:10karolherbst: do you need to restart X?
19:10pmoreau: i do
19:11karolherbst: I only had such a macbookpro with dynamic switching
19:11karolherbst: I bet DRI_PRIME is no solution?
19:11karolherbst: the gmux hardwires to the display or something I guess
19:12pmoreau: skeggsb: This would be more or less the final version https://phabricator.pmoreau.org/P18. Should I move the code somewhere else (it needs to be run at init time and after a laptop suspend but not necessarily after a card suspend)?
19:12pmoreau: It's a hard mux iirc
19:13karolherbst: pmoreau: why not put it into pci_init and add pci_after_suspend or something?
19:13karolherbst: I also plan to do a lot of pcie init stuff
19:15pmoreau: I have to find how to get the object for reading/writing from there
19:15pmoreau: But it should be doable I guess
19:15karolherbst: nvkm_wr32 ?
19:16pmoreau: Could be
19:16karolherbst: I am already doing it this way
19:16karolherbst: works fine
19:16pmoreau: But, that'll be tomorrow's task as it's already 4:16 :-)
19:16karolherbst: right :D
19:17karolherbst: I will do some groundwork for tesla cards inside the pci subdev anyway
19:17pmoreau: (I'll have to test if this patch solve an issue on some G84...)
19:17karolherbst: I see
19:18karolherbst: but it seems like you need also a mask function
19:18karolherbst: mhh, then I will most likely add it I guess
19:37marcosps1: imirkin: there is a way to "ld u64" ?
19:40imirkin: marcosps1: no, there are 2 movs and a merge
19:41marcosps1: imirkin: Yes! I'm trying to figure out how this works to be able to continue to load a 64 bit...
19:41imirkin: [the merge is a fake op... just used for RA]
19:41imirkin: but the idea is that you should be able to propagate such a pair of mov's if the value they're loading is right
19:41marcosps1:was trying to read merge op in envytools, so now it makes sense...
19:53marcosps1: imirkin: So, it's already happening in the instrunction::print(): http://pastebin.com/DNdrWvsN
19:54imirkin: set u32 %r64 neu f64 %r60d %r63d
19:54imirkin: see that?
19:54imirkin: ideally that would be
19:54imirkin: set u32 %r64 neu f64 %r60d 0x3ff0000000000000
19:55imirkin: [assuming that set is one of the isntructions with a double immediate encoding option]
20:00marcosps1: imirkin: Hum... this makes things clear (or not...), but at least now I have some data to follow the code and get the same output.
20:03marcosps1: imirkin: Hum.... now I got it... instead of "ld ld merge" we'll use directly into set op?
20:05marcosps1: imirkin: everything makes sense now. I wasn't able to see thought the trello description until now...
20:05marcosps1: imirkin: thanks a lot!
20:06imirkin: i _think_ you need to make getImmediate() see through the merge, but... i haven't looked at it in detail
20:07imirkin: err... maybe not. see the isImmd32Load()
20:07imirkin: basically you need to add a isImmd64Load() variant
20:08imirkin: and i guess LoadPropagation::visit will need some fixing too
20:08imirkin: since it's no longer a direct load but a merge
20:13marcosps1: imirkin: noted here...
20:13imirkin: skeggsb: what's the issue with agpgart on mac? is it on *all* macs, or just a few?
20:14airlied: imirkin: the chipsets are bullshit
20:14imirkin: hm ok
20:14imirkin: what about pcigart - is that a thing?
20:14imirkin: i.e. is there a way for pci chips (not pcie) to write to system memory?
20:14airlied: not a chipset thing, the VM on nouveau does the job
20:14airlied: yeah PCI and PCIE work the same, you just DMA
20:14airlied: as does AGP
20:14airlied: the GART is just for remapping
20:15imirkin: but with AGP you can't just dma anywhere
20:15imirkin: with pcie you can
20:15airlied: yes you can
20:15airlied: you can use PCI DMA transactions fine on an AGP port
20:15imirkin: then what's with the aperture idiocy?
20:15airlied: the aperture is for giving the GPU a linear mapping of system memory
20:16imirkin: which they care about because...
20:16imirkin: oh, because no VM
20:16airlied: there are also various reasons the AGPGART is on the chipset
20:16airlied: mostly speed reaons for the CPU updating it I think
20:17imirkin: but then PCI "gart" has the same issue... does it go through swiotlb or something?
20:17airlied: no it's just slow
20:17imirkin: not sure i get it
20:17imirkin: is it slow coz 32bit 33mhz is slow
20:18airlied: let me see if I can page it back in
20:18imirkin: well... tbh it doesn't matter
20:18imirkin: basically i have an agp thing plugged in
20:18airlied: I'm not sure how nivida worked
20:18imirkin: and i guess that can't use system memory
20:18imirkin: basically i'm thinking about how to deal with this BE/LE nonsense
20:18imirkin: and what happens to the data as it moves around
20:19imirkin: i probably need to do some very careful tests, write to vram with m2mf and then peek it through imem or something
20:19airlied: I'd ignore the AGPGART for now
20:20imirkin: well, so i think that the hw swaps everything on m2mf
20:20imirkin: which is how we move things into vram
20:20imirkin: so... it'll be LE in vram
20:20airlied: the mac AGP was designed for simpler times
20:20airlied: where you just stuck 128MB RAM in the GART at boot and never changed the backing
20:20imirkin: sure, but i want my thing to work for the pcie macs too
20:20airlied: our drivers would like to change the backing pages dynamically
20:20airlied: and the apple chipset generally screws that up
20:21imirkin: anyways, since the PCIe would have gart in sysmem, and sysmem writes *don't* go through m2mf of some sort...
20:22airlied: I think for PCIe you'd store the GART in VRAM
20:22imirkin: we'd end up with diff representations of the data in sysmem and vram, which is unlikely to be a good idea
20:24airlied: at least on radeon, pre-r500 the PCI gart table was in system RAM
20:24airlied: and the GPU have a one entry tlb
20:24airlied: so it pretty much sucked
20:24orbea: will nouveau work with a deblobbed kernel?
20:27orbea:reads this and thinks he may of answered his own question http://www.fsfla.org/ikiwiki/selibre/linux-libre/
20:27Karlton: yes, it should work with linux-libre kernels and deblob scripts
20:28orbea: cool, that is what I thought, but I heard it was wrong so I wanted to make sure :)
20:31Karlton: (not sure if that will change later with the cards that require signed firmware)
20:32imirkin: orbea: pre-GM200 should be mostly fine
20:32orbea: hope not, I like how my failing cards still more or less work with nouveau, but nvidia wont even get me into x
20:33karolherbst: at least intel skylake won't work :/
22:14fling: Will there be a lot of changes in 4.3?
22:15imirkin: fling: yeah, nouveau received somewhat of a rewrite
22:16imirkin: not a lot of functionality change, but lots of adjustment to the internals
22:17fling: imirkin: No nvc0 memory reclocking improvements planned?
22:17skeggsb: unless you do it yourself, i doubt fermi will get touched until kepler/maxwell have been fully sorted out
22:21fling: ok :>
22:23karolherbst: though I somehow planned to take a look, because I have a fermi card here, but my kepler is somehow more important to me :)
22:23imirkin: and a lot closer to working :)
22:23karolherbst: pcie reclokcing will be messy on fermi though
22:23karolherbst: because pstate doesn't work at all, right?
22:24fling:is using nv50
22:24karolherbst: ohh right
22:24imirkin: karolherbst: erm, the two are somewhat disconnected
22:24karolherbst: skeggsb: the current nvif interface for pstates are kind of bad for reporting pcie speeds :/
22:25karolherbst: imirkin: I meant the sysfs interface
22:25karolherbst: it returns -ENODEV or something?
22:25imirkin: karolherbst: yea
22:25imirkin: would be nice to rework all that into a state we can expose btw
22:25karolherbst: what do you mean by the latter?
22:26imirkin: including letting fermi reclock core without memory
22:26imirkin: i mean that it's in sysfs now
22:26karolherbst: ahh I see
22:26imirkin: and we can't expose it because there are rules with sysfs
22:26imirkin: whereas in debugfs -- there are no rules
22:26karolherbst: I was thinking to add pcie speeds with the pstates
22:26karolherbst: ohh wait
22:27karolherbst: take it :p
22:27karolherbst: totally forgot about that
22:27imirkin: problem with the space key? :p
22:27skeggsb: i'm actually thinking i'd rather still use sysfs, but convert it to the style they're anal about (ie. one attribute per file)
22:28airlied: shouldn't it all happen automatcailly? :)
22:28skeggsb: but i haven't really thought much about it, the backend of it all doesn't work properly, so i don't much care about the userspace interface
22:28skeggsb: airlied: yes, it should
22:28airlied: so debugfs is probably fine :-P
22:28karolherbst: I actually cared about what imirkin said and ported all my stuff to the debugfs thingy
22:29skeggsb: meh, i don't much care either way really, as i said, i'm more interested in making it actually work
22:29imirkin: imho it's the right move... and positions us to expose a lot more granular things, like cstates, etc
22:30karolherbst: debugfs is more save to develop on
22:31imirkin: skeggsb: btw, looks like you got rid of the agpmode param for 4.3 -- i think that's likely to break a bunch of people
22:31karolherbst: procfs is sometimes, well, mhh how do I put it, ... a bit edgy
22:31imirkin: skeggsb: i know it's still there as NvAGP, but... people won't have that in their boot lines.
22:32skeggsb: good, that'll give us a chance to catch those bugs and add the quirks for them :)
22:33karolherbst: skeggsb: I am a bit annoyed about this NVIF_CONTROL_PSTATE_ATTR interface :/
22:33imirkin: somehow i doubt they're going to file bugs or come to us... just complain about broken nouveau
22:33karolherbst: they complain either way :p
22:34imirkin: not if you don't break it
22:35karolherbst: ohh right, but this is the rule of kernel development anyway, isn't it?
22:35imirkin: there's a rule about "no regressions"
22:35karolherbst: yeah, don't break stuff
22:35skeggsb: generally, but it's usually a "you have to fix it if people notice" :P
22:35imirkin: and complain in time
22:36karolherbst: broken interfaces only get repaird while in rc state?
22:36karolherbst: or something
22:36imirkin: and people with agp probably don't update their kernels too often so... problem solved?
22:36imirkin: by the time they update again, it'll be too late
22:36karolherbst: what is the issue by the way?
22:36imirkin: module param was removed
22:37karolherbst: yeah, but what did the param do
22:37skeggsb: overrode the default agp speed
22:37karolherbst: ohh I see
22:37imirkin: allowed to set a lower agp mode, or disabled agp entirely
22:37imirkin: agp was a pretty finicky thing back in the day
22:37skeggsb: in case the chipset+gpu combination sucked at the max speed
22:38imirkin: i think they had issues at the electrical level
22:38skeggsb: i wonder if nvidia would give us their quirks list...
22:38skeggsb: (for agp)
22:38karolherbst: I bet there are some simliar mechanis around like with the pcie stuff, only that the pcie stuff doesn't seem to mess the card up
22:38imirkin: i suspect that pcie learned from agp's mistakes
22:38karolherbst: there are still tons of regs in tesla/fermi which indicate some kind of limits
22:40karolherbst: but are these agp issues stuff like x4 card in x8 slot and card upset or really messy issues like chipset and gpu not compatible?
22:40skeggsb: the latter
22:40karolherbst: sounds bad
22:40skeggsb: we already negotiate the link speed to the maximum supported by both the gpu and chipset
22:41skeggsb: yes, hence why they're quirks and not a driver bug per se
22:42karolherbst: today we found some kind of "reset" bit for a pcie reg on tesla, which kind of unmessed a reg
22:42karolherbst: maybe there is stuff like that for agp as well?
22:42skeggsb: the binary driver has some code in it which, if it detects too many gpu errors on agp, will automagically revert to pci mode
22:43skeggsb: all gpu clients would have to die to do that, however
22:43karolherbst: sounds user friendly as hell
22:43skeggsb: agp just sucked, basically
22:44karolherbst: never had such fun with agp sadly
22:44karolherbst: the time I dealt with agp cards, I used macs
22:44karolherbst: allthough I used win cards at the end
22:44airlied: well via and apple chipsets were the worst offendors
22:45airlied: but also AGP was designed for dnyamic GART updates, but nobody really used them
22:45karolherbst: the most annyoing thing for me were just these overpriced gpus
22:46karolherbst: there were actually some stores selling reflashed x86 gpus without marking them as those, still overpriced though
22:47karolherbst: imirkin: ohh this would be a lot of fun for you
22:47karolherbst: is your ppc a agp one?
22:50imirkin: karolherbst: yes.
22:50imirkin: karolherbst: but apparently agp on macs was entirely broken
22:51imirkin: disabled by default for nouveau
22:51karolherbst: can nouveau handle x86 gpus on macs?
22:51karolherbst: *ppc mac
22:51imirkin: at least... i think
22:51karolherbst: would be nice to test some reflashed cards
22:52karolherbst: or at least to analyze these bios files
23:06imirkin: skeggsb: so... how does data get uploaded for agp gpu's whose agpgart is disabled?
23:06imirkin: [in a pre-nv50 world]
23:06imirkin: is this where all that dma objects jazz comes into play?
23:07skeggsb: well, those are used on agp too, to point at the aperture
23:07skeggsb: but, yes, those can also have a page table
23:07imirkin: oh really? they can do effective sgdma?
23:07imirkin: so what's so bad about doing that?
23:07imirkin: i.e. what's so great about agpgart?
23:08skeggsb: *shrug* i'm actually not entirely sure, i presume there's some kind of benefit to using it though
23:08imirkin: iirc it used to be that you set agpmode=0 and got GART: 0mb
23:08skeggsb: that shouldn't have been the case
23:08imirkin: ok. perhaps i remember wrong.
23:08skeggsb: or we print it wrong
23:08airlied: at least on old radeons the PCI gart table was in system RAM, and the GPU had to fetch the entries from it
23:08skeggsb: but, it's there
23:08airlied: so there was a lot of overhead
23:08imirkin: oh, SPEAKING of gart...
23:09imirkin: skeggsb: what do you think about limiting GART size for nv50+?
23:09imirkin: right now it's set to 1TB
23:09airlied: putting the translation table in the chipset made GPU life a lot faster
23:09imirkin: but some pour suckers have less than 1TB of ram
23:09skeggsb: airlied: ours is in instance memory (ie. vram), so, that's not a benefit really
23:09airlied: skeggsb: well the driver had to write it over PCI then still
23:09imirkin: and so it's easy to end up pinning a whole lot of ram as sysmem and then have the oom killer go on a killing spree
23:10karolherbst: imirkin: what "benefits" would such a limitation have?
23:10imirkin: karolherbst: less oom
23:10karolherbst: like mine oom?
23:10skeggsb: imirkin: i thought ttm handled limiting that.. and kicking stuff out when it got too much
23:10imirkin: skeggsb: oh hm. maybe it just needs to be tuned then
23:11karolherbst: skeggsb: I had some real oom fun some months ago :)
23:12imirkin: well, some applications run out of their 32-bit vm space
23:12karolherbst: skeggsb: imagine this: some stupid game sucked like 16GB+ bo in kernel space + 0f pstate going crazy + kernel oom goes around to play a bit :)
23:12imirkin: but that could well be for other reasons