[Ffmpeg-devel-irc] ffmpeg-devel.log.20120916

[burek]

[01:28] <Compn> Daemon404 : see, you could have said it was msvc only :P
[01:28] <Compn> i thought it was all windows (mingw/cygwin) :P
[01:28] <Compn> re: breaking win2k 
[01:29] <Daemon404> lul
[01:37] <Daemon404> nevcairiel, did you get anywhere?
[01:40] Action: Compn puts a windows2000 sticker on Daemon404 when hes not looking
[01:41] Action: Daemon404 hisses
[01:51] <CIA-54> ffmpeg: 03Derek Buitenhuis 07master * r31fbdecce8 10ffmpeg/configure: 
[01:51] <CIA-54> ffmpeg: msvc: Disable stripping
[01:51] <CIA-54> ffmpeg: MSVC-built binaries should not be stripped.
[01:51] <CIA-54> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[01:51] <CIA-54> ffmpeg: 03Ronald S. Bultje 07master * r663c21d4ac 10ffmpeg/compat/msvcrt/snprintf.c: 
[01:51] <CIA-54> ffmpeg: compat/vsnprintf: return number of bytes required on truncation.
[01:51] <CIA-54> ffmpeg: This conforms to C99, but requires Windows >= XP.
[01:51] <CIA-54> ffmpeg: 03Derek Buitenhuis 07master * re1b4496040 10ffmpeg/ (cmdutils.c compat/msvcrt/snprintf.c compat/va_copy.h): 
[01:51] <CIA-54> ffmpeg: msvc: Add a va_copy compatability macro for msvc
[01:51] <CIA-54> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[01:51] <CIA-54> ffmpeg: 03Hendrik Leppkes 07master * re3a1eb9edf 10ffmpeg/libavfilter/af_pan.c: (log message trimmed)
[01:51] <CIA-54> ffmpeg: af_pan: Fix sscanf formats to work with buggy sscanf implementations
[01:51] <CIA-54> ffmpeg: Some implementations of sscanf do not handle a space before a trailing %n
[01:51] <CIA-54> ffmpeg: properly.
[01:51] <CIA-54> ffmpeg: As an example, MSVC's does this for the second insatnce in this patch, for
[01:51] <CIA-54> ffmpeg: an input of "0x3:c0=c1:c1=c0":
[01:51] <CIA-54> ffmpeg:  1) Match the final "c0" or "c1".
[01:51] <CIA-54> ffmpeg: 03Derek Buitenhuis 07master * rd512e74dec 10ffmpeg/libavutil/bprint.c: 
[01:51] <CIA-54> ffmpeg: bprint: Remove custom vsnprintf
[01:51] <CIA-54> ffmpeg: A proper implementation was introduced in
[02:14] <ubitux> Daemon404: since you selected the va_copy.h include, why not protect it?
[02:15] <ubitux> the !defined(va_copy) should prevent any harm though
[02:21] <Daemon404> yes
[02:22] <Daemon404> anything else is redundant
[02:23] <ohsix> yes but i like my redundant in blue rather than yellow
[02:23] <Daemon404> :P
[02:23] <ubitux> :)
[02:48] <ubitux> Daemon404: i'm purging some external symbols that should be static
[02:48] <ubitux> i'll send a patchset in a while
[02:48] <ubitux> that might help you
[02:48] <Daemon404> i dont think it is s symbol clash.
[02:48] <Daemon404> makes no sense
[02:48] <ubitux> doesn't hurt anyway
[03:06] <ubitux> https://github.com/madler/zlib/blob/master/zlib2ansi heeeh~
[03:15] <Daemon404> dat regex
[03:21] <ubitux> i wonder if the zlib guy ever considered adding some prefixes to the API
[03:21] <ohsix> it wouldn't be zlib then :D
[03:29] <Daemon404> AHHHHHHHHHHHHHHHHHHH I AM DUMB
[03:29] <Daemon404> i had been linkeding to the asm'd zlib
[03:29] <Daemon404> it doesnt happen with c-ased zlib
[03:29] <Daemon404> :<
[03:33] <Daemon404> thatll teach me to use things from contrib
[03:33] <ubitux> how come the issue didn't show up with libav?
[03:33] <Daemon404> i dont know.
[03:34] <Daemon404> i did use a c-based zlib for libav originally
[03:34] <Daemon404> but nev used asm for libav too
[03:34] <Daemon404> so.. i dunno
[03:36] <Daemon404> https://github.com/madler/zlib/commits/master/contrib/masmx86
[03:37] <Daemon404> useful history is useful
[03:40] <ubitux> :D
[03:52] <Daemon404> http://mail.madler.net/pipermail/zlib-devel_madler.net/2011-June/002572.html
[03:52] <Daemon404> >abusing ebp
[03:52] <Daemon404> hints i should not be using that asm
[04:02] <Daemon404> fate passes \o/
[04:04] <Daemon404> (with git master)
[04:31] <ubitux> :)
[04:37] <CIA-54> ffmpeg: 03Clément BSsch 07master * r74434d3bfe 10ffmpeg/libavfilter/vf_ass.c: lavfi/ass: mark ass_libavfilter_log_level_map as static const.
[04:37] <CIA-54> ffmpeg: 03Clément BSsch 07master * rd214e5cfb4 10ffmpeg/libavcodec/ (ass_split.c ass_split.h srtenc.c): lavc/ass_split: add ff_ prefix to ass_style_get().
[04:37] <CIA-54> ffmpeg: 03Clément BSsch 07master * rca81e3b6e7 10ffmpeg/libavformat/ (matroska.c matroska.h matroskadec.c matroskaenc.c): lavf/mkv: prefix video stereo arrays with ff_.
[04:37] <CIA-54> ffmpeg: 03Clément BSsch 07master * r8b05220727 10ffmpeg/libavutil/error.c: lavu/error: make error_entries static const.
[08:56] <nevcairiel> Daemon404: now the question remains why the hell does it work for libav?
[14:29] <CIA-54> ffmpeg: 03Mans Rullgard 07master * rcb6632809d 10ffmpeg/libavcodec/ (avcodec.h avpacket.c): 
[14:29] <CIA-54> ffmpeg: libavcodec: remove av_destruct_packet_nofree()
[14:29] <CIA-54> ffmpeg: This function was deprecated two major versions ago (2009).
[14:29] <CIA-54> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:29] <CIA-54> ffmpeg: 03Anton Khirnov 07master * r990450c5bf 10ffmpeg/cmdutils.c: 
[14:29] <CIA-54> ffmpeg: cmdutils: avoid setting data pointers to invalid values in alloc_buffer()
[14:29] <CIA-54> ffmpeg: Fixes bug 352.
[14:29] <CIA-54> ffmpeg: 03Stefano Sabatini 07master * r5d1203f063 10ffmpeg/libavformat/ (avio.h aviobuf.c img2enc.c version.h): 
[14:29] <CIA-54> ffmpeg: avio: flush the internal buffer in avio_close()
[14:29] <CIA-54> ffmpeg: This is consistent with stdio, and thus what people would naturally
[14:29] <CIA-54> ffmpeg: expect.
[14:29] <CIA-54> ffmpeg: 03Anton Khirnov 07master * r0c270239c2 10ffmpeg/libavformat/utils.c: lavf: cosmetics, reformat av_write_trailer().
[14:29] <CIA-54> ffmpeg: 03Anton Khirnov 07master * r3b4bb19e63 10ffmpeg/ (19 files in 2 dirs): 
[14:29] <CIA-54> ffmpeg: lavf: flush the output AVIOContext in av_write_trailer().
[14:29] <CIA-54> ffmpeg: This is consistent with stdio and is what we want to do in all cases.
[14:29] <CIA-54> ffmpeg: Fixes a bug in the voc muxer which didn't flush in write_trailer()
[14:29] <CIA-54> ffmpeg: previously. This is the cause of the change in the test results.
[14:29] <CIA-54> ffmpeg: mp3enc: write Xing TOC
[14:29] <CIA-54> ffmpeg: Based on the code by:
[14:29] <CIA-54> ffmpeg: Peter Belkner <pbelkner at snafu.de>,
[14:29] <CIA-54> ffmpeg: Michael Niedermayer <michaelni at gmx.at>,
[14:29] <CIA-54> ffmpeg: Clément BSsch <clement.boesch at smartjog.com>,
[14:29] <CIA-54> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de>, and
[14:29] <CIA-54> ffmpeg: 03Andrey Utkin 07master * r0443879089 10ffmpeg/doc/filters.texi: 
[14:29] <CIA-54> ffmpeg: Enhance doc on asyncts audiofilter
[14:29] <CIA-54> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[14:29] <CIA-54> ffmpeg: 03Michael Niedermayer 07master * rf276a490f0 10ffmpeg/: (log message trimmed)
[14:29] <CIA-54> ffmpeg: Merge commit '3f7fd59d151a2773f0e2e93e56b6b13ec6e5334b'
[14:29] <CIA-54> ffmpeg: * commit '3f7fd59d151a2773f0e2e93e56b6b13ec6e5334b':
[14:29] <CIA-54> ffmpeg:  avformat: fix typo in avformat_close_input
[14:30] <CIA-54> ffmpeg:  mp3enc: write Xing TOC
[14:30] <CIA-54> ffmpeg:  mp3enc: support MPEG-2 and MPEG-2.5 in Xing header.
[14:30] <CIA-54> ffmpeg:  mp3enc: downgrade some errors in writing Xing frame to warnings
[14:42] <CIA-54> ffmpeg: 03Michael Niedermayer 07master * r197bbcf44c 10ffmpeg/libavformat/mp3enc.c: 
[14:42] <CIA-54> ffmpeg: mp3enc: move mp3_update_xing() down
[14:42] <CIA-54> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:42] <CIA-54> ffmpeg: 03Michael Niedermayer 07master * r744e4429cf 10ffmpeg/libavformat/mp3enc.c: 
[14:42] <CIA-54> ffmpeg: mp3enc: merge mp2/mp3_write_trailer
[14:42] <CIA-54> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:58] <CIA-54> ffmpeg: 03Ronald S. Bultje 07master * rc1c8fdab46 10ffmpeg/compat/msvcrt/snprintf.c: 
[14:58] <CIA-54> ffmpeg: compat/vsnprintf: return number of bytes required on truncation.
[14:58] <CIA-54> ffmpeg: This conforms to C99, but requires Windows >= XP.
[14:58] <CIA-54> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[14:58] <CIA-54> ffmpeg: 03Mans Rullgard 07master * r7689eea49a 10ffmpeg/ (6 files in 3 dirs): flacdsp: arm optimised lpc filter
[14:58] <CIA-54> ffmpeg: 03Mans Rullgard 07master * r1c9d54b468 10ffmpeg/common.mak: 
[14:58] <CIA-54> ffmpeg: build: Properly remove object files while cleaning
[14:58] <CIA-54> ffmpeg: Previously, object files in, for example, compat/ were left
[14:58] <CIA-54> ffmpeg: after a clean or distclean was run.
[14:58] <CIA-54> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[14:58] <CIA-54> ffmpeg: 03Anton Khirnov 07master * r8b78c2969a 10ffmpeg/libavcodec/bmp.c: 
[14:58] <CIA-54> ffmpeg: bmpdec: only initialize palette for pal8.
[14:58] <CIA-54> ffmpeg: Gray8 is not considered to be paletted, so this would cause an invalid
[14:58] <CIA-54> ffmpeg: write.
[14:59] <CIA-54> ffmpeg: nellymoserdec: drop support for s16 output.
[14:59] <CIA-54> ffmpeg: It internally decodes as float and then converts to s16 by a call to
[14:59] <CIA-54> ffmpeg: float_to_int16(). The caller can do this just as well by using lavr.
[14:59] <CIA-54> ffmpeg: 03Mans Rullgard 07master * r2568646abb 10ffmpeg/libavcodec/mpegvideo_motion.c: 
[14:59] <CIA-54> ffmpeg: mpegvideo: drop unnecessary arguments to hpel_motion()
[14:59] <CIA-54> ffmpeg: These arguments are either constants or copies of MpegEncContext
[14:59] <CIA-54> ffmpeg: fields just as easily accessed within the function.
[14:59] <CIA-54> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:31] <CIA-54> ffmpeg: 03Carl Eugen Hoyos 07master * r52ef5ca9bb 10ffmpeg/doc/general.texi: Mentioning 8bps once in the FFmpeg documentation is sufficient.
[16:39] <michaelni> ubitux, about ffplay AV sync, you might want to CC marton balint, iam not sure he wont miss the mail otherwise
[16:40] <ubitux> will do if i don't see any reply
[16:40] <ubitux> michaelni: any more comments on the various ogg cleanups?
[16:44] <CIA-54> ffmpeg: 03Carl Eugen Hoyos 07master * r6fa2532dd3 10ffmpeg/libavcodec/vda_h264.c: 
[16:44] <CIA-54> ffmpeg: vda_h264.c: Change header inclusion order.
[16:44] <CIA-54> ffmpeg: Fixes compilation with XCode 3.2.6.
[16:44] <CIA-54> ffmpeg: Fixes ticket #1736.
[16:44] <michaelni> no
[16:45] <ubitux> ok to push then?
[17:02] <michaelni> ubitux, if you took care of all (non nit) comments, think its free of new security issues and volunteer to help a bit maintaining it in the future ;), yes push 
[17:04] <ubitux> okay :)
[17:31] <kierank> ubitux: your r128 scanner is very cool
[17:33] <ubitux> haha thx :)
[17:54] <ubitux> kierank: any suggestion of improvement?
[17:54] <kierank> I don't understand " /* set audio output formats (same as input since it's just a passthrough) */"
[17:55] <kierank> it doesn't normalise the audio?
[17:55] <ubitux> nope no normalization yet
[17:55] <ubitux> just graphing
[17:55] <kierank> ah
[17:56] <ubitux> ideally, the M,S,I,LRA will be transmitted to another filter for normalization
[17:56] <kierank> i see
[17:56] <ubitux> i need to figure out how that could be done
[17:56] <ubitux> also, i need metadata injection in lavfi :p
[18:09] <ubitux> but i'll focus on that later, i need to get done some stuff now :p
[18:09] <ubitux> too much things started; webvtt/vobsub/ebur128/ogg... :p
[18:09] <kierank> hehe webvtt
[18:09] <ubitux> well webvtt is done
[18:09] <ubitux> it's just ignoring all the markups
[18:10] <kierank> of course
[18:10] <ubitux> i'll likely make a new version supporting elementary tags and push it
[18:10] <ubitux> shouldn't take long
[18:10] <kierank> i reckon either smpte-tt will win or they'll concede and add 608/708 support to web
[18:11] <ubitux> i don't know much about the other closed captions
[18:12] <ubitux> it just seems that webvtt is going to be kind of spread
[18:12] <ubitux> and actually, it's a good occasion to make things better from a subtitles PoV in ffmpeg
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * rbf8bfc6a11 10ffmpeg/libavformat/oggdec.c: 
[18:34] <CIA-54> ffmpeg: lavf/oggdec: inline ogg_get_headers().
[18:34] <CIA-54> ffmpeg: There is no point in a distant definition of a small function like this
[18:34] <CIA-54> ffmpeg: used only once.
[18:34] <CIA-54> ffmpeg: Additional spacing to distinguish better the block.
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * re1ca1dd71b 10ffmpeg/libavformat/oggdec.c: lavf/oggdec: remove a comment not matching anything.
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * r277ddf127d 10ffmpeg/libavformat/oggdec.c: 
[18:34] <CIA-54> ffmpeg: lavf/oggdec: rename str to sid.
[18:34] <CIA-54> ffmpeg: "str" is misleading here (it's often used for string). "sid" makes more
[18:34] <CIA-54> ffmpeg: sense to identify a stream id.
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * re18ea76523 10ffmpeg/libavformat/oggdec.c: lavf/oggdec: more explicit zeroing of the new ogg stream.
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * r23f6420026 10ffmpeg/libavformat/oggdec.c: lavf/oggdec: reindent and comment blocks.
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * r094991eb69 10ffmpeg/libavformat/oggdec.c: lavf/oggdec: reword stream creation error message.
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * r3a89553347 10ffmpeg/libavformat/oggdec.c: lavf/oggdec: rework allocations in ogg_new_streams().
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * redca80387c 10ffmpeg/libavformat/oggdec.c: 
[18:34] <CIA-54> ffmpeg: lavf/oggdec: simplify destroying streams with chained audio streams.
[18:34] <CIA-54> ffmpeg: nstreams is assumed to be 1 at that point, so the loop is pointless.
[18:34] <CIA-54> ffmpeg: 03Clément BSsch 07master * ra218c5ebd2 10ffmpeg/libavformat/oggdec.c: 
[18:34] <CIA-54> ffmpeg: lavf/oggdec: make stream replacement less convoluted.
[18:34] <CIA-54> ffmpeg: Also re-use the allocated buffer instead of re-allocating a new one.
[18:52] <ubitux> the ogg regression will be fixed tonight
[18:52] <ubitux> if everything goes fine :p
[18:56] <Daemon404> nevcairiel, indeed
[19:36] <CIA-54> ffmpeg: 03Michael Niedermayer 07master * ra593f5bd9d 10ffmpeg/libavcodec/arm/dca.h: 
[19:36] <CIA-54> ffmpeg: arm/dca: Fix compilation of decode_blockcodes() with --enable-thumb
[19:36] <CIA-54> ffmpeg: Fix Suggested-by: Reimar
[19:36] <CIA-54> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:46] <Daemon404> who is fate-admin?
[19:48] <nevcairiel> baptiste answered me on my key add request, so i guess
[19:48] <Daemon404> oic
[19:48] <Daemon404> did you beat me to a ffmpeg fate msvc box? :P
[19:49] <nevcairiel> didnt bother setting one up, but it would take 5 minutes to do :p
[19:49] <Daemon404> lol
[19:49] <Daemon404> have you actually tried building on win7 btw?
[19:49] <Daemon404> with -jN?
[19:49] <nevcairiel> i only do fate on 2008
[19:49] <nevcairiel> everything else on 7
[19:49] <nevcairiel> so yes
[19:51] <nevcairiel> it was rather odd that it didnt manage to get a 100% load during building
[19:52] <Daemon404> so you got the "win7 ftl" problem too?
[19:53] <nevcairiel> i'll try on 2008 now to see if its better
[19:54] <Daemon404> [01:13] <@Robo210> http://i.imgur.com/G9Jg5.png
[19:54] <Daemon404> [01:14] <@Robo210> each of those colored lines is a process running on the cpu
[19:54] <Daemon404> [01:14] <@Robo210> 100% means it is using 100% of a single processor core during that time interval
[19:54] <Daemon404> [01:14] <@Daemon404> eck
[19:54] <Daemon404> [01:15] <@Daemon404> i have no idea what could cause that
[19:54] <Daemon404> [01:15] <@Daemon404> or what theyre blocking waiting for
[19:54] <Daemon404> [01:15] <@Robo210> you'll notice that only one process is running at a time, even though there are 7 other cores sitting idle
[19:54] <Daemon404> ^ last night
[19:54] <Daemon404> (someone who knows more about MS tools than i)
[19:54] <Daemon404> theyre all waiting on some resource
[19:55] <Compn> Daemon404 : http://i.imgur.com/G9Jg5.png is 404
[19:55] <Compn> :P
[19:55] <Daemon404> o
[19:55] Action: Daemon404 ruls
[19:55] <Daemon404> still in my cache
[19:55] <Compn> lul
[19:55] <Daemon404> http://i.imgur.com/Fyt3o.png
[19:56] <Compn> lookat dem funky graph
[19:58] <Daemon404> i somehow think c99wrap is to blame
[19:58] <Compn> you're just talking about threaded msvc building ?
[19:58] <Daemon404> make -jN with cc="c99wrap cl"
[19:58] <Compn> what version make ?
[19:58] <Compn> possibly tho
[19:58] <Daemon404> irrelevant
[19:58] <Daemon404> tired them all
[19:59] <Compn> c99wrap have threading options ?
[19:59] <ohsix> disks are funny things
[19:59] <Daemon404> Compn, its not threads
[19:59] <Compn> :P
[19:59] <Daemon404> ohsix, it's not i/o bound
[19:59] <Daemon404> hardly any i/o is being used
[19:59] <Compn> use filemon to see whats up
[19:59] <Compn> nah
[19:59] <Compn> wont help
[19:59] <ohsix> you can be io bound when QOS says you don't get that much disk access :p
[19:59] <Daemon404> no this is the windows performance kit
[20:00] <Daemon404> ohsix, i somewhat doubt it's i/o. i can use the same amount of i/o with a similar use case just fine
[20:00] <Daemon404> aka parallel builds in msvs
[20:00] <Daemon404> or with gcc/migw
[20:00] <Daemon404> mingw*
[20:00] <ohsix> okay
[20:01] <Daemon404> i think it's likely c99wraps fault
[20:01] <Daemon404> teh way it is launching procs
[20:01] <Daemon404> makign a giant lock somewhere
[20:01] <nevcairiel> can always test if it happend to start after the createprocess change
[20:01] <Daemon404> no it didnt
[20:02] <Daemon404> i actually tested if that fixed it too :P
[20:02] <Daemon404> its pre-createproc
[20:02] <Daemon404> before ohsix asks: https://github.com/rbultje/c99-to-c89/blob/master/compilewrap.c
[20:02] <Daemon404> code is here
[20:03] <Compn> if you just use make -jN with cc="cc" does threading work ?
[20:03] <Compn> probably yes
[20:03] <Daemon404> cc=gcc works fine
[20:03] <Daemon404> i said that above
[20:04] <Compn> i'm slow today :)
[20:04] <nevcairiel> does that also happen for libav? its fate is running right now, giving near 100% usage
[20:04] <nevcairiel> on 2008
[20:04] <Daemon404> it happens for libav and ffmpeg
[20:04] <Daemon404> on win7
[20:04] <Daemon404> for me
[20:05] <Daemon404> i get 100% cpu on 2008r2
[20:05] <Daemon404> (diff box)
[20:05] <nevcairiel> 2008r2 and win7 should be rather similar kernel wise
[20:05] <Daemon404> i know
[20:05] <ohsix> it's not the wrapper
[20:05] <Daemon404> they ARE the same kernel
[20:06] <Daemon404> ohsix, im sort of clueless as to what it could atually be then
[20:06] <ohsix> i dunno how to weed out the environmental stuff on win7, so i'd just assume that until i knew otherwise
[20:07] <ohsix> about the only thing it does is call unlink
[20:07] <ohsix> hur This POSIX function is deprecated beginning in Visual C++ 2005. Use the ISO C++ conformant _unlink instead.
[20:07] <ohsix> making shit hard for no reason
[20:08] <Daemon404> ohsix, that wouldnt explain what cl.exe is waiting on
[20:08] <Daemon404> i thought it might be related to the wrapper waiting for a return code
[20:08] <Daemon404> but that doesnt make sense
[20:10] <Daemon404> .......
[20:10] <Daemon404> i wonder
[20:10] <Daemon404> what happens if we set SetProcessAffinityMask <_<
[20:10] <Daemon404> http://support.microsoft.com/kb/2417038
[20:10] <Daemon404> but i guess that wouldnt make sense
[20:11] <nevcairiel> it doesnt
[20:11] <Daemon404> since were not hard setting it on the parent process
[20:11] <ohsix> find some tools, all this guessing is teh sux
[20:11] <Daemon404> i was using the WPK
[20:11] <ohsix> apimonitor can show syscall latency but it's hard to hook it up to cl unless you find one invocation that does the same thing
[20:11] <Daemon404> but i dunno really how to even approach this problem
[20:12] <Daemon404> yeah
[20:12] <ohsix> you could also just ignore it
[20:12] <Daemon404> it cripples builds
[20:12] <nevcairiel> make does its job properly and launches enough cl.exe, i can see them sit there
[20:13] <nevcairiel> so something makes it wait for no reason
[20:13] <Daemon404> each cl.exe is waiting on another cl.exe
[20:13] <Daemon404> which is usign some resource
[20:13] <Daemon404> locking it
[20:13] <ohsix> cl is magic
[20:13] <Daemon404> according to WPK
[20:14] <Daemon404> im going to install msvs 2012 and see if an ew cl.exe still does it
[20:15] <nevcairiel> i can try, i have it setup
[20:15] <Daemon404> and you can reproduce the problem with 2010?
[20:15] <Daemon404> it was using hardly any cpu for me
[20:15] <nevcairiel> yes
[20:15] <Daemon404> ok
[20:15] <Daemon404> can you try?
[20:15] <Daemon404> (win 7 + 2012)
[20:15] <nevcairiel> goes to an average of 40% or so
[20:15] <Daemon404> 40?
[20:15] <Daemon404> make -j8 did like
[20:15] <Daemon404> fucking 5% for me
[20:16] <nevcairiel> thats not even one core
[20:16] <Daemon404> inorite
[20:16] <Daemon404> make -j1 works surefine
[20:17] <ohsix> the difference is weird, but it's not like cl hasn't been very poor at this forever
[20:17] <ohsix> they introduced incremental compilation and load & go just to get around a full build sucking
[20:17] <Daemon404> bare cl.exe in msvs works fine ro parallelism
[20:17] <Daemon404> last time i tried
[20:18] <Daemon404> (via msbuild)
[20:19] <ohsix> find out what system call has the highest latency
[20:19] <ohsix> why can come later
[20:19] <Daemon404> hold on
[20:19] <Daemon404> im dlign 2012 pro (lol free msdn)
[20:19] <Daemon404> then lunch
[20:19] <ohsix> it's probably some fruity precompiled header or something redundant from an unclean build
[20:19] <Daemon404> then apimonitor
[20:20] <Daemon404> no precompiled headers here
[20:20] <Daemon404> not used
[20:20] <nevcairiel> if it was something simple like that, it wouldnt be tied to one OS
[20:20] <ohsix> "something redundant"
[20:20] <nevcairiel> you can start with a 100% clean tree
[20:20] <nevcairiel> run it on 7, its slow, run it on 2008r2, its fast
[20:20] <ohsix> it's not just the OS, it's the setup, the tree, the compiler, it's everything right now
[20:20] <nevcairiel> its the same compiler
[20:21] <nevcairiel> the same tree
[20:23] <Daemon404> right i forgot msdn has this stupid dl manager
[20:24] <ohsix> but it's not the saaaame
[20:24] <Daemon404> orite
[20:25] <Daemon404> dl is an iso
[20:25] <Daemon404> win7 cant mount isos
[20:25] <ohsix> pismo file mount
[20:25] <ohsix> (at least it's free :)
[20:26] <ohsix> there's a thing to convert the images to the ones windows can mount, too, but f if i can remember either
[20:26] <nevcairiel> Daemon404: same problem with 2012
[20:27] <Daemon404> damn
[20:28] <ohsix> hur nevermind you have to use a 3rd party tool to convert them to wim
[20:29] <Daemon404> indeed
[20:29] <ohsix> well i'm sorry i can't tell you directly, you'll just have to use apimonitor; when you know more i might be able to give you an idea, if it isn't immediately obvious already
[20:30] <Daemon404> ill run apimonitor after lunch
[20:30] <Daemon404> after i install 2012 ( i need to anyway
[20:30] <ohsix> there are perf counters for this stuff but it'd be extremely convoluted to set it up just to see what cl is doing
[20:30] <Daemon404> also
[20:30] <Daemon404> pismo file mount;s site
[20:30] <Daemon404> lawdy
[20:30] <Daemon404> is this 1995
[20:30] <ohsix> yep
[20:32] <Daemon404> oh well it works
[20:32] <ohsix> it would be pretty nice if everyone standardized on fuse for a userspace filesystem, even if you have to put windows junk in the linux/osx side of things to really support it
[20:33] <ohsix> there are like 10 userspace filesystems from third parties on windows, and a few windows even supports natively lul
[20:33] <ohsix> it's like my-pet-wrapper for the windows userspace drivers
[20:34] <Daemon404> >.>
[20:34] <Daemon404> i see with 2012 i dont have an option for what features to install
[20:34] <Daemon404> only everything
[20:35] <nevcairiel> i think i got some high-level options
[20:35] <Daemon404> yea
[20:35] <Daemon404> but i usually only install c/c++
[20:35] <ohsix> why even install visual studio if that's all you want, you can get newer compilers from the psdk/wdk
[20:36] <ohsix> they come with prefast and stuff, too
[20:36] <Daemon404> laziness
[20:36] <Daemon404> anyway
[20:36] <Daemon404> lunch
[20:36] Action: Daemon404 bbiab
[20:37] <ohsix> last i used it it still had .bat files for setting up your environment as if it were like 20 different compiler/os combinations
[20:37] <ohsix> which is cool if you need to target a bunch, or are testing
[20:39] <nevcairiel> still coems with the bat file
[20:39] <nevcairiel> i think its quite handy
[20:56] <nevcairiel> Daemon404: i copy-pastad my libav fate script and now there is one for ffmpeg as well. if you run one as well, might as well have one on another config, maybe with threads
[21:13] <Daemon404> indeed
[21:14] <Daemon404> i also thought about maybe icl for windows
[22:19] <nevcairiel> shouldnt icl even work without the c99conv?
[22:19] <Daemon404> yes
[22:19] <Daemon404> well only recently
[22:20] <Daemon404> when inline asm was properly segmented off
[22:20] <nevcairiel> that would be a neat alternative for debugging even, it can create MS compatible debug info
[22:21] <Daemon404> yeah
[22:21] <Daemon404> hah
[22:22] <Daemon404> i tempted the guy i know at ms into working on it fixing the converter
[22:22] <Daemon404> or, figuring out whats wrong
[22:22] <nevcairiel> dare him to add dwarf debug support to msvc
[22:22] <Daemon404> nah
[22:22] <Daemon404> he doesnt work on msvc
[22:22] <Daemon404> juts WPK
[22:45] <nevcairiel> i briefly tried icl on windows, and it will need some more configure changes
[22:46] <Daemon404> ah
[22:46] <nevcairiel> it looks like intel has two different frontends, one that mimics gcc on linux, and one that mimics msvc on windows
[22:46] <Daemon404> well i can get most intel software free-ish.. so i might try it
[22:46] <Daemon404> nevcairiel, both have c99 modes
[22:46] <nevcairiel> yes of course
[22:46] <nevcairiel> but the compiler option it takes are different
[22:47] <nevcairiel> and configure is not aware of that
[22:48] <Daemon404> ah
[22:51] <nevcairiel> it also uses a slightly different syntax, which again messes with msys, and would need a wrapper
[22:51] <nevcairiel> but c99wrap doesnt work, because once it sees compiling related options, it a lso calls c99conv
[22:51] <Daemon404> lol
[22:51] <nevcairiel> why cant it be easy for once
[22:53] <Daemon404> [16:48] <@Robo210> you are going to hate me here, but...
[22:53] <Daemon404> [16:49] <@Robo210> when i compile it on my machine, it's using 100% of the processors, all the time
[22:53] <Daemon404> [16:50] <@Daemon404> >______>
[22:53] <Daemon404> [16:50] <@Daemon404> wtf?
[22:53] <Daemon404> motherfu--
[22:53] <Daemon404> [16:51] <@Robo210> i only have 2 cores, but they are max out the entire time
[22:54] <nevcairiel> my run also uses enough performance for 2 cores
[22:54] <nevcairiel> run it on 4+4, and you see some idle
[22:55] <Daemon404> how much of that idle is the hyperthreaded cores?
[22:56] <nevcairiel> its really not easy to figure that out on windows
[22:56] <nevcairiel> it shows cpu usage all over the place
[22:56] <nevcairiel> anyway, my 2008r2 also is 4+4
[22:57] <nevcairiel> just a xeon model
[22:57] <Daemon404> ic
[23:00] <Daemon404> i guess he cant help much if he cant reproduce it
[23:00] <Daemon404> i cant give him rdp to mine since its on vimeo's corp network
[00:00] --- Mon Sep 17 2012