The claim that we require vulkan memory model's MakeAvailable and
MakeVisible semantics for image writes isn't accurate. This would be
required *if* we were already using the Vulkan memory model.
But we're using the GLSL450 memory model in those cases, which has no
such requirements.
This means that any problems on RADV due to the lack of these semantics
are RADV bugs, and should be fixed in RADV instead.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10345>
v2:
* Fixed indentation in iris_resource_from_memobj
v3:
* Removed the call to iris_resource_configure_aux, as we don't
have any auxiliary buffer support.
v4:
* Added a comment about the assertion that there's no aux buffer
in case we add them later.
v5:
* Changed the logic of iris_resource_from_memobj. When the user doesn't
explicitly set the tiling to linear, we use a similar logic with the
anv driver's logic to calculate it instead of querying the kernel.
This is because the Vulkan driver doesn't perform ioctls to update the
kernel when it suballocates buffers.
v6:
* Removed the line that sets the modifier info in the resource. We
shouldn't need it.
v7, v8:
* Removed left over code related to modifiers.
v9:
* Replaced FORCE_LINEAR_TILING flag with PIPE_BIND_LINEAR where
necessary.
v10: rebase, use iris_resource_configure_main (Tapani)
v11:
* isl surfaces should be created only for textures and not for
buffers (fixes: pixel buffer tests assertion failure on BDW).
v12:
* fix in return type is required after rebasing to master.
Signed-off--by: Juan A. Suarez Romero <jasuarez@igalia.com>
Signed-off-by: Eleni Maria Stea <estea@igalia.com>
Co-authored-by: Eleni Maria Stea <estea@igalia.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com> (v9)
Reviewed-by: Tapani Pälli <tapani.palli@intel.com> (v12)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4337>
v2: use iris_bo_import_dmabuf (Tapani)
v3: included "util/u_memory.h" to fixed compilation errors caused by
using the CALLOC_STRUCT macro
v4: implemented iris_memobj_destroy (pscreen->memobj_destroy) callback
v5: removed iris_bo_from_handle and changed the approach for setting the
tiling: Instead of querying the kernel and call
iris_bo_import_dmabuf to create the bo, we call
iris_bo_import_dmabuf_no_mods that imports the bo but without
setting the tiling mode. We are going to update it when we create
the resource. Also: implemented the iris_bo_import_dmabuf_no_mods.
v6: rebase to iris_bo_import_dmabuf changes and take a reference
to memobj->bo (Tapani Pälli)
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Signed-off-by: Eleni Maria Stea <estea@igalia.com>
Co-authored-by: Eleni Maria Stea <estea@igalia.com>
Reviewed-by: Rohan Garg <rohan.garg@collabora.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4337>
Turns out both kernel v5.10 and v5.11 have the same amdgpu driver
version and only one has modifiers ... In addition the version check
is kinda annoying for backports.
So lets use the cap. Since the cap is technically about ADDFB2 I
tested that this works on rendernodes (and reading the code there
is no distinction from what kind of node this is called).
Fixes: 9a937330ef ("radeonsi: Only set modifier creation function for GFX9+ & with kernel support.")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10337>
If depth bias is enabled but zero values used, they were never
emitted to the command buffer because they are equal to the default
values.
Previously, they were always emitted when the bound DS attachment
changed.
This should fix some sort of Z fighting with Dota2 on all GPUs.
This also fixes a different issue (ie. some occlusion queries failures)
on GFX6 because CLEAR_STATE is not used on that chip.
Fixes: 8a47422d97 ("radv: do not scale the depth bias for D16_UNORM depth surfaces")
Cc: 21.1 mesa-stable
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/10310>
Without this, we're left with a bunch of medium-precision residue, like
i2imp. And to avoid that the lowering intrudces left-over instructions,
also run other lowering passes, similar to what other drivers do.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10185>
If the calling process happens to use an invalid bo (e.g. fd has been
closed), this led to lseek() returning -1 and this mmap trying to mmap
a buffer of size -1 (0xffffffffffffffff ...) which led to mmap
failing, which led to munmap failing which then led to the process
aborting.
This fixes that to gracefully handle the mmap failures and percolate
the failures back up through the API so eglCreateImage will not return
a valid image anymore, thus the error is detectable in the caller
process too.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10313>
gallium hud checks for the PIPE_FORMAT_B8G8R8A8_SRGB format to set
has_srgb, but can then receive a different format such as
PIPE_FORMAT_B8G8R8X8 in hud_run.
If the driver supports PIPE_FORMAT_B8G8R8A8_SRGB but does not support
the other formats such as PIPE_FORMAT_B8G8R8X8_SRGB, that will break
rendering as gallium hud assumes srgb is also supported for that format.
Extend the check to set has_srgb to prevent that from happening.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10222>
gallium hud uses different tgsi fragment shaders for text and background
quads, which have different varying layouts. Since these are compiled
directly from tgsi they bypass some optimizations and may not work
properly on all backends.
A simple fix for the varying layout problem is to define a vs_text
shader to match the varyings in fs_text so the problem is avoided.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10222>
As requested by Ken since we're now (after 20e2c7308f)
re-emitting constants at the beginning of every batch which may lead
to some redundant constant restore overhead. No statistically
significant performance changes observed with either change.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9903>