01:49 imirkin: pendingchaos: to answer your pm about envytools development, i just push stuff. some people open PR's - i have no interest in dealing with github workflows though. to each their own.
02:05 azaki: karolherbst: i got the shader dump you requested yesterday. =o
02:05 azaki: i'm not sure where i should upload it
02:05 azaki: i also recorded a video of the buggy behavior.
02:05 azaki: https://www.youtube.com/watch?v=HlJnwCVq69w
12:11 karolherbst: ... now I don't get the EVO timeouts :( messy
12:13 karolherbst: do we have some nouveau patch for that "INIT_GENERIC_CONDITON: unknown 0x07" thing?
12:16 karolherbst: skeggsb_: I think the non handling of that causes some issues on one of my GPUs
12:18 karolherbst: or uhm, maybe it is something else
13:02 karolherbst: Lyude, skeggsb_: do you know if there are some pending DP related fixed? I have some syncing issues I would like to get fixed
15:08 pendingchaos: imirkin: any ideas on how to handle how xmad has two types, one for each operand of the multiplication?
15:08 pendingchaos: currently, in the patches, it's done by adding a sign extension modifier
15:12 pendingchaos: (previously (edited for briefness): https://hastebin.com/olaropawon.txt)
15:27 Lyude: karolherbst: not yet; what is the issue you're having?
15:28 Lyude: I know I'm currently seeing some issues with how nouveau interacts with the lenovo laptop docks over DP AUX, which is next on my to-do after fixing up the deadlocks
15:28 karolherbst: Lyude: https://vimeo.com/279980046
15:29 Lyude: wtf
15:29 Lyude: that is certainly a new one
15:29 karolherbst: that change when it reaches the top though
15:29 karolherbst: and it is super reliable
15:29 karolherbst: same display works on HDMI good enough
15:29 Lyude: I'll be honest; that seems more like an encoder related issue, I think
15:29 karolherbst: only happens with DP
15:30 Lyude: has it always been like this?
15:30 karolherbst: well
15:30 karolherbst: kind of the first time I tried it
15:30 karolherbst: it is a newish laptop with a 970M
15:30 karolherbst: I got it quite cheap from somebody
15:30 Lyude: Is this SST?
15:30 karolherbst: SST?
15:31 Lyude: opposite of MST
15:31 karolherbst: yes
15:31 karolherbst: with an active HDMI 2.0 to DP 1.4 converter
15:31 Lyude: oooh, so the source is DP and the sink is HDMI2?
15:32 karolherbst: well I doubt that display can do HTMI2
15:32 karolherbst: *HDMI
15:32 karolherbst: but the other way around
15:32 Lyude: So the sink's DP and the source is HDMI
15:32 karolherbst: the display provides HDMI :)
15:32 karolherbst: well
15:32 karolherbst: no
15:32 karolherbst: both is DP as far as the GPU is concerned
15:32 karolherbst: there is no HDMI whatsoever anymore
15:32 Lyude: well, first off I'm suspecious of the active encoder before anything else
15:33 karolherbst: it works
15:33 karolherbst: I used it with a 4K display and intel
15:33 Lyude: hmmm
15:33 karolherbst: but maybe that converter is still funky in some way
15:33 karolherbst: but I used it with plenty of hardware
15:33 karolherbst: and it works with nvidia
15:33 Lyude: It could be the converter is funky in a way i915 is trained to handle but nouveau isn't
15:33 karolherbst: and nvidia ;)
15:33 karolherbst: and mac os x
15:33 karolherbst: and... other hardware
15:33 karolherbst: I have that convert for nearly 2 years now
15:33 karolherbst: *converter
15:34 Lyude: do any other display modes work?
15:34 karolherbst: didn't try
15:34 Lyude: i'd give that a shot, I wonder if we're just setting up the evo channel wrong with dp
15:35 Lyude: I wonder as well if you can reproduce that without the active encoder if you clone the EDID onto something else
15:35 karolherbst: I got some EVO timeout errors a few days ago
15:35 karolherbst: but not today
15:35 Lyude: not sure when I can take a look but could you also upload the edid blob for that display somewhere so I can try it with the chamelium?
15:35 karolherbst: yeah
15:40 pendingchaos: imirkin: would you prefer putting the h1 flags in the modifiers or the subop?
16:39 karolherbst: Lyude: I get a "nouveau 0000:01:00.0: disp: 0x00006341[0]: INIT_GENERIC_CONDITON: unknown 0x07" though, so maybe that's kind of related
16:40 Lyude: no, afaik that's just a hotplug event from ACPI for the nv gpu
16:40 Lyude: it's so we know when to wake up the gpu to reprobe for outputs
16:42 karolherbst: ahh, okay
16:44 karolherbst: Lyude: a 1920x1080 mode works
16:44 karolherbst: 1920x1080i causes those weird issues
16:44 Lyude: ahhhh
16:44 Lyude: that makes sense
16:44 Lyude: (additionally, non-interlaced is always better anyhow...)
16:45 Lyude: it may be just that we don't handle interlacing properly
16:45 Lyude: and additionally; maybe it doesn't default to interlacing on hdmi?
16:46 karolherbst: all interlaced modes cause those issues btw, refresh rate doesn't seem to matter
16:46 karolherbst: I have 720x576i and 720x480i which I will test now
16:46 karolherbst: yeah, same issues
16:47 karolherbst: Lyude: mhhh, let me see
16:48 karolherbst: Lyude: it does, but it works with HDMI
16:48 Lyude: Huh.
16:48 karolherbst: mhhh
16:49 karolherbst: weird
16:49 karolherbst: I have less modes with HDMI
16:49 Lyude: karolherbst: they might be getting pruned
16:49 karolherbst: might be
16:49 Lyude: enable KMS debugging to learn more
16:50 Lyude: hm, dp says there's a special bit in the video stream that needs to be set for interlacing
16:50 karolherbst: :)
16:51 karolherbst: quick patch?
16:51 Lyude: oh no; i mean I'm just looking at specs
16:51 Lyude: i'm not sure how one would actually configure that with evo
16:51 Lyude: i need to read a bit more into how the nv50 disp code works tbh
16:52 Lyude: best bet is probably to look at where we try to enable interlacing though, and see if the codepath we follow is any different between displayport and HDMI
16:53 karolherbst: yeah
16:53 karolherbst: that is my hope as well
16:53 Lyude: otherwise, maybe just compare what evo does on the blob vs. nouveau
16:54 karolherbst: Lyude: evo_data(push, m->interlace ? 0x00000002 : 0x00000000);
16:54 karolherbst: in nouveau/dispnv50/head507d.c
16:54 karolherbst: mhhh
16:54 karolherbst: maybe breaking it for HDMI is a good first step understanding that stuff :D
17:05 karolherbst: Lyude: mhh, when breaking it for HDMI, the output is simply weirdly scaled
17:06 karolherbst: but maybe that helps somehow
17:06 Lyude: Does anyone know of (or if there even is one) what the proper way to allow nested pm_runtime_get() calls in the suspend/resume is?
17:06 Lyude: karolherbst: did you see if we're actually setting the interlaced bit for DP?
17:06 karolherbst: not yet
17:10 azaki: karolherbst: should i just open a bug report to upload the shader dumps as an attachment?
17:10 karolherbst: azaki: no, you can't really share them publicly
17:10 karolherbst: so email to me would be best I guess
17:11 karolherbst: use karolherbst@gmail.com
17:11 karolherbst: azaki: did you also create an apitrace?
17:11 karolherbst: because that might help us fix the issue in nouveau
17:12 azaki: not yet, but i'm about to do that, i was curious about the syntax of that command. also not sure if i need to use the 32bit or 64bit one. i *think* eso runs as 32bit, but it does include a 64bit version so i'd have to check
17:12 azaki: steam is only 32bit though
17:13 azaki: apitrace trace --api gl wine Steam.exe or something?
17:13 karolherbst: Lyude: mhh, we enable it for DP as it is the same code
17:13 karolherbst: Lyude: and if we don't set that bit, DP and HDMI have exactly the same output
17:14 Lyude: hm, that makes me think there might be a different bit we might need to set for interlacing on DP
17:14 Lyude: time to start poking bits?
17:17 karolherbst: I crashed the GPU :(
17:38 Lyude: does anyone know if Lukas Wunner is on irc?
17:38 Lyude: i wonder if they might be able to answer some questions I've got about runtime suspend/resume
17:39 Lyude:is still having some trouble figuring out a clean way to make i2c/aux wake up the GPU without grabbing RPM refs in the suspend/resume path
17:42 karolherbst: Lyude: ohhh we have those display related header files
17:42 karolherbst: yay
17:42 karolherbst: Lyude: #define NV907D_CORE_NOTIFIER_3_CAPABILITIES_CAP_SOR0_20_DP_INTERLACE 26:26
17:43 Lyude: ahhh, nice
17:43 Lyude: so is it possible we're not able to do interlacing on DP with this chipset, and we're just not checking the cap file for it?
17:43 karolherbst: maybe?
17:46 karolherbst: Lyude: but I am sure I get those interlace modes with nvidia
17:46 karolherbst: Lyude: that bit we set for interlaced vs progressive seems correct though
17:54 azaki: crap, it's running as 64bit. lol
17:54 karolherbst: azaki: so?
17:55 karolherbst: apitrace should just dump the traces
17:55 karolherbst: but mhh
17:55 karolherbst: you might want to execute the game directly
17:55 karolherbst: allthough with steam this is all a bit super ugly
17:55 azaki: yeah, that's what i was thinking. because of steamworks
17:55 karolherbst: but
17:56 karolherbst: steam isn't really the painful part here, but wine _and_ steam
17:56 azaki: hopefully it works well when i launch directly
17:56 karolherbst: yeah...
17:56 karolherbst: but make sure steam isn't running
17:56 karolherbst: otherwise the process jsut quit and steam starts it
17:57 azaki: hm, ok.
17:58 karolherbst: Lyude: ohh crap... the hardware cap indeedd says no interlace
17:58 azaki: apitrace trace --api gl wine eso64.exe
17:58 azaki: that looks good?
17:58 azaki: or should i be adding other arguments to apitrace
17:58 karolherbst: no
17:58 karolherbst: normally you don't even need to specify --api gl
17:58 Lyude: karolherbst: in that case the bug is that nouveau isn't pruning the interlace modes
17:59 karolherbst: Lyude: but I was under the impression that nvidia exposes interlaced modes...
17:59 karolherbst: let me check
18:00 karolherbst: ohhh crap
18:00 karolherbst: no interlaced modes with nvidia :)
18:03 karolherbst: Lyude: would you know where I need to add such things?
18:03 karolherbst: I mean the drm bits
18:03 karolherbst: for rejecting the mode
18:03 Lyude: karolherbst: good question! let me see
18:06 Lyude: so it looks like drm does the mode pruning depending on what drm_encoder_slave_funcs->mode_valid returns
18:07 Lyude: karolherbst: nouveau_connector.c:nouveau_connector_mode_valid()
18:07 karolherbst: ahh nice
18:07 Lyude: also feel free to cc the patch to me and I'll be happy to review
18:08 karolherbst: :)
18:08 karolherbst: yeah, this sounds like super easy to fix
18:09 karolherbst: wondering why that didn't came up until now :)
18:09 Lyude: because interlace is poop and I would hope most setups default to disabling it
18:10 karolherbst: well
18:10 karolherbst: TV screens use it by default afaik
18:10 Lyude: older ones do
18:10 Lyude: it's not really needed for anything that isn't analog afaik
18:11 karolherbst: ahhh
18:11 Lyude: same kind of situation as overscan: it's not actually needed or even supported by most devices, but they enable it anyway :)(
18:11 Lyude: *:)
18:11 karolherbst: mhh
18:11 karolherbst: I know that there are 4k displays which expose mode with insane clock requiernments
18:12 karolherbst: and sometimes you need to use the reduced 4k mode to get it to work
18:12 karolherbst: but I don't even konw what all that means anyway
18:29 karolherbst: Lyude: mhhh, it doesn't seem like we care about those caps at all
18:29 karolherbst: we simply push those to EVO
18:30 karolherbst: I guess I will ask skeggsb_ on how we would like to implement something like that
18:35 azaki: is it normal for the trace to be several gigabytes in size? =o
18:35 azaki: i actually ran out of hard drive space, looks like i'm going to have to do it again
18:35 Lyude: i don't know what trace you're talking about but yes
18:35 pmoreau: Lyude: Lukas would be l1k IIRC, though he doesn’t seem to be around at the moment.
18:35 karolherbst: azaki: yes
18:35 Lyude: pmoreau: i actually got in contact with them over email, I will keep that in mind for the future though
18:36 karolherbst: azaki: reduce resolution, make _short_ traces
18:36 karolherbst: azaki: if the issue is visible, that is the time to stop the application :)
18:36 karolherbst: azaki: reducing graphic settings also helps
18:36 karolherbst: but reducing resoltuion the most
18:36 Lyude: ^ shorter traces also help make it clearer where the interesting bits are for developers
18:36 azaki: the settings are already super low, and it's in windowed mode. but i did stay in game for too long probably.
18:37 azaki: so this time i'll just login and quit after seeing the issue
18:37 pmoreau: Lyude: Okay; good luck with solving those pm reference leaks, it seems to be quite hard to get right, given there has been a few series to solve it over the years. :-)
18:37 karolherbst: yeah
18:37 Lyude: pmoreau: yeah; one of the big questions on my mind is: "why the heck don't we just turn get/puts() for runtime power management in the context of the runtime suspend/resume thread into noops by default?"
18:38 karolherbst: Lyude: the thing is, we already know what's wrong and how to fix it :)
18:38 Lyude: karolherbst: well we only know the first half, actually
18:38 karolherbst: Lyude: why?
18:38 Lyude: I -thought- we knew the second half but we don't
18:38 Lyude: karolherbst: see lukas's responses to my patches
18:38 karolherbst: I meant azakis issue
18:39 Lyude: OH
18:39 Lyude: sorry we are talking different issues
18:39 karolherbst: the trace is just for testing stuff
18:39 karolherbst: well I _hope_ wine didn't mess up though
18:39 karolherbst: Lyude: bug is: d3d10 allows 128 sampler views and with opengl we only expose 32
18:39 karolherbst: so bad things happen if a game uses more
18:39 Lyude: yikes
18:40 karolherbst: possible fixes: bindless_textures inside wine or driver exposes 128 samplers
18:41 karolherbst: azaki: I really hope there is no wine bug causing the OpenGL code to be buggy. But if wine is actually buggy as well, you might need to trace it with a windows version of apitrace and trace the d3d calls....
18:41 karolherbst: which is where the fun really starts
19:43 karolherbst: Lyude: ohh there is even MODE_NO_INTERLACE
19:43 Lyude: karolherbst: yep
19:45 karolherbst: Lyude: is the nouveau_encoder object the actual thing storing the limits of the port?
19:45 karolherbst: or does it already take into account what hardware is conncted?
19:45 Lyude: karolherbst: i am not sure, but I'm in a meeting so I will get back to you on that in a bit
19:47 karolherbst: mhh link_bw is filled from vbios values
19:47 karolherbst: and link_nr as well
19:51 karolherbst: ahh, nv_encoder->dcb->dpconf.link_nr are the bios limits
19:51 karolherbst: nv_encoder->dp.link_nr what the port provides in relation to the display
19:56 Lyude: ok back
20:03 karolherbst: Lyude: current fix: https://github.com/karolherbst/nouveau/commit/3a22baf0b96b23651d477fcba0dc67b8754111c4
20:04 Lyude: hm, that might not be the right spot to set that cap
20:04 karolherbst: yeah
20:04 karolherbst: I know
20:05 karolherbst: but I can give that to skeggsb_ and he tells me what is wrong with it :p
20:05 Lyude: nouveau_dp_detect() is called when we detect the connector, we probably want it somewhere in the vbios?
20:05 Lyude: ah, lol
20:05 Lyude: *vbios parsing
20:05 karolherbst: well
20:05 karolherbst: is there a vbios flag for that?
20:05 Lyude: sorry-I assumed that's where this info was coming from
20:05 karolherbst: and anyway, why trust the vbios if the hw can tell us anyway?
20:05 Lyude: if not then, sec...
20:05 karolherbst: it is from the reg :)
20:06 karolherbst: 0x61c000
20:06 Lyude: ahhh
20:06 karolherbst: uhm... well
20:06 karolherbst: no, 0x61c000 isn't correct as I have to index the correct one
20:06 karolherbst: 0x61c000 + i * 0x800
20:06 karolherbst: 0x61c000 contains the caps of sor0
20:06 karolherbst: it should be somewhere inside the sor object in the end
20:08 Lyude: ahh, yeah, skeggsb will probably know better than I where that should go
20:08 Lyude: otherwise the patch makes sense
20:09 karolherbst: maybe the EVO timeout was related to setting the interlacing bit and sometimes this just totally messes up the evo
20:09 karolherbst: so ...
20:10 Lyude: if the evo isn't expecting that to get set then yeah maybe
20:20 skeggsb_: you should actually be getting an error from EVO if you try to enable interlacing and the cap isn't supported, not just a hang
20:21 angrydev: hey guys, i'm getting SCHED_ERRORs a few times a day that sometimes lock up my system (gnome/gentoo) and was wondering if i could get pointed in the right direction
20:21 angrydev: NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1) and kernel 4.16.18
20:23 karolherbst: skeggsb_: well, didn't I show you the video?
20:23 karolherbst: angrydev: yeah... kind of known to happen on some kepler cards
20:23 karolherbst: skeggsb_: basically the output is just out of sync or something
20:24 karolherbst: skeggsb_: anyway, there is a flag on the SOR CAP register telling us if we are able to do interlacing or not
20:24 skeggsb_: yes, i'm aware. and we load those onto evo too, which is supposed to error-check it
20:24 karolherbst: well
20:24 karolherbst: we need to reject the mode
20:25 karolherbst: like it shouldn't even be available to userspace
20:25 angrydev: karolherbst: thanks, that's unfortunate. are there any knobs available to me that i can turn to try to reduce the chance of them happening?
20:25 karolherbst: angrydev: using nvidias context switching firmware
20:26 karolherbst: skeggsb_: so something like that, just in cleaner and better: https://github.com/karolherbst/nouveau/commit/3a22baf0b96b23651d477fcba0dc67b8754111c4
20:26 karolherbst: and I think we might want to validate more stuff inside nouveau_connector_mode_valid
20:26 angrydev: karolherbst: is this the page i want to read? https://nouveau.freedesktop.org/wiki/NVC0_Firmware/
20:27 karolherbst: angrydev: kind of, but there is something else
20:27 angrydev: karolherbst: or is it the firmware section of this page: https://nouveau.freedesktop.org/wiki/VideoAcceleration/
20:29 skeggsb_: karolherbst: yes, more could be done there indeed
20:30 skeggsb_: i'll look better at the patch shortly, sorting out a customer bug before a meeting
20:30 karolherbst: ahh, okay
20:31 karolherbst: angrydev: I think there was something somewhere
20:40 angrydev: do you guys have any suggestions on a card that would be relatively stable and support 3+ outputs?
20:41 karolherbst: angrydev: depends on what driver you want to use ;)
20:42 angrydev: karolherbst: ha well nouveau for the sake of this discussion :)
20:42 angrydev: karolherbst: i'd like to stay away from the proprietary drivers and i don't have any experience with amd/ati so not those
20:42 karolherbst: yeah well, the thing is, if you plan to buy a new GPU anyway, you are probably better off with vendors which support open drivers
20:43 angrydev: is the situation much better with amd/ati?
20:43 karolherbst: yes
20:43 angrydev: ah
20:43 karolherbst: vendor support
20:43 angrydev: did not know that
20:43 karolherbst: they kind of move towards making everything open source
20:43 Lyude: yeah, nvidia doesn't like working with open source
20:43 Lyude: intel is very good too, but it wouldn't support more then 3 outputs
20:43 karolherbst: angrydev: amd has still some closed business/enterprise driver thingy, but nobody in their right mind would use that ;)
20:44 Lyude: and you don't really need to use it in most cases
20:44 karolherbst: their compute stack is also open source (ROCm)
20:44 Lyude: the performance difference is usually marginal, and in some cases we've performed better then they do
20:44 karolherbst: I think it is usually slower, no?
20:44 karolherbst: :D
20:44 Lyude: theirs?
20:44 karolherbst: I mean the closed one
20:44 karolherbst: yes
20:44 Lyude: yeah it was at one point, I'm not sure what the current status of that is
20:44 Lyude: go radv \o/
20:44 angrydev: thanks guys
20:45 karolherbst: latest benchmarks were like: closed one is sometimes 5% faster, but if the open is faster, then like 30%
20:45 Lyude: that sounds about right
20:45 karolherbst: yeah
20:45 angrydev: this is my office workstation running gnome/gentoo, no games, and i have three monitors
20:45 karolherbst: yeah well
20:45 karolherbst: we try to make nouveau run stable on such setups at least
20:45 Lyude: angrydev: heck, any intel GPU should work with that. nouveau as well
20:45 karolherbst: performance is always difficult to achieve if you have no idea what the GPU likes and what not :)
20:45 Lyude: so long as you are not looking for A Maximum Gaming Experience
20:45 angrydev: just can't escape these SCHED_ERRORs i've been getting for a while now
20:45 karolherbst: Lyude: stability ;)
20:46 karolherbst: yeah, exactly that
20:46 Lyude: karolherbst: tbh we should be able to keep it stable... most of it at least
20:46 karolherbst: we would like to fix all the issues, but... sometimes that simply doesn't work out
20:46 angrydev: not a huge problem, but maybe once a day i have to kill -3 gnome-shell
20:46 Lyude: that's what i'm paid for anyway
20:46 karolherbst: so bugs affecting more users are kind of fixed first than bugs happening one a few models
20:47 angrydev: i understand that i may never get away from them with this card
20:53 angrydev: anyway i appreciate the help guys, thanks for giving me some background on the card
22:42 azaki: finally got that apitrace compressed. i was trying with xz -ze9 and it was taking forever, i just decided to use default compression level. =p
22:42 azaki: karolherbst: i just sent the email.
22:43 azaki: it has both the shader dump and the apitrace.
22:55 karolherbst: azaki: seems like I didn't got anything
22:56 karolherbst: maybe the email bounced due to its size?
23:00 azaki: hm, we're both using gmail, so i dunno why. the apitrace was compressed too, it's just a few KBs
23:00 azaki: err
23:00 azaki: i mean the shader dump was just a few KBs
23:00 azaki: the apitrace is a google drive link
23:01 karolherbst: ohh wait, I checked the wrong email
23:02 azaki: oh, ok.
23:02 azaki: i used the one you had given earlier
23:02 karolherbst: sure and I checked my company emails :)