summaryrefslogtreecommitdiffstats
path: root/src/mesa/main
Commit message (Collapse)AuthorAgeFilesLines
* mesa: expose AMD_texture_texture4Marek Olšák2018-12-041-0/+1
| | | | | | because the closed driver exposes it. Tested by piglit. Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: expose EXT_texture_compression_bptc in GLESMarek Olšák2018-12-043-1/+21
| | | | | | | | | tested by piglit. v2: rebase Reviewed-by: Ilia Mirkin <[email protected]> (v1) Reviewed-by: Erik Faye-Lund <[email protected]>
* mesa: expose EXT_texture_compression_rgtc on GLESMarek Olšák2018-12-043-6/+24
| | | | | | | | | The spec was modified to support GLES. Tested by piglit. v2: rebase Reviewed-by: Ilia Mirkin <[email protected]> (v1) Reviewed-by: Erik Faye-Lund <[email protected]>
* mesa/main: fix up _mesa_has_rg_textures for gles2Erik Faye-Lund2018-12-041-1/+2
| | | | | | | | | | | rg-textures are supported in GLES 2.0 if EXT_texture_rg, so let's make sure the enums are accepted. Fixes: 510b6424607 "mesa/main: do not allow rg-textures enums before gles3" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108936 Signed-off-by: Erik Faye-Lund <[email protected]> Tested-by: Mark Janes <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: correct validation for GL_RGB565Erik Faye-Lund2018-12-041-1/+3
| | | | | | | | | | | Technically speaking, this validation was incorrect, because GL_RGB565 is only supported in OpenGL ES 1.x if OES_framebuffer_object is supported. This couldn't lead to any real incorrect behavior, because all drivers support OES_framebuffer_object. But let's keep the code self-documenting, by correcting the check as per the spec. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* mesa: expose GL_EXT_texture_view as an alias of GL_OES_texture_viewMarek Olšák2018-12-041-0/+1
| | | | | | There are no spec changes. Reviewed-by: Ilia Mirkin <[email protected]>
* mesa: drop unused & deprecated libEric Engestrom2018-12-041-1/+1
| | | | | | | | DeprecationWarning: the imp module is deprecated in favour of importlib Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* mesa: Revert INTEL_fragment_shader_ordering supportMatt Turner2018-12-032-2/+0
| | | | | | | | | | | | | | | | This extension is not properly tested (testing for GL_ARB_fragment_shader_interlock is not sufficient), and since this was noted in review on August 28th no tests have been sent. Revert "i965: Add INTEL_fragment_shader_ordering support." Revert "mesa: Add GL/GLSL plumbing for INTEL_fragment_shader_ordering" This reverts commit 03ecec9ed2099f6e2b62994b33dc948dc731e7b8. This reverts commit 119435c8778dd26cb7c8bcde9f04b3982239fe60. Cc: [email protected] Acked-by: Jason Ekstrand <[email protected]> Acked-by: Eric Anholt <[email protected]>
* mesa/main: do not require float-texture filtering for es3Erik Faye-Lund2018-12-031-1/+3
| | | | | | | | | The OpenGL ES 3.0 specification, table 3.13 lists half-float textures as filterable, but not float textures. So we shouldn't depend on ARB_float_texture, which requires full filtering support for both. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: require EXT_texture_sRGB for gles3Erik Faye-Lund2018-12-031-0/+1
| | | | | | | | sRGB textures is a requirement for OpenGL ES 3.0, so let's make sure we don't incorrectly enable a too high version. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: require EXT_texture_type_2_10_10_10_REV for gles3Erik Faye-Lund2018-12-031-1/+2
| | | | | | | | | | | OpenGL ES 3.0 require this functionality, so we should also test for it to avoid incorrectly exposing a too high GLES version. On desktop, this has been required since all the way back in OpenGL 1.2 anyway. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: split float-texture support checking in twoErik Faye-Lund2018-12-032-12/+41
| | | | | | | | | | | | | | | | On OpenGL ES 2.0, there's separate extensions adding support for half-float and float textures. So we need to validate the enums separately as well. This also prevents these enums from incorrectly being allowed on OpenGL ES 1.x, where there's no extension that enables this in the first place. While we're at it, remove the pointless default-case, and the seemingly stale fallthrough comment. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow EXT_texture_sRGB_R8 enums before gles3Erik Faye-Lund2018-12-031-2/+2
| | | | | | | | | | | | | ctx->Extensions.EXT_texture_sRGB_R8 is set regardless of the API that's used, so checking for those direcly will always allow the enums from this extensions when they are supported by the driver. There's no extension adding support for this on OpenGL ES before version 3.0, so let's tighten the check. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-By: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow sRGB texture enums before gles3Erik Faye-Lund2018-12-031-1/+1
| | | | | | | | | | | | ctx->Extensions.EXT_texture_sRGB is set regardless of the API that's used, so checking for those direcly will always allow the enums from this extensions when they are supported by the driver. There's no extension adding support for this on OpenGL ES before version 3.0, so let's tighten the check. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow snorm-texture enums before gles3Erik Faye-Lund2018-12-031-1/+1
| | | | | | | | | | | | ctx->Extensions.EXT_texture_snorm is set regardless of the API that's used, so checking for those direcly will always allow the enums from this extensions when they are supported by the driver. There's no extension adding support for this on OpenGL ES before version 3.0, so let's tighten the check. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow floating-point texture enums on gles1Erik Faye-Lund2018-12-031-10/+10
| | | | | | | | | | | | ctx->Extensions.OES_texture_float is set regardless of the API that's used, so checking for those direcly will always allow the enums from this extensions when they are supported by the driver. There's no extension enabling floating-point textures for OpenGL ES 1.x, so we shouldn't allow those enums there. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow type_2_10_10_10_REV enums before gles3Erik Faye-Lund2018-12-032-3/+10
| | | | | | | | | | | | ctx->Extensions.EXT_texture_type_2_10_10_10_REV is set regardless of the API that's used, so checking for those direcly will always enable extensions when they are supported by the driver. There's no corresponding extension for OpenGL ES 1.x/2.0, so we shouldn't allow these enums there. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow MESA_ycbcr_texture enums on glesErik Faye-Lund2018-12-031-2/+2
| | | | | | | | This extension requies OpenGL, and shouldn't be available on OpenGL ES. So let's not allow the enums from it either. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow EXT_texture_shared_exponent enums before gles3Erik Faye-Lund2018-12-032-2/+8
| | | | | | | | | | | | ctx->Extensions.EXT_texture_shared_exponent is set regardless of the API that's used, so checking for those direcly will always allow the enums from this extensions when they are supported by the driver. We also need to make sure this is enabled on OpenGL ES 3. Because the check is repeated, let's introduce a helper. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow rg-textures enums before gles3Erik Faye-Lund2018-12-032-11/+17
| | | | | | | | | | | EXT_packed_float isn't supported on OpenGL ES, we shouldn't allow these enums there, before OpenGL ES 3.0 which also introduce support for these enums. Since this check is repeated a lot, let's make a helper for this. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow EXT_packed_float enums before gles3Erik Faye-Lund2018-12-032-3/+9
| | | | | | | | | EXT_packed_float isn't supported on OpenGL ES, we shouldn't allow these enums there, before OpenGL ES 3.0 which also introduce support for these enums. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow ARB_depth_buffer_float enums before gles3Erik Faye-Lund2018-12-032-3/+9
| | | | | | | | | | | | Floating-point depth buffers are only supported on OpenGL 3.0, OpenGL ES 3.0, or if ARB_depth_buffer_float is supported. Because we checked a driver capability rather than using an extension-check helper, we ended up incorrectly allowing this on OpenGL ES 1.x and 2.x. Since this logic is repeated, let's make a helper for it. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow integer-texture enums before gles3Erik Faye-Lund2018-12-031-2/+2
| | | | | | | | | | Integer textures shouldn't be implicitly exposed on OpenGL ES 1.x and 2.x, but because the code checked against a driver-capability rather than using an extension-check helper, we ended up accidentally allowing these enums on older versions when the driver supports it. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow ARB_texture_rgb10_a2ui enums before gles3Erik Faye-Lund2018-12-032-6/+12
| | | | | | | | ARB_texture_rgb10_a2ui isn't supported on OpenGL ES, we shouldn't expose it there even if the driver supports it. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow stencil-texture enums on gles1Erik Faye-Lund2018-12-031-1/+2
| | | | | | | | | | | | | | ctx->Extensions.ARB_texture_stencil8 is set regardless of the API that's used, so checking for those direcly will always allow the enums from this extensions when they are supported by the driver. So let's instead check for both ARB_texture_stencil8 and OES_texture_stencil8, so we support depth textures on OpenGL and OpenGL ES 2.0+. There's no extension enabling stencil-textures for OpenGL ES 1.x, so we shouldn't allow those enums there. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow depth-texture enums on gles1Erik Faye-Lund2018-12-031-1/+2
| | | | | | | | | | | | | | | | ctx->Extensions.ARB_depth_texture is set regardless of the API that's used, so checking for those direcly will always allow the enums from this extensions when they are supported by the driver. So let's instead check for both ARB_depth_texture and OES_depth_texture, so we support depth textures on OpenGL and OpenGL ES 2.0+. There's no extension enabling depth-textures for OpenGL ES 1.x, so we shouldn't allow those enums there. This fixes oes_packed_depth_stencil-depth-stencil-texture_gles1 on i965 Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow astc enums on gles1Erik Faye-Lund2018-12-031-3/+3
| | | | | | | | | | | | ctx->Extensions.KHR_texture_compression_astc_ldr is set regardless of the API that's used, so checking for those direcly will always enable extensions when they are supported by the driver. But there's no extension enabling ASTC for OpenGL ES 1.x, so we shouldn't allow those enums there. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow etc2 enums on gles1Erik Faye-Lund2018-12-031-1/+1
| | | | | | | | | | | | ctx->Extensions.ARB_ES3_compatibility is set regardless of the API that's used, so checking for those direcly will always enable extensions when they are supported by the driver. But there's no extension enabling ETC2 for OpenGL ES 1.x, so we shouldn't allow those enums there. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: do not allow s3tc enums on gles1Erik Faye-Lund2018-12-031-5/+2
| | | | | | | | | | | | | | There's no extension enabling S3TC formats on OpenGL ES 1.x, so we shouldn't allow these even if the driver can support it. So let's check for EXT_texture_compression_s3tc instead of ANGLE_texture_compression_dxt, which is supported on all other OpenGL variations. We also need to use _mesa_has_EXT_texture_compression_s3tc() instead of checking the driver cap directly, otherwise we end up enabling this on OpenGL ES 1.x, as the API isn't checked. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: use _mesa_has_FOO_bar for compressed format checksErik Faye-Lund2018-12-031-12/+6
| | | | | | | | _mesa_has_FOO_bar() knows about the APIs these extensions should be supported under, so let's use that to simplify these checks a bit. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: clean up integer texture checkErik Faye-Lund2018-12-032-16/+17
| | | | | | | | This makes the logic a little bit easier to follow, and reduce a bit of repetition. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: clean up ES2_compatibility checkErik Faye-Lund2018-12-031-1/+1
| | | | | | | | | This makes the logic a little bit easier to follow; this is *either* about ES2 compatibility *or* about gles. GL_RGB565 was added already in OpenGL ES 1.0. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: clean up OES_texture_float_linear checkErik Faye-Lund2018-12-031-1/+1
| | | | | | | | | | | | | | Using the _mesa_has_FOO_bar helpers is generally more safe and should generally be prefered over checking driver-caps like this code did, because the _mesa_has_FOO_bar helpers also verify the API type and version. This shouldn't have any practical effect here, as this function only gets called for OpenGL ES 3.x right now. But if this was to change in the future, this makes the function behave a lot more predictable. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: clean up S3_s3tc checkErik Faye-Lund2018-12-031-5/+3
| | | | | | | | | | | | | | S3_s3tc is the extension that enables this functionality on desktop, so let's check for that one. The _mesa_has_S3_s3tc() helper already verifies the API according to the extension-table. As for the second hunk, we currently already only expose EXT_texture_compression_s3tc on desktop so by using the helper instead, we get rid of this detail here, and once we enable it for GLES we'll automaticall get the interaction right. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: rename format-check functionErik Faye-Lund2018-12-033-11/+11
| | | | | | | | | | | | | _mesa_es3_error_check_format_and_type isn't specific to OpenGL ES 3.x, it applies to all versions of OpenGL ES. So let's rename it to reflect this. While we're at it, let's also rename a helper function it uses similarly. As the helper is static, we can also remove the namespacing-prefix from the name. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: make _mesa_has_tessellation return boolErik Faye-Lund2018-12-031-1/+1
| | | | | | | | All other _mesa_has_foo functions return bool rather than GLboolean, so let's follow that style here as well. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: fixup requirements for GL_PRIMITIVES_GENERATEDErik Faye-Lund2018-11-261-0/+1
| | | | | | | | | | | | This enum is also allowed by EXT_tessellation_shader, which is supported on older i965 HW (as opposed to OES_geometry_shader). This was missed when narrowing this code-path, leading to dEQP regressions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108868 Fixes: f09d94fbd11 "mesa/main: fix validation of transform-feedback queries" Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Tested-by: Mark Janes <[email protected]>
* mesa/main: fix incorrect depth-errorErik Faye-Lund2018-11-261-7/+50
| | | | | | | | | | | | | | | | | | | | | If glGetTexImage or glGetnTexImage is called with a level that doesn't exist, we get an error message on this form: Mesa: User error: GL_INVALID_VALUE in glGetTexImage(depth = 0) This is clearly nonsensical, because these APIs don't even have a depth-parameter. The reason is that get_texture_image_dims() return all-zero dimensions for non-existent texture-images, and we go on to validate these dimensions as if they were user-input, because glGetTextureSubImage requires checking. So let's split this logic in two, so glGetTextureSubImage can have stricter input-validation. All arguments that are no longer validated are generated internally by mesa, so there's no use in validating them. Fixes: 42891dbaa12 "gettextsubimage: verify zoffset and depth are correct" Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]>
* mesa/main: check cube-completeness in common codeErik Faye-Lund2018-11-261-15/+16
| | | | | | | | | | | | | | This check is the only part of dimensions_error_check that isn't about error-checking the offset and size arguments of glGet[Compressed]TextureSubImage(), so it doesn't really belong in here. This doesn't make a difference right now, apart for changing the presedence of this error. But it will make a difference for the next patch, where we no longer call this method from the non-sub tex-image getters. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]>
* mesa/main: factor out common error-checkingErik Faye-Lund2018-11-261-12/+34
| | | | | | | | | | | This error checking is the same for teximage and texsubimage getters, so let's factor it out to its own function. This will be useful when getteximage and gettexsubimage gets their own error checking routines a bit later. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]>
* mesa/main: factor out tex-image error-checkingErik Faye-Lund2018-11-261-46/+64
| | | | | | | | This will be useful when we split error-checking for getteximage and gettexsubimage later. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]>
* mesa/main: remove bogus error for zero-sized imagesErik Faye-Lund2018-11-261-36/+13
| | | | | | | | | | | | | | | | | | | | | | | | | The explanation quotes the spec on the following wording to justify the error: "An INVALID_VALUE error is generated if xoffset + width is greater than the texture’s width, yoffset + height is greater than the texture’s height, or zoffset + depth is greater than the texture’s depth." However, this shouldn't generate an error in the case where *all three* of width, xoffset and the texture's width are zero. In this case, we end up generating an unspecified error. So let's remove this check, and instead make sure that we consider this as an empty texture. So let's not generate an error, there's non mandated in the spec in xoffset/yoffset/zoffset = 0 case. We already avoid doing any work in this case, because of the final, non-error generating check in this function. Fixes: b37b35a5d26 "getteximage: assume texture image is empty for non defined levels" Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]>
* mesa/main: remove ARB suffix from glGetnTexImageErik Faye-Lund2018-11-262-5/+5
| | | | | | | | | This function has been core since OpenGL 4.3, so naming the implementation and reporting erros using an ARB-suffix can be confusing. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Juan A. Suarez <[email protected]>
* mesa/main: remove overly strict query-validationErik Faye-Lund2018-11-231-14/+0
| | | | | | | | | The rules encoded in this code also applies to OpenGL ES 3.0 and up, but the per-enum validation has already been taught about these rules. So let's get rid of this duplicate, narrow version of the validation. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa/main: fix validation of GL_TIMESTAMPErik Faye-Lund2018-11-231-1/+2
| | | | | | | | | | | | | | | | ctx->Extensions.ARB_timer_query is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_ARB_timer_query(ctx) instead to figure out if the extension is really supported. We also need to check for EXT_disjoint_timer_query for GLES-support. This shouln't have any functional effect, as this entry-point is only valid on desktop GL, or on GLES with EXT_disjoint_timer_query in the first place. But if this gets added to the core of a future version of ES, this should be a step in the right direction. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa/main: fix validation of ARB_query_buffer_objectErik Faye-Lund2018-11-231-2/+2
| | | | | | | | | | | | | ctx->Extensions.ARB_query_buffer_object is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_ARB_query_buffer_object(ctx) instead to figure out if the extension is really supported. This turns attempts to read queries into buffer objects on ES 3 into errors, as required by the spec. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa/main: fix validation of transform-feedback overflow queriesErik Faye-Lund2018-11-231-2/+2
| | | | | | | | | | | | | | ctx->Extensions.ARB_transform_feedback_overflow_query is set based on the driver-capabilities, not based on the context type. We need to check against _mesa_has_RB_transform_feedback_overflow_query(ctx) instead to figure out if the extension is really supported. This turns usage of GL_TRANSFORM_FEEDBACK_STREAM_OVERFLOW and GL_TRANSFORM_FEEDBACK_OVERFLOW into errors on ES 3, as required by the spec. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa/main: fix validation of transform-feedback queriesErik Faye-Lund2018-11-231-2/+3
| | | | | | | | | | | | | | | ctx->Extensions.EXT_transform_feedback is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_EXT_transform_feedback(ctx) instead to figure out if the extension is really supported. We also need to check for OES_geometry_shader. This turns usage of GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN into an error on ES 2, as well as usage of GL_PRIMITIVES_GENERATED on ES 3, both as required by the spec. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa/main: fix validation of GL_TIME_ELAPSEDErik Faye-Lund2018-11-231-1/+2
| | | | | | | | | | | | | | ctx->Extensions.EXT_timer_query is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_EXT_timer_query(ctx) instead to figure out if the extension is really supported. We also need to check for EXT_disjoint_timer_query, which enables the same functionality for ES. This turns usage of GL_TIME_ELAPSED into an error on ES 3, as is required by the spec. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa/main: fix validation of GL_ANY_SAMPLES_PASSED_CONSERVATIVEErik Faye-Lund2018-11-231-2/+2
| | | | | | | | | | | | | | | | | ctx->Extensions.ARB_ES3_compatibility is set based on the driver- capabilities, not based on the context type. We need to check against _mesa_has_ARB_ES3_compatibility(ctx) instead to figure out if the extension is really supported. In addition, EXT_occlusion_query_boolean should also allow this behavior. This shouldn't cause any functional change, as all drivers that support ES3_compatibility should in practice enable either ES3_compatibility or EXT_occlusion_query_boolean under all APIs that export this symbol. Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 19:48:58 +0000