summaryrefslogtreecommitdiffstats
path: root/tests/manual/rhi
Commit message (Collapse)AuthorAgeFilesLines
* rhi: multiview manual test: exercise passing through gl_ViewIndexLaszlo Agocs2024-04-166-1/+4
| | | | | Change-Id: Iee9a29250061ca57ea30e3e545d1a6de952c1852 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for resolving depth-stencilLaszlo Agocs2024-04-033-0/+277
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add setDepthResolveTexture(). Should work similarly to the color attachments' resolveTexture, but for depth or depth-stencil. However, this is another fragmented feature. - D3D11/12: Not supported. AFAICS multisample resolve (ResolveSubresource) is just not supported for depth or depth-stencil formats. - Vulkan: Not supported with Vulkan 1.0. Supported with Vulkan 1.1 and the two extensions. (VK_KHR_depth_stencil_resolve which in turn requires VK_KHR_create_renderpass2 since the 1.0 structs are not extensible, so now need to use VkRenderPassCreateInfo2 and all the '2' structs) In Vulkan 1.2 the above are in core, without the KHR suffix, but we cannot just use that because our main target, the Quest 3 (Android) is Vulkan 1.1. So 1.2 and up is ignored for now and we always look for the 1.1 KHR extensions. The depth resolve filter is forced for SAMPLE_0. AVG seems to be supported on desktop (NVIDIA) at least, but that's not guaranteed, so would need physical device support checks. On the Quest 3 it does not seem to be supported. And in any case, other APIs such as Metal do not have an AVG filter mode at all, so just use SAMPLE_0 always. - OpenGL (not ES): Should work, both when the multisample data is a renderbuffer and a texture. Relies on glBlitFramebuffer with filter NEAREST. What it does internally, with regards to the depth/stencil resolve mode, is not under our control. - OpenGL ES: Should work when the multisample buffer is a texture. But it will not work when a multisample renderbuffer (setDepthStencilBuffer, not setDepthTexture) is used because the GLES-only multisample extensions (GL_EXT_multisampled_render_to_texture, GL_OVR_multiview_multisampled_render_to_texture, which we prefer over the explicit resolve-based approach) work with textures only. - Metal: Should work. Task-number: QTBUG-122292 Change-Id: Ifa7ca5e1be78227bd6bd7546dde3a62f7fdbc95e Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Add configure feature for MetalTor Arne Vestbø2024-03-197-11/+11
| | | | | | | Simplifies maintenance of code paths that rely on Metal. Change-Id: I1d1f705fffc14dbafde346eeb555b43be6d5be54 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add QWidgetPrivate::rhi() helper methodTor Arne Vestbø2024-03-011-8/+1
| | | | | | | | For accessing the RHI managed by the widget compositing machinery. Pick-to: 6.7 6.6 6.5 Change-Id: Ia3c1227cc2d9cfebe95611cad3dbcd7aa6f6f8c7 Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* Remove extra semi-colonsTasuku Suzuki2024-02-061-1/+1
| | | | | Change-Id: I92fddb36cd136fd1bd627955f15d0559b9942d7e Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Change license for tests filesLucie Gérard2024-02-0459-59/+59
| | | | | | | | | | | | According to QUIP-18 [1], all tests file should be LicenseRef-Qt-Commercial OR GPL-3.0-only [1]: https://contribute.qt-project.org/quips/18 Pick-to: 6.7 Task-number: QTBUG-121787 Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8 Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
* Fix compilation error for QRhi stereo manual testHatem ElKharashy2023-10-051-0/+2
| | | | | | | | | Add a guard to prevent compilation error on non-Windows platform Change-Id: Ibe0d74c1dfe3d4656addeb80c702b6e254d37d84 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Kristoffer Skau <kristoffer.skau@qt.io>
* Add stereo support for DirectX12 and Vulkan backendsIlya Doroshenko2023-09-053-9/+58
| | | | | Change-Id: Id12723d6c392e25935ccb265c58af91aff968984 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: add a way to test Display P3 with the manual testLaszlo Agocs2023-08-151-3/+12
| | | | | | | | | | | Extended linear Display P3 + FP16 is likely the thing to use on platforms such as VisionOS and iOS (and optionally on macOS) and perhaps iOS). Enable testing this on macOS with the hdr manual test. Change-Id: I67f0bdbadae8c7ebccae7de008f12fd8d9135529 Reviewed-by: Andy Nichols <andy.nichols@qt.io> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* Add QRhiWidgetLaszlo Agocs2023-08-148-5/+5
| | | | | | Task-number: QTBUG-113331 Change-Id: I8baa697b4997b05f52acdee0e08d3c368fde5bc2 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Enhance the hdr info struct and add a manual testLaszlo Agocs2023-08-0315-45/+575
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...while sharing the related code between the d3d backends. The isHardCodedDefaults flag is not used in practice and is now removed. Add the luminance behavior and SDR white level (for Windows) to help creating portable 2D/3D renderers that composite SDR and HDR content. (sadly the Windows HDR and Apple EDR behavior is different, as usual) The new test application is expected to run with the command-line argument "scrgb" or "sdr". It allows seeing SDR content correction (on Windows) in action, and has some simple HDR 3D content with a basic, optional tonemapper. Also shows the platform-dependent HDR-related screen info. With some helpful tooltips even. Additionally, it needs a .hdr file after the 'file' argument. The usual -d, -D, -v, etc. arguments apply to select the 3D API. For example, to run with D3D12 in HDR mode: hdr -D scrgb file image.hdr The same in non-HDR mode: hdr -D sdr file image.hdr Change-Id: I7fdfc7054cc0352bc99398fc1c7b1e2f0874421f Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: gl: metal: Enable depth-stencil correctly with multiviewLaszlo Agocs2023-06-281-1/+1
| | | | | | | | | | | | | | | After fixing the data type for D24S8, we can now implement attaching depth and stencil (with the same texture). For Metal we need to set a stencil flag correctly. This allows using D24S8 in the manual test, which is likely the format that is going to be commonly used when setting up multiview with Qt Quick. Fixes: QTBUG-114904 Change-Id: Ife425c6cb3e09bfe40092c841b78f7a93bb6a4cd Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: Enable depth texture for multiviewLaszlo Agocs2023-06-281-1/+1
| | | | | | | | | | | | | | | Cannot just do like with other APIs and expose a view of multiple array layers. The only option is to use the multiview-specific API and specify layers 0..view_count-1 in the depth texture. This allows having depth in a multiview render pass with OpenGL. Note that this does not cover stencil. D24S8 does not work, so we may need to explore having a dedicated, separate stencil texture. Task-number: QTBUG-114896 Change-Id: I06ede1d77fef199148d595a55d144c96dc3cbc9d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Use a depth/stencil texture in the multiview manual testLaszlo Agocs2023-06-281-4/+17
| | | | | | | | ...and expand the docs a bit. Task-number: QTBUG-114896 Change-Id: I969c3aa2fa72a242e275e4b6dd996df20d1cd2ab Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: multiview: Exercise instancing in the testLaszlo Agocs2023-06-276-10/+33
| | | | | | | | | Just to make sure instanced drawing does not regress. Relevant particularly with Metal. Fixes: QTBUG-114885 Change-Id: Ib39066d32985bf25ca02d5aa54d9cf654772be9a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: metal: Add support for multiview renderingLaszlo Agocs2023-06-275-4/+4
| | | | | | | | | | | | | | Some shortcomings and unexpected problems are not unlikely. The basic feature, with 2 views going to a texture array's 0 and 1 elements, seems to be working with macOS, also with MSAA. Instanced drawing has not been verified. (relevant because layered rendering works via instancing in Metal and the QRhi backend has to adjust the instance count in every draw call) Fixes: QTBUG-114774 Change-Id: I3655e0d2c658b88c4cd6b52a32f94134324e4ac9 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Add an option to exercise MSAA in the multiview testLaszlo Agocs2023-06-261-3/+36
| | | | | | Task-number: QTBUG-114790 Change-Id: Id9378abb13e56062bf1db6c7360595b7a2f1afc6 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: multiview test: Fix leftover resourceUpdate callLaszlo Agocs2023-06-261-2/+0
| | | | | | | This should not be there because 'u' is passed to beginPass(). Change-Id: I95ba8ed400baa06948b4d4c6bbf7ca2d07a5480f Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: d3d12: Implement multiview supportLaszlo Agocs2023-06-226-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This relies on qsb being able to invoke dxc instead of fxc when the request HLSL (shader model) version is 6.1. (6.1 is required for SV_ViewID) This currently works only when conditioning offline with qsb (or via CMake), because qsb can easily invoke dxc instead of fxc. When shipping HLSL inside the .qsb package (so when -c is not specified or running the external tool fails), this won't work since the D3D12 backend still uses D3DCompile(), not IDxcCompiler. Support for that will be investigated separately. We also need to bump to ID3D12Device2 and ID3D12GraphicsCommandList1. With Windows 10 version 1703 being quite old now, this should not be a problem at run time. There are however issues at build time, namely that MinGW and MinGW/LLVM and similar seems to have ancient Windows SDK headers according to the CI test runs. None of the MSVC configurations have this in the CI, they have reasonable versions of d3d12.h and similar. Therefore, one important aspect of this change is that the D3D12 backend of QRhi will only be available from now on when the SDK headers are new enough (meaning ID3D12Device2 is declared, which is a several years old type now). Otherwise, QRhi::create() will simply fail when asking for D3D12 with a helpful warning message about the Qt build being crippled. Implementation-wise, there are surprises in store as well: The way the PSO is created needs to be revamped to follow the extensible approach that uses a pipeline state stream description. Both the graphics and compute pipeline creation is changed to use CreatePipelineState() and the associated machinery. This is only really essential for graphics pipelines since we know have to include data for view instancing (multiview). For compute the result is the same as before. Additionally, the view count must now be baked into the QRhiGraphicsPipeline. This means that applications must call setMultiViewCount() with the same value (typically 2) *both* on the render target's color attachment and on the pipeline. Backends that do not care about the pipeline's view count (GL, Vulkan) will of course ignore it, but if it's not set correctly D3D12 will fail. The manual test is updated accordingly. Fixes: QTBUG-114772 Change-Id: I93db7313377e711c2faeb956815899b12132d23b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Introduce multiview starting with OpenGL (ES)Laszlo Agocs2023-06-2215-1/+359
| | | | | | Fixes: QTBUG-114770 Change-Id: Ibb1ced7f19d15a5116c60e95fd3e6b86ace63155 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Make it a QPA-style private but semi-public APILaszlo Agocs2023-05-2120-110/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from shadertools; done separately) become "RHI APIs", following the concept of QPA APIs. Mirror completely what is done for QPA headers, but using the "rhi" prefix for the headers. This involves updating syncqt to handle the new category of headers. (a note on the regex: matching everything starting with "qrhi" is not acceptable due to incorrectly matching existing and future headers, hence specifying the four header names explicitly) There is going to be one difference to QPA: the documentation for everything RHI is going to be public and part of the regular docs, not hidden with \internal. In addition to the header renaming and adding the comments and documentation notes and warnings, there is one significant change here: there is no longer a need to do API-specific includes, such as qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a single header that is then included from qrhi.h. This means that users within Qt, and any future applications can just do #include <rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no other headers are needed. There are no changes to functionality in this patch. Only the documentation is expanded, quite a lot, to eliminate all qdoc warnings and make the generated API docs complete. An example, with a quite extensive doc page is added as well. Task-number: QTBUG-113331 Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* rhi: update manual test shadersLaszlo Agocs2023-04-208-4/+4
| | | | | | | | | | ...so we have core profile compatible GLSL code in them. Just so one can run e.g. triquadcube with -g -c (OpenGL with a core profile context). Pick-to: 6.5 Change-Id: I585d3b4f0c7cd71ce7fae1fff4bf9a84cb7410da Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Replace the temporary GPU time query API with a saner oneLaszlo Agocs2023-04-183-21/+16
| | | | | | | | | | | | | | | | | | | | | | | Modeled after Metal's cb.GPUStart/EndTime. Implemented with timestamp queries for other APIs. Implemented for Metal, D3D11, Vulkan for now. No more callback, just a getter on the command buffer which returns the latest known value, referring to some previous frame. This makes it a lot more usable than the original solution that is not really used anywhere at the moment. Now works for offscreen "frames" as well, this was not implemented before. Opt in with a new QRhi::create() flag because we cannot tell in advance if the getter will be called or not, and this way we can skip recording the timestamps by default. The cost is probably minimal, though. Qt Quick will set this automatically when running with QSG_RHI_PROFILE=1. Change-Id: I903779984a4e0bbf1d03806d04bf61571ce23d72 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Fix offscreen manual test's Vulkan initLaszlo Agocs2023-04-181-0/+1
| | | | | | Pick-to: 6.5 Change-Id: Iaf7da78fd0c1c1265b05bfd4c7ced5d94ae963fe Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Replace PUBLIC_LIBRARIES with LIBRARIES in qt_internal_add_manual_testAmir Masoud Abdol2023-04-132-2/+2
| | | | | | | | Noticed the warnings when building the manual tests. Pick-to: 6.5 Change-Id: I7f927f42f11d234ec3c980f36d8e12c0c49be712 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* rhi: Remove unused init flagLaszlo Agocs2023-04-122-2/+2
| | | | | Change-Id: I289452f39fd161da0e0d7bf329e0922df6bbde8a Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi manual tests: allow having some gui controlsLaszlo Agocs2023-03-2328-51/+52606
| | | | | | | | | | | | | Having a simple Dear ImGui bridge is not just useful for the manual tests, which do not have any other means to displays GUIs, but is in itself an important exercise for the QRhi machinery. Have a new manual test that exercises the built-in ImGui demo window. Then use it in the displacement test for real, to replace the myriads of key presses with on-screen sliders and checkboxes (with less code). Change-Id: I296bafae2a5cce6fc7a447d97e68e5bcec15f451 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: displacement / tessellation manual test Metal memory alignmentBen Fletcher2023-03-107-5/+5
| | | | | | | | | | | This test was created with a work around for a Metal tessellation pipeline memory alignment issue. The workaround was to specify shader stage in / out variable uv as vec3 rather than vec2. A recent patch to correct Metal tessellation pipeline memory alignment has now allowed this test to use vec2 for variable uv as originally intended. Change-Id: I6772c0e824e1e4b7e749dafa218f3fd8eba0e541 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi manual test: Bump Vulkan instance API version requestLaszlo Agocs2023-03-091-4/+7
| | | | | | | | Do what Qt Quick would do. Change-Id: I82743a39808601752f4ecbdb74b87f3a757a9310 Reviewed-by: Kristoffer Skau <kristoffer.skau@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add missing shbang line to shell scriptEdward Welbourne2023-02-241-0/+1
| | | | | | | If it's executable, it should specify how it's to be executed. Change-Id: If5671712da3e1fbc42b15d22c1253129910091bc Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: d3d11: Drop the built-in TDR testLaszlo Agocs2023-02-201-14/+1
| | | | | | | | | This does not really belong here as a built-in feature, esp. considering that such testing is relevant for other backends as well. Change-Id: Ifbe3b8c6a430aacb9fcbdabf0e3761b14c48decc Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* tests: Remove remains of qmake conversion from CMakeLists.txt filesFriedemann Kleint2023-02-1723-125/+0
| | | | | | | Pick-to: 6.5 Change-Id: I8d106554bb86ac1ec9bb7a4083de4c376bcbab1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* rhi: Add a displacement / tessellation manual testLaszlo Agocs2023-02-1417-0/+505
| | | | | | | | | | | | | | | | | | | | There is something odd when running on Metal: note how the uv is vec3 instead of vec2, in order to make the vertex-tesc-tese data to look like this: struct main0_out { float3 out_uv; float3 out_normal; float4 gl_Position; }; if out_uv was float2 we'd get some strange rendering results, perhaps due to something related to alignment. But have no means to investigate this further. Change-Id: I79d4edb2ddde3971c599c4326d98e99a49aa7122 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add D3D12 supportLaszlo Agocs2023-02-076-11/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - The optional nice-to-haves DebugMarkers, Timestamps, PipelineCache are not yet implemented (features reported as false, to be implemented later, although buffer/texture resource name setting already works as-is, regardless of DebugMarkers). - Mipmap generation for 3D textures is missing. Won't matter much given that 3D textures are not used in Qt for anything atm. For generating mipmaps for 2D (or 2D array) textures, the MiniEngine compute shader and approach is used. 3D support for the mipmap generator may be added later. 1D textures / arrays are supported except for mipmap generation, and so the OneDimensionalTextureMipmaps feature is reported as false. - Qt Quick and Qt Quick 3D are expected to be fully functional. (unforeseen issues are not impossible, of course) - Uses minimum feature level 11.0 when requesting the device. It is expected to be functional on resource binding tier 1 hardware even, although this has not been verified in practice. - 2 frames in flight with the usual resource buffering (QRhiBuffer::Dynamic is host visible (UPLOAD) and always mapped and slotted, other buffers and textures are device local (DEFAULT). Requests 3 swapchain buffers. Swapchains are mostly like with D3D11 (e.g. FLIP_DISCARD and SCALING_NONE). - The root signature generation is somewhat limited by the SPIR-V binding model and that we need to map every binding point using the nativeResourceBindingMap from the QShader. Thus the root signature is laid out so each stage has its own set of resources, with shader register clashes being prevented by setting the visibility to a given stage. Sampler handling is somewhat suboptimal but we are tied by the binding model and existing API design. It is in a fairly special situation due to the 2048 limit on a shader visible sampler heap, as opposed to 1000000 for SRVs and UAVS, so the approach we use for textures (just stage the CPU SRVs on the (per-frame slot) shader visible heap as they are encountered, effectively treating the heap as a ring buffer) would quickly lead to having to switch heaps many times with scenes with many draw calls and sampledTexture/sampler bindings in the srb. Whereas static samplers, which would be beautiful, are impossible to utilize safely since we do not have that concept (i.e. samplers specified upfront, tied to the graphics/compute pipeline) in the QRhi API, and an srb used at pipeline creation may change its associated resources, such as the QRhiSampler reference, by the time the shader resources are set for the draw call (or another, compatible srb may get used altogether), so specifying the samplers at root signature creation time is impossible. Rather, the current approach is to treat each sampler as a separate root parameter (per stage) having a descriptor table with a single entry. The shader visible sampler heap has exactly one instance of each unique sampler encountered during the lifetime of the QRhi. - Shader-wise no different from D3D11, works with HLSL/DXBC 5.0 (i.e. existing .qsb files with DXBC in them work as-is). But unlike D3D11, this one will try to pick 6.7, 6.6, ..., down to 5.0 from the QShader, in that order. - Uses D3D12MA for suballocating. As a result it can report vmem allocation statistics like the Vulkan backend, and it does more since the DXGI memory usage (incl. implicit resources) is also reported. This is optional technically, so we also have the option of going straight with the heavyweight CreateCommittedResource() instead. That is what we do if the adapter chosen reports it's software-based or when QT_D3D_NO_SUBALLOC=1 is set. - PreferSoftwareRenderer (picking the WARP device) and the env.var. QT_D3D_ADAPTER_INDEX work as with the D3D11 backend. - It is not unexpected that with large scenes that generate lots of draw calls with multiple textures/samplers per call the performance may be slightly below D3D11 (probably mostly due to descriptor management). Similarly, the reported memory usage will be higher, which is partly natural due to creating heaps, descriptor pools, staging areas, etc. upfront. Will need to be evaluated later how these can be tuned. Change-Id: I5a42580bb65f391ebceaf81adc6ae673cceacb74 Reviewed-by: Andy Nichols <andy.nichols@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix up rhiwidget manual test after the QWidgetPrivate changeLaszlo Agocs2022-12-011-1/+7
| | | | | | Change-Id: Id3e8d8ce7e175be9b5e9e83e23910546d69a90fa Reviewed-by: Kristoffer Skau <kristoffer.skau@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: tex1d manual test: Also build GLSL 120 shadersLaszlo Agocs2022-11-163-2/+2
| | | | | | | | | | This way we can run the test on macOS with the version 2.1 OpenGL context. Amends 85a1663eb15cd85f91fe1f6dd924588d9cc7c2a8 Change-Id: I8ec122fefaab54b35613e226e3937f4b51a7ea5a Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* RHI: Add support for 1D texturesBen Fletcher2022-11-158-0/+716
| | | | | | | Support for 1D textures on Vulkan, OpenGL, Metal, and D3D. Change-Id: Ie74ec103da9cfcbf83fa78588cf8cfc1bd6e104f Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Add support for stereoscopic content in QRhi::OpenGLES2Kristoffer Skau2022-11-077-0/+415
| | | | | | | | | | Setting the flag QSurfaceFormat::StereoBuffers does not actually do anything, because we do not utilize the extra buffers provided. We need to expose setting the correct buffers using glDrawBuffers between draw calls. Change-Id: I6a5110405e621030ac3a2886fa83df0cfe928723 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add a manual test for simple stencil-based outlineLaszlo Agocs2022-10-259-1/+202
| | | | | | | | | | | | | Interesting on its own just because it exercises stencil testing, unlike any of the other existing manual tests. In addition it serves as a base example for how outlines could be done, it is one possible approach at least. (render with stencil write, then render again slightly scaled up with a solid color with testing against the stencil buffer content) Change-Id: I0c845a9004136f229cab037f6f0aab2f772bdd76 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: metal: Add support for tessellationLaszlo Agocs2022-09-019-11/+44
| | | | | Change-Id: Ie8d226a6a959aa5e78284ea72505fd26aec1e671 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Move QMacAutoReleasePool from qglobal.h to qcore_mac_p.hSona Kurazyan2022-09-012-0/+5
| | | | | | | | And include qcore_mac_p.h where needed. Task-number: QTBUG-99313 Change-Id: Idb1b005f1b5938e8cf329ae06ffaf0d249874db2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-2328-28/+28
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* rhi: d3d11: Enable tessellation and geometry with some caveatsLaszlo Agocs2022-08-1512-4/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | The caveat being having to manually create HLSL versions of the hull, domain, and geometry shaders in parallel with the Vulkan GLSL ones, while keeping the interfaces intact (stage inputs and outputs, cbuffer layouts, binding points/registers). This is not always trivial but typically doable in not very complicated case after inspecting the SPIRV-Cross-generated vertex/fragment code in the .qsb files. Once written, the HLSL files can be injected into a .qsb file with qsb -r. or the corresponding CMake syntax. Conceptually this is no different from how samplerExternalOES support is implemented for Multimedia. (there the problem is that the shaders cannot be compiled to SPIR-V to begin with, here it is that we cannot translate from SPIR-V, but in the end the workaround for both problems is effectively the same) The manual tests demonstrate this, both the tessellation and geometry apps work now with D3D out of the box. On the bright side, the implementation here in the the D3D backend of QRhi does not need to know about how the shaders got there in the QShader. So none of the implementation is dependent on this manual process. If some day qsb would start translating to these kind of shaders as well, it would all still work as-is. Change-Id: I32d9ab94e00174e4bd5b59ac814dfedef9f93ad1 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-0328-0/+84
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* rhi: gl: Avoid magic adjustments to the context/window formatLaszlo Agocs2022-08-015-15/+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>
* CMake: Rename tests to be unique for top-level buildsAlexandru Croitor2022-07-281-2/+2
| | | | | | | Pick-to: 6.4 Task-number: QTBUG-105238 Change-Id: I6c0276d14b4d90046b0fcfd281e198f59318e804 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Don't use PUBLIC_LIBRARIES for tests and test helpersAlexandru Croitor2022-07-2827-27/+27
| | | | | Change-Id: I9b7404e1d3a78fe0726ec0f5ce1461f6c209e90d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* rhi: Clean up some inconsistenciesLaszlo Agocs2022-07-122-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 a manual testLaszlo Agocs2022-07-071-1/+1
| | | | | | | | ...that uses the old name after a recent change in the name of a function. Change-Id: Ife36fbb0c5d28b350cb1cfc48625528a205af8f9 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: metal: Switch back to presentDrawableLaszlo Agocs2022-06-281-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This convenience should be, according to the Apple docs, equivalent to calling present from a scheduled handler. (which on its own makes it unclear why we switched in the first place) In practice it seems the two approaches are not identical. It looks like that once a frame is submitted earlier than the next display link callback, the throttling behavior we implement in beginFrame() (waiting on the semaphore for the completion of the appropriate command list etc.) starts exhibiting unexpected behavior, not correctly throttling the thread to the refresh rate. Changing back to presentDrawable does not exhibit this at all. The suspicion is that presentDrawable is probably doing more than what the docs suggest, and so is not fully equivalent to calling present manually from a scheduled handler. Therefore, switch to presentDrawable now, which restores the expected cross-platform behavior, but make a note of the oddity, and also prepare the hellominimalcrossgfxtriangle manual test to provide an easy, self-contained application to allow experimenting in the future, if needed. This allows Qt Quick render thread animations to advance at the expected speed (because the render thread is correctly throttled to the refresh rate), even if the render thread decides to generate a new frame right away, without waiting for the next display link update. Without this patch, attempting to get updates not via requestUpdate(), but by other means (timer etc.) leads to incorrect throttling, and so the triangle in the test app is rotating faster than expected - but only with Metal. Running with OpenGL on macOS or with any API on any other platform the behavior will be correct. Even if scheduling updates without display link is not efficient, and should be discouraged, not doing so cannot break the core contract of vsync throttling, i.e. the thread cannot run faster just because it renders a frame not in response to an UpdateRequest. Amends 98b60450f7ce6b16464392747ab8721f30add15e (effectively reverts but keeps the code and the notes because we might want to clear this up some day) Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-103415 Change-Id: Id3bd43e94785384142337564ce4b2644bf257100 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-04 09:04:29 +0000