Commit Graph

9 Commits

Author SHA1 Message Date
Allan Sandfeld Jensen
af2daafde7 Deprecate constructing QFlags from a pointer
This was used to support QFlags f = 0 initialization, but with 0 used
as a pointer literal now considered bad form, it had been changed many
places to QFlags f = nullptr, which is meaningless and confusing.

Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2019-11-20 19:43:38 +01:00
Laszlo Agocs
f1c7814a55 rhi: Remove QVectors from the data description structs as well
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>
2019-10-03 09:37:48 +02:00
Laszlo Agocs
7000b66f7e Remove QVector in the API of QRhiResource subclasses
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>
2019-09-30 20:07:43 +02:00
Laszlo Agocs
22d22eb282 rhi: Add a --transparent option to manual tests
This will also cause clearing to 0,0,0,0.

Essential in order to allow fast testing of window transparency
issues in combination with QRhi and the various backends.

Change-Id: Iee2763c1d06f1d3e5d59a9142abaf30fab1dc543
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
2019-09-26 17:02:12 +02:00
Laszlo Agocs
2602209f54 rhi: vulkan: Introduce secondary command buffer usage
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>
2019-08-29 10:23:15 +02:00
Laszlo Agocs
058c52fc2a rhi: Improve base vertex/instance support
Have feature flags as appropriate. OpenGL is causing a mess here
but let's support what we can since some of this will become relevant
in more sophisticated mesh drawing cases with 3D in particular.

Change-Id: Idfa7b4642ec87147978e03d78d6233efbd151491
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-07-01 17:34:47 +02:00
Laszlo Agocs
854ddb0301 rhi: Enhance line width and point size support
...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>
2019-07-01 17:34:29 +02:00
Laszlo Agocs
6f4aa54131 rhi: Add compute api and implement for Vulkan and Metal
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>
2019-06-17 10:32:57 +02:00
Laszlo Agocs
53599592e0 Introduce the Qt graphics abstraction as private QtGui helpers
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>
2019-06-13 10:13:45 +02:00