summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* nir/opt_peephole_select: Don't peephole_select expensive math instructionsIan Romanick2018-12-171-1/+1
| | | | | | | | | | | | | | | | On some GPUs, especially older Intel GPUs, some math instructions are very expensive. On those architectures, don't reduce flow control to a csel if one of the branches contains one of these expensive math instructions. This prevents a bunch of cycle count regressions on pre-Gen6 platforms with a later patch (intel/compiler: More peephole select for pre-Gen6). v2: Remove stray #if block. Noticed by Thomas. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Thomas Helland <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* nir/opt_peephole_select: Don't try to remove flow control around indirect loadsIan Romanick2018-12-171-1/+1
| | | | | | | | | | | | | | | | | | | That flow control may be trying to avoid invalid loads. On at least some platforms, those loads can also be expensive. No shader-db changes on any Intel platform (even with the later patch "intel/compiler: More peephole select"). v2: Add a 'indirect_load_ok' flag to nir_opt_peephole_select. Suggested by Rob. See also the big comment in src/intel/compiler/brw_nir.c. v3: Use nir_deref_instr_has_indirect instead of deref_has_indirect (from nir_lower_io_arrays_to_elements.c). v4: Fix inverted condition in brw_nir.c. Noticed by Lionel. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* st/nir: Use nir_src_as_uint for tokensJason Ekstrand2018-12-161-5/+1
| | | | Reviewed-by: Marek Olšák <[email protected]>
* i965/gen9: Add workarounds for object preemption.Rafael Antognolli2018-12-141-0/+63
| | | | | | | | | | | | | | | | | | | | | Gen9 hardware requires some workarounds to disable preemption depending on the type of primitive being emitted. We implement this by adding a function that checks the primitive type and number of instances right before the 3DPRIMITIVE. For now, we just ignore blorp. The only primitive it emits is 3DPRIM_RECTLIST, and since it's not listed in the workarounds, we can safely leave preemption enabled when it happens. Or it will be disabled by a previous 3DPRIMITIVE, which should be fine too. v3: - Apply missing workarounds for instanced rendering and line loop (Ken) - Move workaround code to brw_draw_single_prim() Signed-off-by: Rafael Antognolli <[email protected]> Cc: Kenneth Graunke <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen10+: Enable object level preemption.Rafael Antognolli2018-12-144-1/+36
| | | | | | | | | | | | Set bit when initializing context. v3: - Always toggle preemption bool to false before enabling it for the first time, so the state gets emitted (Chris Wilson). - Emit end of pipe sync with PIPE_CONTROL_RENDER_TARGET_FLUSH (Ken) Signed-off-by: Rafael Antognolli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* genxml: Consistently use a numeric "MOCS" fieldKenneth Graunke2018-12-141-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we first started using genxml, we decided to represent MOCS as an actual structure, and pack values. However, in many places, it was more convenient to use a numeric value rather than treating it as a struct, so we added secondary setters in a bunch of places as well. We were not entirely consistent, either. Some places only had one. Gen6 had both kinds of setters for STATE_BASE_ADDRESS, but newer gens only had the struct-based setters. The names were sometimes "Constant Buffer Object Control State" instead of "Memory", making it harder to find. Many had prefixes like "Vertex Buffer MOCS"...in a vertex buffer packet...which is a bit redundant. On modern hardware, MOCS is simply an index into a table, but we were still carrying around the structure with an "Index to MOCS Table" field, in addition to the direct numeric setters. This is clunky - we really just want a number on new hardware. This patch eliminates the struct-based setters, and makes the numeric setters be consistently called "MOCS". We leave the struct definition around on Gen7-8 for reference purposes, but it is unused. v2: Drop bonus "Depth Buffer MOCS" fields on Gen7.5 and Gen9 Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kristian H. Kristensen <[email protected]>
* mesa/st: Expose compute shaders when NIR support is advertised.Eric Anholt2018-12-131-7/+12
| | | | | | | | We have a NIR path, and V3D doesn't have TGSI input for compute (only what TTN can handle for the various gallium-internal shaders). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965/compute: Emit GPGPU_WALKER in genX_state_uploadJordan Justen2018-12-123-130/+105
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/genX_state: Add register access functionsJordan Justen2018-12-121-0/+31
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/st/nir: fix missing nir_compact_varyingsRob Clark2018-12-111-1/+2
| | | | | | | | | LinkedTransformFeedback is normally populated, which had nerf'd varying packing since the check was introduced. Fixes: dbd52585fa9 st/nir: Disable varying packing when doing transform feedback. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Timothy Arceri <[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]>
* i965: Flip arguments to load_register_reg helpers.Kenneth Graunke2018-12-095-9/+10
| | | | | | | | | load_register_imm and load_register_mem take the destination as the first argument, so I'd like load_register_reg to do the same the sake of consistency. Otherwise, reading sequences of mixed LRI/LRM/LRR is needlessly confusing. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Delete dead brw_meta_resolve_color prototype.Kenneth Graunke2018-12-091-7/+0
| | | | Dead since commit 09e041d61d367ff3a9e8492521606090050255d4 (May 2016).
* intel/blorp: Expand blorp_address::offset to be 64 bits.Kenneth Graunke2018-12-073-3/+3
| | | | | | | | | | | | | In the softpin world, surface state base address may be a fixed 64-bit address (with no associated BO). It makes sense to store this in the offset field. But it needs to be the full size. We also update the clear color address to be consistently uint64_t everywhere so we can continue passing intel_miptree_get_clear_color a pointer to the blorp_address's offset field without type mismatches. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* st/mesa: Add support for EXT_multisampled_render_to_textureKristian H. Kristensen2018-12-063-0/+5
| | | | | | | | | In gallium, we model the attachment sample count as a new nr_samples field in pipe_surface. A driver can indicate support for the extension using the new pipe cap, PIPE_CAP_MULTISAMPLED_RENDER_TO_TEXTURE. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kristian H. Kristensen <[email protected]>
* mesa: Add core support for EXT_multisampled_render_to_texture{,2}Kristian H. Kristensen2018-12-066-16/+58
| | | | | | | | | 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]>
* nir: Make boolean conversions sized just like the othersJason Ekstrand2018-12-051-2/+2
| | | | | | | | | Instead of a single i2b and b2i, we now have i2b32 and b2iN where N is one if 8, 16, 32, or 64. This leads to having a few more opcodes but now everything is consistent and booleans aren't a weird special case anymore. Reviewed-by: Connor Abbott <[email protected]>
* st/mesa: expose EXT_render_snorm on GLESMarek Olšák2018-12-041-0/+8
| | | | Reviewed-by: Ilia Mirkin <[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]>
* st/mesa: expose GL_OES_texture_viewMarek Olšák2018-12-041-0/+1
| | | | | | | | | | For format fallbacks like ETC and ASTC, switching between sRGB and linear decoding is undefined, or at least is not bit-exact. Same as EXT_texture_sRGB_decode on GLES. There are no piglit or dEQP regresssions. 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]>
* Revert "st/mesa: silenced unhanded enum warning in st_glsl_to_tgsi.cpp"Matt Turner2018-12-031-1/+0
| | | | | | | This reverts commit 198c50f4873758e9f64d89eea262af5dd1644df9. This needs to be reverted after commit 017199d2d2e4 ("mesa: Revert INTEL_fragment_shader_ordering support")
* mesa: Revert INTEL_fragment_shader_ordering supportMatt Turner2018-12-033-3/+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/st: do not probe for the same texture-formats twiceErik Faye-Lund2018-12-031-4/+4
| | | | | | | This should be equalent of what we did before. 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 08:30:17 +0000