01:06orbea: ever see a hwdec bug with mplayer like this? :P https://i.imgur.com/Ex4uyrk.jpg https://i.imgur.com/jRZqEyG.jpg
01:50imirkin: orbea: hmmm... every so often, the whole engine gets fucked up
01:50imirkin: and it randomly fixes itself a play or two later
01:51imirkin: this seems well beyond the usual messing up of h264
01:51imirkin: so if this repros, i'd love to get the source video.
02:04orbea: seems reproducible, I can send you a sample soonish
02:04orbea: however its not always green, this time its purple...
02:20imirkin: yeah, probably an uninitialized buffer or something
02:20imirkin: could also be something broke recently
02:20imirkin: i haven't been paying close attention to all the various changes
02:58imirkin: i _really_ need to take some time and beef up demmt for vdec stuff
02:59tannerb3: hey guys, I just got an nvidia card and am trying to use nouveau on wayland with sway and a 1080 and 4k monitor. As soon as I open something on the 4k monitor my framerate drops a bunch, probably to 20-25fps, but the 1080p monitor is still fine
02:59tannerb3: I have been trying to google it but most things I end up seeing are links to low framerates in video games :)
02:59imirkin: tannerb3: my guess is that the 4k monitor comes up in a 30hz resolution, and your WM isn't great at handling 2 monitors with diff refresh rates
03:00imirkin: tannerb3: what GPU do you have, and how is your 4k monitor connected?
03:00tannerb3: both are running at 60hz. I have a GTX1080 so that should definitely be no issue, and my 4k is connected via DisplayPort
03:00imirkin: (wow, i'm tired... sorry... 30hz *mode* is what i meant)
03:01tannerb3: haha, I understood you :P
03:01imirkin: ok, so that's ruled out...
03:01tannerb3: yeah, if I have nothing open on the 4k side, I get a solid 60hz (judging via mouse stutter)
03:01imirkin: do you have accel firmware installed for the gp102?
03:02imirkin: i dunno how wayland mouse works, but normally mouse is a separate plane and adjusting it is ~instant
03:02imirkin: pastebin 'glxinfo' output (or 'eglinfo')
03:03skeggsb: could also be that there's just not enough memory bandwidth to go around
03:03tannerb3: no I have never heard of that before
03:03imirkin: [yeah, glxinfo requires X, but it should work with XWayland and provide roughly what i'm looking for]
03:03tannerb3: yeah I have xwayland
03:03imirkin: skeggsb: yeah, that's the "sad" answer to the question
03:04imirkin: but basically i want to make sure that you're using accel to render stuff rather than CPU
03:04tannerb3: I feel like it may be CPU
03:04imirkin: ok yeah, looks all happy
03:04tannerb3: because jetbrains is fairly heavy when it is idnexing
03:04imirkin: which means that you have GPU accel
03:04tannerb3: ah darn
03:05imirkin: soo.... what skeggsb said :(
03:05imirkin: we appreciate that you have a choice of vendors when buying a GPU, and you appear to have chosen poorly.
03:05tannerb3: what do you mean by Memory Bandwidth
03:05tannerb3: yeah that's not hte first time I've heard that in the last few days
03:06imirkin: well, the images sit in VRAM on the GPU
03:06tannerb3: I was in the Sway irc a hwhile ago, whew, there was some anger there
03:06imirkin: in order to get to the screen they have to be read out from VRAM and encoded into bits on the wire
03:06imirkin: if the VRAM is clocked too low, then it can't do that
03:06imirkin: and when it can't do that... it's not entirely clear what happens
03:06tannerb3: I have a GTX1080
03:06tannerb3: how could that not handle this
03:06imirkin: uh huh
03:07imirkin: well, it boots up with pretty low clocks
03:07imirkin: so ... "easily"?
03:07skeggsb: tannerb3: because, we can't change memory speed reliably on most boards, and not at all on yours
03:07tannerb3: sorry guys, forgive me, you're a little out of my depth
03:07skeggsb: nvidia have blocked us from parts of the gpu cryptographically, and refuse to help
03:08tannerb3: I'm just trying to get 60hz while doing my work
03:08imirkin: tannerb3: in order to save power, GPUs allow changing clock speeds for various parts of the board. much like CPUs do.
03:08tannerb3: that's really shitty of them
03:08skeggsb: yes it is, but such is life
03:08imirkin: tannerb3: changing those clocks is a tricky dance.
03:08imirkin: tannerb3: and nvidia requires cryptographically-signed firmware on your board in order to perform that dance. which they don't release.
03:09imirkin: [like i said, you have chosen poorly]
03:09tannerb3: yes, I have heard. My girlfriend calls that 'non-constructive criticism'
03:11tannerb3: thanks for your help guys
03:11tannerb3: looks like I'm sol
03:11tannerb3: how long is Neweggs return policy
03:11tannerb3: shoulda bought amazon.. damnit
03:11imirkin: they're generally pretty good... 30day? i forget.
03:11imirkin: although tbh i've never returned anything to them
03:12imirkin: the one time i wanted to, it wasn't economically logical to do so
03:12imirkin: so i just put MSI on my "never buy again" list, and moved on with life
03:17imirkin: might charge a 15% restocking fee
03:20imirkin: orbea: i dunno wtf is going on. it's like the I-frames are getting all messed up, but all the other frames work fine.
03:20imirkin: this is the opposite of what normally happens, i.e. the I frames are fine, and all the other frames get messed up ;)
03:23orbea: huh, interesting
03:24orbea: its quite possible who ever made the video didn't really know what they were doing :)
03:25imirkin: well, it plays fine with other stuff
03:25imirkin: it's even more possible that whoever wrote the nouveau stuff didn't know what they were doing ;)
03:53imirkin: orbea: btw, if you have blob handy, a mmt trace of mplayer would be useful
03:53imirkin: just like the first few frames until corruption initially comes up
03:53imirkin: [mmt trace of mplayer running with blob vdpau, obviously]
03:55orbea: i dont have it handy, but if it really helps I can try later
03:55imirkin: well, dunno when i'll have time to look at it
03:55imirkin: so don't kill yourself over it
03:55orbea: fair neough
04:19imirkin: hm, looks like it's picking up "bs" data when decoding I-frames
04:20imirkin: i initialized all the "reference" frames to 0, and now it's deterministically green
04:20imirkin: (and YUV 0 = RGB green)
04:21imirkin: orbea: in case you feel like playing with it: https://hastebin.com/nixetuyayi.hs
04:22imirkin: basically in nvc0_video_vp.c we fill unset reference frame args with the "null" reference frame, which has random data.
04:22imirkin: it's normally not supposed to pull data from there
04:22imirkin: and yet it does
04:22imirkin: i don't know if there's something illegal in the bitstream that we're supposed to be normalizing away
04:22imirkin: or if ... something else
04:23imirkin: unfortunately my in-depth knowledge of video codecs doesn't extend past MPEG-2
09:04mlankhorst: h264 part 2 is still easy :)
09:07mwk: h264 part 2?
09:09mlankhorst: ugh, mpeg4*
09:09mlankhorst: mpeg4 part 2 or h263, definitely not h264
12:43_xvilka_: Hi! on your wiki at https://nouveau.freedesktop.org/ git link is obviously wrong - it links to https://github.com/skeggsb/linux which seems abandoned
12:50RSpliet: _xvilka_: look again. There's per-kernel branches up to 4.14 in that github repo
12:50RSpliet: it's not obviously wrong, it's non-obviously right
12:57Smidget: does nouveau support g-sync monitors? ive been using the propriatary drivers but i want to switch to wayland+sway and they dont intend on supporting the propriatary driver. im a bit new to the linux ecosystem
13:01Smidget: also id be interested in a discussion about why its so hard to support nvidia proprietary drivers. Are there optimizations that make sense for them to have closed source?
13:02imirkin: Smidget: g-sync is the nvidia version of freesync right?
13:02imirkin: there's no special support for that in nouveau, but the monitor should light up just fine with a fixed refresh rate
13:03imirkin: as for your second question... not sure what you're asking
13:03Smidget: one second
13:03imirkin: if your question is, "why are nvidia being a bunch of douches and not playing nice with the open source community", then you've come to the wrong place to ask it
13:04Smidget: well thats not really my question, my question is more along the lines of "what is the marketing reason to not have it open source?"
13:04imirkin: same reason as always, "IP"
13:05Smidget: so no reason
13:05Smidget: basically lol
13:05_xvilka_: RSpliet: yes, I saw those branches, was distracted that master is super old, and another page recommends to use master as the latest source
13:05imirkin: one might ask further, "what is the reason not to provide the signed firmware blobs WHICH ARE SHIPPED WITH DRIVER ANYWAYS as a separate package"
13:06_xvilka_: or more like some top-manager position against it, without real motivation
13:06imirkin: and you'll come up similarly short of good answers
13:06_xvilka_: most likely the person who doesn't know the difference between bit and byte
13:08Smidget: ok, thanks. I started with an nvidia gpu before i got into all this. Been a developer for a while but always was on the web side of things so i never saw the issues with nvidia drivers
13:08Smidget: prob going to switch to amd somewhere down the line
13:08imirkin: good idea.
13:08imirkin: or intel
13:08imirkin: depending on your graphics needs
13:09Smidget: Yeah I prefer something a bit more beefy for sure. I dual boot windows so I need something to drive games on there
13:09Smidget: but yeah, thanks for the info! gonna hop off now
13:34tarragon: does anybody know how to debug a game crashing always at the same spot and same action?
13:34tarragon: the message got something to do with GLES
13:34tarragon: doesn't tell a lot nor is anything in Xorg.0.log.
13:34orbea: is it a free game you can build with debugging symbols and get a backtrace from?
13:35imirkin: run in gdb and see where it's crashing?
13:36tarragon: I am curious because this game used to crash in the same stage but further down and it was the same spot back then as well. Different spots but predictable crash everytime.
13:36tarragon: imirkin: so gdb is the easiest way to do it?
13:36tarragon: and how to save the log?
13:37imirkin: what log?
13:37tarragon: that complicated way 1>&2 /dev/null or somesort.
13:37orbea: gdb program 2>&1 | tee gdb.log
13:37imirkin: then you lose interactivity no?
13:37orbea: not with tee
13:38imirkin: tee will be the foreground process
13:38tarragon: orbea: thanks
13:38imirkin: so... no interactivity with gdb
13:38orbea: i just know I do that regularly and it works
13:38imirkin: and you can run commands in gdb?
13:39imirkin: i'll have to figure out why that works
13:40orbea: it will start to add symbols to the log if you type and have to use backspace though :P
18:15tarragon: fast output terminal with nouveau X jumps up to 30% cpu usage.
18:15tarragon: with amdgpu hovers at around 1% cpu usage.
18:15tarragon: do I have the wrong 2d or whatever loaded?
18:15tarragon: 30% is a bit excessive.
18:33imirkin_: tarragon: i've noticed that too...
18:33imirkin_: tarragon: my guess is that with your AMD setup you have a compositor and/or TearFree enabled?
18:34imirkin_: tarragon: but it kinda sucks. i haven't looked in detail why it happens
18:34imirkin_: can you confirm that you're using xf86-video-nouveau and not modesetting?
18:39imirkin_: skeggsb: quite the push
18:42skeggsb: yes... let's see how to world falls over, though, to be fair, it hopefully shouldn't.. i went through a lot of pain testing it
18:42imirkin_: skeggsb: not to mention fixing it, i imagine ;)
18:42imirkin_: skeggsb: what's the headline version of what this all gets us?
18:43skeggsb: nothing exciting atm, until userspace can do useful things with it (i haven't exposed it there yet)
18:43imirkin_: is this enough to let userspace place objects at specific VA's?
18:45imirkin_: oh, does this enable non-4K cpu pages?
18:45skeggsb: pascal is using its proper mmu layout now, suspend/resume should be rather faster, various optimisations that weren't possible before (merging pte unmap+unrefs together, some optimisation the pascal doc mentions when mixing large and small pages in the same range, skipping pte unmap writes if the whole page table is going away... etc etc)
18:45skeggsb: yes, in theory
18:45skeggsb: i haven't tested it
18:45skeggsb: pascal also gets 2MiB large page support
18:45imirkin_: i saw that one
18:46imirkin_: did you test with old GPUs much?
18:46skeggsb: // piglit runs got quicker by a few minutes somehow too
18:46skeggsb: yeah, they didn't seem to break any more than they already were :P
18:46imirkin_: [i mean pre-G80]
18:47imirkin_: ok good
18:47skeggsb: tested at least one board for every major change in mmu support
18:47skeggsb: and at each "stage" of the series, so, should be bisectable
18:48skeggsb: rebuilding the module that often, for every different board, with a kernel that has KASAN enabled is... frustrating ;)
18:48imirkin_: as compared to my "yeah, sometimes i compile it first" style of testing ;)
18:49skeggsb: it's mostly laying the foundations for exposing more flexibility to userspace, while untangling some mess that's resulted from the last decade
19:00imirkin_: skeggsb: well, congrats on getting it out there
19:00imirkin_: now you can go to sleep ;)
19:03tarragon: some testings, unpacked some dir with many files which produce fast terminal output onto /dev/shm. With tmux 30% cpu usage and 5 seconds. With xterm alone it too 24 seconds and sustained 80-90% cpu usage.
19:03tarragon: imirkin_: no modesetting means NOUVEAU(0) in Xorg.0.log?
19:04imirkin_: should see why that's happening
19:04imirkin_: e.g. run perf on Xorg while this is happening
19:04tarragon: so confirmed I have NOUVEAU(0)
19:04imirkin_: and then see where that CPU time is going
19:04imirkin_: tarragon: what GPU btw?
19:04tarragon: 104 I think
19:04imirkin_: (hopefully not NV04/NV05 since those are largely unaccelerated due to... fail.)
19:05tarragon: with the amd it's a brand new install, plain fluxbox and xterm with default fonts.
19:05tarragon: hold on
19:05imirkin_: either way, pastebin xorg log
19:06imirkin_: just to double-check there's no silliness there
19:07imirkin_: hm, that should work fine unless you've messed things up bigtime somehow
19:09imirkin_: tarragon: anyways, if you're so-inclined, it'd be interesting to see where the cpu time is going
19:10tarragon: i'll run perf, how to do this?
19:10tarragon: imirkin_: how to check that?
19:10imirkin_: search the googs
19:10imirkin_: whatever you do, just don't attach to Xorg with gdb from a terminal emulator running on that X server ;)
19:11tarragon: I don't thing xterm is using any expensive anti-aliasing or hinting.
19:11imirkin_: i'm sure it's not
19:11imirkin_: if it were, chances are there'd be less cpu time used ;)
19:11tarragon: imirkin_: so you don't have a readily usable perf command?
20:07RSpliet: is it me you're looking for...?
20:07RSpliet: I can see it in your eyes...
20:09Lyude: finally, finally, finally actually working on powergating :D
20:17Lyude: Also, has anyone been seeing weird visual artifacts with kepler on 4.14.0-rc7?
20:18imirkin_: someone mentioned something about that earlier
20:18imirkin_: i said 'no'. but now the answer is 'yes' ;)
20:19Lyude: alright, looks like I've got some warmup :)
20:20imirkin_: now i can't find it obviously =/
20:23imirkin_: perhaps i dreamt it?
20:24imirkin_: Lyude: is it the result of a kernel upgrade? or perhaps mesa?
20:25imirkin_: Lyude: definitely run mesa-master -- i'm giving up on attempting to support any of the so-called stable releases
20:26Lyude: imirkin_: I'm not sure if it's just a kernel upgrade causing it but I'm about to find out
20:29tarragon: gdb doesn't find debug symbols
20:30Lyude: yes, I'm sure we all can relate
20:32tarragon: mm.. wrong chan
20:32tarragon: I meant ppsspp
20:42tarragon: by the way "Stream Thread I[G3D] /GLES/ShaderManagerGLES.cpp"
20:46imirkin_: tarragon: well, nouveau + threads = quick way to fail
20:47orbea: is ppsspp doing that now too? :(
20:48orbea: wasn't last time I checked...
20:48tarragon: orbea: some games play nice, is just this one. on a particular stage.
20:49imirkin_: perhaps it's not - i dunno
20:49imirkin_: did you get a backtrace?
20:49tarragon: segfault with 'long string libc' in dmesg
20:49imirkin_: (and do you have debug symbols for nouveau?)
20:49orbea: tarragon: mind sharing what game?
20:49tarragon: orbea: Peace Walker
20:50orbea: idk it
20:50tarragon: orbea: Metal Gear.
20:50imirkin_: karolherbst: you got a few to do a mmiotrace of mplayer?
20:50tarragon: could be a combination of many things, such as ppsspp graphics options etc.
20:51imirkin_: tarragon: well, should try to see if it crashes in ppsspp or in nouveau
20:51tarragon: orbea: I could upload the 'saved game' and you try it.
20:51orbea: not now
20:51orbea: a backtrace is not too hard to get
20:52tarragon: imirkin_: what do you mean? I am using ppsspp witha nouveau driver.
20:52orbea: if you crash it in gdb it will show you where its crashing which will help determine if its a nouveau or ppsspp bug
20:53tarragon: orbea: gdb not working with ppsspp
20:53orbea: it should
20:53tarragon: dunno whether it makes a difference it's PPSSPPSDL, not the qt backend.
20:53orbea: does it only happen with teh sdl frontend?
20:53tarragon: gdb PPSSPPSDL <--- nothing happens.
20:55orbea: that sounds strange....it bring up an interactive gdb session even if you have no binary called PPSSPPSDL, It would tell you it doesn't exist then..
20:56tarragon: orbea: oh it does that
20:56tarragon: but no ppsspp nowhere to be seen
20:56orbea: what is your ppsspp binary called?
20:57imirkin_: orbea: i suspect he's just not running it.
20:57tarragon: PPSSPPSDL like that in upper caps
20:57orbea: yea, sounds like you're right
20:57tarragon: caps/upper case
20:57imirkin_: tarragon: r
20:57orbea: type that in the prompt ^
20:57orbea: should start ppsspp
20:58karolherbst: imirkin_: I am not quite sure if I will be able to do anything for nouveau the next few days.
20:58imirkin_: karolherbst: k
20:58karolherbst: next week should look better
21:01karolherbst: imirkin_: at least I got already internet working here,
21:01imirkin_: you moved?
21:01karolherbst: so maybe I do something on the weekend already
21:01karolherbst: imirkin_: .....
21:01karolherbst: had to
21:01karolherbst: well, it was my decision though
21:02imirkin_: where are you now?
21:02karolherbst: so "had to" is the wrong term, here
21:02karolherbst: imirkin_: brno
21:02imirkin_: oh right
21:02imirkin_: well, enjoy sunny czech republic :)
21:02karolherbst: well I enjoyed vienna today
21:03imirkin_: i suspect lots of german speakers in that area anyways
21:03karolherbst: you would be surprised, but my landlord can speak it
21:03karolherbst: which is good
21:04karolherbst: but the people who helped me find the apartment also help me translate anything related to my apartment as well, so it should be fine anyway
21:04imirkin_: i'm sure between english and german you should be covered
21:38pmoreau: Lyude: What kind of visual artifact, and while doing what? I could have a check on my Kepler cards.
21:39Lyude: pmoreau: it looks like something's blitting out of sync with the display
21:43imirkin_: Lyude: are you on X or wayland?
21:44Lyude: will give X a shot in a sec
21:50Lyude: imirkin_: yeah, looks to be wayland only. modesetting comes up just fine
21:51imirkin_: wonder if it's some interaction between a core drm change and nouveau
21:58pmoreau: Ah, I don’t think I have ever tried Wayland on Linux yet.
22:11imirkin_: what platforms have you tried it on?
22:17pmoreau: Nor on any other platform, TBH ;-D
22:22skeggsb: Lyude: https://paste.fedoraproject.org/paste/G-WX42OHxxj-yRaa7q8n0A
22:23Lyude: that was fast
22:23Lyude: skeggsb: will try
22:24skeggsb: cool, thanks :)
22:25imirkin_: old state is different from new state? who knew.
22:25skeggsb: it was a careless mistake
22:25skeggsb: but, understandable i guess
22:26skeggsb: it was a naive transform from older macros, which was fine.. but for some reason the swap_state() call was moved before it, which changes how that change needed to be done
22:27Lyude: skeggsb: Reviewed by: Lyude Paul <email@example.com> | Tested-by: Lyude Paul <firstname.lastname@example.org>
22:27skeggsb: either that, or i'm confused, and even though it seems to help, i've actually broken it in some other way ;)
22:28skeggsb: Lyude: awesome, i'll sneak it to dave in case we can somehow get it into 4.14 still
22:28Lyude: skeggsb: think this is going to be able to make it in time for 4.14
22:28Lyude: ah ok
22:28karolherbst: skeggsb: hi!