The extra bits in CB_SHADER_MASK break dual source blending in
SkQP on a Stoney device. However:
- As far as I can tell, some other dual source blend tests are passing
before and after the change.
- A hacked around skqp passes on my Vega desktop and Raven laptop
- Getting Skqp to give any useful info or to run it outside of Android
on ChromeOS is proving difficult.
I have confirmed 3 strategies that seem to work:
- The old radv behavior of setting CB_SHADER_MASK to 0xF
- AMDVLK: CB_SHADER_MASK = 0xFF, and the 3 RB+ regs
are 0.
- radeonsi: CB_SHADER_MASK = 0xFF, but does not set DISABLE
bits in SX_BLEND_OPT_CONTROL for CB 1-7.
Let us use the radeonsi solution as that solution also seems like the correct
thing to do for holes. I have tested on my Raven laptop that setting the high
surfaces to not disabled and downconvert to 32_R does not imply a performance
penalty.
Fixes: e9316fdfd4 "radv: fix setting CB_SHADER_MASK for dual source blending"
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3670>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3670>
The same pattern kept coming up, and we don't need to hit
util_format_write_4* to do it when we have util_format_pack_rgba().
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2744>
We always want the same behavior of choosing which unpack to do to
generate our 4x32-bit RGBA values, so just sink that choice down below
the pipe_get/put_tile API.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2744>
The previous caller wasn't using it as tiled, just row-at-a-time, and
didn't want the clipping (since copytexsubimage comes in clipped). If
someone wanted these functions again in the future, they should be
rewritten on u_format_pack/unpack.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2744>
Almost all users of the unpack functions don't have strides to plug in
(and many are only doing one pixel!), and this will help simplify
them.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2744>
It's not adding 2.0 features, but it's enough to run the 2.0 CTS on top of
clover and probably most CL applications using it.
We just fail if we hit unknown properties and that's probably good enough
until we implement the other bits properly.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Pierre Moreau <dev@pmoreau.org>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2370>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2370>
Move expected values/bpp into the test params, add more formats now that
we've fixed context setup so that they work.
Reviewed-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3216>
OSMesa is weird and you only get the type (byte/ubyte/565/etc.) at
MakeCurrent time, having only a channel order at CreateContext time. The
code was setting up a visual at CreateContext time, and then at
MakeCurrent it would fail to validate against the visual.
Reviewed-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3216>
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/2464
Fixes: e62c3cf350 ("util/os_socket: Include unistd.h to fix build error")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Krzysztof Raszkowski <krzysztof.raszkowski@intel.com>
Otherwise there will be a warning:
"libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering."
Happens with EGL_KHR_surfaceless_context:
eglMakeCurrent(egl_display, EGL_NO_SURFACE, EGL_NO_SURFACE, egl_context)
eglMakeCurrent(egl_display, egl_surface, egl_surface, egl_context)
glFlush() // Here will be a warning
Cc: <mesa-stable@lists.freedesktop.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1525
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3628>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3628>
Previously, we were using cubemap_stride and sometimes overwriting other
BOs such as shaders.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3692>
Otherwise, we may be incrementing max_lod over the limit, causing a
DATA_INVALID_FAULT.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3692>
From decoding cmd streams generated by the blob, the pointers in the
payload don't seem to include those that refer to different depth levels
when the texture is in tiled format.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3692>
Destroy rsc->pending_ctx set in etna_resource_destroy(), otherwise
the memory is allocated, never free'd, and becomes unreachable. This
fixes a memory leak.
Fixes: 9e672e4d20 ("etnaviv: keep references to pending resources")
Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3633>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3633>
Clang has a warning about overloading virtuals that triggers when a
derived class defines a virtual function that's an overload of
function in the base class. This kind of thing:
struct chart; // let's pretend this exists
struct Base
{
virtual void* get(char* e);
};
struct Derived: public Base {
virtual void* get(chart* e); // typo, we wanted to override the same function
};
The solution is to use
using Base::get;
to be explicit about the intention to reuse the base class virtual.
We hit this a lot with out glsl ir_hierarchical_visitor visitor
pattern, so let's adds some 'using' to calm down the compiler.
See-also: https://stackoverflow.com/questions/18515183/c-overloaded-virtual-function-warning-by-clang)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3686>
