This field is ignored for tf writes so should be 0.
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Looks like the decompress does not handle invalid encodings well,
which happens with random memory. Of course apps should not use it
with random memory, but they are allowed to ....
Fixes: 44fcf58744 "radv: Disable DCC for GENERAL layout and compute transfer dest."
Reviewed-by: Dave Airlie <airlied@redhat.com>
Now that we have two of these, we're duplicating a bunch of this logic.
The next commit will add more logic, which would make the duplication
seem worse.
This ends up setting EXEC_OBJECT_CAPTURE on the batch, which isn't
necessary (it's already captured), but it should be harmless.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Having a boolean for "we're using malloc'd shadow copies for all
buffers" is cleaner than having a cpu_map pointer for each. It was
okay when we had one buffer, but this is more obvious.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Previously the dataflow propagation algorithm would calculate the ACP
live-in and -out sets in a two-pass fixed-point algorithm. The first
pass would update the live-out sets of all basic blocks of the program
based on their live-in sets, while the second pass would update the
live-in sets based on the live-out sets. This is incredibly
inefficient in the typical case where the CFG of the program is
approximately acyclic, because it can take up to 2*n passes for an ACP
entry introduced at the top of the program to reach the bottom (where
n is the number of basic blocks in the program), until which point the
algorithm won't be able to reach a fixed point.
The same effect can be achieved in a single pass by computing the
live-in and -out sets in lock-step, because that makes sure that
processing of any basic block will pick up the updated live-out sets
of the lexically preceding blocks. This gives the dataflow
propagation algorithm effectively O(n) run-time instead of O(n^2) in
the acyclic case.
The time spent in dataflow propagation is reduced by 30x in the
GLES31.functional.ssbo.layout.random.all_shared_buffer.5 dEQP
test-case on my CHV system (the improvement is likely to be of the
same order of magnitude on other platforms). This more than reverses
an apparent run-time regression in this test-case from my previous
copy-propagation undefined-value handling patch, which was ultimately
caused by the additional work introduced in that commit to account for
undefined values being multiplied by a huge quadratic factor.
According to Chad this test was failing on CHV due to a 30s time-out
imposed by the Android CTS (this was the case regardless of my
undefined-value handling patch, even though my patch substantially
exacerbated the issue). On my CHV system this patch reduces the
overall run-time of the test by approximately 12x, getting us to
around 13s, well below the time-out.
v2: Initialize live-out set to the universal set to avoid rather
pessimistic dataflow estimation in shaders with cycles (Addresses
performance regression reported by Eero in GpuTest Piano).
Performance numbers given above still apply. No shader-db changes
with respect to master.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104271
Reported-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Both state->prog->info.inputs_read and state->InputsBound are GLbitfield64
so it seems that the OR of those values should be of the same type.
I'm not sure this fixes any actual issues though.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
v2: add some const qualifiers, per Ian.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Make the code a bit more concise.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The values will never be larger than VBO_ATTRIB_MAX (currently 44).
v2: add STATIC_ASSERT to be sure VBO_ATTRIB_MAX can fit in ubyte,
per Emil.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Both switch cases began with the same code.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
The vbo_save_vertex_list structure records one or more glBegin/End
primitives which all have the same vertex format.
To draw these primitives, we setup the vertex array state, then
issue the drawing command. Before, the 'start' vertex was typically
zero and we used the vertex array pointer to indicate where the
vertex data starts.
This patch checks if the vertex buffer offset is an exact multiple of
the vertex size. If so, that means we can use zero-based vertex array
pointers and use the draw's start value to indicate where the vertex
data starts.
This means a series of display list drawing commands may have
identical vertex array state. This will get filtered out by the
Gallium CSO module so we can issue a tight series of drawing commands
without state changes to the device.
Note that this also works for a series of glCallList commands (not
just one list that contains multiple glBegin/End pairs).
No Piglit or conform changes.
v2: minor fixes suggested by Ian.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Using a plural name makes it easier to see that this is an array and
not a pointer to a single object.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
