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