summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi/qrhi_p.h
Commit message (Collapse)AuthorAgeFilesLines
* rhi: Make sample count selection logic be closer to Qt 5Laszlo Agocs2023-12-061-0/+2
| | | | | | | | Pick-to: 6.6 6.5 Fixes: QTBUG-119148 Change-Id: Ia119ab3ced9da08853c608aa256bde08a6fd8d4e Reviewed-by: Andy Nichols <andy.nichols@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* rhi: Enable registering cleanup callbacks with a keyLaszlo Agocs2023-07-311-0/+11
| | | | | | | | | And the ability to deregister. Going to be required by QRhiWidget. Change-Id: If185cbed2faa042098ac1f6bb1d6daaffd834377 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: metal: Enable depth-stencil correctly with multiviewLaszlo Agocs2023-06-281-0/+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: Make it a QPA-style private but semi-public APILaszlo Agocs2023-05-211-1790/+621
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Replace the temporary GPU time query API with a saner oneLaszlo Agocs2023-04-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | 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: Remove unused init flagLaszlo Agocs2023-04-121-4/+3
| | | | | Change-Id: I289452f39fd161da0e0d7bf329e0922df6bbde8a Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Remove readback result type aliasLaszlo Agocs2023-04-121-3/+1
| | | | | | Change-Id: I1b14d3230ab4011506892c64ea03d5431d82a90d Reviewed-by: Christian Strømme <christian.stromme@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* rhi: Clean up 1D and 3D texture feature flagsLaszlo Agocs2023-03-071-1/+3
| | | | | | | | | | | | | | Separate 1D mipmap generation support from rendering into an 1D texture. Those are two independent features, so have a separate feature flag for both instead of using just one. This will then be symmetric with the 3D texture features, where now we have a new flag to report support for generating mipmap for 3D textures. (whereas 3D texture as a render target is already covered by RenderTo3DTextureSlice) Change-Id: Ie5e1f056a7d1c341d90cd7fc522877a3f2da3290 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Remove unused gettersLaszlo Agocs2023-03-021-4/+0
| | | | | | Change-Id: Ifb1e42b75a7f9ae51929c56809454d9207fa0d1c Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for half precision vertex atttributesBen Fletcher2023-02-271-2/+7
| | | | | | | | | | | | | | | | | | | Runtime support is indicated via QRhi::Feature::HalfAttributes. OpenGL support is available in OpenGL 3.0+, OpenGL ES 3.0+, and in implementations that support the extension GL_ARB_half_float_vertex. Other RHI backends (Vulkan, Metal, D3D11, and D3D12) all support this feature. Note that D3D does not support the half3 type. D3D backends pass half3 as half4. tst_qrhi auto unit test included. Change-Id: Ide05d7f62f6102ad5cae1b3681fdda98d52bca31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Make some op== and qHash hidden friendsLaszlo Agocs2023-02-221-23/+146
| | | | | | Change-Id: I0ba829b5b3df7ebff2fe7da81424e2623a895325 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Make the mip size helpers staticLaszlo Agocs2023-02-201-2/+2
| | | | | Change-Id: Ibe480330290ccddeac0a62b52a8a33c3399cb5bc Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Remove QRhiSrb data gettersLaszlo Agocs2023-02-201-1/+3
| | | | | | | | | | | | | | | | This is for internal use, QRhiShaderResourceBinding does not need to have the data() getters. The backends can use any internal means to access this, no need to have the getters in the frontend just for that. Now, Qt Quick 3D has a special case of accessing this, hence keeping the two getters for now, to be removed in a follow up once that repo updates. While we are at it, share and reuse the sorting function. Change-Id: Ia2308af79863c72ca65024ce6c00531d0256a2cb Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: backends: Get color attachment count in a saner wayLaszlo Agocs2023-02-201-4/+14
| | | | | | | | Also bring all list-like data to the same level when it comes to the interface exposed in QRhi*. Change-Id: I90296a49ff1f52c1ce4e787167c99006fab3c4c3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add D3D12 supportLaszlo Agocs2023-02-071-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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>
* rhi: metal: Add enablers for pre-querying window stuff on the gui threadLaszlo Agocs2023-01-041-0/+11
| | | | | | | | Pick-to: 6.5 Task-number: QTBUG-97518 Change-Id: Ia8fb5128149c9f91ebedfa914d1fe3e3d49774dc Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* RHI: Add support for 1D texturesBen Fletcher2022-11-151-2/+5
| | | | | | | 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-071-0/+6
| | | | | | | | | | 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 way to query the parent QRhi from a resourceLaszlo Agocs2022-10-051-0/+3
| | | | | | | | | | Quick3D introduces the need to verify the QRhi when only a QRhiTexture (pulled out from a QSGTexture) is available. To enable this, there needs to be a way to retrieve the QRhi from the QRhiTexture. Change-Id: I00777f08b030a7de742169beb0b99ca6282d51a6 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Clean up some inconsistenciesLaszlo Agocs2022-07-121-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the offsets are already quint32 in the API (vertex input attributes, dynamic offsets, offsets in draw calls), matching the reality of the underlying 3D APIs, but many buffer-related functions use int as of now, simply because that used to be the default choice, and the same goes for sizes (such as buffer or range sizes). This is not quite consistent and should be cleaned up if for nothing else then just to make the classes consistent, but also because no 3D API use a signed type for offsets, sizes, and strides. (except OpenGL for some) When it comes to strides (for vertex inputs and raw image texture uploads), those are already all quint32s. This is straightforward because most of the 3D APIs use 32-bit uints for these regardless of the architecture. Sizes and offsets are often architecture-dependent (Vulkan, Metal), but there is at least one API where they are always 32-bit even on 64-bit Windows (UINT == unsigned int, D3D11). In addition, we do not really care about buffer or texture data larger than 4 GB, at least not without realistic use cases and real world testing, which are quite unlikely to materialize for now (esp. since we still have the width/height of 2D textures limited to 16 or 32K in many cases even on desktops, whereas 2GB+ buffers are not guaranteed in practice even when an API seemingly allows it). In any case, the important change here is the signed->unsigned switch. A number of casts can now be removed here and there in the backends, because the offsets and sizes are now unsigned as well, matching the underlying API reality. The size can be potentially increased later on with minimal effort, if that becomes necessary for some reason. Change-Id: I404dbc365ac397eaeeb3bd2da9ce7eb98916da5f Reviewed-by: Inho Lee <inho.lee@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Fix up the instancing step rate typeLaszlo Agocs2022-07-071-4/+4
| | | | | | | | | | | | | | | This is a UINT/uint32_t/GLuint/NSUInteger in all APIs (with Metal being special due to being 64-bit in 64-bit apps whereas all others are 32-bit always, at least on 64-bit Windows) As the stride is already an uint32, follow suit for the step rate. There was no reason to have this as int in the first place. As an added bonus, some casts, that were previously needed when mapping to the underlying API reality, can now be removed. Change-Id: I8e0eef037bd795b637578dfc3e59dc2efaa5976c Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Keep track of pipeline creation timesLaszlo Agocs2022-07-051-4/+5
| | | | | | | | | | | | | | | | | | | | | 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-0/+1
| | | | | | | | | | | | | | | | 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>
* 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/+2
| | | | | | | | It's one thing that this is not part of OpenGL ES, but it is optional even with Vulkan, with some mobile GPUs not offering the feature at all. Change-Id: I4e2c6642eccb0793e69074b4b6eeb2b7cef3516e Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Add explicit subclass for RTs from swapchainsLaszlo Agocs2022-04-051-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+12
| | | | | | | | | | | | | | | | | | 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>
* rhi: Add the long-pending probe() helper, with backing for MetalLaszlo Agocs2022-02-091-0/+1
| | | | | | | | | | | | | | | | | | | | | 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: Add the basic infrastructure for geometry shader supportBen Fletcher2022-01-311-3/+6
| | | | | | | | | | | | | | | | | | | | | .. 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/+9
| | | | | | | | | | | | | | | | | 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: Add the basic infrastructure for tessellation supportLaszlo Agocs2022-01-131-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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-1/+3
| | | | | | | | | | 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/+2
| | | | | | | | | | | 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 support for separate image and sampler objectsLaszlo Agocs2022-01-061-3/+16
| | | | | | | | | | | | | | | | | | | | | 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-2/+26
| | | | | | | | | | 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-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | The system we inherited from the original Qt 5.14 introduction of QRhi is a text stream based solution where resource creation and frame timings are sent in a comma-separated format to a QIODevice. This, while useful to get insights about the number of resources at a given time, is not actively helpful. The frameworks built on top (Qt Quick, Qt Quick 3D) are expected to provide solutions for logging timings in a different way (e.g. via the QML Profiler). Similarly, tracking active resources and generating statistics from that is better handled on a higher level. The unique bits, such as the Vulkan memory allocator statistics and the GPU frame timestamps, are converted into APIs in QRhi. This way a user of QRhi can query it at any time and do whatever it sees fit with the data. When it comes to the GPU timestamps, that has a somewhat limited value due to the heavy asynchronousness, hence the callback based API. Nonetheless, this is still useful since it is the only means of reporting some frame timing data (an approx. elapsed milliseconds for a frame) from the GPU side. Change-Id: I67cd58b81aaa7e343c11731f9aa5b4804c2a1823 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add the basics for HDR swapchainsLaszlo Agocs2022-01-031-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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: Expose the maximum uniform buffer range limitLaszlo Agocs2021-11-101-1/+2
| | | | | | | | Pick-to: 6.2 Task-number: QTBUG-97715 Change-Id: I7f0a52c410b9b77f735fb3b7fd33141674bb0cda Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add texture array supportLaszlo Agocs2021-10-291-4/+17
| | | | | | | | | | | | | | 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: Remove Q_RELOCATABLE_TYPE for types with QVLA in themLaszlo Agocs2021-09-201-7/+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: Allow testing renderpass compatibility without the objectsLaszlo Agocs2021-09-161-0/+2
| | | | | | | | | | | | | | | | | | | Follow what has been done for QRhiShaderResourceBindings. Have a way to retrieve an opaque blob (that just happens to be a list of integers) so that a simple == comparison can be used to determine compatibility even when the objects from which the blob was retrieved are no longer alive. The contract is the following: bool a = rp1->isCompatible(rp2); bool b = rp1->serializedFormat() == rp2->serializedFormat(); assert(a == b); Pick-to: 6.2 Change-Id: I45e7d05eeb6dfa2b2de474da0a0644912aaf174a Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: gl: Have a way to state GL_TEXTURE_RECTANGLE is wantedLaszlo Agocs2021-09-161-1/+2
| | | | | | | | | | | | | | 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-2/+3
| | | | | | | | | | | 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-4/+26
| | | | | | 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-1/+6
| | | | | | | | | | | | | | | | | | | | | ...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-031-0/+9
| | | | | | | | | | | | | | | | | 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: Include resource count in srb layout compatibility checksLaszlo Agocs2021-09-031-2/+4
| | | | | | | | | | | | | | | 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: Add support for 3D texturesLaszlo Agocs2021-05-311-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Supported on OpenGL (and ES) 3.0+ and everywhere else. Can also be a render target, targeting a single slice at a time. Can be mipmapped, cannot be multisample. Reading back a given slice from a 3D texture is left as a future exercise, for now it is documented to be not supported. Upload is going to be limited to one slice in one upload entry, just like we specify one face or one miplevel for cubemap and mipmapped textures. This also involves some welcome hardening of how texture subresources are described internally: as we no longer can count on a layer index between 0..5 (as is the case with cubemaps), simply arrays with MAX_LAYER==6 are no longer sufficient. Switch to sufficiently dynamic data structures where applicable. On Vulkan rendering to a slice needs Vulkan 1.1 (and 1.1 enabled on the VkInstance). Task-number: QTBUG-89703 Change-Id: Ide6c20124ec9201d94ffc339dd479cd1ece777b0 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: Add support for importing an existing renderbuffer objectLaszlo Agocs2021-05-191-1/+7
| | | | | | | | | | | | | | | | | | | | | | 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/+1
| | | | | | | Those are needed to handle 16bit YUV formats in Qt Multimedia. Change-Id: I39c67bf4fcf558487b7819ea38e578f99c12a3ed Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 18:11:53 +0000