02:03mlankhorst: it's the perfect click bait >:D
02:05karolherbst: mlankhorst: what is?
02:06mlankhorst: 'more to come' without saying anything
02:08karolherbst: I am sure there will come more for the gk20a
02:09karolherbst: or did you mean something else?
02:09mlankhorst: well I wish there was more for the video encoding and decoding engines on the tegra :P
02:10karolherbst: pmoreau: by the way, does DRI3 offloading work for you?
02:11karolherbst: without actually touching the mux
02:11pmoreau: Not sure about DRI2, about offloading fails as Nouveau is not listed as being an "input"
02:12karolherbst: pmoreau: yeah, with DRI3 you don't need that
02:12karolherbst: xrandr is totaly unimportant
02:12karolherbst: basically you just load the nouveau kms module and then it just works
02:12pmoreau: How does it work then? Just with DRI_PRIME=1?
02:13karolherbst: I do like: modprobe nouveau; DRI_PRIME=1 glxinfo => magic
02:13pmoreau: I'll check, then. But I think I tried it and it was still using the main card
02:13karolherbst: pmoreau: it does look like this then: https://gist.github.com/karolherbst/db5b96bc6e7a822991bc :D
02:13karolherbst: ohhh mhh
02:14pmoreau: Except I don't have any Intel, but, yeah ;-)
02:14karolherbst: ohh right, how is DRI3 with nouveau anyway?
02:14karolherbst: the nouveau ddx has to support this kind of
02:15karolherbst: pmoreau: anyway, Prime is kind of unimportant for you, because you can do something better instead :D
02:15gnurou: I will just shut up next time :)
02:16karolherbst: gnurou: I am disappointed by him, because he didn't do the gddr5 benchmarks he promised :D
02:16pmoreau: karolherbst: The SLI thing? Well, it would first have to be implemented
02:17karolherbst: pmoreau: :)
02:17pmoreau: gnurou: I guess you meant that line as a hope from your side, rather than trying to hint at some future announcement
02:17pmoreau: karolherbst: Whereas DRI_PRIME is already there
02:17gnurou: I don't mean anything. I'm not even listening >_<
02:17karolherbst: pmoreau: yeah, but the SLI thing will give you more perf *cough*
02:18pmoreau: karolherbst: It's loading dri2. Is there a way to force it to dri3?
02:18karolherbst: gnurou: aha! so that basically means a lot of more awesmoness in the future
02:18pmoreau: Well, atm, not really given that there is no SLI support iirc.
02:18karolherbst: pmoreau: well for intel there is Option "DRI" "3"
02:18karolherbst: but I don't know if nouveau supports it
02:19pmoreau: Oh, I guess I'm not in the video group
02:20pmoreau: Hum.. I was
02:20karolherbst: you should be
02:20gnurou: karolherbst: well, if you like Tegra that is :/
02:21pmoreau: karolherbst: Why would I, if I didn't put myself in it?
02:22karolherbst: pmoreau: I don't know but my gentoo installation guide told me todo so, because it is important :D
02:22karolherbst: gnurou: not especially :D
02:23karolherbst: pmoreau: I think the nouveau ddx can't do dri3, so
02:23gnurou: karolherbst: don't get too excited then >_<
02:24karolherbst: gnurou: oh :( now I am sad
02:25karolherbst: gnurou: at least if nouveau devs would get the feeling, that asking nvidia about stuff is faster than REing it, that would help a lot already :p
02:25gnurou: karolherbst: asking is not completely futile, but even that part could be improved
02:26karolherbst: I know
02:26karolherbst: but there is some disappointment there
02:27gnurou: same here - it's a resource issue though
02:27karolherbst: gnurou: I mean that sometimes things are difficult because of contracts and IP and stuff, but it would be already nice to know, what nvidia can tell us about directly, and for what stuff it needs time
02:33nchauvet: gnurou, one question about the firmware listing in the nouveau module for gk20a, do you think there is a way to sort out if this is a dGPU for initramfs creation of a given "host only" image (compared to generic initramfs images ?)
02:34nchauvet: I mean, sorting that from userspace...
02:35gnurou: nchauvet: what do you mean by "sort out"?
02:36RSpliet: gnurou: usually "figure out" in this context :-P
02:37nchauvet: gnurou, I think that if the given hardware has a dGPU, then the nouveau kernel module doesn't need to be bundle into the initramfs because it would not handle kms
02:37gnurou: ah, so you want to exclude that fw when building an initramfs for a dGPU
02:38nchauvet: gnurou, yes, fw and nouveau.ko, then the initramfs becomes "host specific"
02:39RSpliet: nchauvet: there's a little caveat though. I recall on some laptops the dGPU is wired to an external monitor port, where the LVDS panel is hooked up to the iGPU
02:39gnurou: one way would be to not build support for Tegra GPUs when building on a desktop machine
02:39nchauvet: it does not handle the case of generic initramfs (so my patch is still needed unless some defered probe would be implemented for the fw loading )
02:39gnurou: that way the FW files would not be exported in nouveau.ko
02:41nchauvet: gnurou, sure, we already avoid to build TEGRA_124 on x86_64 ;)
02:42nchauvet: but there is a little corner case of pcie armv7 devices where kms support would be needed
02:42nchauvet: there is probably very few corner case here
02:42gnurou: yeah in that case I'm afraid you cannot presume anything
02:43nchauvet: even aarch64 should have pcie more often
02:53karolherbst: is there a way to print the current fps to stdout with gallium?
04:21karolherbst: fun times, wasteland 2 crashes :/
04:21karolherbst: works with intel
04:24karolherbst: can't reproduce it anymore, strange
06:28karolherbst: mupuf: we need to expose the current load through sysfs, don't we?
06:28karolherbst: debugfs is like root only :/
07:07RSpliet: karolherbst: so is pstate changes
07:07karolherbst: wait.... why can't I grep my C application output?
07:07karolherbst: RSpliet: but you can read the pstate interface as non root
07:08karolherbst: or do you have to be root for this?
07:08imirkin: all that stuff belongs in debugfs... regular users shouldn't have access to this
07:08karolherbst: imirkin: I already have patches :p but I was thinking maybe I should keep the sysfs stuff
07:09karolherbst: and put informative stuff there
07:09karolherbst: like the current load
07:09karolherbst: don't see why a user shouldn't be able to see this
07:09RSpliet: imirkin: well, tbh, in the final final final situation if would be nice if we can have some userspace tools display statistics
07:09imirkin: RSpliet: sure
07:09RSpliet: but we're about three finals away from that right now :-D
07:10RSpliet: karolherbst: if we are going to expose any such information, we should synchronise the method with other vendors imho
07:10karolherbst: RSpliet: intel tool is kind of broken :/
07:10RSpliet: probably end up with a "drm" API or the like
07:10karolherbst: intel_gpu_top can hang your gpu at any time :D
07:11RSpliet: what about intel_gpu_bottom?
07:11karolherbst: a drm API would be nice indeed
07:11karolherbst: hakzsam: how are the perf counters exposed to userspace?
07:11RSpliet: or sensors perhaps...
07:12karolherbst: RSpliet: no, sensor isn't the place for load
07:12karolherbst: just for sensors
07:12karolherbst: power consumption will go there
07:12RSpliet: for CPUs we have CPUfreq I reckon
07:12RSpliet: ... GPUfreq? :-P
07:12RSpliet: food for thought on the long term, but until we aim for perfection I'd say use debugfs
07:13karolherbst: RSpliet: do you want to run a benchmark observer application as root?
07:13hakzsam: karolherbst, which perf counters?
07:13imirkin: karolherbst: debugfs until this stuff is figured out.
07:14RSpliet: karolherbst: not daily, but when I'm developing I don't care
07:14karolherbst: I want to write a benchmark script/application to benchmark dynamic reclocks
07:14karolherbst: imirkin: k
07:14karolherbst: hakzsam: the stuff you are working on :p
07:14imirkin: karolherbst: sysfs or ioctl-based api when it is and we can figure out what the best way of exposing it is.
07:15hakzsam: karolherbst, they are still not exposed because nvif is still not merged :)
07:15karolherbst: hakzsam: okay
07:16karolherbst: but what is planned?
07:16imirkin: hakzsam: they're exposed. just no lib to access them.
07:16hakzsam: karolherbst, once ben has merged nvif to libdrm
07:17hakzsam: imirkin, so, not really exposed :)
08:02karlmag: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 650 Ti Boost] (rev a1)
08:04kubast2: nice gpu you hav ethere
08:05karlmag: difficult to get hold of too..
08:05karlmag: it's actually a demo card I got hold of.
08:05karlmag: but - looks to be working
08:05karlmag: just put it into a machine like 5 minutes ago
08:05karolherbst: karlmag: :D
08:05kubast2: 01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
08:05karolherbst: karlmag: and now you can test my pcie and gddr5 patches
08:05karolherbst: thanks in advance
08:06karlmag: karolherbst: hehehe ;-)
08:06karolherbst: ohh a Ti Boost
08:06kubast2: keppler master race
08:06karolherbst: I see voltage issues coming
08:06karlmag: I *could* mention I have a an amd card in that machine too though. And that is quite newer than this nvidia one.
08:06karolherbst: only 1.5 GFLOPS
08:06karolherbst: same as mine
08:07karlmag: not sure if I'll have both cards in the same machine though.
08:07karolherbst: karlmag: OpenCL!
08:07karlmag: but yeah, if time permits I might help with some testing here.
08:07karolherbst: just run all OpenCL stuff on the amd card and use the nvidia one for GL stuff
08:07karlmag: karolherbst: it might be a bit new so far... :-P
08:07karolherbst: maybe video decoding is also fun on the amd
08:08karlmag: https://www.asus.com/Graphics-Cards/STRIXR9390DC3OC8GD5GAMING/specifications/ this is the amd one
08:08kubast2: karolherbst my gtx 650 does h.264 4K encoding just fine
08:08kubast2: *on windows
08:08karlmag:'s been shopping a wee bit lately :-P
08:08imirkin: hopefully someone will come along interested in RE'ing nvenc
08:09karolherbst: kubast2: try that wiht nouveau and vdpau :)
08:09karolherbst: imirkin: not me :p
08:09karlmag: I guess my wish of X automagically configure across multiple cards is not a thing of quite yet :-P
08:09imirkin: karlmag: should work
08:10karolherbst: karlmag: delete xorg.conf first :p
08:10karlmag: which xofg.conf? :-P
08:10imirkin: karlmag: http://nouveau.freedesktop.org/wiki/Optimus/
08:10imirkin: karlmag: you're looking for "Using outputs on discrete GPU"
08:11karlmag: imirkin: well, that means configuring something ;-)
08:11kubast2: karolherbst hw video decoding works on nouveau
08:11imirkin: some DE's auto-configure it, others don't
08:11karolherbst: kubast2: yes?
08:11imirkin: kubast2: http://nouveau.freedesktop.org/wiki/VideoAcceleration/
08:11kubast2: well I guess it's better than nvidia linux properiaty driver on taht manner
08:11karolherbst: kubast2: try it out and see for yourself :p
08:12karolherbst: I had my fun with that and deicded to not touch it again :D
08:12karolherbst: quite disappointed that my CPU decoded a 4K video faster than my nvidia card :p
08:13karlmag: karolherbst: depends a bit on the cpu I would think?
08:13imirkin: karolherbst: did you check how blob did with it? might be a nouveau fail.
08:13karolherbst: imirkin: prop was fine
08:15karolherbst: imirkin: blob
08:15imirkin: we probably don't keep the pipeline properly filled
08:16kubast2: "Supports Hardware H264 Decoding false" What a lie from firefox xd
08:16karlmag:ponders putting the nvidia in a secondary workstation. Makes it easier to test stuff too then.
09:00karolherbst: karlmag: what the heck is "OC mode", for bragging?
09:03imirkin_: kubast2: i believe firefox only supports gstreamer, which in turn only supports libva
09:04kubast2: linux mint doesn't have lbva
09:04kubast2: so that explains a lot
09:04imirkin_: you could install the libva <-> vdpau adapter
09:04kubast2: E: Nie udało się odnaleźć pakietu libva
09:04kubast2: I need to install arch linux
09:05imirkin_: my polish is rusty... what does that mean?
09:05karolherbst: tere is vdpau-va-driver though
09:05kubast2: Unable to find libva packlage
09:05imirkin_: couldn't manage to ... package libva
09:05imirkin_: aha. find.
09:05imirkin_: would not have guessed that.
09:05karolherbst: but vdpau-va-driver looks like a _big_ hack :D
09:06kubast2: libva info: va_openDriver() returns 0
09:06kubast2: let me check ff now
09:06kubast2: Supports Hardware H264 Decoding false
09:06kubast2: VAProfileH264Baseline : VAEntrypointVLD
09:06kubast2: VAProfileH264Main : VAEntrypointVLD
09:06kubast2: VAProfileH264High : VAEntrypointVLD
09:07kubast2: yes I have restarted firefox
09:07kubast2: and the VAProfile is from vainfo[nvidia-355.11]
09:08imirkin_: kubast2: pastebin vainfo output?
09:09imirkin_: seems like something from the blob driver
09:09imirkin_: try... LIBVA_DRIVER=nouveau
09:10imirkin_: er wait, that's not it
09:10kubast2: it's loaded properiaty driver ,let me now try the open one
09:10karolherbst: imirkin_: that's the vdpau-va-driver
09:10imirkin_: export LIBVA_DRIVER_NAME=vdpau
09:11imirkin_: much better
09:12imirkin_: check with some application that you can actually use va?
09:12imirkin_: actually in hindsight, there's probably a symlink from nvidia_drv_video to vdpau_drv_video
09:12imirkin_: so it's the same as before =/
09:13imirkin_: but where did it get the nvidia name from... are you running on the blob?
09:13kubast2: currentlly yes
09:13imirkin_: ah, that explains it
09:13kubast2: I didn't tested the the nouveau one yet
09:14kubast2: vlc launches video just fine with vdpau acceleration on blob
09:14kubast2: firefox doesn't care
09:14kubast2: chromium doesn't care
09:15kubast2: now let me restart with nouveau
09:15imirkin_: the point was to use va, not vdpau, with some other app... oh well.
09:16kubast2: Supports Hardware H264 Decoding false
09:16kubast2: Vendor ID nouveau
09:17kubast2: well it seems like there's a simlink
09:17karolherbst: browsers usually use internal black/white lists for that
09:17kubast2: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so
09:17karolherbst: try to use the vdpau va backend in a non _bloated_ software :D
09:18kubast2: well that's vainfo output
09:18kubast2: on nouveau
09:18imirkin_: an application that actually uses va.
09:18kubast2: it won't work
09:18kubast2: on nouveau because blob is loaded
09:18kubast2: oh wait
09:18karolherbst: kubast2: doesn't matter currently :p
09:18imirkin_: i think i convinced mpv to use libva at one point
09:18karolherbst: vlc can to va
09:19kubast2: libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so
09:19kubast2: libva info: va_openDriver() returns -1
09:19kubast2: vaInitialize failed with error code -1 (unknown libva error),exit
09:19karolherbst: kubast2: yeah, there is no nouveau symlink for the vdpau driver
09:19imirkin_: kubast2: how about 'vdpauinfo'
09:19karolherbst: ohh wait, for willy there is
09:20kubast2: display: :0.0 screen: 0
09:20kubast2: Failed to open VDPAU backend libvdpau_nouveau.so: cannot open shared object file: No such file or directory
09:20kubast2: Error creating VDPAU device: 1
09:20karolherbst: kubast2: what distribution are you using?
09:20kubast2: linux mint 17.2 xfce4
09:20imirkin_: kubast2: ok, well until that works, you won't be getting hw video decoding accel with nouveau.
09:20karolherbst: yeah, they use an outdated ubuntu package
09:22karolherbst: allthough I don't know
09:23karolherbst: you can check in /usr/lib/x86_64-linux-gnu/dri/ for files like *_drv_video.so
09:24kubast2: ls /usr/lib/x86_64-linux-gnu/dri/
09:24karolherbst: kubast2: you can make a symlink from nouveau_drv_video.so to vdpau_drv_video.so
09:25karlmag: karolherbst: no idea :-P It came with the card (as far as I am concerned :-P )
09:25imirkin_: won't help
09:25imirkin_: the issue is that vdpau isn't installed.
09:26karolherbst: imirkin_: ohh yeah, I saw too late that the nouveau vdpau driver is missing :/
09:30karolherbst: kubast2: is there a package called mesa-vdpau-drivers for you?
09:31kubast2: and other onces
09:31kubast2: for utopic
09:31kubast2: and vivid
09:31karolherbst: is there somewhere a _good_ package search site for liux mint?
09:31kubast2: well I think there's not
09:31kubast2: it uses the same packages as ubuntu+older ones on their repo
09:31karolherbst: but I think mesa-vdpau-drivers is right
09:31karolherbst: just install the newest
09:32kubast2: this one was from ubuntu repo
09:33kubast2: well it returned some stuff
09:33kubast2: not supported all the way
09:34kubast2: perhaps this card only works with dxva
09:34karolherbst: kubast2: do you have a /usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nouveau.so file?
09:34karolherbst: try VDPAU_DRIVER=nouveau if so
09:35kubast2: same thing
09:37imirkin_: kubast2: you don't have the firwmare installed
09:37kubast2: firmware ?
09:37imirkin_: kubast2: all detailed on the page i sent you to
09:41karolherbst: I slowly begin to hate those stupid phones ... yeah because it is unsafe to draw 900mA from a USB-3 port :/
09:42karolherbst: mupuf: WIP https://gist.github.com/karolherbst/867958e003cd3b935de1
09:43kubast2: I'll move NVIDIA-Linux-x86_64-352.55 folder to NVIDIA-Linux-x86-340.32
09:43kubast2: to launch extract_firmware.py
09:44imirkin_: or you can follow the instructions
09:44kubast2: oh ok
09:46kubast2: either I'll use 340.32 just for the sake of something going wrong
09:46kubast2: or just modify the script to allow my version to work
09:48karolherbst: kubast2: the second part is much harder
09:49imirkin_: or follow the instructions on the VideoAcceleration page.
09:54kubast2: newest supported version from python2 script
09:55imirkin_: newest isn't always best. but it should work ok.
09:55imirkin_: 325.15 is best
09:55imirkin_: but wtvr
09:55karolherbst: 943fps @ 27.5W sounds much better than 952fps @ 29.3W :)
09:55karolherbst: imirkin_: why is 325.15 best?
09:55imirkin_: karolherbst: only 10% better
09:55karolherbst: imirkin_: with same perf, yes
09:56imirkin_: karolherbst: because the script also knows how to extract pgraph fw from it
09:56karolherbst: ahh k
09:56imirkin_: kubast2: much better
09:56kubast2: yeah Unknown PGRAPH archive order in this version.
09:56karolherbst: now some real tests
09:57karolherbst: will I do a heaven benchmark apitrace? :/
09:57karolherbst: sounds like a bit off an overkill
10:02kubast2: seems to be working
10:02kubast2: mplayer -vo vdpau -vc ffh264vdpau Double-Barreled\ Shotgun.-EY2lWmZN5TQ.mp4
10:03karolherbst: now you can test firefox again :D
10:03kubast2: seems 100% gpu decoded
10:03kubast2: 2% cpu usage
10:03karolherbst: kubast2: on which gpu?
10:03kubast2: gtx 650
10:03kubast2: Supports Hardware H264 Decoding false
10:03kubast2: firefox ^
10:04kubast2: Video Decode: Software only, hardware acceleration unavailable
10:04kubast2: chromium ^
10:04karolherbst: kubast2: you could use my pdaemon_counters branch and then read the actual gpu load
10:05kubast2: can you hand me git repo
10:05karolherbst: wait, I will make a good branch for ya
10:05karolherbst: with a lot of nice stuff
10:05kubast2: I think I'm still using the pcie test one
10:05kubast2: alongside with gddr5 patch
10:06karolherbst: kubast2: there is some more stuff in :p
10:07karolherbst: kubast2: git clone https://github.com/karolherbst/nouveau.git -b master_karol_stable --depth 1
10:07kubast2: cd drm?
10:08kubast2: make -j4
10:08kubast2: then I copy over .so file mv the old one to be .old
10:08karolherbst: after install you also have to regenerated your initramfs
10:09kubast2: LD [M] /home/kubast/nouveau/nouveau/drm/nouveau/nouveau.ko
10:09kubast2: ina sec
10:10kubast2: where to put .ko file /lib/
10:10pmoreau: kubast2: -^
10:11pmoreau: And if I were you, I would symlink it rather than copy it :-)
10:11kubast2: ls: cannot access /usr/lib/modules: No such file or directory
10:11kubast2: I think I used /lib/modules then
10:11pmoreau: Could be
10:12pmoreau: On Arch, /lib is a symlink to /usr/lib so...
10:14kubast2: ok initramfs updated
10:18kubast2: seems faster tbh
10:18kubast2: docky loaded almsot instantlly
10:18karolherbst: shouldn't be :D
10:18karolherbst: go to /sys/kernel/debug/dri/0
10:19karolherbst: there you have two nice files: pstate and current_load
10:19kubast2: yeah they are here
10:19karolherbst: while watching video the video counter should go up
10:19karolherbst: these are values between 0 and 255
10:19kubast2: core: 0
10:19kubast2: mem: 100
10:19kubast2: video: 0
10:19kubast2: pcie: 0
10:20kubast2: Kuba-Pc 0 # cat current_load
10:20kubast2: core: 37
10:20kubast2: mem: 122
10:20kubast2: video: 42
10:20kubast2: pcie: 0
10:20kubast2: it works
10:20karolherbst: please don't paste it here direclty :p
10:21karolherbst: high memory load though :/
10:21kubast2: the idle is 100
10:21kubast2: I think the value for it is 100 to 255
10:21karolherbst: do you have envytools installed?
10:22karolherbst: nvapeek 0x10a500 0x50
10:22kubast2: *I have them compiled
10:24karolherbst: nvapoke 0x10a534 0x80
10:24karolherbst: and then peek again
10:25kubast2: well I have mem: 3 on cat current_load now
10:25karolherbst: then this 0x1000 counter doesn't work everywhere
10:25karolherbst: or maybe it does work and it is normal on dedicated gpus
10:26kubast2: well now my mem load is 11 and 10 on video decoding
10:26karolherbst: try some serious stuff
10:26karolherbst: like 4k decoding
10:28kubast2: getting 5 minute 4k video from yt
10:28kubast2: 266 mp4 3840x2160 DASH video 22317k , h264, 30fps, video only,
10:28karolherbst: seems good
10:33kubast2: launched 4k
10:33kubast2: video works
10:34kubast2: but some debug/leak hapend ?
10:34kubast2: video: 255
10:34kubast2: mem: 35
10:35kubast2: core: 129 pcie: 4
10:35imirkin_: that happens when there's a pushbuf fail
10:41karolherbst: kubast2: does it happens even if you retry it?
10:41kubast2: you mean this nouveau:
10:41kubast2: it starts normally
10:42karolherbst: here are some CC licensed 4K videos by the way: http://www.elementaltechnologies.com/resources/4k-test-sequences
10:42kubast2: well the video is a bit glitchy
10:42karolherbst: I used the cactus one on my gpu
10:42karolherbst: kubast2: try highest pstate
10:42kubast2: but no errors
10:43karolherbst: it should be better then
10:43karolherbst: maybe not much, but at least a little
10:43karolherbst: and if your card crashes, we might get it fixed someday :p
10:44kubast2: well thx
10:44karolherbst: but it shouldn't
10:44karolherbst: maybe you get some screen corruption, but well
10:44kubast2: that happens xD
10:44kubast2: echo 0f > pstate
10:44karolherbst: which pstates do you have?
10:44karolherbst: 07 0a 0f?
10:44karolherbst: or also 0d
10:44kubast2: 07 0a 0f AC
10:45karolherbst: AC is current
10:45karolherbst: go to 0a
10:45kubast2: well I just went for 0f
10:45karolherbst: yeah, no problem
10:45karolherbst: 0f is gddr5 high clock
10:45karolherbst: you see that because of the high memory clock
10:45kubast2: well it seems fast
10:45karolherbst: it should be around 6000 or something
10:45kubast2: 5000 yeah
10:45kubast2: video: 255
10:46kubast2: mine is 5000 mhz
10:46karolherbst: this is a 650 Ti Boost right?
10:46kubast2: gtx 650
10:46karolherbst: ohhhh okay
10:46karolherbst: karlmag: you was it with the ti boost :D
10:46karolherbst: no, then it is fine
10:47karolherbst: kubast2: so video seems faster, but still not fast enough?
10:47karolherbst: or is it good enough
10:47kubast2: well it goes fine
10:47kubast2: but sometimes
10:47kubast2: it looks like one or two frames
10:47kubast2: aren't rendering
10:47karolherbst: kubast2: regarding 0f: just try a few times, it should usually work
10:48 < AndChat|341361> It seems to be pushing vidro decoder to the limits
10:49 < AndChat|341361> I would say video works just as it was with 0a
10:50karolherbst: 0f crashed?
10:50karolherbst: ohh other account
10:50kubast2: but I wanted to see how it would work
10:50kubast2: if I wouldn't alt_tab
10:50kubast2: beetween apps
10:50imirkin_: kubast2: there are some outstanding issues with h264 decoding somewhere
10:50imirkin_: only some videos are affected
10:51kubast2: well it's dash video so
10:51kubast2: let me test the cc 4k videos
10:51imirkin_: i spent a long time trying to work out what it was with VP2... unsuccessfully
10:51imirkin_: never investigated it on VP3
10:55karolherbst: kubast2: how many tries do you need until 0f works?
10:55kubast2: karolherbst: is it the same karol_stable with gddr5 and pcie patch that I tested?
10:56kubast2: this one is really glitchy http://hwcdn.net/j9t9v3v5/cds/Mobile_H264.mp4
10:56kubast2: karolherbst: once
10:56karolherbst: kubast2: yeah, just with some fixes and other stuff
10:57karolherbst: kubast2: okay, so it usually works, but sometimes the screen glitches
10:58kubast2: karolherbst: it works fine ,just video decoding glitches[of the CC 4k videos]
10:58karolherbst: and on 0a it doesn't glitch?
10:58kubast2: let me see
10:59kubast2: glitches just as much
10:59kubast2: I guess the CC 4k video is pushing my gpu to even bigger limits
10:59karolherbst: I want that http://1.f.ix.de/scale/geometry/600/q75/imgs/18/1/6/0/6/3/3/9/digirule-1d09e76c198dfdba.jpeg :O
10:59karolherbst: kubast2: :)
11:00karolherbst: use the ProRes file
11:00karolherbst: much fun in there
11:00kubast2: I can't download it xD
11:00kubast2: thx firefox
11:01kubast2: *firefox read mime type and wanted to play the video
11:02kubast2: video couldn't be processed by firefox
11:02kubast2: so I couldn't right click+download it
11:02kubast2: because it's "damaged"
11:02kubast2: chromium downloads the file
11:02kubast2: 5 minutes left
11:18kubast2: got the video
11:35mupuf: free time!!!! YEEEAAAAAHHHH RRRRIIIIGGGHHHTTT!
11:35karolherbst: mupuf: :)
11:35mupuf: The finnish class was insane, so good that I reviewed so much this past 2 days, I would have died otherwise!
11:35mupuf: But hey, back to working on the pcie stuff ... after lunch!
11:35mupuf: err, dinner
11:36karolherbst: I hacked up a shell script to benchmark dynamic reclocking :)
11:36karolherbst: with apitraces
11:37mupuf: oh, super cool!
11:38karolherbst: I should stop using my intel card for recording them :/
11:38karolherbst: some bechmarks really slow down my entire desktop
11:41karolherbst: mupuf: you can't imagine how painfull it is to manage two background daemons in bash :D
11:43karolherbst: mupuf: that's the script https://gist.github.com/karolherbst/f621c241e7f352db19eb
11:43mupuf: right, collecting metrics in // is hard
11:45karolherbst: I had a lot of fun with your userspace power sensor tool
11:45karolherbst: the output got buffered
11:45karolherbst: and I was wondering, mhh why don't | cat get anything
11:48karlmag: "| cat"? That sounds redundant? :-P
11:49kubast2: cat pstate | cat
11:50kubast2: when one cat isn't enough ,you need to double the verbosity
11:52karlmag: And in bad cases, call in the cat lady? :-P
11:52kubast2: well there's one thing one should never do
11:52kubast2: alias dog = cat
11:52kubast2: it's well known that kernel panics
11:54kubast2: *ok I'll stop with unfunny jokes xd
11:58karlmag: so.. if I where to test something on nouveau, what would I need to do? I have an hour or two I can do some stuff like that now.
11:59kubast2: well first you will git clone the repo I think
11:59karolherbst: but it is nice to know, that my nvidia card with nouveau is actually faster then my intel card :)
11:59karolherbst: others have the problem, that their nvidia card with the blob isn't even faster at all :p
11:59karolherbst: karlmag: test my branch
11:59karolherbst: karlmag: git clone https://github.com/karolherbst/nouveau.git -b master_karol_stable --depth 1
12:01kubast2: karolherbst: the blob is slow to load the xfce4 wallpaper right after start up
12:02karlmag: any assumption that thing does?
12:02karlmag: versions of stuff, etc?
12:02pmoreau: Can't I just rerun configure on Mesa with a new set of flags to have them taken into account?
12:02karolherbst: pmoreau: nope :P
12:02karolherbst: make clean needed
12:02karolherbst: somehow the header files aren't tracked
12:02karolherbst: so make doesn't see the changes
12:03karolherbst: and doesn't recompiled everything needed
12:03pmoreau: Well, even configure in the summary message didn't took them into account
12:03pmoreau: Or at least not the one I was trying to add (--enable-glx0
12:04pmoreau: Oh: "configure: WARNING: Neither DRI nor Xlib-GLX enabled, disabling GLX"
12:05karolherbst: mupuf: sometimes I get values in the counters greater then the ticks (maybe because of latency between reads), I think I should read the ticks last then :/
12:06karolherbst: pixmark_piano: 15.9 fps @ 44W (stock), 15.8 fps @ 40W (clock gates + dyn reclock)
12:06karlmag: karolherbst: didn't compile
12:06karolherbst: still only 10%, but still
12:06karolherbst: karlmag: which kernel do you have?
12:07karolherbst: soc/tegra/pmc.h not found?
12:07karolherbst: remove the include there
12:12mupuf: karolherbst: yes, that's what I do
12:13karolherbst: I know
12:13karolherbst: I do it too on reator :o
12:13karolherbst: gpu crashed again
12:14karolherbst: mupuf: I am now at duty + 6
12:14karolherbst: maybe it is unrelated though
12:15mupuf: yes, it is!
12:16karolherbst: but it seems to be nearly only furmark
12:16karolherbst: this benchmark really pushes the card
12:19karolherbst: 53W with furmark power consumption here :/
12:19karolherbst: and that's only the gpu
12:19mupuf: still a far cry from 90W :D
12:20karolherbst: I could decode and encode videos in the background
12:20mupuf: ah ah
12:20karolherbst: it is still awesome how the load matters for power consumption
12:22mupuf: you should read up on dynamic and static power consumption
12:22karolherbst: yeah, I get usually up to 10% less power consumption
12:22karolherbst: mhh okay .D
12:23mupuf: on low-power devices, the power consumption is given as frequency * constant
12:23mupuf: of course, that's when working completely
12:23karolherbst: I was more refering to same clock, with load
12:23mupuf: and the more complex the hw is, the harder it is to predict because it is hard to predict which block is going to be active
12:24karolherbst: ohhh right
12:24karolherbst: clock gating
12:24karolherbst: I enabled this
12:24mupuf: try disabling it, you'll still see a scaling
12:24karolherbst: on the same freq?
12:24mupuf: some parts of the gpu are clock gated and power gated automatically, so it is hard to know what is going on
12:25karolherbst: ohh okay
12:25mupuf: you know what, I am going to give you a page of my thesis to read
12:25karolherbst: you already did
12:25karlmag: karolherbst: http://pastebin.com/gWq1xfty
12:25karolherbst: karlmag: :O
12:26karlmag: I'm really n00b at this :-P
12:26karolherbst: karlmag: it should be there
12:27mupuf: karolherbst: http://phd.mupuf.org/files/these_martin.pdf page 103 of the pdf, read the section 5.2.3 on transistors
12:27karolherbst: karlmag: you have to cd into drm
12:27karolherbst: but still this compile error shouldn't happen
12:28karlmag: that went quite a bit smoother, yeah..
12:29mupuf: well, the whole chapter would be beneficial to you I would say. And you can have a look at the power usage vs temperature too, it is fun
12:31karolherbst: mupuf: maybe the pdf is broken, but I don't see a 5.2.3 :(
12:32karlmag: karolherbst: ok.. installed, rebooted, then what?
12:32karolherbst: karlmag: do stuff
12:32karlmag: what am I looking for?
12:32karolherbst: go to highest pstate
12:32mupuf: karolherbst: page 79 is written on the page, but it page 103 of the pdf
12:33karolherbst: mupuf: I know, but the title isn't there
12:33mupuf: what the heck
12:33karolherbst: there is 5.2.2 clock
12:33karolherbst: and then 5.2.4 storing data...
12:34karolherbst: I think you missed something in tex
12:34mupuf: what the heck? It is definitely in the pdf
12:34mupuf: I am looking at it right now
12:34karolherbst: even the toc gives the same page number for 5.2.2 and 5.2.3
12:34mupuf: and I did not regenerate it
12:34mupuf: yes, 5.2.2 and 5.2.3 are on the same page
12:35mupuf: the last paragraph of page 79 is for "5.2.3 Transistors"
12:35mupuf: what pdf reader do you use?
12:35karolherbst: currently the builtin chromium one
12:35karolherbst: will download and test with others
12:35mupuf: same here, and it works :s
12:35mupuf: okular works too
12:36karolherbst: with okular it is there indeed
12:36karolherbst: okay, then my reader is broken :D
12:37karolherbst: but I just use the chrome bundled one in chromium
12:37karolherbst: ohh no, it is chromium now
12:37karolherbst: there is no binary one anymore
12:38karolherbst: after the 5.1 formula everything is empty on that page
12:38mupuf: lovely :D
12:41karolherbst: anyway, this seems to work kind of
12:41karolherbst: karlmag: /sys/kernel/debug/dri/0
12:41karolherbst: there you have pstate/cstate/current_load
12:41karolherbst: current_load should contain values close to 0
12:41karolherbst: as long as you don't do anything
12:43karlmag: karolherbst: nothing under that debug directory.. I guess kernel needs to be compiled with some debug thingie set?
12:44karolherbst: karlmag: root
12:45karlmag: I am root
12:46karolherbst: you need debugfs mounted
12:48karlmag: there you go
12:50karlmag: DP-1/ DVI-I-1/ bufs gem_names vbios.rom vma
12:50karlmag: DVI-D-1/ HDMI-A-1/ clients name vm
12:50Shibe: why is nouveau slower than proprietary drivers?
12:51imirkin_: because proprietary drivers have had something on the order of 1000 man-years invested into them
12:51imirkin_: while nouveau has had 10 man-years at most
12:52karlmag: and direct access to all hardware (presumably at least) and proper hardware specs?
12:52karolherbst: karlmag: are you sure you are using my module?
12:52imirkin_: probably doesn't hurt
12:52karlmag: karolherbst: make; make install; reboot... I would assume so..
12:53karolherbst: karlmag: regenerated initramfs?
12:53karlmag: karolherbst: there is none
12:53imirkin_: i wonder what make install does
12:53imirkin_: almost certainly not what you want
12:54karolherbst: karlmag: you should copy the compiled module over the existing one
12:55karlmag: oh... right..
13:02mupuf: karolherbst: oh dear, adding a new subdev is a ton of fun :D
13:03mupuf:is glad to do it AFTER the rewrite
13:03karolherbst: guess why I waited for bens rewrite
13:03mupuf: it used to be a nightmare of casted pointers
13:03hakzsam: yeah, pretty simple now :)
13:03mupuf: ok, now, I am down to one WARN_ON
13:04mupuf: in drivers/pci/msi.c :D
13:04karolherbst: I think I know that one
13:04karolherbst: like this? https://gist.github.com/karolherbst/a977aad7ff5afb335b8a
13:05karlmag: yay... finally
13:05karolherbst: mupuf: ohh inside the kerel
13:05karolherbst: karlmag: :)
13:06mupuf: karolherbst: http://pastebin.com/7JTniLvz
13:06mupuf: let's stash the changes and see if it helps
13:06karolherbst: there were some changes regarding this
13:06karolherbst: like 3 days ago
13:07mupuf: karolherbst: which tree?
13:07karlmag: so... mem: 168, the other three are 0
13:07karlmag: doing nothing
13:07karolherbst: mupuf: which one are you using? :D
13:07mupuf: ah, right
13:07karolherbst: karlmag: mhh okay
13:07mupuf: and I get the same one without my code
13:08mupuf: so I guess this is work for ben!
13:08karolherbst: karlmag: nvapoke 0x10a534 0x80
13:08karlmag: first thing first.. "nvapoke"
13:08karolherbst: weird, this counter is helpful on my card, but useless on others
13:08karolherbst: karlmag: envytools
13:09karolherbst: there shall be a package
13:10karlmag: uhm... nope... not for me anyway.. but I'll get them from git I suppose.
13:11karolherbst: anyway, isn't that important
13:11karolherbst: it doesn't do anything besides giving you some data
13:11karolherbst: switching to highest pstate shall be more fun
13:11karolherbst: I fear your card will crash
13:12karlmag: karolherbst: as long as it doesn't get bricked I don't mind
13:13karlmag: I'm doing this on a different computer than I work on.
13:13karolherbst: I only think that nouveau might use a too low voltage
13:13karolherbst: but we will see
13:14karlmag: should I get any response?
13:14karolherbst: does the display still work? :D
13:14karlmag: looks like it
13:15karlmag: I'll double check
13:15karolherbst: you can also run sensors
13:15karolherbst: you should get your core voltage there
13:15karlmag: yup, both monitors still work
13:16karolherbst: what does sensors say?
13:16karlmag: GPU core: +0.86 V
13:16karlmag: power1: 10.00 uW
13:16karolherbst: power is garbage currently
13:16karolherbst: mhh core
13:16karolherbst: this seems pretty low :/
13:17karolherbst: dmesg may contain a voltage error
13:17karlmag: doesn't seem to
13:18karolherbst: maybe it is fine
13:18karolherbst: cat pstate
13:19karlmag: 07: core 324 MHz memory 648 MHz
13:19karlmag: 0a: core 324-862 MHz memory 1620 MHz
13:19karlmag: 0d: core 549-1254 MHz memory 6008 MHz
13:19karlmag: 0f: core 549-1254 MHz memory 6008 MHz
13:19karlmag: AC: core 324 MHz memory 648 MHz
13:20karolherbst: hey you didn't change the pstate :p
13:20karolherbst: you did the nvapoke thingy?
13:20karlmag: pretty sure I did
13:20karolherbst: ahh no, that just changes current_load
13:20karolherbst: should all 0 now
13:21karolherbst: or close enough
13:21karlmag: I don't know... really n0000b at this as earlier mentioned
13:21karlmag: not really sure what I'm doing :-P
13:21karolherbst: just cat current_load
13:21karolherbst: and check if the values are close to 0
13:21karlmag: core: 8
13:21karlmag: mem: 5
13:21karlmag: video: 0
13:21karlmag: pcie: 1
13:22karolherbst: seems okayish
13:22karolherbst: now echo 0f > pstate
13:22karolherbst: this either corrupt your card, crashes your card or prints stupid voltage error in dmesg
13:22karolherbst: or just works
13:23karlmag: still able to move a terminal window between the two monitors..
13:23karolherbst: what does the AC line say in pstate?
13:23karlmag: and nothing in dmesg it seems
13:24karlmag: AC: core 1254 MHz memory 6007 MHz
13:24karlmag: so higher than before
13:25karolherbst: mhh nice
13:25karolherbst: then do some stuff
13:25karolherbst: like vblank_mode=1 glxgears
13:27karlmag: about 16k7 fps
13:28karolherbst: seems good
13:28karolherbst: around the value I got on a second X
13:29karolherbst: karlmag: lspci -s 01:00.0 -vv | grep LnkSta:
13:30karlmag: started a second glxgears on the second monitor.. about 10k fps on both
13:30karlmag: LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
13:32karolherbst: seems alright
13:34karolherbst: karlmag: you seem very unlucky, because everything works so far, you can't help me anymore :p
13:34karolherbst: you could actually play some games on 0f until something bad happens
13:34karolherbst: but it seems to be fine so far
13:38mupuf: here we go, I did what morpheus said: Follow the white crashes!
13:39karlmag: games of 0f ?
13:39karlmag: karolherbst: I'm pretty sure a certain mr Murphy is playing us :-P
13:41karlmag: I did input 0f many times after each other, and both screens went black.. but that was because stuff went to power-save mode :-P (not at console of that comp)
13:41karolherbst: well you have to switch to another pstate first
13:41karolherbst: best would be 0a of 07
13:41karolherbst: otherweise nouveau won't do anything
13:42karlmag: well, there is a very short blink on both monitors when I change
13:44karlmag: 0a gives about half fps (about 5k1)
13:44karlmag: still both monitors
13:45karlmag: and 07 about 1k9
13:45karolherbst: if you want to take it to the more serious level: while true; echo 0a > pstate; sleep 0.001 ; echo 0f > pstate; sleepd 0.001 ; done
13:45karolherbst: this may crash your card pretty fast
13:45karolherbst: ohh wait
13:45karolherbst: there is something wrong
13:45karolherbst: while true; echo 0a > pstate; sleep 0.001 ; echo 0f > pstate; sleep 0.001 ; done
13:46karolherbst: while true; do echo 0a > pstate; sleep 0.001 ; echo 0f > pstate; sleep 0.001 ; done
13:47karlmag: it does have trouble drawing new picture fast enough
13:47karlmag: maybe manage 1/6 before redraw
13:48karlmag: oh.. now it's all there
13:48karlmag: but the while loop is still running
13:48karolherbst: that's the idea
13:49karlmag: uhmm.. what is?
13:49karlmag: while loop is running and now both monitors show picture as it should
13:49karlmag: about 7k7 fps on both monitors
13:50karolherbst: I do the same currently
13:50karolherbst: and well
13:50karolherbst: it is pretty stable
13:51karlmag: when the flickering went away it seems stable yeah
13:51karlmag: not crashed yet at least
13:53karlmag: karolherbst: well.. if there is anything else, do ask and I'll try if I can/have time :-)
13:54karolherbst: karlmag: seems like we have to reboot now :/
13:54karolherbst: at least I didn't manage to kill this stupid while loop :D
13:55karlmag: karolherbst: actually I wonder if it might have died quite early on but still seems to be running
13:56karolherbst: don't know
13:56karolherbst: maybe it got locked ujp
13:56karolherbst: dead lock for me
13:56karolherbst: ohhh boring
13:56karlmag: can't seem to see any of the processes being run
13:57karolherbst: echo is builtin
13:57karolherbst: so is sleep
13:57karolherbst: lsof /sys/kernel/debug/dri/1
13:57karolherbst: lsof /sys/kernel/debug/dri/0
13:57karolherbst: there should be a bash process
13:57karolherbst: which you can kill
13:58karolherbst: or not
13:58karolherbst: I will reboot now
13:58karlmag: or not.. my conclusion too :-P
14:02karolherbst: mupuf: maybe we should mutex lock the clocking somehow?
14:02karlmag: karolherbst: wb
14:10mupuf: karolherbst: as in?
14:10mupuf: do not allow multiple reclocking to happen at the same time? Isn't it there already?
14:10karolherbst: mhhh, I manage to get a lockup while doing echo > pstate
14:11karolherbst: *dead lock
14:11karolherbst: when I do it really fast
14:12mupuf: check the code
14:12mupuf: but pstate should also be synchronous
14:14karlmag: I can second that
14:15karlmag: well, something happened.
14:16karolherbst: mupuf: I don't think it is
14:19karolherbst: mupuf: is this asnyc or sync? https://github.com/karolherbst/nouveau/blob/master/drm/nouveau/nvkm/subdev/clk/base.c#L240-L248
14:19karolherbst: looks like async to me
14:19karolherbst: but I don't know it
14:19mupuf: depends on the value of wait :D
14:20karolherbst: it is called with true from the pstate interface
14:20mupuf: then it is supposed to be
14:20mupuf: but check that the work does not create another task!
14:20karolherbst: karlmag: is it still running on your machine?
14:21karolherbst: or did you reboot as well
14:21karlmag: I rebooted when you did
14:21karolherbst: I don't have the stack anymore
14:21karolherbst: mupuf: but I think it deadlocked inside schedule
14:22karlmag: I can set it up again..
14:22karolherbst: karlmag: don't bother, I can do it :/
14:22karlmag: well, it's not my primary machine so if it locks up or anything it doesn't matter
14:22karolherbst: at least reclocking every 0.1 seconds kind of worked
14:22karolherbst: nobody will reclock that fast
14:24karlmag: seems to run for about 18 seconds (yeah, I counted, not particularly scientific) then the flickering stopped
14:25karlmag: it's dead Jim..
14:25karolherbst: karlmag: lsof /sys/kernel/debug/dri/0
14:25karolherbst: then get the PID
14:26karolherbst: cat /proc/$PID/stack
14:26karlmag: I tried to kill it
14:26karlmag: still somethign there
14:26karolherbst: yeah I know
14:26karolherbst: that's why the lsof
14:26karolherbst: and the stack
14:27karlmag: karolherbst: http://pastebin.com/F0EsyAg5
14:28karolherbst: wow not even the schedule is there for you
14:28karlmag: maybe something was lost when I tried to kill that process?
14:28karlmag: I can redo it.. gimme a minute or two
14:30karolherbst: there won't be more
14:32karolherbst: karlmag: you could run some benchmarks though :D
14:32karlmag: something must have froze when I did reboot.. because picture just froze on both monitors. Didn't change until the power was cycled by the computer
14:32karlmag: sure, just tell me how
14:38karolherbst: karlmag: oh, you could just rerun those phoronix benchmarks, where gddr5 didn't work right :D
14:38karolherbst: I just don't find them
14:41karlmag: I haven't done much other than glxgears really
14:42karlmag: have I? :-P
14:42karlmag: and the fiddling in /sys
14:49karolherbst: karlmag: there is this phoronix benchmark tool, which this phoronix guy uses to do his benchmarks :D
14:49karlmag: just looked it up
14:49karolherbst: I think it is the best way to compare to what he does
14:49karolherbst: it handles a lot of stuff though
14:49karolherbst: like downloading binaries
14:50karolherbst: passing the right flags
14:52karlmag: welp..installed now
14:53karlmag: karolherbst: it had only a few options :-P
15:24karolherbst: oh man :/ I want to live somewhere else, somewhere with better jobs and not 80% java bs, and 15% .NET and 4% cobol :D
15:29karlmag: karolherbst: can't imagine that :-P
15:29karolherbst: okay I lied, there is also php and web stuff
15:30karlmag: that's the 1% then? ;-)
15:30RSpliet: karolherbst: Germany is probably one of the better places to live tbh
15:30karolherbst: RSpliet: yes, but I am complaining about those IT jobs :D
15:30RSpliet: there's Suse
15:30karolherbst: ohhh right
15:31karolherbst: totally forgot about them
15:31RSpliet: and companies like Bosch and Siemens
15:31karolherbst: yeah well, that's too big for me :D
15:31RSpliet: (who do a lot of embedded and real-time stuff)
15:31RSpliet: not to mention the car manufacturers
15:32karolherbst: I would rather to some non embedded stuff :/
15:32RSpliet: I think NVIDIA has an engineering office in Germany as well iirc
15:32karolherbst: yeah, that would be funny: hi there did stuff for nouveau, do you have a job for me :)
15:33RSpliet: gnurou: well... do you?
15:33karlmag: karolherbst: suggestions about phornoix tests to run?
15:33karlmag: way too much to choose from :-P
15:33karolherbst: karlmag: gputest
15:33karolherbst: gputest is small and somehow usable
15:33karolherbst: also the unigine tests
15:37karlmag: karolherbst: uhm.. I think something crashed
15:37karlmag: on 3dplot test
15:37karolherbst: RSpliet: the thing is, I want to work somewhere where I can mainly work on community driven projects
15:37karolherbst: or at least projects where there is a big community to work with
15:37karolherbst: karlmag: mhh gimark shouldn't work
15:37karlmag: [ 3844.090718] nouveau 0000:01:00.0: fifo: read fault at 00028c8000 engine 00 [GR] client 08 [GPC2/PE_2] reason 02 [PTE] on channel 6 [023f899000 GpuTest]
15:37karlmag: [ 3844.090725] nouveau 0000:01:00.0: fifo: gr engine fault on channel 6, recovering...
15:38karolherbst: too low voltage maybe
15:38karolherbst: mupuf: ?
15:38RSpliet: karolherbst: Pengutronix?
15:38mupuf: karolherbst: try a higher one :D
15:38karlmag: mouse pointer still moves about but everything else seems frozen
15:39karolherbst: RSpliet: mhhh if I am able to work from home, yes, otherwise I can only do that some other time
15:39mupuf: yes, pingutronix definitely kicks asses!
15:39mupuf: intel has offices in germany too
15:39mupuf: although probably nothing for the open source
15:40mupuf: for that, it is finland or sweden
15:40karolherbst: would be nice, but currently I can't do that
15:40mupuf: finish your studies, come to XDC next year and I am sure you will get people interested in you!
15:40karlmag: I forget; where did I read out the voltage again?
15:40RSpliet: karolherbst: http://www.pengutronix.de/jobs/kernel_hacker_de.html :-P
15:41RSpliet: no idea where Hildesheim is
15:41karolherbst: karlmag: sensors
15:41mupuf: lynxeye used to be a nouveau dev :) he works with pingutronix now
15:41karolherbst: RSpliet: south
15:41karlmag: *facepalm* yeah..
15:41karolherbst: ohh well
15:41karolherbst: not that south
15:41karolherbst: near hannover
15:41mupuf: relocating is fun
15:42karlmag: GPU core: +0.86 V
15:42karolherbst: that would be kind of okay
15:42karlmag: power1: 10.00 uW
15:42RSpliet: anyway, Germany has quite a few opportunities :-)
15:42karolherbst: karlmag: power doesn't work yet
15:42karolherbst: RSpliet: yes, the 1%
15:42karlmag: oh, right
15:42mupuf: karolherbst: you need to understand that there is only a very limited number of people working on what you are working on! :D
15:42RSpliet: karolherbst: good thing that less than 1% of the pop. is capable of doing this kind of work :-P
15:43mupuf: You could even try nvidia,
15:43karolherbst: mupuf: :D I know
15:43RSpliet: Hamburg right?
15:43mupuf: karolherbst: when will you be done with your studies?
15:43karolherbst: mupuf: don't know :( if I find my motiviation again to finish them
15:43RSpliet: karolherbst: not you, nvidia :-P
15:43mupuf: if XDC is in finland next year, you can have interviews at intel and nvidia :D
15:44karolherbst: I am nearly done though
15:44RSpliet: mupuf: silly, there's FOSDEM in Feb first :-P
15:44karolherbst: I have like 190 CPs?
15:44mupuf: How could I forget that!!!
15:44mupuf: I missed it last year, not again this year!
15:44RSpliet: karolherbst: are those ECs in the ECTS?
15:44RSpliet: and you need 300? :-P
15:45karolherbst: credit points
15:45karolherbst: and no
15:45karolherbst: BA is usually 180
15:45karolherbst: I think they are x2 EcTS?
15:45RSpliet: EC -> European Credits, one EC is the equivalence of 26,667 hours, 60EC is one year of study
15:46RSpliet: BSc in NL is 3 years -> 180ECs
15:46karolherbst: then I have around 190 ECs
15:46RSpliet: ECTS -> EC Transfer System :-P
15:46RSpliet: basically "the system we use in Europe to measure equivalence"
15:46karolherbst: yeah got that
15:47RSpliet: (where with Europe I mean that thing excluding Cambridge, and possibly other parts of the UK :-P)
15:47RSpliet: because Cambridge is special
15:47karolherbst: at least my google page looks quite nice :D
15:48karolherbst: mupuf: even your slides are showing up
15:48RSpliet: google has a lot of engineers in .de too!
15:48karolherbst: RSpliet: I know
15:48RSpliet: not necessarily on community projects though, they tend to be quite evil
15:48karolherbst: RSpliet: one of their recruiter already asked me like 2 years ago?
15:48mupuf: karolherbst: hehe
15:48karolherbst: but this was more like a: try to apply kind of asking
15:50karolherbst: but this was for Vienna or Dublin
15:54karolherbst: I actually could go to fosdem, it isn't _that_ far away from where I live
15:58karolherbst: okay, at least nvidia doesn't seem to have something near hamburg, berlin though
15:59karolherbst: sys admin :/
16:00karolherbst: yeah I relly like that, quote from a semi famous german hacker "a good sys admin clicks reddit all day, because the stupid task are all automated away" :D
16:03karolherbst: karlmag: plase upload your vbios.rom somewhere
16:03karlmag: uhm... ok...
16:04karlmag: not sure where that "somewhere" should be, but...
16:05karolherbst: doesn't matter
16:07karolherbst: mupuf: intel does indeed have something hear in hamburg, but this is like security stuff, which I won't touch for at least 20 years :D
16:07karlmag: that was strange... card 0 and 1 was swapped this boot..
16:08mupuf: karolherbst: you don't want to relocate?
16:09karolherbst: mupuf: I can't currently
16:09mupuf: studies? Just finish them and be done with it :p
16:09karolherbst: I will be able to do so in half a year or something
16:09karolherbst: no, rather personal matter
16:10mupuf: well, half a year, sounds like about time you start contacting companies
16:10karolherbst: studies would be no problem, then I would simply study somewhere else :D
16:10mupuf: big companies take forever
16:10karolherbst: mhh right
16:12karolherbst: anyway, how much is it worth to have like 4+ years of working experience at the big compaies in general?
16:13karolherbst: or in teh cases you are aware of
16:14karlmag: karolherbst: http://www.slackware.com/~karlmag/nouveau/vbios.rom
16:15mupuf:has less than a year
16:15mupuf: I would say that the companies we are interested in should hire you based on your contributions to linux
16:15mupuf: and because they know you
16:15mupuf: you completely bypass the useless HR selection process too, which is great
16:19mupuf: yeepeeeeee! For some reason, I was going WAAAAYYYY down in the i2c stack ... to find out that indeed, I screwed up and was looking for a device on the wrong bus...
16:19karolherbst: at least you know it
16:19mupuf: I had forgotten that the bios is a piece of shit and tells you that a device is on one bus when it actually is somewhere else
16:20mupuf: [ 2833.459065] divide error: 0000 [#1] PREEMPT SMP
16:20mupuf: oopsie :p
16:21karolherbst: funny though, the falcon doesn't care
16:22mupuf: fuck, I should be in bed already
16:22karolherbst: ohh why? it isn't _that_ late :p
16:22mupuf: well, depends when you need to wake up
16:22karlmag: 'tis late :-P
16:23karolherbst: :P :P :P
16:23karolherbst: mupuf: okay then, nighty night
16:23mupuf: Power = 22699904 uW
16:23mupuf: hmm, that even looks plausible
16:25mupuf: well, that will be good-enough for now :D
16:29karlmag: karolherbst: did you get it?
16:29karolherbst: karlmag: yes
16:29karlmag: goodie :-)
16:29karolherbst: ti boost?
16:30karlmag: 01:00.0 VGA compatible controller: NVIDIA Corporation GK106 [GeForce GTX 650 Ti Boost] (rev a1)
16:31karolherbst: karlmag: nvapeek 101000
16:31karlmag: karolherbst: 00101000: 80404896
16:32karlmag: np :-)
16:32karolherbst: now let's take a look
16:32karolherbst: INA3221 nice
16:33karlmag: uhm.. if you say so :-P
16:33karolherbst: and MAX6649 temp sensor
16:33mupuf: http://cgit.freedesktop.org/~mperes/nouveau/commit/?h=pwr_sensor&id=5c2116436d35247e4133509ed0146b135069706a <-- speaking about ina3221
16:33karolherbst: mupuf: thanks a lot
16:33mupuf: it is not done at all
16:33mupuf: this is just the infrastructure
16:33karolherbst: does it kind of work?
16:33mupuf: well, it should allow you to read the power, yes
16:34mupuf: for your ina3221
16:34mupuf: but the interface to read is not even there :D
16:34karolherbst: which means?
16:34karolherbst: but it looks nice
16:34mupuf: you could read by using device->iccsense->driver.pwr_get(&device->iccsense);
16:34mupuf: or something like this
16:35mupuf: this is a giant QIP commit
16:35mupuf: I will split it later
16:35karolherbst: I see
16:35karolherbst: the MAX6649 seems nice
16:35mupuf: in vbios-parsing, changes to the i2c, infrastructure for the iccsense
16:36mupuf: (with the nil pwr sensor)
16:36mupuf: and then one commit per sensor
16:36karolherbst: how many cards will be supported by this, 5% or more? :D
16:36mupuf: and then add your patch to read the pwr
16:36karolherbst: I really don't know how common those sensors are
16:36mupuf: you can make the stats based on the vbios repo
16:37mupuf: but we lack bioses to make good stats
16:37mupuf: the expensive cards have it
16:37karolherbst: there are way less kepler cards
16:37karolherbst: I will add the ti boost
16:37karlmag:feels a little tiny bit useful
16:38karolherbst: but currently I don't know what you could trace
16:38karolherbst: maybe you want to RE the NVENC :p
16:38karlmag:looks at the copper traces on a pcb..
16:38karolherbst: that would be super usefull
16:38mupuf: that definitely is a newcomer's task, yes :D
16:38mupuf: only imirkin_ was stupid-enough to start a project like that straight away (video decoding)
16:39mupuf: but hey, he was smart-enough to pull it off super nicely!
16:39karolherbst: somebody just needs to do it
16:39hakzsam: imirkin, well, MP counters now work with valley/heaven without any weird 3D affects. NVC0_COMPUTE is going to be definitely removed :)
16:39mupuf: hehe, one needs to be stupid-enough not to need bravoury
16:39karolherbst: mupuf: sadly we lost him for the VP5,VP4 engines for that
16:39karolherbst: he won't ever touch it again, at least he said so
16:39mupuf: yeah, meh
16:40mupuf: this is far from being the most useful part of the GPU :D
16:40mupuf: nvenc is though
16:40karlmag: I found this; https://en.wikipedia.org/wiki/Nvidia_NVENC and figured... yikes.. :-P
16:40karolherbst: isn't the cpu fast enough usually?
16:40karolherbst: karlmag: right
16:40mupuf: for decoding, yes
16:40karolherbst: that's the stuff
16:40mupuf: for encoding, no
16:40karolherbst: allthough even my gpu can do this fancy nvidia recording thing on windows
16:40mupuf: let's wait for nvidia to add support for it on the GM20B :D
16:41linkmauve1: mupuf, I remember reading stuff about how the ultrafast preset of ffmpeg was both higher quality and faster than some GPU encoding.
16:41karolherbst: I bet there is a way to do that: front buffer => nvenc => h.264 stream
16:41linkmauve1: I don’t remember which GPU though.
16:41mupuf: well, one advantage is that it does not leave the gpu
16:41karolherbst: mupuf: yes
16:41mupuf: that means less pcie bandwidth
16:41karolherbst: mupuf: which is super critical for me :/
16:42mupuf: hehe, see?
16:42karolherbst: or more critical than I thought
16:42karolherbst: +25% pef in talos through higher pcie speed :/
16:42mupuf: and that also means you can keep your buffer tiled
16:42karolherbst: just insane
16:42mupuf: which probably helps!
16:42mupuf: you need more vram :D
16:42karolherbst: if I need something, is more speed
16:42karolherbst: not vram
16:42karolherbst: I have 3GB
16:43mupuf: if your pcie bw is important, it means you are bouncing buffers between the host and gpu
16:43karolherbst: and only 4GHz mem clock
16:43mupuf: or that the game/benchmark is stupid
16:43karolherbst: game is stupid
16:43karlmag:looks at computer with the most (v)ram in the house..
16:43mupuf: see you though, really need to sleep
16:43karolherbst: mupuf: + DRI_PRIME
16:44karolherbst: karlmag: what you got? 1GB or 2GB?
16:44karolherbst: ohh wait
16:44karolherbst: I can check that
16:44karolherbst: I think
16:44karolherbst: not sure
16:44karolherbst: ohh nice
16:44karolherbst: that's the better variant then
16:44karlmag: the amd card has 8GB though...
16:44karlmag: and computer has 64
16:44karolherbst: yeah well
16:45karolherbst: karlmag: did you check how much of it was used?
16:45karolherbst: with the blob I barly tough 1GB here
16:45karlmag: uhm.. no?
16:45karolherbst: big numbers, but no use
16:45karolherbst: more sys ram is super usefull though
16:45karolherbst: if the system ran long enough, you could actually remove the SATA disc
16:45karolherbst: without the system going ops
16:46karlmag: cstate is it?
16:47karolherbst: same as on a cpu
16:47karolherbst: ohhw ait
16:47karolherbst: cstates on the nvidia gpu are just clocks
16:48karolherbst: I think cpus are more advnaces with their states
16:48karlmag: so.. where to look?
16:48karolherbst: cat cstate
16:49karlmag: current pstate: 0xffffffff
16:49karlmag: available clockings: 324 - 324 MHz
16:49karlmag: available cstates for current pstate:
16:49karlmag: current core: 648000
16:49karlmag: current memory: 324000
16:49karlmag: so this?
16:49karlmag: it's kind of sleeping.. monitor1 is blank, monitor2 has picture on it still..
16:49karlmag: strange they don't go at the same time
16:50karolherbst: ohh you need to be on a usefull pstate first
16:50karolherbst: then you can list all available clocks for that one pstate
16:50karlmag: just tell me what to do
16:51karolherbst: I have to read your vbios first
16:52karlmag: ah, ok.. not today then I guess
16:52karlmag: well, technically, perhaps, but...
16:52imirkin: hakzsam: did you figure out what was going wrong before?
16:54imirkin: mupuf: yeah, and it still doesn't work :(
16:56karolherbst: karlmag: vbios seems to be sane, but the table for the voltages isn't corectly REed yet
16:56karolherbst: so there are some cards with issues like that
16:57karolherbst: it could be something completly different though
16:59karlmag: karolherbst: right
17:33karlmag: ah, yeah.. I should try that sleep thing I've heard so much about. :-P
17:35karolherbst: again a kernel crash after removing nouveau
17:35imirkin: skeggsb: looks like something with the unsynchronized bit that glamor uses
17:35imirkin: skeggsb: if i remove that bit, all works for me
17:36imirkin: skeggsb: http://hastebin.com/nafucahexu.diff -- let me know if this helps you
17:36imirkin: if it does, i'm going to have a hard look at wtf unsynchronized _really_ means
17:45skeggsb: imirkin: building mesa now...
17:46imirkin: coz i'm pretty sure that what glamor is doing is fairly illegal
17:47karolherbst: any ideas about my crash?
17:47airlied: imirkin: you should ask anholt
17:48imirkin: well i also didn't look too carefully
17:48airlied: I can't remember is UNSYNCHRONIZED code for allocate a new buffer and keep going
17:48airlied: instead of overwrite the current buffer which the gpu is possibly using
17:48imirkin: that's definitely not what nouveau does
17:48imirkin: unsync just gives you a map to the buffer and you can go at it however you like
17:48skeggsb: airlied: isn't there some other flag for that?
17:48skeggsb: DISCARD or something?
17:49imirkin: yeah, there's a discard
17:49imirkin: and if it's the size of the whole buffer we realloc the thing
17:51airlied: oh unsync is trust me I know what I'm doing
17:51imirkin: yeah, except apparently not ;)
17:52airlied: though I think with WRITE and INVALIDATE_RANGE
17:52airlied: you can return scratch memory and upload it async
17:53imirkin: yeah.... perhaps we do
17:57skeggsb: wtf.. selecting edit->preferences in gnome-terminal running in Xephyr makes it open preferences on my Xorg instance..
17:58skeggsb: imirkin: running on Xorg+glamor, the terminal title bar is fine, but still missing glyphs in some dialog boxes etc
17:59imirkin: skeggsb: hm ok
17:59imirkin: skeggsb: is this with ARB_buffer_storage disabled or not?
17:59airlied: skeggsb: wierd, gnome-terminal has some factory procewss
18:00skeggsb: imirkin: ah, this is with ARB_buffer_storage enabled for the "real" session
18:00imirkin: skeggsb: can you try disabling it?
18:00skeggsb: airlied: also, when I kill Xephyr, all my gnome-terminals for my real session die too.. fun times
18:01imirkin: moral of the story: if it starts with gnome-, don't use it
18:01imirkin: never had that problem with aterm :)
18:01skeggsb: i rather like gnome-terminal in general
18:01airlied: skeggsb: maybe --disable-factory
18:01skeggsb: airlied: where's a good place to override environment vars for gdm and gnome sessions spawned from it?
18:02karolherbst: I used to use it even on my kde session, too
18:02airlied: oh looks like that might be gone
18:02skeggsb: actually, screw it, i'll ssh in and launch the session manually, that seems easier
18:03airlied: skeggsb: https://wiki.gnome.org/Apps/Terminal/Debugging
18:07imirkin: skeggsb: it's gnome, it'll outsmart you
18:08skeggsb: imirkin: yeah, without buffer storage it seems to work just fine actually
18:08skeggsb: (still running mesa with your patch)
18:08imirkin: skeggsb: you think it uses rhyme and reason to operate, but that is not so
18:08imirkin: skeggsb: ok, that's good to know
18:08imirkin: sounds like there's a disagreement between anholt and myself re what these flags mean
18:08imirkin: somehow i suspect that he's the one who's right
18:20glennk: from memory unsynchronized mapping means the app has to avoid trampling buffer data in use by the gpu
18:20glennk: typically either using fences, or waiting say n+2 frames and praying...
18:21airlied: well I think the app can know it hasn't used this portion of the buffer for the gpu
18:25glennk: uh yeah thats the point of the flag, the app manages all the synchronization, not the driver
18:26glennk: that said, its obsoleted by buffer_storage and persistent coherent maps
18:26imirkin: airlied: nouveau does keep track of how far a buffer is used
18:27imirkin: airlied: but unsync means that all sync efforts should be ignored
18:27imirkin: at least as far as i understood
18:27imirkin: glennk: i'm guessing that the buffer_storage code has the same issues, which is why i said it should be disabled
18:28glennk: probably easiest to just dig up what glamor is doing
18:30imirkin: nvidia likes to keep a pretty deep draw pipeline, so i'm not surprised we're hitting issues other gpu's don't see
18:30airlied: https://www.opengl.org/wiki/Buffer_Object_Streaming at the end
18:30airlied: is what it wants I expect
18:30airlied: Streaming optimizations
18:31glennk: the blob driver hates glMapBufferRange since it breaks its threading
18:31airlied: it's the write-combine me if you can option :)
18:34glennk: well, looks like glamor misses the "permanent map" part of buffer_storage
18:35glennk: eh, misread, empty if...
18:35glennk: but the map buffer range path does have one strange thing going on
18:36glennk: if its unsynchronized and you unmap it before the drawing is complete -> undefined behavior
18:36glennk: if you then additionally map it again with GL_MAP_INVALIDATE_RANGE_BIT, your data may be eaten by a grue
18:39EmperorDAZ_2: Is this line of any relevance? dmesg: "[26883.662329] nouveau 0000:03:00.0: Invalid ROM contents"
18:40airlied: glennk: as long as you map a different range it's fine
18:40imirkin: EmperorDAZ_2: not really
18:41EmperorDAZ_2: and, according to "https://wiki.freedesktop.org/nouveau/DumpingVideoBios/", I seem to get 2 slightly different files, the /sys/bus/pci method gives me a different size rom compared to the /sys/kernel/debug
18:41EmperorDAZ_2: expected behavior?
18:41imirkin: yeah. you want the /sys/kernel/debug one.
18:42EmperorDAZ_2: is there any explanation for the difference?
18:43imirkin: yeah, they're totally different data
18:43EmperorDAZ_2: what does each one mean? the webpage seems to imply they are the same thing
18:44imirkin: the webpage is wrong
18:45EmperorDAZ: where can I learn their difference other than asking here (irc)?
18:46EmperorDAZ: the wiki.freedesktop.org/nouveau is the (active) page of this (nouveau) project right?
18:48imirkin: nouveau.freedesktop.org -- should be largely the same thing though
18:49karolherbst: there was a pledge :D
18:53EmperorDAZ: I have this doubt here, not sure if it's nouveau issue
18:53imirkin: EmperorDAZ: provide information on what's going wrong :)
18:53EmperorDAZ: on my i5-5820K system, with GTX760 non-ref card, 4GB
18:53EmperorDAZ: if I run lspci
18:54EmperorDAZ: it hangs (the lspci)
18:54EmperorDAZ: the process is unkillable
18:54EmperorDAZ: googled around, since I am using archlinux, found an answer on its forums, stating that it was related to nouveau
18:54EmperorDAZ: dmesg did show some messages regarding nouveau
18:55karolherbst: that sounds, weird, EmperorDAZ do you have a link
18:55imirkin: pastebin dmesg
18:56EmperorDAZ: I ran it yesterday and havent rebooted yet but dmesg hasnt recorded anything new
18:56EmperorDAZ: with --ctime?
18:56EmperorDAZ: or doesnt matter?
18:57karolherbst: it doesn't
18:58EmperorDAZ: I am not sure if it's related to nouveau so I prefered to investigate a bit and ask here first before raising any kind of bug ticket which would be a false alarm
18:59EmperorDAZ: one extra info, I am not running X server
18:59karolherbst: imirkin: wasn't here somebody some days ago with a similiar stack?
19:00EmperorDAZ: the GPU is just there so I can boot the pc, it's being used as a headless machine for CPU distributed computing tasks
19:00EmperorDAZ: can run tests
19:00karolherbst: EmperorDAZ: this is a laptop, right?
19:00EmperorDAZ: its a desktop
19:01EmperorDAZ: Gigabyte GTX 760, 4GB edition, factory overclocked
19:01EmperorDAZ: let me find link
19:01karolherbst: no, it is okay
19:01karolherbst: I was just wondering about the mxm line
19:01EmperorDAZ: X99 system
19:02EmperorDAZ: can give list of the build if required
19:13EmperorDAZ: one thing, the HDD is cannibalized from a laptop
19:13EmperorDAZ: I remembered that
19:13EmperorDAZ: does it matter?
19:16karolherbst: not really
19:16karolherbst: there is some power managemant stuff going on, which should not happen :/
19:18EmperorDAZ: is it the cause for the lspci "malfunction" ?
19:18EmperorDAZ: or it turns out this call trace is a different unrelated issue
19:21karolherbst: EmperorDAZ: mhhh the error shouldn't happen usually
19:21karolherbst: but your card seems to work, so I don't get why lspci doesn't work
19:22EmperorDAZ: the source who mentioned nouveau: "https://bbs.archlinux.org/viewtopic.php?id=183185"
19:22karolherbst: EmperorDAZ: try to run lspci -s 03:00.0
19:23EmperorDAZ: I'll reboot the machine
19:24EmperorDAZ: still no result
19:24karolherbst: so it hangs with " lspci -s 03:00.0" too?
19:24EmperorDAZ: at the present moment yes
19:24EmperorDAZ: no dmesg messages tho
19:25EmperorDAZ: if my memory isnt failing, after the first "lspci" run, dmesg messages popped up to which I already pastebin'd them here
19:26EmperorDAZ: any subsequent lspci run shows nothing more
19:26EmperorDAZ: I'll see dmesg after boot
19:27karolherbst: this error is just super weird :/
19:33EmperorDAZ: dmesg is clean
19:33EmperorDAZ: lspci hanged
19:34EmperorDAZ: more error
19:34EmperorDAZ: i need to close the ssh session because not even ctrl-c will close it
19:39karolherbst: EmperorDAZ: is this issue there like always?
19:40EmperorDAZ: the issue for me is lspci / "lspci -s 03:00.0" hangs
19:41EmperorDAZ: now, the reason for it is unknown to me
19:41EmperorDAZ: new pastebin
19:41EmperorDAZ: this one mentions lspci at the bottom
19:41karolherbst: I somehow think this is more a kernel issue
19:42EmperorDAZ: lspci on my other machine works perfectly fine
19:42EmperorDAZ: 2x maxwell GM200 system (the one I am typing from at this moment) has no issues
19:42karolherbst: maybe a case of bad combinations of stuff
19:43EmperorDAZ: kern ver of the machine with issues is 4.2.2
19:43airlied: nouveau.runpm=0 might be worth a try
19:43EmperorDAZ: I can try update to 4.2.3
19:43EmperorDAZ: might be the issue here
19:44karolherbst: airlied: I know, but there was somebody here with a similiar issue, and this didn't help
19:44karolherbst: airlied: it already goes the path for runpm=0, so this is fine
19:44EmperorDAZ: what was their kern ver?
19:44karolherbst: airlied: https://github.com/imirkin/nouveau/blob/a41f62639b14bab1f306241445398f525f8e47b7/drm/nouveau/nouveau_drm.c#L717-L727
19:44karolherbst: either it goes the first branch or the second one
19:44karolherbst: there is no difference
19:45karolherbst: EmperorDAZ: I don't know anymore
19:46karolherbst: found it
19:46karolherbst: ohh thats only dmesg before it :/
19:47karolherbst: this one: https://bpaste.net/show/e81dd0aea7f2
19:47karolherbst: its nearly the same
19:47karolherbst: just with 3.16
19:48karolherbst: pmoreau: you fixed some pcie issues, how did yours show?
19:49EmperorDAZ: that dmesg is G92 chip
19:49EmperorDAZ: this is GK104
19:50EmperorDAZ: ssh reboot doesnt work
19:50EmperorDAZ: has to be manual poweroff method
19:50karolherbst: yeah, this is some kind of dirty issue :/
19:51EmperorDAZ: the curse of the X99+GTX760+4.2.2kernel
19:55karolherbst: EmperorDAZ: sorry that we can't really help you with this one, if you got the time and patience, you could try out different distributions
19:55karolherbst: the nouveau codebase should be the same, but the kernel might be configured differently
19:55karolherbst: if you find a kernel where it works, this could help
19:56EmperorDAZ: I am fine with nouveau
19:56EmperorDAZ: the issue is non critical
19:57airlied: it's wierd it's definitely trying to run time suspend
19:57karolherbst: EmperorDAZ: yeah, as long as you don't encounter any applications calling lspci :D
19:57karolherbst: airlied: yes, and nouveau tells the kernel not to do it again
19:58EmperorDAZ: my intention was to 'help' the nouveau project since I happened to stumble across a bug, the project would benefit from it
19:58EmperorDAZ: raise ticket?
19:58EmperorDAZ: 1 new thing
19:58karolherbst: EmperorDAZ: well, you could create one, but I doubt that somebody will have the idea why this happens. Testing different kernel configurations might help
19:58karolherbst: maybe its a stupid gcc bug
19:58karolherbst: who knows
19:59EmperorDAZ: I get the call trace
19:59EmperorDAZ: without lspci
19:59karolherbst: EmperorDAZ: yeah, this is normal
19:59karolherbst: airlied: maybe if vgaswitcheroo is disabled, it doesn't print this issue?
19:59airlied: something like ur1.ca/o0z12 might help
19:59airlied: though I still can't see how it happens
19:59EmperorDAZ: it coincides when the monitor goes to sleep
20:00airlied: yes so then the gpu powers down
20:00airlied: if it could
20:00EmperorDAZ: call trace about suspend --> normal
20:00airlied: maybe boot with drm.debug=6 and see if it prints anything
20:00EmperorDAZ: lspci hang --> different issue?
20:02airlied: the lspci hang is due to it trying to resume the card
20:02karolherbst: airlied: vga_switcheroo is builtin or usually a module?
20:02airlied: karolherbst: built-in usually
20:02karolherbst: I really want to disable it and check if that helps
20:02karolherbst: it should help
20:02airlied: but since switcheroo doesn't get enabled it won't matter
20:03airlied: since it requires two gpus
20:04karolherbst: EmperorDAZ: cat /sys/kernel/debug/vgaswitcheroo
20:04karolherbst: I want to be sure
20:04karolherbst: EmperorDAZ: I meant cat /sys/kernel/debug/vgaswitcheroo/switch
20:05karolherbst: airlied: idea: there is an intel hdmi chip
20:05karolherbst: airlied: and vgaswitcheroo things: well let us disable this nvidia hdmi chip :)
20:05karolherbst: "snd_hda_intel 0000:03:00.1: Handle VGA-switcheroo audio client"
20:05airlied: that is the nvidia hdmi chip
20:05EmperorDAZ: there is no vgaswitcheroo
20:05airlied: or rather the gpu
20:06karolherbst: okay, but who else would call that?
20:06airlied: EmperorDAZ: did you ever use powertop
20:07airlied: or have something installed to reduce battery usage
20:07airlied: I'm guessing userspace is enabling runtime pm for you
20:07karolherbst: airlied: well I use powertop and laptop_mode_tools
20:08airlied: karolherbst: depends if you do something bad with them
20:08EmperorDAZ: the attempt of trying to wakeup screen from ssh with "echo -ne "\033[9;0]" >/dev/tty1" from https://raspberrypi.stackexchange.com/questions/10374/wake-console-screen-with-ssh
20:09EmperorDAZ: also hangs
20:09karolherbst: airlied: well, usually a lot :D
20:09EmperorDAZ: it seems that anything that touches the GPU will permahang
20:10airlied: EmperorDAZ: get powertop, and before it hangs go to the tunables column
20:10airlied: and see if runtime pm is enabled for nouveau
20:13EmperorDAZ: powertop says "Bad" for Runtime PM for nvidia
20:13EmperorDAZ: it says bad for almost eberything
20:13EmperorDAZ: except for USB related stuff
20:22karolherbst: ohh maybe I load nouveau with runpm enabled
20:22karolherbst: could be fun
20:22airlied: okay so that rules out that crazy idea
20:23karolherbst: my computer will die :/
20:23EmperorDAZ: >>I probably should learn more about this project and contribute to it
20:24karolherbst: skeggsb: why does runpm work for me?
20:24airlied: karolherbst: you have an optimus?
20:24EmperorDAZ: >>Access to old semi discardable pcs (LGA775s) and a oscilloscope
20:24karolherbst: airlied: I use a dirty hack written by him
20:24airlied: EmperorDAZ: printks in nouveau_drm.c would be my next option
20:24karolherbst: with a spoilter that runpm might not work
20:25karolherbst: airlied: http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a1d7077da37dfe2c3f89d1445f5b78e63de5666c
20:25EmperorDAZ: what is the (main repo)/(up to date) of nouveau? https://github.com/imirkin/nouveau ?
20:25karolherbst: in the old commit was anotice
20:26karolherbst: fun times, nvkm_volt returns 0.6V for powered off cards
20:27airlied: karolherbst: that has nothing to do with runtime pm of itself
20:27airlied: that just allows the card to work at all
20:27karolherbst: I know, skeggsb just wrote somewher,e that runpm might not work
20:27karolherbst: and I had issues with runpm even with that hack some time ago
20:28airlied: well we fixed another runpm problem last week
20:28airlied: with fbdev
20:28airlied: EmperorDAZ: cgit.freedesktop.org/nouveau/linux-2.6
20:28airlied: linux-4.3 branch
20:29karolherbst: airlied: this is the kernel tree right?
20:30karolherbst: okay, if the pwerf would be a bit better I could really ditch the blob now :D
20:31diegoviola: is reclocking ever going to be possible
20:31karolherbst: diegoviola: it completly works for me card
20:31diegoviola: which card
20:31karolherbst: gtx 770m
20:32karolherbst: kepler gddr5
20:32diegoviola: dynamic reclocking you mean?
20:32diegoviola: same as blob
20:33diegoviola: I haven't used nouveau in ages
20:33karolherbst: well I have a userspace daemon which does dynamic reclocking for me
20:34karolherbst: don't know when the kernel implementation will be ready
20:34karolherbst: mayb 4.5 or 4.6 or 5.0
20:34karolherbst: who knows
20:34EmperorDAZ: airlied: what do you mean by printks
20:35karolherbst: diegoviola: tesla and kepler reclocking works quite well now
20:35karolherbst: diegoviola: and I will implement some dynamic reclocking stuff for gt215 chips and newer
20:39karolherbst: EmperorDAZ: do you know how to compiler your own kernel?
20:39EmperorDAZ: given time and a internet connection I will know how to
20:40EmperorDAZ: I dont know yet
20:40EmperorDAZ: I can learn it up, I have a good amount of free time
20:41karolherbst: I would say either try to install LFS or gentoo/Linux is the best/hard way to lern it :D
20:41karolherbst: like you never done it before, and then you actually have to get it right, because otherwise your system won't boot :p
20:42EmperorDAZ: does VM count?
20:42karolherbst: this isn't a bad idea indeed
20:42karolherbst: EmperorDAZ: https://wiki.gentoo.org/wiki/Handbook:Main_Page
20:42EmperorDAZ: else I will have to find some scrap/useless HDD and strap one of my unused LGA775 system
20:42karolherbst: LFS is a little bit too much
20:43karolherbst: EmperorDAZ: but compiling kernel is much easier then installing gentoo
20:43karolherbst: gentoo is just a fun way to bootstrap your entire system yourself
20:44karolherbst: and you learn a lot about unix and stuff
20:44karolherbst: but for the sake of nouveau stuff testing out
20:44EmperorDAZ: I recently bought a PCIe RS232 card so I think I wont need to plug-unplug my keyboard if I am to use a real system for this
20:44karolherbst: EmperorDAZ: you can also use this tree: http://cgit.freedesktop.org/~darktama/nouveau/
20:44karolherbst: there you can compile just nouveau
20:44EmperorDAZ: thanks for the tips
20:44karolherbst: and install it into your system
20:45karolherbst: then you don't need to touch the kernel
20:45EmperorDAZ: GCC right?
20:45karolherbst: and a bunch of other stuff
22:05imirkin: upon a more careful look at what's going on, what glamor is doing seems perfectly ok
22:14imirkin: skeggsb: is there any difference between the gart and vram dma handles for tesla (with nouveau)?
22:19skeggsb: nope, they both map over the entire channel address space
22:19skeggsb: we still have two for legacy reasons, there's no good reason to do so anymore
22:19imirkin: was just checking
22:38vducuy: hi all, how can i change bpp to 16 when booting? default is 32 for 3.18.20 kernel. thanks
22:39imirkin: you mean for fbcon? or for X?
22:40vducuy: i boot from u-boot. do we have any parameter to set when boot?
22:40imirkin: looks like you could do something like video=1024x768-16
22:41vducuy: thanks. let me try
22:41imirkin: i haven't personally tried that
22:41imirkin: just reading the docs
22:55vducuy: tried both video=1680x1050-16 and video=1680x1050,bpp=16. does not work
22:56imirkin: what if you specify your connector as well?
22:56imirkin: e.g. video=DVI-I-1:1680x1050-16
22:58vducuy: i used VGA analog port. how to specify?
22:59imirkin: vducuy: it's whatever it comes up as... 'git grep /sys/class/drm/card*-*/status' should help you figure it out
22:59imirkin: make that
22:59imirkin: 'grep . /sys/class/drm/card*-*/status'
23:01vducuy: sys/class/drm/card0-DVI-I-1/status:disconnected /sys/class/drm/card0-TV-1/status:disconnected /sys/class/drm/card0-VGA-1/status:connected
23:04vducuy: it WORK
23:04vducuy: thank imirkin
23:04imirkin: with VGA-1:1680x1050-16?
23:04imirkin: btw, curious why you want this...
23:05imirkin: using a TNT or something?
23:05vducuy: yeap. video=VGA-1:1680x1050-16
23:05vducuy: no. i run android
23:05vducuy: and android not support bpp=32
23:07imirkin: weird... i won't even bother wondering why not
23:07imirkin: skeggsb: this seems like a more plausible patch: http://hastebin.com/tutazepagu.coffee
23:08vducuy: it's because i used built-in android EGL engine. not openGL yet
23:09imirkin: EGL isn't directly connected to opengl... fyi there has been a bunch of effort in getting mesa to play nice with android
23:13vducuy: next steps i have to make mesa work with android. still learning how to do
23:16skeggsb: imirkin: building...
23:16imirkin: skeggsb: well that'll only help for nv50
23:16imirkin: skeggsb: i need to do something similar for nvc0... i can't repro the issue on my GF108 though
23:17imirkin: ultimately it's still a hack though. i don't see what the serialize would do there
23:19skeggsb: oh, i didn't notice the nv50-ness
23:19imirkin: i had a trace with oddness on nv50 though... need to find it
23:19imirkin: this might fix that issue as wlel
23:23skeggsb: what other fermi+ boards do you have btw? interested to know if it happens on everything *except* nvc1
23:24skeggsb: err, gf108
23:24skeggsb:still needs to get used to that
23:24imirkin: i have a GF108 here and GK208 at the office, i can check that out tomorrow
23:24imirkin: oh, and a GK20A sitting on a shelf
23:27imirkin: nooope. no help there.
23:31imirkin: skeggsb: this is an equivalent version for fermi+ : http://hastebin.com/qebebuwamo.pl
23:31imirkin: [ok, not completely equivalent... but a little equivalent ;) ]
23:32skeggsb: somewhat smaller :)
23:35hakzsam: imirkin, the only stuff I fixed which could be related to is an unaligned memory access when reading couters using that compute kernel. ButI I think this has been fixed as a side effect and probably by you. Anyway, I'll enable compute support by default on Fermi and if someone use those MP counters and complain about 3D sutff, I'll fix it :)
23:35imirkin: hakzsam: iirc things were going wrong even without using MP counters before, no?
23:36hakzsam: I don't think because compute support is currently only used by MP counters
23:38hakzsam: I mean, it's not possible to test that compute support without using them
23:38imirkin: i thought before compute would get initialized by default
23:38imirkin: on any nvc0 screen
23:38imirkin: and that was breaking things
23:40hakzsam: yes, it is initialized by default but that weird 3D effects only happened when lauching a compute kernel
23:40skeggsb: i suspect some of the state might alias?
23:41imirkin: seems likely
23:41hakzsam: no idea
23:41skeggsb: the class interface is only a wrapper around the "real" state, so it's not inconceivable that the compute class tramples some of the same state that we expect to be persistant when using fermi/kepler/maxwell classes
23:42imirkin: skeggsb: well iirc we're missing something in ctxsw for GK110+ for compute right?
23:42skeggsb: not that i know of
23:42hakzsam: skeggsb, okay, makes sense
23:42skeggsb: simple test: invalidate all 3d state after using compute and see
23:43imirkin: there's a bit more to it
23:43imirkin: there's nvc0->state which keeps track of some things
23:45imirkin: although those things are unlikely to alias to the compute stuff
23:45skeggsb: imirkin: shockingly enough, that patch seems to actually work
23:45imirkin: skeggsb: that's quite sad :(
23:46mupuf: skeggsb: hey, did you hear about the context switching bug on the gf100/110? I tried having a look at it and I really looked like a monkey with a stick
23:46skeggsb: there was another type of corruption i was seeing that was harder to reproduce, but i suspected was related.. i'll see if that's gone too, but it'll take some time
23:46mupuf: basically, some of the counters are not context switched
23:46hakzsam: imirkin, I'll be glad to fix the problem if someone complain when compute support is enabled by default :)
23:46hakzsam: mupuf, he knows
23:46hakzsam: I sent him an email yesterday night
23:47skeggsb: mupuf: hakzsam emailed me about it earlier, i believe nvidia separate the pm context from the rest and make it optional
23:47skeggsb: we don't implement it at all
23:47mupuf: that's fun that it works at all then
23:47skeggsb: it's not surprising it works, we still set the default values, but don't context switch them
23:47skeggsb: our ucode is somewhat... simpler.. than nvidia's
23:47mupuf: is it a different address space you need to copy? I did not see a list of registers, it looked like we just dumped everything
23:48mupuf: no, I mean, many registers related to the MP are context-switched
23:48mupuf: we made sure of that
23:48mupuf: some counters are not context switched though
23:49skeggsb: yes, nvidia split it out for some (presumably good) reason, so it's only context switched for clients that use it
23:49mupuf: and it apparently works on other fermis, so I guess they decided not to make it optional anymore
23:49mupuf: well, that can make sense, why store state that is unecessary?
23:49mupuf: it takes up memory bandwidth
23:49hakzsam: and that only happens on some boards especially when they have more GPCs/TPCs than others
23:50mupuf: but the hw already knows about the usage of the counters, so I wonder why they decided to involve the kernel in this :s
23:50skeggsb: the hw doesn't decide what's context switched, that's what the ucode does
23:50mupuf: ack, but the hw could keep track of it, that's what I meant
23:52mupuf: I guess we could check that the SEL register is not 0 and only context switch if this is true
23:52hakzsam: mupuf, as skeggsb told me, I'll have a look at the android gk20a code to get some inspiration about that
23:52hakzsam: mupuf, nope, SEL can be 0 (ie. active_cycles)
23:52mupuf: ok, please fw me the email
23:53mupuf: skeggsb: thanks, have to go now!
23:53hakzsam: have to go too, see you
23:53mupuf: I see
23:54skeggsb: imirkin: i'm guessing that serialise is undesirable in general?
23:54hakzsam: mupuf, well, I think we can decide to context switch if the MP mux is enabled or not
23:54imirkin: skeggsb: i'm guessing as well