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