summaryrefslogtreecommitdiffstats
path: root/src/mesa/main
Commit message (Collapse)AuthorAgeFilesLines
* nir, glsl: move pixel_center_integer/origin_upper_left to shader_info.fsAlejandro Piñeiro2019-02-211-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On GLSL that info is set as a layout qualifier when redeclaring gl_FragCoord, so somehow tied to a specific variable. But in practice, they behave as a global of the shader. On ARB programs they are set using a global OPTION (defined at ARB_fragment_coord_conventions), and on SPIR-V using ExecutionModes, that are also not tied specifically to the builtin. This patch moves that info from nir variable and ir variable to nir shader and gl_program shader_info respectively, so the map is more similar to SPIR-V, and ARB programs, instead of more similar to GLSL. FWIW, shader_info.fs already had pixel_center_integer, so this change also removes some redundancy. Also, as struct gl_program also includes a shader_info, we removed gl_program::OriginUpperLeft and PixelCenterInteger, as it would be superfluous. This change was needed because recently spirv_to_nir changed the order in which execution modes and variables are handled, so the variables didn't get the correct values. Now the info is set on the shader itself, and we don't need to go back to the builtin variable to set it. Fixes: e68871f6a ("spirv: Handle constants and types before execution modes") v2: (Jason) * glsl_to_nir: get the info before glsl_to_nir, while all the rest of the info gathering is happening * prog_to_nir: gather the info on a general info-gathering pass, not on variable setup. v3: (Jason) * Squash with the patch that removes that info from ir variable * anv: assert that OriginUpperLeft is true. It should be already set by spirv_to_nir. * blorp: set origin_upper_left on its core "compile fragment shader", not just on some specific places (for this we added an helper on a previous patch). * prog_to_nir: no need to gather specifically this fragcoord modes as the full gl_program shader_info is copied. * spirv_to_nir: assert that we are a fragment shader when handling this execution modes. v4: (reported by failing gitlab pipeline #18750) * state_tracker: update too due changes on ir.h/gl_program v5: * blorp: minor change after change on previous patch * radeonsi: update due this change. v6: (Timothy Arceri) * prog_to_nir: remove extra whitespace * shader_info: don't use :1 on origin_upper_left * glsl: program.fs.origin_upper_left/pixel_center_integer can be move out of the shader list loop
* mesa: add explicit enable for EXT_float_blend, and error conditionIlia Mirkin2019-02-184-1/+26
| | | | | | | | | If EXT_float_blend is not supported, error out on blending of FP32 attachments in an ES2 context. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: return NULL if we exceed MaxColorAttachments in get_fb_attachmentTapani Pälli2019-02-181-2/+6
| | | | | | | | | | | | | | | This fixes invalid access to Attachment array which would occur if caller would exceed MaxColorAttachments. In practice this should not ever happen because DiscardFramebufferEXT specifies only GL_COLOR_ATTACHMENT0 to be valid and InvalidateFramebuffer will error out before but this should make coverity happy. v2: const, remove _EXT (Ian) CID: 1442559 Fixes: 0c42b5f3cb9 "mesa: wire up InvalidateFramebuffer" Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: INVALID_VALUE for wrong type or format in Clear*Buffer*DataAndres Gomez2019-02-151-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | Instead of generating a GL_INVALID_ENUM error when the type or format is incorrect while using glClear{Named}Buffer{Sub}Data, generate GL_INVALID_VALUE. From page 72 (page 94 of the PDF) of the OpenGL 4.6 spec: " An INVALID_VALUE error is generated if type is not one of the types in table 8.2. An INVALID_VALUE error is generated if format is not one of the formats in table 8.3." Fixes the following test: KHR-GL45.direct_state_access.buffers_errors v2: correct the doxygen documentation. Cc: Pi Tabred <[email protected]> Cc: Brian Paul <[email protected]> Signed-off-by: Andres Gomez <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa: Advertise EXT_float_blend in ES 3.0+ contexts.Kenneth Graunke2019-02-121-0/+1
| | | | | | | | | | | | | | | | | | | | This extension simply drops a draw time restriction: "Furthermore, an INVALID_OPERATION error is generated by DrawArrays and the other drawing commands defined in section 2.8.3 (10.5 in ES 3.1) if blending is enabled (see below) and any draw buffer has 32-bit floating-point format components." We never correctly enforced this restriction anyway, so we were basically already implementing it. We just need to advertise it for our behavior to be correct. The extension requires EXT_color_buffer_float, but we already enable that via dummy_true. So we can dummy_true this one as well. Found while debugging WebGL conformance tests. Does not fix any. Reviewed-by: Tapani Pälli <[email protected]>
* util: move BITFIELD macros to util/macros.hTimothy Arceri2019-02-081-24/+0
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: release references to image textures when a context is destroyedGert Wollny2019-02-053-0/+15
| | | | | | | | | | | | | When a texture is still bound as an image and the context it was bound in is destroyed but not the texture, then the texture will still hold the resource and will not be freed when it is finally destroyed. Hence, release these references when the context is destroyed. This leak was triggered by virglrenderer: https://gitlab.freedesktop.org/virgl/virglrenderer/issues/86 Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: Expose EXT_texture_compression_s3tc_srgbGurchetan Singh2019-02-013-1/+4
| | | | | | | | | | Required for the following test: bin/compressedteximage GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT pass when emulating GL on GLES. Reviewed-by: Erik Faye-Lund <[email protected]>
* mesa: Skip partial InvalidateFramebuffer of packed depth/stencil.Eric Anholt2019-01-311-0/+23
| | | | | | | | | One of the CTS cases tries to invalidate just stencil of packed depth/stencil, and we incorrectly lost the depth contents. Fixes dEQP-GLES3.functional.fbo.invalidate.whole.unbind_read_stencil Fixes: 0c42b5f3cb90 ("mesa: wire up InvalidateFramebuffer") Reviewed-by: Marek Olšák <[email protected]>
* mesa/core: Enable EXT_texture_sRGB_R8 also for desktop GLGert Wollny2019-01-302-1/+2
| | | | | | | | As of Nov/30/2018 the extension is also valid for OpenGL >= 1.2, so enable it accordingly and also add the required view class entry. Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: expose NV_conditional_render on GLESErik Faye-Lund2019-01-302-1/+5
| | | | | | | | | | | The extension spec has been updated to include GLES 2 support, so let's enable it there. v2: fixup ABI-check as well Signed-off-by: Erik Faye-Lund <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* mesa: wire up InvalidateFramebufferRob Clark2019-01-292-7/+66
| | | | | | | | | | And before someone actually starts implementing DiscardFramebuffer() lets rework the interface to something that is actually usable. Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa/main: Expose EXT_sRGB_write_controlGert Wollny2019-01-283-5/+4
| | | | | | | | | | | | | | | Use EXT_framebuffer_sRGB to expose EXT_sRGB_write_control on GLES. Remove the checks for desktion GL in the enable calls, since EXT_framebuffer_sRGB now also indicates support for switching the linear-sRGB color space conversion on GLES. Thanks to Ilia Mirkin for all the helpful discussions that helped to rework this series. v2: Fix alphabetical listing of extensions (Tapani Pälli) Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]> (v1)
* mesa/main/version: Lower the requirements for GLES 3.0Gert Wollny2019-01-281-2/+2
| | | | | | | | | | | GLES 3.0 does not actually require support for EXT_framebuffer_sRGB, it only needs support for sRGB attachments to framebuffers and framebuffer objects as defined in ARB_framebuffer_objects. v2: Clarify that ARB_framebuffer_objects is needed. Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: Use flag for EXT_sRGB instead of EXT_framebuffer_sRGB where possibleGert Wollny2019-01-284-4/+4
| | | | | | | | | | | | | | | | All drivers that support EXT_framebuffer_sRGB also support EXT_sRGB, but in order to keep this commit minial, and not to break any drivers both flags are checked. v2: - Use only EXT_sRGB (Ilia Mirkin) - Move adding the flag EXT_sRGB to gl_extensions to a separate patch v3: use _mesa_has_EXT_framebuffer_sRGB instead of extension flag The _mesa_has function also checks for the correct versions and should be preferred over using the flags directly (Erik) Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa:main: Add flag for EXT_sRGB to gl_extensionsGert Wollny2019-01-281-0/+1
| | | | | | | | | | | | | EXT_sRGB is an (incomplete) GLES extension that provides support for sRGB framebuffer attachments, hence it can be used to check for this support as an alternative to EXT_framebuffer_sRGB that provies the same functionality but also sRGB write control support. However, since EXT_sRGB is incomplete and superseted by GLES 3.0 it will not be exposed as an extension. Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* Revert "mesa/main: remove ARB suffix from glGetnTexImage"Emil Velikov2019-01-242-5/+5
| | | | | | | | | | | | | This reverts commit f1998e15ffccf260552bf559abe1a733a8ce990e. This changes the ABI, such that glGetnTexImageARB entry-point from the GLAPI gets removed. Thus accessing many functions by offset (as we do) will result in getting the wrong one. Follow-up work will swap the by-offset handling, but for now revert this patch. Acked-by: Erik Faye-Lund <[email protected]>
* mesa: correctly use os.path.join in our python scriptsEmil Velikov2019-01-241-4/+3
| | | | | | | | | | | | With Windows in mind, using forward slash isn't the right thing to do. Even if it just works, we might want to fix it. As here, use __file__ instead of argv[0] and sys.path.insert over sys.path.append. With the path tweak being reportedly faster. Suggested-by: Dylan Baker <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Erik Faye-Lund <[email protected]>
* mesa: add MESA_SHADER_KERNELKarol Herbst2019-01-211-0/+4
| | | | | | | | used for CL kernels Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir: rename nir_var_function to nir_var_function_tempKarol Herbst2019-01-191-1/+1
| | | | | | | | Signed-off-by: Karol Herbst <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* glsl: don't skip GLSL IR opts on first-time compilesTimothy Arceri2019-01-191-2/+1
| | | | | | | | | | | | | | This basically reverts c2bc0aa7b188. By running the opts we reduce memory using in Team Fortress 2 from 1.5GB -> 1.3GB from start-up to game menu. This will likely increase Deus Ex start up times as per commit c2bc0aa7b188. However currently 32bit games like Team Fortress 2 can run out of memory on low memory systems, so that seems more important. Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: Optionally override RGB/RGBX dst alpha blend factorsKenneth Graunke2019-01-152-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intel's blending hardware does not properly return 1.0 for destination alpha for RGBX formats; it requires the factors to be overridden to either zero or one. Broadcom vc4 and v3d also could use this override. While overriding these factors is safe in general, Nouveau and Radeon would prefer not to. Their blending hardware already returns correct values for RGB/RGBX formats, and would like to avoid the resulting per-buffer blending and independent blend factors (rgb != a) since it can cause additional overhead. I considered simply handling this in the driver, but it's not as nice. pipe_blend_state doesn't have any format information, so we'd need the hardware blend state to depend on both pipe_blend_state and pipe_framebuffer_state. Furthermore, Intel GPUs don't have a native RGBX_SNORM format, so I avoid exposing one, which makes Gallium fall back to RGBA_SNORM. The pipe_surfaces we get in the driver have an RGBA format, making it impossible to tell that there shouldn't be an alpha channel. One could argue that st not handling it in that case is a bug. To work around this, we'd have to expose RGBX pipe formats, mapped to RGBA hardware formats, and add format swizzling special cases. All doable, but it ends up being more code than I'd like. st_atom_blend already has access to the right information and it's trivial to accomplish there, so we just add a cap bit and do that. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* nir: rename global/local to private/function memoryKarol Herbst2019-01-081-1/+1
| | | | | | | | | | | | | | | | | | the naming is a bit confusing no matter how you look at it. Within SPIR-V "global" memory is memory accessible from all threads. glsl "global" memory normally refers to shader thread private memory declared at global scope. As we already use "shared" for memory shared across all thrads of a work group the solution where everybody could be happy with is to rename "global" to "private" and use "global" later for memory usually stored within system accessible memory (be it VRAM or system RAM if keeping SVM in mind). glsl "local" memory is memory only accessible within a function, while SPIR-V "local" memory is memory accessible within the same workgroup. v2: rename local to function as well v3: rename vtn_variable_mode_local as well Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Add support for using derefs for UBO/SSBO accessJason Ekstrand2019-01-081-0/+1
| | | | | | | | | For now, it's hidden behind a cap. Hopefully, we can eventually drop that along with all the manual offset code in spirv_to_nir. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Tested-by: Bas Nieuwenhuizen <[email protected]>
* nir: Move propagation of cast derefs to a new nir_opt_deref passJason Ekstrand2019-01-081-1/+1
| | | | | | | | | We're going to want to do more deref optimizations going forward and this gives us a central place to do them. Also, cast propagation will get a bit more complicated with the addition of ptr_as_array derefs. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* glapi: fixup EXT_multisampled_render_to_texture dispatchKristian H. Kristensen2018-12-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | There's a few missing and convoluted bits: - FramebufferTexture2DMultisampleEXT Missing sanity check, should be desktop="false" - RenderbufferStorageMultisampleEXT Missing sanity check, is aliased to RenderbufferStorageMultisample. Thus it's set only when desktop GL or GLES2 v3.0+, while the extension is GLES2 2.0+. If we flip the aliasing we'll break indirect GLX, so loosen the version to 2.0. Not perfect, yet this is the most sane thing I could think of. v2: [Emil] Fixup RenderbufferStorageMultisampleEXT, commmit message Cc: Kristian H. Kristensen <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108974 Fixes: 1b331ae505e ("mesa: Add core support for EXT_multisampled_render_to_texture{,2}") Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* mesa: Add core support for EXT_multisampled_render_to_texture{,2}Kristian H. Kristensen2018-12-065-15/+57
| | | | | | | | | This also turns on EXT_multisampled_render_to_texture which is a subset of EXT_multisampled_render_to_texture2, allowing only COLOR_ATTACHMENT0. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kristian H. Kristensen <[email protected]>
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 17:10:35 +0000