\inmodule QtGuiPrivate \inheaderfile rhi/qrhi.h
- Since
- 6.6
Describes the a single color attachment of a render target.
A color attachment is either a QRhiTexture or a QRhiRenderBuffer. The former, i.e. when texture() is set, is used in most cases. QRhiColorAttachment is commonly used in combination with QRhiTextureRenderTargetDescription.
- Note
- texture() and renderBuffer() cannot be both set (be non-null at the same time).
Setting renderBuffer instead is recommended only when multisampling is needed. Relying on QRhi::MultisampleRenderBuffer is a better choice than QRhi::MultisampleTexture in practice since the former is available in more run time configurations (e.g. when running on OpenGL ES 3.0 which has no support for multisample textures, but does support multisample renderbuffers).
When targeting a non-multisample texture, the layer() and level() indicate the targeted layer (face index
When texture() or renderBuffer() is multisample, resolveTexture() can be set optionally. When set, samples are resolved automatically into that (non-multisample) texture at the end of the render pass. When rendering into a multisample renderbuffers, this is the only way to get resolved, non-multisample content out of them. Multisample textures allow sampling in shaders so for them this is just one option.
- Note
- when resolving is enabled, the multisample data may not be written out at all. This means that the multisample texture() must not be used afterwards with shaders for sampling when resolveTexture() is set.
-
This is a RHI API with limited compatibility guarantees, see \l QRhi for details.
- See also
- QRhiTextureRenderTargetDescription
Definition at line 576 of file qrhi.h.
| void QRhiColorAttachment::setMultiViewCount |
( |
int | count | ) |
|
|
inline |
Sets the view count.
Setting a value larger than 1 indicates that the render target with this color attachment is going to be used with multiview rendering. The default value is 0. Values smaller than 2 indicate no multiview rendering.
When count is set to 2 or greater, the color attachment must be associated with a 2D texture array. layer() and multiViewCount() together define the range of texture array elements that are targeted during multiview rendering.
For example, if layer is 0 and multiViewCount is 2, the texture array must have 2 (or more) elements, and the multiview rendering will target elements 0 and 1. The 0 or 1 then, where view 0 corresponds to the texture array element 0, and view 1 to the array element 1.
- Note
- Setting a count larger than 1, using a texture array as texture(), and calling \l{QRhiCommandBuffer::beginPass()}{beginPass()} on a QRhiTextureRenderTarget with this color attachment implies multiview rendering for the entire render pass. multiViewCount() should not be set unless multiview rendering is wanted. Multiview cannot be used with texture types other than 2D texture arrays. (although 3D textures may work, depending on the graphics API and backend; applications are nonetheless advised not to rely on that and only use 2D texture arrays as the render targets of multiview rendering)
See \l{https://registry.khronos.org/OpenGL/extensions/OVR/OVR_multiview.txt}{GL_OVR_multiview} for more details regarding multiview rendering. Do note that Qt requires \l{https://registry.khronos.org/OpenGL/extensions/OVR/OVR_multiview2.txt}{GL_OVR_multiview2} as well, when running on OpenGL (ES).
Multiview rendering is available only when the \l{QRhi::MultiView}{MultiView} feature is reported as supported from \l{QRhi::isFeatureSupported()}{isFeatureSupported()}.
- Note
- For portability, be aware of limitations that exist for multiview rendering with some of the graphics APIs. It is recommended that multiview render passes do not rely on any of the features that \l{https://registry.khronos.org/OpenGL/extensions/OVR/OVR_multiview.txt}{GL_OVR_multiview} declares as unsupported. The one exception is shader stage outputs other than
-
Multiview rendering is not supported in combination with tessellation or geometry shaders, even though some implementations of some graphics APIs may allow this.
- Since
- 6.7
Definition at line 605 of file qrhi.h.
Sets the resolve texture tex.
tex is expected to be a 2D texture or a 2D texture array. In either case, resolving targets a single mip level of a single layer (array element) of tex. The mip level and array layer are specified by resolveLevel() and resolveLayer().
An exception is \l{setMultiViewCount()}{multiview}: when the color attachment is associated with a texture array and multiview is enabled, the resolve texture must also be a texture array with sufficient elements for all views. In this case all elements that correspond to views are resolved automatically; the behavior is similar to the following pseudo-code: \badcode for (i = 0; i < multiViewCount(); ++i) resolve texture's layer() + i into resolveTexture's resolveLayer() + i
Setting a non-multisample texture to resolve a multisample texture or renderbuffer automatically at the end of the render pass is often preferable to working with multisample textures (and not setting a resolve texture), because it avoids the need for writing dedicated fragment shaders that work exclusively with multisample textures (sampler2DMS, texelFetch, etc.), and rather allows using the same shader as one would if the attachment's texture was not multisampled to begin with. This comes at the expense of an additional resource (the non-multisample tex).
Definition at line 596 of file qrhi.h.
1.14.0