Announcement

Collapse
No announcement yet.

Qt 5.10 To Have Built-In Vulkan Support

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

  • #11
    Originally posted by cipri View Post
    My advice is not to get false hopes. Qt has so many bugs, I reported enough of them, also at least one was flagged as "critical". My naive understanding of critical gave my the hope that it would be solved very quickly..... the reality was... not even after more than 2 years it was touched (not to speak about fixing it)!
    I spent enough time on the new Qt3D 2.0 ... finding a lot of bugs, and noticing that the developers didn't write some tests for testing this module (also the documentation is very very very very incomplete). For c++ there are just a few simple basic examples. After having to deal with a lot of bugs... in the end after my own example became bigger, I started to notice the performance problems [cpu usage was over 30% with no apparent reason]. If I as a complete beginner in the domain of qt3d found so many bugs in short time, I really wonder why the developers of qt3d, after working many years on it, didn't find them!
    After noticing that the c++ Widgets in QT are getting no attention and Qt3D was a disappointment , I decided to write my own GUI toolkit and Rendering engine, using of course qtcreator. And my first target was Wayland and Vulkan with modern c++17 (clang 4.0). I switched my Gnome Ubuntu to Wayland, and after reading about Wayland, I started coding..... just to notice that keyboard layout while typing in qtcreator was another than the one of the settings. The keyboard input works fine for everything else, just not in qtcreator. I'm hunted by QT Bugs.
    I don't see a future in QT, it's full of bugs, it somehow forces you in the old programming style of the 90s (raw pointers..), and because they want to be consistent, also the the interface of the new modules (like qt3d) are also written in the same spirit.
    My advice, don't get fooled and become an pre-alpha tester of QT, then write bug reports, and then wait a few years till they might get attention.... which in normal case anyway doesn't happen, because QT in the meantime will be working on someht
    Another case of rage breaking keyboards.

    Also, I think you didn't say "bugs" enough in your post.

    Comment


    • #12
      Originally posted by indepe View Post
      where would the limit for financial revenue be?
      Microsoft, once again, won gamers mindshare. When communities like /r/pcmasterrace talk about new releases, performance, optimization, etc they talk about DX12, games using it, etc. This might be reflected in game sales - putting DX12 on a store page can generate sales, while putting Vulkan there has significantly less recognition. There was no ad campaign and hype machine for it the way Mantle / DX12 got.

      Comment


      • #13
        Originally posted by zanny View Post

        Microsoft, once again, won gamers mindshare. When communities like /r/pcmasterrace talk about new releases, performance, optimization, etc they talk about DX12, games using it, etc. This might be reflected in game sales - putting DX12 on a store page can generate sales, while putting Vulkan there has significantly less recognition. There was no ad campaign and hype machine for it the way Mantle / DX12 got.
        Sounds very hypothetical to me, especially for an app where you would choose to use Qt. And if that superficial marketing aspect really mattered, it probably would only get worse over time. Besides, you don't have that option on Linux, and I doubt even more that you would get any effect like that by putting "OpenGL" on the box.

        Comment


        • #14
          Originally posted by bug77 View Post

          If Qt couldn't push more than 20fps on the desktop, it wouldn't be usable at all on mobile. And yet it is. Some widgets may be slow, but you can code a resource hungry control using pretty much any toolkit.
          It can, easily. Advanced hidpi full screen text interfaces in CPU mode averages around 1000fps even when heavily animated. What you have to realise is that full repaints are expensive with CPU rendering, but CPU rendering is a lot more selective than most fast GPU rendering engines. So while a GPU would repaint the entire screen (or a number of tiles on a phone), a CPU rendering engine only repaints newly exposed areas. This means that if you increase scrolling input from 30 events per second to 60 events per second, each event will only scroll half the distance and expose half as many pixels meaning on a CPU it would need to do exactly half the work, so in fact rendering scrolling text at 60fps or 30fps is equally hard. The main limitations for CPU rendering speed is memory blitting (is it fast enough to move unchanged parts or not), and that cpu rendering absolutely sucks for 3d viewport tranforms that changes all the pixels in every frame.

          Comment


          • #15
            Originally posted by carewolf View Post

            It can, easily. Advanced hidpi full screen text interfaces in CPU mode averages around 1000fps even when heavily animated. What you have to realise is that full repaints are expensive with CPU rendering, but CPU rendering is a lot more selective than most fast GPU rendering engines. So while a GPU would repaint the entire screen (or a number of tiles on a phone), a CPU rendering engine only repaints newly exposed areas. This means that if you increase scrolling input from 30 events per second to 60 events per second, each event will only scroll half the distance and expose half as many pixels meaning on a CPU it would need to do exactly half the work, so in fact rendering scrolling text at 60fps or 30fps is equally hard. The main limitations for CPU rendering speed is memory blitting (is it fast enough to move unchanged parts or not), and that cpu rendering absolutely sucks for 3d viewport tranforms that changes all the pixels in every frame.
            So you are talking about scrolling within a single text widget ?

            Comment


            • #16
              Originally posted by indepe View Post

              So you are talking about scrolling within a single text widget ?
              Yes. It is the only common widget case where you must hit 60fps. You don't need 60fps of 60 new applications every second, that would be epileptic inducing. So 0.05 second for a new window is acceptable, while 0.05s for scrolling a window is not.

              Comment


              • #17
                Originally posted by carewolf View Post

                Yes. It is the only common widget case where you must hit 60fps. You don't need 60fps of 60 new applications every second, that would be epileptic inducing. So 0.05 second for a new window is acceptable, while 0.05s for scrolling a window is not.
                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.

                Comment


                • #18
                  Originally posted by Namenlos View Post
                  I would rather see them fix wayland. By the looks of it there will be no QT 5.8.1 and KDE wayland session is broken in 5.8 an there seems to be nothing going on since more than a week (Gerrit/QTBUG-58423)
                  yeah, it sucks than the last release broke wayland, and no info about when it is going to be fixed, or if we have to wait some more months until the next plasma release.

                  Comment


                  • #19
                    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 DX12 backend is there because OpenGL support is unreliable on Windows, and the current work-around when OpenGL doesn't work is using ANGLE, which isn't very good either. As far as I understand, the Vulkan support does primarily target embedding Vulkan content. I think it is actually possibly to already embed Vulkan scenes, but only if you have NVidia hardware because NVidia drivers have a GL-Vulkan bridging extension.

                    Comment


                    • #20
                      Originally posted by carewolf View Post

                      The DX12 backend is there because OpenGL support is unreliable on Windows, and the current work-around when OpenGL doesn't work is using ANGLE, which isn't very good either.
                      Let's hope that Vulkan support will be reliable on all its platforms.

                      Originally posted by carewolf View Post
                      As far as I understand, the Vulkan support does primarily target embedding Vulkan content. I think it is actually possibly to already embed Vulkan scenes, but only if you have NVidia hardware because NVidia drivers have a GL-Vulkan bridging extension.
                      This requirement is probably the reason why the initial target is a whole window instead.

                      Comment

                      Working...
                      X