00:03karolherbst: 409800 is the falcon running status reg
00:04karolherbst: the falcon basically just disappears and the reg vanishes, so that's where this read fault is comming from
00:05karolherbst: basically we lazy load the graph context and whenevere something from userspace requests a context, we boot up the graph engine(s) and do the secboot stuff
00:05karolherbst: and if it fails, userspace timeouts
00:05karolherbst: or well
00:06karolherbst: nouveau timeouts waiting until graph is booted, but that just doesn't happen
00:08karolherbst: anyway, the patch I linked above might help
00:11nullspoo1: Alrighty. Can do
00:11nullspoo1: I'll take a look
00:11nullspoo1: Gonna go take a walk for a bit. Been inside too long today and it's finally not cold or snowing outside!
00:11nullspoo1: Thanks very much karolherbst!
00:29Sophira: Hi. I have a very odd problem. I'm using a GTX 970 on Gentoo Linux running gentoo-sources-4.15.4 (which is no longer in the tree; I should probably switch to another version). I have odd visual effects when I upgrade to mesa 17.3.8 or higher. I made a video showing the odd effects which I took using mesa 18.0.1: https://www.youtube.com/watch?v=puSC7a_osw0 . I also did the same things in mesa 17.2.8 to
00:29Sophira: show what the expected behaviour is: https://www.youtube.com/watch?v=LbjCoIX4DKE .
00:31Sophira: It's consistent and reproducible for me every time when using >=mesa-17.3.8 . (At least, I tried with 17.3.8 and 18.0.1, but I assume it applies to the others too.)
00:31Sophira: The Xorg.log file shows no significant differences so far as I can tell.
00:33karolherbst: Sophira: git bisect it is
00:33Sophira: Okay, will do.
00:33karolherbst: at least this should help us to track down what exactly broke it
00:33karolherbst: no point in guessing or debugging if we know it is a regression
00:38Sophira: Okay, the mesa-17.2.8 and mesa-17.3.8 ebuilds don't appear to be different enough for me to care in my situation so what I think I'll do is copy mesa-9999 to an overlay, alter the depends so it uses the earlier libxcb, and point it to a local git clone that I'll bisect and then emerge from. Probably the easiest way to do this.
00:39karolherbst: Sophira: mhh
00:40karolherbst: Sophira: there is a little hack
00:40karolherbst: do a git bisect in a local git tree
00:40karolherbst: set mesa_LIVE_COMMIT= accordingly
00:40karolherbst: in the make.conf or so
00:40karolherbst: maybe you can just put it in front of emerge as well
00:41Sophira: Interesting. I didn't realise that was a thing.
00:42karolherbst: yeah.. stuff like that are usually documented in the eclass
00:42karolherbst: you can also set the branch and everything
00:42karolherbst: but things might not build
00:43Sophira: I'd still need to edit the ebuild to use the earlier libxcb, though, since I 1.12-r2 and -9999 wants 1.13.
00:44karolherbst: oh well
00:54Sophira: Okay, testing to make sure I see the same behavious when I do 17.2.8 and 17.3.8 from git, and then will start bisecting. Could take a while; even on this beefy computer mesa still takes 7-8 minutes to compile each time. Actually this is probably an appropriate use of ccache come to think about it...
00:59karolherbst: Sophira: temporarily disable 32 bit builds ;)
01:00karolherbst: or well, just force the installation or something
01:00karolherbst: nothing should break
01:03Sophira: I'll probably use ccache to find the commit, then disable ccache and spend a little bit longer to verify that commit is the broken one.
01:47imirkin: Sophira: are you using xf86-video-nouveau or -modesetting?
01:47imirkin: from the looks of it, you might be using modesetting
01:48imirkin: if so, i'd strongly recommend switching to -nouveau
02:08imirkin: Sophira: separately, there's been a regression in texture tracking, i think in 17.3, although it seems unlikely it would have that effect
03:07Sophira: imirkin: I'm using -modesetting, yes. I can switch to the separate package if wanted, though I got the impression that using KMS was the recommended way of using X. I guess I'm wrong?
03:07imirkin: the two are unrelated concepts
03:07imirkin: xf86-video-nouveau also uses KMS
03:08imirkin: but it makes use of the 2D hw interface for accel instead of implementing it on top of GL
03:08imirkin: the GL thing might work out ok in theory, but in practice when the GL driver is buggy, it's not a great match :)
03:12Sophira: Ah, okay. I'll see what I can do about that first then, because bisecting between the mesa-17.2.8 and mesa-17.3.8 tags didn't work out due to a bad merge base and me not knowing how to continue from that.
03:14imirkin: (and xonotic also gets a red floor tile in its corruption on maxwell+, so ... maybe the same thing)
03:14imirkin: (although why it'd get red and not random -- no clue.)
06:47Sophira: imirkin: So my results seems to show that the nouveau X driver for the GTX 970 does seem to work out better. I was having crashes with the KMS driver in some cases and had to use LIBGL_ALWAYS_SOFTWARE=1 with some games to stop that from happening. With the nouveau X driver that doesn't appear to be a problem, and I don't have the issues I showed in the YouTube video either.
06:48Sophira: I looked to see why I wasn't always using it and it looks like back when I first tried it in 2016, it didn't support the GTX 970 and would fallback to fbdev. So I suspect I'm going to stick with the nouveau X module now.
06:49Sophira: That said, I'm still interested to see what that bug is so I'll probably go back to KMS again and try to bisect it properly so I can find the commit that broke that for you.
09:43Sophira: imirkin: So I discovered a few more things... firstly, the bug was already there at the start of the 17.2 branchpoint but got fixed specifically for 17.2. I managed to bisect the fix in 17.2.x to commit 17a3e4891bf4fa09785fe9d22db5c79a949004db, and the log for that explains why it was 17.2-only.
10:00Sophira: imirkin: And testing the commits referenced, I can confirm that fcbb93e860246375d03f280f927f79d3645a8988 was the commit that caused the bug.
10:06Sophira: Now just testing master and then if necessary filing or finding a bug in Bugzilla for it.
10:20Sophira: And it turns out it *is* still a problem in master.
11:08Sophira: Alright, I filed a bug for it. Hopefully I did it correctly. https://bugs.freedesktop.org/show_bug.cgi?id=106294
11:14karolherbst: Sophira: looks fine
11:15karolherbst: Sophira: maybe I can check that on Monday, please ping me
14:50imirkin: Sophira: thanks for the info. i consider modesetting to be unsupported (its better name, btw, would be 'generic'), although your bisect points to this being related to the larger texturing issue that i'm aware of
14:51imirkin: i didn't think it was reachable via GL, but perhaps it is
19:04imirkin: skeggsb: the current drmmode_display.c code appears to be a bit simplistic wrt screen <-> drmmode mappings (e.g. the existence of drmmode_from_scrn seems odd)
19:04imirkin: skeggsb: is there a good reason for it to be this way, or should we nuke that and track events at the crtc level properly?
19:09imirkin: oh i see. a lot of this stuff doesn't belong in drmmode in the first place
19:31imirkin: ohhhhh. drmmode == screen.
19:31imirkin: gr. i wish that was in a comment somewhere.