Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: The Mesa 3D Release Process Is Changing

  1. #11
    Join Date
    Jun 2009
    Posts
    1,086

    Default

    Quote 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

  2. #12
    Join Date
    Oct 2012
    Location
    Washington State
    Posts
    406

    Default

    Clearly someone should have mentioned SIGGRAPH.

  3. #13
    Join Date
    Oct 2008
    Posts
    3,023

    Default

    Quote 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)

  4. #14
    Join Date
    Jun 2009
    Posts
    1,086

    Default

    Quote 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]

  5. #15
    Join Date
    Oct 2008
    Posts
    3,023

    Default

    Quote 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.

  6. #16
    Join Date
    Aug 2011
    Location
    Hillsboro, Oregon
    Posts
    128

    Default

    Mesa versioning is quite simple actually. There are feature releases and stable releases.

    • Feature releases happen after a set amount of time (previously 6 months, now we're aiming for 3 months).

      For example, 8.0 -> 9.0 or 9.0 -> 9.1. These are based on the latest development code (the 'master' branch in git). These include all the latest development work, including new features, performance improvements, and new hardware support.

      Normally, features are implemented as OpenGL extensions. Applications can immediately detect and use these once we support them. From time to time, Khronos releases a new version of OpenGL (i.e. 4.1). These are essentially a collection of extensions that are guaranteed to exist, which means applications can simply check for 4.1 rather than checking for an older version plus a list of extensions that provide the functionality they want.

      When core Mesa and at least one driver adds enough features to support a new OpenGL version, we bump the major version number. For example, 8.0 -> 9.0 happened when the i965 driver supported OpenGL 3.1. Other drivers like r600g weren't quite ready for 3.1 yet, but it gained support in the next release - 9.1.

      We don't bump the major version number on new OpenGL ES releases for some reason.
    • Stable/point releases happen every couple of weeks or when enough bug fixes accumulate to warrant one.

      For example, 9.1.3 and 9.1.4. These are based off of the stable branch (i.e. "9.1"), with bug fixes backported from master. These fix problems - for example, 9.1.4 makes Portal render correctly - but generally don't improve performance. They don't add any new OpenGL features whatsoever. We sometimes backport new hardware enablement, as that won't break anyone's system (since no one has one yet).


    You really don't want features or performance work in point releases - those tend to be destabilizing. Keeping the point releases as bug-fixes-only with a bit of platform enabling mixed in is essential for distros to be able to trust upstream and take new releases.

    The change being proposed here is to shorten the cycle on minor releases, which do add new features/performance, to get those into the hands of users more quickly. Our previous 6-month cycle also meant that if we didn't quite line up with your distro's 6-month release schedule (i.e. Fedora/Ubuntu/...), then you could be nearly a year behind schedule. With a 3-month cycle, this is less likely to occur. Plus, for rolling release distros, you'll get the latest and greatest much more quickly.

  7. #17
    Join Date
    Apr 2013
    Posts
    221

    Default look good

    look like amd and nvidia pro... drivers final driver, every 3 months they give a new driver.its good for gammers

    for exemple unstabell mesa 9.2 have a lote of improvents on valve games

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •