01:11Maxdamantus: Hmm .. got a computer at work with a "NVIDIA Corporation GM107GL [Quadro K2200] (rev a2)" .. Xorg seems to sometimes freeze and go to 100% CPU as the kernel gets stuck in nouveau_dma_wait .. rxvt-unicode consistently produces screen corruption (unless it's run inside Xephyr—other programs I've run (Firefox, Chromium) don't).
01:12Maxdamantus: I think the message `nouveau E[ PFIFO][0000:01:00.0] CHSW_ERROR 0x00000001` is usually spammed in response to problems other than that visual corruption.
01:12Maxdamantus: and the corruption happens using Xorg with only fbdev (no fbdevhw or nouveau in X)
01:13Maxdamantus: happens there as well as with nouveau/fbdevhw
01:14Maxdamantus:wishes the CPU had integrated graphics :(
01:17Maxdamantus: also seem to be unable to use two 1920x1080 monitors unless they're configured to be the same .. I think the same lockup occurs as it tries to switch.
07:11imirkin: Maxdamantus: i guess our context switching is still a little broken on maxwell. you can try using the blob ctxsw firmware.
07:53pq: imirkin, ok, thanks. I have to say I'm fairly uninterested in looking into why closed source programs don't work, but this particular program does not need any specific hardware (Rift not necessary), and the dependencies are minor. The download is <100 MB. Should I open a bug report nevertheless?
07:53pq: it's not like I'm ever going to be able to run that program well on this machine with nouveau, it'll probably never reach the needed framerate.
07:55imirkin: pq: the issue is probably the case on the whole nv50 family, and i doubt i'll ever figure out why without nvidia's help
09:14hargut: I'm trying to use VDPAU with nouveau & GT218. It seems that vdpauinfo finds the decoders, but the performance is very poor. Is VDPAU supported with the GT218 & nouveau?
09:15imirkin_: well, since you got it working, it's clearly supported :p
09:15imirkin_: you could try increasing clock speeds
09:15imirkin_: (boot with nouveau.pstate=1, there should be a pstate file you can echo things into)
09:17hargut: imirkin: It looks like it is, but the processor performance is extremely high compared to the nvidia driver. According to http://nouveau.freedesktop.org/wiki/VideoAcceleration/ it should be in Group VP4.0 which seems to have support for many/all codecs.
09:19hargut: imirkin_: Do you have some reference/link for handling the pstates/clocks?
09:19martm: hargut: but still do what imirkin said, it changes the clock frequencies
09:19imirkin_: boot with nouveau.pstate=1 in the kernel cmdline
09:20hargut: martm: imirkin_: Is there something else required, or only booting with that parameter?
09:20imirkin_: hargut: once you've booted with that, we can go from there.
09:20hargut: imirkin_: Machine will be up in a second.
09:21hargut: [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.0.0-2-amd64 root=UUID=5c51d043-ff7e-4453-bbd3-c36190302576 ro nouveau.modeset=1 nouveau.pstate=1 quiet splash
09:21imirkin_: cool. so now, pastebin the contents of /sys/class/drm/card0/device/pstate
09:21hargut: root@multi-player:/sys/class/drm/card0/device# cat pstate
09:21hargut: 07: core 405 MHz shader 810 MHz memory 324 MHz
09:21hargut: 0f: core 520 MHz shader 1230 MHz memory 600 MHz
09:21hargut: AC: core 405 MHz shader 810 MHz memory 405 MHz
09:22imirkin_: you have 2 pstates... you can switch between them by echoing '0f' or '07' into that file
09:22imirkin_: note that this is a bit experimental
09:22imirkin_: aka might hang your gpu
09:22hargut: AC: is the active one?
09:22specing: ml|: apparently it would be best to avoid maxwell as it requires blobs
09:22imirkin_: AC = current setting (sort of)
09:22hargut: echo 0f > /sys/class/drm/card0/device/pstate
09:23imirkin_: specing: GM10x doesn't require signed things
09:23imirkin_: hargut: yes
09:23hargut: root@multi-player:/sys/class/drm/card0/device# cat pstate
09:23hargut: 07: core 405 MHz shader 810 MHz memory 324 MHz
09:23hargut: 0f: core 520 MHz shader 1230 MHz memory 600 MHz AC DC *
09:23hargut: AC: core 520 MHz shader 1240 MHz memory 597 MHz
09:23imirkin_: please avoid pasting more than 3 lines into irc
09:23imirkin_: use pastebin for larger pastes
09:23hargut: Ok, clear. I'll test again.
09:23hargut: Thanks so far.
09:23imirkin_: anyways, your gpu should now be running at the higher speed
09:29hargut: imirkin_: It seems to be a bit better, but compared to the speed of the proprietary nvidia driver it's very slow. CPU is up to 80-100% at tasks where the proprietary driver had only <10% CPU load.
09:29imirkin_: hargut: that's very odd
09:30imirkin_: hargut: i suspect some sort of issue in your configuration... have you tried using mplayer as suggested on that wiki page?
09:30imirkin_: (not mplayer2, not mpv, not anything other than 'mplayer')
09:30hargut: imirkin_: Tried kodi & vdr softhddevice, both are up high with the CPU performance.
09:30imirkin_: yeah kodi never worked well
09:31hargut: And kodi likes to crash with the nouveau vdpau
09:31imirkin_: please try mplayer :)
09:31hargut: Let me see. :)
09:31imirkin_: the big difference i've found between mplayer and anything else, is that mplayer works 100% of the time, while everything else tops out at 99%
09:31imirkin_: (but often much lower)
09:34martm: did you guys successfully add new cards to the list of "capable of to be reclocked"?
09:34Karlton: I never had mpv or mplayer above 20% cpu usage using software, but then I never tried playing something that was 4k resolution
09:36Karlton: and mpv seems to handle threading better
09:36imirkin_: everything does *something* better than mplayer
09:37imirkin_: however mplayer is the only thing that actually works all the time :)
09:37imirkin_: mplayer's got tons of issues too. but it does one thing reliably -- play videos.
09:38imirkin_: although who knows, perhaps they've upstreamed enough of their ffmpeg changes
09:42martm: imo looks like a progress indeed too, nouveau has been in good hands and calim whish was for granted that new devs come into active development, imirkin_ came imo, though i am not quite sure if he threw a line here and there before calim was concerned about new devs
09:43martm: i said like never ever , not possible that newcomers hit the scenes, but sounds good today regardless
09:46hargut: imirkin: It's a bit better with mplayer, but still it will not be really useable for the required tasks.
09:47hargut: imirkin: mplayer tops out at approx 60% CPU on full HD videos.
09:48imirkin_: hargut: can you pastebin the output of mplayer (up to the spinner)
09:49hargut: Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
09:49imirkin_: heh, that's not vdpau
09:49imirkin_: you didn't follow the instructions in the wiki
09:49hargut: imirkin_: Same video, but on a different machine, with a radeon card. ;)
09:50imirkin_: not sure what you're trying to say
09:50imirkin_: but if you don't provide the things i ask for, i can't really help
09:51hargut: imirkin_: Maybe it's worth stating that I've a very low-powered CPU in that system. It's a http://www.msi.com/product/mb/C847MS-E33.html#hero-specification with Intel® Celeron 847/ 1.1 GHz/ Dual-Core.
09:51martm: hargut: i bet imirkin_ asked for the mplayer output from your nvidia machine, heheee
09:51imirkin_: well, on my (fairly high-powered) system, vdpau h264 takes about 5% of cpu time
09:51hargut: imirkin_: You asked if it was h264, I didn't know that so I just fired up mplayer on this machine to check for the codec. ;)
09:51imirkin_: i doubt that celeron is 12x slower
09:52hargut: Give me a second, I'll join in from the other machine. Will make it easier.
09:52imirkin_: you can ssh into it
09:52imirkin_: and do DISPLAY=:0 to make stuff appear locally to that machine
09:56hargut_: Checked the wiki, and started mplayer accordingly. Interesing enough mplayer has now low cpu usage, but konsole & Xorg are up.
09:57imirkin_: oh, that's expected... turn off the mplayer spinner or just hide the console
09:57imirkin_: mplayer -quiet iirc
09:57hargut_: mplayer is at approx. 10%, the terminal running top is approx. 40%.
09:58imirkin_: sounds like everything is working fine then. just run mplayer with -quiet and you should be fine.
09:59imirkin_: if power/heat is a concern, drop back down to the lower power state
10:02hargut: imirkin_: mplayer worked fine, but the load of Xorg was extremely high. And then the GPU hang.
10:04martm: hmm, just couple of ideas, but i don't even try to make sense, well which 2d acceleration method might your chip use?
10:09Karlton: hargut: < imirkin_> sounds like everything is working fine then. just run mplayer with -quiet and you should be fine.
10:10hargut: Karlton: The GPU hang after starting mplayer with -quiet
10:10hargut: As well, the Xorg process took up to 90% CPU while mplayer was playing -quiet
10:11martm: well he said that before, that those states could hang a gpu, but anyways, lower it just a little bit or change 2d accel method
10:11martm: which could be possible on gt218
10:11hargut: martm: How to find out which 2d accel method is used?
10:11martm: hargut: well somewhere in xorg.d catalogue
10:11martm: folder pardon
10:11martm: which distro?
10:12hargut: martm: debian sid xorg.d is quite empty, only turned off composite
10:12hargut: I'll have a look in /usr/share/X11/xorg.conf.d, as X loads that according to the logfile.
10:13martm: hargut: well do some kind of a config in that dir, after checking the log file, and change the accel, i belive two possible methods
10:13martm: EXA or glamor
10:13hargut: martm: I'll try that
10:26hargut_: martm, I tried EXA first, which didn't give an improvment. Now loaded glamor, but mplayer is strangely looking for "libvdpau_nvidia.so: cannot open shared object file: No such file or directory", same as vdpauinfo
10:26hargut_: $ cat /var/log/Xorg.0.log | grep -i accel
10:26hargut_: (**) NOUVEAU(0): Option "AccelMethod" "glamor"
10:26hargut_: is what the Xserver gives.
10:26hargut_: The Xorg process is now relaxed in terms of cpu usage. (2-5%)
10:27martm: allrightly, hmm..i do not know why this library is not found really
10:28hargut_: I guess it should be libvdpau_nouveau instead.
10:28martm: i think you should wait for imirkin coming back, with my logics i do not understand how that is possible
10:29RSpliet: I wouldn't be surprised if mplayer just throws a bunch of library names at the vdpau subsystem to see which sticks
10:29martm: aaah yeah right , ok
10:30RSpliet: if you want hardware acceleration for nouveau video decoding, make sure to extract the right firmware files from the official driver
10:30hargut_: grep -i vdpau /var/log/Xorg.0.log, gives no output with the glamor accel method. Is that ok?
10:30RSpliet: I don't think X.org uses vdpau directly
10:30martm: dunno anything about it really, i have no hw
10:30RSpliet: anyway, make sure you have the right libs
10:31RSpliet: which I think include libxv and the nouveau vdpau driver
10:31RSpliet: I'm pretty sure there's a manual on the wiki somewhere
10:32hargut_: RSpliet, It worked just two minutes ago, with Xserver configured for AccelMethod EXA, changed to glamor mplayer looks vor libvdpau_nvidia, which is not there.
10:32hargut_: /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nouveau.so & libvdpau_nouveau.so.1.0 are available.
10:33RSpliet: oh sorry... hmm... I don't suppose libvdpau_nouveau requires EXA to work, does it?
10:33RSpliet: it's pretty much to be expected that glamor fails though
10:34RSpliet: on my system it seems to link to libxcb-dri2.so.0 and libdrm_nouveau.so.2 - a strong indication to me that it requires EXA
10:34RSpliet: well, no wait
10:34RSpliet: that's not the dri module
10:36RSpliet: the first module though is a hint to me... Imirkin, help me out here :-P
10:37RSpliet: and while I'm at it, why the heck would ldd /usr/lib64/vdpau/libvdpau_nouveau.so.1 link to libdrm_radeon.so.1? :-D
10:37martm: unfornently i do not understand what is going on, i head off to get couple of more beers
10:37RSpliet: I'll do the same in a couple of minutes
10:39hargut_: glx-alternative-mesa <- this could be also the crux. Let's see if it helps. Maybe libgl was wrong linked.
10:41hargut_: RSpliet, same here, also linked against libdrm_radeon.so.1
12:57imirkin_: skeggsb: any comment on my gm107 mesa change to reuse more of the nvc0 lowering pass?
12:57imirkin_: skeggsb: http://patchwork.freedesktop.org/patch/55422/
13:55imirkin_: wow, just checked glxspheres speed... on my GK208, moving from 2.5GT/s to 8GT/s, 204 -> 331 Mpixels/s
13:59imirkin_: still shy of the haswell which gets 350 =/
14:14hakzsam: nice :)
14:29imirkin_: but it's also going over prime, so i assume some of the slowdown is from that
14:42imirkin_: skeggsb: why not push the tiled gart thing for maxwell? seems like that should be necessary for desktop too
14:45imirkin_: skeggsb: and also probably your cursor patch should make it in there...
15:20imirkin_: if somebody could test unigine heaven on kepler or maxwell that'd be great. it totally kills nouveau for me on my GK208 but i suspect that's due to the dri3 boogeyman.
15:57tobijk: imirkin_: what ever happend to heaven, it does not work on nouveau or intel
15:57imirkin_: tobijk: huh?
15:57imirkin_: tobijk: are you also running it via prime?
15:58tobijk: you wanted it to be tested :> neither card does run heaven for me right now
15:58tobijk: intel does not obviously
15:58imirkin_: i didn't actually cehck intel
16:00tobijk: mh maybe this: http://cgit.freedesktop.org/mesa/mesa/commit/?id=5ead448719f39d27bfbf4cabf138324dfee34a4f
16:01imirkin_: you need to copy in a new drirc
16:01imirkin_: but perhaps that causes it to break on intel now
16:02tobijk: a new drirc? with something added?
16:02imirkin_: heh, yeah, intel is all black textures
16:03imirkin_: aha, looks like intel is broken with blend func
16:04imirkin_: i'll report that
16:06tobijk: pff i is just the window mode of heaven which borks my xserver ~_~
16:09tobijk: imirkin_: ok that sorted out nouveau looks fine
16:10imirkin_: disable_blend_func_extended=true for intel
16:10imirkin_: in the env
16:13tobijk: still black
16:13tobijk: anyway nouveau is fine :)
16:14imirkin_: well, that worked for me
16:14imirkin_: (for intel)
16:14imirkin_: ok cool. and this is with tess right?
16:15tobijk: heh typo in my drirc, yeah that helps
16:20imirkin_: tobijk: can you confirm that you tested tess with heaven 4 on a kepler and it all worked fine?
16:21tobijk: oh with tess, lets recheck if that is enabled
16:22imirkin_: tobijk: make sure you have a moderately recent checkout (past 48h or so) since i've pushed various fixes
16:22imirkin_: esp for kepler
16:22tobijk: could haven known that :/
16:22imirkin_: i guess 4 days. heh.
16:23tobijk: damn low framerate, but yeah with tess "extreme" it is all fine
16:23imirkin_: increase the GT/s of your card ;)
16:24imirkin_: nvapeek 8c080
16:24tobijk: ok lets see waht bot does
16:27tobijk: yeah up 2 -> 15 fps
16:27imirkin_: cool :)
16:27imirkin_: my hsw gets me 20fps, but no tess
16:28imirkin_: i suspect tess would slow it down
16:28imirkin_: what's the slowdown on nouveau? you can press F3 to turn off tess
16:28imirkin_: (and that's 20fps at 1024x768)
16:30tobijk: yeah well 30fps -> 15 fps on 800x600
16:32tobijk: the link reset when nouveau goes to sleep goes on my nerves :(
16:32tobijk: is karolherbs doing something with pcie reclocking btw? :)
16:57imirkin_: i think he's waiting on skeggsb to publish a branch that he can base new work off of
16:58imirkin_: ok, so all we need is someone to test heaven on maxwell now... see how badly i messed up tess on there
17:02tobijk: imirkin_: ah you feared for breakage on kepler, now you fear on maxwell, it's all fine :D
17:04imirkin_: tobijk: well, i had a pretty good idea that kepler was fine
17:04imirkin_: since all the piglits passed on my GK208
17:04imirkin_: [well, almost all]
17:04imirkin_: so it was just a question of encoding
17:04imirkin_: but i don't think i've run any tess stuff on maxwell in *quite* a while
17:08imirkin_: urghhhh... i think MemoryOpt will happily merge accesses between diff vertices... gr.
17:09imirkin_: where's calim so i can yell at him
17:11tobijk: yell at me, ask him questions when you need it :P
17:12imirkin_: if only it worked like that
21:53imirkin: mupuf: i think reator's having issues =/ the power led flickered, and i can't ssh in now...
21:56imirkin: hrm... looks like the BAR instruction is actively hurtful to TCS shaders
21:57imirkin: unrelatedly, would anyone find it helpful if i documented the nvidia fermi+ isa in envytools?
22:23imirkin: ugh... the proper way to reenable patch loads/stores in memoryopt is to create a new register file
22:24imirkin: but on the bright side, memoryopt *does* properly account for rel0/rel1 on fetches, so i was wrong earlier