summaryrefslogtreecommitdiffstats
path: root/src/mesa/main/fbobject.c
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* mesa: Limit Framebuffer Parameter OpenGL ES 3.1 usageMarta Lofstedt2015-09-011-1/+17
| | | | | | | | | | | | | | | 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>
* mesa: move non-generic samples validationTimothy Arceri2015-08-181-0/+10
| | | | | | | | | 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]>
* mesa/es3.1: Allow Multisampled FrameBufferTexturesMarta Lofstedt2015-08-101-2/+3
| | | | | | | 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]>
* mesa: initialize variables to silence compiler warningsBrian Paul2015-07-231-2/+2
| | | | Reviewed-by: Anuj Phogat <[email protected]>
* mesa: Rename _mesa_lookup_enum_by_nr() to _mesa_enum_to_string().Kenneth Graunke2015-07-201-36/+36
| | | | | | | Generated by sed; no manual changes. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* PATCH 03/10] mesa: Complete ARB_framebuffer_no_attachments in Mesa coreKevin Rogovin2015-06-171-29/+182
| | | | | | | | | | 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]>
* mesa: Constants and functions for ARB_framebuffer_no_attachmentsKevin Rogovin2015-06-171-0/+28
| | | | | | | | 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]>
* mesa: Define infrastructure for ARB_framebuffer_no_attachmentsKevin Rogovin2015-06-171-0/+1
| | | | | | | | | 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]>
* mesa: Use the profile instead of an extension bit to validate ↵Ian Romanick2015-05-281-3/+10
| | | | | | | | | | | 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]>
* Revert "mesa: Add ARB_direct_state_access checks in FBO functions"Ian Romanick2015-05-281-67/+0
| | | | | | | This reverts commit 6ad0b7e07a0445e9e0f368e079c4f7b8a6757bb3. Acked-by: Fredrik Höglund <[email protected]> Cc: "10.6" <[email protected]>
* Revert "mesa: Add ARB_direct_state_access checks in renderbuffer functions"Ian Romanick2015-05-281-21/+0
| | | | | | | This reverts commit cb49940766b581c6656473d89c221653c69fa0f9. Acked-by: Fredrik Höglund <[email protected]> Cc: "10.6" <[email protected]>
* mesa: Check the lookup_framebuffer return value in NamedFramebufferRenderbufferFredrik Höglund2015-05-161-0/+2
| | | | | | | Found by Coverity. Reported-by: Ilia Mirkin <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: Add ARB_direct_state_access checks in renderbuffer functionsFredrik Höglund2015-05-141-0/+21
| | | | | Signed-off-by: Fredrik Höglund <[email protected]> Reviewed-by: Adam Jackson <[email protected]>
* mesa: Add ARB_direct_state_access checks in FBO functionsFredrik Höglund2015-05-141-0/+67
| | | | | Signed-off-by: Fredrik Höglund <[email protected]> Reviewed-by: Adam Jackson <[email protected]>
* mesa: Make GL_TEXTURE_CUBE_MAP valid in FramebufferTextureLayerFredrik Höglund2015-05-141-5/+31
| | | | | Signed-off-by: Fredrik Höglund <[email protected]> Reviewed-by: Adam Jackson <[email protected]>
* main: Add stubs for [Get]NamedFramebufferParameteri[v].Laura Ekstrand2015-05-141-0/+32
| | | | | | | | | | | | | | 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]>
* main: Add entry points for InvalidateNamedFramebuffer[Sub]Data.Laura Ekstrand2015-05-141-0/+69
| | | | | Reviewed-by: Fredrik Höglund <[email protected]> Signed-off-by: Fredrik Höglund <[email protected]>
* main: Refactor invalidate_framebuffer_storage.Laura Ekstrand2015-05-141-11/+27
| | | | | Reviewed-by: Fredrik Höglund <[email protected]> Signed-off-by: Fredrik Höglund <[email protected]>
* main: Complete error conditions for glInvalidate*Framebuffer.Laura Ekstrand2015-05-141-1/+19
| | | | | | | 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]>
* main: Add entry point GetNamedFramebufferAttachmentParameteriv.Laura Ekstrand2015-05-141-41/+83
| | | | | | | | | [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]>