Announcement

Collapse
No announcement yet.

Mesa 17.3.6 Released To Fix Intel GPU Hangs

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

  • Mesa 17.3.6 Released To Fix Intel GPU Hangs

    Phoronix: Mesa 17.3.6 Released To Fix Intel GPU Hangs

    It's been just one week since the Mesa 17.3.5 debut while today it's been succeeded by v17.3.6 as what's being advertised as an emergency release...

    http://www.phoronix.com/scan.php?pag...7.3.6-Released

  • #2
    Mesa 18.0 meanwhile should be released in the days ahead as this quarterly release has been running behind schedule...
    Did they have stright schedule really? As i see for 2017. releases happened in february, may, september, december.

    Sounds more expected something like march, june, september, december... either 3, 6, 9, 12 or 2, 5, 8, 11, but they did 2, 5, 9, 12

    That somewhat goes in line with llvm, so 3 and 6 to compile against first release of llvm, but 9 and 12 against second release of a year

    4 against 2 boring points

    On kernel side of things upstream have about 5 releases per year, with just 1 or 2 longterm ones
    Last edited by dungeon; 02-27-2018, 12:36 AM.

    Comment


    • #3
      Also maybe to note that both Debian Stable and Ubuntu LTS tend to pick for their release mesa's december release (altough stronk point one)... Debian 9 released with 13.0.6 and Ubuntu will likely be with this 17.3.6...

      These both really operate with one release of kernel and mesa per year and anything else is just development

      Boring stronk 2016., stronk 2017. Or before boring 2015. distro released with boring 2014. mesa get boring 2016. mesa in backports, also boring 2017. distro released with boring 2016. mesa will get boring 2017. backport That sounds quite enough to cover most users.

      Should i note that AMD blob also have one major release per year and that this is also in december... with also 4 points for workstations, even for APUs that is sort of.

      Only gaming consumer cards needs all git and a lot of minor emergency functionality and performance hotfixes as games happen to be release irregulary or these with imperfect particulary new gen hardware launch (where again up to one cycle roll usually fix most of the issues)
      Last edited by dungeon; 02-27-2018, 01:42 AM.

      Comment


      • #4
        if possible, do not use point release Mesa. It is partially implemented and buggy most of the time. Freedesktop.org should provide a rolling release Mesa only. Maybe then all distributions would have Mesa dev git repository. What I hate in Debian is point released old and buggy software. To get bug fixes fast, you need to compile latest version of your favourite software. Oibaf does excellent job with his Mesa ppa. Distribution maintainers should work like Oibaf does.

        Comment


        • #5
          Originally posted by debianxfce View Post
          if possible, do not use point release Mesa.
          That is what most will use, also release/longterm kernels

          It is partially implemented and buggy most of the time.
          Well It shouldn't be, as that is where most of users are

          Freedesktop.org should provide a rolling release Mesa only.
          They provide it, just build it and you will have it. Rolling release model as even name of it is self explainotory - is about rolling version releases, it is about releases and not about random development trunk of whatever

          Maybe then all distributions would have Mesa dev git repository.
          That is not needed majorly, as developers already build mesa and testers should too.

          What I hate in Debian is point released old and buggy software.
          It is neither old nor buggy, but might not be so new enough to serve you with Debian releases If you prefer new and buggy like rolling, use Sid and build whatever you want trunk current random from git of non-point . Otherwise testing once frozen if you wanna test next-stable. Stable have only utter stronk mesa release yearly option.

          To get bug fixes fast, you need to compile latest version of your favourite software.
          Of course you or someone else need to compile it for you as favorite version of software xyz likely vary among different users... what else versions you want of 50K+ binary packages for 10+ architectures?

          Oibaf does excellent job with his Mesa ppa. Distribution maintainers should work like Oibaf does.
          Fabio in the mirror repo rolls fine on average for probably bellow one percent Ubuntu users for which stock or HWE releases might not be enough. That repo is not really for Debian users, as even there might be some high compatibility among these that is certainly not quite there all the time, but also not entirely roll properly as for example llvm is old there Even if you are not developer, you should be able to be ready to bisect things fast in case of regressions and that only slows you down anyway

          I only understand someone who is developer or tester to want things to git roll couple times daily, but about users in general? Quite certainly - nope. Users majorly and only might wanna roll drivers couple months maybe up to one year if they bought particulary new hardware but drivers are not in place or in not so good shape yet.
          Last edited by dungeon; 02-27-2018, 08:02 AM.

          Comment


          • #6
            Originally posted by debianxfce View Post
            if possible, do not use point release Mesa. It is partially implemented and buggy most of the time. Freedesktop.org should provide a rolling release Mesa only. Maybe then all distributions would have Mesa dev git repository. What I hate in Debian is point released old and buggy software. To get bug fixes fast, you need to compile latest version of your favourite software. Oibaf does excellent job with his Mesa ppa. Distribution maintainers should work like Oibaf does.
            No. Release versions are reference points. Apart from being very important in terms of support, they create the right amount of pressure for people to be responsible for having things in order in time.

            Comment


            • #7
              Originally posted by debianxfce View Post
              if possible, do not use point release Mesa. It is partially implemented and buggy most of the time. Freedesktop.org should provide a rolling release Mesa only. Maybe then all distributions would have Mesa dev git repository. What I hate in Debian is point released old and buggy software. To get bug fixes fast, you need to compile latest version of your favourite software. Oibaf does excellent job with his Mesa ppa. Distribution maintainers should work like Oibaf does.
              Debian already updated Mesa to 17.3.6.

              Comment


              • #8
                Originally posted by dungeon View Post

                Did they have stright schedule really? As i see for 2017. releases happened in february, may, september, december.

                Sounds more expected something like march, june, september, december... either 3, 6, 9, 12 or 2, 5, 8, 11, but they did 2, 5, 9, 12
                Mesa stable branchpoints are made on a regular schedule. The releases are not made until there are no regressions in the release candidates. This process is tracked in TRACKER bugs eg:
                https://bugs.freedesktop.org/show_bug.cgi?id=104757

                Resolving regressions is not a time-bounded activity. Some bugs are harder than others. Often, developers have time critical tasks (eg OpenGL/Vulkan conformance) and can't work on stable regressions right away.

                Comment


                • #9
                  dungeon, why do you use so many emoticons lol

                  Comment


                  • #10
                    Originally posted by zoomblab View Post

                    No. Release versions are reference points. Apart from being very important in terms of support, they create the right amount of pressure for people to be responsible for having things in order in time.
                    Release versions are branches where Mesa developers have done their best to guarantee that there are no unfixed regressions vs the previous release. For this reason, they are more reliable for distros to use. When a regression IS discovered that exists in an active stable branch, developers backport the fix.

                    So, it's more than a simple reference point. However, there is no deadline for developers to implement a feature for a stable release. Developers are motivated to get their work to the end users, so they will try to finish features in time for a release branch. The "pressure" to do this is coming from the developers themselves, not a release manager or product manager.

                    Comment

                    Working...
                    X