| *** tpb has joined #timvideos | 00:00 | |
| mithro | puck: I've updated the documentation a bit | 03:02 |
|---|---|---|
| mithro | CarlFK: regarding the "https://github.com/pbatard/fxload "Oh man, are people actually using that old code? This is no longer maintained and has been superseded by the fxload app in the libusbx directory." -- Turns out he removed functionality needed in the latest versions | 03:02 |
| tpb | Title: pbatard/fxload ยท GitHub (at github.com) | 03:02 |
| puck | mithro: ta, I need to head off now, tomorrow is a holiday, I'll be back at it on Friday | 03:22 |
| mithro | thaytan: just fyi | 04:02 |
| mithro | https://www.irccloud.com/pastebin/xFdDo8E3 | 04:03 |
| tpb | Title: Pastebin: xFdDo8E3 | IRCCloud (at www.irccloud.com) | 04:03 |
| thaytan | mithro, seems a bit off, eh? | 04:07 |
| mithro | Well, it's of the order of 50-40 microseconds | 04:08 |
| mithro | (at worse) | 04:09 |
| mithro | I'm trying to remember my signal processing to see if there is something that could give me a better understanding of the jitter | 04:12 |
| thaytan | I really suspect it'll just be timing error taking the measurement | 04:16 |
| thaytan | although it's interesting that the average is about 10 uS shy | 04:17 |
| thaytan | I wonder why / how it reports that 16661 value | 04:17 |
| mithro | thaytan: a theory is that is how long it takes to service the interrupt | 04:18 |
| thaytan | right, but somehow it still reports a different value for the internal framerate estimate | 04:18 |
| mithro | what do you mean? | 04:22 |
| thaytan | mithro, that it reports 16661uS for the internal measure of the framerate | 04:29 |
| thaytan | but the average from measuring it yourself is 16651 | 04:29 |
| thaytan | 10 uS shorter | 04:30 |
| thaytan | so how is libGL measuring it? | 04:30 |
| mithro | thaytan: I assume it is just passing up what the monitor is saying it does | 04:30 |
| thaytan | it can't get it direct from the monitor - it's measured against the system clock on the PC | 04:30 |
| thaytan | right? | 04:30 |
| thaytan | would have to drill into libGL to find out | 04:31 |
| thaytan | or ask keithp or anholt | 04:31 |
| mithro | yeah, I just joined #intel-gfx to see if someone there could help | 04:34 |
| mithro | thaytan: you assume it is doing the right thing :P | 04:34 |
| *** mproctor has quit IRC | 04:39 | |
| mithro | thaytan: it probably just reads the edid information and reports that :P | 04:40 |
| thaytan | mithro, it is at least internally consistent - 4700000/78309 == 60.018644Hz == 1661.4893 uS per frame | 04:40 |
| thaytan | mithro, that doesn't make sense to me | 04:41 |
| thaytan | if the monitor knew it wasn't doing exactly 60fps... it'd be able to adjust slightly so it was | 04:41 |
| mithro | my code could be wrong :P | 04:42 |
| mithro | https://www.irccloud.com/pastebin/Pp0x1M56 | 04:42 |
| thaytan | that I believe ;) | 04:42 |
| tpb | Title: Pastebin: Pp0x1M56 | IRCCloud (at www.irccloud.com) | 04:42 |
| thaytan | damnit, don't make me go read Mesa code :-P | 04:43 |
| thaytan | it is reporting based on the system dot clock taken from XF86VidModeGetModeLine | 04:47 |
| mithro | thaytan: I'm chatting with keithp now | 05:02 |
| thaytan | oh good | 05:03 |
| thaytan | it makes sense to me a bit more now | 05:03 |
| thaytan | after learning GetMscRateOML comes from the dotclock | 05:04 |
| mithro | what is "the dotclock" ? | 05:06 |
| thaytan | it's the crystal on the graphics chip that clocks out the pixels | 05:06 |
| thaytan | it gets set to the closest supported value to output the requested video mode | 05:07 |
| thaytan | which can't always hit the ideal value for a given framerate | 05:07 |
| CarlFK | mithro: pretty sure the functionality is there, just under a different option. like -d vs -D (we have had this discussion before.. maybe I should open an issue? | 07:50 |
| mithro | CarlFK: I'm pretty sure it was missing | 07:53 |
| CarlFK | whats the functionality? | 07:53 |
| mithro | The udev script needs the ability to specify a USB device in /sys for when you have two devices with the same vid:pid (IE you plug in two devices) | 07:54 |
| mithro | It may have been added since I last looked. | 07:56 |
| CarlFK | $ djtgcfg prog -d Atlys -i 0 -f hdmi2usb.bit | 07:56 |
| CarlFK | pretty sure it is now -D | 07:56 |
| mithro | No | 07:56 |
| mithro | Fx load | 07:56 |
| CarlFK | but that may be a hex | 07:56 |
| mithro | Bblr | 07:56 |
| CarlFK | oh.. back to docs.. | 07:56 |
| CarlFK | see ya | 07:56 |
| *** CarlFK1 has joined #timvideos | 12:06 | |
| *** CarlFK has quit IRC | 12:06 | |
| *** CarlFK1 is now known as CarlFK | 12:07 | |
| *** CarlFK has quit IRC | 12:16 | |
| *** CarlFK has joined #timvideos | 12:18 | |
| *** mproctor has joined #timvideos | 21:22 | |
| mithro | CarlFK: heyo | 23:46 |
| CarlFK | mithro: perfect timing | 23:46 |
| CarlFK | I am on a box with 24 cores (not sure if they are real, or 12*2.. whatever, don't care, call it 24. | 23:47 |
| CarlFK | I need to kick of 22 instances of my encoder (webm isn't multi tread) | 23:48 |
| CarlFK | I think I did something like that with bash script and screen -d -m .. but couldn't figure it out a few days ago | 23:48 |
| CarlFK | any suggestions ? | 23:49 |
| mithro | python | 23:49 |
| mithro | :) | 23:49 |
| CarlFK | that did come to mind | 23:49 |
| mithro | subprocess and queue should work well | 23:50 |
| mithro | CarlFK: I could write you up something which just takes the command lines on stdin and reports when they finish on stdout | 23:51 |
| CarlFK | I think I want them running in a screen or tmux | 23:52 |
| CarlFK | I don't trust things will run well enough, and if it fails I want to be able to attach to the session to see what is going on | 23:53 |
| CarlFK | like I just bumped into a unicode problem that somehow eluded your fix | 23:54 |
Generated by irclog2html.py 2.12.1 by Marius Gedminas - find it at mg.pov.lt!