02:37 imirkin: glisse: ppc-be or le?
02:57 glisse: imirkin: oups little endian :)
02:57 glisse: enough issues with it being ppc
03:20 imirkin: hehe yeah
03:22 imirkin: glisse: anyways, i have nothing determinstic, but i'd guess it's some memory coherency issue
03:23 imirkin: e.g. if the uncached mappings aren't working as expected, etc
04:03 Kevlar_Noir: it's nouveau ?
04:03 imirkin: ?
05:53 rhyskidd: i've got hold of a nv96 and nvac to do some nouveau poking on
05:54 rhyskidd: local hardware, so i'm motivated to look at bugs anyone's reported on either of those ...
13:36 imirkin: rhyskidd: not specific to those, but try to repro https://bugs.freedesktop.org/show_bug.cgi?id=109330
18:48 pmoreau: rhyskidd: MacBook Pro 2009? Working external outputs would be nice. :-) There is this bug report https://bugs.freedesktop.org/show_bug.cgi?id=88272.
23:23 pendingchaos: karolherbst, imirkin: sent out a third version of the EXT_shader_image_load_formatted series: https://lists.freedesktop.org/archives/mesa-dev/2019-January/213641.html
23:24 HdkR: <3
23:27 karolherbst: is there a trade off using suld.p btw?
23:27 karolherbst: *of
23:29 pendingchaos: not that I know of
23:35 Lyude: skeggsb: where does nouveau set the link rate/lane count to be used for an MST topology?
23:38 Lyude: Oh. I see. Hm.
23:41 skeggsb: Lyude: i do have some plans to make that more explicit, and under control of the kms driver btw (more in line with what nvidia do)
23:41 Lyude: skeggsb: so do I!
23:41 skeggsb: it's tricky though, we handle some of that stuff very differently to their stack, and requires some subtle and tricky changes
23:42 Lyude: long story short: Apparently my weird TB3 hub is not the only one that will randomly change the reported link rate when it's not really supposed to, lenovo docks seem to do it under weird circumstances I don't yet understand
23:42 Lyude: which is causing issues since most drm drivers are happy-go-lucky with dpcd reads and just determine everything based off that, so if the hub changes it's link rate and there's more then one sink only one of them ends up getting updated to the new link rate
23:42 Lyude: which breaks the world etc etc
23:43 skeggsb: heh, yay DP
23:43 Lyude: anyway-I'm probably going to try to move the link rate/lane count that nouveau decides to use for MST (not SST though) into the actual atomic topology state, and do the same for i915
23:44 skeggsb: i'll be back a bit later, heading into the office to pick up some HW that got delivered
23:44 Lyude: that way it's impossible to have inconsistent link rates across the topology, and the link rate should be maintained through s/r cycles if the hub decides to be a smartass and change it mid-suspend
23:44 Lyude: alright
23:45 imirkin_: pendingchaos: awesome, will have a look tonight
23:46 karolherbst: skeggsb: do you have a moment to talk about how to handle the channel is dead notifications for currently released kernels (aka by writing patches we are able to get into stable branches)? my current apporach is to listen via poll on the nouveau_drm->fd, but that doesn't work if the same applications listens on page flibs on a different fd sadly. Any ideas? Or do we really have to use whatever new command submission API we want
23:46 karolherbst: to use in the future?
23:47 karolherbst: I mainly just want to get this stupid "X freezes beacuse nv hw channel is dead" issue fixed :/