summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi/qrhivulkan_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* rhi: Keep track of pipeline creation timesLaszlo Agocs2022-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* rhi: Add a feature flag for non-fill polygon modesLaszlo Agocs2022-04-221-0/+1
| | | | | | | | 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-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Add the basic infrastructure for geometry shader supportBen Fletcher2022-01-311-0/+1
| | | | | | | | | | | | | | | | | | | | | .. 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/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...backed by support in the backends for D3D11 and Vulkan. Expose only what works in practice: scRGB with RGBA16F and HDR10 with RGB10A2 (or A2BGRA10 etc.). For general use, e.g. to render 2D/3D content, scRGB (i.e. extended sRGB linear) should be chosen because that is a linear space. On Windows with a HDR10 display (and an NVIDIA card) both of these are known to work, as long as Use HDR is enabled in the Settings for the display on which the window is created. When requesting a HDR format and it is not supported, we will fall back to the default SDR RGBA8/BGRA8 format. However, the behavior seems to be a bit weird with Vulkan and NVIDIA at least when there is a HDR display but Use HDR is set to Off: this seems to enable HDR mode for the lifetime of the window (with the usual set of black screens while switching over the entire display). Not sure why the driver does this. With D3D/DXGI, with fewer abstractions in the way, we can check upfront properly, so that will nicely fall back to the defaults regardless of why HDR is not available. Support can also be checked in advance via QRhiSwapChain::isFormatSupported() as long as the QWindow is available. (though with Vulkan, as said above, this also seems to ignore the Use HDR setting of Windows) Complications, such as moving a window from one screen to another, are currently not known how they behave. To be seen how this is handled by the Windows compositor. (from 1903 and up it is said to be able to automatically downconvert scRGB to SDR so perhaps moving from a HDR to a non-HDR screen would work - remains to be seen if this needs something more involved) When it comes to other platforms and potential future support: - based on its docs Android 8+ may support scRGB with Vulkan as-is on a suitable device/display, as long as the application declares android:colorMode="wideColorGamut" in the manifest. - for Metal the layer can be made EDR enabled and then e.g. MTLPixelFormatRGBA16Float/kCGColorSpaceExtendedLinearSRGB should work. However, this won't be added unless we can test it. - Linux is unknown. If one needs access to display specific values such as the min/max luminance when implementing tonemapping or a transfer function, that needs platform/API specific approaches, and sadly the kind of data exposed seems to vary, potentially making it difficult to maintain a single cross-platform logic. With D3D one can get the DXGI_OUTPUT_DESC1 from the IDXGIOutput6. This has the min/max luminances in nits and a bunch of other things. For convenience the output object is now exposed from the swapchain's nativeHandles() whenever the D3D backend is used at run time. For Metal one would presumably access maximumExtendedDynamicRangeColorComponentValue and co. in the NSScreen. Elsewhere one needs to rely on platform/winsys specific approaches, if there are any. Remains to be seen longer term if/how this needs/can be better supported. Change-Id: I2e61a0e062282d4bfdfba39655941c0f9a795112 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Auto-rebuild rt by tracking attachment id and generationLaszlo Agocs2021-12-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | 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: Allow testing renderpass compatibility without the objectsLaszlo Agocs2021-09-161-0/+4
| | | | | | | | | | | | | | | | | | | 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: Add a way to tell an srb that only the resources have changedLaszlo Agocs2021-09-031-0/+1
| | | | | | | | | | | | | | | | | 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: Add support for 3D texturesLaszlo Agocs2021-05-311-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Make it possible to clone a QRhiRenderPassDescriptorLaszlo Agocs2021-03-191-0/+2
| | | | | | | | Pick-to: 6.1 Task-number: QTBUG-91888 Change-Id: Ib6d2e639e6c24f3e9a733c6563dc8a6d6da47719 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Pipeline cache load/saveLaszlo Agocs2021-01-221-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | | | | | | | | | | | ...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>
* rhi: vk: Prevent WAW hazard reported from sync validation with offscreen rtLaszlo Agocs2021-01-061-0/+1
| | | | | | | | | | | | ...when a QVkRenderBuffer is used as depth-stencil (i.e. a "throwaway" depth-stencil buffer that is a lazily allocated / transient VkImage under the hood). Such a resource is not tracked by the QRhiPassResourceTracker, so do an explicit barrier in beginPass instead of having it generated by the tracker. Fixes: QTBUG-89764 Change-Id: Ice794f44342175f712ea56f450270cbb8929f516 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* Replace discouraged Q_MOVABLE_TYPE by Q_RELOCATABLE_TYPEAndreas Buhr2020-11-301-6/+6
| | | | | | | | | | | | | | 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>
* rhi: Further reduce copying in the command bufferLaszlo Agocs2020-10-161-4/+3
| | | | | Change-Id: I2e2ff5f4b8aa91d0accb01108a5199b98c371455 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Make the new direct buffer update available for non-uniform buffersLaszlo Agocs2020-10-121-2/+2
| | | | | | | | | | | | | | | | | The original restriction to UniformBuffer was due to the GL backend where there is no GL buffer object for QRhiBuffers with usage UniformBuffer. However, we can still implement this for cases when there is a true GL buffer object underneath. With other backends it should all work as-is already. This becomes useful when one has buffers with usage Vertex that need full updates every frame. (f.ex. instance data) Unfortunately this involves renaming the function. But while at it, add an autotest case as well. Change-Id: Iff59e4509a8bae06654cc92fe8428bd79eb012fb Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: gl: vk: Pre-calculate the flags for dyn.offsetLaszlo Agocs2020-10-111-0/+2
| | | | | | | ...instead of doing a loop in setShaderResources() just for this. Change-Id: Iac8d4517783967c6b8bca4926cceca918f7dcdec Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for full, direct buffer updatesLaszlo Agocs2020-10-111-0/+2
| | | | | Change-Id: I02c1f8c32c08d39cde9845d20ba8b02541d9d325 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: vk: Alter command buffer strategyLaszlo Agocs2020-10-021-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reports on the Web have it that there's nothing guaranteeing a driver does any actual freeing of resources then doing vkFreeCommandBuffer for a command buffer from a command pool that does not have VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT, thus leading to continuously growing resource usage with our current allocate/free pattern. It could be that this is the source of out of memory problems we are seeing on some Android devices. Instead of just going straight for said command pool flag and doing ResetCommandBuffer for the command buffers individually, take one step further and use per-slot (slot being 0 or 1 if QVK_FRAMES_IN_FLIGHT is 2) command pools. The current pool is reset in each beginFrame/beginOffscreenFrame, moving all allocated command buffers to the initial state (while other command buffers with the other pool are not affected). This may be (while impossible to tell from just guessing based on the spec) our best approach to command buffer allocation since a Vulkan implementation can likely just use some simple per pool allocator, knowing that we never want to free or reset individual command buffers, but we rather only reset the whole pool at once. The option of importing an existing VkCommandPool when creating the QRhi instance is now gone, but there was probably no point in offering that in the first place. When it comes to VK_COMMAND_POOL_RESET_RELEASE_RESOURCES_BIT it will not be set unless releaseCachedResources() (in Qt Quick this is hooked into QQuickWindow::releaseResources()) was called. What this does in practice is unknown, but have an option to set it now and then if the application really wants. While we are at it, rename secondaryCbs to activeSecondaryCbStack to indicate what it really is. (it's a stack as each call to beginExternal() pushes a new one, while each endExternal() pops) Change-Id: I2e5c1fad26d794e1f56c778e38f750998d706d84 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Make per-frame flags per-pass where appropriateLaszlo Agocs2020-10-021-3/+8
| | | | | | | | | | | | | | | | | | | | 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-2/+3
| | | | | | | | 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: vk: Do not copy the entire BufferOp struct for host writesLaszlo Agocs2020-09-291-1/+6
| | | | | | | | Take only the three things we need. Otherwise we waste time on copying data that is not even relevant to buffer updates at all. Change-Id: I5ed6ae647e23c6f1d0f5f1d973bead2e008f06cc Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Switch command lists to QVLALaszlo Agocs2020-09-251-1/+1
| | | | | Change-Id: Ic163533eee973f0ee2f3e2efe25390caa57dd659 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Switch to qvla where it makes sense in rhiLaszlo Agocs2020-06-301-4/+4
| | | | | | | | | 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-7/+7
| | | | | | | | 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: Enable specifying just an adapter or phys devLaszlo Agocs2020-06-261-1/+2
| | | | | | | | | Required by OpenXR. A VkPhysicalDevice or an adapter LUID + feature level pair should be adoptable while leaving the rest (device, queue, etc. setup) to QRhi as normal. Change-Id: Iada0972671b037b4efb03e7831b7c9b8c5f2393d Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Harmonize create-destroy API pattern with the rest of QtLaszlo Agocs2020-05-281-24/+24
| | | | | | | | | | 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>
* rhi: Add backing format hint to QRhiRenderBufferLaszlo Agocs2020-04-291-2/+4
| | | | | | Task-number: QTBUG-83707 Change-Id: I63548f4ace70af614a2aa082663bb3ae9fbedc25 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* RHI: Fix running with Vulkan on WaylandEskil Abrahamsen Blomfeldt2020-03-301-2/+3
| | | | | | | | | | | | | | | | When the Wayland client plugin is in use, the capabilities for the surface may report a minimum image count of 4. The internal "maximum minimum count" of 3, was arbitrary and only used for sizing buffers. To be more friendly to different setups, we remove the restriction and use QVarLengthArrays instead. We also set the initial size of the buffers to 4 so that we can run with Wayland without any resizing, but now the arrays will also grow to be safe for cases where 4 is not sufficient. Change-Id: Iba5434e84417d36b70f2655b152e816f04650ce4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add support for arrays of combined image samplersLaszlo Agocs2020-03-051-4/+7
| | | | | | | | | | | | | | | | Introduces a new QRhiShaderResourceBinding function that takes an array of texture-sampler pairs. The existing function is also available and is equivalent to calling the array-based version with array size 1. It is important to note that for Metal one needs MSL 2.0 for array of textures, so qsb needs --msl 20 instead of --msl 12 for such shaders. Comes with an autotest, and also updates all .qsb files for said test with the latest shadertools. Task-number: QTBUG-82624 Change-Id: Ibc1973aae826836f16d842c41d6c8403fd7ff876 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Add a way to communicate back the native image layout for a QRhiTextureLaszlo Agocs2020-03-031-0/+1
| | | | | | | | | | | | | | | | | | | | | Relevant when doing custom rendering combined with QRhi, and only for APIs like Vulkan, where image layouts are a thing. As shown by demo apps, it is not currently possible to implement a correct application that renders or raytraces into a QRhiTexture's backing VkImage, and then uses that QRhiTexture in a QRhi-based render pass. This is because QRhi has no knowledge of the image layout if it changes due to commands recorded by direct Vulkan calls, and not via QRhi itself. So, except for certain simple cases, one will end up with incorrect image layout transitions in the barriers. (at minimum this will be caught by the validation layer) To remedy this, add a simple function taking the layout as int (we already do the opposite in nativeTexture()). Task-number: QTBUG-82435 Change-Id: Ic9e9c1b820b018f3b236742f99fe99fa6de63d36 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* rhi: vulkan: Sanitize device extension handlingLaszlo Agocs2020-03-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of qputenv("QT_VULKAN_DEVICE_EXTENSIONS", "VK_KHR_get_memory_requirements2;VK_NV_ray_tracing"); one can now do params.deviceExtensions = { "VK_KHR_get_memory_requirements2", "VK_NV_ray_tracing" }; on the QRhiVulkanInitParams passed to QRhi::create(). The environment variable stays important for Qt Quick applications, which provide no configurability for the QRhi construction (yet). On the other hand, applications using QRhi directly can now also use the new approach to specify the list of device extensions to enable. In addition, take QVulkanInfoVector<QVulkanExtension> into use. There is no reason not to rely on the infrastructure provided by QVulkanInstance. This also implies showing an informative warning for unsupported extensions, instead of merely failing the device creation. (applications will likely not be able to recover of course, but at least the reason for failing is made obvious this way) Task-number: QTBUG-82435 Change-Id: Ib47fd1a10c02be5ceef2c973e61e896c34f92fa3 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* rhi: Execute pending host writes on nativeBuffer() queryLaszlo Agocs2020-03-031-1/+1
| | | | | | | | | | | | | Otherwise it is impossible to write an application that pulls out the VkBuffer for a Dynamic QRhiBuffer, and then uses it with custom Vulkan operations that read from the buffer. More precisely, the problem arises only if the buffer in question is not used in combination with any QRhi operations, because in that case there is nothing that would trigger doing the host writes queued up by a resource batch's updateDynamicBuffer(). Task-number: QTBUG-82435 Change-Id: Ieb54422f1493921bc6d4d029be56130cd3a1362a Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Allow querying the native buffer objects behind a QRhiBufferLaszlo Agocs2020-02-211-0/+1
| | | | | | | | | | | | | Modeled after QRhiTexture's NativeTexture query. This becomes valuable in advanced cases of integrating external native rendering code with Qt Quick(3D), because it allows using (typically vertex and index) buffers created by Quick(3D) in the custom renderer as well, without having to duplicate the content by manually creating native buffers with the same vertex and index data. Change-Id: I659193345fa1dfe6221b898043f0b75ba649d296 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Enable sampler address mode W in the APILaszlo Agocs2020-01-301-3/+6
| | | | | | | | | | | 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>
* rhi: gl: vulkan: Generate barriers between dispatches in a compute passLaszlo Agocs2020-01-131-2/+15
| | | | | | | | | | | | | | | | | | | The new float16texture_with_compute manual test demonstrates a case that was not handled correctly before: multiple dispatch() calls in a row storing to and then loading from the same subresource(s). Without the appropriate barriers subtle data corruption issues appear. For Vulkan this also adds better batching for image/buffer barriers when using deferred recording. Also, for OpenGL this fixes the case of updating a buffer or rendering into a texture and then using it for load/store in a compute pass (previously this also lacked an appropriate glMemoryBarrier). Task-number: QTBUG-81217 Change-Id: I7970c445564473f9452662f4b1a20618cb8627a3 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io> Reviewed-by: Johan Helsing <johan.helsing@qt.io>
* RHI: Remove old native texture APIPaul Olav Tvete2020-01-061-3/+0
| | | | | | Task-number: QTBUG-78570 Change-Id: I8c4850828ac03319ac923a26c2e985883956c286 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* RHI: new native texture APIPaul Olav Tvete2019-12-051-0/+2
| | | | | | | | | | | | The new version takes/returns a value that can be unpacked and passed to other functions without knowing which backend is in use. The old API will be removed in a later change when dependent modules have been updated Task-number: QTBUG-78570 Change-Id: I18d928ceef3cb617c0c509ecccb345551a7990af Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Allow testing QRhiRenderPassDescriptors for compatibilityLaszlo Agocs2019-11-271-2/+8
| | | | | | | | | | | | | | | | | | | | For Metal and Vulkan this needs actual work because that's where the concept of renderpass descriptors is relevant. GL and D3D can just return true always. The big benefit of this is that Qt Quick can now compare renderpass descriptors via isCompatible() for its pipeline cache (similarly to how it is already using isLayoutCompatible() for srbs), and so renderpass descriptors for layers (Item.layer, ShaderEffect) will typically be compatible and so can pick up pipelines created by other layers from the cache. Also add autotests for shader resource binding and renderpass descriptor compatibility. Task-number: QTBUG-80318 Change-Id: I0008bc51c4ee13b0113d2c8caf799e1257f18a18 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* rhi: Add support for buffer readbacksLaszlo Agocs2019-10-091-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | This also marks the beginnings of significantly extending autotesting of the resource and rendering functionality in QRhi. Also involves fixing up the buffer operation lists like we did for textures before. This is to ensure updates and reads on the same batch execute in the correct order. So just have two lists: one with buffer, one with texture operations. Also simplify the struct layouts. No need for those inner structs with many duplicate members. This reduces the size even, since using a union was never an option here. Also switch to a VLA, the size is around 253 KB per batch. The Null backend now keeps track of the QRhiBuffer data so it can return valid results in readbacks. Task-number: QTBUG-78984 Task-number: QTBUG-78986 Task-number: QTBUG-78971 Task-number: QTBUG-78883 Change-Id: I9694bd7fec523a4e71cf8a5c77c828123ebbb3bd Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* rhi: Remove QVectors from the data description structs as wellLaszlo Agocs2019-10-031-1/+2
| | | | | | | | | | | | | | | As usual, keep some QVector overloads around to allow Qt Quick to compile. Color attachments and vertex input bindings get an at(index) type of accessor, unlike any other of similar lists. This is because there the index is significant, and sequential iteration is not the only type of operation that is performed. Sometimes a lookup based on an index will be needed as well. Task-number: QTBUG-78883 Change-Id: I3882941f09e94ee2f179e0e9b8161551f0d5dae7 Reviewed-by: Christian Strømme <christian.stromme@qt.io> Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* Remove QVector in the API of QRhiResource subclassesLaszlo Agocs2019-09-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Forcing users to go through a QVector, when in practice they almost always want to source the data from an initializer list, a QVarLengthArray, or a plain C array, is not ideal. Especially since we can reason about the maximum number of elements in the vast majority of use cases for all the affected lists. QRhiResource is also not copyable so we do not need the usual machinery offered by containers. So switch to a QVarLengthArray. Note that a resource is not a container. The only operations we are interested in is to be able to source data either via an initializer list or by iterating on something, and to be able to extract the data, in case a user wishes to set up another resource based on the existing one. In some cases a QVector overload is kept for source compatibility with other modules (Qt Quick). These may be removed in the future. Also do a similar QVector->QVarLengthArray change in the srb-related data in the backends. Change-Id: I6f5b2ebd8e75416ce0cca0817bb529446a4cb664 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: gl: Pick up context lossLaszlo Agocs2019-09-131-1/+1
| | | | | | | | ...and change the return value of makeThreadLocalNativeContextCurrent() to a bool since we expect this to mirror QOpenGLContext::makeCurrent(). Change-Id: I339507152e461fe28fcf7fe777165e6d0072f055 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: vulkan: Report device lostLaszlo Agocs2019-09-121-0/+1
| | | | | | | | | | | | Typically caught in vkQueueSubmit(). The WaitIdles that can be hit upon cleanup must be guarded by !deviceLost because they inexplicably cause an infinite blocking wait when the device was already reported as lost. (with NVIDIA at least) Change-Id: I7142e2461e1aed9ee3068b2b963cdf2c678ca4e0 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: Better handling of device lossLaszlo Agocs2019-09-121-0/+1
| | | | | | | Starting with D3D11. The other backends will follow later. Change-Id: I4f165c9f1743df0fb00bdce1e898917575bf5f6e Reviewed-by: Christian Strømme <christian.stromme@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-22 07:13:10 +0000