Announcement

Collapse
No announcement yet.

Fedora Developers Discuss Raising Base Requirement To AVX2 CPU Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Michael
    Advanced Vector Extensions 2 is Intel Sandy Bridge and newer or AMD Jaguar/Bulldozer and newer.
    Isn't that for AVX and not AVX2?

    As for the change itself, it seems too much. Dropping CPUs from before 2013 is too bold.

    Comment


    • #22
      Originally posted by fguerraz View Post

      Which will work still find with distributions of the era you bought them.
      which will stop receiving security updates or updates in general pretty soon. how is that a solution?

      Comment


      • #23
        Originally posted by yoshi314 View Post

        which will stop receiving security updates or updates in general pretty soon. how is that a solution?
        I agree. I was about to write this but you did it earlier. Thanks.

        Comment


        • #24
          What are the expected benefits?

          Comment


          • #25
            The idea to require avx2 is completely insane (try again in another 10 years or so maybe...). Requiring fma is just as terrible (it's a separate feature, but afaik there's no cpu which implements one but not the other, and in any case fma definitely requires avx).
            Now, requiring cmpxchg16b might be reasonable - this is what caused some trouble with windows 8.1 64bit, since 8.0 didn't require it and so on some cpus, namely older athlon 64 X2, it couldn't be upgraded to 8.1, but that's quite old hw...
            But apart from cmpxchg16b I'm not sure you could really update the sse2 requirement.
            SSE3 might be ok (even later P4 and A64 X2 support it, so in practical terms might be similar to chmpxchg16b support). The problem is, it's a pretty small extension and I have some doubts requiring it as baseline really makes much of a performance difference.
            SSSE3 could possibly be ok too, although dropping everything pre-Bulldozer on the AMD side (and dropping everything pre-Core 2 from intel).
            SSE4.1 would probably be quite controversial - I think on the AMD side it's the same as SSSE3, but on the intel side it's disabled on all (?) celeron/pentiums which natively can't do AVX (so, celerons / pentiums from the pre-Sandy Bridge timeframe, and atom cores pre-silvermont).
            Requiring even "only" AVX is downright crazy imho and I bet it's not gonna happen.

            Comment


            • #26
              Originally posted by finalzone View Post
              Users willing to continue supporting AVX2 less hardware can step up and work on that effort in accordance of free and open source and Fedora philosophies. The crucial part is maintenance which is one of major weaknesses.
              As I have no AVX2 hardware I would leave Fedora/rpmfusion altogether and switch to another distro, I reckon Fedora could lose up to 50% of it's devs and users.

              Comment


              • #27
                This was really half-assed proposal. It suggests that people should grep for avx2 based on release notes before upgrading. While I think that people should read release notes and if they don't they and run into avoidable problems they can only blame themselves buv this is not the place to put that information and also the check must be automatic.

                That said I think the people actually deciding this are not even considering this. The person that made the proposal (YMMW) put Fedora developers in bad light so let's just drop this. I'm pretty sure that they will not go forward with this.

                Comment


                • #28
                  Originally posted by fguerraz View Post

                  Which will work still find with distributions of the era you bought them.
                  Oh come on, hardware and software don't come bundled, there is no reason for it to. Do you really want to continue using old releases with the bugs and security holes that come with it?
                  I myself am using an 11 year old Q9300 based desktop and guess what? It still is enough for most of today's computing needs. Even for development.

                  As for AVX: I'd like to mention that the low power J5005 (Gemini Lake, released Dec 2017) doesn't have this instruction set. I'd say it is pretty idiotic to stop supporting this pretty new piece of hw.

                  Comment


                  • #29
                    Originally posted by Xaero_Vincent View Post
                    Considering that there is still hardware being produced in 2019 like Penitum Gold CPUs that lack support for AVX2 instruction set, this is a terrible idea. Worse than dropping 32-bit app support if you ask me because at least there are workarounds to that.
                    Came to say just that. Pentium Gold and Celeron CPUs 14nm Whiskey Lake (2018/Q2 onward) processors lack AVX2 support. In the previous generations all Celeron and Pentium CPUs lacked AVX2. There still isn't any news regarding Ice Lake but it's safe to assume Intel will continue to segment around AVX2.

                    Originally posted by Xaero_Vincent View Post
                    What's up with distro developers and their ridiculous and radically ambitious design ideas lately? These developers ought to sit the f*** down and relax and stop trying to behave like Apple.
                    I don't know about that. Intel isn't even releasing certain speculative execution fixes to most CPUs older than Coffee Lake (2018/10) so from a security standpoint we're talking about defective hardware that is only a browser bug away from getting pwned.

                    Besides, not every distro needs to cater to low-end, older machines. There's plenty of fish in the sea.

                    Comment


                    • #30
                      So whats the benefit outside of Games, HPC and possibly video encoding? Why not only compile those AVX2-only, I doubt most system libraries will care.
                      On the other hand, chipping away at x86 overboarding redundant crap is somewhat nice, but I would prefer just accelerating ARM/Risc-V replacements to get rid of the whole crap once and for all.

                      Comment

                      Working...
                      X