summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi
Commit message (Collapse)AuthorAgeFilesLines
* rhi: metal: Ignore baseInstance if not supportedLaszlo Agocs2021-11-261-3/+9
| | | | | | | | | | | | | | | | | | | | | | A previous patch already introduced calling the correct variant of drawIndexedPrimitives, but it was not done for drawPrimitives. When base vertex and instance is not supported (e.g. on the iOS simulator), it does not mean that the value cannot be other than 0, but rather that the version of the function taking this arguments must not be called at all, otherwise a Metal failure occurs. The docs and logic is all in place, just add it to draw() as well. Amends 213755a86622ae8b3ed3d7ad34a6aecd051b2b03 which fixed this for indexed draw calls. Now we also prevent aborting Qt Quick applications that trigger non-indexed draw calls. Change-Id: Icb4313ffd2d3a77a73f7b5f49d7ce63c935254d3 Pick-to: 6.2 Task-number: QTBUG-95795 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: Optimize context/surface changesLaszlo Agocs2021-11-262-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* d3d11rhi: remove leftover of pre-win10 codeYuhang Zhao2021-11-261-3/+1
| | | | | | | | | Amends commit 1e085b9e15abeb45bbbf7995818fcd9c94bfefe1 Task-number: QTBUG-84432 Pick-to: 6.2 Change-Id: Id48fb6c2a9c7d24f1525975c6c154dbc323bbc25 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Expose the maximum uniform buffer range limitLaszlo Agocs2021-11-108-1/+62
| | | | | | | | 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: Extend docs regarding QImage and data lifetimeLaszlo Agocs2021-11-021-0/+11
| | | | | | Change-Id: I45e0e53af7e6ba084f6305c3097c6a0ff65fb458 Pick-to: 6.2 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: vk: fix offscreen frame command completion waitLaszlo Agocs2021-11-021-11/+11
| | | | | | | | | | | | | | | Remove the if-there-is-more-than-one-swapchain condition. Surely in a (onscreen) 0, (onscreen) 1, (offscreen) 0 frame sequence the wait is essential when starting the offscreen frame. Otherwise we may be deferred-releasing resources from the still active onscreen #0 frame. The problem is only apparent with certain frame slot change sequences. For instance (onscreen) 0, (offscreen) 1, (onscreen) 0 would not show any problems. Pick-to: 6.2 Change-Id: I705a0a3ab0b4bc9e4dc2b1c6ff60025d04c739b3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add texture array supportLaszlo Agocs2021-10-2913-112/+367
| | | | | | | | | | | | | | 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>
* RHI: use the flags we've just calculatedThiago Macieira2021-10-191-1/+1
| | | | | | | Caught by clang 13 detecting we set a variable but never used it. Change-Id: I8c6a0ff3ec184205a544fffd16af3d52b6f172a2 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Rhi: Document expectation for setGraphicsPipeline's pipeline argumentChristian Strømme2021-10-191-0/+3
| | | | | | | | | The backed expect the pipeline to be valid, so document it and assert if the set pipeline is a null pointer. Pick-to: 6.2 Change-Id: I72b3d0d11b8dc98240d17e13adf2b6ccbd71891d Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* RHI: suppress annoying warning about deprecated copy constructorsThiago Macieira2021-10-181-0/+1
| | | | | | | | | | | | With clang 13: vk_mem_alloc.h:4360:22: warning: definition of implicit copy constructor for 'VmaStlAllocator<VmaDefragmentationAlgorithm::AllocationInfo>' is deprecated because it has a user-declared copy assignment operator [-Wdeprecated-copy] vk_mem_alloc.h:4391:9: note: in implicit copy constructor for 'VmaStlAllocator<VmaDefragmentationAlgorithm::AllocationInfo>' first required here Repeats ad nauseam Change-Id: Iea05060bc2c046928536fffd16adf5181ede7abe Reviewed-by: Laszlo Agocs <laszlo.agocs@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: Don't retain texture operations after frame is doneEskil Abrahamsen Blomfeldt2021-10-121-0/+2
| | | | | | | | | | | | | | Retaining texture upload commands comes at a price, because it means we also retain the backing storage, which could e.g. be fullscreen buffers for applications on Wayland. These would eventually be overwritten, but just clearing the array between frames is also fine because the data is never reused and the array is a QVarLengthArray anyway so it already has a lot of reserved space. Pick-to: 6.2 Change-Id: I7389487be67b671830787e30e1468c303b7ac5c2 Reviewed-by: Laszlo Agocs <laszlo.agocs@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 documentationJonas Kvinge2021-10-122-7/+7
| | | | | | Pick-to: 5.15 6.2 Change-Id: I533f5a55cd0cd60a76990b552d7dab51a301ac1c Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* 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: metal: Query supported sample counts from the deviceLaszlo Agocs2021-10-082-1/+8
| | | | | | | | | | Check if 2, 4, 8 are actually supported. Pick-to: 6.2 Fixes: QTBUG-97146 Change-Id: I23c22c2bfeb072b9658f3b5dfba51dd6dc850de3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@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: vk: Fix invalid index for unused attachmentsLaszlo Agocs2021-09-231-12/+14
| | | | | | Pick-to: 6.2 Change-Id: I8140de4eeb1a8a490fcffd10370c29a49d677fed Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Remove Q_RELOCATABLE_TYPE for types with QVLA in themLaszlo Agocs2021-09-202-10/+1
| | | | | | | | | | | | | QVLA itself is non-relocatable due to self references. (ptr pointing to array[Prealloc] as long as capacity < Prealloc) Seems we shot ourselves in the foot in multiple places with this. Pick-to: 6.2 6.2.0 Fixes: QTBUG-96619 Change-Id: I57a2ce539b671326cd352dbe57a1f3d4c46a6456 Reviewed-by: Tobias Koenig <tobias.koenig@kdab.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* rhi: vulkan: Reset state more aggressivelyLaszlo Agocs2021-09-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | ...when starting a render/compute pass. This matches most other backends in fact, the Vulkan backend has just certain historical differences, and is complicated due to the fact that it has the option of using secondary command buffers for passes that specify ExternalContents (to support the case of wanting to issue direct Vulkan commands in a code block surrounded by calls to beginExternal and endExternal). Not resetting state such as the currently bound index buffer when starting a pass quickly blows up when two consecutive render passes use different settings, one targeting the primary while the other the secondary command buffer. Instead of further complicating the logic, just reset the relevant state in every begin(Compute)Pass. Comes with an autotest that is crafted so that it manages to downright crash when run with Vulkan without the fix to the backend. Fixes: QTBUG-89765 Pick-to: 6.2 Change-Id: I8dc47bd179c17d45a0556ec31200dc90c4b67ca5 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: document serializedLayoutDescriptionLaszlo Agocs2021-09-161-4/+31
| | | | | | | | | | | The docs are internal still but won't hurt to keep them up-to-date. At the same time, enhance the QRhiRenderPassDescriptor serializedFormat() docs as well, with appropriate notes about the intended usage of the "serialized" data. Pick-to: 6.2 Change-Id: I8425fff625903468621e3b09d089b345fada85f4 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Allow testing renderpass compatibility without the objectsLaszlo Agocs2021-09-1612-1/+121
| | | | | | | | | | | | | | | | | | | 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: Note in the docs that texture copies expect a matching formatLaszlo Agocs2021-09-161-0/+5
| | | | | | Pick-to: 6.2 Change-Id: I0a1fb042ec2a3983ffbd146ff9bdc9af20134fa5 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: gl: Have a way to state GL_TEXTURE_RECTANGLE is wantedLaszlo Agocs2021-09-163-1/+15
| | | | | | | | | | | | | | 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: Reset resource state tracking tables upon layout-compatible updatesLaszlo Agocs2021-09-073-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...just like create() would do when requesting a full rebuild. Not relevant for the OpenGL backend, while D3D and Metal may get away without doing this, but the Vulkan backend gives visible rendering errors in Qt Quick once updateResources() is taken into use and a scene manages to do the "right" amount and types of changes. The most common source is a changing uniform buffer offset. Consider how the Qt Quick scenegraph merges uniform data into a single buffer in unmerged batches (i.e. when a set of geometry nodes cannot be batched together in a single draw all). While each node gets its own draw call, each associated srb refers to the same uniform buffer at binding point 0, just with a different offset. Without the layout-compatible-update optimization (that is QRhiShaderResourceBindings::updateResources()) this is not something that needs extra care: once an srb is built or rebuilt (by calling create()), the offset, just like the resource itself is fixed and cannot change. And once create() is called, it conveniently invalidates all related data structures, leading to the subsequent setShaderResources() rewrite descriptors (incl. the resource, the offset, etc.) with Vulkan or do whatever is relevant with other backends. updateResources() only does the minimum amount of changes because we know that the binding list layout has not changed. It turns out this was a bit too minimal, because certain state tracking data structures still need resetting, just as if we called create(). The problem is becoming apparent with non-layout data such as the uniform buffer offset, storage buffer offset, or the storage image mip level. It however works as expected when changing the resource itself. E.g. if a binding point now references a QRhiBuffer different than before, then there is no visible problems, regardless of the buffer offset being different or the same. Hence being difficult to discover, until the aforementioned Qt Quick renderer case triggers it. Why is this? Changing the resource (buffer, texture, sampler) itself works due to the guarantees given by the QRhi resource model. Consider the following: ubuf is a uniform buffer ubuf->create(); srb->setBindings({ references ubuf }); srb->create(); // use the srb in some draw calls // ... // later, when preparing the next frame we decide we need new data with // a different size even: ubuf->setSize(new_size) ubuf->create(); // fill in new data to ubuf // use the srb in some draw calls at this point "magic" happens: note how there is no rebuilding of the srb itself (no create(), no nothing), yet it will correctly pick up the now-different native buffer objects underneath ubuf. This works because there is a certain degree of state tracking happening that allows recognizing that a resource referenced from an srb got rebuilt and now has different native objects (e.g. a VkBuffer) underneath, which in turn needs (with Vulkan) rewriting the associated descriptor with the new native resource. Incidentally, this also makes updateResources() work just fine as long as it replaces the QRhiBuffer/Texture/Sampler reference for the binding point. However, with the example snippet above there is no way to change the other associated data such as the buffer offset. (that would need rebuilding the srb with create(), and that resets all related state tracking structures) So once we encounter an updateResources() where the same QRhiBuffer is now used with an offset different from before, that is not recognized by setShaderResources() and (with Vulkan) it will not rewrite the descriptor with the new offset. (unless the changes for another resource in the binding list trigger it; the granularity here is quite coarse, i.e. we either rewrite (with Vulkan) all descriptors or none at all; this makes the problem even less apparent because now rendering errors occur only when Qt Quick ends with an update where only the uniform buffer offset, but nothing else changed) Pick-to: 6.2 Change-Id: I82ee43aa358947288135ff72ec213e091342e9cb Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Improve srb layout serialization helpersLaszlo Agocs2021-09-072-3/+4
| | | | | | | | | | | Be idiomatic and return the output iterator one past the last element. Otherwise passing in a plain pointer (as exercised by the autotest now) fails to function because we write over the same 4 elements again and again for each binding. Pick-to: 6.2 Change-Id: If74463fa5140ffa2b1d5be97b71868848ad46614 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Enable serializing a layout description without baking an srbLaszlo Agocs2021-09-072-10/+31
| | | | | | Pick-to: 6.2 Change-Id: I66d28cc9d5417bcd5d192fa100c21f69fd42fd6b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Make the serialized srb layout description accessibleLaszlo Agocs2021-09-072-1/+14
| | | | | | | | | | | | | | | | | | | | | ...by the Qt Quick renderer, for example. A typical Qt Quick material binding set serializes to 8 uints. This would not demand a container like QVector. However, being implicitly shared is essential here due to the intended usage (query the serialized blob, put it into a cache key, hash it, compare it, all without any copying and new allocs; we can afford an extra alloc upon each srb construction, but don't want more afterwards in the rendering engines) Also make it clear in the pipeline docs that the optimization Qt Quick is (soon going to be) doing is legal. (the srb ref in the pipeline can be dead and dangling as long as every call to setShaderResources() specifies a layout-compatible alternative) Pick-to: 6.2 Change-Id: I97efbea1fa3516b10c9832adbab0a21b7bc0845d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add a way to tell an srb that only the resources have changedLaszlo Agocs2021-09-0311-0/+70
| | | | | | | | | | | | | | | | | 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: Correct a doc noteLaszlo Agocs2021-09-031-2/+6
| | | | | | | | | | It is not true that isLayoutCompatible() can be called before create(). That used to be the case before the optimizations have been added. The docs are still internal, but let's fix it up. Pick-to: 6.2 Change-Id: Iee61848f058a06774550af6f38a3253956e4cfd3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Include resource count in srb layout compatibility checksLaszlo Agocs2021-09-032-6/+13
| | | | | | | | | | | | | | | Relevant for Vulkan, given that descriptorCount is part of VkDescriptorSetLayoutBinding, meaning two srbs with arrays of SampledTextures should only be reported as compatible if the array size matches. Also reduces the prealloc size for the VLAs. For Qt Quick even a lower number would be sufficient, but we still keep the number something fairly high in order to play nice with Quick3D. Pick-to: 6.2 Change-Id: Id92b7c09b051ebe54b1fa2bf4ba78950fe60ba27 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: Polish some feature flag docsLaszlo Agocs2021-08-261-22/+37
| | | | | | | | | | | | | | Clean a bit, also enhance, e.g. mention textureLod for TexelFetch which is how Quick3D uses it, and most notably expand the "in practice" notes. As no application or library can be expected to write fully conditional code based on all these flags, knowing when a certain feature is (un)supported in a real run time environment is essential in order to make informed decisions on when and in what manner (i.e. with or without conditions), rely on a given feature. Pick-to: 6.2 Change-Id: I15ea34e11bd345b36248f92de9b1fdb1fdc3e8d9 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: gl: Allow passing in a custom shareContextLaszlo Agocs2021-08-263-3/+14
| | | | | | | | | | | | | | | | 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: metal: Make base vertex and instance support optionalLaszlo Agocs2021-08-183-14/+34
| | | | | | | | | | | | | | | | | | | | | | | Like we do for OpenGL. Conveniently enough the QRhi feature flags are readily available. This should prevent errors such as: MTLValidateFeatureSupport:3901: failed assertion `Base Vertex Instance Drawing is not supported on this device' on the iOS Simulator. It is not clear since which version or SDK this became a fatal problem, but the base vertex/instance support is indeed an optional feature according to the Metal Feature set tables, so not calling the drawIndexedPrimitives variant taking baseVertex and baseInstance when the reported iOS GPU family is too low is the right thing to do regardless. Pick-to: 6.2 6.1 Fixes: QTBUG-95795 Change-Id: I47c54a77a66a0410b86b8d4e5a1863dc730490f4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* d3d11rhi: remove pre-win10 codeYuhang Zhao2021-08-111-10/+5
| | | | | | | | | | | | CreateDXGIFactory2() is always available from Windows 8.1 No need to load it dynamically. Pick-to: 6.2 Task-number: QTBUG-84432 Change-Id: I84d82f30327df416e1fdbac256b63512900c07b7 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Be more graceful when one destroys a resource after the QRhiLaszlo Agocs2021-08-027-127/+257
| | | | | | | | | | | | | | | | | | | | | 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>
* Remove Windows 7, 8, and 8.1 codepathsOliver Wolff2021-07-301-11/+9
| | | | | | | Pick-to: 6.2 Task-number: QTBUG-84432 Change-Id: I970d7d7e9ebdcf246a5be32d60066b4e5e948c27 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add missing qHash overload for INTEGRITYKimmo Ollila2021-06-162-0/+12
| | | | | | | | | Fixes build issue "no instance of overloaded function "qHash" matches the argument list" on INTEGRITY Pick-to: 6.2 Change-Id: Ia1273587840d55199846dc64d487d194f9a4d565 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* QDebug: add support for QVarLengthArrayMarc Mutz2021-06-131-6/+0
| | | | | | | | | | | | | | Remove a conflicting definition of the same operator from qrhi.cpp. Who knows how many ODR violations this hidden gem may have caused... [ChangeLog][QtCore][QDebug] Can now stream QVarLengthArray objects. [ChangeLog][QtCore][QVarLengthArray] Can now be output via QDebug streaming. Change-Id: I12f7670e32029fa8c96b446e9a98ebf3b9732d0d Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* rhi: Use QByteArray for storing data in QGles2BufferRobert Löhning2021-06-082-14/+12
| | | | | | | | | | 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-036-28/+46
| | | | | | Change-Id: I0c687677b7e86b7284130c775718b29aca2cca40 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: d3d: Avoid debug layer warning when having no vertex inputsLaszlo Agocs2021-05-311-7/+9
| | | | | | | Pick-to: 6.1 Fixes: QTBUG-94064 Change-Id: I03237fcff06225ba41c65c0171d77fb6ae75fcd3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for 3D texturesLaszlo Agocs2021-05-3114-203/+587
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: vk: Switch to the modern validation layer internallyLaszlo Agocs2021-05-311-14/+3
| | | | | | Task-number: QTBUG-88388 Change-Id: Ia30af6c4554594f094af7866ad6e10ed7929de27 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: Add support for importing an existing renderbuffer objectLaszlo Agocs2021-05-197-2/+94
| | | | | | | | | | | | | | | | | | | | | | 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>
* rhi: Fix memory leakRobert Löhning2021-05-101-3/+4
| | | | | | | | | | | | The leak can be reproduced by running the test project from QTBUG-63557 with asan, although that report is about yet another leak. [ChangeLog][gui][QRhiGles2] Fixed a memory leak in QRhiGles2 Task-number: QTBUG-63557 Pick-to: 6.1 Change-Id: Ic4d346abb36a5666feb3ceb881865b029f5a6945 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* rhi: gl: Sanity check vertex outputs and fragment inputsLaszlo Agocs2021-05-032-0/+26
| | | | | | | | | | | | | | | | | | | | | | Print a warning if the name for a given location does not match. This is relevant only to OpenGL and only to < 330 GLSL versions: there the location qualifier is simply not present in the actual shader code and all matching is name-based. This leads to hard to discover problems in Qt Quick ShaderEffects for instance, where providing a custom fragment shader but using a built-in vertex shader is common, and one may be tempted to use a name other than qt_TexCoord0 for the input variable in the fragment shader. Unfortunately this breaks, sometimes silently, when not having location qualifiers. (and we won't, neither in GLSL 120 or 150 which are the standard for Qt Quick) Make this situation recognizable by printing a warning to the debug output. Pick-to: 6.1 Task-number: QTBUG-92500 Task-number: QTBUG-93370 Change-Id: I0d0bcc135e23a228783f7633f872e39c4e43bb93 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Add QRhiTexture::RG16 formatLars Knoll2021-04-076-0/+29
| | | | | | | Those are needed to handle 16bit YUV formats in Qt Multimedia. Change-Id: I39c67bf4fcf558487b7819ea38e578f99c12a3ed Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add support for custom bytes-per-line for uncompressed raw dataLaszlo Agocs2021-03-309-19/+82
| | | | | | | Fixes: QTBUG-90770 Change-Id: Icba328c417bcce256e7b44f1d540af7f8e83376b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 22:32:09 +0000