12:42 karolherbst: tagr: maybe it would be worth using renderonly_create_kms_dumb_buffer_for_resource?
12:42 karolherbst: that's what kmsro is using for the scanout bits
12:43 karolherbst: but that doesn't do much.. so maybe wouldn't help
13:26 tagr: karolherbst: that should basically end up being the same as forcing linear via PIPE_BIND_LINEAR
13:26 karolherbst: ahh, okay
13:27 tagr: so I think it will end up running into exactly the same issues, just via a slightly different code path
13:27 karolherbst: yeah...
13:27 karolherbst: I talked with the etnaviv devs and they also detile
13:27 tagr: karolherbst: yeah, I vaguely recalled seeing the detile somewhere, though I couldn't find it when I last looked
13:28 tagr: karolherbst: when they do detile, they must end up with the same problems as we do with X, though
13:28 karolherbst: yes
13:28 karolherbst: for them X is just broken :)
13:28 karolherbst: and honestly.. I'd also just ignore X. Either we get 1.21 and it's fixed, or we never see it and X is EOL :p
13:29 karolherbst: in both cases, there is nothing have to do
13:29 karolherbst: not sure how important X is though for the use cases one might want to use tegra with... but that's something I'd sort out later...
13:30 karolherbst: tagr: I also opened a bug against mutter to allow kms-modifiers to be enabled for certain drivers: https://gitlab.gnome.org/GNOME/mutter/-/issues/1408
13:30 karolherbst: I also want to talk internally about it as even with your patch, the desktop feels way smoother with kms-modifier enabled
13:31 karolherbst: but maybe that would get resolved by doing less blits as mentioned on the MR
13:32 karolherbst: tagr: anyway... anything holding your mesa MR back?
13:33 karolherbst: I have some internal discussion on getting tegra to work out of the box with fedora 33, so I'd like to see something merged sooner or later :)
13:46 tagr: karolherbst: which MR? the detiling one? I may want to rev one patch to avoid an excess flush that I don't think is strictly necessary
13:46 tagr: karolherbst: other than that it's not terribly useful because, well, it really only enables the fallback for the case where we don't have modifiers
13:47 tagr: so it's bad from a performance point of view and the use-cases will likely be few
13:47 karolherbst: right... but that still makes mutter work by default
13:47 tagr: and it doesn't actually fix X, so it's a bit moot
13:47 karolherbst: and I am not quite sure how enabling kms-modifiers will work out
13:48 tagr: I was kind of hoping that danvet would go along with the implied modifiers approach, which I still think is a neat compromise
13:48 karolherbst: tagr: right.. but I'd just ignore X anyway
13:48 tagr: longer term I think a proper implementation as discussed over on #dri-devel is probably what we want
13:49 tagr: so I think if we can just come up with a reference implementation, I suspect we could just point people at that and then everyone can implement the canonical procedure in their compositor
13:49 karolherbst: I think personally I would be happy enough to tell developers that not using modifiers is just broken and unsupported. It's just a different story for users wanting to use it
13:49 karolherbst: mhhh
13:49 karolherbst: maybe
14:54 danvet: tagr, [PATCH] drm/doc: Document that modifiers are always required for fb
14:54 danvet: some discussions about implied modifiers in that thread too
15:27 ryszard: my nvs295 hangs GNOME on nouveau: http://codepad.org/g5QyWjEq
15:27 ryszard: the log is long and this is only a part
15:27 ryszard: this is dmesg and journalctl output
15:37 RSpliet: ryszard: it would be good to see the first nouveau error. Can you post the whole, unfiltered kernel log?
15:37 ryszard: you wish me to get all dmesh?
15:37 ryszard: dmesg?
15:37 ryszard: entire*
15:38 RSpliet: Yes please. Or if it comes from journalctl, -k is the flag I think
15:38 ryszard: sure but when its huge where can I put it for you?
15:38 RSpliet: hastebin.org should be fine no?
15:38 RSpliet: Well no
15:38 ryszard: everything hangs on this system and I'm connected remotely by ssh
15:39 RSpliet: hastebin.com
15:39 RSpliet: what distro?
15:39 ryszard: mouse, keyboard, power button all dead
15:39 ryszard: fedora 32 with wayland
15:39 RSpliet: journalctl -k <whatever other flags> | fpaste
15:39 RSpliet: if you don't have fpaste, install it
15:40 RSpliet: That will bring it to the CentOS pastebin
15:40 RSpliet: without a lot of manual labour
15:40 ryszard: right, forgot about fpaste ...
15:41 karolherbst: huh...
15:42 karolherbst: ryszard: what are you doing to hit this?
15:42 karolherbst: normally application should just abort or crash or whatever when they hit this...
15:42 karolherbst: I wanted to have a proper reproduce so I can track down further issues
15:43 karolherbst: ryszard: you can also just kill firefox
15:43 karolherbst: I think...
15:45 ryszard: https://paste.centos.org/view/9acc58a2
15:45 ryszard: it happened around 17:30:00
15:46 ryszard: well actually I killed not only firefox but gnome as well
15:46 ryszard: when tried to suspend it manually from ssh it returned 'time out'
15:46 ryszard: then the system failed seriously ;p
15:48 ryszard: hmm why he says sth about Xwayland there
15:48 ryszard: maybe ff ir running under x11 instead of wayland
15:48 ryszard: karolherbst: do you need anything more or I can reboot the machine?
15:48 ericonr: firefox is kinda weird about x11 and wayland
15:49 karolherbst: ryszard: mhhh... seems like our recory is messed up :/
15:49 ryszard: I did not list xlsclients before, after reboot will run ff and check it
15:49 ryszard: recory?
15:49 karolherbst: it's on my todo list to be better about context going away..
15:49 karolherbst: it's just.. annoying
15:49 karolherbst: *recovery
15:50 ryszard: ou
15:50 ryszard: then no chaces for workaround or any quickfix ;p
15:50 ryszard: chances*
15:50 karolherbst: ryszard: libdrm with asserts enabled could help
15:50 karolherbst: maybe
15:50 ryszard: how can I do that to try?
15:51 karolherbst: wait.. I need to check soemthign
15:51 karolherbst: ehhh
15:51 karolherbst: no.. that's a deeper issue
15:51 karolherbst: ehh and skeggsb is not around :/
15:51 karolherbst: RSpliet: are you familiar with the context recovery code under tesla?
15:51 karolherbst: it seems like we don't actually kill the channel
15:52 RSpliet: ryszard: d'oh, the log is missing the top. dmesg only reads the logs from a ringbuffer of a fixed size. As new lines come in, old lines fall out. I thought journalctl'd be better...
15:52 RSpliet: karolherbst: sadly no
15:52 karolherbst: mhh
15:52 karolherbst: so... the kernel see sthat the channel is stuck
15:52 karolherbst: okay..
15:52 karolherbst: but it doesn't actually kill it
15:52 ryszard: I can try to hang it again and grab the logs faster
15:52 karolherbst: ryszard: journalctl --dmesg will give you that as well
15:52 RSpliet: ryszard: there's also a way of increasing the log buffer size. I forgot the exact kernel param for that...
15:53 karolherbst: yeah.. but that's not needed
15:53 karolherbst: journald should have it all
15:53 karolherbst: just pass in --boot to select from which boot you want to get it
15:54 ryszard: ok, firefox runs in wayland mode
15:54 karolherbst: like "journalctl --dmesg --boot -1"
15:55 ryszard: ok, lets try again
15:55 ryszard: ok died ;p
15:55 karolherbst: uhhhhh
15:55 karolherbst: I know that bug
15:56 ryszard: https://paste.centos.org/view/099dbcc4
15:57 ryszard: here you have, starting from boot to hang
15:57 karolherbst: RSpliet, ryszard: https://github.com/karolherbst/nouveau/commit/2f8194075c52e42893a470e53b6afd8e014bf08d
15:57 karolherbst: there is a stupid race in nouveau
15:57 karolherbst: and I bet this is hit here
15:58 karolherbst: although not 100% sure
15:58 karolherbst: could be something else
15:59 karolherbst: but I know it ends up in nvif_vmm_put being wrong and everything just goes south randomly
16:02 ryszard: race condition sounds bad
16:03 karolherbst: well.. the trapped reads are also bad, but shouldn't cause issues directly
16:04 karolherbst: ryszard: mind creating an apitrace?
16:04 ryszard: how?
16:04 karolherbst: not quite sure how that works with firefox though
16:04 karolherbst: yeah... no idea, maybe somebody in #dri-devel knows
16:04 karolherbst: but that could help others to reproduce
16:04 karolherbst: or.. maybe pmoreau or RSpliet do the same with firefox you did
16:04 karolherbst: and see if they can reproduce
16:05 karolherbst: I don't have a system ready with a similiar GPU sadly
16:14 ryszard: sure, well nothing more we can do now with it
16:18 karolherbst: ryszard: you could file a bug against mesa maybe and describe how you hit this issue
16:18 karolherbst: maybe somebody will be able to reproduce
16:19 ryszard: it happens when I use firmware extracted from nvidia drivers according to the instruction from nouveau webpage
16:19 ryszard: will try to remove those and see if it will happen again
16:20 ryszard: need to isolate the scenario first
18:30 Lyude: gonna be honest, the best part of the ampere announcement has been seeing all of my friends posting pictures of large outdoor AC systems and going "look my RTX9990 came" https://twitter.com/d01n/status/1300953001587171328
18:35 HdkR: :D
18:42 airlied: need some 3-phase power jokes