As a side effect, we can delete the whole control flow stack thing.
v2 (Jason Ekstrand):
- Drop the ttn_if helper and just inline it in the two uses
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6866>
vl_mpeg12_decoder needs to override the chroma_format value to get the
correct size calculated (chroma_format is used by vl_video_buffer_adjust_size).
I'm not sure why it's needed, but this is needed to get correct mpeg decode.
Fixes: 24f2b0a856 ("gallium/video: remove pipe_video_buffer.chroma_format")
Acked-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6817>
Set up texture coordinates for the stencil-fallback blit code. This
worked in the orignal NIR code, but accidentally broke when rewriting to
use TGSI, and my test-case had a constant colored stencil buffer.
Fixes: e8a40715a8 ("gallium/util: add blitter-support for stencil-fallback")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6898>
This should have been the destination surface size, not the dimensions
of the source box. These were the same in the test-case I used while
developing this, but this matters for the GTF framebuffer-blit
functional CTS tests.
Fixes: e8a40715a8 ("gallium/util: add blitter-support for stencil-fallback")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6898>
This gives me one place to document why it works this way. This does make
the debug message a little less helpful ("etna" instead of "etnaviv" and
"vmwgfx" instead of "svga", but you should only be able to reach this when
doing something like trying the radeon/nouveau vdpau target on the wrong
DRM device for example.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6751>
This wires up the shader in the previous commit so we can blit without
having to reimplement the blitter in the D3D12 driver.
This isn't optimal, but it's reasonable enough, and this behavior is
rare.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6681>
This shader is useful to replicate single bit from a stencil buffer even
when there's no support for PIPE_CAP_SHADER_STENCIL_EXPORT.
This is useful for the D3D12 driver, where the graphics pipeline is the
only way of writing to MSAA stencil-buffers, and not all drivers support
exporting the stencil-value from the shader.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6681>
This makes it explicit that this intrinsic is only for SSBOs. For the
v3dv driver, we'll be adding a get_ubo_size intrinsic and we want to be
able to distinguish between the two.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6812>
Issue: While running the tast for odd resolutions there are green lines
observed in the dumped image. The resolution is 321x241, the extra 1 pixel
data is missing in the image. The reason for this is in the post
processing when we adjust the size of height and width we are
dividing it by 2.
Fix: To resolve this issue we first need to align it to 2 and then divide
by 2 to get the required values. Once we do this we will have proper data
in the dumped image and missing pixel data will be available.
Signed-off-by: Krunal Patel <krunalkumarmukeshkumar.patel@amd.corp-partner.google.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6795>
For UBO accesses to be the same performance as classic GL default uniform
block uniforms, we need to be able to push them through the same path. On
freedreno, we haven't been uploading UBOs as push constants when they're
used for indirect array access, because we don't know what range of the
UBO is needed for an access.
I believe we won't be able to calculate the range in general in spirv
given casts that can happen, so we define a [0, ~0] range to be "We don't
know anything". We use that at the moment for all UBO loads except for
nir_lower_uniforms_to_ubo, where we now avoid losing the range information
that default uniform block loads come with.
In a departure from other NIR intrinsics with a "base", I didn't make the
base an be something you have to add to the src[1] offset. This keeps us
from needing to modify all drivers (particularly since the base+offset
thing can mean needing to do addition in the backend), makes backend
tracking of ranges easy, and makes the range calculations in
load_store_vectorizer reasonable. However, this could definitely cause
some confusion for people used to the normal NIR base.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6359>
Some drivers can't use float-samplers to read integer textures, so let's
make sure the stenicil-sampler has the right type.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6512>
We can get duplicate declarations for an index (for example dvec3 + float
packed into 2 vec4s, the second one won't pack into the first's array
decl), and we'd end up stepping by the wrong amount in GS vtx/prim emit.
Fixes vs-gs-fs-double, sso-vs-gs-fs-array-interleave piglit tests.
Fixes: 49155c3264 ("draw/tgsi: fix geometry shader input/output swizzling")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6567>
If supported this means that src_x/src_y/width/height parameters of
CopyTex functions will not be clipped using the read framebuffer's dimensions.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6259>
GLSL lowers packhalf2x16 itself, but for SPIRV we don't have that
option.
For packing when NIR lowers it uses f2f16
and for unpack it needs the casting and f2f32
Fixes:
dEQP-VK.glsl.builtin.function.pack_unpack.packhalf2x16*
dEQP-VK.glsl.builtin.function.pack_unpack.unpackhalf2x16*
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6381>