qt5base-lts/tests
Laszlo Agocs 84fb0de413 rhi: Add D3D12 support
- The optional nice-to-haves DebugMarkers, Timestamps, PipelineCache
  are not yet implemented (features reported as false, to be
  implemented later, although buffer/texture resource name setting
  already works as-is, regardless of DebugMarkers).

- Mipmap generation for 3D textures is missing. Won't matter much
  given that 3D textures are not used in Qt for anything atm. For
  generating mipmaps for 2D (or 2D array) textures, the MiniEngine
  compute shader and approach is used. 3D support for the mipmap
  generator may be added later. 1D textures / arrays are supported
  except for mipmap generation, and so the
  OneDimensionalTextureMipmaps feature is reported as false.

- Qt Quick and Qt Quick 3D are expected to be fully functional.
  (unforeseen issues are not impossible, of course)

- Uses minimum feature level 11.0 when requesting the device. It is
  expected to be functional on resource binding tier 1 hardware even,
  although this has not been verified in practice.

- 2 frames in flight with the usual resource buffering
  (QRhiBuffer::Dynamic is host visible (UPLOAD) and always mapped and
  slotted, other buffers and textures are device local (DEFAULT).
  Requests 3 swapchain buffers. Swapchains are mostly like with D3D11
  (e.g. FLIP_DISCARD and SCALING_NONE).

- The root signature generation is somewhat limited by the SPIR-V
  binding model and that we need to map every binding point using the
  nativeResourceBindingMap from the QShader. Thus the root signature
  is laid out so each stage has its own set of resources, with shader
  register clashes being prevented by setting the visibility to a
  given stage.

  Sampler handling is somewhat suboptimal but we are tied by the
  binding model and existing API design. It is in a fairly special
  situation due to the 2048 limit on a shader visible sampler heap, as
  opposed to 1000000 for SRVs and UAVS, so the approach we use for
  textures (just stage the CPU SRVs on the (per-frame slot) shader
  visible heap as they are encountered, effectively treating the heap
  as a ring buffer) would quickly lead to having to switch heaps many
  times with scenes with many draw calls and sampledTexture/sampler
  bindings in the srb.

  Whereas static samplers, which would be beautiful, are impossible to
  utilize safely since we do not have that concept (i.e. samplers
  specified upfront, tied to the graphics/compute pipeline) in the
  QRhi API, and an srb used at pipeline creation may change its
  associated resources, such as the QRhiSampler reference, by the time
  the shader resources are set for the draw call (or another,
  compatible srb may get used altogether), so specifying the samplers
  at root signature creation time is impossible.

  Rather, the current approach is to treat each sampler as a separate
  root parameter (per stage) having a descriptor table with a single
  entry. The shader visible sampler heap has exactly one instance of
  each unique sampler encountered during the lifetime of the QRhi.

- Shader-wise no different from D3D11, works with HLSL/DXBC 5.0
  (i.e. existing .qsb files with DXBC in them work as-is). But unlike
  D3D11, this one will try to pick 6.7, 6.6, ..., down to 5.0 from the
  QShader, in that order.

- Uses D3D12MA for suballocating. As a result it can report vmem
  allocation statistics like the Vulkan backend, and it does more
  since the DXGI memory usage (incl. implicit resources) is also
  reported.  This is optional technically, so we also have the option
  of going straight with the heavyweight CreateCommittedResource()
  instead.  That is what we do if the adapter chosen reports it's
  software-based or when QT_D3D_NO_SUBALLOC=1 is set.

- PreferSoftwareRenderer (picking the WARP device) and the env.var.
  QT_D3D_ADAPTER_INDEX work as with the D3D11 backend.

- It is not unexpected that with large scenes that generate lots of
  draw calls with multiple textures/samplers per call the performance
  may be slightly below D3D11 (probably mostly due to descriptor
  management). Similarly, the reported memory usage will be higher,
  which is partly natural due to creating heaps, descriptor pools,
  staging areas, etc. upfront. Will need to be evaluated later how
  these can be tuned.

Change-Id: I5a42580bb65f391ebceaf81adc6ae673cceacb74
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2023-02-07 13:33:01 +01:00
..
auto rhi: Add D3D12 support 2023-02-07 13:33:01 +01:00
baseline Update base line test case for widgets 2023-01-06 14:51:29 +01:00
benchmarks QSortFilterProxyModel: port to PMF connects for performance reasons 2023-02-02 20:43:59 +01:00
global tst_bic: Add linux-gcc-ia32 bic data for QtXml 2013-01-16 08:25:28 +01:00
libfuzzer Change the license of all CMakeLists.txt and *.cmake files to BSD 2022-08-23 23:58:42 +02:00
manual rhi: Add D3D12 support 2023-02-07 13:33:01 +01:00
shared Inline the resetSystemLocale function 2023-01-12 19:54:13 +01:00
testserver Use SPDX license identifiers 2022-05-16 16:37:38 +02:00
CMakeLists.txt Restrict the minimum supported ICU version to 50.1 2023-01-17 15:15:11 +00:00
README Doc: Fix references to Qt Test 2013-01-30 01:35:06 +01:00

This directory contains autotests and benchmarks based on Qt Test. In order
to run the autotests reliably, you need to configure a desktop to match the
test environment that these tests are written for.

Linux X11:

   * The user must be logged in to an active desktop; you can't run the
     autotests without a valid DISPLAY that allows X11 connections.

   * The tests are run against a KDE3 or KDE4 desktop.

   * Window manager uses "click to focus", and not "focus follows mouse". Many
     tests move the mouse cursor around and expect this to not affect focus
     and activation.

   * Disable "click to activate", i.e., when a window is opened, the window
     manager should automatically activate it (give it input focus) and not
     wait for the user to click the window.