aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/state_tracker
Commit message (Collapse)AuthorAgeFilesLines
* nir: Gather texture bitmasks in gl_nir_lower_samplers_as_deref.Kenneth Graunke2019-02-113-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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]>
* 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]>
* 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]>
* st/glsl_to_nir: call nir_remove_dead_variables() after lowing local indirectsTimothy Arceri2019-02-081-0/+7
| | | | 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]>
* 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-052-0/+153
| | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* 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]>
* 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]>
* mesa/st: wire up DiscardFramebufferJonathan Marek2019-01-291-0/+25
| | | | | Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa/main: Use flag for EXT_sRGB instead of EXT_framebuffer_sRGB where possibleGert Wollny2019-01-281-1/+1
| | | | | | | | | | | | | | | | 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]>
* st/mesa: fix PRIMITIVES_GENERATED query after the "pipeline stat single" changesMarek Olšák2019-01-231-1/+2
| | | | | | | | | | | | When this functionality was added, the PRIMITIVES_GENERATED query was accidentally omitted. This causes issues for drivers that support transform feedback." Fixes: d644698b443 ("gallium: Add the ability to query a single pipeline statistics counter") Reviewed-by: Erik Faye-Lund <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: purge framebuffers when unbinding a contextMarek Olšák2019-01-231-0/+5
| | | | | | | This fixes pipe_surface "leaks". Cc: 18.3 <[email protected]> Acked-by: Timothy Arceri <[email protected]>
* gallium: Add PIPE_CAP_GLSL_TESS_LEVELS_AS_INPUTSCaio Marcelo de Oliveira Filho2019-01-231-0/+2
| | | | | | | | | | | | In the Intel backend, it makes the most sense to treat gl_TessLevelInner and gl_TessLevelOuter as ordinary shader inputs. For Radeon, it makes more sense to treat them as system values which get special handling. We already have a compiler option for this, but the Iris driver will need a capability bit so we can set it appropriately. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* nir: rename nir_var_ssbo to nir_var_mem_ssboKarol 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]>
* nir: rename nir_var_ubo to nir_var_mem_uboKarol 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]>
* 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]>
* nir: rename nir_var_private to nir_var_shader_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]>
* st/mesa: Optionally override RGB/RGBX dst alpha blend factorsKenneth Graunke2019-01-153-2/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* gallium: Add the ability to query a single pipeline statistics counterKenneth Graunke2019-01-154-2/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gallium historically has treated pipeline statistics queries as a single query, PIPE_QUERY_PIPELINE_STATISTICS, which returns a block of 11 values. This was originally patterned after the D3D1x API. Much later, Brian introduced an OpenGL extension that exposed these counters - but it exposes 11 separate queries, each of which returns a single value. Today, st/mesa simply queries all 11 values, and returns a single value. While pipeline statistics counters aren't typically performance critical, this is still not a great fit. A D3D1x->GL translator might request all 11 counters by creating 11 separate GL queries...which Gallium would map to reads of all 11 values each time, resulting in a total 121 counter reads. That's not ideal. This patch adds a new cap, PIPE_CAP_QUERY_PIPELINE_STATISTICS_SINGLE, and corresponding query type PIPE_QUERY_PIPELINE_STATISTICS_SINGLE. When calling create_query(), q->index should be set to one of the PIPE_STAT_QUERY_* enums to select a counter. Unlike the block query, this returns the value in pipe_query_result::u64 (as it's a single value) instead of the pipe_query_data_pipeline_statistics group. We update st/mesa to expose ARB_pipeline_statistics_query if either capability is set, preferring the new SINGLE variant when available. Thanks to Roland, Ilia, and Marek for helping me sort this out. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* st/mesa: Rearrange PIPE_QUERY_PIPELINE_STATISTICS result fetching.Kenneth Graunke2019-01-151-43/+45
| | | | | | | | | | | This just changes the order of the switch statements, so we only look at target if the query type is PIPE_QUERY_PIPELINE_STATISTICS. The next commit will introduce a new SINGLE query type which can be used for the same GL query types, and it won't want this processing. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* st/mesa: Make an enum for pipeline statistics query result indices.Kenneth Graunke2019-01-151-11/+11
| | | | | | | | | | | | Gallium handles pipeline statistics queries as a single query (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values. Sometimes it's useful to refer to each of those values individually, rather than as a group. To avoid hardcoding numbers, we define a new enum for each value. Here, the name and enum value correspond to the index in the struct pipe_query_data_pipeline_statistics result. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* st/nir: Lower TES gl_PatchVerticesIn to a constant if linked with a TCS.Kenneth Graunke2019-01-111-0/+23
| | | | | | | | If the TCS and TES are linked together, we can simply replace the TES's gl_PatchVerticesIn system value with a constant, possibly allowing extra optimization or letting the driver avoid uploading a special value. Reviewed-by: Timothy Arceri <[email protected]>
* st/mesa: don't leak pipe_surface if pipe_context is not currentMarek Olšák2019-01-091-1/+4
| | | | | | | | | | We have found some pipe_surface leaks internally. This is the same code as surface_destroy in radeonsi. Ideally, surface_destroy would be in pipe_screen. Cc: 18.3 <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* st/mesa: don't reference pipe_surface locally in PBO codeMarek Olšák2019-01-091-3/+1
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/mesa: unify window-system renderbuffer initializationMarek Olšák2019-01-093-21/+28
| | | | Reviewed-by: Brian Paul <[email protected]>
* nir: rename global/local to private/function memoryKarol Herbst2019-01-081-2/+2
| | | | | | | | | | | | | | | | | | 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]>
* nir: Distinguish between normal uniforms and UBOsJason Ekstrand2019-01-081-2/+1
| | | | | | | | | | | | | | | | Previously, NIR had a single nir_var_uniform mode used for atomic counters, UBOs, samplers, images, and normal uniforms. This commit splits this into nir_var_uniform and nir_var_ubo where nir_var_uniform is still a bit of a catch-all but the nir_var_ubo is specific to UBOs. While we're at it, we also rename shader_storage to ssbo to follow the convention. We need this so that we can distinguish between normal uniforms and UBO access at the deref level without going all the way back variable and seeing if it has an interface type. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* st/glsl: refactor st_link_nir()Timothy Arceri2019-01-071-36/+16
| | | | | | | | | | | | | | | | | | The functional change here is moving the nir_lower_io_to_scalar_early() calls inside st_nir_link_shaders() and moving the st_nir_opts() call after the call to nir_lower_io_arrays_to_elements(). This fixes a bug with the following piglit test due to the current code not cleaning up dead code after we lower arrays. This was causing an assert in the new duplicate varyings link time opt introduced in 70be9afccb23. tests/spec/glsl-1.10/execution/vsfs-unused-array-member.shader_test Moving the nir_lower_io_to_scalar_early() calls also allows us to tidy up the code a little and merge some loops. Reviewed-by: Eric Anholt <[email protected]>
* nir: rename nir_link_constant_varyings() nir_link_opt_varyings()Timothy Arceri2019-01-021-1/+1
| | | | | | | | | | The following patches will add support for an additional optimisation so this function will no longer just optimise varying constants. Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* st/glsl_to_nir: call nir_lower_load_const_to_scalar() in the stTimothy Arceri2019-01-021-1/+3
| | | | | | | | | This will help the new opt introduced in the following patches allowing us to remove extra duplicate varyings. Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* st/mesa: expose GL_NV_shader_atomic_float when ATOMFADD is supportedIlia Mirkin2018-12-261-0/+1
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: select ATOMFADD when source type is floatIlia Mirkin2018-12-262-0/+3
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: allow glDrawElements to work with GL_SELECT feedbackIlia Mirkin2018-12-262-23/+42
| | | | | | | | | | | Not sure if this ever worked, but the current logic for setting the min/max index is definitely wrong for indexed draws. While we're at it, bring in all the usual logic from the non-indirect drawing path. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109086 Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* st/nir: Drop unused gl_program parameter in VS input handling helper.Kenneth Graunke2018-12-211-2/+2
| | | | | | | Nobody uses this, so let's drop it. This makes the helper callable from places without a gl_program. Reviewed-by: Marek Olšák <[email protected]>
* st/nir: Gather info after applying lowering FS variant featuresKenneth Graunke2018-12-211-0/+4
| | | | | | | | DrawPixels lowering, for example, adds new varyings that need to be accounted for in inputs_read. The earlier info gathering at link time cannot account for this. Reviewed-by: Marek Olšák <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-10 11:50:30 +0000