11:08karolherbst: imirkin, ajax: okay.. I think those GL errors are just casued by some weird interactions between apitrace and xwayland
17:14karolherbst: *sigh*... yeah so.. we don't really have an easy way to figure if an used address belongs to valid memory within a submissions, do we?
17:16karolherbst: imirkin: do we have a simple way of getting the proper bo information from a memory uapi handle?
17:16imirkin: the pushbuf submit has a list of referenced buffers
17:17imirkin: which in turn have addresses/sizes
17:17karolherbst: imirkin: no, it doesn't
17:17imirkin: oh yeah, but they're just gem handles
17:17imirkin: so you have to keep track of it
17:17imirkin: not the end of the world though
17:17karolherbst: yeah well.. I wished for a solution without adding more overhead in the non debug case :D but .. yeah...
17:17karolherbst: things also get more complicated if you consider bufctx
17:18karolherbst: I might just print created bos or so...
17:18imirkin: the problem is "used address" is hard to determine
17:18imirkin: since it might not be an address in that submit at all
17:18imirkin: but a value which is in the gpu from earlier
17:18karolherbst: so the libdrm debug output put print handle: base + range or so
17:18karolherbst: and then you can just do it yourself ...
17:18karolherbst: for now
17:18imirkin: libdrm_nouveau knows all about the bo's
17:18karolherbst: not when submitting a pushbuffer
17:18karolherbst: it doesn't reference bos at all afaik
17:18imirkin: it's easily accessed
17:19imirkin: i don't remember :)
17:19karolherbst: ohh wait..
17:19karolherbst: there is nouveau_pushbuf_priv.bos
17:19karolherbst: let's see...
17:19imirkin: like ... where do you think it gets the gem handles from? :)
17:19karolherbst: nouveau_pushbuf_krec has that stuff
17:20karolherbst: mhh, my problem is just if all that information is available when submitting
17:20karolherbst: ahh no
17:20karolherbst: imirkin: bos is just the lists of bos containing the pushbuffers data
17:20imirkin: there's another list.
17:20imirkin: or krel
17:20imirkin: or ksomething
17:21karolherbst: there is just struct drm_nouveau_gem_pushbuf_bo buffer[NOUVEAU_GEM_MAX_BUFFERS];
17:21imirkin: look at where the gem handle id is coming from
17:21karolherbst: and there is no reference to the bo object at that point
17:21karolherbst: maybe I am missing something though
17:21imirkin: figure out how the buffer data is being filled
17:21imirkin: that's the point at which it knows what the bo is
17:22karolherbst: through nouveau_pushbuf_refn
17:22imirkin: which most definitely takes a bo
17:22karolherbst: yeah, but it doesn't store it
17:22karolherbst: so internally we only have a list of handles
17:22karolherbst: and the bo reference that
17:24karolherbst: I mean.. I potentially know how to get that information, I just want to not burden normal users not caring :D.. maybe I just store a list somewhere and it points to NULL unless you dump pushbuffers or something...
17:24karolherbst: just hoped there would be an easier way out
17:24karolherbst: in the end I really just want to know handle -> memory range
17:26karolherbst: or we just store the bo address alongisde...
17:27karolherbst: imirkin: my alternative idea was to create a new PUSH_ macro thing for addresses which takes a bo+offset and asserts that the used bo is actually referenced by the pushbuffer atm, but that gets complicated with bufctx even... would allow us to assert on it though
17:28imirkin: so again, the thing you're not considering
17:28imirkin: is values which were set in the gpu a long time ago
17:28imirkin: e.g. the TLS gets set once on start
17:28karolherbst: yeah.. that's another problem
17:28imirkin: but it keeps getting used
17:28imirkin: i've had to fix problems like this before:
17:29karolherbst: anyway, in the end we see a fault in dmesg and we would like to know what bo that is, where it comes from and if it's actually bound or not
17:29karolherbst: and off hand I have no simple way of actually telling instead of guessing and putting prints everywhere
17:29karolherbst: maybe I am missing something simple here
17:30karolherbst: yeah, I remember that
17:32karolherbst: I just want a simple way of debugging this stuff :p
17:32imirkin: sounds good!
17:32imirkin: crap, i forgot to review your libdrm patch
17:32imirkin: can you link it again?
17:32imirkin: i'll open it, maybe reducing the chances of my forgetting
17:35imirkin: NOUVEAU_GEM_PUSHBUF_SYNC -- wtf is that?
17:35karolherbst: something nice
17:35karolherbst: wait a sec
17:35imirkin: care to share?
17:35karolherbst: imirkin: 0352029ed83ff
17:36imirkin: in what tree
17:36HdkR: Is this a DRM change?
17:36karolherbst: so if we sync we know the last submission causing the kernel to kill the channel is the one causing troubles
17:36imirkin: ok, it's new, no wonder it's new to me :)
17:36karolherbst: in theory
17:36HdkR: Okay, not a new ioctl. awaaay
17:37imirkin: HdkR: well, a flag
17:37HdkR: I'm fine with this. I don't need to parse that bit of the structure with my downstream drm maintaining
17:40imirkin: karolherbst: one minor english correction on a comment on the last patch
17:40imirkin: karolherbst: otherwise r-b me
17:40karolherbst: cool, thanks
17:48karolherbst: let's see if I can just figure things out by parsing the pushbuffer.. :D
17:51karolherbst: annoying thing is, this issue only seems to happen on my kepler GPU... but I've also only tested with turing besides that
17:54karolherbst: imirkin: slowly I think I am hitting something random...
17:54karolherbst: "[ 35.803822] nouveau 0000:01:00.0: gr: GPC2/TPC1/MP trap: global 00000000  warp 3c0009 [ILLEGAL_INSTR_ENCODING]"
17:54imirkin: is this your GK106?
17:56karolherbst: it could be this infamous "firmware" issue, but maybe it's also just something totally random
17:56karolherbst: the machine doesn't crash though...
17:56karolherbst: killing the application and it continues happily
17:57karolherbst: but I can reproduce it so quickly, it's scary
18:03karolherbst: luckily I have a couple of more kepler cards... *sigh* will try them out later
18:04imirkin: karolherbst: you could check if using blob ctxsw fw fixes everything
18:04imirkin: that'd be sad
18:05imirkin: but we've been sad before...
18:55karolherbst: worth a try I guess
18:56karolherbst: imirkin: what's the fancy new way of extracting that btw?
18:57imirkin: and by "fancy new way" you mean "the thing i did in 2014"?
18:57imirkin: just use extract_firmware.py
18:57imirkin: on blob 325.15
18:57imirkin: or whatever it tells you to do
18:57karolherbst: yeah.. I think we might want to update this page: https://nouveau.freedesktop.org/NVC0_Firmware.html
18:58imirkin: no, that's still legit
18:58imirkin: if you want to extract from traces
18:58karolherbst: yeah I mean, most users won't
18:58imirkin: also read the first part of that
18:58imirkin: You basically never need to do the mmiotrace, unless you're a nouveau developer. There is a script that will extract all the known (useful) firmware from the blob directly. See the VideoAcceleration page for instructions
18:58karolherbst: I missed that :D
18:58imirkin: yes, the first sentence. easily missed.
19:04imirkin: i was pretty proud of that perl script though :) it replaced like a 100-line python thing
19:04imirkin: ok, maybe not 100-lines. but it had to be carefully changed, etc.
19:09karolherbst: I think I am missing something
19:09imirkin: like what
19:09karolherbst: the graph firmware
19:09imirkin: did you get the files extracted?
19:10imirkin: did you use 325.15?
19:10karolherbst: ahh, no
19:10imirkin: just have to follow the instructions :p
19:10karolherbst: I only want to copy paste stuff :D
19:10imirkin: karolherbst: if you had, you'd be fine
19:11imirkin: unfortunately you didn't
19:11imirkin: check the VideoAcceleration page
19:11imirkin: it makes you fetch 325.15
19:11karolherbst: ohh.. crap there it is
19:12karolherbst: we sould remove those $ and # so one can actually copy paste the whole thing
19:12imirkin: well, the # is for root stuff.
19:12imirkin: feel free to change it
19:18karolherbst: uhh.. sigh
19:19karolherbst: imirkin: nouveau doesn't declare the graph firmware as used firmware so it won't show up in smart initramfs generators checking modules for actually used firmwares :D
19:21airlied: not sure you can declare fw that isn't shipped in linux-firmware
19:21airlied: without something complaining
19:22karolherbst: airlied: annoying
19:24imirkin: karolherbst: why do you need it in the initramfs?
19:24imirkin: oh, does the module get loaded from initramfs? heh
19:24karolherbst: because thats where nouveau gets loaded
19:24karolherbst: because of luks
19:24imirkin: i make my initrd be constant
19:24imirkin: i have luks
19:24imirkin: i don't think luks needs nouveau to be loaded
19:25karolherbst: no, but the fancy kms password prompt
19:25imirkin: ah hehe
19:25karolherbst: shown on all displays and such :D
19:25imirkin: i obv have none of that
19:27imirkin: make sure you also pass in NvGrUseFW
19:27imirkin: (i think)
19:27karolherbst: it all works, I just have to write this dracut config file to include the firmware
19:29karolherbst: no firmware loading errors anymore
19:30karolherbst: imirkin: soo.. I think I have good and bad news, which one first?
19:32imirkin: can you combine the two sentences and alternate words?
19:32karolherbst: mhh, I think if I tell one you already know the other anyway
19:32imirkin: let me guess
19:32imirkin: good news: error is gone
19:32imirkin: bad news: different error
19:33karolherbst: good news: I have a GPU where nvidias firmware seems to help
19:33karolherbst: (and would be able to debug it)
19:33imirkin: bad news: you have to play with firmware
19:33imirkin: but that's just bad news for you
19:33imirkin: not for me :)
19:33karolherbst: that's true
19:34imirkin: there's like a 30% chance it's not even a "we're not doing X" bug
19:34imirkin: but rather some more obvious screwup
19:34imirkin: like we're writing falcon wrong, etc
19:35imirkin: we have funny instruction selection bugs a long while back
19:35karolherbst: could be
19:35imirkin: obviously fixed the ones we knew about
19:35imirkin: but ... :)
19:35karolherbst: at least writing a falcon debugger isn't all that painful
19:38karolherbst: what I am more concerned about is, if the users bug is something else or the same
19:38imirkin: this is a GK104
19:38karolherbst: the error after which the channel dies looks pretty random
19:38imirkin: most of the people with *bad* problems were GTX 660's
19:39imirkin: like where it's insta-death
19:39karolherbst: "fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]" and what comes after that
19:39karolherbst: I hit this with the gk106 often enough as well
19:39imirkin: hm ok
19:39karolherbst: "fault 01 [WRITE] at 000000e18cc00000 engine 00 [GR] client 00 [HUB/VIP] reason 09 [WORK_CREATION] on c>" what the heck is that even :p
19:39imirkin: so then it's probably that something about those GTX 660's which makes it happen extra-fast
19:39imirkin: enum probably came from gk20a headers or something
19:40karolherbst: the RT_WIDTH_OVERRUN errors aren't great either
19:40karolherbst: but.. not fatal at least, or are they?
19:40imirkin: don't think so
19:40imirkin: i mean, that draw might get aborted
19:40karolherbst: different channel anyway
19:41karolherbst: that makes me thing.. maybe thats firefox hopping on the "let's do multiple GL contexts" bandwagon as well
19:41karolherbst: ehh wai
19:41karolherbst: that's with chrome
19:42karolherbst: the thing is just..
19:42karolherbst: it's xwayland crashing
19:43karolherbst: and xwayland isn't really doing all that much
19:43imirkin: it's doing enough ;)
19:48karolherbst: well the modesetting DDX is probably doing more but Xwayland? As long as you don't move stuff around or resize stuff, nothing really happens
19:48imirkin: should be doing the same stuff
19:48imirkin: in fact yeah, i bet xwayland does more
19:48imirkin: coz it doesn't just draw everything to the same final surface
19:50karolherbst: yeah.. not sure.. I was just looking on the commands submitted and it wasn't much
19:57imirkin: i'd encourage you to do an audit comparing the envydis output with what we're feeding to envyas
19:57imirkin: should be able to largely diff it
19:57imirkin: esp the post-preprocess version
19:57karolherbst: maybe I can convince nvidia to release fuc ISA docs :D
19:58imirkin: i doubt that's a problem
19:58karolherbst: probably not though
19:58imirkin: the problem is more that envyas isn't 100% perfect
19:58imirkin: esp at rejecting bogus things
19:58karolherbst: I am a bit aware
19:58karolherbst: and that's probably an issue
19:58imirkin: there was the immediates thing
19:58imirkin: i forget if you found that or RSpliet did
19:58karolherbst: I will try with my other kepler cards and see on how many I hit this
19:58karolherbst: there is just one problem
19:58karolherbst: I think I only have gk106 ones :D
19:59imirkin: i have 0 gk10x's
19:59imirkin: only a gk208
20:01karolherbst: actually.. no, the other is gk107
20:01karolherbst: but I think I left one kepler in brno actually..
20:06imirkin: one can determine where karol's been by the trail of kepler's left behind...
20:06karolherbst: so I can't reproduce the same issue with my gk107
20:06imirkin: gk106 has more ... things
20:07imirkin: you could be super-sneaky
20:07imirkin: you can start masking off various units
20:07RSpliet: imirkin: I don't think I've doen much around falcon isa REing and opcodes
20:07imirkin: RSpliet: well, it was *someone*
20:07imirkin: and it wasn't me
20:07imirkin: karolherbst: basically you can start masking off MP's and TPC's
20:07imirkin: you could just make it match the GK107 setup
20:07imirkin: if that makes everything work, then bisect :)
20:08karolherbst: I can think of more pleasent things to work on
20:08RSpliet: karolherbst: you could resurrect that old patch I have lingering around, that can do a stackdump of a pre-GK110 falcon on a CTX timeout
20:08imirkin: karolherbst: you can just set masks in a couple registers
20:09imirkin: ok. so mwk fixed envytools a while ago. but i forget who noticed and caused the fuc to be rebuilt.
20:09karolherbst: yeah... dunno
20:09karolherbst: it's just weird that the gk106 is the one getting hit by this issue :D
20:10RSpliet: the stack dump may tell you what FECS/GPCCS is doing when it times out - whether it's waiting on something, whether it's idling
20:10mwk: I what?
20:10imirkin: mwk: 5fde30a2684041f9820aa9dc4fbd0009a45076a9
20:10imirkin: i'm sure you remember it well.
20:11mwk: oh it has a diff of... well everything
20:11RSpliet: I get random hangs on GK107, I think there's a correlation with high res video playback on youtube non-fullscreen. But that's just one case. It does definitely happen at other times too. Higher resolution monitor made it more frequent
20:11imirkin: mwk: most importantly, it was something with immediates
20:11karolherbst: RSpliet: the thing is.. the firmware isn't really dieing
20:11karolherbst: just the channel gets nuked and things continue
20:12imirkin: mwk: i don't remember. but we regenerated the gr firmware, and that made some things better. iirc.
20:12imirkin: this was all years ago.
20:12mwk: ... yeah
20:12RSpliet: karolherbst: I've seen so many different things happen. We used to have a bug where the firmware could miss the CTX switch interrupt. sitting there idling while the scheduler waits for a CTXswitch to finish - which never happened.
20:12imirkin: i think the signed sounds right
20:12karolherbst: RSpliet: yeah, could be
20:12RSpliet: I fixed one of those eons ago
20:13karolherbst: I think we really need a falcon debugger :p
20:13imirkin: RSpliet: yes, found that one too in the history :)
20:13RSpliet: getting stack dumps is a good first step
20:13karolherbst: at some point I started to write one...
20:13karolherbst: in bash
20:13mwk: mmmh I had some great plans for one
20:13mwk: too bad that never happened
20:14karolherbst: RSpliet: oh I actually had one I could use to attach to falcons, dump the code and disassemble it
20:14karolherbst: even single stepping
20:14RSpliet: mwk: the story of so many projects
20:14karolherbst: it was just hacked up in bash though and I got occupied with more important things :D
20:14mwk: oh yes
20:16karolherbst: RSpliet: although.. I guess when dumping the state you also dumped the instruction pointer, no?
20:44Shred00: does this: https://paste.centos.org/view/184e048b mean i am not going to get any hardware video decoding?
20:45imirkin: Shred00: remind me what GPU
20:45imirkin: Shred00: make sure you follow these steps: https://nouveau.freedesktop.org/VideoAcceleration.html#firmware
20:47Shred00: i guess even rpmfusion is not packaging a firmware? let me run the extraction…
20:47imirkin: can't package it
20:47imirkin: you could package the nvidia thing + script, and run the script on install
20:47Shred00: arch and gentoo seem to do something. but i understand.
20:47imirkin: that's what i did for the gentoo package
20:48imirkin: and someone presumably copied it for arch
20:53RSpliet: karolherbst: yep, think pre-GK110 that was just in a MMIO reg
20:55Shred00: can i load the firmware after the system is booted or do i need a reboot for that?
20:55imirkin: generally, yes
20:55imirkin: i don't remember if it retries if it tried and failed
20:56Shred00: ahhh. vdpauinfo shows a few profiles supported now. are the "--- not supported ---" just not supported by the hardware or can it be driver/firmware lacking?
20:56imirkin: the latter.
20:56imirkin: if there's no firmware, vdpau doesn't support those.
21:00Shred00: so: H264_EXTENDED --- not supported ---
21:00Shred00: means there is no firmware for that profile?
21:01imirkin: are some of them supported?
21:01imirkin: it could also indicate that i have no idea wtf the difference between the h264 profiles is
21:02Shred00: in any case, the card is GT218 [ION]
21:03imirkin: wasn't it a GT216 yesterday?
21:03imirkin: or was that someone else?
21:03Shred00: yup. going through the network replacing nvidia binary driver with nouveau. :-)
21:04imirkin: anyways, you have "VDPAU Feature Set C"
21:04imirkin: so whatever that supports is what SHOULD be supported
21:04imirkin: if there are any differences
21:04imirkin: then that's just my incompetence
21:04imirkin: (which knows no bounds, so ...)
21:05imirkin: by the looks of it, extended should be supported
21:06imirkin: i'll go through and true it up
21:10Shred00: yeah. looks like i am also supposed to have
21:10Shred00: H264_PROGRESSIVE_HIGH --- not supported ---
21:10Shred00: H264_CONSTRAINED_HIGH --- not supported ---
21:10Shred00: so those are missing firmware files?
21:10imirkin: just a couple lines of code
21:11Shred00: ahhh. i see what you are saying now.
21:11imirkin: all those are just completely random numbers
21:12Shred00: well, kodi and mplayer show me that they are using vdpau, (well vaapi for the former which used vdpau afaiu). nice!
21:12imirkin: for video decoding, or just display?
21:13imirkin: cpu usage should make it pretty obvious
21:13imirkin: h264 decoding is heavy on the cpu
21:14Shred00: spoke a bit too soon. kodi is just showing a black screen, although is playing the video. let me see what mplayer does with it…
21:14imirkin: and the video's not meant to be all black, eh?
21:17Shred00: heh. no. mplayer reports "[vdpau] Error when calling vdp_device_create_x11: 23". let me go google that…
21:18imirkin: Shred00: can you pastebin the vdpauinfo output?
21:18Shred00: display: :0 screen: 0
21:18Shred00: Error creating VDPAU device: 23
21:19imirkin: that seems worse than it was before
21:19imirkin: pastebin dmesg?
21:19Shred00: that was working a minute ago, giving all kinds of goodies
21:21imirkin: so you never plopped the firmware where you were supposed to
21:22imirkin: follow the instructions on the VideoAccel page for firmware
21:22Shred00: i used the commands on the page. the firmware files are in /lib/firmware/nouveau/. perhaps those messages are from before i extracted the firmware
21:22imirkin: ls -l /lib/firmware/nouveau
21:22imirkin: (pastebin that)
21:23imirkin: 404 page not found
21:25imirkin: yeah, those messages probably from before you had the files then
21:25imirkin: confirm that you can access those as your user?
21:26Shred00: everything is running as root
21:26Shred00: bad, i know. this is a lab test. wouldn't do that in production.
21:28imirkin: error 23 = VDP_STATUS_RESOURCES i think
21:28Shred00: ahhh. stopping mplayer, vdpauinfo looks sane again
21:28imirkin: oh hm. might not allow two at once?
21:28imirkin: that's slightly surprising.
21:28imirkin: i didn't remember that.
21:29Shred00: allow two what?
21:30imirkin: i guess we only allow h264_constrained_baseline
21:30imirkin: oh, no, we also allow h264_baseline/main/high
21:30imirkin: that should cover ~everything
21:31imirkin: can you pastebin the output from mplayer when it errors out?
21:31Shred00: playing a different video, 1280x720, h264 with mplayer works
21:31imirkin: there's a max size
21:31imirkin: how big was the failing one?
21:32imirkin: Maximum width or height: 128 macroblocks (2048 pixels) for feature set C
21:33Shred00: 1920x1080. but it is playing this time. but it is "slow" and mplayer is complaining the system is too slow.
21:34imirkin: that should work ok
21:34imirkin: try reclocking
21:34imirkin: cat /sys/kernel/debug/dri/0/pstate
21:34Shred00: yeah. mplayer is using a full core.
21:34imirkin: it might just be spinning
21:34Shred00: 0f: core 535 MHz shader 1070 MHz memory 400 MHz
21:34Shred00: AC: core 405 MHz shader 810 MHz memory 405 MHz
21:35imirkin: echo 0f > /sys/kernel/...
21:35imirkin: note this could hang
21:35imirkin: so ... save your work ;)
21:35Shred00: # echo 0f > /sys/kernel/debug/dri/0/pstate?
21:36imirkin: ("AC" = current level, and indicates you have an AC adapter plugged in)
21:37imirkin: just noticed -- that max macroblocks is wrong too
21:37imirkin: should be 8192
21:41Shred00: ok. saved some work. going to try the command…
21:42Shred00: still playing slowly, using a core. fwiw, my experience is that mplayer doesn't spin on CPU. it's usually quite low when using vdpau
21:43imirkin: Shred00: right, i meant like mesa might be spinning on a fence or something
21:44imirkin: if the decoder is being slow
21:44imirkin: i haven't really seen any problems when it works well
21:44imirkin: mind pastebinning mplayer output?
21:47imirkin: you did not follow instructions
21:48imirkin: Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
21:48imirkin: this means vdpau is not being used
21:48Shred00: VO: [vdpau] 1920x1080 => 1920x1080 Planar YV12
21:48imirkin: yes, for display
21:48imirkin: look at "Using VDPAU"
21:49Shred00: hrm. pretty sure i've never had do that with the proprietary nvidia driver. is this something unique to nouveau/mesa?
22:01imirkin: perhaps blob drivers auto-install that bit of mplayer.conf, dunno
22:07Shred00: i have a blob driver machine here to compare with: GM107GLM [Quadro M1200 Mobile] but vdpauinfo is reporting:
22:07Shred00: Error creating VDPAU device: 1
22:07Shred00: maybe this thing doesn't support any vdpau at all?
22:12Shred00: hrm. so, that 1920x1080 video that plays with mplayer and vdpau is "black screen" in kodi.
22:13Shred00: cpu usage looks great. player info says it's using ff-h264-vaapi (HW)
22:15Shred00: maybe these?
22:15Shred00: 2021-05-06 02:08:14.284 T:3568 INFO <general>: VAAPI::SupportsFilter vaDeriveImage not supported by driver - ffmpeg postprocessing and CPU-copy rendering will not be available
22:15Shred00: 2021-05-06 02:08:16.461 T:3569 INFO <general>: VAAPI::SupportsFilter vaDeriveImage not supported by driver - ffmpeg postprocessing and CPU-copy rendering will not be available
22:16imirkin: no vdpau on gm107 with nouveau
22:17imirkin: ah yes - that's a kodi bug
22:17imirkin: it assumes that vaDeriveImage always works
22:17Shred00: the gm107 is using the blob driver
22:17imirkin: whereas it's very clearly specified as not being required to work
22:17imirkin: on some mobile chips, video decode is fused off
22:17Shred00: and that will cause the black screen artifact?
22:17imirkin: not sure. i don't use kodi.
22:18imirkin: i just remember amd guys putting in nasssty hacks into mesa to work around it
22:18imirkin: but those hacks don't work with nouveau
22:22Shred00: this is a pity. this is going to be my show-stopper. :-(
22:23imirkin: does mplayer work ok with that 1080p video now btw?
22:24Shred00: indeed. very cool. you guys have done some amazing work here!
22:24imirkin: you should reach out to the kodi guys
22:24imirkin: although i sorta assume their answer will be "don't use nouveau"
22:24Shred00: yeah. that's was many of the answers i have seen already are.
22:26imirkin: you could try nuking the native libva thing
22:26imirkin: and using the va-vdpau converter
22:26imirkin: it might make kodi happier
22:26imirkin: probably don't even have to nuke anything
22:26Shred00: that was all greek to me. :-) let me google some terms…
22:26imirkin: just set like VA_API_DRIVER or something
22:27imirkin: so ... someone has made a libva wrapper on top of libvdpau
22:27imirkin: libva (like libvdpau) supports any number of backends
22:27imirkin: currently you're using the nouveau backend
22:27imirkin: but instead you could try to use the "vdpau" backend, which is this wrapper thing
22:28imirkin: LIBVA_DRIVER_NAME is the thing
22:28imirkin: yeah, try LIBVA_DRIVER_NAME=vdpau
22:29imirkin: in the env when running kodi
22:30Shred00: libva info: VA-API version 1.11.0
22:30Shred00: libva info: User environment variable requested driver 'vdpau'
22:30Shred00: libva info: Trying to open /usr/lib64/dri/vdpau_drv_video.so
22:30Shred00: libva info: va_openDriver() returns -1
22:30imirkin: you might have to install something
22:31imirkin: libva-vdpau-driver or something like that
22:32Shred00: the log looks pretty promising: https://paste.centos.org/view/2445956a
22:32Shred00: but kodi is frozen at that point. didn't even start playing the video.
22:34Shred00: that looks better
22:34imirkin: 2021-05-06 02:28:21.413 T:3721 ERROR <general>: OutputPicture - failed to configure renderer
22:34imirkin: not quite ideal...
22:35Shred00: so startup looked better but ultimately kodi segfaulted
22:36Shred00: libva info: Trying to open /usr/lib64/dri/vdpau_drv_video.so
22:36Shred00: libva info: Found init function __vaDriverInit_1_10
22:36Shred00: libva info: va_openDriver() returns 0
22:37imirkin: that's good
22:37imirkin: (i think)
22:39Shred00: indeed. that part looks better, after installing libva-vdpau-driver
22:40Shred00: i want to install gdb to get the ful stacktrace, but my disk is full. neeed to rebuild this live image and try again. probably tomorrow though.
22:40Shred00: thanks for all of the help and input imirkin. i seriously do appreciate it. maybe once i get a stacktrace, things might be a bit more clear.
23:52Lyude: imirkin: btw - were you planning on doing a new release since you added that patch for fixing compilation on xf86-video-nouveau? i'm about to update the package but I can wait a minute or two if you forgot to bump the release
23:52Lyude: (not letting myself get off work today until I actually do it)