00:37mlankhorst: yeah it's fun :)
02:03xexaxo: imirkin: udev does not imply libudev (and vice versa) afaict. the latter is supposed to be a wrapper/helper around sysfs (not 100% accurate but still).
02:04xexaxo: the good thing is that we fall-back to libdrm/ioctls if libudev fails. the former works 98% of the time.
02:06xexaxo: with the final 2% is the non render-node opencl, as auth is not always done.
02:17zerwas: When using Google Maps with WebGL in Chrome I get reproducible freezes with Nouveau (using GeForce GT 610, xorg-edgers PPA on Ubuntu 15.04). Magic SysRq still reacts (but can't switch to text console).
02:27karolherbst: imirkin: okay, so may computer didn't wake up with runpm enabled and nouveau still loaded
02:37karolherbst: :/ this trace is really heavy, running through callgrind for 5 minutes and still nothing yet :/ I think I actually have to do stuff while this is running
03:32Kiranos: Hi I thought I was going to start using nouveau instead of propitiary drivers for my desktop, have to reconfigure nvidia settings after every kernel upgrade.., but I read now that nouveau has very limited support for multiple monitors?
03:32Kiranos: I have two graphics cards and one card has 2 monitors and the second have 1 monitor
03:32Kiranos: so three monitors in total, is there work beeing done to support this ?
06:45karolherbst: Kiranos: try it out. If it works it works, if not then maybe the issue can be fixed
08:04imirkin: skeggsb: thoughts on missing PCIR section in OF VBIOS?
08:13skeggsb: imirkin: ugh, it probably makes sense that it wouldn't have it...
08:14skeggsb: not entirely certain on what to do there
08:24karolherbst: man, like I run the valgrind memcheck tool on the trace for 30 minutes without finding anything, because the mem usage peek is at the end and then my X just crashes before it can fiish
08:24imirkin: skeggsb: perhaps add a no_pcir bit to the thing? the pcir is only used for multi-image things right?
08:25skeggsb: that, and as an extra sanity-check, but yeah, something like that is probably the only option
08:26imirkin: presumably this can only happen with OF
08:26imirkin: at least they're the only ones that have complained :)
08:29mogorva: any idea how I can help debug this: https://bugs.freedesktop.org/show_bug.cgi?id=91187
08:29karolherbst: mogorva: valgrind?
08:30karolherbst: but why do you think its memory related?
08:30imirkin: mogorva: the game dereferences a null pointer. this will be difficult to figure out why.
08:30mogorva: yes, i thought of valgrind. the problem is that valgrind crashes when running that game: aspacem <<< SHOW_SEGMENTS: out_of_memory (670 segments, 127 segnames)
08:30imirkin: i suspect it's because a malloc fails
08:31imirkin: and it doesn't expect that
08:31imirkin: but then the question is... why does it use up oodles of memory. and that i do not know.
08:31mogorva: this is the result of my valgrind run: http://hastebin.com/kovulilaro.xml
08:31karolherbst: maybe you should ask the wine guys, the usually know whats up there
08:31imirkin: perhaps the windows drivers are more generous about not littering the process VM space with GPU bo mappings
08:33karolherbst: imirkin: I trimmed down the metro apitrace... 6 frames, maye 62,000 calls in total, but still 1.7GB big
08:33mogorva: i have 8 GB ram installed, in top I noticed that the game peaked at 2 GB memory usage
08:34karolherbst: 2GB is like nothing, what about your system RAM usage?
08:35karolherbst: I only start to worry if its like 5GB
08:35karolherbst: but fear 2?
08:35imirkin: mogorva: well, it's a 32-bit process... are you using a 64-bit kernel?
08:35karolherbst: I have that game, I may try it even out on my system
08:35mogorva: no, it's 32-bit
08:35mvaenskae: cheers, anyone in here with an nvidia k2100?
08:35imirkin: ok, so you either have a 2/2 split or a 3/1 split. probably the latter
08:36imirkin: so 3G is the max any process can really use, and i bet 1G of that is wasted on GPU bo mappings
08:36mlankhorst: I don't think anyone supports a 2/2 split any more. :P
08:36mlankhorst: there were some patches to support a 4g/4g split which was interesting
08:36imirkin: mogorva: even if you run 32-bit userspace, you should still run a 64-bit kernel, if your hw is capable.
08:37mvaenskae: i am looking for reports on how well the gpu works with nouveau (sadly either the k2100 or an amd firepro m5100); i am currently checking out either the dell m4800 and the hp zbook 15 g2 and was wondering how well those are supported in the graphics department by nouveau
08:37imirkin: mvaenskae: definitely go with amd if you're looking for GPU power.
08:37imirkin: (and open drivers)
08:37mvaenskae: i am mostly looking for the gpu to just be supported
08:37mogorva: i compiled 4.1.2 a few days ago, which is the kernel option I should look for?
08:37karolherbst: mogorva: 64bit
08:38karolherbst: its on the most top menu I think
08:38imirkin: mogorva: well, you'll also need a gcc capable of producing 64-bit binaries
08:38mvaenskae: the thing is, the dell m4800 only sells their UHD displays with the k2100 and no hybrid support
08:38imirkin: mvaenskae: yeah, actually a few people have come in regarding those laptops iirc
08:38imirkin: mvaenskae: with nothing particularly good to say as i recall :)
08:38karolherbst: mvaenskae: so a laptop just with a nvidia card?
08:38imirkin: mvaenskae: search bugs.freedesktop.org for m4800
08:39mvaenskae: karolherbst: in essence yes, unless i go with the FHD display
08:39mogorva: i have CONFIG_X86_32=y & CONFIG_X86=y in the kernel config
08:39imirkin: mogorva: you want CONFIG_X86_64=y instead
08:39karolherbst: actually its CONFIG_64BIT for me, but maybe my kernel is too much patches
08:40imirkin: oh heh. maybe.
08:40mvaenskae: imirkin: currently looking :)
08:40karolherbst: its in the most top meu for me
08:40karolherbst: make menuconfig
08:40karolherbst: it should be there
08:40imirkin: we were both right ;)
08:40karolherbst: I think the latter is for executing stuff
08:40karolherbst: because x32 biary support is called X86_X32
08:41imirkin: yeah, but i doubt you can build a 64-bit kernel without 64-bit binary execution support
08:41imirkin: the arch is x86_64 though -- arch/x86/Kconfig:config X86_64
08:41mogorva: but i don't have such problem with FEAR2 when using the binary drivers, and the stock Fedora kernel I used also had CONFIG_X86_32=y & CONFIG_X86=y
08:41imirkin: mogorva: yeah, this isn't supposed to fix things
08:41imirkin: just hopefully make your system faster and better able to use more memory
08:42mogorva: i see
08:42imirkin: since with 8GB you're stuck using PAE to reach it
08:42imirkin: which iirc has to go through a bounce region, etc
08:42karolherbst: currently I am also debugging an oom situation on my system
08:42karolherbst: but with oom I mean like kernel oom, killing processes ad stuff
08:43karolherbst: once also a kernel thread was killed :/
08:43mogorva: yes, I have 'CONFIG_X86_PAE=y' set
08:43karolherbst: yeah, but PAE is just for total system memory, isn't it?
08:43imirkin: karolherbst: yeah. but the kernel isn't as free in what it can do with PAE
08:44karolherbst: yeah, right
08:44imirkin: it's just a giant annoyance... better use a 64-bit kernel
08:44karolherbst: I think it can only be used inside virtual mapping
08:45mogorva: unrelated to the FEAR2 issue, some other games under Wine+Valgrind crash with 'vex x86->IR: unhandled instruction bytes: 0x2E 0xFF 0x15 0x7C'
08:45imirkin: valgrind suckage =/
08:45mogorva: i nowhere found that specific intructions mentioned in valgrind bugzilla
08:46imirkin: hmmmm.... those do look invalid actually
08:47imirkin: oh, i think it just wants more bytes
08:47karolherbst: can be anything
08:47karolherbst: mogorva: everything beyond sse2 isn't supported inside 32bit libVEX
08:48mogorva: umm, could it be due to that I selected Athlon K8 optimizations when I configured the kernel?
08:49imirkin: but it could be due to those optimizations if you built any userspace libraries with them, like glibc or mesa
08:49karolherbst: and a bunch of others
08:50mogorva: i didn't touch glibc, it's from the Fedora repos, I compiled mesa with CFLAGS="-Og -ggdb -g -gdwarf-2 -gstrict-dwarf"
08:50karolherbst: imirkin: I actually found a pattern while running with memcheck with my bug: it claims some memory and then around 66% of this is freed a little bit later
08:52karolherbst: imirkin: memcheck doesn't really help "still reachable: 900,347 bytes in 3,114 blocks"
08:52karolherbst: that's like nothing
08:52mogorva: regarding the 'unhandled intruction' error from Valgrind, is it possible that I have something misconfigured?
08:52imirkin: mogorva: no
08:52karolherbst: "definitely lost: 1,168 bytes in 5 blocks"
08:53karolherbst: mogorva: as I said: a bunch of X library can have newer instructions than sse2
08:53karolherbst: then 32bit valgrind simply fails
08:53karolherbst: its as simple as that
08:53mogorva: karolherbst: would you mind checking FEAR2 in wine on your part when you have time?
08:54karolherbst: I am currently downloading it
08:54karolherbst: was there some kind of bad drm?
08:54mogorva: dunno, mine is the GOG version
08:55karolherbst: mhh I see
08:55karolherbst: imirkin: is it normal, that mesa spends like 6% of its cpu time inside calloc?
08:56imirkin: karolherbst: normal? probably not. expected? sorta.
08:56karolherbst: its while loading and shader compilation time
08:56karolherbst: so yeah
08:56karolherbst: memcheck doesn't help me much here :/
08:56karolherbst: any idea how I can track allocations inside the kernel?
08:57imirkin: kmemleak but i doubt your issue is inside the kernel
08:58karolherbst: the think is, that I can't relly get a trace without the process getting oomed out
08:58imirkin: that's unfortunate, but hardly a kernel issue
08:58karolherbst: currently it looks somehow like this: mesa is allocation a lot of memory, maybe also the kernel stores a lot of drm stuff, but its not lost, it just currently worked on
08:59mogorva: imirkin: re bug #91314, is it normal that the assertion occurs only when mesa was compiled with '--enable-debug' flag but the game starts fine with a non-debug mesa build?
09:00imirkin: mogorva: yes
09:00mogorva: i forgot to mention in the bug report that I used a debug enabled mesa
09:00karolherbst: it starts on my system
09:00imirkin: otherwise you wouldn't have hit that assert :)
09:00imirkin: asserts are compiled out in non-debug builds
09:01mogorva: karolherbst: can you start a new game?
09:01karolherbst: I can even load my saves
09:01karolherbst: I just get some shader issues, but that's all
09:01mogorva: in the options menu, do you have texture LOD set to medium or high?
09:02karolherbst: all to lowest for testing
09:02karolherbst: I had a video somewhere too :)
09:03mogorva: what happens if you set texture lod to the maximum and everything else is kept on the minimum?
09:05karolherbst: whre is texture lod?
09:05mogorva: somewhere in performance options
09:06karolherbst: are we talking about the same game?
09:06mogorva: i'm talking about FEAR2
09:06karolherbst: ahh, no I meant witcher 2 now
09:08karolherbst: imirkin: after retracing the trimmed part of the trace, there is not really anything going on inside mesa
09:09karolherbst: but I have a bunch of addresses as function name inside kcachegrind, do you know how to resolve them?
09:10karolherbst: maybe I should also test FEATURES=nostrip :/
09:11imirkin: or at least splitdebug
09:11karolherbst: I have this already
09:11karolherbst: but some applications doesn't read the debug file locatons out of the binaries
09:11imirkin: ah, you should be able to resolve them with gdb then
09:11karolherbst: this is no problem, but like custom stack tracers like the X one won't resolve them
09:13karolherbst: mogorva: http://www.filebin.ca/28HiNotNjuI1/out.mp4
09:13karolherbst: fun, isn't it?
09:15mogorva: karolherbst: cool...i see those flashing, colored polygons when opening the inventory: http://imgur.com/BwivyIC
09:18Yoshimo: doesn't look that bad though
09:19karolherbst: its actually a pretty cool effect :)
09:20karolherbst: for example, it shows you exactly when you look not down to the ground, because as long as you do this, there is no such glitch
09:30karolherbst: nice, now its better with nostrip
09:31karolherbst: imirkin: 8k calls to reference_buffer_object?
09:43hakzsam: imirkin, the nv50 rotate logic is already implemented, we have nothing to do in this area. However, you're right for nv50_query_result()
09:43imirkin: hakzsam: oh. so it is.
09:43imirkin: just differently than on nvc0
09:44hakzsam: yes, a bit different
09:44imirkin: hakzsam: only diff is that it doesn't reallocate
09:45imirkin: oh wait. it does. ok.
09:45hakzsam: yeah, it's similar
09:45hakzsam: I checked all occlusion_query piglit tests, they are okay
09:56imirkin: hakzsam: you typo'd you S-o-B line
09:57hakzsam: yes, I saw that
11:59karolherbst: okay, maybe my X11 crash is just lto caused? :/
12:00karolherbst: but then again, why didn't I added xorg-server to my list of software for which lto is disabled?
12:29karolherbst: imirkin: do you know any other idea how I could check for the error? :/ I was already thinking about just bisecting the patches, but I just think I will land at the commit, which enabled subroutine support
13:27karolherbst: imirkin: I can confirm your talos demo problems
14:39karolherbst: imirkin_: what's your build issue with vogl? It built fine here, but I am using Qt 5.4.2
14:40imirkin_: i filed a bug
14:42karolherbst: seems like someehre internally a #include <QObject> was removed
14:42imirkin_: i know absolutely nothing about QT
14:42karolherbst: you could add one at the top of ../src/vogleditor/vogleditor_qsettings.h
14:42karolherbst: then it should work
14:42imirkin_: except that it takes an enormous quantity of resources to build
14:43karolherbst: boost is worse
14:43imirkin_: and almost no applications i care about use it
14:43imirkin_: boost is quite horrid too, but nowhere near QT's scale
14:43karolherbst: but thats the deal with c++
14:43imirkin_: not at all.
14:43imirkin_: just these libraries.
14:43karolherbst: its normal that a c++ compiler needs more ressources
14:43karolherbst: yeah if you don't use templates, then not
14:43imirkin_: but boost is full of meta-programming abuse
14:44karolherbst: yeah true :D
14:44imirkin_: and my complaint about qt is that the lib itself takes forever to build
14:44karolherbst: but still awesome
14:44karolherbst: never did anything qith Qt itself though
14:44karolherbst: but I think only qtwebkit needs really a lot of time
14:45karolherbst: the other parts still in "reasonable" time though
14:45imirkin_: karolherbst: that seems to fix that particular error, thanks!
14:45karolherbst: but a lot of "qt-like" stuff needs a lot of time to compile: mono, icedtea, boost. Its not that easy if you want to add an extended standard library for everything
14:46karolherbst: in C it isn't that bad, because a lot of usefull libraries have a C api
14:46karolherbst: but then in c++ you begin to write C++ wrapper around these, like libcurl
14:46karolherbst: or other boring stuff
14:47imirkin_: karolherbst: if you have a github handle, happy to reference you in my "fix" comment
14:47karolherbst: https://github.com/QupZilla/qupzilla/issues/970 :)
14:47karolherbst: seems like this issue
14:48karolherbst: everytime I see a "header cleanup" fix, because the seems to be obviously not needed anymore, I get a strange feeling, and then issues like this happens :D
14:49imirkin_: GAH!!! the minimum width of the window is 1210 pixels
14:49karolherbst: which tool?
14:49imirkin_: clearly these people have never heard of rotated 1920x1200 monitors
14:50karolherbst: ahh width
14:50karolherbst: but still
14:50karolherbst: easy to fix though
14:50karolherbst: wait a sec
14:50karolherbst: sure about 1210?
14:50imirkin_: that's what windowmaker says
14:50imirkin_: i tend to trust it in these matters
14:50imirkin_: 1210x824 is the min size
14:51karolherbst: mhh to bad
14:51karolherbst: no magic nuimbers inside the code
14:51imirkin_: nah, probably just the sum of a few panels
14:52karolherbst: what a cmake abuse
14:52karolherbst: they create directories outside the build directory
14:52imirkin_: cmake = insane
14:53karolherbst: nah, cmake is fine, but a lot of people can't use it right :D
14:53karolherbst: its pretty nice if you want to develop for and on every platform
14:53karolherbst: mesa has to maintain two build systems, right?
14:55imirkin_: no has explained to me what's wrong with autoconf beyond vague "it doesn't work on windows" claims, even though i know first-hand that it works just fine
14:55karolherbst: its messy though
14:55imirkin_: it works
14:55imirkin_: which is more than can be said of all the other ones
14:55karolherbst: yeah, but you have to install unix tools before
14:55imirkin_: so what
14:56imirkin_: you have to install a compiler too
14:56imirkin_: and the build tool
14:57imirkin_: autoconf has fairly free cross-compiling, assuming that you don't go out of your way to do bad things
14:57imirkin_: cmake barely even works with distcc
14:57karolherbst: yeah pre 3 cmake had not that good crosscompiling support either
14:59karolherbst: but usually it should just work if you set the compiler right :/
15:00karolherbst: running metro thourhg vogl may be interessting :)
15:00karolherbst: allthough mhh
15:07karolherbst: imirkin_: do you think metro 2033 redux will run only with the subroutine patches applied and overrides to GL4.0?
15:07imirkin_: that's my understanding, yes
15:08imirkin_: i don't have the game myself
15:08karolherbst: yeah, I did something wrong before
15:08karolherbst: no, it runs fine
15:08karolherbst: but the memory usage is still damn high
15:09karolherbst: so at least I know that the other patches don't do anything stupid
15:09karolherbst: this is a mess to debug, seriously :(
15:14imirkin_: well, afaik others got it to run on radeonsi
15:14imirkin_: no mention of memory issues
15:15karolherbst: either my setups is messed up or some nouveau issue
15:15karolherbst: I think I know what I do. I will simply test other games and compare memory usage betwee nouveau and intel
15:16imirkin_: well, nouveau probably maps in too much GPU VM into the CPU VM
15:16imirkin_: so you end up with double or even triple usage of space
15:17karolherbst: I am pretty sure, that with more RAM the game would really run
15:17karolherbst: because in the main menu there is already a 8-9GB spike
15:17karolherbst: but it falls back to around 3GB
15:25karolherbst: mhh other games behave fine
15:25karolherbst: imirkin_: are there any subroutine tests in piglit already?
15:25karolherbst: wait I can check that myself
15:26karolherbst: ahh there they are
15:26karolherbst: maybe the piglit tests are sufficient eough
18:09smoking-peanuts: I am having issues with compiz and nouveau.. I am not having issues with gnome metacity where should I start troubleshooting?
18:16cjashfor2: I have a Lenovo W520, with only discrete graphics enabled, and when I plug in the second of two external monitors, the system screens go blank for awhile, and then appear to reset every few seconds. Looking at the output of dmesg, I see that gnome-shell gets a segfault in libmutter.so.0.0.0. Does that sound familiar to anyone here?
18:19cjashfor2: This is on Fedora 22, by the way. xorg-x11-drv-nouveau-1.0.11
18:27Uramekus: running Glxinfo using dri3/glamor my X crashes.
18:28Uramekus: do anyone know if that bug it's already listed? or if there is a workaround/fix for it?
18:29smoking-peanuts: I am am getting a gpu lockup when using compiz with nouveau driver
18:30Uramekus: try logging with LIBGL_DEBUG=verbose to a text file
18:45smoking-peanuts: anyone else around?