Starting with HALTI2 the RS supports 64bpp clears.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Update to etna_viv commit c51353e.
Signed-off-by: Christian GMEINER <christian.GMEINER@bachmann.info>
Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Now that SVGA doesn't have a table that has to be in PIPE_FORMAT
order, we can let the enums have whatever values they naturally would
without worrying about holes.
Acked-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Now that we're using the array initializers, we don't need to manually
fill out all these stub entries.
Produced with "sed -i '/.*INVALID.*INVALID.*INVALID/d'
src/gallium/drivers/svga/svga_format.c"
Acked-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
By using the [ ] = {} array initializer syntax, we no longer need the
entries to be listed in PIPE_FORMAT_* value order. This means that
people adding new gallium formats don't need to cargo-cult changes to
this driver or regress that non-unit-tested requirement.
While I'm here, drop the lines for formats that no longer exist (the
numbered ones in the table).
Acked-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Seemed like a sensible cleanup, while I was looking at whether I could
make the table sparse.
To make the svga table not require fixups on every new gallium format,
we may want to change how it's populated.
Acked-by: Jose Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
PIPE_FORMAT_YV12 is not handled so switching to PIPE_FORMAT_IYUV and
adding back YVU support.
Signed-off-by: James Xiong <james.xiong@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
PIPE_TIMEOUT_INFINITE is unsigned and gets assigned to signed fields
where it ends up as -1. When this reaches the kernel as a timeout it
gets translated as no timeout, which cause the waiting functions to
return immediately and not actually wait for a completion.
This seems to cause unstable results with lima where even piglit tests
randomly fail.
Handle this by setting the signed max value in case of infinite timeout.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
This method returns size_t, but the multiplication multiplies two
integers, leading to overflow rather than type widening.
Noticed by compiling with MSVC, which emits a warning.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
On Windows, p_atomic_inc_return returns an unsigned long long rather
than the type the pointer refers to, so let's make sure we cast the
result to the right type. Otherwise, we'll trigger a warning about
the wrong format-string for the type.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
There was two incompatible definitions of strcasecmp, which lead to a
compiler warning. Let's clean this up by only leaving one of them, and
using that one all the time.
Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Our hardware supports independent (per-RT) blending, but we need to
route those settings through from Gallium.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Fixes DATA_INVALID_FAULTs with multiple render targets.
We do always allocate space for 4 cbufs just to keep things sane. This
may not be strictly necessary.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
I don't think the hardware cares, but this adds a lot of noise to traces
that we would rather not need to look at.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
It doesn't... make a ton of sense to need to assert and this routine is
hotter than you might expect. Doesn't matter for release builds, of
course.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Fixes: 797a2e4fd0 ("etnaviv: update logic to determine uniform limits")
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Also this adds the missing impl for etna_dump_shader_nir(..).
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Jonathan Marek <jonathan@marek.ca>
Have a correct answer to GL_MAX_FRAGMENT_UNIFORM_VECTORS and
GL_MAX_VERTEX_UNIFORM_VECTORS.
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach l.stach@pengutronix.de
The flush callback may be called on the same pipe context, and thus
the same stream, from two different threads of execution. However,
etna_cmd_stream_flush{,2}() must not be called on the same stream
from two different threads of execution as that would mess up the
etna_bo refcounting and likely have other ugly side effects.
Fix this by using a reentrant screen lock around the flush callback.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Now we have an accessors for ppir src, so it's possible to easily
print all srcs and dests while dumping ppir representation.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Sometimes we need to walk through ppir_node sources, common
accessor for all node types will simplify code a lot.
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
The DRI interface for modifiers with aux data treats the aux data as a
separate plane of the main surface.
When the dri layer requests the plane associated with the aux data, we
save the required information into the dri aux plane image.
Later when the image is used, the dri plane image will be available in
the pipe_resource structure's `next` field. Therefore in iris, we
reconstruct the aux setup from this separate dri plane image when the
image is used.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reworks:
* If the aux-state is not ISL_AUX_STATE_AUX_INVALID, then use memset
even when memset_value is zero. The hiz buffer initial aux-state
will be set to invalid, and therefore we can skip the memset. But,
for CCS it will be set to ISL_AUX_STATE_PASS_THROUGH, and therefore
the aux data must be cleared to 0 with the memset. Previously we
would use BO_ALLOC_ZEROED with the CCS aux data, so this memset
wasn't required. Now, the CCS aux data may be part of the main
surface. We prefer to not use BO_ALLOC_ZEROED excessively, so the
memset is needed for the CCS case. (Nanley)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This is not currently required because the hiz buffer is in a separate
buffer, and therefore the offset is 0. If we combine the aux buffer
with the main surface buffer, then the hiz offset may become non-zero.
Suggested-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
We can't intersect with empty regions.
Fixes: 65ae86b854 ("panfrost: Add support for KHR_partial_update()")
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Midgard has no hardware support for transform feedback, so we simulate
it in software. Lucky us.
What Midgard does do is write out vertex shader outputs to main memory
unconditonally. Fragment shaders read varyings back from main memory;
there's no on-chip storage for varyings. Whether this was a reasonable
design is a question I will not be engaging in this commit message.
What that does mean is that, in some sense, Midgard *always* does
transform feedback uncondtionally, and there's no way to turn off
transform feedback. Normally, we would allocate some scratch memory
every frame to store the varyings in an arbitrary format (interleaved
for simplicity), and then feed that scratch to the fragment shader and
discard when the rendering completes.
The only difference now is that sometimes, for some buffers, we use a BO
provided to us by Gallium and a format provided by Gallium, instead of
allocating the memory and choosing the format ourselves. This has some
limitations -- in particular, it only works at vec4 granularity, so a
corresponding GLSL linkage patch is needed to correctly implement
transform feedback for non-vec4 types. Nevertheless, given the hardware
already works in this admittedly-bizarre fashion, transform feedback is
"free". Or, at least, it's no more expensive than any other rendering.
Specifically not implemented is dynamically-sized transform feedback
(i.e. with geometry/tesselation shaders).
Spoiler alert: Midgard has no support for geometry *or* tessellation
shaders, despite advertising support. They get compiled to *massive*
compute shaders. How's that for checkbox compliance?
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
We have to maintain the internal offset ourselves. Per v3d.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
We could probably get away with doing this once per pipe_shader_state
but let's not jump down that rabbit hole quite yet.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
