OpenHarmony/third_party_mesa3d
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

gallium: Add PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT

Browse Source 
Add PIPE_CAP to determine if the GL extension
'GL_ARB_framebuffer_no_attachments' shall be
supported.

The driver is required to support 'PIPE_FORMAT_NONE'
via its 'is_format_supported()' callback in order
to determine the MSAA modes the hardware supports so
that values requested from the application using
'GL_ARB_framebuffer_no_attachments' may be quantized
to what the hardware expects.

V.2:
 Fix doc for a more detailed description of the PIPE_CAP
 and the corresponding GL constant.

V.3:
 Renamed and repurposed once again.

V.4:
 Remove CAP from cap_mapping array.

[airlied: fix damaged whitespace]

Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit is contained in:
Edward O'Callaghan
2016-02-17 20:59:52 +11:00
committed by Dave Airlie
parent 85f79f0c75
commit 4bc9130fba
16 changed files with 23 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/gallium/docs/source/screen.rst
View File

@@ -323,6 +323,14 @@ The integer capabilities:
* ``PIPE_CAP_PCI_BUS``: Return the PCI bus number.
* ``PIPE_CAP_PCI_DEVICE``: Return the PCI device number.
* ``PIPE_CAP_PCI_FUNCTION``: Return the PCI function number.
* ``PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT``:
If non-zero, rendering to framebuffers with no surface attachments
is supported. The context->is_format_supported function will be expected
to be implemented with PIPE_FORMAT_NONE yeilding the MSAA modes the hardware
supports. N.B., The maximum number of layers supported for rasterizing a
primitive on a layer is obtained from ``PIPE_CAP_MAX_TEXTURE_ARRAY_LAYERS``
even though it can be larger than the number of layers supported by either
rendering or textures.
.. _pipe_capf: