01:48iman: Hi, is there a 'hello world' tutorial to development [tinkering] with nouveau? Like, how to set-up a safe environment to work on it?
01:54imirkin_: not that i know of
01:54imirkin_: what's your end goal?
01:55iman: I want to eventually help with development. To begin, I want to have an env, where I can tweak current code and play with it
01:59iman: I think it would greatly help new people to dive-in, if there was a tutorial on how to setup an environment. I _could_ do this directly, but very soon I would break things and mess-up my system, I am guessing there is a smarter way of doing this?
02:01imirkin_: iman: it helps if you have a goal in mind
02:01imirkin_: like ... what part of nouveau are you talking about?
02:01imirkin_: kernel? mesa? ddx?
02:03iman: mesa
02:07imirkin_: ok
02:07imirkin_: so then the best thing to do is to grab the code, and make sure to pick a non-system prefix
02:07imirkin_: that way when you install it goes into its own little spot
02:07imirkin_: and then you just use LD_LIBRARY_PATH to make applications of your choosing pick that up
02:09iman: Thanks! This makes total sense, I can then tweak the mesa, build it anew, and try out my changes like this putting my path in LD_LIBRARY_PATH and nothing would break.
02:11imirkin_: well, the kernel can hang, depending on your changes :)
02:11imirkin_: but unfortunately that's hard to isolate against
02:11iman: if it does, you can recover rather easy right?
02:12imirkin_: just reboot
02:12iman: I mean, But if I were to play with the kernel driver itself [being lower level than mesa], it would not be so easy right? Like, if you tweak the kernel driver then pick that instead of your current [working] driver, it would crash right?
02:12iman: You can't just say: For this _program_ use this kernel driver?
02:12imirkin_: right
02:12imirkin_: what are you looking to do btw?
02:14iman: I was assessing a couple of things, trying to see which 1 is easiest to do first. 1) Add an imaginary 'gl*' which is not in opengl to mesa 2) make changes to how the kernel driver does code generation [like, how it generates gpu asm] and profile performance differences
02:15iman: The LD_LIBRARY_PATH I think solves (1) , I think it's pretty much do-able. But for (2), I don't know how people actually do it: like do they have a specific system to play around with the kernel driver, and not crash their actual laptop?
02:17iman: I mean even the debugging looks so hard: you got a crash in the kernel driver, your system now has no display driver and everything is on fire.
02:18imirkin_: kernel driver doesn't do code generatoin
02:18imirkin_: that's all in mesa
02:18imirkin_: having a compiler in the kernel would b enuts
02:19imirkin_: anyways ... i think you could get far with the gl shader binary thing
02:19imirkin_: are you hoping to write your own compiler? or what are you hoping to do exactly?
02:19iman: so this means: the code gets generated in mesa [the actual code, in the gpu's ISA] right? then the driver just loads it into the gpu memory for execution?
02:19imirkin_: yes.
02:20imirkin_: all in src/gallium/drivers/nouveau/codegen (for nv50+, which covers all DX10+ GPUs)
02:21imirkin_: if you just want to mess with codgen, probably easiest to just create some env vars which toggle this or that
02:21imirkin_: rather than integrating it all the way to GL functions
02:21imirkin_: since that's a ton of plumbing
02:21imirkin_: i once wrote a spec for being able to insert "debug" ops into GLSL shaders
02:22imirkin_: that the codegen could do whatever it felt like with
02:22imirkin_: to simplify RE'ing specific ops
02:22imirkin_: but never actually got around to implementing it
02:22iman: Not a whole compiler actually, more like, adding optimization to mesa: Like, I have a heuristic to generate better code [small changes, like a plugin] and I want to try that and see if it actually does.
02:23imirkin_: https://people.freedesktop.org/~imirkin/MESA_debug_operations.spec
02:23imirkin_: sure
02:23iman: Perfect! I understand. You just saved me LOTS of head-scratching! thanks, I will later write a tutorial after I manage to do this.
02:24imirkin_: feel free to ask here if you have any questions... lots of subtlety
04:29pabs3: is this Xwayland crash (SIGABRT) in nouveau_pushbuf_data useful to report somewhere? https://paste.debian.net/1153269/
04:30pabs3: (Debian bullseye, mesa 20.1.1-1)
04:42imirkin_: odd
04:42imirkin_: usually this happens due to multithreading of some osrt
04:43imirkin_: pabs3: is there anything in dmesg?
04:45pabs3: yes, https://paste.debian.net/1153270/
04:46pabs3:wishes GNOME shell could recover from Xwayland crashes
04:48imirkin_: hm ok
04:48imirkin_: so that crash is probably from the channel getting stuck
04:48imirkin_: and it seems to have gotten stuck because of a bad read somewhere
04:48imirkin_: (or we forgot to upload a texture, etc)
04:52pabs3: anything I can do to make debugging these sorts of things easier after the fact?
04:54imirkin_: nothing simple.
05:02pabs3: ok, so the crash is not really actionable, thanks for looking anyway :)
05:02imirkin_: sorry =/
09:29VanackSabbadium: hi karolherbst, i made all the tests and even though many of them did not pass, my system survived until the end
09:30VanackSabbadium: however, i found out that i had a prehistoric 4.15 Linux kernel
09:31VanackSabbadium: so, i've just updated to the latest 5.7.4 Linux-libre kernel, based on 5.7.4 Linux official kernel. So, if you patched it for multithreading issues since 5.6 release, i should be ok
09:31VanackSabbadium: I'll test it and let you know :)
09:33karolherbst: VanackSabbadium: mhh... there is no fix in the kernel, but the kernel reports error to userspace, so at least freezes should be prevented
09:33karolherbst: but I don't know how reliable that is
09:35VanackSabbadium: i do hope so
09:35VanackSabbadium: let you know anyway
10:38VanackSabbadium: karolherbst nope. Still freezes. However, i managed to go back to tty and type something. I tried to start X again but then it freezed again and i had to hard boot.
10:38karolherbst: VanackSabbadium: ohh, interesting
10:38karolherbst: VanackSabbadium: so that's an aprovement at least
10:39VanackSabbadium: i have an error message, i let you see
10:39karolherbst: VanackSabbadium: mind either shutting down or fetch the logs the next time this happens?
10:39VanackSabbadium: https://cloud.disroot.org/s/BgGJfqQKDX8Lt4e
10:39karolherbst: like the full thing
10:39karolherbst: mhhhh
10:39karolherbst: yeah.. that doesn't help as much sadly
10:39VanackSabbadium: that AIGLX thing?
10:40karolherbst: ohhh
10:40karolherbst: compton crashes
10:40karolherbst: or well.. crashes the GPU context
10:40karolherbst: VanackSabbadium: so.. mhh
10:40karolherbst: the next time this happens, mind gdb attach to compton and give me the backtraces of all thrads?
10:40karolherbst: *threads
10:41VanackSabbadium: how do i do that?
10:41karolherbst: would like to see where it spins or messes up
10:41karolherbst: start gdb as root
10:41karolherbst: attach $pid_of_compton
10:41karolherbst: "thread apply all bt"
10:41VanackSabbadium: i'll try
10:41karolherbst: you could try to do it already, just that there won't be any interesting
10:41karolherbst: just so you know what needs to be done
10:42karolherbst: you can just quit gdb with "quit" and it will detach again
10:42karolherbst: VanackSabbadium: but I assume with the older kernel you couldn't move to a tty?
10:43VanackSabbadium: exactly. it showed me tty but X did not crash
10:43VanackSabbadium: now it crashed and put me back on tty with console command
10:43karolherbst: well.. I see this as an improvement already :p
10:43karolherbst: ohh
10:43karolherbst: ahh yeah..
10:43karolherbst: I now that we handle some places correctly, mostly wondering about the ones we don't
10:44karolherbst: it's not nice to crash the compositor.. but better than freezing
10:45VanackSabbadium: yeah
10:45VanackSabbadium: it doesn't start X anymore, i had to reboot
10:46karolherbst: ohhh
10:46karolherbst: I see
10:46karolherbst: mhhh
10:47VanackSabbadium: https://pastebin.com/6j13Nbir
10:47VanackSabbadium: is that useful to you?
10:48karolherbst: ohh wait.. mhh
10:48karolherbst: need to install debug packages for mesa
14:28karolherbst: Seems like Tomb Raider ist broken on turing..
15:29karolherbst: tested it.. it works without problems
15:29imirkin_: michael lies then
15:29imirkin_: or you did something that fixed it
15:30karolherbst: I checked the commit he tested on
15:30karolherbst: I even downloaded the preference file he is using
15:30karolherbst: so.. mhh, weird
15:30imirkin_: which gpu are you testing on?
15:30karolherbst: tu117
15:31imirkin_: ah. i think he's on a RTX board
15:31karolherbst: mhh 164... right
15:31karolherbst: that's tu104
15:31imirkin_: which i can imagine has some differences we don't account for
15:31karolherbst: dunno... I think skeggsb did his development on a tu10X
15:32karolherbst: my RTX cards are at the office right now :D
15:32imirkin_: mine are at the store :)
15:32imirkin_: and i expect will remain that way for the foreseeable future
15:34Lyude: mhhhh, seems like typec_ucsi has suddenly started causing kernel panics on my RTX4000 (assuming it's because it has a USB-C port on it :s)
15:34karolherbst: Lyude: eugh.....
15:35Lyude: karolherbst: i feel like I see a lot of problems come from this driver :s, wonder if it's related to some of the nvidia specific usb-c stuff
15:35karolherbst: maybe
15:35imirkin_: good thing i'm on a SNB laptop. don't have any problems like that! :)
15:36karolherbst: well
15:36karolherbst: laptops usually don't have the usb-c port provided by nvidia :)
16:07VanackSabbadium: karolherbst is there a way to update to the latest nouveau drivers without compiling them?
16:10VanackSabbadium: alright, found it. it's an external repository so i don't know if that's so reliable, but i'm trying everything. I really don't want to install the proprietary drivers.
16:11karolherbst: VanackSabbadium: so the issue you are seeing is, that compton just crashes randomly, right?
16:11VanackSabbadium: i don't think that it's just compton
16:11VanackSabbadium: compton is just the compositor
16:12karolherbst: VanackSabbadium: depends on how you start X
16:12VanackSabbadium: many people reported that even disabling compton doesn't solve the problem
16:12karolherbst: does X crash?
16:12VanackSabbadium: startx from tty
16:12VanackSabbadium: yeah, it crashes after some seconds
16:12karolherbst: when restarting or after a fresh boot?
16:13VanackSabbadium: it crashes after a freeze
16:13VanackSabbadium: did you see the screenshot?
16:13VanackSabbadium: wait
16:13karolherbst: yeah.. but that doesn't help tracking down the cause
16:13karolherbst: it just means the GPU is probably messed up or something
16:13karolherbst: which.. would be odd though
16:13VanackSabbadium: xinit: connection to X server lost
16:14VanackSabbadium: that's what shows after a minute
16:14karolherbst: okay, what happens with X then?
16:14VanackSabbadium: i'm already on tty, so nothing else
16:14VanackSabbadium: i can't start it anymore, i gotta reboot
16:14karolherbst: I mean.. is there anything in the X logs
16:15VanackSabbadium: i tried to look, but i couldn't find any recent log
16:15VanackSabbadium: everything was pretty much old
16:15VanackSabbadium: i looked into /var/log/
16:15karolherbst: yeah well.. I need to know why X doesn't start/crash
16:15VanackSabbadium: don't know if that's the right folder
16:16karolherbst: might be.. some distributions write everything into journald these days
16:16VanackSabbadium: https://cloud.disroot.org/s/BgGJfqQKDX8Lt4e
16:16VanackSabbadium: that's what happens, it's the same screenshot as this morning
16:16karolherbst: but this doesn't tell me what's happening
16:16VanackSabbadium: i know
16:17karolherbst: ohh
16:17karolherbst: see the log file path in there?
16:17karolherbst: at the top?
16:17VanackSabbadium: yeah, i see it
16:17VanackSabbadium: .local/share?
16:17karolherbst: yeah
16:17VanackSabbadium: gotta check it
16:17karolherbst: if you start x as a user it might store stuff in your user directory
16:17VanackSabbadium: i'm @ work now
16:17karolherbst: okay, cool
16:18karolherbst: that might help figure out what's wrong
16:18VanackSabbadium: hell, that's so annoying
16:18karolherbst: there are already some strange messages in the screenshot, but would rather see the full log
16:19karolherbst: VanackSabbadium: yeah.. tracking down the actual cause is always annoying :p
16:19VanackSabbadium: no no i don't mean that
16:19VanackSabbadium: i mean that this issue is annoying
16:19VanackSabbadium: i don't care if sometimes an application crashes
16:19karolherbst: rebooting is annoying, right :p
16:20VanackSabbadium: but having to brute force shutdown and rebooting each time...
16:20VanackSabbadium: and i can't really trust opening anything
16:20karolherbst: yeah.. at least the brute force shutdown part should be solved.. although it seems when you restart X things don't work as well :/
16:20VanackSabbadium: if after 2 minutes each application crashes
16:21karolherbst: mhh yeah.. the bug i a bit strange
16:21VanackSabbadium: yeah, but it's not so good that you want to relax playing half-life 2 and then it crashes after 2 minutes
16:21karolherbst: I really would lke to know what causes the initial crash
16:21karolherbst: maybe we can fix it easily
16:21VanackSabbadium: and then you reboot, and try again, and then again after 5 minutes
16:21VanackSabbadium: i really hope so....
16:48VanackSabbadium: i heard somebody saying that switching from DVI cable to VGA cable solved the issue, you have any idea?
16:48karolherbst: VanackSabbadium: it could depending on the bug
19:01Lyude:hopes this will be the final drm_vblank_work revision
23:55rhyskidd: after the earlier update, valgrind-mmt is now rebased against the upstream bugfix v3.16.1: https://github.com/envytools/valgrind/tree/mmt-3.16.1
23:55rhyskidd: go forth and trace mmio in userspace!