qt5base-lts/tests/manual/rhi/hellominimalcrossgfxtriangle/window.h
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

66 lines
1.5 KiB
C++

// Copyright (C) 2020 The Qt Company Ltd.
// SPDX-License-Identifier: LicenseRef-Qt-Commercial OR BSD-3-Clause
#ifndef WINDOW_H
#define WINDOW_H
#include <QWindow>
#include <QtGui/private/qrhinull_p.h>
#if QT_CONFIG(opengl)
#include <QtGui/private/qrhigles2_p.h>
#include <QOffscreenSurface>
#endif
#if QT_CONFIG(vulkan)
#include <QtGui/private/qrhivulkan_p.h>
#endif
#ifdef Q_OS_WIN
#include <QtGui/private/qrhid3d11_p.h>
#include <QtGui/private/qrhid3d12_p.h>
#endif
#if defined(Q_OS_MACOS) || defined(Q_OS_IOS)
#include <QtGui/private/qrhimetal_p.h>
#endif
class Window : public QWindow
{
public:
Window(QRhi::Implementation graphicsApi);
void releaseSwapChain();
protected:
virtual void customInit();
virtual void customRender();
// destruction order matters to a certain degree: the fallbackSurface must
// outlive the rhi, the rhi must outlive all other resources. The resources
// need no special order when destroying.
#if QT_CONFIG(opengl)
std::unique_ptr<QOffscreenSurface> m_fallbackSurface;
#endif
std::unique_ptr<QRhi> m_rhi;
std::unique_ptr<QRhiSwapChain> m_sc;
std::unique_ptr<QRhiRenderBuffer> m_ds;
std::unique_ptr<QRhiRenderPassDescriptor> m_rp;
bool m_hasSwapChain = false;
QMatrix4x4 m_proj;
private:
void init();
void resizeSwapChain();
void render();
void exposeEvent(QExposeEvent *) override;
bool event(QEvent *) override;
QRhi::Implementation m_graphicsApi;
bool m_running = false;
bool m_notExposed = false;
bool m_newlyExposed = false;
};
#endif