summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi/qrhi_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* rhi: Make it a QPA-style private but semi-public APILaszlo Agocs2023-05-211-804/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-17/+1
| | | | | | | | | | | | | | | | | | | | | | | 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: Make it safe to always call deleteLater on a resourceLaszlo Agocs2023-04-181-9/+8
| | | | | | | | | | | | | | | | | | | ...even when the QRhi is already gone. This should not happen in well-written applications and libraries, but we handle this gracefully in the regular dtor and destroy() for resources that register themselves to their creator QRhi, so by registering everything we can offer this to all QRhiResource subclasses. We still want to differentiate between native resource owning QRhiResources and others (that do not create native graphics objects), so do this via a flag passed to registerResource(). This way the behavior with QT_RHI_LEAK_CHECK=1 does not change. Pick-to: 6.5 Fixes: QTBUG-112914 Change-Id: I9bafc81ef7a4ae76f356fc5f6248628d1f8791e0 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Move generic setup code out of create()Laszlo Agocs2023-04-121-0/+2
| | | | | Change-Id: I5222dd5479fe5c23b20bd08a2908a85be4d25e45 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Remove readback result type aliasLaszlo Agocs2023-04-121-2/+2
| | | | | | Change-Id: I1b14d3230ab4011506892c64ea03d5431d82a90d Reviewed-by: Christian Strømme <christian.stromme@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* rhi: Remove QRhiSrb data gettersLaszlo Agocs2023-02-201-0/+15
| | | | | | | | | | | | | | | | 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-2/+1
| | | | | | | | 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-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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/+9
| | | | | | | | 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>
* QRhi: Allow negative viewport originAntti Määttä2022-10-201-16/+25
| | | | | | | | | | | | Do not bound viewport rect to surface size, only scirror rect. Modifying the viewport will move the view origin changing the way the scene gets rendered. Pick-to: 6.4 Task-number: QTBUG-106082 Change-Id: I105516bd460af87727d0e73f580b8cf6b748d87f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Port from qAsConst() to std::as_const()Marc Mutz2022-10-111-1/+1
| | | | | | | | | | | | | | | | We've been requiring C++17 since Qt 6.0, and our qAsConst use finally starts to bother us (QTBUG-99313), so time to port away from it now. Since qAsConst has exactly the same semantics as std::as_const (down to rvalue treatment, constexpr'ness and noexcept'ness), there's really nothing more to it than a global search-and-replace, with manual unstaging of the actual definition and documentation in dist/, src/corelib/doc/ and src/corelib/global/. Task-number: QTBUG-99313 Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* rhi: metal: Add support for tessellationLaszlo Agocs2022-09-011-0/+3
| | | | | Change-Id: Ie8d226a6a959aa5e78284ea72505fd26aec1e671 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Clean up some inconsistenciesLaszlo Agocs2022-07-121-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Keep track of pipeline creation timesLaszlo Agocs2022-07-051-1/+19
| | | | | | | | | | | | | | | | | | | | | Make our QRhiMemAllocStats struct a bit more generic, drop the memory allocation part in the naming, and use the same getter and struct for reporting some important timings. (we are free to rename for now, there are no users in other modules yet) The time spent in graphics (or compute) pipeline creation has a special relevance in particular with the modern APIs (as it is the single biggest potentially time consuming blocking operation), but also highly interesting with others like D3D11 simply because that's where we do the expensive source-to-intermediate compilation is HLSL source is provided. In order to see the effects of the various caching mechanisms (of which there can be confusingly many, on multiple levels), the ability to see how much time we spent on pipeline creation e.g. until we render the first view of an application can be pretty essential. Task-number: QTBUG-103802 Change-Id: I85dd056a39db7e6b25fb1f9d02e4c94298d22b41 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Gui: Do not depend on transitive includesFabian Kosmale2022-03-171-0/+2
| | | | | Change-Id: I27321235d9c8428de0cff1e22a618299b9e5a97f Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* rhi: Add the basic infrastructure for geometry shader supportBen Fletcher2022-01-311-2/+4
| | | | | | | | | | | | | | | | | | | | | .. 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 the basic infrastructure for tessellation supportLaszlo Agocs2022-01-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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: Drop the profiler for nowLaszlo Agocs2022-01-041-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Auto-rebuild rt by tracking attachment id and generationLaszlo Agocs2021-12-101-0/+77
| | | | | | | | | | | | | | | | | | | | | | | 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: Add texture array supportLaszlo Agocs2021-10-291-0/+1
| | | | | | | | | | | | | | 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-3/+0
| | | | | | | | | | | | | 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: Add support for 3D texturesLaszlo Agocs2021-05-311-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add support for custom bytes-per-line for uncompressed raw dataLaszlo Agocs2021-03-301-1/+1
| | | | | | | 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>
* rhi: Pipeline cache load/saveLaszlo Agocs2021-01-221-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add QRhi APIs to retrieve and reload the contents of the "pipeline cache". The only API where there is a true pipeline cache is object is Vulkan (VkPipelineCache). For OpenGL, the other backend where we support this, it is simulated with program binaries. The Qt 5 style OpenGL program binary disk cache continues to work like before, but one has now the option to do things in a more modern, graphics API agnostic way, that leads to generating a single blob instead of a large set of files in some system location, allowing easier "pre-baking" of the cache content. It is expected that Qt Quick exposes the two new functions in form if QSG_RHI_ environment variables, thus allowing easy testing and cache file generation. As an example for the performance improvements this can give, consider Vulkan, where we do not have any existing persistent caching mechanism in place: Running BenchmarkDemoQt6.exe --scene flythrough --mode demo creates 18 QRhiGraphicsPipeline objects from Qt Quick and Qt Quick 3D. The total time spent in QRhiGraphicsPipeline::create() during application startup for these 18 pipelines is 35-40 ms on a given Windows (NVIDIA) system. When exporting the pipeline cache contents to a file, and then, in a subsequent run, reloading the cache contents, this is reduced to 5-7 ms on the same system, meaning we get a 6-7x improvement. The generated data is always specific to a given Qt version, RHI backend, graphics device, and driver version. Much of the implementation consists of adding and verifying the appropriate header to the blobs retrieved from the driver, to allow gracefully ignoring data that was generated with a device or driver that differs from the one used at run time. This should provide robustness, even if the Vulkan or OpenGL implementation is for some reason not prepared to identity and reject incompatible cache/program blobs. Fixes: QTBUG-90398 Change-Id: I67b197f393562434f372c7b7377f638abab85cb3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* RHI: Use QT_BEGIN_LICENSE:LGPL headerKai Köhne2021-01-151-11/+14
| | | | | | | Task-number: QTBUG-90321 Pick-to: 6.0 Change-Id: If3b0841f3e9139bb1911c6a5d03a16daf8c1b3d6 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Expose device name, type, and IDsLaszlo Agocs2021-01-131-0/+1
| | | | | | | | | | | | | | | | ...to the extent it is sensible. We have to make compromises still, meaning some fields will only be applicable with certain APIs. Most of this is already shown upon QRhi::create() as info debug prints, when enabled. Now expose it all through the QRhi API as well. This is useful for printing in qtdiag, and, while it should be avoided as much as possible, to make decisions about disabling 3D rendering features depending on the driver and GPU in use. Change-Id: Iebe1e192965c928b82a094d1c7c50ddf4b38b9a2 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Replace discouraged Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPEAndreas Buhr2020-11-301-5/+5
| | | | | | | | | | | | | | Q_MOVABLE_TYPE was conceived before C++ had move semantics. Now, with move semantics, its name is misleading. Q_RELOCATABLE_TYPE was introduced as a synonym to Q_MOVABLE_TYPE. Usage of Q_MOVABLE_TYPE is discouraged now. This patch replaces all usages of Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPE in QtBase. As the two are synonymous, this patch should have no impact on users. Pick-to: 6.0 Change-Id: Ie653984363198c1aeb1f70f8e0fa189aae38eb5c Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* QRhiBackendCommandList: avoid new[]/delete mismatchFabian Kosmale2020-10-191-1/+1
| | | | | | Change-Id: Iac2645ebd1d42753817078f194ba61520f5f70c9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Further reduce copying in the command bufferLaszlo Agocs2020-10-161-0/+32
| | | | | Change-Id: I2e2ff5f4b8aa91d0accb01108a5199b98c371455 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: d3d: Save a few cycles in bindShaderResourcesLaszlo Agocs2020-10-111-1/+2
| | | | | Change-Id: Ib11ea33eb695d4599f4f040415d497aaf19cb15b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for full, direct buffer updatesLaszlo Agocs2020-10-111-1/+0
| | | | | Change-Id: I02c1f8c32c08d39cde9845d20ba8b02541d9d325 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Make per-frame flags per-pass where appropriateLaszlo Agocs2020-10-021-2/+5
| | | | | | | | | | | | | | | | | | | | ExternalContentsInPass becomes a per-pass flag now. Why is this beneficial? Because while Qt Quick has no choice for its render pass, not being able to guess if the application wants to do some native rendering in there, Quick 3D's render passes, all the ones that are under Quick3D's control, do not have native rendering from the application in them, and so using secondary command buffers with Vulkan is not necessary. Introduce something similar for compute and OpenGL. By knowing that none of the resources used in a pass are used with a compute pass (e.g. because we know that there are no compute passes at all) a small amount of time can be saved by skipping tracking buffers and textures because the only purpose of said tracking is to generate barriers that are relevant only to compute. Change-Id: I0eceb4774d87803c73a39db527f5707a9f4d75c1 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Manage buffer data without QBALaszlo Agocs2020-09-301-36/+79
| | | | | | | | Use a simple and straightforward container that only does what we need here. Change-Id: I1a81b53a58bc91d533e3d7df5471a1362046825d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Drop QBitArray usageLaszlo Agocs2020-09-291-1/+1
| | | | | Change-Id: I4ae92e6c8c91111a4593c51ee05443b3bc806c35 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Improve layout compatibility test performanceLaszlo Agocs2020-09-291-0/+1
| | | | | | | | | Also bump the non-heap buffer size in the binding list to 16, in order to accommodate complex Quick3D materials with many associated texture maps. Change-Id: Id190e5f8304f5941cffc41a2605fce45dfeb72f0 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: vulkan: Fix mipmap generation for cubemapsLaszlo Agocs2020-09-251-3/+1
| | | | | Change-Id: Ia1aab06214be802aaabc97ffefa28947e11148e3 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Reuse the data in buffer ops in res.update batchesLaszlo Agocs2020-09-231-4/+39
| | | | | | | | Because having profilers bombarded with mallocs (due to creating deep copy QByteArrays) is not nice. Change-Id: I848f41f3465d6dc2a58a193cc863495aacf13d79 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Reuse buffer/texture op entries in res.update batchesLaszlo Agocs2020-09-231-0/+20
| | | | | | | | More of an enabler for reusing the data in the individual entries since not clearing the QVLA does not give us much on its own. Change-Id: Ief9761f75382c3373cc2bc7b866eb59fdd8b3277 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Report an "optimal capacity" from res.update batchesLaszlo Agocs2020-09-231-2/+5
| | | | | Change-Id: If47eddf3fe7d365c80b0a15712ef155a6898d904 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Do not just pick the first free res.upd. batch all the timeLaszlo Agocs2020-09-231-0/+1
| | | | | | | | | Rather, utilize all the available ones in the pool, picking the next available batch after the one we picked previously (with wrapping over as necessary). Change-Id: I5f26e127a406c2dd07d155712429c72ad4f0f0f1 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Sanity check the srb in debug buildsLaszlo Agocs2020-09-031-0/+1
| | | | | | | | | | | Instead of cryptic assertions and crashes depending on the backend, show some useful warnings (in debug builds only) when one tries to create an srb with a list where there are duplicated bindings. (a mistake that happens relatively often during the development of frameworks, such as Quick 3D, on top) Change-Id: If1b50a2e8165b001878ad566e048f146e636514f Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Switch to qvla where it makes sense in rhiLaszlo Agocs2020-06-301-1/+1
| | | | | | | | | For all of these we know in advance that the vast majority of usages will not exceed a certain number of elements. Also, none of these are copied or moved ever. Change-Id: I48aedf143e221dc178d661e23454d1e4fb7a271b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Use QList instead of QVector in guiJarek Kobus2020-06-291-3/+3
| | | | | | | | Applied to headers only. Source file to be changed separately. Task-number: QTBUG-84469 Change-Id: Ic08a899321eaffc46b8461aaee3dbaa4d2c727a9 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Harmonize create-destroy API pattern with the rest of QtLaszlo Agocs2020-05-281-3/+3
| | | | | | | | | | For historical reasons we use build and release instead of create and destroy. This becomes confusing now that more modules in Qt start taking QRhi into use. Migrate to the more familiar naming, so those who have used QWindow or QOpenGLContext before will find it natural. Change-Id: I05eb2243ce274c59b03a5f8bcbb2792a4f37120f Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Initialize TextureOp and BufferOp structsVolker Hilsheimer2020-05-151-7/+7
| | | | | | | | | | | | | | | Fixes Coverity warnings, and avoids hard-to-debug errors, at minimal overhead. Change-Id: I3ff530a9263693d1123932458b3e186e79a14b7e Coverity-Id: 263692 Coverity-Id: 263693 Coverity-Id: 263699 Coverity-Id: 263700 Coverity-Id: 263702 Coverity-Id: 263705 Pick-to: 5.15 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Correct another scissor/viewport clamping problemLaszlo Agocs2020-05-071-2/+2
| | | | | | | | | | | | | | | | | | | | | When x or y are >= the width or height of the render target, then the width or height of the scissor/viewport rect is zero, no further logic is needed. This is different from the case of x or y being negative, because then there is still a chance that there is an in-bounds area (if width or height are large enough). It is important to make this check based on the original value of x and y, not the clamped ones. Otherwise we end up with a 1 pixel wide region even when the expected result is a width or height of 0. Previously the incorrect subtraction of 1 in the final clamping of w and h masked this, but once that is fixed, the issue fixed here becomes visible in the cubemap_scissor manual test. Change-Id: I3d4b0a163a16aa1116b1e838fa95c0faf7b56a3d Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* RHI: fix off-by-one clippingEirik Aavitsland2020-05-071-2/+2
| | | | | | | | | | | In cases where qrhi_toTopLeftRenderTargetRect() would clip the width or height to the available space, it would subtract 1 from the result, leading to painting errors. Fixes: QTBUG-83928 Change-Id: I65d23151d838386b516ded0588702bc0bf4c0d93 Reviewed-by: Jonas Karlsson <jonas.karlsson@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add backing format hint to QRhiRenderBufferLaszlo Agocs2020-04-291-1/+2
| | | | | | Task-number: QTBUG-83707 Change-Id: I63548f4ace70af614a2aa082663bb3ae9fbedc25 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* rhi: Enable sampler address mode W in the APILaszlo Agocs2020-01-301-2/+5
| | | | | | | | | | | Internally this is already supported by all backends. The frontend was just not exposing addressW, instead defaulting to the (arbitrarily chosen) ClampToEdge. Add the parameter to newSampler(), but make it optional, defaulting to the more natural Repeat (because that's what one would get with OpenGL for WRAP_R by default) Change-Id: I0b991d8b649db37d4da86ac8e98ab7845601cf67 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-18 13:08:44 +0000