Having a simple Dear ImGui bridge is not just useful for the manual
tests, which do not have any other means to displays GUIs, but is
in itself an important exercise for the QRhi machinery.
Have a new manual test that exercises the built-in ImGui demo window.
Then use it in the displacement test for real, to replace the myriads
of key presses with on-screen sliders and checkboxes (with less code).
Change-Id: I296bafae2a5cce6fc7a447d97e68e5bcec15f451
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
There is something odd when running on Metal: note how the uv
is vec3 instead of vec2, in order to make the vertex-tesc-tese
data to look like this:
struct main0_out
{
float3 out_uv;
float3 out_normal;
float4 gl_Position;
};
if out_uv was float2 we'd get some strange rendering results,
perhaps due to something related to alignment. But have no means
to investigate this further.
Change-Id: I79d4edb2ddde3971c599c4326d98e99a49aa7122
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Support for 1D textures on Vulkan, OpenGL, Metal, and D3D.
Change-Id: Ie74ec103da9cfcbf83fa78588cf8cfc1bd6e104f
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Setting the flag QSurfaceFormat::StereoBuffers does not actually do
anything, because we do not utilize the extra buffers provided. We need
to expose setting the correct buffers using glDrawBuffers between draw
calls.
Change-Id: I6a5110405e621030ac3a2886fa83df0cfe928723
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Interesting on its own just because it exercises stencil testing,
unlike any of the other existing manual tests.
In addition it serves as a base example for how outlines could be
done, it is one possible approach at least. (render with stencil
write, then render again slightly scaled up with a solid color with
testing against the stencil buffer content)
Change-Id: I0c845a9004136f229cab037f6f0aab2f772bdd76
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
QPlatformTextureList holds a QRhiTexture instead of GLuint. A
QPlatformBackingStore now optionally can own a QRhi and a
QRhiSwapChain for the associated window. Non-GL rendering must use
this QRhi everywhere, whereas GL (QOpenGLWidget) can choose to still
rely on resource sharing between contexts. A widget tells that it
wants QRhi and the desired configuration in a new virtual function in
QWidgetPrivate returning a QPlatformBackingStoreRhiConfig. This is
evaluated (among a top-level's all children) upon create() before
creating the repaint manager and the QWidgetWindow.
In QOpenGLWidget what do request is obvious: it will request an
OpenGL-based QRhi. QQuickWidget (or a potential future QRhiWidget)
will be more interesting: it needs to honor the standard Qt Quick
env.vars. and QQuickWindow APIs (or, in whatever way the user
configured the QRhiWidget), and so will set up the config struct
accordingly.
In addition, the rhiconfig and surface type is (re)evaluated when
(re)parenting a widget to a new tlw. If needed, this will now trigger
a destroy - create on the tlw. This should be be safe to do in
setParent. When multiple child widgets report an enabled rhiconfig,
the first one (the first child encountered) wins. So e.g. attempting
to have a QOpenGLWidget and a Vulkan-based QQuickWidget in the same
top-level window will fail one of the widgets (it likely won't
render).
RasterGLSurface is no longer used by widgets. Rather, the appropriate
surface type is chosen.
The rhi support in the backingstore is usable without widgets as well.
To make rhiFlush() functional, one needs to call setRhiConfig() after
creating the QBackingStore. (like QWidget does to top-level windows)
Most of the QT_NO_OPENGL ifdefs are eliminated all over the place.
Everything with QRhi is unconditional code at compile time, except the
actual initialization.
Having to plumb the widget tlw's shareContext (or, now, the QRhi)
through QWindowPrivate is no longer needed. The old approach does not
scale: to implement composeAndFlush (now rhiFlush) we need more than
just a QRhi object, and this way we no longer pollute everything
starting from the widget level (QWidget's topextra -> QWidgetWindow ->
QWindowPrivate) just to send data around.
The BackingStoreOpenGLSupport interface and the QtGui - QtOpenGL split
is all gone. Instead, there is a QBackingStoreDefaultCompositor in
QtGui which is what the default implementations of composeAndFlush and
toTexture call. (overriding composeAndFlush and co. f.ex. in eglfs
should continue working mostly as-is, apart from adapting to the
texture list changes and getting the native OpenGL texture id out of
the QRhiTexture)
As QQuickWidget is way too complicated to just port as-is, an rhi
manual test (rhiwidget) is introduced as a first step, in ordewr to
exercise a simple, custom render-to-texture widget that does something
using a (not necessarily OpenGL-backed) QRhi and acts as fully
functional QWidget (modeled after QOpenGLWidget). This can also form
the foundation of a potential future QRhiWidget.
It is also possible to force the QRhi-based flushing always,
regardless of the presence of render-to-texture widgets. To exercise
this, set the env.var. QT_WIDGETS_RHI=1. This picks a
platform-specific default, and can be overridden with
QT_WIDGETS_RHI_BACKEND. (in sync with Qt Quick) This can eventually be
extended to query the platform plugin as well to check if the platform
plugin prefers to always do flushes with a 3D API.
QOpenGLWidget should work like before from the user's perspective, while
internally it has to do some things differently to play nice and prevent
regressions with the new rendering architecture. To exercise this
better, the qopenglwidget example gets a new tab-based view (that could
perhaps replace the example's main window later on?). The openglwidget
manual test is made compatible with Qt 6, and gets a counterpart in form
of the dockedopenglwidget manual test, which is a modified version of
the cube example that features dock widgets. This is relevant in
particular because render-to-texture widgets within a QDockWidget has
its own specific quirks, with logic taking this into account, hence
testing is essential.
For existing applications there are two important consequences with
this patch in place:
- Once the rhi-based composition is enabled, it stays active for the
lifetime of the top-level window.
- Dynamically creating and parenting the first render-to-texture
widget to an already created tlw will destroy and recreate the tlw
(and the underlying window). The visible effects of this depend on the
platform. (e.g. the window may disappear and reappear on some,
whereas with other windowing systems it is not noticeable at all -
this is not really different from similar situtions with reparenting
or when moving windows between screens, so should be acceptable in
practice)
- On iOS raster windows are flushed with Metal (and rhi) from now on
(previously this was through OpenGL by making flush() call
composeAndFlush().
Change-Id: Id05bd0f7a26fa845f8b7ad8eedda3b0e78ab7a4e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
.. but this will only be supported on Vulkan, OpenGL 3.2+, and Open GL
ES 3.2+ for the time being.
The situation is:
- Vulkan is working. qsb accepts .geom files already, and QShader has
existing geometry shader support.
- OpenGL 3.2 and OpenGL ES 3.2 are working.
- D3D11 is not working. D3D11 supports geometry shaders, but SPIRV-
Cross does not support translating geometry shaders to HLSL.
- Metal is not working. Metal does not directly support geometry
shaders.
Change-Id: Ieb7c44c58b8be5f2e2197bf5133cf6847e6c132d
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Support for Polygon Mode (Triangle Fill Mode in Metal, Fill Mode in D3D)
in the RHI graphics pipeline.
Options are Fill and Line
Status:
OpenGL - ok
Vulkan - ok
Metal - ok
D3D11 - ok
OpenGL ES - does not support glPolygonMode.
Change-Id: I20b7ef416624700c3dc8d1cbe6474f4ca3889db8
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
...but this will only be supported with Vulkan and OpenGL 4.0+ and
OpenGL ES 3.2+ for the time being.
Taking the Vulkan model as our standard, the situation is the
following:
- Vulkan is ok, qsb secretly accepts .tesc and .tese files as input
already (plus QShader already has the necessary plumbing when it
comes to enums and such) To switch the tessellation domain origin to
bottom left we require Vulkan 1.1 (don't bother with
VK_KHR_maintenance2 on top of 1.0 at this point since 1.1 or 1.2
implementations should be common by now). The change is essential to
allow the same evaluation shader to work with both OpenGL and
Vulkan: this way we can use the same shader source, declaring the
tessellation winding order as CCW, with both APIs.
- OpenGL 4.0 and OpenGL ES 3.2 (or ES 3.1 with the Android extension
pack, but we won't bother with checking that for now) can be made
working without much complications, though we need to be careful
when it comes to gathering and setting uniforms so that we do not
leave the new tessellation stages out. We will stick to the Vulkan
model in the sense that the inner and outer tessellation levels must
be specified from the control shader, and cannot be specified from
the host side, even though OpenGL would allow this. (basically the
same story as with point size in vertex shaders)
- D3D11 would be no problem API-wise, and we could likely implement
the support for hull and domain shader stages in the backend, but
SPIRV-Cross does not support translating tessellation shaders to
HLSL. Attempting to feed in a .tesc or .tese file to qsb with
--hlsl specified will always fail. One issue here is how hull
shaders are structured, with the patchconstantfunc attribute
specifying a separate function computing the patch constant
data. With GLSL there is a single entry point in the tessellation
control shader, which then performs both the calculations on the
control points as well as the constant data (such as, the inner and
outer tessellation factors). One option here is to inject
handwritten HLSL shaders in the .qsb files using qsb's replace (-r)
mode, but this is not exactly a viable universal solution.
- Metal uses a different tessellation pipeline involving compute
shaders. This needs more investigation but probably not something we
can prioritize in practice. SPIRV-Cross does support this,
generating a compute shader for control and a (post-)vertex shader
for evaluation, presumably in order to enable MoltenVK to function
when it comes to tessellation, but it is not clear yet how usable
this is for us.
Change-Id: Ic953c63850bda5bc912c7ac354425041b43157ef
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The system we inherited from the original Qt 5.14 introduction of QRhi
is a text stream based solution where resource creation and frame
timings are sent in a comma-separated format to a QIODevice.
This, while useful to get insights about the number of resources at a
given time, is not actively helpful. The frameworks built on top (Qt
Quick, Qt Quick 3D) are expected to provide solutions for logging
timings in a different way (e.g. via the QML Profiler). Similarly,
tracking active resources and generating statistics from that is
better handled on a higher level.
The unique bits, such as the Vulkan memory allocator statistics and
the GPU frame timestamps, are converted into APIs in QRhi. This way a
user of QRhi can query it at any time and do whatever it sees fit with
the data.
When it comes to the GPU timestamps, that has a somewhat limited value
due to the heavy asynchronousness, hence the callback based
API. Nonetheless, this is still useful since it is the only means of
reporting some frame timing data (an approx. elapsed milliseconds for
a frame) from the GPU side.
Change-Id: I67cd58b81aaa7e343c11731f9aa5b4804c2a1823
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Arrays of textures have always been supported, but we will encounter
cases when we need to work with texture array objects as well.
Note that currently it is not possible to expose only a slice of the
array to the shader, because there is no dedicated API in the SRB,
and thus the same SRV/UAV (or equivalent) is used always, capturing
all elements in the array. Therefore in the shader the last component
of P in texture() is in range 0..array_size-1.
Change-Id: I5a032ed016aeefbbcd743d5bfb9fbc49ba00a1fa
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Supported on OpenGL (and ES) 3.0+ and everywhere else.
Can also be a render target, targeting a single slice at a time.
Can be mipmapped, cannot be multisample.
Reading back a given slice from a 3D texture is left as a future
exercise, for now it is documented to be not supported.
Upload is going to be limited to one slice in one upload entry,
just like we specify one face or one miplevel for cubemap and
mipmapped textures.
This also involves some welcome hardening of how texture subresources
are described internally: as we no longer can count on a layer index
between 0..5 (as is the case with cubemaps), simply arrays with
MAX_LAYER==6 are no longer sufficient. Switch to sufficiently dynamic
data structures where applicable.
On Vulkan rendering to a slice needs Vulkan 1.1 (and 1.1 enabled on the
VkInstance).
Task-number: QTBUG-89703
Change-Id: Ide6c20124ec9201d94ffc339dd479cd1ece777b0
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Draw 25000 cubes while doing a uniform buffer update for each.
Change-Id: I2216641c8bf7c6ea147fe3edd679317b472e1f04
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
