[FFmpeg-devel-irc] IRC log for 2010-08-26

[irc at mansr.com]

[18:09:28] * Terminating due to: TERM
[18:09:40] * /join #ffmpeg-devel ...
[18:09:42] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[18:09:42] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886342
[18:09:42] <mru> and you promised not to commit war
[18:09:47] <Dark_Shikari> I'm not commit warring
[18:09:51] <mru> and you were about to
[18:09:55] <Dark_Shikari> I'm reverting something that you committed to something I maintain (x86)
[18:10:01] <Dark_Shikari> which is something you don't maintain
[18:10:02] <Dark_Shikari> you maintain ARM
[18:10:04] <mru> since when do you maintain anything?
[18:10:11] <Dark_Shikari> since Michael said so?
[18:10:16] <Dark_Shikari> Michael said I'm an x86 co-maintainer
[18:10:18] <mru> when did he say that?
[18:10:18] <Dark_Shikari> repeatedly
[18:10:27] <mru> show me
[18:10:27] <Dark_Shikari> every bloody time there's an x86 patch
[18:10:38] <mru> show me
[18:10:41] <Dark_Shikari> Me and Loren, that is
[18:10:48] <janneg> mru: he did
[18:10:52] <mru> so bloody show me
[18:10:58] <mru> or I'll have to ban you all
[18:11:02] <Dark_Shikari> ....
[18:11:06] <Dark_Shikari> so I'm the one "warring"
[18:11:06] <peloverde> Look we all are behaving like children Dark_Shikari: You shouldn't have tried to revert the commit, mru: You shouldn't have block his access, and I should have tried to fix this rather than just pissing and moaning about it
[18:11:10] <Dark_Shikari> but you're threatening to ban everyone?
[18:11:30] <mru> peloverde: I blocked his access because he threatened to start a commit war
[18:11:31] <Vitor1001> Just wondering, any reason not to simply drop "--cpu=i686"?
[18:11:48] <Dark_Shikari> Because it works as a generic "give me cmov" option.
[18:11:52] <Dark_Shikari> People use it for that.
[18:11:58] <Dark_Shikari> It's also a pretty standard identifier across linux distros.
[18:12:01] <mru> I don't fucking care
[18:12:03] <Vitor1001> If you want CMOV and no MMX, you have a pentiumpro then you should use --cpu=pentiumpro
[18:12:03] <Dark_Shikari> Even if you don't like it, people use it.
[18:12:15] <Dark_Shikari> mru: then don't remove my fucking commit access
[18:12:26] <Dark_Shikari> If you don't care, stop acting like you do.
[18:12:26] <peloverde> Vitor1001: The problem with that is it drops runtime detection for MMX
[18:12:29] <mru> Dark_Shikari: then don't commit stuff you're not supposed to
[18:12:33] <Vitor1001> We can just fail and suggest either "--cpu=pentiumpro2orlater" or --cpu=486
[18:12:34] <Dark_Shikari> I'm supposed to commit things to code I maintain.
[18:12:42] <Dark_Shikari> Vitor1001: read what mru said again
[18:12:47] <Dark_Shikari> he wants --cpu=pentium3 to remove sse2
[18:12:52] <Dark_Shikari> he wants --cpu=pentium4 to remove ssse3
[18:12:57] <Dark_Shikari> this applies _generally_
[18:13:25] <Vitor1001> bbl
[18:14:24] <Dark_Shikari> mru: stop it.
[18:14:24] <Dark_Shikari> now
[18:14:27] <Dark_Shikari> give me back my svn access
[18:14:38] <mru> what will you do?
[18:14:46] <Dark_Shikari> I will commit that patch.
[18:14:52] <mru> which patch?
[18:15:06] <Dark_Shikari> r24946, reversed.
[18:15:12] <Dark_Shikari> I will not revert emms.
[18:15:33] <Dark_Shikari> reasoning: there are three possible solutions to this problem
[18:15:41] <Dark_Shikari> 1) Revert everything, give up. (not going to do this yet)
[18:15:49] <Dark_Shikari> 2) Your solution (too many problems, many people disagree)
[18:15:56] <Dark_Shikari> 3) some other solution which doesn't involve reverting emms
[18:16:08] <Dark_Shikari> we're holding out in the hope that someone can come up with a good solution for 3) so we don't have to do 1).
[18:16:17] <Dark_Shikari> however, neither 1) nor 3) involves r24946.
[18:16:21] <Dark_Shikari> therefore, r24946 should be reverted.
[18:16:28] <peloverde> which one is r24946?
[18:16:37] <Dark_Shikari> the one that makes --cpu=i686 disable mmx.
[18:16:46] <peloverde> until this is fixed r24946 should stand
[18:16:51] <Dark_Shikari> I don't even 100% disagree with that patch
[18:16:57] <Dark_Shikari> but rather, it doesn't inform users at all of the consequences
[18:17:00] <Dark_Shikari> because we _changed_ behavior
[18:17:15] <Dark_Shikari> so I think it's better to have that "bug" than to have that patch
[18:17:20] <Dark_Shikari> that patch will break about 98% of distro builds
[18:17:29] <Dark_Shikari> and the ffmpeg win32 builds too
[18:17:40] <BBB> DS is right, silently disabling mmx is BAD BAD BAD
[18:17:46] <BBB> we assume distro people know what they're doing
[18:17:49] <BBB> yet we know they don't
[18:17:51] <BBB> it's BAD
[18:17:58] <Dark_Shikari> it's really just a matter of hassle, I do not want to deal with users who have broken builds because of this
[18:18:01] <Dark_Shikari> I have no time
[18:18:02] <BBB> silently disabling mmx is the worst thing in the world
[18:18:10] <Dark_Shikari> what BBB said
[18:18:18] <peloverde> BBB: having a build with --cpu=i686 SIGILL on i686 is BAD BAD BAD
[18:18:23] <Dark_Shikari> peloverde: no, actually it isn't
[18:18:27] <Dark_Shikari> It's not nearly as bad as silently disabling mmx
[18:18:38] <peloverde> I think it's far worse
[18:18:39] <Dark_Shikari> because the latter affects 99.9% of users
[18:18:42] <Dark_Shikari> the former affects 0.1%
[18:18:53] <Dark_Shikari> x264 SIGILLs (well, it errors out) on i686.
[18:18:57] <Dark_Shikari> It has done so for the past 2 YEARS
[18:19:00] <Dark_Shikari> only two people have complained
[18:19:01] <Dark_Shikari> in that entire time
[18:19:06] <peloverde> If users want i686+mmx they can bump to pentium2
[18:19:15] <Dark_Shikari> peloverde: but mru is arguing that pentium2 should disable sse.
[18:19:26] <peloverde> Dark_Shikari: I'm talking about for the time being
[18:19:34] <BBB> peloverde: well, so fail the build then
[18:19:34] <Dark_Shikari> peloverde: that's simply not reasonable
[18:19:38] <peloverde> until we fix this emms issue
[18:19:41] <BBB> don't cripple the build either way
[18:19:44] <Dark_Shikari> if you're going to do that, you have to magically tell every single person in the world
[18:19:44] <BBB> fail it
[18:19:47] <Dark_Shikari> to use pentium2 instead
[18:19:53] <peloverde> fail to build with i686 but not disable-mmx is ok by me
[18:19:58] <BBB> let the user explicitely state --disable-mmx or --enable-mmx or change --cpu
[18:20:01] <Dark_Shikari> here is my advice
[18:20:04] <BBB> so we know what he wants
[18:20:07] <Dark_Shikari> it should be IMPOSSIBLE TO BUILD FFMPEG WITHOUT MMX
[18:20:09] <Dark_Shikari> without using --disable-mmx
[18:20:12] <Dark_Shikari> end of story.
[18:20:13] <BBB> agreed
[18:20:19] <BBB> I said that in a post also
[18:20:25] <Dark_Shikari> That is why we need to revert that patch
[18:20:26] <peloverde> mumble mumble mumble yasm
[18:20:31] <Dark_Shikari> peloverde: unrelated
[18:20:31] <BBB> peloverde: working on it
[18:20:35] <BBB> peloverde: help me converting asm please
[18:20:39] <peloverde> very related
[18:20:41] <BBB> it's a pain and a lot of junkwork
[18:20:51] <peloverde> BBB: not converting things to yasm
[18:20:56] <peloverde> my yasm patch from this morning
[18:21:13] <BBB> oh that
[18:21:15] <BBB> please apply
[18:21:18] <mru> no
[18:21:22] <BBB> I think mru already had such a patch earlier
[18:21:26] <BBB> I Don't know why it changed
[18:21:32] <mru> dying if yasm is absent and mmx disabled is wrong
[18:21:40] <BBB> that's true
[18:21:46] <Dark_Shikari> mru: thank you.
[18:21:52] <peloverde> I'm updating it now
[18:21:53] <CIA-11> ffmpeg: mru * r24949 /trunk/configure:
[18:21:53] <CIA-11> ffmpeg: Revert "Disable MMX for i686 and pentiumpro"
[18:21:53] <CIA-11> ffmpeg: To avoid being burned at the stake by an angry mob, I am forced to
[18:21:53] <CIA-11> ffmpeg: revert this commit.
[18:21:55] <BBB> excellent
[18:22:45] <BBB> thanks for the email also, I'm sure we can solve this quickly in a angry-mob-style way :-p
[18:23:57] <peloverde> why doesn't disable-asm imply disable-mmx and disable-yasm?
[18:24:41] <mru> yasm is just a tool
[18:24:50] <mru> do you want --disable-asm to delete it?
[18:25:20] <brad0> it'll find yasm but just not use it if disable-asm, right?
[18:25:21] <mru> it won't be used with --disable-asm
[18:25:26] <peloverde> no I'm trying to come up with a sane check
[18:25:27] <mru> brad0: yes
[18:25:36] <mru> sane check for what?
[18:25:41] <brad0> that makes sense to me IMO.
[18:25:47] <peloverde> if ! disabled yasm && ! disabled mmx; then ... triggers true if --disable-asm
[18:26:21] <Dark_Shikari> mru: I'm writing up a summary of a few options for you
[18:26:22] <Dark_Shikari> this shoudl help
[18:26:35] <mru> http://pastebin.ca/1926107
[18:26:58] <brad0> peloverde: what triggers true?
[18:27:07] <Dark_Shikari> mru: hah, nice
[18:27:42] <peloverde> mru: that still errors with configure --disable-asm
[18:28:35] <mru> add that to the list too then
[18:28:44] <peloverde> I'll do that
[18:29:07] <brad0> argh! stupid pastebin.ca.
[18:29:20] <mru> they're all stupid
[18:29:28] <Dark_Shikari> mru: check my list
[18:29:47] <brad0> mru: even more so when their network is busted.
[18:29:54] <mru> works for me
[18:30:27] <CIA-11> ffmpeg: alexc * r24950 /trunk/configure: x86: Require yasm OR --disable-asm OR --disable-mmx OR --disable-yasm to build.
[18:30:37] <Dark_Shikari> Looks good peloverde
[18:30:42] <Dark_Shikari> mru: which of my 4 solutions do you prefer?
[18:30:49] <mru> just got the mail
[18:31:09] <mru> peloverde: mike's ppc box doesn't seem to have yasm
[18:31:11] <Dark_Shikari> ok
[18:31:16] <Dark_Shikari> mru: hah!
[18:31:19] <Dark_Shikari> wait.  ppc?
[18:31:22] <Dark_Shikari> we don't use yasm for ppc.
[18:31:31] <mru> err osx
[18:31:33] <Dark_Shikari> lol
[18:31:43] <mru> look what you've done to me
[18:31:46] <mru> I can't think anymore
[18:31:48] <peloverde> wtf it's inside an "elif enabled x86; then"
[18:32:01] <peloverde> oh intel/osx?
[18:32:06] <Dark_Shikari> yeah, it's intel
[18:32:09] <Dark_Shikari> he just didn't install it
[18:32:14] <mru> I know
[18:32:14] <Dark_Shikari> btw, we should have some tests without yasm as well
[18:32:16] <Dark_Shikari> just in case
[18:32:32] <BBB> mru just added no-sse tests no?
[18:32:40] <mru> yes
[18:32:50] <BBB> should be easy to add 1-2 more
[18:32:56] <Dark_Shikari> oh yeah, and mru, both 2) and 3) let us add inline MMX asm.
[18:32:57] <mru> there are plenty of machines running only the C code
[18:33:08] <Dark_Shikari> which is an extra benefit.
[18:33:18] <Dark_Shikari> mru: I meant if non-yasm was broken, but yasm worked
[18:34:26] <BBB> oh my...
[18:34:35] <BBB> this vp3 code is a little annoying to translate
[18:34:54] <Dark_Shikari> "inline asm"  "annoying"
[18:34:55] <BBB> "movdqa address, xmm7" /* xmm7 = address */ \
[18:34:55] <Dark_Shikari> well what a surprise
[18:35:03] <BBB> it goes on like that for 20 lines in a row
[18:35:11] <BBB> I'm trying to keep all comments identical
[18:35:30] <Dark_Shikari> why?  if they're shit, improve them
[18:35:32] <mru> imo feel free to drop idiot comments
[18:35:37] <Dark_Shikari> or remove
[18:35:39] <Dark_Shikari> what mru said
[18:35:48] <Dark_Shikari> "x += 1; //add one to x"
[18:36:23] <j-b> Dark_Shikari: what --cpu= flag do you recommend to compile FFmpeg for x86/Win32 platform?
[18:36:26] <mru> x++; // like x += 1 // add one
[18:36:33] <Dark_Shikari> j-b: I use i686 personally
[18:36:39] <mru> j-b: depends on the cpu of course
[18:36:41] <Dark_Shikari> since anything above that is useless and possibly dangerous
[18:36:48] <Dark_Shikari> *cough* autovectorization
[18:36:51] <j-b> Dark_Shikari: I do too. But I might be wrong.
[18:36:55] <peloverde> j-b: pentium2 is probably good for generic
[18:36:59] <mru> Dark_Shikari: autovec is disabled
[18:37:07] <Dark_Shikari> mru: we turned that off for x86?
[18:37:11] <j-b> mru: this is for the main VLC win32 build. So, normal people on this stupid OS.
[18:37:14] <mru> we turned it off for gcc
[18:37:17] <Dark_Shikari> ah k
[18:37:24] <mru> it broke everywhere
[18:37:24] <j-b> peloverde: ok. some --march too?
[18:37:26] <peloverde> What is the minimum win32 version you require?
[18:37:33] <j-b> peloverde: Win2k
[18:37:41] <j-b> peloverde: and XP for next major
[18:37:51] <j-b> peloverde: we follow Microsoft support.
[18:38:24] <peloverde> XP seems to require pentium 233
[18:38:36] <peloverde> but cmov is good and stuff
[18:38:58] <j-b> peloverde: we do not care about anything under pentium2
[18:39:07] <Dark_Shikari> so mru, which of the 4 options do you prefer
[18:39:57] <peloverde> j-b: cool, we are trying to sort out the cpu stuff at the moment, but you don't care if MMX support is hard coded instead of detected?
[18:40:15] <Dark_Shikari> peloverde: that's what the distro people confirmed was fine
[18:40:18] <Dark_Shikari> hardcoding of mmx specifically
[18:40:23] <Dark_Shikari> iirc.
[18:40:42] <j-b> peloverde: we deactivate autodetection and do it ourselves :D
[18:41:43] <peloverde> Dark_Shikari: If people think hard coding of MMX specifically is OK... i'm ok with it as long as things run on the chips they are configured for.... i.e. --cpu=i686 should require an explicit enable/disable mmx
[18:42:20] <peloverde> Really it should disable-mmx if it can't auto detect it but apparently i686 is codeword for generic
[18:42:41] <Dark_Shikari> also, we need a default --cpu
[18:42:51] <Dark_Shikari> I think --cpu=pentium2 should be the default.
[18:42:58] <peloverde> I agree
[18:43:09] <Dark_Shikari> meaning the default is an actual cpu.
[18:43:19] <Dark_Shikari> as opposed to some nebulous default
[18:43:43] <peloverde> also I don't think --disable-mmx should be explicitly required for i386 or i486
[18:43:47] <mru> I had a patch for that somewhere
[18:43:54] <mru> sensible default cpu
[18:44:04] <Dark_Shikari> peloverde: I think yes it should
[18:44:12] <Dark_Shikari> here's why
[18:44:18] <Dark_Shikari> 1) i686 doesn't support mmx
[18:44:22] <Dark_Shikari> 2) neither does i386 or i486
[18:44:29] <Dark_Shikari> 3) thus, to be consistent, they should all act the same way
[18:44:39] <Dark_Shikari> 4) whether we like it or not, huge numbers of users use i686 for "generic with mmx and cmov"
[18:44:49] <mru> i486 disables cmov
[18:44:51] <Dark_Shikari> 5) therefore, if we break i386/486's mmx, we must break i686's
[18:45:00] <Dark_Shikari> mru: cmov didn't used to be runtime detected =p
[18:45:11] <Dark_Shikari> also, currently, cmov is off by default
[18:45:12] <mru> #5 is fucked up logic
[18:45:14] <Dark_Shikari> because default cpu == generic
[18:45:21] <Dark_Shikari> mru: consistency is important imo
[18:45:24] <peloverde> But the reason for this is because i686 used to mean generic+CMOV
[18:45:35] <Dark_Shikari> if we disable mmx on some cpus that don't support it, we should disable it on all
[18:45:36] <peloverde> i486 always meant hard disable mmx
[18:45:56] <peloverde> i486 never autodetected mmx
[18:46:06] <Dark_Shikari> wait
[18:46:10] <Dark_Shikari> then what was the default --cpu?
[18:46:18] <mru> compiler default
[18:46:24] <mru> with mmx
[18:46:28] <Dark_Shikari> ok, so you're saying that before any of these changes
[18:46:29] <Dark_Shikari> i386: no mmx
[18:46:31] <Dark_Shikari> i486: mmx
[18:46:32] <Dark_Shikari> er,
[18:46:36] <Dark_Shikari> i486: no mmx
[18:46:38] <Dark_Shikari> i686: mmx
[18:46:40] <Dark_Shikari> right?
[18:46:41] <mru> yes
[18:46:50] <Dark_Shikari> ok, then let's keep it that way even if it's wrong.
[18:46:58] <mru> also pentium disables mmx
[18:46:59] <Dark_Shikari> But actually it does kind of make sense
[18:47:02] <mru> and i586
[18:47:10] <Dark_Shikari> some i686 cpus support mmx
[18:47:14] <Dark_Shikari> no i486s do
[18:47:17] <Dark_Shikari> but, well, some pentiums do...
[18:47:27] <mru> there's pentium-mmx for that
[18:48:01] <Dark_Shikari> are there any distros out there compiling ffmpeg with --cpu=i586?
[18:48:05] <Dark_Shikari> I would be totally shocked if there aren't
[18:48:39] <Dark_Shikari> because as you can tell by my reaction, it's not obvious that --cpu=i586 disables mmx
[18:48:44] <Dark_Shikari> especially since --cpu=i686 doesn't!
[18:48:59] <Dark_Shikari> i.e. the user isn't told.
[18:49:18] <Dark_Shikari> IMO the "requiring --disable-mmx for a cpu without mmx" is a good enough way to do it.
[18:49:25] <Dark_Shikari> not perfect, sure, but it wakes people up
[18:51:40] <peloverde> Back in the day mandrake targetted i586
[18:52:03] <peloverde> I remember because GStreamer Hat was building everything 386
[18:54:47] <Yuvi> pretty sure red hat does i586
[18:57:01] <janneg> not a problem since red hat/fedora will never have ffmpeg
[18:57:06] <janneg> ;)
[19:01:02] <Dark_Shikari> peloverde: huh?
[19:01:08] <Dark_Shikari> I'm confused
[19:01:09] <Dark_Shikari> C#?  why
[19:01:34] <peloverde> "a tool to make it more difficult for users to stab themselves in the face"
[19:01:39] <Dark_Shikari> huh?
[19:01:49] <Dark_Shikari> You are as aware as anyone else that users WILL accidentally disable asm
[19:01:51] <Dark_Shikari> and unless you tell them
[19:01:55] <Dark_Shikari> they will then complain about it going slow
[19:01:58] <Dark_Shikari> as per what BBB said
[19:02:02] <Dark_Shikari> we CANNOT silently disable mmx.
[19:02:48] <peloverde> I'm aware, but I don't see it as an issue
[19:03:19] <BBB> guys, STOP FUCKING AROUND :-p
[19:03:30] <Dark_Shikari> peloverde: well, I repeat myself
[19:03:32] <BBB> my god I can barely keep up with marking my inbox emails as read without actually reading them
[19:03:35] <Dark_Shikari> I will revert any patch that silently disables mmx
[19:03:43] <Dark_Shikari> in any situations where it wasn't before
[19:04:01] <BBB> mru: intptr_t ok with you?
[19:04:07] <BBB> mru: I'll work on a patch later on rgarding that
[19:04:21] <BBB> I hate all these if (64bit) movsxd r%d, r%dd statements
[19:04:23] <mru> BBB: intptr_t is defined to be at least as wide as a pointer
[19:04:30] <mru> it's wrong to use for general arithmetic
[19:04:36] <BBB> hm... :(
[19:04:40] <BBB> got anything better?
[19:04:45] <BBB> I'm tempted to just use void *
[19:04:50] <mru> buy a ppc
[19:05:00] <mru> void *?
[19:05:01] <mru> wtf
[19:05:06] <BBB> it was a joke
[19:05:09] <BBB> now calm down :-p
[19:05:28] <mru> not until you guys put down the pitchforks
[19:05:30] <mru> and put out the fire
[19:05:36] <peloverde> What about intptrdiff_t
[19:05:40] <peloverde> it is a pointer difference
[19:06:07] <peloverde> A value meant to be added to a pointer is by definition a pointer difference
[19:06:14] <mru> that's ptrdiff_t
[19:06:23] <mru> and no it's not
[19:06:28] <mru> ptr1-ptr2 is a pointer difference
[19:06:35] <mru> ptr+number is not
[19:06:55] <peloverde> ptr+number is not
[19:06:58] <peloverde> number is
[19:07:02] <BBB> I think he means that number could be defined as ptr1-ptr2
[19:07:06] <BBB> ptrdiff_t isn't a bad idea
[19:07:08] <peloverde> exactly
[19:07:19] <mru> but that's not what the number is
[19:07:23] <BBB> if ptr1+number is a valid number, then that's ptr2, and thus number=ptr2-ptr1
[19:07:23] <mru> it's just a number
[19:07:26] <BBB> thus ptrdiff_t
[19:07:42] <BBB> but anyway, yeah, let's bury the pitchforks for a sec
[19:07:57] <mru> are there any posix interfaces with similar semantics?
[19:08:04] <BBB> that's what I'm wondering
[19:08:10] <BBB> I know nothing about posix
[19:08:22] <BBB> I know long>=int>=short>=char
[19:08:26] <BBB> that's about all I know
[19:09:57] <mru> someone still has to sign extend the thing
[19:10:08] <BBB> caller would do that
[19:10:10] <BBB> instead of callee
[19:10:16] <BBB> that's why I want it part of the interface
[19:10:39] <BBB> if we make it machine native size, then that shouldn't cost any effort on the caller side
[19:12:07] <mru> it still comes from somewhere
[19:12:22] <BBB> right, but that's usually a struct in memory
[19:12:23] <mru> also, mips and ppc don't have that problem
[19:12:34] <BBB> we can leave it as-is, not abig issue
[19:12:37] <peloverde> The caller can resize it when shoving it on the stack or into the appropriate register
[19:12:43] <BBB> I just hate the random movsxds in my code here ;)
[19:12:58] <mru> so you want to hide the ugly parts
[19:13:14] <mru> you'd better pray the compiler doesn't fuck it up too
[19:13:37] <peloverde> The cglobal interface could be extended?
[19:13:39] <mru> also, making it wider might use more stack space
[19:14:01] <peloverde> Is using an extra 4 bytes of stack space in an inner loop that bad?
[19:14:12] <mru> it might be
[19:16:24] <CIA-11> ffmpeg: mru * r24951 /trunk/configure: configure: improve error message for missing yasm
[19:18:08] <mru> oh, and it's quite common to have 64-bit long with 32-bit pointers on ppc64 and mips64
[19:18:32] <peloverde> what's why we don't use long
[19:18:44] <andoma> mru: i've been working with such archs as well...
[19:19:14] <mru> peloverde: but what size would your magic type be?
[19:19:27] <mru> a register is 64 bits, so that would be one logical answer
[19:19:35] <mru> but that would be wasteful
[19:19:53] <peloverde> I'd say 64-bits then
[19:20:07] <mru> but that's wrong
[19:20:18] <peloverde> I disagree
[19:20:19] <mru> or at the very least wasteful
[19:20:21] <peloverde> by the way what was the rationale for C's retarded type system
[19:20:32] <mru> a plethora of existing hardware
[19:20:36] <peloverde> meh I'm an american, I live to be wasteful
[19:23:03] <BBB> Dark_Shikari: how do I create a define that does nothing in yasm?
[19:23:10] <BBB> %define ADD(x) /* nothing */
[19:23:14] <BBB> yasm doesn't like empty defines
[19:23:29] <BBB> %define ADD(x) paddw x, [pw_8] works fine though
[19:23:58] <peloverde> Is there a way we can work integer promotion into the cglobal interface?
[19:24:08] <peloverde> or is that too messy
[19:24:49] <BBB> sign extension?
[19:24:53] <BBB> I don't think that'd work...
[19:25:57] <peloverde> We are potentially pulling arguments from the stack. Why copy them twice.
[19:26:05] <mru> why don't you just make a macro that does it and call said macro with the relevant args at the start of the functionn?
[19:26:31] <BBB> peloverde: well, cglobal doesn't really know which arguments are truncated and which aren't
[19:26:37] <peloverde> i know
[19:26:42] <peloverde> it would praobably be a mess
[19:26:45] <peloverde> sigh
[19:27:02] <mru> is load+sext as two insns really any slower than doing it in one?
[19:27:07] <mru> it's two uops either way
[19:43:46] <BBB> mru: really my only purpose here is int stride
[19:43:59] <BBB> I think we could use ptrdiff_t stride
[19:44:04] <BBB> but I won't push it if you don't like it
[19:44:30] <mru> it's wrong
[19:44:57] <peloverde> it is a pointer difference
[19:48:16] <peloverde> char* some_plane, char* some_planed_plus_stride = some_plane + STRIDE; ptrdiff_t stride = some_planed_plus_stride - some_plane;
[19:51:02] <CIA-11> ffmpeg: mru * r24952 /trunk/configure: configure: write config.fate file as early as possible
[19:51:03] <mru> what's so dreadful about sign extending one value yourself?
[19:51:16] <mru> or two for the functions that take two such params
[19:56:14] <BBB> mru: nothing much
[19:56:20] <BBB> mru: so I'll leave it for now
[20:04:43] <mru> hmm, strange compiler bug
[20:04:59] <mru> armcc 4.1 miscompiles two back-to-back bytestream_get_byte() calls
[20:10:52] <BBB> error: (CAT_XDEFINE:1) `%xdefine' expects a macro identifier
[20:10:53] <BBB> wtf?
[20:15:24] <pengvado> BBB: "%define ADD(x)" worksforme
[20:15:46] <BBB> pengvado: the whole thing doesn't work for me
[20:15:57] <BBB> can I pastebin a whole .asm file and you tell me why it gives me compiler errors?
[20:16:02] <pengvado> yes
[20:16:50] <BBB> http://pastebin.com/YewF0t23
[20:16:54] <BBB> errors at the bottom
[20:16:57] <BBB> so you have line numbers
[20:30:29] <pengvado> BBB: typo on line 513, should be capitalized
[20:53:11] <BBB> pengvado: holy shit, thanks
[21:22:14] <BBB> patch posted \o/ another 2 files moved to yasm
[21:22:27] * BBB looks @ h264 doomsday moment approaching
[21:22:40] <Yuvi> BBB: you should do a %macro SIGN_EXTEND 1 for the movsxd, that'd at least get rid of 2/3 lines in each function
[21:22:50] <astrange> there's going to be a census?
[21:23:35] <BBB> Yuvi: is fine with me also
[21:23:40] <BBB> oh yeah
[21:23:47] <BBB> does anyone know calling convention on x86-32?
[21:23:56] <BBB> there's a ?? in my patch and I don't know what it does on x86-32
[21:24:40] <Yuvi> for yasm (atm) params are always on the stack
[21:24:55] <BBB> if I call a function also from within yasm?
[21:25:01] <Dark_Shikari> within yasm, you can do whatever you want
[21:25:05] <Dark_Shikari> literally
[21:25:36] <BBB> Dark_Shikari: can you fill in the "??" in my patch just posted?
[21:25:41] <BBB> kthnx!!112
[21:25:57] <Yuvi> hm
[21:26:00] <pengvado> we have a macro movsxdifnidn
[21:26:12] <BBB> that's useful
[21:26:17] <BBB> is it in x86util.asm?
[21:26:20] <pengvado> yes
[21:26:22] <BBB> awesome
[21:26:25] <BBB> I'll use that
[21:26:40] <Yuvi> you can't do a tail call to a C function on 32-bit unless it has the same number or fewer arguments
[21:26:54] <BBB> Yuvi: same number of args here
[21:26:58] <BBB> I did a jmp
[21:27:09] <BBB> but the args have different order
[21:27:20] <astrange> if clang supports __attribute__((fastcall)) we could switch dsp to that on x86-32
[21:27:29] <astrange> i'm not sure it would really save much
[21:27:36] <BBB> probably not
[21:27:41] <BBB> we barely do any function calls inside simd
[21:28:08] <pengvado> the main point would be to save time when calling simd in the first place
[21:28:45] <Yuvi> BBB: something like
[21:28:45] <Yuvi> mov r0m r2
[21:28:46] <Yuvi> mov r1m r0
[21:28:46] <Yuvi> mov r2m r1
[21:29:08] <BBB> and then jmp?
[21:29:12] <Yuvi> yeah
[21:29:15] <BBB> awesome
[21:29:18] <jenk> man i thought i knew assembly but i srsly dont know any of the operands or instructions you guys mention in here
[21:29:19] <BBB> so I don't need the fourth arg
[21:29:27] <jenk> movsxdifnidn ????? wtf
[21:29:36] <astrange> they're macros in x86util
[21:29:37] <BBB> that's a macro, not a instr
[21:29:40] <Dark_Shikari> jenk: movsxd if not identical
[21:29:41] <jenk> i get that its a macro
[21:29:48] <jenk> but i dont even know what it would be a macro for
[21:29:49] <Dark_Shikari> that is, if the two arguments are the same
[21:29:50] <Dark_Shikari> do nothing
[21:29:50] <pengvado> we pretty much wrote our own assembly syntax
[21:29:53] <Dark_Shikari> otherwise, do it
[21:30:01] <jenk> ic
[21:30:08] <jenk> i dont even know what movsxd is
[21:30:12] <jenk> i know mov!
[21:30:13] <jenk> lol
[21:30:19] <Dark_Shikari> mov sign-extend double
[21:30:28] <Dark_Shikari> 32bit -> 64bit, with sign extend
[21:30:29] <jenk> is that a FP inst?
[21:30:34] <Dark_Shikari> doubleword
[21:30:36] <Dark_Shikari> i.e. 32-bit int
[21:30:39] <jenk> oh that kind of double
[21:30:58] <Yuvi> BBB: oh, make sure to pop any clobbered regs
[21:31:07] <Yuvi> before the jmp
[21:31:08] <BBB> O
[21:31:08] <BBB> ,
[21:31:10] <BBB> oops
[21:31:12] <pengvado> doubleword. which is really half of a word.
[21:31:13] <BBB> I'm not using any, I think
[21:31:29] <jenk> i learned all kinds of useless x86, like setting up ring0 and using the built-in multitasking
[21:31:35] <jenk> and virtual memory
[21:31:50] <jenk> i basically leanred how to make DOS
[21:32:09] <iive> dos doesn't mess with ring0, it is realmode.
[21:32:35] <BBB> Yuvi: ok, patch updated, I'm using only 3 regs on 32 and 4 on 64, so I don't think I have to pop any, or do I?
[21:32:48] <Yuvi> nope
[21:33:16] <jenk> but DOS does use the built-in "OS" features of the x86
[21:33:20] <jenk> and nothing else does
[21:33:52] <BBB> Yuvi: excellent, thanks for the help!
[21:33:57] <jenk> i wonder if there's a way to abuse them for performance
[21:34:15] <jenk> like using the virtual memory exceptions as a nifty in-hardware hash table or something
[21:36:37] <pengvado> aren't exceptions, like, really slow?
[21:36:51] <jenk> hardware faults to be precise
[21:37:01] <jenk> i dunno
[21:37:05] <jenk> are they
[21:41:39] <mru> hw exceptions are always slow
[21:42:09] <mru> they flush all kinds of state and switch to kernel mode
[21:42:34] <mru> which then has to save context, do stuff, restore context, and switch back to user mode
[21:42:48] <mru> count hundreds of cycles at the minimum
[21:43:45] <mru> many modern cpus have more efficient ways of doing a system call
[21:44:10] <mru> they can be made faster since it's really just like a normal function call except it switches to kernel mode
[21:49:06] <jenk> not int 0x80?
[21:49:31] <mru> that's oldskool
[21:49:40] <jenk> it is?
[21:49:46] <mmu_man> call gates, ...
[21:49:48] <jenk> what do you do now
[21:49:53] <mru> sysenter
[21:50:07] <mru> http://www.intel.com/software/products/documentation/vlin/mergedprojects/analyzer_ec/mergedprojects/reference_olh/mergedprojects/instructions/instruct32_hh/vc311.htm
[21:50:09] <jenk> i will check that out
[21:50:14] <mru> what a lovely url
[21:50:21] <astrange> there's also new stuff for fast virtualization
[21:50:40] <Yuvi> mergedprojects x3
[21:50:59] <mmu_man> it's a big merge
[21:51:30] <jenk> it looks like it acts just like int 0x80? it jumps to an address specified by the OS
[21:51:37] <jenk> except you have to manually save regs
[21:51:58] <jenk> i will keep reading though
[21:51:58] <mru> which can be a huge win
[21:52:06] <mru> if you're not actually going to modify most of them
[21:52:30] <jenk> ah
[21:52:44] <mmu_man> saves the cost of fetching/decoding all the movs
[21:53:51] <mmu_man> hmm or just moving them for fast paths
[21:54:39] <jenk> man my asm is so rusty
[21:54:52] <jenk> im guessing MIPS is still just "syscall"
[21:55:06] <mru> I think so
[21:55:45] <mru> some systems also do clever things that completely avoid an actual context switch for some syscalls
[21:56:13] <mru> linux/ppc has a special page that processes can map read-only
[21:56:24] <mru> reading the right place on that page gives the current time
[21:56:36] <mru> so gettimeofday() doesn't need a full syscall
[21:56:51] <mru> some apps call that a _lot_
[21:57:10] <mru> mostly stupid ones of course
[21:57:13] <mru> like firefox
[21:58:46] <jenk> linux does that with VDSO doesn't it?
[21:59:05] <mmu_man> linux-gate.so
[21:59:32] <mmu_man> Haiku also has a "comm page" for those like system_time() or optimized memcpy
[21:59:59] <mmu_man> mru well depends, at least on BeOS system_time() which is equivalent is meant to be cheap
[22:00:08] <mmu_man> and used
[22:00:22] <mru> the apps are still stupid
[22:00:30] <mru> how quickly do they expect the time to change?
[22:00:36] <mru> and why the fuck do they care?
[22:01:16] <mmu_man> how else would they get those cpu-sucking JavaScript newstickers work smoothly ? :)
[22:01:27] <mmu_man> (while it can use no cpu if correctly written but eh)
[22:01:36] <mru> set a timer for the actual time you want to wake up?
[22:02:20] <jenk> so sysenter transitions to CPL=0, pushes relevant registers, switches to kernel stack etc...
[22:02:26] <jenk> how is this different from what int 0x80 does?
[22:02:31] <mru> mmu_man: btw, how's ffmpeg/beos doing these days?
[22:02:34] <mru> jenk: I don't know
[22:02:39] <mru> but it's supposed to be faster
[22:02:40] <jenk> hrm
[22:02:45] <jenk> i am looking at http://articles.manugarg.com/systemcallinlinux2_6.html
[22:02:50] <mmu_man> still have a local patch here
[22:03:24] <mmu_man> still need to check a haiku build but current nightlies are unstable
[22:03:48] <jenk> do you guys mind if i bug you with random x86 questions or should i go somewhere else
[22:04:21] <mmu_man> jenk you might find better answers on #osdev maybe
[22:04:53] <jenk> thx
[22:23:21] <CIA-11> ffmpeg: mru * r24953 /trunk/configure:
[22:23:21] <CIA-11> ffmpeg: configure: move config.fate creation after OS section
[22:23:21] <CIA-11> ffmpeg: The OS label can be changed, and we want this to be reflected.
[22:59:30] * peloverde can't wait for git, it will be so much easier to not deal with these messes
[22:59:54] <restrex> hi guys... I found this patch http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-October/077506.html will it make ffmpeg create cbr mpeg-2 transport streams? which version of ffmpeg should i download to apply it? thanks
[23:00:28] <peloverde> "--- libavformat/mpegtsenc.c	(revision 20231)" may be a clue
[23:00:46] <mru> kinda old...
[23:01:13] <restrex> i know, but how do I get it?
[23:01:21] <restrex> svn?
[23:01:34] <restrex> or are there tarballs for that revision?
[23:02:49] <restrex> like svn co -r 20231 svn://svn.mplayerhq.hu/ffmpeg/trunk ?
[23:03:24] <restrex> ok, it's going through thanks
[23:07:05] <peloverde> do builds that don't use x87 need emms at all?
[23:10:09] <astrange> yes, the client might use it
[23:10:44] <peloverde> suppose the cpu doesn't have x87 support?
[23:11:16] <peloverde> x87 was originally optional, could it be remove again some day
[23:11:29] <astrange> nothing in x86 can ever be removed (except 3dnow)
[23:11:44] <astrange> but if x87 doesn't exist then emms is unnecessary, yes
[23:13:25] <peloverde> why not?
[23:13:33] <peloverde> you just said s3now can be removed
[23:13:36] <peloverde> *3dnow
[23:13:37] <astrange> windows apps will break
[23:13:42] <peloverde> so what
[23:13:57] <peloverde> those apps were told they should runtime detect these features
[23:14:26] <astrange> if it doesn't run windows xp, it's just as good as another ISA and might get replaced by one
[23:14:40] <peloverde> and why is 3dnow an exception to those
[23:15:15] <peloverde> I use plenty of apps that don't run on windows xp, doesn't make my cpu any less useful
[23:15:23] <Dark_Shikari> why can't 3dnow be removed
[23:15:25] <Dark_Shikari> er, can
[23:15:35] <astrange> 3dnow didn't exist on intel, so there was a real requirement to detect it
[23:15:53] <Dark_Shikari> sse4 doesn't exist on amd... so...
[23:16:07] <astrange> i think the same goes for it
[23:20:02] <peloverde> But there are plenty of CPUs still in use that dont support for instance SSSE3