summaryrefslogtreecommitdiffstats
path: root/src/mesa/main/fbobject.c
Commit message (Collapse)AuthorAgeFilesLines
* mesa: add KHR_no_error support for NamedFramebufferTextureTimothy Arceri2017-05-171-0/+8
| | | | | | V3: use frame_buffer_texture() helper Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: add KHR_no_error support for FramebufferTextureTimothy Arceri2017-05-171-0/+9
| | | | | | V3: use the frame_buffer_texture() helper Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: add *FramebufferTexture() support to frame_buffer_texture helperTimothy Arceri2017-05-171-100/+41
| | | | | | V2: call check_layered_texture_target() even for no_error Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: add KHR_no_error support for NamedFramebufferTextureLayerTimothy Arceri2017-05-171-0/+12
| | | | | | v3: use frame_buffer_texture_layer() helper Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: add KHR_no_error support for FramebufferTextureLayerTimothy Arceri2017-05-171-0/+9
| | | | | | V3: use frame_buffer_texture_layer() helper Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: add no error support to frame_buffer_texture_layer() helperTimothy Arceri2017-05-171-27/+43
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: add frame_buffer_texture_layer() helperTimothy Arceri2017-05-171-54/+31
| | | | | | | To be used to add KHR_no_error support while sharing code between the DSA and non-DSA OpenGL function. Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: add KHR_no_error support for FramebufferTexture*D functionsTimothy Arceri2017-05-111-0/+30
| | | | Reviewed-by: Eric Anholt <[email protected]>
* mesa: add no error version of framebuffer_texture_with_dims()Timothy Arceri2017-05-111-0/+22
| | | | Reviewed-by: Eric Anholt <[email protected]>
* mesa: add error version of get_texture_for_framebuffer()Timothy Arceri2017-05-111-8/+18
| | | | | | This is a step towards KHR_no_error support. Reviewed-by: Eric Anholt <[email protected]>
* mesa: pass rb attachment to _mesa_framebuffer_texture()Timothy Arceri2017-05-111-17/+37
| | | | | | This change will help us add KHR_no_error support to the caller. Reviewed-by: Eric Anholt <[email protected]>
* mesa: add _mesa_get_and_validate_attachment() helperTimothy Arceri2017-05-111-12/+25
| | | | | | | Will be used to add KHR_no_error support. We make this available external so it can be called from meta. Reviewed-by: Eric Anholt <[email protected]>
* mesa: remove _mesa_problem() from a few locationsTimothy Arceri2017-05-111-5/+3
| | | | | | | | | | | _mesa_problem() is still useful in some places such as is if a backend compile fails, but for the majority of cases we should be able to remove it. OpenGL test suites are becoming very mature, we should place more trust in debug builds picking up missed cases. Reviewed-by: Eric Anholt <[email protected]>
* mesa: make _mesa_get_framebuffer_attachment_parameter() staticTimothy Arceri2017-05-111-9/+9
| | | | Reviewed-by: Eric Anholt <[email protected]>
* mesa: fix indentationTimothy Arceri2017-05-111-1/+1
| | | | Reviewed-by: Eric Anholt <[email protected]>
* mesa: remove _mesa from static framebuffer object functionTimothy Arceri2017-05-111-3/+3
| | | | Reviewed-by: Eric Anholt <[email protected]>
* mesa: fix renderbuffer leakTimothy Arceri2017-04-071-1/+1
| | | | | | | | | | | We don't need to call _mesa_reference_renderbuffer() for the first assignment as refCount starts at 1. For swrast we work around the fact we will indirectly call _mesa_reference_renderbuffer() by resetting refCount to 0. Fixes: 32141e53d1520 (mesa: tidy up renderbuffer RefCount initialisation) Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]>
* mesa/main: simplify _mesa_IsRenderbuffer()Samuel Pitoiset2017-04-071-7/+6
| | | | | | | _mesa_lookup_renderbuffer() already checks if 'id' is non-zero. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* mesa: tidy up renderbuffer RefCount initialisationTimothy Arceri2017-04-061-1/+0
| | | | | | | | | | | 42aaa548 changed the renderbuffer initialisation of RefCount from 1 to 0. This is inconsitent with how we use RefCount elsewhere. Also every driver implementation of NewRenderbuffer() calls _mesa_init_renderbuffer() so its safe to set it there. Reviewed-by: Brian Paul <[email protected]>
* mesa: Avoid read of uninitialized variableRobert Foss2017-03-021-1/+1
| | | | | | | | | | | | | | | | The is_color_attachement variable is later read when handling two separate error cases, where only one of the cases results in the variable being initialized. This can be avoided by giving the variable a safe default value. Coverity-Id: 1398631 Cc: [email protected] Signed-off-by: Robert Foss <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* main/fboject: default_framebuffer allowed for GetFramebufferParameterAlejandro Piñeiro2017-02-061-7/+37
| | | | | | | | | | | | | | | | | | | | 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]>
* main/fbobject: implement new 4.5 pnames for GetFramebufferParameterAlejandro Piñeiro2017-02-061-0/+18
| | | | | | | | | | | | | | | | | | | | | | 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]>
* mesa: use same is_color_attachment trick to discern error casesIlia Mirkin2017-01-311-3/+11
| | | | | | | | | | | 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]>
* mesa/main: Fix FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for NONE attachment typeAlejandro Piñeiro2017-01-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* main/fbobject: throw invalid operation when get_attachment fails if neededAlejandro Piñeiro2017-01-131-7/+42
| | | | | | | | | | | | | | | | 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]>
* main/fboject: return if it is color_attachment on get_attachmentAlejandro Piñeiro2017-01-131-11/+19
| | | | | | | | | 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]>
* mesa: Return LINEAR encoding for winsys FBO depth/stencil.Kenneth Graunke2016-12-111-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* mesa/fbobject: Update CubeMapFace when reusing texturesNanley Chery2016-11-181-0/+1
| | | | | | | | | | | | | | | | | | | | | 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]>
* mesa: replace gl_framebuffer::_IntegerColor wih _IntegerBuffersBrian Paul2016-10-131-4/+6
| | | | | | | | | | | 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]>
* mesa: Raise INVALID_ENUM in FramebufferTexture*D for unknown textargets.Kenneth Graunke2016-10-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* mesa: Reorganize check_textarget().Kenneth Graunke2016-10-041-43/+37
| | | | | | | | 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]>
* mesa: fix glGetFramebufferAttachmentParameteriv w/ on-demand FRONT_BACK allocMarek Olšák2016-09-161-2/+14
| | | | | | | This fixes 66 CTS tests on st/mesa. Cc: 12.0 <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* mesa: print number of samples in renderbuffer_storage error msgBrian Paul2016-07-081-1/+1
| | | | Reviewed-by: Timothy Arceri <[email protected]>
* mesa: fix crash in driver_RenderTexture_is_safeMarek Olšák2016-05-311-1/+2
| | | | | | | | | 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]>
* mesa: skip level checking for FramebufferTexture*D if texture is zeroMarek Olšák2016-05-291-3/+3
| | | | | | | | | | | | | 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]>
* mesa: allow GL_FRAMEBUFFER_DEFAULT_LAYERS to be queried with ES geometryIlia Mirkin2016-05-231-2/+2
| | | | | | | 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]>
* mesa: Unlock mutex on error path.Matt Turner2016-05-221-0/+1
| | | | Caught by Coverity (CID 1362021). Caused by commit 015f2207c.
* mesa: Replace uses of Shared->Mutex with hash-table mutexesMatt Turner2016-05-201-13/+19
| | | | | | | | | | | | | | | 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]>
* mesa: Add comment to framebuffer_parameteri()Edward O'Callaghan2016-04-071-0/+5
| | | | | | | | | 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]>
* mesa: Disallow GL_FRAMEBUFFER_ATTACHMENT_OBJECT_NAME on winsys FBO.Kenneth Graunke2016-03-191-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* mesa: Fix error code for GetFramebufferAttachmentParameter in ES 3.0+.Kenneth Graunke2016-03-081-2/+16
| | | | | | | | | | | | | | | | | | 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]>
* main: call invalidate_framebuffer_storage() with driver's viewport limitsSamuel Iglesias Gonsálvez2016-03-021-2/+4
| | | | | | | 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]>
* mesa: Refactor bind_framebuffer to make _mesa_bind_framebuffersIan Romanick2016-03-011-12/+21
| | | | | | | | | | 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]>
* mesa/fbobject: propogate Layered when reusing attachments.Dave Airlie2016-03-011-0/+1
| | | | | | | | | | | | 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]>
* mesa: check fbo completeness based on internal format, not driver formatIlia Mirkin2016-02-191-3/+2
| | | | | | | | | | | | 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]>
* mesa: Refactor renderbuffer_storage to make _mesa_renderbuffer_storageIan Romanick2016-02-101-39/+58
| | | | | | | | | 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]>
* mesa: Refactor _mesa_framebuffer_renderbufferIan Romanick2016-02-101-16/+26
| | | | | | | | | | | 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]>
* mesa: invalidate framebuffer when changing parametersIlia Mirkin2016-02-021-0/+3
| | | | | | | | | | | | | 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]>
* main: get rid of needless conditionalErik Faye-Lund2016-01-121-13/+12
| | | | | | | | 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]>
* mesa: Fix GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE for default framebuffer.Iago Toral Quiroga2015-09-231-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 01:48:57 +0000