00:09 tobijk: imirkin_: well it has its up and downs: https://hastebin.com/igixuwahaf.hs
00:10 imirkin_: grrrr.
00:10 tobijk: (at least it does not crash) :d
00:10 imirkin_: always a silver lining ;)
00:10 imirkin_: yeah ok, i can see the gpr thing.
00:10 imirkin_: that's solvable.
00:10 imirkin_: i'll have a bigger better patch
00:11 tobijk: imirkin_: yeah let me know if you think its ready, i will test it, np
00:11 imirkin_: in ... later.
00:11 tobijk: imirkin_: yeah, just cc me if you post it somewhere
00:12 imirkin_: well, i can run shader-db all by myself. i just don't have the stuff handy here.
00:12 imirkin_: and i was curious :)
00:14 Aristar: hmm seems most kde/plasma stuff migrated to QtWebEngine which detects nouveau,
00:15 Aristar: though some wm themes have effects builtin, exporting `KWIN_EFFECTS_FORCE_ANIMATIONS=0` disables basically everything
04:45 imirkin: bleh. the shader-db thing takes so long.
04:48 imirkin: 13 minutes
04:49 imirkin: ok. https://hastebin.com/umufavuger.hs this seems better.
04:57 imirkin: tobijk: https://github.com/imirkin/mesa/commit/ded5eec722e081f03b1239af5a94a693e4d11a86
04:58 imirkin: hm. my baseline is misleading =/
05:08 imirkin: on the bright side, this might fix the constbuf load thing. hmmm.
05:37 imirkin: skeggsb: did you have a chance to test out my MST patch for xf86-video-nouevau?
05:55 airlied: skeggsb: i think hes on golidays
05:55 airlied: holidays
05:56 imirkin: oh
05:56 imirkin: that explains why he hasn't responded.
06:41 imirkin: with a few patches i've been working on ... https://hastebin.com/hujaretamo.hs - not too bad.
06:51 imirkin: all available on my cts branch... up to and including the "load from constbuf" change. all those stats need to be regenerated...
11:58 tarragon: 4.14 any good?
12:24 gnarface: tarragon: i'm sticking with 4.9 for a while longer due to bad experiences with 4.13 and alsa. not sure if that helps you or not.
12:33 tarragon: gnarface: wowo
12:33 tarragon: :(
12:48 gnarface: tarragon: (4.9 is probably the stock default in debian stable for a reason)
12:53 karolherbst: gnarface: no, it doesn't change and it was the newest one back then. I don't think they put more thoughts into this than that
12:54 karolherbst: maybe they choose a longterm kernel in addition to that, but that pretty much is the decision making
12:55 tarragon:checks 4.14 nouveau changelog
13:21 karolherbst: fun, so I need to deal with that gp107 firmware not loading issue.. fun
13:24 mupuf: karolherbst: and?
13:24 karolherbst: resetting the GPCCS timeout
13:25 karolherbst: would be fun if it would work with the "broken" version, right?
17:14 Noxbru: Hi, I have a question:
17:14 Noxbru: I have a dual GPU setup intel + nvidia
17:15 Noxbru: right now it is working fine with bumblebee, but I haven't played anything recently so I was thinking of changing the nvidia drivers for nouveau, is it possible?
17:17 imirkin_: Noxbru: what nvidia gpu do you have?
17:21 Noxbru: 920m
17:21 Noxbru: 3D controller: NVIDIA Corporation GK208M [GeForce 920M]
17:21 Noxbru: at least that's what lspci says
17:22 feaneron: Noxbru: same setup here. works perfectly with nouveau
17:22 imirkin_: oh excellent - GK208 should work quite well
17:22 imirkin_: (it's a POS gpu, but not much we can do about that)
17:23 Noxbru: good, but I wanted to ask if it would be possible to have a setup similar to the one I have, where it is always powered down because I don't use it
17:23 imirkin_: yeah. just make sure you don't use bumblebee, and it should all work.
17:23 imirkin_: (runtime pm will turn it off automatically after like 5s iirc)
17:24 imirkin_: (assuming your platform supports it, which all laptops do)
17:24 feaneron: Noxbru: if you use gnome and have switcheroo, you can even launch apps on that gpu withing gnome-shell
17:24 Noxbru: okay, good to know, I'll try at some point, thanks :)
17:25 feaneron: for reference: http://www.hadess.net/2016/10/dual-gpu-integration-in-gnome.html
17:26 feaneron: Noxbru: notice that with 920m you have to manually change the clocking rate to get the best performance
17:27 Noxbru: as I said, I don't really use it now, the intel is enough for everything and even for playing
17:27 Noxbru: so, probably it's going to stay at the lowest clock :)
17:27 feaneron: right
17:27 Noxbru: thanks imirkin_ and feaneron
17:28 imirkin_: yw. feel free to ask here should you run into trouble / get something unexpected
17:29 imirkin_: do note that you'll get a fraction of the max perf with nouveau compared to nvidia - about 40-80% depending on the thing.
17:29 Noxbru: sure, that's expected
17:30 Noxbru: but hopefully I will have some free time to learn a bit of how nouveau works
17:30 imirkin_: (turns out they know their GPUs better and have more people working on it than we do.)
17:31 feaneron: nouveau is a miracle of smart people. btw, imirkin_, what's blocking full performance on <= kepler? i thought the clocking thing was the most important one
17:33 Noxbru: magic optimizations that nvidia does?
17:33 imirkin_: feaneron: i'm talking about clock-for-clock perf
17:33 imirkin_: obviously having different clocks will also affect perf
17:33 feaneron: maybe? looks like the override some shaders from some games, but would that be the source of perfs?
17:33 feaneron: ah, right
17:34 imirkin_: i don't really know tbh. there are basically 3 sources of this:
17:34 imirkin_: 1. features we don't implement (e.g. zcull, probably others)
17:34 imirkin_: 2. resource management (moving stuff between sysram/vram/etc)
17:34 imirkin_: 3. compiler quality
17:35 imirkin_: oh, and 4: unnecessary sync'ing
17:35 imirkin_: (there are a ton of caches/etc in the gpu, and if you don't know how to flush them properly, you end up over-flushing. it's hard to discover that stuff reliably through RE though.)
17:40 feaneron: right. i assume (1) is mesa-level, (2) is kernel (or libdrm?) level, and (3) is llvm or something like that?
17:40 Noxbru: feaneron: nouveau doesn't use llvm as far as I know
17:51 imirkin_: feaneron: all mesa level
17:53 feaneron: ok, thanks.
17:54 feaneron:clones mesa
17:55 Noxbru: I used to have it cloned somewhere... in my old laptop
18:06 imirkin_: [and technically nouveau does use llvm, but practically speaking, it doesn't]
18:07 karolherbst: imirkin_: it might end up getting used more than you hoped for :P
18:09 Noxbru: really? you mean through clover maybe?
18:09 karolherbst: Noxbru: that would be one idea
18:09 karolherbst: but there is also spir-v in general
18:10 karolherbst: and why not just compile it to tgsi though llvm?
18:10 Noxbru: but then you would need llvm to produce TGSI or something that nouveau can consume
18:10 karolherbst: exactly
18:15 imirkin_: karolherbst: coz it's a pain :)
18:15 imirkin_: much easier to just consumer spir-v directly
18:15 karolherbst: right
18:17 imirkin_: Noxbru: llvm is used as a fallback by the mesa state tracker, to handle some ancient GL stuff that's a pain to do in hw (feedback and select buffers)
18:18 imirkin_: also nv30 has a bunch of stuff it falls back to the draw module for, which uses llvm if available
18:18 Noxbru: oh, I didn't know, thanks for the info
18:18 imirkin_: but it's not being used in any capacity to deal with the nvidia gpu
18:18 imirkin_: only for cpu-based calculations
18:19 imirkin_: (if we were smart, we'd make the translate module use llvm...)
18:19 imirkin_: (instead it uses a custom rtasm thing. it's decent, but i'm sure a competent compiler can do better.)
20:01 imirkin_: tobijk: btw, dunno if you saw, but i pushed some more patches
20:02 imirkin_: tobijk: they're all at the "bottom" of my cts branch
20:02 tobijk: nope, i did not, will check them out
20:03 karolherbst: ohh right, I should continue to work on my cts branch as well
20:03 imirkin_: in sum it came out to https://hastebin.com/hujaretamo.hs
20:03 imirkin_: karolherbst: oh, nothing to do with cts. just ... the branch i happened to be on ;)
20:03 karolherbst: I know
20:04 karolherbst: there is that textureGrad patch still ;)
20:04 imirkin_: yeahhhh
20:04 imirkin_: gr.
20:04 imirkin_: G-R-R!
20:04 karolherbst: :D
20:04 tobijk: imirkin_: i approve the stats, yet have to look at the patches
20:05 imirkin_: pretty simple stuff.
20:06 tobijk: the ordering is interesting to say :D
20:19 tobijk: imirkin_: mh there is everything from sane to completely unstable :O
20:20 tobijk: but consider upstreaming the more sane ones (the ones you posted to the ml already)
20:21 imirkin_: that's why i said the bottom ones
20:21 imirkin_: up to https://github.com/imirkin/mesa/commit/c2c0525f4d30ac69d9c6de8190069bbd73fb12ab
20:22 tobijk: yep
20:23 tobijk: you have the r-b's for the first two from me anyway and for the last one you linked, will look at the others
21:18 tobijk: imirkin_: something like this: https://github.com/imirkin/mesa/commit/8f3628846f82ed17c46051f4e2eb7be00a2f8fee#diff-70ffabf33cc5a58af0db0774e917b125R2342 should be doable for the constrainedmoves thing for OP_STORE you had yesterday
21:19 imirkin_: that *is* the thing for that.
21:19 imirkin_: condenseSrcs() generates a merge
21:19 imirkin_: this logic directly targets that merge
21:19 tobijk: ah well allright then :)
21:21 tobijk: imirkin_: i'm happy with those patches then, just some numers for https://github.com/imirkin/mesa/commit/4ab42f524b5b946520e1fed6654c987e83bab33e would have been nice (to see if it actually makes a difference)
21:22 tobijk: i'll run it on my own
21:22 imirkin_: tobijk: it makes a big difference. i just haven't had a chance to run it separately and in order.
21:22 imirkin_: almost all those numbers need to be regenerated
21:23 tobijk: imirkin_: well they are just indicators, so having old numbers is ot that big of a problem
21:23 imirkin_: well, some of them are actively wrong
21:23 imirkin_: i.e. the load constbuf one is plain false
21:24 imirkin_: but it needs some of the earlier stuff to not suck
21:24 imirkin_: and so i ahven't redone it
21:24 imirkin_: it takes like 15 mins on my box for each run :(
21:25 imirkin_: and it'd be interesting to compare some of those with different arch's
21:25 imirkin_: like a 64-register arch
21:25 tobijk: mhm
21:26 imirkin_: where it might improve spilling
21:26 tobijk: right, its just a matter of time
21:27 tobijk: i always run it with -j 1 to have comparable results
21:28 imirkin_: why should -j make a difference?
21:28 imirkin_: in case there's some threading bug?
21:29 tobijk: imirkin_: for once, if one shader crashes it puts all others as faild out there and second, the stats file is not ordered otherwise
21:30 tobijk: both not hard to solve, yet i'm lazy :)
21:30 imirkin_: =]
22:56 tobijk: imirkin_: i was courious and ran shader-db with all your sane patches, it looks like the way to go: https://hastebin.com/ikotematab.hs
22:57 tobijk: btw, one run is ~5min for me with -j 1, so you most certainly have a -j 1 somewhere as well when running shader-db :)
22:57 imirkin_: no, it's taking up 800% of cpu
22:57 tobijk: or you have a secret stash of shaders :D
22:57 imirkin_: (8 hyperthreads)
22:57 imirkin_: i might have a secret stash.
22:57 imirkin_: gyah!
22:57 imirkin_: local went up!
22:57 imirkin_: gr
22:57 imirkin_: GRRR
22:57 karolherbst: tobijk: sometimes -x textureGather helps, because those test tend to break nouveau
22:58 karolherbst: ohhhh wait
22:58 karolherbst: shader-db, not piglit
22:58 tobijk: karolherbst: ow? i thought textureGater is broken anyway :)
22:58 karolherbst: silly me
22:58 karolherbst: who knows
23:02 karolherbst: I think I am finished with my reclocking patches
23:02 karolherbst: if somebody wants to risk it: https://github.com/karolherbst/nouveau/commits/clk_cleanup_for_real
23:02 karolherbst: please test
23:02 karolherbst: it compiles against 4.14
23:02 tobijk: karolherbst: actually i would but only have a pascal around
23:04 tobijk: not exactly right, is that targetin old ones as well? nv86?
23:05 karolherbst: well, kind of
23:05 karolherbst: it shouldn't break anything there
23:06 tobijk: karolherbst: is there auto-reclock in there as well?
23:06 karolherbst: not yet
23:06 tobijk: that'd be something to test on the old one as well
23:07 karolherbst: well right, but no
23:07 tobijk: allright
23:13 nyef``: karolherbst: I might be able to test next week, presuming that I have hardware that would benefit?
23:13 karolherbst: nyef``: kepler and newer
23:13 nyef``:hurriedly looks up codenames.
23:13 tobijk: nyef``: nveX basically
23:14 nyef``: Hrm. Okay, I have a couple of cards that would be affected, I think.
23:14 karolherbst: nyef``: there is stuff in like change clocks/voltage depending on temperature automatically, software downclock if GPU is too hot, limiting clocks when running laptop on batteries
23:14 nyef``: Oh, nice.
23:15 nyef``: Automatic upclocking?
23:15 karolherbst: not really
23:15 karolherbst: but kind of
23:15 nyef``: Ah, just downclocking?
23:15 karolherbst: it reclocks in those cases automatically
23:15 karolherbst: no
23:15 karolherbst: also upclocking
23:15 karolherbst: but not based on performance
23:15 karolherbst: it is a first good step though
23:15 imirkin_: based on what?
23:15 imirkin_: oh, just adjusting the max cstate?
23:15 karolherbst: temperature and power supply status
23:16 karolherbst: also pstate
23:16 nyef``: So you set a target cstate/pstate, and then the system tries to keep to that, within the limits of the thermal and power envelopes?
23:16 karolherbst: imirkin_: like if your vbios stats that on battery you can only do 500MHz and 0xa pstate, then with my patches Nouveau will limit the clocks whenever you remove the charger
23:17 karolherbst: and run on battery
23:17 karolherbst: and clocks back up if you plug it in again
23:18 imirkin_: that sounds nice, but should be disableable
23:18 karolherbst: in nvbios in the BASE CLOCK table it is the "max batt entry" header field
23:18 karolherbst: imirkin_: well, it only does it when you reclock in the first place
23:18 karolherbst: as long as you don't change any pstate manually, nothing will happen later on as well
23:20 karolherbst: and I am kind of optimistic about this, because we didn't reallz have any kepler/maxwell reclocking issues, except those cases where it is totally broken and even a simple write to pstate can break the system already
23:20 karolherbst: but I could add a switch like "NvAdvancedPM"
23:21 nyef``: How are we doing on Fermi and Tesla reclocking, btw?
23:21 imirkin_: meh
23:21 imirkin_: don't worry about it
23:21 imirkin_: just make it work
23:21 imirkin_: and then we can throw disable switches if needed
23:21 karolherbst: right
23:22 imirkin_: nyef``: tesla is half-good
23:22 imirkin_: fermi is half-bad
23:22 imirkin_: ;)
23:22 imirkin_: no, actually fermi is at the ... 10% mark (i.e. nothing works)
23:22 karolherbst: nyef``: rumours say that fermi memory reclocking is in a good shape on same secret computer somewhere
23:22 imirkin_: while for tesla a bunch of gpu chips work ok
23:23 karolherbst: funny that kepler workst out best allthough it is the more complicated one compared to everything before....
23:23 karolherbst: although fermi is sometimes real crazy as well
23:23 imirkin_: yeah, but skeggsb sunk a few months of work into it, followed by a lot of work from you
23:23 karolherbst: yeah
23:24 imirkin_: he has a partial tree for it, and RSpliet has a partial tree for it
23:24 karolherbst: a few days ago I talked with Lyude about how we found out the voltage thing and showed the IRC logs where we basically guessed the correct constants :D
23:25 karolherbst: (to be fair, I got pretty good values from my experiements already then)
23:25 imirkin_: yeah
23:25 imirkin_: that was pretty helpful
23:25 imirkin_: knowing the basic formula is huge
23:26 karolherbst: finding that speedo reg was also quite fun, because nvidia only reads it out once and we only knew it is inside fuse from the nvgpu code...
23:27 nyef``: Okay, so if I want fermi reclocking any time soon, I should be prepared to do a lot of digging and testing?
23:27 karolherbst: nyef``: well.....
23:27 karolherbst: basically this is what works: lower and mid range clocks
23:27 karolherbst: kind of
23:28 karolherbst: sometimes you are lucky and clocking to the highest engine clocks works as well
23:28 karolherbst: but memory reclocking is basically broken
23:28 imirkin_: nyef``: https://github.com/skeggsb/nouveau/commits/devel-clk
23:28 imirkin_: and https://github.com/RSpliet/kernel-nouveau-nv50-pm/commits/master
23:29 imirkin_: i think skeggsb has a ton more work that he's done, but unfortunately he's been reluctant to push it
23:29 imirkin_: which has also prevented RSpliet from making substantial progress
23:29 nyef``: ... more digging than I'm prepared to do this year, I think.
23:29 feaneron: what's preventim him from pushing?
23:29 imirkin_: no clue.
23:29 karolherbst: imirkin_: well he has to be kind of carefull to not push stuff which he isn't allowed to
23:30 karolherbst: kind of influenced his workflow I assume
23:30 imirkin_: dunno.
23:30 feaneron: :(
23:30 karolherbst: well I know that he can't push everything he writes code for
23:30 imirkin_: yeah, but it's not like he's getting info from nvidia about this
23:31 karolherbst: and have to be super careful to not push stuff when I work on such things, because usually I push like after every rebase....
23:31 karolherbst: imirkin_: that's why I mentioned workflow
23:31 feaneron: i'm sorry to hear that. that's a bummer
23:32 karolherbst: I think he will push it again after he thinks it is kind of stable and ready to be tested
23:32 imirkin_: well, he pushed that out in April.
23:32 karolherbst: yeah and he did more work on it afaik
23:33 imirkin_: which is why everyone else is blocked.
23:33 karolherbst: well, if somebody is indeed blocked by this, he should complain to skeggsb then
23:33 feaneron: is that because of nvidia somehow? some sort of commercial secrecy?
23:34 karolherbst: mhhh
23:34 karolherbst: not in this regard
23:34 karolherbst: but basically he has some NDA situation with nvidia, because he works for RH
23:35 feaneron: of course, there's no need to answer that (and i apologize if i'm pushing the boundaries here)
23:35 feaneron: right
23:35 karolherbst: well, we won't tell you anything we aren't allowed to anyway :p
23:36 feaneron: i know first-hand that this kind of curiosity might put people in uncomfortable situations
23:36 feaneron: anyway
23:39 feaneron: so, if i understood correctly, a purely volunteer contributor not associated with any company would have to deal with ndas?
23:39 imirkin_: not at all.
23:40 karolherbst: just if you work for a company which kind of has an NDA with nvidia
23:40 nyef``: As an example: I don't have to deal with NDAs for nouveau work, but I'm also limited in what I have time/energy/money/knowledge to work on.
23:40 karolherbst: or if you personally signed one, which you shouldn't
23:41 imirkin_: nyef``: is there a cheap 3d monitor that's available?
23:41 imirkin_: (could be as small as you want)
23:41 nyef``: I have no clue anymore? You'd probably have to get it on the used market if you want HDMI 3D.
23:42 imirkin_: and i guess preferably small.
23:42 imirkin_: like 15" would be ideal. i doubt those were ever made.
23:42 nyef``: My 3D TVs are 24 and 42 inches, respectively.
23:43 imirkin_: who made the 24"? or is that the Playstation thing?
23:43 nyef``: That's the PS3D display, yes.
23:47 imirkin_: oooh. $100 for pickup in brooklyn. that's actually maybe almost worth it.
23:48 linkmauve1: £846?!
23:48 nyef``: I have 17-inch 3D panels, but they're "3D Vision Ready", not HDMI 3D. And laptop panels anyway.
23:49 gruetzkopf: none of my laptops likes my 15" 3d panel
23:49 imirkin_: is the PS3D tv passive glasses, or what?
23:49 nyef``: imirkin_: Active glasses.
23:50 imirkin_: how are those? i've never used a 3d tv with active
23:50 nyef``: They also have a somewhat unusual mode, in that you can have them display only the left field to both eyes, or only the right field to both eyes, for multiplayer games on one display, with each player seeing something completely different.
23:51 nyef``: Umm... I tried the demo model in a Best Buy once. I've never actually used the glasses with my PS3D display. Never needed them for what I was doing.
23:51 imirkin_: hehe
23:51 imirkin_: i presume it's also useable as just a regular 1080p panel?
23:52 linkmauve1: nyef``, oh, sounds super useful!
23:52 nyef``: Yeah. HDMI and HD Component input only. Two HDMI ports. Treats NTSC composite as B&W.
23:53 imirkin_: makes sense - luma wins out
23:53 nyef``: Basically, they cheaped out on the input hardware.
23:53 nyef``: But since it was only really intended to pair to a PS3, that didn't matter so much.
23:56 nyef``: Oh! The other catch with the PS3D display as far as nouveau is concerned is that it's one of the displays that doesn't like the audio stream from a GT215/MCP89.
23:56 imirkin_: noted
23:57 imirkin_: this would be for "because 3d sounds cool", not "for playing audio" :)
23:57 nyef``: ... "3D *sounds* cool"? Umm...
23:58 imirkin_: ;)