Announcement

Collapse
No announcement yet.

RADV Achieves Same-Day Conformance For Vulkan 1.1

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

  • #21
    Originally posted by airlied View Post
    I think you could to Vulkan on CAYMAN
    So theoretically should be possible on ARUBA too? (Which is TeraScale 3 VLIW4, like CAYMAN.)

    Comment


    • #22
      Originally posted by BNieuwenhuizen View Post

      Per the article RADV is fully conforming for VI (GCN 1.2) cards and newer. It is of course never feature complete
      I asked, because my ideapad 720s review unit w/ Vega gfx still prints out some "WARNING: radv is not a conformant vulkan implementation, testing use only." kind of string each time I run a Vulkan app. Maybe time to update to latest Mesa git ;-)
      Last edited by rene; 08 March 2018, 08:10 AM.

      Comment


      • #23
        Originally posted by bridgman View Post

        Do you mean "radeon rather than amdgpu on GCN hardware" or "radeon so I can run pre-GCN GPUs" ? That's an important distinction AFAIK.

        Running RADV on radeon rather than amdgpu on GCN hardware is probably doable (although the radeon IOCTL set might need some additions) but it hardly seems worth the effort.

        Running on pre-GCN hardware is more of an issue - Mantle definitely needed GCN-level hardware and I *think* that is also the case for Vulkan, but I'm not 100% sure since IIRC the Vulkan spec was tweaked relative to Mantle in order to allow support on slightly less feature-ful hardware.
        It's my understanding that any unified shader architecture can support the same subset of Vulkan that say adreno can support. In all honesty even Intel's -current- products fall in that same class of hardware, except worse because it isn't even a totally unified shader architecture, it just chooses not to do vertex shaders in hardware. But, otherwise everything from GF8XXX and HD2XXX and up can support at least the minimal subset. Some of those cards probably are fast enough, but I doubt many of them are still in day to day use, so it probably isn't worth it considering how old they are.

        Comment


        • #24
          Originally posted by Strunkenbold View Post
          Really impressive work by the driver devs. Its actually astonishing. However, it will take months till things appear in an official release. You may say thats no problem because we have no users of Vulkan 1.1 anyway but what if this changes? Maybe next feral game come with support, nvidia and amd binary users can start right away, mesa people wait 6 months till their distro picks up support...
          Maybe the release model of mesa should change from a time based release schedule to a feature based schedule.
          Same for maintenance releases. It may sounds cool if you have 100 patches in each stable release but honestly I think once an important bug gets fixed, like fixes for popular games / apps, crash and hang fixes, fixes for WM / DE the release should happen at least in the same week.
          Or you can just compile it yourself in 10 minutes. It's basically effortless.

          Comment


          • #25
            Originally posted by nuetzel View Post

            Why can't you (if you need it for i.g. gaming) add a repro for Mesa git?
            Sorry but I dont think that you got the point. Its not about me, Im running mesa git / LLVM SVN, and frequently reporting bugs btw.
            Its simply about what the situation is for the other 95% of linux users. If there are really casual gamers using linux outthere, they usually dont want to set up a git repo even if their PC just needs 10 mins to compile. The usual gamer just want to have fun with their game and not care about developing or risk a broken desktop by using experimental packages.
            The second point is about game developers. If they test their release with mesa and find out that mesa doesnt support feature xy, they usually mark the game not supported by mesa. The third point comes with the developing speed of mesa. Usually mesa lacks behind in term of features by months or years. Now they got things together on day 1, which is a remarkable moment in mesa history. Yet 95% of the user base dont profit from this. Given that mesa 18.0 hasnt even released and is one month behind its schedule, you can expect it takes months again till vulkan 1.1 sees an official mesa release.

            Im wondering why it shouldnt be possible to bundle such a new feature also in a new release. As those are new features it shouldnt break other stuff. There are also no apps out there which rely on that new feature who could possibly break.
            Lets say Feral uses vulkan 1.1 for Tomb Raider. They are usually kind enough to test mesa and patch it. Which, if there would be really a bug, results in a fresh released mesa 18.0.1. Feral releases the game, give official mesa support, users just need to hit the update button in their distro, all happy.

            Comment


            • #26
              Originally posted by Kavalor View Post

              Unfortunately that is the best you will ever see, to push the changes in a public repository earlier would violate the NDA's and Information Embargoes. We have seen with the chaos around Meltdown/Spectre , which broke a week early because of speculation resulting over some code pushes into the kernel.
              I think that the whole patch series was developed in a private repository and was later pushed to the ml. I dont know a reason why this shouldnt be possible with a mesa release. And actually they dont even need to provide a day 1 mesa release. It would be perfectly fine if a release would happen in some weeks.

              Originally posted by Kavalor View Post
              And that would only change things for rolling releases but not for stable one, where it already depends when they plan the next release. These decision are already done independent of the upstream release cadence. They just take whats current mostly , when they start building.
              I think you got a good point here. But usually those packages are still available in testing repository. Thats still far more user friendly than setting up a git repo and compile yourself / or using user packages.

              Comment


              • #27
                Originally posted by Strunkenbold View Post

                I think that the whole patch series was developed in a private repository and was later pushed to the ml. I dont know a reason why this shouldnt be possible with a mesa release. And actually they dont even need to provide a day 1 mesa release. It would be perfectly fine if a release would happen in some weeks.



                I think you got a good point here. But usually those packages are still available in testing repository. Thats still far more user friendly than setting up a git repo and compile yourself / or using user packages.
                The problem I see with that is that's already pretty much what amdvlk is already doing. But look at its source, no git, no nothing, no kind of revision control or source management of any kind. Good luck finding broken lines of code, commits aren't recorded and can't be reversed like that. Maybe it could be considered more user friendly pehaps due to the possibility of AMD releasing their own binary packages. But there is no way it's a technically better approach, not at a technical level. These are some of the reasons why you can bet your last dollar in the end radv is going to produce higher quality code than amdvlk can ever hope to.
                Last edited by duby229; 08 March 2018, 01:19 PM.

                Comment


                • #28
                  Originally posted by duby229 View Post

                  The problem I see with that is that's already pretty much what amdvlk is already doing. But look at its source, no git, no nothing, no kind of revision control or source management of any kind. Good luck finding broken lines of code, commits aren't recorded and can't be reversed like that. Maybe it could be considered more user friendly pehaps due to the possibility of AMD releasing their own binary packages. But there is no way it's a technically better approach, not at a technical level. These are some of the reasons why you can bet your last dollar in the end radv is going to produce higher quality code than amdvlk can ever hope to.
                  I dont know what amdvlk has to do with an alternate release schedule like the one Im supposing. After all amdvlk dont even had a single release except its initial release. Basically someone just drop patches from time to time and thats it.
                  Which has nothing to do with the way vulkan 1.1 for ANV and RADV were developed. Numerous people had access to those NDA branches. All patches have review by tags and some of them are already 6 months old. Which makes it even more questionable to wait for another 6 months to make it appear for the users.
                  There is a nice discussion on the ml where devs talks about releasing vulkan 1.1 on day 1:

                  I do think that being there day-1 is important. If nothing else, it shows the rest of the graphics community (who already fears the concept of open-source) that working in the open isn't going to cramp their style. If we can deliver full-featured and fully conformant Vulkan 1.1 drivers on day 1, then they can to. I think that's an important message for the open-source community to send.
                  I completely agree here. We have git. We can change code after it lands. The value we as a project get from having day 1 support is huge, and the value of getting our python style polished before any patches land is... well, it doesn't even compare.


                  I think its an even stronger sign for all to have a release with vulkan 1.1 in the next 2-3 Weeks. It doesnt neccessary have to be a day 1 release but letting those, actually rather mature patches, rust for another 6 months in a git repo doesnt make much sense.

                  Comment


                  • #29
                    Originally posted by Strunkenbold View Post

                    I dont know what amdvlk has to do with an alternate release schedule like the one Im supposing. After all amdvlk dont even had a single release except its initial release. Basically someone just drop patches from time to time and thats it.
                    Which has nothing to do with the way vulkan 1.1 for ANV and RADV were developed. Numerous people had access to those NDA branches. All patches have review by tags and some of them are already 6 months old. Which makes it even more questionable to wait for another 6 months to make it appear for the users.
                    There is a nice discussion on the ml where devs talks about releasing vulkan 1.1 on day 1:



                    I think its an even stronger sign for all to have a release with vulkan 1.1 in the next 2-3 Weeks. It doesnt neccessary have to be a day 1 release but letting those, actually rather mature patches, rust for another 6 months in a git repo doesnt make much sense.
                    There are release cycles. Thet's the point. What amdvlk has to do with it is that AMD can meet those release cycles with it. But radv is a part of mesa and it gets released on a schedule that may or may not coincide with new hardware releases or new distro releases or new API releases. But you can see how many different things need to fall into place in order to get those coincidences. With a project like mesa it's just never gonna be able to please everybody everytime.

                    Comment

                    Working...
                    X