00:02karolherbst: imirkin: what's the benefit of those 4-byte instructions, shorted encoding or someting else too?
00:02imirkin: less icache
00:03imirkin: i assume it's better
00:03imirkin: could have something to do with dual-issue
00:03karolherbst: I see
00:03karolherbst: at least it saves memory
00:04imirkin: oops :)
00:08karolherbst: this = 0x18
00:09karolherbst: "std::deque with -21 elements"... sounds like memory corruption or something
00:15Doctors: I was looking through the channel logs, however I haven't seen a definite awnser so I decided to ask here. Is there any knowladge/fix as to whats going on when a user receives "java: pushbuf.c:727: nouveau_pushbuf_data: Assertion `kref' failed." ?
00:15imirkin: Doctors: most likely an issue related to concurrent GL commands from multiple threads
00:16imirkin: Doctors: i actually am working on a fix for that as we speak
00:16Doctors: Oh cool
00:17imirkin: if you feel like testing patches, i can share
00:17Doctors: imirkin; Could I be notified if/when you need help testing your fix? I'd love to help out.
00:18imirkin: this is what i'm testing right now: https://github.com/imirkin/mesa/commit/4191a078eb92df5dc049c78bfc49299381213db5
00:19imirkin: note that this is only for nvc0 - it's likely to actually break stuff for nv50 and nv30 in its current state
00:22Doctors: imirkin; Welp guess I can see what gets broken for nv50 then. :-p
00:24imirkin: Doctors: ah, well i just have to fix up the nv50 stuff in order to make it work for nv50
00:24imirkin: i've only done it for nvc0 thus far
00:25Doctors: ahh, mind letting me know when you've fixed up the nv50 stuff?
00:25karolherbst: imirkin: okay, somehow the def list of a Value gets corrupted and a broken instruction is in there
00:25Doctors: I'll build the driver and test it once its ready
00:25imirkin: Doctors: yeah, probably in th enext hour or two
00:25Doctors: alright, I'll hang out in here then
00:25imirkin: nouveau 0000:02:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 2000d [GPR_OUT_OF_BOUNDS]
00:26imirkin: either i'm still messing something up, or ... gr
00:28karolherbst: imirkin: fun. using nouveau_compiler and it works....
00:30imirkin: karolherbst: yeah, that can happen
00:31karolherbst: so it is something like an old shader compilation hasn't cleaned enough
00:32imirkin: more like we don't set something up in nouveau_compiler that we do in the real thing
00:32imirkin: (think the assignSlots() hook)
00:33imirkin: alright. let's see if F1 2015 starts now. if i disconnect, you'll know why.
00:40karolherbst: I will go to bed
00:40karolherbst: seems like the dual issue test has to wait until I or somebody else fixes that crash
00:48imirkin: hm. different death than before.
02:47mark4: so im playhing world of warcraft in linux with nouveau drivers, is there anything i can do to improve my frame rates?
02:47mark4: they are playable, no real complaints, just wondering if i can make it better
02:48mark4: other than reducing quality and window size lol
03:03imirkin: Doctors: ok, i've updated my patch a little better for nv50
03:03imirkin: it seems to not be totally broken ... but ... lots of subtlety
03:03imirkin: Doctors: https://github.com/imirkin/mesa/commit/644f87456825fa7bf4c87e067b723964bcd2e0ae
03:04Doctors: imirkin; Alright I'll check it out tomarrow
03:04imirkin: ok. i will probably have updated it again by then.
03:54Doctors: imirkin; Just ping me if you do, I'll see it when I open quassel tomarrow
09:27Akien: Morning karolherbst
09:28Akien: karolherbst: You mentioned having a kernel patch to prevent everything freezing when trying to reclock a non-powered discrete GPU IIRC?
09:28karolherbst: Akien: well I have patches for keplers and maxwells1 yeah
09:29karolherbst: you mean non powered
09:29karolherbst: I thought I did, but seems like there is still an issue somewhere
09:29karolherbst: which should be rather stupid as well
09:29karolherbst: but for now I just disabled reclocking while the gpu is off
09:29karolherbst: but after the gpu suspends, it will have the same clock state as pre suspend
09:31Akien: So you mean `echo 0a > /sys/kernel/debug/dri/1/pstate` would be discarded if the GPU is off, and then when the GPU gets powered on, it should be reissued to properly reclock it?
09:31Akien: That sounds like a much better situation than the current one already on kernel 4.6.1 :)
09:31karolherbst: well it will be discarded and the gpu won't reclock
09:31Akien: I just had to reboot three times due to a misuse of reclocking while the GPU was in fact OFF :D
09:32karolherbst: only if you reclocked it before suspending
09:32Akien: Sounds good to me
09:34Akien: karolherbst: Do you think that's a patch I could propose to our (Mageia)'s kernel maintainer?
09:35Akien: Or better wait for it to be properly upstreamed?
09:37karolherbst: no idea if it would applie anywhere
09:37Calinou: hi Akien :p
09:38Calinou: karolherbst: btw, I think I will have my GTX 1080 in about two weeks
09:38Calinou: does it matter if it's a non-founders-edition one?
09:38Calinou: ie. with stock overclocking
09:39karolherbst: no clue
09:39karolherbst: we know like not much about pascal yet
09:40Calinou: I'll surely go for non-FE because it costs less
09:44Yoshimo: and often has a better cooling system
09:44Calinou: yes, I want something relatively quiet, especially at idle
09:44Yoshimo: do we know the pci id of the pascal cards already?
10:00karolherbst: Yoshimo: unimportant
10:13Yoshimo: partially, it would benefit the feature detection of wine if we added it there
10:14karolherbst: wine really should ask the driver
10:14karolherbst: and not rely on the pci id
10:14karolherbst: because the pci id isn't always right
10:15karolherbst: mesa will tell you which chipset the gpu has and so will nvidia
10:15karolherbst: but anyway
10:15karolherbst: it doesn't matter, because why should wine even care about that?
10:17Yoshimo: dlls/wined3d/wined3d_private.h & dlls/wined3d/directx.c b/dlls/wined3d/directx.c have lines about this
10:17Yoshimo: for example the 980 patch https://source.winehq.org/patches/data/120633
10:17karolherbst: yeah, for stupid reasons
10:17karolherbst: wine uses that to get the amount of VRAM in a really bad way
10:17karolherbst: because same chipsets can have different vram sizes
10:18karolherbst: there are even some with 512MB/1GB/2GB
10:18karolherbst: and wine would think it has only 512MB allthough it has 2GB
10:18karolherbst: wine-staging has patches to use gl extensions to get that information
10:18Yoshimo: i guess there are cases where asking the driver isn't reporting the right values?
10:18karolherbst: which is the only sane way to do that, really
10:18karolherbst: Yoshimo: nope
10:19karolherbst: and if so, it would be a bug in the driver wine shouldn't care about
10:19karolherbst: because the driver should fix that
10:19Yoshimo: in that case i wonder why they introduced that hack
10:19karolherbst: well the mesa extension is quite new though
10:19karolherbst: but if you would run a pascal on mesa, you will have the extension for sure
10:20Yoshimo: do all cards benefit from that mesa extension regardless of their age?
10:22karolherbst: it depends on the driver actually
10:22karolherbst: I think there is a drm interface for that?
10:22karolherbst: not quite sure
10:22karolherbst: but glxinfo supports that extension
10:22karolherbst: "Video memory: 3068MB"
10:26librin: imirkin, massive thanks for the four conservative revalidation patches
10:26librin: I already reap sweet benefits ;]
10:38hakzsam: librin, cool, which application?
10:39librin: hakzsam, I left a reply on the bug report about it
10:39librin: but overall "all of them"
10:40hakzsam: very nice
10:40hakzsam: but not surprising because the validation path (still) needs to be improved
10:41librin: Guess so
10:41librin: But at the very least, this made Payday 2 actually playable now, as I mentioned in the reply
10:42librin: "oh, happy day!"
10:43hakzsam: cool :)
10:43karolherbst: Yoshimo: nvidia has GL_NVX_gpu_memory_info for the memory amount
11:57karolherbst: imirkin: it seems like the SFU only performs floating points MUL and not the integer ones... odd
12:16karolherbst: 1659->1663 at 120x80 :D
12:18karolherbst: okay, now I have to use the implicit information from the paper too+
12:30karolherbst: 1666 with the kepler dual issue code
12:31karolherbst: now I wonder
12:31karolherbst: maybe that MUL/MAD thing works on my kepler too
12:32karolherbst: mhh wait
12:33karolherbst: all f32 arith ops are dual issued already
12:35karolherbst: hah 1668
13:06karolherbst: why is floor a convert instruction?
13:12karolherbst: okay, it seems like we can usually dual issue everything which is executed on different parts
13:14gregory38: imirkin: hello
13:15gregory38: quick question on the validation of ubo
13:15gregory38: do you validate all of them when 1 is updated ?
13:15gregory38: st_bind_ubos => seems to loop on all uniform block
13:16karolherbst: gregory38: did you see the newest commits on mesa?
13:16gregory38: I saw some
13:16gregory38: yes I have latest master
13:16gregory38: it is better ^^
13:17karolherbst: ahh nice
13:17karolherbst: how big is the difference to nvidia now?
13:18gregory38: I don't know
13:18gregory38: When debian releases the package with 4.6 fix
13:18gregory38: I will install it again and I will benchmark it without the threaded optimization
13:19gregory38: however, I'm nearly sure that there is a room to reduce the validation cost
13:20gregory38: Typically the way I wrote my glsl shader
13:20gregory38: every time I update an uniform buffer
13:21gregory38: the driver will validate 7 (max ubo) * 3 (shader stages)
13:22gregory38: it would be nice to have some piglit program
13:22gregory38: that let's say create N ressources (like UBO/SSBO)
13:22gregory38: but only update 1 every draw call
13:22gregory38: to check the perf impact
13:24karolherbst: piglit is no becnhmarking tool ;)
13:34gregory38: karolherbst: yes I know. It would still be handy to have kinds of worst-case validation program
13:35gregory38: games have too much noise
13:38gregory38: and it would be far easier to compare with others drivers implementations :)
13:41karolherbst: well usually there are enough benchmarks for that, usually
13:41karolherbst: and performance wasn't the primary target anyway
13:43karolherbst: mupuf: 00020340: 000000a0 00000041
13:43mupuf: karolherbst: what is this reg again?
13:43karolherbst: pwm div/duy
13:43karolherbst: and it is like 00020340: 00000060 0000002d on mine :D
13:43mupuf: that is serious!
13:44karolherbst: 3.125mV steps confirmed? :D
13:44mupuf: that is unrelated
13:44karolherbst: yeah I know
13:44karolherbst: but higher div means usually a smaller step size
13:44karolherbst: or not?
13:44karolherbst: 160 div...
13:44mupuf: of course not
13:44mupuf: it is just the frequency that is changed
13:44karolherbst: ahh okay
13:45mupuf: 168 MHz? update rate?
13:45karolherbst: but on some maxwell we used a different div already, didn't we?
13:45mupuf: wait a sec
13:46mupuf: well, this divider is set based on the frequency you want
13:46karolherbst: ahh I see
13:46karolherbst: and we know what freq we want after looking into the vbios voltage table
13:47tobijk: imirkin: for the "add locking" patch, is there something else needed, or just the patch on the ML?
13:47mupuf: karolherbst: yes
13:47karolherbst: mhh okay
13:48karolherbst: anyway, the voltage table is gone and something new came
13:48karolherbst: so this will be a lot of fun for us
13:50karolherbst: ohhh wait
13:51karolherbst: I think I found the table already...
13:53karolherbst: maybe not, where was that strange thing
13:55karolherbst: mupuf: anyway here are all readable tables https://gist.github.com/karolherbst/8df17c1164fe95a94d1d28bd7a3f9628
13:55karolherbst: and the 6c one has some odd values
13:55karolherbst: 675000 // 300000 // 1300000 // 1000000
13:57karolherbst: mupuf: hehe: https://paste.debian.net/714836/
13:57karolherbst: nvidia-smi on a 1080
14:00Lekensteyn: karolherbst: fyi, someone posted a vbios for the GTX 970M at https://bugs.freedesktop.org/show_bug.cgi?id=93896
14:00karolherbst: that guy sholdn't use an outdated kernel
14:04karolherbst: another card with 32bit offsets
14:08Lekensteyn: GTX 965M/970M/980M are the same family afaik
14:11karolherbst: doesn't matter
14:11karolherbst: they can have different vbios
14:11karolherbst: and they will
14:11karolherbst: even two 980M may have different vbios
14:13Lekensteyn: ah ok
14:20LiquidAcid: hello, just a short question concerning firmware. i have a GM107M here on vanilla 4.6.1 and i don't see any fw loading errors/warning during modprobe. is firmware for this hw not needed or optional?
14:21karolherbst: LiquidAcid: not needed
14:21karolherbst: LiquidAcid: except for video accell which won't work anyway
14:22karolherbst: but you have your intel gpu to watch movies, don't you? :D
14:23LiquidAcid: karolherbst, thx, i was wondering since a lot of guides point out that one should have the proper fw in nvidia/hwname, etc.
14:23karolherbst: LiquidAcid: well for maxwell2 you need that
14:24karolherbst: but maxwell1 is fine
14:24karolherbst: we can even fully reclock those if we wanted to :p
14:25LiquidAcid: yeah, i probably leave the gpu off anyway since runpm is not working
14:25karolherbst: what do you mean by runpm is not working?
14:25karolherbst: it messes up on resume?
14:25LiquidAcid: karolherbst, this bug here: https://bugs.freedesktop.org/show_bug.cgi?id=94725
14:26LiquidAcid: karolherbst, i haven't checked resume, the issue already happens when issuing glxinfo
14:26karolherbst: stupid libpciaccess
14:28LiquidAcid: libpciaccess? i figured it was some acpi issue
14:28karolherbst: that too
14:29karolherbst: but libpcieaccess wakesup all pci devices
14:44imirkin: tobijk: just that patch. why, does it not apply?
14:46imirkin: gregory38: ubo's are in a cso, so the driver won't even hear about it. but obviously that comparing is non-free. over-validating is a problem, but also the way that ubo's/images/ssbo's are bound to programs in GL sucks bigtime - through that stupid glUniform() interface. not a whole lot we can do.
14:50imirkin: karolherbst: i was hoping you could take my locking patches for a spin and see if they destroy perf or not
14:50imirkin: er, i guess "locking patch" would be more accurate
14:56karolherbst: imirkin: what do you think would be the biggest perf impact?
14:57imirkin: karolherbst: ideally it'd be ~free
14:58Lekensteyn: LiquidAcid: can you add your acpidump to the report?
14:59Lekensteyn: LiquidAcid: I have the same rpm issue with a Clevo P651RA, a workaround is to boot with acpi_osi="!Windows 2015" such that the problematic win10-specific hack is not executed
15:00karolherbst: imirkin: yeah right, but what should be the worst case scenario?
15:01imirkin: karolherbst: deadlock due to messed up locking
15:01tobijk: imirkin: no, all fine, just wanted to make sure before testing
15:01tobijk: btw do you want me to run some special test workload?
15:01imirkin: tobijk: nope
15:03imirkin: LiquidAcid: all (semi-modern) gpu's need firmware, however up to and including GM10x, nouveau ships its own firmware. starting with GM20x, the gpu verifies a cryptographic signature for uploaded firmware, which means we can no longer supply it.
15:04LiquidAcid: Lekensteyn, acpidump attached
15:04LiquidAcid: Lekensteyn, since schenker uses clevo barebones i guess it's probably the same issue
15:05Lekensteyn: hmm, next time please do not xz compress it :)
15:06LiquidAcid: why not? who' still using gzip :D
15:06Lekensteyn: plaintext :)
15:06Lekensteyn: it is exactly the same issue in the PGON method
15:07Lekensteyn: I spent a week trying to figure out why this happens, but failed https://github.com/Lekensteyn/acpi-stuff/blob/master/Clevo-P651RA/notes.txt
15:07LiquidAcid: maybe, but i'm not going to investigate this more, i don't use the gpu anyway
15:08Lekensteyn: be sure to set acpi_osi="!Windows 2015" then so your battery lasts a bit longer
15:08Lekensteyn: without that, and if you enable runpm (default), then your machine will lock up when you invoke lspci
15:09LiquidAcid: Lekensteyn, just removed nouveau from the kernel again, that also "fixes" it for me
15:10Lekensteyn: that is another workaround
15:10imirkin: LiquidAcid: but now your gpu stays on
15:11Calinou: LiquidAcid: gzip is the "poor man"'s compressor, xz is the "rich man"'s compressor, both have their uses
15:11LiquidAcid: imirkin, i doubt it, i've never seen the fan for the gpu turn on all these months
15:12Lekensteyn: LiquidAcid: it will still consume like 9w idle.
15:12imirkin: LiquidAcid: it definitely stays powered on.
15:12LiquidAcid: Lekensteyn, if that were the case the 9w would have to go somewhere, hence fan activity
15:12imirkin: you need to execute ACPI methods to turn it off.
15:14LiquidAcid: i guess it's turned off by default when booting
15:14Lekensteyn: it is not
15:15LiquidAcid: how do you know?
15:16Lekensteyn: go measure it, leave your laptop idle and watch it drain (/sys/class/power_supply/BAT0/uevent) and do the same after loading nouveau (but be sure not to invoke lspci or something or use the acpi_osi workaround)
15:16Lekensteyn: because... that is what the standards say and what I observe?
15:16Lekensteyn: if you do not load a driver, you can invoke 'lspci'
15:16Lekensteyn: all those values are taken from the PCI config space which definitely needs the device to be powered
15:18karolherbst: the kernel could cache those
15:18LiquidAcid: i guess i'm fine with whatever state the firmware leaves the gpu on boot, as long as the fan doesn't spin
15:19karolherbst: in fact only the revision id is read out from there
15:19karolherbst: if somebody has some time
15:19karolherbst: take this: https://github.com/karolherbst/linux/commit/cb918e4c926990dfcfce92e1ecd905e0896de605
15:19karolherbst: and make pciaccess use this instead of the config space
15:21Lekensteyn: caching would be nice, the device is currently resumed when invoking lspci and when changing between X and a tty
15:22karolherbst: but the kernel already caches the revision
15:22karolherbst: it isn't exposed through sysfs though
15:22karolherbst: basically pciaccess just reads out the revision out of the config space
15:23LiquidAcid: karolherbst, anyway, thanks for the help, going to reboot now
15:24Lekensteyn: lspci from pciutils always reads the pci config space directly and interprets it, maybe it could create a special access mode (-H linux-sysfs2) that tries to re-use existing values as much as possible (to avoid waking)
15:25karolherbst: Lekensteyn: why should lspci do that?
15:25Lekensteyn: should or does? you can dump the full pci config with lspci -xxxx
15:25karolherbst: well it shouldn't when it is initializing the library
15:25Lekensteyn: but the common case (lspci without options) just needs vendor/product id and rev id
15:26karolherbst: but I also thought lspci uses pciaccess
15:26karolherbst: Lekensteyn: right, and rev id is only in the config space currently ;)
15:26karolherbst: or does lspci also reads the config space for vendor/product it?
15:38mupuf: karolherbst: the witcher 2 is quite busted
15:38mupuf: so is talos principles
15:39karolherbst: yeah, we know
15:39mupuf: on the titan
15:39karolherbst: also on my kepler
15:39karolherbst: let me guess
15:39karolherbst: broken vertices with witcher2
15:39mupuf: ok, I only see renderng issue on the lowest setting
15:39karolherbst: and flickering ground with talos?
15:39mupuf: yes and yes
15:39karolherbst: imirkin looked into the talos issue at one point but didn't find anything
15:40mupuf: I was trying to make an apitrace
15:40karolherbst: withcer2... it is ARB_image_copy related or something else
15:40mupuf: but failed to, how do you do it?
15:40karolherbst: let me see
15:40karolherbst: mupuf: apitrace trace Application
15:40mupuf: karolherbst: I know this, but for steam games?
15:41karolherbst: usually you can always run them from cli
15:41mupuf: I see
15:41mupuf: I can try
15:41karolherbst: sometimes you have to set LD_LIBRARY_PATH to the ubuntu12_32 directory
15:41karolherbst: mine is at ~/.steam/steam/ubuntu12_32
15:41karolherbst: no idea where yours is
15:41karolherbst: usually when the steam API can't be loaded
15:41karolherbst: you have to add this path
15:41karolherbst: (and steam has to run)
15:42tobijk: and you need an 32bit apitrace *urgh* :D
15:42karolherbst: some launcher shell scripts are smart and detect this
15:42karolherbst: like when they see the game isn't started through steam
15:42karolherbst: they do xdg-open steam://game/11111 or something
15:42mupuf: tobijk: oh, right
15:42tobijk: mupuf: for 32 bit games only ofcourse
15:43karolherbst: mupuf: or you could modify the steam command line
15:43karolherbst: and add "apitrace trace %command%"
15:43karolherbst: but then the trace file ends up elsewhere
15:43mupuf: karolherbst: yeah, my issue is that i ran the wrong apitrace in the end
15:43karolherbst: I see
15:44mupuf: why the fuck do people still make 32 bit games?
15:44karolherbst: imirkin: but you are right, your locking doesn't look like something we want to do actually :/
15:44karolherbst: mupuf: VP can't port games
15:44karolherbst: mupuf: they _don't_ have source access
15:44karolherbst: so they just get the windows stuff and have to deal with that
15:44karolherbst: like wine does
15:45imirkin: karolherbst: are you seeing a perf impact?
15:45karolherbst: but yeah, usually a lot of other games are 32bit only too
15:45karolherbst: imirkin: nope, just reading the code and the only thing which comes in my mind "you usually want to lock data, not function calls" :/
15:45imirkin: karolherbst: i am locking data
15:45tobijk_: mh, something is up with 4.7rc and nouveau, since this merge window i see sporadic system hangs :/
15:45imirkin: karolherbst: i'm locking the pushbuf
15:46karolherbst: what about nouveau_transfer_staging?
15:46karolherbst: allthough I have no idea what it does :/
15:46imirkin: karolherbst: what about it?
15:46karolherbst: you lock that too
15:46imirkin: that's coz i'm a retard
15:46imirkin: thanks for pointing that otu
15:46karolherbst: I see
15:46imirkin: i meant to lock the nouveau_transfer_read
15:47karolherbst: you also lock nouveau_buffer_cache, but I guess that's fine
15:47imirkin: because it calls nouveau_buffer_read :)
15:47imirkin: but i don't want to have locks in EVERY little place
15:47imirkin: that's a lot of lock acquisition for the overwhelmingly common case of "no contention"
15:48imirkin: i'd rather have ever-so-slightly longer critical sections
15:49imirkin: karolherbst: i've updated the github copy
15:49karolherbst: nv30 branch I geuss
15:50imirkin: it's the one i'm on now :)
15:50imirkin: i meant to do nv30 work
15:50imirkin: and see what happened
15:50karolherbst: well, I also did some tesla work today :)
15:50karolherbst: never thought I would _ever_ do that :D
15:50imirkin: you can look at the bug that was filed today
15:51imirkin: it's only an issue on tesla it seems
15:52karolherbst: currently I have no internet access on that machine :/
15:52hakzsam: mupuf, are you using reator?
15:52mupuf: hakzsam: nope
15:52karolherbst: imirkin: it annoys the heck out of me, that the b43 wifi driver doesn't work, so I have it directly connected with my laptop...
15:52karolherbst: have to setup internet passtrhough at some point
15:53imirkin: karolherbst: just make a bridge
15:53imirkin: (an ethernet bridge)
15:54karolherbst: yeah, I know that it is possible somewhat. Whenever I read about this, it involves iptables and stuff...
15:54karolherbst: allthough I could just connect it directly into my router, but then I have to find a socket for power
15:55imirkin: that's NAT
15:55imirkin: i'm talking about a bridge
15:55imirkin: look into "brctl"
16:30karolherbst: .... why would you build fans in a way, that you can't detach them from the motor...
16:37karolherbst: and now I have a silent fan :D
16:49hakzsam: imirkin, btw, I already checked few days ago about nouveau_bufctx_reset(), should be fine now (no need to make a new patch)
16:49imirkin: hakzsam: there's definitely at least on ehack that has to be undone
16:49imirkin: which was when i stuck it into a validate function
16:50imirkin: which is totally the wrong place for it
16:51hakzsam: imirkin, that hack is in nvc0_validate_suf()
16:51imirkin: yeah, that needs to be removed
16:51imirkin: nouveau_bufctx_reset has no place in a validate function
16:52hakzsam: imirkin, yeah, it should be moved where the dirty flag is updated
17:02mupuf: karolherbst: AHAHAHAHAHAh
17:05karolherbst: mupuf: ? :D
17:05mupuf: karolherbst: silence fan
17:05karolherbst: ahh right
17:05karolherbst: I didn't mean I broke it
17:05karolherbst: (allthough I was well aware some might think that :p ) :D
17:07karolherbst: now let's see if dhcpcd also works now
17:09karolherbst: very nice
17:09karolherbst: who needs dbus!
17:11tobijk_: karolherbst: you are going the hard way? :D (no dbus and such)
17:11karolherbst: "server" basically
17:11karolherbst: bascially 35% of all running procces are the getty :D
17:12karolherbst: and now, how can I turn that frigging gpu off
17:13tobijk_: just remove the card (if its a desktop)
17:13karolherbst: it's a mac mini
17:13karolherbst: the gpu is like 70°C idle
17:14karolherbst: no envytools installed :O
17:36jneto: what reclocking changes happened between kernel 4.3 and 4.4?
17:37karolherbst: jneto: why you ask?
17:37jneto: because reclocking its broken for me in linux 4.4.
17:37karolherbst: well a fix for gddr5 reclocking on kepler landed
17:38karolherbst: jneto: what gpu do you hav?
17:38jneto: nvs 3100m
17:38karolherbst: and what do you mean by "broken"?
17:38karolherbst: that's a gt218, right?
17:38karolherbst: with gddr3
17:38karolherbst: mhh no idea
17:39jneto: my system freezes and screen glitches.
17:39karolherbst: I think imirkin or RSpliet know something about it
17:39imirkin: jneto: as in it broke in 4.4 but was working in 4.3?
17:40imirkin: there were, in fact, a bunch of changes there
17:40imirkin: jneto: could you bisect the nouveau changes? shouldn't be *too* many i think
17:41imirkin: RSpliet added G94+ support in that kernel, and there were a handful of updates to the GT21x logic as well
17:42imirkin: jneto: specifically i'm thinking of this change: https://github.com/skeggsb/nouveau/commit/393f16f3b36032de84904025eef125f7723ea0dd
17:42imirkin: as well as this one: https://github.com/skeggsb/nouveau/commit/c4440d4caa441ae3b03ea76a671b68957561ef7c
17:44RSpliet: imirkin: I don't think either of those changes hit gt218
17:46karolherbst: well in the end git bisect might help
17:47karolherbst: could it been fixed by newer nouveua?
17:48karolherbst: 4.4 is a bit old, but I don't know if anything related to that changed
17:48RSpliet: I don't think many patches were pushed since
17:48karolherbst: when did the rework happen again?
17:48RSpliet: as in, nothing changed to ramgt215.c since
17:49karolherbst: jneto: could you provide us with any error logs?
17:53jneto: linux 4.5 it's affected too.
17:54jneto: and there are no errors in log.
17:55imirkin: jneto: a log will provide information like what chip you have and what kind of ram
17:56karolherbst: why nouveau doesn't report the voltage on my nvac...
17:57karolherbst: ohh right
17:57karolherbst: voltage table, but no VID_GPIOs
17:57karolherbst: jneto: well, we would need what comes after loading nouveau ;)
17:57karolherbst: especially when something bad happens
18:00jneto: ok i'll reproduce the bug here. but, like i said, there are no errors in the log from past freezes.
18:01karolherbst: imirkin: okay, I have your locking code applied now, I will scream when something breaks
18:01karolherbst: jneto: can you ssh into the machine?
18:02orbea: nothing if you ssh, type dmesg -w and then repeat the freeze?
18:05jneto: i only have this machine.
18:07karolherbst: jneto: do you know if the machine itself crashes or just no output?
18:09jneto: i'm not 100% sure if it crashes, but i lose control from input too.
18:11jneto: i try to blindly reboot my machine, without success.
18:11karolherbst: jneto: the echo command might hang forever
18:12karolherbst: or other things hang really long
18:12karolherbst: without a second machine this might be a bit tricky to debug
18:12karolherbst: no phone?
18:13karolherbst: allthough I have no idea how hard it is to install terminals on stock roms...
18:13jneto: my phone is not smart.
18:14RSpliet: jneto: try enabling and rebooting using magic sysrq
18:14karolherbst: good idea
18:14RSpliet: that should help preserve logs well enough to survive a reboot
18:14karolherbst: sync discs before that though
18:15RSpliet: oh yes, the full REISUB sysrq dance
18:15karolherbst: RSpliet: well, sysrq reboot is pretty harsh and direct
18:15karolherbst: reisub? :D
18:15karolherbst: ahh right
18:15karolherbst: I usually skip that
18:17karolherbst: well if anybody wants to hack on my nvac, I might be able to make it available through the net somehow now
18:18karolherbst: now that the fan is fixed, it won't annoy anybody
18:18RSpliet: magic sysrq is disabled by default on Fedora though, make sure to configure properly first
18:18jneto: there is something that never worked for me - at least not in my 2 tries.
18:19RSpliet: karolherbst: I already had my fun with NVCE
18:19jneto: my sysrq key is also a printscreen key.
18:19karolherbst: RSpliet: well there is more fun now!
18:19karolherbst: RSpliet: another crash running pixmark_piano
18:20karolherbst: the instruction from frame #0 is bricked
18:21RSpliet: NVAC is only useful for it's hw video decoder,never tried serious GL workloads on it :-P
18:21RSpliet: jneto: there's plenty of guides on how to get magic sysrq to work with Fedora, otherwise the guys in #fedora can probably help
18:21karolherbst: I was able to increase the performance of pixmark_volplosion by 0.5! yesterday
18:21karolherbst: not so useless anymore now!
18:22RSpliet: unless you find a way to make gnome shell run at 60fps, I'm not impressed :-P
18:22karolherbst: piece of cake!
18:22RSpliet: *in full HD
18:23karolherbst: but I am sure my nvac is the fastest there is
18:24karolherbst: or are the mcp7a faster than the mcp79?
18:24karolherbst: uhh, seems that way
18:24RSpliet: AC: core 450 MHz shader 1100 MHz vdec 450 MHz ?
18:24karolherbst: I am sure you also have the 9400m, right?
18:25RSpliet: "03:00.0 VGA compatible controller: NVIDIA Corporation ION VGA (rev b1)"
18:25karolherbst: ohh ion
18:25karolherbst: it is a 9400m
18:26RSpliet: that board has a BIOS setup utility that lets me pick a shader core speed... if I want 1400MHz, I reboot and set it to 1400 :-P
18:26karolherbst: without volting this is really usefull
18:26RSpliet: it adjusts the VBIOS accordingly
18:26karolherbst: or does your nvac have vid_gpios?
18:26RSpliet: none of the NVACs have that afaik
18:27RSpliet: looked through quite a lot of VBIOSes back then
18:27RSpliet: (same for NVAA)
18:27karolherbst: they have the voltage table though
18:27RSpliet: it's a waste of bits
18:27karolherbst: but all PM_Mode entries point to 1.01V
18:28karolherbst: not for me
18:28karolherbst: 0.9 and 1.01
18:28karolherbst: stupid engineers
18:28karolherbst: my card idles... at 78°C
18:28karolherbst: not even X is running
18:47jneto: ok, reisub method worked after the screen glitch.
18:47jneto: but no errors on log.
18:47jneto: journalctl -b -1 -o cat | grep nouveau
18:52karolherbst: skeggsb_: push that stuff of yours! :P (and update the vbios repo before ;) )
18:54karolherbst: RSpliet: I've pushed a gp1080 trace now, just curious if you want to check something
18:59Unseen2: I'll keep the Linux installation on that box just in case you need more data...
19:00karolherbst: yeah, would be great
19:01karolherbst: one of our devs might be interessted in it
19:01karolherbst: but he lives in australia
19:01karolherbst: Unseen2: skeggsb_ would be the one
19:02karolherbst: but the low engine clock really looks interessting
19:02karolherbst: ohhhhh my god...
19:02karolherbst: those SEQ scripts
19:02Unseen2: It went up a bit just by moving the mouse and back into triple digits when moving a window IIRC
19:03karolherbst: most likely idle downclocking
19:03karolherbst: or idling
19:03karolherbst: like cpus do today
19:04karolherbst: pascal will be a big change
19:05karolherbst: I hope that reclocking stuff isn't different on the 1070
19:05Unseen2: Isn't the current assumption that the 1070 is the same chip with one-quarter of the units disabled?
19:06karolherbst: it has GDDR5 instead of GDDR5X
19:06Unseen2: Ah, ok
19:06karolherbst: well on maxwell 1 the memory reclocking bits are as on kepler
19:06karolherbst: I just hoped on pascal we won't have big changes there
19:07karolherbst: well the gddr5x one will change for sure
19:07karolherbst: now I am really curious
19:07karolherbst: Unseen2: could you check if "nvapeek 0x20340 0x8" changes the output
19:07karolherbst: depending on the clock set?
19:13Unseen2: It does. The first value stays at 0xa0 all the time, the second one varies. It's 0x34 while idling, 0x58 while running glxgears and there was an intermediate value of 0x3c after it powered down again after stopping glxgears.
19:14Unseen2: I also saw 0x68 once before the first "idle", but that didn't show up again
19:15karolherbst: are you sure it completly reclocked while you traced?
19:15karolherbst: ohh wait
19:15karolherbst: it is me being stupid
19:15Unseen2: Do you want me to capture a video? ;)
19:15karolherbst: I hope
19:16karolherbst: we have a problem
19:16karolherbst: mupuf: fun, and in such amounts we can't handle that
19:16karolherbst: mupuf: I am like sure, the driver doesn't change the voltage
19:33Unseen2: karolherbst: Checking again, the card may not have reclocked fully in my trace - the first GPU clock I see after starting X is 17xx MHz, but after idling once it only goes back to 160xMHz with glxgears
19:35karolherbst: it doesn't have to reclock full
19:35karolherbst: just high enough so that it actually matters
19:41Unseen2: In that case the trace should be ok
20:01imirkin: ugh. these jokers are sticking unsynchronized bits where they don't belong =/
20:03imirkin: looking at the payday trace
20:03imirkin: trying to figure out wtf is going on
20:03karolherbst: well its wine
20:05imirkin: with rather limited success, i might add
20:05karolherbst: I can create more traces for you if you want :p
20:05tobijk_: the he was going towards wine :)
20:16RSpliet: jneto: whoa, okay, you might have the first GDDR3 NVA8 that I've seen
20:18Doctors: imirkin; I should be able to test your patch in the next hour or two, just need to firgure out how to patch your code in with nouveau-git from the AUR.
20:18RSpliet: and judging by the only differences between 4.3 and 4.4, I'm guessing you have a VBIOS for which the FBVDDQ bit is always zero, and nouveau is not supposed to touch the voltage (rather than fiddling with it)
20:18tobijk_: imirkin: somewhere we failing lately: nouveau 0000:01:00.0: bus: MMIO write of 00000002 FAULT at 4188ac [ !ENGINE ]
20:20RSpliet: as far as your problems go, I understand the problem, but the fix is going to take 1) your VBIOS and strap register value (0x101000), 2) a trace of the official driver to confirm, and 3) time, of which I have very little unfortunately
20:26imirkin: tobijk_: is this new with my patch? i hope not =/
20:29tobijk_: imirkin: o gernally lately
20:30imirkin: ah ok. then i dunno
20:30imirkin: actually i didn't know either way :)
20:47Rush__: hi guys :) The problem I have is that on the screen which is driven by nouveau I am getting mouse cursor artifacts (left over graphics from moving cursor). Ttoday I migrated from NVIDIA binary blob on Thinkpad T420 with Optimus disabled in the BIOS to Intel+Nouveau Opimus setup with a reverse prime Display Port secondary screen. I am using KDE / Plasma5 and Kwin. I am running openSUSE tumbleweed. Any ideas?
20:49imirkin: Rush__: that generally points to an out-of-date xf86-video-intel
20:50imirkin: Rush__: nouveau just draws whatever image it's handed to by the intel ddx
20:50imirkin: Rush__: and i don't think there's hw cursor support for reverse prime, so it's composited on there
20:50Rush__: I see, the version I have is reported as 2.99.917.651_g34f63f2-2.1
20:50imirkin: what version of Xorg?
20:51tobijk_: imirkin: its tumbleed, so its pretty recent :)
20:51imirkin: well there goes my theory.
20:51imirkin: yeah, that's a recent ddx and xorg
20:51tobijk_: Rush__: you could try X11:XOrg
20:51imirkin: nah, 1.18.3 should be fine
20:51imirkin: Rush__: are you using SNA or UXA?
20:51tobijk_: for the latest available
20:52imirkin: and which (intel) chip is this? SNB?
20:52Rush__: yes, SNB
20:52tobijk_: imirkin: default is SNA and DRI2 :>
20:52imirkin: i have a T420s without the nvidia :)
20:53imirkin: either way, i still maintain this is a not-nouveau issue
20:53Rush__: I think I'm using DRI3 cause the secondary monitor works over hard-wired display port works out of the box after I modprobe nouveau (good job guys!)
20:53imirkin: however a bunch of people have run into this
20:53imirkin: and for some of them, the issues magically went away at one point
20:53imirkin: but not for others
20:53tobijk_: Rush__: dri3 is disabled in standard builds for tumbleweed
20:53imirkin: i have no idea what distinguishes one group from the other
20:53Rush__: but I'm unfamilar with SNA/UXA
20:53imirkin: Rush__: pastebin xorg log
20:53tobijk_: Rush__: care to share your x log?
20:54tobijk_: <-- tumbleweed user btw :D
20:54Rush__: tobijk_ imirkin https://pastie.virtkick.com/hash/241c2f81c6a/txt/
20:55Rush__: tobijk_: I just upgraded to tumbleweed, so far everything works (except the cursor problem, but it existed in Leap as well)
20:56Rush__: I really appreciate your help guys
20:56tobijk_: Rush__: if you are up to a little journey, you could try my dri3 builds :>
20:57imirkin: i have no idea... you could try #intel-gfx and see if they remember how people dealt with that problem
20:57Rush__: tobijk_: does it involve compiling or just installing from a repo? :)
20:57tobijk_: Rush__: installing, but you need 3 of them
20:57karolherbst: imirkin: so far nothing locked up, I get the feeling something increased performance _a_lot_ in a game, no idea what is was though...
20:58Rush__: tobijk_: ah, no worries then, I can always downgrade if stuff breaks
20:58Rush__: I just need this laptop working for tomorrow morning
20:58tobijk_: hehe, maybe do it tomorrow evening then ;-)
20:59tobijk_: Rush__: aynway its a pretty easy, repos = X11:XOrg, tobijk:X11:XOrg and tobijk:X11:XOrg:Unstable
21:00tobijk_: they get more unstable the further you go
21:00Rush__: so I gather I should try one after another, going from the left and via `zypper dup --from <repo>` ?
21:01tobijk_: they do not contain always all packages, so you will keep the packages from the repos prior in the list as the build onto each other
21:07Rush__: tobijk_: if I may ask, what are the benefits of DRI3?
21:07imirkin: karolherbst: probably the image/ssbo validation thing
21:08karolherbst: imirkin: well, maybe, but I thought cpu overhead gets like unimportant when the game starts using SMAA
21:08karolherbst: and SSAO
21:08imirkin: depends i guess
21:09Rush__: tobijk_: https://build.opensuse.org/project/repositories/home:tobijk:X11:XOrg -this shows only factory and leap
21:10Rush__: btw. I can work around the mouse cursor artifacts by enabling Full screen repaints in Kwin
21:11karolherbst: Rush__: if you do that, you _want_ dri3
21:12karolherbst: but this may be a simple vsyncing issue
21:12karolherbst: to properly vsync with prime offloading, both gpus have to "vsync"
21:12karolherbst: or more like the clients and the display side
21:13Rush__: how to check if I have DRI3 enabled?
21:13karolherbst: Rush__: I guess when you run glxgears a bit bigger and move it around, you should also see some tearing artifacts?
21:14Rush__: karolherbst: only the cursor
21:15Rush__: rest seems to be fine. It was not fine on old kernel and old xorg but after having everything recent, it seems only the cursor is the problem.
21:16karolherbst: I see
21:16karolherbst: imirkin: well, seems like the game engine was just improved due to updates... no perf change since 11.0
21:16karolherbst: ohh maybe this was a perf regression...
21:17imirkin: karolherbst: it was.
21:18imirkin: karolherbst: ssbo/images made it worse
21:18Rush__: ok getting better. I upgraded to tobijk_'s supposedly DRI3 enabled xorg and the cursor artifacts are fixed. I have no way to check if it's DRI3 though. :) there are some other problems though. If I have glxgears on the Intel driven monitor, the cursor is blinking. If glxgears is on the nvidia driven monitor cursor is ok and stable.
21:18karolherbst: imirkin: since when is ssbo/images merged/enabled? 11.2 or later
21:19tobijk_: Rush__: oh sorry was away for a short time
21:19imirkin: Rush__: there's a limitation in xorg right now -- the cursor is composited by the originating gpu for reverse prime screens
21:19tobijk_: Rush__: use Factory, its Tumbleweed with another name nowadays :>
21:20Rush__: and on DRI2 running glxgears gave me 120 FPS, and on DRI3 it's 60FPS so I guess it is vsynced now?
21:20Rush__: with DRI_PRIME=1 I mean
21:20tobijk_: DRI3 should give you more performance and hopefully avoid copies
21:20tobijk_: Rush__: yes vsync is on
21:21Rush__: and if I run google-chrome via DRI_PRIME and have it on reverse prime monitor, will the buffers go the route of Nvidia -> Intel -> Nvidia or some more efficient way?
21:22xexaxo: Rush__: if you use newish mesa $LIBGL_DEBUG=verbose glxgears should tell you whether DRI2 or DRI3 is used
21:22imirkin: Rush__: all rendering is done on the "main" gpu, in your case intel
21:22imirkin: Rush__: oh, wait, i see what you're saying. yes.
21:22imirkin: everything goes through the main gpu
21:23Rush__: xexaxo: thank you sir, it's DRI3 all right ;)
21:23xexaxo: newish = 10.6
21:23Rush__: imirkin: ok so I guess it's just not a good idea then
21:23xexaxo: Rush__: props goes to mupuf for adding the debug text ;-)
21:23tobijk_: xexaxo: he is somewhere at 12.0-rc to mesa head :D
21:24imirkin: Rush__: well, if you think about it, doing anything else is wildly complicated
21:24xexaxo: tobijk_: ack. ty
21:24tobijk_: np :)
21:25Rush__: so another question if I may, is my GPU reclockable? NVIDIA Corporation GF119M [Quadro NVS 4200M]
21:25xexaxo: imirkin: props for the WIP locking (multithreaded GL) patch.
21:25imirkin: not by nouveau
21:25imirkin: xexaxo: we'll see if it works :)
21:25imirkin: i hit quite a few deadlocks during development
21:25tobijk_: imirkin: xexaxo: it works fine on a first glance here
21:26xexaxo: imirkin: I won't be able to test any time soon, sadly :-(
21:26imirkin: no worries
21:27Rush__: imirkin: well, I wouldn't mind rendering and compositing the browser fully on nvidia but I understand it would require full support from the compositor or smth like that. :)
21:27imirkin: Rush__: well, it's questionable whether the NVD9 is faster than the SNB
21:27imirkin: Rush__: i can definitely tell you that in terms of reliability, the intel is WAY more reliable than nouveau-driven hw
21:28tobijk_: Rush__: if you are really using :Unstable, be warned again, that it may break with every update
21:28Rush__: tobijk_: I didn't go as far as to Unstable, your basic Xorg repo managed to fix the cursor
21:28imirkin: Rush__: without reclocking, the only reason to use that NVD9 is if you need GL 4.x features, which nouveau mostly supports
21:28jneto: RSpliet: 1) how can I get the 'strap register value'? 2) how? any instructions?
21:29jneto: should I open a bug report?
21:29Rush__: imirkin: oh yeah, I sometimes enjoy trying out some fancy new WebGL, 3d view google maps etc.
21:29Rush__: some of those require new opengl features
21:29imirkin: Rush__: the intel snb can handle all that just fine
21:29imirkin: mmmm... i don't think so. none of that is piped through webgl afaik
21:29RSpliet: jneto: for tracking purposes that'd be really good yes
21:30RSpliet: but 1) install envytools and as root run "nvapeek 0x101000"
21:30Rush__: imirkin: also I used to play Fallout New Vegas on this laptop on binary NVidia. I don't know if Intel can handle it. No time to play games these days though.
21:31RSpliet: 2) the Ubuntu guys have a relatively good manual for this, see https://wiki.ubuntu.com/X/MMIOTracing
21:31imirkin: Rush__: sure, but my point is that your gf119 is probably clocked to middle or low clocks by default. and with those speeds, you get really shitty perf
21:31RSpliet: (although the module will never be called "nvidia-current" on Fedora)
21:32Rush__: imirkin: yeah I get it. :-) 3d view on google maps work fine on your DRI3 branch and I'm happy I have a working Optimus setup after all these years \o/ big kudos to all of you working on Linux graphics
21:33RSpliet: sorry I can't help you with solving this bug on the very short term. I have some more pressing (non-nouveau) work requiring my attention right now
21:33RSpliet: if you file a bug, I can come back to it afterwards (but that might take a month or so)
21:33tobijk_: Rush__: btw, right now the only difference for you and the default repo is an enabled DRI3 xf886-video-intel
21:34Rush__: imirkin: oh I know what will not work in this setup for sure. Cities Skylines. It had only Nvidia support for Linux.
21:34tobijk_: ah and mesa (ups)
21:34RSpliet: in the meanwhile, I can recommend you to either run kernel 4.3 or build your own kernel with the 4.4 patches reverted
21:35imirkin: Rush__: well, you can always try stuff with nouveau - in general the GL component is fairly standards-conformant. of course that's of little consolation when the GPU is running at 1hz
21:36Rush__: imirkin: I have probably one last question, will nouveau put my GPU go to sleep if I disconnect the external monitor?
21:36imirkin: Rush__: should, but potentially won't :)
21:37imirkin: Rush__: you can check by cat'ing the vgaswitcheroo file
21:37imirkin: it should say DynOff it it's powered off
21:37Rush__: what's the full path to the file?
21:37imirkin: (which lives in /sys somewhere)
21:37Rush__: ah ok
21:37tobijk_: Rush__: you should even be able to notice it in dmesg
21:37Rush__: find is faster
21:37jneto: ok. no problems at all. thanks for you willingness.
21:40Rush__: imirkin: it just says 0:IGD:+:Pwr:0000:00:02.0\n1:DIS: :DynPwr:0000:01:00.0 - no changes after disconnecting the monitor. Is there some timeout, should I wait longer?
21:40imirkin: Rush__: yeah... i think like 5-10s
21:40imirkin: for DIS it should say DynOff
21:41imirkin: i think i saw a patch recently
21:41imirkin: which fixed some broken logic in there, which made it not suspend after you used it with reverse prime
21:45imirkin: Rush__: you can also check /sys/kernel/debug/dri/1/clients to see if anything's still using it
21:45tobijk_: imirkin: you sure about the "1"? for me its 0 or 1 :>
21:46imirkin: "the nvidia one"
21:46imirkin: normally it's on 1 for optimus
21:48tobijk_: imirkin: yeah for DRI_PRIME its always 1, but the probling makes it in /debug 0 or 1
21:49imirkin: normally it's 1 :)
21:49imirkin: but not always
21:49tobijk_: imirkin: from an observational pov it is a 50% 50% chance :>
21:50imirkin: heh ok
21:52karolherbst: tobijk_: both modules?
21:52karolherbst: or both builtin?
21:53tobijk_: karolherbst: both modules, but maybe my system is extra unlrelaible :D
21:55tobijk_: mhpf i should try to fix the drm subsystem hang if you try to reclock nouveau when the card sleeps
22:23Rush__: playing youtube seems to be really hard on my current setup, it seems everything comes to a crawl, I wonder why ....
22:24Rush__: all rendering, regardless of monitor becomes ultra slow
22:25imirkin: this is all running on your intel setup
22:25imirkin: i think you're looking for #intel-gfx
22:25Rush__: imirkin: sure, sorry for off topic :)
22:27imirkin: you're just not reaching people who know about this here.
22:27imirkin: fwiw youtube works fine on my T420s :)
22:27imirkin: but i also don't do crazy stuff, like use a GL compositor
22:32Rush__: imirkin: why I like using the GL compositor is that it fixes all the terrible artifacts when opening yakuake, moving windows etc.
22:33imirkin: i prefer the 1980 style of things. in that view of the world, compositor = crazy
22:33tobijk: thats call a purist :D
22:34Rush__: imirkin: you're one of the guys still using motif?
22:35Rush__: I remember the days when X11 over network was working fine, good times :)
22:36Rush__: but looking forward to burning that past and moving to Wayland one day ...
22:36tobijk: the problem is right now neither is there :/
22:44imirkin: Rush__: hah, motif. those were the days. no, i use largely modern applications. just no compositor/etc.
22:44imirkin: no kde stuff though
22:45imirkin: i have my standards :p
22:45imirkin: hakzsam: nve4_set_surface_info:830 - unsupported surface format, try is_format_supported() !
22:45imirkin: hakzsam: very odd - esp since this is an application that definitely doesn't use images
22:45Rush__: I'm actually surprized I still use KDE considering how broken plasma and friends are.
22:51imirkin: hakzsam: OH! i bet it's the stupid pbo download thing
22:51imirkin: yep, sure enough. st_ReadPixels
22:51imirkin: with BGRA8_UNORM
23:04andril: i am running Debian 8.4 and noticed that neofetch shows my card as nvidia but details shows intel ivy bridge am i missing something?
23:07imirkin: andril: you probably have both
23:08andril: i have been experiencing freezing in gnome-shell and wonder if this is the issue
23:09imirkin: andril: pastebin xorg log
23:09andril: imirkin, kinda n00b here how can i do it?
23:10andril: imirkin, Display Adapters NVIDIA GeForce GT 630M Intel(R) HD Graphics 4000
23:10imirkin: andril: cat /var/log/Xorg.0.log - paste on your favourite paste bin website
23:10imirkin: provide link
23:11andril: just a sec
23:14andril: imirkin, http://pastebin.com/TBgTzdVs
23:15imirkin: andril: this is all running off your IVB chip
23:15imirkin: the nvidia GF117 chip is available for offloading, but you'd have to explicitly request that when launching an application
23:16andril: damn how do i get it on the nvidia chip
23:16imirkin: i don't think you want to do that
23:16imirkin: it will be slower and less reliable
23:17andril: understood that's why i ask the pros thanks imirkin :)
23:17imirkin: ideally the benefit you're getting from nouveau right now is that it's suspending that chip, and so you're getting the power savings
23:21Doctors: imirkin; How do you compile the nouveau driver and install it? I think I'm taking the hard way to doing this.
23:23imirkin: Doctors: ./configure --prefix=/home/user/install ...; make -j8 install
23:23imirkin: Doctors: LD_LIBRARY_PATH=/home/user/install/lib foo-application
23:24Doctors: knew there was an easier way
23:25andril: thanks imirkin
23:35Doctors: imirkin; Thats not working, is ./configure correct?
23:36imirkin: it's a regular autoconf thing ... first time using it?
23:36imirkin: if so, first run NOCONFIGURE=1 ./autogen.sh
23:36imirkin: which should generate a configure script
23:37imirkin: and then you can run ./configure --help
23:37imirkin: for the various options available