00:08 tobijk: oh i'm back (that took its time :D)
00:08 tobijk: imirkin_: is it possible to directly have immediates for st(ores)
00:08 imirkin_: only 0
00:09 tobijk: the value 0 or zero values? :D
00:09 imirkin_: value 0
00:09 imirkin_: there's a special register for it
00:09 tobijk: so $63 or what it is
00:09 imirkin_: aka RZ (r63 on fermi/kepler1, r255 on kepler2+)
00:09 imirkin_: and any out-of-bounds register on tesla
00:10 tobijk: :o
00:10 tobijk: well, ok i leave them and use the normal registers and 63/255 :D
00:10 imirkin_: so r63 for short encoding if you're using fewer regs, or r127 otherwise
00:11 tobijk: so the compiler "should" pick up 0x0 and put r63 in there? (i cant remember)
00:11 imirkin_: yep.
00:11 imirkin_: replaceZero()
00:11 imirkin_: except a few cases where that's undesirable
00:11 imirkin_: those are few and far in between
00:12 tobijk: k
00:12 imirkin_: [like where it must be an immediate]
00:13 tobijk: imirkin_: thanks, that gives me enough to start with this compiler optimization :)
00:14 imirkin_: what's the opt
00:15 tobijk: coming from OP_STORE, intentionally killing OP_MOV
00:15 imirkin_: hm?
00:15 tobijk: imirkin_: https://hastebin.com/iganamimox.pl
00:15 tobijk: thats where i come from
00:16 imirkin_: what do you want to do about it?
00:16 tobijk: imirkin_: well for startests, propagate the immediate
00:16 imirkin_: oof
00:16 tobijk: thats a thing we can always do
00:16 imirkin_: heh
00:16 imirkin_: 108: st u64 # l[0xf0] %r627 %r627 (0)
00:16 imirkin_: let's say that was 627 and 628
00:17 imirkin_: and 627 is 0 and 628 is not
00:17 tobijk: we propagate 627
00:17 imirkin_: uh huh
00:17 imirkin_: and emit what?
00:17 imirkin_: the store only takes 1 reg
00:17 tobijk: 0x0?
00:17 imirkin_: those 2 have to be adjacent regs
00:17 tobijk: look at the register allocated part
00:18 imirkin_: which means you'll end up right back at the mov
00:18 tobijk: parts
00:18 imirkin_: i think a better strategy would be to avoid merging stores where you're storing a 0
00:18 tobijk: yeah well, you are right
00:18 imirkin_: coz then the propagation would make sense.
00:18 tobijk: the elimiate the mov is "for starters"
00:19 imirkin_: my point is that it won't get eliminated
00:19 imirkin_: since the RA will add it right back in
00:19 tobijk: 120: mov u32 $r2 0x00000000 (8) <-- that one we can eliminate
00:19 imirkin_: heh, actually that's the one that'll come back ;)
00:19 tobijk: :/
00:19 imirkin_: try it if you don't believe me.
00:19 tobijk: *sad*
00:20 imirkin_: since you'll have a merge of 0x0 and some reg
00:20 imirkin_: and it'll insert constraint moves
00:20 imirkin_: this is a pretty vexing problem more generally
00:20 imirkin_: the reason that it hasn't been solved isn't that we're just lazy bums
00:21 tobijk: yeah thats the second thing: only inser the constained ld if we have a value != 0x0
00:21 tobijk: 121: ld u64 { %r665 %r668 } l[%r664+0xf0] (0) <-- this is bogus imho
00:21 imirkin_: why?
00:21 tobijk: if 0xf0 is 0x0 we can just omit it, no?
00:22 imirkin_: only if %r664 == 0
00:22 imirkin_: it's an index into a temp array
00:22 imirkin_: some of the temp array elements are 0
00:22 imirkin_: others aren't
00:23 tobijk: mh but 0xf0 stays 0, so it should not be a problem *in this case*
00:23 imirkin_: what does 0xf0 have to do with it?
00:23 tobijk: maybe i'm looking to much at this special shader :D
00:23 imirkin_: here's what this code looks like in C
00:24 imirkin_: int foo[10] = {0}; stuff; foo[i];
00:24 imirkin_: 0xf0 == &foo[0]
00:25 imirkin_: now, it looks like the jerks that wrote this shader omitted "stuff", so one could know that foo[i] is zero no matter what.
00:25 imirkin_: but we're not smart enough to work that out.
00:25 tobijk: ? isnt %r664 foo?
00:25 imirkin_: %r664 is "i"
00:25 tobijk: if somethnig makes sense is that 0xf0 is the array indey`
00:25 imirkin_: 0xf0 is the base of the array
00:26 tobijk: ah ups
00:26 imirkin_: (which is constant)
00:26 tobijk: ok, i'm conviced
00:26 imirkin_: while %r664 is the index into the array, which is variable
00:28 tobijk: ok, so just save line 120 by checking for 0x0 and use r63 or what it is
00:28 imirkin_: i'd avoid the store merges
00:28 tobijk: not as much as i hoped, but well
00:28 imirkin_: that way every store can just be a store of $t63
00:28 imirkin_: $r63 that is
00:29 imirkin_: which gets rid of all those dumb movs
00:29 tobijk: yep
00:29 imirkin_: note that stores are slow though
00:29 imirkin_: so overall it should be an insignificant win
00:29 imirkin_: [for this shader]
00:29 tobijk: right
00:30 tobijk: that one looks like a especially bad one
00:30 imirkin_: the bigger win would be to notice that all that code is pointless
00:30 imirkin_: but perhaps it becomes point-ful later
00:30 imirkin_: can i see the TGSI for this shader?
00:30 tobijk: yep,
00:30 tobijk: sec
00:31 tobijk: imirkin_: https://hastebin.com/egoceludoz.md
00:32 tobijk: imirkin_: actually when compiled 0x100 - 0x148 arent touched anymore
00:32 imirkin_: w.t.f.
00:32 tobijk: but i havent looked where the are getting used
00:32 imirkin_: https://hastebin.com/ladoyozoru.css -- all those immediates are 0's
00:33 tobijk: imirkin_: yep
00:33 imirkin_: do you have the glsl?
00:33 tobijk: imirkin_: Civilization 6 is wonderful, isnt it?!
00:33 tobijk: mom
00:33 imirkin_: this would be worth detecting as an idiotic thing.
00:34 imirkin_: "indirect load from an array full of identical values"
00:34 tobijk: imirkin_: do you have the nouveau shader db around or should i pastebin it?
00:34 imirkin_: pastebin it
00:35 tobijk: imirkin_: https://hastebin.com/atoyilocow.cs
00:35 imirkin_: ohhhh
00:35 imirkin_: lol
00:35 imirkin_: ok
00:35 imirkin_: this is just lost in translation
00:35 imirkin_: they're not all 0's
00:35 imirkin_: they're actually various values
00:35 imirkin_: however the tgsi encoding doesn't properly pass float immediates along
00:35 imirkin_: so you think they're 0's
00:35 imirkin_: but they're not
00:36 imirkin_: (look at x3)
00:36 imirkin_: ok, that makes a lot more sense.
00:36 tobijk: jep, i see it now (have only looked at the tgsi)
00:37 imirkin_: vec4 texelFetch_rect_as_buffer(sampler2DRect s, int P) {return texelFetch(s, ivec2(P % 4096, P / 4096));}
00:37 imirkin_: urgh
00:37 imirkin_: COME ON GUYS!
00:37 imirkin_: you really can't do it as uints??
00:37 imirkin_: with signed int, we can't do bit shifts!
00:38 tobijk: imirkin_: btw, that is the shader nouveau fails to compile :D
00:38 tobijk: as we run out of registers
00:38 imirkin_: yeah
00:38 imirkin_: makes sense
00:39 imirkin_: it's got 24 output registers
00:39 imirkin_: tobijk: fix up the tgsi to make it more realistic
00:39 imirkin_: instead of
00:39 imirkin_: IMM[5] FLT32 { 0.0000, 0.0000, 0.0000, 0.0000}
00:39 tobijk: mhm
00:40 imirkin_: do IMM[5] INT32 { 0x19, 0xf, 0x5, 0 }
00:40 imirkin_: etc
00:40 tobijk: so to be precise, is it nouveaus fault or actually the TGSI translate? (if you happen to know)
00:41 imirkin_: no one's fault
00:41 imirkin_: it's the tgsi text printer, but it has a mode to not lose data like this
00:42 airlied: you can ask it do dump float azhe
00:42 airlied: as hex
00:43 imirkin_: yea
00:43 imirkin_: i don't remember what you called it though
00:56 imirkin_: tobijk: your issue will be fixed if we implement signed int32 MOD lowering for power-of-two values
00:58 imirkin_: i think it's solvable by taking the absolute value, doing the and, then adding then negating
00:58 tobijk: imirkin_: i'm not so much for fixing the issue (well thats always good), but for sidetracking me a bit for a while :D
00:58 imirkin_: that works for everything except MIN_INT i think
00:58 imirkin_: however since we know it's a power of two, MIN_INT % power of 2 = 0
00:59 Manoa: you know what guys ?! I hate this: games broken and you have to fix them
00:59 imirkin_: so actually it'll work out too
00:59 tobijk: :)
01:00 imirkin_: (assuming that cvt abs returns MIN_INT for MIN_INT)
01:00 tobijk: imirkin_: heh not sure about cvt :)
01:00 imirkin_: what else would it return?
01:00 tobijk: did we end up converting all possible?
01:01 tobijk: i only rember it a bit "patchwork"
01:01 tobijk: maybe it changed
01:01 imirkin_: yea
01:01 imirkin_: but i mean
01:01 imirkin_: the hw
01:01 imirkin_: since it's not an imm
01:02 tobijk: ah right, so yup
01:02 tobijk: did you solve the 0* inf thing btw?
01:02 imirkin_: define 'solve'
01:03 tobijk: if solving is the right term here
01:03 imirkin_: it was never a problem
01:03 tobijk: more a define :D
01:03 imirkin_: i just made what we did match nvidia blo
01:03 imirkin_: nah...
01:03 imirkin_: i think it's at least partly an opt
01:03 tobijk: so you go with the nvidia behavior?
01:03 imirkin_: yep
01:04 tobijk: k, thats enough info
01:04 tobijk: i have that context :)
01:06 imirkin_: so let's see... mod(a,b) where b is a pow of 2 becomes ... t = abs(a); s = a & 0x80000000; r = t & bits; return s ? -r : r;
01:07 imirkin_: for MIN_INT (i.e. 0x80000000), r becomes 0.
01:07 imirkin_: seems reasonable.
01:09 Tanriol: imirkin_, I've tried to make a patch myself and with https://pastebin.com/R58VFrM1 the audio function does appear. However, something seems wrong with it - no sound and pulseaudio hangs starting. Will try to look at them tomorrow in more detail.
01:10 imirkin_: mmmmm
01:10 imirkin_: that dev->multifunction = 1 might be a bit aggressive
01:10 imirkin_: i wonder if there's something else required
01:11 imirkin_: Tanriol: however could be a much more pedestrian issue
01:11 imirkin_: Tanriol: check if ELD makes it through, etc
01:20 Aristar: hmm, anyone know offhand of any issues __GL_YIELD=USLEEP ? not sure it's even used if Option "SwapLimit" "2" is set, though still getting tearing
01:21 Aristar: default is apparently sched_yield()
01:22 Aristar: i know really old nvidia binary drivers used to work better with __GL_YIELD=NOTING but supposedly lately USLEEP is better, but not sure with nouveau
01:23 Aristar: NOTHING*
01:24 Aristar: guess i'll find out, though if anyone has some insight into nouveau's behavior regarding this, it'd be appreciated
01:37 tobijk: imirkin_: oh i didnt look anymore...
01:37 tobijk: soory for that
01:37 tobijk: *sorry
01:37 tobijk: i should go to bed :)
01:47 imirkin: Aristar: __GL_YIELD is a nvidia blob thing
01:58 Aristar: Ah okay, thanks. that helps
01:58 Aristar: wasnt sure if it was or not
02:01 Aristar: i'm guessing __GL_SYNC_TO_VBLANK is also
02:02 imirkin: yep
02:03 Aristar: looks like this is too __GL_SYNC_DISPLAY_DEVICE=foo
02:03 Aristar: thanks
02:04 imirkin: oh nice! "Results are undefined if one or both operands are negative"
02:04 imirkin: (for glsl % operator)
02:10 Aristar: also FWIW, regarding DPI with nouveau - if it's improperly detected and becomes defaulted to 96x96, it seems the only way to set DPI is to add it to the xserver command line arguments, usually via a display manager configuration "-dpi 108" for example
02:10 Aristar: not sure when "DisplaySize" and "DPI" under Screen->Monitor sections stopped working but it seemingly ignores them
02:11 Aristar: and Driver section has no DPI or EDID ignoring options with nouveau evidently (tried a bunch)
02:11 imirkin: yeah i dunno. i think that's a general X thing, nto nouveau-specific
02:11 imirkin: i could be wrong
02:11 Aristar: well nouveau should be passing along what it detects i tihnk
02:11 Aristar: like the displaysize in mm, which the xserver uses to calculate dpi
02:12 Aristar: and if it's invalid it defaults to 96
02:12 Aristar: and for some reason EDID probing doesn't work here, falls back to DDC which gets a weird number for displaysize
02:15 Aristar: or perhaps the xserver does the edid probing and it that fails it asks the driver for DDC info
02:16 Aristar: or maybe the other wya around
02:22 imirkin: X server is what handles all this, not nouveau.
02:22 imirkin: anyways, you can blame whatever you like - fine by me tbh
03:12 imirkin: tobijk: try the modulo patches i sent - should fix your civ6 shader right up
03:46 Aristar: imirkin: idk maybe the xserver is incorrectly marking nouveau as the culprit then?
03:47 Aristar: such as:
03:47 Aristar: (WW) NOUVEAU(0): Output LVDS-1: Strange aspect ratio (304/19000), consider adding a quirk
03:48 Aristar: and and oddly enough if the xserver is launched with -dpi 108 it now says tihs
03:48 Aristar: (++) NOUVEAU(0): DPI set to (108, 108)
03:48 Aristar: instead of 96x96 nomatter the xorg.conf settings
03:49 Aristar: strange, not sure what is to blame but maybe i'll track it down when i have some motivation
03:49 Aristar: hasn't caused issued yet now that i found a workaround
03:51 Aristar: also nouveau is flagged as the one setting screen sze (in mm) which it seems to be getting from whatever DPI is being set, so if it's default 96x96 it ends up being wrong, but if launched with -dpi 108 it gives tihs:
03:51 Aristar: (II) NOUVEAU(0): Setting screen physical size to 301 x 188
03:51 Aristar: (which is the correct screen size for this panel)
03:54 Aristar: (this is on latest release(s) of xorg, mesa, libdrm, and latest kernel)
03:55 Aristar: (but i believe it's always incorrectly detected the screensize on older ones as well)
03:55 Aristar: or X did, whoever is doing it
03:55 Aristar: but with binary driver installed the screen size is set to the correct mm x mm and dpi
03:56 Aristar: just saying that's why i'm led to believe it's something in nouveau is all, sorry
04:29 imirkin: jolar2: https://people.freedesktop.org/~imirkin/patches/0001-drmmode-update-logic-for-dynamic-connectors-paths-an.patch
04:32 imirkin: very light testing on my end... with limited hw. seems to not be totally broken... maybe
10:01 ylwghst: Hello.
10:04 ylwghst: How could be Gnome3 fast and smooth on ubuntu but sluggish on other distros?
10:08 ylwghst: I experience very slow desktop effects and sluggish web browser smooth-scrollin propably due to vsync configuration.
10:09 ylwghst: While in ubuntu 17.10 with same drivers are these problems gone.
10:11 airlied: you sure ubuntu hasnt the nvidia driver?
10:11 ylwghst: airlied: sure
10:13 airlied: but if x logs and glxinfo are the same, then not sure what
10:13 ylwghst: nor me
10:15 ylwghst: i do thinkg its propably due to vsync configuration or something with it
10:16 airlied: maybe if vsync was broken, what other diztro?
10:18 ylwghst: I use NixOS which i prefer, but I have tried others too and the problem is same. Gnome3 was completely unusable on openSuse the desktop environment was too sluggish, i tried glmark with same result in all distros.
10:19 ylwghst: both ubuntu and openSUSE has gnome 3.26 already
10:25 ylwghst: Can I somehow improve or change the vsync on nouveau?
10:26 airlied: i doubt you have enough info to say it has anything to do qith vsync
10:26 josef_: imirkin: Wow, did you stay up all night? :P Will test in a couple of hours.
10:27 airlied: you could maybe use perf or sysprof to record activity when slow
10:27 airlied: ylwghst: so nixos had same kernel?
10:27 ylwghst: airlied: same kernel I use
10:29 airlied: sluggish souns like cpu rendering
10:30 airlied: perf would tell, or try a fedora live image
10:31 ylwghst: I have tried fedora too, exactly same experience
10:32 airlied: did you check if any distrobwas using wayland
10:32 ylwghst: ubuntu is on wayland, fedora too, opensuse too
10:34 ylwghst: it lags only if i move windows or scroll web pages
10:34 ylwghst: but not on ubuntu hehe
10:36 ylwghst: brb
10:48 ylwghst: which configuration files should I export to compare it?
10:49 airlied: ylwghst: there really isnt any hence why its confusing
10:54 airlied:zzz
13:09 tarragon:checks 4.13.12 for nouveu fixes
13:33 tarragon: possible explanation for CPU usage difference between xterm and tmux with fast terminal output.
13:51 tarragon: tmux uses ncurses with is thread optimized.
13:51 tarragon: never mind, xterm also uses ncurses
14:16 mupuf: Summary: 442359 results, 440507 pass (99.58%), 1852 fail (0.4%) <-- getting somewhere with my "safe" model
14:16 karolherbst: mupuf: nice!
14:16 karolherbst: this looks really good now
14:16 mupuf: I will now make an histogram showing how much I overestimate
14:16 mupuf: if it is mostly off by ones or bigger amounts
14:17 mupuf: the errors I now get are just *way* above what I compute
14:17 mupuf: so there is something I am missing out...
14:17 mupuf: more non-linear behaviours
14:19 josef_: imirkin: I just tried your patch. It does not make anything worse. And it might be the case that it helps in recognizing the external display (after undocking and docking for 3 times, the external display was found and got an X screen automatically).
14:20 josef_: imirkin: I was however thrown out into the gdm login screen when undocking just as last time
14:20 josef_: imirkin: I think have some interesting dmesg output though!
14:22 josef_: imirkin: https://pastebin.com/SqyVWvcg
14:22 josef_: first thing is [ 140.449733] WARNING: CPU: 0 PID: 6305 at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nouveau_dp_detect+0x77/0x300 [nouveau]
14:23 josef_: secondly, this is new for me [ 190.019961] [drm:drm_wait_vblank_ioctl] *ERROR* Unsupported type value 0x4f, supported mask 0x7400003f
14:24 josef_: this is all done with 4.14-rc8
14:30 pmoreau: Not sure what went south, but it did:
14:30 pmoreau: (gdb) p q->pipe->create_compute_state
14:30 pmoreau: $3 = (void *(*)(pipe_context *, const pipe_compute_state *)) 0x7fffebca701a <nvc0_video_buffer_create>
14:31 pmoreau: “Create a compute state” -> “OK, how about I allocate a video buffer for you?” --"
14:33 pmoreau: (This is after re-basing my work on top of the latest master.)
14:37 pmoreau: Hum, create_video_buffer == nvc0_create_decoder and create_video_codec == nullptr: seems to be an off-by one, but why?
14:41 pmoreau: The mismatch starts at “set_shader_images”: https://hastebin.com/heqetoviva.go
14:49 pmoreau: Hum, cca5617348a added “set_hw_atomic_buffers” before “set_shader_images”, but why doesn’t it appear?
14:52 pmoreau: I’ll blame the build system for not properly rebuilding stuff, and do a clean + rebuild to see whether that fixes it.
14:53 imirkin: pmoreau: just clean and move on with life
14:53 imirkin: it happens sometimes
14:53 imirkin: some change doesn't get picked up
14:54 imirkin: josef_: bleh. that's not my patch's fault... i think that's in the MST processing =/
14:55 imirkin: josef_: can you check if connectors get added / removed from xrandr?
14:55 imirkin: er, probably just added - i don't think they ever get removed
14:55 imirkin: tobijk: give those mod patches i sent a shot
14:56 pmoreau: Hum, distclean + rebuild wasn’t enough. Trying one more time
14:56 imirkin: what's distclean?
14:56 imirkin: you can do a git clean
14:56 imirkin: although be careful with that
14:56 imirkin: since it'll delete stuff :)
14:56 pmoreau: :-D
14:56 josef_: imirkin: hmm what's the best to test this? start the laptop when it is not in the docking station, start x, run xrandr --setprovideroffloadsink nouveau Intel and then finally dock it and see if new displays appear?
14:57 imirkin: josef_: i guess yeah
14:57 josef_: I think that would be the ultimate test since the only way I could access those displays before was from booting the laptop in the docking station
14:57 josef_: ok
14:58 imirkin: josef_: unfortunately there's multiple potential levels of fail
14:58 imirkin: what i did was process the information that nouveau provides about the new connectors
14:59 imirkin: however if those connectors aren't being detected by nouveau, nothing this patch does will help that
14:59 josef_: imirkin: well there seems to be a kernel (nouveau module) issue again
15:00 josef_: at least stuff is better for me than it was last week without the patch we came up with
15:00 josef_: :)
15:00 pmoreau: imirkin: “Delete all files in the current directory (or created by this makefile) that are created by configuring or building the program” according gnu.org.
15:01 imirkin: pmoreau: yeah i wouldn't rely on that working :)
15:01 pmoreau: It has been working so far.
15:01 imirkin: hm ok
15:02 imirkin: well, dunno then.
15:02 imirkin: perhaps the build is failing and you keep using the old thing?
15:02 pmoreau: It could be due to an old libOpenCL.so leaving in my install dir (old, as in a few hours old)
15:02 karolherbst: pmoreau: sometimes you just need to clean the entire build directory
15:02 karolherbst: I had the same issue with some silly spirv header file
15:02 pmoreau: s/leaving/living
15:02 karolherbst: and with clean I mean rm
15:03 josef_: imirkin: the ultimate test succeeded!
15:03 imirkin: woohoo!
15:03 imirkin: so now it's working as well as xf86-video-modesetting presumably
15:03 josef_: you just improved the situation even more
15:04 josef_: does xf86-video-modesetting use this same drm*.c file?
15:04 imirkin: similar.
15:04 imirkin: that's where i copied the code from ;)
15:04 josef_: this is nice stuff
15:04 ylwghst: so it has definitely something to do with cpu usage
15:05 josef_: one thing though.. I think I got a compiler warning
15:05 josef_: hold on
15:05 imirkin: it was there before :)
15:05 josef_: this one ‘xf86_reload_cursors’ is deprecated [-Wdeprecated-declarations]
15:06 imirkin: yep
15:06 josef_: pok
15:06 josef_: ok
15:06 josef_: well, very nice
15:06 imirkin: i'm gonna have to add a thousand #if's to make sure this compiles with older X servers..
15:06 ylwghst: airlied: ^^
15:07 josef_: imirkin: ok so this "new" error is reproducible I think
15:08 josef_: if I undock with an external display connected, I am thrown out to gdm login screen and get that kernel warning
15:08 ylwghst: i ve tried fedora with almost same set up and it was unusable. Firefox was eating 90% CPU only for file download
15:08 imirkin: josef_: can you check the xorg log?
15:08 imirkin: it means X crashed
15:08 imirkin: probably some case i don't handle
15:09 josef_: ok
15:09 josef_: after this has happened, I cannot dock again and get the external display to work
15:10 josef_: I'll upload the xorg.0.log
15:10 josef_: imirkin: https://pastebin.com/UZGJRA4a
15:13 josef_: imirkin: I do not think this is a cause of your patch though
15:13 josef_: imirkin: X crashed like this before your patch with only my patch
15:14 josef_: imirkin: I am also not sure if this really is something to be handle by DDX code since there is this kernel warning in dmesg?
15:28 josef_: ok so after ret = nvkm_i2c_aux_xfer(aux, true, 9, addr, data, &size); in nvkm_rdaux
15:28 josef_: WARN_ON(!ret && size != xfer); is triggered
16:23 imirkin: josef_: that xorg log indicates you're using modesetting, not nouveau
16:23 imirkin: note "modeset(G0)" vs "NOUVEAU(G0)"
16:53 josef_: imirkin: then i am sending you the wrong log or something
16:54 josef_: imirkin: I am using reverse PRIME
16:57 josef_: imirkin: let me try to reproduce and see what I get
17:00 mupuf: imirkin, karolherbst: http://fs.mupuf.org/nvidia/fan_calib/safe_model_error_0.svg. http://fs.mupuf.org/nvidia/fan_calib/safe_model_error_100.svg, http://fs.mupuf.org/nvidia/fan_calib/safe_model_error_all.svg <-- that's from my safe model which is overestimating the duty
17:03 josef_: imirkin: hmm I think the log is indeed correct, and this is the setup I am actually using for my hybrid grapics
17:03 josef_: graphics*
17:03 josef_: imirkin: but as I said I use reverse prime with the nouveau provider
17:04 karolherbst: mupuf: well, looks good enough
17:04 karolherbst: mupuf: how high is the biggest error?
17:04 mupuf: karolherbst: the graph shows it to you, 100%
17:04 karolherbst: ohh, right
17:04 mupuf: but this is in useless cases (where the max speed would be 0%)
17:05 karolherbst: yeah, I meant more like in absolute values
17:05 karolherbst: well absolute is the wrong term as well
17:05 josef_: imirkin: ahhh the log is overwritten
17:05 josef_: imirkin: hold on
17:05 karolherbst: mupuf: well, what I meant is like when the fan should be driven at 50% how many X% points are we off at most?
17:06 mupuf: 50 % :D
17:06 karolherbst: allthough in the 100% graph there also seems to be a 100% one?
17:06 karolherbst: mhh yeah
17:06 karolherbst: sad
17:06 mupuf: but this is very unlikely
17:06 mupuf: these are all edge cases
17:06 karolherbst: yeah...
17:06 mupuf: I should probably not even show them on the graph
17:06 karolherbst: but those are the interesting errors
17:06 josef_: imirkin: before undocking https://pastebin.com/dtUpDZY0
17:06 karolherbst: no, those are the most important ones
17:07 mupuf: I have only 21 failures out of 6k samples
17:07 josef_: imirkin: (with TV connected through docking station)
17:07 karolherbst: because if you get those edges right, then it is fine
17:07 karolherbst: mupuf: yeah right, but then somebody hits the 100% case where we do 0%
17:07 karolherbst: that's bad
17:07 mupuf: nope, you got it wrong
17:07 mupuf: I am always overestimating
17:07 mupuf: and thre graph shows by how much
17:07 mupuf: which is... up to 100%
17:07 josef_: imirkin: after undocking https://pastebin.com/7WFArnXc
17:07 karolherbst: mupuf: ahh so it is the other way around?
17:08 mupuf: nope
17:08 mupuf: and to get 100% error, it means that i set the fan speed to max when nvidia sets it to 0%
17:08 karolherbst: that's what I meant with the last sentence
17:08 mupuf: as I said, edge case which is irrelevant
17:08 karolherbst: but you hit this, right?
17:09 josef_: imirkin: this makes sense since I cannot do reverse PRIME after X has crashed and reloaded (nouveau is not there as a provider anymore)
17:09 mupuf: karolherbst: I don;t undersrtand what you mean
17:10 josef_: imirkin: the sad part is... there is nothing about the actual crash in the Xorg log
17:10 karolherbst: mupuf: I mean, you hit cases where we should do 0% where we do 100%. Which is not a problem for now though
17:11 karolherbst: I am interested in cases where your model producing lower values than nvidia does, but it seems like there are none anymore?
17:11 mupuf: there still are a couple of them... but they really make 0 sense
17:11 mupuf: I checked them all
17:11 karolherbst: mhhhh
17:12 mupuf: but it does not matter much, they are for random values that make no sense
17:12 karolherbst: what would nouveau master do in those cases?
17:13 mupuf: produce a lower fan speed than expected
17:14 karolherbst: compared to your new model
17:14 mupuf: ah! sorry
17:14 mupuf: right now, it would spin the fan all the time at 100%
17:15 mupuf: so, with my model, the fan my spin too slowly at first, but then auto fan management will increase it anyway
17:15 mupuf: so... we are somewhat safe anyway
17:15 mupuf: I always compute the 100% value right :)
17:16 karolherbst: well, I am more concered about situations where we would use lower fan speeds
17:17 mupuf: yes, they exist
17:17 mupuf: but they are not dramatic as long as the 100% value is right
17:18 mupuf: I will ask nvidia for a proper model
17:18 karolherbst: mhhh
17:18 mupuf: but... until then, we will have this
17:18 karolherbst: are we hitting the 100% case anyhow on every card?
17:18 karolherbst: Because currently I know a lot cards where we don't go up to 100%
17:19 tobijk: imirkin: when did you send those mod patches? i do not have those in my inbox
17:20 tobijk: oh never mind
17:20 tobijk: found em
17:21 tobijk: i will look at them tonight, gtg again
17:22 karolherbst: mupuf: but well, if your model is much better overall than what nouveau currently does, then I am all for it
17:34 josef_: regarding the WARN_ON at drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 - any idea how to handle it?
19:19 tarragon: no fixes further than 4.13.9
21:56 josef_: karolherbst: Could you try to undock the P50 at the office while using external monitors through the docking station (reverse PRIME)? It would be interesting to see if your X crashes as well. Other than that things are working pretty sweet with imirkin's hotplug patch :) (i.e. almost usable for me at my office)
21:56 karolherbst: josef_: not until wednesday
21:57 josef_: no hurry, I will be on a business trip for 2 weeks starting wednesday so I will not be needing the docking station, but it would be nice to resolve it once and for all
21:57 josef_: it is like 90 % done now