At this point in the code, s must be visit_continue. If the child
returned visit_stop, visit_stop is the only correct thing to return.
Found by inspection.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Otherwise extensions to 1.40 that are only for core profile won't work.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
max_unroll_iterations was moved into options a long, long time ago.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Needed to successfully link llvmpipe or swr when using shared llvm libs
built with inteljitevents enabled.
v2: Make adding inteljitevents component global rather than just
llvmpipe/swr, since libgallium will have a symbol dependency.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Small buffers are now handled via the slabs code, so separate buckets in
pb_cache have become redundant.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Only enable for chips with GPUVM, because older driver paths do not take the
required offset into account.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Note the logic for adding fences is somewhat different than for amdgpu,
because radeon has no scheduler and we therefore have no guarantee about
the order in which submissions from multiple threads are processed.
(Ironically, this is only an issue when "multi-threaded submission" is
disabled, because "multi-threaded submission" actually means that all
submissions happen from a single thread that happens to be separate from
the application's threads. If we only supported "multi-threaded
submission", the fence handling could be simplified by adding the fences
in that thread where everything is serialized.)
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When a buffer is added to a CS without the SYNCHRONIZED usage flag, we now
no longer add a dependency on the buffer's fence(s).
However, we still need to add a fence to the buffer during flush, so that
cache reclaim works correctly (and in the hypothetical case that the buffer
is later added to a CS _with_ the SYNCHRONIZED flag).
It is now possible that the submissions refererring to a buffer are no longer
linearly ordered, and so we may have to keep multiple fences around. We keep
the fences in a FIFO. It should usually stay quite short (# of contexts * 2,
for gfx + dma rings).
While we're at it, extract amdgpu_add_fence_dependency for a single buffer,
which will make adding the distinction between real buffer and slab cases
easier.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When passed to winsys->buffer_create, this flag will indicate that we require
a buffer that maps 1:1 with a kernel buffer handle.
This is currently set for all textures, since textures can potentially be
exported to other processes. This is not a huge loss, since the main purpose
of this patch series is to deal with applications that allocate many small
buffers.
A hypothetical application with tons of tiny textures might still benefit
from not setting this flag, but that's not a use case I'm worried about
just now.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is really the behavior we want most of the time, but having a
SYNCHRONIZED flag instead of an UNSYNCHRONIZED one has the advantage that
OR'ing different flags together always results in stronger guarantees.
The parent BOs of sub-allocated buffers will be added unsynchronized.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
This is a simple framework for slab allocation from buffers that fits into
the buffer management scheme of the radeon and amdgpu winsyses where bufmgrs
aren't used.
The utility knows about different sized allocations and explicitly manages
reclaim of allocations that have pending fences. It manages all the free lists
but does not actually touch buffer objects directly, relying on callbacks for
that.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The implementation of i915_drm_buffer_get_handle now handles
DRM_API_HANDLE_TYPE_FD in the same way that intel_winsys_import_handle
does, by calling drm_intel_bo_gem_create_from_prime.
Tested by successfully running Chrome's ozone_demo [1] with the
ozone-gbm backend on an Intel Pineview M machine. Without this change
it fails while trying to create a DMA-BUF.
[1] https://chromium.googlesource.com/chromium/src.git/+/master/ui/ozone/demo/ozone_demo.cc
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
[Emil Velikov: Fix coding style]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Change dri2_query_image to check the return value of resource_get_handle
and return GL_FALSE if an error occurs.
For reference this is an example callstack that should propagate the
error back to the user:
i915_drm_buffer_get_handle
i915_texture_get_handle
u_resource_get_handle_vtbl
dri2_query_image
gbm_dri_bo_get_fd
gbm_bo_get_fd
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
[Emil Velikov: Split from larger patch, polish coding style, cc stable]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Change gbm_dri_bo_get_fd to check the return value of queryImage and
return -1 (an invalid file descriptor) if an error occurs.
Update the comment for gbm_bo_get_fd to return -1, since (apart from the
above) we've already return -1 on error.
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Nicholas Bishop <nbishop@neverware.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
[Emil Velikov: Split from larger patch, polish coding style, cc stable]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
VBR bitrate calc needs 64 bits at high rates.
v2: use float.
Signed-off-by: Andy Furniss <adf.lists@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: mesa-stable@lists.freedesktop.org
For now that's never since advanced blend hasn't been piped through.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Marek Olšák <marek.olsak@amd.com>
As part of the shader-cache work an upcoming change will add new
references to _mesa_add_parameter and _mesa_new_parameter_list from
the glsl code. To prepare for that, and to allow the standalone
glsl_compiler to still link, here we add mesa/program/prog_parameter.c
to the libglsl_util sources.
Then, in order to get *that* to work, we also add to stubs to
standalone_scaffolding:
_mesa_program_state_flags
_mesa_program_state_string
These functions aren't actually used by the two functions in
prog_parameter.c that we are actually calling. They are used in other
functions in the same file. So we don't care what the implementation
of these stubs is, (they won't be called by glsl_compiler). We just
need the stubs present so that it can link.
Signed-off-by: Timothy Arceri <timothy.arceri@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Support multi-planar YUV for external EGLImage's (currently just in the
dma-buf import path) by lowering to multiple texture fetch's for each
plane and CSC in shader.
There was some discussion of alternative approaches for tracking the
additional UV or U/V planes:
https://lists.freedesktop.org/archives/mesa-dev/2016-September/127832.html
They all seemed worse than pipe_resource::next
Signed-off-by: Rob Clark <robdclark@gmail.com>
Fixed the way the values that span two Dwords are decoded.
Based on the start and end indices of the field, the Dwords
are fetched and decoded accordingly.
v2: rename dw to qw in gen_field_iterator_next
and remove extra white space (Anuj)
v3: change all instances of dw to qw (Anuj)
Earlier, 64-bit fields (such as most pointers on Gen8+)
weren't decoded correctly. gen_field_iterator_next seemed
to walk one DWord at a time, sets v.dw, and then passes it
to field(). So, even though field() takes a uint64_t, we're
passing it a uint32_t (which gets promoted, so the top 32
bits will always be zero). This seems pretty bogus... (Ken)
Signed-off-by: Sirisha Gandikota <Sirisha.Gandikota@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This adds a new envvar called NV50_PROG_CHIPSET which allows to
compile shaders with a different target, especially useful for
shader-db.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
This allows to use hexadecimal numbers which are automatically
detected by strtol() when the base is 0.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Tested-by: Brian Paul <brianp@vmware.com>
Based off of Ilia's original patch, but with output values replicated so
that it matches the TGSI semantics.
Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
This is needed to be consistent with other drivers.
Signed-off-by: Emilio Cobos Álvarez <me@emiliocobos.me>
Reviewed-by: Brian Paul <brianp@vmware.com>
Usually, there's no user-specified texture swizzle so we can optimize
the swizzle_swizzle() function and skip the loop/switch.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Some demos, like Heaven, were creating and destroying a large number
of sampler views because of a swizzle issue.
Basically, we compute the sampler view's swizzle by examining the
texture format, user swizzle, depth mode, etc. Later, during validation
we recompute that swizzle (in case something like depth mode changes)
and see if it matches the view's swizzle.
In the case of PIPE_FORMAT_RGTC2_UNORM, get_texture_format_swizzle
returned SWIZZLE_XYZW but the u_sampler_view_default_template() function
was setting the sampler view's swizzle to SWIZZLE_XY01. This mismatch
caused the validation step to always "fail" so we'd destroy the old
sampler view and create a new one.
By removing the conditional, the sampler view's swizzle and the computed
texture swizzle match and validation "passes". When creating a new sampler
view, we always want to use the texture swizzle which we just computed.
Fixes VMware issue 1733389.
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Ian Romanick
Tim Rowley
Nicolai Hähnle
Nicholas Bishop
Andy Furniss
Mark Thompson
Timothy Arceri
Ilia Mirkin
Carl Worth
Samuel Pitoiset
Rob Clark
Sirisha Gandikota
Glenn Kennard
Nayan Deshmukh
Emilio Cobos Álvarez
Brian Paul