Add process_frame to pipe_video codec
Add new structures/caps for video post-processing with rotation,
flip, alpha blending, crop, and scaling, via the video engine.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17557>
Rework:
* Ken: Check bo for IRIS_MMAP_NONE rather than the global
intel_vram_all_mappable
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17349>
This can be false on systems where the PCI Base Address Register (BAR)
is too small for the amount of VRAM. Eventually the kernel will be
able to tell us that a system can't map all of VRAM, and
`all_vram_mappable` will then be false.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17349>
We might not be able to map all vram buffers in the future, so only
map the buffer when actually required.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17349>
Allow folding constants/undef sources by sharing more code with the image_store
16bit folding pass.
Allow more than one set of sources because RADV wants two, one for
G16 (ddx/ddy) and one for A16 (all other sources).
Allow folding cube sampling destination conversions on radeonsi/radv because
I think the limitation only applies to sources.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16978>
the alternative here is to just spin aimlessly until the process ooms,
which causes problems when trying to detect failures in cts caselists
a separate env var is used so that it can be exported without affecting
ZINK_DEBUG
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17525>
It will get turned into SSA and copy-propagated in NIR, no need to walk
the IR collapsing it here.
iris shader-db results appear to be noise:
total instructions in shared programs: 8932195 -> 8932147 (<.01%)
instructions in affected programs: 537 -> 489 (-8.94%)
LOST: 12
GAINED: 11
lost/gained are simd32 switches in unigine, l4d2, portal2, asphalt9.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17613>
in some cases it becomes desirable to "maybe" stop and start the current
renderpass, such as when updates MAY result in layout changes for attachments
for such cases, avoid splitting the renderpass unless it actually needs to
be split
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17640>
this is more accurate and fixes usage with lavapipe
cc: mesa-stable
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17627>
in this case, lying about having multiple images and then returning the
same image every time doesn't work, so use the busy flag
and return an available image when possible
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17590>
the number of viewports in use is based on the outputs of the last vertex
stage, not the viewports passed by the state tracker
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17639>
this is a weird corner case where glsl permits a zero value, so clamp to 1
and then don't emit any vertices to avoid driver hangs
affects:
dEQP-GL45-ES31.functional.geometry_shading.emit.points_emit_0_end_0
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17639>
cached mode was great 2 years ago when template support was less widespread,
but now that templates are everywhere, caching is less performant in
every scenario
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17636>
zink_kopper_acquire_readback will flush any outstanding clears, this means that
the current clears need to be applied first before calling zink_kopper_acquire_readback.
This was already done for native_blit and native_resolve, also do this for the emulated draw path.
Seen as intermittent failures in cts case GTF-GL33.gtf21.GL2FixedTests.buffer_clear.buffer_clear.
Cc: mesa-stable
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17631>
Spirv spec does not allow the use of OpEmitVertex or OpEndPrimitive when there are multiple streams.
Instead emit the multi-stream version of these with stream set to 0.
This issue was seen when testing cts case KHR-GL46.transform_feedback.draw_xfb_stream_test
Fixes: 35e346f428 ("zink: handle vertex streams")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17513>
We can't do uniform buffer objects and from the hardware
perspective constants (uniforms) and immediates are treated in
the same way. They are uploaded together and fit together into the
(rather low) total constant limit. Therefore, there is actually no
advantage in converting immediates to uniforms, and a whole lot of
disadvantages (less possible optimizations and no inlining).
Fixes the dEQP regressions from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16770
The tests failed because when there is an indirect array access the
compiler inserts a big if ladder and converting the temp to a uniform
means more instructions because the ifs cant be lowered at least
partially to selects. It is particularly visible, because the code
NIR currently emits for the indirect access doesn't really fit the
hardware, see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6366
No change in my shader-db, so this concerns the tests only.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17576>
We're about to make it so that the compiler warns/errors if you use the
wrong iterator macro. Fix up a bunch of places where someone used the
wrong one before we break anything.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17630>
[anholt: changed to make all drivers do the right thing by moving the
payload barycentric check into the compiler]
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17381>
this can get called from multiple threads with the recent llvmpipe
overlapping rendering changes, so make sure to lock around the
map/unmapping so they can't race.
This should fixes some crashes seen with kwin.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Tested-by: Adam Williamson (Fedora)
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17531>
When doing 10bit encoding in ffmpeg it uses
VaDeriveImage, and that could result in missing
mapping the chroma buffer of the input frame.
This WA to disallow ffmpeg using VaDeriveImage
function, so that VaCreateImage and VaPutImage can
be used and WA the chroma buffer mapping issue.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17472>
this ensures the alpha component is full if it must be read for fbfetch
fixes (RGBX swapchain config):
KHR-GL46.blend_equation_advanced*
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17366>
these are only ever going to hurt tiler perf, so remove the footgun
this also means there's no more srgb format conversion needed, so delete
all of that too
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17366>
in the scenario where:
* at least 1 color buffer was bound and a depth buffer was bound
* no color clear was enabled
* a zs clear was enabled
* the zs clear was never flushed
* the zs clear needs a renderpass
* the fb state changes
the color buffer(s) would be unbound, following which the depth buffer unbind
would trigger a renderpass, which would utilize the just-unbound color buffers,
which have no batch tracking, thus creating a case where the surface was destroyed
while it was still in use
cc: mesa-stable
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17366>
formats like GL_RGB10_A2UI can be cleared with out of range values,
so to ensure consistent driver behavior, pre-clamp to the valid range
affects:
KHR-GL46.direct_state_access.renderbuffers_storage_multisample
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17366>
it's unknown whether there may be clears to the depth attachment at the start of
a renderpass, so always assume there will be
Fixes: c132a28745 ("zink: use store op NONE when necessary for depth usage")
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17366>
this was really stupid: instead of just binding a new fb and firing off
a clear, the code was calling u_blitter to bind a new fb and do actual
draws
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17366>
These are reachable, and
dEQP-VK.api.smoke.triangle_ext_structs,Crash is why.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17586>
LLVM-15 enables opaque pointers by default. We temporarilly request
non-opaque pointers while we migrate our code to support non-opaque pointers.
This workaround needs to be removed before LLVM-16.
See #6615
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Kai Wasserbäch <kai@dev.carbon-project.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17514>
Similar motivation as c426e21ff1 ("turnip: Reverse the order of walking
pipes or tiles on odd rows."), but instead we just swap the order of
alternate rows of fd_tile the the gmem stateobj.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17303>
nir->info.has_transform_feedback_varyings is set for all stages in the
pipeline when xfb is present, so it can't be used for this
harmless, but this is more correct
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17404>
this splits all the members of a struct into separate variables to
improve xfb inlining and reduce the number of locations consumed by
xfb outputs, reducing the chances of running out of shader outputs
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17404>
get_slot_components() returns the total number of output components
for arrays for initial evaluation phase, but during the packed->inlined
conversion the arrayed size must be normalized to the slot's component count
in order to effectively catch and inline the array
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17404>
these are not necessarily the same case even if in glsl they are the same,
and by splitting it out a bunch of redundant array[scalar] code can be deleted
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17404>
while some (tg4) sample ops can use different bit sizes in spirv, most
cannot, and all the shader variables are always emitted as 32bit, so
ensure the 32bit type is always what's being used for sampling
cc: mesa-stable
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17427>
It's everyone's favourite day, infrastructure maintenance Friday.
This includes manual disables for a618-vk and zink-anv-tgl, because
apparently the disable-on-variable rules don't carry through to those
jobs for ... some reason.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17553>
When the shader state is destroyed before the async shader compile is
done, we get a use after free in the async thread, as the shader state
it is operating on is gone. Fix this by dropping any pending job from
the async queue or wait for it to finish before destroying the state
by calling util_queue_drop_job.
Also call util_queue_fence_destroy, which would have caught this issue
by asserting that the queue_fence is in signalled state when the
shader state is destroyed.
Fixes: 1141ed5859 ("etnaviv: async shader compile")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17534>
On Linux, the static glapi path sees libGL.so implementing the static
glapi, and the drivers (libgallium_dri.so) updating/reading the TLS
vars.
On Windows, to allow libgallium_wgl.dll to be a full ICD, it's
responsible for implementing the actual static glapi. However, before
this change, OpenGL32.dll was also implementing the static glapi,
meaning that GL API calls from OpenGL32.dll didn't route to the driver
correctly because the TLS vars were never actually set - the driver set
its copy, and OpenGL32.dll read its own copy.
Now, always build a bridge and static version of glapi when not using
shared. The bridge version is linked into OpenGL32.dll, and the static
version is linked into the driver on Windows. GLES only builds with
shared glapi - but after this, shared glapi is not really needed on
Windows for GLES, since the driver has all of the data.
Fixes: f36921ef ("wgl: Refactor drivers to a libgallium_wgl.dll")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6560
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16713>
The sampler views array needs to be dimensioned by
PIPE_MAX_SHADER_SAMPLER_VIEWS, not PIPE_MAX_SAMPLERS.
This fixes out-of-bounds array writes when using more than 32
textures in a shader.
Also add some assertions to check array indexing elsewhere.
And change loop limits to be based on ARRAY_SIZE().
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
This fixes another VMware test (dx9-stretch-formats-copy-a8r8g8b8-x8r8g8b8).
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
The logicop_enable and independent_blend_enable vars need to always
be assigned, otherwise, once turned on, they could never be disabled.
This fixes a number of failures in VMware's test suite.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
This allows a VMware test to pass. The comments in lp_bld_limits.h
mention SM 3.0 requirements, but we're in the SM 5.0 era...
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
For the linear rendering fast path, we need to know whether the
texcoord argument to tex instructions comes directly from an FS input
(swizzling OK, but no arithmetic, etc). Use the input register info
to fill in the tex_info object.
This is part of a fix for some linear rendering bugs.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
We were saving the address of the constants[] and nir_constants[]
arrays in the jit structure. But those arrays went out of scope
before use.
This patch moves the constants[] array to the function scope and
consolidates the TGSI/NIR paths.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
The texture_unit field needs to be set like the sampler_unit field.
Also, add a swizzle initialization and some comments.
Signed-off-by: Brian Paul <brianp@vmare.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
And GET_DADX(), GET_DADY(), GET_PLANES(). This is a bit more
readable, making the expected parameter types explicit.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
The code did not handle more than 32 textures. We have a test that
exercises 128 textures (views) and crashed w/ memory corruption down
in the llvm code generator because of this.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
Use the existing 'set_state' field. Some code was using 'state'
and other code was using 'set_state'. It didn't really matter
since lp_rast_cmd_arg is a union, but this removes some potential
confusion.
Signed-off-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17062>
Streamout is not L3 coherent so previous writes to the same address
might be pending and overwrite the SO writes later when they get
flushed from L3, even though the SO write happened later in the batch.
v2: Use the right flag (not COUNTER)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6680
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17503>
Unlike image writes, buffer writes may access the same memory in
different ways, which we've seen in the past can cause problems. Use an
incoherent access to force flush/invalidate between accesses to the same
buffer, unless we know the barrier applies to images only.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17193>
Certain player has hard coded max_transform_hierarchy_depth_inter and
max_transform_hierarchy_depth_intra values set through VA-API, which
doesn't work on radeon HW. Until properly fixing it on player side,
temporarily adding this workaround to use calculated values instead.
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17489>
the si_pm4_clear_state() initializes the variable in struct si_pm4_state which
anyway gets freed in si_pm4_free_state(). Hence no need to call
si_pm4_clear_state() in si_pm4_free_state().
Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17504>
Format on buffers is irrelevant and bind flag validation needs to be disabled.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17446>
If the memobj wraps a resource, then we only succeed the
mapping operation if the gallium desc matches the D3D12
resource desc.
If the memobj wraps a heap, then we can place whatever
gallium is describing on the heap.
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17446>
Win32 memory objects can be imported by name (const void *
that will be interpreted as const wchar_t *)
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Marek Olák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17446>
Remove the previous compile-time early-ZS implementation and replace it with the
decoupled early-ZS implementation. This uses more efficient settings in some
cases (depth/stencil tests always passes or do not write), and fixes the
settings used in another case (alpha-to-coverage enabled with an otherwise
early-ZS shader.)
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Closes: #6206
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17428>
If we know ahead-of-time that depth/stencil testing will always pass, it's
better to use weak_early than force_early. However, if depth/stencil testing
could fail (discarding pixels), we'd rather use force_early. Determine which
case we're in at CSO create time.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17428>
Apparently, the point coord origin within a batch can change with Gallium
(seemingly even with GLES? where that's impossible at an API level?) but that
doesn't matter if we're not drawing points. This might have to do with internal
Gallium CSOs (e.g. u_blitter). Issue noticed in SuperTuxKart, which was getting
state change flushes. Performance on one level on a Valhall GPU improved from
26fps to 29fps.
Fixes: 3641dfe436 ("panfrost: Flip point coords in hardware")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17430>
b6a30b72ab ("panfrost: Implement provoking vertices on Valhall") added an
assertion that every draw selects a particular provoking vertex. The intent was
to ensure provoking vertex selection actually happened. Unfortunately, the
assertion is too strong, as the provoking vertex is irrelevant for some (most)
draws. For those, we don't *want* to commit to a particular provoking vertex for
those to avoid flushing.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17430>
driFetchDrawable is only ever called from the MakeCurrent path, which
means it has to handle the case of pre-GLX-1.3 Windows being named as
the drawable. When it finds the drawable in the hash, it increments its
refcount before returning it, so for a GLXWindow it would be 2 on first
return, one from glXCreateWindow and one from glXMakeCurrent. But when
it does not find the drawable and creates one for the naked Window, the
reference count on first return would only be 1. As a result, if this
context was then ever bound to a different drawable, the old Window's
DRI drawable state (like the back buffer) would be destroyed.
Fixes piglit's glx-multi-window-single-context and glx-make-current for
a variety of drivers.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6713
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17479>
There is nothing more TODO here. With softpin, which is available on all
GPUs using texture descriptors, there is no need for the kernel to patch
the descriptor, as the proper GPU virtual address is filled in by userspace.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17448>
There already is a error handling label to free the sampler view
struct and return failure. Consistently use this label to make
error handling more uniform.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17448>
Texture descriptors currently waste a massive ammount of memory, as every
one is allocated via a separate BO. As the allocation granularity of the
kernel is 4KB and the descriptor is only 256B, 93.75% of the allocated
memory is wasted.
Add a simple suballocator for the texture descriptors, to allocate multiple
ones out of a single kernel BO. This isn't perfect, as freed slots in the
suballocated resource are not reused, but worst-case we end up with the
same waste as we had before. This also potentially improves efficiency at
the kernel side, as this reduces the number of BOs needed for the sampler
views in each submit.
As the BO is now used by multiple descriptors, avoid syncing with the GPU
via the cpu_prep/fini calls, as to not introduce stalls between pending
rendering and new descriptors being filled. This is safe, as each
suballocation slot is only used once, so newly filled slots are certainly
not in use by the GPU.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17448>
The dummy texture descriptor and the dummy render target relocs are not ever
changed by a context operation, so we can save some space by moving them to
the screen and potentially share them and the BOs backing them between
multiple contexts.
Also don't hold two pointers to the same BO, one in the reloc and one raw,
but always just use the reloc one.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17448>
libc++ does not yet implement the c++17 monotonic_buffer_resource,
so emulate it by doing normal allocations that are cleaned up
when the resource is destroyed.
v2: - Use C include and version without namespace aligned_alloc
- add include for sstream needed with clang++ (maurossi)
Closes: #6836
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17452>
With that most piglits for compatibility contexts are
passing, so enable higher compatibility profile support.
v2: fix formatting ahd fallthrough tag (Filip)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17484>
Another hot-fix: when a local register is written to, it is
actually unlikely that the value is never used, so just make
sure that this is never done.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17484>
On Cayman bank_swizzle[4] is never counted up, so add an
additional condition to make sure the loop is finished
at one point. This is a hot-fix, the logic below should be
improved.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17484>
The compiler has improved significantly since we found this issue
and this is no longer required.
Notice that because we are increasing the number of samplers
supported beyond what we can loop unroll (currently capped at 16),
some piglit tests that test the maximum number of samplers supported
start to fail because they use indirect indexing on a sampler array
and we don't support that (previously the indirect indexing was
removed by loop unrolling). This is a bug in tests which the
GLSL linker detects, failing to compile the shaders.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17509>
Correct the max thread number for DG2+ platforms according
to below bspec.
Ref: Bspec: 47202
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17506>
We were defaulting to a swap interval of 1, but we can follow dri2/dri3's
lead and respect the driconf var.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17470>
We need to track what the caller has given us for swap interval, and use
that to set the present mode at startup.
Fixes incorrect vblank syncing in apitrace's glretrace, which sets the
swap interval to 0 before the swapchain is made.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17470>
Fill in support for TXD instruction which emits shader TEXLDD opcode.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17500>
Rename the args from low_bias/compare to src1/src2, since they
are used for different purposes depending on the texture load
type. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17500>
Fixes arb_timer_query-timestamp-get on my radv system, where the GPU has
been on for many days and the timestamp would only increment every once in
a while.
Part of fixing #6808
Fixes: 7a40b734ee ("zink: handle timestamp queries")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17477>
glsl_get_explicit_size can return non-16 byte aligned sizes.
Therefore, make sure the sure the size isrounded up so that OOB does not happen.
Fixes: ea8a0654f5 ("zink: further improve bo sizing")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17460>
This pass tries to move register usage closer to SSA, and for large
shaders this means we can overflow the register index, which only has
RC_REGISTER_INDEX_BITS size. This creates invalid code and leads to
crash at a later stage. Limit the pool of available registers to
RC_REGISTER_MAX_INDEX, currently is was two times the number of
shader instructions.
This means we'll fail the compile right away if we wanted more than
RC_REGISTER_MAX_INDEX temps, but when we've got that many we're
already well past how many instructions we can support anyway.
CC: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6017
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17393>
the EXT_external_object spec originally was underspecified with regards
to this function, leaving room for synchronization errors where:
* app calls SignalSemaphoreEXT to signal a semaphore
* mesa defers pipe_context::fence_server_signal with threaded context
* driver defers gpu submission
* SignalSemaphoreEXT has long since returned, app submits vk cmdbuf waiting on semaphore
* spec violation / device lost
to prevent this, the spec is being changed to:
1) require an implicit flush when calling SignalSemaphoreEXT
2) require that this implicit flush also forces GPU submission before SignalSemaphoreEXT returns
all affected drivers have been updated
fixes#6568
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17376>
The hardware doesn't support 3D textures. We had been lying about 3D
texture level support in the past so that we got GL 2.1, but now reporting
levels==0 doesn't disable GL 2.1 (since we don't check for GL2 extensions
any more). But, by not lying, we now fix the majority of the remaining
GLES2 deqp failures.
This regresses a few desktop GL piglits which get GL errors that they
notice instead of what would be silent rendering failures on 3D texturing
operations.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17350>
The dri2_allocate_buffer() can be called with arbitrary height, however
the struct pipe_resource .height0 member is uint16_t. Check height for
maximum size to avoid overflow. Note that .width0 is unsigned int, so
it does not have the same issue.
The uint16 limit comes from commit:
e6428092f5 ("gallium: decrease the size of pipe_resource - 64 -> 48 bytes")
The overflow can be triggered e.g. by requesting large BO:
```
gbm_bo_create(dev, 1, 640*480*4, GBM_FORMAT_R8, GBM_BO_USE_LINEAR);
```
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16513>
Another victim of automated re-indenting being unaware of the semantics.
Re-indent this to put each dword of the packet on it's own line to make
the size of the packet more clear.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17341>
When the field was first introduces, the numbers were reporting the number of
vec4 instead of the number of float. Do not propagate them if they are wrong.
Fixes: d92c1ca01b
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17415>
if a texture barrier occurs while clears are pending, these clears should
show up if the fb attachments are read in shaders, so trigger a renderpass
to flush out the clears
cc: mesa-stable
fixes#6766
fixes (radv):
dEQP-GLES3.functional.draw_buffers_indexed.overwrite_common.common_advanced_blend_eq_buffer_advanced_blend_eq
dEQP-GLES3.functional.draw_buffers_indexed.overwrite_common.common_blend_eq_buffer_advanced_blend_eq
dEQP-GLES3.functional.draw_buffers_indexed.overwrite_common.common_separate_blend_eq_buffer_advanced_blend_eq
dEQP-GLES3.functional.draw_buffers_indexed.overwrite_indexed.common_advanced_blend_eq_buffer_advanced_blend_eq
dEQP-GLES3.functional.draw_buffers_indexed.overwrite_indexed.common_advanced_blend_eq_buffer_blend_eq
dEQP-GLES3.functional.draw_buffers_indexed.overwrite_indexed.common_advanced_blend_eq_buffer_separate_blend_eq
Reviewed-By: Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17363>
PS is the only shader type where unpacked 16-bit outputs can be used,
so use ac_shader_abi::is_16bit to pass the proper type to LLVMBuildLoad2.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17361>
Outputs are always f32 except for FS that may use unpacked f16.
Store this information here to make it available to later processing.
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17361>
This commit replaces LLVMBuildLoad usage by LLVMBuildLoad2
where possible (= where the pointee type is known).
Reviewed-by: Mihai Preda <mhpreda@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17361>
Fixed:
- VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT was able to stop prim counter
when pipeline stats query is running.
- This may have happened when prim gen query was in secondary cmdbuf.
- VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT counting geometry in each tile.
- VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT counting geometry in each tile
when pipeline stats query is started inside prim gen query and inside
a renderpass.
The matter of VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT and pipeline stats
interaction is solved by tracking whether pipeline stats query is
running both on CPU (for non secondary cmdbuf case) and on GPU (for
secondary cmdbuf).
Note, prim gen query is not allowed with secondary command buffers, so
only pipeline stats query is tracked on gpu.
See https://gitlab.khronos.org/vulkan/vulkan/-/issues/3142
Counting geometry per each tile is solved by:
- Conditionally executing START/STOP_PRIMITIVE_CTRS to not run in tiling
pass. Solves the case when prim gen query is inside a renderpass.
- Stop prim counters before executing `draw_cs` and restarting them
afterwards. Solves prim gen query being outside a renderpass.
Fixes GL CTS tests with Zink + `TU_DEBUG=gmem`:
GTF-GL46.gtf30.GL3Tests.transform_feedback.transform_feedback_max_separate
GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_basic
GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_framebuffer
GTF-GL46.gtf40.GL3Tests.transform_feedback3.transform_feedback3_streams_overflow
GTF-GL46.gtf40.GL3Tests.transform_feedback3.transform_feedback3_streams_queried
GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_states
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6602
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17163>
It's legal to use this instruction in a fragment shader, even if the
graphics pipeline doesn't use MSAA.
Fixes
dEQP-GLES31.functional.shaders.multisample_interpolation.interpolate_at_sample.non_multisample_buffer.sample_n_*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17398>
Flushing the batch midframe (splitting a renderpass) is expensive on a tiler, as
it requires the GPU to flush the framebuffer contents to main memory and read
them back. Clearing the framebuffer should not trigger a flush. Apps expect
clears to be (almost) free, flushing for a clear is at the very least unexpected
behaviour.
The only reason we previously flushed is to ensure we could always use a "fast"
clear. But a slow clear is a heck of a lot faster than a flush ;-) Instead of
flushing, we should clear with a draw (via u_blitter) in case a fast clear isn't
possible.
This fixes pathological performance for applications that rely on partial clears
within a frame. This issue was identified with Inochi2D, which repeatedly clears
the stencil buffer midframe, in order to implement masking efficiently with the
stencil buffer. In total, the all-important workload of rendering Asahi Lina is
improved from 17fps to 29fps on a panfrost device.
Fixes: c138ca80d2 ("panfrost: Make sure a clear does not re-use a pre-existing batch")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17112>
I wrote fiction about dreaming that these were supported but after
waking finding that they were not. Somehow I came to consider that
fiction as fact and I never thought to test if they did work.
While reverse engineering the polygon list format, I found that these
were supported after all.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17371>