00:19 ectospasm: imirkin: about my DPMS issue... issuing the sleep 1 && xset dpms force off command does blank the screen, but rather than staying off, the monitors blink back on (and lightdm greeter/login screen shows)
00:19 imirkin: ectospasm: i.e. X crashes?
00:19 ectospasm: imirkin: no
00:19 ectospasm: Or at least, I don't think so
00:20 imirkin: perhaps you have some source of inputs being picked up by X that wakes it back up?
00:20 ectospasm: imirkin: no. Only difference for this problem I can make is loading the nvidia driver
00:21 ectospasm: light-locker shows the lightdm greeter if the monitors go off (which they do, but only momentarily)
00:22 ectospasm: With nvidia loaded, DPMS works as expected (but I have other, worse issues)
00:22 imirkin: so... does the kernel think that the monitors are asleep? why does it turn the back on?
00:22 imirkin: i told you to boot with drm.debug=0x1e
00:23 imirkin: that should indicate all the various actions taken
00:24 ectospasm: imirkin: I did boot with dm.debug=0x1e, and it didn't show much that I was interested in. No DPMS events, just that it was loaded.
00:24 ectospasm: drm.debug*
00:24 imirkin: drm.debug=0x1e should have dumped a TON of debug info
00:25 imirkin: are you sure you're using nouveau?
00:25 ectospasm: define "a TON"
00:25 ectospasm: imirkin: should be, I remove nvidia before I reboot with nouveau
00:25 ectospasm: I see a lot of drm debug info, but none of it looks interesting to me.
00:26 karolherbst: ectospasm: did you booted with "dm" or "drm"?
00:26 ectospasm: drm, that was a typo earlier, karolherbst
00:27 imirkin: perhaps pastebin dmesg?
00:28 ectospasm: imirkin: I'll have to reboot with that parameter loaded, as I've unloaded it now.
00:53 karolherbst: imirkin: the divinity issue again? :/
00:54 imirkin: karolherbst: ?
00:56 karolherbst: imirkin: bug 95215
00:56 ectospasm: imirkin: before "sleep 1 && xset dpms force off": https://paste.debian.net/682800/
00:58 ectospasm: looks like after is too large to paste at paste.debian.net and pastebin.ca...
00:59 imirkin: ectospasm: hastebin.com
01:02 imirkin: karolherbst: i dunno, someone with an amd card was able to get it to run just fine
01:02 karolherbst: funny
01:02 karolherbst: without my branch? mhh maybe they fixed it?
01:02 karolherbst: I should try to run the game
01:04 karolherbst: imirkin: well, still crashes for me with stock mesa
01:04 imirkin: there was another bug open about it
01:04 imirkin: yeah, it crashed
01:04 imirkin: but somewhere else? dunno
01:04 karolherbst: yeah
01:04 karolherbst: there are multiple reasons it crashes
01:04 karolherbst: three in total
01:04 karolherbst: 1. no GL 4.2
01:05 karolherbst: 2. no ARB_shading_language_include
01:05 karolherbst: 3. no mesa-595d56cc866638f371626cc1d0137a6a54a7d0f8
01:07 ectospasm: imirkin: http://filebin.ca/2gOK6ojk7pCM/after.dpms.off
01:07 ectospasm: Looks like I see some events, but I don't know how to interpret them.
01:08 imirkin: hmmmmmmm
01:08 imirkin: i wonder if the audio is somehow waking it up
01:09 imirkin: i never see it setting DPMS to off. that's weird.
01:09 ectospasm: That's a clue I hadn't thought of, about the audio.
01:09 imirkin: unfortunately nothing you can do about it
01:10 ectospasm: Well, this DPMS problem is not as bad as the issue I get with nvidia
01:10 ectospasm: THAT'S really weird, and I don't know how to approach it.
01:11 ectospasm: but this isn't the right forum for that.
07:58 mupuf: I am surprised karol did not mention this: https://youtu.be/OCoKQTMoSHI?t=1834
07:59 mupuf: This is exactly what we have been working on for voltage!
07:59 mupuf: and now, we know how much it fluctuates, yeepee!
08:19 mupuf: imirkin_: hey, opinion on Pascal's independent viewports?
08:19 mupuf: opinions*
08:19 mupuf: I mean, how messy it will be to configure? :D
08:20 mupuf: 16 apparently
08:20 mupuf: 16 viewports*
08:21 mupuf: I see how you could simply push the parameters for them in the pushbuffer ... but I wonder how they can be connected to each others Maybe there is a higher-level API that just specifies the curvature you want and how many viewports you want to use and if you want it stereo or not
08:23 mupuf: I am wondering because how do you specify how each viewport is connected to the other ... unless you actually give the 3D coordinates of all the corners
08:24 mupuf: which is actually a possibility
08:24 mupuf: but I wonder if we will need to get a VR headset
08:25 mupuf: to reverse this, or if it will be exposed to the user on linux without it
08:41 mupuf: imirkin_: well, actually, it is also designed for multiple screens, so, that should not be an issue to reproduce ... when the linux team is done implementing this feature
08:41 karolherbst: mupuf: what :D
08:42 karolherbst: mupuf: I didn't watched the presentation... yet
08:42 mupuf: karolherbst: you saw my link?
08:42 karolherbst: yeah
08:42 karolherbst: let me see
08:43 mupuf: the multi viewport is definitely a cool feature
08:45 mupuf: so, let's hope we will get same-day firmwares for the soon-to-be pascal GPUs!
08:46 karolherbst: yeah well, he didn't tell much, did he?
08:46 mupuf: the slide is enough
08:48 karolherbst: ahh now I get the slide :D
08:48 karolherbst: I think
08:48 mupuf: the thing is that we may still have instabilities because we do not configure clock and power gating
08:48 karolherbst: not sure
08:48 karolherbst: mhhh
08:48 karolherbst: you know what? I also thought about this
08:49 mupuf: so, the peek-to-peek voltage may fluctuate more in practice
08:49 karolherbst: we have no way to messure this, right?
08:49 mupuf: no
08:49 karolherbst: sounds like fun
08:49 Hoolootwo: can you just throw a scope on there?
08:53 mupuf: Hoolootwo: well, I won't solder
08:53 mupuf: as in, I do not want to take the risk
08:53 mupuf: but hey, we have up to 1 kHz scope on some
08:54 mupuf: not enough to measure peek-to-peek though
08:54 Hoolootwo: where is the voltage fluctuating? on the GPU's power supply circuit?
08:54 Hoolootwo: likely you could just do a poke with a probe and get a good signal
08:57 mupuf: Hoolootwo: the voltage fluctuates because the load fluctuates
08:57 mupuf: and you know, U = RI
08:58 mupuf: so, if I changes, the voltage drops increase
09:02 karolherbst: mupuf: heard anything about what GPU Boost 3.0 brings new?
09:03 karolherbst: well I guess we have to look in the vbios, but maybe it is just about increased clocks
09:06 mupuf: oh yeah, we can at least get vbioses when they get released
09:06 mupuf: maybe we can get them even now!
09:06 karolherbst: :D
09:06 karolherbst: I think we have to wait a few days
09:06 karolherbst: but I will ask Michael :D
09:06 mupuf: why, pre-production hw is out :D
09:08 karolherbst: but I am curious why the decided to increase the clocks so much with pascal
09:08 karolherbst: even for gddr5 the effective clock increased by 42%
09:08 karolherbst: same with the cores
09:09 mupuf: what do you mean, isn't the answer obvious?
09:10 karolherbst: ohhh
09:10 mupuf: when you increase the memory clock, you need to increase the clocks of the processor to be able to max the memory bw in all cases
09:10 karolherbst: gddr5x is quad-pumped
09:10 mupuf: otherwise, what good is it?
09:10 mupuf: memory bw should always be the bottleneck
09:10 karolherbst: right
09:10 mupuf: and remember, they expected HBM to arrive
09:11 karolherbst: k, gddr5x will be fun
09:11 mupuf: so... you need to drastically fix your inefficiences if you want to be able to cope with that much bw
09:11 karolherbst: so memory is indeed lower clocked
09:12 mupuf: still pretty high :p
09:12 karolherbst: right
09:12 karolherbst: well
09:12 karolherbst: this means more code changes inside clk this time
09:13 karolherbst: 14GHz can be supported as it seems
09:13 karolherbst: which makes sense somewhat
09:13 mupuf: :)
09:13 karolherbst: http://www.anandtech.com/show/9883/gddr5x-standard-jedec-new-gpu-memory-14-gbps
09:15 karolherbst: ahh the magic 1.4GHz range
09:16 karolherbst: and now a second transition at 6GHz needed
09:16 mupuf: ah ah, up to 16 GHz
09:17 mupuf: oh, so it is compatible with GDDR5
09:17 mupuf: there is just another mode
09:18 karolherbst: I don't think so
09:18 karolherbst: the "middle" mode has DLL/PLL off
09:18 karolherbst: which is odd, because on gddr5 they are on for sure
09:19 mupuf: yep :_
09:19 mupuf: Ok, let's have a look at the tegra while I still can
09:20 mupuf: and then, gonna have to go back to studying :s
09:20 pmoreau: I thought they already had multi-projection on Maxwell v2, but apparently it was only viewport multicast.
09:23 mupuf: they were building towards it :)
09:24 mupuf: hakzsam: hey, how can I dump the pushbuffer?
09:25 hakzsam: mupuf, you can use an envvar but I don't remember the name, or valgrind-mmt
09:25 mupuf: yeah, I was trying to remember the name for the env var
09:26 hakzsam: DEBUG something ;)
09:27 mupuf: NOUVEAU_LIBDRM_DEBUG?
09:27 mupuf: yeah, seems to do the trick
09:28 hakzsam: yup
09:28 mupuf:wonders why the heck we push so many commands to the gpu :o
09:28 mupuf: for just running wflinfo -a gl -p gbm
09:29 hakzsam: bunch of initialization commands
09:29 mupuf: well, I guess I will need valgrind mmt on this jetson, so, let's start compiling it before we absolutely have to
09:29 mupuf: yeah, but we do not need them "D
09:29 hakzsam: yeah, but this doesn't hurt
09:30 karolherbst: wondering why PCIe speed matters in talos principle now...
09:30 karolherbst: :D
09:50 mupuf:has issues using demmt though
09:51 mupuf: I get absolutely no output from demmt
09:51 mupuf: mmt_bin2dedma works though
09:53 hakzsam: it probably fails to find the pushbuf idx
09:54 mupuf: hakzsam: any recommendation?
09:54 mupuf: I can test with a more complex application
09:55 hakzsam: mupuf, oh, did you disable nvif?
09:55 hakzsam: demmt doesn't support nvif IIRC
09:55 hakzsam: this new kernel interface
09:56 mupuf: hakzsam: I just followed this: https://nouveau.freedesktop.org/wiki/Valgrind-mmt/
09:56 hakzsam: mupuf, see 5b614b141a4674e214e2258613adfdf3c138c387
09:56 hakzsam: mupuf, yeah this is how to launch valgrind-mmt
09:56 hakzsam: but you probably need to disable nvif inside mesa
09:56 hakzsam: to use the old kernel interface which is supported by demmt
09:56 hakzsam: err, valgrind-mmt
09:57 mupuf: oh no... recompiling mesa ... again :D
09:57 mupuf: I see, how do I disable nvif then?
09:57 hakzsam: no, only the nouveau subtree
09:57 hakzsam: mupuf, revert this commit a8c474760268f2ebdddd655cea06dbef4500236a
09:57 hakzsam: this should work
09:57 mupuf: ok
09:59 Tom^: anyone tried pcie passthrough and run nouveau on that? :P
09:59 mupuf: Tom^: yeah, hakzsam tried
09:59 mupuf: with the blob ... and windows :D
09:59 Tom^: meh thats of no interest, i want to run on nouveau and linux!
09:59 hakzsam: yeah, I did that and it worked with nouveau IIRC
10:00 Tom^: mostly because im so lazy and dont want to reboot all the time testing stuff
10:00 hakzsam: do you have VT-d?
10:00 Tom^: yea
10:00 mupuf: Tom^: why do you need to reboot?
10:00 hakzsam: and two gpus I guesS?
10:00 Tom^: mupuf: recompiling nouveau with karols branches eetc
10:00 Tom^: hakzsam: well onboard and the 780ti
10:01 Tom^: hakzsam: i think the onboard on the 6700 will satisfy most of my needs and leave the gaming to the pci passthrough
10:01 hakzsam: Tom^, you could find some hints here https://hakzsam.wordpress.com/2015/02/21/471/
10:01 Tom^: cool
10:01 hakzsam: I only tried with two nvidia gpus though
10:02 Tom^: that isnt such a bad idea either, ordering a secondhand lowend kepler or similiar hmm.
10:02 hakzsam: bbl
10:11 mupuf: hakzsam: it did not work. I gave up and used dedma
10:11 mupuf: I only cared about the pushbuffer
10:40 hakzsam: mupuf, okay
11:24 mwk: seriously, I love this tool
11:24 mwk: one of many things llvm gets right
11:27 mwk: I'd also love to migrate our testsuite to lit... except we don't actually have one
11:28 karolherbst: ahh right
11:28 karolherbst: ninja is just a make replacement right?
11:29 mwk: it's just a make replacement that gives an order of magnitude speedup when you recompile with a few changed files
11:30 mwk: and it's supported out of the box by cmake
11:32 mwk: oh, and the UI is much better
11:33 mwk: it just takes up a single line of output unless some command shouts warnings or blows up
11:34 mwk: + it buffers all subcommand output to pipes, and displays it in-order, so you don't get interleaved warning mess like you do with make
11:35 mwk: ... unless you mark a job as "console", in which case it's guaranteed to run with *exclusive* access to the terminal
11:35 mwk: in general, a damn well-designed tool
11:35 mupuf: nice
11:36 mupuf: and it runs faster even when not rebuilding
11:36 karolherbst: :)
11:36 mupuf: 2.4s vs 1.9 here
11:36 mwk: yep
11:36 karolherbst: mwk: do you think we can default to it in cmake?
11:36 mupuf: karolherbst: no, please
11:36 mwk: I'm not convinced it's a good idea
11:37 mwk: it's not installed by default anywhere, so...
11:37 mwk: it's awesome, but it needs to be opt-in
11:37 karolherbst: I meant with a dep check or something of course
11:38 mwk: hmm
11:38 mwk: I'm not sure if it can actually be done
11:39 karolherbst: reading about cmake antipatterns.. it seems like everybody says you shouldn't add header files to the target
11:39 karolherbst: but you really should
11:39 mwk: add header files to a target? what does that mean?
11:40 karolherbst: for IDE users it does
11:40 karolherbst: if you don't add your target headers to the target, they won't show up in your GUI (Xcode, MSVC, whatever)
11:40 karolherbst: which is not so nice to work with then
11:42 karolherbst: but it seems like we can't change it :/
11:50 RSpliet: it's a shame it has a non-descriptive name
11:50 mwk: true
11:50 mwk: and apparently not unique
11:51 mwk: some buildbot broke recently in LLVM because it had a different ninja in path... something related to server administration
11:53 mupuf: RSpliet: make was already taken :D
11:57 mwk: anyhow, it spoils you
11:59 mwk: I just had to write a little patch to binutils and wrangled with autotools and make and dejagnu and their crappy testsuite
11:59 mwk: that was... painful
12:00 mupuf: mwk: yeah, some people are fans of autotools, I fail to see what is so great about it
12:00 karolherbst: me too
12:00 mwk: yep, we have hundreds of failing tests in the testsuite... don't worry about them, just diff before and after to see if there's any new failure
12:01 mupuf: cmake is less linux-centric so it does not do everything it should when it comes to FHS, but still!
12:01 karolherbst: mupuf: cmake has the big advantage, that it isn't a build too
12:01 karolherbst: l
12:01 mupuf: karolherbst: it isn't a build?
12:01 karolherbst: *tool
12:01 mupuf: ah
12:01 karolherbst: the approach is totally different
12:02 mupuf:likes that is is declarative
12:02 mupuf: and it fucks with everyone's mind
12:02 karolherbst: autotools is done for building stuff, and cmake is there for describing a project to a build tool
12:02 mupuf: right
12:02 mupuf: and some people love creating one CMakeList per folder, like with autoconf
12:03 mupuf: this is stockholm syndrome, right?
12:03 karolherbst: which makes totally sense
12:03 mwk: mupuf: what's wrong with that?
12:03 Tom^: i rather prefer to let the compiler actually error then having a "autotool" print a unlogical message of why it cant build it.
12:03 karolherbst: mupuf: usually I do it this way: /cmake for common files
12:03 karolherbst: mupuf: /CMakeLists.txt for general project related stuff
12:04 karolherbst: mupuf: /src/CMakeLists.txt for including subtargets (and optionally if-disable them)
12:04 mupuf: mwk: http://aegis.sourceforge.net/auug97.pdf
12:04 karolherbst: /src/$subtarget/CMakeLists.txt to desribe the one subtarget
12:04 mwk: mupuf: that doesn't trigger recursive make though
12:05 mupuf: hmm, then OK
12:05 karolherbst: mupuf: you already forgot that cmake isn't a build tool ;)
12:05 mupuf:usually hates digging through a ton of folders to find out the building rules
12:05 mwk: or... does it?
12:06 mwk: what the fuck
12:06 karolherbst: mwk: cmake does dependency management itself anyway
12:06 mupuf: IIRC, you do get a different Makefile per folder
12:06 mupuf: yep, at least it does so on Waffle
12:06 mwk: yeah...
12:07 mwk: and they do use recursive make
12:07 mwk: except they use it to delegate to some other makefile inside CMakeFiles/
12:07 mupuf: so, it is relevant
12:07 karolherbst: yeah
12:07 mupuf: this is likely why ninja works faster. because it can compile all folders in parrallel
12:07 karolherbst: none of those problems in the paper occur even in cmake
12:08 karolherbst: mupuf: well, the cmake generated makefiles also allow you to do this
12:08 karolherbst: kind of
12:08 karolherbst: allthought it usually only builds targets in parallel
12:08 karolherbst: and if you specify -j8, at most 8 targets are built in parallel
12:09 karolherbst: and it doesn't matter where they are
12:09 mwk: huh.
12:09 karolherbst: mupuf: what a big problem with make is, that you can't simply build one subtarget, because the deps aren't managed
12:09 mwk: all the more reason to ditch that thing...
12:10 karolherbst: in cmake you can build whatever subtarget you want without issues
12:10 karolherbst: well with the makefiles generated from cmake
12:11 mupuf: just the fact that cmake works on windows is enough for me
12:12 mupuf: but yeah, all the other features help
12:12 mupuf: it is a truly portable system
12:12 karolherbst: though there are many badly written cmake projects
12:12 mupuf: for the kind of systems modern devs should think about
12:12 mupuf: yeah, the documentation sucks
12:12 mupuf: and there are too little best practices
12:12 karolherbst: and getting linux/macosx/windows-{mingw,msvc} to work at the same time might be tricky for complex projects
12:12 mupuf: it got much better though
12:13 karolherbst: mupuf: I have a project template somewhere where it allows you to add quirks to targets you care about without affecting the rest
12:13 mupuf: oh, cool
12:13 karolherbst: mupuf: like you can add a compile flag in /cmake/compiler/GNU.cmake
12:13 karolherbst: and it only has an effect with gcc
12:13 mupuf: anyways, let's go back to the tegra issue :s
12:35 pmoreau: karolherbst: You can make groups in CMake (using `source_group`) to have them appear in the IDE. That way you don’t need to add them to target.
12:35 pmoreau: karolherbst: You can use it to have a group containing all your OpenGL shaders for example.
12:40 karolherbst: pmoreau: right, but what if I want the header to appear in the target?
12:41 karolherbst: and not in a different section
12:43 pmoreau: Do you have a target section in your IDE?
12:43 karolherbst: I have a section for each of my targets, right
12:44 karolherbst: and smart IDEs also seperate files by headers and source files for each targets
12:44 karolherbst: or give you the option to do so
12:44 karolherbst: *target
12:46 pmoreau: Hum… Dunno. Maybe if you create a group corresponding to the target, with the headers and the source, it won’t be overwritten by the files passed to target, or it will take the union of both?
12:46 karolherbst: pmoreau: anyway, I don't want to workaround something like this. Some headers belong only to one target and that's why I add them as sources
12:46 karolherbst: anything else doesn't make sense
12:47 karolherbst: and it is stupid to call this an anti pattern
12:47 karolherbst: in fact, cmake should even add include directives automatically according to the added header files to the target
12:48 karolherbst: !
12:48 karolherbst: so one could also drop those stupid include_directory(${CMAKE_CURRENT_SOURCE_DIRECTORY} ${CMAKE_CURRENT_SOURCE_DIRECTORY}/include ${CMAKE_CURRENT_SOURCE_DIRECTORY}/priv) thingies...
12:51 karolherbst: https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=4abac0d0bbc628df5f26845fe05ffc6b3a6533dd :)
13:27 aeqrs25: How can i disable vsync on nouveau?
13:28 karolherbst: aeqrs25: vblank_mode=0
13:29 aeqrs25: But where i need to change this?
13:31 karolherbst: aeqrs25: it is an environmental variable
13:31 karolherbst: aeqrs25: usually there is no reason to disable vsync. And usually you can disable it withing your window manager or inside the application
13:31 Tom^: i wonder if driconf doesnt let you set it
13:33 aeqrs25: ok
13:34 Calinou: <karolherbst> aeqrs25: usually there is no reason to disable vsync. And usually you can disable it withing your window manager or inside the application
13:34 Calinou: what
13:34 Calinou: do you ever play fast-paced games?
13:35 Calinou: vsync is calling for input lag and stuttering (if your FPS drops below 60)
13:35 Calinou: there's a reason QuakeWorld players 1) disable vsync, 2) use 500 Hz or 1000 Hz USB polling, 3) use raw input
13:35 Tom^: meh, buy a better gpu
13:35 Calinou: it makes sense to enable vsync by default (most users don't play such games), but not making it easy to disable it kind of sucks
13:35 Tom^: =D
13:35 Calinou: Tom^: won't solve it
13:35 Calinou: even a 980 Ti will suffer from the same input lag
13:36 Tom^: ofc it does never dropping below 60 would remove most annoyances
13:36 karolherbst: Calinou: like that matters much
13:36 karolherbst: Calinou: usually I get a headache faster for having tearing
13:36 Calinou: if you want to attract hardcore gamers to free operating systems, it's important :P
13:36 karolherbst: and my concentration decreases
13:46 Tom^: wish i had the money to get gsync
13:47 karolherbst: Calinou: at some point the internet latency is too big and a kind of placebo effect is there thinking higher usb polling helps :D
13:51 Calinou: karolherbst: what if you have fiber :)
13:53 Tom^: Calinou: the latency towards your router is greater then what you will ever achieve on usb polling or input :P
13:57 karolherbst: Tom^: well, 4ms with Wifi is possible though
13:57 karolherbst: Tom^: and a shitty router can account for 2ms of that
13:57 Tom^: mhm
13:58 karolherbst: now the biggest latency I've got comes from the ISP being stupif
13:58 karolherbst: *stupid
13:58 arom: is fermi unlocked?
13:59 Tom^: arom: uhm define unlocked
13:59 karolherbst: Tom^: but at my gf dorm I had one hop internet Core access. So after 2-3ms I was alread way passed the ISP
13:59 karolherbst: "ISP"
13:59 arom: reclocking
13:59 Tom^: karolherbst: heh
14:00 karolherbst: Tom^: yep
14:00 karolherbst: don't have the traceroutes anymore though
14:00 Tom^: time to compile your branch.
14:00 Tom^: yes, i bought a 850 250gb evo, and installed arch on it. i got bored
14:00 karolherbst: Tom^: there are mesa patches for getting divinity working an easy way now :)
14:00 karolherbst: :D
14:01 Tom^: im more of concerned with cs:go tho :(
14:01 karolherbst: meh arch. Those maintainers are getting a bit crazy over time
14:02 Tom^: yea well its either arch or gentoo but i never find the patience to learn use flags and emerge builds
14:02 karolherbst: :D
14:25 Tom^: karolherbst: however i guess the reclocking flicker isnt fixed yet?
14:25 karolherbst: Tom^: nope
14:25 Tom^: :(
14:25 karolherbst: well, at least it does reclock more stable now
14:26 Tom^: so anyway to force it to max clocks on your v5 then?
14:26 karolherbst: Tom^: what do you mean by "max" clock?
14:27 Tom^: either boost or non boost :P
14:27 Tom^: i just dont want down or up clocking
14:27 Tom^: because well flickers =D
14:28 karolherbst: it won't flicker
14:28 karolherbst: flicker only happens on memory reclocking
14:28 Tom^: oh
14:28 imirkin: mupuf: i'm not sure how that viewport feature is any different from the DX10 GS-based viewports (aka ARB_viewport_arrays)
14:28 karolherbst: Tom^: there has to be engine reclocks
14:28 karolherbst: Tom^: temperature will most likely trigger those
14:29 Tom^: is reclocking on by default? or is there a debugfs file
14:30 karolherbst: ...
14:30 karolherbst: wut
14:30 karolherbst: helped inst ../nvidia_shaderdb/tomb_raider/2566.shader_test - 0 31 -> 1
14:30 karolherbst: Tom^: debugfs
14:30 karolherbst: Tom^: pstate and boost
14:30 Tom^: oki
14:30 arom: fermi reclocked?
14:30 karolherbst: arom: nope
14:31 arom: bad
14:36 Tom^: karolherbst: odd im not recieving flickers anymore when changing pstate =D
14:36 karolherbst: ...
14:36 karolherbst: that's odd
14:37 Tom^: ah now, after a few spam changes
14:37 Tom^: heh
14:37 Tom^: doesnt seem to happend at all times
14:38 karolherbst: ehm...
14:39 karolherbst: does this vertex shader really does nothing?
14:39 karolherbst: *do
14:40 Tom^: karolherbst: think i found a tiny bug, boost file seems to suggest the "third" or state 2 will boost to 1176 but pstate tells me im only getting 1096 which is more in line with what the blob gives me anyways
14:41 karolherbst: nope
14:41 karolherbst: this is right
14:41 karolherbst: Tom^: do nvaforcetemp 1
14:41 karolherbst: then the clock should icnrease
14:41 karolherbst: and with nvaforcetemp 95
14:41 karolherbst: it may be lower
14:41 Tom^: well im on 63C
14:41 karolherbst: hot hot :D
14:42 Tom^: benchmarking :p
14:43 karolherbst: Tom^: you may get worse results now
14:43 Tom^: D:
14:44 karolherbst: imirkin: is anything usefull happending here? https://gist.github.com/karolherbst/1fdab8123ca2d0bef96c6ceba6475926
14:44 karolherbst: *happening
14:44 Tom^: karolherbst: i had the impression that v5 had dynreclocking in it, but that isnt the case yet ?
14:44 karolherbst: Tom^: nope
14:44 karolherbst: Tom^: just temperature aware reclocking
14:45 Tom^: thats why i thought it was gonna flicker but ah i see
14:45 karolherbst: Tom^: the maximum voltage drops for most gpus at higher tempteratures
14:45 karolherbst: Tom^: which means we might have to clock down to meet the voltage requiernments
14:46 karolherbst: like if cstate 60 needs 1.20V at 70°C
14:46 Tom^: mh just that with this beefy third party cooler i cant go above 65C even at max 1.2 volts and max stable clocks.
14:46 Tom^: :P
14:46 karolherbst: but we should only volt to 1.19V at 70°C
14:46 karolherbst: then we can't use that cstate
14:46 imirkin: karolherbst: not really... in a vertex shader, there are no outputs, so... it does nothing.
14:46 karolherbst: allthough the hardware can do 1.215V
14:46 karolherbst: imirkin: ahh okay
14:46 karolherbst: imirkin: because without my pass this shader gets like 31 instructions
14:46 karolherbst: imirkin: after it, only one exit
14:46 imirkin: chances are you removed the exports
14:47 imirkin: which in turn meant everything else was dead code
14:47 karolherbst: imirkin: the output was with my postRADCE pass
14:47 karolherbst: let me check without it
14:47 karolherbst: but it shouldn't get removed
14:47 karolherbst: imirkin: easier: pre SSA https://gist.github.com/karolherbst/24502548d73475c2f33d19c6236070c8
14:48 karolherbst: that's a pretty big shader though
14:48 karolherbst: the glsl code has like 190 loc
14:48 Tom^: karolherbst: dont remember what settings do you? http://i.imgur.com/BD4B6XH.png because i just got like 700 more score then before.
14:49 karolherbst: imirkin: so this is all dead-code?
14:49 karolherbst: Tom^: 4x msaa
14:49 karolherbst: Tom^: and normal tess
14:49 Tom^: and ultra perhaps
14:49 karolherbst: yep
14:50 imirkin: karolherbst: looks like there are no exports... wtf is the source of the shader?
14:54 karolherbst: more detailed stats about my pass by the way: https://gist.github.com/karolherbst/9806873e8d843cbead3635b9eb49d7cb everything else had a change below 0.05%
14:56 imirkin: very cool
14:56 Tom^: :O ive gained 4 score http://i.imgur.com/mP4p766.png , thats a point per month since i last tested =D
14:57 karolherbst: Tom^: :D
14:57 karolherbst: Tom^: yeah, this sounds okay
14:57 karolherbst: Tom^: it shouldn't affect perf at all or not that much
14:57 karolherbst: Tom^: this mostly fixes stability issues
14:57 Tom^: cool
14:58 karolherbst: Tom^: well sometimse it decreases performance when the voltage drop on temperature is really high
14:58 karolherbst: Tom^: or sometimes it increases perf when there is no voltage drop
14:58 karolherbst: in any case
14:58 karolherbst: it will be slower than stock nouveau
14:58 karolherbst: but a lot more stable
14:59 Tom^: once you plan on adding dynreclocking, ping me and il dedicate my entire free time so we can hunt down the flicker issue :P
14:59 karolherbst: Tom^: but there is oemthing to play with :)
14:59 karolherbst: Tom^: https://github.com/karolherbst/nouveau/commit/648fbe28edc7fbc280dede539afc450c602a22d0
14:59 karolherbst: I should work on the commit message though
14:59 Tom^: oh cool
15:00 karolherbst: Tom^: technically: NvVoltOffsetmV adjust the "result" of those voltage map entries
15:00 Tom^: however i dont think im ever reaching a high temp enough so it starts downclocking
15:00 karolherbst: but still keeps info.min and info.max ranges
15:00 karolherbst: Tom^: it already did
15:00 Tom^: are you sure? arent i on the max allowed cstate that the volts let me hm
15:00 karolherbst: -- ID = 2, mode: 1, link: -1, voltage_min = 1137500, voltage_max = 1200000, volt = 1279548 + (-97 * T * 5^6) >> 10 [µV]
15:00 karolherbst: this is the important entry
15:01 karolherbst: volt = 1279548 + (-97 * T * 5^6) >> 10
15:01 karolherbst: at 43°C it is above 1.215V
15:01 karolherbst: your hardware max voltage
15:01 Tom^: oh i see
15:01 karolherbst: at 60°C it is already down to 1.19V
15:02 karolherbst: 90: 1.14V
15:02 karolherbst: Tom^: that's why I said play around with nvaforcetemp :D
15:02 karolherbst: you should see the effect in pstate
15:02 karolherbst: and sensors
15:02 Tom^: indeed
15:02 karolherbst: and on load the temperature usually gets up
15:03 karolherbst: and might force nouveau to drop the voltage
15:04 karolherbst: Tom^: here your parsed vbios: https://gist.github.com/karolherbst/97406058a6c9f9745b6d02c6613fcd47
15:05 karolherbst: Tom^: interessting tables: "CSTEP", "BASE CLOCK" and "Voltage map"
15:05 karolherbst: base clock contains the boost 0 and 1 values
15:06 karolherbst: and CSTEP has the clock => vmap entry id mapping
15:06 karolherbst: Tom^: and S is the speedo value of your GPU
15:06 karolherbst: in the voltage map table
15:07 karolherbst: Tom^: dmesg will show the speedo with debug=volt=debug
15:07 Tom^: yea i remember bits of this when we dug through these with that .net tool
15:07 karolherbst: yeah, but this is way pass this already :D
15:07 karolherbst: now this is a tool for children
15:07 Tom^: :P
15:08 karolherbst: anyway
15:08 karolherbst: now we have nice formular there
15:08 karolherbst: *formulars
15:08 Tom^: yea
15:15 Tom^: this is too good to be true, not the slightest hint of stutter and im always above 140 fps in cs:go, before i was at around 70-80 at long distances with a smoke popped of
15:16 Tom^: either imirkin has done awesome work or valve updated cs:go, my guess is the former ;)
15:17 imirkin: mmmmm... i don't remember doing anything, but hey, i'll take the credit
15:17 Tom^: that means all games run at acceptable speed without quirks, blob be gone.
15:17 karolherbst: ohh the stutter on a lot of gunfire is fixed?
15:17 Tom^: karolherbst: so it seems
15:17 karolherbst: should be something really recent
15:17 karolherbst: Tom^: just ping me after it crashed for reasons :D
15:17 Tom^: =D
15:17 karolherbst: Tom^: ohh by the way, the power reading is most likely wrong
15:18 Tom^: i have faith
15:18 Tom^: karolherbst: i dont have power reading at all
15:18 karolherbst: sensors
15:18 Tom^: sensors dont report anything unless i add that line to uhm dont remember the file
15:18 karolherbst: ohhh
15:18 Tom^: gk110 something in some struct
15:19 karolherbst: wtf
15:19 karolherbst: you shouldn't have to
15:19 karolherbst: I am pretty sure it should just work
15:19 Tom^: or well im assuming so
15:19 Tom^: i see a power1 at 38w at load
15:19 karolherbst: yeah
15:19 Tom^: i just assumed that was something else
15:19 karolherbst: no
15:19 karolherbst: well the reading is wrong
15:19 karolherbst: I have to fix it up at some point
15:20 Tom^: i see
15:20 karolherbst: imirkin: by the way, my PostRADCE still finds stuff: "total instructions in shared programs : 2583239 -> 2567255 (-0.62%)"
15:20 imirkin: karolherbst: figure out what it is and why
15:20 karolherbst: crap load of more stuff in saints row and bioshock :D
15:21 karolherbst: "helped inst ../nvidia_shaderdb/bioshock_infinite/1540.shader_test - 0 83 -> 44" ugh
15:22 karolherbst: the heck
15:23 karolherbst: my pass should have found this :/
15:26 karolherbst: -.-
15:26 karolherbst: seriously
15:27 karolherbst: imirkin: if (condition) {//empty} else { condition2 = stuff; if (condition2) { // empty} else {//empty} }
15:27 karolherbst: ....
15:30 karolherbst: imirkin: I think I need to run DCE manually on the BB where I delete the conditional bra instruction
15:30 karolherbst: and rerun the pass on the previous BBs
15:31 imirkin: ok
15:31 karolherbst: should be easy though
15:34 karolherbst: imirkin: can I simply do: DeadCodeElim dce; dce.visit(bb) ?
15:37 imirkin: karolherbst: it's c++ code
15:37 imirkin: it obeys the usual rules of c++
15:37 karolherbst: okay
15:37 karolherbst: I was more thinking about stuff I have to do before I can just run those passes
15:38 imirkin: i honestly don't remember
15:38 imirkin: you'd have to look at the DCE pass specifics
15:38 imirkin: but it's just a class... you instantiate it... you call functions on it
15:40 Tom^: oh thats cool 8x msaa is not introducing the LSD effect anymore
15:41 karolherbst: right
15:43 mslusarz: wow, ninja is awesome
15:43 imirkin: Tom^: yeah, that got fixed at one point or another
15:43 imirkin: Tom^: i forget exactly what fixed it
15:44 imirkin: nothing relating to AA iirc
15:44 Tom^: heh
16:03 karolherbst: imirkin: segfault in nv50_ir::MemoryPool::release :/
16:04 karolherbst: released points to something stupid
16:04 karolherbst: ohhh
16:04 karolherbst: right
16:05 karolherbst: I don't call run
16:05 karolherbst: so this->prog isn't initialized
16:19 karolherbst: wow
16:19 karolherbst: for saints_row 3/4 only a few instruction got nuked
16:19 karolherbst: but bioshock
16:19 karolherbst: total instructions in shared programs : 177159 -> 159683 (-9.86%) and total gprs used in shared programs : 18673 -> 17782 (-4.77%)
16:19 karolherbst: that's a lot
16:20 karolherbst: and there are still incstructions to nuke: total instructions in shared programs : 2568067 -> 2545696 (-0.87%)
16:21 karolherbst: changes with the improved pass: https://gist.github.com/karolherbst/9806873e8d843cbead3635b9eb49d7cb/revisions
16:25 karolherbst: imirkin: now it is getting fun. dead BBs with phi instructions :/
16:30 karolherbst: ohh doesn't matter
16:30 karolherbst: I just messed up again
16:30 karolherbst: running my pass twice helps arleady
16:30 karolherbst: *already
16:48 karolherbst: though now I tink that most of it comes from the missing "SSO ENABLED" in the shader_tests :/
16:57 Tom^: karolherbst: whereis those patches for divinity to mesa?
16:58 karolherbst: Tom^: http://whitecape.org/paste/nullptrs
16:58 karolherbst: this is all you need
16:58 Tom^: O_o
16:59 karolherbst: yeah
16:59 karolherbst: the game engine checks for null pointer
16:59 karolherbst: and if glNamedStringARB is NULL, it doesn't use that extension
16:59 Tom^: ah
17:38 karolherbst: hakzsam: do you have a branch somewhere with your metric changes?
17:39 hakzsam: it's pushed
17:39 karolherbst: ohh
17:39 karolherbst: ahh I see
17:40 karolherbst: which metrics? metric-branch_efficiency, and?
17:40 karolherbst: occupancy, right
17:40 hakzsam: you can also try branch and divergent_branch
17:40 hakzsam: with your pass
17:41 karolherbst: hakzsam: the issue is, that I think now that my pass won't help much....
17:41 karolherbst: hakzsam: because this dead code is there because SSO was disabled in the shader_tests
17:42 hakzsam: ah
17:45 karolherbst: hakzsam: a bit sad that we just figured this out today, but maybe there is still some improvement somewhere
17:45 aeqrs25: Why i cant cat the pstate? aeqrs25@capivara:~$ cat /sys/class/drm/card0/device/pstate cat: /sys/class/drm/card0/device/pstate: No such file or directory
17:45 karolherbst: aeqrs25: debugfs since 4.5
17:45 hakzsam: karolherbst, yeah maybe
17:46 Tom^: aeqrs25: /sys/kernel/debug/dri/0/pstate
17:47 karolherbst: hakzsam: by the way: with bioshock three metrics at once is no problem
17:47 hakzsam: which ones?
17:47 aeqrs25: Thanks Tom and Karolherbst
17:47 karolherbst: hakzsam: metric-branch_efficiency,metric-achieved_occupancy,metric-issue_slot_utilization
17:47 hakzsam: karolherbst, cool
17:48 karolherbst: hakzsam: yeah, sometimes it can do even more
17:48 karolherbst: hakzsam: I think after you finish your rework it should be possible to run a lot more in parallel
17:48 hakzsam: right, I hope so :)
17:51 karolherbst: hakzsam: sometimes branch efficiency is 0%
17:51 karolherbst: hakzsam: maybe this is the case when it is 100%?
17:53 karolherbst: hakzsam: what is the best way to get the instruction issued per frame?
17:53 karolherbst: metric-inst_issued?
17:53 karolherbst: or something else
17:53 hakzsam: what? if branch_efficiency is 0%, something is bad somewhere
17:53 hakzsam: yeah, metric-inst_issued
17:53 hakzsam: and set GALLIUM_HUD_PERIOD=0
17:54 hakzsam: this will launch a query for every frame
17:54 hakzsam: which is not the case by default
17:54 karolherbst: okay
17:54 karolherbst: hakzsam: glxgears also has 0% branch_efficiency
17:55 hakzsam: mmh
17:55 hakzsam: what about branch and divergent_branch?
17:57 hakzsam: I guess divergent_branch is 0, right?
17:58 karolherbst: both 0
17:58 hakzsam: that explains why branch_efficiency is 0%
17:59 hakzsam: try with glxspheres64
17:59 hakzsam: it's not 0 IIRC
17:59 karolherbst: hakzsam: okay, no change in instruction per frame allthough my pass nuked 10% instruction away. Guess it's all SSO stuff
17:59 karolherbst: hakzsam: there it works
18:00 hakzsam: how much %?
18:00 karolherbst: 80
18:00 hakzsam: cool
18:00 karolherbst: divergent_branch means "useless" branch ?
18:02 hakzsam: nope, it's incremented by one if at least one thread in a warp diverges (ie. takesa different execution path)
18:02 aeqrs25_: root@capivara:/home/aeqrs25# echo 07 > /sys/class/drm/card0/device/pstate bash: /sys/class/drm/card0/device/pstate: Permission denied how can i change this?
18:02 karolherbst: aeqrs25_: as root
18:02 karolherbst: pohhh
18:02 karolherbst: wait
18:02 karolherbst: odd
18:03 karolherbst: aeqrs25_: cat it first
18:03 karolherbst: aeqrs25_: or do you have a laptop with multiple GPUs?
18:03 aeqrs25_: I have a desktop with a gtx 650
18:04 karolherbst: aeqrs25_: ohh right
18:04 karolherbst: aeqrs25_: wrong path
18:04 karolherbst: aeqrs25_: as Tom^ already said: /sys/kernel/debug/dri/0/pstate
18:05 Calinou: there should be someone providing nice aliases for changing graphics card pstate
18:05 Calinou: like, nouveauctl :)
18:05 Calinou: nouveauctl pstate 07
18:05 Calinou: automatically calls sudo if not used with sudo
18:05 Tom^: im trying o make that right now funnily enough
18:05 Tom^: xD
18:05 Tom^: but im lacking C skills so it will take a while
18:06 aeqrs25_: root@capivara:/home/aeqrs25# cat /sys/class/drm/card0/device/pstate cat: /sys/class/drm/card0/device/pstate: No such file or directory
18:06 aeqrs25_: aeqrs25@capivara:~$ sudo cat /sys/kernel/debug/dri/0/pstate 07: core 324 MHz memory 648 MHz 0a: core 540 MHz memory 1620 MHz 0f: core 1202 MHz memory 5000 MHz AC: core 324 MHz memory 648 MHz
18:06 aeqrs25_: with sudo i can cat
18:06 Tom^: aeqrs25_: yes and as root you are using the wrong path
18:13 karolherbst: seems like it worked
18:38 karolherbst: aeqrs25: I guess it froze?
18:39 aeqrs25: I have discovered how to change the frequency but when i do this my system instantly froze
18:40 aeqrs25: Its very strange ;-;
18:47 aeqrs25_: I have tried two other times and have frozed too, i cant stop laughing kkkkkk
18:55 karolherbst: aeqrs25: well you need my branch to reclock more stable
18:57 aeqrs25: How can i use your branch?
18:58 Tom^: Calinou: behold https://gist.github.com/anonymous/2f0f38a956de67487eb420874b03864d nouveauctl
18:59 Tom^: hm safefree can be removed, old remnants heh
18:59 karolherbst: Tom^: well it doesn't work here
18:59 Tom^: why not :(
18:59 karolherbst: because for me it is /sys/kernel/debug/dri/1
18:59 Tom^: oh
18:59 Tom^: meh you all suck.
18:59 Tom^: life is pointless
18:59 Tom^: karolherbst: how should i parse that then :P
19:00 karolherbst: Tom^: iteratore over all directories inside /sys/kernel/debug/dri/
19:00 karolherbst: and see which of them have a psate and boost file
19:00 karolherbst: and if there are more than one
19:00 karolherbst: require a -c argument to select the gpu
19:00 Tom^: mhm ok
19:00 Cheery: http://boxbase.org/entries/2016/may/9/linux-on-the-desktop-missing-piece/
19:01 Cheery: Does anyone of you have ideas how could I get right things through to make things improve in the aspects I point out?
19:01 karolherbst: aeqrs25: well, if you want to compile an out of tree module and install it: git clone https://github.com/karolherbst/nouveau.git -b stable_reclocking_kepler_v5
19:01 karolherbst: aeqrs25: cd nouveau/drm
19:01 karolherbst: aeqrs25: make
19:02 Cheery: For example, who would need to get a post on NVIDIA to get VK_KHR_display* into mainline nvidia drivers?
19:02 Cheery: or who could initiate development of portable GPU-IPC?
19:02 imirkin: Cheery: i think you're looking for the nvidia guys
19:03 imirkin: nouveau is the open-source, reverse engineered driver. no vulkan impl yet.
19:03 Tom^: karolherbst: debugfs is quite annoying, all files are 0 bytes.
19:03 Cheery: I know. But they've been interacting with nouveau.
19:04 karolherbst: Tom^: right
19:04 imirkin: not really. i guess a little bit. mostly the tegra guys, not the desktop gpu driver guys.
19:04 karolherbst: Tom^: that's why you use stat
19:07 imirkin: Tom^: and all sysfs files are 4k. welcome to fake filesystems.
19:11 aeqrs25: karolherbst http://pastebin.com/x2yPppdH just it?
19:12 karolherbst: aeqrs25: well now you have to install it and regenerate initramfs
19:13 aeqrs25: I am very noob how can i install it?
19:14 karolherbst: aeqrs25: make install (might work, might not, but it is the easiest way)
19:14 aeqrs25: ok
19:14 karolherbst: aeqrs25: and regenerate initramfs
19:14 karolherbst: aeqrs25: and after you reboot, there should be a /sys/kernel/debug/dri/0/boost file
19:16 aeqrs25: aeqrs25@capivara:~/nouveau/drm$ sudo make install
19:16 aeqrs25: make -C /lib/modules/4.5.3-040503-generic/build M=/home/aeqrs25/nouveau/drm/nouveau KCPPFLAGS="" modules_install
19:16 aeqrs25: make[1]: Entering directory '/usr/src/linux-headers-4.5.3-040503-generic'
19:16 aeqrs25: INSTALL /home/aeqrs25/nouveau/drm/nouveau/nouveau.ko
19:16 aeqrs25: At main.c:222:
19:16 aeqrs25: - SSL error:02001002:system library:fopen:No such file or directory: bss_file.c:168
19:16 aeqrs25: - SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:171
19:16 karolherbst: uhhh
19:16 karolherbst: signed modules
19:17 aeqrs25: Kiwirc trolled me lol ;-;
19:17 aeqrs25: http://pastebin.com/79SFcnVU
19:18 karolherbst: no idea how this is handled though
19:18 karolherbst: but if you don't have the key to sign modules, I have no idea what to do
19:21 aeqrs25: I don't have the key ;-; better i don't touch in it
19:22 pmoreau: imirkin: Maxwell v2 had fixed function to "bypass" the GS stuff, and improve perf. I guess Pascal is even "smarter", I’d have to re-read what it is doing.
19:23 aeqrs25: Thanks for all the help
19:23 imirkin: pmoreau: same concept though. GM20x added a way to broadcast a single geometry to multiple viewports without doing it by hand in a GS
19:24 imirkin: pmoreau: also GM20x allows setting the layer/viewport from VS in case a GS is missing
19:28 pmoreau: It’s hard to tell from the little info released, what is different in Pascal
19:28 imirkin: yeah, it sounds like people are making it out to be some new thing, but nothing that they've said sounds at all new
19:29 imirkin: maybe related to this? https://www.opengl.org/registry/specs/NV/viewport_swizzle.txt
19:29 pmoreau: One thing that is different, is the language used: for Maxwell they talk about render target, and for Pascal, they don’t talk directly about render targets, but more monitor or viewport, which could encompass multiple render targets.
19:30 pmoreau: But could just be marketing language as well :-)
19:30 imirkin: well, viewport is a rasterizer concept
19:30 imirkin: which happens before render targets
19:30 imirkin: but that's how it works on DX10 as well
19:52 Calinou: imirkin: is the multiple viewports thing available in OpenGL/Vulkan?
19:53 imirkin: Calinou: ARB_viewport_arrays added it in GL 4.1 (and available as an ext). I *assume* it's available in Vulkan as well.
19:53 imirkin: still a little unclear what this magical viewports thing they're talking about is, and how it's different than the multiple viewports available since the GTS 8800.
19:57 Calinou: according to some Pascal article, VR headsets run at 90 Hz, is this true?
19:57 Calinou: rather than 60
19:59 imirkin: def makes sense... 60 is way too low
19:59 imirkin: 80hz is probably the min
19:59 pmoreau: Calinou: At least the HTC vive is at 90 Hz.
20:00 Calinou: it would be nice of mainstream monitors were 90 Hz too
20:00 Calinou: if*
20:00 Calinou: right now, only really lightweight (or well-coded :p) games run smoothly on 60 Hz
20:00 Calinou: heavier games will stutter every now and then
20:13 agrecascino: hello
20:13 agrecascino: i'm trying to get nouveau working on slackware
20:14 agrecascino: but when i start X, I get [DRM] KMS not enabled.
20:14 agrecascino: i tried nouveau.modeset=1 in the boot parameters, but it still doesn't work
20:17 pmoreau: agrecascino: Could you paste the output of dmesg? You probably have a nomodeset=1 set somewhere.
20:18 agrecascino: https://0x0.st/NEd.log
20:21 pmoreau: agrecascino: You are missing the firmware, so Nouveau fails to load.
20:21 agrecascino: oh, how do i get it?
20:22 agrecascino: i thought that might of had to do with video decoding
20:23 pmoreau: Maybe there is a package for your distrib, it’s in the regular linux-firmware, but you need a more recent version most likely
20:23 pmoreau: No, GM20x cards need signed firmware from NVIDIA for power management, hardware 3D acceleration
20:23 pmoreau: http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git
20:25 pmoreau: You will also need at least Mesa 12.0 IIRC, and use X modeset instead of Nouveau DDX
20:25 agrecascino: :\
20:27 agrecascino: so where do i copy the firmware blobs to?
20:28 pmoreau: Usually it’s in /lib/firmware.
20:29 pmoreau: It looks like this would be the corresponding package: http://packages.slackware.com/?r=slackware-current&p=kernel-firmware-20160401git-noarch-1.txz
20:29 imirkin: mesa 11.2
20:30 agrecascino: will i need mesa for X?
20:30 imirkin: yes.
20:30 pmoreau: And it does have the needed NVIDIA firmwares, so you can use that package rather than copy/pasting manually.
20:31 agrecascino: will that work on slackware 14.1
20:32 agrecascino: wait
20:32 agrecascino: nvm
20:32 agrecascino: dumb question
20:32 agrecascino: okay, so i tried to compile mesa earlier
20:32 agrecascino: and it couldn't link with xcb
20:46 agrecascino: is there a mesa help channel?
20:48 Calinou: #mesa I'd say
20:48 agrecascino: it's dead
20:50 imirkin: agrecascino: sounds like you're in need of a distro support channel
20:52 RSpliet: oh jolly, besides Qimonda being bankrupt, Elpida also no longer exists... how on earth am I supposed to find datasheets for those RAM chips? O:-)
20:52 agrecascino: mesa just failed builded
20:52 agrecascino: building*
21:11 Calinou: move to Arch
21:11 Calinou:runs
21:43 karolherbst: RSpliet: well, how critical is the information=
21:43 karolherbst: ?
21:43 RSpliet: karolherbst: it's either info or yolo
21:43 karolherbst: RSpliet: usually the nvidia driver already takes care of the important bits ;) So what exactly would you need?
21:44 RSpliet: karolherbst: the EMRS2 definition of the Elpida EDW1032BBBG-50-F ideally
21:44 RSpliet: it's less important than I thought, since it's GDDR5, not GDDR3
21:45 karolherbst: yeah, but wouldn't you get the information you need eventually by checking what nvidia does? Or does it take significantly longer this way?
21:45 karolherbst: I am just curious
21:45 RSpliet: datasheets help
21:45 RSpliet: big time
21:46 RSpliet: nouveau reclocking wouldn't stand where it is today without them
21:48 karolherbst: okay
21:49 karolherbst: RSpliet: maybe we could ask gnurou, these can't be so strong protected that they can't give us a copy of the datasheets, can they?
21:49 RSpliet: NVIDIA doesn't have them, RAM vendors have them
21:49 RSpliet: I think we can get away without for now
21:49 karolherbst: shouldn't nvidia have a copy of them if they use them?
21:50 RSpliet: possibly, depends on whether they certify RAM chips for their GPUs or not
21:50 RSpliet: (and did so in 2008)
21:55 karolherbst: well, there are gddr5 fermis, right?
21:55 karolherbst: or was there something else odd
21:56 RSpliet: yes
21:56 karolherbst: ohh
21:56 karolherbst: even gddr5 teslas
21:56 karolherbst: right, this was the odd one
21:56 RSpliet: well, only one GDDR5 NVA3
21:56 karolherbst: right
21:56 karolherbst: and of the same model there was also a DDR3 and GDDR3 version
21:57 karolherbst: two models in fact
21:57 karolherbst: GT 340 and GT 240
22:06 RSpliet: karolherbst: are you still awake enough to test a kernel patch for me?
22:07 karolherbst: RSpliet: on my fermi?
22:10 RSpliet: karolherbst: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/12c76f4c4f4dfc3af5fecae26715b30cbe8505fd
22:11 RSpliet: fermi or kepler... I expect this might solve or at least reduce the number of random hangs
22:11 RSpliet: if I did it correctly
22:11 RSpliet: skeggsb: ^ you might want to review that change
22:14 karolherbst: RSpliet: any good idea to test this? Besides stuff still working
22:15 RSpliet: not really
22:15 RSpliet: in the lab I have a computer that I can get to hang reliably just by starting openarena twice and waiting 5 mins
22:15 RSpliet: (XFCE, no serious compositor)
22:16 RSpliet: I don't have time to test it unfortunately
22:16 RSpliet: (not in the lab, maybe I can find some spare time soon :-P)
22:17 RSpliet: not hanging instantly would already be reassuring, less hangs would be great
22:19 karolherbst: well usually my GPU doesn't hang
22:25 RSpliet: karolherbst: hangs with 2 contexts (Xorg + one 3D app) are pretty rare
22:26 karolherbst: well
22:26 karolherbst: I have one
22:26 RSpliet: although the cards in my lab reliably hung after a day of work
22:26 karolherbst: but also 20 contexts are pretty stable
22:26 RSpliet: anyway, I must hit the sack
22:27 RSpliet:&
23:00 karolherbst: when we have mov $r0 $r2; mov $r1 $r3; call abs BUILTIN:1; are both $r0 and $r1 used by the call ?
23:02 karolherbst: later in pre RA there is a nop referencing both
23:06 imirkin_: karolherbst: the nop after is to clobber the regs after the function call
23:06 imirkin_: r0/r1 are inputs
23:07 karolherbst: mhh okay
23:07 imirkin_: r0..r4 p0..p2 are outputs
23:07 imirkin_: or... something
23:07 karolherbst: well in PostRA they could get DCEed away because it somes at least $r0 is unreferenced in that case :/
23:08 karolherbst: imirkin_: anyway, I've added now the "SSO ENABLED" entry in all shaders which changed due to my pass, but now I get stuff like "ERROR: Unexpected token in ../nvidia_shaderdb/antichamber/4215.shader_test"
23:08 karolherbst: but the shader_runner doesn't complain
23:08 karolherbst: when I run it alone
23:09 karolherbst: ohh maybe shader-db itself can't handle that
23:10 karolherbst: right...
23:10 imirkin_: memory corruption?
23:10 karolherbst: nope
23:10 karolherbst: run.c can't handle SSO ENABLED
23:10 karolherbst: line 122
23:10 imirkin_: ah
23:10 karolherbst: :/ meh
23:11 karolherbst: imirkin_: any special gl call which has to be called when sso is enabled?
23:12 karolherbst: I guess adding the parsing code should be kind of trivial
23:15 imirkin_: yeah
23:15 imirkin_: a bunch
23:16 imirkin_: look at how shader_runner does it
23:16 karolherbst: I guess I have to create fake shaders with input/output match the stuff and create the pipeline objects?
23:18 karolherbst: :/
23:20 karolherbst: and shader-db also only udnerstands VP and FP
23:20 karolherbst: ohh not true
23:20 karolherbst: also gs
23:20 karolherbst: ...
23:20 karolherbst: nvm
23:20 karolherbst: I am tired as it seems
23:23 agrecascino: help
23:24 agrecascino: apparently i screwed up still
23:25 agrecascino: i put the nvidia folder into /lib/firmware
23:25 agrecascino: and the firmware load still fails
23:38 orbea: is it just me or does this no longer work? "dmesg | grep -i chipset"
23:38 orbea: 4.4.8 kernel here
23:38 imirkin_: probably got changed in 4.3 or so
23:38 imirkin_: orbea: lspci -nn -d 10de:
23:38 orbea: thanks
23:40 agrecascino: where do i put the firmware blobs
23:40 agrecascino: like
23:40 imirkin_: agrecascino: /lib/firmware.
23:40 agrecascino: /lib/firmware/(place)
23:40 imirkin_: agrecascino: but ideally just update your firmware package and your distro will take care of it all
23:41 agrecascino: slackware
23:41 orbea: agrecascino: I already told you in ##slackware, there is a slackbuild for this... https://slackbuilds.org/repository/14.1/system/nvidia-firmware/?search=nvidia-firmware
23:41 agrecascino: too old
23:41 agrecascino: need 350~ or newer
23:41 imirkin_: that build is for totally different firmware
23:41 orbea: oh
23:41 imirkin_: you need linux-firmware.
23:41 agrecascino: oh
23:41 agrecascino: well
23:41 agrecascino: i got linux-firmware from git
23:42 imirkin_: that should have it.
23:42 agrecascino: where do i place the nvidia folder
23:42 agrecascino: i put it directly in /lib/firmware
23:42 imirkin_: ask your distro
23:42 agrecascino: and firmware load still fails
23:42 orbea: imirkin_: he wants the firmware inside the kernel?
23:42 imirkin_: there's more to it. you appear to need help operating your distro. ask in a distro-specific support channel.
23:43 imirkin_: we (well, at least i), tend not to provide distro support here.
23:47 orbea:reads up and thinks he should already have the firmware, its just that with a maxwell card it might not work?
23:47 imirkin_: orbea: what problem are you attempting to solve?
23:48 orbea: w/e agrecascino is on about
23:48 imirkin_: he's having trouble getting his system to load the nvidia firmware supplied in linux-firmware
23:48 imirkin_: it tries to find it but can't
23:48 imirkin_: which is indicative of one of 100 different issues
23:48 imirkin_: the overriding one is PEBKAC
23:49 orbea: he has a maxwell card, is that the reason?
23:49 imirkin_: the reason for what?
23:49 orbea: for not finding the firmware
23:49 imirkin_: no, the reason is that he messed something up
23:49 imirkin_: the reason it wants firmware in the first place is that it's a GM20x GPU though - is that what you were asking?
23:52 orbea: He's been asking in the ##slackware channel and till now I thought he wanted something else because it wasn't clear what his problem was. Slackware should have the firmware ootb in the kernel-firmware package http://dpaste.com/3K9HEZE
23:54 imirkin_: yeah
23:54 imirkin_: like i said - could be one of 100 diff issues
23:55 orbea: yea...
23:56 orbea: and he's gone so no point...
23:58 imirkin_:doesn't do distro support