Announcement

Collapse
No announcement yet.

AMD Begins Staging AMDGPU Patches For Linux 4.20/5.0, Including FreeSync Refactoring

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

  • #11
    Originally posted by sireangelus View Post
    honestly, for 5.0, i would stop submitting ANY new code not bugfix/regression related and prompt the developers to pause all current work and use their time only towards that end, before going foward.
    they do it for every release, after two week merge window. honestly, nobody needs your teachings

    Comment


    • #12
      Originally posted by sireangelus View Post
      honestly, for 5.0, i would stop submitting ANY new code not bugfix/regression related and prompt the developers to pause all current work and use their time only towards that end, before going foward.
      For this case there are release candidates where only bugfixes and critical features are accepted. A bugfix-only version wouldn't make sense because feature development happens always in the background and will be merged on the next possible merge-window. The developer are responsible to do enough bugfixing.

      Comment


      • #13
        Originally posted by euler271 View Post

        "I don't want to be too predictable. The version numbers are meaningless" Linus Torvalds
        Then again, that mean there's no real difference between 4.13 and 5.0. So no extra care on bugfix/regression should/has to/will be taken, and that's just ok.
        Such version numbers have meaning, when following semantic versioning...

        But, for kernel, I would just name it with YEAR.MONTH of release date.

        Comment


        • #14
          Originally posted by pal666 View Post
          they do it for every release, after two week merge window. honestly, nobody needs your teachings
          no merge window either. Only bugfixing and regression is allowed.

          Comment


          • #15
            Originally posted by sireangelus View Post
            no merge window either. Only bugfixing and regression is allowed.
            all bugfixing was done before opening new merge window, it does not open until regressions are fixed. what makes you preach useless delay of development? are you jealous because some other os is lagging behind linux?
            Last edited by pal666; 26 August 2018, 12:53 PM.

            Comment


            • #16
              Why do I get the feeling that they are simply fking with us to keep their proprietary driver in play.

              Comment


              • #17
                Originally posted by ThoreauHD View Post
                Why do I get the feeling that they are simply fking with us to keep their proprietary driver in play.
                What do you think we should be doing instead ?

                We can't "reach agreement on a cross-vendor solution" by ourselves...
                Last edited by bridgman; 02 September 2018, 11:54 PM.
                Test signature

                Comment


                • #18
                  Originally posted by debianxfce View Post
                  and put AMD freesync patches to the mainline open source software.
                  If we had been allowed to do that it would have been upstream a year ago (or whenever DC went upstream).

                  The expectation is that freesync will go upstream as a cross-vendor solution.
                  Test signature

                  Comment


                  • #19
                    Originally posted by bridgman View Post
                    The expectation is that freesync will go upstream as a cross-vendor solution.
                    Which other vendors are actively interested in using freesync? I'm surprised Intel isn't already involved.

                    Comment


                    • #20
                      Not sure who originally pushed back on upstreaming as AMD-only code but the focus for the last year has been on finding a cross-vendor solution. I believe the main participants have been Manasi from Intel plus some AMD folks.

                      My understanding is that kernel code for freesync has been upstream for a while since that is vendor-specific by nature, and that the discussion has been around userspace code - X driver, libdrm and Mesa.
                      Last edited by bridgman; 05 September 2018, 05:16 AM.
                      Test signature

                      Comment

                      Working...
                      X