Add the files otherwise things just won't build.
Haven't actually tested it, but it's a small step in the right
direction.
Fixes: de3b34df97 ("freedreno: Add a6xx backend")
Cc: Kristian H. Kristensen <hoegsberg@chromium.org>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
The pipe_loader_release API closes the fd given, even if the pipe-loader
should _not_ take ownership of it.
With earlier commit we fixed pipe_loader_drm_probe_fd, and now with
cover the final piece.
Note that unlike the DRM case, here the caller _did_ forget to dup
before using it ... most likely leading to all sorts of fun.
Don't forget the close in the error path. Seems like the things are a
bit leaky/asymmetrical with the semi-recent config work. But we can shave
that yak another day ;-)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Currently pipe_loader_drm_probe_fd takes ownership of the fd given.
To match that, pipe_loader_release closes it.
Yet we have many instances which do not want the change of ownership,
and thus duplicate the fd before passing it to the pipe-loader.
Move the dup() within pipe-loader, explicitly document that and document
all the cases through the codebase.
A trivial git grep -2 pipe_loader_release makes things as obvious as it
gets ;-)
Cc: Leo Liu <leo.liu@amd.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Axel Davy <davyaxel0@gmail.com>
Cc: Patrick Rudolph <siro@das-labor.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com> (for nine)
As the newly introduced comment says:
The pipe loader takes ownership of the fd
Thus, there's no need to close it again.
Cc: Patrick Rudolph <siro@das-labor.org>
Cc: Axel Davy <davyaxel0@gmail.com>
Cc: mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Axel Davy <davyaxel0@gmail.com>
With commit c6c0f94714, back in 2006 Brian removed the
_glapi_check_multithread() call from core mesa - _mesa_make_current.
It was done to remove fairly awkward #ifdef guard which caused subtle
differences in core mesa.
Since that guard is long gone, we can drop the duplication and
reintroduce the call in core.
Note that the function is was missing when using EGL + classic dri HW
drivers. Yet on TLS builds it's a no-op, so we're safe.
Any non TLS users - more or less anything !Linux (or even musl on Linux
up-to semi-recently) may have experienced problems.
v2: don't remove the call from swrast - move it to core (Eric)
Cc: Eric Anholt <eric@anholt.net>
Cc: Brian Paul <brianp@vmware.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Earlier commit added support for 'front_buffers', erroneously adding a
return in vl_dri3_screen_destroy. Effectively leaking a lot of state.
Fixes: 8d7ac0a4e4 ("vl/dri3: implement DRI3 BufferFromPixmap")
Cc: Leo Liu <leo.liu@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
The header was used only by dri2.c, containing a two-member struct and cast wrapper.
Just inline it where it's used/needed.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
The overrides array contains entries indexed on the gl_api enum.
Use a C99 initializer to make it a bit more obvious.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
This is the minimum value according to the spec.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
This can be used as a drop in replacement for
disk_cache_get_function_timestamp().
Here we use build-id to generate a driver-id rather than build
timestamp if available. This should resolve issues such as
distros using reproducable builds and flatpak not having
real build timestamps.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Only some drivers use a timestamp here. Others use things such
as build-id, or even a combination of build-ids from Mesa and
LLVM.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
In the GL_MESA_framebuffer_flip_y implementation
_mesa_is_winsys_fbo checks were replaced with
FlipY checks. rb->Name is also used to determine
if a buffer is winsys.
v2: Fixes annotation [for emil]
Fixes: ab05dd183c ("i965: implement GL_MESA_framebuffer_flip_y [v3]")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Chad Versace <chadversary@chromium.org>
We already call nir_rematerialize_derefs_in_use_blocks_impl prior to
calling nir_lower_ssa_defs_to_regs_block so the assertion that all deref
uses in the block should hold. This fixes the following CTS test when
SPIR-V optimization recipe 1:
dEQP-VK.glsl.struct.local.loop_nested_struct_array_vertex
Fixes: 606eb56ab9 "intel/nir: Only lower load/store derefs"
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
If the block in which the jump is inserted is the predecessor of a phi
then we need to remove phi sources otherwise the phi may end up with
things improperly connected. This fixes the following CTS test when
dEQP is run with SPIR-V optimization recipe 1:
dEQP-VK.glsl.functions.control_flow.return_in_nested_loop_vertex
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Let's just be explicit that VK_NV_shading_rate_image is not supported.
Suggested-by: Jason Ekstrand <jason.ekstrand@intel.com>
Fixes: 6ee1709170 "vulkan: Update the XML and headers to 1.1.86"
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
This fixes a bunch of Vulkan subgroup tests on little core platforms.
Fixes: 4150920b95 "intel/fs: Add a helper for emitting scan operations"
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Timestamp can be zero for example when Flatpak is used. In this
case just disable the cache rather then segfaulting when
incompatible cache items are loaded.
V2: actually return false when mtime is 0.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Unnecessary. While we are at it, remove the check for pre-VI
because it's already checked earlier.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
If apps use the MUTABLE bit and the same formats as the image one
in the list, we can still enable TC-compat HTILE. I don't think
this happens often but given the fact that TC-compat HTILE allows
a nice boost in some situations, it's worth checking.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Like we disable DCC/CMASK for small color surfaces as well.
Serious Sam 2017 creates a 1x1 depth surface and I think
it should be faster to do slow clears on the graphics queue
instead of fast clears on compute, and eventually a depth
expand if the surface isn't TC-compatible HTILE.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Other drivers set these two as well, just apply the same rule.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
I don't think this is required by Vulkan too.
Ported from RadeonSI (AMDVLK doesn't set it either).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
As discussed in the review of the patch which added the comment:
Nothing happens when a thread is created, because pthread_atfork doesn't
affect creating threads. However, spawning a child process will likely
crash.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
We already track if the DMA engine is busy/idle with a flag,
and we emit a packet that waits for all CP DMA operations
to be complete. This is done at end of command buffer because
the kernel doesn't wait for them, and also when emitting
barriers, so it should be safe.
This improves small copies for both aligned and unaligned sizes.
Aligned sizes:
BEFORE:
1 KB: 59.840000 ms
2 KB: 71.200000 ms
AFTER:
1 KB: 31.200000 ms
2 KB: 31.040000 ms
Unaligned sizes:
BEFORE:
2 KB: 68.3200 ms
3 KB: 79.3600 ms
5 KB: 76.6400 ms
9 KB: 90.8800 ms
17 KB: 116.0000 ms
AFTER:
2 KB: 31.0400 ms
3 KB: 32.0000 ms
5 KB: 30.8800 ms
9 KB: 30.5600 ms
17 KB: 29.6000 ms
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
According to my benchmark results, it appears that we should
reduce the threshold to 1024.
BEFORE:
1 KB: 68.656000 ms
2 KB: 118.368000 ms
AFTER:
1 KB: 31.760000 ms
2 KB: 29.840000 ms
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
It's unnecessary because we can just check if the timestamp
is to different to the default value when a pool is created
or resetted. Instead of waiting for the availability bit to
be 1, we have to emit a not equal WAIT_REG_MEM for checking
if the timestamp is ready.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Pulling this logic out means we can share the logic and avoid a couple
of temporary variables that helped make things clearer before. Note
that in either vismode case, we always program vismode 0.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Now that we've copied the emit logic into each branch of the
if (info->index_size) statement, we can simplify the logic a bit
according to which case we're in.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
This splits the two code paths into separate functions and moves the
"if (info->indirect)" test into draw_impl().
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
This way the markers clearly bracket the draw call and isn't
duplicated for both direct and indirect draw code.
Signed-off-by: Kristian H. Kristensen <hoegsberg@chromium.org>
According to the following definition,
int AtomicCompSwap(inout int mem, uint compare, uint data);
the preceding one in atomic_comp_swap of NIR is compare and data is
followed, while src0 for cmpxchg needs vec2(data, compare)
So for ssbo/image deref comp_swap, that should be reversed.
Fixes: dEQP-GLES31.functional.image_load_store.*.atomic.comp_swap*
