00:13 imirkin: untested, but i think this works: https://paste.debian.net/1188362/
00:15 imirkin: unlord: i'll test it out later
00:15 unlord: ok
00:15 imirkin: along with some benchmarks
00:15 unlord: please try mpv -vo=drm on the console
00:15 imirkin: i just have the cpu i have (i7-920), so obviously limited
00:16 imirkin: like i said - i don't have anything hooked up to the tnt2
00:16 imirkin: and it's not easy for me to get the other monitor out
00:16 imirkin: my current monitors are digital-only, sadly
00:19 unlord: imirkin: I had that problem recently and bought two VGA to DVI converters for $4
01:03 imirkin: unlord: A2D presmably? i have plenty of the round hole / square peg ones
01:04 imirkin: i.e. DSUB <-> DVI-I -- i got those.
01:37 imirkin: urgh. of course i can't easily test this code. it relies on some pre-nv50 methods
01:37 imirkin: ok. will worry about that later.
01:44 unlord: imirkin: you gotta boot your TNT2
01:46 imirkin: ?
01:47 unlord: that is how you run pre-nv50
01:48 imirkin: ah yeah, heh. or i can get any one of my nv3x/nv4x's with DVI
01:49 imirkin: and be able to do some slightly more useful testing
01:49 imirkin: this is still in here from when i was debugging some seemingly-pre-nv10-specific issues
01:49 imirkin: which they weren, but definitely a lot easier to trigger on there
01:49 imirkin: (fixed in 1.0.17)
01:50 airlied: skeggsb: hey: noticed I made a mistake, would be good to confirm https://patchwork.freedesktop.org/patch/423175/
01:51 imirkin: unlord: i'll try mpv -vo drm now on my desktop, but i bet it'll ahve the same results as you on yours...
01:52 imirkin: yeah, of course that works fine
02:07 imirkin: hm. SSE2 has a pavgb which is exactly what i want.
02:08 imirkin: oh! and SSE does too. why didn't i see that before...
03:32 imirkin: i really should finish off the overlay support. sigh
03:32 imirkin: pmoreau: ping =]
03:58 imirkin: unlord: try it with -vo x11 -- that should force the conversion to bgr
05:41 imirkin: mwk: fwiw, i've confirmed that "st s[]" obeys predicates
05:41 imirkin: so it must just be something "st unlock"-specific
05:55 imirkin: and also confirmed that g[] atomics also respect predicates
06:10 imirkin: i wonder if it really just wants the double-store
06:44 unlord: imirkin: so it worked fine for you?
06:46 imirkin: no
06:46 imirkin: i mean - yes, but that was expected
06:46 imirkin: it was on x86_64 and on a more recent gpu
06:47 imirkin: but in order to get a similar experience to the one you have with drm, you could try -vo x11
06:47 imirkin: which i think would get a similar conversion in your setup
10:38 lichun: hi, I ask a question.
10:39 lichun: I tried to compile NVIDIA-Linux-x86_64-460.56.run, almost done, it report: -> Unable to determine if Secure Boot is enabled: No such file or directory
10:51 RSpliet: lichun: wrong channel. That's a different driver, and it sounds like you might need distro support. It's unlikely you'll find someone with expertise on that ehre
10:52 RSpliet: NVIDIA does have an unofficial IRC channel, but I'm not sure they're very active over there.
11:03 lichun: RSpliet: which unofficial IRC channel where I go?
11:32 RSpliet: think it's just called #nvidia
11:54 lichun: RSpliet: thanks
15:50 nmschulte: Thanks for getting nouveau.fd.o back online.
15:51 nmschulte: vaapi h264 decode on nv98 mostly works, but for certain video resolutions, it produces corrupt output: https://desmas.net/zoneminder-nouveau-8400-gs-rev2-vaapi-2048.png
15:51 aldcor: hi. will it be possible to run blender on nouveau some time soon?
15:52 aldcor: https://0x0.st/-P7H.txt
15:52 nmschulte: Q: how can I diagnose this, improve it? With nvidia 340 driver, VDPAU fails for certain resolutions too, even if they meet the max-w/max-h constriant: https://paste.debian.net/1188354/
15:53 imirkin: nmschulte: what resolutions are problematic specifically?
15:54 imirkin: note that we may have skimped on some size checks in nouveau
15:54 imirkin: but just because we don't enforce it doesn't mean that the hw magically works :)
15:55 imirkin: aldcor: this is the first i hear of issues. tell me more about your setup, including blender version?
15:55 imirkin: in the past, blender has worked fine
15:57 imirkin: nmschulte: http://us.download.nvidia.com/XFree86/Linux-x86_64/340.108/README/vdpausupport.html -- i believe nv98 is vdpau feature set B
15:57 imirkin: also some fun notes like "GPUs with this note may not support H.264 streams with the following widths: 49, 54, 59, 64, 113, 118, 123, 128 macroblocks (769-784, 849-864, 929-944, 1009-1024, 1793-1808, 1873-1888, 1953-1968, 2033-2048 pixels)."
15:58 karolherbst: ehhhhhh
15:58 karolherbst: very specific
15:58 imirkin: ;)
15:58 imirkin: like i said, the hw can do what it can do. just because we don't enforce it doesn't mean it'll work
15:59 imirkin: nearly all of the "vdpau feature set B" GPUs have that note btw
15:59 imirkin: http://us.download.nvidia.com/XFree86/Linux-x86_64/340.108/README/supportedchips.html
16:00 nmschulte: imirkin: correct, VP3/feature set b. is there an existing tool I can use to permute the hw w/h/mbs combos to determine constraints? I have a whole list of various sizes, but can write a script to permute.
16:01 imirkin: see the docs i linked to above
16:01 imirkin: they cover the constraints
16:01 nmschulte: 1920x1080 works great ;). thank you for the docu, looking now.
16:01 aldcor: blender version 2.90.1. I got lenovo y50-70 NVIDIA Corporation GM107M [GeForce GTX 960M]. I tried nvidia driver and nouveau. On both it worked poorly. Can't render image. When i do, everything freezes. Specs are in the `middle range` so I assumed should work fine (not perfect). I tried DRI_PRIME=1 blender and it helped to look better while I was in blender but it didn't help with rendering.
16:01 imirkin: yeah, so like the common stuff works fine
16:02 imirkin: aldcor: do you know what "render image" entails? i'm not familiar with blender (i know what it is, but not much beyond that)
16:02 imirkin: also note that without DRI_PRIME=1 or equivalent, you're running everything on the built-in intel GPU
16:02 imirkin: i.e. nothing to do with nouveau
16:03 aldcor: oh. Alright. What would you suggest me to do?
16:03 imirkin: aldcor: well, your backtrace has nouveau in it -- so presumably that was with DRI_PRIME=1 ?
16:04 aldcor: i think yes
16:04 imirkin: aldcor: the best thing would be to come up with a way to reproduce that does not require me to have or know how to operate blender. you may be able to take an apitrace of it to capture the commands that are running
16:04 imirkin: and then if replaying the trace reproduces the error, then all is well
16:04 imirkin: aldcor: btw, can you check dmesg and see if there are any errors there? that could also indicate what's going on
16:05 imirkin: nmschulte: and if you'd like to add better size checks to nouveau, be my guest!
16:06 aldcor: there are some nvidia and noveau related messages but all they say is that nouveau has taken over
16:06 aldcor: i have removed nvidia now too
16:06 imirkin: any errors from nouveau?
16:06 imirkin: like validate_list: -2 ?
16:07 aldcor: oh i see 7.200276] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 022554 [ IBUS ]
16:07 imirkin: that's fine
16:07 aldcor: no.. other than that no errors
16:08 aldcor: well i got some usb errors but nothing to do with noveau
16:08 imirkin: sure
16:08 imirkin: could be that blender is trying to do GL from multiple threads?
16:08 imirkin: that won't necessarily work well with nouveau
16:08 nmschulte: imirkin: I see that my problem is the overall constriant: macbs (macroblock size/count). I will definitely create patches for nouveau w/ my relevant checks. Is there any debug/tracing available in the module, like VDPAU_TRACE for nvidia driver?
16:09 imirkin: VDPAU_TRACE works with libvdpau
16:09 nmschulte: correct; wondering if there's a nouveau/vaapi variant of the idea
16:09 imirkin: it's not vdpau-backend-specific
16:09 imirkin: oh
16:09 imirkin: no.
16:09 imirkin: i just use VDPAU_TRACE :)
16:10 nmschulte: nouveau supports vdpau (via vaapi? or v/v)?
16:11 imirkin: nouveau supports video decoding. mesa has vdpau and va-api state trackers built on top of that.
16:11 imirkin: ultimately the build produces a libvdpau_nouveau.so which you can use with libvdpau...
16:11 imirkin: (and also a libva_whatever)
16:12 nmschulte: excellent, thank you again.
16:12 imirkin: (i know a lot less about libva tbh)
16:13 nmschulte: > effort is underway to fully reverse the underlying engines and create open-source firmware to provide out-of-the-box video decoding -- is this still accurate? (From n.fd.o WWW site)
16:13 imirkin: it was never accurate.
16:13 imirkin: it was hopeful at best
16:13 imirkin: there were some incomplete efforts to understand the VP2 engines
16:13 imirkin: but nothing for VP3+
16:14 imirkin: nmschulte: if video stuff is something you're interested in, you're welcome to try to make VP6+ work :)
16:14 imirkin: nvidia even released NVDEC (and NVENC!) docs recently, for tegra, but probably desktop is similar
16:16 imirkin: https://nvidia.github.io/open-gpu-doc/classes/video/
16:16 imirkin: (and everyone's favorite - nvjpg)
16:17 nmschulte: that's fascinating, but I have no hardware to work with, nor time. nor interest in working w/ NVIDIA at all really.
16:17 imirkin: =]
16:17 imirkin: no worries
16:18 nmschulte: right now I've just resurrected some old hardware that I ran into these quirks with. very happy with how well the system is working w/ nouveau. simply didn't understand the macroblock constraint listed in the docu (and n.fd.o was down!).
16:18 imirkin: i dunno why that was -- that's run by the fd.o infra
16:19 nmschulte: it looked like an internal/reverse proxied host was down; "bad gateway" issues. it's up now. :)
16:20 imirkin: ah ok. we don't run it directly. in the future if you have infra-level issues with fd.o, you can reach people who can do something about it in #freedesktop
16:21 imirkin: nmschulte: but more than those macroblock issues, some videos just have problems. i never was able to figure out why.
16:21 imirkin: it works on nvidia blob, but not with my code
16:21 imirkin: can't imagine who's to blame ;)
16:24 imirkin: what's esp surprising is that the same failure appears on both VP2 and VP3+
16:24 imirkin: even though they're substantially different engines
19:59 imirkin: pmoreau: ping :)