Announcement

Collapse
No announcement yet.

Qt 3D Studio 2.4 Released With Massive Performance Boost - By Switching Away From Qt 3D

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

  • Qt 3D Studio 2.4 Released With Massive Performance Boost - By Switching Away From Qt 3D

    Phoronix: Qt 3D Studio 2.4 Released With Massive Performance Boost - By Switching Away From Qt 3D

    The Qt Company has released Qt 3D Studio 2.4 as the latest release of its 3D user-interface creation suite...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Is there something fundamentally wrong with Qt3D? Is it being fixed? It's not a very good advert for Qt3D if the Qt folk aren't dog fooding it

    Comment


    • #3
      Originally posted by FireBurn View Post
      Is there something fundamentally wrong with Qt3D?
      No. It just wasn't optimized for some use cases.

      Originally posted by FireBurn View Post
      Is it being fixed?
      1. There was a performance regression between 1.x and 2.x due to trying to abstract certain hardware details by assuming desktop features are always cheap even in embedded system. e.g. vertical sync.

      2. They put too much faith in C++ magic thinking certain abstractions and features were cost-free. As it turns out, it introduced runtime overhead and some RAM waste. So they removed them.

      Originally posted by FireBurn View Post
      It's not a very good advert for Qt3D if the Qt folk aren't dog fooding it
      The fixes are in the library:

      '''
      What we did is to use the same runtime architecture as with Qt 3D Studio 1.x releases instead of running on top of Qt 3D. The core logic of the 3D engine is still the same as before, but it is running directly on top of OpenGL instead of using Qt 3D. This provides significantly improved performance especially on embedded devices, but also on more powerful desktop systems. By running Studio’s 3D engine directly on top of OpenGL we avoid overhead in rendering and simplify the architecture. The simpler architecture translates to less internal signalling, less objects in memory and reduced synchronization needs between multiple rendering threads. All this has allowed us to make further optimizations over the Qt 3D Studio 1.x – and of course to bring the new features developed in the Qt 3D Studio 2.x releases on top of the OpenGL based runtime.
      '''

      Overall it's just an extreme case of overly abstracted and under-optimized library under embedded constraints.

      Comment


      • #4
        Even though I like Qt much, when I heared that they would change the donated code to work with qt3d I immediately was sceptical. What was the probability that (a) they could outperform code written by nvidia in the 3d domain and (b) while at the same time working on an higher level abstractions.

        Comment


        • #5
          The switch was made for performance reasons on constrained (embedded) hardware where there are not many hardware threads or RAM available. We (KDAB and TQC) know where the performance and latency issues are in Qt 3D and are working to improve them. A general purpose renderer will never be as fast as a specialised one as is needed for Qt 3D Studio.

          We have recently been doing lots of work to add support for gltTF 2 on top of Qt 3D in the Kuesa project (https://github.com/KDAB/kuesa) where we are not constrained by source and binary compatibility promises. We will upstream as much of this as we can once the API and implementation settles down. We also have lots of ideas of how to reduce latency and boost performance for Qt 6 and beyond.

          Comment


          • #6
            Performance gains of this magnitude always smell. It sounds like something went horribly wrong there. This would be understandable if this was an early version that takes care of low hanging fruit, but that doesn't seem to be the case.

            Comment


            • #7
              Yeah, I always hated when Qt does its own wrapper around a standard API, they did the same thing to Vulkan to "improve" it.

              Comment


              • #8
                Originally posted by cl333r View Post
                Yeah, I always hated when Qt does its own wrapper around a standard API, they did the same thing to Vulkan to "improve" it.
                Ah. You code directly to Vulkan then? And OpenGL as well? And it's variants? On Android and Linux and Windows and Mac and Solaris and Integrity and VxWorks? I am impressed.

                Comment


                • #9
                  Originally posted by pipe13 View Post
                  On Android and Linux and Windows and Mac?
                  FTFY (I don't write apps for irrelevant shit)

                  Comment


                  • #10
                    Originally posted by zoomblab View Post
                    Even though I like Qt much, when I heared that they would change the donated code to work with qt3d I immediately was sceptical. What was the probability that (a) they could outperform code written by nvidia in the 3d domain and (b) while at the same time working on an higher level abstractions.
                    Whenever someone tries to wrap OpenGL, I'm immediately skeptical.

                    OpenGL is a funky API that is stubbornly resistant to wrapping without hurting performance in one use case or another. The best OpenGL wrappers are light-weight ones that just handle some housekeeping and add type-safety.

                    Comment

                    Working...
                    X