00:08 gnurou: skeggsb_: wow, none of my patches apply properly anymore :)
00:08 skeggsb_: gnurou: yes, apologies for that
00:08 gnurou: skeggsb_: I suppose it's for the best, thanks for the heads-up
00:08 skeggsb_: the consequences of renaming the world, unfortunately
00:08 gnurou: besides it's my fault for keeping patches out-of-tree for so long
00:09 gnurou:flogs himself
00:09 skeggsb_: if it helps, i've rebased them so many times that i'm *really* over fixing conflicts :P
00:10 gnurou: oh, you have separated the big drm/Kbuild into many small ones
00:10 gnurou: nice
00:10 skeggsb_: yeah, i wanted to be able to reuse them for the library build
00:10 skeggsb_: i got sick of updating two sets of build files
00:11 gnurou: yeah, that sounds sensible
00:12 gnurou: well, great task to close the afternoon while listening to chiptune :)
00:12 skeggsb_: nothing changed btw, so chances are you can git format-patch, then s/nouveau/nvkm/ on them
00:12 skeggsb_: then apply
00:13 skeggsb_: well, aside from some shuffled headers and redundant includes removed etc, but no code
00:14 skeggsb_: i was pretty paranoid about accidentally breaking something, so, objdump was used to make sure :P
00:14 gnurou: right, that's less scary when looked under that angle
00:18 gnurou: uh, what happened to vm.h btw?
00:18 skeggsb_: mmu.h
00:18 gnurou: of course
00:18 skeggsb_: things are generally called what you guys call them now, if that helps
00:19 gnurou: well I was used to the way *you* called them... ;)
00:19 skeggsb_: ;)
00:20 gnurou: I don't work on the proprietary driver so I grew fond of the Nouveau way
00:23 gnurou: btw, I will be at FOSDEM, hope to meet many of you guys
00:25 mlankhorst: oh goodie
00:26 mlankhorst: I'm not there in the morning :P
00:26 skeggsb_:needs to make it there some year
00:26 mlankhorst: but I'll be there saturday afternoon and whole of sunday
00:27 gnurou: mlankhorst: cool!
00:27 gnurou: I will be there the whole time, probably mostly in the graphics devroom
00:36 pmoreau: I need to book the hotel and transports
00:36 hakzsam: skeggsb_, great job, but I think my set of patches for performance counters won't apply with that :)
00:40 mupuf: "drm: remove symlinks from build, use Kbuild files for lib build" --> sweet
00:43 mupuf:predicts skeggsb_will be the 1st in the changed lines hall of fame of lwn
00:52 maliboy: how is the performance nouveau performance for GT 635M graphics ?
00:58 hakzsam: skeggsb_, btw, what did you not rename nv50 to g80 ? the nvidia gpu names have to be only used for fermi+?
00:59 skeggsb_: nope, that was deliberate, nv50 was really nv50 except in marketing
00:59 skeggsb_: that changed from g84
00:59 hakzsam: okay
01:18 koz_desktop: I've set nouveau.pstate=1. Is reclocking automatic, or do I have to do it manually?
01:22 mupuf: no, it is manual
01:22 mupuf: you'll find a pstate file in /sys/class/drm/card0/dev/
01:22 koz_desktop: mupuf: What should I set it to?
01:22 mupuf: sorry, /device/
01:22 mupuf: cat pstate
01:22 koz_desktop: I actually don't know what clock speeds my card is designed for, or what the stuff in pstate means.
01:23 koz_desktop: OK, I have the following:
01:23 mupuf: then echo $number > pstate
01:23 koz_desktop: So just, whatever?
01:23 koz_desktop: Hold on, let me just paste you my current pstate.
01:23 mupuf: patebin please
01:24 koz_desktop: http://pastebin.com/Hhaw65p9
01:26 koz_desktop: My card is a GeForce GTX650.
01:27 koz_desktop: Non-reference from Asus.
01:30 hakzsam: koz_desktop, only some NV50 have reclocking support, IIRC
01:31 mupuf: hakzsam: keplers have a better support
01:31 koz_desktop: Yeah, this card's a Kepler.
01:31 koz_desktop: I just dunno what to clock it to.
01:31 mupuf: well, try : echo a > pstate
01:31 mupuf: if it works and games are stable
01:32 mupuf: you may try the f power state
01:32 mupuf: 7 is hte slowest
01:32 skeggsb_: if it's a gddr5 kepler don't even bother trying 0xf
01:33 skeggsb_: *unless*
01:33 skeggsb_: you do it while nouveau loads, it might work then
01:33 koz_desktop: OK, gonna test it now.
01:33 skeggsb_: "config=NvForcePost=1,NvClkMode=0x0f" has a chance, but that's the only way
01:33 mupuf: skeggsb_: you got rid of the mem reclock flagM
01:33 mupuf: ?
01:34 skeggsb_: oh, with NvMemExec=1 too
01:34 mlankhorst: shrug, I comment out the GDDR5 stuff and abuse my old scripts to turn up memory
01:34 mupuf: (sorry, still trying to learn the qwerty keyboard)
01:34 mupuf: bbl
01:34 koz_desktop: mupuf: So echo f > pstate?
01:37 koz_desktop: I'm a bit confused as to what to do...
01:38 koz_desktop: I've tried both, and it doesn't seem to give me any performance gain.
01:44 fling: mupuf: It hangs when I open a huge image in xombrero sometimes.
01:44 fling: With an older kernel version also happened with smaller images too.
01:44 gnurou: skeggsb_: oh, it seems like you haven't finished converting everything to the "NV names"?
01:44 gnurou: e.g. instmem still uses nvXX
01:45 skeggsb_: gnurou: there's nothing in there that was getting converted (still calling nv50, nv50)
01:45 gnurou: ah, good
01:45 gnurou: so I don't have to expect more fun?
01:45 skeggsb_: nope
01:45 gnurou: great
01:53 karolherbst: hey guys, PGRAPH issue fixed for me with this kernel patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=74b51ee152b6d99e61ba329799a039453fb9438f
01:56 gnurou: skeggsb_: gk20a seems to work fine after your change
01:56 gnurou: the renaming is giving me some pain though ; that's a good lesson to submit my patches earlier :(
02:00 hakzsam: I have ~1500 changes in the perfmon engine (now called pm), I think I'll take one full day to rebase them :)
02:02 skeggsb_: hey it only took me two to rename everything :P
02:02 hakzsam: hehe :)
02:02 mupuf: koz_desktop: you'll need to add the following to your kernel command line
02:03 skeggsb_: bbiab
02:03 mupuf: nouveau.conf="NvMemExec=1"
02:04 mupuf: skeggsb_: I seriously like the idea of getting rid of all the symlinks
02:04 mupuf: and also getting rid of automake in favour of a small script
02:05 mupuf: (if I understood correctly, I cannot really review the patches at work)
02:23 koz_desktop: I've changed my power mode to 0a, but I'm not getting *any* performance improvement.
03:43 mlankhorst: memory clock is still awful probably
03:59 mupuf: mlankhorst: actually, for some reason his core clock did not change
04:01 mlankhorst: ah
08:03 vnd: hi guys, I have a problem with nouveau driver - the fan is running much too fast
08:03 vnd: the problem occurs when I load the nouveau module
08:03 vnd: my gfx card is geforce gt 730
08:04 mlankhorst: is it running at full speed or below?
08:05 vnd: mlankhorst: hard to say, i've tried to put it to lower speed using /sys pwm files but when i've set it to 1% it was still running faster than i.e. when I use ubuntu livecd
08:05 vnd: i was afraid to set some higher value in there
08:05 vnd: afair it was set to 40% in pwm files
08:07 vnd: i use gentoo system, hardened sources
08:08 vnd: i've tried to compile the nouveau module into the kernel and to make it a module, in both of the cases the fan is running too fast
08:08 vnd: any guess what could I check/modify/correct?
08:17 vnd: anyone?
10:05 vnd: anyone? for those who have joined: i have a problem with fan, it works too fast - gentoo hardened-sources, nouveau module, geforce gt 730
10:06 vnd: setting pwn in /sys manually doesn't seem to work - even on 1% of speed it works too fast
10:18 vnd: mupuf: ^
10:21 pmoreau: vnd: Is it a regression or was it always the case?
10:22 vnd: what do you mean by regression? i've bought this card a few days ago so it's quite new setup for me, anyway I haven't had such a problems never before
10:22 pmoreau: You should probably open a bug report and attach a copy of you vbios.
10:22 pmoreau: Oh, ok :D
10:23 pmoreau: I couldn't guess you just bought the card :)
10:23 pmoreau: s/you vbios/your vbios
10:27 vnd: oh, i thought there's some faster way :) but ok, i'll try to open a new bug report
10:28 pmoreau: Well, there might be if there's someone who knows how it works present ;)
10:58 mupuf: vnd:
10:58 mupuf: hey
10:58 mupuf: can you please provide me with your kernel logs?
10:58 mupuf: and vbios too?
10:59 mupuf: what kernel version do you use? I added support for those not so long ago
11:00 mupuf: please write a bug report
11:00 mupuf: with all this information please
13:31 effractur: mm i am still having the issues with nouveau
13:31 effractur: but when i attach a external display
13:31 effractur: it works
13:31 effractur: so is there a way to create a EDID
13:33 RSpliet: there is a kernel param, somewhere, to load an edid from a file
13:33 RSpliet: during boot
13:34 RSpliet: but... don't ask me where it's hidden
13:35 effractur: yes i did thest that
13:35 effractur: but taht did not work
13:35 RSpliet: as for actually creating the EDID... there's a couple of basic EDID files floating around for various resolutions, big chance you can just download one
13:35 effractur: so is there a way to read the resolution ?
13:35 RSpliet: read a resolution from where?
13:36 effractur: the driver
13:36 effractur: the nvdiafb works
13:36 RSpliet: you can use xrandr for that
13:36 effractur: so i want to query the resoluton
13:36 effractur: with no x11
13:36 RSpliet: oh, hmm...
13:37 tizbac: is there any mmiotrace with nvc0 and directx from the windows driver?
13:37 RSpliet: tizbac: there's this slight problem of not having mmiotrace in Windows
13:38 tizbac: i've read about being possible to do mmiotrace using PCI-e passthrough
13:38 RSpliet: because, trust me, mmiotrace is a glorious hack
13:38 RSpliet: hmm... not sure about that
13:39 RSpliet: effractur: something tells me you're not just interested in the resolution, but rather the full modeline
13:42 RSpliet: not the expert on this, but my guess is that nvidiafb just created a bog standard VGA mode for 1024x768
13:42 effractur: isee it does a 640x480
13:43 pmoreau: tizbac: if you run Windows in a vm, under Linux, and have PCI-e passthrough (or whatever the technology is called), you could the Windows blob.
13:43 pmoreau: hakzsam: -^
13:44 RSpliet: effractur: really? yuck... tried feeding a 640x480 EDID into nouveau?
13:45 effractur: RSpliet: no not yet
13:45 effractur: there is no default edid for
13:45 effractur: so i have to create one
13:49 hakzsam: tizbac, you need VT-d with intel (don't remember the equivalent for AMD) and qemu-kvm
13:54 RSpliet: effractur: just modify the example file (like https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/800x600.S?id=refs/tags/v3.19-rc5 ) with a mode generated by cvt
13:55 RSpliet: see https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/HOWTO.txt?id=refs/tags/v3.19-rc5
13:58 effractur: mm and the offsets?
13:58 effractur: how to i know
13:58 effractur: them
14:01 effractur: mm make: *** [1024x768.bin.ihex] Error 127
14:09 effractur: mm is there a way to create a edid from a modline?
14:10 mlankhorst: it's annoying anyway..
14:10 mlankhorst: I've spent some time creating a non-standard mode but I had a valid edid to start with
14:13 effractur: powergentoo ~ # cat /sys/devices/virtual/graphics/fb0/modes
14:13 effractur: U:1024x768p-116
14:14 effractur: is that usefull info?
14:14 mlankhorst: no :P
14:19 effractur: because with nouveau it is wrong
14:19 effractur: there it is U:720x576p-0