Announcement

Collapse
No announcement yet.

Qt 5.10 To Have Built-In Vulkan Support

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

  • #21
    Originally posted by indepe View Post

    From this perspective, I am wondering why there is an experimental DX12 backend for QT Quick (according to an earlier phoronix article).

    I would expect basic and simple support for an application to embed its own 2D/3D graphics within a Qt app, using Vulkan, to be important enough to do sooner, especially since QT is a cross-platform framework.
    The experimental DX12 backend exists because we (the qt graphics team) didn't have access to Vulkan yet when we started looking at refactoring the Qt Quick scenegraph rendering in 5.8. We experimented with both Metal and DX12 because they were low level graphics APIs that were available at the time (end of 2015). We just needed one to validate the changes we were doing, so DX12 was chosen. The 3 API's are similar enough that doing a backend for 1 should mean its possible to implement a future backend for any.

    Comment


    • #22
      I think another important point that is being lost here is that these are just basic enablers for using Vulkan within Qt Applications. This is comparable to the existing OpenGL support in Qt Gui. It is not however a Qt Quick rendering backend. There are no plans to create a Vulkan backend for Qt Quick this year.

      What this commit enables is for users to more easily embedded Vulkan renderers into their Qt applications.

      Comment


      • #23
        Originally posted by indepe View Post
        According to NVidia and AMD website info, the current drivers support both Vulkan and Windows 7, so I'd assume Vulkan does work on Windows 7, as it is meant to do. Not knowing the Windows world very well, where would the limit for financial revenue be?
        Yes. Only DX12 is limited to Windows 10.
        Vulkan is compatible with more OSes.

        Comment


        • #24
          Originally posted by nomadewolf View Post

          Yes. Only DX12 is limited to Windows 10.
          Vulkan is compatible with more OSes.
          Irrelevant. Developers are going to use the API that is easiest/quickest to work with. And when it comes to quality of development tools, it's not even close: Microsoft wins.

          Comment


          • #25
            Originally posted by gamerk2 View Post

            Irrelevant. Developers are going to use the API that is easiest/quickest to work with. And when it comes to quality of development tools, it's not even close: Microsoft wins.
            I have yet to meet game developers willingly cutting themselves out of over 50% of their main market (Windows 7/8), and they would do that with DX12.

            Comment


            • #26
              Originally posted by bsquask View Post

              The experimental DX12 backend exists because we (the qt graphics team) didn't have access to Vulkan yet when we started looking at refactoring the Qt Quick scenegraph rendering in 5.8. We experimented with both Metal and DX12 because they were low level graphics APIs that were available at the time (end of 2015). We just needed one to validate the changes we were doing, so DX12 was chosen.
              Well, availability of Vulkan is still a relevant factor, as it is lacking for the open source drivers on Linux (except perhaps the Intel one), although good with the closed source drivers from AMD and NVidia, for quite some time already.

              Originally posted by bsquask View Post
              The 3 API's are similar enough that doing a backend for 1 should mean its possible to implement a future backend for any.
              So may I conclude you consider using Vulkan for Linux and/or Windows 7/8 (if not also Windows 10), for future backends ? (Even if not this year.)
              Last edited by indepe; 21 February 2017, 12:43 AM.

              Comment


              • #27
                Originally posted by indepe View Post

                Well, availability of Vulkan is still a relevant factor, as it is lacking for the open source drivers on Linux (except perhaps the Intel one), although good with the closed source drivers from AMD and NVidia, for quite some time already.



                So may I conclude you consider using Vulkan for Linux and/or Windows 7/8 (if not also Windows 10), for future backends ? (Even if not this year.)
                Regarding Qt Quick scenegraph renderers: Vulkan (or Metal or DX12) backends are not high priority. OpenGL is not going away anytime soon and all of the places Vulkan works so does OpenGL. The Qt Quick renderer is not API bound so there is not as much to gain from the low level APIs as just using OpenGL in a more modern way. So while I expect experimental work to start on a Vulkan renderer to start this year (as it's the highest priority of the low level APIs) it is not a priority. What is however is making sure users are able to use Vulkan in their Qt Applications (but not necessarily use it ourselves yet in Qt).

                Comment


                • #28
                  Originally posted by gamerk2 View Post
                  Irrelevant. Developers are going to use the API that is easiest/quickest to work with. And when it comes to quality of development tools, it's not even close: Microsoft wins.
                  I agree that since everyone already pretty much uses DX(11, 10, etc...), it may look like DX12 is easier. But in fact, there shouldn't be much different since both (DX12 and VK are so similar) and both are a completely paradigm.

                  That said, you can port your game engine from DX11 to DX12 with little effort. Just convert functions and do some adjustments. It won't be true DX12, you'll lose performance, but the transition will be easier and you'll be able to tweak the engine to better DX12 support at a later time.
                  There's also the economic incentive.

                  About quality of development tools, i think that it (may) be true for now, but the Khronos group is making serious effort on that regard, so i think that VK won't suffer from the same problems that OpenGL did.

                  Comment

                  Working...
                  X