summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi/qrhivulkan_p_p.h
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* rhi: gl, metal, d3d: Reuse shader objects when source is the sameLaszlo Agocs2019-09-091-0/+1
| | | | | | | | | | | | | | | | | | Now that Qt Quick's batch renderer misses one level of shader source caching due to the nature of pipeline state objects, it can be useful to keep and reuse shader objects when the hash of the source code matches. The goal here is to allow Qt Quick to be on par with what the direct OpenGL path has when it comes to caching shader sources and compilation results. The program binary disk cache is not in scope in this patch. Also adds QRhi::releaseCachedResources(), similarly to what the scenegraph has. This can be called to clear caches such as the shader object cache we keep here. Change-Id: Ie3d81d823f61fa65ec814439e882c498f7774d43 Reviewed-by: Christian Strømme <christian.stromme@qt.io>
* rhi: vulkan: Introduce secondary command buffer usageLaszlo Agocs2019-08-291-17/+33
| | | | | | | | | | | As an option. Must opt in via setting ExternalContentsInPass in the flags for beginFrame(). It is somewhat unfortunate to require declaring this up front, but forcing using secondary command buffers always, even though beginExternal() may not be used in many applications, would be an overkill. Change-Id: I8d52bcab40c96f89f140c4c7877b6c459925e3c7 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Attempt to fix up the logic around beginExternal()Laszlo Agocs2019-08-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Mainly for Vulkan where it lacked the recording of the still queued commands. Uncovered by Qt Quick examples that integrate custom Vulkan rendering. This still has an issue that needs to be tackled separately. (we probably will switch to using a dedicated secondary command buffer with RENDER_PASS_CONTINUE_BIT for the external commands, and then just have a vkCmdExecuteCommands in our own queue instead of recording everything in beginExternal). The possibility of losing glMemoryBarrier() calls due to begin/endExternal() with the OpenGL backend is fixed too. The logic here mirrors Vulkan to some extent except that we do not have a concept of (and so the trouble with) renderpass instances. Clean up around the implementations of finish() as well. Attempting to share code via a "flushCommandBuffer" function is admirable but is not worth it since some semantics are different. (finish() cannot be called within a begin/endPass, unlike begin/endExternal). Change-Id: I5137db598d6a40d484e53678f5c919abf750d9ed Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: vulkan: Expose the VkRenderPass via the usual mechanismsLaszlo Agocs2019-08-291-0/+2
| | | | | | | | | Qt Quick in turn will expose it via QSGRendererInterface. Essential when adding custom Vulkan rendering into a Qt Quick application because the custom pipeline state objects will need to reference a VkRenderPass. Change-Id: Idf4092cfc3937830fb8123164081059b0d8d030e Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Enhance line width and point size supportLaszlo Agocs2019-07-011-0/+2
| | | | | | | | | | | | | | | | | | | | | ...but this will vary between backends, or in some cases even between implementations of the same API. Point size is settable only via the vertex shader (gl_PointSize). It is silently ignored with D3D and HLSL. Line widths other than 1 are supported only on OpenGL and Vulkan. (but this is in fact deprecated with GL and optional with Vulkan) Add QRhi::Feature values for both. The line width is now settable on QRhiGraphicsPipeline. It is not a dynamic state since the static, per-pipeline width is good enough for most cases. (and the feature is not supported on half of the backends anyways so it will get limited use in practice). Change-Id: I6d3a32269527c452b794b2cb8b0f03101eab40b2 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* rhi: Add compute api and implement for Vulkan and MetalLaszlo Agocs2019-06-171-8/+63
| | | | | | | | | | | | | D3D11 and GL (4.3+, ES 3.1+) will come separately at a later time. Change-Id: If30f2f3d062fa27e57e9912674669225b82a7b93 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* rhi: Make it possible to request making the context current on GLLaszlo Agocs2019-06-171-0/+1
| | | | | | | | | | | | | | | | | Needed by Qt Quick to handle cases where the application (or other Qt) code contains OpenGL calls, and Qt Quick facilitates this by ensuring the scenegraph's GL context is current. The expectation is that when running with the GL backend of the rhi, all such code remains fully functional. So add a makeCurrent type of call into the QRhi API that is a no-op with anything other than OpenGL. Change-Id: I6f774bf828e31802bdab0c3fef9421cdc0cebe5c Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Introduce the Qt graphics abstraction as private QtGui helpersLaszlo Agocs2019-06-131-0/+859
Comes with backends for Vulkan, Metal, Direct3D 11.1, and OpenGL (ES). All APIs are private for now. Shader conditioning (i.e. generating a QRhiShader in memory or on disk from some shader source code) is done via the tools and APIs provided by qt-labs/qtshadertools. The OpenGL support follows the cross-platform tradition of requiring ES 2.0 only, while optionally using some (ES) 3.x features. It can operate in core profile contexts as well. Task-number: QTBUG-70287 Change-Id: I246f2e36d562e404012c05db2aa72487108aa7cc Reviewed-by: Lars Knoll <lars.knoll@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 13:14:48 +0000