01:19edip: Hello. I was using win7 and Ubuntu 14.10 on Toshiba Satellite. last year, and my laptop randomly shuted down. It was about Nvidia Driver. I deleted it and I used Xorg video driver instead of it. And I cleaned the fan of laptop. It waorked. Now I upgraded Win7 to Windows 10 and I am using Windows 10 and Xubuntu 14.10. Now laptop randomly shuts down again. I think it is because of updated Nvidia or laptop's fan overheating or motherboar
01:20edip: I am looking for an opensource video driver for Nvidia for windows 10 like nouveau. Anyone can help? Thanks
01:21edip: Also I have a doupt about Grub 2.
01:22towo^work: oss nvidia driver for windows doesn't exist
01:22karolherbst: edip: well did you check the gpu temperature?
01:22edip: Yes, it was 55-60
01:22karolherbst: that isn't much
01:22edip: from sensors command
01:22karolherbst: much is more like 100°C or more
01:23karolherbst: your laptop shouldn't shutdown just because of such temperatures though
01:23edip: Yes I know. Last year It was 90 C but now there is not overheating problem
01:23karolherbst: even 90 shouldn't effect this, there is something different fishy
01:24edip: unsuitable Nvidia driver for windows may cause the problem?
01:24karolherbst: not directly
01:24karolherbst: a sudden shudown means your bios did it
01:24karolherbst: not the os usually
01:24karolherbst: maybe your EC is just totally messed up
01:25karolherbst: or your RAM is just broken
01:25edip: I also had shut-down problem with ubuntu 15.10 because of Nvidia. When I remove Nvidia and use nouveau, It works
01:26edip: Yes karolherbst you are right
01:26edip: So I should take my laptop to a repair service
01:26karolherbst: well but it totally depends on the system you are running
01:27karolherbst: well I don't trust those repair services except when they are under warrenty :D
01:27edip: I use an old bios. and grub2 works right now
01:27edip: I also do not trust them. I never took laptop to them
01:28karolherbst: well you would have to pay for it now anyway, because your laptop is not new :D
01:28karolherbst: edip: is the gpu 55-60°C warm while idling?
01:29edip: The last choice is to format claerly just for win10 and use ubuntu on virtualbox
01:29edip: no it depends, when I use 3D modelling software it is about 55-70, when normal usage temp is 45-55
01:30karolherbst: is this a dual gpu setup or only the nvidia gpu?
01:30edip: Xubuntu uses nouveau, Win10 uses Nvidia 340 with dual boot
01:31karolherbst: I meant if your laptop also has an intel gpu, but it sounds like it is nvidia only
01:31edip: When I use Xubuntu, It works good, But It sometimes shuts down when I mount Win10 ntfs
01:32karolherbst: what you could do though is to check your system logs after your laptop shuts down. It could be that the os detected some kind of emergency situation
01:32edip: Yes It has only Nvidia GPU, because I tryed to install Intel's driver, It did not work
01:32karolherbst: it could be a bug in the kernel then
01:33karolherbst: so if you don't mount the ntfs partition, it doesn't shut down?
01:33edip: I do not know to check system logs :/
01:33edip: Yes It dowsnt
01:33edip: It happens after I upgraded Windows 10
01:33karolherbst: yeah, then I guess your system has a problem with the ntfs partition
01:35karolherbst: you could check journalctl and check if you see something there
01:35edip: Also I saw a warning while I mount win10 from Xubuntu, As I remember It warned like "Win10 continues to work, you should completely shut down and start the system again. Ntfs is buggy"
01:36edip: Sorry, what is journalctl?
01:36karolherbst: a cli application to see system logs
01:36edip: I see
01:36edip: Ok I will research about it
01:36karolherbst: well you could just open a terminal and execute journalctl ;)
01:37edip: Sorry, now I am at work and does not have linux
01:37karolherbst: ahh k
01:37edip: I will try it later.
01:37edip: karolherbst Thank you very much!
01:37karolherbst: anyway, it sounds like a ntfs problem so you might want to report it there then
01:37edip: Ok. I will try to check it
02:00karolherbst: was it a think to change the pci link somehow in pre pcie times?
02:05mwk: karolherbst: AGP 1x/2x/4x/8x
02:05mwk: as for PCI itself, not really
02:05karolherbst: yeah well, I meant more like dynamically changing it
02:06mwk: IIRC you can dynamically change it
02:06karolherbst: because I am rethinking the speed change interface currently
02:06mwk: not sure if you'd want to do it though
02:06karolherbst: so instead of having a nvkm_pcie_set_link and pcie_* attributes in the pstate struct
02:06karolherbst: I would do something like nvkm_pci_set_link and have pci_* attributes
02:07karolherbst: so that it isn't pcie specific
02:07mwk: it *is* pcie specific
02:07mwk: AGP speeds are an unrelated thing
02:07mwk: so I'd say, if anything other comes around, make another interface
02:07karolherbst: yeah I know, it was just for the interface
02:08karolherbst: nvkm_pci_set_link would then check what type of card it is and forward to the specific implementation
02:08karolherbst: but if it's really only a pcie thing, then it doesn't make much sense
03:27karolherbst: k, so newest version of my pcie stuff here: https://github.com/karolherbst/nouveau/compare/master_4.3...pcie_speed plan is to merge it this weekend
03:50RSpliet: karolherbst: note that skeggsb does regular working hours for nouveau, so no feedback over the weekend
03:51karolherbst: RSpliet: I know
03:52karolherbst: he said he wants to merge it this weekend ;)
03:52karolherbst: well he said "by" but this means basically the same :D
05:59imirkin: Tom^: just try various games, make sure there's no rendering corruption
05:59imirkin: karolherbst: would be awesome if you could do the same, as your gpu has fewer registers than Tom^'s, thus totally different RA situation
06:00imirkin: karolherbst: this is with http://patchwork.freedesktop.org/patch/69589/
06:10karolherbst: that's the shadow warrior thingy right?
06:11imirkin: karolherbst: the patch is to fix shadow warrior, yes
06:11duelle: Hi imirkin, yesterday you told me that there might be someone who could have some ideas what might be wrong with my settings/logs from x11trace (regarding the issue with multiple screens using revPRIME and the error "Configure crtc 5 failed."). Do you know how I could find out when it would be possible to ask him?
06:11imirkin: karolherbst: however it futzes with RA, which i don't *quite* understand, so it needs lots o' testing to make sure it doesn't accidentally break stuff
06:12imirkin: duelle: you're looking for airlied most likely, who's in eastern australia, and has just had a baby. don't know how much he's around, but he's probably asleep right now.
06:16duelle: Thanks imirkin. It is not urgent, but I would be happy if I found a solution for this issue at some point in time. So I am quite flexible if I knew when he would have time and be willing to look into my issue.
06:16imirkin: duelle: you might also ask in #intel-gfx, perhaps there's someone more knowledgeable about X there (specifically look for ickle)
06:16karolherbst: imirkin: I played some wine games today and didn't notice anything yet, may try other stuff
06:17imirkin: karolherbst: with the patch in question?
06:27duelle: Thanks again for your help/hints imirkin!
06:32imirkin: well that's positive... the ra fix has no effect on anything in shader-db...
06:58karolherbst: mhh I tried to run my gpu with the blob pgraph firmware, but I get this error: "Direct firmware load for nvidia/gk106/fecs_inst.bin failed with error -2" I thought I was installing the firmware the right way, but it seems like I miss something?
07:00imirkin: karolherbst: it all got renamed
07:00karolherbst: ahhh k
07:01imirkin: i can never remember which is which....
07:01karolherbst: well git might help then
07:01imirkin: but basically *d -> _data.bin, *c -> _code.bi
07:01imirkin: but which of 409 and 41a are fecs and gpccs... no clue
07:02karolherbst: imirkin: https://github.com/karolherbst/nouveau/commit/44fe057064d53f8053bc167f48a8bdae5ff72aaf?diff=unified
07:02imirkin: 409 = fecs, 41a = gpccs
07:05karolherbst: what does the gr firmware effect by the way?
07:07RSpliet: gpccs is probably the context switching code for the gpc
07:08RSpliet: eg. store and restore state-related registers
07:08imirkin: karolherbst: context switching between multiple... contexts
07:08imirkin: one context per open file handle
07:08karolherbst: ahh k
07:09imirkin: a ton of stuff is only directly accessible from that special falcon... it dumps a bunch of data, loads a bunch more
07:10RSpliet: imirkin: FE == FIFO Engine?
07:10imirkin: or frontend. dunno.
07:20karolherbst: mhh I was thinking, maybe it would help those pmu communication errors if I would be able to see if I could simply use the blobs pmu firmware :/
07:22imirkin: blob's pmu firmware isn't compatible with ours
07:22imirkin: our host interface is different
07:23karolherbst: yeah I thought so much
07:24Tom^: ok time to build with patch and play games for the entire evening!
07:25karolherbst: anyway, I wanted to look at the disassembled pmu code anyway
07:55imirkin: Tom^: preferably different games :)
07:55Tom^: hehe, yes.
07:55imirkin: although i'm less concerned about GK110... with 256 registers you almost never spill
07:56imirkin: i guess RA can still be wrong
08:07Tom^: does mesa or nouveau have any sort of pre rendering of frames like the blob where i can pre render 5 frames. ?
08:08imirkin: Tom^: "pre-render"?
08:09Tom^: yea like this http://superuser.com/questions/925474/what-does-nividias-pre-rendered-frames-mean
08:09Tom^: however im not quite sure if that is supported on linux blob hm.
08:10imirkin: no idea
08:10Tom^: or well this explains it more. http://www.tweakguides.com/NVFORCE_7.html
08:10imirkin: i think it's probably the swap depth?
08:19Tom^: to me it sounds more like it buffers the frame, and continues to render the next and shows it from that queue/buffer. creates a bit of input latency but can reduce stutter.
08:20imirkin: right. aka swap depth.
08:22Tom^: is there any controllable uh swap depth then, in mesa?
08:23imirkin: in the ddx i think
08:23imirkin: Option "SwapLimit" "integer"
08:23imirkin: double- vs triple-buffering
08:25Tom^: yea but isnt that only for vsync?
08:25imirkin: what's vsync? :)
08:25imirkin: (think about how it works)
08:27Tom^: yea but i sort of want trible buffering that isnt synced towards my hz/monitor =D
08:28karolherbst: then do tripple buffering but disable vsync :p
08:28Tom^: is that even gonna work?
08:28karolherbst: why not?
08:28imirkin: not sure.
08:28Tom^: i thought it would rather disable the buffering if vsync isnt on
08:28karolherbst: well buffering just means, you have some buffers where you save ready images
08:29karolherbst: which will get drawn when somebody decides it is the right time to draw them
08:29karolherbst: if all buffers are full, that basically means the graphic driver can't compute new outputs
08:30karolherbst: and has to wait until a buffer was readout for displaying
08:30karolherbst: vsync is just the synchronisation part with the display
08:30karolherbst: though without vsync it is very unlikely that the buffers get full anyway
08:31Tom^: thats the thing with this if im not mistaken, the buffers arent ever *full* and never stops the gpu.
08:32karolherbst: well you could just continue displaying stuff from the next buffer :/
08:32karolherbst: I don't think any driver does this though
08:32karolherbst: or just copy to the display
08:33RSpliet: Tom^: what's the point of a buffer depth larger than 1 without sync-to-vblank?
08:34RSpliet: your display is not going to deliver at a rate higher than it's refresh rate, so if you have a buffer of 5 frames, I guess the effect you'd get is that if all 5 are finished, you'd discard the first four and display the last?
08:34Tom^: so instead of showing frame per frame, you show frames from the queue, which means if the 5fth frame in the queue takes a slight longer to render its "fps drop" gets huh hidden.
08:34Tom^: hence the experience gets smoother
08:34Tom^: at the cost of a bit latency
08:35RSpliet: Tom^: that works when you sync to vblank, if you don't... the whole mechanism is pointless
08:36Tom^: well the problem with vsync is that games suck and if the games at some point cant keep up at those 60fps it has to drop to (iirc 30fps) to keep the vsyncing up.
08:36Tom^: this sort of never does that :P
08:36karolherbst: I really don't think halfing fps is a thing anymore
08:36Tom^: with triple buffering it isnt
08:36RSpliet: no, when the queue is empty (eg. a frame isn't ready), it continues to show the old frame until the new one is ready
08:37karolherbst: I think some stupid AAA engines still implement this really wrong
08:37Tom^: well yea, games suck.
08:38karolherbst: like in saints row IV. it has some kind of "increasing perf" mode where each next frame takes less time to be displayed or rendered or something
08:38karolherbst: something of that kind
08:44karolherbst: by the way, vsync seems to be somehow a bit broken with prime. Rarely I still see tearing :/
10:51karolherbst: sometimes I am not sure if some persons are trolling or that I just missed something important :/
10:52imirkin: no, they're trolling
10:56karolherbst: could be a regression though
10:56karolherbst: or something else
11:00KSteffensen: hi all
11:00KSteffensen: Im getting lots of warn on spam in my kernel log.
11:00KSteffensen: Is that something thats useful to anybody or should I just ignore?
11:01karolherbst: KSteffensen: totally depends
11:01imirkin: KSteffensen: do you have a pre-nv50 gpu?
11:01imirkin: KSteffensen: and are you using 4.3?
11:02KSteffensen: Its a NV110 (GTX 970) and Im using 4.3 kernel
11:02imirkin: KSteffensen: ah, you should be able to get modesetting just fine with that. please pastebin your dmesg
11:05imirkin: KSteffensen: btw, note that there's no acceleration for GM20x gpu's
11:06imirkin: but that shouldn't cause any dmesg spam
11:07KSteffensen: there ya go
11:08imirkin: well that's not great
11:09imirkin: skeggsb: looks like assert_drm_connector_list_read_locked is triggering?
11:11imirkin: KSteffensen: does this only happen when you plug/unplug a screen (or DPMS event)?
11:12KSteffensen: imirkin: DPMS? Dynamic Power something something?
11:12imirkin: KSteffensen: monitors turning on/off :)
11:13KSteffensen: imirkin: Seems related to Xorg turning off my screens due to inactivity
11:13imirkin: skeggsb: i guess you need to acquire a lock in nouveau_connector_hotplug?
11:13imirkin: KSteffensen: ok that makes sense
11:13imirkin: KSteffensen: would you be so kind as to open a bug on bugs.freedesktop.org, xorg -> Driver/nouveau
11:13imirkin: KSteffensen: and include the dmesg that you pastebinned
11:15KSteffensen: imirkin: sure I can do that
11:16imirkin: not sure why lots of other people aren't seeing this... i guess you only get those warnings if you have lockdep?
11:18KSteffensen: imirkin: lockdep?
11:19imirkin: CONFIG_LOCKDEP iirc
11:19KSteffensen: standard Arch Linux kernel, let me check
11:20KSteffensen: CONFIG_LOCKDEP_SUPPORT=y, so yeah
12:13kugel: I'm not getting this on 4.3 with karolherbst's reclock branch
12:13kugel: imirkin: ^
12:14imirkin: what is the "this" that you're not getting, and which of karol's 100 branches are you talking about?
12:14kugel: the dmesg spam
12:14kugel: and kepler_stable_reclocking
12:15kugel: I'm also on the standard Arch linux kernel
12:15imirkin: oh, in reference to KSteffensen's issue
12:16kugel: yea, nothing happened in irc in the meantime so I thought it was obvious, sorry
12:16imirkin: i'm just slow.
12:17kugel: chances are that I didn't look right but I can't remember such warnings, and my screen also regularly turns off on inactivity
12:18kugel: but then again, I'm on standard Archlinux with nouveau.ko swapped for the self compiled one
12:31karolherbst: I didn't mess with that kind of code though :D
12:33karolherbst: imirkin: it feels like I got a perf regression somehow :/
12:33karolherbst: don't think it is related to your patch, everything just feels slower
12:33imirkin: karolherbst: too much coffee?
12:39karolherbst: imirkin: I think I will bisect mesa then :/
12:39karolherbst: should be something around 10% or less
12:40karolherbst: I just saw that I get lower fps in heaven than usual
13:12airlied: skeggsb: is there a -next?
13:12imirkin:doesn't see one
14:37skeggsb: airlied: i'll send you something by the weekend, there's at least one more patch series i'd like to merge, which i can hopefully do today
14:37skeggsb: karolherbst: ^^^
14:42karolherbst: yeah I think I fixed your stuff
14:43skeggsb: i did just notice the updated commits, i'll look over them in a moment
14:46imirkin: skeggsb: there's a WARN_ON from some sort of work function where we apparently forget to lock something
14:46imirkin: skeggsb: https://bugs.freedesktop.org/show_bug.cgi?id=93634
14:47imirkin: on a GM20x if it makes a difference (don't think it does...)
14:48airlied: skeggsb: is there likely any arm related fail this time? :-P
15:02imirkin: skeggsb: it's odd that no one else reported that... seems like the sort of thing that should trigger 100% of the time
15:03skeggsb: well, it's a path that's only hit when you plug/unplug a screen
15:03skeggsb: it's in my dmesg right now in fact :)
15:03imirkin: ah lol
15:03skeggsb: i'd never noticed before
15:04imirkin: skeggsb: cc: stable too? i guess it's in 4.3
15:05skeggsb: i somewhat suspect the warning might be new in 4.4, but i should double-check that
15:05skeggsb: i haven't even confirmed the fix myself yet, don't want to reboot the machine i'm using just yet
15:06imirkin: skeggsb: [ 0.000000] Linux version 4.3.3-2-ARCH (builduser@tobias) (gcc version 5.3.0 (GCC) ) #1 SMP PREEMPT Wed Dec 23 20:09:18 CET 2015
15:06skeggsb: righto then
16:08karolherbst: did anybody here ever used envydis to disassemble the blob falcon code?
16:08mwk: I might've looked at it a tiny bit...
16:11karolherbst: I have the issue that I don't get any output
16:12mwk: output of what? and which falcon?
16:13karolherbst: for example the video stuff
16:13karolherbst: "envydis nve6_fuc084 -m fuc" is what I call
16:13karolherbst: also the pgrapgh firmware files didn't work
16:13skeggsb: use -i if it's a binary
16:14karolherbst: I guess unknown opcodes are pretty normal?
16:14karolherbst: or do I have to specify that it is fuc3 code
16:14skeggsb: might need -VfucX
16:14mwk: you should add -V
16:14skeggsb: where X is whatever
16:14skeggsb: *version the falcon uses
16:14karolherbst: much better now
16:14karolherbst: thanks a lot :)
16:14mwk: anyhow, what are you up to?
16:15karolherbst: debuggin the pmu issues
16:15mwk: ah, pmu.
16:15karolherbst: I want to know what the blob does on the pmu
16:15karolherbst: for the counters and reclocking stuff
16:15mwk: is that your first time messing with blob's pmu?
16:15karolherbst: I didn't even read it out yet
16:15karolherbst: ohhh wait
16:16karolherbst: there is an unknown opcode
16:16mwk: well, you're in for quite some fun.
16:16karolherbst: f5 3c
16:16karolherbst: and two args
16:16mwk: that's not an unknown opcode
16:16mwk: throw in -F crypt
16:16mwk: ... or what was the syntax
16:16mwk: yeah, -F crypt
16:17karolherbst: still something unknown
16:17karolherbst: "f5 3c f3 a9 ??? [unknown: 00 00 f3 a9] [unknown instruction]"
16:17karolherbst: there is more though
16:17mwk: I don't know that one.
16:17mwk: it's a crypto op
16:17mwk: there are a handful of unknowns there
16:18mwk: as you can imagine, it's not exactly easy to run these to test them...
16:18mwk: anything involving f5 3c is a crypto opcode
16:18karolherbst: but the other stuff could be somehow REed?
16:19karolherbst: like I push values in it and push the result into the scratch and somehow try to figure out what it does?
16:19mwk: for falcon3? there are no unknowns left
16:19mwk: other than crypto
16:19karolherbst: so did you check my paste?
16:20mwk: well... have you ever decompiled stuff before?
16:20karolherbst: or could it be that envydis doesn't support them all yet
16:20mwk: then you should know that telling apart data from code is one of the hard problems...
16:21karolherbst: ohh right
16:21mwk: the remaining unknowns are data areas
16:21karolherbst: what about stuff like "b9 45 c0 not b32 $r5 $r4 [unknown: 00 00 c0]" ?
16:22mwk: still data
16:22mwk: the falcon page size is 0x100 bytes
16:22mwk: notice how all the unknowns are clustered in such blocks
16:23mwk: these are the data pages
16:23mwk: occasionally you may also find some unknown ops on page bounduary
16:23karolherbst: ohh okay
16:23mwk: this is when there's a page break in the code, the the previous page is filled with 0s
16:24karolherbst: the pmu code is uploaded 0x10a184 ?
16:24mwk: which causes the beginning of the next page to be misaligned
16:24mwk: no, not really
16:24mwk: a bit of it is
16:24mwk: but mostly it loads itself from memory
16:24karolherbst: ohhhh okay
16:25karolherbst: I thought I could just find the pmu code inside my trace somewhere
16:25mwk: extracting the PMU code is quite damn hard
16:25karolherbst: so extracting from binary files?
16:25mwk: I do have a full set, but it's from an old driver version
16:26mwk: IIRC nobody quite knows how to find the binaries in current blob
16:26mwk: they're compressed and maybe encrypted
16:26karolherbst: k, how old is old?
16:26mwk: has Kepler, no Maxwell
16:26karolherbst: I am fine with kepler stuff
16:26karolherbst: I just want to check the pmu code for my nve6 in fact
16:27karolherbst: and investigate why nouveau looses IRQs (or wherever they get lost)
16:27karolherbst: and why requesting stuff from different processes alternately messes up the host-kern communication for real
16:27skeggsb: i suspect you won't find the solution to that by looking at nvidia's ucode
16:27skeggsb: ours is *nothing* like theirs
16:27karolherbst: which needs ot be stable when we want to have a working dynamic reclocking stuff on the pmu
16:28mwk: besides, it's scary
16:28karolherbst: well at least I might find the counters stuff
16:28skeggsb: ours also hasn't been debugged that much, it was quickly hacked up to allow work on memory clock changes, and like all that code, is *not* ready to be used generally
16:28karolherbst: if I have only the perf stuff, this would be all I need basically
16:28karolherbst: the communication stuff would be just nice to have
16:29karolherbst: skeggsb: well I assume you saw my pdaemon_counters branch where I added this current_load debugfs file?
16:29karolherbst: anyway, the specifics doesn't matter, just the the debufs file reads out some stuff from the perf pmu process
16:29skeggsb: you can see basically what nvidia implement for perf by looking at the interface headers that the android gk20a driver uses
16:30karolherbst: the pmu counters
16:30skeggsb: the hardware behind that, we already understand
16:30karolherbst: whenever I while true cat current_load
16:30karolherbst: and let this run like for 1M requests
16:30karolherbst: I loose like 25 IRQs where I can recover response in 100% of all cases
16:31karolherbst: same when I just reclock the pstate from 07 to 0f alternatly
16:31karolherbst: but when I mix those, like while true cat current_load && reclock
16:31skeggsb: i suspect there's a stupid race, more than a misunderstanding of the hw bits
16:31karolherbst: the fifo gets messed up for real
16:31karolherbst: and sometimes GET is 5 and POST is like 9
16:31mupuf: skeggsb: yep, I tried to find this race but failed. Does not mean that it is not here
16:31mupuf: I guess it is just an issue of coalescing of IRQs on the CPU side
16:32karolherbst: mupuf: well but this isn't the _real_ issue I meant
16:32karolherbst: mupuf: as long as you communicate with one process on the pmu, you can recover all responses and only the IRQ is lost, which is bad, but well we could handle that
16:32karolherbst: but if you access different processes alternatly (memx and perf) something really bad happens
16:33karolherbst: basically the fifo runs full
16:33karolherbst: and you won't be able to write new stuff in it
16:33karolherbst: but you also don't get the responses
16:34karolherbst: mupuf: also I don't see how IRQs could be coalesced, because there are only synchronus requests and nouveau always waits only for one response :/
16:34karolherbst: I mean the situation is, that an IRQ could just be lost
16:34karolherbst: this just happens
16:35karolherbst: mupuf: https://lwn.net/Articles/391973/
16:35karolherbst: ohh wait
16:35karolherbst: wrong article
16:35karolherbst: mupuf: https://lwn.net/Articles/392136/
16:35karolherbst: this one
16:37karolherbst: mupuf: and to be honest, 20 lost IRQs out of 1M isn't too bad
16:37mupuf: depends on how you handle them
16:37karolherbst: but the expected response from the pmu was there after the timeout
16:38mupuf: ok, time to go to sleep
16:38karolherbst: anyway, we should wait with a timeout on IRQs
16:38mupuf: have fun guys!
16:38karolherbst: :D thanks
16:57karolherbst: mwk: I know there is a script to extract the pgraph stuff out of the drivers. I assume you have something like that for the pmu stuff?
17:01karolherbst: imirkin: do you have any examples on which h.264 trailer show artefacts?
17:05imirkin: karolherbst: yeah, the simpsons trailer... sec
17:05imirkin: karolherbst: http://www.h264info.com/clips.html
17:05imirkin: the 720p version iirc
17:06karolherbst: does the artifacts appear the entire time?
17:08imirkin: play it, should be obvious
17:08imirkin: in the intro, as it's drawing the outline of homer's head (iirc), and when he's jumping over the ravvine with the dogs
17:08imirkin: and a few other spots
17:12karolherbst: yeah well
17:12karolherbst: I can't play it with the blob
17:13karolherbst: the video engine got stuck
17:13karolherbst: 100% load even after mplayer was killed
17:14karolherbst: ohhh wut
17:14karolherbst: imirkin: https://gist.github.com/karolherbst/585d5994717c69fe01d6
17:15imirkin: dunno, used to work :)
17:15karolherbst: maybe I did something terribly wrong
17:15imirkin: it's been known to happen
17:16karolherbst: now I have to reboot :/
17:23karolherbst: now I got a kernel panic :O
17:24karolherbst: lets try again
17:24imirkin: karolherbst: sounds like you're doing something unexpected
17:24karolherbst: well I shutdown my laptop
17:24karolherbst: booted it
17:25karolherbst: and then I simply did "optirun -b none bash" which basically turns on the gpu and starts X on it
17:25karolherbst: and then it paniced inside nvidia_rc_timer
17:32karolherbst: and now I get "Error creating VDPAU device: 1"
17:33karolherbst: you know what, I just check with nouveau :D
17:42imirkin: unfortunately vdpau + dri3 = fail
17:42karolherbst: so where should the artifacts be?
17:42imirkin: sec, let me pull it up...
17:43imirkin: ok, you can see a few artifacts at A: 15.8 V: 15.8 A-V: 0.000 ct: -0.012 0/ 0 0% 0% 0.9% 0 0
17:44imirkin: some much bigger ones at about 27s in
17:44imirkin: and a few others
17:45karolherbst: because I didn't see any
17:45imirkin: could be all fixed on kepler? don't think so though...
17:45imirkin: you're probably just using vdpau wrong
17:45karolherbst: maybe the one 4k issue was just the smae?
17:45imirkin: s.t. you're not actually using it for decoding
17:46imirkin: this is the 1280x544 version of the video, right?
17:47imirkin: md5sum: fb049672d80640561ee9f56708772247
17:47karolherbst: also load on the video engine
17:47karolherbst: the counters tell me
17:48karolherbst: high one though
17:48karolherbst: well "high"
17:48imirkin: you're doing mplayer -vo vdpau -vc ffh264vdpau ?
17:49karolherbst: the pmu counters tell me that there is load on the video engine, so I am sure it works
17:50karolherbst: ohhh wait
17:50karolherbst: now I saw some
17:50imirkin: if you're looking at individual frames you might miss it
17:51skeggsb: yeah, i definitely see them
17:51karolherbst: they are there for sure
17:56imirkin: what's especially interesting is that it happens on both VP2 and VP3
17:57imirkin: which leads me to believe it's not some stupid little thing in the data handling we're getting wrong
17:57imirkin: but some much larger thing... like a NAL type we're supposed to handle ourselves
17:57imirkin: or ... something
17:57imirkin: or something that we're getting equally wrong in VP2 and VP3. although all the data passing is different. but i probably did refer to the vp3 stuff a bit when i was doing vp2...
17:58imirkin: but e.g. all the reference frame handling is different, etc
17:59karolherbst: or some other buffer too small
17:59karolherbst: I also got some artifacts with the big videos
17:59karolherbst: if there weren't too big and nouveua could handle them mostly
17:59imirkin: well, this is a fairly low bitrate 720p video
18:00imirkin: i have super-high 1080p bitrate videos which play just fine
18:00karolherbst: I don't think this depends on the bitrate though
18:00imirkin: i've seen it on low motion scenes, i've seen it on high motion scenes
18:01imirkin: i didn't have demmt back then
18:01imirkin: with the current demmt one could build up a *much* better analysis engine
18:02imirkin: i did build the h264player which was a bit more trace-friendly
18:02imirkin: things like mplayer like to reorder frames and whatnot
18:02imirkin: makes for a lot of confusion
18:02imirkin: my h264player doesn't do any of that, and logs a ton of useful stuff on top of it
18:02imirkin: (in my re-vp2 repo)
22:44imirkin: Tom^: that patch i sent was totally bogus, stop testing it :)
22:44imirkin: Tom^: also looks like there is a CS:GO update -- perhaps they fixed the memory leaks