Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-78135

Quick3D: Shader managment rework to enable an efficient QRhi-based port

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: P1: Critical
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 6.0.0
    • Component/s: Qt RHI, Quick: 3D
    • Labels:
      None
    • Story Points:
      20
    • Commits:
      a9f13409195d0ae1dfb72e88c333991fde27b756 (qt/qtquick3d/dev)
    • Sprint:
      Qt Quick 3D - Week 19/20, Qt Quick 3D - Week 21/22, Qt Quick 3D - Week 23/24, Qt Quick 3D - Week 25/26, Qt Quick 3D - July, Qt Quick 3D - 33 - 34, Qt Quick 3D - 35 - 36, Qt Quick 3D - 37 - 38

      Description

      Direct OpenGL usage is to be removed in Qt 6.0 and is replaced by rendering via the Qt Rendering Hardware Interface and the associated graphics and compute shader management machinery provided by the Qt Shader Tools module.

      See https://github.com/alpqr/talks/blob/master/Qt_World_Summit_2019/qt_graphics_qtws2019.pdf

      This affects Quick 3D and involves significant rework in both the lower level rendering layer and the shader management system for default and custom materials. This task is about the latter.

      Quick 3D should make it possible to move away from runtime shader string generation and compilation. This is needed to enable better performance, and to avoid possible problems (support for less-common platforms, licensing, etc.) due to relying on the Qt Shader Tools module and its 3rd party dependencies.

      • For a given scene, we need to be able to generate all shader code (both for default and custom materials used anywhere in the scene) offline. This means outputting a set of files with GLSL source in them.
      • Preferably by having both a library and a command line tool, in order to allow future integration into the designer tools.
      • The resulting shader sources are then run through the compiling and processing steps by the Qt Shader Tools module. In the first phase this may simply mean manually running qsb, and so no work is needed for this step in this task.
      • The engine should have some hooks to find the set of .qsb files associated with the scene at run time. The actual usage of them is not part of the task as that is to be implemented in the initial port onto the RHI.
      • The library and command line tool must be able to handle additional options that specify additional variants to generate. For example, if a scene contains 2 lights (as in Light nodes), a default material variant with 2 lights should be generated. However, if the options specify to support 3 and 4 lights as well, the output should be variants for 2, 3, and 4 lights. This is because dynamic changes to the scene (say, a dynamically instantiated Light node) cannot be deduced by just parsing the QML code. Eventually this is expected to be exposed visually in the designer tools "baking" settings, or similar.
      • It is yet to be seen if/how runtime shader compilation and processing is supported in Qt 6. It could be that an initial QRhi port will be brought up using that approach, but that does not mean we want to support that in production. Therefore, the offline (or application build time) processing should be the default approach. This means potential consequences for the designer and deployment story. Deploying single QML files is likely not an option in Qt 6 time frame anymore, without appropriate asset baking steps. This is to be managed in future, separate tasks.

        Attachments

          Issue Links

          For Gerrit Dashboard: QTBUG-78135
          # Subject Branch Project Status CR V

            Activity

              People

              Assignee:
              stromme Christian
              Reporter:
              lagocs Laszlo Agocs
              PM Owner:
              Pasi Keränen Pasi Keränen
              RnD Owner:
              Andy Nichols Andy Nichols
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 8 weeks, 1 day
                  8w 1d
                  Remaining:
                  Remaining Estimate - 8 weeks, 1 day
                  8w 1d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified

                    Gerrit Reviews

                    There are no open Gerrit changes