[FFmpeg-devel] [PATCH] split-radix FFT

Ramiro Polla ramiro
Thu Aug 7 20:57:59 CEST 2008


Hi,

For some reason my original reply didn't get through, so I'm trying again.

  wrote:
> Loren Merritt <lorenm at u.washington.edu> writes:
> 
>> On Tue, 5 Aug 2008, M?ns Rullg?rd wrote:
>>> Loren Merritt <lorenm at u.washington.edu> writes:
>>>
>>>> @@ -829,6 +838,7 @@ mmx2_deps="x86 mmx"
>>>>  neon_deps="armv4l"
>>>>  ssse3_deps="x86"
>>>>  vis_deps="sparc"
>>>> +yasm_deps="x86 mmx"
>>> What is the purpose of this?  Yasm is only used on x86, and it could
>>> be used for non-mmx code.  (Side-note: should we separate mmx/sse/sse2?)
>>> Either way, that line is in the wrong place; yasm is not a CPU feature.
>> I added that because I replaced a HAVE_MMX with a HAVE_YASM, but I
>> guess it's not needed.
> 
> Yes, since SIMD support is detected at runtime, it is enough check
> whether the code will build.
> 
>>> What is the correct value for objformat on win64?
>> "win64"
>>
>> Hmm, specifying arch separately is an alternative to including bitness
>> in the objformat, so I can simplify the case too.
>>
>>>> @@ -1534,6 +1551,25 @@ EOF
>>>>      enabled mmx2  && check_asm mmx2  '"movss %xmm0, %xmm0"'
>>>>
>>>>      check_asm bswap '"bswap %%eax" ::: "%eax"'
>>>> +
>>>> +    enable yasm
>>>> +    if enabled x86_64; then
>>>> +        YASMFLAGS="-DARCH_X86_64"
>>>> +        enabled shared && append YASMFLAGS "-DPIC"
>>>> +        case "$objformat" in
>>>> +            elf) objformat="elf64";;
>>>> +            macho) objformat="macho64";;
>>>> +            win32) disable yasm;;
>>> As I said, we shouldn't break win64 (even if I don't care personally).
>> With this line, nothing breaks, only a speed regression in mdct
> 
> I call that a form of breakage.
> 
>> codecs. Without this line, it would break until someone ports the
>> calling convention macros.
> 
> Ramiro apparently has a win64 system.  Maybe he can help.

I don't have one myself. I could ask NightStrike to VNC into his system
to make some tests. I just have to know what exactly I need to test. But
I'm quite busy (and there's GSoC too), so this is not high on my priorities.

>> OK, I'll try. Here's a completely untested attempt at win64.
>> I have intentionally omitted the complex stack frame mandated by the
>> win64 abi. I'm not entirely sure what effect this omission has, but
>> Squid_80 tells me that all it should do is confuse the exception
>> handler in the event of a crash.
> 
> Why, oh why, do they always make things so complicated in windows?
> 
>>> Hmm, maybe YASMFLAGS="-DARCH_$(toupper $arch) -f $objformat"
>> done
>>
>>>> +    check_yasm "pabsw xmm0, xmm0" || disable yasm
>>> Come to think of it, isn't enough to check_cmd yasm --version?  Either
>>> it's there, or it's not.
>> Either it's there, or it's not, or it's an obsolete version. I don't
>> want more variants of HAVE_SSSE3 than necessary. And if not ssse3, I'd
>> still have to check if it's too old to support x86_64.
> 
> Good point.  Keep the check.  I don't know which instructions belong
> to which category of mmx, mmx2 mmxext, sse, sse2, sse3, ssse3, sse4,
> sse4.5, ssssse5, etc. (and I have no intention of learning it), so it
> wasn't obvious to me what was being tested.
> 
>> @@ -1534,6 +1550,15 @@ EOF
>>      enabled mmx2  && check_asm mmx2  '"movss %xmm0, %xmm0"'
>>
>>      check_asm bswap '"bswap %%eax" ::: "%eax"'
>> +
>> +    YASMFLAGS="-f $objformat -DARCH_$(toupper $arch)"
>> +    enabled x86_64 && append YASMFLAGS "-m amd64"
>> +    enabled_all x86_64 shared && append YASMFLAGS "-DPIC"
>> +    case "$objformat" in
>> +        elf*) enabled debug && append YASMFLAGS "-g dwarf2";;
>> +        *) append YASMFLAGS "-DPREFIX";;
>> +    esac
> 
> This bit could use be written a bit prettier.  I'm thinking something
> like this:
> 
>     enabled     x86_64        && append YASMFLAGS "-m amd64"
>     enabled_all x86_64 shared && append YASMFLAGS "-DPIC"
>     case "$objformat" in
>         elf*) enabled debug && append YASMFLAGS "-g dwarf2" ;;
>         *)                     append YASMFLAGS "-DPREFIX"  ;;
>     esac
> 
> The rest is OK.
> 
> If nobody steps up to test this on win64, I suggest we simply check it
> in, and deal with any bugreports that might result.

I'm fine with this too.

Ramiro Polla





More information about the ffmpeg-devel mailing list