Hi, On Thu, Aug 9, 2012 at 4:49 PM, Diego Biurrun <[email protected]> wrote: > On Sun, Aug 05, 2012 at 07:20:40AM -0700, Ronald S. Bultje wrote: >> 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?). > > Look at where in x86inc.asm the string mmx2/mmxext appears. Merge > conflicts are very unlikely and trivial to fix. > >> 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. > > So it's a stalemate?
OMG you're actually going to argue over something silly like this? Please. I'm the one who has to fix these issues, and they have happened a lot over the past year or two. I'm asking you to not do this. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
