summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi/qrhi.cpp
Commit message (Collapse)AuthorAgeFilesLines
* rhi: Keep track of pipeline creation timesLaszlo Agocs2022-07-051-14/+41
| | | | | | | | | | | | | | | | | | | | | 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>
* rhi: Make it possible to query the backend name beforehandLaszlo Agocs2022-07-051-4/+13
| | | | | | | | | | | | | | | | The goal is to make it possible to implement QSGRhiSupport::backendName() in Qt Quick with just a single line: return QString::fromUtf8(QRhi::backendName(m_rhiBackend)); instead of duplicating the strings and the logic. Similarly, QBackingStoreRhiSupport can now drop its apiName() helper entirely. Change-Id: Ia8cbb1f1243539ed4d7a98e71dcc2ed56b017e40 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Fix a doc snippetLaszlo Agocs2022-07-051-3/+6
| | | | | | | | | Docs are private for now, but it is still preferable that the code snippets in there are up-to-date. Change-Id: Icaf28d9b6a9ac029755ba241263f59d5091aa1b5 Reviewed-by: Inho Lee <inho.lee@qt.io> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Fix typos in docs and commentsKai Köhne2022-06-151-2/+2
| | | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: Ie3e301a23830c773a2e9aff487c702a223d246eb Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* rhi: d3d11: Make the "pipeline" cache save/load functionalLaszlo Agocs2022-06-011-21/+53
| | | | | | | | | | | | | | | | | | | | | | | | There are no pipelines here of course. That's only for Vulkan. But the QRhi APIs provide a common interface for retrieving the serialized blob and pre-seeding the cache with a blob. The OpenGL backend already implements that interface via GL program binaries. We can do something similar with D3D, but it's a lot simpler: we just need to include the bytecode from HLSL->DXBC compilation (i.e. the result of D3DCompile() calls) and pick up the already present bytecode and skip the D3DCompile() call when applicable. Thus the mechanism is now available for Vulkan, OpenGL, and D3D11 as well. Has no effect whatsoever if EnablePipelineCacheLoadSave is not set at QRhi create() time. Also update the related docs. Task-number: QTBUG-103802 Change-Id: I91f1fb1f471bc7c654e26886a37c283066e842a8 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Fix texture format doc typo and rephraseLaszlo Agocs2022-05-241-3/+3
| | | | | Change-Id: Ica4cc0fcea642eccfff7b53a65e7d1a428fd4dad Reviewed-by: Christian Strømme <christian.stromme@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: Add a feature flag for non-fill polygon modesLaszlo Agocs2022-04-221-1/+10
| | | | | | | | 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>
* rhi: Add explicit subclass for RTs from swapchainsLaszlo Agocs2022-04-051-10/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/+22
| | | | | | | | | | | | | | | | | | 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>
* Fix deprecated uses of QScopedPointerMårten Nordheim2022-03-081-3/+5
| | | | | | | | | By changing it to unique_ptr. Pick-to: 6.2 6.3 Change-Id: I91abb69445b537d4c95983ae735341882352b29d Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* rhi: Add the long-pending probe() helper, with backing for MetalLaszlo Agocs2022-02-091-0/+48
| | | | | | | | | | | | | | | | | | | | | There is a TODO for this in Qt Quick from the 6.0 times. To decide upfront if Metal can be expected to function, or if a fallback to OpenGL needs to be triggered (especially important with macOS virtual machines, where, unlike any real macOS system, Metal may not be present at all), the scenegraph calls create() and then drops the result. The idea to make this less wasteful was back then to add a dedicated probing function which can, possibly, perform the checks in a more lightweight manner than full initialization. Implement this now, focusing on Metal. Brought to attention by QTBUG-100441: printing warnings about not having an MTLDevice is confusing in a Metal-less macOS VM, because it is not an actual error, only part of the probing at scenegraph initialization. We can now avoid printing confusing warnings there. Change-Id: Ie52c36af9224bedc3f5e4c23edb486d961c9f216 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Code quality - remove defaults from switch enumsBen Fletcher2022-02-011-25/+8
| | | | | | | | | | | | | On code review of previous RHI patches it was noted that many switch on enum statements contain a default. This is discouraged as it prevents the compiler from automatically identifying switch statements that do not cover all enum cases. This patch addresses rhi base classes. Further patches required for specific backend implementations. Change-Id: Ib2bb30c66fd214b65a4ca7b787c7c610f3c313f5 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add the basic infrastructure for geometry shader supportBen Fletcher2022-01-311-0/+17
| | | | | | | | | | | | | | | | | | | | | .. 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/+14
| | | | | | | | | | | | | | | | | 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-7/+7
| | | | | | | | | 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/+12
| | | | | | | | | 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>
* rhi: Add the basic infrastructure for tessellation supportLaszlo Agocs2022-01-131-3/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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/+10
| | | | | | | | | | 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/+17
| | | | | | | | | | | 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: Add some docs for the hdr info queriesLaszlo Agocs2022-01-111-0/+55
| | | | | Change-Id: I9b3b62ac83642a7d3e474c991e572877b9e46ca5 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for separate image and sampler objectsLaszlo Agocs2022-01-061-8/+158
| | | | | | | | | | | | | | | | | | | | | 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: Expose HDR output info in a saner wayLaszlo Agocs2022-01-061-8/+27
| | | | | | | | | | Don't bother with exposing the IDXGIOutput6. Instead, report the values, just the ones that matter for tonemapping or transfer functions in a cross-platform way that's also prepared for Metal's different way of doing things. Change-Id: I28c7b6144f8267a9d3d44eff1e40697fb543385f Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Drop the profiler for nowLaszlo Agocs2022-01-041-52/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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-1/+35
| | | | | | | | | | | | | | | | | | | | | | | 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>
* rhi: Expose the maximum uniform buffer range limitLaszlo Agocs2021-11-101-0/+15
| | | | | | | | 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: Add texture array supportLaszlo Agocs2021-10-291-23/+81
| | | | | | | | | | | | | | 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: 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: 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>
* gui: Fix typos in documentationJonas Kvinge2021-10-121-5/+5
| | | | | | Pick-to: 5.15 6.2 Change-Id: I533f5a55cd0cd60a76990b552d7dab51a301ac1c Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* 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-161-1/+23
| | | | | | | | | | | | | | | | | | | 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-161-0/+7
| | | | | | | | | | | | | | 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: Improve srb layout serialization helpersLaszlo Agocs2021-09-071-1/+1
| | | | | | | | | | | 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-071-6/+5
| | | | | | 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-071-0/+8
| | | | | | | | | | | | | | | | | | | | | ...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: 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-031-4/+9
| | | | | | | | | | | | | | | 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: 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: metal: Make base vertex and instance support optionalLaszlo Agocs2021-08-181-4/+9
| | | | | | | | | | | | | | | | | | | | | | | 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>
* rhi: Be more graceful when one destroys a resource after the QRhiLaszlo Agocs2021-08-021-4/+12
| | | | | | | | | | | | | | | | | | | | | 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>
* 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: Enable reading back slices of 3D texturesLaszlo Agocs2021-06-031-4/+5
| | | | | | 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-8/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+47
| | | | | | | | | | | | | | | | | | | | | | 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>
* Add QRhiTexture::RG16 formatLars Knoll2021-04-071-0/+5
| | | | | | | 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-301-7/+26
| | | | | | | 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-21 15:57:31 +0000