When a texture is mapped with the DISCARD_WHOLE_RESOURCE flag set,
v3d_map_usage_prep will try to allocate a new buffer for the resource.
Previously, if the resource was used in a bound texture then nothing
would cause it to update the sampler view with the offset for the new
buffer. This commit just adds that in by looking at all sampler views
and calling v3d_create_texture_shader_state_bo for each one that
references this resource.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6914>
This extracts the part of v3d_create_sampler_view that creates and fills
in the buffer for the TEXTURE_SHADER_STATE record into a helper
function. This will be used in a later patch to update the record when
the information changes.
v2: Also put the part that creates the buffer into the helper function
so that it won’t override the contents of an inflight buffer.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6914>
This moves the static function v3d_dirty_tex_state_for_shader_type from
v3dx_state.c to v3d_context.c and adds a declaration for it in the
header so that it can be used as a general utility function in a later
patch.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6914>
Fix defects reported by Coverity Scan.
uninit_member: Non-static class member insns is not initialized in this
constructor nor in any functions that it calls.
uninit_member: Non-static class member clipVertexOutput is not
initialized in this constructor nor in any functions that it calls.
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6769>
The android platform is not interested in this feature of Mesa. There are
currently workarounds for apps on Android, and no support for it in the
xmlconfig code. Even if there we do need workarounds eventually, we'll
want to bake them in as structs rather than have this awkward external
dependency for parsing user-readable data installed by Mesa for
Mesa-internal details.
This gets rid of the expat dependency in the turnip driver.
Note that rather than have more #ifdefs in the file, I've opted to move
the code to have more logical locations since the structs refactor had
left less-used helpers scattered across the file.
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6916>
We can generate the XML if anybody actually queries it, but this reduces
the amount of work in driver setup and means that we'll be able to support
driconf option queries on Android without libexpat.
This updates the driconf interface struct version for i965, i915, and
radeon to use the new getXml entrypoint to call the on-demand xml
generation. Note that our loaders (egl, glx) implement the v2 function
interface and don't use .xml when that's set, and the X server doesn't use
this interface at all.
XML generation tested on iris and i965 using adriconf
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6916>
The only user was radeon/r200, which was using it to have something that
looks a lot like an enum value return a float from the config option.
Just convert that option to a plain float value (for compat with existing
driconfs) with the min and max of its disjoint range as the range. The
driver's option handling code already correctly deals with other values in
the range.
The disjoint range support was a bunch of extra parsing for this dead
driver, and made turning driconf into static structs difficult.
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6916>
When I copied and pasted the code from MOV_INDIRECT for handling the
dependency controls, I missed a subtle difference between MOV_INDIRECT
and SHUFFLE. Specifically, MOV_INDIRECT gets lowered to a narrow
instruction on Gen7 by the SIMD width lowering whereas SHUFFLE has to
split it in the generator. Therefore, the check safety check for
whether or not we can use dependency control has to be based on the
lowered width rather than the width of the original instruction.
Fixes: a8ac61b0ee "intel/fs: NoMask initialize the address..."
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3593
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6989>
Fixes the following building errors:
external/mesa/src/intel/vulkan/anv_android.c:627: error: undefined reference to 'mesa_log'
...
external/mesa/src/intel/vulkan/anv_device.c:164: error: undefined reference to 'mesa_log'
Fixes: 13ea7db76 ("mesa: Promote Intel's simple logging façade for Android to util/")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Acked-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6972>
The volatile pattern gives me flaky results for 32-bit builds on
ChromeOS Android. This is because on 32-bit the volatile 64-bit
loads gets split into 2 32-bit loads each.
So if we read the lower dword first and then the upper dword, it
can happen that the upper dword is already changed but the lower
dword isn't yet. In particular for occlusion queries this gives
false readings, as the upper dword commonly only constains the
ready bit.
With the GCC atomic intrinsics we get a call to __atomic_load_8
in libatomic.so which does the right thing.
An alternative fix would be to explicitly split the 32-bit loads
in the right order and do a bunch of retries if things change, though
that gets messy quickly and for 32-bit builds only doesn't feel worth
it that much.
CC: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6933>
var->data.binding is only set for vulkan drivers (though it also will
get incremented after nir_lower_uniforms_to_ubo), so we have to generate
our own values here.
to do this, we iterate backwards over the ubos to account for the
"first" ubos being at the end of the list, and we must also ensure that we
remap the buffer index correctly based on whether we're running our
nir_lower_uniforms_to_ubo pass
note that running nir_lower_uniforms_to_ubo unconditionally would require
us to add a number of checks in this patch for !shader->num_uniforms in
order to properly adjust to the altered instructions which become 1-indexed
instead of 0-indexed when this pass is run with no uniforms present
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6981>
