On Thu, Aug 09, 2012 at 08:23:10PM -0700, Ronald S. Bultje wrote: > 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.
There's a simple solution if you are so afraid of conflicts, albeit they are unlikely to happen and be trivial to fix. I can just add %define cpuflags_mmxext cpuflags_mmx2 to the top of x86inc.asm. Problem solved. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
