Andrew Lutomirski wrote: > Features like SSE2: enabling SSE2 as the basic floating point mechanism > changes the ABI drastically. But x86_64 already requires SSE2, so this is > irrelevant. For what it's worth, only the x86_64 ABI actually makes use of this. For i686 (32-bit), even when Fedora moved to requiring SSE2, the ABI was not changed (because that would have meant bootstrapping a whole new architecture, breaking compatibility with all existing binaries in the process). So i686 is stuck with the x87 ABI, copying floating-point data back and forth between x87 and SSE registers. > Things like SSSE3, SSE3, SSE4, AVX1, AVX2, FMA, etc: for the most part, > these accelerate existing algorithms. I'm sure that someone somewhere has > written an algorithm that requires FMA for enhanced precision, but > otherwise pretty much any code that benefits from any of these features > would work just fine, if slower, without the features. FMA can also be emulated in pure software (while still using hardware floating-point instructions!), it is even implemented in glibc. So this also falls under "would work just fine, if slower, without the features". > but FSGSBASE is not a credible requirement for Fedora since IIRC it's not > supported on Sandy Bridge. Even Intel seems to consider Sandy Bridge to > be an important CPU to support. AVX2 is also not supported on Sandy Bridge. > I think that, for vector extensions, Fedora shouldn't require anything > beyond SSE2 for basic functionality. Instead, Fedora should figure out > where there are material benefits to using them and find ways to make it > easier for packagers to make them available. Ideally this would all be > figured out at runtime, I agree. > but install-time choices could make sense, too. I think we should just do it right and figure it out at runtime. Otherwise, the user ends up having to manually install things such as those infamous atlas-sse* subpackages, and most users will not bother doing that, or even not even know that they exist or at least which one to pick. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx