00:00 rhyskidd: karolherbst: was the volta vbios recently added to nvidia_bios repo from a non-nouveau source?
00:01 rhyskidd: i'm aware of the different sources, but dropped the first 2560-ish bytes header on other volta vbios'es - which i believe fixes "vbios"es that you can find on techpowerup and other places
00:01 nyef: ... Why is HPD even enabled for eDP connectors?
00:02 skeggsb: nyef: because DP (ab)uses is to signal stuff like link loss
00:02 nyef: Ah, okay.
00:06 karolherbst: rhyskidd: that's not enough
00:06 skeggsb: Lyude: i think i know what might be happening for the timeout part
00:06 Lyude: skeggsb: hm?
00:06 karolherbst: rhyskidd: or maybe it is enough for those, dunno
00:06 skeggsb: Lyude: i'll get you a patch shortly
00:06 Lyude: oh sweet, do you still need me to bisect it btw?
00:07 skeggsb: nah
00:07 skeggsb: i can only see one way things can possibly happen like they are
00:12 nyef: Current progress: The eDP panel is now less flickery on resume, and is clearly powered up... But it's still blank.
00:15 rhyskidd: karolherbst: ok
00:21 nyef: ... during resume, it tries to link-train the (unpowered?) panel, and fails. Then, shortly post-resume it gets an HPD and enables aux power, but doesn't try to link-train?
00:28 nyef: When does that link retrain happen during the resume cycle?
00:28 nyef: Is it during the nvif_client_resume() or at some point later?
00:35 skeggsb: Lyude: https://paste.fedoraproject.org/paste/DN8p1KuPtaphcNZ53BE4dg
00:35 skeggsb: give that a try
00:36 Lyude: skeggsb: sec
00:36 skeggsb: nyef: it'll happen during the first modeset
00:37 skeggsb: i think
00:38 skeggsb: there *is* a PANEL_POWER GPIO that we toggle in a potentially weird place (panel detection)
00:38 nyef: Yeah, but that place only triggers on the initial walk of connectors during startup, or from an HPD IRQ.
00:40 nyef: I'm trying to smack it during resume (to wake the panel back up), and during suspend (because otherwise it stays *on* until the GPIOs are resumed at which point it gets shut off because default).
00:42 nyef: If it doesn't get turned off during suspend, the panel flickers obnoxiously for a bit on resume. And if it doesn't get turned on again at some point, there's no internal display anymore.
00:42 skeggsb: i'm somewhat surprised it matters for suspend... one would expect power would get cut regardless
00:43 nyef: Power probably *does* get cut. But on wakeup, it gets restored, and then cut *again* because of the GPIO resume resetting the pin to default (off).
00:44 nyef: Hence obnoxious flickering.
00:44 skeggsb: what exactly is doing this "restoring"
00:44 skeggsb: we certainly don't
00:45 nyef: Some bit of chip state persistent across suspend, maybe?
00:46 nyef: I'm somewhat guessing here, but I know that the GPIO resume code shuts the pin off, and if the pin is already shut off at suspend time then the display doesn't flicker on resume, but if the pin is still on at suspend time then it does flicker.
00:48 skeggsb: nyef: i don't like this exactly, but it should do what you're trying to achieve and see if things are any better
00:48 skeggsb: https://paste.fedoraproject.org/paste/z2DsomCHBJl4cQAeK6EFoA
00:49 nyef: Thank you.
00:50 nyef: And I agree, that's a fairly horrible way to do it, but probably the right PLACE to do it...
00:50 skeggsb: it's the place i don't necessarily agree with ;)
00:50 skeggsb: it shouldn't be where it is either though
00:51 nyef: What I was thinking was that we might need to have an NVIF interface for "connector panel power" or something, associated to the connector.
00:51 Lyude: skeggsb: Tested-By: Lyude Paul <lyude@redhat.com>
00:51 skeggsb: Lyude: i might be wrong, but i think it should solve the oops too
00:52 marcheu: shouldn't you do the notify_get first so you don't miss HPDs... :)
00:54 skeggsb: marcheu: quite possibly
00:56 nyef: And I was thinking "shouldn't you do the notify_put first so you don't get stray HPDs?" (-:
00:56 skeggsb: Lyude: btw, the whole reason for that outp->flush_disable case is because the mst manager seemed to fuck up when disabling multiple mst streams at the same time... is that still the case?
01:03 nyef: Hrm. No improvement... Might be the HPD thing, or I could "just" be missing something fundamental.
01:12 nyef: Umm... Are we supposed to be doing link training with aux power set as "demand" (instead of "always")?
01:14 skeggsb: nyef: can you show me the log?
01:18 nyef: https://paste.fedoraproject.org/paste/V0QMc0gQDtXErfMOI-SeYw
01:21 skeggsb: nyef: your panel doesn't respond when we check, so we assume it's not there
01:22 nyef: This would be the link training failure?
01:22 skeggsb: no, before then, but both are probably caused by the same thing
01:23 nyef: The outp toggle of aux power at 166.146955 ?
01:24 skeggsb: yes, if you had i2c=debug too, you'd see an aux transaction between those two lines
01:26 nyef: Okay, I think that gives me more to work with. Thank you.
01:33 skeggsb: nyef: here's another hack that's definitely not correct, but if it works, i'll think of something else
01:33 skeggsb: https://paste.fedoraproject.org/paste/qRgNul1zGeXyplQI~nehwg
01:35 nyef: Do we actually use DPCD_SC00_SET_POWER_D0 or equivalent anywhere?
01:36 skeggsb: yes, we check it before link training
01:36 skeggsb: it's also used in dpms handling, which is why doing it unconditionally here isn't right
01:36 skeggsb: i have ideas for what to do here instead, but i want to see if this works first
01:37 skeggsb: i've seen sinks that won't respond to a dpcd read without it, i think there's a hack in the atomic code for a dell monitor i have actually
01:38 skeggsb: yeah, there is
01:38 skeggsb: oh, no, that's something else. nevermind :P
01:38 nyef: Ah, I see the logic here, I think. Patching it in now.
01:43 nyef: On further review, this is feeling unlikely, but still worth trying.
01:45 nyef: Which resumes first, the conn or the outp/dp ?
01:45 skeggsb: connector
01:46 nyef: Okay, yeah. I see that now. Hunh.
01:47 nyef: Oops. Should've passed a nouveau.debug, shouldn't I?
01:49 nyef: Yeah, no go.
01:55 skeggsb: got a new log?
01:58 nyef: "sink not detected", for both transactions post-resume.
01:59 nyef: At which point, the panel is registered as not being there.
02:00 nyef: Hrm...
02:04 nyef: "disp: init running..." is at 107.253757, the dp detect starts at 107.564972, training starts at 107.678142, training is registered as failing at 107.680256, an HPD for the panel lands at 107.793045.
02:05 nyef: What if the power-on delay from that GPIO just isn't long enough?
02:06 nyef: That's more than half a second from starting to resume disp to logging an HPD from the panel.
02:08 skeggsb: sounds easy enough to check ;)
02:10 imirkin: karolherbst: i haven't really been following irc... if you need help with specific stuff, shoot me an email
02:12 nyef: Looks like 700 ms might be sufficient, but bumping to 1000, just in case.
02:20 nyef:makes a note: "huge success"
02:20 karolherbst: imirkin: main thing is currently fixing those MS issues when doing glGetPixels
02:20 karolherbst: uhm
02:20 karolherbst: glReadPixels
02:21 karolherbst: I think you said something about resolving doesn't work correctly or something like that a year ago
02:21 imirkin: correct.
02:21 imirkin: we're supposed to resolve. we don't.
02:21 karolherbst: yes
02:21 karolherbst: and I am sure the CTS test fails because of that
02:21 imirkin: if the test is doing glReadPixels on a MS winsys fb, then yes.
02:22 imirkin: iirc it's illegal to do glReadPixels on a non-winsys MS fb
02:23 karolherbst: imirkin: https://github.com/karolherbst/piglit/commit/2531195b612bc2bc268d4cde4589c3819c25e8d7
02:23 karolherbst: this is what the test is doing basically
02:23 karolherbst: well pretty much exactly this, I just extracted that failing case
02:25 karolherbst: allthough maybe in this case the resolve thing isn't really the issue
02:25 karolherbst: or not at glreadpixels time
02:27 karolherbst: but it blits, so I guess in the end it ends up kind of with the same code path
02:29 nyef: Hrm. This extended delay thing has implications for the corresponding delay in nouveau_connector_ddc_detect().
02:30 imirkin: karolherbst: it never readpixel's from winsys fbo
02:30 imirkin: so it's unrelated.
02:30 karolherbst: okay
02:31 imirkin: er ... hm
02:31 imirkin: interesting.
02:31 imirkin: oh.
02:32 imirkin: glRenderbufferStorageMultisample(GL_RENDERBUFFER, 0, GL_RGBA8, TEX_SIZE, TEX_SIZE);
02:32 imirkin: 0 samples.
02:32 imirkin: fbo[2] is not multisampled
02:32 imirkin: that's why glReadPixels works on it
02:32 karolherbst: yeah
02:33 skeggsb: nyef: well, the one in ddc detect would be removed completely, it has no point if we move it where i did
02:33 nyef: Okay, that seems plausible.
02:34 karolherbst: imirkin: but sadly I am not exactly sure where the first bug occurs, so I kind of thought fixing those piglit tests might actually also help with that fail
02:34 imirkin: sure.
02:34 nyef: Although... if there isn't an eDP panel, we should probably maintain the GPIO in an "off" state (unless there's some other reason for it to be on).
02:35 skeggsb: yeah, it's tricky. probably turn on, wait, check if hpd is asserted, turn off again if not
02:36 nyef: Right.
02:36 imirkin: karolherbst: gonna spend like 10 mins looking at it, see if anything pops out
02:40 imirkin: karolherbst: interesting. passes on nv50.
02:40 imirkin: always a good sign....
02:40 karolherbst: \o/
02:40 imirkin: so it's something dumb
02:41 karolherbst: and most likely somewhere inside the blitter setup code
02:41 imirkin: it appears that the WHOLE buffer gets set to 0xcccccccc on nvc0
02:41 karolherbst: yes
02:41 imirkin: yeah. looks like it messes about with stencil
02:41 karolherbst: if you set samples to 2 it passes on nvc0
02:41 imirkin: which is confusing.
02:41 karolherbst: only samples higher 2 fail that test
02:41 imirkin: anyways, will play with apitrace
02:41 karolherbst: apitrace won't help
02:42 karolherbst: sadly
02:42 imirkin: we'
02:42 imirkin: we'll see
02:42 karolherbst: everytime I check with apitrace, I either get uninit memory or it looks like intel
02:42 karolherbst: which is weird
02:42 imirkin: let me worry about that.
02:42 karolherbst: but this seems to be the case with all those MS related bugs
02:42 karolherbst: okay :)
02:43 imirkin: ok yeah. i get diff results on nv50 and nvc0
02:43 imirkin: the bottom half is supposed to remain white.
02:43 karolherbst: uhm, maybe I should fix the blitter for nv50 as well (unsigned -> signed blits)
02:44 imirkin: alright. so now i get the joy of trying to figure out how this thing is supposed to work.
02:44 karolherbst: ohh it is all in common codes, nvm then
02:44 nyef: skeggsb: Thank you for your help tonight. I think that I shall start trying to put together a patch (or patches!) for this tomorrow. AIUI, it's not suited for merge to a -rcN kernel, but it'd be nice to have it in the 4.19 merge window.
02:44 imirkin: yeah
02:45 imirkin: in the presence of stencil, i think a blit just becomes a draw...
02:45 imirkin: or not.
02:46 imirkin: just gonna compare nv50 and nvc0
02:47 karolherbst: nv50 disables VERTEX_TWO_SIDE_ENABLE explicitly, no idea if that's relevant
02:47 imirkin: doubtful. two-sided lighting.
02:50 karolherbst: uhm
02:50 karolherbst: what's that tri_x/tri_y code inside nv50?
02:51 karolherbst: nv50: x1 = x0 + tri_x * x_range; vs nvc0: x1 = x0 + 32768.0f * x_range;
02:51 karolherbst: tri_x = 16384 << nv50_miptree(dst)->ms_x;
02:51 karolherbst: that looks oddly suspicous
02:51 imirkin: yeah, it's a bit different on nvc0
02:51 imirkin: let's just say it's the result of a lot of fiddling
02:52 imirkin: we don't do the blit as msaa
02:54 imirkin: the blit under "// blit" is the one that's failing btw
02:54 imirkin: the result is a mis-compressed surface.
02:54 imirkin: i'm not extremely surprised...
02:54 karolherbst: ahh
02:55 imirkin: er wait. hold on.
02:55 imirkin: this is super-confusing.
02:56 imirkin: yeah ok. the depth in that blit ends up bad.
02:56 imirkin: in the good, the depth scales from 0..1
02:56 imirkin: in the bad, it scales from 0..0.5
02:56 imirkin: the glDrawElements is good in both cases.
03:00 imirkin: which means we're ending up with a scale of 2x on the y coordinate somehow
03:00 imirkin: which is why samples=2 works -- those are laid out on the X axis
03:03 imirkin: my suspicion is that there are like 20 things wrong, which mostly cancel each other out
03:03 imirkin: this actually sounds familiar ... MS blits, going from MS <-> MS, in the 3d engine, end badly
03:03 imirkin: there are EXT_framebuffer_multisample tests which demonstrate this
03:09 imirkin: yeahhhh .... so the way we do MS blits is just ... wrong.
03:10 imirkin: i understand this all a bit better now.
03:10 imirkin: [than when i did last time i was messing around with this junk]
03:12 imirkin: 99% of the time, we'd end up using the 2d engine for the MS blits
03:12 imirkin: which handles them OK
03:12 imirkin: but Z32F always hits the 3d engine
03:12 imirkin: (hmmm... why... seems like it'd be fine... for unscaled blits)
03:13 karolherbst: yeah, that's what I see with nvidia
03:13 karolherbst: they use the 2d blitter
03:13 karolherbst: well
03:13 karolherbst: not for the cTS test
03:13 karolherbst: but for one of the piglit ones, where we do
03:13 karolherbst: use the 3d one
03:14 karolherbst: and it was Z32F
03:19 imirkin: well, can't finish it up now...
03:19 imirkin: main thing is that pre-nva3 didn't support sample shading
03:19 imirkin: so nv50 has to play all kinds of tricks
03:20 imirkin: on nvc0 this is no longer necessary
03:20 imirkin: but it's shared code
03:20 imirkin: i think we'd be better off enabling per-sample shading for the blits on nva3+ instead of playing weird geometry games
03:20 imirkin: it'll require a lot of changes though
03:21 imirkin: gtg
15:30 karolherbst: imirkin: mhh I am looking into the 3d issue now and for whatever reason no matter I change inside nve4_set_surface_info it either draws the first layer, or nothing
15:30 karolherbst: on my kepler card I was kind of able to mess around with the image stuff quite nicely, but not so on the pascal one
15:31 karolherbst: even setting the address to 0 still makes it work
15:34 karolherbst: as far as I understood the issue, we have two 3d images, one to read one to write and we bind each layer as 2d textures and copy the content through image operations
15:34 karolherbst: so I think I just need to set the correct offsets for the bindings and let the image operations operate on the correct address, right?
15:52 nyef: Hrm. Nothing about eDP startup timing in the DCB 4.x specification. Either a fixed value is being used or wherever it's stored isn't in the DCB... Or there's a detect method that doesn't rely on a long timeout?
15:55 nyef: Well, a proper test series would be annoying, but what if it's a matter of apply LCD0 power, wait 1 ms or so, check LCD0 power status, and if it's clear consider there to not be a panel present?
15:56 nyef: That's something we can possibly rule out absolutely based on the contents of the GPIO table, can look for in blob driver traces... and I don't remember if I can power one of these boxes up without a panel. Possibly can't.
16:08 kubast2: So there is no reclocking support for 1st gen maxwell cards?
16:08 kubast2: Also how does it work with optimus laptops ,as I see it in lsmod 2 drivers are loaded at once
16:08 kubast2: i915 and nouveau
16:09 nyef:does not even want to THINK about trying to get GPU switching up and going on his current project machine.
16:10 nyef: ... I know that eDP + no GPU module is a no-go on this hardware. Maybe I'm mixing that scenario up with headless?
16:11 kubast2: theortically the pstate might be set but I doubt"0f: core 270-862 MHz memory 5010 MHz AC DC *" well the only reason it didn't exploded is either 1.it's a stub on maxwell. 2.intel drives all the screens
16:11 kubast2: Yeah it's sorta headless the nvidia gpu isn't connected to any display
16:11 kubast2: I checked it under windows disabled nvidia device
16:11 kubast2: connected all the outputs
16:12 kubast2: EDP HDMI VGA all work with nvidia device disabled so I presume all screens are driven by intel
16:12 nyef: ... Right, that's an angle if I start getting curious for some reason. Thank you.
16:13 nyef: ... I wonder if HDMI input switch-off works on LVDS, or if it's broken there, too?
16:14 nyef: Or if HDMI input requires eDP in the first place? That feels unlikely.
16:15 kubast2: no idea ,I'm testing out optirun vs no-optirun vs nvidia-prime vs nouveau
16:15 kubast2: rn
16:15 nyef: Yeah, even having an HDMI input is pretty unusual, I don't really expect you to know.
16:17 kubast2: well I can tell that that pstate change was a failure tho
16:17 kubast2: lspci and unigine-superposition fails
16:17 kubast2: brb gettin a reboot
16:17 kubast2: also will be taking a ride on a bicycle soon
16:17 kubast2: I will check how the outputs look like
16:17 nyef: "I want to ride my bicycle, I want to ride my bike!"
16:18 kubast2: once I put the pstate in(to check which screen fails/which one is connected directlly)
16:18 kubast2: to which gpu
16:18 kubast2: basically if the pstate change and one of screens freezes/does something weird I will know which one is it
16:25 kubast2: disconnecting hdmi+vga after pstate change causes edp-1 to freeze :shrug:
16:26 kubast2: yeah I will get goin gonna check really quick the exact name of the chip
16:26 nyef: ... Hunh. Some combination of actions just got the display back after it blanking due to HDMI input.
16:26 kubast2: GM107(ggdr5 version of gt 940mx)
16:27 nyef: My hardware disables the integrated GPU if there's an eDP on it, but that might be because of using an old-enough generation of CPU that the built-in GPU can't drive an eDP panel.
16:28 nyef: Or the signal routing just wasn't there at the time or something.
16:30 nyef: Maybe it's a matter of a lost HPD, somehow?
16:30 nyef: ... though I don't recall a lost HPD in the traces I took back when.
16:35 nyef: Mis-handled HPD is looking likely.
16:38 nyef: Plug HDMI in -> "HPD: 2" "aux power -> demand", unplug -> "HPD: 1" "aux power -> always", replug -> "HPD: 2" "aux power -> demand", unplug -> "HPD: 1" "aux power -> always". s2ram and resume, screen comes back. Conclusion: Probably missed a queue for a link retrain.
16:38 nyef: s/queue/cue/.
16:47 nyef: Okay, that's NVKM_I2C_UNPLUG and NVKM_I2C_PLUG. Hrm.
16:55 nyef: ... I'm not seeing anything obvious in terms of special plug/unplug handling for eDP as distinct from DP.
16:58 nyef: ... I'm getting conn 07 HPD events, that seems odd.
16:59 kubast2: yeah I guess that happend
16:59 kubast2: DRI_PRIME=1 doesn't show a window I guess idk how prime works so
17:00 nyef: I think it works on secret '80s energy (as produced by "transformers: the movie") and the FM principle ("f___ing magic").
17:00 pmoreau: kubast2: Try something like `DRI_PRIME=1 glxinfo | grep OpenGL` or `DRI_PRIME=1 glxgears`.
17:00 kubast2: pmoreau, yeah that works
17:01 kubast2: ah wait
17:01 kubast2: glxgeras
17:01 kubast2: gonna check
17:01 kubast2: glxgears works
17:01 pmoreau: DRI_PRIME=1 on its own does nothing, you are just setting the environment variable DRI_PRIME to 1, for an empty command.
17:01 kubast2: steam works I guess
17:01 kubast2: unigine benchmark doesn't tho
17:01 kubast2: gonna check one more time
17:02 nyef: ... I'm looking at this backwards, aren't I? I shouldn't be looking for special handling for eDP, I should be looking for special handling for non-eDP, meaning DP.
17:02 kubast2: yeah unigine-superposition doesn't even render a window with DRI_PRIME=1
17:03 pmoreau: What's the output of `DRI_PRIME=1 glxinfo | grep OpenGL`, and do you get anything special in dmesg after trying to run unigine?
17:05 kubast2: wait I'm back rn was afk
17:05 kubast2: gonna send you a termbin link for glxinfo http://termbin.com/56tu
17:06 kubast2: and there is nothing in dmesg pmoreau
17:06 kubast2: I checked and dead island starts so I have no idea why unigine fails
17:11 kubast2: there is an dmesg from dead island
17:11 pmoreau: The glxinfo looks fine; weird for unigine though.
17:11 kubast2: I can also provide dmesg from dead island crash/freeze
17:11 nyef: ... conn 7 is a tmds interface? WTF?
17:11 kubast2: dde-file-manage sefault
17:12 nyef: Oh! Duh.
17:12 nyef: Okay, I just confused myself for a bit, I know what that is now.
17:12 kubast2: http://dpaste.com/32RPZ3Y.txt pmoreau that is from dead island freeze
17:12 nyef: What I get for loopbacking the HDMI output to the HDMI input. (-:
17:14 pmoreau: kubast2: For Dead Island, there's nothing saying Nouveau is at fault there.
17:15 kubast2: I guess
17:15 kubast2: it fails only at 1080p
17:15 kubast2: works fine at 768p
17:16 kubast2: not sure how to read the framerate but it looks very solid on minimal settings
17:16 nyef: ... still nothing obvious in terms of HPD hookup. /-:
17:20 pmoreau: kubast2: I think you can get framerate through the GALLIUM_HUD environment variable.
17:20 kubast2: steam in-game fps setting
17:21 kubast2: 40-46 fps
17:22 pmoreau: The GALLIUM_HUD exposes more things than just fps, you can also get GPU load and more (if supported), see https://manerosss.wordpress.com/2017/07/13/howto-gallium-hud/ for some information.
17:23 nyef: Nothing obvious in the generic code, either...
17:23 skeggsb: nyef: what are you looking for?
17:24 nyef: I have a scenario where my eDP will issue an HPD for unplug, and then later for plug. Post-plug, shouldn't we be doing link training?
17:24 kubast2: pmoreau, do I need something for gallium_hud ?
17:24 kubast2: some package ?
17:25 skeggsb: nyef: generally yes, if there's a mode set at the time
17:25 nyef: Now, a DP HPD plug event clearly causes link training, so I'm trying to find a difference in handling between the two.
17:25 kubast2: doesn't work for me right out the bat on glxgears pmoreau
17:26 kubast2: GALLIUM_HUD=fps glxgears ?
17:26 kubast2: GALLIUM_HUD=fps+cpu+GPU-load glxgears
17:26 kubast2: tried those 2
17:26 kubast2: ah
17:26 kubast2: wait
17:26 kubast2: DRI_PRIME=1
17:26 skeggsb: nyef: for plug/unplug events, we punt it to userspace and let it respond with modesets
17:26 kubast2: yeah now we talking
17:26 pmoreau: kubast2: It's within Mesa, so as long as you are using a Mesa driver, it should be there.
17:26 skeggsb: we'll actively retrain for an irq event if we detect the sink needs it
17:26 nyef: ... er?
17:26 nyef: Hrm.
17:27 nyef: So, is this userspace being screwy ("eDP can't generate plug/unplug, don't worry about it"), or something else?
17:28 skeggsb: i don't know, as i'm not entirely sure what you're seeing :P
17:28 nyef: Damn. That also explains why a pure HPD doesn't help, but an HPD that causes a mode change does.
17:28 kubast2: pmoreau, yeah I forgot about dri_prime and that I'm not running on a pc
17:28 kubast2: *desktop
17:29 kubast2: I added gallium hud to steam options if it doesn't show up then I borked and only steam launches with dri and it was intel igpu driver launching dead island
17:31 pmoreau: Ah yes, with Steam it gets a bit trickier.
17:32 nyef: Basically, if I connect something to the HDMI input, the panel switches to that input and delivers an HPD UNPLUG to the video card. Then, when the HDMI input is disconnected (or by hotkey), the panel switches back to the video card and delivers an HPD PLUG.
17:33 nyef: And I'm seeing no reason why this shouldn't Just Work.
17:33 skeggsb: i don't see why you'd be getting HPD at all on the panel when you plug in hdmi..
17:33 nyef: Because it's disconnecting from the video card as an output?
17:33 skeggsb: it doesn't work like that
17:34 nyef: It's an HDMI input, not an HDMI output.
17:34 nyef: I'm plugging some *other* thing in to use the laptop panel as a display.
17:34 skeggsb: oh.. i didn't even know such things existed, weird
17:35 nyef: Yeah, I typically end up with weird and wacky hardware.
17:35 skeggsb: what DE are you running?
17:35 nyef: Mate.
17:36 skeggsb: presumably that has something that responds to hotplug events? if so, yes, it *should* just work
17:36 skeggsb: does stuff work if you kill the DE and run from fbcon?
17:36 nyef: ... Waitasec. This also needs to work for... Exactly. Good question. Can I test just by M-C-F1 and trying, or do I actively need to kill X?
17:37 skeggsb: you can VT-switch
17:38 nyef: ... Oh, fun: It *blanked the panel* while the HDMI in was connected, but recovered perfectly once it was disconnected.
17:38 nyef: That's no good either.
17:39 skeggsb: what behaviour do you expect? the panel says its not there when you've plugged in hdmi?
17:39 nyef: I'd like for the backlight to still be on. (-:
17:39 skeggsb: as far as the driver is concerned, the panel doesn't exist at that point
17:41 kubast2: pmoreau, got it to work I think
17:41 kubast2: I see cpu usage and fps
17:42 kubast2: it has some extra switches I saw in help but other than cpu/hdd temps I don't understand neither of them
17:43 pmoreau: I haven't used GALLIUM_HUD either (I just know it exists), so I won't be able to help you more, sorry.
17:44 nyef: So, this is going to be a matter of having fbcon not kill the backlight on eDP unplug, possibly with a bloody DMI check, plus fixing up something with... probably Mate, but small-possibly xf86-video-modesetting and xf86-video-nouveau, isn't it?
17:46 skeggsb: yeah, i uh, don't exactly know how you're going to achieve keeping the backlight on in any kind of sane way
17:46 skeggsb: now why you want to?
17:46 skeggsb: nor*
17:46 nyef: Because if the backlight is off, I can't see anything from the HDMI input?
17:49 kubast2: pmoreau, well I guess I will use dead island to benchmark the drivers anyhow I noticed this: https://i.imgur.com/XSR2qY0.jpg
17:49 kubast2: I will just get to a point where it saves and use those locations forward
17:50 kubast2: given it runs at minimal gpu frequency(I presume)
17:50 kubast2: it runs pretty well only half the speed of intel igpu(which runs at 1000mhz instead of 135mhz)
17:51 skeggsb: nyef: ah. for some reason i was expecting whatever hw turns the hdmi signal into something for the eDP panel to fully take over driving the panel (including power, backlight etc) after it sends unplug
17:51 pmoreau: Btw, reclocking should work on Maxwell v1, IIRC.
17:51 kubast2: pmoreau, manual or ?
17:51 kubast2: I did changed the pstate but it crashed
17:51 kubast2: brb
17:51 pmoreau: Yes, manual
17:52 kubast2: I will re check it crashed/lspci lagged when I did that
17:52 kubast2: and generarlly apps that would work on intel gpu
17:52 nyef: skeggsb: Yeah, no such luck. And I get to test everything over again with an LVDS panel as well.
17:52 kubast2: didn't worked
17:52 kubast2: afk
17:52 pmoreau: Ah, if that GPU auto-suspends, you need some extra patches to prevent the crash
17:52 skeggsb: nyef: do you know if nvidia handle it?
17:52 nyef: Not in the console, obviously, but yeah.
17:53 skeggsb: ok, lemme see if i can get a hint
17:56 kubast2: pmoreau, yeah I think it auto-suspends
17:57 kubast2: pmoreau, temperature throttling/temperature control is in place ?
17:57 kubast2: in nouveau
17:57 kubast2: for GM107 ?
17:57 pmoreau: I don't think so (which would be partly why there is no automatic reclocking)
17:57 kubast2: ah
17:58 kubast2: temperature reading is avalible ? pmoreau
17:58 pmoreau: You should be able to see it through the `sensors` command
17:58 kubast2: pmoreau, I see gpu voltage
17:59 kubast2: unless
17:59 kubast2: ath10k_hwmon-pci-0300 is the gpu ?
17:59 kubast2: nouveau-pci-0100 only has gpu core votlage
17:59 pmoreau: You don't have something like? https://hastebin.com/nanukoqiqe.swift
17:59 kubast2: gonan send a termbin link
17:59 pmoreau: Maybe your GPU doesn't have a temp sensor, or it isn't recognised, I don't know
18:00 kubast2: http://termbin.com/ndkk5
18:00 kubast2: it has a gpu sensor
18:00 kubast2: (*temp
18:00 kubast2: cause nvidia driver reads it
18:00 nyef: ... Maybe the simpler option would be to check for eDP and then /not/ pass HPD back up the line and instead have the HPD PLUG cause a retrain automatically?
18:00 karolherbst: pmoreau: ohh btw, do you think you have some time reviewing my nir series?
18:01 pmoreau: I guess Nouveau doesn't recognise it then
18:01 karolherbst: also I try to work on my reclocking patches this week
18:02 pmoreau: Having at least the patches that prevent the crash when reclocking while the GPU is suspended, would be pretty nice :-)
18:03 kubast2: no pstate is selected but it looks like AC pstate shows the current pstate?
18:03 kubast2: since it previouslly was 0 mhz core 0 mhz memory
18:04 kubast2: when there was no DRI_PRIME=1 apps running
18:05 karolherbst: pmoreau, skeggsb: I think those 4 patches should be fine though: https://github.com/karolherbst/nouveau/commits/clk_fixes
18:05 kubast2: ok chainging the clock to 0a
18:06 karolherbst: maybe the last two can be skipped
18:06 pmoreau: kubast2: Yes, AC(/DC) shows the current state
18:06 kubast2: 0a: core 270-862 MHz memory 1600 MHz as I understand this it autoreclocks ?
18:06 karolherbst: I am sure they don't apply anymore
18:06 kubast2: from 270-862mhz ?
18:06 pmoreau: Hum, I think it's more like it will pick a clock within that range, depending on temperature and such.
18:06 kubast2: or it's just a range of possible clocks after I apply it
18:06 pmoreau: But karolherbst knows way more about that :-)
18:07 kubast2: switching a pstate *fingers crossed*
18:07 karolherbst: yeah
18:07 karolherbst: kubast2: use config=NvBoost= to set the upper limit
18:08 karolherbst: possible values are 0, 1 or 2
18:08 karolherbst: we default to 0
18:08 karolherbst: so you get the "base" clocks only
18:08 nyef: ... LVDS and eDP use different hotplug IRQs... Now to compare their device entries...
18:08 karolherbst: 1 is "boost" and 2 is whatever is possible with therm/voltage constraints
18:09 karolherbst: we don't default to 1 or 2 yet because we aren't exactly good and throttling on high heat
18:09 karolherbst: but usually those levels dont really cause overheating
18:10 kubast2: I see I checked and 768p and 1080p performs at around same framerate on dead island
18:11 kubast2: so as I understand "base" clock
18:11 kubast2: you mean the non-turbo value(700mhz)
18:11 kubast2: because I did got around *2 fps increase from 405mhz to 270-862mhz range
18:12 karolherbst: yes
18:12 karolherbst: 700mhz is the non turbo one
18:12 karolherbst: usually GPUs are sold with some marketing frequencies: base/boost
18:12 karolherbst: but there is a cap beyond boost
18:12 karolherbst: the boost value is just a clock which is possible to reach in most cases
18:13 karolherbst: you can boot with nouveau.config=NvBoost=2 to try the highest clocks
18:13 karolherbst: but just watch your GPU temperature and check that it doesn't go too crazy
18:13 kubast2: Yeah I have no gpu temperature reading karolherbst
18:13 karolherbst: where <70º is a good target, but even 90º would be fine
18:13 karolherbst: kubast2: sensors
18:13 kubast2: only gpu voltage
18:13 karolherbst: hu
18:13 karolherbst: weird
18:14 karolherbst: what kernel version?
18:14 kubast2: 4.17.3-1
18:14 karolherbst: I am sure that temperature readings should be available on pretty much every GPU
18:14 karolherbst: and sensors only reports voltage?
18:14 kubast2: it's a custom one
18:14 kubast2: for acer only
18:14 kubast2: has 512 cores
18:14 kubast2: and is branded as gt 940mx
18:15 kubast2: where most of them have 384 cores
18:15 kubast2: has lower clocks but more shaders and rops etc
18:15 karolherbst: doesn't matter
18:15 kubast2: I see
18:15 karolherbst: do you have envytools installed?
18:15 kubast2: I don't think so
18:16 kubast2: but I can install them in a jiffy
18:17 kubast2: I'm installing one from aur envytools-git but if it won't be sufficient I will grab it from github
18:17 kubast2: envytools-git 1:0.r4044.3b4bd3e-1
18:19 karolherbst: kubast2: as root: nvapeek 2044c 8
18:19 karolherbst: when the GPU is on
18:23 kubast2: need to compile it myself
18:23 kubast2: was afk grabbed a beer
18:23 kubast2: https://github.com/envytools/envytools
18:24 kubast2: make -j4 ing it all
18:25 kubast2: where will I find the binary I'm looking for(I can "find" it but yeah)
18:25 kubast2: 0002044c: 00000076 00000040
18:25 kubast2: karolherbst
18:25 kubast2: ah wait
18:25 kubast2: gpu is probablly off rn
18:25 kubast2: launching a game
18:25 karolherbst: no, that's fine
18:26 karolherbst: 0x76 - 0x40 = 54 ºC
18:26 karolherbst: nvapeek 20400 should work as well
18:26 karolherbst: or maybe that one doesn't
18:27 kubast2: I will heat the gpu up a bit
18:32 nyef: Trying a startup with the HDMI in attached... and HDMI in doesn't kick in until the nouveau driver loads.
18:34 kubast2: karolherbst, 0002044c: 0000008f 00000040
18:34 kubast2: same temp under load ?
18:34 kubast2: the base clock probablly heats up to 70*C(on standard driver in windows)
18:34 kubast2: so those will be safe temps
18:37 nyef: Hrm. "[drm] Cannot find any crtc or sizes"?
18:38 karolherbst: kubast2: first value
18:38 karolherbst: kubast2: so you got 79º now
18:38 nyef: ... so, can't rely on the auxch to determine the existence of a panel? That seems odd, somehow.
18:39 kubast2: oh
18:39 kubast2: 0x76 - 0x40
18:39 karolherbst: kubast2: yeah
18:39 kubast2: I didn't noticed that
18:39 kubast2: I just brain farted and assumed 0x40 hex
18:39 karolherbst: kubast2: nvapeek 20400 should give you the value directly
18:39 karolherbst: but maybe that one doesn't work
18:39 karolherbst: and that's why nouveau doesn't report the temperature
18:40 karolherbst: I think I remember something like that
18:40 kubast2: yeah
18:40 karolherbst: so nvapeek 20400 doesn't give you any value?
18:40 kubast2: nope it gives 32
18:40 kubast2: with 72 and 40
18:40 kubast2: for 2044c
18:41 kubast2: 0002044c: 00000072 00000040
18:41 kubast2: 00020400: 00000032
18:41 karolherbst: well, that is correct though
18:41 karolherbst: 0x72 - 0x40 == 0x32
18:41 karolherbst: odd
18:41 karolherbst: kubast2: mind sharing your dmesg?
18:42 karolherbst: maybe there is something in the logs
18:42 kubast2: full one
18:42 kubast2: yeah
18:42 karolherbst: otherwise I would have to read the code and check why that happens
18:42 kubast2: allright no prob
18:42 kubast2: http://termbin.com/fj2x
18:42 kubast2: I have some MMIO FAULTs at start up but idk what those are
18:42 kubast2: the PCIE corrected thing is from a wifi card karolherbst
18:43 karolherbst: mhhh
18:44 kubast2: [ 10.888239] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 612004 [ IBUS ]
18:44 kubast2: [ 10.895725] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 10ac08 [ IBUS ]
18:44 kubast2: idk what those are but yeah they show up at startup but the driver works
18:44 karolherbst: doesn't really matter
18:44 karolherbst: just that we read values we shouldn't
18:45 karolherbst: kubast2: ls /sys/devices/pci0000\:00/0000\:00\:01.0/0000\:01\:00.0/hwmon/hwmon*/
18:46 kubast2: ls doesn'
18:46 kubast2: 't have acces to : There is no such file or directory
18:46 kubast2: with sudo
18:46 karolherbst: hu
18:46 karolherbst: ls -lah /sys/class/hwmon/
18:46 kubast2: 0000:00:02.0/ 0000:00:17.0/ 0000:00:1f.0/ pci_bus/
18:46 kubast2: ah wait
18:47 kubast2: hwmon0 up to hwmon4
18:47 karolherbst: does any of those symlinks look like they link to your nvidia gpu?
18:48 karolherbst: most likely it is hwmon4, but there is no guarentee
18:48 kubast2: 2 of them link to pci slots
18:48 kubast2: one of them is for wifi card
18:48 kubast2: the other for a host pcie root port
18:49 kubast2: ah
18:49 kubast2: I see
18:49 kubast2: one is connected to nvidia
18:49 karolherbst: okay
18:49 karolherbst: what is inside that one?
18:49 kubast2: device in0_input in0_label in0_max in0_min name power subsystem uevent update_interval
18:50 kubast2: all of them are read only besides folders/symlinks
18:50 nyef: ... So, next question that comes to mind is "why does HDMI input not kick in until nouveau loads?"
18:50 karolherbst: kubast2: ohh, I think I see it
18:50 kubast2: http://termbin.com/sme3
18:51 kubast2: here is the output of them
18:51 kubast2: the cathologs didn't got sent
18:51 kubast2: it's the votlage karolherbst
18:51 karolherbst: no, I meant the reason why it doesn't show up
18:51 kubast2: :shrugs_in_lack_of_knowledge:
18:56 karolherbst: kubast2: nvapeek 0x0212a8
18:57 kubast2: wait gonna launch a game it returns 3 dots
18:58 kubast2: returns 3 dots regardless
18:58 karolherbst: ueah
18:58 karolherbst: *yeah
18:59 karolherbst: mhhh
18:59 karolherbst: so yeah, that's the reason
18:59 karolherbst: kubast2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nvkm/subdev/therm/g84.c?h=v4.18-rc3#n34
19:00 karolherbst: could you remove that entire if/else thing by "return nvkm_rd32(device, 0x20400);"
19:00 karolherbst: and see if this enables temp readouts for you?
19:01 kubast2: allright I will check it
19:03 kubast2: How can I checkout to a tag btw ? I presume I will want to 4.18-rc3 tag it instead of master
19:04 kubast2: checkout tags/4.18-rc3 I see
19:04 nyef: Plausibilities are two: Either a GPIO gets smacked some way during driver startup, or it's an ACPI thing.
19:05 nyef: The fact that there's an ACPI hotkey to turn the detect on or off leads me to suspect "ACPI thing".
19:09 kubast2: g84_temp_get(struct nvkm_therm *therm) { struct nvkm_device *device = therm->subdev.device; return nvkm_rd32(device, 0x20400); } like this ?
19:10 kubast2: I presume get rid of else return -ENODEV; and the if before return nvkm_rd32 karolherbst
19:11 kubast2: http://dpaste.com/05GZJDC.txt
19:13 kubast2: I did it this way compillin a kernel rn
19:15 nyef: ... If we can block the cut-over to HDMI input until after we have done display detect and have the EDID, we can then present the connector as still connected, even after the HDMI input is running, which should be more than enough to fake out the userland.
19:20 kubast2: once I get the kernel booted up I will notify you I presume my task after that will be to check hwmon4 and sensors command ? karolherbst
19:20 kubast2: I take all of those as yes
19:26 karolherbst: kubast2: well it should just appear in sensors
19:27 karolherbst: I am quite positive that this will fix it, because there isn't anything else which could prevent this...
19:51 nyef: It doesn't "feel" like the trigger is registering with ACPI_VIDEO...
19:51 nyef: ... leaves ACPI_WMI and MXM_WMI, I think?
19:53 nyef: MXM_WMI feels unlikely, somehow.
19:56 nyef: ... maybe something with alienware-wmi.c?
19:56 nyef: That has some bits about the HDMI input, but I don't think it's for this generation of hardware.
19:57 kubast2: Anyways I will be going to uni and getting a "minning" rig I might as well sell my desktop get a psu that won't self-combust and a mobo+cpu with gpu passthrough support ,and buy some cheapo nvidia gpus ,but I would first had to check whether I would had an external ip there and that would take awhile
19:57 kubast2: as in
19:58 kubast2: Would any of the devs be interested in remote access to a desktop with nvidia gpu?
19:58 nyef: Your electricity costs are going to be covered by the UNI, so you might as well blow it on mining cryptocurrency?
19:58 kubast2: yup
19:58 kubast2: as long as I set it up in a way
19:58 nyef: ... Fair enough, I guess.
19:58 kubast2: that it mines through my internet
19:58 kubast2: and the remote access for devs goes through the uni internet
19:58 kubast2: I bet they either block or detect the miners at this point
20:00 nyef: Ah, ACPI_WMI is the outer envelope. Forgot about that.
20:01 kubast2: nyef, nothing is said about costs of electricity
20:03 kubast2: I will have to check first how much cash rent for uni will cost me and how much will the minning rig/remote rig cost me
20:04 nyef: kubast2: The relation is that bitcoin mining produces "value" at about the rate of the cost of electricity consumed to do the mining... Or at least it did at one point, I really haven't been paying attention.
20:05 kubast2: ethereum minning ,from what I recall it's really hard to find bitcoin miners that make profit at least I couldn't find any
20:06 kubast2: the minning rig alone can be cheap if I just buy a psu for my current pc
20:07 nyef: ... How powerful a PSU do you need, and are you on good terms with the manager of your local "waste transfer station"?
20:09 kubast2: I belive a 500-450W psu is all I need
20:09 kubast2: right now I have a shitty one that is rated 500W
20:09 kubast2: but pulls a max of 240W
20:09 kubast2: never runned a 75W*3 tdp gpu
20:09 kubast2: and current psu doesn't even have an 8pin it has an 6pin
20:09 nyef: Yeah, that might not be so easy to source at a low price point.
20:10 kubast2: like I can sell some of my handhelds since I bought the vita but it came with a wrong software version
20:10 kubast2: so I can sell that
20:11 kubast2: so that gets me a free psu
20:12 kubast2: nyef, the ram is a bigger issue if I will go to new mobo route
20:13 kubast2: ram is expensive asf
20:13 kubast2: like yeh a decent psu is 40-60 and up bucks
20:14 nyef:is so, so glad for six-year-old hardware.
20:14 kubast2: same
20:14 kubast2: but I have broke a pcie slot
20:14 kubast2: I was dumb enough
20:14 kubast2: to put in a pcie wifi card when the gpu was plugged in WHEN DESKTOP WAS RUNNING
20:15 kubast2: basically the screen went black
20:15 kubast2: plugged off the wifi card
20:15 kubast2: and the pcie works
20:15 kubast2: the x16 one only when that slot is unplugged
20:15 kubast2: not sure about the other x1 slot
20:15 kubast2: since it was hidden by a gpu
20:15 nyef: I've heard of "PCI hotplug", but I've never looked deeply into what's involved in making it work.
20:16 kubast2: >search for psu >by price >all certificates besides "none"
20:17 nyef: Always struck me as being one of those "primarily enterprise feature" things.
20:17 kubast2: well now it would also be "kubast2 not breaking his motherboard" feature
20:18 kubast2: chieftec is a decent brand from what I recall
20:18 kubast2: PCI-E 8-pin (6+2) x2
20:18 kubast2: 44 usd
20:19 kubast2: 600w yeh that will do
20:19 kubast2: If I understood correctlly AB350 boards support iommu passthrough
20:20 kubast2: so anything better should do won't gamble with A350
20:20 kubast2: when it's 'just' 20 bucks more for b350
20:20 kubast2: yeh let me check now nyef how much it would cost me
20:21 nyef: Hunh. PCIe is supposed to support hotplug on all host hardware, but some cards absolutely don't support it?
20:22 kubast2: nyef, dude I broke a pcie slot lol
20:22 kubast2: the x16 line doesn't work when the lower x1 slot is inserted
20:22 kubast2: after I did that hotplug
20:22 kubast2: I sold that 1050 the guy didn't complained
20:23 kubast2: I only have cash for an rx 570
20:23 kubast2: so my guess is the gpu itself was fine
20:24 kubast2: after that "hotplug" run of mine
20:25 kubast2: yeh
20:25 kubast2: the mobo(cheapest b350)+cpu(cheapest ryzen 3)+ram(cheapest 8GB) alone costs almost as much as rx 570 alone
20:26 kubast2: karolherbst, almost there compilation completed I will be rebooting soon
20:28 kubast2: Should I cp bzImage or vmlinuz to /boot/vmlinuz-test
20:28 kubast2: ?
20:28 kubast2: I will follow the arch wiki bzImage it is then
20:31 kubast2: reboot
20:33 kubast2: gonna launch Steam (dri prime nouveau)
20:33 kubast2: cause sensors returns -0.0 *C
20:33 kubast2: rn
20:33 kubast2: it returned with hugh crit and emrgency
20:33 kubast2: they are quiet high tbh
20:34 kubast2: 95*C 105*C 135*C; I recall gpu-z reading max allowed temp being 92*C but yeh
20:34 kubast2: idk
20:34 kubast2: maybe that's thermal throttle temp
20:34 kubast2: karolherbst, steam launched got a temp reading
20:34 kubast2: 37-38*C
20:35 kubast2: and -0 again gonna launch some game
20:36 kubast2: yup it works I think karolherbst
20:37 kubast2: next time I would loadmodconfig/the make command that creates a .config from currentlly run kernel modules
20:37 kubast2: etc
20:38 kubast2: is it possible to show the cpu temp on gallium hud ? karolherbst
20:38 kubast2: hmm
20:38 kubast2: wanted to say it seems like dead island always crashes just like that
20:39 kubast2: ah I accidentlly openned irc logs somehow
20:39 kubast2: *dead island always crashes on first start up
20:40 karolherbst: mupuf: so uhm, any idea what to do when the temp calib doesn't return 1?
20:41 mupuf: karolherbst: on what chipset?
20:41 karolherbst: mupuf: gm107
20:42 mupuf: ;o
20:42 mupuf: that is odd...
20:42 mupuf: is it only this one?
20:42 mupuf: and does 20400 return a sensible value anyway?
20:43 karolherbst: mupuf: seems like it
20:43 mupuf: I guess it is an oversight
20:44 kubast2: nyef, yeah I might resign from getting a minning rig tbh
20:44 karolherbst: mupuf: I guess we should what nvidia does
20:44 mupuf: karolherbst: +1
20:45 kubast2: anyways any "low price" gpu you might want for testing ?
20:45 kubast2: my desktop pc sits and does nothing so I can buy some nvidia gpu and test stuff on my desktop
20:48 kubast2: I presume ones from the hardware needed list would work well too even though those ones are "for sending" to someone
20:58 kubast2_: yeah I guess marcin/nouveau dev from poland has a ton of nvidia gpus
21:06 kubast2_: Idk next time I can setup distcc + and do allmodconfig instead; well I don't have the exact knowledge of inner workings of a pc ,but I can buy hardware and test outputs etc.(well I rather not abuse the 14 day return policies ,so in general there would be a restriction on how many things I can test out)
21:12 kubast2_: /localmod config it might have been
21:14 karolherbst: imirkin: it is a bit annoying that nvidia fails the 3dimage piglit test, or basically most of them
21:24 kubast2_: Well a gt710/1030 is within my reach so that's what I might get and test out things on a machine that isn't my dailly driver
21:25 nyef: Well, well... If I run a kernel without CONFIG_ACPI (meaning no ACPI_VIDEO, no ACPI_WMI, and no MXM_WMI), the HDMI input *doesn't kick in*.
21:27 nyef: ... And alienware_wmi doesn't apply, I get "No known WMI GUID found", which doesn't mean that there might not be a suitable hook, just that it's not yet "known".
21:31 kubast2_: Well I'm buying a gt 710 then
21:32 kubast2_: I can either make it a dailly rutine or run it every week and report in
21:33 nyef: Overall, I'm set for nvidia hardware that I currently consider to be "interesting".
21:36 nyef: ("Interesting" defined as "hardware that I already have and use, or that covers some gap in the lineup for making some feature that I want to have work".)
21:36 kubast2_: I see ,I normally just buy whathever is in my 2nd bang for the buck price bracket
21:36 kubast2_: Which is gtx 1050/rx560 price
21:37 nyef: I think I got a gtx 1050 so that I would have a GM10x device. And more as a target of opportunity than because I really wanted one.
21:37 kubast2_: I don't need a gaming pc since my laptop now fits that role and is portable vs my desktop
21:38 kubast2_: I sold it because I haven't used it for months
21:38 nyef: I have hardware that I haven't used in years.
21:39 kubast2_: Same but no one would buy broken headphones and phones with leaked screens
21:39 nyef: Occasionally, obsolete hardware comes in handy.
21:39 kubast2_: And almost unused usb hdd
21:39 kubast2_: Sorta I guess
21:40 nyef: USB HDD? Spare Linux test environment!
21:40 kubast2_: Well I will be checking lowest price for gt 710 and I will get one
21:41 kubast2_: Asus one is super cheap wow -33%
21:41 kubast2_: Gddr5 too
21:42 nyef: At one point last year I set up my Vic-20 (not used in years) in order to dump a cartridge that I had for it that apparently isn't available online.
21:43 nyef: I have no idea when the last time I powered up my SGI Fuel was.
21:43 nyef: And so it goes.
21:47 nyef: Dragging things back to nouveau, I have a gf119. I got it for a particular purpose. I'm fairly sure I haven't used it since April 2017. It will probably break before I find occasion to get rid of it.
21:48 nyef: My collection of 30-pin SIMMs got raided less than a year ago.
21:48 kubast2_: Ok I will be paying for a gt 710 tomorrow
21:49 kubast2_: 27 euro after conversion
21:49 nyef: Congratulations. I hope it is useful for you.
21:49 kubast2_: Well only for nouveau testing
21:49 kubast2_: I MIGHT use it to learn gpu modding
21:49 Lyude: mainline seems to have a runtime pm leak
21:49 kubast2_: At some point
21:50 Lyude: I /think/ it's coming from nv50's display code but I'm not 100% sure yet
21:54 Lyude: oh, now i'm 100% sure. patch coming in just a moment, along with a bonus runtime pm leak fix i'm surprised i found at all
21:54 kubast2_: Generarlly speaking for newest nouveau changes I should use mainline? I see that freedesktop wiki proposes a kernel which had a last commit 3 years ago
21:54 Lyude: yes
21:55 kubast2_: Oh okay I see
21:55 Lyude: that, or the nouveau out of tree module on github (same module, just gets updates before mainline)
21:55 kubast2_: Brqnch 4.18
21:55 kubast2_: June 19
21:55 Lyude: (keep in mind, the time difference between the oot module and the mainline module getting updates isn't terribly big)
21:57 kubast2_: oot?
21:57 Lyude: out of tree
21:57 Lyude: or ocarina of time, for the gamerz
21:57 kubast2_: Ah okay so generarlly just use master of mainline got it
21:58 Lyude: mhm, drm-next is also a thing
21:58 kubast2_: allright
21:58 Lyude: A summary: from most up to date to least: nouveau out of tree module, drm-next, mainline
21:59 kubast2_: I will be using drm-next for my dailly tests
22:00 kubast2_: Well unless something will break
22:00 kubast2_: And I will need to test an out of tree
22:01 Lyude: kubast2_: what kind of testing is this if you don't mind me asking?
22:02 kubast2_: Hmm generarlly if stuff breaks and performance I presume kepler is done well tho
22:03 kubast2_: I have free time a spare desktop doing nothing
22:06 kubast2_: Lyude I'm not really good of an programmer or someone who can reverse enginner software/hardware ,I'm a fairlly basic linux user tbh ,but for some time I will have nothing to do Lyude
22:07 Lyude: kubast2_: ahhh, well I appreciate the help :). we need more testing, although hopefully we'll have igt working for nouveau so we can have CI at some point
22:08 kubast2_: So basically: 1.Graphical glitches. 2.Video decode/encode acceleration. 3.Performance. 4.Does it boot. 5.Sensors. 6.Does stutter happen when it didn't happen(regressions). 7.Does it boot.
22:08 kubast2_: That's how I see it
22:09 kubast2_: And I guess video outputs
22:09 Lyude: 8. suspend/resume, 9. runtime power management, 10. atomic vs legacy, 11. load/unload
22:09 Lyude: testing a video driver is a looooot of work to actually do fully, jfyi
22:10 kubast2_: Oh okay load/unload(driver?)
22:10 kubast2_: pmstates
22:10 kubast2_: Not sure about atomic vs legacy
22:10 Lyude: although quick runs can catch silly issues before they become not-so-silly
22:10 Lyude: atomic is atomic modesetting, legacy is the old modesetting interface for the kernel
22:10 kubast2_: Yeah ik even my runs will be pretty scarce vs a full run
22:10 kubast2_: And yeah I guess piglet can be added in
22:11 Lyude: don't forget --dmesg if you do piglit :)
22:11 Lyude: that's especially important (unfortunately) for nouveau
22:13 kubast2_: Can you point me to linux-drm repo?
22:13 kubast2_: I will make it an allias
22:14 kubast2_: I found one but it wasn't updated in 4 weeks
22:14 kubast2_: So I guess mainline it is then
22:15 Lyude: my git says
22:15 Lyude: Fetch URL: git://people.freedesktop.org/~airlied/linux
22:15 Lyude: ^ that's drm-next
22:16 airlied: not any more it's not
22:16 airlied: git://git.freedesktop.org/git/drm/drm
22:17 Lyude: oh, huh
22:17 Lyude: well now I know
22:22 nyef: I'm going to forget that by the time I next need to know it, aren't I?
22:22 kubast2_: Suddenlly that tv I got won't be so uselesd
22:22 kubast2_: I still will have to buy dvi to dvi cable
22:22 kubast2_: Instead of hdmi to dvi
22:22 kubast2_: To test all outputs at once
22:35 kubast2_: Well I will close this session on irc to have this in my history ,turn on autologin+add irc to startup on my dailly driver and I will be set; Once I get my gt 710 feel free to message me anytime(I might be asleep ,cause irccloud on my phone)
22:36 kubast2_: I will write down that little list of tasks even if it isn't complete I guess and accept any custom requests
22:40 kubast2_: Lyude What would be a thing to check about runtime power managment?
22:41 Lyude: checking to make sure that the GPU actually suspends when it's not being used on a hybrid laptop, making sure the GPU actually stays on on a hybrid laptop when displays are in use, etc.
22:41 kubast2_: Turning it all into a note on my phone
22:41 kubast2_: Ah it will be tested on a desktop
22:43 kubast2_: I'm not so found about testing on my laptop since that's my dailly driver and where as I can get away with accidentlly chainging kernels stable entry into drm-git one instead of using a special entry for it on a desktop ,I just rather avoid testing on a machine I will be using for dailly day to day stuff
22:44 kubast2_: So no auto suspend when gpu is not in use since my desktop turns of intels igpu
22:44 kubast2_: Once the pcie x16 slot/gpu is in
22:44 Lyude: gross :(
22:44 Lyude: really wish more desktops would implement the firmware methods for that
22:45 kubast2_: Also on a hybrid laptop of my nvidia gpu has no direct outputs
22:46 kubast2_: It only shows on screen through intel
22:46 Lyude: kubast2_: tbh though, the thing we need most with qa on nouveau right now is intel-gpu-tools support
22:46 Lyude: but that would require a developer
22:46 Lyude: (i am planning on working on it asap, after I drain my work backlog)
22:46 kubast2_: I see
22:47 Lyude: if it's not tested by robots, it's probably broken. if it's not tested by people, it's probably broken. if it's tested by both, it has a good chance of not being broken :)
22:49 airlied: once the robots can keep the robots running it'll be great :-P
22:49 Lyude: hehe
22:51 airlied: when people talk about maintaining a CI system, the realisation of quite how much work it is (a full time job on it's own) takes time to get to :-P
22:52 airlied: writing tests is really the easiest bits :-P
22:52 Lyude: yeah
22:53 Lyude: that being said though, I think there's still a lot that can be gained even from just /having/ a test suite, with or without CI :P
22:54 airlied: oh definitely, but moving to a CI is never, oh great it's automated I can do something more interesting with my time, it's always oh hey I have to keep it automated constantly
22:54 Lyude: hehe, yep
22:54 airlied: (if hw is involved)
22:54 airlied: though maybe we could use an nviida gpu in the cloud to run some piglit tests :-P
22:54 Lyude: i've never minded working on stuff like that at least, upkeeping systems is fun for me in a strange way
23:26 imirkin: wow, that's it for ms images on maxwell? i was sure the blob did it the "manual" way
23:27 imirkin: airlied: it's been considered :)
23:31 nyef: The M17x R4 does not work without a panel attached. Right.
23:43 nyef: ... 1600x900? Did I screw this up somehow, or did my LVDS panel always suck?
23:44 nyef: HDMI in still works...
23:44 nyef: ... and so does the recovery.
23:44 nyef: That's new.
23:51 nyef: Well, I don't know what I'm looking at, probably because it's an LVDS hot-plug instead of a DPort or HDMI hot-plug, but it Just Works for some reason.
23:52 nyef: Does register as disconnected while HDMI-in is connected, as for eDP.
23:53 nyef: Console the same, it Just Works. No backlight drop, the GPU takes back control smoothly, and all that.
23:58 nyef: ... There's a mode configured. Someone pulls the plug on the only display device. There's *no point* to changing the mode. Someone plugs the display device back in. There's *still no point* to changing the mode: it's already the mode that we want.
23:58 nyef: That at least would explain the X11 side of things.
23:58 nyef: And LVDS doesn't need to link-retrain, so that bit Just Works.
23:59 nyef: No idea what's up on the eDP console side yet, though.