When MSAA is enabled smoothing is ignored
v2: As pointed out by Roland I got this completely wrong,
fix this to work the other way
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4122>
This just adds the sample values for 4xmsaa, and hooks them
up to the get_sample_position API
v2: move to vulkan standard sample positions
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4122>
There is a race with u_blitter shaders + pipeline shaders (aaline/aapoint)
where the draw bind can cause a pipeline flush which can use bind_fs_state to
be reenters and llvmpipe->fs gets the wrong value. Fix this by only
setting the llvmpipe->fs value after the draw binding is complete.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4122>
This adds a sample stride field and allocates enough memory for
each sample storage. Hook up the sample_stride field to draw
and jit textures and images
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4122>
This adds a new callback to get the stride between the per-sample
images, adds a new value for the per-sample index to lookup,
and a flag to use multisampling.
gallivm/sample: add num samples interface for dynamic samplers
This will be used for getting number of samples in jit code.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4122>
robclark noted that the blob wasn't doing range reduction in the mediump
case, and I confirmed it on
dEQP-GLES3.functional.shaders.operator.angle_and_trigonometry.sin.mediump_float_fragment
vs
dEQP-GLES3.functional.shaders.operator.angle_and_trigonometry.sin.highp_float_fragment.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4893>
Currently nine_convert_blend_state has no way
of knowing the number of rts.
For now set to an upper bound.
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4891>
Move the relevant code from si_init_depth_surface to
si_emit_framebuffer_state, so that it can be changed after a pipe_surface
is initialized.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4866>
I wanna remove dependency on tc_compatible_htile from non-dynamic states.
This should be the same as 8_UINT if HTILE is disabled.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4866>
NIR already optimizes undef usage.
If undef reaches llvm, it's probably because of a broken shader.
In this situation, rather than letting llvm use the undef values
to do more optimization and probably produce incorrect results,
we replace undef values by 0.
"undef" values that are directly used in exports are kept as undef,
because this allows llvm to optimize them away.
This is only enabled for radeonsi.
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2689
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4607>
This commit introduces a new way to zero-init variables but keep the
old one to not break any existing behavior.
With this change GLSLZeroInit becomes an integer, with the following
possible values:
- 0: no 0 init
- 1: current behavior
- 2: new behavior. Similar to 1, except ir_var_function_out type are
0 initialized but ir_var_shader_out.
The rationale behind 2 is: zero initializing ir_var_shader_out can
prevent some optimization where out variables are completely eliminated
when not written to.
On the other hand, zero initializing "ir_var_function_out" has no
effect on correct shaders but typically helps shadertoy since the main
function is:
void mainImage(out vec4 fragColor) { ... }
So with this change we're sure that fragColor will always get a value.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4607>
Shared globals and glsl_zero_init can cause linker errors if the
variable is only initialized in 1 place.
This commit adds a flag to variables that have been implicitely
initialized to be able in this situation to keep the explicit
initialization value.
Without this change the global-single-initializer-2-shaders piglit
test fails when using glsl_zero_init.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4607>
This commit makes zero_init a bitfield of types of variables to zeroinit.
This will allow some flexibility that will be used in the next commit.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4607>
The Vulkan spec says:
"shaderInt16 specifies whether 16-bit integers (signed and unsigned)
are supported in shader code. If this feature is not enabled, 16-bit
integer types must not be used in shader code."
I think it's just safe to enable it because 16-bit integers should
be fully supported with LLVM and also with ACO and GFX8+. On GFX8
and earlier generations, throughput of 16-bit int is same as 32-bit
but that should't change anything.
For GFX6-GFX7 ACO support, we have to implement conversions without
SDWA.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4874>
Instead of open-coding uniform -> UBO lowering, let's instead use the
one that already exists. This should make things a bit simpler going
forward.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4734>
Zink needs to know the sizes of UBOs, and for normal UBOs we get this
from the nir_var_mem_ubo variables. This allows us to treat all of these
the same way.
We're about to need the same information for the in-progress D3D12
driver, so let's do this in a central location instead of in the driver.
This version is also a bit more careful than the Zink version. In
particular, for two reasons:
1. We increase the variable bindings when we adjust the pre-existing
UBOs.
2. We increase shader->info.num_ubos when we insert a new UBO variable.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4734>
Dave Airlie
Tomeu Vizoso
Rhys Perry
Eric Anholt
Axel Davy
Marek Olšák
Pierre-Eric Pelloux-Prayer
Samuel Pitoiset
Erik Faye-Lund
Louis-Francis Ratté-Boulianne