Announcement

Collapse
No announcement yet.

The Mesa 3D Release Process Is Changing

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

  • The Mesa 3D Release Process Is Changing

    Phoronix: The Mesa 3D Release Process Is Changing

    Ian Romanick of Intel who generally has been serving as the release manager of new Mesa releases, has announced some planned changes for releasing Mesa 3D drivers...

    http://www.phoronix.com/vr.php?view=MTQwMTk

  • #2
    3 month release cadence should be good. And it show that devs do not have all that much Q&A...

    What about "LTS" Mesa versions? Will there be any, or will it be up to distro devs to care&provide such...

    Comment


    • #3
      it'll prob fall into the same cadenance and respect as the kernel and KDE do: you'll get stability improvements up until the new version is released. If distros want to stick to a specific version then they'll have to selectively backport fixes.

      Comment


      • #4
        Great news!
        ## VGA ##
        AMD: X1950XTX, HD3870, HD5870
        Intel: GMA45, HD3000 (Core i5 2500K)

        Comment


        • #5
          Originally posted by przemoli View Post
          3 month release cadence should be good. And it show that devs do not have all that much Q&A...

          What about "LTS" Mesa versions? Will there be any, or will it be up to distro devs to care&provide such...
          I believe it should be up to the distro to provide such. The kernel is handled differently because (I believe) the API and ABI remains constant for LTS, and that would make harder for a distro to backport the fixes themselves, while it benefits the user that doesn't need to recompile the software (for which might not even have the source code). In mesa it should always be constant, since it should be OpenGL compliant (you shouldn't directly target mesa, but OpenGL, and the only specific bits are the ones bound to the use of a specific windowing system, which should be a constant anyway).

          Comment


          • #6
            Originally posted by przemoli View Post
            3 month release cadence should be good. And it show that devs do not have all that much Q&A...

            What about "LTS" Mesa versions? Will there be any, or will it be up to distro devs to care&provide such...
            This sounds uterly stupid and very debian-ish to me. Waiting more for a release is a nice way to actually increase the bug count. Continuous testing AND fixing is the way to go. If you don't want to use a just-released version, use the previous one as it will have some of the bug fixes back ported.

            The idea that software magically becomes bug-free with developer-driven Q&A is really not true. Software becomes bug-free when users test it and report back. Of course devs should try to avoid breaking what is already working by running tests (like piglit), but there is a limit to that!

            Comment


            • #7
              Originally posted by przemoli View Post
              3 month release cadence should be good. And it show that devs do not have all that much Q&A...

              What about "LTS" Mesa versions? Will there be any, or will it be up to distro devs to care&provide such...
              well git mesa breaks for me maybe once a year and that is as bleeding edge as you can be, unlike closed source systems where you pull all the crap together and then start the Q&A process in projects like Mesa its done at commit level hence a smaller Q&A time is needed since the patches were quite well tested before reach upstream[and git allows you to merge branches and keep them up to date with yours, so you can always check your patch works with the latest changes upstream or dependent branches you use]

              another thing mesa is an driver API not an public API, meaning you should never use mesa directly unless you are writing a driver so, you must use Opengl/GL ES/EGL/GLX/etc,

              another fact is that mesa never include major features in point releases, aka mesa 9 is a major release and added support for Opengl 3.1 but mesa 9.1 won't have Opengl 3.2/3.3 because that will come with mesa 10, so mesa 9.1 will only include corner case bugfix or safe performance optimizations that missed the merge window.

              this all apply to every linux distro but official ubuntu since for some reason canonical love to patch mesa downstream[the assumption is unity need them] and break stuff, but if you don't use unity you can replace their version with a clean one from PPA[is not uncommon to break unity when doing so tho]

              anyway this change affect distros like Arch or Gentoo or Sabayon[aka rolling release distros] but it won't affect fixed cycle distros like ubuntu since they freeze the version once they tag the release version, so in ubuntu 14.04 you will see mesa 9.3 and mesa 9.4 in PPA and the in 14.10 you could see mesa 9.5 or 10

              Comment


              • #8
                Originally posted by MPF View Post
                This sounds uterly stupid and very debian-ish to me. Waiting more for a release is a nice way to actually increase the bug count. Continuous testing AND fixing is the way to go. If you don't want to use a just-released version, use the previous one as it will have some of the bug fixes back ported.

                The idea that software magically becomes bug-free with developer-driven Q&A is really not true. Software becomes bug-free when users test it and report back. Of course devs should try to avoid breaking what is already working by running tests (like piglit), but there is a limit to that!
                The idea of LTS is not "developer-driven Q&A", but having a version which is feature freezed, so actually one does not increase the bugs surface. One does not release left often, but tags one release as LTS and keeps backporting fixes only to that, while normal releases keep happening. It's still users finding the bugs.
                Also, betas, release candidates and such are tested by users, only that they are voluntarily hunting bugs.

                Originally posted by jrch2k8 View Post
                another fact is that mesa never include major features in point releases, aka mesa 9 is a major release and added support for Opengl 3.1 but mesa 9.1 won't have Opengl 3.2/3.3 because that will come with mesa 10, so mesa 9.1 will only include corner case bugfix or safe performance optimizations
                Aren't the implemented pieces available as extensions? Or you need to explicitly build it with support for them until the whole new version of OpenGL is complete?

                Comment


                • #9
                  Originally posted by mrugiero View Post
                  Aren't the implemented pieces available as extensions? Or you need to explicitly build it with support for them until the whole new version of OpenGL is complete?
                  you can write all the extensions one by one but as far as I know... OpenGL doesn't broadcast individual extensions (for the most part). It broadcasts versions. AMD can change Catalyst to report that it only supports OpenGL 2.1, despite the fact it supports 4.3 + some. And any app that asks the driver "What do you support" will be told "I support OpenGL 2.1." And therefore use an OpenGL 2 code path, assuming one exists. And it'll stay that way until someone realizes AMD is lying and starts ignoring what it reports and just assumes 4.3

                  Comment


                  • #10
                    Originally posted by Ericg View Post
                    you can write all the extensions one by one but as far as I know... OpenGL doesn't broadcast individual extensions (for the most part). It broadcasts versions. AMD can change Catalyst to report that it only supports OpenGL 2.1, despite the fact it supports 4.3 + some. And any app that asks the driver "What do you support" will be told "I support OpenGL 2.1." And therefore use an OpenGL 2 code path, assuming one exists. And it'll stay that way until someone realizes AMD is lying and starts ignoring what it reports and just assumes 4.3
                    Yes, OpenGL broadcasts extensions. That's one of the key points everyone hated about it versus DirectX, which just guaranteed a certain functionality with a version #, with OpenGL you had all sorts of extensions.

                    It provides versions as well, but that is like a minimum set of guaranteed extensions, and then you can manually query for anything on top of that if you want.

                    Originally posted by mrugiero
                    Aren't the implemented pieces available as extensions? Or you need to explicitly build it with support for them until the whole new version of OpenGL is complete?
                    Generally what you do is take some baseline feature set that you require - such as GL2, or GL3, etc. Then on top of that you do manual querying for any useful extensions you might want to use but that aren't guaranteed by the baseline version. You have to use those optionally, only if the driver provides what you want. Of course, you can ignore that step if baseline GL3 (for example) provides everything you need. It just depends on how much effort you want to go to, and exactly what your code can benefit from that isn't part of the standard versions. Making it worse is that often an extension will be present only on the NVidia or AMD drivers, with the other providing an equivalent that is just different enough to trip you up, so the recommendation is usually to stick with the standard versions as much as possible.

                    So the 9.1 driver absolutely added new extensions and other risky changes that the 9.0 driver didn't. The truly safe changes are provided in the monthly (now supposedly every two weeks) updates - 9.0.1, 9.0.2, etc.
                    Last edited by smitty3268; 07-03-2013, 09:09 PM.

                    Comment


                    • #11
                      Originally posted by smitty3268 View Post
                      Yes, OpenGL broadcasts extensions. That's one of the key points everyone hated about it versus DirectX, which just guaranteed a certain functionality with a version #, with OpenGL you had all sorts of extensions.

                      It provides versions as well, but that is like a minimum set of guaranteed extensions, and then you can manually query for anything on top of that if you want.



                      Generally what you do is take some baseline feature set that you require - such as GL2, or GL3, etc. Then on top of that you do manual querying for any useful extensions you might want to use but that aren't guaranteed by the baseline version. You have to use those optionally, only if the driver provides what you want. Of course, you can ignore that step if baseline GL3 (for example) provides everything you need. It just depends on how much effort you want to go to, and exactly what your code can benefit from that isn't part of the standard versions. Making it worse is that often an extension will be present only on the NVidia or AMD drivers, with the other providing an equivalent that is just different enough to trip you up, so the recommendation is usually to stick with the standard versions as much as possible.

                      So the 9.1 driver absolutely added new extensions and other risky changes that the 9.0 driver didn't. The truly safe changes are provided in the monthly (now supposedly every two weeks) updates - 9.0.1, 9.0.2, etc.
                      well someone from mesa should confirm but i never see or find that a change at opengl level[extension or revision]that made in a point release unless it was available in the major release and fixes a bug/issue. I can be wrong ofc is not like i readed every changelog or commit history from mesa 1.0

                      Comment


                      • #12
                        Clearly someone should have mentioned SIGGRAPH.

                        Comment


                        • #13
                          Originally posted by jrch2k8 View Post
                          well someone from mesa should confirm but i never see or find that a change at opengl level[extension or revision]that made in a point release unless it was available in the major release and fixes a bug/issue. I can be wrong ofc is not like i readed every changelog or commit history from mesa 1.0
                          Then you haven't been looking very hard.

                          Here are the last 5 release notes of non-major releases (no 8.0 or 9.0). As you can see, there are new extensions in each and every one. Some even provide new API's entirely (OpenGL ES support, for example).

                          9.2 release notes (early edition): http://cgit.freedesktop.org/mesa/mes...notes/9.2.html
                          <li>GL_ARB_texture_buffer_range</li>
                          <li>GL_ARB_texture_multisample</li>
                          <li>GL_ARB_texture_storage_multisample</li>
                          <li>GL_ARB_texture_query_lod</li>
                          <li>Enable GL_ARB_texture_storage on radeon, r200, and nouveau</li>
                          <li>Added new freedreno gallium driver</li>
                          <li>OSMesa interface for gallium llvmpipe/softpipe drivers</li>
                          <li>Gallium Heads-Up Display (HUD) feature for performance monitoring</li>
                          9.1 release notes: http://cgit.freedesktop.org/mesa/mes...notes/9.1.html
                          <li>GL_ANGLE_texture_compression_dxt3</li>
                          <li>GL_ANGLE_texture_compression_dxt5</li>
                          <li>GL_ARB_ES3_compatibility</li>
                          <li>GL_ARB_internalformat_query</li>
                          <li>GL_ARB_map_buffer_alignment</li>
                          <li>GL_ARB_shading_language_packing</li>
                          <li>GL_ARB_texture_buffer_object_rgb32</li>
                          <li>GL_ARB_texture_cube_map_array</li>
                          <li>GL_EXT_color_buffer_float</li>
                          <li>GL_OES_depth_texture_cube_map</li>
                          <li>OpenGL 3.1 core profile support on Radeon HD2000 up to HD6000 series </li>
                          <li>Multisample anti-aliasing support on Radeon X1000 series</li>
                          <li>OpenGL ES 3.0 support on Intel HD Graphics 2000, 2500, 3000, and 4000</li>
                          7.9 release notes: http://cgit.freedesktop.org/mesa/mes...notes/7.9.html
                          <li>New, improved GLSL compiler written by Intel.
                          See the <a href="../shading.html"> Shading Language</a> page for
                          more information.
                          <li>New, very experimental Gallium driver for R600-R700 Radeons.
                          <li>Support for AMD Evergreen-based Radeons (HD 5xxx)
                          <li>GL_EXT_timer_query extension (i965 driver and softpipe only)
                          <li>GL_EXT_framebuffer_multisample extension (intel drivers, MAX_SAMPLES = 1)
                          <li>GL_ARB_texture_swizzle extension (alias of GL_EXT_texture_swizzle)
                          <li>GL_ARB_draw_elements_base_vertex, GL_ARB_fragment_program_shadow,
                          GL_ARB_window_pos, GL_EXT_gpu_program_parameters,
                          GL_ATI_texture_env_combine3, GL_MESA_pack_invert, and GL_OES_EGL_image
                          extensions in Gallium drivers
                          <li>GL_ARB_depth_clamp and GL_NV_depth_clamp extensions (in nv50 and r600
                          Gallium drivers)
                          <li>GL_ARB_half_float_vertex extension (in nvfx, r300, r600, softpipe,
                          and llvmpipe Gallium drivers)
                          <li>GL_EXT_draw_buffers2 (in nv50, r600, softpipe, and llvmpipe Gallium
                          drivers)
                          <li>GL_EXT_texture_swizzle (in nvfx, r300, r600, softpipe, and llvmpipe
                          Gallium drivers)
                          <li>GL_ATI_texture_mirror_once (in nvfx, nv50, r300, r600, softpipe, and
                          llvmpipe Gallium drivers)
                          <li>GL_NV_conditional_render (in r300 Gallium driver)
                          <li>Initial "signs of life" support for Sandybridge hardware in i965 DRI
                          driver.
                          </ul>
                          7.8 release notes: http://cgit.freedesktop.org/mesa/mes...notes/7.8.html
                          <li>GL_NV_conditional_render extension (swrast driver only)
                          <li>GL_EXT_draw_buffers2 extension (swrast and i965 driver only)
                          <li>GL_ARB_fragment_coord_conventions extension (for swrast, i965, and Gallium drivers)
                          <li>GL_EXT_texture_array extension (swrast driver only)
                          <li>GL_APPLE_object_purgeable extension (swrast and i945/i965 DRI drivers)
                          <li>Much improved support for <a href="../egl.html">EGL in Mesa</a>
                          <li>New state trackers for <a href="../opengles.html">OpenGL ES 1.1 and 2.0</a>
                          <li>Dedicated documentation for Gallium
                          7.7 release notes: http://cgit.freedesktop.org/mesa/mes...notes/7.7.html
                          <li>VMware "SVGA" Gallium driver. This is a Gallium3D driver which targets the
                          VMware virtual graphics device. It allows Linux OpenGL guest applications
                          to utilize the 3D graphics hardware of the host operating system.
                          <li>GL_ARB_draw_elements_base_vertex (supported in Intel i965 and software drivers)</li>
                          <li>GL_ARB_depth_clamp (supported in Intel i965 DRI and software drivers)</li>
                          <li>GL_NV_depth_clamp (supported in Intel i965 DRI and software drivers)</li>
                          <li>GL_ARB_provoking_vertex (same as GL_EXT_provoking_vertex)</li>
                          <li>Wavefront .obj file loader/viewer demo (progs/demos/objviewer)

                          Comment


                          • #14
                            Originally posted by smitty3268 View Post
                            Then you haven't been looking very hard.

                            Here are the last 5 release notes of non-major releases (no 8.0 or 9.0). As you can see, there are new extensions in each and every one. Some even provide new API's entirely (OpenGL ES support, for example).

                            9.2 release notes (early edition): http://cgit.freedesktop.org/mesa/mes...notes/9.2.html

                            9.1 release notes: http://cgit.freedesktop.org/mesa/mes...notes/9.1.html

                            7.9 release notes: http://cgit.freedesktop.org/mesa/mes...notes/7.9.html

                            7.8 release notes: http://cgit.freedesktop.org/mesa/mes...notes/7.8.html

                            7.7 release notes: http://cgit.freedesktop.org/mesa/mes...notes/7.7.html
                            yeap you are right i saw some of those, what i meant in my doubt if is those were made in in the point 0 but were disable or flaged because it wasn't stable enough or depend of another patch in another part of the stack in some cases i found others that were already present in some drivers and became active on another in the .1+ release.

                            remember in mesa there are at least 3 stages for any extension or profile to get exposed

                            1. inner mesa basic representation without any actual driver code[here should be a major release]
                            2. actual GPU specific implementation[here can be both]
                            3. profile expose[if needed] or extension availabity thorugh api[Glx/Egl][here should be major release]

                            and it could be special cases like new languages with low exposure[you can't break gl es if it wasn't there previously, so it could fit in the point zone]
                            another special case could be similar extensions with vendor prefixes for the sake of compatiblity[AMD_, NV_, ARB_] that do almost the same or the same

                            this is my specific doubt for a mesa dev that have a more general idea of the commits and the stages.

                            so to refactor my previous point, mesa developers don't allow invasive changes outside major releases, only independant subsystem or minor changes that won't trash your system, and if for some reason they allow so, normally are accesible by other developers but not directly exposed for applications[texture from pixmap comes to my mind, kde git used it before mesa actually exposed the extension]

                            Comment


                            • #15
                              Originally posted by jrch2k8 View Post
                              so to refactor my previous point, mesa developers don't allow invasive changes outside major releases, only independant subsystem or minor changes that won't trash your system, and if for some reason they allow so, normally are accesible by other developers but not directly exposed for applications[texture from pixmap comes to my mind, kde git used it before mesa actually exposed the extension]
                              This is really, really 100% completely and totally WRONG!

                              I don't know how many ways i can say it. Obviously you aren't going to believe anyone.

                              There's really no difference at all between a major and minor release in terms of what goes in. 9.0 and 9.1 had equally large/risky changes. The only difference is that 9.0 happened to update the version number on one of the APIs mesa implements because the final few necessary extensions got finished in that release.

                              Comment

                              Working...
                              X