[FFmpeg-devel] [PATCH] Fix configure to disable MMX for Pentium Pro
Thu Aug 26 19:06:50 CEST 2010
On Thu, Aug 26, 2010 at 10:59 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> On Thursday, 26 August 2010 at 16:48, Jason Garrett-Glaser wrote:
>> 2010/8/26 M?ns Rullg?rd <mans at mansr.com>:
>> > "Ronald S. Bultje" <rsbultje at gmail.com> writes:
>> >> Hi,
>> >> On Thu, Aug 26, 2010 at 9:34 AM, Alex Converse <alex.converse at gmail.com> wrote:
>> >>> ./configure --cpu=prentiumpro says build me an FFmpeg for a
>> >>> PentiumPro. The result will no longer run on a PentiumPro.
>> >> A) It should require --disable-mmx (and thus the configure patch to
>> >> disable mmx should be changed to error out unless mmx is disabled),
>> > That's a stupid idea. ?Specifying a CPU without MMX should of course
>> > disable MMX. ?That stands to reason. ?It is also how all the other
>> > architectures work.
>> >> B) we should revert the mmx-requiring commit and only do unconditional
>> >> emms on x86-64 (I think this is acceptable. Mans?).
>> > The main point of the change was to get rid of the stupid global
>> > mm_flags variable. ?We discussed it at length some time ago (it nearly
>> > went full bikeshed), and nobody objected then, not even the distro people.
>> > Why the sudden outrage?
>> Whether we like it or not, a huge number of people compile ffmpeg with
>> --cpu=i686 or similar for generic builds. ?With these changes,
>> --cpu=i686 will actually SLOW DOWN ffmpeg as opposed to not specifying
>> CPU at all. ?This is not intuitive behavior.
> Not in my opinion. Do you expect gcc -march=i686 to generate code
> that won't run on a Pentium Pro? No. If you want MMX/SSE/whatever,
> you add -mmmx/-msse/whatever, and then you know that it won't,
> because you specified it. Perfectly intuitive, if you ask me.
> Just my two cents.
I don't care what is intuitive. I don't care what is right. What I
care about is that behavior is CHANGING, silently, and it *WILL*
silently break for millions of people, and you have absolutely no plan
to deal with that. "Fuck the users" is not a plan.
More information about the ffmpeg-devel