03:16imirkin: abderrahim[m]: interlaced output means that the video decoder produces 2 separate pictures, one for each field. this is just how the decoder works.
03:17imirkin: the state tracker is supposed to take care of compositing it back together (or surfacing it to the caller of the api, if that's allowed)
03:17imirkin: sounds like st/va doesn't do this? or at least under some circumstances? it used to work.
03:17imirkin: unfortunately right now i have a G92 and GM206 plugged in, neither of which have working video decoding on nouveau
03:18imirkin: although ... interesting
03:18imirkin: all it's doing is trying to ALLOCATE the surface
03:18imirkin: not use it for decoding
03:19imirkin: that should actually be allowed ... maybe
03:19imirkin: how do i use vaapi?
03:23orbea: I found a case where where nouveau (And the llvmpipe) vastly outperform radeonsi...i mean like full 60 fps vs 7 fps...
03:24imirkin: if llvmpipe outperforms radeonsi, that's more of a problem with radeonsi...
03:27imirkin: orbea: you use mpv right?
03:27orbea: i switch back and forth between mplayer and mpv, so yes
03:27imirkin: do you know how to tell if hwdec is in effect?
03:28orbea: its been a while, but before it would print something when it was
03:28orbea: but it forces it off for a lot of content unlike mplayer
03:28imirkin: VO does not support requested hardware decoder, or loading it failed.
03:28imirkin: that was with -vo xv
03:28imirkin: Using hardware decoding (vdpau).
03:32imirkin: abderrahim[m]: so it only looks like that happens when exporting a va surface... how do i do that?
03:32orbea: last time I tried that with nouveau + mpv it didn't immediately blow up the system, but it did make mpv unstable where it tended to segfault. ITs been a while
03:32AndrewR: imirkin, I tried (successfully) to compile this version of mplayer https://aur.archlinux.org/packages/mplayer-vaapi/ and it sort of worked for me (just va-api display)
14:21karolherbst: imirkin: any thoughts on how much we care about race free driver statistics?
14:22karolherbst: I have a patch to use p_atomic_add instead, but... I don't know if we care all that much
17:03imirkin: karolherbst: probably worth it, if for nothing else than our own sanity
17:04karolherbst: well, it reduces the amount of warnings if running a thread sanitizer
17:04karolherbst: but I am not quite sure what the spec is saying regarding that
17:05karolherbst: or for what are the driver counters used?
17:05karolherbst: I thought we need them for some gl extensions
17:12karolherbst: imirkin: there is one stuipd issue I don't really know how to solve right now. st/mesa calls a st_flush every time a context gets flushed, which means that if we flush two contexts at the same time we also flush the screen twice which could lead to some mt problems regarding that screen pushbuf :/
17:13imirkin: i haven't had time to look at your series...
17:13imirkin: the driver counters are just exposed via various perf things
17:14karolherbst: right, but we write to them quite often
17:14karolherbst: allthoug I doubt it matters all that much
17:15karolherbst: overhead of p_atomic_add isn't all that high in the end
17:15imirkin: relative to how rarely we write them
17:16imirkin: and what other huge things we do in between
17:16imirkin: if it were in a tight loop, i'd care
17:16imirkin: it's not :)
17:17karolherbst: well, one could have a copy of that struct in each context, merge values into the screen on context_destroy and make it more expensive reading those counters out (by collecting the data from all contexts + the screen)
17:17karolherbst: but yeah.. it doesn't really matter
17:18imirkin: tbh, i don't think they're relevant at the screen level
17:18imirkin: but perhaps i'm not thinking it through
17:20karolherbst: well if we start to care about CPU overhead it might be worth looking into it
17:21karolherbst: the stupid thing about that screen race is that I am not 100% sure anymore. Deleted that thread sanitizer log and those were all polluted with those driver statistics races anyway, could have been that and I just remeber it wrongly
17:35karolherbst: but I think this is still a problem though :/
17:52imirkin: karolherbst: got those patches up somewhere? i have to look at the whole function for proper context...
17:53karolherbst: imirkin: there are all on my mt_fixes_take2 branch
17:53imirkin: which is located ...
17:54imirkin: thanks :)
17:55imirkin: is there a way to, in the github ui, expand all sections?
17:56karolherbst: in the patch view? yes
17:56karolherbst: you can look more on the top/bottom if you lock at that thingy...
17:56karolherbst: this blue button with that thingy in it, witht he tooltip "expand"
17:57imirkin: that's just expanding one thing
17:57karolherbst: but that doesn't really work all that well anyway
17:57imirkin: i want ... everything
17:57karolherbst: yeah :/
17:57karolherbst: "view file"?
17:57imirkin: that views the file at that version
17:57imirkin: i still want the side-by-side diff
17:58karolherbst: mhh, yeah, I guess there isn't anything better
17:58imirkin: anyways, i just went and clicked a bunch
17:58imirkin: it's fine
17:58imirkin: i'll live :)
17:58imirkin: i just need to see that whole opnd function to make sure you didn't accidentally miss something
17:58karolherbst: I should try out the gitlab ui at some point, maybe it's overall better, dunno
17:58imirkin: since there's various funky control flow
17:59imirkin: gitlab ui is equally crappy
17:59karolherbst: at first I was adding return true; instead of that delete = true thing, but that's obvisouly wrong :)
17:59imirkin: the thing i want was open-sourced as "rietveld", but as-is it won't be an ideal fit
18:00imirkin: i was one of the initial developers of that project
18:00karolherbst: isn't gerrit sameish?
18:00imirkin: yes, but i've never used gerrit
18:00imirkin: i've heard it's variously annoying, so i'm not sure if the things that i liked about that project got carried over
18:00imirkin: i implemented a lot of the UX on there, so ... it's very much to my liking ;)
18:01karolherbst: only stumpled across gerrit like one or twice
18:01imirkin: (late 2006)
18:01imirkin: IE7 had just come out, for reference.
18:02karolherbst: right.. that time
18:02karolherbst: where all were worried if IE6 was displaying that stuff properly
18:02karolherbst: which it wasn't
18:02imirkin: i got bugs for stuff being wrong in konqueror ;)
18:02imirkin: there was lots of magic
18:02karolherbst: yeah konqueror wasn't all that better
18:02imirkin: my favorite bug though had to do with character encodings
18:03imirkin: or ... not even encodings
18:03imirkin: but basically
18:03karolherbst: it was before their move to a proper webkit right?
18:03imirkin: imagine you have some code which says foo("abc", "def")
18:03karolherbst: KHTML was ... weird
18:03imirkin: except in the browser, it was being rendered as foo("def", "abc")
18:04imirkin: because abc/def were in arabic iirc, which is RTL
18:04imirkin: and we didn't have any sort of directionality reset characters thrown in
18:05imirkin: so it rtl'd the entire string "abc", "def" instead of abc separately and def separately
18:28drmacro: Getting the following from dmesg on ubuntu 18.04: "Direct firmware load for nouveau/nv84_xuc00f failed with error -2
18:28drmacro: " Is there a way to fix it?
18:30imirkin: you could install the firmware. it's for video decoding acceleration.
18:30imirkin: (i.e. vdpau/vaapi, that sort of thing)
18:40drmacro: imirkin: thanks that appears to have fixed it...didn't reboot yet though. But, restarting the app that caused it before doesn't show an error in dmesg Thanks! :-D
18:41imirkin: drmacro: cool. note that the decoding logic is ... imperfect
18:41imirkin: you get mpeg2 and h264, but h264 has some issues with some videos. but in general it's fine
18:45drmacro: imirkin: I don't do much video, I was getting the message when launching FreeCAD. But, this IS UbuntuStudio so I do occasionally do some video editing and run Ardour.
18:45imirkin: well, it could be loading a library which loads a library which loads a library
18:46imirkin: either way, this is part of getting accelerated h264 and mpeg2 decoding
18:46imirkin: although tbh, mpeg2 is almost faster on the cpu anyways ... moving that data around about the same speed as just doing it on the cpu
18:46karolherbst: imirkin: depends on the CPU though, I guess higher versions of SSE and AVX are helping here a lot
18:47imirkin: well, i know that on my i7-920 i had a REALLY hard time getting a G96 (GT 9500) to be faster at decoding mpeg2
18:47imirkin: i played a lot of games.
18:47imirkin: thing is ... vdpau isn't really well-styled for mpeg2 decoding on there
18:47imirkin: xvmc works much better -- iirc i got xvmc to be faster
18:48imirkin: coz mplayer/ffmpeg/etc have highly optimized VLD logic, whereas the VLD logic in mesa is not nearly as optimized
18:49karolherbst: mhh what are the bigger issues of xv btw? painful to fix tearing or something like that?
18:50imirkin: you mean xvmc?
18:50imirkin: it's perfectly fine for what it does
18:50imirkin: it was never extended for supporting h264 though
18:50imirkin: or for hardware-assisted vld
18:51imirkin: but for the featureset of VP2's (and VPE's) mpeg decoding, it's ideal
18:51karolherbst: ahh, I see
18:51imirkin: also it's harder to control presentation
18:52imirkin: to get subtitles or a video control element overlaid
18:52karolherbst: does it hard depend on X btw?
18:52imirkin: obviously :)
18:52karolherbst: right.. but it could be something easily fixed or super hard
18:53imirkin: it's a pretty crazy api
18:53imirkin: and it's bound to X in non-trivial ways
18:53karolherbst: so in regards to wayland we needed a replacement anyway. Just wondering why vdpau came about, or is it simply because nvidia didn't care all that much?
18:54imirkin: vdpau came out a LONG time ago
18:54imirkin: the G84+ have VLD for h264, so it made sense there
18:55karolherbst: right, but nvidia more or less cared about headless systems where you have no X at all
18:56drmacro: hmm...thinking outloud here; I was having some issues with this PC. SO to figure it out I swapped out the high end Radion card with the NVIDIA card. HAve I just caused myself a headache when I swap the Radeon back in?
18:56karolherbst: drmacro: shouldn't matter if you use open drivers
18:56karolherbst: and by open I mean mesa
18:57drmacro: hmm...I just have what ever UBS installed by default.
19:01karolherbst: no idea what that installs
19:03drmacro: karolherbst: hmm...one place on the web says 18.04 has mesa by default, another says there's a ppa for 18.04 Never easy... :P
19:03imirkin: yeah, we don't really do distro support here
19:03imirkin: if you have questions about your distro, you should ask in a distro-related support chan
19:05drmacro: karolherbst: wasn't ask for that...more like mumbling to myself...outloud. ;-)
19:05karolherbst: well, if you don't switch away from mesa you should be fine
19:06karolherbst: there is this prop AMD stuff some people think is a good idea to use
19:07drmacro: karolherbst: I guess I'll surprise myself when I swap the other card back.
19:07karolherbst: well if all you do is switching cards it shouldn't break
19:08drmacro: karolherbst: thanks! I'm outta here for now.
21:19imirkin: Lyude: https://hastebin.com/utisivihoy.cs
21:19imirkin: any thoughts?
21:19imirkin: i _think_ this happened when flipping a dell display from DP 1.2 to DP 1.1 mode
21:35Lyude: imirkin: yikes! although that feels like an error I've seen/fixed befor
21:35Lyude: is 4.18.12 the latest 4.18.x stable?
21:38imirkin: i also apparently have some local patches, although i don't think they're yours
21:38imirkin: ah right, it was my HDMI2 stuff
21:40imirkin: Lyude: i guess this is part of the same badness - https://hastebin.com/feqedimomu.cs
21:40imirkin: karolherbst: feel like reviewing https://patchwork.freedesktop.org/series/53517/ ?
21:44karolherbst: imirkin: ohh right, I forgot about that. the nouveau changes looked fine, just wanted to take a deeper look at that lowering and that "nv50/ir: ensure that the constraint mov is placed above flow control" patch
21:45karolherbst: wondering why that is needed
21:45imirkin: it's not deeply related to this series
21:45imirkin: it's just that this series makes this situation occur reliably
21:45karolherbst: usually you want to construct two bbs for that :/
21:45imirkin: i used to have a comment in there about critical edge splitting
21:46imirkin: but i'm not longer convinced that's the case.
21:46imirkin: basically you might have multiple branches at the end of a bb
21:46imirkin: that's always the case
21:46imirkin: e.g. 1 conditional and 1 unconditional
21:46karolherbst: okay, right
21:46imirkin: you want the mov to go above the conditional branch
21:47karolherbst: so you make that fallthrough more explicit
21:47imirkin: that said.
21:47imirkin: when i removed the explicit jump
21:47imirkin: from the generated lowering code
21:47imirkin: it still didn't work
21:47karolherbst: I don't think you need that "bld.mkFlow(OP_BRA, joinBB, CC_ALWAYS, NULL);" if the next bb is joinBB
21:47imirkin: yeah. i tried removing that.
21:47karolherbst: or well, you shouldn't have to need it
21:48imirkin: it's there in the tgsi handling of if/else/endif
21:48karolherbst: you didn't add the edge
21:48karolherbst: addAndCasBB -> joinBB
21:49imirkin: fuck me
21:49imirkin: i think you're right, and then i can delete all that
21:50imirkin: + BasicBlock *addAndCasBB = atom->bb->splitBefore(atom, false);
21:50imirkin: + BasicBlock *joinBB = atom->bb->splitAfter(atom);
21:50imirkin: i'll have to double-check what all that does
21:50karolherbst: ohh wait
21:50karolherbst: the order of the edges is screwed
21:50karolherbst: the last one is the fallthrough, right?
21:51imirkin: BasicBlock *splitAfter(Instruction *, bool attach = true);
21:51karolherbst: so it would jump to addAndCasBB in both cases
21:51imirkin: so i think it's attached.
21:51imirkin: does the order of edges matter for that?
21:51karolherbst: how else would it know to which bb to jump?
21:51imirkin: the TREE one
21:52karolherbst: there is no such logic afaik
21:52karolherbst: only the last one afaik
21:52imirkin: or first ;)
21:52karolherbst: so if the second split does attach = false
21:52imirkin: i'll investigate
21:52karolherbst: and you add the second edge explicitly
21:52karolherbst: I would expect it to work
21:52imirkin: i'll try it
21:52imirkin: of course that GPU is dead now coz of the DP fail
21:52imirkin: so i'll have to reboot
21:53imirkin: although i can just check the compilation of it
21:53imirkin: but i have to reboot anyways.... bbiab
21:54karolherbst: in my nir code when handling if/else: bb->cfg.attach(&ifBB->cfg, Graph::Edge::TREE); bb->cfg.attach(&elseBB->cfg, Graph::Edge::TREE);
21:54karolherbst: and else is the implicit jump
21:56karolherbst: or it's the other way around.. need to udnerstand that code again
21:58imirkin: Lyude: gonna build 4.19.8 while i'm at it
21:58karolherbst: nope.. I was confused how we do OP_SET ssa_value
21:58karolherbst: so yeah, the else branch is the last one
21:59karolherbst: uhm I meant a OP_BRA with reg as the condition
22:00karolherbst: it's all weird though
22:01karolherbst: okay, now I got it
22:02karolherbst: I have a OP_BRA into the else branch with a !condition check. "mkFlow(OP_BRA, elseBB, CC_EQ, src)->setType(sType);" -> if src is 0 branch into elseBB. So that makes the explicit branch the second edge and the implicit one the first edge :/
22:04imirkin: which is what i have
22:05karolherbst: okay, but nothing connects addAndCasBB and joinBB
22:06karolherbst: it's connected with curBB
22:06karolherbst: addAndCasBB that is
22:06imirkin: sure it does
22:06imirkin: the splitAfter() does
22:06karolherbst: "atom->bb->splitAfter(atom);" connects curBB with joinBB
22:07karolherbst: or not?
22:08karolherbst: anyway, looking at the IR print might help
22:11imirkin: it should connect the bb that atom is in to joinbb
22:11karolherbst: which isn't addAndCasBB
22:13karolherbst: I am sure a "addAndCasBB->cfg.attach(&joinBB->cfg, Graph::Edge::TREE);" before/(after) the other attach should fix it
22:13karolherbst: imirkin: which tests did you use for that? would make it easier for me to look into it as well
22:14imirkin: the shared atomicAdd one
22:14imirkin: in piglit
23:01AndrewR: just as comment, I tried to play Mafia 2 (dx9 game from 2010) on somewhat reclocked (core +shader) 384 Mb vram G92 [GeForce 8800 GS] , with nouveau of course (fairly recent mesa git after texture upload limiting patches + kernel 4.19)
23:02AndrewR: it works, but slowly (5-9-10 fps in open areas, up to 15 fps in small rooms). Adding AA from game menu just resulted in rejected pushbuffers and some black texture flashing ..but without AA it works ....
23:03AndrewR: I wonder if game slow due to small (by today's standards) vram size .....
23:04karolherbst: dunno, maybe?
23:05karolherbst: a game from 2010 will most liekly not run very well on a 8800 GS
23:05karolherbst: the higher is high, but that GPU wasn't exactly fast
23:05AndrewR: karolherbst, it was fast for things like doom3 :)
23:06karolherbst: oh well
23:06AndrewR: karolherbst, and I think Unigine Tropics worked fairly well (but heaven was too heavy ...still worked at low , 1440x900)
23:07AndrewR: karolherbst, I don't think nouveau exposes requested vram/gtt like radeon? at least it doesn't wired to HUD.....
23:07karolherbst: we don't afaik
23:07karolherbst: anyway, we don't really handle out of memory situations
23:11AndrewR: karolherbst, yeah, and for now only way to detect such situation by its side effects, like "[72752.504063] nouveau 0000:01:00.0: mafia2.exe: nv50cal_space: -16" in dmesg and or visually ..?
23:12AndrewR: karolherbst, still, thanks for working on all this stuff like per-context (?) pushbuffers even if for nvc0 for now ... it was stalled for years (as task), so it really nice to see some progress there
23:13karolherbst: AndrewR: it's easibly to add that to nv50, I just was simply lazy
23:13karolherbst: should be more or less trivial
23:15AndrewR: karolherbst, unfortunately it not trivial for me ..... so, if you will prepare some patches somewhere - I can test them, but sadly not modify ones you already send (so much for hanging around here for like 11 years, on my side)
23:16karolherbst: AndrewR: well I wanted to first focus on getting it right for nvc0 and then look into all that stuff on the older ones... chances are I might have to rework stuff significantly again and it's easier to just do that for one of the three versions ;)
23:18AndrewR: karolherbst, ok ..should I put testing request on some rssian linux site i frequetly hang at?
23:18AndrewR: *russian /u key tend to skip hitting here on my keyboard
23:28karolherbst: if anybody is up for that, sure
23:43AndrewR: karolherbst, posted: https://www.linux.org.ru/forum/desktop/14660570
23:43AndrewR: karolherbst, i think there must be mesa branch somewhere too?
23:44AndrewR: https://github.com/karolherbst/mesa/commits/mt_fixes_take2 ?
23:44karolherbst: yeah, but I might force push into it
23:46AndrewR: karolherbst, added this line .. (some users can read/write english tehre, or at least ask someone to translate their reslts back, so it hopeflly ok to leave some english text there)
23:58AndrewR: ...still, i sort-of idle wonder why context-switch on nw hardware was/is so slow? It was designed to separate applications (via virtualization of few available hw contexts?) instead of giving each thread its own context?