01:05mlankhorst: gnurou: ping?
01:07mupuf: skeggsb: he wanted moar FPS :D
01:07mupuf: gimme moar, gimme moar!
01:08mupuf: this haswell laptop can do 5509.058 FPS though
01:08mupuf: my desktop manages more than 10k
01:08mlankhorst: ah nice
01:09mupuf: I guess this is the cost of using hw contexts for each client
01:09skeggsb: mupuf: yes, i was getting >10k on nv40 back when we used dri1
01:09mupuf: the state tracking for glxgears is pretty simple so only a small part of the context needs to be updated
01:09mupuf: yep, I remember it
01:09skeggsb: (swap was done in the same channel as the rendering)
01:10mupuf: but hey, who cares about this!
01:10skeggsb: it's a cost worth paying imo
01:10mupuf: skeggsb: did you see the problems with the pwm controller on some boards?
01:11gnurou: mlankhorst: pong
01:11mupuf: for some reason, you need to write duty / 50 to have the fan behave properly
01:11mlankhorst: gnurou: if I shut down Xorg I get a whole bunch of GPPTR failures, everything with 00000000's though
01:11skeggsb: mupuf: no, i didn't see that
01:12mupuf: and I keep on trying to find where the heck am I supposed to know when I am supposed to do it or can't find any information in the vbios for this
01:12mupuf: this is why people complain about high speed fan
01:13mupuf: I wonder if it is a hw bug on a list of PCIID or just a given chipset (nvc1 seems common)
01:13mupuf: I guess I'll just fire an email to nvidia...
01:14mupuf: I got access to one card like that at work
01:16gnurou: mlankhorst: that cannot be good
01:16gnurou: mlankhorst: do you have a log posted somewhere?
01:16mlankhorst: gnurou: Not right now, I can get you one later. It seems to only happen when shutting down Xorg though.
01:17gnurou: it should never happen nonetheless :P
01:17mlankhorst: most of the time doing rmmod nouveau; modprobe nouveau afterwards is enough to bring up Xorg again. :P
01:17mlankhorst: I mostly ironed out the details of gpu slaves, found out why I didn't get a desktop
01:17gnurou: my debugging skill for such issues is limited, but I will try to see if this rings a bell somewhow...
01:18mlankhorst: I had to patch unity-greeter, compiz, libnux and unity. eg most of the unity core. :P
01:18gnurou: wow. how come?
01:18mlankhorst: unity-greeter to do xrandr --auto, compiz, libnux and unity to use opengl instead of gles2.
01:18gnurou: why isn't gles2 working?
01:19mlankhorst: it uses dri2 instead of present
01:19mlankhorst: dri3 works better in this case, and allows me to replace the linear scanout with a tiled pixmap during a flip. :P
01:20gnurou: ok, so not an issue with Nouveau by itself - glad to hear that
01:20gnurou: that's really awesome you got X to work to fast
01:20mlankhorst: I'll stuff everything in a ppa, but xorg-server is kind of a mess
01:21mlankhorst: oh skeggsb, got any objections against my patch to nouveau ddx for setting the domains with NOUVEAU_BO_APER?
01:22skeggsb: mlankhorst: honestly, i'm very much in a "i don't care much about the ddx except for boards that can't do glamor" mindset. so, as long as it doesn't break, do whatever you like :P
01:22mlankhorst: actually I'm kind of worried about dma-buf in that case, since mesa currently allocates it as gart for DRI3. I really want to set it to VRAM|GART and have the ddx use VRAM if available..
01:23mlankhorst: skeggsb: fair enough..
01:23airlied: damn keys
01:23mlankhorst:steals airlied's sso token
01:24gnurou: skeggsb: btw, do you plan to make a new push to -next soon? we need it to push the libdrm/Mesa patches for GK20A
01:24skeggsb: gnurou: i hadn't just yet, but i can if you need me to
01:25skeggsb: i'll wait on imirkin to test a couple of patches i stuck in my tree, and send what's there already to airlied
01:25gnurou: skeggsb: sounds good, thanks!
01:26mlankhorst: gnurou: http://cgit.freedesktop.org/~mlankhorst/xserver/log/?h=tegra btw
01:27gnurou: mlankhorst: is that all that is needed? i.e. no extra changes to kernel/drm/mesa?
01:28mlankhorst: nouveau ddx needs some changes, I didn't touch kernel or mesa, except for a rebuild against the version in vivid
01:28gnurou: that's really cool. Thanks for giving it a shot!
01:28mlankhorst: I'll get a full tegra ppa up when it's ready
02:02 < ahellquist|work> pmoreau: Hi, any news on the HUB_TIMEOUT problem with Quadro k2100m (rev a1) (GK106GLM) ?
03:48imirkin: mlankhorst: http://hastebin.com/raw/zaremabeto -- weren't you messing with this stuff? i have libdrm 2.4.59
03:49imirkin: er hm, looks like you messed with it *after* .59 :)
03:52mlankhorst: yeah. :P
03:54imirkin: when this piglit run finishes, i guess i'll see if i can get a proper backtrace
03:54imirkin: i am, however, a *little* curious how that all ended up on my terminal rather than picked up by piglit
03:55mlankhorst: it aborts on double free
03:55imirkin: not sure how that affects things
03:55imirkin: it's a process... it runs... it exits... piglit is supposed to pick up all its output, stdout and stderr...
03:56imirkin: (i mean the test runner infrastructure)
03:57mlankhorst: it opens /dev/tty
03:57imirkin: it really looks like texelFetch is able to trigger whatever issue is going on
03:57mlankhorst: see eglibc/sysdeps/posix/libc_fatal.c
03:58imirkin: hehe. well i don't use eglibc, but i assume glibc does the same thing
03:58mlankhorst: probably the same issue, just try upgrading to 2.4.60
03:58imirkin: i've never seen this before
03:59imirkin: and someone else was in here recently talking about the same thing... librin or something along those lines
03:59imirkin: and also with texelFetch
04:00imirkin: [i'm sure it has nothing to do with the texel fetching parts, but rather how the test uses resources]
04:00mlankhorst: probably, libdrm 2.4.60 should cut down on list traversal a lot though
04:01imirkin: so you're saying that it's a multi-year-old issue that's never surfaced before that *all of a sudden* two people have independently seen?
04:01mlankhorst: upgrade and find out before I do ;-)
04:01imirkin: no .60 package in portage yet
04:02imirkin: anyways, this corruption in libdrm is causing all sorts of validate to fail
04:03imirkin: also, wouldn't those other issues only happen under parallelism? none here...
04:05mlankhorst: no, the libdrm stuff fixes things in the same process
04:05imirkin: yes, but that process would have to be threaded no?
04:06imirkin: which none of the piglit stuff is...
04:06mlankhorst: it could be an ordinary double free though..
04:06mlankhorst: in which case valgrind would tell you
04:06imirkin: yeah, i'll dig a bit when/if this piglit run finishes
04:07imirkin: it's a nouveau_bo_wait doing the unref though, i guess it could be trying to wait on a free'd bo?
04:08mlankhorst: but in that case the ref should be held by pushbuf..
05:18mlankhorst: gnurou: uh oh, this doesn't look good either.. http://paste.debian.net/162708/
07:08imirkin_: i know this is highly unrelated, but with efibootmgr, i can specify *any* boot path, right? doesn't have to be bootx64.efi?
07:11buhman: anything inside the ESP, sure
07:12imirkin_: and there's no way to *edit* the cmdline with (most) efi bioses right? the only way to do something like that would be a pseudo os like grub2?
07:12imirkin_: tell me more :)
07:14buhman: efibootmgr -u and -@
07:15buhman: not sure what's that's actually called in the spec, but any firmware that doesn't support that isn't a real/compliant firmware
07:15imirkin_: buhman: sure, but that's constant
07:15imirkin_: buhman: no way to edit it after the fact right?
07:15imirkin_: (like from the EFI BIOS)
07:16imirkin_: [certainly one could provide such implementation in an EFI BIOS, but unless i'm blind, i don't see dell doing so]
07:16buhman: intel firmwares can
07:16buhman: does your firmware have a thing that lets you add arbitrary efi boot entries?
07:16buhman: or is it just a bios-like thing that lets you modify some 'boot order' nonsense
07:16imirkin_: pretty sure i _can_ add arbitrary boot entries
07:16imirkin_: but that's with efibootmgr
07:17imirkin_: the actual BIOS UI is pretty limited
07:17buhman: that sucks
07:17buhman: the point of gummiboot is to work around lazy vendor firmwares.
07:17imirkin_: this is my first EFI interaction though, so i may be missing stuff
07:17imirkin_: why would i use that over grub?
07:18buhman: if you only want a menu specifically
07:18imirkin_: [other than the fact that grub2 is the spawn of the devil]
07:18buhman: gummiboot is just a menu, and can't otherwise do things that your firmware can't already do
07:18buhman: so you'd use grub if you want to load a kernel from a luks container inside mdraid or similar awesomeness ;p
07:19imirkin_: so it just pulls from the efi vars right?
07:19buhman: gummiboot ignores efivars
07:19imirkin_: how do you configure it?
07:19buhman: it reads some gummiboot.conf inside the ESP
07:19imirkin_: ah ok
07:19imirkin_: so it's a bootx64.efi replacement, and you only have that as your one os registered with the efi?
07:20imirkin_: kk, thanks
07:20imirkin_: let me digest this and figure out what i actually want
07:20imirkin_: this whole "reboot and pray that your new bootx64.efi works" thing is getting old
07:22imirkin_: [basically i'm trying to minimize the quantity of things that can go wrong when i accidentally the whole thing]
08:16jo77ah: i have a quadro 880M - GT216GLM chipset. is there a possibility to get some clockusage? like nvidia-smi?
08:16imirkin_: jo77ah: with kernel 3.19+ you should be able to reclock. boot with nouveau.pstate=1
08:16imirkin_: jo77ah: and you should see the current state in /sys/class/drm/card0/device/pstate
08:17imirkin_: jo77ah: and be able to switch between levels by echoing the level id's into the file (e.g. 03 or 07 or 0a or whatever is listed in there, varies from card to card)
08:25jo77ah: imirkin_: imirkin: thanks. sounds like a good start point.
09:42imirkin_: skeggsb: i've finally rebooted... let me know if you want me to poke at the gk208 before i try loading nouveau (will probably do that in the afternoon)
11:44mlankhorst: now I need to figure out why window decorations are borked..
13:47imirkin_: skeggsb: is there a quick way i could do the test against a 3.19 kernel?
13:47imirkin_: oh neat. it builds.
13:47imirkin_: i wasn't even going to try =]
13:48imirkin_: skeggsb: [18618.345665] nouveau E[ PIBUS][0000:01:00.0] HUB0: 0x614900 0x00800000 (0x1f708200)
13:49imirkin_: skeggsb: iirc the error was different before
14:31martm: honestly i didn't qiuite understand that if i go like 15000 km to the south, that someone would recognize me, this kinda multiculture stuff i did not understand
14:32imirkin_: skeggsb: this is my vbios btw: http://filebin.ca/1vr2k7J0alIP/gk208-vbios.rom
14:32martm: is it possible that those persons know something about estoniaks
14:32imirkin_: skeggsb: i think that the 614900 thing may be coming from a IO call
14:34imirkin_: 0x86b5: 69 c3 03 00 01 IO I[0x03c3] &= 0x00 |= 0x01
14:38martm: death comes to all of us, but i am still completly stunned of what happened, its a complete lack of understanding by me, you know i dont get it
14:58martm: you know it all comes to, well they said same problems will follow you everywhere you are, plus one ganster said, you will be found everywhere your at,, and i thought those are not ok from the head, but australians and new zealanders were all concentrated to what i do
15:02martm: also one song from the same guy is cur your teeth, i dunno i am kinda world wide famous guy
15:14Ident: hello, i m from the CEGUI library and it seems we have issues with nouveau drivers rendering things upside-down and half the size
15:14Ident: specifically the size seems to be reduced towards the center
15:14Ident: did anybody see or experience similar issues?
15:14Ident: i mean in general OpenGL usage
15:14imirkin_: Ident: what hardware are you using?
15:14imirkin_: sounds like texcoords are messed up
15:15Ident: the same code works on a large variety of hardware and setups, on Windows no one experienced issues
15:15Ident: i will check what hardware was reported
15:15imirkin_: Ident: oh, i wasn't suggesting an error in your software
15:16Ident: a user reported an older version of our software worked for him on nouveau drivers, i assume it could be that we do something that the drivers do not like while most proprietery ones accept it
15:16Ident: unfortunately i couldnt find out what would cause this
15:17Ident: as in, what GL calls
15:17imirkin_: Ident: well, knowing the hardware he was on would narrow down the possible set of issues
15:17imirkin_: Ident: also an apitrace that reproduces the issue for the user would be ideal (https://github.com/apitrace/apitrace)
15:18Ident: NVIDIA Corporation G92 [GeForce GTS 250]
15:18imirkin_: hmmm.... odd. that should work fairly well
15:19imirkin_: i was assuming it was some ancient geforce 2 or something
15:19Ident: Quadro K2000
15:19Ident: dunno if thats the correct name
15:19imirkin_: that's a kepler... yeah, all those should be very well supported
15:19Ident: ah yea its the correct name
15:19Ident: didnt know there was a k-series
15:20imirkin_: Ident: if you can provide an apitrace that causes the problems, i'd be very interested
15:22Ident: i cant reproduce the issue on my system but i have asked the reporters to do an apitrace
15:24imirkin_: Ident: can't repro using nouveau, or a different driver?
15:25Ident: imirkin_: i m on windows ;)
15:25imirkin_: ok, so i'll go with "a different driver" :)
15:25Ident: i have not encountered it on any GPu or driver
15:25imirkin_: it's an odd issue and doesn't ring a bell
15:26Ident: the issue seem to have occured on archlinux and mint mainly, and someone reported that it worked on 11.04 ubunut and then stopped working on mint 17.1
15:26imirkin_: sounds like the sort of thing that could easily go wrong if texcoords are messed up
15:26imirkin_: those versions mean quite little to me... mesa versions make sense to me. various distro versions, not so much
15:26imirkin_: you should figure out what versions of mesa they're using
15:26Ident: we render to the main FBO, in that case the geometry would span the same space no matter what tex coords there are
15:27imirkin_: is CEGUI an "old-school" GL app, or does it use fancy new features?
15:27Ident: yet the whole geometry seems to be compressed towards the center of the screen
15:27imirkin_: i.e. is it like a GL1-era application, or a GL3-era
15:27Ident: we use an oldschool backwards compatibility GL1.X renderer and a GL 3.2 Core Profile (no deprecated functions) renderer that I wrote
15:27Ident: the issues appeared on both
15:27Ident: which is scary
15:28imirkin_: ah cool. with new-enough mesa (not that new... like mesa 10.2 or so) you should get core profile with G80+ cards with nouveau
15:28imirkin_: assuming it's a general nouveau issue, would i be able to repro the issue myself?
15:28imirkin_: or are there custom files or whatever involved?
15:29Ident: it is an open source project
15:29Ident: no custom files involved
15:29Ident: the sample browser was tested and caused the issues
15:29imirkin_: cegui 0.8.4 new enough or do i need more recent?
15:30Ident: thats fine
15:30Ident: 0.7.9 was reported to work
15:30Ident: everything above 0.8.0 not
15:30Ident: i think 0.7.9 had not OGL3 Renderer
15:30imirkin_: ok. well i don't have nouveau [easily] here, but let me see how it behaves on i965 to rule out some overall mesa issue
15:30Ident: ok thank you sounds great
15:30imirkin_: and i can check on nouveau in a couple of hours
15:31imirkin_: do i just run it and the issue should be obvious if i have it? or do i have to go somewhere in the gui?
15:31Ident: just run
15:31Ident: when it is loaded it should be apparent
15:31Ident: this is how it looked for people with issues
15:32Ident: thats how it is suppoed to look: https://www.youtube.com/watch?v=Z5Uf9IsWCXY
15:33Ident: i know the texture filtering on the previews isnt optimal, bilinear used to be enough
15:51mupuf: skeggsb: my gm107 seems to work correctly with the open firmware, well done!
15:51imirkin_: mupuf: xonotic still buggy though? :)
15:51mupuf: there is still this funny corruption in xonotic, yes
15:51mupuf: it looks a bit different though
15:51imirkin_: well, it's probably timing-sensitive
15:51mupuf: now I also get some green solids :D
15:52imirkin_: i wonder if it's a timeout situation as well
15:52mupuf: but I am now using the same shaders
15:52mupuf: they oscilate between red and green, so I guess it is the same bug
15:52mupuf: hopefully, nvidia will answer your email
15:52imirkin_: yeah, i'm not holding out hope
15:52mupuf: for the VAO cache
15:53imirkin_: could very well be something wholly unrelated
15:53imirkin_: like it could be the shader execution timing out
15:54mupuf: oh, right
15:54Ident: have you tried it on your i965?
15:54mupuf: like the bug on tesla :D
15:54imirkin_: Ident: building... had some mishaps :)
15:54Ident: ok :)
15:55imirkin_: hmmmm... the cegui package didn't build any binaries
15:56imirkin_: Ident: which one of these do i want? http://hastebin.com/raw/moketebewi
15:59Ident: you dont need python, you do need expat
15:59imirkin_: ok, but i doubt that 'expat' is the thing i'm missing
16:00Ident: + means installed and - means not installed?
16:00Ident: at least one xml parser needs to be activated
16:00Ident: i m honestly not sure what i m looking at here though
16:01Ident: i always use cmake and configure these things myself
16:01imirkin_: + means selected, - means deselected
16:01Ident: ah ok
16:01imirkin_: this is the gentoo ebuild
16:01imirkin_: (don't worry about the fact that there are two columns, they should be identical to one another)
16:01Ident: why do you think expat is not the thing missing?
16:01imirkin_: that's only needed for xml parsing
16:02imirkin_: i'm missing a *binary* :)
16:02imirkin_: what cmake variable do i need?
16:02Ident: i m extremely confused
16:02imirkin_: i.e. CEGUI_BUILD_xxxxx
16:03Ident: arent packages supposed to be built?
16:03imirkin_: yes, packages are supposed to be built
16:03imirkin_: i built it
16:03Ident: and your build created no binaries?
16:03Ident: any error messages?
16:03imirkin_: i got a /usr/lib64/libCEGUIBase-0.so.2.3.0
16:03imirkin_: and related files
16:03imirkin_: and i got a bunch of header files
16:03Ident: maybe the packager didnt include the samplebrowser
16:03imirkin_: aha, samplebrowser is the thing i want?
16:04Ident: CEGUI_SAMPLES_ENABLED and then CEGUI_SAMPLE_ENABLE_XXX (at least one)
16:04Ident: should be activated
16:04imirkin_: got it
16:04Ident: sorry for the confusion
16:05imirkin_: it hardcodes that :)
16:05Ident: is that bad?
16:06imirkin_: well, it means there's no use flag to turn it on =/
16:06Ident: what the heck
16:06imirkin_: i guess i'll go the non-package route
16:06Ident: in the cmake gui this is a regular variable
16:06Ident: i m not a cmake expert tho, i only touch it when i have to ;)
16:07Ident: but i assume in a normal setup this should be regularly configurable
16:07imirkin_: The SampleFramework is deactivated due to missing OpenGL dependencies (GLFW library)
16:07imirkin_: i assume that's bad?
16:07Ident: yea you need glfw
16:07Ident: 3 wont work
16:07imirkin_: how about 2.6?
16:07Ident: can you install it?
16:07Ident: should work too
16:08imirkin_: None of the image codec modules are going to be built.
16:08imirkin_: what does it want me to have?
16:08Ident: CEGUI_OPTION_DEFAULT_IMAGECODEC = SillyImageCodec
16:09Ident: this is all much more complicated than it was supposed to be ;)
16:09imirkin_: i'm not using cmake properly :(
16:09imirkin_: i wish people would just use autotools... they work. gr.
16:09Ident: we had autotools
16:09Ident: we switched to cmake
16:09CptRageToaster: I use gnumake myself....
16:09imirkin_: and then you decided it worked too well so you had to switch to the slower and more confusing cmake?
16:09Ident: i m not sure what the reason was but i think the scale of configuration options
16:10imirkin_: alright, well, i can't figure out how to build it. i guess if i were more interested, i might try, but... wtvr.
16:10Ident: i wasnt part of the decisionmaking process because i m only a dev there for some years
16:10Ident: no problem
16:10Ident: thanks for trying
16:11imirkin_: fwiw this doesn't work: cmake -DCEGUI_OPTION_DEFAULT_IMAGECODEC=SillyImageCodec .
16:11imirkin_: (it still says none of the image odec modules will be built)
16:12Ident: where did you get the sources?
16:12imirkin_: i dunno... sourceforge or whereever the main site linked
16:12Ident: ah ok
16:13Ident: this doesnt include silly
16:13Ident: its in the dependencies package
16:13Ident: i m not sure if you can install this as a package
16:13Ident: or if you need to build it from source
16:13Ident: sources would be here: https://bitbucket.org/cegui/silly
16:13imirkin_: i downloaded the source
16:13imirkin_: and was trying to build it
16:13Ident: ah ok
16:13Ident: what did it say?
16:13imirkin_: but you guys use cmake
16:14imirkin_: which i can't figure out how to operate
16:14imirkin_: it said, "None of the image codec modules are going to be built."
16:14imirkin_: "You should ensure that CEGUI_OPTION_DEFAULT_IMAGECODEC is set to something appropriate."
16:14imirkin_: i'll wait for the apitrace.
16:15Ident: i hope one of the guys will create one
16:15Ident: do you also want an apitrace of a working version?
16:15Ident: it might differ quite a lot though
16:15imirkin_: i would assume it'd be the same
16:15Ident: because the entire program is different
16:15Ident: ah sorry
16:16imirkin_: why do you think it'd be different?
16:16Ident: i mean if you want an apitrace of an older version of the program that seems to work on all drivers
16:16imirkin_: same GL calls, no?
16:16imirkin_: oh, no, don't care about old version
16:16Ident: the calls might be different
16:16imirkin_: presumably it was doing things differently, so who cares
16:16Ident: so you think you can figure things out just based on the one api trace?
16:16Ident: is it just a list of opengl calls?
16:16imirkin_: because this doesn't happen for anything else
16:17imirkin_: a replayable list of opengl calls
16:17Ident: including all data?
16:17Ident: images etc
16:17imirkin_: with fb's and textures explorable in a (crappy) UI
16:17Ident: thats pretty amazing
16:17Ident: i always used gdebugger to find out about issues
16:17imirkin_: not sure what that is... i guess we all have our tools :)
16:17Ident: clearly that lacked a good histor
16:18imirkin_: (or you mean 'gdb'?)
16:18Ident: gDEbugger, it lets you explorer textures, fbos, vbos etc in run-time
16:18imirkin_: oh that's nice.
16:18Ident: should also be available on linux
16:18imirkin_: never heard of it.
16:18Ident: unfortunately its not developed anymore
16:18imirkin_: there's also the valve thing
16:18Ident: but its still good enough for most stuff
16:19imirkin_: which i haven't played with tbh
16:19imirkin_: anywas, bbl
16:19Ident: yea i heard about the valve thing, but is it opne for usage?
16:19Ident: ok bye
16:21Ident: vogl docu says it is alpha², i think i will wait, but it is a promising project. opengl really needs such things
17:12imirkin: skeggsb: i got "remote: tee: hooks/reflog: Permission denied"
17:14skeggsb: imirkin: *shrug* the commit still made it there apparently
17:14skeggsb: imirkin: why do you need the zeta one?
17:15imirkin: skeggsb: parity with the nvc0 one and peace of mind
17:15imirkin: fairly sure it has absolutely 0 effect
17:15skeggsb: i'm pretty sure it should be guaranteed that way already by our default context
17:15skeggsb: but anyways, doesn't hurt
17:15imirkin: right. hence "peace of mind" :)
17:16imirkin: skeggsb: btw i assume you saw my gk208 results?
17:17skeggsb: yeah, so, problem we were trying to address fixed, still other annoying stuff left :P
17:17skeggsb: that's what i took from it
17:17imirkin: skeggsb: well maybe... or it's caused by the pgob stuff? dunno
17:18imirkin: i didn't get that message last time...
17:18skeggsb: yeah i don't think it could be
17:19imirkin: did you see the GM108 trace? either i really can't do math, or it should be 4GB of ram. also the 3d4 error is in a really odd place, not sure how it happens
17:20skeggsb: that error reporting is all async, and can get stomped over by new ones coming in etc, it's not going to be reliable :P
17:20skeggsb: i didn't look properly at that yet, no, but i did glance over your comments
17:21imirkin: yeah, i suspected that, BUT the memory size gets read out as 0xbadf, so i think the timing is suspicious
17:21airlied: not those wierd 3.5GB/0.5GB VRAM setups?
17:22imirkin: well the dude claims it's 1GB
17:22imirkin: which seems low for a "modern" nvidia setup, but who knows
17:22skeggsb: windows apparently says it's 1 too
17:22imirkin: that's what i mean -- he says in windows it's 1GB
17:22imirkin: unless he's totally incompetent
17:23skeggsb: oddly enough, PFB does indeed disagree..
17:24imirkin: but presumably it's right on the GM107, and it's not like they'd have switched the units between chips...
17:24imirkin: esp when it's been the same since GF100
17:26skeggsb: no, it's definitely got 4GiB.. nvidia are filling in page tables with vram addresses up that high too
17:26airlied: 0.5GB/0.5GB split :)
17:27imirkin: ok, so the guy's just lying
17:27skeggsb: or genuinely mistaken :P
17:27skeggsb: or we are, somehow
17:27skeggsb: all are possible
17:27imirkin: why assume incompetence when you can assume malice? :)
17:28airlied: incompetent malice is always a good answer
17:28skeggsb: imirkin: it depends on my mood :P
17:28imirkin: good mood today?
17:29skeggsb: better than yesterday :P
17:29airlied: netflix induced good mood
17:29imirkin: and worse than tomorrow, so... average?
18:14imirkin: mlankhorst: naturally i can't repro that libdrm messup, and valgrind is silent
18:41imirkin: mlankhorst: http://hastebin.com/raw/ovazixeyal -- that's bs, right? just valgrind being paranoid?
18:54slacka_: Is it possible to build mesa so only a single app uses it, instead of it replacing the stable system default?
18:56imirkin: slacka_: use LD_LIBRARY_PATH
18:57slacka_: jmirkin: thanks I'll try it!
18:58airlied: and LIBGL_DRIVERS_PATH
18:59imirkin: i hate that one... i don't trust it :)
19:02airlied: well you need both unless you set --prefix to somewhere
19:03airlied: else you end up searching /usr/local/lib/dri at least here
19:03imirkin: yeah, i set the prefix and point the LD_LIBRARY_PATH at it
19:03imirkin: seems easiest
19:03airlied: I generally don't install
19:03imirkin: and it's the way that every other lib works, which is nicely consistent
19:33slacka_: $LD_LIBRARY_PATH worked for me. Thanks guys!
23:22mlankhorst: imirkin: yes