| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike renderbufferStorage, renderbufferStorageMultisample is not
guaranteed to accept the unsized GL_DEPTH_STENCIL internalformat. For the
former, WebGL 2 guarantees it for compatibility for WebGL 1, but the
multisample version does not exist in WebGL 1, so from the specs it is not
given at all that the unsized format would be accepted. So use the ES 3.0
sized format instead, like we would on a "real" ES 3.0 implementation.
Fixes: QTBUG-80296
Change-Id: I822ae382097085c0a3279c16bb69a173dbf15093
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
Defers initialization until actually needed.
Change-Id: Idb09dbad0dfa602949d381ee61565d9050e77e7c
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-79221
Change-Id: Ie8e6376f79c816071c12962dc054838aeaabcaa5
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the source size is not explicitly specified, we take the entire
subresource. However, just using the texture's size is wrong: when the
source level in a copy or readback is not 0, the size for the corresponding
mip level has to be used instead.
This fixes occasional crashes with Metal in the autotest.
Change-Id: I99f689feef93ec86dffdc9e82d6bfdaf5c1eb041
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
| |
Also improve (docs and runtime checks) and test the minimum set
of required data to create a graphics pipeline.
Task-number: QTBUG-78971
Change-Id: If5c14f1ab1ff3cf70f168fde585f05fc9d28ec91
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
| |
The joys of "level - Specifies the mipmap level of the texture
image to be attached, which must be 0." for glFramebufferTexture2D
in OpenGL ES 2.0.
Change-Id: Iaf19502f48d7ba73b26abb72535bfa6696a1e182
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use only APIs that are in GLES 3.0.
glMapBuffer() is an old OES extension, stop bothering with that.
Not the least because ANGLE claims supporting it and then fails the
map. (not that we care much about ANGLE, but, for instance, the qrhi
autotest is run with ANGLE configurations as well in the CI, so have
to still take care of it for the duration of Qt 5.x)
Change-Id: I29140402cedffe0430f920ee0c061673257c3aa1
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
...and make the Null backend able to deal with these, for RGBA8 textures
at least. Naturally it is all QImage and QPainter under the hood.
Also fix a bug in the OpenGL backend, as discovered by the autotest:
the size from the readback did not reflect the mip level.
Task-number: QTBUG-78971
Change-Id: Ie424b268bf5feb09021099b67068f4418a9b583e
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also marks the beginnings of significantly extending autotesting
of the resource and rendering functionality in QRhi.
Also involves fixing up the buffer operation lists like we did
for textures before. This is to ensure updates and reads on the
same batch execute in the correct order. So just have two lists:
one with buffer, one with texture operations.
Also simplify the struct layouts. No need for those inner structs
with many duplicate members. This reduces the size even, since using a
union was never an option here. Also switch to a VLA, the size is around
253 KB per batch.
The Null backend now keeps track of the QRhiBuffer data so it can return
valid results in readbacks.
Task-number: QTBUG-78984
Task-number: QTBUG-78986
Task-number: QTBUG-78971
Task-number: QTBUG-78883
Change-Id: I9694bd7fec523a4e71cf8a5c77c828123ebbb3bd
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Triangle fan drawing is only supported on some platforms. The feature
flag QRhi::TriangleFanTopology is set accordingly.
In general, TriangleStrip topology will be more efficient on most GPUs.
However, if polygon data is already stored as triangle fans, the CPU
savings may be more significant.
Change-Id: I9704fad751d2119eac8791074f58942dd9315601
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As usual, keep some QVector overloads around to allow Qt Quick to compile.
Color attachments and vertex input bindings get an at(index) type of
accessor, unlike any other of similar lists. This is because there the
index is significant, and sequential iteration is not the only type of
operation that is performed. Sometimes a lookup based on an index will
be needed as well.
Task-number: QTBUG-78883
Change-Id: I3882941f09e94ee2f179e0e9b8161551f0d5dae7
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-78862
Change-Id: If278bd55530081cbbdbab8dd6e14d86e28da558e
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sad to see this go since the d pointer pattern with implicit sharing
would have been perfect for this class, had this been a public API.
However, as binary compatibility will not be a concern for QRhi classes,
it is wasteful to allocate memory on every QRhiShaderResourceBinding.
This allows users, such as Qt Quick, to use QRhiShaderResourceBinding as
a cheap, simple, value class, without having to invent their own
alternatives in performance critical places.
The change brings a not insignficant improvement in certain qmlbench scenes
(the ones with thousands of unbatched geometry nodes).
Change-Id: I6d1dced6498d9ad625f90ead78bc0a417ea99ed8
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The expectation for it is to function identically to what we get with
QOpenGLShaderProgram. (same environment variables, same logging
categories, etc.).
QOpenGLProgramBinaryCache is now shared between the QOpenGL convenience
classes (like QOpenGLShaderProgram) and QRhi. To achieve more modularity
and to prepare for QOpenGLShaderProgram and friends moving out of QtGui,
this class cannot depend on QOpenGLShader* anymore. This involves adding
some minor conversions between QRhi and QOpenGL enums for example.
Change-Id: I2f4664e074823ea536281aea8006a6db159a7381
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert surfacePixelSize() to be a getter only. With Metal this will
mean returning the "live" layer size (and so not the
layer.drawableSize), which is in line with what we expect with other
backends.
Instead, we leave it to the swapchain's buildOrResize() to "commit"
the size by setting drawableSize on the layer. With typical
application or Qt Quick logic this ensures that layer.drawableSize is
set once and stays static until we get to process the next resize - on
the rendering thread.
This of course would still mean that there was a race when a client
queries surfacePixelSize() to set the depth-stencil buffer size that
is associated with a swapchain. (because that must happen before
calling buildOrResize() according to the current semantics)
That can however be solved in a quite elegant way, it turns out,
because we already have a flag that indicates if a QRhiRenderBuffer is
used in combination with (and only in combination with) a
swapchain. If we simply say that setting the UsedWithSwapChainOnly
flag provides automatic sizing as well (so no setPixelSize() call is
needed), clients can simply get rid of the problematic
surfacePixelSize() query and everything works.
Task-number: QTBUG-78641
Change-Id: Ib1bfc9ef8531bcce033d1f1e5d4d5b4984d6d69f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
|
|
|
|
|
| |
Change-Id: I5408e53f90c1c19836c400659bac15a8690c6ae8
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
This was visible in the triquadcube test when enabling transparent window
background: the cube on the left was rendered incorrectly because alpha
was not written out due to not setting glColorMask() back to the defaults
when switching to another pipeline.
Change-Id: I7a8c94072e0b68a58fffcc8c1a200e3940dcad44
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With OpenGL a scissor (or viewport) rectangle is not allowed to have a negative
width or height. Everything else is allowed. This is also the semantic we wish to
keep for QRhiViewport and QRhiScissor.
This raises some problems. For instance, when we do bottom-left - top-left
rectangle conversion, the case of partially out of bounds rects needs to be
taken into account.
Otherwise, Qt Quick ends up in wrong scissoring in certain cases, typically when
the QQuickWindow size is decreased so the content does not fit because that will
then start generating negative x, y scissors for clipping (which is perfectly
valid but the QRhi backends need to be able to deal with it)
Then there is the problem of having to clamp width and height carefully, because
some validation layers for some APIs will reject a viewport or scissor with
partially out of bounds rectangles.
To verify all this, add a new manual test, based on the cubemap one. (cubemap was
chosen because that is an ideal test scene as it fills the viewport completely, and
so it is visually straightforward when a scissor rectangle is moving around over it)
Fixes: QTBUG-78702
Change-Id: I60614836432ea9934fc0dbd0ac7e88931f476542
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
| |
...and change the return value of makeThreadLocalNativeContextCurrent() to
a bool since we expect this to mirror QOpenGLContext::makeCurrent().
Change-Id: I339507152e461fe28fcf7fe777165e6d0072f055
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
| |
Starting with D3D11. The other backends will follow later.
Change-Id: I4f165c9f1743df0fb00bdce1e898917575bf5f6e
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
| |
Change-Id: I9a632c06d8b9e666d99d0f135d3396d2de03f92a
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When interfacing with reality (i.e. native platform APIs provided in C,
ObjC, or COM), each of the APIs has its own idea of what types it likes
to use for sizes, points, rects, etc.
Out of the hundreds of warnings Qt Creator throws at us with the default
clang check level when opening one of the rhi backends not a single one
is useful. Regardless, let's try getting rid of what we can. This mostly
involves throwing in int/uint conversions in order to get the signedness
change warnings to shut up. The things that are either unacceptable to
change or are beyond our control are left untouched.
Change-Id: I6e4cb7cd373bf48dc990eaf83344242bbf30bd66
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that Qt Quick's batch renderer misses one level of shader source
caching due to the nature of pipeline state objects, it can be useful
to keep and reuse shader objects when the hash of the source code
matches.
The goal here is to allow Qt Quick to be on par with what the direct
OpenGL path has when it comes to caching shader sources and compilation
results. The program binary disk cache is not in scope in this patch.
Also adds QRhi::releaseCachedResources(), similarly to what the scenegraph
has. This can be called to clear caches such as the shader object
cache we keep here.
Change-Id: Ie3d81d823f61fa65ec814439e882c498f7774d43
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
As an option. Must opt in via setting ExternalContentsInPass in
the flags for beginFrame(). It is somewhat unfortunate to require
declaring this up front, but forcing using secondary command buffers
always, even though beginExternal() may not be used in many applications,
would be an overkill.
Change-Id: I8d52bcab40c96f89f140c4c7877b6c459925e3c7
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mainly for Vulkan where it lacked the recording of the still queued
commands. Uncovered by Qt Quick examples that integrate custom Vulkan
rendering.
This still has an issue that needs to be tackled separately. (we probably
will switch to using a dedicated secondary command buffer with
RENDER_PASS_CONTINUE_BIT for the external commands, and then just have
a vkCmdExecuteCommands in our own queue instead of recording everything in
beginExternal).
The possibility of losing glMemoryBarrier() calls due to begin/endExternal()
with the OpenGL backend is fixed too. The logic here mirrors Vulkan
to some extent except that we do not have a concept of (and so the trouble
with) renderpass instances.
Clean up around the implementations of finish() as well. Attempting to share
code via a "flushCommandBuffer" function is admirable but is not worth it
since some semantics are different. (finish() cannot be called within a
begin/endPass, unlike begin/endExternal).
Change-Id: I5137db598d6a40d484e53678f5c919abf750d9ed
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
| |
This is private API for the time being. Without this the QRhi*
classes show up in the class list in the docs.
Change-Id: I662abb9cc8eaae13ffe9266bd6313faa8e138353
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
| |
With GLES both point sprites and gl_PointSize in the vertex shader
are implcitly enabled, but OpenGL has these as optional and must be
enabled explicitly.
Change-Id: I48cf6134f6bbd721cb938e2cad82d255cf4fb2cd
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
| |
Switching TexImage2D to the sized internal format was a bad idea.
Go with what we do without the RHI in QtGui and elsewhere, and just
pass the unsized GL_RGBA or GL_BGRA.
Change-Id: I8216c0e49813355fa5e2594b24f06c64bc8e3873
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adjusting the size is not very useful on its own. Leave it to Qt Quick
or whoever provides the data to scale the source image data as they see
fit.
This is also more in line with other backends.
While we are at it, update the feature flag documentation. It applies
both to the repeat wrap mode and filtering modes other than nearest
and linear (i.e. mipmapping).
Change-Id: Ie28f1436b862335efeac042dc21e09189f46e626
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
|
| |
...due to setting the unsupported texture compare mode. This keeps
wasm happy (gl errors show up in the console there).
Change-Id: I5de8bce8e793c709272f3df499d2320c7b07ff71
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
|
|
|
|
|
|
|
| |
Also make sure the gl backend is consistent with the other three.
Change-Id: I2f6b783f5fa474c94ede460f5d7ac6fe8129a4f6
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
| |
Note that SPIRV-Cross does not translate 'bool' to GLSL versions
that do not have uint. So in practice we will still need to use
'int' instead in shaders that also target old GL versions.
Change-Id: I070f5414fe761796ab92937034b7182cdfb73a14
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Following the Quick scenegraph (qt.scenegraph.*), we now have
qt.rhi.general. Other categories may get added later.
This does not change the printing of real errors, those will
continue to use qWarning().
Change-Id: Id95416fc82ba8add9527212e431bcbd47d416f1a
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
| |
...and storage buffers and images.
Change-Id: If38a51322e3187088a13cf4e9b88cb40c8af8621
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
|
|
|
|
|
|
|
|
|
| |
It was somewhat incorrect in a few places.
Some of these should be moved to QOpenGLFunctions/Extensions later.
Change-Id: Ibc7a6409f16ddf1ad71230671dcad558dac1b86f
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
| |
Have feature flags as appropriate. OpenGL is causing a mess here
but let's support what we can since some of this will become relevant
in more sophisticated mesh drawing cases with 3D in particular.
Change-Id: Idfa7b4642ec87147978e03d78d6233efbd151491
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
| |
...when having a 3.3+ or ES 3.0+ context.
Change-Id: Ie92815263e190912d8f0b7b92ae6da55e062af05
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enforce the maximum texture size limit both for textures and renderbuffers,
showing warnings and adjusting the size automatically.
On the low end ES 2.0 devices we can easily hit a maximum size of 2048x2048.
For example a Raspberry Pi running in full HD with the Controls 2 Material
style breaks right away as it tries to create slightly wider than 2048 texture
for its ShaderEffect.
Instead of breaking with an obscure framebuffer incomplete warning at best,
show something more informative and adjust the sizes so that something shows
up on the screen still.
(naturally applications not taking the maximum sizes returned from QRhi
into account are technically incorrect and may well end up with incorrect
rendering, but we should still try handling this as gracefully as possible)
Change-Id: Ib75eb893ab4774e1a3c49ed2d14c6bf9be8c807a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
So that we can now operate on plain ES 2.0 implementations like the
Broadcom stack on the Raspberry Pi (which does not even have packed
depth stencil).
Also add the WebGL-specific combined attach logic to enable WebAssembly.
This has not been tested in practice.
Change-Id: I21219319062f295c1e88e3057c0c2ede724ac664
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...but this will vary between backends, or in some cases
even between implementations of the same API.
Point size is settable only via the vertex shader (gl_PointSize).
It is silently ignored with D3D and HLSL.
Line widths other than 1 are supported only on OpenGL and Vulkan.
(but this is in fact deprecated with GL and optional with Vulkan)
Add QRhi::Feature values for both.
The line width is now settable on QRhiGraphicsPipeline. It is not a
dynamic state since the static, per-pipeline width is good enough for
most cases. (and the feature is not supported on half of the backends
anyways so it will get limited use in practice).
Change-Id: I6d3a32269527c452b794b2cb8b0f03101eab40b2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
May very well be called within an active pass when going
through beginExternal() (think examples like d3d11underqml)
Change-Id: Ie98e72609308f47497d83fbe10c19ad1ae8eade3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D3D11 and GL (4.3+, ES 3.1+) will come separately at a
later time.
Change-Id: If30f2f3d062fa27e57e9912674669225b82a7b93
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Needed by Qt Quick to handle cases where the application (or other Qt)
code contains OpenGL calls, and Qt Quick facilitates this by ensuring
the scenegraph's GL context is current. The expectation is that when
running with the GL backend of the rhi, all such code remains fully
functional. So add a makeCurrent type of call into the QRhi API that is
a no-op with anything other than OpenGL.
Change-Id: I6f774bf828e31802bdab0c3fef9421cdc0cebe5c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
Comes with backends for Vulkan, Metal, Direct3D 11.1, and OpenGL (ES).
All APIs are private for now.
Shader conditioning (i.e. generating a QRhiShader in memory or on disk
from some shader source code) is done via the tools and APIs provided
by qt-labs/qtshadertools.
The OpenGL support follows the cross-platform tradition of requiring
ES 2.0 only, while optionally using some (ES) 3.x features. It can
operate in core profile contexts as well.
Task-number: QTBUG-70287
Change-Id: I246f2e36d562e404012c05db2aa72487108aa7cc
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|