Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 778035

Summary: media-video/ffmpeg: allow use of sse3 without sse2 as sse3 is an extension of sse2
Product: Gentoo Linux Reporter: Igor Franchuk <lanthruster>
Component: Current packagesAssignee: Gentoo Media-video project <media-video>
Status: UNCONFIRMED ---    
Severity: normal    
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description Igor Franchuk 2021-03-24 22:44:09 UTC
ffmpeg ebuilds would fail if CPU_FLAGS_X86 omits sse2 like

CPU_FLAGS_X86="mmx mmxext sse sse3"

with  
The following REQUIRED_USE flag constraints are unsatisfied:
cpu_flags_x86_sse3? ( cpu_flags_x86_sse2 )

which looks wrong because sse3 implies sse2 sse support so it should be something like CPU_FLAGS_X86="mmxext sse3" be enough to compile ffmpeg (correct me if I'm wrong) 

sse3 -> implies (sse2,sse) support (extends sse2)
sse2 -> implies (sse) support (extends sse)

mmxe -> implies (mmx) support (extends mmx)

sse3,sse2, sse co-exists with mmx and mmx3 which are different instruction sets


why then this logic:

	cpu_flags_x86_sse3?  ( cpu_flags_x86_sse2 )
	cpu_flags_x86_sse2?  ( cpu_flags_x86_sse )
	cpu_flags_x86_sse?  ( cpu_flags_x86_mmxext )



Reproducible: Always
Comment 1 Igor Franchuk 2021-03-24 23:02:07 UTC
I meant sse3,sse2, sse co-exists with mmx and mmxext

question: is it possible at all to support sse3 without supporting sse2 and sse? 

sse3 = sse2 + extended instructions
sse2 = sse + extended instructions 

mmxext = mmx + extended instructions 

it's not like sse2 is just extended instructions for sse2 it consists of both 

https://www.intel.com/content/www/us/en/support/articles/000005779/processors.html
Comment 2 Niklāvs Koļesņikovs 2021-03-26 09:12:49 UTC
And avx2 implies the CPU has not only sse3 but also ssse3 and aes and almost certainly also sse4_2. By extending the logic of this bug report, the user needs but specify the highest one. Does this have an actual use case?

It's also worth reminding that the Gentoo recommendation is to set all supported CPU_FLAGS_* as reported by cpuid2cpuflags with the sensible exception being removing ones that either user does not want (e.g. the so called power-virus) or ones that are supported by the host system but may cause trouble with systems to which the built binaries may be distributed to. Speaking of that, FFmpeg has cpudetection that is very handy for that. ;)

Finally, not all ebuilds have sse3 (a rather rare instruction set to see in the wild), so sse2 should be generally set anyway.
Comment 3 Igor Franchuk 2021-03-26 12:47:27 UTC
(In reply to Niklāvs Koļesņikovs from comment #2)
> And avx2 implies the CPU has not only sse3 but also ssse3 and aes and almost
> certainly also sse4_2. 

Yes and it looks like the cpu_flags should only have avx2 in that case

CPU_FLAGS_X86 = 'avx2' 

A portage function like cpu_flags('avx2') could return the full list like 'avx2 sse2, sse, etc). I suggest to transform the CPU_FLAGS_X86 via 

CPU_FLAGS_X86 = cpu_flags(CPU_FLAGS_X86) 

first and then the backward compatibility is met. (uniqueness of fags would be 
provided by cpu_flags function)


> By extending the logic of this bug report, the user
> needs but specify the highest one. Does this have an actual use case?

 I've personally seen a few libs in the portage that won't build with both sse2 and sse3 flags set. As to how often that problem occurs - try googling for: "The following REQUIRED_USE flag constraints are unsatisfied: cpu_flags_x86_sse3? ( cpu_flags_x86_sse2 )"

> It's also worth reminding that the Gentoo recommendation is to set all
> supported CPU_FLAGS_* as reported by cpuid2cpuflags with the sensible
> exception being removing ones that either user does not want (e.g. the so
> called power-virus) or ones that are supported by the host system but may
> cause trouble with systems to which the built binaries may be distributed
> to. Speaking of that, FFmpeg has cpudetection that is very handy for that. ;)
> 
> Finally, not all ebuilds have sse3 (a rather rare instruction set to see in
> the wild), so sse2 should be generally set anyway.

Transforming CPU_FLAGS from make.conf via cpu_flags function before using them should fix the problem like forever. That would give control over the flags to the portage. Less probability for a user to set them wrong. All so that would give an early diagnosis to the wrong set of flags set by a user.

The user would from that moment only have to set for example 

CPU_FLAGS_X86="mmxext sse3"

portage would expands that to CPU_FLAGS_X86="mmx mmxext sse sse3 sse3" via cpu_flags functions, the backward compatibility is met for the ebuilds. No logic problems with choosing CPU_FLAGS_X86 from the user side. 

Still if a user prefers to set CPU_FLAGS_X86="mmx mmxext sse sse3 sse3" he can do it, cpu_flags would just return the same "mmx mmxext sse sse3 sse3" in that case and go on. 

CPU_FLAGS_X86="sse2" would be transformed by cpu_flags to CPU_FLAGS_X86="sse sse2" 

I can't think of any case when this wouldn't work. Portage will take care of sse flags, a cool feature.