00:04 imirkin: AndrewR: yeah, indeed mpeg2 is way slow with VP2 on the G92
00:05 imirkin: i wonder if there's a lesson in that
00:05 imirkin: either way, xvmc decoding with PMPEG seems to work just fine on my G92
00:06 imirkin: [with subtitles too]
00:16 gnarface: hey imirkin, i suspect i already know the answer to this, but you don't happen to have any experimental fixes for h264 decoding on that card i can test yet, do you?
00:16 imirkin: gnarface: nope
00:16 gnarface: (i have actually time to do so now)
00:17 imirkin: "that card" being the G92 right?
00:17 gnarface: imirkin: yea... but it DOES do mpeg2 in hardware?
00:17 imirkin: [actually i have no experimental fixes at all, irrespective of the card]
00:17 imirkin: yes
00:17 gnarface: when you say just... "slow" ? slow as in high CPU load or long delay?
00:17 imirkin: you can use the VP engine or the VPE engine
00:17 gnarface: or both?
00:18 imirkin: slow as in it doesn't seem to be able to keep up with real-time decoding of a DVD
00:18 imirkin: which means clocks are messed up or something
00:18 gnarface: ah, so really badly slow
00:18 gnarface: what is PMPEG in this context?
00:18 imirkin: but the VPE-based stuff still works fine
00:18 imirkin: just run with NOUVEAU_PMPEG=1
00:18 imirkin: in the environment
00:18 imirkin: and that will flip over to that engine
00:18 gnarface: oh interesting. uh... as of which kernel?
00:19 gnarface: (i'm assuming 3.16 is too old)
00:19 imirkin: should be fine
00:19 gnarface: oh, really?
00:19 gnarface: hmm, might try that then
00:19 imirkin: iirc i fixed all this stuff up around 3.11 or so, but it probably worked on nv50+ even before that
00:20 gnarface:really wishes there was a way to make steam streaming use mpeg2
00:21 imirkin: sorry, just haven't had time to investigate
00:21 imirkin: esp as i suspect the issue has nothing to do with the video decoding engine itself
00:21 imirkin: but rather overall card clocking settings or something along those lines
00:21 gnarface: yea, i think you're right there
00:21 gnarface: something needs to happen to trigger the card to go into a different power state or something like that
00:22 imirkin: before i investigate that i'm probably going to try investigating the h264 decoding issue that happens on basically all hw
00:22 gnarface: or to make it disengage one part of the chips to engage another...
00:22 gnarface: there is a separate h264 issue on other hardware?
00:23 gnarface: i have another card to test but the test machine doesn't have the right power hookups for it :(
00:59 Horizon_Brave: hey everyone
01:16 Hoolootwo: I'm trying to get a kernel to work on my laptop, the stock debian ones don't work, failing on a nouveau issue
01:19 Hoolootwo: I'm not sure exactly what I'm seeing, since I'm IRCing on this laptop, but the weird thing is that I have another laptop (also 3100M) which just works with a newer gentoo kernel
01:21 gnarface: Hoolootwo: the debian kernel you're trying to use is 3.16?
01:22 gnarface: Hoolootwo: if you're on debian stable, maybe try the backport kernel
01:22 Hoolootwo: I'm on 4.9.18
01:22 gnarface: oh, nevermind then
01:23 gnarface: that is the backported kernel already
01:24 Hoolootwo: I'm on testing right now
01:24 imirkin: Hoolootwo: which GPU is this?
01:24 Hoolootwo: 01:00.0 VGA compatible controller: NVIDIA Corporation GT218M [NVS 3100M] (rev a2)
01:24 imirkin: hrmph
01:25 imirkin: so what's the issue?
01:25 imirkin: i.e. what specifically causes you to think something's not working?
01:25 Hoolootwo: well, when I reboot, the screen goes black except for a cursor in the top left, I don't know much more than that yet
01:26 Hoolootwo: just a sec, grabbing another box to IRC from
01:34 Hoolootwo: it's still u, I can ssh to it
01:34 Hoolootwo: s/u/up/
01:37 Hoolootwo: grabbing dmesg|grep nouveau right now, nothing else looks relevant
01:38 Hoolootwo: https://bpaste.net/show/01436d49289e
01:41 Hoolootwo: it's trying to boot 4.10.0, which isn't latest, but isn't a big step up either
01:42 gnarface: black screen with cursor present... cursor can move or not?
01:42 Hoolootwo: uh, the cursor isn't present anymore
01:42 Hoolootwo: I think it was trying to flash, not sure
01:43 Hoolootwo: but not moving
01:43 gnarface: might just be screen blanking though now, if it's been more than 306 seconds
01:43 gnarface: i wonder if compositing is on
01:49 Hoolootwo: ok there's something funky here, I just rebooted to the last version that worked and it didn't
01:51 Hoolootwo: I now have a white screen, except for a black bar :/
01:52 gnarface: ok that is weird for sure, and might be evidence of a physical problem with the display
01:53 gnarface: but i have noticed various multi-output nvidia cards behaving strangely in different ways with regards to power-on detection of which ports are "active" and/or "default" depending on which ones are connected and powered on
01:53 gnarface: i'm not saying that's the cause of your problem here, but not being aware of the possibility may make it much harder to debug the actual problem
01:53 Hoolootwo: the display worked ten minutes ago, with like 4 days of uptime
01:54 Hoolootwo: brb throwing a kernel which is known to work with this card at it
01:54 gnarface: i would try powering it up (from a completely "off" state) with the display plugged in and powered on, then compare the behavior to what happens if i plug in the display after boot-up is finished
01:55 Hoolootwo: it's a laptop, so that's the default way I've been powering it off
01:55 Hoolootwo: it just worked :/
01:55 gnarface: oh, nevermind, was assuming a desktop card
02:56 Hoolootwo: this kernel just worked, not sure why the 4.10 one didn't
02:56 Hoolootwo: (there were a couple issues with trying to build a kernel on gentoo that were fixed in a chroot)
03:00 gnarface: weird
03:00 Hoolootwo: I'll try with a less minimal config
03:00 gnarface: wait, you mean the gentoo kernel just worked on debian?
03:01 Hoolootwo: well, it's all linux
03:01 gnarface: yea, it does suggest a mere configuration difference
03:01 gnarface: but it's curious to me because i'm ... not having that problem on the 3.16 debian kernel
03:01 Hoolootwo: what are you seeing
03:02 gnarface: i mean, it just works for me
03:02 gnarface: at least, the desktop
03:02 gnarface: boot up
03:02 gnarface: etc
03:02 gnarface: multi-display support
03:02 gnarface: it's all working except hardware video decoding
03:03 Hoolootwo: it's probably some weird race condition with hardware initialization or something
03:03 Hoolootwo: and it could be specific to this card
03:03 gnarface: yea, the difference is probably with my hardware, but i'm still curious to know what configuration changes may have caused yours not to work
03:03 Hoolootwo: the default gentoo kernel has basically everything off by default
03:03 Hoolootwo: but the default debian one has basically everything on
03:04 gnarface: yea, the stock debian kernels are pretty good these days. this is a disturbing revelation
03:04 Hoolootwo: I'm thinking it might have something to do with that, but I'm not sure
03:04 Hoolootwo: they're also really big
03:04 gnarface: well the debian one also has some non-vanilla patches
03:05 gnarface: gentoo doesn't do that, right?
03:05 gnarface: usually just backported bug and security fixes, but it's not completely unheard-of for them to cause problems (been a long time for me since one has though)
03:06 gnarface: hmmmm
03:06 gnarface: i wonder if you could be having the wrong driver load
03:06 Hoolootwo: I'm pretty sure gentoo gives you upstream sources
03:06 Hoolootwo: no, I don't think so, nouveau is loading and throwing a bunch of errors
03:06 gnarface: oh
03:07 gnarface: i'm stumped
03:07 Hoolootwo: https://bpaste.net/show/01436d49289e
03:07 gnarface: worst pastebin ever, btw
03:07 Hoolootwo: I'm going to try the same build process with the newest upstream kernel, with both the debian .config and the gentoo .config and see what happens
03:08 Hoolootwo: no, pastebin is the worst pastebin
03:08 gnarface: well pastebin does have ads
03:08 gnarface: i'll concede that
03:08 Hoolootwo: what's a better one?
03:08 gnarface: i like paste.debian.net
03:08 gnarface: doesn't have this problem with showing long lines
03:08 Hoolootwo: I'll use that next time then
03:09 gnarface: this is weird
03:10 gnarface: i almost wonder if the xorg version is just incompatible with that nouveau version
03:10 gnarface: no idea though
03:11 gnarface: dinner time for me, but i'd still like to hear what it turns out to be if you figure it out
03:12 Hoolootwo: sure, I'll keep you posted
03:19 Hoolootwo: dammit, that didn't work
03:20 Hoolootwo: (newest linux upstream + working gentoo .config)
03:22 Hoolootwo: hmm, looks like it doesn't happen every time
03:22 Hoolootwo: as long as it doesn't get worse, it's a thing I can work with, but I'd really prefer not to
03:24 Hoolootwo: also worth noting is that a near-identical machine is loading a kernel in the same way, and seems to work every time
03:25 Hoolootwo: (near-identical meaning same CPU generation + graphics card)
05:21 Hoolootwo: welp and that's an oops
05:22 Hoolootwo: yeah, the minimal kernel is working, but not the one with a debian config
05:23 Hoolootwo: I'm not sure if it has to do with size, but this feels like some sort of race condition
14:12 RSpliet: pmoreau: do you happen to know whether OpenCL C is supposed to allow the comma operator in for-loops
14:12 RSpliet: Its reference to C99 seems to imply it should, but NVIDIA does not like what I'm doing
14:13 RSpliet: oh actually NVIDIA does allow it, but not in the corner case where I say
14:14 imirkin_: stealing skeggsb's style?
14:14 RSpliet: i = 1, unsigned int j = 120; (eg. a declaration after a definition)
14:15 imirkin_: hehe
14:15 imirkin_: yeah, i could see it getting mad
14:16 imirkin_: dunno if that's legal tbh
14:16 RSpliet: I guess it gets a bit... ambiguous
14:16 RSpliet: but I don't see other ways of having an initial definition of a variable scoped to only the loop - other than more curly brackets
14:17 RSpliet: not sure if the compiler needs my help with this, but... meh
14:22 karolherbst_: RSpliet: please don't do stuff like this
14:22 karolherbst_: it hurts my eyes more than it should :p
14:23 RSpliet: karolherbst_: whether I should do it or not is not my question. I'm just wondering whether the compiler *should* accept it or not
14:24 RSpliet: I have the right to screw up!
14:24 karolherbst_: I am sure it gets confused, cause i is declared outside the loop?
14:24 karolherbst_: what happens if both are declared inside the loop ehader?
14:25 RSpliet: I *guess* the notation unsigned int j = 120, i = 1 will have exactly that effect
14:25 karolherbst_: and what does "unsigned int j = 120, i =1" do?
14:25 karolherbst: welll
14:25 karolherbst: is i what i was before or is i an unsigned int now?
14:26 RSpliet: Anyway, no idea why I ask pmoreau, he doesn't touch parsing/lexing :-)
14:26 karolherbst: at that point I would already try to crash the compiler :D
14:27 karolherbst: on a side note: just found my second compiler bug in javac.... it's fun to crash compilers
15:22 RSpliet: GK104: 00000150: 00212186 14000000 (not $p0) ld b32 $r4 c0[$r2] [unknown: 00000100 00000000]
15:23 RSpliet: that unknown bit is set for every load from c0...
15:26 RSpliet: not for movs, whether predicated or not
15:35 imirkin_: RSpliet: how does it change with nvdisasm?
15:36 imirkin_: echo 00212186 14000000 | perl -ane 'foreach (@F) { print pack "I", hex($_) }' > tt; nvdisasm -b SM30 tt
15:36 imirkin_: echo 00212086 14000000 | perl -ane 'foreach (@F) { print pack "I", hex($_) }' > tt; nvdisasm -b SM30 tt
15:36 imirkin_: how are those different, if at all?
15:40 dboyan: imirkin_: @!P0 LDC.IL R4, c[0x0][R2];
15:40 dboyan: The .IL
15:41 imirkin_: oh goodie.
15:41 imirkin_: if only i knew what that meant.
15:41 imirkin_: so iirc there's a .IS flag which lets you load across constbufs
15:42 dboyan: cryptic flag names, aren't they?
15:42 imirkin_: indeed they are.
15:49 RSpliet: imirkin: there's .IL, .IS and .ISL (0x1, 0x2, 0x3)
15:51 imirkin_: yea
15:51 imirkin_: so S is for cross-constbuf indirection
15:51 imirkin_: no clue what L is
15:51 RSpliet: well, it appears to contrast Load to Store
15:52 imirkin_: LDC = load constbuf
15:52 RSpliet: Indirect Load, Indirect Store? (indirection on source vs. dest)?
15:52 imirkin_: there's no store.
15:53 imirkin_: it's a load.
15:53 RSpliet: so dest is always a reg?
15:54 dboyan: Ah, there is subops for load in codegen, IL IS and ISL. But they are never used
15:54 imirkin_: RSpliet: you can't store to a const buf :)
15:54 imirkin_: dboyan: IS is used.
15:55 imirkin_: RSpliet: otherwise it might lose some of its const-ness
15:55 RSpliet: all of it presumably :-)
22:22 Lyude: finally. imirkin_, have a working post_depth_coverage test and turning the extension on/off actually changes the test outcome :)
22:23 Lyude: let's just say I ended up teaching myself a good bit about using opengl, enough so I finally realized I was doing some very silly things (apparently I had the right idea before though with how to implement the test...) with the fbo and some other stuff
22:25 imirkin_: does i965/skl pass?
22:26 Lyude: nvidia's blob does , haven't tested with i965 yet because I didn't want to risk the chance that the extension has been broken on i965 since the test never actually worked before...
22:26 Lyude: will check in a bit though
22:26 imirkin_: well, the test tested that enabling post_depth_coverage didn't *break* things