00:02mupuf: karolherbst: are you trying to make the GPU take off?
00:02mupuf: it is as loud as my vaccuum cleaner :o
00:02karolherbst: sorry, I checked the therm downclocking
00:02karolherbst: it really downclocks really early
00:03karolherbst: at 82°C it dropped down to 24th cstate
00:03mupuf: yeah, please postpone this test until tomorrow :D
00:03karolherbst: at 80 it was at the 37th one
00:03karolherbst: yeah I am done with that anyway
00:03karolherbst: it was just a quick check
00:03mupuf: found anything interesting?
00:03karolherbst: the power reading stuff seems right on our end
00:04karolherbst: the value is wrong
00:04karolherbst: let me disable the last rail to confirm
00:04karolherbst: k, all rails off now
00:06karolherbst: I can't speak french, nvagetbios throws out strange stuff :D
00:06karolherbst: -bash: /home/mupuf/nvidia/envytools/build/nva/nvagetbios: Erreur d'entrée/sortie
00:07karolherbst: ohhh, mhh
00:08mupuf: what the heck
00:08mupuf: well input/output error
00:08mupuf: but still
00:08karolherbst: yeah, I noticed
00:08karolherbst: well my system crashed with such stuff
00:08karolherbst: faking vbios and stuff
00:09karolherbst: k, reboot to nouveau without issues
00:10karolherbst: k, reboot to blob without issues
00:10karolherbst: well the card has 6GB of vram
00:10karolherbst: maybe nvafakebios can't handle that :D
00:10karolherbst: or nvagetbios
00:11karolherbst: yeah, it is so that one rail
00:11karolherbst: all disabled: nvidia fails to init
00:12karolherbst: all rails removed except the one nouveau reads: 56W
00:12karolherbst: nouveau code: around 12W
00:13mupuf: why is nouveau reading only one rail?
00:13mupuf: that explains why I maxed out at 70W
00:13karolherbst: nvidia also only reads out one rail
00:14karolherbst: now there is just one :D
00:14mupuf: sure sure
00:14mupuf: so we have an issue reading the power AND we also read only one out of the three channels? :D
00:14karolherbst: there is just one active channel
00:14karolherbst: I read out all three on nouveau
00:14karolherbst: still 12W
00:16mupuf: so, in hw, only one channel is measuring something
00:17mupuf: the others are not connected?
00:17mupuf: that would be surprising
00:18mupuf: why would they buy an expensive INA3221 instead of an INA229 then?
00:18mupuf: or 219*
00:18mupuf: this makes no sense
00:18mupuf: and secondly, this is a Titan, the flagship
00:18karolherbst: I also have a ina3221
00:18karolherbst: and only one channel
00:19mupuf: ack, but I still find it very suspicious
00:19karolherbst: maybe there are more inas
00:19karolherbst: but your tool doesn't find any at all anyway :/
00:19mupuf:would suggest checking nouveau's code again
00:19mupuf: right, what does my tool say wghen on the blob?
00:20karolherbst: defbus 0 mhh
00:21mupuf:is more inclined for us misparsing the sense table than nvidia not monitoring all the power inputs
00:21karolherbst: I have an idea
00:21karolherbst: I think our rail -> extdev mapping kind of works
00:21karolherbst: because now there is just one rail in the vbios
00:21karolherbst: and the power reading didn't change for nvidia
00:21karolherbst: maybe there is a flag on the extdev table
00:22mupuf: I would suggest spying on the bus
00:22mupuf: and checking how many lanes the blob polls
00:23mupuf: how do you disable channels?
00:23karolherbst: ohh right, I could try to read out the config of the ina3221 :)
00:24mupuf: you need nvaspyi2c
00:24mupuf: it will dump all the reads and writes
00:25karolherbst: 7807 is the device config
00:26karolherbst: and we would set 4e07...
00:28karolherbst: indeed, all channels enabled...
00:31karolherbst: 81:00 =R=> 7807 that's the sensors then I assume
00:31karolherbst: readings on all three channels
00:31mupuf: and all three show values?
00:32karolherbst: this is odd though, because there is only one rail in the vbios now
00:32karolherbst: and if I remove the last one, the driver won't load
00:32mgoodwin: froze after watching vdpau with kodi
00:32mupuf: how did you comment the other rails?
00:32mupuf: did you just change the number of entries?
00:32karolherbst: mupuf: filled the entries with 0
00:33karolherbst: what happens when I remove the first and the second :D
00:33mgoodwin: so.. apparently the module no longer looks for PGRAPH fw in the same spot that the script generates...
00:33mupuf: karolherbst: it is likely that nvidia would just use the same value for shunt for all channels if unset
00:34karolherbst: mupuf: mhhh
00:34karolherbst: mupuf: they don't do it on mine
00:34karolherbst: I assume there is a flag somewhere for this
00:34mgoodwin: where do I get nvidia/gk106/fecs_inst.bin now
00:35karolherbst: mupuf: when I remove the 0th and 1st rail, it fails to load
00:36karolherbst: mupuf: it also fails if just the 0th entry is missing
00:37mupuf: karolherbst: instead of changing this, how about you see if you can reproduce the values the blob is showing
00:37mupuf: and for this, I would suggest using pwr_read.c
00:38mupuf: since it will already decode the i2c transactions into per-lane power
00:38mgoodwin: Where is this firmware that nvidia now provides
00:38karolherbst: mupuf: 20W in nvidia-smi now :D
00:38karolherbst: mupuf: I just changed the unknowns bytes inside the rail entry
00:41mgoodwin: why is nouveau looking for gk106 if it doesn't exist
00:41mgoodwin: I have linux-firmware as recent as 3/21
00:41karolherbst: back at 57W now :)
00:41karolherbst: mupuf: well multiple bytes of course
00:43karolherbst: mupuf: 01 00 00 00 00 05 00 05 00 05 00 07 78 (rail, I left the last bytes, because there are just 0)
00:43karolherbst: 00th: some kind of mode, 0x1 seems to say that we have to use this rail for power reaiding
00:44karolherbst: 01st: extdev_id
00:44karolherbst: 05th: mohm
00:44karolherbst: 06th: rail
00:45karolherbst: which is the same as on mine by the way
00:45karolherbst: the next "05 00" ... wait a second
00:45karolherbst: why is there a "05 00" like three times
00:45karolherbst: and on mine it is "05 00 0a 40 0a 40"?
00:46karolherbst: and the "07 78" is "07 4e" on mine
00:48karolherbst: 5W now
00:49karolherbst: those things somewhat change how the power consumption is calculated
00:49mupuf: Ah ah, why make it simple when it can be made hard
00:50karolherbst: I am happy
00:50karolherbst: 62W now
00:50karolherbst: I think you also get the idea :D
00:51karolherbst: 70W :)
00:57karolherbst: mupuf: well this table contains more fun as it seems
00:58mupuf: well, 4am, time for me to sleep...
00:59mupuf: I guess I will send my new mesa-demo gbminfo later
01:00mupuf: it allows asking mesa for its version
01:00mupuf: and extensions
01:00mupuf: for both core and compat profiles
01:00mupuf: I will need to add support to gles too
01:04karolherbst: yeah I will give up for today too
01:04karolherbst: that is too much fund for me today
01:04karolherbst: and I should check what nvidia does on my gpu too
01:05mupuf:will not arrive early at work, for sure!
01:07mgoodwin: nouveau used to confirm loading pgraph fw iirc
01:07mgoodwin: does it not do that anymore
01:07mgoodwin: I can see that it stopped complaining about it missing but I usually prefer affirmatives
01:11karolherbst: mgoodwin: right
01:11karolherbst: mgoodwin: we should add a message about that
01:11karolherbst: mgoodwin: how is it going with nvidia firmware?
01:11mgoodwin: when is gk106 going to land in linux-firmware?
01:12mgoodwin: I have it as recent as 3/21 but it's not there
01:12mgoodwin: Then why on earth is the driver looking for it there
01:12imirkin_: because skeggsb decided that it was never going to be useful outside of GM20x
01:12karolherbst: and distribution problem
01:12mgoodwin: With the only information out there about it being that this is now the location where it looks for it because nvidia will officially provide firmware now
01:13karolherbst: mgoodwin: for GM20x
01:13mgoodwin: yeah but it looks for it in /lib/modules/nvidia/gk106/*
01:13mgoodwin: and they're the wrong names to boot
01:14mgoodwin: so I would have to argue it's not just a gm20x change
01:14karolherbst: mgoodwin: right, the firmware paths were changed
01:14karolherbst: mgoodwin: but you still use the one you extracted
01:15mgoodwin: Yes and the _only_ information on how to make that work is here: https://bugs.freedesktop.org/show_bug.cgi?id=93629#c9
01:15mgoodwin: by imirkin_
01:15karolherbst: imirkin_: mind putting that in the wiki? :D
01:15karolherbst: mgoodwin: well anyway
01:16karolherbst: mgoodwin: we can't distribute those firmware files
01:16karolherbst: and we really don't want to either
01:16mgoodwin: I know that
01:16karolherbst: mgoodwin: we should fix our firmware instead
01:16mgoodwin: But the message reads that nvidia will be supplying gk106 firmware in linux-firmware
01:16mgoodwin: Should be clearer that isn't the case
01:16mgoodwin: karolherbst: of course
01:16karolherbst: ohh maybe they do in the future, but I really don't think so
01:16karolherbst: but only gm20x really requires them though
01:17mgoodwin: which are the safest kwin options btw
01:17mgoodwin: since you said you used plasma
01:17karolherbst: I use intel
01:18karolherbst: but on dri3 you would use automatic
01:18karolherbst: on dri2 I would use "full scene repaints"
01:18mgoodwin: Why's that?
01:18karolherbst: and EGL is usually less stable than GLX
01:18karolherbst: mgoodwin: because DRI3 has awesomely improvement vsync stuff
01:19karolherbst: and just use the same stuff for all options in the end
01:19mgoodwin: imirkin_ scolded me when I turned DRI3 on a few months ago
01:19mgoodwin: Has that changed
01:19karolherbst: because the compositor doesn't need to do much anyway
01:19karolherbst: on nouveau the situation is different
01:19imirkin_: mgoodwin: doubtful
01:19imirkin_: mgoodwin: but i probably suggested trying turning that off, if you were having issues
01:20mgoodwin: I'm ribbing :D but yeah you suggest that it itself was causing problem so I'm just wondering if it's safe to use that now
01:20imirkin_: there's no proper sync model iirc, so some applications can run into trouble
01:21imirkin_: but it should be fairly rare
01:21imirkin_: you'd have to be a GIANT jerk, and use X drawing operations an expect them to show up in imported pixmaps in GL programs
01:21mgoodwin: My options are OpenGL 2/3.1, GLX/EGL, and various vsync methods
01:22mgoodwin: I'm pretty much just asking which are expected to be stable with nouveau
01:22mgoodwin: so I can try and rule out those settings and can stop playing roulette
01:24imirkin_: i use windowmaker, no compositor. it's pretty stable.
01:26karolherbst: mgoodwin: well I think "full scene repaints" should work
01:26karolherbst: mgoodwin: ohhh wait
01:26karolherbst: mgoodwin: do you use plasma 5.6?
01:26karolherbst: they implemented the thing where an application can disabled the compositor
01:27karolherbst: mgoodwin: do you notice it sometimes, that for fullscreen applications the window effects are gone?
01:27mgoodwin: I have that option unchecked
01:27mgoodwin: but no not really
01:28karolherbst: no, that option doens't do anything :D
01:28karolherbst: but if you didn't notice, then it may be alright
01:28mgoodwin: doesn't do anything?
01:28karolherbst: the "suspend compositor..." thing you mean?
01:28mgoodwin: for fullscreen windows
01:29mgoodwin: exactly what you described
01:29karolherbst: yeah, it doesn't do anything
01:29karolherbst: no I meant something else
01:29mgoodwin: DRI3 is really bugging out with fonts btw
01:29mgoodwin: Artifacts when I type
01:29imirkin_: are you using modesetting?
01:29imirkin_: or are you using nouveau?
01:29karolherbst: window management -> window rules -> New -> appearance & fixes -> Block compositing
01:30karolherbst: mgoodwin: set to force->no
01:31mgoodwin: imirkin_: both I thought
01:31karolherbst: mgoodwin: he means the X driver
01:32mgoodwin: I'm only away of nouveau and that's what's listed in Xorg.0.log
01:33imirkin_: hm ok
01:37mgoodwin: No artifacts if I switch to XRender
01:38mgoodwin: EGL/GLX, OpenGL 2,3 doesn't make a difference
01:39mgoodwin: So improved, you can't even use it!
01:40imirkin_: solution: use xrender
01:40karolherbst: with Xrender you don't get tearing prevention though
01:40imirkin_: yeah, but you get working fonts
01:40imirkin_: seems like a win :)
01:40mgoodwin: using xrender is not a solution
01:41karolherbst: tearing is really bad .D
01:41karolherbst: I rather have ugly fonts than tearing
01:41mgoodwin: Why on earth would I use software rendering if I have a discrete GPU :/
01:41imirkin_: xrender is not software rendering
01:41imirkin_: majority of xrender is accelerated
01:42mgoodwin: I was always told that was software rendering only but Im more than happy to be wrong
01:42imirkin_: if you do super-weird shit, yeah, it'll hit the cpu paths
01:42mgoodwin: And like he said, the tearing is horrible
01:43imirkin_: but the majority of operations is accelerated
01:43imirkin_: my solution to this problem is to not use a compositor at all
01:43imirkin_: i never needed one before, sure don't need one now...
01:44mgoodwin: "My solution to modern computing is to not do things that modern computers do"
01:44mgoodwin: I mean sure I've made lots of sacrifices, but I would at least like things to look nice
01:44mgoodwin: and be able to watch videos without tearing
01:44karolherbst: usually you get the best experience by software trying not to be smart :)
01:44imirkin_: i never have tearing when watching video
01:44karolherbst: imirkin_: well you don't move windows around, do you?
01:45imirkin_: while watching videos? rarely
01:45karolherbst: I mean usually
01:45karolherbst: video tearing is only a minority of where tearing happens actually
01:45imirkin_: sure i do
01:47mgoodwin: Ok the tearing that bothers me with extreme prejudice is scrolling a web page in firefox
01:48mgoodwin: I'll move mountains to get rid of that when I encounter it
01:53karolherbst: let me check
01:54karolherbst: mgoodwin: well with intel I also have no tearing even when I set tearing prevention to none :D
01:54karolherbst: but I am sure it is the dri3 part
01:55mgoodwin: DRI3 isn't cuasing tearing with nouveau
01:56mgoodwin: It's causing artifacts for sure, but not tearing when using OpenGL
01:56mgoodwin:goes back to DRI2
01:56imirkin_: mgoodwin: what version of X are you using btw?
01:58mgoodwin: X.Org X Server 1.18.3
01:58mgoodwin: Release Date: 2016-04-04
02:03imirkin_: so much for my theory of some old X bug that got fixed
02:03imirkin_: do you have an up-to-date mesa?
02:04mgoodwin: I'm on F23 updates-testing
02:04mgoodwin: but i'll get you the version
02:05imirkin_: ok, that's moderately up-to-date, but there's a 11.1.2 that's out (and a 11.2.1)
02:05imirkin_: i forget when i fixed various stuff...
02:05imirkin_: but the likelihood of my fixes affecting you are low
02:06mgoodwin: No artifacts with DRI2
02:06mgoodwin: I will say that must be new since November though, since the last time you told me to turn it off
02:06mgoodwin: I would have noticed that
02:07karolherbst: mgoodwin: but it seems to be stable wiht nvidia firmware?
02:07mgoodwin: my hardware?
02:07mgoodwin: Oh, thus far no crash use in 2D space
02:08mgoodwin: VDPAU is the real killer
02:08karolherbst: that is something I might be able to check
02:08karolherbst: though I really dislike using dri2 offloading
02:08imirkin_: no dri3 + vdpau, unfortunately
02:09karolherbst: I know
02:10mgoodwin: I started talking about pgraph firmware when you guys were messing around with rails and wattage because the GPU locked up after I was watching a video on kodi
02:10mgoodwin: Which is when I gave up on raw nouveau (I give it a shot every 6 mo or so)
02:11mgoodwin: Next progressive step is nouveau with pgraph
02:11mgoodwin: and if I can't get that stable, back to the dark side :(
02:11imirkin_: mgoodwin: just switch to an amd gpu, all will be better
02:11mgoodwin: seems like a terse comment
02:11mgoodwin: from a nouveau developer
02:12imirkin_: it's one i stand behind
02:12mgoodwin: So then you're not being sarcastic?
02:12imirkin_: amd is putting resources towards open-source support
02:12imirkin_: no - fully serious
02:13karolherbst: well on laptops it isn't that bad actually
02:13karolherbst: as long as you offload
02:13imirkin_: nouveau is supported by a small handful of volunteers and a RH full-time employee
02:13imirkin_: nvidia blob driver is supported by hundreds of full-time engineers with access to a whole lot more docs
02:14mgoodwin: I wasn't as committed to floss when I built my rig, but now that I am I will probably look toward who has the better floss drivers
02:15karolherbst: one might argue that radeon can be used on with libre-linux at all :D
02:15mgoodwin: Even my laptop is intel and it won't resume from sleep without screen corruption
02:15mgoodwin: OS can be spit and polished, greatest thing ever, but if your drivers suck it's all for naught
02:16mgoodwin: (i915 Haswell if you're wondering)
02:16karolherbst: mgoodwin: well I have a haswell too
02:16karolherbst: and no screen corruptions
02:17mgoodwin: Sure and plenty of people use gk106 with nouveau without issue im sure
02:17mgoodwin: I just have crap luck I guess
02:17karolherbst: I have a gk106 :D
02:18karolherbst: but seriously, can radeon be used with linux-libre?
02:19imirkin_: of course, neither can nouveau if you want to load nvidia firmware
02:19imirkin_: which is required for GM20x+
02:19mgoodwin: which is the one with the least closed source compromises
02:19karolherbst: but for radeon that means, none will work, right?
02:19mgoodwin: Because obviously the sad state of things is that modern computing is impossible without blobs
02:20imirkin_: karolherbst: mmmm... i think r300+ won't? not 100% sure when CP firmware became a thing for them
02:20mgoodwin: Hardware is locked, and that's just the way it is
02:20karolherbst: yeah, because somebody today wants to use those old pre r300 cards
02:20mgoodwin: Otherwise you're running a 10 year old thinkpad or a leemote yeelong
02:20karolherbst: mgoodwin: well before gm20x we don't use blobs
02:20karolherbst: right, x86
02:20karolherbst: there is a new power achitecture coming :D
02:21imirkin_: power isn't exactly new :p
02:21karolherbst: I meant power8
02:21imirkin_: that's been out for a while too afaik
02:21karolherbst: ohh :O
02:21imirkin_: but yeah, definitely newer than, say, power4
02:22mgoodwin: argue what you must but the fact is if you want to use linux and be as libre as possible your hardware considerations dwindle considerably
02:22mgoodwin: And then there's the conundrum where intel is supposedly the most open graphics / best supported yet in order to have that you need their CPU which in turn requires a fuckton of microcode
02:22imirkin_: "as libre as possible" as defined by RMS?
02:23imirkin_: tbh, i dunno that his definition is worth pursuing
02:23imirkin_: it's internally inconsistent
02:23mgoodwin: I don't want to argue the specifics of free software but I don't think he's a person capable of being defined as inconsistent
02:24imirkin_: i'm not defining him as inconsistent... but what's in linux-libre is internally inconsistent
02:24karolherbst: ... stupid network
02:24imirkin_: their basic argument is that code loaded off a ROM is ok, but that same code loaded off the HD is not ok
02:24imirkin_: seems bogus to me
02:25karolherbst: it is
02:25karolherbst: it kind of makes a difference though
02:25imirkin_: there's an argument to be made that neither is ok
02:25imirkin_: and that's a consistent argument
02:25karolherbst: if it can only be loaded from the device ROM, it can't be replaced anyway
02:25imirkin_: who cares.
02:25karolherbst: or maybe that is the thought
02:26imirkin_: it's an irrelevant detail
02:26karolherbst: imirkin_: well, they seem to care
02:26mgoodwin: I would agree, which is why I use Fedora and not Trisquel
02:26karolherbst: if you can provide the file the device loads, it should be free software
02:26imirkin_: what if you can replace the ROM (e.g. one of those plugin thingies)
02:26mgoodwin: I am by no means a purist, I have RPMFusion installed and love my libav
02:26imirkin_: does that make a difference?
02:26karolherbst: imirkin_: well yeah, then you should install a free firmware too :D
02:26mgoodwin: My rule is : If a floss alternative exists, and you can use it, use it.
02:26mgoodwin: Call that whatever philosophy you like
02:27karolherbst: but I think this should be done by libreboot or something
02:27imirkin_: mgoodwin: that's the "floss sucks" philosophy, since you're thinking of floss as the alternative
02:27karolherbst: ohh right
02:27karolherbst: power9 is coming
02:27imirkin_: instead of thinking of proprietary as the alternative
02:27karolherbst: awesome stuff
02:28mgoodwin: No I think you misunderstood me
02:28imirkin_: they're functionally equivalent
02:28mgoodwin: I don't use proprietary unless I am forced to
02:28imirkin_: just different ways of looking at it
02:28mgoodwin: Such as with the case with nouveau
02:29karolherbst: I am currently wondering how easy it would be to emulate x86 on power8 :D
02:29imirkin_: as easy as emulating power8 on x86?
02:29karolherbst: well one way is most likely harder
02:29imirkin_: qemu jit goodness, hopefully
02:30karolherbst: am I the only one or are all web search engines shit these days?
02:30karolherbst: "amd64 on power8 emulation speed", first results: android stuff
02:30imirkin_: you should have tried excite ;)
02:31imirkin_: i dunno. my first result is about dosbox perf
02:31imirkin_: then about ibm's power8 release
02:33karolherbst: mhh doesn't matter in the end, those power8 cpus are expensive
02:33mgoodwin: actually it would seem I don't have any rpmfusion-nonfree
02:33mgoodwin: anymore at least
02:33mgoodwin: So what we're left with is what's included in the linux kernel then
02:34karolherbst: and then power8 still sucks vs haswel
02:34mgoodwin: and some nvidia blobs
02:35mgoodwin: I've never tried running my laptop on linux-libre though ....
02:35mgoodwin: I want to try just to see how haswell falls on its face
02:35karolherbst: well haswell should be good
02:36mgoodwin: I suppose I should get this vdpau test going
02:36karolherbst: usually wifi doesn't work
02:36karolherbst: and sometimes also ethernet
02:37mgoodwin: Ah shit yeah
02:37mgoodwin: I just replaced the Atheros card for an Intel 802.11ac
02:41mgoodwin: yep, vdpau killed it
02:45karolherbst: solution: don't use vdpau then :D
02:48mgoodwin: I came to the same conclusion last time
02:48mgoodwin: I do not however remember what pushed me over the edge
02:49mgoodwin: I think I couldn't even get it stable with PGRAPH firmware
13:46mgoodwin: http://paste.fedoraproject.org/360205/61764724 woke up to this and a screen that wouldn't turn on :/
14:53karolherbst: I am at my mothers house and I can't connect to freenode...
14:56karolherbst_: ahh now
14:58karolherbst1: and now my usual nickname is unavailable
15:26mezo: is there a reason why i cant adjust brightness ingame on nouveau?
15:26karolherbst: mezo: in every game or only in special ones?
15:26karolherbst: mezo: there are some games which have a very ugly way to go fullscreen
15:26karolherbst: mezo: like they block every command to the window manager and everything
15:26mezo: cs:go and 1.6 for example
15:29mezo: im btw. the whole day on max clock. no freeze so far, so i assume it only happen while reclocking on load
15:40karolherbst: mezo: with my branch?
15:40karolherbst: mezo: or stock nouveau?
15:40mezo: with ur branch
15:40karolherbst: k and with stock nouveau it hangs pretty fast I assume?
15:40mezo: not rly
15:40mezo: same for me
15:41karolherbst: well under load it is getting interessting
15:42karolherbst: but maybe with your vbios it doesn't matter
15:42mezo: what u mean by "under load it is getting interessting"?
15:43karolherbst: mezo: well nouveau should be stable under full load on highest clocks
15:43karolherbst: otherwise reclocking is pointless
15:44mezo: for this i need a benchmark, right?
15:46karolherbst: or run a game or something
15:46karolherbst: it just shouldn't crash
15:46mezo: it doesnt. i played cs go and cs 1.6 today
15:47mezo: the only carashes i noticed, is reclocking while on load
15:47mezo: otherwise it seems stable
15:48karolherbst: yeah there are display things missing on reclocking
15:48karolherbst: but I think I said this already
15:49karolherbst: :D heck
15:49karolherbst: "Value range propagation now assumes that the this pointer of C++ member functions is non-null. This eliminates common null pointer checks but also breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). As a temporary work-around -fno-delete-null-pointer-checks can be used. Wrong code can be identified by using -fsanitize=undefined."
16:11Tom^: karolherbst: -Wnull-dereference
16:11Tom^: gcc6 <3
16:15Tom^: karolherbst: i look forward to it "warns if the compiler detects paths that trigger erroneous or undefined behavior due to dereferencing a null pointer. This option is only active when -fdelete-null-pointer-checks is active, which is enabled by optimizations in most targets. The precision of the warnings depends on the optimization options used."
16:54mezo: is there a way to force a game 4:3 instead of stretching itself to 16:9
17:15vedranm: Tom^: nice feature indeed
17:55Tom^: speaking of which, seems gcc 6.1 is out.
18:07mupuf: and so is tomb raider, let's hope they indeed have a CLI benchmark mode!
18:07mupuf: we could use that for testing nouveau's perf
18:56mezo: mupuf: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/868127-tomb-raider-is-now-out-on-steam-for-linux-steamos
18:56mezo: doesnt seem so :|
18:59mupuf: too bad
19:17lynx`: on boot after the system hands "hands off" to nouveau, my dual head system mirrors the console on both displays. is there a way to set it so console output is shown on only one display? I've seen this behaviour on two different video cards (G98 and GM206) using kernel 4.4.8. Otherwise, dual head support in X11, at least, seems to work perfectly.
19:19imirkin_: lynx`: i don't think so
19:20imirkin_: lynx`: fbcon is set up to do that, i believe, not sure if there's a way to control it
19:21lynx`: thanks for your reply, imirkin_. yeah, I've not so far done better than turning off output to both displays. ;-)
19:22imirkin_: it's not really nouveau's fault :)
19:23Tom^: con2fb seems to support various things
19:23Tom^: even making each monitor show different tty's , but i havent tried it myself.
19:24lynx`: imirkin_, I'm certainly not attributing blame. But I would imagine this has been seen before. But I couldn't find a bug ticket or even a list post with linked to a solution.
19:24Tom^: it also seems to be rather old, but *shrug* :p
19:24lynx`: Tom^, I'll take a look. Thanks!
19:25imirkin_: lynx`: i don't think there's a solution... it's just the way it works
19:25imirkin_: and by design
19:26lynx`: so, basically, if I dislike it (and I only do because one display is portrait orientation), turn off the monitor or just boot up init 4 and ignore the mirroring. ;-)
19:27lynx`: I was worried that maybe the fact that one or both displays (depending on the video card I was using) was connected to the card's DP interface was the problem.
19:27imirkin_: or just don't look at the monitor
19:27lynx`: but it sounds like that it isn't the case.
19:27imirkin_: i have 2 rotated monitors
19:27imirkin_: and i use the following setting: fbcon=rotate:1
19:27imirkin_: which means that one monitor is "correct" and one monitor is upside down
19:27imirkin_: just don't look at the upside down one ;)
19:29lynx`: I'll admit I haven't tried the proprietary drivers (out of principle), but it sounds like that isn't the fix. so I appreciate you saving me the run-around with that.
20:27Wolf480pl: Hello. Are there any new experimental features for gk104 that I could test for you?
20:48lynx`: imirkin_, Tom^, thanks again!
23:23karolherbst: yay, testing Tomb Raider on nouveau in 30 minutes :)
23:30mupuf: karolherbst: you bought it?
23:30karolherbst: I already owned it
23:31mupuf: oh, cool!
23:31mupuf: 20e now
23:31karolherbst: it's a solid game though
23:31karolherbst: not much of a challange though
23:31karolherbst: I will just dump the shaders and see how performance is
23:32karolherbst: at least with nvidia it seems to be okay
23:37karolherbst: well still downloading
23:38karolherbst: it is like 11.1GB download :D
23:40karolherbst: well I hope I will find more time tomorrow to RE those power sensors on the titan
23:40karolherbst: it really helps that nvidia-smi gives us the info
23:41karolherbst: but it seems like something really strange is going on there :/
23:46karolherbst: mupuf: this is weird. on my ina, nvidia only enables channel 1, but it still reads out the other channels
23:47karolherbst: bus voltage has a normal value
23:47karolherbst: shunt voltage is 0
23:49karolherbst: this looks so odd
23:50karolherbst: 81:02 =R=> 0338 (status = 0, polls = 0250)
23:50karolherbst: 81:02 =R=> 49a8 (status = 0, polls = 0256)
23:50karolherbst: mupuf: could it be there is some race condition in the code and it should have beed 81:01 and 81:02?
23:52karolherbst: or the reading isn't fast enough