[Mesa-dev] [Bug 110724] Unhandled GL format: 0x8058
https://bugs.freedesktop.org/show_bug.cgi?id=110724 Tapani Pälli changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #7 from Tapani Pälli --- Alberto, I read discussion in rpcs3/issue and it looks like this happened due to installation issue. Based on this I'm resolving this as NOTABUG. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 0/2] Alternate default config mechanism
On 5/23/19 8:22 PM, Sumit Semwal wrote: Hi Eric, On Thu, 23 May 2019 at 20:25, Eric Engestrom wrote: On Thursday, 2019-05-23 08:34:40 +0300, Tapani Pälli wrote: Hi; On 5/22/19 9:20 PM, Alistair Strachan wrote: On Tue, May 21, 2019 at 10:10 PM Tapani Pälli wrote: On 5/21/19 4:53 PM, Sumit Semwal wrote: Hello everyone, First up, my apologies on not being able to respond earlier; secondly, thanks very much for your review. On Wed, 15 May 2019 at 19:27, Emil Velikov wrote: Hi all, On Tue, 14 May 2019 at 08:18, Tapani Pälli wrote: On 5/13/19 6:52 PM, Haehnle, Nicolai wrote: This approach seems entirely incompatible with si_debug_options.h, and will be an absolute maintenance nightmare going forward for adding / removing options, because you're introducing a second location where options are defined. Quite frankly, this seems like a terrible idea as-is. If you really can't use XML for whatever reason, then please find some way of deriving both the tables here and the XML from the same single source of truth. I was looking at this yesterday and came up with same conclusion. We should have the options in one place. Currently libexpat is statically linked with Android >=O, maybe for such restricted environments we could just inline the xml as is at compile time and parse that later or alternatively (maybe cleaner) parse and generate default option cache already during compilation? I realise that jumping the "me too" train does not help much, so here are some alternative ideas. How about we first distil the reasons why this is a problem and what kind. Then explore independent solution for each one - as-is this seems like a one-size-fits-all approach. I totally agree that this seems like a rudimentary / ugly approach, and we can definitely improve upon it once the reasons are discussed. Some examples: - XML file may be inaccessible - the in-driver defaults should work(tm) Yes there are some app specific ones, yet neither(?) of these apps is present on Android - libexpat is not available, but libFOO is - investigate into a compat wrapper - cannot use external libraries (libexpat or equivalent) - static link AFAIU, in the Android space, it is a combination of some of the above: a. current Android doesn't allow GL drivers to access config files from the vendor partition: this is enforced via selinux policy. For point a, vendors can (and should) define their own policy rules regarding what file access and ioctl's are required. This is done by setting BOARD_SEPOLICY_DIRS in BoardConfig.mk file. That directory then contains all the necessary rules required for the particular driver to work. As example: BOARD_SEPOLICY_DIRS += device/samsung/tuna/sepolicy If a vendor wanted to use xml based configuration for Mesa it should be possible by setting a sepolicy rule so that particular library is able to access such file. Looking at Android Celadon selinux files, 'file_contexts' is probably the place to do it. The EGL/GLES driver stack is a special kind of HAL in Android (same-process HAL) so we have to be very careful about expanding the sepolicy rules to work around unnecessary file accesses. We also have strict sepolicy "neverallows" for untrusted apps (the processes this same-process HAL might be loaded into). I strongly disagree with your suggestion here. From an Android PoV, the EGL/GLES drivers should minimize their dependencies so as to not affect other NDK libraries loaded into the app processes. They should also limit interactions with the rest of the system, such as opening configuration files. It's clear that Mesa can work just fine without reading a configuration file, and that the use case of opening a configuration file should only be necessary for development and bring-up. The discussion so far on this thread seems to be optimizing for Mesa's configuration file, rather than for security and file size. On an embedded platform such as Android, in cases where Mesa might ship in a production configuration, there should be no configuration file, and we would want vendors to optimize for security and file size. My opinion is that we need Sumit's changes, or something like them. Pulling in libexpat just to build internal configuration state from a built-in XML file seems quite over-engineered. That said, I agree with other feedback on this thread that it should be possible to derive the baked configuration from the same source of truth (possibly an XML file) as another platform which might not have a baked configuration. b. Also, they had some concerns around how safe libexpat is vis-a-vis dual-loading, and that's where the concern around static linking came from. Alistair, could you please correct me if I am wrong, and if there are additional details on the need of this? The concern is basically that libexpat might be "dual loaded" - by the linker namespace for the sphal, and that of the app itself - and that there might be global data (like pthread
Re: [Mesa-dev] [RFC PATCH] nir/algebraic: Simplify max(abs(a), 0.0) -> abs(a)
How does max(NaN, 0) work? IIRC there's some provision that this
becomes 0, while abs(NaN) = NaN.
On Thu, May 23, 2019 at 10:47 PM Alyssa Rosenzweig wrote:
>
> I noticed this pattern in glmark's jellyfish scene.
>
> Assuming this is correct (it should be...?), could someone do a
> shader-db run? Thank you!
>
> Signed-off-by: Alyssa Rosenzweig
> Cc: Ian Romanick
> ---
> src/compiler/nir/nir_opt_algebraic.py | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/compiler/nir/nir_opt_algebraic.py
> b/src/compiler/nir/nir_opt_algebraic.py
> index 89d07aa1261..abd0b6591ce 100644
> --- a/src/compiler/nir/nir_opt_algebraic.py
> +++ b/src/compiler/nir/nir_opt_algebraic.py
> @@ -377,6 +377,7 @@ optimizations = [
> (('imax', a, a), a),
> (('umin', a, a), a),
> (('umax', a, a), a),
> + (('fmax', ('fabs', a), 0.0), ('fabs', a)),
> (('fmax', ('fmax', a, b), b), ('fmax', a, b)),
> (('umax', ('umax', a, b), b), ('umax', a, b)),
> (('imax', ('imax', a, b), b), ('imax', a, b)),
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC PATCH] nir/algebraic: Simplify max(abs(a), 0.0) -> abs(a)
I noticed this pattern in glmark's jellyfish scene.
Assuming this is correct (it should be...?), could someone do a
shader-db run? Thank you!
Signed-off-by: Alyssa Rosenzweig
Cc: Ian Romanick
---
src/compiler/nir/nir_opt_algebraic.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index 89d07aa1261..abd0b6591ce 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -377,6 +377,7 @@ optimizations = [
(('imax', a, a), a),
(('umin', a, a), a),
(('umax', a, a), a),
+ (('fmax', ('fabs', a), 0.0), ('fabs', a)),
(('fmax', ('fmax', a, b), b), ('fmax', a, b)),
(('umax', ('umax', a, b), b), ('umax', a, b)),
(('imax', ('imax', a, b), b), ('imax', a, b)),
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] scons: fix build with llvm 9.
From: Roland Scheidegger
The x86asmprinter component is gone, and things seem to work by just
removing it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110707
---
scons/llvm.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scons/llvm.py b/scons/llvm.py
index a84ad51d97a..bf9666459c6 100644
--- a/scons/llvm.py
+++ b/scons/llvm.py
@@ -260,7 +260,10 @@ def generate(env):
if '-fno-rtti' in cxxflags:
env.Append(CXXFLAGS = ['-fno-rtti'])
-components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter',
'mcdisassembler', 'irreader']
+if llvm_version < distutils.version.LooseVersion('9.0'):
+ components = ['engine', 'mcjit', 'bitwriter', 'x86asmprinter',
'mcdisassembler', 'irreader']
+else:
+ components = ['engine', 'mcjit', 'bitwriter', 'mcdisassembler',
'irreader']
env.ParseConfig('%s --libs ' % llvm_config + ' '.join(components))
env.ParseConfig('%s --ldflags' % llvm_config)
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: fix default cbuf info.
From: Roland Scheidegger
The default null_output really needs to be static, otherwise the values
we'll eventually get later are doubly random (they are not initialized,
and even if they were it's a pointer to a local stack variable).
VMware bug 2349556.
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
index b4e3c2fbc8..9fc9b8c77e 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
@@ -608,7 +608,7 @@ finished:
*/
for (index = 0; index < PIPE_MAX_COLOR_BUFS; ++index) {
- const struct lp_tgsi_channel_info null_output[4];
+ static const struct lp_tgsi_channel_info null_output[4];
info->cbuf[index] = null_output;
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 0/2] Alternate default config mechanism
Hi Eric, On Thu, 23 May 2019 at 20:25, Eric Engestrom wrote: > > On Thursday, 2019-05-23 08:34:40 +0300, Tapani Pälli wrote: > > Hi; > > > > On 5/22/19 9:20 PM, Alistair Strachan wrote: > > > On Tue, May 21, 2019 at 10:10 PM Tapani Pälli > > > wrote: > > > > > > > > > > > > On 5/21/19 4:53 PM, Sumit Semwal wrote: > > > > > Hello everyone, > > > > > > > > > > First up, my apologies on not being able to respond earlier; secondly, > > > > > thanks very much for your review. > > > > > > > > > > On Wed, 15 May 2019 at 19:27, Emil Velikov > > > > > wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > On Tue, 14 May 2019 at 08:18, Tapani Pälli > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On 5/13/19 6:52 PM, Haehnle, Nicolai wrote: > > > > > > > > This approach seems entirely incompatible with > > > > > > > > si_debug_options.h, and > > > > > > > > will be an absolute maintenance nightmare going forward for > > > > > > > > adding / > > > > > > > > removing options, because you're introducing a second location > > > > > > > > where > > > > > > > > options are defined. > > > > > > > > > > > > > > > > Quite frankly, this seems like a terrible idea as-is. > > > > > > > > > > > > > > > > If you really can't use XML for whatever reason, then please > > > > > > > > find some > > > > > > > > way of deriving both the tables here and the XML from the same > > > > > > > > single > > > > > > > > source of truth. > > > > > > > > > > > > > > I was looking at this yesterday and came up with same conclusion. > > > > > > > We > > > > > > > should have the options in one place. Currently libexpat is > > > > > > > statically > > > > > > > linked with Android >=O, maybe for such restricted environments > > > > > > > we could > > > > > > > just inline the xml as is at compile time and parse that later or > > > > > > > alternatively (maybe cleaner) parse and generate default option > > > > > > > cache > > > > > > > already during compilation? > > > > > > > > > > > > > I realise that jumping the "me too" train does not help much, so > > > > > > here > > > > > > are some alternative ideas. > > > > > > > > > > > > How about we first distil the reasons why this is a problem and what > > > > > > kind. Then explore independent solution for each one - as-is this > > > > > > seems like a one-size-fits-all approach. > > > > > I totally agree that this seems like a rudimentary / ugly approach, > > > > > and we can definitely improve upon it once the reasons are discussed. > > > > > > > > > > > Some examples: > > > > > >- XML file may be inaccessible - the in-driver defaults should > > > > > > work(tm) > > > > > > Yes there are some app specific ones, yet neither(?) of these apps > > > > > > is > > > > > > present on Android > > > > > >- libexpat is not available, but libFOO is - investigate into a > > > > > > compat wrapper > > > > > >- cannot use external libraries (libexpat or equivalent) - > > > > > > static link > > > > > > > > > > > > > > > > AFAIU, in the Android space, it is a combination of some of the above: > > > > > a. current Android doesn't allow GL drivers to access config files > > > > > from the vendor partition: this is enforced via selinux policy. > > > > > > > > For point a, vendors can (and should) define their own policy rules > > > > regarding what file access and ioctl's are required. This is done by > > > > setting BOARD_SEPOLICY_DIRS in BoardConfig.mk file. That directory then > > > > contains all the necessary rules required for the particular driver to > > > > work. As example: > > > > > > > > BOARD_SEPOLICY_DIRS += device/samsung/tuna/sepolicy > > > > > > > > If a vendor wanted to use xml based configuration for Mesa it should be > > > > possible by setting a sepolicy rule so that particular library is able > > > > to access such file. Looking at Android Celadon selinux files, > > > > 'file_contexts' is probably the place to do it. > > > > > > The EGL/GLES driver stack is a special kind of HAL in Android > > > (same-process HAL) so we have to be very careful about expanding the > > > sepolicy rules to work around unnecessary file accesses. We also have > > > strict sepolicy "neverallows" for untrusted apps (the processes this > > > same-process HAL might be loaded into). I strongly disagree with your > > > suggestion here. > > > > > > From an Android PoV, the EGL/GLES drivers should minimize their > > > dependencies so as to not affect other NDK libraries loaded into the > > > app processes. They should also limit interactions with the rest of > > > the system, such as opening configuration files. It's clear that Mesa > > > can work just fine without reading a configuration file, and that the > > > use case of opening a configuration file should only be necessary for > > > development and bring-up. > > > > > > The discussion so far on this thread seems to be optimizing for Mesa's > > > configuration file, rather than for security and file size. On an > > >
Re: [Mesa-dev] [PATCH] svga: clamp max_const_buffers to SVGA_MAX_CONST_BUFS
Reviewed-by: Charmaine Lee From: Brian Paul Sent: Monday, May 20, 2019 6:36:33 AM To: mesa-dev@lists.freedesktop.org Cc: Neha Bhende; Charmaine Lee Subject: [PATCH] svga: clamp max_const_buffers to SVGA_MAX_CONST_BUFS In case the device reports 15 (or more) buffers. --- src/gallium/drivers/svga/svga_screen.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/svga/svga_screen.c b/src/gallium/drivers/svga/svga_screen.c index 02c1a99..b70fd85 100644 --- a/src/gallium/drivers/svga/svga_screen.c +++ b/src/gallium/drivers/svga/svga_screen.c @@ -1079,7 +1079,8 @@ svga_screen_create(struct svga_winsys_screen *sws) /* Maximum number of constant buffers */ svgascreen->max_const_buffers = get_uint_cap(sws, SVGA3D_DEVCAP_DX_MAX_CONSTANT_BUFFERS, 1); - assert(svgascreen->max_const_buffers <= SVGA_MAX_CONST_BUFS); + svgascreen->max_const_buffers = MIN2(svgascreen->max_const_buffers, + SVGA_MAX_CONST_BUFS); screen->is_format_supported = svga_is_dx_format_supported; } -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: silence three compiler warnings seen with MinGW
Reviewed-by: Kristian H. Kristensen
On Thu, May 23, 2019 at 9:52 AM Brian Paul wrote:
>
> Ping.
>
> -Brian
>
> On 05/20/2019 07:36 AM, Brian Paul wrote:
> > Silence two unused var warnings. And init elem_size, elem_align to
> > zero to silence "maybe uninitialized" warnings.
> > ---
> > src/compiler/nir/nir_lower_int_to_float.c | 2 +-
> > src/compiler/nir/nir_opt_copy_prop_vars.c | 4 +---
> > src/compiler/nir_types.cpp| 2 +-
> > 3 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/compiler/nir/nir_lower_int_to_float.c
> > b/src/compiler/nir/nir_lower_int_to_float.c
> > index 439afa0..66a740d9 100644
> > --- a/src/compiler/nir/nir_lower_int_to_float.c
> > +++ b/src/compiler/nir/nir_lower_int_to_float.c
> > @@ -28,7 +28,7 @@
> > static bool
> > assert_ssa_def_is_not_int(nir_ssa_def *def, void *arg)
> > {
> > - BITSET_WORD *int_types = arg;
> > + MAYBE_UNUSED BITSET_WORD *int_types = arg;
> > assert(!BITSET_TEST(int_types, def->index));
> > return true;
> > }
> > diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c
> > b/src/compiler/nir/nir_opt_copy_prop_vars.c
> > index 94bc8af..0fd96b7 100644
> > --- a/src/compiler/nir/nir_opt_copy_prop_vars.c
> > +++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
> > @@ -433,9 +433,7 @@ load_element_from_ssa_entry_value(struct
> > copy_prop_var_state *state,
> > nir_builder *b, nir_intrinsic_instr
> > *intrin,
> > struct value *value, unsigned index)
> > {
> > - const struct glsl_type *type = entry->dst->type;
> > - unsigned num_components = glsl_get_vector_elements(type);
> > - assert(index < num_components);
> > + assert(index < glsl_get_vector_elements(entry->dst->type));
> >
> > /* We don't have the element available, so let the instruction do the
> > work. */
> > if (!entry->src.ssa.def[index])
> > diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> > index 3bf93c5..e2dfc40 100644
> > --- a/src/compiler/nir_types.cpp
> > +++ b/src/compiler/nir_types.cpp
> > @@ -630,7 +630,7 @@ glsl_get_natural_size_align_bytes(const struct
> > glsl_type *type,
> > *size = 0;
> > *align = 0;
> > for (unsigned i = 0; i < type->length; i++) {
> > - unsigned elem_size, elem_align;
> > + unsigned elem_size = 0, elem_align = 0;
> >glsl_get_natural_size_align_bytes(type->fields.structure[i].type,
> > _size, _align);
> >*align = MAX2(*align, elem_align);
> >
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] nir: silence three compiler warnings seen with MinGW
Ping.
-Brian
On 05/20/2019 07:36 AM, Brian Paul wrote:
Silence two unused var warnings. And init elem_size, elem_align to
zero to silence "maybe uninitialized" warnings.
---
src/compiler/nir/nir_lower_int_to_float.c | 2 +-
src/compiler/nir/nir_opt_copy_prop_vars.c | 4 +---
src/compiler/nir_types.cpp| 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir_lower_int_to_float.c
b/src/compiler/nir/nir_lower_int_to_float.c
index 439afa0..66a740d9 100644
--- a/src/compiler/nir/nir_lower_int_to_float.c
+++ b/src/compiler/nir/nir_lower_int_to_float.c
@@ -28,7 +28,7 @@
static bool
assert_ssa_def_is_not_int(nir_ssa_def *def, void *arg)
{
- BITSET_WORD *int_types = arg;
+ MAYBE_UNUSED BITSET_WORD *int_types = arg;
assert(!BITSET_TEST(int_types, def->index));
return true;
}
diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c
b/src/compiler/nir/nir_opt_copy_prop_vars.c
index 94bc8af..0fd96b7 100644
--- a/src/compiler/nir/nir_opt_copy_prop_vars.c
+++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
@@ -433,9 +433,7 @@ load_element_from_ssa_entry_value(struct
copy_prop_var_state *state,
nir_builder *b, nir_intrinsic_instr *intrin,
struct value *value, unsigned index)
{
- const struct glsl_type *type = entry->dst->type;
- unsigned num_components = glsl_get_vector_elements(type);
- assert(index < num_components);
+ assert(index < glsl_get_vector_elements(entry->dst->type));
/* We don't have the element available, so let the instruction do the work. */
if (!entry->src.ssa.def[index])
diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
index 3bf93c5..e2dfc40 100644
--- a/src/compiler/nir_types.cpp
+++ b/src/compiler/nir_types.cpp
@@ -630,7 +630,7 @@ glsl_get_natural_size_align_bytes(const struct glsl_type
*type,
*size = 0;
*align = 0;
for (unsigned i = 0; i < type->length; i++) {
- unsigned elem_size, elem_align;
+ unsigned elem_size = 0, elem_align = 0;
glsl_get_natural_size_align_bytes(type->fields.structure[i].type,
_size, _align);
*align = MAX2(*align, elem_align);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110357] [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 --- Comment #3 from Eric Engestrom --- (In reply to Juan A. Suarez from comment #2) > This bug is a blocker for 19.1.0. Is reverting dacb11a585 enough to fix the issue? If so, I'd suggest doing that, and a new attempt can land after however long it takes. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110357] [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 Eric Engestrom changed: What|Removed |Added CC||fdo-b...@engestrom.ch -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110357] [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 Kenneth Graunke changed: What|Removed |Added CC||intel-3d-bugs@lists.freedes ||ktop.org -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110357] [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in new attempted "41" configuration
https://bugs.freedesktop.org/show_bug.cgi?id=110357 Kenneth Graunke changed: What|Removed |Added Component|Drivers/DRI/i965|EGL Assignee|intel-3d-bugs@lists.freedes |mesa-dev@lists.freedesktop. |ktop.org|org QA Contact|intel-3d-bugs@lists.freedes |mesa-dev@lists.freedesktop. |ktop.org|org -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 0/2] Alternate default config mechanism
On Thursday, 2019-05-23 08:34:40 +0300, Tapani Pälli wrote: > Hi; > > On 5/22/19 9:20 PM, Alistair Strachan wrote: > > On Tue, May 21, 2019 at 10:10 PM Tapani Pälli > > wrote: > > > > > > > > > On 5/21/19 4:53 PM, Sumit Semwal wrote: > > > > Hello everyone, > > > > > > > > First up, my apologies on not being able to respond earlier; secondly, > > > > thanks very much for your review. > > > > > > > > On Wed, 15 May 2019 at 19:27, Emil Velikov > > > > wrote: > > > > > > > > > > Hi all, > > > > > > > > > > On Tue, 14 May 2019 at 08:18, Tapani Pälli > > > > > wrote: > > > > > > > > > > > > > > > > > > On 5/13/19 6:52 PM, Haehnle, Nicolai wrote: > > > > > > > This approach seems entirely incompatible with > > > > > > > si_debug_options.h, and > > > > > > > will be an absolute maintenance nightmare going forward for > > > > > > > adding / > > > > > > > removing options, because you're introducing a second location > > > > > > > where > > > > > > > options are defined. > > > > > > > > > > > > > > Quite frankly, this seems like a terrible idea as-is. > > > > > > > > > > > > > > If you really can't use XML for whatever reason, then please find > > > > > > > some > > > > > > > way of deriving both the tables here and the XML from the same > > > > > > > single > > > > > > > source of truth. > > > > > > > > > > > > I was looking at this yesterday and came up with same conclusion. We > > > > > > should have the options in one place. Currently libexpat is > > > > > > statically > > > > > > linked with Android >=O, maybe for such restricted environments we > > > > > > could > > > > > > just inline the xml as is at compile time and parse that later or > > > > > > alternatively (maybe cleaner) parse and generate default option > > > > > > cache > > > > > > already during compilation? > > > > > > > > > > > I realise that jumping the "me too" train does not help much, so here > > > > > are some alternative ideas. > > > > > > > > > > How about we first distil the reasons why this is a problem and what > > > > > kind. Then explore independent solution for each one - as-is this > > > > > seems like a one-size-fits-all approach. > > > > I totally agree that this seems like a rudimentary / ugly approach, > > > > and we can definitely improve upon it once the reasons are discussed. > > > > > > > > > Some examples: > > > > >- XML file may be inaccessible - the in-driver defaults should > > > > > work(tm) > > > > > Yes there are some app specific ones, yet neither(?) of these apps is > > > > > present on Android > > > > >- libexpat is not available, but libFOO is - investigate into a > > > > > compat wrapper > > > > >- cannot use external libraries (libexpat or equivalent) - static > > > > > link > > > > > > > > > > > > > AFAIU, in the Android space, it is a combination of some of the above: > > > > a. current Android doesn't allow GL drivers to access config files > > > > from the vendor partition: this is enforced via selinux policy. > > > > > > For point a, vendors can (and should) define their own policy rules > > > regarding what file access and ioctl's are required. This is done by > > > setting BOARD_SEPOLICY_DIRS in BoardConfig.mk file. That directory then > > > contains all the necessary rules required for the particular driver to > > > work. As example: > > > > > > BOARD_SEPOLICY_DIRS += device/samsung/tuna/sepolicy > > > > > > If a vendor wanted to use xml based configuration for Mesa it should be > > > possible by setting a sepolicy rule so that particular library is able > > > to access such file. Looking at Android Celadon selinux files, > > > 'file_contexts' is probably the place to do it. > > > > The EGL/GLES driver stack is a special kind of HAL in Android > > (same-process HAL) so we have to be very careful about expanding the > > sepolicy rules to work around unnecessary file accesses. We also have > > strict sepolicy "neverallows" for untrusted apps (the processes this > > same-process HAL might be loaded into). I strongly disagree with your > > suggestion here. > > > > From an Android PoV, the EGL/GLES drivers should minimize their > > dependencies so as to not affect other NDK libraries loaded into the > > app processes. They should also limit interactions with the rest of > > the system, such as opening configuration files. It's clear that Mesa > > can work just fine without reading a configuration file, and that the > > use case of opening a configuration file should only be necessary for > > development and bring-up. > > > > The discussion so far on this thread seems to be optimizing for Mesa's > > configuration file, rather than for security and file size. On an > > embedded platform such as Android, in cases where Mesa might ship in a > > production configuration, there should be no configuration file, and > > we would want vendors to optimize for security and file size. > > > > My opinion is that we need Sumit's changes, or something like them. > >
[Mesa-dev] [PATCH] radv: always dirty the framebuffer when restoring a subpass
The old code was not wrong because the transitions performed
after the resolves should re-emit the framebuffer if needed.
This change is mostly a no-op but it improves consistency
regarding other meta operations that need to save/restore subpasses.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_resolve.c| 3 ++-
src/amd/vulkan/radv_meta_resolve_fs.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_resolve.c
b/src/amd/vulkan/radv_meta_resolve.c
index ade5d438438..b9f5106ef01 100644
--- a/src/amd/vulkan/radv_meta_resolve.c
+++ b/src/amd/vulkan/radv_meta_resolve.c
@@ -691,7 +691,8 @@ radv_cmd_buffer_resolve_subpass(struct radv_cmd_buffer
*cmd_buffer)
&(VkExtent2D) { fb->width, fb->height });
}
- cmd_buffer->state.subpass = subpass;
+ radv_cmd_buffer_set_subpass(cmd_buffer, subpass);
+
radv_meta_restore(_state, cmd_buffer);
}
diff --git a/src/amd/vulkan/radv_meta_resolve_fs.c
b/src/amd/vulkan/radv_meta_resolve_fs.c
index 3c63195f48f..9f20f6753e2 100644
--- a/src/amd/vulkan/radv_meta_resolve_fs.c
+++ b/src/amd/vulkan/radv_meta_resolve_fs.c
@@ -632,6 +632,7 @@ radv_cmd_buffer_resolve_subpass_fs(struct radv_cmd_buffer
*cmd_buffer)
&(VkExtent2D) { fb->width, fb->height });
}
- cmd_buffer->state.subpass = subpass;
+ radv_cmd_buffer_set_subpass(cmd_buffer, subpass);
+
radv_meta_restore(_state, cmd_buffer);
}
--
2.21.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On 05/23/2019 02:48 AM, Erik Faye-Lund wrote: On Wed, 2019-05-22 at 18:06 +0200, Akim Demaille wrote: Hi Erik, Le 22 mai 2019 à 08:54, Erik Faye-Lund < erik.faye-l...@collabora.com> a écrit : I ended up reverting the change [from-%error-verbose to %define parse.error verbose] , and I can't find an obcious way to support both old and new versions with the same source file. Well, you just disable warnings about deprecated features. -Wno-deprecated. The Android SDK also ships a pre-3.x version of Bison, so you're not the only one affected. Also, Chocolatey doesn't provide a new enough version of Bison for Windows either. I would be interested in knowing why some distros lag. Do you happen to know why for some of them? The only clear examples I know of are the Android SDK and Chocolatey. As I said before, we mighit not have to use the bison version shipped in the Android SDK, so perhaps that's fixable. And for Chocolatey, it turns out they have a winflexbison pacakge and a winflexbison3 package, and the latter has a more recent Bison version. So looking at this again, it looks like it might be solveable, at least in the cases where this is visible to me. Brian: do you think VMWare cuold upgrade the Bison version used in the forseeable future? I could start to work on that. Getting new ancillary components into our build system is rather complex, but I've been through it a few times. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110724] Unhandled GL format: 0x8058
https://bugs.freedesktop.org/show_bug.cgi?id=110724 --- Comment #6 from Alberto Salvia Novella --- Reported this info as: https://github.com/RPCS3/rpcs3/issues/6007 -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On Wed, 2019-05-22 at 18:06 +0200, Akim Demaille wrote: > Hi Erik, > > > Le 22 mai 2019 à 08:54, Erik Faye-Lund < > > erik.faye-l...@collabora.com> a écrit : > > > > I ended up reverting the change [from-%error-verbose to %define > > parse.error verbose] , and I can't find an obcious way to > > support both old and new versions with the same source file. > > Well, you just disable warnings about deprecated features. > -Wno-deprecated. > > > The Android SDK also ships a pre-3.x version of Bison, so you're > > not > > the only one affected. Also, Chocolatey doesn't provide a new > > enough > > version of Bison for Windows either. > > I would be interested in knowing why some distros lag. Do you > happen to know why for some of them? > The only clear examples I know of are the Android SDK and Chocolatey. As I said before, we mighit not have to use the bison version shipped in the Android SDK, so perhaps that's fixable. And for Chocolatey, it turns out they have a winflexbison pacakge and a winflexbison3 package, and the latter has a more recent Bison version. So looking at this again, it looks like it might be solveable, at least in the cases where this is visible to me. Brian: do you think VMWare cuold upgrade the Bison version used in the forseeable future? > > The problem is that Bison doesn't seem to have any mechanism for > > doing > > statements like these conditionally. > > We try to keep your sources nice and clean, and using %if or > things like this is anything but nice. So far these old > directives are not a maintenance burden, so there is no plan > to drop support for them. But still, at least for consistency, > I promote the newest forms. > Thanks for that clarification, makes sense. > > The only way around that that I > > can see is to pre-process the source files somehow. But especially > > with > > three different build systems, that's not really a venue I find > > particularly attractive. If someone can think of a neat solution, I > > would certainly love to hear about it :) > > Don't do that! > Yeah, I'm not planning on going down that road, as it seems needlessly convoluted. > > For now I guess we can just live with the warning. But whenever the > > Bison devs decide to remove support for %error-verbose, I fear that > > we'll either have to drop support for older versions or live with > > pre- > > processing. > > This should not happen. What should happen though, is that distros > stop shipping old versions. > I fully agree. > [generating the parsers in the tarballs] > > I don't really think this would work for us in Mesa. We no longer > > generate the distribution using autotools since we switched to > > Meson, > > we just do git archive these days. > > Well, I think that's a pity. The distinction between end user tools > and maintainer tools is a useful one. As exemplified by the issue > at hand. > I don't think this would have solved the issue for VCS users anyway, which is a large portion of our users these days, so I'm not sure it would have helped all that much. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glsl: do not use deprecated bison-keyword
On Wed, 2019-05-22 at 20:41 +0200, Akim Demaille wrote: > > Le 22 mai 2019 à 18:06, Akim Demaille a écrit > > : > > > > Hi Erik, > > > > > Le 22 mai 2019 à 08:54, Erik Faye-Lund < > > > erik.faye-l...@collabora.com> a écrit : > > > The Android SDK also ships a pre-3.x version of Bison, so you're > > > not > > > the only one affected. Also, Chocolatey doesn't provide a new > > > enough > > > version of Bison for Windows either. > > > > I would be interested in knowing why some distros lag. Do you > > happen to know why for some of them? > > Well, it appears that Bison 3.3.2 is available. Bundled with Flex > for some reason I find debatable, but it's there. > > https://chocolatey.org/packages/winflexbison3 > Thanks for the pointer! ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110724] Unhandled GL format: 0x8058
https://bugs.freedesktop.org/show_bug.cgi?id=110724 --- Comment #5 from Alberto Salvia Novella --- So is this a bug in the emulator itself? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110724] Unhandled GL format: 0x8058
https://bugs.freedesktop.org/show_bug.cgi?id=110724 --- Comment #4 from Tapani Pälli --- And because glTexStorage2D fails it is likely that is why the following glGetTexLevelParameteriv for that texture fail. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 110724] Unhandled GL format: 0x8058
https://bugs.freedesktop.org/show_bug.cgi?id=110724 --- Comment #3 from Tapani Pälli --- Playback of the trace throws following error: Mesa: User error: GL_INVALID_VALUE in glTexStorage2D(width, height or depth < 1) It looks like the emulator is making following invalid call: glTexStorage2D(GL_TEXTURE_2D, 1, GL_RGBA8, 0, 0); spec says: "GL_INVALID_VALUE is generated if width, height or levels are less than 1." -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] radv: implement VK_EXT_sample_locations
Thanks for pointing this out, I will implement.
On 5/22/19 10:20 PM, Marek Olšák wrote:
The depth decompress pass needs to know the sample locations.
If shader loads read from compressed depth, the texture hardware will
always use the standard locations for decompression.
Marek
On Tue, May 21, 2019 at 8:17 PM Bas Nieuwenhuizen
mailto:b...@basnieuwenhuizen.nl>> wrote:
So this does not seem to use the sample locations during layout
transitions?
AFAIK those are needed for e.g. HTILE decompression as it is based on
equations somehow.
On Thu, May 16, 2019 at 11:51 AM Samuel Pitoiset
mailto:samuel.pitoi...@gmail.com>> wrote:
>
> Basically, this extension allows applications to use custom
> sample locations. It doesn't support variable sample locations
> during subpass. Note that we don't have to upload the user
> sample locations because the spec doesn't allow this.
>
> Only enabled on VI+ because it's untested on older chips.
>
> v2: - change sampleLocationCoordinateRange[1] to 0.9375
> - compute and emit PA_SC_CENTROID_PRIORITY_{0,1}
> - rebased on top of master
> - some cleanups
>
> Signed-off-by: Samuel Pitoiset mailto:samuel.pitoi...@gmail.com>>
> ---
> src/amd/vulkan/radv_cmd_buffer.c | 223
++
> src/amd/vulkan/radv_device.c | 27
> src/amd/vulkan/radv_extensions.py | 1 +
> src/amd/vulkan/radv_pipeline.c | 30
> src/amd/vulkan/radv_private.h | 26 +++-
> 5 files changed, 300 insertions(+), 7 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c
b/src/amd/vulkan/radv_cmd_buffer.c
> index 4f592bc7f68..fb79c1c6713 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -105,6 +105,7 @@ radv_bind_dynamic_state(struct
radv_cmd_buffer *cmd_buffer,
> dest->viewport.count = src->viewport.count;
> dest->scissor.count = src->scissor.count;
> dest->discard_rectangle.count =
src->discard_rectangle.count;
> + dest->sample_location.count = src->sample_location.count;
>
> if (copy_mask & RADV_DYNAMIC_VIEWPORT) {
> if (memcmp(>viewport.viewports,
>viewport.viewports,
> @@ -192,6 +193,22 @@ radv_bind_dynamic_state(struct
radv_cmd_buffer *cmd_buffer,
> }
> }
>
> + if (copy_mask & RADV_DYNAMIC_SAMPLE_LOCATIONS) {
> + if (dest->sample_location.per_pixel !=
src->sample_location.per_pixel ||
> + dest->sample_location.grid_size.width !=
src->sample_location.grid_size.width ||
> + dest->sample_location.grid_size.height !=
src->sample_location.grid_size.height ||
> + memcmp(>sample_location.locations,
> + >sample_location.locations,
> + src->sample_location.count * sizeof(VkSampleLocationEXT))) {
> + dest->sample_location.per_pixel = src->sample_location.per_pixel;
> + dest->sample_location.grid_size = src->sample_location.grid_size;
> + typed_memcpy(dest->sample_location.locations,
> + src->sample_location.locations,
> + src->sample_location.count);
> + dest_mask |= RADV_DYNAMIC_SAMPLE_LOCATIONS;
> + }
> + }
> +
> cmd_buffer->state.dirty |= dest_mask;
> }
>
> @@ -632,6 +649,190 @@ radv_emit_descriptor_pointers(struct
radv_cmd_buffer *cmd_buffer,
> }
> }
>
> +/**
> + * Convert the user sample locations to hardware sample
locations (the values
> + * that will be emitted by PA_SC_AA_SAMPLE_LOCS_PIXEL_*).
> + */
> +static void
> +radv_convert_user_sample_locs(struct
radv_sample_locations_state *state,
> + uint32_t x, uint32_t y, VkOffset2D
*sample_locs)
> +{
> + uint32_t x_offset = x % state->grid_size.width;
> + uint32_t y_offset = y % state->grid_size.height;
> + uint32_t num_samples = (uint32_t)state->per_pixel;
> + VkSampleLocationEXT *user_locs;
> + uint32_t pixel_offset;
> +
> + pixel_offset = (x_offset + y_offset *
state->grid_size.width) * num_samples;
> +
> + assert(pixel_offset <= MAX_SAMPLE_LOCATIONS);
> + user_locs = >locations[pixel_offset];
> +
> + for (uint32_t i = 0; i < num_samples; i++) {
> + float shifted_pos_x = user_locs[i].x - 0.5;
> + float shifted_pos_y = user_locs[i].y - 0.5;
> +
> + int32_t scaled_pos_x = floor(shifted_pos_x * 16);
> + int32_t scaled_pos_y = floor(shifted_pos_y * 16);
> +
> + sample_locs[i].x = CLAMP(scaled_pos_x, -8, 7);
> + sample_locs[i].y = CLAMP(scaled_pos_y, -8, 7);
> + }
> +}
> +
>
