Bifrost has a new type of job called 'index-driven vertex', which takes
in two shaders. The primary shader, called for all values, performs
position shading to a cacheline-aligned attribute buffer. The secondary
shader, called for values still live after culling, performs varying
shading.
It is the responsiblilty of the implementation to ensure that vertices
from different instances do not share a cacheline.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11413>
We can actually create array surfaces instead of requiring single-slice
in a few cases. This does require us to be very careful about our
checks, though.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11647>
It doesn't matter for the actual copy rectangle and this makes the
asserts a bit nicer as we don't need to bother with the intratile
offsets because there aren't any yet.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11647>
This adds a helper isl_surf_get_uncompressed_surf for creating a surface
which provides an uncompressed view into a compressed surface. The code
is basically a direct port of the uncompressed surface code from the
Vulkan driver which, in turn, was a port from BLORP.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11647>
Mirroring a change in iris; see the previous commit for rationale.
One difference is that crocus does sometimes use CPU maps on Atoms
for *reads*...but writes don't go through CPU caches. Should be OK.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11727>
Back when SSBOs were first enabled in i965, we tried to work around
issues where the CPU and GPU were incoherently writing to the same
cacheline by forcing an alignment such that different sections of
data would fall in different cachelines. This seems wrong.
On integrated GPUs with LLC, CPU and GPU writes should be coherent.
On integrated GPUs without LLC, we either enable snooping (so they
are again coherent), or we use WC maps (so the CPU cache isn't used).
Discrete GPUs always use WC maps (so the CPU cache isn't used).
This should work. In other words, I think the increased alignment
was just working around coherency problems on atoms that have been
fixed in the intervening 6 year time period.
Untyped surface messages require 4B alignment.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5016
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11727>
Since writers are counted in the accessor set, the old implementation
had a redundant flush in the "flush accessing" case. To fix, split the
two modes into separate functions, removing the redundancy and offering
a much more ergonomic API.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11077>
Squashed together with commits from Boris's original dependency tracking
cleanup series.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11077>
Reduces the work that other shader passes have to do to look at dead code,
and possibly extra rounds around the optimization loop if dce wasn't the
last pass in it.
shader-db runtime -1.12919% +/- 0.264337% (n=49) on SKL.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11628>
if shaders aren't being shared between programs, they can instead directly
assign io between the shader stages such that only the producer and consumer
pair need to have their slots match up
this requires that each gfx program struct stores base nir for a given shader
in order to avoid breaking io for other programs which reuse shader states
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11691>
the base shader states will never change for a program, and tcs will never
change its io, so there's no point in having this in the shader update hotpath
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11691>
After attempting to use the GBM backend specified by the user
via an environment variable, if any, but before falling back
to the built-in GBM backends, attempt to dlopen
libg<DRM driver name>_gbm.so in the GBM backend library search
path (Defaults to "$libdir/gbm") and initialize a device using
it. This enables automatic backend discovery for devices that
do not provide a DRI driver.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
If the user specifies a backend name explicitly
via an environment variable and it is not in the
list of built-in backends, attempt to load it at
runtime.
runtime-loaded backends get a new gbm_backend_desc
struct instance for each device using them (A
small increase in memory usage to eliminate the
need for the locking and bookkeeping sharing them
would require), so these structures need to be
freed when destroying devices using runtime-loaded
backends.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
Subsequent changes will use this same logic to
instantiate devices with the correct version and
set up their backend reference.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
A subsequent change will allow loading backends
from DSOs specified by the GBM_BACKEND environment
variable. The exact DSO name and path are derived
by the common loader code and will be of the form:
<gbm_backend_path>/<GBM_BACKEND>_gbm.so
E.g., a user would set the environment variable to
"external" to load "external_gbm.so". Users will
also still be able to explicitly request any
builtin backends by name as well, so this change
helps keep the environment variable syntax
consistent between internal and external backends.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
This is the list of locations where GBM will look
for alternate backend implementations based on the
DRM driver name. It defaults to $libdir/gbm.
On Android, this path is currently hard-coded to
/vendor/lib[64]/gbm.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
Separate the path-building and dlopen() portion of
loader_open_driver() from the DRI extension
loading logic. The former will be shared by the
GBM backend loading logic in a subsequent change.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
This just makes it clearer the array isn't a global
list of all backends in use.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
This is based on the wayland EGL library ABI test
framework. The helper macros were copied from
there and expanded to support more than one
struct/type, and to additionally check member
type compatibility by default.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
Define a version number for the interface GBM uses
to offload work to its backends/drivers. Store the
version in the backend interface structs provided
to the loader by backends, as well as in the core
interface struct provided to backends by the GBM
loader code to backends.
The backend can create structures of any version
it supports, which can be greater or less than the
interface version specified by GBM in the core
interface structure. Hence, GBM will need to take
care to check the backend version before accessing
any members added to structs defined in
gbm_backend_abi.h after this change.
Similarly, the backend may need to check the
interface version supported by the GBM library
before passing back data in any structure members
that require the GBM library to interact with
them for correct operation. For example, if for
some reason a structure defined in
gbm_backend_abi.h gained a field which was a
pointer to memory allocated by the backend and
freed by GBM, the backend should avoid allocating
this memory if the GBM library did not specify an
interface version new enough to indicate that it
was aware of the new structure member.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
The content of gbm_backend_abi.h are nearly an
identical copy of the old gbmint.h. Only minimal
modifications have been made to ease history
tracking. Subsequent changes will further
formalize the ABI structures in gbm_backend_abi.h
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
The GBM core/loader code defines one helper
function used by both itself and the built-in DRI
backend. Presumably, external backend authors
would want to use such functions as well, so
package them into a single struct that will be
passed explicitly to externally loaded backends in
subsequent changes.
Another option considered was to simply export
the gbm_format_canonicalize() function directly,
optionally renaming it to better indicate it is
intended only for "internal" use first. However,
even with a rename, this would expose it to
potential use by applications as well, which is
not ideal, as it is not intended to be part of
the application-facing GBM ABI.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
This will be used for looking up the backend
again at destruction time to perform any backend-
agnostic cleanup. To facilitate that, also
dispatch device destruction to the backend manager
code.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
It was a functional no-op with the currently
available backends (Only DRI), and its implied
intended functionality is implemented elsewhere
in subsequent patches.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902>
There is some hardware with num_render_backends == 1, but the number
of render backends in GB_ADDR_CFG > 1. Turns out this can be turned
off by making them rb unaligned which is valid with only 1 render
backend.
Fixes: 0833dd7d12 ("amd/common: Add support for modifiers.")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10575>
Logic lifted from the Bifrost compiler, which was a copypaste of the Midgard
compiler, which was based on a faulty understanding of the v3d compiler,
which...
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11718>
These are duplicates from a few lines up
Reviewed-by: Dave Airlie <airlied@redhat.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/11703>
These are duplicates from a few lines up
Reviewed-by: Dave Airlie <airlied@redhat.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/11703>
Per OpenGL Shading Language, section 8.11. "Atomic Memory Functions"
first argument "mem" of all atomicOP functions is inout.
The same is true for ARB_shader_storage_buffer_object and
GL_INTEL_shader_atomic_float_minmax
For implicit conversion of inout parameters it is required for type
to support bi-directional conversion, since there is no such types
in glsl - implicit conversion is effectively prohibited.
Alternatively we could have marked atomic_var parameter of built-in
atomicOP functions as inout, however it opens another can of worms
during NIR lowerings.
Fixes: ea0a1f5beb
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2837
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4887>
Use syncobjs to implement vkEvents (as suggested by Boris).
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11709>
Have it accept a syncobj so it can be used in a future commit.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11709>
So all CommandBuffers in a given CommandPool can reuse BOs for their
memory pools.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
This commit adds the actual implementations, allowing to diverge while
still sharing code that depends on pool functionality.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
The Gallium and Vulkan drivers will soon use different memory pool
implementation, but some pieces in libpanfrost depend on pan_pool. Let's
split the implementation so we have common bits still available while
letting the drivers implement what really matters: the allocation logic.
All the generic pieces are prefixed pan_pool, and what will become the
gallium implementation is prefixed panfrost_pool. We'll then duplicate
the panfrost_pool bits in panvk and prefix it with panvk_pool, and
implementations will start diverging from there.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
Pass a memory pool to pan_blit_ctx_init() instead of creating a new pool.
Useful for Vulkan since the descriptor pool is at the command buffer
level and is thus shared by all blit batches. Doing this will save us a
BO ownership transfer.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
The transient_bo has already been added to the BO list, no need to call
panfrost_batch_add_bo() a second time on the same BO.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11695>
The code was using a prim assembler after the tess stage, however
tess prims aren't necessarily the output prim types, so just put
the prim ids into the vertices at tess stage, and skip prim assembly.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11000>
This ensures space for the extra outputs is calculated in the
tes vertex outputs.
dEQP-VK.pipeline.misc.primitive_id_from_tess
Fixes: dacf8f5f5c ("draw: hook up final bits of tessellation")
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11000>
This fixes a possible problem if a non-indexed draw comes in first
in a new batch, then the batch might not emit the index buffer.
I'm unsure if we see this, I just spotted it trying to fix alacritty
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11705>
ifind_msb_rev was introduced in a5747f8ab3.
ifind_msb_rev guards against src0 being both 0 or -1 at the same time.
That is always true. This patch changes it to check for those values
individually.
Spotted from a compile warning.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: a5747f8ab3 (\"nir: add opcodes for *find_msb_rev and lowering\")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11630>
+ 9.31% drawover:gdrv0 iris_dri.so [.] iris_binder_reserve_3d
+ 2.36% drawover:gdrv0 iris_dri.so [.] iris_binder_reserve_3d
If the app never uses compute, then the compute bindings bit will always
be dirty causing these two paths never get shortcuts.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11699>
Add PCI IDs based in pci_ids/i965_pci_ids.h and move crocus before
iris in driver_map[].
This allows Xorg to load the crocus driver since iris would claim
the devices handled by crocus (because the i915 kernel driver is
used for all Intel devices) then fail during initialization.
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11694>
The intention here was to pass VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT to
select_memory_types() when requesting device local memory, or simply
pass 0 for the prime blit destination which should be in system memory.
Unfortunately, that meant we did (type.propertyFlags & 0) == 0 which
was vacuously true, causing us to not filter out device local types.
Fixes hybrid display of Vulkan apps on Intel TGL+DG1 systems.
Tested-by: Luis Felipe Strano Moraes <luis.strano@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11680>
Even with the wrap mode forced to REPEAT, we get undefined results in
CelShading when the Y channel is unwritten since the beginning of the
program.
I dropped the coords==0 case in the process, since that's not possible and
made the 1D case confusing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11457>
As written this would require that the driver be built before we looked
at the option. This is wrong because it affects code outside of the
driver, it's in libGL's PCI ID table. This is sort of harmless for
crocus at the moment, but for iris you would need to build it in order
to remove it from the table; if you built just i965 and tried to run it
against gen9, the libGL you just built would direct the loader to the
iris driver you just didn't, and setup would fail, which is: goofy.
Reviewed-by: Zoltán Böszörményi <zboszor@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11655>
This was used in the heuristics for deciding whether to CPU map,
but those have since been deleted, so this is now unused.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
If the caller has asked for a coherent BO with snooping, and the kernel
fails to set it for whatever reason, we were happily returning them a
non-coherent buffer. This isn't what they wanted and could lead to
surprising results.
Better to simply fail the allocation. Probably.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
On integrated GPUs without LLC, we enable snooping when someone requests
coherency for a buffer. (With LLC, it's already coherent.)
For discrete GPUs...if someone requests coherency, we allocate the
buffer in SMEM and resort to WC maps rather than WB maps with CPU
caches enabled. There's no snooping to enable, and calling this ioctl
is nonsensical, and may fail.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11644>
With HTILE only, all values between 0.0 and 1.0 are fetchable.
This should allow more fast clears for depth surfaces where
TC-compat HTILE is disabled.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10035>
VK_EXT_depth_range_unrestricted removes the restriction that the
clear value must be between 0.0 and 1.0.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10035>
The HTILE clear code is now computed based on the floating point value.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10035>
For images, variable data includes the format. For samplers, variable
data is used for OpenCL inline samplers. When converting a variable
from one to the other, zero out the data so we don't accidentally
interpret a converted image as an inline sampler.
Fixes: fa677c86 ("nir_lower_readonly_images_to_tex: Support non-CL semantics")
Acked-by: Enrico Galli <enrico.galli@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11674>
batch tracking has until now been the same as refcounting, but this
is inefficient and incurs additional overhead from constant atomic ops,
so make them separate
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11684>
I think maybe I misunderstood how things worked, or there were issues
generally with resource lifetimes, or whatever, but this isn't needed anymore
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11684>
This should be a subtract, not an add. The comment's proof is correct,
but the (wrong) expression we actually use isn't what it's in the
comment! Correct the discrepancy.
The lowering in nir_opt_algebraic was correctly typed.
Fixes: 272e927d0e ("nir/spirv: initial handling of OpenCL.std extension opcodes")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11671>
this is now a screen-based queue which can be triggered to serialize
cache updates, ensuring synchronization
the cache is on the program object, enabling incremental updates as well as
variant loading for an entire pipeline collection at once
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11595>
with tc enabled, we get genuine multidraws with valid drawids, so we can
update this to reflect the new capabilities...which are the same as the old
ones except that potentially some drivers can now do direct multidraws
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11662>
If the barrier tries to apply to memory that we can't express, just
don't apply the memory portion of the barrier. Similarly, if it tries
to apply a global memory barrier at invocation level, upgrade it to
thread-group.
Reviewed-by: Enrico Galli <enrico.galli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11670>
We already apply start when setting the bits in writable_buffer, so
shifting the bits up by start just makes us apply the offset twice.
Caught by Coverity.
Fixes: 988d091720 ("gallium/u_threaded: clear valid buffer range only if it's not bound for write")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11635>
Both games perform two image layout transitions with the same image
in the same pipeline barrier with UNDEFINED and this re-initializes
DCC to the uncompressed state. No ideal solution sadly. Note that
both games declare all images as CONCURRENT.
This fixes rendering issues on GFX10+ because DCC for stores is
supported and this implicitly enables DCC for concurrent.
Fixes: da166f648f ("radv: enable DCC for concurrent images on GFX10")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4927
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4607
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11656>
There are some cases using kgsl backend on linux that is still not usual
setup though, we need to consider too.
Regarding the timeline semaphore feature, we could implement it for
the kgsl backend in the future, and probalby it should be using the
existing code in tu_drm.
See #4738, #4907
Signed-off-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11488>
Layering AHB on top of dma_buf_fd requires venus to combine the memory
type bits internally for VkBuffer.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11661>
The unused bo_flags here is a leftover from the past. A similar
setup of bo_flags is now performed within anv_device_alloc_bo
via a call to anv_bo_alloc_flags_to_bo_flags.
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11645>
The destination of the upcoming blit (the old rsc struct that houses the
fresh BO) wouldn't have its ubwc cleared first, which if it got
unfortunate data in a recycled BO could lead to blit failures.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11544>
The valid flag indicates whether the bo has had any data written to it.
Failure to swap it meant that if for some reason we fell back to SW
mappings during the blit from shadow, the PIPE_MAP_READ staging blit would
get dropped.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11544>
After disabling SMEM stores, nir_opt_access() now does the same analysis
and we don't need this anymore. Doing it in isel is also too late if we
want to lower descriptor loads in NIR.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11652>