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