On 07/30/2012 09:52 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Jul 30, 2012 at 2:41 AM, Måns Rullgård <m...@mansr.com> wrote:
>> "Ronald S. Bultje" <rsbul...@gmail.com> writes:
>>> On Thu, Jul 26, 2012 at 4:52 PM, Ronald S. Bultje <rsbul...@gmail.com>
>>> wrote:
>>>> On Thu, Jul 26, 2012 at 3:54 PM, Diego Biurrun <di...@biurrun.de> wrote:
>>>>> On Thu, Jul 26, 2012 at 03:42:24PM -0700, Ronald S. Bultje wrote:
>>>>>> On Thu, Jul 26, 2012 at 2:39 PM, Diego Biurrun <di...@biurrun.de> wrote:
>>>>>>> On Thu, Jul 26, 2012 at 01:50:17PM -0700, Ronald S. Bultje wrote:
>>>>>>>>
>>>>>>>> discussion thread. We currently use HAVE_SSSE3 and related macros to
>>>>>>>> indicate that we want to compile these and that our compiler tools are
>>>>>>>> good enough to know what to do with it. As a result, we currently use
>>>>>>>> HAVE_AVX around all avx code (yasm only - we don't have any avx inline
>>>>>>>> asm), HAVE_SSSE3 around some yasm and all inline asm code that uses
>>>>>>>> ssse3 instructions, and sometimes HAVE_SSE/2 around inline asm using
>>>>>>>> xmm regs. There is no HAVE_SSE4. HAVE_MMX2 is almost never used but
>>>>>>>> does exist.
>>>>>>>
>>>>>>> Do we need HAVE_SSE4? It should be easy enough to add.
>>>>>>>
>>>>>>>> HAVE_MMX is something entirely different and is used as an
>>>>>>>> alternative form of ARCH_X86.
>>>>>>>
>>>>>>> No, HAVE_MMX is just that. True, it's abused in some places where
>>>>>>> ARCH_X86 would be better (when invoking init functions), but that
>>>>>>> is an issue that needs to be addressed at some point.
>>>>>>>
>>>>>>>> In addition to that, we're using inline asm checks to test whether to
>>>>>>>> enable HAVE_SSSE3 and HAVE_SSE2 (line 2850 of configure).
>>>>>>>>
>>>>>>>> Can we split these macros in something for yasm vs something for
>>>>>>>> inline asm? This means e.g. that we can use ssse3 if yasm (but not
>>>>>>>> inline asm) supports it, if inline asm is lacking, etc.
>>>>>>>
>>>>>>> What is your goal? Do you want to write something like
>>>>>>>
>>>>>>> #if HAVE_INLINE_SSSE3
>>>>>>>
>>>>>>> instead of
>>>>>>>
>>>>>>> #if HAVE_SSSE3 && HAVE_INLINE_ASM
>>>>>>>
>>>>>>> ?
>>>>>>
>>>>>> Right now, in practice:
>>>>>>
>>>>>> HAVE_SSSE3 means "we support inline ssse3"
>>>>>> HAVE_SSE2 means "we support inline sse2"
>>>>>> HAVE_AVX means "we support yasm avx" but depends on HAVE_SSSE3
>>>>>>
>>>>>> I wonder whether it makes sense to have a "generic" HAVE_SSSE3 anyway
>>>>>> - when would we use it, what would it mean? I think in practice, we
>>>>>> probably want a HAVE_INLINE_SSSE3, as you said, because yes, there's
>>>>>> compilers that don't support this, but do support HAVE_INLINE_ASM in
>>>>>> general. Likewise, HAVE_AVX could be renamed HAVE_YASM_AVX or so.
>>>>>> Having HAVE_YASM_SSSE3 seems pointless, I don't think we support any
>>>>>> yasm/nasm version that doesn't understand ssse3, so it'd always be 1.
>>>>>> However, this would make it clear that HAVE_SSSE3 and HAVE_AVX don't
>>>>>> and shouldn't depend on each other.
>>>>>
>>>>> Try dropping the line
>>>>>
>>>>> avx_deps="ssse3"
>>>>>
>>>>> from configure and see if that works out the way you want it to.
>>>>
>>>> I'm still wondering if it makes sense to change the names to reflect
>>>> what they do, to prevent more misunderstandings.
>>>>
>>>> Plus, someone (i.e. me) needs to go over all our x86 simd function
>>>> pointer inits and make sure we use HAVE_INLINE_SSSE3 only for inline,
>>>> not yasm. Also, HAVE_SSE2, HAVE_SSE, HAVE_MMX2, HAVE_MMX need such
>>>> rules (are they inline? yasm? both?) and the same check in init
>>>> functions.
>>>
>>> I hear no further opinions, so I suppose nobody minds if I replace
>>> HAVE_MMX2/SSE/SSSE3 with HAVE_INLINE_*, HAVE_AVX/FMA4 with HAVE_YASM_*
>>> and remove the dependency of avx on ssse3?
>>
>> I'm not at all convinced this is what we really want. Instead of trying
>> to change one part of the mess to match another part at random, we
>> should figure out what semantics we really want from these options, then
>> change everything to match that. It may be a little more effort, but it
>> will be worth it.
>
> Maybe somebody should open a RFC thread to figure out what it is that
> we want - oh wait.
>
> So in other words, can you be more forthcoming about what it is that
> we want? I've given my opinion here a few times now. A RFC cannot be a
> one-way street.
I think we have several things to address:
1) detecting feature support in older compilers
- we should validate (independent of our existing code) that these
are the only features we need to detect and support for inline asm
and for yasm/nasm
2) the user wants to disable building of some cpu feature
- e.g. --disable-amd3dnow and --disable-amd3dnowext
- do we need to support this?
3) the user wants to disable building of all asm optimizations
- to get this to work properly, I think we would have to make sure
we're not abusing HAVE_MMX when we really mean HAVE_ARCH_X86
-Justin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
