Announcement

Collapse
No announcement yet.

RadeonSI Compatibility Profile Is Close To OpenGL 4.4 Support

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

  • #11
    Let's not jump the gun yet... getting the code written is the first step of what could be a long path.

    The reason developers don't like compatibility profiles is that (at least historically) following the spec to the letter was not sufficient to get the same behaviour between different implementations, which leads to a lot of per-application testing / debugging / tweaking.

    With core profiles "following the spec" gets you a lot closer to consistent behaviour between implementations.
    Test signature

    Comment


    • #12
      Originally posted by bridgman View Post
      Let's not jump the gun yet... getting the code written is the first step of what could be a long path.

      The reason developers don't like compatibility profiles is that (at least historically) following the spec to the letter was not sufficient to get the same behaviour between different implementations, which leads to a lot of per-application testing / debugging / tweaking.

      With core profiles "following the spec" gets you a lot closer to consistent behaviour between implementations.
      Yeah having compatibility profile tests in the CTS would be a step in the right direction, but I'm not holding my breath for that.

      Comment


      • #13
        Originally posted by tarceri View Post

        Yeah having compatibility profile tests in the CTS would be a step in the right direction, but I'm not holding my breath for that.
        It could be if the software didn't already rely on the current (broken) behavior.

        Edit: Actualy no, it couldn't be. The behaviour is not defined so it can not be conformance tested.
        Last edited by Tomin; 22 June 2018, 09:09 PM.

        Comment


        • #14
          Ok, according to Timothy the remaining ones to reach 4.4 status are:
          • ARB_draw_indirect/ARB_multi_draw_indirect
          • ARB_vertex_attrib_64bit

          Then I think they just need 2 more for 4.5.
          • ARB_direct_state_access
          • ARB_ES3_1_compatibility

          And for 4.6:
          • ARB_indirect_parameters
          • ARB_gl_spirv - which also needs to be finished in core contexts

          Comment


          • #15
            Originally posted by bridgman View Post
            The reason developers don't like compatibility profiles is that (at least historically) following the spec to the letter was not sufficient to get the same behaviour between different implementations, which leads to a lot of per-application testing / debugging / tweaking.

            With core profiles "following the spec" gets you a lot closer to consistent behaviour between implementations.
            I completely agree with these statements and priorities, however, I think it is worth pointing out that now would be a good time to release a user-friendly tool for users to create their own application profiles, with a service where these profiles could be submitted for others to use. Perhaps community profiles shouldn't automatically load by default, but anything approved by AMD could be. A lot of us would like to contribute toward better performance but a lot of us don't know how. This could be a great opportunity to take a major and tedious responsibility off the shoulders of AMD's open-source devs.

            Comment


            • #16
              Originally posted by Tomin View Post

              It could be if the software didn't already rely on the current (broken) behavior.

              Edit: Actualy no, it couldn't be. The behaviour is not defined so it can not be conformance tested.
              There are compat profile specs, but currently nothing is conformance tested. The specs can and should be amended where is makes sense to more clearly define behaviour. As for breaking apps, if all drivers do that same thing then the spec can be changed or the apps can be fixed (or have per app workarounds in the driver) just like what happens with bugs in the core profile.

              Comment


              • #17
                Originally posted by Qaridarium
                YES this means we get a really good and complete free driver.

                now we need to port this to windows and send the closed source crap to the garbage bin.
                Except as mentioned in previous thread, compatibility contexts are more vague in specification than core ones so your games will break anyway since they were written against nVidia's interpretation of compatibility contexts

                Comment


                • #18
                  The one glimmer of hope I see here is that we can probably use AMD's closed source OpenGL compatibility profile as a reference since that has a fairly tight API checker. That won't help with games that were written for NVidia's driver only, but it should be a pretty good start.
                  Test signature

                  Comment

                  Working...
                  X