[FFmpeg-devel] [PATCH] vp9: change order of operations in adapt_prob().

[James Zern]

On Fri, Oct 14, 2016 at 11:54 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi Michael,
>
> On Fri, Oct 14, 2016 at 2:31 PM, Michael Niedermayer <michael at niedermayer.cc
>> wrote:
>
>> On Fri, Oct 14, 2016 at 08:29:37PM +0200, Michael Niedermayer wrote:
>> > On Fri, Oct 14, 2016 at 11:09:30AM -0700, James Zern wrote:
>> > > Ronald,
>> > >
>> > > On Fri, Oct 14, 2016 at 10:01 AM, Ronald S. Bultje <rsbultje at gmail.com>
>> wrote:
>> > > > This is intended to workaround bug "665 Integer Divide Instruction
>> May
>> > > > Cause Unpredictable Behavior" on some early AMD CPUs, which causes a
>> > > > div-by-zero in this codepath, such as reported in Mozilla bug
>> #1293996.
>> > > >
>> > > > Note that this isn't guaranteed to fix the bug, since a compiler is
>> free
>> > > > to reorder instructions that don't depend on each other. However, it
>> > > > appears to fix the bug in Firefox, and a similar patch was applied to
>> > > > libvpx also (see Chrome bug #599899).
>> > > >
>> > >
>> > > I recently made a few additional changes as this regressed in chrome
>> > > [1][2], but just like this change there's no guarantee it won't occur
>> > > again.
>> >
>> > maybe you can use empty "asm volatile(:::"memory")" statments to
>> > prevent unwanted instruction reordering by the compiler
>> > never tried something like this so dunno, also it would be specific
>> > to gcc compatible compilers but should not be architecture specific
>>
>> thinking again, why dont you write the function in asm for x86 ?
>> this would take the compiler out of the equation
>
>
> I think the primary reason is that "this seems to work". Don't forget that
> the bug is in the hardware, not in the code, so I don't want to make the
> code needlessly (well... maybe that's debatable) complicated for a problem
> that isn't really ours...
>
> But I guess I'm open to hearing everyone else's opinion on this - if people
> want me to make the workaround more persistent I can work on that.
>

That ended up being my view mostly due to the fact that I didn't have
access to the hardware. Even with assembly there is a
timing/scheduling element, so it may be less fragile, but I think the
bug could still occur.