summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* i965: add P0x formats and propagate required scaling factorsTapani Pälli2019-02-123-0/+17
| | | | | | Signed-off-by: Tapani Pälli <[email protected]> Signed-off-by: Lin Johnson <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* intel/compiler: add scale_factors to sampler_prog_key_dataTapani Pälli2019-02-121-0/+1
| | | | | | | | Patch propagates given scale_factors to lowering options. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Use info->textures_used instead of prog->SamplersUsed.Kenneth Graunke2019-02-112-7/+7
| | | | | | | | | | prog->SamplersUsed is set by the linker when validating resource limits, while info->textures_used is gathered after NIR optimizations, which may have eliminated some unused surfaces. This may let us skip some work. Reviewed-by: Eric Anholt <[email protected]>
* i965: Drop unnecessary 'and' with prog->SamplerUnitsKenneth Graunke2019-02-111-1/+1
| | | | | | | textures_used_by_txf is a subset of textures_used which is a subset of prog->SamplerUnits. This should do nothing. Reviewed-by: Eric Anholt <[email protected]>
* nir: Gather texture bitmasks in gl_nir_lower_samplers_as_deref.Kenneth Graunke2019-02-114-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | Eric and I would like a bitmask of which samplers are used, similar to prog->SamplersUsed, but available in NIR. The linker uses SamplersUsed for resource limit checking, but later optimizations may eliminate more samplers. So instead of propagating it through, we gather a new one. While there, we also gather the existing textures_used_by_txf bitmask. Gathering these bitfields in nir_shader_gather_info is awkward at best. The main reason is that it introduces an ordering dependency between the two passes. If gathering runs before lower_samplers_as_deref, it can't look at var->data.binding. If the driver doesn't use the full lowering to texture_index/texture_array_size (like radeonsi), then the gathering can't use those fields. Gathering might be run early /and/ late, first to get varying info, and later to update it after variant lowering. At this point, should gathering work on pre-lowered or post-lowered code? Pre-lowered is also harder due to the presence of structure types. Just doing the gathering when we do the lowering alleviates these ordering problems. This fixes ordering issues in i965 and makes the txf info gathering work for radeonsi (though they don't use it). Reviewed-by: Eric Anholt <[email protected]>
* program: Make prog_to_nir create texture/sampler derefs.Kenneth Graunke2019-02-111-5/+16
| | | | | | | | | | | | | Until now, prog_to_nir has been setting texture_index and sampler_index directly. This is different than GLSL shaders, which create variable dereferences and rely on lowering passes to reach this final form. radeonsi uses variable dereferences for samplers rather than texture_index and sampler_index, so it doesn't even make sense to set them there. By moving to derefs, we ensure that both GLSL and ARB programs produce the same final form that the driver desires. Reviewed-by: Eric Anholt <[email protected]>
* st/nir: Use sampler derefs in built-in shaders.Kenneth Graunke2019-02-112-8/+24
| | | | Reviewed-by: Eric Anholt <[email protected]>
* st/nir: Lower sampler derefs for builtin shaders.Kenneth Graunke2019-02-111-0/+2
| | | | Reviewed-by: Eric Anholt <[email protected]>
* st/nir: Pull sampler lowering into a helper function.Kenneth Graunke2019-02-112-4/+14
| | | | | | This will make it easier to reuse across GLSL / ARB / built-ins. Reviewed-by: Eric Anholt <[email protected]>
* i965: Call nir_lower_samplers for ARB programs.Kenneth Graunke2019-02-111-0/+2
| | | | | | | | | An upcoming patch will start building derefs in prog_to_nir, at which point we'll need to lower them to indexes. This gets both GLSL and non-GLSL shaders using the same paths. Reviewed-by: Eric Anholt <[email protected]>
* st/mesa: Limit GL_MAX_[NATIVE_]PROGRAM_PARAMETERS_ARB to 2048Kenneth Graunke2019-02-111-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Piglit's vp-max-array test creates a vertex program containing a uniform array sized to the value of GL_MAX_NATIVE_PROGRAM_PARAMETERS_ARB. Mesa will then add additional state-var parameters for things like the MVP matrix. radeonsi currently exposes a value of 4096, derived from constant buffer upload size. This means the array will have 4096 elements, and the extra MVP state-vars would get a prog_src_register::Index of over 4096. Unfortunately, prog_src_register::Index is a signed 13-bit integer, so values beyond 4096 end up turning into negative numbers. Negative source indexes are only valid for relative addressing, so this ends up generating illegal IR. In prog_to_nir, this would cause an out of bounds array access. st_mesa_to_tgsi checks for a negative value, assumes it's bogus, and remaps it to parameter 0 in order to get something in-range. This isn't right - instead of reading the MVP matrix, it would read the first element of the vertex program's large array. But the test only checks that the program compiles, so we never noticed that it was broken. This patch limits the size of the program limits, with the understanding that we may need to generate additional state-vars internally. i965 has exposed 1024 for this limit for years, so I don't expect lowering it to 2048 will cause any practical problems for radeonsi or other drivers. Fixes vp-max-array with prog_to_nir.c. Cc: "19.0" <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: consider a 'base level' when calculating width0, height0, depth0Andrii Simiklit2019-02-071-1/+25
| | | | | | | | | | | I guess that when we calculating the width0, height0, depth0 to use for function 'intel_miptree_create' we need to consider the 'base level' like it is done in the 'intel_miptree_create_for_teximage' function. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107987 Signed-off-by: Andrii Simiklit <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/glsl_to_nir: call nir_remove_dead_variables() after lowing local indirectsTimothy Arceri2019-02-081-0/+7
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* util: move BITFIELD macros to util/macros.hTimothy Arceri2019-02-081-24/+0
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* st/mesa: require RGBA2, RGB4, and RGBA4 to be renderableKarol Herbst2019-02-071-0/+2
| | | | | | | | | | | | If the driver does not support rendering to these formats but does support texturing, we can end up in incompatibilities between textures and renderbuffers that are then copied to. Fixes KHR-GL45.copy_image.functional on nvc0 Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Cc: 19.0 <[email protected]>
* gallium: add PIPE_CAP_MAX_VARYINGSKarol Herbst2019-02-071-4/+1
| | | | | | | | | | | | | | | | | Some NVIDIA hardware can accept 128 fragment shader input components, but only have up to 124 varying-interpolated input components. We add a new cap to express this cleanly. For most drivers, this will have the same value as PIPE_SHADER_CAP_MAX_INPUTS for the fragment shader. Fixes KHR-GL45.limits.max_fragment_input_components Signed-off-by: Karol Herbst <[email protected]> [imirkin: rebased, improved docs/commit message] Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Rob Clark <[email protected]> Acked-by: Eric Anholt <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Cc: 19.0 <[email protected]>
* st/nir: Use src/ relative include path for autotoolsKristian H. Kristensen2019-02-052-2/+4
| | | | | | Fixes: cdc53fa81cbeb80373eac33ef7695d9025caf14b Acked-by: Kenneth Graunke <[email protected]> Signed-off-by: Kristian H. Kristensen <[email protected]>
* gallium: Add a PIPE_CAP_NIR_COMPACT_ARRAYS capability bit.Kenneth Graunke2019-02-051-2/+5
| | | | | | | | | Iris would like to use compact arrays for tesslevels and clip/cull distances. radeonsi will likely want to switch to these at some point, since it'll be necessary for GL_ARB_gl_spirv support, but it's not ready for them just yet. Reviewed-by: Timothy Arceri <[email protected]>
* st/nir: Call nir_lower_clip_cull_distance_arrays().Kenneth Graunke2019-02-051-0/+1
| | | | | | | | | | | | Today, st always sets LowerCombinedClipCullDistance, causing the GLSL IR lowering to run, giving us vec4[2] arrays. I would like to disable this and instead run the NIR lowering so that we get compact float[] arrays instead. Calling the new pass is a noop if the GLSL IR pass has already run, so it's safe to call the pass unconditionally. Reviewed-by: Timothy Arceri <[email protected]>
* program: Extend prog_to_nir handle system values.Kenneth Graunke2019-02-051-0/+30
| | | | | | | | | | | Some drivers, such as radeonsi, use a system value for gl_FragCoord rather than an input variable. In this case, our Mesa IR will have a PROGRAM_SYSTEM_VALUE register, which we need to translate. This makes prog_to_nir work for Gallium drivers which expose the PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL capability bit. Reviewed-by: Eric Anholt <[email protected]>
* program: Use u_bit_scan64 in prog_to_nir.Kenneth Graunke2019-02-051-7/+6
| | | | | | | We can simply iterate the bits rather than using util_last_bit and checking each one up until that point. Reviewed-by: Eric Anholt <[email protected]>
* st/mesa: Add NIR versions of the PBO upload/download shaders.Kenneth Graunke2019-02-051-2/+188
| | | | | | Acked-by: Marek Olšák <[email protected]> Tested-by: Rob Clark <[email protected]> Tested-by: Eric Anholt <[email protected]>
* st/mesa: Add a NIR version of the OES_draw_texture built-in shaders.Kenneth Graunke2019-02-051-7/+62
| | | | | | Reviewed-by: Marek Olšák <[email protected]> Tested-by: Rob Clark <[email protected]> Tested-by: Eric Anholt <[email protected]>
* st/mesa: Add NIR versions of the clear shaders.Kenneth Graunke2019-02-051-13/+67
| | | | | | | | | | | | We implement the basic VS and FS, as well as the VS that does layered clears by writing gl_Layer from the vertex shader. Drivers which need a geometry shader for writing layer continue falling back to TGSI, as I didn't need this and so didn't bother implementing it. (We certainly could, however, if people want to add it in the future.) Reviewed-by: Marek Olšák <[email protected]> Tested-by: Rob Clark <[email protected]> Tested-by: Eric Anholt <[email protected]>
* st/mesa: Add NIR versions of the drawpixels Z/stencil fragment shaders.Kenneth Graunke2019-02-051-21/+119
| | | | | | Reviewed-by: Marek Olšák <[email protected]> Tested-by: Rob Clark <[email protected]> Tested-by: Eric Anholt <[email protected]>
* st/mesa: Add a NIR version of the drawpixels/bitmap VS copy shader.Kenneth Graunke2019-02-051-8/+29
| | | | | | | | | This provides a native NIR version of the DrawPixels/Bitmap passthrough vertex shader. Reviewed-by: Marek Olšák <[email protected]> Tested-by: Rob Clark <[email protected]> Tested-by: Eric Anholt <[email protected]>
* st/nir: Make new helpers for constructing built-in NIR shaders.Kenneth Graunke2019-02-054-0/+155
| | | | | | | | | | | | | | | | | | | | | | | | | The state tracker generates several built-in shaders in order to perform scissored clears, upload/download PBOs, and so on. These are currently constructed using TGSI, using ureg and u_simple_shader. I want to have NIR versions of these shaders, for my Gallium driver that has a NIR backend but no TGSI support. To that end, we'll want a few helpers to help construct simple shaders. This patch adds two new helpers: - st_nir_finish_builtin_shader() takes a manually constructed NIR shader, applies lowering passes (like st_link_nir would do for GLSL), and constructs the pipe_shader_state. - st_nir_make_passthrough_shader() makes a simple passthrough shader, which copies inputs to outputs. This is similar to u_simple_shaders. v2: Set info->fs.untyped_color_outputs for vc4/v3d (thanks Eric!). Reviewed-by: Marek Olšák <[email protected]> Tested-by: Rob Clark <[email protected]> Tested-by: Eric Anholt <[email protected]>
* st/nir: Move varying setup code to a helper function.Kenneth Graunke2019-02-052-20/+29
| | | | | | | | I want to reuse this for built-in shaders. Reviewed-by: Marek Olšák <[email protected]> Tested-by: Rob Clark <[email protected]> Tested-by: Eric Anholt <[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]>
* i965: skip bit6 swizzle detection in Gen8+Caio Marcelo de Oliveira Filho2019-02-041-0/+14
| | | | | | | It is always false on Gen8+. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* st/mesa: Set pipe_image_view::shader_access in PBO readpixels.Kenneth Graunke2019-02-041-0/+1
| | | | | | | | | | | | Commit 8b626a22b24089edf90cb1b06e5b1895bb36c61b introduced a new pipe_image_view::shader_access field, indicating the access mode specified in the shader. st/mesa's built-in PBO download shader creates a write-only image buffer, so we should flag it as such. Nobody uses this field yet (Iris will), so we don't need to backport this fix to stable branches. Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: expose EXT_texture_compression_s3tc_srgbGurchetan Singh2019-02-011-0/+6
| | | | Reviewed-by: Erik Faye-Lund <[email protected]>
* i965: Set flag for EXT_texture_compression_s3tc_srgbGurchetan Singh2019-02-011-0/+1
| | | | Reviewed-by: Tapani Pälli <[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]>
* st/glsl_to_nir: remove dead local variablesTimothy Arceri2019-02-011-0/+3
| | | | | | | | | | | | | | Without this we do not end up with a deterministic NIR because temporary register variables are added in random order. NIR must be deterministic because we use it to produce a sha for the radeonsi backends disk cache. This fixes the shader cache for a bunch of shaders. Another positive is that this results in a large reduction in the size of the NIR that the state tracker stores to the disk cache. Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: Fix topogun-1.06-orc-84k-resize.trace crashNeha Bhende2019-01-311-0/+4
| | | | | | | | | | | | | We need to initialize all fields in rs->prim explicitly while creating new rastpos stage. Fixes: bac8534267 ("st/mesa: allow glDrawElements to work with GL_SELECT feedback") v2: Initializing all fields in rs->prim as per Ilia. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* android,autotools,i965: Fix location of float64_glsl.hDylan Baker2019-01-312-1/+3
| | | | | | | | | | | | Android.mk and autotools disagree about where generated files should go, which wasn't a problem until we wanted to build a dist tarball. This corrects the problem by changing the output and include paths to be the same on android and autotools (meson already has the correct include path). Fixes: 7d7b30835cfb9eb89beca9fb8593d0954f79b84d ("automake: Fix path to generated source") Reviewed-by: Tapani Pälli <[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/st: wire up DiscardFramebufferJonathan Marek2019-01-291-0/+25
| | | | | Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Eric Anholt <[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]>
* intel/defines: Explicitly cast to uint32_t in SET_FIELD and SET_BITSJason Ekstrand2019-01-291-1/+1
| | | | | | | | | If you pass a bool in as the value to set, the C standard says that it gets converted to an int prior to shifting. If you try to set a bool to bit 31, this lands you in undefined behavior. It's better just to add the explicit cast and let the compiler delete it for us. Reviewed-by: Iago Toral Quiroga <[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-285-5/+5
| | | | | | | | | | | | | | | | 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/st: rework support for sRGB framebuffer attachementsGert Wollny2019-01-284-18/+31
| | | | | | | | | | | | | | | | | | | | | For GLES sRGB framebuffer attachemnt support is provided in two steps: sRGB attachments like described in EXT_sRGB (and GLES 3.0) that enable linear to sRGB color space transformation automatically, and the ability to switch formats of the render target surface between sRGB and linear that introduces full support for EXT_framebuffer_sRGB. Set the according flags to reflect these two levels of sRGB support. As a difference between desktopm GL and GLES, on desktop GL for a sRGB framebuffer attachment the linear-sRGB conversion is turned off by default, and for GLES it is turned on. This needs to be taken into account when initally creating a surface, i.e. on desktop GL creation of a sRGB surface is preferred, but on GLES sRGB surfaces are only created when explicitely requested. v2: - Use the new CAPS name Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965: Set flag for EXT_sRGBGert Wollny2019-01-281-0/+1
| | | | | | Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: <Gurchetan Singh [email protected]> Reviewed-by: Tapani Pälli <[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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 22:40:15 +0000