00:58karolherbst: imirkin: your gl-integration branch is just a merge of 2-3 branches? Or is there more to it?
01:38karolherbst: imirkin: I think there is an issue on the i965 side of that branch :/ investigating
01:39karolherbst: this mesa commit messes it up a bit: http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/drivers/dri/i965/brw_context.c?id=6e255a3299c9ec5208cb5519b5da2edb0ce2972b
02:55karolherbst: imirkin: rebased on current mesa master, hopefully without any issues (will run piglit anyway now): https://github.com/karolherbst/mesa/commits/gl4-integration-4
03:54karolherbst: maybe I will just fix some piglit tests which may be related to the bugs I found :/
03:54karolherbst: there are more than ony my intel card, so it might make sense
04:03karolherbst: ohh piglit got me hardware error
04:03karolherbst: I mean like dmesg errors and stuff
04:38karolherbst: yay, OpenGL 4.1 :)
04:41karolherbst: imirkin: the patches seems to harm my intel OpenGL state a bit :/
04:53karolherbst: seems like I was wrong :/
04:54karolherbst: okay, nice
05:09karolherbst: imirkin: metro 2033 redux, mem requiernment: 20GB+ :) https://gist.github.com/karolherbst/b86339b0c3ed143a5774
05:17karolherbst: also biochock infinite doesn't display anything usefuell, the cursor and the subtitles are fine though
08:20imirkin: karolherbst: i only count 12GB :)
08:22karolherbst: kernel + process
08:22karolherbst: I have 16 GB
08:22karolherbst: freshly rebooted less than 1GB desktop usage
08:22imirkin: i guess we're leaking oodles of ram somewhere... if you want to figure out where, that could be useful.
08:22karolherbst: then metro round about 10% in the intro meu
08:22imirkin: btw, what did you mean about messing up intel state?
08:23karolherbst: then while continueing the game: metro stable at 10%, but RAM usge goes up to 15GB + the other stuff
08:23karolherbst: I thought a lot of more piglit tests would fail :/
08:23karolherbst: but there isn't that much, could be random stuff
08:24karolherbst: there are some fixes, some regressions
08:24karolherbst: but I am also hit by this bug: https://bugs.freedesktop.org/show_bug.cgi?id=91317
08:24karolherbst: so who knows
08:24karolherbst: with swap enabled, I also got like 16GB RAM full + 3GB swap
08:25karolherbst: this wasn't that funny
08:25karolherbst: couldn't even ssh into the machine anymore
08:27karolherbst: imirkin: I would llike to take a screenshot of the bioshock problem, but it always minimizes itself while switching applications... x11grab I guess :(
08:29imirkin: karolherbst: for bioshock, are you using a debug mesa build?
08:30imirkin: i suspect there's some kind of error going on... that tends to be the thing when you just see black
08:30karolherbst: I don't see black
08:30karolherbst: will show you
08:30karolherbst: doesn't look like random data either
08:30imirkin: well, either way, would be interesting to see a debug build
08:31karolherbst: whats the difference?
08:31imirkin: it will print stuff like "Mesa user error: bla"
08:31karolherbst: I see, k
08:31karolherbst: will build with debug then
08:31imirkin: for illegal things the thing does
08:32karolherbst: I suspect it has something todo with the new features, but who knows
08:33karolherbst: there was only one conclict I wasn't sure about in the rebase process and it was inside radeonsi stuff
08:39karolherbst: imirkin: but in metro 2033 redux the main menu is rendered pretty nice, performance isn't the best though
08:42karolherbst: imirkin: could it be a in kernel memory leak by the way?
08:43karolherbst: or userspace isn't telling, that something can be freed?
08:44karolherbst: wow, that was fast
08:44karolherbst: imirkin: bioshock gives that: Mesa: User error: GL_INVALID_OPERATION in glTexImage2DMultisample(internalformat=GL_RGB9_E5)
08:46karolherbst: metro gives this with debug: ir_swizzle @ 0x64ca790 specifies a channel not present in the value. (swiz xy (swiz x (swiz x (var_ref vec_ctor) )))
08:53karolherbst: I bet nobody did care enough to implement GL_RGB9_E5 stuff in mesa?
09:01karolherbst: imirkin: error was totally unrelated, bioshock wasn't starting because I launched it from cli and forgot to set LD_LIBRARY_PATH :/
09:02karolherbst: other errors: Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=GL_MAX_COMPUTE_UNIFORM_BLOCKS)
09:02karolherbst: Mesa: User error: GL_INVALID_OPERATION in glCopyImageSubData(extension not available)
09:04karolherbst: okay, it seems like it just renders that whats in the buffer left :/
09:09karolherbst: imirkin: seems like bioshock requires ARB_copy_image
09:12mogorva: imirkin: re: bug #91314: I get this from gdb, does this make sense to you? http://hastebin.com/wavehocuhu.vhdl
09:14karolherbst: imirkin: intel already implemented ARB_copy_image allthough its not stated in the gl3.txt file
09:14karolherbst: ohh no, its listed, my fault
09:22glennk: karolherbst, GL_RGB9_E5 is supported, but not as a render target in GL (no hardware does that)
09:38karolherbst: glennk: yeah, was a false alarm anyway
09:38imirkin: karolherbst: ugh, it uses glCopyImageSubData without checking for ARB_copy_image or whatever the ext is =/
09:38karolherbst: yeah its ARB_copy_image
09:38imirkin: do you get a ton of those errors? or just a few?
09:39karolherbst: a ton
09:39imirkin: ok yeah, it's probably coz of that then :(
09:39imirkin: on the bright side, the vmware guys said they were working on that and ARB_clear_texture
09:39imirkin: mogorva: you have to run "up" a few times, until you're in the function that called the assert
09:40imirkin: _mesa_init_teximage_fields (ctx=0x2055bed0, img=0x204c7420, width=0, height=0, depth=0, border=0, internalFormat=0,
09:40imirkin: that's a pile of crap
09:44mogorva: imirkin: http://hastebin.com/odepefumab.xml
09:44imirkin: mogorva: thanks
09:56karolherbst: imirkin: do you know if there is some work in progress branch for ARB_copy_image=
10:00rpirea: karolherbst http://pastebin.com/kKvQEwY9
10:00rpirea: it's kernel 4.1
10:01imirkin: karolherbst: i think someone gave it a shot at one point... it's the type of extension whose 99.9% of functionality takes 2 lines of code, but handling the edge cases is incredibly difficult and confusing, at least in gallium
10:01rpirea: nvidia 840m, case 0x118 added manually to gm100.c(something like that)
10:01imirkin: rpirea: that all seems fine.
10:02imirkin: karolherbst: on the bright side, i965 supports ARB_copy_image (and ARB_clear_texture)
10:03rpirea: imirkin [ 8.867713] nouveau E[ DRM] Pointer to flat panel table invalid
10:03imirkin: rpirea: yeah that's fine
10:03rpirea: ok :D
10:03rpirea: tnx a lot
10:03imirkin: i'm not thrilled about the GPC/HUB errors, but they're probably ok too
10:05imirkin: psaisanas: hmmm... can you pastebin a dmesg from a regular boot?
10:10rpirea: imirkin do you know how to use nvidia graphic card?
10:10rpirea: i have nvidia an intel, hybrid
10:11imirkin: rpirea: http://nouveau.freedesktop.org/wiki/Optimus/
10:26rpirea: imirkin not working
10:26rpirea: Provider 1: id: 0x4f cap: 0x5, Source Output, Source Offload crtcs: 0 outputs: 0 associated providers: 0 name:nouveau
10:27rpirea: DRI_PRIME=1 glxinfo | grep .... have the same output like DRI_PRIME=0
10:29imirkin: rpirea: and you ran the xrandr --setblaprovider thing?
10:30imirkin: rpirea: what version of mesa do you have?
10:32imirkin: hrm ok. i was hoping for 10.2 or something, before maxwell support was added :)
10:33imirkin: rpirea: can you pastebin your xorg log, and the full output of 'LIBGL_DEBUG=verbose DRI_PRIME=1 strace -f -e open glxinfo'
10:33rpirea: imirkin http://pastebin.com/jE6HXwwR
10:34imirkin: wtvr, you want the offloadsink one
10:34imirkin: xrandr --setprovideroffloadsink nouveau Intel
10:35karolherbst: imirkin: yeah I know that intel supports this, but I don't get it to run on intel sadly
10:35karolherbst: even with overrides
10:35imirkin: karolherbst: what does it complain about?
10:35rpirea: imirkin i want one of them working :) doesn't matter witch one
10:35karolherbst: "Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x8e89)"
10:35karolherbst: coult be unrelated though
10:36karolherbst: the game just says it needs 4.1
10:36rpirea: imirkin http://pastebin.com/6VNLEP5Q
10:37karolherbst: imirkin: right, it isn't set
10:37imirkin: rpirea: did 'xrandr --setprovideroffloadsink nouveau Intel' work?
10:37imirkin: or did you also get an error after running it?
10:38rpirea: imirkin yes
10:38imirkin: that wasn't a yes or no question
10:38rpirea: without error
10:39rpirea: brb 2 sec
10:39imirkin: and your xorg log?
10:43imirkin: ugh... why do people apply grep to logs when i just ask for the log :(
10:43imirkin: rpirea: that was not your xorg log
10:43imirkin: that was a tiny selection of your xorg log
10:44rpirea: imirkin http://pastebin.com/3fM809t5
10:45rpirea: all my xorg log
10:45imirkin: i bet i know what's going on
10:45imirkin: stupid glamor
10:46imirkin: the glamor integration in nouveau doesn't actually support DRI2
10:46imirkin: so... the quickest simplest easiest way for you to get this going would be to use DRI3, as detailed by that wiki page
10:48karolherbst: slowly I get the felling, that disabling dri3 inside binaries are not the brightest idea overall ...
10:48karolherbst: imirkin: if he is unlicky, his intel ddx has no dri3 support at all
10:49karolherbst: no, it has to be inside nouveau then
10:49karolherbst: my mistake
10:51rpirea: karolherbst i can recompile :)
10:51karolherbst: the arch packages looks file
10:51karolherbst: at least of the X server
10:53karolherbst: imirkin: are you sure about this anyway?
10:53imirkin: rpirea: there's another option which is to use my EXA maxwell impl, but then you have to turn off EXA for composite, otherwise it won't work
10:53karolherbst: oh I bet with "actually" you mean it seems like it would work, but it won't
10:54imirkin: karolherbst: no, it really just doesn't support DRI2 -- the DRI2 flag isn't set, you can't create core contexts, etc
10:54karolherbst: okay, I see
10:54karolherbst: imirkin: but in theory, should it work with a dri 2 intel DDX and a dri 3 nouveau ddx?
10:54imirkin: [coz GLX_ARB_create_context_something is predicated on dri2 being available.\
10:54imirkin: i'm not sure, but it seems doubtful
10:55imirkin: i assume that the whole flink thing isn't available either
10:55karolherbst: weird is, that the x server isn't loading the dri3 module
10:55karolherbst: allthough it should be built with it
10:56karolherbst: something is lacking dri3 support really hard
10:58rpirea: in xorg --confingure is set --enable-glamor
11:00karolherbst: imirkin: do you know if xf86-video-intel enables dri3 by default?
11:00imirkin: i know that it does not
11:01karolherbst: arch packages intel ddx with "./configure --prefix=/usr --libexecdir=/usr/lib"
11:01karolherbst: how explicit
11:04karolherbst: right dri3 is disabled by default in intel ddx
11:04karolherbst: rpirea: okay you can do this: build xf86-video-intel explicitly with dri3 enabled
11:05karolherbst: --enable-dri3 has to be passed to configure
11:08karolherbst: imirkin: I feel like setting my X crash bug to critical, but somehow that isn't a critical issue :( only super annoying
11:09rpirea: i think mesa doesn't have dri3
11:10karolherbst: rperier: that shouldn't be that important actually
11:10karolherbst: if your intel ddx driver starts with dri3 support then most of the stuff is done already
11:13rpirea: how i can check if my ddx driver have support for dri3?
11:16karolherbst: rpirea: it won't have it, because arch builds it with default arguments
11:16karolherbst: and default its off
11:17karolherbst: maybe your xorg.conf file also would help, just to be sure
11:19rpirea: done x86-video-intel have dri3 now
11:19karolherbst: then restart X :)
11:23rpirea: no sign of DRI3 in xorg log
11:23imirkin: rpirea: you also need something like Option "DRI" "3" or so
11:23karolherbst: imirkin: no, he doesn't
11:23karolherbst: it works for me without that
11:23imirkin: ah ok
11:23tobijk: it does work for me without as well :)
11:24imirkin: ok, ignore me ;)
11:24karolherbst: could be that xorg-server is stripped of its dri3 as well
11:24karolherbst: but why?
11:24rpirea: karolherbst https://wiki.archlinux.org/index.php/PRIME
11:24rpirea: in bottom of page
11:25rpirea: is something about mesa
11:25rpirea: " you need to recompile mesa with --enable-dri3"
11:25karolherbst: yeah try compile mesa with it too
11:25karolherbst: but the server should load dri3 anyway
11:25karolherbst: at least this is what I would expect
11:26tobijk: --enable-dri3 \ <-- from my xserver config
11:26tobijk: better be verbose about that
11:27karolherbst: xserver doesn't have a dri3 flag
11:27karolherbst: its always enabled as far as I know
11:28tobijk: AC_ARG_ENABLE(dri3, AS_HELP_STRING([--enable-dri3], [Build DRI3 extension (default: auto)]), [DRI3=$enableval], [DRI3=auto])
11:30rpirea: flag for threads of make is -j , right?
11:30imirkin: i thought there was an extra thing there
11:31imirkin: tobijk: how's your cull impl?
11:31tobijk: imirkin: i havent worked on it tbh, had to complete a little compiler for my studies
11:38rpirea: [ 224.434] (II) intel(0): direct rendering: DRI2 DRI3 enabled
11:38rpirea: and now
11:38rpirea: it's working :X
11:38rpirea: tnx a lot boys
11:38tobijk: try the offload first ;-)
11:39rpirea: Could not find provider with name nouveau
11:39tobijk: with dRI3 you dont need to do the --setprovideroffload dance
11:40rpirea: but without offload works
11:40tobijk: just do DRI_PRIME=1 app
11:40rpirea: DRI_PRIME=1 glxinfo | grep vendor
11:40rpirea: OpenGL vendor string: nouveau
11:40tobijk: there you go
11:42rpirea: but i should recompile lib32-mesa too :))
11:48imirkin: karolherbst: so i got the talos demo... i get really bad rendering with 10.6.1 even on the lowest gpu option. it seems like some if (do this) condition is being unstable
11:49imirkin: seems to be a function of the angle
11:58drbombay: trying to get nouveaufb working on new install, please help, machine is ppc G5 , here is dmesg http://dpaste.com/17MCNDQ
11:59imirkin: drbombay: can you provide your NVDA,BMP of file?
11:59imirkin: drbombay: someone else recently came in saying that something was messed up with OF, so perhaps it's an issue like that
12:00imirkin: you should be able to grab NVDA,BMP out of /sys i think.
12:00drbombay: checking now
12:05imirkin: drbombay: in the meanwhile could you provide a dmesg with "nouveau.debug=debug"
12:05imirkin: actually make that nouveau.debug=debug,VBIOS=trace
12:06karolherbst: imirkin: did you try the customize options?
12:06karolherbst: imirkin: and which gpu?
12:06karolherbst: I harldy get 10fps with on 07 with my 770M
12:07imirkin: karolherbst: nvc1, i set it to "lowest"
12:07imirkin: at 1024x768
12:07imirkin: but the point is that i saw render fail
12:07karolherbst: yeah doesn't matter much
12:07karolherbst: I see
12:07karolherbst: talos has an internal render resolution too
12:07karolherbst: so not just the window size matters
12:07imirkin: or a bug in the game i suppose
12:07karolherbst: no, its a setting
12:07imirkin: but basically depending exactly how i was turned it'd either render moss on stones or it wouldn't
12:08imirkin: and the whole lighting/shading situation would change
12:08karolherbst: the angle is imporant somehow
12:08karolherbst: don't know for the green wall though
12:08karolherbst: imirkin: is anything enable if you customize the gpu speed on lowest?
12:08imirkin: i suspect it's all related
12:08imirkin: yeah, crumbs
12:08karolherbst: doesn't really matter
12:09karolherbst: "no dynamic lightniing" should speed up the game a lot
12:09karolherbst: if you activate it
12:09imirkin: but the thing would display even without them
12:09imirkin: i ahve no idea what they are tbh
12:09imirkin: yeah, so futzing with that got me the redness
12:10imirkin: but even with it disabled, i still see messed up lighting
12:10imirkin: so i'm guessing it's all related
12:12karolherbst: i see
12:40rpirea: imirkin you told me to use a binary blob called ctxsw for better performance
12:41rpirea: how can i obtain?
12:41imirkin: i did not say any such thing
12:41rpirea: hmmm :-?
12:59karolherbst: intel bug fixes, that was fast
13:00karolherbst: would be nice to have more paid gues working on nouveau :/
13:02imirkin: or documentation
13:02imirkin: or volunteers
13:03Yoshimo: isn't the best of these 3 options documentation?
13:04imirkin: only if it's complete documentation
13:08karolherbst: I think intel devs are only allowed to use what is in open documentation anyway
13:08karolherbst: which is on the same time pretty amazing
13:09imirkin: no, they have tons of internal docs
13:09imirkin: as well as simulators, etc
13:09karolherbst: but as far as I know, they aren't allowed to implement stuff not inside the open docs
13:10imirkin: there are things they're not supposed to implement, but that's things like HDCP
13:10karolherbst: maybe I am wrong, but this is how I remember this
13:10imirkin: but having docs that explain how things work, and being able to run things in simulators, can be very helpful.
13:10karolherbst: yeah of course
13:10imirkin: but even if not, their public docs are *way* better than what we've worked out for nvidia
13:10karolherbst: I am not saying, that its easier to implement it if you work at intel, but usually you should find everything in the docs somehow
13:11imirkin: they also have a large team, qa, and resources.
13:21Samsai: what, that tegra support not enough for you? :P
13:22karolherbst: if I could apply the voltage stuff from the tegra card to my card it would :p
13:25imirkin: it's nice that they're adding support for tegra, which otherwise would have been much less likely to happen
13:26imirkin: but thus far they've been reluctant to dedicate resources towards improving the 3d driver
13:34rpirea: reclocking is available for my video card?
13:35Yoshimo: is the only advantage in dedicating ressources to a closed source linux driver instead of an open source one, protecting some vague idea of intellectual property?
13:35rpirea: performance is poor
13:36imirkin: rpirea: as expected.
13:36karolherbst: Yoshimo: what other reason is there to write a driver closed source?
13:36rpirea: but will be better, right? :)
13:36psaisanas: drbombay: I have got it working (just as a workaround) on newer kernels by loading up the equivalent x86 bios image for your exact card via the NvBIOS module option. This is just because newer kernels possibly seem not able to extract the DCB block from the OF device tree.
13:36karolherbst: rpirea: which card to you have?
13:36imirkin: rpirea: not anytime soon
13:37imirkin: psaisanas: could you provide a boot log with the same thing i asked drbombay ?
13:37rpirea: karolherbst nvidia 840m
13:37imirkin: psaisanas: i suspect there's some sort of issue reading the NVDA,BMP file... both the boot log and the actual file from OF would be great
13:37imirkin: ideally in a bug report, otherwise i'll lose the info and/or forget about it
13:38Yoshimo: karolherbst: can't think of any, but companies are creative when it comes to find excuses
13:39imirkin: well, a lot of their tech would be easily adaptable to other vendors
13:39imirkin: and they don't want to share their IP
13:39imirkin: that's the main reason
13:39psaisanas: Awesome, please tell be exactly what you need and i will provide you a report. By boot log you mean a full dmesg?
13:39imirkin: everything else is just derivatives of that
13:40imirkin: psaisanas: full dmesg with "nouveau.debug=debug,VBIOS=trace"
13:40imirkin: psaisanas: and you should be able to grab the NVDA,BMP file out of /sys or /proc somewhere
13:41imirkin: bug should go to bugs.freedesktop.org, xorg -> Driver/nouveau
13:41Yoshimo: imirkin: does AMD really need to spy on nvidia to make a great new card? i seriously doubt that
13:41imirkin: [there's no DRM/nouveau component]
13:41imirkin: Yoshimo: nothing to do with the hw
13:41karolherbst: Yoshimo: "excuses" != reasons ;)
13:41psaisanas: do i put those as modulde parameters i assume
13:41imirkin: they (a) have a good GL impl, (b) a strong compiler, (c) tons of optimization workarounds for all kinds of games
13:42rpirea: karolherbst ?
13:42imirkin: psaisanas: either on the kernel cmdline, or as the debug= for the module in modprobe.conf or something
13:45mupuf: the benchmark from phoronix from today was not too bad!
13:45mupuf: 73% of the performance, when having clock for clock
13:45mupuf: I was expecting worse!
13:46imirkin: there are so many diff factors...
13:48karolherbst: mupuf: yeah, but that was my feeling all along somehow, clocking really does make a difference
13:50karolherbst: mupuf: how was your trip if its over already?
13:50RSpliet: mupuf: in my XDC presentation I mentioned getting within 90% of the blobs perf ;-)
13:55karolherbst: imirkin: by the way, to whom I have to talk to about the metro redux issue?
13:55imirkin: can you remind me what the issue was?
13:56karolherbst: high mem usage
13:56karolherbst: allthough I could retest with 32GB and see if that helps
13:56imirkin: heh, no
13:56imirkin: i guess you talk to me :)
13:56imirkin: perhaps one of those patches introduces a leak
13:56imirkin: i wouldn't be surprised
13:56karolherbst: I have 16GB in the second laptop here, would be no biggi
13:57karolherbst: maybe I rebased just wrongly
13:57imirkin: maybe. what about my tree?
13:57karolherbst: which feature was it, subroutine?
13:59karolherbst: but remind me to disable swap before trying
14:00karolherbst: ahh ebuilds repository URI can be overwritten by environment, nice
14:00karolherbst: yeah, then its no problem to try out your branch
14:01karolherbst: yeah nice, clean clone instead of using the old repository with new remotes :/
14:09mupuf: RSpliet: yes, you said so, but it was for a nv50
14:09mupuf: the code has been well optimised by calim
14:09mupuf: AFAIK, Kepler has not received as much love at all
14:10mupuf: and there is the sched instruction too
14:10imirkin: i actually thought that kepler received more love than tesla
14:10mupuf: and i am sure more crazy stuff
14:10imirkin: among other things, he RE'd all the sched stuff :)
14:10mupuf: imirkin: for performance or for features?
14:10imirkin: there's definitely further to go if that's what you mean
14:11mupuf: oh, there is always :p
14:11imirkin: biggest thing for all generations is instruction scheduling
14:12mupuf: maybe one day, I will actually have a look into this
14:12mupuf: but this day is not in a foreseable future!
14:12imirkin: i keep wanting to sit down and do it
14:12imirkin: but... it's a lot of effort and would require benchmarking, etc
14:13mupuf: oh, well, one could automate this kind of stuff, right?
14:14tobijk: mh i'd really love to see a infrastructure to conut instructions for well-known shaders (shader-db)
14:14karolherbst: imirkin: ask michael, maybe he would help :D and lure him with "unpublished" performance boosting patches for nouveau, exclusvly of course ;)
14:14mupuf: karolherbst: surest way of getting him angry :D
14:15tobijk: psst he is listening ;-)
14:15imirkin: he has no interest in helping
14:15karolherbst: well well, X has a great day here today
14:15tobijk: it keeps crashing?
14:15tobijk: yeah here as well :/
14:16karolherbst: tobijk: if I would knew why
14:16tobijk: i see a pattern when i create/destroy a window
14:16karolherbst: this signal handler is just annoying
14:16karolherbst: tobijk: mhh
14:16karolherbst: it happens for me a lot inside chromium
14:17karolherbst: while opening/closing/changing tabs
14:17tobijk: which are windows as well?!
14:17karolherbst: don't know
14:17karolherbst: could be everything rendered thorugh something
14:18karolherbst: imirkin: I guess I will play around with your branch tomorrow
14:18tobijk: isnt chrome/chromium forking itself for every tab?
14:18imirkin: karolherbst: but really we need to check the valgrind situation
14:18karolherbst: imirkin: it looks like its inside the kernel, or isn't it?
14:19imirkin: but afaik others have gotten metro up and running on radeonsi
14:19karolherbst: top didn't displayed much mem usagy by metro
14:19karolherbst: it was like userspace: 15% in total
14:19imirkin: i thought it was at like 12GB
14:19karolherbst: but entire ram was used
14:19imirkin: at least in total vm
14:19karolherbst: it was physically completly full, so
14:19imirkin: did i misread?
14:20karolherbst: don't know
14:20tobijk: mh i'm trying latest xserver version, maybe that'll help...
14:20karolherbst: at least my kernel oomed metro
14:21imirkin: hmmm... 3806850 total vm pages, of which 499633 pages resident
14:21imirkin: which is 2GB resident, but 12GB in VM usage
14:22tobijk: i915_gem_shrinker_oom+0x1b1/0x200 is in that backtrace
14:23karolherbst: its prime anyway
14:24tobijk: the gem is shared, no?
14:50psaisanas: imirkin: i have just sent a bug report regarding the OF issies as instructed.
14:51imirkin: mmm... i don't see it
14:51imirkin: do you have a link?
14:54imirkin: psaisanas: oh. i thought you were going to put it up on bugs.freedesktop.org
14:54imirkin: anyways, i don't have approval power for the mailman list
14:54imirkin: i guess i'll see it in a day or so
14:59psaisanas: sorry, you want me to try again on bugs.freedesktop.org?
15:00imirkin: not necessarily
15:01psaisanas: will you get the attached files on the mailing list... sorry, i just gotta get ready for work!
15:01imirkin: yeah, should
15:01psaisanas: Appreciate the great work you guys do!
15:19karolherbst: #winehq is a good example why you should have anti spam in irc :D
16:02karolherbst: imirkin: nice, I can still install the talos demo through steam :)
16:16karolherbst: imirkin: okay, the nouveau module rescued me this time: metro shows 13% mem usage in top (from 16GB)
16:16karolherbst: but 11GB in total is used
16:16karolherbst: it was like 1GB before starting metro
16:17karolherbst: and the second most mem used is steam with 1%
16:18karolherbst: imirkin: what would be the next step to debug this issue? This time it was with your branch
16:20imirkin: figure out where the leak is happening
16:20karolherbst: I don't think they are even leaks
16:21karolherbst: while loading the main menu metro shows a big spike up to 11GB, but it goes down a little bit later
16:21karolherbst: this alone is troubling enough
16:22karolherbst: but my card does have a sched error now, so I have to reload the module, wish me luch, that X won't crash
16:22karolherbst: okay, seems fine
16:26karolherbst: imirkin: the problem is, I simply can't use my system until metro was killed
16:26karolherbst: because everything just is in total freeze
16:26imirkin: make a trace, see if it repros with the trace
16:27imirkin: then you can use valgrind on it
16:27karolherbst: apitrace? okay
16:27karolherbst: now may network was just killed :/
16:28karolherbst: ohh, metro is 64bit
16:28karolherbst: no valgrind bug :)
16:29tobijk: does metro work with intel?
16:30karolherbst: it requires 4.0
16:30tobijk: mh :/
16:31karolherbst: here we go
16:31imirkin: i.e. yes -- with the subroutines branch + override vars, it should be fine
16:31tobijk: but hangs in kernel?! :D
16:32karolherbst: everything hangs
16:32karolherbst: okay, this is new
16:33karolherbst: "[ 1479.479867] [TTM] nouveau 0000:01:00.0: Failed to fill cached pool (r:-12)!"
16:33karolherbst: wow 6GB trace :/
16:33karolherbst: imirkin: so override with 4.0 should work on intel? k
16:34karolherbst: why doesn't it work with apitrace? :D
16:34karolherbst: it fails at context creation for 1.0 :(
16:35karolherbst: I mean glretrace
16:35karolherbst: imirkin: ohh it starts, nice
16:37karolherbst: imirkin: it also ooms with intel
16:38karolherbst: ohh no
16:38karolherbst: it was nouveau again
16:41karolherbst: imirkin: I don't get subroutines with overrides on intel :/
16:42karolherbst: tobijk: MESA_GL_VERSION_OVERRIDE=4.0 glretrace metro.trace
16:42karolherbst: error: context mismatch: expected OpenGL 1.0, but got OpenGL 4.0 core
16:44tobijk: mh you can override the gl level as well imho
16:44karolherbst: yeah, it spikes up to 6GB while loading the main menu
16:44karolherbst: even with glretrace
16:44karolherbst: glsl? k
16:44tobijk: ah ignore me
16:45tobijk: can you make that trace available somewhere?
16:45karolherbst: no no, its okay I think
16:45karolherbst: tobijk: 6GB :)
16:45tobijk: is it already? i haven followed that cose, sorry
16:45tobijk: mh :/
16:46karolherbst: uncompressed though
16:46tobijk: start xz -9 and go to bed? ;-)
16:46karolherbst: yeah, glsl stayed at 3.3
16:46imirkin: you need to set both GL and GLSL version
16:47karolherbst: yeah I figured already
16:48karolherbst: yeah, it really seems to work now and its not nouveau
16:48karolherbst: stays under 2GB
16:48karolherbst: wait until I load the save
16:50karolherbst: wow it even loads the game
16:50karolherbst: nouveau just stoped at some point
16:50karolherbst: nice performance though
16:50karolherbst: at 3.2GB currently with intel
16:51karolherbst: imirkin: works with intel
16:51tobijk: make a trace already :)
16:51karolherbst: got this in glretrace though: https://gist.github.com/karolherbst/88e539eef3d664bcacca
16:51karolherbst: tobijk: yeah okay
16:52karolherbst: tobijk: tell me where to upload it then ;)
16:52karolherbst: should be there in 1t secs
16:52tobijk: dont know which hoster you trust ;-)
16:52karolherbst: which doesn't have a file size limit that big?
16:52karolherbst: and no upload speed limit?
16:54Karlton: p2p it
16:54tobijk: can you try to create a smaller one? the hoster problem is 2nd :>
16:54karolherbst: tobijk: funny
16:54karolherbst: like I could skip the intro
16:54karolherbst: this is like: starting game, wait, click continue, wait for oom
16:55karolherbst: really you should not tough the trace at least you have over 16GB RAM
16:56karolherbst: xz really needs its time
16:56Karlton: I could never figure out how to cut the beginning off my apitraces :(
16:56karolherbst: is this even possible?
16:58tobijk: karolherbst: this is metro last light?
16:58karolherbst: redux, yes
16:58karolherbst: metro 2033 redux
16:59tobijk: lets google a bit...
17:00tobijk: Open legal.ogv with a text editor. Delete its contents and save the file.
17:00tobijk: that worth a try, i'd say :>
17:00karolherbst: what should this change?
17:01karolherbst: ahh no intro video
17:01tobijk: :) exactly
17:01karolherbst: this will save you maybe 5k calls
17:01karolherbst: the other intro is engine rendered
17:01karolherbst: and there are like 30k calls per frame
17:03karolherbst: the intro has like 280 calls
17:04tobijk: meh :/
17:05karolherbst: though there is a bash script for hosting a tiny webserver for file transfer
17:06tobijk: karolherbst: there is a benchmark mode for metro
17:07Karlton: there is also GNUnet, which is like Tor but for file sharing
17:07tobijk: just have to find out howto
17:09tobijk: karolherbst: http://steamcommunity.com/app/286690/discussions/1/619573787410183094/
17:09tobijk: they have little problems, but who cares
17:11karolherbst: mhh I think I will record the trace with intel
17:11tobijk: yeah and try the benachmark mode, maybe that cuts the intro(s)
17:12karolherbst: segfault, nice
17:14karolherbst: okay, nearly at oom
17:14karolherbst: ohh damn you nouveau :/
17:17karolherbst: okay, the combination of oom and SCHED_ERROR is not nice
17:19karolherbst: so, next try
17:19karolherbst: tobijk: but the benchmark produced a nice trace: 7GB :)
17:19tobijk: mh cant you stop it after some seconds or whatever?
17:20karolherbst: imirkin: should it be enough to stop at 4 or 5 GB usage?
17:20tobijk: or is that the 7GB version already? :D
17:20karolherbst: nah, I have to check when there is enough memory used
17:20karolherbst: stopped at 5.5
17:21karolherbst: trace is 1.8 GB big
17:21karolherbst: that's better
17:22karolherbst: 290 frames
17:25karolherbst: okay, max memory usage by the trace is like 5GB RAM, so if you have that or more free, you should be able to replace it
17:36psaisanas: imirkin: Regarding the OpenFirmware nouveau issues, i have now created a bug in bugzilla, RE: Bug 91319.
17:36karolherbst: uploading trace
17:37imirkin: ok i see it
17:37tobijk: imirkin: btw, do we have a new gl4-integration branch?
17:37imirkin: i've gone up to -3 i think
17:38karolherbst: tobijk: I did one
17:38karolherbst: but there was a radeonsi merge I am not sure about
17:38karolherbst: and it may break everything
17:38imirkin: psaisanas: unfortunately options nouveau config="NvMSI=0,debug=debug,VBIOS=trace" is not what i was hoping for...
17:38imirkin: psaisanas: debug=debug,VBIOS=trace should have been a separate option
17:38tobijk: ah something to test tomorrow :)
17:38karolherbst: tobijk: https://github.com/karolherbst/mesa/commits/gl4-integration-4 if you want otherwise take imirkin ones
17:39karolherbst: I rebased it today
17:39tobijk: will have a look tomorrow, thanks
17:40tobijk: but now, my pillow awaits...bye
17:41karolherbst: yeah nice, have to rebase again
17:41imirkin: psaisanas: also as another note for the future, best to include logs uncompressed and as separate attachments in bugzilla -- avoids having to download/etc
17:41karolherbst: imirkin: https://www.dropbox.com/s/wdnk3x4vkiqzyvt/metro.trace.xz?dl=0
17:42karolherbst: 5GB RAM required
17:42psaisanas: imirkin: Sorry, first time submitting a bug. how do i add more than one attachment as i only saw the option to add one?
17:43imirkin: psaisanas: you add them one at a time. anyways.... in older kernel, did it manage to grab the OF thing?
17:43imirkin: or did it always read from PROM?
17:44psaisanas: yes, always from openfirmware it never attempted from PROM to the best of my knowledge
17:45psaisanas: I have tried to force it via the NvBIOS OpenFirmware method and it didnt work.
17:48imirkin: yeah... we need to figure out why that's not working
17:49imirkin: the code _looks_ reasonable...
17:50imirkin: psaisanas: basically you could add a ton of prints to drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowof.c
17:51karolherbst: psaisanas: did you bisect the kernel?
17:52karolherbst: would be an idea to try out latest 4.0/3.19 kernel first and then try to find what exactly broke it
17:52imirkin: i bet it lands on ad4a362635353f7ceb66f4038269770fee1025fa
17:53imirkin: i'd just stick prints in, this isn't so complicated that it needs a bisect
17:53psaisanas: Sorry, my skills as a dev are non existent!
17:53karolherbst: this is just the first thing I would do with a regression
17:54karolherbst: psaisanas: mhh yeah, that would be problematic, because you would have to configure your kernel at some points
17:54karolherbst: imirkin: this patch is part of 3.19 or 3.20?
17:54psaisanas: I can compile and configure kernels fine, i got no problem with that.
17:55imirkin: this commit is in 3.19
17:55imirkin: psaisanas: first off do the boot with the debug
17:55imirkin: psaisanas: and once we have that, we can go from there
17:55karolherbst: imirkin: is the trace _okay_ by the way?
17:55psaisanas: For starters, to give more helpful info, what would you like me to append on the kernel command line exactly? I can do it for a working kernel and a non working one.
17:56psaisanas: By the way, i am running Debian Jessie (8.1) if that helps!!!
17:56imirkin: instead of options nouveau config="...,debug=...", should be options nouveau config="..." debug="..."
17:57karolherbst: psaisanas: if you are not up to wasting a day with something like that then ;)
17:57imirkin: karolherbst: i doubt i'll have time to look at the trace
17:58karolherbst: nah just wanted to know if you got the same problem
17:58imirkin: esp since chances are it'll kill my piddly box
17:58karolherbst: it only needs 5GB!
17:58imirkin: 6G of ram, i generally run without swap
17:58karolherbst: with swap would be your death with that trace
17:58karolherbst: do it _always_ with swap off
17:59karolherbst: otherwise your kernel won't oom the process
17:59karolherbst: but okay
17:59karolherbst: maybe I will then look into it
17:59karolherbst: there are a lot of linker errors though
18:00karolherbst: "458563: message: major api error 2: GL_INVALID_OPERATION in glUseProgram(program 6423 not linked)"
18:01karolherbst: but I will go to bed now too. Maybe I look into that myself then
18:45psaisanas: imirkin: whenever I'm at the machine again ill attempt to pass the module parameters you gave. I'll attach a new kernel log on bugzilla. thanks for your time, much appreciated.
19:04CMEPTb: hi guys. i'm having problems with opengl maybe? switched to nouveau from nvidia-drivers, now when i try to play somethign in mpv or glxgears i get this error: libGL error: MESA-LOADER: could not create udev device for fd 12 MESA-LOADER: could not create udev device for fd 12 <- what can i try to fix it?
19:05imirkin: CMEPTb: pastebin dmesg, xorg log, and 'LIBGL_DEBUG=verbose glxinfo' output
19:05CMEPTb: awesome thank you one momeent
19:05CMEPTb: errr parts of dmesg ok?
19:06imirkin: ideally the whole thing... has it scrolled off the circular buffer end?
19:09CMEPTb: i got it..
19:12CMEPTb: imirkin, here it is: http://pastebin.com/dUgcdK58
19:14imirkin: CMEPTb: everything looks perfectly fine... what's the problem? that MESA-LOADER thing?
19:15CMEPTb: imirkin, yea...
19:15CMEPTb: i never got that kind of error before trying out nvidia-drivers. now i see it everywhere after switching back..
19:15imirkin: is udev messed up / not available on your system?
19:16CMEPTb: ~ # /etc/init.d/udev status
19:16CMEPTb: * status: started
19:16CMEPTb: seems to be running no errors that i saw...
19:17imirkin: well, your libudev appears to not be working the way the libGL loader expects it to. no idea why, i'm not really familiar with that part of the system. however it's nothing to really worry about
19:18imirkin: xexaxo: perhaps you have an idea?
20:06CMEPTb: for gtx770 what's better to use for movies - opengl or vdpau?
20:07imirkin: assuming you have fw installed. if not, doesn't matter, neither will use hw accel
20:08imirkin: put another way, opengl and vdpau aren't mutually exclusive
20:10CMEPTb: not sure what fw stands for other than firewall and that makes no sense here
20:10imirkin: see the video acceleration page in the wiki
20:12mogorva: imirkin: Re bug #91314: with your patch applied I'm getting 'witcher2: main/teximage.c:3115: _mesa_choose_texture_format: Assertion `f != MESA_FORMAT_NONE' failed.'
20:12imirkin: i prolly messed something up
20:12CMEPTb: oh you mean the nvidia-firmware package??? no i did not have that..
20:13CMEPTb: but is that for the open source nvidia driver, not the nvidia-drivers binary blob?
20:13imirkin: i believe the video acceleration wiki page covers all that
20:15CMEPTb: would be nice if gentoo mentioned this step in its own wiki, thank you found the page, reading :)) hopefully now glxgears will show something closer to 18k fps, instead of 5k
20:17imirkin: nouveau just needs the video decoding firmware, for vdpau
20:17imirkin: the fps won't change, but also the fps in glxgears have little to do with driver performance
20:17imirkin: that said, your card doesn't get reclocked by default, which means that you're in the lowest level
20:18imirkin: you can boot with nouveau.pstate=1 to access the (experimental) reclocking functionality
20:18imirkin: (as also mentioned on the front wiki page)
20:20CMEPTb: thank you again imirkin. is there maybe some utility like nvidia-settings for nouveau or is it all text and conf files?
20:20imirkin: what functionality from nvidia-settings were you hoping for? it's a single application which does a ton of diff and unrelated things...
20:22CMEPTb: oh. to change pstate for one(assuming it's a setting for overclocking, or rather sets of levels you can have you card clocked at), see fan speeds/temp
20:23imirkin: fan speeds/temps come out as sensor readings, anything that plugs into the usual linux sensor outputs should display them
20:23imirkin: including the 'sensors' command
20:23imirkin: the reclocking functionality (nothing to do with "overclocking" btw) is highly experimental, and most likely to hang your card at the highest levels
20:23imirkin: by adding nouveau.pstate=1 you get a file in sysfs which you can cat and echo stuff into. it's very much a debug-style interface.
20:27mogorva: imirkin: would it help if I performed the same steps as earlier in gdb to get a backtrace?
20:28imirkin: mogorva: no
20:29imirkin: mogorva: you can just remove that assert for now and unapply my patch
20:30imirkin: if you can generate a trace that crashes, that'd be quite helpful
20:30mogorva: the trace when replaying doesn't print anything in the terminal
20:30imirkin: does it not crash as well, when the assert is removed?
20:34CMEPTb: imirkin, i read a lot on different forums and people are saying contradictory things.. should the compositor's sync to vblank be turned on or not? i'm on xfce4.12
20:35imirkin: with recent userspace and kernel, vblank works just fine
20:35imirkin: it should default to 'on' as well
20:35imirkin: so glxgears should only have given you 60fps without disabling vblank...
20:36CMEPTb: right. when disabled, it's 5k or so
20:36CMEPTb: just noticing some screen tearing, very little while watching a 720p media with mplayer. got the firmware... wondering if i need to experiment with the pstate thing.
20:37imirkin: are you using vdpau for decoding?
20:37imirkin: i.e. did you add the -vc thing as recommended by the wiki?
20:38CMEPTb: i did the vc to /etc/mplayer/mplayer.conf yes, also selected vdpau in smplayer for video driver
20:39CMEPTb: it may just be a bad file, will try something huge rez in a sec once the copy is done. then i'll know for sure :) btw, thanka bunch for all your hard work! you and everyone else
20:40imirkin: well, you can always try clocking up and see if that works
20:40imirkin: most people ahve gotten the 0a perf level to work on gpu's like yours
20:41imirkin: although the highest memory clocks remain unaccessible
20:43CMEPTb: 0a? is there a wiki on doing the pstate magic? i don't see it mentioned on the accel page
20:43imirkin: not really
20:43imirkin: certainly not on the video decoding accel page ;)
20:44imirkin: if you boot with nouveau.pstate=1 you should see a /sys/class/drm/card0/device/pstate file
20:44imirkin: you can cat it to see the pstate config, and you can echo pstate level names into it to ask it to switch
20:45CMEPTb: aaaaah just 'echo 0a > pstate'?
20:48mogorva: imirkin: if I remove the assert then the game starts fine
20:48imirkin: mogorva: and if you capture a trace
20:48imirkin: and then replay the trace *with* the assert
20:48imirkin: does the assert get hit?
20:48mogorva: i'll try that
20:51mogorva: imirkin: yes. I get the assert when replaying the trace
20:52imirkin: awesome. can you put that trace up? should help me check whether my changes work :)
20:56mogorva: imirkin: trace: https://drive.google.com/open?id=0B-tTbLKBl-tOZW5heE0tTjlvemM
21:05imirkin: cool thanks
21:13mogorva: during creating the trace I got lots of warning from apitrace: http://hastebin.com/yipedefeqi.sm
21:13imirkin: ah right, glBufferStorage. not an issue for hitting the bug, but an issue for making the trace display things
21:14mogorva: when replaying the trace (with the assert removed) I get only a garbled screen
21:17imirkin: yeah, that's expected
21:28mogorva: re: bug 91310, the menus look fine, I'm getting such flashing polygons when opening the inventory though -> http://imgur.com/BwivyIC
21:32imirkin: probably some buffer storage fail... and i assume that starting the game with MESA_EXTENSION_OVERRIDE=-GL_ARB_buffer_storage doesn't work at all?
21:34mogorva: crashes on start, the last line shows 'Mesa: User error: GL_INVALID_VALUE in glMapBufferRange(access has undefined bits set)'
21:35imirkin: super. looks like it uses glBufferStorage whether it's available or not.
21:49CMEPTb: imirkin, hm. i guess try the pstate thing next? tried this file 1080p_BluRay_QEBS5_AAC51_PS3_MP4-FASM, all is well visually, but when the scene scrolls to the side, there is a visible weird tear about half an inch from the top of the screen .. also always there, no where else. it doesn't feel like vsync issues i've had before tho. any idea?
21:49imirkin: actually now that you say it, i seem to recall people reporting tearing issues on kepler boards
21:49CMEPTb: mine's a kepler?
21:49CMEPTb: any way to mitigate... ? o pwz o pwz..
21:50imirkin: not that i'm aware of... haven't looked into it
21:50Karlton: did you try compositor vsync?
21:51Karlton: I think that helped for me
21:52CMEPTb: it's on i checked..
21:52CMEPTb: any thing i could do to be helpful in maybe debugging this since i have hardware and others reported it too?
21:55imirkin: unfortunately i have no clue where to even start debugging things like that =/
21:57CMEPTb: i was thinking recompiling mplayer in debug and stepping through it :)
21:57CMEPTb: i don't know how video devs do these things really
21:58imirkin: somehow the video frame copy isn't being properly synchronized
21:58imirkin: unfortunately i don't really know how that stack really works or interacts with vsync
22:00CMEPTb: ok going to cut out a chunk of this video and make a loop out of it so the sheer is always on.. see if maybe i can spot something.
22:00CMEPTb: but having looked at my settings, you are sure there is no missing USE flag or some library that would help, right?
22:01imirkin: pretty sure i've heard others on kepler with the same issue. it works great on my fermi.
22:04CMEPTb: well one thing i guess left to try is the 0a thing. maaaabe it's just lacking enough oomf in certain circumstance.
22:07CMEPTb: same card works fine in win, btw :P
22:08imirkin: probably missing an inter-channel sync ... or using the built-in fifo copy engine has some difference from the separate copy engines on fermi
22:08imirkin: who knows
22:08drbombay: does make g5_deconfig create a useable kernel?, and which kernel sources are recommended?
22:08imirkin: drbombay: upstream should be fine
22:08imirkin: not a whole lot of dev going on targeting G5's :)
22:09drbombay: are you on a G5
22:10imirkin: oh, if you want nouveau to work you have to make sure to use 4K pages, not 64K pages
22:10drbombay: is that configured in the kernel
22:10imirkin: but apparently there's some issue with OF that you and someone else are running into
22:11imirkin: yeah... CONFIG_4K_PAGES or something like that
22:14imirkin: there are some bugs in nouveau relating to PAGE_SIZE != 4k... but it's really hard to debug without the hardware, and there are some legitimately annoying issues that come up with the cpu page size != gpu page size