00:01 Lyude: karolherbst: "specified in a specification" from my experience of trying to write an irc client ages ago: yes, but literally no one follows that spec lol
00:01 Lyude: basically every ircd has a slightly different protocol, but it's similar enough across ircds that clients can handle the exceptions usually
00:02 Lyude: irc as a protocol is a much bigger mess then it might seem from a glance
00:02 Lyude: it's been years since then though, so I can't remember any of those exceptions off the top of my head
00:02 Lyude: I know unreal ircd has some stuff that inspircd doesn't, same with ratbox based daemons, etc...
00:32 mooch2: tbh i don't know why the fuck nobody's adopting ircv3
00:32 mooch2: it's been around for a WHILE
00:32 Lyude: it's being adopted
00:32 Lyude: it's just, not enouguh
00:32 Lyude: *enough
00:33 Lyude: afaik I know elemental ircd had support for it (so also shadowircd and charybdis, not sure which of those two are even active anymore...)
00:33 mooch2: no i meanb
00:33 mooch2: *mean
00:33 mooch2: actual BIG networks adopting it
00:34 Lyude: does ircd-seven (freenode's ircd) not have it? I would have thought it would since it's ratbox based...
00:34 Lyude: or whatever their ircd thing is
00:35 Lyude: otherwise it's just a matter of networks actually updating their ircds
00:35 Lyude: which, boy I /really/ hope they do that.
00:36 mooch2: oh, apparently, freenode barely supports ANY of ircv3
00:36 mooch2: at least, according to this https://ircv3.net/support/networks.html
00:37 mooch2: and it also seems that no current network supports ALL of ircv3
00:37 mooch2: it's really sad tbh
00:37 Lyude: tbh: irc just needs to be replaced
00:38 mooch2: yeah :/
00:38 mooch2: though if we could extend it with shit like voice chat, that would be KILLER
00:38 mooch2: though that would be a MASSIVE hack
00:38 Lyude: oh lord that's definitely not happening
00:40 mooch2: why?
00:40 mooch2: all the competitors have it
00:40 Lyude: tbh: it's better explained by looking at the source code of basically any modern irc client or daemon
00:41 mooch2: okay, fair enough, they're probably all messes anyway :/
00:42 Lyude: yeah it's really bad
00:43 Lyude: i don't know if hexchat changed this, but back in xchat the standard for passing variable length strings to functions was to make a function that took a va_args that had each entry as a single char
00:43 Lyude: /////bad/////
00:58 mooch2: oh GOD
01:26 nyef: Voice chat over IRC? Wasn't that a thing that absolutely hammered IRC networks for a bit about a quarter-century ago, until the voice software people got their own networks?
07:36 karolherbst: mhh, we have some issues with GL_TRIANGLE_STRIP_ADJACENCY
07:38 karolherbst: llvmpipe as well though
07:38 karolherbst: or the test was written against intel and intel is wrong
08:25 karolherbst: mhh
08:25 karolherbst: I think the test is wrong actually
12:41 Tron42: Hi! I was reading throught the documentation, I have a Nvidia GT 730 card, and I don't get what codename it is (NVE0 or NVC0)
12:42 Tron42: In the NVE0 list there is the geforce GT 730M, but maybe is different from the geforce GT 730 (without M) that I own
12:48 karolherbst: Tron42: check lspci
12:48 karolherbst: or dmesg if nouveau is loaded
12:49 Tron42: lspci: 01:00.1 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1)
12:51 karolherbst: Tron42: that's a nv108 then
12:52 karolherbst: Tron42: do you know if DDR3 or GDDR5?
12:52 Tron42: ok thank you
12:52 Tron42: It's a GDDR5, 1gb
12:52 karolherbst: nice
12:53 Tron42: And it runs well with nouveau so far
12:55 Tron42: I am trying to tweak the clock with power management to improve performance
12:57 karolherbst: Tron42: yeah, you should :p
12:58 karolherbst: Tron42: you can also boot with nouveau.config=NvBoost=2 to increase it even more (if you don't reach the max clocks)
12:58 karolherbst: but more heat and nouveau doesn't really check if the GPU gets too hot
12:58 karolherbst: (well the GPU does and shutsdown at some point)
13:02 Tron42: karolherbst: there is some man page or documentation about power management somwhere? Because I am struggling to understand where to start
13:03 karolherbst: Tron42: check the /sys/kernel/debug/dri/0/pstate file
13:03 karolherbst: that's basically everything we have right now
13:04 karolherbst: well, we also have that nouveau.config=NvPmEnableGating=1 thing to reduce power consumption
13:04 karolherbst: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/
13:08 Tron42: I see
13:09 Tron42: karolherbst: The values in the pstate file should be edited by hand?
13:11 karolherbst: Tron42: uhm, you can basically select on of the lines, except the last one
13:11 karolherbst: if you have 0f: ...
13:12 karolherbst: you can echo f into pstate
13:12 karolherbst: and then this state is selected
13:12 Tron42: I have 07, 0f and AC. 07 and AC are identical, and in 0f I have the top performance I guess
13:13 karolherbst: yeah
13:13 karolherbst: the last line shows the current state
13:13 karolherbst: AC/DC depending on if the power supply is connected (on laptops)
13:13 karolherbst: and then the clocks
13:17 Tron42: So if I understand I change the last line (AC) with the values that are in 07 (the ones I want)?
13:18 karolherbst: you don't change anything
13:18 karolherbst: you just write into it
13:18 karolherbst: it isn't a fail as a file on your disc
13:18 karolherbst: *file
13:18 karolherbst: just echo f or 7 into it
13:19 karolherbst: and then it does the stuff
13:20 Tron42: Oh I see great it worked
13:21 Tron42: thanks you so much!
14:23 karolherbst: imirkin: that breaks images on kepler1: https://github.com/karolherbst/mesa/commit/805d885364351d2cf2e873c710baa8f9ba91e815
14:23 karolherbst: :(
14:24 karolherbst: but
14:24 karolherbst: KHR-GL45.shader_image_load_store.non-layered_binding is still fixed by it on kepler
14:26 karolherbst: ohh, maybe it is the other part of the patch breaking it, not the tile size
14:29 karolherbst: ohh.. meh
15:42 karolherbst: imirkin: mhh, it seems like when accesing z != 0 something messes up. Any idea why a 0 z tiling might break on kepler, but not on maxwell?
17:22 RSpliet: Oh that's not merged for Kepler2 yet :-C
17:23 RSpliet: s/that/gating/
20:33 Lyude: hm; so if we have to abort the runtime suspend process in nouveau_pmops_runtime_suspend() after nouveau_switcheroo_optimus_dsm() has been called, does anyone know if there is some sort of cleanup function we need to call to reverse the effect of nouveau_switcheroo_optimus_dsm()? i'm not actually really clear on what that supposedly does
20:35 Lyude: ( karolherbst maybe?)
20:35 karolherbst: Lyude: basically the stuff we do in resume
20:35 karolherbst: the DSM stuff is a bit annoying though
20:36 karolherbst: Lyude: I suppose we should complete the suspend stuff though and just wake up again
20:36 karolherbst: but uhm
20:36 karolherbst: Lyude: for what reasons do we have to abort it?
20:37 Lyude: karolherbst: see the comments on https://patchwork.freedesktop.org/patch/242164/
20:37 Lyude: i'm also thinking we could just take the easy way out and disable hotplugging /before/ we call dsm, as I'm not sure it really matters if we do it earlier
20:38 karolherbst: meh
20:38 karolherbst: we shouldn't have to deal with that
20:38 Lyude: a bug is a bug
20:39 karolherbst: no I mean
20:39 karolherbst: _we_ as in nouveau shouldn't have to deal with that
20:39 Lyude: well yeah... that's why I'm trying to add fb_helpers for this
20:39 karolherbst: if anything wants to resume the GPU, we just do a full suspend/resume cycle
20:39 karolherbst: and handle that inside the runpm code itself
20:39 karolherbst: or somewhere else
20:40 karolherbst: Lyude: I mean, how does hotplugging works after suspending the GPU anyway?
20:40 Lyude: karolherbst: the thing is in order to make the locking less insane with that patch series, we add a fb_helper function that literally tells fbcon to stop paying attention to hotplug events until we say otherwise so that it can't try to do a modeset an deadlock us
20:40 Lyude: karolherbst: so there's two kinds of hpd on prime laptops: acpi and normal nv hpd
20:40 karolherbst: okay.. so we would get an ACPI trigger
20:40 Lyude: Ideally what I want nouveau to do eventually is to keep acpi hotplugging disabled during normal runtime, and enable it /right/ before we disable nv hotplugging
20:40 karolherbst: mhhh
20:40 karolherbst: still allows racy stuff
20:41 karolherbst: Lyude: is the ACPI stuff always on?
20:42 Lyude: karolherbst: yes; although I'd like it to only be on when we don't have normal hotplug detection https://patchwork.freedesktop.org/patch/241659/ . In that series we enable it right before disabling normal HPDs, so if a hotplug happens mid-disable it will still have an acpi handler queued up that will wake the GPU back up
20:42 karolherbst: okay
20:42 karolherbst: so yeah
20:43 karolherbst: we basically should enable that ACPI stuff, disable everything else and ignore any kind of non ACPI interrupts we get
20:43 karolherbst: if we are suspending, we don't care
20:43 Lyude: no, we actually do care
20:43 karolherbst: why would we?
20:44 karolherbst: aborting the suspend calls for trouble
20:44 karolherbst: I mean, in the end we want to enable the ACPI triggers _before_ calling into runtime_suspend
20:44 Lyude: karolherbst: so: you should take a look at the fb_helper stuff that i had to add first
20:45 karolherbst: so when runtime_suspend is called, we simply assume we suspend for real and don't get bothered
20:45 Lyude: basically; one of the things causing problems was the fact that we needed to be able to disable hotplugging, but fbcon could potentially try to do a modeset if a hotplug happened (which is more likely then you'd think) mid-runtime suspend. that would lead to fbcon trying to grab a runtime power reference to the GPU, while we waited on fbcon to finish up
20:45 Lyude: leading to deadlock
20:46 Lyude: i tried a bunch of different ways to fix it but the simplest one came down to "just tell fbcon not to do /anything/ in response to hotplugs after we call the new helper, drm_fb_helper_suspend_hotplug(). So if a hotplug does happen; it just gets delayed until we "resume" fb_helper's hotplugging in the runtime resume process
20:46 karolherbst: yeah, that's why I have the idea that when runtime_Suspend is called, it is safe to suspend and nothing is allowed to actually get a reference causing an abort
20:46 Lyude: but----that leaves one spot
20:46 karolherbst: we need to continue suspending
20:46 karolherbst: and just wake up again
20:46 karolherbst: otherwise things will get insane
20:47 karolherbst: the runpm stuff sets the state to SUSPENDING or something
20:47 Lyude: karolherbst: not exactly... all you really need to do is disable the stuff like this which could cause us to wake up first before doing anything else
20:47 Lyude: karolherbst: no; it's OK to abort runtime suspend
20:47 Lyude: if you return -EBUSY it just reschedules
20:48 Lyude: so the trick is to just do the reversable no-risk stuff first, then do the stuff we can't take back after we're sure we're past the point of potential wakeups
20:48 karolherbst: okay sure, but that is basically the idea of having something done _before_ runtime_suspend
20:48 Lyude: at which point we have ACPI hotplugging, which will wake up the GPU afterwards if a hotplug happened after the no-take-back period
20:48 karolherbst: and runtime_suspend is that critical part
20:48 karolherbst: I mean, it doesn't need to be a new runpm callback
20:48 karolherbst: we could do that in drm or somewhere with helper
20:48 karolherbst: and drivers get two callbacks
20:49 karolherbst: or whatever
20:49 karolherbst: but we kind of have to enforce that split
20:49 Lyude: karolherbst: there isn't any new callbacks being added... right now the current abort code for fbcon is just this: https://patchwork.freedesktop.org/patch/242159/
20:49 karolherbst: and tell the driver: here is stuff which could abort the suspending or has to put the driver into a state where it can't back off anymore
20:49 karolherbst: I am more thinking about how things should be
20:49 Lyude: like, there's literally almost no sane way to stop fbcon if it tries to initiate a modeset before we manage to turn off hpd
20:50 Lyude: we'd need to fix locking there first, which would be very nice but...
20:50 Lyude: keep in mind: that drm_fb_helper_suspend_hotplug() call happens before we've even started suspending anything
20:51 karolherbst: sure
20:51 karolherbst: Lyude: but how do we abort after calling into it?
20:51 karolherbst: or is that already handled inside?
20:51 karolherbst: and if drm_fb_helper_suspend_hotplug returns it is safe to continue?
20:52 Lyude: karolherbst: it's magically handled inside. We do mutex_trylock() on fbcon so there's no risk of potentially deadlocking with it, but we still get a chance to block fb_helper and disable normal hotplug operations for it so then calls to drm_fb_helper_hotplug_event() that happen after we finish up with drm_fb_helper_suspend_hotplug() don't do anything but set delayed_hotplug
20:53 Lyude: so drm_fb_helper_suspend_hotplug() does and tries mutex_trylock() on fb_helper, if that fails we abort, if it succeeds we set fb_helper->hotplug_suspended which prevents fbcon from doing anything in response to hotplugs from that point forward
20:54 Lyude: "that point forward" is the part that we need to figure out now, which really should be fairly simple. Go through the process of switching from normal nv hpd to ACPI HPD, then when we've finished up disabling nv hpd check one last time to see if there's a delayed hotplug now, and re-enable hpd and don't suspend in that case. otherwise suspend, and any hotplug that happen after that point will just get picked
20:54 Lyude: up by acpi
20:55 karolherbst: Lyude: uhm, isn't that "if (fb_helper->deferred_setup) {" inside drm_fb_helper_hotplug_event a bit risky, because the lock ins't unlocked?
20:55 Lyude: which; i'm going to add another fb_helper for of course
20:55 karolherbst: mhhh
20:56 Lyude: karolherbst: no; it's fine. deferred_setup just means the driver hasn't initialized fbcon yet, so in that case it goes and initializes it then unlocks and returns
20:56 karolherbst: okay
20:57 Lyude: now you see why this has taken me so long to fix, hehe...
20:57 karolherbst: okay so yeah, double checked locking pattern. Always a bit ugly and silly, but in the end I doubt we really get around it
20:57 karolherbst: I was just wishing to deal with all that dirty stuff outside of the actual drm drivers
20:57 karolherbst: as every driver basically needs to do the same anyway
20:57 karolherbst: even non drm drivers
20:57 Lyude: yeah, that's why I'm trying to add all of the fb_helper stuff. eventually I'd like to have just one callback for switching over hpd
20:58 karolherbst: no, I mean, all non drm drivers also follow the same pattern
20:58 karolherbst: 1. enable fallback ACPI events 2. disable native events 3. recheck for incomming events 4. suspend
20:59 Lyude: karolherbst: yep; that's what I'd like to eventually stick in a single drm helper. So you just provide a callback to disable non-acpi hotplugging, and DRM handles calling things in the right order and checking for events in the middle
20:59 Lyude: that will probably happen when I go and fix the hacks I have in amdgpu to workaround this
20:59 karolherbst: I am wondering if we actually should change the runpm stuff itself
20:59 Lyude: sigh.... i've tried
20:59 karolherbst: yeah.. I know the code
21:00 karolherbst: but that recheck for events could be an actual refcount check
21:00 Lyude: karolherbst: i'm also planning on fixing the i2c/aux stuff by just handling it from drm btw
21:00 karolherbst: and then you could handle the reverting stuff in runpm itself
21:01 Lyude: karolherbst: well the thing is the point where we can deadlock with fb_helper isn't after it's gotten an rpm reference, it's always as it's waiting for one
21:01 Lyude: i have a diagram for just this occasion, one moment!
21:01 karolherbst: right, and that is fine I think if we reorder responsibilities
21:02 karolherbst: mhh but yeah, driver internal stuff shouldn
21:02 karolherbst: 't deadlock
21:02 karolherbst: ohhh, I know
21:02 Lyude: karolherbst: jfyi https://lkml.org/lkml/2018/7/19/997 to make sure we're on the same page
21:02 karolherbst: Lyude: while rinpm suspends, it should increase the refcount and let everything trying to get a refcount wait
21:02 karolherbst: *runpm
21:03 Lyude: karolherbst: that's the problem though
21:03 Lyude: runpm already does that, which is why we deadlock
21:03 Lyude: because then we can't stop fb_helper as it's waiting for a refcount, but we're waiting on fb_helper so we can finish suspending
21:03 karolherbst: yeah, but runpm doesn't do the sane disable stuff/cleanup/revert thing
21:04 karolherbst: but mhh
21:04 karolherbst: maybe what I have in mind would be quite complicated as well
21:05 Lyude: yeah... if we did add something like what you're describing I think it'd look like this: do hpd switchover. Then before we go to drm_kms_poll_disable() (where the deadlock happens), we first call something like pm_runtime_suspend_interrupted()
21:06 karolherbst: yeah
21:06 karolherbst: bascially
21:06 Lyude: except, gah: then we could still deadlock if it tried to grab a ref after we called pm_runtime_suspend_interrupted()
21:06 Lyude: whatever the barrier is has to be a single call
21:06 karolherbst: well, we kind of want more decoupling here I think
21:06 karolherbst: maybe
21:06 karolherbst: dunno
21:07 karolherbst: I mean, runtime_suspend actually does two things
21:07 karolherbst: preparing for suspend _and_ suspending
21:08 karolherbst: Lyude: we could maybe do the preparation stuff without getting a ref?
21:08 karolherbst: and just before we actually do the suspend, we check for new events/last_use and abort/rollback if needed
21:09 karolherbst: but mhh
21:09 Lyude: karolherbst: well remember when we're in runtime_suspend we don't actually have references
21:09 Lyude: we're considered a "pending request"
21:09 Lyude: which resume requests have to wait for
21:09 karolherbst: yeah, but the point is, when calling runtime_suspend it isn't actually safe to call runtime_suspend
21:10 karolherbst: and this kind of sounds like a design issue to me
21:10 karolherbst: or the runpm stuff simply states it isn't allowed to get a ref while runtime_suspend is getting called
21:11 karolherbst: I mean, in the end it would make sense to just say it is a driver bug when the refcount would be increased inside runtime_suspend
21:11 Lyude: well no; again the deadlock happens because fbcon is "waiting for a ref" e.g. calling down to runtime_resume which waits on the previous suspend requst to finish before queueing up a resume request, while we're in the ->runtime_suspend() waiting for fbcon to finsih
21:12 karolherbst: right, but the thing is runtime_suspend() -> fbcon stuff() -> taking a ref
21:12 karolherbst: but just imagine this would be "not allowed" to take the ref at all inside runtime_suspend
21:12 Lyude: but fbcon stuff() is happening in a different thread!
21:12 Lyude: so it's not happening in runtime_suspend
21:12 karolherbst: ohhhh
21:13 karolherbst: okay yeah, then it gets ugly
21:13 Lyude: that's why I had the diagram, it's really ugly :P
21:14 karolherbst: but uhm, who triggers that thread?
21:15 Lyude: a hotplug! if one of the hpd's nvif_notify entries goes off before we get a chance to disable it, and it detects a connector change, then it calls down to drm_fb_helper_output_poll_changed() which then calls down to the fb_helper poller, which then attempts to detect and if it finds something new, tries to do the atomic commit which is the spot where it ensures it's demise by calling pm_runtime_get_sync()
21:16 karolherbst: okay right
21:16 Lyude: the thing is too I'd rather have anything that fb_helper is doing that could change display state disabled before we suspend display state; because anything else will put us in a fucky state
21:19 Lyude: So, now with those patches the process looks like this: disable fb_helper hotplug work at the very start if possible. If it's possible, we start (what is currently, at least in that version of the patchset) the no-take-backs part of the suspend process. But then since we currently disable hpd in the no-take-backs portion of the suspend process, and fb_helper has it's connector probing suspended by us, then a
21:19 Lyude: delayed hotplug in fb_helper will just stay delayed until we resume
21:20 Lyude: which is the last part we'd need to fix: instead of disabling HPDs in that part, move it to before the DSM calls and then call a new fb_helper to check if fb_helper has a delayed hotplug, so then we can go re-enable normal HPD and handle that hotplug before it's too late
21:20 karolherbst: yeah
21:21 karolherbst: we should move everythign before the DSM stuff
21:21 karolherbst: _but_
21:21 karolherbst: ohh not
21:21 karolherbst: actually yes
21:21 karolherbst: we should move it
21:22 Lyude: i'm fine with that
21:22 karolherbst: actually nouveau_switcheroo_optimus_dsm should be called after do_suspend
21:23 karolherbst: soo
21:23 karolherbst: mhhh
21:23 karolherbst: actually
21:23 karolherbst: that all is stupid
21:23 karolherbst: thhe DSM stuff doesn't belong there
21:24 karolherbst: it should just go away and magically get handled inside pci+acpi
21:24 karolherbst: Lyude: we need a way to register those ACPI methods with the pci+acpi stuff
21:24 karolherbst: and just outsource that crap to them
21:24 karolherbst: :p
21:25 Lyude: karolherbst: mm, alright; for now though i'd rather like to get this part fixed first and deal with deduplicating the acpi suspend effort after
21:25 karolherbst: yeah
21:25 karolherbst: sounds good
21:25 Lyude: karolherbst: so; for the time being it would be OK to move the dsm stuff to be called after nouveau_do_suspend()?
21:26 karolherbst: Lyude: I mean in the end it would be a simple do_suspend_acpi_crap callback or something maybe
21:26 karolherbst: dunno
21:26 karolherbst: Lyude: yes
21:26 karolherbst: Lyude: or well
21:26 karolherbst: another thing
21:26 karolherbst: Lyude: we should move that pci_* stuff inside nouveau_switcheroo_optimus_dsm
21:27 karolherbst: and if optimus_skip_dsm is set, we don't do the pci calls at all
21:27 karolherbst: that might be already good enough
21:28 karolherbst: and we shouldn't do the D0 stuff as well on resume if we have _PR#
21:28 karolherbst: *_PR3
21:28 karolherbst: but yeah, this could actually wait
22:36 mooch2: does anybody know how i can enable reclocking on my gm107 if it's supported?
22:38 Lyude: cat /sys/kernel/debug/dri/*/pstate
22:38 Lyude: for available states
22:38 Lyude: write back the one you want with echo
22:38 Lyude: don't do it while under load
22:38 Lyude: or you'll be cursed
22:40 mooch2: no such file or directory :c
22:40 mooch2: and i know i'm using nouveau because i saw it when i booted
22:40 Lyude: mooch2: do you have /sys/kernel/debug/dri/0 _and_ /sys/kernel/debug/dri/1?
22:40 mooch2: yep
22:40 Lyude: did you check if pstate is in 1?
22:41 mooch2: ah, it is, but it isn't in 0
22:41 mooch2: thanks
22:41 Lyude: jfyi: 0 == intel/amd integrated, 1 == nvidia/amd dedicated
22:41 mooch2: sorry, i'm running with both igpu and dgpu enabled lol
22:41 Lyude: general rule of thumb for most laptops
22:41 mooch2: i know
22:41 mooch2: it's not a laptop tho
22:41 mooch2: it's a desktop
22:41 Lyude: ahhh
22:41 Lyude: same thing then :P
22:42 mooch2: uh, permission denied :/
22:42 mooch2: even as sudo
22:42 mooch2: *root
22:42 karolherbst: mooch2: sudo echo executes echo as root
22:42 karolherbst: not the write
22:42 karolherbst: so you write the output of your command into something as your user
22:42 mooch2: ah lol
22:43 mooch2: yeah, i already fixed it
22:43 mooch2: just did su -
22:43 karolherbst: people tend to use tee for that
22:43 mooch2: ctrl-d afterwards of course
22:43 mooch2: oh :/
22:43 mooch2: i don't know tee so lol
22:59 nyef: echo | sudo tee {file}