Performing a DCC decompression pass is currently pretty rare,
but using predication allows the GPU to skip unnecessary passes.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Use caps to obtain the multisample sample positions for up to 16
positions and implement the according Gallium interface.
This implemenation (plus its counterpart in virglrenderer) assume that
the fixed sample position are always the same for a given number of samples
over the whole live time of a qemu session. It also assumes that sample
series are only given for 2, 4, 8, and 16 samples, and for intermediate
numbers N of samples the next higher supported set from above list is picked
and the sample positions for the first N samples are returned accordingly.
Fixes (when run on GL host):
dEQP-GLES31.functional.texture.multisample.samples_1.sample_position
dEQP-GLES31.functional.texture.multisample.samples_2.sample_position
dEQP-GLES31.functional.texture.multisample.samples_3.sample_position
dEQP-GLES31.functional.texture.multisample.samples_4.sample_position
dEQP-GLES31.functional.texture.multisample.samples_8.sample_position
dEQP-GLES31.functional.texture.multisample.samples_10.sample_position
dEQP-GLES31.functional.texture.multisample.samples_12.sample_position
dEQP-GLES31.functional.texture.multisample.samples_13.sample_position
dEQP-GLES31.functional.texture.multisample.samples_16.sample_position
v2: remove unrelated chunk (thanks Ilia Mirkin)
v3: - also return positions for intermediate sample counts
- fix unused varible warning
- update description
v4: explain better what this patch assumes and how it handles sample numbers
that are not directly advertised (thanks go to Erik Faye-Lund for making
me aware that this should be documented)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
and PIPE_FORMAT_R8G8B8A8_SRGB, as well.
The reason for this is that when Virgl runs with GLES on the host, it
cannot directly upload textures in BGRA.
So to avoid a conversion step, consider the RGB sRGB formats as well for
this extension.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
If the driver doesn't support PIPE_FORMAT_B8G8R8A8_SRGB, fall back to
PIPE_FORMAT_R8G8B8A8_SRGB.
Drivers such as Virgl will have a hard time supporting
PIPE_FORMAT_B8G8R8A8_SRGB when the host runs GLES, as GL_BGRA isn't as
well suported there.
So go with PIPE_FORMAT_R8G8B8A8_SRGB so these drivers can avoid a
conversion copy.
v2: Fix typo in commit message
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
When Mesa itself implements ETC2 decompression, it currently
decompresses to formats in the GL_BGRA component order.
That can be problematic for drivers which cannot upload the texture data
as GL_BGRA, such as Virgl when it's backed by GLES on the host.
So this commit adds a flag to _mesa_unpack_etc2_format so callers can
specify the optimal component order.
In Gallium's case, it will be requested if the format isn't in
PIPE_FORMAT_B8G8R8A8_SRGB format.
For i965, it will remain GL_BGRA, as before.
v2: * Remove unnecesary include (Emil Velikov)
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Every time we emit a new state base address we will need to re-emit our
binding tables, since they might have been emitted with a different base
state adress.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
CC: <mesa-stable@lists.freedesktop.org>
If we have to re-emit push constant data, we need to re-emit all
of it.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
CC: <mesa-stable@lists.freedesktop.org>
v2: none
v3: none
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
CC: Marek Olšák <maraeo@gmail.com>
CC: Rhys Perry <pendingchaos02@gmail.com>
CC: Matt Turner <mattst88@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
v2: none
v3: none
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
CC: Marek Olšák <maraeo@gmail.com>
CC: Rhys Perry <pendingchaos02@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reuse code shared with mesa/main/texcompress_bptc.
v2: Use block decompress function
v3: Include static bptc code from texcompress_bptc_tmp.h
Suggested-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
CC: Nicolai Hähnle <nicolai.haehnle@amd.com>
CC: Marek Olšák <maraeo@gmail.com>
CC: Gert Wollny <gw.fossdev@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Shaders that need special code for external samplers were broken if
they were loaded from the cache.
Cc: 18.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
We need to add loop terminators to the list in the order we come
across them otherwise if two or more have the same exit condition
we will select that last one rather than the first one even though
its unreachable.
This fix is for simple unrolls where we only have a single exit
point. When unrolling these type of loops the unreachable
terminators and their unreachable branch are removed prior to
unrolling. Because of the logic change we also switch some
list access in the complex unrolling logic to avoid breakage.
Fixes: 6772a17acc ("nir: Add a loop analysis pass")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
The spec doesn't explicitly say to generate an error but since
DrawArraysInstanced* and DrawElementsInstanced* do, it makes
sense to do it for these functions also.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
The extension is enabled for compat profile but there is currently
no display list support.
I filed a spec bug and it has been agreed that
glDispatchComputeIndirect should generate an INVALID_OPERATION
error when called during display list compilation.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
this is required for Drivers which don't allow reading from outputs.
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Signed-off-by: Karol Herbst <kherbst@redhat.com>
We were overlapping it with the threadable/nan flags, resulting in
incorrect relocations (threadable/nan included in the offset) and wrong
ordering in the CLIF files.
The XML ends up noisier if you're only looking at one version, but from
the diffstat there's obvious wins in terms of deduplication. This will
get even more significant if we ever support 3.2 or 4.0.
The XML zipper wants one XML per version for filling out its tables, but
we want to do more than one GPU version per XML now. Assume that the
"gen" field will be the same as min_ver and look up our XML text assuming
that they're listed in increasing min_ver.
It turns out that most V3D versions change very few packets, so keeping
separate copies of the XML per version makes changing the XML a pain as
you have to replicate your changes to each one. This is the start of
changing it so that one XML can generate headers for multiple versions.
Running VK-CTS in batch execution mode was raising the
VK_ERROR_INITIALIZATION_FAILED error in multiple tests. But when the
same failing tests were run isolated they always passed.
createDevice and destroyDevice were called before and after every
tests. Because the binding_table_pool was never closed, we reached the
maximum number of open file descriptors (ulimit -n) and when that
happened every call to createDevice implied a
VK_ERROR_INITIALIZATION_FAILED error.
Fixes: c7db0ed4e9
("anv: Use a separate pool for binding tables when soft pinning")
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
