summaryrefslogtreecommitdiffstats
path: root/src/gui/rhi/qrhimetal.mm
Commit message (Collapse)AuthorAgeFilesLines
* rhi: metal: Ignore baseInstance if not supportedLaszlo Agocs2021-11-261-3/+9
| | | | | | | | | | | | | | | | | | | | | | A previous patch already introduced calling the correct variant of drawIndexedPrimitives, but it was not done for drawPrimitives. When base vertex and instance is not supported (e.g. on the iOS simulator), it does not mean that the value cannot be other than 0, but rather that the version of the function taking this arguments must not be called at all, otherwise a Metal failure occurs. The docs and logic is all in place, just add it to draw() as well. Amends 213755a86622ae8b3ed3d7ad34a6aecd051b2b03 which fixed this for indexed draw calls. Now we also prevent aborting Qt Quick applications that trigger non-indexed draw calls. Change-Id: Icb4313ffd2d3a77a73f7b5f49d7ce63c935254d3 Pick-to: 6.2 Task-number: QTBUG-95795 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Expose the maximum uniform buffer range limitLaszlo Agocs2021-11-101-0/+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-9/+42
| | | | | | | | | | | | | | 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: metal: Query supported sample counts from the deviceLaszlo Agocs2021-10-081-1/+7
| | | | | | | | | | Check if 2, 4, 8 are actually supported. Pick-to: 6.2 Fixes: QTBUG-97146 Change-Id: I23c22c2bfeb072b9658f3b5dfba51dd6dc850de3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Allow testing renderpass compatibility without the objectsLaszlo Agocs2021-09-161-0/+21
| | | | | | | | | | | | | | | | | | | 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: Reset resource state tracking tables upon layout-compatible updatesLaszlo Agocs2021-09-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...just like create() would do when requesting a full rebuild. Not relevant for the OpenGL backend, while D3D and Metal may get away without doing this, but the Vulkan backend gives visible rendering errors in Qt Quick once updateResources() is taken into use and a scene manages to do the "right" amount and types of changes. The most common source is a changing uniform buffer offset. Consider how the Qt Quick scenegraph merges uniform data into a single buffer in unmerged batches (i.e. when a set of geometry nodes cannot be batched together in a single draw all). While each node gets its own draw call, each associated srb refers to the same uniform buffer at binding point 0, just with a different offset. Without the layout-compatible-update optimization (that is QRhiShaderResourceBindings::updateResources()) this is not something that needs extra care: once an srb is built or rebuilt (by calling create()), the offset, just like the resource itself is fixed and cannot change. And once create() is called, it conveniently invalidates all related data structures, leading to the subsequent setShaderResources() rewrite descriptors (incl. the resource, the offset, etc.) with Vulkan or do whatever is relevant with other backends. updateResources() only does the minimum amount of changes because we know that the binding list layout has not changed. It turns out this was a bit too minimal, because certain state tracking data structures still need resetting, just as if we called create(). The problem is becoming apparent with non-layout data such as the uniform buffer offset, storage buffer offset, or the storage image mip level. It however works as expected when changing the resource itself. E.g. if a binding point now references a QRhiBuffer different than before, then there is no visible problems, regardless of the buffer offset being different or the same. Hence being difficult to discover, until the aforementioned Qt Quick renderer case triggers it. Why is this? Changing the resource (buffer, texture, sampler) itself works due to the guarantees given by the QRhi resource model. Consider the following: ubuf is a uniform buffer ubuf->create(); srb->setBindings({ references ubuf }); srb->create(); // use the srb in some draw calls // ... // later, when preparing the next frame we decide we need new data with // a different size even: ubuf->setSize(new_size) ubuf->create(); // fill in new data to ubuf // use the srb in some draw calls at this point "magic" happens: note how there is no rebuilding of the srb itself (no create(), no nothing), yet it will correctly pick up the now-different native buffer objects underneath ubuf. This works because there is a certain degree of state tracking happening that allows recognizing that a resource referenced from an srb got rebuilt and now has different native objects (e.g. a VkBuffer) underneath, which in turn needs (with Vulkan) rewriting the associated descriptor with the new native resource. Incidentally, this also makes updateResources() work just fine as long as it replaces the QRhiBuffer/Texture/Sampler reference for the binding point. However, with the example snippet above there is no way to change the other associated data such as the buffer offset. (that would need rebuilding the srb with create(), and that resets all related state tracking structures) So once we encounter an updateResources() where the same QRhiBuffer is now used with an offset different from before, that is not recognized by setShaderResources() and (with Vulkan) it will not rewrite the descriptor with the new offset. (unless the changes for another resource in the binding list trigger it; the granularity here is quite coarse, i.e. we either rewrite (with Vulkan) all descriptors or none at all; this makes the problem even less apparent because now rendering errors occur only when Qt Quick ends with an update where only the uniform buffer offset, but nothing else changed) Pick-to: 6.2 Change-Id: I82ee43aa358947288135ff72ec213e091342e9cb 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/+15
| | | | | | | | | | | | | | | | | 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: metal: Make base vertex and instance support optionalLaszlo Agocs2021-08-181-10/+24
| | | | | | | | | | | | | | | | | | | | | | | Like we do for OpenGL. Conveniently enough the QRhi feature flags are readily available. This should prevent errors such as: MTLValidateFeatureSupport:3901: failed assertion `Base Vertex Instance Drawing is not supported on this device' on the iOS Simulator. It is not clear since which version or SDK this became a fatal problem, but the base vertex/instance support is indeed an optional feature according to the Metal Feature set tables, so not calling the drawIndexedPrimitives variant taking baseVertex and baseInstance when the reported iOS GPU family is too low is the right thing to do regardless. Pick-to: 6.2 6.1 Fixes: QTBUG-95795 Change-Id: I47c54a77a66a0410b86b8d4e5a1863dc730490f4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Be more graceful when one destroys a resource after the QRhiLaszlo Agocs2021-08-021-26/+34
| | | | | | | | | | | | | | | | | | | | | One is a bad application or library in this case, but nonetheless we should handle this more gracefully then just crashing due to the QRhi already having been destroyed. Mainly because in Qt 5 one could get away with the same: releasing OpenGL objects underneath, for example, a QSGPlainTexture with no (or wrong) GL context did not generate any user visible fatal errors. So we should not crash in Qt 6 either with these code bases. In debug builds or when QT_RHI_LEAK_CHECK is set, one will get the unreleased resources warning printed in Qt 6, which is a step forward compared to Qt 5. So there is still some indication that something is badly designed, even if the application survives. Task-number: QTBUG-95394 Pick-to: 6.2 Change-Id: I944f4f425ff126e7363a82aff926b280ccf1dfc3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Enable reading back slices of 3D texturesLaszlo Agocs2021-06-031-6/+4
| | | | | | Change-Id: I0c687677b7e86b7284130c775718b29aca2cca40 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Add support for 3D texturesLaszlo Agocs2021-05-311-26/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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/+2
| | | | | | | Those are needed to handle 16bit YUV formats in Qt Multimedia. Change-Id: I39c67bf4fcf558487b7819ea38e578f99c12a3ed Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add support for custom bytes-per-line for uncompressed raw dataLaszlo Agocs2021-03-301-2/+8
| | | | | | | 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: Make it possible to clone a QRhiRenderPassDescriptorLaszlo Agocs2021-03-191-0/+10
| | | | | | | | 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: metal: Remove most availability guardsLaszlo Agocs2021-03-161-81/+23
| | | | | | | | | Once the deployment target is bumped to 13.0, most guards can be removed. Pick-to: 6.1 Change-Id: I7566a4f2915ada9defa1a4bcee10f75021222b30 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* rhi: metal: Stop using BufferOp for no good reasonLaszlo Agocs2021-03-111-6/+8
| | | | | | | | | | | Do what the Vulkan backend does, and just take the offset and the QRhiBufferData. There is no reason to store a full QRhiResourceUpdateBatchPrivate::BufferOp struct within the backend. Change-Id: I67528029de40320b3e4f031346d40dfc0bb9ab52 Pick-to: 6.1 6.0 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: metal: Skip unnecessary writes when updating the entire bufferLaszlo Agocs2021-03-111-1/+4
| | | | | | | | | | | Follow the similar Vulkan change in 20eb40bce92c3e5460cd2540547f3c404fe6dccc and drop the queued up buffer data for a given slot when the current update covers the entire buffer. This is relevant in particular for Qt Quick 3D where such dynamic buffer changes are common. Change-Id: If1e70d78968586b552a5357bc97af10cc61d9611 Pick-to: 6.1 6.0 Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: metal: Avoid unused argument warning on iOSLaszlo Agocs2021-03-101-0/+3
| | | | | | Change-Id: I4cb729f3d8dbe7703b89153b742ce2874f35cfd2 Pick-to: 6.1 6.0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* rhi: metal: Use the layer as the single source of truthLaszlo Agocs2021-03-101-8/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...when it comes to the output size. This mirrors what all other backends do. For example, with Vulkan the only source of size is the surface (VkSurfaceKHR), never the QWindow, even though we'd expect that the surface size equals to window_size * dpr, and that's almost always true, but there are exceptions. (e.g. we have seen bugs on Windows with some drivers in high DPI situations where the Vulkan surface did not fully match the window size, yet it is the surface, and only the surface, that matters for rendering, i.e. viewports and such must match the surface, not the native window) With Metal we hit a similar problem on iOS: the QWindow's size*dpr and what we calculate from the CAMetalLayer have a height difference of 1. Mitigate this by making QRhiSwapChain::surfacePixelSize() and the calculation for currentPixelSize() done via the same route (the CAMetalLayer). Otherwise, if there is a mismatch between what the QWindow and the layer says, Qt Quick will think that there is a resize happening (has happened) whenever starting a new frame, and that has far reaching consequences (suboptimal performance, increased memory usage by buffers, etc.) Change-Id: I114df92bf35622c99f2747420fdce401db7705a6 Pick-to: 6.1 6.0 Fixes: QTBUG-91438 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* rhi: metal: Present drawables via addScheduledHandler instead of presentDrawableTor Arne Vestbø2021-02-051-3/+7
| | | | | | | | | | | | | | The former API is the recommended way to present drawables -- avoiding WindowServer submission throttling and potential issues with lock-ups when window are not serviced, are being moved to other screens, or users mistakenly call waitUntilCompleted. The scheduled block captures the drawable and retains it until the block is done executing. Change-Id: I99dca2db3bcfbea67c686dd5d97ba5011598997e Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: metal: Manually manage drawable lifetimeTor Arne Vestbø2021-02-051-3/+8
| | | | | | | | | | | | | | | | | | | The drawable returned from nextDrawable is autoreleased, which means unless we explicitly retain it we have no guarantee that it will stay alive long enough to be used again in endFrame(). For example, if the user had an autorelease-pool in their custom render code, where the call to beginPass() happens, the drawable would be released when that pool went out of scope. The only reason we didn't hit this yet is due to the default autorelease-pool being at the level of the runloop, so the drawable happened to outlive the rendering of a single frame. An advantage of manually managing the lifetime of the drawable is also that we can release it immediately after being done with it, instead of waiting until the autorelease-pool drains. Change-Id: Ie6fd271adbe1121eb947bb7075142f1a6c81175d Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Pipeline cache load/saveLaszlo Agocs2021-01-221-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+29
| | | | | | | | | | | | | | | | ...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-2/+2
| | | | | | | | | | | | | | 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: Add missing \internal doc commandsTor Arne Vestbø2020-10-121-0/+3
| | | | | | Pick-to: 5.15 Change-Id: I09a69a04c6fcd406602e797cbeec59216fecd5d8 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Make the new direct buffer update available for non-uniform buffersLaszlo Agocs2020-10-121-4/+4
| | | | | | | | | | | | | | | | | 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: Add support for full, direct buffer updatesLaszlo Agocs2020-10-111-0/+26
| | | | | 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-5/+5
| | | | | | | | 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: Improve layout compatibility test performanceLaszlo Agocs2020-09-291-0/+2
| | | | | | | | | 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: Reuse the data in buffer ops in res.update batchesLaszlo Agocs2020-09-231-5/+5
| | | | | | | | 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-2/+4
| | | | | | | | 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>
* Support signed integer attributes on QRHIInho Lee2020-09-211-1/+9
| | | | | | | Previous UIntAttributes feature is renamed as IntAttributes. Change-Id: I4b4a87a0eebf37291da832605f7bee8fb2d4e62b Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Expose compute threadgroup limits in ResourceLimitsLaszlo Agocs2020-09-181-0/+14
| | | | | | | | | | As OpenGL ES and Vulkan ruin the day with the spec mandated minimum value for max threads per threadgroup being only 128, clients need a way to decide if their compute shader (local_size_*) is suitable for use at run time. Change-Id: I72b4fc97032406340623add82ea4d9544ebe9fdc Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: Sanity check the srb in debug buildsLaszlo Agocs2020-09-031-0/+4
| | | | | | | | | | | 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>
* Change QByteArray to handle large arraysLars Knoll2020-08-271-2/+2
| | | | | | | | | | Use qsizetype throughout. Change-Id: I787af7fcfa17e1be87decb64c41c609cc24be117 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* rhi: Allow null resources in srbLaszlo Agocs2020-07-131-48/+2
| | | | | | | | | | In this case the srb represents the layout only, and can still be used to create a pipeline. For setShaderResources() one will then need to use another, layout compatible, srb that references valid resources. Change-Id: I3ea5b63df3be8847540ca4c0c40fbd29dbed8fb7 Reviewed-by: Paul Lemire <paul.lemire@kdab.com> Reviewed-by: Andy Nichols <andy.nichols@qt.io>
* rhi: add support for D24 / D24S8 formatsJean-Michaël Celerier2020-07-021-4/+13
| | | | | Change-Id: I7ba14d30fa57bcb92cd764aed6c85cde853935b4 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* Switch to qvla where it makes sense in rhiLaszlo Agocs2020-06-301-2/+2
| | | | | | | | | 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>
* rhi: Enable specifying just an adapter or phys devLaszlo Agocs2020-06-261-8/+4
| | | | | | | | | 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: Add a feature flag for readback format supportLaszlo Agocs2020-06-151-0/+2
| | | | | | | | | Indicate that doing a QRhiResourceUpdateBatch::readBackTexture() for texture formats other than RGBA/BGRA is not necessarily supported at run time. Change-Id: Ie9ca9546a3af9bff142b875f1ecf26bf26bcc442 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* Add RHI feature check for screen space derivativesEskil Abrahamsen Blomfeldt2020-06-121-0/+2
| | | | | | | | | | | | | | Fragment shader functions like fwidth() are useful for antialiasing distance field text in the case of perspective projections. In order to enable this as an alternative code path, we need to detect support. - OpenGL: Supported with GL_OES_standard_derivatives or GLES3 and up - Direct 3D: Supported for ps_2_x, so always supported on Direct3D 11 - Vulkan/Metal: Always supported Task-number: QTBUG-84695 Change-Id: I5e3fa8014c808a9a2d639305c5e90ec25d44655c Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Harmonize create-destroy API pattern with the rest of QtLaszlo Agocs2020-05-281-56/+56
| | | | | | | | | | 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>
* QRhiVertexInputAttribute : Add unsigned int formats for vertex inputInho Lee2020-05-271-0/+10
| | | | | | Task-number: QTBUG-83173 Change-Id: I640cd1fe74227d2cc96672d6c7aaac93e1930bcd Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* RHI: Introduce QRhiTexture::RG8VaL Doroshchuk2020-05-251-0/+6
| | | | | | Change-Id: I58f35b2629bd6464f08cba66e852215472fcbe2a Fixes: QTBUG-84384 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* RHI: Store texture handle as 64-bit intEskil Abrahamsen Blomfeldt2020-05-221-4/+4
| | | | | | | | | | | | | | | | | | When storing a void* pointer to the texture handle, we had to ensure that the variable would exist until the build phase, which is error prone and caused errors in QQuickWidget because we copied the texture ID from the FBO into a local variable before passing it into QQuickWindow::setRenderTarget(). The reason for using a void* was that we cannot know the width of the handles in the different backends, but we do know that they are 64-bit at maximum, so instead of storing potentially dangling pointers, we just make it a 64-bit integer and cast it back and forth in the backends. Task-number: QTBUG-78638 Change-Id: I7951e24351ddb209045ab6197d81eb1290b4da67 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* rhi: Add backing format hint to QRhiRenderBufferLaszlo Agocs2020-04-291-138/+146
| | | | | | Task-number: QTBUG-83707 Change-Id: I63548f4ace70af614a2aa082663bb3ae9fbedc25 Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
* rhi: Take mip size into account for render target sizeLaszlo Agocs2020-04-231-1/+4
| | | | | | | | Also extend autotesting, both for rendering into a given mip level and for rendering into a given cubemap face. Change-Id: Ida94b71150477ceb50a3b5616d8b7be13174558b Reviewed-by: Andy Nichols <andy.nichols@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 23:34:57 +0000