Announcement

Collapse
No announcement yet.

Mesa 12.0 Might Be A Delayed Release This Summer With OpenGL 4.5 Support

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

  • #21
    Originally posted by boffo View Post

    Maybe it's better to release 11.3 as planned and release 12.0 as soon as it's ready. I mean it depends on distro releases, if the one month delay doesn't impact on including mesa 12.0 in the near future distro releases then it's fine to delay, otherwise it's better to release 11.3 and have support for the new hardware out of the box for the next distro release. This is the main problem with non rolling distros.
    Yeah, I would have gone for the same, it seems the most reasonable option IMO.

    Comment


    • #22
      Originally posted by GreatEmerald View Post
      Nice, but what about the Unreal Engine 4 issue?
      it's a bug, bugs can be fixed after feature freeze

      Comment


      • #23
        Originally posted by You- View Post
        ES3.1 and 3.2 are not complete
        3.1 is complete

        Comment


        • #24
          Originally posted by boffo View Post
          Maybe it's better to release 11.3 as planned and release 12.0 as soon as it's ready.
          i want to stress that next release is already 12.0 - 11.0 had gl4.1, even in the extremely unlikely case when unreal 4.3 bug will not be fixed, 4.2 is already new version
          so it should be spelled "to release 12.0 as planned and release 13.0 as soon as it's ready"

          Comment


          • #25
            Looks like Emil (understandably) isn't too keen on delaying the release.

            The first part of Intel's FP64 stuff is in so they're up to 4.0. There's GL_ARB_vertex_attrib_64bit to go before they can finally advertise OpenGL 4.2. Hopefully that'll land and the release is branched on Friday as originally planned, so the final release (with Polaris support) comes around the time as AMD's Polaris ships. Good work, AMD!

            Comment


            • #26
              I'm slightly confused, mesamatrix says 4.3 is done (core and radeonsi), but I've checked the release notes on mesa and can only see mention of 4.1.

              Do I take that to mean that 4.3 is done, but that they haven't done a release yet that includes 4.3?

              Comment


              • #27
                Originally posted by kaprikawn View Post
                I'm slightly confused, mesamatrix says 4.3 is done (core and radeonsi), but I've checked the release notes on mesa and can only see mention of 4.1.

                Do I take that to mean that 4.3 is done, but that they haven't done a release yet that includes 4.3?
                Radeonsi has all the extensions for 4.3 but only exposes 4.2 so far due to bugs in/related to UE4-based games when they use the 4.3 codepaths. Intel has today advanced to 4.0 for 'gen8' hardware.

                There hasn't been a release since any driver advanced beyond 4.1 support. Most likely the documentation hasn't been fully updated yet but that often comes late in a release cycle (it's more subject to change earlier on as features get added).

                Comment


                • #28
                  Originally posted by kaprikawn View Post
                  I'm slightly confused, mesamatrix says 4.3 is done (core and radeonsi), but I've checked the release notes on mesa and can only see mention of 4.1.
                  Mesamatrix merely parses the GL3.txt file. It allows to have an overview of the Mesa situation, but the bleeding-edge status of the project can be a little different as the documentation gets updated later or commits are pending in the mailing list.

                  Comment


                  • #29
                    So what the heck is the difference beteween GL_KHR_robust_buffer_access_behavior and GL_ARB_robust_buffer_access_behavior? Will the latter make the former easier to implement? Is GL_ARB_ES3_1_compatibility a formality for drivers with ES3.1 support?

                    Comment


                    • #30
                      Originally posted by Kristian Joensen View Post
                      So what the heck is the difference beteween GL_KHR_robust_buffer_access_behavior and GL_ARB_robust_buffer_access_behavior? Will the latter make the former easier to implement? Is GL_ARB_ES3_1_compatibility a formality for drivers with ES3.1 support?
                      I think you're confusing these extensions with GL_KHR_robustness and GL_ARB_robustness , as the ones you linked only "specifies the behavior of out-of-bounds buffer and array accesses" . As for the difference I am no expert, but at a superficial reading the documentations are pretty close except for this goal that is added for the KHR one: "Define behavior of OpenGL calls made after a graphics reset."

                      EDIT: reading again maybe you specifically asked for those two extensions, discard my post if that's the case

                      Comment

                      Working...
                      X