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