09:26karolherbst: imirkin: gk106.. "nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]"....
09:26karolherbst: yay I guess?!?
09:26karolherbst: although I also get "[ 1128.223762] nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 000000b57f6a9000 engine 00 [GR] client 19 [HUB/CE2] reason 01 [PDE_SIZE] on channel -1 [06d5d47000 unknown]"
09:26karolherbst: wondering if that's still this firmware issue or something else
10:13emersion: imirkin: fyi, might be a lead for that 4k@60Hz issue https://patchwork.freedesktop.org/series/89759/
13:35imirkin: emersion: we don't support yuv420
13:35imirkin: emersion: the "link encoder" is something weird about intel, i think
13:37emersion: i mean, maybe yuv420 on the wire is what makes the proprietary driver able to do 4k@60Hz
13:37imirkin: emersion: 4k@60 works fine
13:38emersion: on HDMI?
13:38imirkin: there was one dude where the screen lost its scrambler settings when flipping between outputs
13:38imirkin: and we didn't re-set them
13:38emersion: i thought 4k@60 wasn't working on HDMI
13:39RSpliet: emersion: yes, on some older GPUs (Kepler), you'll need YUV4:2:0 for 4k@60Hz, but on most newer GPUs it should be fine
13:39imirkin: i mean, on supported hw, it's working
13:39imirkin: supported hw = GM20x+
13:39emersion: okay, may be misremembering or mixing things up then
13:40imirkin: 4k@60 is definitely not a perfect experience with nouveau
13:40RSpliet: But really, I personally think 4K@30Hz is a better choice than 4K@60Hz YUV4:2:0 on these old GPUs. Quality just degrades otherwise
13:40imirkin: but it's usually a matter of nouveau screwing up management of the separate scrambler value
13:40imirkin: rather than any sort of hard mixup
13:48karolherbst: RSpliet: 30 hz is terrible to use
13:48imirkin: emersion: basically to access the higher frequencies, the monitor and gpu have to be on the same page re encoder settings. if they get desync'd, then fail.
13:49imirkin: and we don't properly keep them in sync
13:49karolherbst: ahh.. that would explain some 4k fails I was seeing as well
13:50RSpliet: karolherbst: so is YUV 4:2:0. Might as well not bother with 4K
13:50karolherbst: I guess it depends on what you are doing
13:52RSpliet: Yep, different strokes for different folks. I'd get a new GPU if they were actually available :-P But don't want to invest in prev-gen tech... so I'm suffering through 30Hz for now
13:52karolherbst: actually 4:2:0 doesn't look all too bad
13:55imirkin: i'm bumping 4:2:0 a bit in my queue of stuff
13:55imirkin: next i'm plugging a GT218 and GF108
13:55imirkin: the GF108 to fix 3d images there
13:55imirkin: and the GT218 to have actual testing of the es3.1 stuff rather than just hopes and dreams
13:56karolherbst: hopes and dreams are fine
13:56imirkin: well, the G84 is missing stuff
13:56imirkin: and i'd like to have a clean run
13:56imirkin: karolherbst: assuming that pans out, thoughts on enabling ES 3.1 on nva3+?
13:56karolherbst: right :/ and I got told about an annoying bug today
13:57karolherbst: imirkin: well... just enable it an hope for the best? worst case applications are crashing while using it instead of outright not working
13:57imirkin: i guess
13:57imirkin: there is one legitimate ES 3.1 feature that won't be supported
13:57imirkin: but i think it's a bit esoteri
13:57karolherbst: any chance to disable it?
13:57imirkin: ES 3.1?
13:57imirkin: it's part of ES 3.1...
13:57imirkin: textureGather() with non-red components
13:58imirkin: exactly ;)
13:58karolherbst: can't we work around that?
13:58imirkin: not easily
13:58imirkin: you'd have to play games with additional samplers
13:58imirkin: er, sampler views
13:59imirkin: which admittedly we could do
13:59karolherbst: can we assert on it?
13:59imirkin: since we only expose 16 textures
13:59imirkin: well, we can emit a pipe_shader_debug
13:59karolherbst: I am not too much concerned about not supporting it, just concerned about some random stupid application making use of it
13:59RSpliet: Is there any use-case at all?
14:00imirkin: there's barely a use-case for textureGather in the first place
14:04karolherbst: it's just a weirdo texelFetch returning four values and maybe faster than texelFetch :p
14:04karolherbst: or not?
14:07imirkin: it's basically that
14:07imirkin: i wonder if we could just do it as 4x texel fetches
14:07imirkin: the thing is that textureGather takes normalized coords
14:07imirkin: so it's not 100% straightforward
14:14karolherbst: mhh, not even nir has lowering for tg4
14:14karolherbst: seems like most hw actually does have proper tg4 support...
14:14karolherbst: just not for constant offsets
14:15karolherbst: imirkin: you can pass in 4 constant offsets to textureGather
14:15karolherbst: and only nv supports it or so
14:15imirkin: ES 3.1 doesn't
14:15imirkin: that's only added in OES_gpu_shader5
19:49Shred00: am i SoL with a "GT216GLM [Quadro FX 880M] (rev a2)"?
19:49imirkin: should work fine
19:50Shred00: what features can i expect? i can't seem to map it to https://nouveau.freedesktop.org/FeatureMatrix.html or https://nouveau.freedesktop.org/VideoAcceleration.html
19:51imirkin: everything should work fine
19:51Shred00: vdpau fully supported?
19:51imirkin: (which is reasonably possible by that generation of hardware)
19:52imirkin: mmm ... *fully* would be a strong statement
19:52imirkin: let's go with "somewhat"
19:53imirkin: anything in particular in mind?
19:55imirkin: Shred00: note that some GPUs actually have video decode fused off. so if it's totally not working (like saying the engine is missing) then you have one of the ones where it's fused off
19:55imirkin: but i don't remember FX 880M as being a model where that's the case
19:55imirkin: (doesn't mean it's not, of course. my memory for these things is quite finite)
19:56Shred00: is nouveau.modeset=0 advised for kernel 5.11.17?
19:56imirkin: if you want nothing to do with nouveau, then yes.
19:56Shred00: oh. so normally not advised.
19:57imirkin: mmm ... i do advise it to people who are running software on a regular basis which upsets their hw setup
19:57imirkin: (mostly so that they stop annoying me with problems i have no hope of fixing)
19:57Shred00: as a default stance then no though? i.e. not until it's known to be needed?
19:58imirkin: if you're looking to use nouveau, then it's definitely not something you want :)
20:15Shred00: is this at all familiar, before i start going through the steps? https://paste.centos.org/view/c8a17efc
20:39imirkin: Shred00: pastebin xorg log + dmesg
20:46imirkin: Shred00: something weird is going on
20:46imirkin: hope that helps =]
20:46imirkin: there's something messed up with your mesa install i think
20:46imirkin: did you have nvidia blob drivers before?
20:47imirkin: also i assume you have another comp?
20:47Shred00: i did. i removed them before trying nouveau.
20:47imirkin: i'm guessing something got messed up in the transition
20:47imirkin: it _is_ loading nouveau though
20:48imirkin: Shred00: it might also be a permissions issue
20:48imirkin: also, if this is fedora 34, make sure you update. someone else was saying they were having major troubles.
20:49imirkin: (with things not related to nouveau at all)
20:49Shred00: i am up-to-date. installed it less than 24h ago
20:50Shred00: permissions issue on what? pretty sure I tried to start that Xorg as root
20:51imirkin: ok, well fedora fell in love with systemd
20:51imirkin: and systemd-way lies permission issues
20:51Shred00: nothing about systemd is related here. I simply tried to run "X" from a command prompt
20:51imirkin: as root?
20:52imirkin: can you check what happens if you run eglinfo ?
20:52imirkin: i still think there's something distro-level messed up with your setup
20:56imirkin: it's bailing early on in the egl init
20:56imirkin: on a null pointer of some sort
20:56imirkin: i've never seen that.
20:57Shred00: after some EGL client extensions string: stuff:
20:57Shred00: GBM platform:
20:57Shred00: Segmentation fault (core dumped)
20:57Shred00: so that's not good
20:58imirkin: it's not good for things to work
20:58imirkin: but it's good for debugging
20:58imirkin: do you have experience with e.g. gdb?
20:59imirkin: apply said experience ;)
20:59Shred00: #0 0x00007ffff6900d7a in driCreateContextAttribs () from /usr/lib64/dri/nouveau_dri.so
20:59Shred00: #1 0x00007ffff6901222 in driCreateNewContext () from /usr/lib64/dri/nouveau_dri.so
20:59Shred00: #2 0x00007ffff7b940ca in dri2_setup_extensions () from /lib64/libEGL_mesa.so.0
20:59Shred00: #3 0x00007ffff7b99c6e in dri2_initialize_drm () from /lib64/libEGL_mesa.so.0
20:59Shred00: #4 0x00007ffff7b92248 in dri2_initialize () from /lib64/libEGL_mesa.so.0
20:59Shred00: #5 0x00007ffff7b8a83c in eglInitialize () from /lib64/libEGL_mesa.so.0
20:59Shred00: #6 0x0000555555555bfc in doOneDisplay ()
20:59Shred00: #7 0x00005555555552d9 in main ()
20:59Shred00: no debug symbols for those clearly.
20:59imirkin: that's still pretty good
21:00imirkin: this also seems familiar
21:00imirkin: can you please check if there are updates?
21:01imirkin: what CPU is this btw?
21:02imirkin: ah. i7-720.
21:02imirkin: i have a i7-920 ;)
21:07RSpliet: Shred00: debug symbols live in separate packages, you may be able to install those for mesa and friends, usually gdb gives hints as to which packages you may need for this
21:11RSpliet: imirkin: if this is a permission problem, could strace give useful hints?
21:11imirkin: i'm asking in #dri-devel
21:11RSpliet: Usually X.org knows when to report a permission error though
21:11imirkin: airlied said it sounded familiar
21:11imirkin: and i'm pretty sure i saw it too
21:11imirkin: but i'm not a RH person :)
21:11imirkin: my solution to RH issues is ... stop using RH
21:11RSpliet: Yeah i was going to say, kind of you to do distro support :-P
21:12imirkin: plus they're forcing glamor even when it's not necessary, which decreases stability for people
21:12airlied: this is actually broken mesa
21:13RSpliet: which reminds me!
21:13imirkin: airlied: as shipped by fedora :)
21:13airlied: oh maybe it's not that
21:13RSpliet: Lyude: did you happen to get round to having another stab at rebuilding xorg-x11-drv-nouveau head? :-D
21:14airlied: if this is 20.3.3
21:14imirkin: Shred00: --^
21:15airlied: sudo dnf debuginfo-install mesa-dri-drivers and get some nicer backtraces
21:15RSpliet: F34 ships with 21.0.3 at the moment...
21:15Lyude: RSpliet: yeah it rebuilds I just forgot to file the update for it, I'm currently recovering from the vaccine so remind me tomorrow
21:15RSpliet: Lyude: haha sure. Sounds like sensible priorities. Hope you'll feel better again soon :-)
21:15airlied: oh looking at the xorg log it looks like the zink loading one
21:16airlied: but who knows
21:16Shred00: imirkin: no updates.
21:16Shred00: what in particular was the --^ in reference to?
21:16imirkin: Shred00: what version of mesa do you have installed?
21:17imirkin: airlied: i don't think X's function name lookup is reliable in this case
21:17Shred00: looks to be 20.3.5
21:17imirkin: the dri extensions stuff is all aliased to itself iirc
21:17imirkin: so it'll just pick one
21:17imirkin: (with megadrivers)
21:17imirkin: but i guess i dunno. Shred00 can you pastebin the output of eglinfo before the coredump?
21:18imirkin: Shred00: RSpliet: so ... if fc34 ships 21.0.3, and 20.3.5 is installed, either that's wrong, or there are updates which haven't been installed
21:18RSpliet: imirkin: or this is still Fedora 33 :-D
21:19RSpliet: 34 was only released last week
21:19RSpliet: Looks like a frankensystem
21:19RSpliet: kernel says F34, Mesa says F33
21:20ajax: Shred00: hi
21:20ajax: Shred00: sudo dnf -y debuginfo-install mesa-dri-drivers mesa-libEGL, if you would, please
21:22imirkin: Shred00: listen to ajax :)
21:22imirkin: he's Mr RH and Mr Winsys rolled into one
21:33Shred00: hrm. yeah. looking more closely, something went sideways with the upgrade. sorry for the noise. i'll fix that up and try again.