Some of the offsets are already quint32 in the API (vertex input
attributes, dynamic offsets, offsets in draw calls), matching the
reality of the underlying 3D APIs, but many buffer-related functions
use int as of now, simply because that used to be the default choice,
and the same goes for sizes (such as buffer or range sizes). This is
not quite consistent and should be cleaned up if for nothing else then
just to make the classes consistent, but also because no 3D API use a
signed type for offsets, sizes, and strides. (except OpenGL for some)
When it comes to strides (for vertex inputs and raw image texture
uploads), those are already all quint32s. This is straightforward
because most of the 3D APIs use 32-bit uints for these regardless of
the architecture.
Sizes and offsets are often architecture-dependent (Vulkan, Metal),
but there is at least one API where they are always 32-bit even on
64-bit Windows (UINT == unsigned int, D3D11). In addition, we do not
really care about buffer or texture data larger than 4 GB, at least
not without realistic use cases and real world testing, which are
quite unlikely to materialize for now (esp. since we still have the
width/height of 2D textures limited to 16 or 32K in many cases even on
desktops, whereas 2GB+ buffers are not guaranteed in practice even
when an API seemingly allows it).
In any case, the important change here is the signed->unsigned
switch. A number of casts can now be removed here and there in the
backends, because the offsets and sizes are now unsigned as well,
matching the underlying API reality. The size can be potentially
increased later on with minimal effort, if that becomes necessary for
some reason.
Change-Id: I404dbc365ac397eaeeb3bd2da9ce7eb98916da5f
Reviewed-by: Inho Lee <inho.lee@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
...that uses the old name after a recent change in the
name of a function.
Change-Id: Ife36fbb0c5d28b350cb1cfc48625528a205af8f9
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
This convenience should be, according to the Apple docs, equivalent to
calling present from a scheduled handler. (which on its own makes it
unclear why we switched in the first place)
In practice it seems the two approaches are not identical. It looks
like that once a frame is submitted earlier than the next display link
callback, the throttling behavior we implement in beginFrame()
(waiting on the semaphore for the completion of the appropriate
command list etc.) starts exhibiting unexpected behavior, not
correctly throttling the thread to the refresh rate. Changing back to
presentDrawable does not exhibit this at all.
The suspicion is that presentDrawable is probably doing more than what
the docs suggest, and so is not fully equivalent to calling present
manually from a scheduled handler.
Therefore, switch to presentDrawable now, which restores the expected
cross-platform behavior, but make a note of the oddity, and also
prepare the hellominimalcrossgfxtriangle manual test to provide an
easy, self-contained application to allow experimenting in the future,
if needed.
This allows Qt Quick render thread animations to advance at the
expected speed (because the render thread is correctly throttled to
the refresh rate), even if the render thread decides to generate a new
frame right away, without waiting for the next display link update.
Without this patch, attempting to get updates not via requestUpdate(),
but by other means (timer etc.) leads to incorrect throttling, and so
the triangle in the test app is rotating faster than expected - but
only with Metal. Running with OpenGL on macOS or with any API on any
other platform the behavior will be correct. Even if scheduling
updates without display link is not efficient, and should be
discouraged, not doing so cannot break the core contract of vsync
throttling, i.e. the thread cannot run faster just because it renders
a frame not in response to an UpdateRequest.
Amends 98b60450f7 (effectively reverts
but keeps the code and the notes because we might want to clear this
up some day)
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-103415
Change-Id: Id3bd43e94785384142337564ce4b2644bf257100
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
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>
Mainly because we do have legacy code in the Qt 5 graphical effects that
tries to dynamically determine the max number of varyings. Make it
easier to port such code.
Change-Id: I846cab2c2fe7b4cd473b5ced0146ca36f1c8169b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@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>
QT_VERSION is now at least QT_VERSION_CHECK(6, 3, 0), so remove all
checks against Qt 6.0.0 or earlier. They are superfluous. Tidied up in
some places in the process, particularly #include order.
Change-Id: I2636b2fd13be5b976f5b043ef2f8cddc038a72a4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
Add QRhi APIs to retrieve and reload the contents of the "pipeline
cache".
The only API where there is a true pipeline cache is object is Vulkan
(VkPipelineCache). For OpenGL, the other backend where we support this,
it is simulated with program binaries. The Qt 5 style OpenGL program
binary disk cache continues to work like before, but one has now the
option to do things in a more modern, graphics API agnostic way, that
leads to generating a single blob instead of a large set of files in
some system location, allowing easier "pre-baking" of the cache content.
It is expected that Qt Quick exposes the two new functions in form
if QSG_RHI_ environment variables, thus allowing easy testing and
cache file generation.
As an example for the performance improvements this can give, consider
Vulkan, where we do not have any existing persistent caching mechanism
in place:
Running BenchmarkDemoQt6.exe --scene flythrough --mode demo creates 18
QRhiGraphicsPipeline objects from Qt Quick and Qt Quick 3D.
The total time spent in QRhiGraphicsPipeline::create() during application
startup for these 18 pipelines is 35-40 ms on a given Windows (NVIDIA)
system.
When exporting the pipeline cache contents to a file, and then, in a
subsequent run, reloading the cache contents, this is reduced to 5-7 ms
on the same system, meaning we get a 6-7x improvement.
The generated data is always specific to a given Qt version, RHI
backend, graphics device, and driver version. Much of the implementation
consists of adding and verifying the appropriate header to the blobs
retrieved from the driver, to allow gracefully ignoring data that was
generated with a device or driver that differs from the one used at
run time. This should provide robustness, even if the Vulkan or OpenGL
implementation is for some reason not prepared to identity and reject
incompatible cache/program blobs.
Fixes: QTBUG-90398
Change-Id: I67b197f393562434f372c7b7377f638abab85cb3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Instead, have a static function in QRhiVulkanInitParams then Qt Quick
and anyone else who creates a QVulkanInstance that is then used in
combination with QRhi can query.
Change-Id: I046e0d84541fc00f5487a7527c97be262221527f
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Just to avoid validation warnings on systems where the sampling
a D32 texture with linear filtering is not supported.
This is likely not a problem elsewhere: Qt Quick 3D for example
samples the depth texture only with Nearest filtering already.
Fixes: QTBUG-89761
Pick-to: 6.0
Change-Id: I80bf5b7ecfcb3365f4010daa17f2ef00bb206b74
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Even though there is no D3D-specific logic in the windows platform
plugin, meaning a QWindow with either OpenGLSurface or VulkanSurface
(or anything really) is DXGI/D3D-compatible, it now looks like it is
beneficial, and more future proof, if there is a dedicated surface
type.
As the linked report shows, there are OpenGL-specific workarounds
accumulated in the platform plugin, while not being clear if these
are relevant to non-OpenGL content, or if they are relevant at all
still. (and some of these can be difficult/impossible to retest and
verify in practice)
When D3D-based windows use the same surface type, all these are
active for those windows as well, while Vulkan-based windows have
their own type and so some of these old workarounds are not active
for those. To reduce confusion, having a dedicated surface type for
D3D as well allows the logic to skip the old OpenGL workarounds,
giving us (and users) a more clear overall behavior when it comes
to OpenGL vs. Vulkan vs. D3D.
The change is compatible with any existing code in other modules
because any code that uses OpenGLSurface for D3D will continue to
work, using the new type can be introduced incrementally.
Task-number: QTBUG-89715
Change-Id: Ieba86a580bf5a3636730952184dc3a3ab7669b26
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with
move semantics, its name is misleading. Q_RELOCATABLE_TYPE was
introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE
is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE
by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this
patch should have no impact on users.
Pick-to: 6.0
Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
In order to prevent too much voodoo in backends like D3D11, the input
layout is expected to specify the slice index for vecX that are part of
an unrolled matrix.
Also deoptimize the instancing manual test to exercise a matrix too
instead of just vectors.
Change-Id: If2dcbcbc483645ce2420b2f87dda765b95da6e80
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The original restriction to UniformBuffer was due to the GL backend
where there is no GL buffer object for QRhiBuffers with usage
UniformBuffer. However, we can still implement this for cases when
there is a true GL buffer object underneath. With other backends it
should all work as-is already.
This becomes useful when one has buffers with usage Vertex that need
full updates every frame. (f.ex. instance data)
Unfortunately this involves renaming the function. But while at it, add
an autotest case as well.
Change-Id: Iff59e4509a8bae06654cc92fe8428bd79eb012fb
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The qsb files seem to be out of date for those two.
Change-Id: Id832e872667cac4d364e13c440011109a6dbdc7f
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>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
As OpenGL ES and Vulkan ruin the day with the spec mandated minimum
value for max threads per threadgroup being only 128, clients need
a way to decide if their compute shader (local_size_*) is suitable
for use at run time.
Change-Id: I72b4fc97032406340623add82ea4d9544ebe9fdc
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This attribute is now on by default.
Change-Id: I7c9d2e3445d204d3450758673048d514bc9c850c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
...now that a recent path enables MultisampleTextures for ES >= 3.1 and
GL 3.x and up.
Just need to make sure the .qsb contains something for OpenGL as well.
While we are at it, make updated .qsb files for all the commonly used
shaders since what we had before was version 4. Bump them to version 5.
Change-Id: If2040f4894e6360d1ebd5daf7e698508e5e6e42e
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The QPair changes trigger warnings about size_t vs. quint32.
We made offsets and sizes 32-bit in the QRhi API to emphasize that
some of the graphics APIs are using 32-bit sizes still. It's a bit
unfortunate that pairs now generate warnings when the size does not
match. Just cast as needed.
Change-Id: I88504eed8be6f4bdb2205b3671e2c2a9db9fcb1e
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
For historical reasons we use build and release instead of create and
destroy. This becomes confusing now that more modules in Qt start taking
QRhi into use. Migrate to the more familiar naming, so those who have
used QWindow or QOpenGLContext before will find it natural.
Change-Id: I05eb2243ce274c59b03a5f8bcbb2792a4f37120f
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
When storing a void* pointer to the texture handle, we had
to ensure that the variable would exist until the build phase,
which is error prone and caused errors in QQuickWidget because
we copied the texture ID from the FBO into a local variable
before passing it into QQuickWindow::setRenderTarget().
The reason for using a void* was that we cannot know the width
of the handles in the different backends, but we do know that
they are 64-bit at maximum, so instead of storing potentially
dangling pointers, we just make it a 64-bit integer and cast
it back and forth in the backends.
Task-number: QTBUG-78638
Change-Id: I7951e24351ddb209045ab6197d81eb1290b4da67
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Conflicts:
tests/manual/rhi/hellominimalcrossgfxtriangle/CMakeLists.txt
Hopefully final merge from wip/cmake, and then all cmake changes
should target dev directly.
Change-Id: I29b04c9b0284e97334877c77a32ffdf887dbf95b
Conflicts:
examples/widgets/graphicsview/boxes/scene.h
src/corelib/Qt5CoreMacros.cmake
src/corelib/Qt6CoreMacros.cmake
src/network/ssl/qsslsocket.cpp
src/network/ssl/qsslsocket.h
src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp
src/testlib/CMakeLists.txt
src/testlib/.prev_CMakeLists.txt
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
Disabled building manual tests with CMake for now, because qmake
doesn't do it, and it confuses people.
Done-With: Alexandru Croitor <alexandru.croitor@qt.io>
Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
This particular test may serve as sample code in various materials in
the future, therefore it is highly beneficial if it is kept in good shape.
Make it easier to read, more compact, and split up among the natural
boundaries of the functionality (global setup in main, window+swapchain
management in Window, graphics resource setup and draw call recording
in HelloWindow).
Change-Id: I2451d3961a01131dcbffe66baf23d2cf9bfd077f
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
They are now version 4, which is hopefully the final format,
relying on nothing but QDataStream.
Except for the qshader autotest which tests all the 1..4 versions
and so needs appropriate test data.
Also unifies the batch file naming.
Change-Id: Iec478be86d14dbec7ffb9d5f9b62c14fca5d7c9e
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
What's more, demonstrate two types of rendering to a cubemap:
one by one to each face, and by attaching all faces as color
attachments in one go.
Both are used by Qt Quick 3D in connection with shadows, so this
proves that the same is possible to implement with QRhi.
Task-number: QTBUG-81261
Change-Id: I5c7077224d7cae0dd6ea02ac30a9e6f9f1f0c229
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Uses the two compute shaders from Qt Quick 3D. Demonstrates
and tests both RGBA16F textures and using them (and doing
load/store with mip levels individually) in combination with
compute.
Task-number: QTBUG-81213
Change-Id: I3f0f250d5997a26c857b7c45517684c63b44e58e
Reviewed-by: Johan Helsing <johan.helsing@qt.io>
