summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi/qrhigles2.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Port from container.count()/length() to size()Marc Mutz2022-10-041-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rhi: gl: Unify end/finish behaviorLaszlo Agocs2022-08-051-0/+12
| | | | | | | | | | | | | | | 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>
* rhi: gl: Avoid magic adjustments to the context/window formatLaszlo Agocs2022-08-011-28/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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>
* rhi: gl: Reset the buffer bindings on beginExternalLaszlo Agocs2022-08-011-1/+7
| | | | | | | | | | | | | | | | | | | Play nice with old renderers like the OpenGL paint engine for QPainter. When combining Qt Quick and QPainter targeting the same GL window, calling QQuickWindow::beginExternalCommands() is not currently sufficient to ensure problem-free operation, it also needs a QQOpenGLUtils::resetOpenGLState() afterwards to get rid of the buffer bindings. (which is important when using legacy code with client-side vertex arrays) Which in turn is not what the documentation promises, so resetting the bindings is now ensured on the rhi level when Qt Quick calls beginExternal(). Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-104801 Change-Id: Ibd82753996768aad0118bff87d4e1f8bcc388c58 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Clean up some inconsistenciesLaszlo Agocs2022-07-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rhi: Fix up the instancing step rate typeLaszlo Agocs2022-07-071-1/+1
| | | | | | | | | | | | | | | This is a UINT/uint32_t/GLuint/NSUInteger in all APIs (with Metal being special due to being 64-bit in 64-bit apps whereas all others are 32-bit always, at least on 64-bit Windows) As the stride is already an uint32, follow suit for the step rate. There was no reason to have this as int in the first place. As an added bonus, some casts, that were previously needed when mapping to the underlying API reality, can now be removed. Change-Id: I8e0eef037bd795b637578dfc3e59dc2efaa5976c Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* QRhi: support uniforms of int and ivec arrays in GLES2 backendInho Lee2022-07-051-21/+58
| | | | | | | Uniforms of int and ivec arrays are supported from GLES v2.0. Change-Id: I9a08db18f584e39b4f71b7348a2a1fe4089bfce4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Keep track of pipeline creation timesLaszlo Agocs2022-07-051-2/+9
| | | | | | | | | | | | | | | | | | | | | Make our QRhiMemAllocStats struct a bit more generic, drop the memory allocation part in the naming, and use the same getter and struct for reporting some important timings. (we are free to rename for now, there are no users in other modules yet) The time spent in graphics (or compute) pipeline creation has a special relevance in particular with the modern APIs (as it is the single biggest potentially time consuming blocking operation), but also highly interesting with others like D3D11 simply because that's where we do the expensive source-to-intermediate compilation is HLSL source is provided. In order to see the effects of the various caching mechanisms (of which there can be confusingly many, on multiple levels), the ability to see how much time we spent on pipeline creation e.g. until we render the first view of an application can be pretty essential. Task-number: QTBUG-103802 Change-Id: I85dd056a39db7e6b25fb1f9d02e4c94298d22b41 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | 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>
* rhi: Make QRhiRenderTarget's rp getter functional with swapchainsLaszlo Agocs2022-04-261-0/+1
| | | | | | | | | | | | | | | | | swapchain->currentFrameRenderTarget()->renderPassDescriptor() is not functional at the moment, it returns null. This is because no backend ensures that the internal renderpass descriptor object is exposed via that getter in a QRhiSwapChainRenderTarget. Whereas in a QRhiTextureRenderTarget this would work by design because there the setter must be called by the user. Fix this up, providing better API symmetry, and also reducing the need to pass along QRhiRenderPassDescriptor objects seprately alongside a QRhiRenderTarget in some places, e.g. in Qt Quick. Change-Id: I42c4e9aaee3202c1d23bd093d840af80c5f8cd0f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add a feature flag for non-fill polygon modesLaszlo Agocs2022-04-221-0/+2
| | | | | | | | It's one thing that this is not part of OpenGL ES, but it is optional even with Vulkan, with some mobile GPUs not offering the feature at all. Change-Id: I4e2c6642eccb0793e69074b4b6eeb2b7cef3516e Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Use the QSurface for QRhiGles2InitParams::fallbackSurfaceJiDe Zhang2022-04-121-7/+8
| | | | | | | | | | There is no need to limit the type to QOffscreenSurface here, QRhi does not depend on the behavior in QOffscreenSurface. Users can use the custom offscreen QSurface types if needed. Task-number: QTBUG-102257 Change-Id: I47a064496f8c5f1986a0e11ec748ea32a03b903e Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add explicit subclass for RTs from swapchainsLaszlo Agocs2022-04-051-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | We want to enable gaining access to the underlying resource(s) by inspecting a QRhiRenderTarget. This is not currently possible for swapchains since there is nothing that references the actual QRhiSwapChain. To clean this up, make an explicit, new QRhiSwapChainRenderTarget subclass. Thus the logic already used in a couple of places to examine the resources attached to a QRhiTextureRenderTarget can now work with swapchain render targets too, by branching based on the resourceType(). This eliminates the somewhat odd setup where a "RenderTarget" resource is QRhiRenderTarget corresponding (but not exposing!) a swapchain, whereas a "TextureRenderTarget" is a QRhiTextureRenderTarget which is a subclass of QRhiRenderTarget. Now we correctly have an (abstract) base and two subclasses, one for each type of render targets. Besides, it allows us to clean up the oddly named Q...ReferenceRenderTarget classes in the backends, which initially tried to indicate that this "render target" merely references (or, in practice, is) a swapchain. We can now have a nice and symmetrical Q...SwapChainRenderTarget and Q...TextureRenderTarget naming scheme. Change-Id: Ib07e9be99a316eec67b94de0860e08f5f4638959 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: d3d11/vulkan: Allow passing in an array range overrideLaszlo Agocs2022-03-241-0/+2
| | | | | | | | | | | | | | | | | | Only (straightforwardly) implementable with modern APIs, and only really exists to handle special platform cases, such as when a video framework gives us a D3D texture array with D3D11_BIND_DECODER | D3D11_BIND_SHADER_RESOURCE which is only possible to use as a shader resource if the SRV selects a single array layer. Has no effect on the normal usage of texture arrays, where all array layers are exposed, and it is the shader that selects the layer when sampling or loading via the sampler2DArray. That continues to be the standard way to work with texture arrays. Change-Id: I0a656b605da21f50239b38abb83067e0208c1dbe Reviewed-by: Piotr Srebrny <piotr.srebrny@qt.io> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Gui: Do not depend on transitive includesFabian Kosmale2022-03-171-0/+1
| | | | | Change-Id: I27321235d9c8428de0cff1e22a618299b9e5a97f Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Fix deprecated use of QBA/Q*String::countMårten Nordheim2022-03-151-3/+3
| | | | | | | 'Use size() or length() instead' Change-Id: I284fce29727c4c1ec9ea38a4e8ea13a9e0af5390 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* wasm: prevent WebGL vertex attribute errorsMorten Johan Sørvig2022-03-141-0/+8
| | | | | | | | | | | | | | WebGL is stricter than OpenGL ES and require that unused vertex attribute arrays are disabled. This prevents errors such as: WebGL: INVALID_OPERATION: drawElements: no buffer is bound to enabled attribute Pick-to: 6.3 Change-Id: I68384a9f6954b6a1960ba6e8afd1fdbdfefe2335 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* rhi: Add the basic infrastructure for geometry shader supportBen Fletcher2022-01-311-1/+20
| | | | | | | | | | | | | | | | | | | | | .. 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>
* rhi: Add support for polygon fill modeBen Fletcher2022-01-311-0/+29
| | | | | | | | | | | | | | | | | 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>
* rhi: Fix tessellation support for OpenGLBen Fletcher2022-01-281-0/+4
| | | | | | | | | Added shader stage mapping for tessellation stages. Manual test rhi/tessellation now works for OpenGL. Change-Id: I7906b21e9d6e20883f17729f077dba57aa29f4fd Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Make sure pixelSize() to a texture rt is always up to dateLaszlo Agocs2022-01-251-0/+3
| | | | | | | | | This is an issue for QQuickWindow in practice, although it is not hit by our current tests. Pick-to: 6.3 Change-Id: Ia73704c1af6a82b2689ce7b844d3b0eb9a17ec18 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* QRhiGles2: replace two QSet<int> with QDuplicateTrackerMarc Mutz2022-01-181-6/+5
| | | | | | | | | | Apart from a more fitting, minimal, API, QDuplicateTracker also transparently uses C++17 pmr::monotonic_buffer_resource to avoid, or at least reduce, memory allocations. Pick-to: 6.3 Change-Id: Ied2574734949b2dadc1bcbaa9d1e3c0ed98ba50a Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add the basic infrastructure for tessellation supportLaszlo Agocs2022-01-131-39/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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>
* rhi: Add queries for vertex input/output limitsLaszlo Agocs2022-01-121-0/+33
| | | | | | | | | | 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>
* rhi: Improve the handling of HDR capable texture formatsLaszlo Agocs2022-01-111-0/+22
| | | | | | | | | | | Add some sort of autotest for both RGBA16F and the new RGB10A2. The latter is introduced particularly because ideally we should have a texture format that corresponds to the D3D/Vulkan swapchain color buffer format with HDR10. Change-Id: I1e1bbb7c7e32cb3db89275900811c0bcaeac39d6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: Prevent breaking with ES when querying the sampler mapping tableLaszlo Agocs2022-01-071-15/+15
| | | | | | | | Send the full QShaderVersion down the line, not just the version number. Change-Id: I895d552fc47e0eb4ca92f32f117cd5a1d4d9015a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Returns mapping tables by value from QShaderLaszlo Agocs2022-01-071-6/+6
| | | | | | | | | As these are QList and QHash. All existing usages are based on this anyway, no value in being able to indicate "not available" - an empty container fulfills the same role. Change-Id: I8059025fa7a4acb6fc674cd98b16fcafa19ed85d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: Do not just rely on GL_COMPRESSED_TEXTURE_FORMATSLaszlo Agocs2022-01-061-55/+103
| | | | | | | Pick-to: 6.3 6.2 Task-number: QTBUG-98937 Change-Id: I64f2783ae64ad3ef77a389999ded4c9ba2c46ee5 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* rhi: Add support for separate image and sampler objectsLaszlo Agocs2022-01-061-53/+159
| | | | | | | | | | | | | | | | | | | | | For Direct 3D, Metal, and Vulkan this is natively supported. (and makes no difference in particular for D3D and Metal because they do not have the legacy combined image sampler concept anyways) With OpenGL it will work too, but this relies on SPIR-Cross magic and is still using a combined sampler (e.g. a sampler2D) in the GLSL shader. The GL backend walks back and forth in the mapping tables from the shader baker in order to make this work, which is presumably slightly more expensive than combined image samplers. Do note that combined image samplers (i.e. sampler2D in the shader and QRhiShaderResourceBinding::sampledTexture() in code) continue to be the primary, recommended way for any user of the rhi for the time being. Change-Id: I194721bc657b1ffbcc1bb79e6eadebe569a25087 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Drop the profiler for nowLaszlo Agocs2022-01-041-42/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rhi: Add the basics for HDR swapchainsLaszlo Agocs2022-01-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...backed by support in the backends for D3D11 and Vulkan. Expose only what works in practice: scRGB with RGBA16F and HDR10 with RGB10A2 (or A2BGRA10 etc.). For general use, e.g. to render 2D/3D content, scRGB (i.e. extended sRGB linear) should be chosen because that is a linear space. On Windows with a HDR10 display (and an NVIDIA card) both of these are known to work, as long as Use HDR is enabled in the Settings for the display on which the window is created. When requesting a HDR format and it is not supported, we will fall back to the default SDR RGBA8/BGRA8 format. However, the behavior seems to be a bit weird with Vulkan and NVIDIA at least when there is a HDR display but Use HDR is set to Off: this seems to enable HDR mode for the lifetime of the window (with the usual set of black screens while switching over the entire display). Not sure why the driver does this. With D3D/DXGI, with fewer abstractions in the way, we can check upfront properly, so that will nicely fall back to the defaults regardless of why HDR is not available. Support can also be checked in advance via QRhiSwapChain::isFormatSupported() as long as the QWindow is available. (though with Vulkan, as said above, this also seems to ignore the Use HDR setting of Windows) Complications, such as moving a window from one screen to another, are currently not known how they behave. To be seen how this is handled by the Windows compositor. (from 1903 and up it is said to be able to automatically downconvert scRGB to SDR so perhaps moving from a HDR to a non-HDR screen would work - remains to be seen if this needs something more involved) When it comes to other platforms and potential future support: - based on its docs Android 8+ may support scRGB with Vulkan as-is on a suitable device/display, as long as the application declares android:colorMode="wideColorGamut" in the manifest. - for Metal the layer can be made EDR enabled and then e.g. MTLPixelFormatRGBA16Float/kCGColorSpaceExtendedLinearSRGB should work. However, this won't be added unless we can test it. - Linux is unknown. If one needs access to display specific values such as the min/max luminance when implementing tonemapping or a transfer function, that needs platform/API specific approaches, and sadly the kind of data exposed seems to vary, potentially making it difficult to maintain a single cross-platform logic. With D3D one can get the DXGI_OUTPUT_DESC1 from the IDXGIOutput6. This has the min/max luminances in nits and a bunch of other things. For convenience the output object is now exposed from the swapchain's nativeHandles() whenever the D3D backend is used at run time. For Metal one would presumably access maximumExtendedDynamicRangeColorComponentValue and co. in the NSScreen. Elsewhere one needs to rely on platform/winsys specific approaches, if there are any. Remains to be seen longer term if/how this needs/can be better supported. Change-Id: I2e61a0e062282d4bfdfba39655941c0f9a795112 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Auto-rebuild rt by tracking attachment id and generationLaszlo Agocs2021-12-101-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Unlike the shader resource binding lists that automatically recognize in setShaderResources() when a referenced QRhiResource has been rebuilt in the meantime (create() was called i.e. there may be completely different native objects underneath), QRhiTextureRenderTarget has no such thing. This leads to an asymmetric API and requires also rebuilding the rt whenever an attachment is rebuilt: rt = rhi->newTextureRenderTarget({ { texture } }) rt->create() cb->beginPass(rt, ...) texture->setPixelSize(...) texture->create() rt->create() // this should not be needed cb->beginPass(rt, ...) Avoid having to do that second rt->create(). Change-Id: If14eaa7aac3530950498bbdf834324d0741a7c4d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Callbacks for begin/end of a frame on OpenGLEskil Abrahamsen Blomfeldt2021-12-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The background for this is that when running Wayland, the Mesa driver has an issue which makes it crash if we call eglDestroySurface() while we are rendering to it. This is not according to the documentation, and it only seems to happen on Mesa and only on Wayland, so it is probably related to something in the Wayland implementation in the driver. Since this driver is very popular, we want to work around it, which can easily be done using existing locking mechanisms in the Qt Wayland QPA plugin. But in order to do so, we need reliable callbacks for the start and end of a frame. The RHI already has this, so we just need to channel the information to the QPA plugin. Having beginFrame/endFrame hooks in the QPlatformOpenGLContext could be useful in other cases as well, especially knowing that there are OpenGL implementations that require some extra thread protection. QPlatformSurface would be a more general location for these hooks, but since the issue is only seen on OpenGL and multi-threading is handled more explicitly in other APIs, we don't want to expose this API in a more general location than necessary. Task-number: QTBUG-92249 Change-Id: I97ce7d4f744c4b28eec457e919d1c9652ff00079 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* rhi: gl: Optimize context/surface changesLaszlo Agocs2021-11-261-11/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When there is a context with a surface current, keep on using that whenever ensureContext() is called without specifying a QWindow. Consider the following sequence: <component A> beginOffscreenFrame render to texture 1 endOffscreenFrame <component B> beginOffscreenFrame render to texture 2 endOffscreenFrame <component C> beginFrame (with swapchain) render something using texture 1 and 2 endFrame repeat all over again, continuously (in practice this is what a top level widget with QOpenGLWidgets and/or QQuickWidgets in it would lead to with the QRhi migration in place) Besides being more readable, the new version recognizes that resource and offscreen operations do not need one specific surface (like the one QOffscreenSurface every GL backend of QRhi has), but are functional with any surface (or with surfaceless even) as long as the context is correct. Thus with the above example we can work with only ever making the one QWindow current. Change-Id: I633071cae88f02e1d45e445ee55c8a58f9ec5a8c Pick-to: 6.2 Fixes: QTBUG-96405 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Expose the maximum uniform buffer range limitLaszlo Agocs2021-11-101-0/+35
| | | | | | | | Pick-to: 6.2 Task-number: QTBUG-97715 Change-Id: I7f0a52c410b9b77f735fb3b7fd33141674bb0cda Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add texture array supportLaszlo Agocs2021-10-291-39/+93
| | | | | | | | | | | | | | 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>
* Fix typo: alignment has an n in itEdward Welbourne2021-10-141-1/+1
| | | | | Change-Id: If64edd32c5084984227b3c366932b3129df94b31 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* RHI: introduce a way to disable framebuffer clears on GLGiuseppe D'Angelo2021-10-121-2/+5
| | | | | | | | | | | | | | | | | On low-end hardware without fast framebuffer clears one can significantly reduce the fill rate by disabling framebuffer clears (provided, as it's usually the case, that the application has content filling the entire framebuffer). Add a couple of environment variables to do so, one to disable all clears and one to disable only color clears (in case the surface is requested without a depth buffer). Note that disabling all clears on a surface *with* a depth buffer still requires QSG_NO_DEPTH_BUFFER to be set, otherwise QtQuick is going to assume that there is a clean usable depth buffer. Change-Id: I96ad0a3d28dd0ab65cc960fb7cb2e0a8b6f35628 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* gui: Fix typos in source code commentsJonas Kvinge2021-10-121-1/+1
| | | | | | Pick-to: 5.15 6.2 Change-Id: Ie53e5542a8f93856470982939ecd8ec90b323d69 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* rhi: gl: Do not issue memory barriers when we do not have toLaszlo Agocs2021-09-281-8/+66
| | | | | | | | | | | | | | | | | | | | | | | | First, issue glMemoryBarrier() only if the read-after-write or write-after-write occurs for a write involving incoherent memory access. In practice this means a QRhiTexture with UsedWithLoadStore or a QRhiBuffer used as an SSBO. Doing the barrier call for other types of texture or buffers is pointless, and potentially wasteful. What is more, some OpenGL implementations feature bugs that manifest themselves when glMemoryBarrier() is called, see associated Jira issue for details. Second, reduce GL_ALL_BARRIER_BITS to the ones relevant for the type of the resource, in an attempt to provide a minor optimization. Real fine-grained resource usage tracking is not implemented for OpenGL so this still means specifying all buffer-related or all texture-related barriers together, but this is still better than all. As the usage of compute is quite close to zero in Qt at the moment, this won't make much of a difference in practice. Fixes: QTBUG-96322 Pick-to: 6.2 Change-Id: Ibf794e2e8a4cbc3c69acaa88476e85de6646b605 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Allow testing renderpass compatibility without the objectsLaszlo Agocs2021-09-161-0/+5
| | | | | | | | | | | | | | | | | | | Follow what has been done for QRhiShaderResourceBindings. Have a way to retrieve an opaque blob (that just happens to be a list of integers) so that a simple == comparison can be used to determine compatibility even when the objects from which the blob was retrieved are no longer alive. The contract is the following: bool a = rp1->isCompatible(rp2); bool b = rp1->serializedFormat() == rp2->serializedFormat(); assert(a == b); Pick-to: 6.2 Change-Id: I45e7d05eeb6dfa2b2de474da0a0644912aaf174a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: gl: Have a way to state GL_TEXTURE_RECTANGLE is wantedLaszlo Agocs2021-09-161-0/+6
| | | | | | | | | | | | | | Added specifically to support the deprecated CVOpenGLTextureCache on macOS, because Qt Multimedia still needs a way to use that when the applications requests using OpenGL instead of Metal. Follow what we did for GL_TEXTURE_EXTERNAL_OES, and add a flag that simply makes all our glBindTexture calls use the GL_TEXTURE_RECTANGLE[_ARB] target. Pick-to: 6.2 Change-Id: If818b13a9f520cdb8bdc16de84a3ca0e18ad6c33 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* rhi: Add a way to tell an srb that only the resources have changedLaszlo Agocs2021-09-031-0/+6
| | | | | | | | | | | | | | | | | Until now, after updating the bindings one had to always rebuild the srb, which can be heavy esp. on Vulkan (release old objects, create new layout object, descriptor sets). When updating the binding list in a way that it is fully isLayoutCompatible() == true with the previous list, this is an overkill. Internally, most notably in setShaderResources(), we already should have everything in place in all backends to recognize if the entries in the binding list refer to QRhiBuffer/Texture/Sampler objects that are different than before, and so apart from adding an alternative to create() in the API there is not much else needed here. Pick-to: 6.2 Change-Id: I2efdd4fd0b24c7ebba694a975ed83509744b044b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: Set the screen on the context, if possibleLaszlo Agocs2021-08-271-0/+2
| | | | | | | | | | | | | | | | | | | | Take the screen from the window, if the window was specified. When it comes to Qt Quick, this is in fact required in order to make the behavior on par with Qt 5, see https://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/quick/scenegraph/qsgthreadedrenderloop.cpp?h=5.15#n1336 try to mirror that in Qt 6 as well. There are still subtle differences between Qt 5 and Qt 6 in particular when qt_gl_global_share_context is set (do we set the screen from that or from the window?), for now leave that question unsettled. What exactly setting the screen on the context does is platform specific, and can become relevant with multi screen, multi GPU systems. Pick-to: 6.2 Change-Id: Icc90b8fea87bf1e34ecf1dec0702f4d3c411db00 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: gl: Allow passing in a custom shareContextLaszlo Agocs2021-08-261-3/+12
| | | | | | | | | | | | | | | | We already honor AA_ShareOpenGLContexts and pass in the QGuiApp's context as the shareContext for the QRhi's QOpenGLContext. Extend this to also allow specifying a QOpenGLContext in the init params struct. A good example of this is the backingstore compositor that serves QQuickWidget and co. If one wanted to implement that with (an OpenGL-based) QRhi, instead of direct OpenGL calls, then the ability to create a QRhi that uses a context that shares resources with a given other context becomes essential. Pick-to: 6.2 Change-Id: I6bc5ff8e803d467f8795197ac1f12fdc0f73bbd1 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Be more graceful when one destroys a resource after the QRhiLaszlo Agocs2021-08-021-25/+51
| | | | | | | | | | | | | | | | | | | | | One is a bad application or library in this case, but nonetheless we should handle this more gracefully then just crashing due to the QRhi already having been destroyed. Mainly because in Qt 5 one could get away with the same: releasing OpenGL objects underneath, for example, a QSGPlainTexture with no (or wrong) GL context did not generate any user visible fatal errors. So we should not crash in Qt 6 either with these code bases. In debug builds or when QT_RHI_LEAK_CHECK is set, one will get the unreleased resources warning printed in Qt 6, which is a step forward compared to Qt 5. So there is still some indication that something is badly designed, even if the application survives. Task-number: QTBUG-95394 Pick-to: 6.2 Change-Id: I944f4f425ff126e7363a82aff926b280ccf1dfc3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Use QByteArray for storing data in QGles2BufferRobert Löhning2021-06-081-13/+10
| | | | | | | | | | Mainly to avoid leaking memory again. A possible reduction of memory allocations would be a welcome side effect. This reverts parts of 89f7389494c6fc917f189150e06ed1fcfaa238e8. Change-Id: I65a7529f532175967a4e408450aa55549b77d7e4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Enable reading back slices of 3D texturesLaszlo Agocs2021-06-031-5/+16
| | | | | | Change-Id: I0c687677b7e86b7284130c775718b29aca2cca40 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for 3D texturesLaszlo Agocs2021-05-311-39/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* rhi: gl: Add support for importing an existing renderbuffer objectLaszlo Agocs2021-05-191-1/+32
| | | | | | | | | | | | | | | | | | | | | | Normally we only allow creating wrappers for texture objects. These can then be used with a QRhiTextureRenderTarget to allow rendering into an externally created texture. With OpenGL (ES), there are additional, special cases, especially on embedded. Consider EGLImages for example. An EGLImageKHR can be bound to a renderbuffer object (glEGLImageTargetRenderbufferStorageOES), which can then be associated with a framebuffer object to allow rendering into the external buffer represented by the EGLImage. To implement the same via QRhi one needs a way to create a wrapping QRhiRenderBuffer for the native OpenGL renderbuffer object. Here we add a createFrom() to QRhiRenderBuffer, while providing a dummy, default implementation. The only real implementation is in the OpenGL backend, which simply takes a renderbuffer id, without taking ownership. Task-number: QTBUG-92116 Change-Id: I4e68e665fb35a7d7803b7780db901c8bed5740e2 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 19:04:09 +0000