summaryrefslogtreecommitdiffstats
path: root/src/mesa/main
Commit message (Collapse)AuthorAgeFilesLines
* 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]> (cherry picked from commit db2ae51121067b66d4ee8313ba7f74cecb201a03)
* 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]>
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 12:32:02 +0000