| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
...in particular when doing multisampling with multiview.
With this the results are now identical with multiview and
multiview+MSAA on the Quest 3. (previously the depth buffer
was clearly broken when doing multiview+MSAA)
Change-Id: Iec3c6af66510ab76cb0591eb8d002aa5855a399e
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
| |
Also implement this for OpenGL ES since it can be relevant with tiled
architectures wrt performance.
Task-number: QTBUG-122669
Change-Id: I90dcfe4f5f9edbb8dfb51189d46b89ef2c7a7c06
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
| |
One is not enough, we have to have three code paths for three sets of
APIs/extensions.
Task-number: QTBUG-122669
Change-Id: Id10e19dfcfe16a8c21b6c932965f09539f061549
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have to be able to strip the _SRGB nonsense from the render target
view formats when rendering into textures that are provided from an
external engine (e.g. OpenXR) and are forced onto us with formats such
as VK_FORMAT_R8G8B8A8_SRGB.
This highlights some limitation of the current system, which has very
limited handling of sRGB stuff since proper renderers such as Qt Quick
3D have first class support for linearization and converting to sRGB
at the end of their shading pipeline, so _SRGB format textures are
never used in practice.
OpenGL has an issue which is different from everything else, namely
that we do not correctly do the glEnable/Disable on GL_FRAMEBUFFER_SRGB.
The QOpenGLExtensions flag is not what we need. We need to know if the
sRGB-conversion-on-write is supported or not, not that some framebuffer
is sRGB-capable. So do our own query based on the desktop and the ES
extension (GL_EXT_sRGB_write_control is something we never checked for,
but that is the appropriate GLES extension, supported on the Quest 3
for instance) This is now corrected in the gl backend. This means that
the colors will no longer be "too bright" with OpenGL ES and multiview
on the Quest 3 for example.
Unlike OpenGL, Vulkan and D3D automatically convert in shader reads and
writes when the shader resource view or the render target view has a
_SRGB format. (which we get by default since we pass on the texture
format) Getting a second linear->sRGB conversion on the already sRGB
data generated by e.g. Qt Quick 3D is just wrong.
Allow solving this by a new function that can be optionally called to
say we want (RGBA8, srgb=false), i.e. VK_FORMAT_R8G8B8A8_UNORM, for
the views.
Of course, reality is more complicated. D3D11 for instance does not
allow "casting" a fully typed texture, we'd need to use a _TYPELESS
format for that (possibly with other consequences), so skip D3D11.
For D3D12 this should work from Windows 1703 on.
Implementing for Metal is also left as a future exercise - it is neither
needed at the moment within Qt, nor is it trivial, because view textures
have to be created explicitly in Metal, normally we just work with the
MTLTexture as-is, not with views.
Task-number: QTBUG-122288
Task-number: QTBUG-122614
Change-Id: I8aea4e892b308d48f0bf18bdef481e460fbc9d47
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
| |
Change-Id: Ide7d16f56ba8a0a23d5c2e29da4dccedfb12ef1b
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
| |
[ChangeLog][RHI] Add support for short and ushort vertex attributes
Change-Id: I6111a02d442bbad2ec9667ac0336107dd3ab7b62
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
| |
...so that MSAA is actually effective.
Pick-to: 6.7 6.6
Change-Id: I4bf85df1312773ec29154a51c9c8464912e6ef8a
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Rendering into a multisample texture (color or depth-stencil) is
supported, but the code only seems to pick up the sample count from
renderbuffers.
Pick-to: 6.7 6.6
Change-Id: I95a97debfebc7582f2026282384f6fb97aadfe23
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
When reading pixels back from a QRhiTexture if the format is R16F/R32F
then we will read pixels to a buffer with just a red component comprised
of (half) floats instead of the default case (RGBA). This is useful when
reading back a shadow map.
Change-Id: Iff2881992f0341252d5c565b5dd64bed078319bc
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code should consider that image may be created by
a pointer to user data, with original alignments.
It means that we the way of setting parameters from
raw data and QImage should be the same.
In Qt Multimedia we want to pass a zero-copy image
to rhi creation to get rid of an extra copy:
codereview.qt-project.org/c/qt/qtmultimedia/+/537062
Aslo, data align has been fixed.
Due to the documentation, GL_UNPACK_ALIGNMENT can
be 8, 4, 2, 1. Let's find the biggest possible align.
Task-number: QTBUG-121934
Pick-to: 6.7 6.6 6.5
Change-Id: Ic0f1617d4699217a7549c13e916be96108183d03
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With ES 3.0 and up the GL_MAX_SAMPLES query is available and is
guaranteed to be at least 4.
With ES 2.0 there is no such query.
While what we report from supportedSampleCounts() has little
significance with OpenGL (for the window's color buffer it is
anyway the QSurfaceFormat that decides, not QRhi), QRhi users
such as Qt Quick may rely on supportedSampleCounts() returning
real values and may, for example, warn if the value attempted
to use is not in the supported list. (even if MSAA is fully
functional)
Avoid getting such warnings on a pure ES 2.0 implementation
with 4x at least.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-120474
Change-Id: I8a34a8bc9ce37ce951fdf7794247e8db44435d41
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Pick-to: 6.6 6.5
Fixes: QTBUG-119148
Change-Id: Ia119ab3ced9da08853c608aa256bde08a6fd8d4e
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
m_window->size() may have been rounded for devices
with DPI which results in a fractional DPR (e.g.
650 DPI / 160 DPI = 3.5 DPR). In this case scaling
by devicePixelRatio does not give the correct result.
Instead, use QPlatformWindow geometry and DPR to determine
the device size, without using the (possibly) rounded
device independent window size.
Fixes: QTBUG-87334
Pick-to: 6.6 6.5 6.2
Change-Id: I280236a06516cdb2a1a259fd0cfa8084c1ce7f46
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
| |
Doing glGenQueries every time the window (and so swapchain) is resized
is not great.
Change-Id: Ide1cf970d86dd5469b06633a3276c2130b030037
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
| |
Only for OpenGL 3.3+ (not ES).
Change-Id: I016ba934d7f5038b3d56f8d0c62e72b3921d86c6
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After fixing the data type for D24S8, we can now implement attaching
depth and stencil (with the same texture).
For Metal we need to set a stencil flag correctly.
This allows using D24S8 in the manual test, which is likely the format
that is going to be commonly used when setting up multiview with
Qt Quick.
Fixes: QTBUG-114904
Change-Id: Ife425c6cb3e09bfe40092c841b78f7a93bb6a4cd
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
| |
Pick-to: 6.6 6.5
Change-Id: I7aaaba49d0cc427c82e1ee4d0657b2992ffd4905
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cannot just do like with other APIs and expose a view of multiple
array layers. The only option is to use the multiview-specific API
and specify layers 0..view_count-1 in the depth texture.
This allows having depth in a multiview render pass with OpenGL.
Note that this does not cover stencil. D24S8 does not work, so
we may need to explore having a dedicated, separate stencil
texture.
Task-number: QTBUG-114896
Change-Id: I06ede1d77fef199148d595a55d144c96dc3cbc9d
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-114790
Change-Id: I295547576ff6fe45c8fe9d03ecd678d323b9ee30
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just handling attachments with a render buffer set and only one
attachment is not what other backends do. They support all attachments
and also the cases of multisample (2D) textures and multisample texture
arrays.
By extension this allows multisample 2D texture arrays. (GL 3.2+/GLES
3.1+) This was previously not working probably since the correct texture
target was never used.
Pick-to: 6.6
Change-Id: Ibe929faaf86824a596f9794240d1becc51f68e43
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
| |
Fixes: QTBUG-114770
Change-Id: Ibb1ced7f19d15a5116c60e95fd3e6b86ace63155
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
| |
Pick-to: 6.6
Change-Id: I2025d559be357a6825cdcae4cb0f0931a89864ab
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
...for Qt 5 compatibility. It seems both Qt Gui and Quick calls
the QOpenGLFramebufferObject helper for blitFramebuffer with
the default GL_NEAREST argument for the filtering. In Qt 6 we
must use the same if we want to ensure pixel-perfect compatibility.
Pick-to: 6.6 6.5
Task-number: QTBUG-113811
Change-Id: I03c69448265e7b0d73f021d71135a1725e96fcbc
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Buffer and texture sizes (size, pixelSize) may get increased, if needed,
but those actual sizes calculated by the QRhi backends are not written
back to the QRhiBuffer m_size or QRhiTexture m_pixelSize.
In contrast, both m_depth and m_arraySize are clamped in QRhiTexture
by most backends (to ensure a lower bound of 1 and 0, respectively).
This is not great since it means the getters for depth() and arraySize()
may return values different from what the user has provided. To avoid
confusion, do not modify the m_* variables.
Change-Id: I2cc5b9abf41ea108549ffd7f2403306e6e8ebba2
Reviewed-by: Jonas Karlsson <jonas.karlsson@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from
shadertools; done separately) become "RHI APIs", following the concept
of QPA APIs.
Mirror completely what is done for QPA headers, but using the "rhi"
prefix for the headers. This involves updating syncqt to handle the
new category of headers. (a note on the regex: matching everything
starting with "qrhi" is not acceptable due to incorrectly matching
existing and future headers, hence specifying the four header names
explicitly)
There is going to be one difference to QPA: the documentation for
everything RHI is going to be public and part of the regular docs, not
hidden with \internal.
In addition to the header renaming and adding the comments and
documentation notes and warnings, there is one significant change
here: there is no longer a need to do API-specific includes, such as
qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a
single header that is then included from qrhi.h. This means that users
within Qt, and any future applications can just do #include
<rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no
other headers are needed.
There are no changes to functionality in this patch. Only the
documentation is expanded, quite a lot, to eliminate all qdoc warnings
and make the generated API docs complete. An example, with a quite
extensive doc page is added as well.
Task-number: QTBUG-113331
Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
|
| |
Might fail with invalid enum in core profile contexts. The behavior
is the same regardless.
Pick-to: 6.5 6.2
Fixes: QTBUG-113289
Change-Id: I5e5764494be3c5f37537f5f9b3b5311d9c49def4
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Three is not enough, need four. This is because in core profile contexts
querying GL_MAX_VARYING_COMPONENTS may apparently be an error (this is
enforced in macOS with 4.1 core contexts for example), so we need to
use something else: GL_MAX_VERTEX_OUTPUT_COMPONENTS.
Change-Id: I005c30e5798b0bf8bb7666bd732aaf996d123db9
Pick-to: 6.5 6.2
Fixes: QTBUG-112985
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modeled after Metal's cb.GPUStart/EndTime. Implemented with timestamp
queries for other APIs.
Implemented for Metal, D3D11, Vulkan for now. No more callback, just
a getter on the command buffer which returns the latest known value,
referring to some previous frame. This makes it a lot more usable
than the original solution that is not really used anywhere at
the moment.
Now works for offscreen "frames" as well, this was not implemented
before.
Opt in with a new QRhi::create() flag because we cannot tell in
advance if the getter will be called or not, and this way we can
skip recording the timestamps by default. The cost is probably
minimal, though. Qt Quick will set this automatically when running
with QSG_RHI_PROFILE=1.
Change-Id: I903779984a4e0bbf1d03806d04bf61571ce23d72
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...even when the QRhi is already gone. This should not happen in
well-written applications and libraries, but we handle this
gracefully in the regular dtor and destroy() for resources that
register themselves to their creator QRhi, so by registering
everything we can offer this to all QRhiResource subclasses.
We still want to differentiate between native resource owning
QRhiResources and others (that do not create native graphics
objects), so do this via a flag passed to registerResource().
This way the behavior with QT_RHI_LEAK_CHECK=1 does not change.
Pick-to: 6.5
Fixes: QTBUG-112914
Change-Id: I9bafc81ef7a4ae76f356fc5f6248628d1f8791e0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
| |
Fixes: QTBUG-112756
Pick-to: 6.5 6.4 6.2
Change-Id: Id03bf805d70754818a98606b81a08a70d06853ba
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
| |
Change-Id: I1b14d3230ab4011506892c64ea03d5431d82a90d
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
|
|
|
|
| |
glBlitFramebuffer is affected by the scissor test.
Fixes: QTBUG-103792
Pick-to: 6.5 6.4 6.2
Change-Id: I2eccc9f3e469af8b2fdff22e9fb7c2311c25b867
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not just that these are not fatal, but some "errors" are
not actual errors, e.g. getting "Nothing to serialize" from Metal
is not something we care about.
Convert them from qWarning to qCDebug with our standard category,
so they still all show up when running with QSG_INFO=1, but won't
pollute the output for regular users. Even if a cache file cannot
be used or written, that's not something typical users care about.
Pick-to: 6.5
Fixes: QTBUG-110485
Change-Id: I63d815f7b95c4d6a4428497b7247811e860ebf04
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate 1D mipmap generation support from rendering into an 1D texture.
Those are two independent features, so have a separate feature flag for
both instead of using just one.
This will then be symmetric with the 3D texture features, where now we
have a new flag to report support for generating mipmap for 3D textures.
(whereas 3D texture as a render target is already covered by
RenderTo3DTextureSlice)
Change-Id: Ie5e1f056a7d1c341d90cd7fc522877a3f2da3290
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Runtime support is indicated via QRhi::Feature::HalfAttributes.
OpenGL support is available in OpenGL 3.0+, OpenGL ES 3.0+, and in
implementations that support the extension GL_ARB_half_float_vertex.
Other RHI backends (Vulkan, Metal, D3D11, and D3D12) all support this
feature.
Note that D3D does not support the half3 type. D3D backends pass half3
as half4.
tst_qrhi auto unit test included.
Change-Id: Ide05d7f62f6102ad5cae1b3681fdda98d52bca31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
| |
Change-Id: Iefcf06ffc251d160e838ae12729314b29d4f36a1
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for internal use, QRhiShaderResourceBinding does not need
to have the data() getters. The backends can use any internal means
to access this, no need to have the getters in the frontend just for
that.
Now, Qt Quick 3D has a special case of accessing this, hence keeping
the two getters for now, to be removed in a follow up once that repo
updates.
While we are at it, share and reuse the sorting function.
Change-Id: Ia2308af79863c72ca65024ce6c00531d0256a2cb
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Also bring all list-like data to the same level when it comes
to the interface exposed in QRhi*.
Change-Id: I90296a49ff1f52c1ce4e787167c99006fab3c4c3
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Once tessellation and geometry shader support is added, the check
makes no sense when there are additional stages between the vertex
and fragment stages.
Pick-to: 6.5 6.4
Change-Id: I3d3c0a5b338f5fe191c072a13a8699924f7a6a1b
Reviewed-by: Kristoffer Skau <kristoffer.skau@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
| |
Fixes: QTBUG-111007
Pick-to: 6.5
Change-Id: If1d84df56ad47ac89ea43ad5091392416fe9fc5f
Reviewed-by: Christian Strømme <christian.stromme@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>
|
|
|
|
|
|
|
|
|
|
|
| |
Doing so generates an error as this value for glEnable is
invalid with WebGL 2. The behavior is always as if this
was enabled. (unlike in GLES 3)
Task-number: QTBUG-107780
Pick-to: 6.4
Change-Id: I3fc34329fc573a6fac8e4265d90ca93520e4e2ee
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
If the last pipeline had a different stencil (write) mask, that
would affect the clear. That is not ideal.
Exercised by the upcoming stenciloutline manual tests.
Pick-to: 6.4 6.2
Change-Id: I925e85a2b7fb884e5ae9ed327b4b05c9bf36484b
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do not yet have a solution on the platform plugin level. All we can
tell so far is calling clearDrawable when making an Offscreen surface
current has unintended effects in certain situations. As well behaved
clients pass in a window when creating the QRhi, we can try to prefer
that in place of our QOffscreenSurface while the window is still
valid. However, to not potentially deoptimize on other platforms
(e.g. where surfaceless contexts are a thing), do this only for
macOS for now.
Fixes: QTBUG-107666
Change-Id: I23c7340a769f474712f7f6d7bb191c70aeec3924
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a combination of Q_UNREACHABLE() with a return statement.
ATM, the return statement is unconditionally included. If we notice
that some compilers warn about return after __builtin_unreachable(),
then we can map Q_UNREACHABLE_RETURN(...) to Q_UNREACHABLE() without
having to touch all the code that uses explicit Q_UNREACHABLE() +
return.
The fact that Boost has BOOST_UNREACHABLE_RETURN() indicates that
there are compilers that complain about a lack of return after
Q_UNREACHABLE (we know that MSVC, ICC, and GHS are among them), as
well as compilers that complained about a return being present
(Coverity). Take this opportunity to properly adapt to Coverity, by
leaving out the return statement on this compiler.
Apply the macro around the code base, using a clang-tidy transformer
rule:
const std::string unr = "unr", val = "val", ret = "ret";
auto makeUnreachableReturn = cat("Q_UNREACHABLE_RETURN(",
ifBound(val, cat(node(val)), cat("")),
")");
auto ignoringSwitchCases = [](auto stmt) {
return anyOf(stmt, switchCase(subStmt(stmt)));
};
makeRule(
stmt(ignoringSwitchCases(stmt(isExpandedFromMacro("Q_UNREACHABLE")).bind(unr)),
nextStmt(returnStmt(optionally(hasReturnValue(expr().bind(val)))).bind(ret))),
{changeTo(node(unr), cat(makeUnreachableReturn,
";")), // TODO: why is the ; lost w/o this?
changeTo(node(ret), cat(""))},
cat("use ", makeUnreachableReturn))
);
where nextStmt() is copied from some upstream clang-tidy check's
private implementation and subStmt() is a private matcher that gives
access to SwitchCase's SubStmt.
A.k.a. qt-use-unreachable-return.
There were some false positives, suppressed them with NOLINTNEXTLINE.
They're not really false positiives, it's just that Clang sees the
world in one way and if conditonal compilation (#if) differs for other
compilers, Clang doesn't know better. This is an artifact of matching
two consecutive statements.
I haven't figured out how to remove the empty line left by the
deletion of the return statement, if it, indeed, was on a separate
line, so post-processed the patch to remove all the lines matching
^\+ *$ from the diff:
git commit -am meep
git reset --hard HEAD^
git diff HEAD..HEAD@{1} | sed '/^\+ *$/d' | recountdiff - | patch -p1
[ChangeLog][QtCore][QtAssert] Added Q_UNREACHABLE_RETURN() macro.
Change-Id: I9782939f16091c964f25b7826e1c0dbd13a71305
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace, with manual
unstaging of the actual definition and documentation in dist/,
src/corelib/doc/ and src/corelib/global/.
Task-number: QTBUG-99313
Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is semantic patch using ClangTidyTransformator:
auto QtContainerClass = expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o)
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container'.
<classes> are:
// sequential:
"QByteArray",
"QList",
"QQueue",
"QStack",
"QString",
"QVarLengthArray",
"QVector",
// associative:
"QHash",
"QMultiHash",
"QMap",
"QMultiMap",
"QSet",
// Qt has no QMultiSet
Change-Id: Ibe8837be96e8d30d1846881ecd65180c1bc459af
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue a glFlush in endOffscreenFrame. This matches endFrame which
flushes either implicitly (swapBuffers) or explicitly with SkipPresent
(glFlush). This will then benefit producer-consumer setups where a
context renders into a texture using begin/endOffscreenFrame and then
the texture is consumed in another context.
In addition, make finish() issue a glFinish().
Pick-to: 6.4
Change-Id: I0a3115255ad2ac82b730e26d1ca7e88377c5a28c
Reviewed-by: Piotr Srebrny <piotr.srebrny@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...by removing the entire adjustedFormat() helper.
Qt Quick has never used this, which indicates it is not that
useful. Same goes for Qt Multimedia or Qt 3D. Ensuring depth and
stencil is requested is already solved by using
QSurfaceFormat::setDefaultFormat() or by adjusting the formats
everywhere as appropriate.
The helper function's usages are in the manual tests that use it as a
shortcut, and in the GL backend itself. Remove it and leave it up the
client to set the depth or stencil buffer size, typically in the
global default surface format. (which in fact many of the mentioned
manual tests already did, so some of calls to
window->setFormat(adjustedFormat()) were completely unnecessary)
By not having the built-in magic that tries to always force depth and
stencil, we avoid problems that arise then the helper cannot be easily
invoked (thinking of widgets and backingstores), and so one ends up
with unexpected stencil (or depth) in the context (where the GL
backend auto-adjusts), but not in the window (which is not under
QRhi's control).
It was in practice possible to trigger EGL_BAD_MATCH failures with the
new rhi-based widget composition on EGL-based systems. For example, if
an application with a QOpenGLWidget did not set both depth and stencil
(but only one, or none), it ended up failing due to the context -
surface EGLConfig mismatches. On other platforms this matters less due
to less strict config/pixelformat management.
Pick-to: 6.4
Change-Id: I28ae2de163de63ee91bee3ceae08b58e106e1380
Fixes: QTBUG-104951
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|