| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before 4.5, the default framebuffer was not allowed for
GetFramebufferParameter, so it should return INVALID_OPERATION for any
call using the default framebuffer.
4.5 included new pnames, and some of them are allowed for the default
framebuffer. For the rest, INVALID_OPERATION. From OpenGL 4.5 spec,
section 9.2.3 "Framebuffer Object Queries:
"An INVALID_OPERATION error is generated by GetFramebufferParameteriv
if the default framebuffer is bound to target and pname is not one
of the accepted values from table 23.73, other than
SAMPLE_POSITION."
Fixes:
GL45-CTS.direct_state_access.framebuffers_get_parameter_errors
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
4.5 added new pnames allowed for GetFramebufferParameter, and
GetNamedFramebufferParameter.
From OpenGL 4.5 spec, section 9.2.3 "Framebuffer Object Queries" (quoting
the paragraph with only the new pnames, not all the supported):
"pname may also be one of DOUBLEBUFFER,
IMPLEMENTATION_COLOR_READ_FORMAT, IMPLEMENTATION_COLOR_READ_TYPE,
SAMPLES, SAMPLE_BUFFERS, or STEREO, indicating the corresponding
framebuffer-dependent state from table 23.73. Values of
framebuffer-dependent state are identical to those that would be
obtained were the framebuffer object bound and queried using the
simple state queries in that table. These values may be queried
from either a framebuffer object or a default framebuffer."
Fixes:
GL45-CTS.direct_state_access.framebuffers_get_parameters
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
All the other calls to retrieve the attachment have been covered except
this one - return the proper error for attachment points that are valid
enums but out of bound for the driver.
Fixes GL45-CTS.geometry_shader.layered_fbo.fb_texture_invalid_attachment
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the attachment type is NONE (att->Type),
FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE should be NONE always.
Note that technically, the current behaviour follows the spec. From
OpenGL 4.5 spec, Section 9.2.3 "Framebuffer Object Queries":
"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
either no framebuffer is bound to target; or the default
framebuffer is bound, attachment is DEPTH or STENCIL, and the
number of depth or stencil bits, respectively, is zero."
Reading literally this paragraph, for the default framebuffer, NONE
should be only returned if attachment is DEPTH and STENCIL without
being allocated.
But it doesn't makes too much sense to return DEFAULT_FRAMEBUFFER if
the attachment type is NONE. For example, this can happens if the
attachment is FRONT_RIGHT run on monoscopic mode, as that attachment
is only available on stereo mode.
With the current behaviour, defensive querying of the object type
would not work properly. So you could query the object type checking
for NONE, get DEFAULT_FRAMEBUFFER, and then get and INVALID_OPERATION
when requesting other pnames (like RED_SIZE), as the real attachment
type is NONE.
This fixes:
GL45-CTS.direct_state_access.framebuffers_get_attachment_parameters
v2: don't change the behaviour for att->Type != GL_NONE, as caused
some ES CTS regressions
v3: simplify condition (Iago)
Reviewed-by: Iago Toral Quiroga <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In most cases, if a call to get_attachment fails is because attachment
is a INVALID_ENUM. But for some specific cases, if COLOR_ATTACHMENTm
(where m >= MAX_COLOR_ATTACHMENTS) is used, it should raise an
INVALID_OPERATION exception instead.
Fixes:
GL45-CTS.direct_state_access.framebuffers_get_attachment_parameter_errors
GL45-CTS.direct_state_access.framebuffers_renderbuffer_attachment_errors
v2: extra new line before quote block. Include "color attachment" on both
new message errors (Nicolai).
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Some callers would need that info to know if they should raise
INVALID_ENUM or INVALID_OPERATION. An alternative would be the caller
to check if the attachment is a GL_COLOR_ATTACHMENTm, but that seems
redundant as get_attachment is already doing that.
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GetFramebufferAttachmentParameteriv should return GL_LINEAR for the
window system default framebuffer's GL_DEPTH or GL_STENCIL attachments
when there are zero depth or stencil bits.
The GL 4.5 spec's GetFramebufferAttachmentParameteriv section says:
"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is not NONE,
these queries apply to all other framebuffer types:
[...]
If attachment is not a color attachment, or no data storage or texture
image has been specified for the attachment, then params will contain
the value LINEAR."
Note that we already return LINEAR for the case where there is an actual
depth or stencil renderbuffer attached. In the case modified by this
patch, FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE returns FRAMEBUFFER_DEFAULT
rather than NONE.
Fixes a CTS test when run in a visual without depth / stencil buffers:
GL45-CTS.gtf30.GL3Tests.framebuffer_srgb.framebuffer_srgb_default_encoding
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Framebuffer attachments can be specified through FramebufferTexture*
calls. Upon specifying a depth (or stencil) framebuffer attachment that
internally reuses a texture, the cube map face of the new attachment
would not be updated (defaulting to TEXTURE_CUBE_MAP_POSITIVE_X).
Fix this issue by actually updating the CubeMapFace field.
This bug manifested itself in BindFramebuffer calls performed on
framebuffers whose stencil attachments internally reused a depth
texture. When binding a framebuffer, we walk through the framebuffer's
attachments and update each one's corresponding gl_renderbuffer. Since
the framebuffer's depth and stencil attachments may share a
gl_renderbuffer and the walk visits the stencil attachment after
the depth attachment, the uninitialized CubeMapFace forced rendering
to TEXTURE_CUBE_MAP_POSITIVE_X.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77662
Signed-off-by: Nanley Chery <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Use a bitmask to indicate which color buffers are integer-valued, rather
than a bool. Also, the old field was mis-computed. If an integer buffer
was followed by a non-integer buffer, the _IntegerColor field was wrongly
set to false.
This fixes the new piglit gl-3.1-mixed-int-float-fbo test.
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ES3-CTS.functional.negative_api.buffer.framebuffer_texture2d expects
glFramebufferTexture[123]D to raise GL_INVALID_ENUM when
supplied a completely bogus textarget parameter (i.e. 0xffffffff).
This is at odds with the spec. GLES 3.1 says:
"An INVALID_OPERATION error is generated if texture is not zero and
textarget is not one of TEXTURE_2D, TEXTURE_2D_MULTISAMPLE, or one
of the cube map face targets from table 8.21."
(and GLES 3.0 and GL 4.5 both have similar text). However, GL has a
general guideline that says:
"If a command that requires an enumerated value is passed a symbolic
constant that is not one of those specified as allowable for that
command, an INVALID_ENUM error is generated."
Apparently other vendors reconcile these two rules as follows: GL should
raise INVALID_OPERATION for actual texture target enumeration values
which are not allowed for this particular glFramebufferTexture*D call.
Any value that is not a texture target should result in GL_INVALID_ENUM.
For example, glFramebufferTexture2D with GL_TEXTURE_1D would result in
INVALID_OPERATION because it is a real texture target, but not allowed
for the 2D version of the function. But calling it with GL_FRONT would
result in INVALID_ENUM, as that isn't even a texture target.
Fixes:
- {ES3-CTS,dEQP-GLES3}.functional.negative_api.buffer.framebuffer_texture2d
- {ES31-CTS,ES32-CTS,dEQP-GLES31}.functional.debug.negative_coverage.get_error.buffer.framebuffer_texture2d
References: https://gitlab.khronos.org/opengl/cts/merge_requests/387
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
| |
Having one top-level switch statement covering all known texture targets
will make the next change easier to implement.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
| |
This fixes 66 CTS tests on st/mesa.
Cc: 12.0 <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
| |
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This just fixed the crash with the apitrace in bug report.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95246
Cc: 11.1 11.2 12.0 <[email protected]>
Reviewed-by: Nicolai Hähnle <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the OpenGL 4.5 core spec:
"An INVALID_VALUE error is generated if texture is not zero and level is
not a supported texture level for textarget, as described above."
Other FramebufferTexture functions already do the right thing.
This fixes the main menu in F1 2015.
Cc: 11.1 11.2 <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
When we have the geometry extensions, enable querying of the new param.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
| |
Caught by Coverity (CID 1362021). Caused by commit 015f2207c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were locking the Shared->Mutex and then using calling functions like
_mesa_HashInsert that do additional per-hash-table locking internally.
Instead just lock each hash-table's mutex and use functions like
_mesa_HashInsertLocked and the new _mesa_HashRemoveLocked.
In order to do this, we need to remove the locking from
_mesa_HashFindFreeKeyBlock since it will always be called with the
per-hash-table lock taken.
Reviewed-by: Timothy Arceri <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
V.2:
Change 'N.B.,' to 'NOTE:'.
Signed-off-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes:
dEQP-GLES3.functional.negative_api.state.get_framebuffer_attachment_parameteriv
Apparently, GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is not allowed when
GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is GL_FRAMEBUFFER_DEFAULT, and
is expected to result in a GL_INVALID_ENUM error.
No GL specification actually defines what GL_FRAMEBUFFER_DEFAULT means.
It probably means the window system FBO. It also doesn't mention the
behavior of any queries for that type. Various ARB folks seem fairly
confused about it too. For now, just do something vaguely like what
dEQP expects.
I think we probably need to check the visual bits against 0 for the
attachment, but we haven't been doing that thusfar, and given how
confusingly this is specified, I can't imagine anyone relying on it.
v2: Improve comments, move error condition above the
_mesa_get_fb0_attachment call, add forgotten "return"
(all suggested/caught by Jordan Justen).
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Jordan Justen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ES 3.0+ specifications contain the exact same text as the OpenGL
specification, which says that we should return GL_INVALID_OPERATION.
ES 2.0 contains different text saying we should return GL_INVALID_ENUM.
Previously, Mesa chose the error code based on API (GL vs. ES).
This patch makes ES 3.0+ follow the GL behavior. ES 2 remains as is.
Fixes dEQP-GLES3.functional.fbo.api.attachment_query_empty_fbo.
However, breaks the dEQP-GLES2 variant of the same test for drivers
which silently promote to ES 3.0. This can be worked around by
exporting MESA_GLES_VERSION_OVERRIDE=2.0, but is a bug in dEQP-GLES2.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
Don't use hardcoded ones because the driver can set different ones.
Signed-off-by: Samuel Iglesias Gonsálvez <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Fixing dd_function_table::BindFramebuffer will come later because that
change is probably not suitable for stable.
v2: Fix whitespace issue noticed by Topi.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
When reusing a depth attachment as a stencil, we need to propogate
the layered bit, otherwise we fail to complete the framebuffer.
discovered running ./bin/fbo-depth-array depth-layered-clear
on virgl on haswell.
Reviewed-by: Marek Olšák <[email protected]>
Cc: "11.1 11.2" <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The base format is a function of the user-requested format, while the
driver format is not. So we should use the base format instead.
The driver format can be anything. Specifically in the stencil-only
case, it might be a depth/stencil format. However we still want to
refuse such an attachment when bound to GL_DEPTH.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Pulls the parts of renderbuffer_storage that aren't just parameter
validation out into a function that can be called from other parts of
Mesa (e.g., meta).
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
This function previously was only used in fbobject.c and contained a
bunch of API validation. Split the function into
framebuffer_renderbuffer that is static and contains the validation, and
_mesa_framebuffer_renderbuffer that is suitable for calling from
elsewhere in Mesa (e.g., meta).
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes dEQP-GLES31.functional.fbo.completeness.no_attachments
When the width or height are 0, the framebuffer is incomplete. We may
also not have been passing the new state down to the driver when the
widths/heights/etc changed. Make sure to dirty the state so that the
framebuffer state is revalidated at draw time.
Signed-off-by: Ilia Mirkin <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
| |
We already check if the driver changed the completeness, we don't
need to duplicate that check. Let's just early out there instead.
Signed-off-by: Erik Faye-Lund <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From section 9.2. Binding and Managing Framebuffer Objects:
"Upon successful return from Get*FramebufferAttachmentParameteriv, if
pname is FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, then params will contain
one of NONE, FRAMEBUFFER_DEFAULT, TEXTURE, or RENDERBUFFER, identifying
the type of object which contains the attached image."
And then it clarifies further:
"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, then
either no framebuffer is bound to target; or the default framebuffer is
bound, attachment is DEPTH or STENCIL, and the number of depth or stencil
bits, respectively, is zero"
Currently, if the default framebuffer is bound, we always return
GL_FRAMEBUFFER_DEFAULT for FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, but
according to the spec, when GL_DEPTH or GL_STENCIL attachments are
the ones being queried, we should return GL_NONE if they don't exist.
Fixes the following dEQP test:
dEQP-GLES3.functional.state_query.fbo.framebuffer_attachment_x_size_initial
Reviewed-by: Ian Romanick <[email protected]>
Cc: "10.6" <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to OpenGL ES 3.1 specification, section 9.2.1 for
glFramebufferParameter and section 9.2.3 for glGetFramebufferParameteriv:
"An INVALID_ENUM error is generated if pname is not FRAMEBUFFER_DEFAULT_WIDTH,
FRAMEBUFFER_DEFAULT_HEIGHT, FRAMEBUFFER_DEFAULT_SAMPLES, or
FRAMEBUFFER_DEFAULT_FIXED_SAMPLE_LOCATIONS."
Therefore exclude OpenGL ES 3.1 from using the GL_FRAMEBUFFER_DEFAULT_LAYERS
parameter.
Signed-off-by: Marta Lofstedt <[email protected]>
Reviewed-by: Kevin Rogovin <kevin.rogovin at intel.com>
|
|
|
|
|
|
|
|
|
| |
The previous patch replaces the other use case.
V2: remove the validation from it old location.
Cc: Tapani Pälli <[email protected]>
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
| |
GLES 3.1 must be allowed to use multisampled framebuffer textures.
Signed-off-by: Marta Lofstedt <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
| |
Reviewed-by: Anuj Phogat <[email protected]>
|
|
|
|
|
|
|
| |
Generated by sed; no manual changes.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Implement GL_ARB_framebuffer_no_attachments in Mesa core
- changes to conditions for framebuffer completenss
- implement set/get functions for framebuffers for
new functions in GL_ARB_framebuffer_no_attachments
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Kevin Rogovin <[email protected]>
|
|
|
|
|
|
|
|
| |
Define the enumeration constants, function entry points and
glGet for the GL_ARB_framebuffer_no_attachments.
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Kevin Rogovin <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Define the infrastructure for the extension GL_ARB_framebuffer_no_attachments:
- extension table
- additions to gl_framebuffer
Reviewed-by: Ian Romanick <[email protected]>
Signed-off-by: Kevin Rogovin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
GL_TEXTURE_CUBE_MAP
The extension on which this depends will always be enabled in core
profile, and the extension bit is about to be removed.
Signed-off-by: Ian Romanick <[email protected]>
Reviewed-by: Fredrik Höglund <[email protected]>
Cc: "10.6" <[email protected]>
|
|
|
|
|
|
|
| |
This reverts commit 6ad0b7e07a0445e9e0f368e079c4f7b8a6757bb3.
Acked-by: Fredrik Höglund <[email protected]>
Cc: "10.6" <[email protected]>
|
|
|
|
|
|
|
| |
This reverts commit cb49940766b581c6656473d89c221653c69fa0f9.
Acked-by: Fredrik Höglund <[email protected]>
Cc: "10.6" <[email protected]>
|
|
|
|
|
|
|
| |
Found by Coverity.
Reported-by: Ilia Mirkin <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Fredrik Höglund <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Fredrik Höglund <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Fredrik Höglund <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ARB_direct_state_access specification says (as of 2015.02.05):
"Interactions with OpenGL 4.3 or ARB_framebuffer_no_attachments
If neither OpenGL 4.3 nor ARB_framebuffer_no_attachments are supported,
ignore the support for NamedFramebufferParameteri and
GetNamedFramebufferParameteriv."
This commit adds stubs for these entry points.
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|
|
|
|
|
|
|
| |
Signed-off-by: Fredrik Höglund <[email protected]>
Reviewed-by: Fredrik Höglund <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
Cc: "10.4 10.5" <[email protected]>
|
|
|
|
|
|
|
|
|
| |
[Fredrik: - Update one of the error messages to reflect that the
framebuffer might not be the bound framebuffer.
- Whitespace fixes.]
Reviewed-by: Fredrik Höglund <[email protected]>
Signed-off-by: Fredrik Höglund <[email protected]>
|