01:11Lightkey: So now that the Voodoo 5 6000 is going to be produced again, how is the driver support?
01:12imirkin: removed, i believe, with all the other dri1 drivers in mesa 7.11 or whatever
01:12imirkin: (i guess removed in 8.0, latest is 7.11 then?)
01:13imirkin: you're only about 10 years too late
01:17kisak: hey, if you want it, all you have to do is dust off the old code, port it over to DRI3, get it to render a triangle, and pass peer review.
01:19kisak: oh, and fend off the impending doom of the non-gallium common code
01:24dcbaker: Port it to gallium while you're at it, lol
01:28dcbaker: Super trivial. So trivial it can have my ack before it's even written
01:28imirkin: esp for a dx8 board (i.e. no shaders)
09:43linkmauve: Speaking of silly old GPUs, I have one which does vs and gs, but no fs, would there be any way to still expose some shader capabilities if I were to write a Mesa driver?
10:48glennk: linkmauve, a classic driver similar to r200?
10:51linkmauve: The main issue would be that pretty much no compositor would be able to make use of such a driver.
13:04woodwose: g'morn, not sure if this is the right channel...
13:05woodwose: running arch with a 5.10.* kernel, mesa 20.3.4, heavy I/O as root causes artifacts, and will eventually crash X with a user session
13:05woodwose: I tried the 5.11.* kernel the issue remains, is this a known problem? are there any workarounds?
13:05tehcloud: nameth thy graphics processing unit
13:06woodwose: gen 7.5 hasweel gpu
13:06woodwose: I can't exactly remember what update this might have caused...
13:07tehcloud: I've got a similar problem with my AMD card since kernel 5.10 but have not had time to bisect... probably unrelated but you never know
13:07woodwose: I went back to an early 5.10.* kernel... which didn't fix the issue, but I didn't downgrade mesa yet
13:07woodwose: tehcloud, are there any bug reports for this you can point to, which I could subscribe to?
13:07ccr: which specific haswell? e.g. the full cpu model
13:07woodwose: it'S pretty annoying because right now it prevents me from using rsync... as soon as I am logged in to X
13:08woodwose: ccr, i7-4712MQ
13:09ccr: ah, probably GT1.
13:09ccr: oh wait, no
13:11woodwose: I'm about to go back to a 5.9.* kernel to see if the problem remains
13:11woodwose: but I wonder if there would be another workaround...
13:12woodwose: I'm not shy of applying patches to a 5.10.* or 5.11.* kernel
13:12ccr: you haven't said whether there are any errors in logs etc
13:12tehcloud: dmesg can tell you a lot
13:13woodwose: having breakfast right now, I'll reproduce it and post the output of it in a couple of minutes
13:30woodwose: so, trying to reproduce now
13:31woodwose: while rsync-ing stuff as root, the artifacts, fragments affect the user running X, I'll let it do its thign until X crashes again
13:32woodwose: nothing via dmesg or syslogs yet
13:33woodwose: those issues also continue once the I/O processes have stopped
13:33woodwose: cpu is spiking as well
13:34LEdoian[m]: Hello, bug reports should be submitted to the Freedesktop GitLab now? Kernel's `MAINTAINERS` link to https://bugs.freedesktop.org/, but the bugzilla there is archived.
13:42woodwose: this looks a lot like it https://gitlab.freedesktop.org/drm/nouveau/-/issues/14
13:44ccr: but that's for nouveau
13:44woodwose: the vdieo linke d in there looks exactly what I am experiencing with the intel gpu
13:44woodwose: and downgrading the kernel didn't help
13:44woodwose: *video linked
13:46woodwose: yeah it sux... it renders this machine useless
13:47ccr: you said that there's eventually Xorg crash. would be useful to have Xorg log for that
13:49woodwose: I'll get the logs for that...
13:49woodwose: it happened twice last night
13:50ccr: probably the best course of action is to submit a bugreport with those logs (dmesg, Xorg at least) attached, https://gitlab.freedesktop.org/drm/intel/-/issues
13:51woodwose: I hesitate to release unsanitized logs...
13:51woodwose: damn it
14:02woodwose: going through the logs right now, I struggle to find the relevant lines, there are a lot of these:
14:02woodwose: "The X11 connection broke: I/O error (code 1)"
14:02woodwose: "The X11 connection broke (error 1). Did the X11 server die?"
14:02woodwose: sddm crashed as well...
14:03woodwose: also when X restarted, SDDM was still affected by artifacts and felt sluggish (also regarding keyboard input)
14:08woodwose: I've been using the modesetting driver for a while, I wonder if the ddx driver would cause a change
14:25woodwose: switching to the ddx driver crashed the hole system
21:08jljusten: robclark, Kayden: looks like i965 is hitting this assert in some cases. https://mesa-ci.01.org/mesa_master/builds/24812/results/3969522980
21:10robclark: jljusten: you probably want to try to get a backtrace on that.. that should give an idea where to add the missing util_cpu_detect() call
21:10jljusten: I haven't been able to reproduce locally just yet :/
21:12robclark: hmm, ok.. getting backtraces out of CI jobs has been a thing I've wished for once or twice..
21:15jljusten: it seems to happen on several tests each run, but only i965, not iris. most commonly gen7, but, even gen9 has hit it: https://mesa-ci.01.org/mesa_master/builds/24807/results/3963618728
21:15robclark: I suppose adding a util_cpu_detect() somewhere early in screen creation should do the job..
21:15robclark: yeah, there was a util_cpu_detect() added in pipe_loader.. which should be early enough to cover the gallium drivers
21:16robclark: (it's safe to call util_cpu_detect() multiple times.. but you perhaps don't want to call it in anything critical-path)
21:28jljusten: testing with a call to util_cpu_detect() added early in brw_init_screen()
22:42jljusten: robclark: that does seem to have cleaned up the results: https://mesa-ci.01.org/jljusten/builds/275/group/63a9f0ea7bb98050796b649e85481845
23:10robclark: jljusten: \o/