GitLab

color only

Let's pretend it's 2008 and forget about multisample textures for
a moment. Therefore, add support for color renderbuffers. These are
only useful when sample count is > 1 i.e. multisampling is requested.
In combination with the yet-to-be-added resolve operation this would
allow doing msaa offscreen rendering on GLES 3.0 (or GLES 2.0 with
extensions) systems as well (those do not have multisample textures)

Backends other than gl just use a texture under the hood. With OpenGL
we use a renderbuffer, however, not a texture.

This may seem like a horrible waste of time but will eventually be
helpful to get a port of Qt Quick that is feature-wise identical to
today's OpenGL path, without changing the OpenGL version requirements.

Introduces isFeatureSupported, so examples like msaatexture can
conveniently qFatal (hehe) when the GL backend reports multisample
textures are not supported.

While we are at it, make some examples nicer by not having to repeat
releasing resources one by one.

The example (msaarenderbuffer) is not finished yet since adding support
for resolve (vkCmdResolveImage, glBlitFrameBuffer, etc.) is a future task.

...including some buffer upload improvements...

...and fix up the whole res update system for d3d and gl. (make it
go through the (fake) command buffer like everything else)

hints -> flags for rt, add sampleCount for tex

...for non-compressed textures.

Color only, one subres at a time, transitions between transfer and
shader-read every time. For the common cases this is good enough,
to be explored later if it could be made smarter.

...in order to make the api nicer. Does not affect the internals.

With an example.

not yet implemented

only implemented for Vulkan for now

...and related plumbing here and there.

...instead of ChangeInfrequently. This way the common case
(not changing the image data afterwards) is the default.

Only downside is that values other than 1 are not supported with Vulkan 1.0.

While we are at it, rename QRhiRenderPass to QRhiRenderPassDescriptor
because renderpass on its own is a somwhat misleading naming.

...and add the - for now - unused buildCompatibleRenderPass functions.

It is for internal use only.