To know when we're flushing the command buffer because we need to
write to surface in the command buffer.
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
In the rather unusual case of Bind + Delete, we need to make sure that
we unbind the current tf object.
Fixes dEQP-GLES3.functional.lifetime.delete_bound.transform_feedback
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This fixes a crash in
dEQP-GLES3.functional.transform_feedback.array_element.separate.points.lowp_mat3x2
and likely others. The vertex shader has > 16 input variables (without
explicit locations), which causes us to index outside of the to_assign
array.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Applications may create a *lot* of fences, perhaps as much as one per
vkQueueSubmit. Really, they're supposed to use ResetFence, but it's easy
enough for us to make them crazy-cheap so we might as well.
This simplifies the code that iterates over the per-component values
found in the matching copy_entry struct and checks whether the
register regions that were copied to each component are similar enough
to be treated as a single (reswizzled) value which can be propagated
into the current instruction.
Aside from being scattered between opt_copy_propagation(),
try_copy_propagate(), and try_constant_propagate(), what I found
terribly confusing about the preexisting logic was that
opt_copy_propagation() tried to reorder the array of values according
to the swizzle of the instruction source, which meant one would have
had to invert the reordering applied at the top level in order to find
out which component to take from each value (we were just taking the
i-th component from the i-th value, which is not correct in general).
The saturate mask was also being swizzled incorrectly.
This consolidates the logic for matching multiple components of a
copy_entry into a single function which returns the result as a
regular src_reg on success, as if the copy had been performed with a
single MOV instruction copying all components of the src_reg into the
destination.
Fixes several ARB_vertex_program MOV test-cases from:
https://cgit.freedesktop.org/~kwg/piglit/log/?h=arb_program
Acked-by: Matt Turner <mattst88@gmail.com>
Scalar immediates used to be handled correctly by swizzle() (as the
identity) but since commit 58fa9d47b5 it
will corrupt the contents of the immediate. Vector immediates were
never handled correctly, but we had ad-hoc code to swizzle VF
immediates in the vec4 copy propagation pass. This takes care of
swizzling V and UV in addition.
v2: Don't implement swizzling of V/UV immediates (Matt). If you need
to swizzle an integer vector immediate in the future apply the
following diff to go back to v1:
--- a/src/mesa/drivers/dri/i965/brw_eu.c
+++ b/src/mesa/drivers/dri/i965/brw_eu.c
@@ -119,11 +119,10 @@ brw_swap_cmod(uint32_t cmod)
static unsigned
imm_shift(enum brw_reg_type type, unsigned i)
{
- assert(type != BRW_REGISTER_TYPE_UV && type != BRW_REGISTER_TYPE_V &&
- "Not implemented.");
-
if (type == BRW_REGISTER_TYPE_VF)
return 8 * (i & 3);
+ else if (type == BRW_REGISTER_TYPE_UV || type == BRW_REGISTER_TYPE_V)
+ return 4 * (i & 7);
else
return 0;
}
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
And replace brw_swizzle1() with brw_swizzle(). Seems slightly cleaner
and will allow reusing brw_swizzle() in the vec4 back-end more easily.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This fixes some use-after-free situations in dEQP when an xfb state is
removed, and then a clear is triggered, which only does a partial
validation. It would attempt to read the no-longer-valid buffers,
resulting in crashes.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "11.1 11.2" <mesa-stable@lists.freedesktop.org>
Between the initial check the returns NO_KERNEL and compiling the
shader, other threads may have added the shader to the cache. Before
uploading the kernel, check again (under the mutex) that the compiled
shader still isn't present.
There is no API for setting the point size and the shader is always
required to set it. Section 24.4:
"If the value written to PointSize is less than or equal to zero, or
if no value was written to PointSize, results are undefined."
As such, we can just always program PointWidthSource to Vertex. This
simplifies anv_pipeline a bit and avoids trouble when we enable the
pipeline cache and don't have writes_point_size in the prog_data.
Using anv_pipeline_cache_upload_kernel() will re-upload the kernel and
prog_data when we merge caches. Since the kernel and prog_data is
already in the program_stream, use anv_pipeline_cache_add_entry()
instead to only add the entry to the hash table.
This function is a helper that unconditionally sets a hash table entry
and expects the cache to have enough room. Calling it 'add_entry'
suggests it will grow the cache as needed.
We can serialize as much as the application asks for and just stop once
we run out of memory. This lets applications use a fixed amount of
space for caching and still get some benefit.
compute.c: In function ‘launch_grid’:
compute.c:435:20: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]
info.input = input;
^
Maybe the pipe_grid_info::input field should be const void *?
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
