03:45gnurou: RSpliet: thanks - I haven't received the notification strangely. Will try the patch today.
04:30gnurou: RSpliet: things seem to be very stable with this patch! let me stress-test some more to be sure though...
08:13RSpliet: gnurou: thanks. I'll see if other bugzilla people test it and otherwise submit it one of these days
08:14gnurou: RSpliet: yeah to me it works really well, and I was able to reproduce the issue easily before
08:15RSpliet: gnurou: I had the feeling I could reproduce quite easily on most of my keplers, and have a similar experience
08:16RSpliet: thanks for testing!
08:16gnurou: thanks for fixing this! ;)
08:33karolherbst: RSpliet: \o/
08:34karolherbst: RSpliet: do your patch works indeed
08:34karolherbst: gnurou: you tested without reclocking?
08:35gnurou: karolherbst: yes, just on top of skeggsb's master branch
08:35gnurou: I was able to repro that way before
08:35karolherbst: gnurou: k. If you are up to, you could then test my reclocking patches and see how that goes for you
08:35karolherbst: nouveau master should also run... kind of stable
08:36karolherbst: more unstable than that, but it depends on the vbios
08:37karolherbst: RSpliet: I will push your patch on my branch
08:39karolherbst: RSpliet: line 41 and 58 have trailing whitespaces ;)
08:42karolherbst: gnurou: stable_reclocking_kepler_v5 branch. RSpliets patch is also there
08:42karolherbst: just if you got some time :p
08:42RSpliet: karolherbst: thanks. Yes, I'll go through it before submission - but trailing whitespaces are a pain for assembly/firmwares :-P
08:42gnurou: karolherbst: can you remind me your repo's address?
08:42karolherbst: RSpliet: well, it's in the fuc code
08:43karolherbst: gnurou: https://github.com/karolherbst/nouveau.git
08:43RSpliet: it's an artefact of many editors doing auto-identation, but not cleaning up tabs when saving the file
08:43karolherbst: awesome that git am works if you just change the paths :D
08:44karolherbst: RSpliet: anyway, nouveau oot version: https://github.com/karolherbst/nouveau/commit/1738e6ca3c454e5fa4f1f6962351a0b78415bd4d
08:44karolherbst: RSpliet: I reassmebled and found no changes (just to confirm this)
08:45RSpliet: shouldn't those .h files be generated upon compilation in the nouveau repo rather than be checked in to the repo?
08:45karolherbst: that was removed
08:45karolherbst: there was a check for envydis earlier
08:45karolherbst: but skeggsb removed it
08:46karolherbst: I think if you compile in the top dir they get assembled?
08:46RSpliet: maybe that's it
08:46karolherbst: but not if you compile the kernel module
08:46karolherbst: anyway, I have a simple script to take care of it
08:46karolherbst: RSpliet: https://gist.github.com/karolherbst/808989054091e5bfb1915de0de214c9e
08:46karolherbst: works from everywhere
08:46karolherbst: and just needs the path to the fuc directory
09:28gnurou: karolherbst: do you want me to run at a particular frequency for the test?
09:30karolherbst: gnurou: well you can test all
09:30karolherbst: gnurou: but if you want, you can also run nvidia and run bin/nv_cmp_volt
09:31karolherbst: this tool just compares nvidia set voltage with what nouveau calculates
09:32gnurou: karolherbst: so far your branch seems stable with Roy's patch
09:32karolherbst: gnurou: if you want to kill your GPU, run gputest_furmark
09:33gnurou: note that I am just testing for stability
09:33karolherbst: my GPU reached like 102°C with that :/
09:33gnurou: I don't want to kill my GPU, thanks :)
09:33karolherbst: well as long as it is stable it is good
09:33gnurou: I already had trouble getting it
09:33karolherbst: that's all I care about with that branch
09:34gnurou: yeah it would have already crashed without Roy's patch I thing
09:34mlankhorst: karolherbst: or just run max-texture-size
09:34mlankhorst: better way to kill
09:34karolherbst: mlankhorst: meh, boring :D
09:35mlankhorst: in parallel it definitely kills nouveau
09:36mupuf: mlankhorst: not killing in the same way, karol meant that it physically kills the GPU
09:36karolherbst: lol, seriously... set // $p0 mov 0xffffffff // not $p0 mov 0x0
09:36mlankhorst: ah :p
09:36mupuf: gnurou: don't worry, karol's GPU is integrated
09:37mupuf: and the thermal protect should work also
09:37karolherbst: just nouveau doesn't downclock yet I think
09:37karolherbst: but we should
09:38karolherbst: so many tables to RE :/
09:38karolherbst: mupuf: well I have an idea: I already know how to get the temperature where we should downclock
09:38karolherbst: mupuf: why just not downlock at this one to min
09:38karolherbst: it is safe and it shouldn't be too anyoing
09:38karolherbst: and a better implementation we can add later
09:39karolherbst: some GPUs want to be clocked down at 80°C, but well
09:39mupuf: no, let's work on the table for a week and get a good implementation
09:39karolherbst: this table is friggin messed up though
09:39karolherbst: there are like 3 temperatures in it
09:39karolherbst: and I have no clue what the other two do
09:48mupuf: karolherbst: well, how about the temperature for the FSRM limiter?
09:48mupuf: or it could be for the fan to go full speed too
09:49karolherbst: well the first one is related to the point where to downclock
09:49karolherbst: the second one is usually around 54°C
09:49karolherbst: the last one usually above 95°C
09:49karolherbst: but yeah, could be fan max boost
09:50karolherbst: maybe fan min/max ?
09:50karolherbst: well will look at it later then
10:04mupuf: yes, they look like fan_min/fan_max
10:05karolherbst: mupuf: okay, and then I guess this might also declare a function with temp => fan mapping or something fancy like that
10:06karolherbst: or maybe even temp => fan,downclock
10:13nd: Hello, I have a question about the GeForce 940MX: is there any support in mesa comming soon? any patches? couldn't find anything yet
10:21RSpliet: nd: is that GM108? should work fine with upstream nouveau
10:21RSpliet: not lightning fast fine, but functional fine
10:23nd: hmm ok thx. now i only have to get arch to build that... ;/
10:25pmoreau: I think Arch’s Mesa should work fine for GM108, but as RSpliet said, you will need upstream Nouveau (i.e. the kernel module).
10:26RSpliet: nd: for help with that you're probably better off asking your distribution's people
10:26nd: using rc7 atm, or you mean any other upstream?
10:27nd: ah thx
10:27pmoreau: More specifically, you need https://github.com/skeggsb/nouveau/commit/3da1f2a19e5e8dc8d68a4400d9cca01c64ecd59e
10:27nd: using this patch already, ok so only need to build mesa
10:27pmoreau: Note that this is an out-of-tree repo
10:29pmoreau: Hum, I would have thought that 11.2.2 would be enough to get the GM108 working.
10:29pmoreau: s/11.2.2/Mesa 11.2.2
10:33nd: well arch default is 11.2.1
10:35pmoreau: Well, should be the same with 11.2.1, since those aren’t feature releases. But since I’m on testing, I have 11.2.2 rather than 11.2.1. ;-)
10:38nd: well thx for the help ;D
10:41pmoreau: What do you get when using Mesa 11.2.1 with the GM108 patch?
11:13nd: well the kernel loads nouveau and does powersaving stuff. but xorg doesn't load any userland drivers for it.
11:26pmoreau: Oh, could you please paste your Xorg.log?
12:42nd: pmoreau: sec, didn't see u here ;p
12:43pmoreau: Sorry, I should have pinged you
12:43pmoreau: And while you are at it, the dmesg as well please
12:46nd: sure, just gimme some mins to get personal stuff out of that log
12:52nd: pmoreau: dmesg: https://paste.aachen.ccc.de/?2ad371a69bb822b4#BtvaQBl5WNUQl3Mg5BWNgwtJXGndlCPIiCRYis5IwqE=
12:54pmoreau: Thanks! Nothing strange in it indeed
12:55nd: pmoreau: xorg: https://paste.aachen.ccc.de/?fe0d23ac336e1958#juZd9S3oA1PxyrZygajKMYc4K0yw+2Fcm9T9VA6t3I0=
12:56nd: well the bad part is at the xorg part of nouveaz doesn't like my gpu ;p
12:56nd: as far as i see everything is fine from the kernel side
12:57pmoreau: I’m trying to remember whether it falls in the category "use modesetting rather than nouveau DDX" or not
12:59pmoreau: Since I don’t see that one being revert, you should use modesetting rather than Nouveau DDX
12:59pmoreau: So just remove xf86-video-nouveau, or equivalent
13:00nd: tried that, then it fails to load modsetting
13:00pmoreau: Eh :-/
13:00nd: guess its just too new
13:02pmoreau: IIRC some people managed to get it running with Nouveau, with the previously mentionned patch, but I can’t find back the bug report
13:04pmoreau: What happens if you disable runpm (using nouveau.runpm=0 on the command line)?
14:14RSpliet: pmoreau: I don't think there's an EXA implementation for any Maxwell
14:16mupuf: there is indeed none
14:16pmoreau: RSpliet: Yeah, that’s what the commit message was saying. But, I had forgotten about modesetting for Maxwell
14:16mupuf: let's hope that it magically works now :D
14:17RSpliet: also, the X.org log mentions an intel GPU... sure we're barking up the right tree?
14:17pmoreau: I haven’t seen the Xorg.log where using modesetting for Nouveau
14:18RSpliet: pmoreau: modesetting for nouveau is kind of pointless when the monitor is attached to the intel GPU ;-)
14:19pmoreau: RSpliet: :-p
14:20RSpliet: (or does modesetting take care of prime-stuff too? that bit I really don't know any more)
14:20mupuf: RSpliet: yes, it is supposed to
14:20mupuf: and it will receive the patches from nvidia to remove tearing, yeepee!
14:20pmoreau: They have finally been accepted?
14:21RSpliet: is it? could someone draw a diagram of how all the PRIME stuff ties together? It's getting too convoluted :-D
14:22pmoreau: nd: Could you paste the Xorg.log using modesetting for the NVIDIA card?
14:47Tom^: to mee it looks more like a race and intel gets loaded.
14:47Tom^: so remove xf86-video-intel and/or even blacklist its modules
14:48Tom^: also if its a laptop isnt that optimus tech, where the monitor is hardwired to the intel gpu and you can only do offscreen rendering and "pipe" it back?
14:51Cyp_: Would an "NVIDIA GeForce GTX 950M" (NV117) work on a desktop machine? According to https://nouveau.freedesktop.org/wiki/FeatureMatrix/ , 3D would work, but 2D is WIP?
14:51Tom^: how do you get a laptop gpu in a desktop?
14:52Cyp_: I mean, a desktop laptop, not a server laptop (not sure what the right word is).
14:52Tom^: the same goes to you, isnt these laptops using optimus where the monitor is hardwired to the intel gpu and you rather need bumblebee or similiar software to render things offscreen and pipe it back?
14:53Tom^: or is it finally sort of supported, quite a while i fiddled with it
14:53Tom^: *since i
14:54Tom^: holy moly, according to archwiki it is. hm ignore me then :P
14:57Cyp_: Oh, if the cpu has Intel graphics in it, then does that mean that it would still work, even if not getting the NVIDIA part working?
14:58Tom^: well you could always only run on the intel gpu sure
15:10Cyp_: Ok, that's better than nothing. Would it be possible to get the NV110 part working too (not sure whether you answered this already).
15:13Tom^: that question il leave to the better informed guys.
15:15Cyp_: Ok, thanks. (And sorry if any of my questions didn't make sense.)
15:19imirkin: Cyp_: the 2D bit being WIP is the ddx support (in xf86-video-nouveau)
15:22Cyp_: Is ddx useful if running a regular KDE desktop (think it uses 3D)?
15:23imirkin: Cyp_: well, it's certainly not useful in your situation, since X stuff is being driven by the intel gpu
15:23Cyp_: Ok, thanks.
15:23imirkin: (unless i misunderstood your configuration... i haven't been paying close attention)
15:24imirkin: RSpliet: pmoreau: fyi i started an impl for maxwell exa... but... i'm lazy and haven't finished it (and also i don't have the hw)
15:24imirkin: it's like ... 90-95% complete.
15:25RSpliet: imirkin: that's great news
15:25imirkin: [and been that way for over a year]
15:25imirkin: top commit
15:26imirkin: basically it's missing a blit impl since earlier chips could use inline data, while maxwell dropped support for that, so i gotta allocate a vbo, configure it, etc
15:26imirkin: all for 4 stinkin' vertices
15:27RSpliet: heh, sounds like a lot of boilerplate but no complexity?
15:28RSpliet: I don't think I can help you test unfortunately, don't have a Maxwell device (although I do expect to get a 940M in a week and a bit)
15:29imirkin: right... well... there are a few additional factors
15:29imirkin: like ben is behind the "death to ddx's" banner
15:29imirkin: and i don't have a maxwell nor do i particularly have time to deal with this stuff anymore
15:29RSpliet: fair enough
15:30RSpliet: I currently have bigger itches to scratch as well, makes sense
15:30imirkin: my original stance was "i don't care about maxwell until GM20x is usable with nouveau"
15:30imirkin: so i have to come up with fresh excuses :)
15:31imirkin: anyways... my guess is that it needs just a few hours work from a competent individual with hardware in-hand
15:32RSpliet:stares at competent individuals
15:33mupuf: ah ah
15:34mupuf: well, not that I have the time, but reator will soon have a maxwell in all the time
15:34RSpliet: imirkin: is "Nullified Bus Destabilisation" a fresh new excuse for you?
15:35imirkin: not to say you're incompetent mupuf, but i suspect it'd take you more than a couple of hours. i meant someone who's hacked on the 3d driver a bunch already.
15:35RSpliet: mupuf: is there any nouveau dev left with actual time? :-)
15:35imirkin: hakzsam's been cranking away at compute + images
15:37RSpliet: imirkin: could have made a nice Xorg EVoC project perhaps...
15:37hakzsam: images are mostly done :)
15:37mupuf: imirkin: well, I am incompetent on this. I basically have no knowledge under libdrm
15:37mupuf: aside from gl
15:37mupuf: which ... does not apply
15:38mupuf: well, we grew old and got jobs :D
15:39mupuf: but yeah, it will happen at some point
15:39mupuf: at least, I freed up 6h/week now, I had my finnish exam yesterday
15:40mupuf: the second class will be over after May, which will give me about 3 more hours/week
15:40mupuf: so... let's see what I do with the aditional time
15:41mupuf: but it will be either work with karolherbst on PM or QA stuff
15:43nd: pmoreau: its a laptop, all displays are wired to the intel gpu. can create the xorg log with modesetting later
15:50Tom^: karolherbst: version 0.01½ https://gist.github.com/anonymous/a1c815969147197280535e472bbdfe46 no dangling pointers, optional short opts, and fixed --help text a bit.
15:50Tom^: karolherbst: =D
16:02nd: pmoreau: here you go: https://paste.aachen.ccc.de/?2856426511fcdd7e#+Ug8aX6mql8NReA8qdTXte4rsmy4vIYB3tgCbmfbN7U=
16:03nd: but i don't see how modesetting will help me since there is no display attached to the gpu
16:23mupuf: Tom^: as much as I don't like scripts, this example could have been written in bash or python :)
16:23Tom^: mupuf: as imirkin said too, the reason for all of this is i dont know bash nor python.
16:23mupuf: ack :)
16:23Tom^: but! atleast i can suid my binary :P
16:24mupuf: you can ask sudo to give you the sudo rights for this command
16:24mupuf: so, it would not be a problem
16:24mupuf: but hey, have fun!
16:24Tom^: also sudo is a bit annoying when keybinding it
16:25mupuf: you can say that one command does not need a passphrase
16:25mupuf: or password
16:25Tom^: mmh i know
17:15Tom^: is there a list somewhere explaining what exactly all the gallium_hud options are?
17:20hakzsam: Tom^, GALLIUM_HUD="help"
17:20Tom^: thats more of which exists
17:21Tom^: "gs-primitives" doesnt tell an untrained eye like me much :p
17:21imirkin_: Tom^: # of primitives emitted by GS
17:21imirkin_: Tom^: got a better name for it?
17:23nd: pmoreau: if you have any idea how to get that running or where to look, id love to hear it, im out of ideas
17:31Tom^: imirkin_: well no, the names are probably both fine and logical. just a tiny description of sorts what it is and does for the various names
17:31Tom^: but i guess il have to resort to commit messages or the code for that
17:40mupuf: hakzsam: are you on reator?
17:41imirkin_: Tom^: feel free to ask
17:52hakzsam: mupuf, yesh
17:52hakzsam: I was not, but now I use it :)
18:31pmoreau: nd: I just came back (and back to Linux where I have my IRC client), I’ll have a look.
18:31pmoreau: imirkin_: Nice to hear about Maxwell EXA :-)
18:33pmoreau: nd: If you run `xrandr --listproviders`, what do you get?
18:37pmoreau: nd: You will most likely need to configure your laptop following https://nouveau.freedesktop.org/wiki/Optimus/ to use the NVIDIA card.
18:38nd: pmoreau: Providers: number : 1
18:38nd: Provider 0: id: 0x4b cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 8 associated providers: 0 name:Intel
18:39nd: yes i know about optimus, but i fail earlier already
18:39pmoreau: Hum :-/
19:33karolherbst: stupid laptop. Went out of suspend by itself
19:40karolherbst: ohh yeah
19:40karolherbst: my EC has a reg for the GPU temp
19:47karolherbst: mupuf: :O
19:48imirkin_: embedded controller
19:48karolherbst: mupuf: the gpu temperature read out through the EC is like 6.5 °C higher
19:48mupuf: imirkin_: spasiba
19:49mupuf: imirkin_: what would be the spelling with the latin alphabet btw?
19:49karolherbst: I think with a c
19:49mupuf: karolherbst: how do you know it is the EC temperature?
19:49imirkin_: mupuf: spasibo
19:49mupuf: imirkin_: thx
19:49karolherbst: ohhh no
19:49mupuf: karolherbst: sorry, meant the GPU
19:49imirkin_: although an o that's not emphasized is pronounced as "a"
19:50imirkin_: but outside of knowing the language, you have no real way of knowing if a particular syllable is emphasized or not
19:50mupuf: yeah, I always heard it as a o
19:50karolherbst: mupuf: well, it increases when the GPU temp increases and I got that from a project wich like disassemled windows dlls
19:50mupuf: but you never know, people in Saint Petersburg may have a weird accent
19:50imirkin_: mmmm... not really. they will use diff words for a few things, but that's about it
19:50karolherbst: anyway, it is pronounced with an a at the end I thnk
19:51karolherbst: but written with an o
19:51imirkin_: in belarus, they actually write a lot of such words with an "a"
19:51mupuf: karolherbst: so... obvious question, what happens when you fake the temperature?
19:51karolherbst: non accentuated o is pronounced a
19:51karolherbst: mupuf: :O good idea!
19:51imirkin_: karolherbst: isn't that what i said?
19:52karolherbst: I am a bit late today
19:52karolherbst: and slow
19:52karolherbst: mupuf: forced temp + 6
19:52mupuf: this makes no sense...
19:52karolherbst: just saying
19:53karolherbst: the EC needs like 5 seconds to turn down the fans
19:53karolherbst: and after I forced 1, the value was 96 until the fan spinned down
19:53karolherbst: then it was 7
19:54karolherbst: mupuf: maybe the real temp from the ec has to be subtraced with 6?
19:54karolherbst: mupuf: because when the GPU is off, the temp is set to 26°C
19:54karolherbst: for whatever reasons
19:54mupuf: well, the EC polls on the temperature every 5 s
19:54karolherbst: makes sense then
19:55mupuf: or every 10
19:55karolherbst: mupuf: should I check with nvidia?
19:55mupuf: why would it change anything?
19:55karolherbst: no idea
19:55karolherbst: nouveau sometimes has bugs
19:55mupuf: you know it is reading the reg on its own?
19:55mupuf: not through the PCIe port though, likely as an i2c device
19:56karolherbst: mupuf: okay, same with nvidia
19:56karolherbst: the EC value is temp + 6
19:56mupuf: 20400-20800 looks like an i2c device
19:56mupuf: an LM99, to be precise
19:56mupuf: so, the bios likely uses this
19:57mupuf: simple-enough, right?
19:57karolherbst: no clue
19:57mupuf: we wondered why nvidia would do that, but your case makes sense
19:57karolherbst: the project which REs the EC I have
19:57karolherbst: is an unity-indicator
19:57karolherbst: reading out the EC in userspace
19:57karolherbst: suid is set of course :p
19:58karolherbst: I mean, what could possible go wrong here :D
20:01karolherbst: here is a nice kernel module implementation though: https://bitbucket.org/lynthium/clevo-xsm-wmi