Hi, On Sun, Aug 5, 2012 at 2:44 AM, Diego Biurrun <[email protected]> wrote: > On Sat, Aug 04, 2012 at 06:19:38PM -0700, Ronald S. Bultje wrote: >> On Sat, Aug 4, 2012 at 2:28 PM, Loren Merritt <[email protected]> >> wrote: >> > On Sat, 4 Aug 2012, Diego Biurrun wrote: >> >> On Sat, Aug 04, 2012 at 03:11:50PM -0400, Justin Ruggles wrote: >> >>> On 07/31/2012 06:17 PM, Diego Biurrun wrote: >> >>>> --- >> >>>> 30 files changed, 215 insertions(+), 211 deletions(-) >> >>> >> >>> Looks ok, but probably should get other opinions on this as well. I know >> >>> Ronald was trying to keep x86inc.asm sychronized with x264, and trying >> >>> to do so after this change would likely require similar extensive >> >>> cpuflag modifications in x264. >> >> >> >> I volunteer to patch x264 if such a change would be accepted on their >> >> side. >> > >> > Rejected. I like "mmx2" better. >> > However, I wouldn't be opposed to dropping mmx1 entirely and using >> > the name "mmx" to refer to mmx2. (x264 doesn't actually support mmx1 >> > anyway; we use mmx2 inline asm that's actually inlined in places where >> > runtime cpu detection is impossible.) But that wouldn't help >> > synchronization if libav doesn't do so. >> >> Right - from my PoV, keeping us in sync with x264 is more important >> that having a slightly more accurate cpuflag for something that's >> never exposed to end users in any way. > > It is exposed through configure. > >> Diego, have ideas on how to fix this, > > Yes, why don't you convince Loren that mmxext is the more sensible name? > >> or can you live with changing everything to MMX2 instead? > > I believe mmxext is the better name and everybody except Loren seems > to agree. There are very few uses of mmx2/mmxext in x86inc.asm and > they are unlikely to ever conflict with future changes to this file. > Besides, we only sync a few times per year. > > So I'm unconvinced that using mmx2 would be a net benefit. I still > hope that Loren can change his mind, as I said, I volunteer to do > all the work.
x86inc.asm is a x264 file that we sync, I'd like to keep it that way, especially given that I'm the guy who historically had to deal with the outfalls every time a sync doesn't work right (remember INIT_MMX not backing up XMM regs anymore on Win64? Remember the register reordering on Win64 recently?). Plus, I didn't say it was a good idea, I said I could live with it if others want it. Right now, it seems others (i.e. Loren) don't. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
