Re: [Mesa-dev] [PATCH 3/5] glsl: fall back to inexact function-match

[Tapani Pälli]

On 11/1/18 11:59 AM, Erik Faye-Lund wrote:

On Thu, 2018-11-01 at 07:49 +0200, Tapani Pälli wrote:


On 10/31/18 7:03 PM, Ilia Mirkin wrote:

On Wed, Oct 31, 2018 at 12:37 PM Erik Faye-Lund
 wrote:


On Wed, 2018-10-31 at 12:01 -0400, Ilia Mirkin wrote:

I had to do a double (or triple) take on this logic as well.
Part of
the subtlety is that the fallback only applies for ES when
there's a
match but no exact match. Probably good to mention this.


Yeah, that makes sense. I thought I mentioneded this in the
commit
message, but perhaps you want that to be more explicit than the
"In
GLES, "-introduction?

How about I simply add something like "This fallback should only
affect
GLES." at the end of the commit message?


Yes, you did mention it in the commit message. But that's unlikely
to
be visible when reading this code. I was thinking something in this
function's comments would be nice.



Sounds good, I wouldn't be worried about saying it aloud, at least I
would love some 'spoon-feeding comments' now and then with compiler
and
linker parts :)




OK, fair enough. How about this?

---8<---
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -667,7 +667,12 @@ match_function_by_name(const char *name,
 /* Local shader has no exact candidates; check the built-ins. */
 _mesa_glsl_initialize_builtin_functions();
 sig = _mesa_glsl_find_builtin_function(state, name,
actual_parameters);
-   return sig;
+
+   /* if _mesa_glsl_find_builtin_function failed, fall back to th
e result
+* of choose_best_inexact_overload() instead. This should only
affect
+* GLES.
+*/
+   return sig ? sig : local_sig;
  }
  
  static ir_function_signature *

---8<---



This is fine for me, thanks!

// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] util: use *unsigned* ints for bit operations

[Dave Airlie]

On Tue, 23 Oct 2018 at 10:57, Eric Anholt  wrote:
>
> Eric Engestrom  writes:
>
> > Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
> > time this macro is used.

This seems to be causing problems for me here on gcc8 (8.0.1 and
8.2.1) in Fedora 28.

./bin/texelFetch fs usampler2DMS 2

is failing here with:
Failed to compile fragment shader: 0:6(1): error: invalid input layout
qualifier used

gcc is probably broken, but we might want to revert his from the tree
and upcoming release until we can figure it out.

Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 00/13] Engine parameter for instructions

[Jason Ekstrand]

On Thu, Nov 1, 2018 at 5:51 AM Toni Lönnberg 
wrote:

> On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> > On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg 
> > wrote:
> >
> > > When we debug media or 3d+media workloads, we'd like to be able to see
> > > what is
> > > in the aub dumps for those workloads. At the moment the decoder can't
> > > distinguish instructions which share the same opcode between the render
> > > and
> > > video pipe, and thus aubinator outputs garbage on media instructions.
> > >
> > > I was reluctant to make these changes into Mesa in the first place
> since
> > > the
> > > work is related to media, not 3d, but as aubinator is now located here,
> > > here we
> > > are.
> > >
> >
> > That's fine.  It's fine if these changres live in mesa.
> >
> >
> > > As far as I can see, these are the options:
> > >
> > > 1. Put these in Mesa as aubinator now resides here instead of IGT.
> > >a) Put all instruction definitions in the current genxml files, be
> it
> > > with a
> > >   tag or an attribute, both methods have their advantages and
> > > disadvantages.
> > >b) Separate genxml files into common, render and video (and
> blitter?)
> > >
> > > 2. Fork aubinator tools and related genxml infra to a completely
> separate
> > >project.
> > >
> > > If I have missed an option, feel free to suggest.
> > >
> >
> > I wasn't suggesting we fork the tools and the XML.  I was just wondering
> > whether we wanted to do separate sections or an attribute.  I think it
> > should land in mesa either way.
>
> I'm not really a fan of any of the methods to be honest as each of them
> have
> disadvantages.
>
> Using the attribute makes it easier to add instructions which should be
> handled
> by a set of engines and not others but requires each instruction to have
> one,
> except the common ones that are always shared which can be made to default
> to
> all engines like in my version.
>
> The tag makes it easier to group things nicely but adds a new level to the
> xml
> and requires duplicate definitions of the instruction if more than one
> engine
> uses that instruction but some engine doesn't.
>

Yeah, I think I'm convinced.


> Splitting the genxml files into different ones for each engine also
> organizes
> the instructions nicely but has the same problem as the tag and requires
> loading
> and parsing of multiple xml files.
>

I also experimented with splitting up the XML files.  There are times when
this is convenient but I'm not sure it's actually all that useful.  If we
were to split it, we'd probably want to split it across other logical lines
like "MI" commands vs. "3DSTATE" commands and maybe a separate file for
registers.  At least for now, we may as well keep it all together.


> To make things more icky, there are the instructions, like MI_FLUSH_DW,
> which
> are shared between engines but might use some of the bits for different
> things.
>

Yeah.  When you mentioned this, I briefly considered the idea of putting
engine tags on individual fields in that case.  That may be getting a bit
nuts; I certainly don't want to recreate the insanity that is the bxml.


> In the end, I just went with how Lionel saw it because it was as good of
> an
> option as any, and pretty straight forward to implement, so.. mehhh. I
> don't
> know if you'd prefer one way or the other.
>

Works for me.  I just wanted to make sure we'd thought it through before
adding it.  I know I certainly hadn't given it all that much thought in my
brief experiments.  I think the attributes is the best solution for now.

--Jason



> >
> > --Jason
> >
> >
> > > On Wed, Oct 31, 2018 at 09:20:39AM -0500, Jason Ekstrand wrote:
> > > > Toni,
> > > >
> > > > I'm a bit curious where you're going with this.  I started on a
> similar
> > > > project a couple of years ago:
> > > >
> > > >
> https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/genxml-engines
> > > >
> > > > Mine took a different (not necessarily better) approach of
> surrounding
> > > the
> > > > instructions in an  tag.  I'm not sure if that's any better
> or
> > > > worse than an attribute.
> > > >
> > > > At the time, I was planning to port over the blitter code to genxml
> and
> > > get
> > > > aubinator decoding blit streams.  I canned the project because there
> are
> > > > few enough differences in hardware generations for the blitter to be
> > > worth
> > > > the re-compilation and I had better things to do.  I've always
> thought it
> > > > would be good to support other engines for no other reason than to
> make
> > > > aubinator for blits.  It would also likely be useful to have if we
> wanted
> > > > to start doing media in mesa for some reason.  What's your
> motivation?  I
> > > > ask because I can't really have an opinion on the approach unless I
> know
> > > > where it's headed.
> > > >
> > > > --Jason
> > > >
> > > > On Wed, Oct 31, 2018 at 8:12 AM Toni Lönnberg <
> toni.lonnb...@intel.com>
> > > > wrote:
> > > >
> > > > > 

Re: [Mesa-dev] [PATCH] virgl/vtest-winsys: Use virgl version of bind flags

[Dave Airlie]

On Thu, 1 Nov 2018 at 19:50, Gert Wollny  wrote:
>
> From: Gert Wollny 
>
> The bind flags defined by mesa/gallium might not always be in sync
> with the ones copied to virglrenderer/gallium. Therefore, use the
> flags defined in virgl like it is done for all the other calls to
> create resources.
>
> Signed-off-by: Gert Wollny 

Reviewed-by: Dave Airlie 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/4] i965: Move some genX infrastructure to genX_boilerplate.h.

[Kenneth Graunke]

This will let us make multiple genX_*.c files, without copy and pasting
all this boilerplate.
---
 src/mesa/drivers/dri/i965/Makefile.sources|  10 ++
 src/mesa/drivers/dri/i965/genX_boilerplate.h  | 160 ++
 src/mesa/drivers/dri/i965/genX_state_upload.c | 129 +-
 src/mesa/drivers/dri/i965/meson.build |   3 +-
 4 files changed, 174 insertions(+), 128 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/genX_boilerplate.h

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index 043a70029f2..63fa7b886f2 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -126,42 +126,52 @@ intel_tiled_memcpy_dep_FILES = \
 
 i965_gen4_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen45_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen5_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen6_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen7_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen75_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen8_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen9_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen10_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_gen11_FILES = \
genX_blorp_exec.c \
+   genX_boilerplate.h \
genX_state_upload.c
 
 i965_oa_GENERATED_FILES = \
diff --git a/src/mesa/drivers/dri/i965/genX_boilerplate.h 
b/src/mesa/drivers/dri/i965/genX_boilerplate.h
new file mode 100644
index 000..546dd1e23bc
--- /dev/null
+++ b/src/mesa/drivers/dri/i965/genX_boilerplate.h
@@ -0,0 +1,160 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef GENX_BOILERPLATE_H
+#define GENX_BOILERPLATE_H
+
+#include 
+
+#include "genxml/gen_macros.h"
+
+#include "brw_context.h"
+#include "intel_batchbuffer.h"
+
+UNUSED static void *
+emit_dwords(struct brw_context *brw, unsigned n)
+{
+   intel_batchbuffer_begin(brw, n);
+   uint32_t *map = brw->batch.map_next;
+   brw->batch.map_next += n;
+   intel_batchbuffer_advance(brw);
+   return map;
+}
+
+struct brw_address {
+   struct brw_bo *bo;
+   unsigned reloc_flags;
+   uint32_t offset;
+};
+
+#define __gen_address_type struct brw_address
+#define __gen_user_data struct brw_context
+
+static uint64_t
+__gen_combine_address(struct brw_context *brw, void *location,
+  struct brw_address address, uint32_t delta)
+{
+   struct intel_batchbuffer *batch = >batch;
+   uint32_t offset;
+
+   if (address.bo == NULL) {
+  return address.offset + delta;
+   } else {
+  if (GEN_GEN < 6 && brw_ptr_in_state_buffer(batch, location)) {
+ offset = (char *) location - (char *) brw->batch.state.map;
+ return brw_state_reloc(batch, offset, address.bo,
+address.offset + delta,
+address.reloc_flags);
+  }
+
+  assert(!brw_ptr_in_state_buffer(batch, location));
+
+  offset = (char *) location - (char *) brw->batch.batch.map;
+  return brw_batch_reloc(batch, offset, address.bo,
+ address.offset + delta,
+ address.reloc_flags);
+   }
+}
+
+UNUSED static struct brw_address
+rw_bo(struct brw_bo *bo, uint32_t offset)
+{
+   return (struct brw_address) {
+.bo = bo,
+.offset = offset,
+.reloc_flags = RELOC_WRITE,
+   

[Mesa-dev] [PATCH 2/4] i965: Rename ISP_DIS to INDIRECT_STATE_POINTERS_DISABLE.

[Kenneth Graunke]

Clearer name.
---
 src/mesa/drivers/dri/i965/brw_pipe_control.c | 2 +-
 src/mesa/drivers/dri/i965/brw_pipe_control.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
index 122ac260703..4d76e5dc9b7 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -362,7 +362,7 @@ gen10_emit_isp_disable(struct brw_context *brw)
  PIPE_CONTROL_CS_STALL,
  NULL, 0, 0);
brw_emit_pipe_control(brw,
- PIPE_CONTROL_ISP_DIS |
+ PIPE_CONTROL_INDIRECT_STATE_POINTERS_DISABLE |
  PIPE_CONTROL_CS_STALL,
  NULL, 0, 0);
 
diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.h 
b/src/mesa/drivers/dri/i965/brw_pipe_control.h
index 4c58e16660f..69b1c7c31e6 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.h
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.h
@@ -48,7 +48,7 @@ struct brw_bo;
 #define PIPE_CONTROL_RENDER_TARGET_FLUSH (1 << 12)
 #define PIPE_CONTROL_INSTRUCTION_INVALIDATE (1 << 11)
 #define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE  (1 << 10) /* GM45+ only */
-#define PIPE_CONTROL_ISP_DIS   (1 << 9)
+#define PIPE_CONTROL_INDIRECT_STATE_POINTERS_DISABLE (1 << 9)
 #define PIPE_CONTROL_INTERRUPT_ENABLE  (1 << 8)
 #define PIPE_CONTROL_FLUSH_ENABLE  (1 << 7) /* Gen7+ only */
 /* GT */
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] i965: Reimplement all the PIPE_CONTROL rules.

[Kenneth Graunke]

This implements virtually all documented PIPE_CONTROL restrictions
in a centralized helper.  You now simply ask for the operations you
want, and the pipe control "brain" will figure out exactly what pipe
controls to emit to make that happen without tanking your system.

The hope is that this will fix some intermittent flushing issues as
well as GPU hangs.  However, it also has a high risk of causing GPU
hangs and other regressions, as this is a particularly sensitive
area and poking the bear isn't always advisable.
---
 src/mesa/drivers/dri/i965/genX_pipe_control.c | 563 +-
 1 file changed, 428 insertions(+), 135 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/genX_pipe_control.c 
b/src/mesa/drivers/dri/i965/genX_pipe_control.c
index 8eb37444253..503e674661b 100644
--- a/src/mesa/drivers/dri/i965/genX_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/genX_pipe_control.c
@@ -25,172 +25,465 @@
 #include "brw_defines.h"
 #include "brw_state.h"
 
+static unsigned
+flags_to_post_sync_op(uint32_t flags)
+{
+   if (flags & PIPE_CONTROL_WRITE_IMMEDIATE)
+  return WriteImmediateData;
+
+   if (flags & PIPE_CONTROL_WRITE_DEPTH_COUNT)
+  return WritePSDepthCount;
+
+   if (flags & PIPE_CONTROL_WRITE_TIMESTAMP)
+  return WriteTimestamp;
+
+   return 0;
+}
+
 /**
- * According to the latest documentation, any PIPE_CONTROL with the
- * "Command Streamer Stall" bit set must also have another bit set,
- * with five different options:
- *
- *  - Render Target Cache Flush
- *  - Depth Cache Flush
- *  - Stall at Pixel Scoreboard
- *  - Post-Sync Operation
- *  - Depth Stall
- *  - DC Flush Enable
- *
- * I chose "Stall at Pixel Scoreboard" since we've used it effectively
- * in the past, but the choice is fairly arbitrary.
+ * Do the given flags have a Post Sync or LRI Post Sync operation?
  */
-static void
-gen8_add_cs_stall_workaround_bits(uint32_t *flags)
+static enum pipe_control_flags
+get_post_sync_flags(enum pipe_control_flags flags)
 {
-   uint32_t wa_bits = PIPE_CONTROL_RENDER_TARGET_FLUSH |
-  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
-  PIPE_CONTROL_WRITE_IMMEDIATE |
-  PIPE_CONTROL_WRITE_DEPTH_COUNT |
-  PIPE_CONTROL_WRITE_TIMESTAMP |
-  PIPE_CONTROL_STALL_AT_SCOREBOARD |
-  PIPE_CONTROL_DEPTH_STALL |
-  PIPE_CONTROL_DATA_CACHE_FLUSH;
-
-   /* If we're doing a CS stall, and don't already have one of the
-* workaround bits set, add "Stall at Pixel Scoreboard."
+   flags &= PIPE_CONTROL_WRITE_IMMEDIATE |
+PIPE_CONTROL_WRITE_DEPTH_COUNT |
+PIPE_CONTROL_WRITE_TIMESTAMP |
+PIPE_CONTROL_LRI_POST_SYNC_OP;
+
+   /* Only one "Post Sync Op" is allowed, and it's mutually exclusive with
+* "LRI Post Sync Operation".  So more than one bit set would be illegal.
 */
-   if ((*flags & PIPE_CONTROL_CS_STALL) != 0 && (*flags & wa_bits) == 0)
-  *flags |= PIPE_CONTROL_STALL_AT_SCOREBOARD;
+   assert(util_bitcount(flags) <= 1);
+
+   return flags;
 }
 
-/* Implement the WaCsStallAtEveryFourthPipecontrol workaround on IVB, BYT:
+#define IS_COMPUTE_PIPELINE(brw) \
+   (GEN_GEN >= 7 && brw->last_pipeline == BRW_COMPUTE_PIPELINE)
+
+/* Closed interval - GEN_GEN \in [x, y] */
+#define IS_GEN_BETWEEN(x, y) (GEN_GEN >= x && GEN_GEN <= y)
+#define IS_GENx10_BETWEEN(x, y) \
+   (GEN_VERSIONx10 >= x && GEN_VERSIONx10 <= y)
+
+/**
+ * Emit a series of PIPE_CONTROL commands, taking into account any
+ * workarounds necessary to actually accomplish the caller's request.
+ *
+ * Unless otherwise noted, spec quotations in this function come from:
  *
- * "Every 4th PIPE_CONTROL command, not counting the PIPE_CONTROL with
- *  only read-cache-invalidate bit(s) set, must have a CS_STALL bit set."
+ * Synchronization of the 3D Pipeline > PIPE_CONTROL Command > Programming
+ * Restrictions for PIPE_CONTROL.
  *
- * Note that the kernel does CS stalls between batches, so we only need
- * to count them within a batch.
+ * You should not use this function directly.  Use the helpers in
+ * brw_pipe_control.c instead, which may split the pipe control further.
  */
-static uint32_t
-gen7_cs_stall_every_four_pipe_controls(struct brw_context *brw, uint32_t flags)
+void
+genX(emit_raw_pipe_control)(struct brw_context *brw, uint32_t flags,
+struct brw_bo *bo, uint32_t offset, uint64_t imm)
 {
-   if (GEN_GEN == 7 && !GEN_IS_HASWELL) {
-  if (flags & PIPE_CONTROL_CS_STALL) {
- /* If we're doing a CS stall, reset the counter and carry on. */
- brw->pipe_controls_since_last_cs_stall = 0;
- return 0;
+   UNUSED const struct gen_device_info *devinfo = >screen->devinfo;
+   enum pipe_control_flags post_sync_flags = get_post_sync_flags(flags);
+   enum pipe_control_flags non_lri_post_sync_flags =
+  post_sync_flags & ~PIPE_CONTROL_LRI_POST_SYNC_OP;
+
+   /* Recursive PIPE_CONTROL workarounds 

[Mesa-dev] [PATCH 3/4] i965: Use genxml for emitting PIPE_CONTROL.

[Kenneth Graunke]

While this does add a bunch of boilerplate, it also protects us against
the hardware moving bits, or changing their meaning.  For something as
finnicky as PIPE_CONTROL, the extra safety seems worth it.

We turn PIPE_CONTROL_* into an bitfield of arbitrary flags, and then
pack them appropriately.
---
 src/mesa/drivers/dri/i965/Makefile.sources|   9 +
 src/mesa/drivers/dri/i965/brw_context.h   |   4 +
 src/mesa/drivers/dri/i965/brw_pipe_control.c  | 240 +++--
 src/mesa/drivers/dri/i965/brw_pipe_control.h  |  58 +++--
 src/mesa/drivers/dri/i965/brw_state.h |  31 +++
 src/mesa/drivers/dri/i965/genX_pipe_control.c | 243 ++
 src/mesa/drivers/dri/i965/meson.build |   4 +-
 7 files changed, 359 insertions(+), 230 deletions(-)
 create mode 100644 src/mesa/drivers/dri/i965/genX_pipe_control.c

diff --git a/src/mesa/drivers/dri/i965/Makefile.sources 
b/src/mesa/drivers/dri/i965/Makefile.sources
index 63fa7b886f2..e4eb0339e09 100644
--- a/src/mesa/drivers/dri/i965/Makefile.sources
+++ b/src/mesa/drivers/dri/i965/Makefile.sources
@@ -127,46 +127,55 @@ intel_tiled_memcpy_dep_FILES = \
 i965_gen4_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen45_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen5_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen6_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen7_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen75_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen8_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen9_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen10_FILES = \
genX_blorp_exec.c \
genX_boilerplate.h \
+   genX_pipe_control.c \
genX_state_upload.c
 
 i965_gen11_FILES = \
diff --git a/src/mesa/drivers/dri/i965/brw_context.h 
b/src/mesa/drivers/dri/i965/brw_context.h
index 7fd15669eb9..fe75425854c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -752,6 +752,10 @@ struct brw_context
 struct brw_bo *bo,
 uint32_t offset_in_bytes,
 uint32_t report_id);
+
+  void (*emit_raw_pipe_control)(struct brw_context *brw, uint32_t flags,
+struct brw_bo *bo, uint32_t offset,
+uint64_t imm);
} vtbl;
 
struct brw_bufmgr *bufmgr;
diff --git a/src/mesa/drivers/dri/i965/brw_pipe_control.c 
b/src/mesa/drivers/dri/i965/brw_pipe_control.c
index 4d76e5dc9b7..cf9cc35875f 100644
--- a/src/mesa/drivers/dri/i965/brw_pipe_control.c
+++ b/src/mesa/drivers/dri/i965/brw_pipe_control.c
@@ -23,200 +23,10 @@
 
 #include "brw_context.h"
 #include "brw_defines.h"
+#include "brw_state.h"
 #include "intel_batchbuffer.h"
 #include "intel_fbo.h"
 
-/**
- * According to the latest documentation, any PIPE_CONTROL with the
- * "Command Streamer Stall" bit set must also have another bit set,
- * with five different options:
- *
- *  - Render Target Cache Flush
- *  - Depth Cache Flush
- *  - Stall at Pixel Scoreboard
- *  - Post-Sync Operation
- *  - Depth Stall
- *  - DC Flush Enable
- *
- * I chose "Stall at Pixel Scoreboard" since we've used it effectively
- * in the past, but the choice is fairly arbitrary.
- */
-static void
-gen8_add_cs_stall_workaround_bits(uint32_t *flags)
-{
-   uint32_t wa_bits = PIPE_CONTROL_RENDER_TARGET_FLUSH |
-  PIPE_CONTROL_DEPTH_CACHE_FLUSH |
-  PIPE_CONTROL_WRITE_IMMEDIATE |
-  PIPE_CONTROL_WRITE_DEPTH_COUNT |
-  PIPE_CONTROL_WRITE_TIMESTAMP |
-  PIPE_CONTROL_STALL_AT_SCOREBOARD |
-  PIPE_CONTROL_DEPTH_STALL |
-  PIPE_CONTROL_DATA_CACHE_FLUSH;
-
-   /* If we're doing a CS stall, and don't already have one of the
-* workaround bits set, add "Stall at Pixel Scoreboard."
-*/
-   if ((*flags & PIPE_CONTROL_CS_STALL) != 0 && (*flags & wa_bits) == 0)
-  *flags |= PIPE_CONTROL_STALL_AT_SCOREBOARD;
-}
-
-/* Implement the WaCsStallAtEveryFourthPipecontrol workaround on IVB, BYT:
- *
- * "Every 4th PIPE_CONTROL command, not counting the PIPE_CONTROL with
- *  only read-cache-invalidate bit(s) set, must have a CS_STALL bit set."
- *
- 

[Mesa-dev] [PATCH] intel: Use a URB start offset of 0 for disabled stages.

[Kenneth Graunke]

There are some cases where the VS is the only stage enabled, it uses the
entire URB, and the URB is large enough that placing later stages after
the VS exceeds the number of bits for "URB Starting Address".

For example, on Icelake GT2, "varying-packing-simple mat2x4 array" from
Piglit is getting a starting offset of 128 for the GS/HS/DS.  But the
field is only large enough to hold an offset of 127.

i965 doesn't hit any genxml assertions because it's still using the old
OUT_BATCH mechanism.  128 << GEN7_URB_STARTING_ADDRESS_SHIFT (57) == 0,
with the extra bit falling off the end.  So we place the disabled stage
at the beginning of the URB (overlapping with push constants).  This is
likely okay since it's a zero size region (0 entries).

It seems like the Vulkan driver might hit this assertion, however, and
the situation seems harmless.  To work around this, always place
disabled stages at the start of the URB, so the last enabled stage can
fill the remaining space without overflowing the field.
---
 src/intel/common/gen_urb_config.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/intel/common/gen_urb_config.c 
b/src/intel/common/gen_urb_config.c
index 0b632149cd9..1440dd713e9 100644
--- a/src/intel/common/gen_urb_config.c
+++ b/src/intel/common/gen_urb_config.c
@@ -195,8 +195,14 @@ gen_get_urb_config(const struct gen_device_info *devinfo,
}
 
/* Lay out the URB in pipeline order: push constants, VS, HS, DS, GS. */
-   start[0] = push_constant_chunks;
-   for (int i = MESA_SHADER_TESS_CTRL; i <= MESA_SHADER_GEOMETRY; i++) {
-  start[i] = start[i - 1] + chunks[i - 1];
+   int next = push_constant_chunks;
+   for (int i = MESA_SHADER_VERTEX; i <= MESA_SHADER_GEOMETRY; i++) {
+  if (entries[i]) {
+ start[i] = next;
+ next += chunks[i];
+  } else {
+ /* Just put disabled stages at the beginning. */
+ start[i] = 0;
+  }
}
 }
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] winsys/amdgpu: Stop using amdgpu_bo_handle_type_kms_noimport

[Dieter Nützel]

Tested-by: Dieter Nützel 

Bugzilla: https://bugs.freedesktop.org/108096
is (code)FIXED with this.

Thank you very much, Michel!

Dieter

Am 01.11.2018 12:31, schrieb Michel Dänzer:

From: Michel Dänzer 

It only behaves any different from amdgpu_bo_handle_type_kms with
libdrm 2.4.93, and it breaks if an older version is picked up.

Bugzilla: https://bugs.freedesktop.org/108096
Signed-off-by: Michel Dänzer 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index 68f0562a644..f49fb47b80e 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -486,7 +486,7 @@ static struct amdgpu_winsys_bo
*amdgpu_create_bo(struct amdgpu_winsys *ws,
else if (initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align64(size, ws->info.gart_page_size);

-   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
>u.real.kms_handle);
+   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms, 
>u.real.kms_handle);


amdgpu_add_buffer_to_global_list(bo);

@@ -1355,7 +1355,7 @@ static struct pb_buffer
*amdgpu_bo_from_handle(struct radeon_winsys *rws,
else if (bo->initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align64(bo->base.size, 
ws->info.gart_page_size);


-   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
>u.real.kms_handle);
+   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms, 
>u.real.kms_handle);


amdgpu_add_buffer_to_global_list(bo);

@@ -1463,7 +1463,7 @@ static struct pb_buffer
*amdgpu_bo_from_ptr(struct radeon_winsys *rws,

 amdgpu_add_buffer_to_global_list(bo);

-amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
>u.real.kms_handle);
+amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms,
>u.real.kms_handle);

 return (struct pb_buffer*)bo;

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] ac/nir_to_llvm: fix b2f for f64

[Timothy Arceri]

Fixes: d7e0d47b9de3 ("nir: Add a bunch of b2[if] optimizations")
---
 src/amd/common/ac_nir_to_llvm.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index e5fbe003f53..c950b81dca2 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -311,9 +311,18 @@ static LLVMValueRef emit_uint_carry(struct ac_llvm_context 
*ctx,
 }
 
 static LLVMValueRef emit_b2f(struct ac_llvm_context *ctx,
-LLVMValueRef src0)
+LLVMValueRef src0,
+unsigned bitsize)
 {
-   return LLVMBuildAnd(ctx->builder, src0, LLVMBuildBitCast(ctx->builder, 
LLVMConstReal(ctx->f32, 1.0), ctx->i32, ""), "");
+   LLVMValueRef result = LLVMBuildAnd(ctx->builder, src0,
+  LLVMBuildBitCast(ctx->builder, 
LLVMConstReal(ctx->f32, 1.0), ctx->i32, ""),
+  "");
+   result = LLVMBuildBitCast(ctx->builder, result, ctx->f32, "");
+
+   if (bitsize == 32)
+   return result;
+
+   return LLVMBuildFPExt(ctx->builder, result, ctx->f64, "");
 }
 
 static LLVMValueRef emit_f2b(struct ac_llvm_context *ctx,
@@ -932,7 +941,7 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
result = emit_uint_carry(>ac, 
"llvm.usub.with.overflow.i32", src[0], src[1]);
break;
case nir_op_b2f:
-   result = emit_b2f(>ac, src[0]);
+   result = emit_b2f(>ac, src[0], 
instr->dest.dest.ssa.bit_size);
break;
case nir_op_f2b:
result = emit_f2b(>ac, src[0]);
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd: Make vgpr-spilling depend on llvm version

[Dieter Nützel]

Tested-by: Dieter Nützel 

Thanks!

Dieter

Am 01.11.2018 19:52, schrieb Jan Vesely:

The option was removed in LLVM r345763
Signed-off-by: Jan Vesely 
---
 src/amd/common/ac_llvm_util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_util.c 
b/src/amd/common/ac_llvm_util.c

index 69d9f7b9f3..dc9b684e9d 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -153,7 +153,8 @@ static LLVMTargetMachineRef
ac_create_target_machine(enum radeon_family family,
LLVMTargetRef target = ac_get_llvm_target(triple);

snprintf(features, sizeof(features),
-
"+DumpCode,+vgpr-spilling,-fp32-denormals,+fp64-denormals%s%s%s%s",
+"+DumpCode,-fp32-denormals,+fp64-denormals%s%s%s%s%s",
+HAVE_LLVM >= 0x0800 ? "" : ",+vgpr-spilling",
 tm_options & AC_TM_SISCHED ? ",+si-scheduler" : "",
 tm_options & AC_TM_FORCE_ENABLE_XNACK ? ",+xnack" : "",
 tm_options & AC_TM_FORCE_DISABLE_XNACK ? ",-xnack" : "",

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] amd: Make vgpr-spilling depend on llvm version

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Thu, Nov 1, 2018 at 2:52 PM Jan Vesely  wrote:

> The option was removed in LLVM r345763
> Signed-off-by: Jan Vesely 
> ---
>  src/amd/common/ac_llvm_util.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
> index 69d9f7b9f3..dc9b684e9d 100644
> --- a/src/amd/common/ac_llvm_util.c
> +++ b/src/amd/common/ac_llvm_util.c
> @@ -153,7 +153,8 @@ static LLVMTargetMachineRef
> ac_create_target_machine(enum radeon_family family,
> LLVMTargetRef target = ac_get_llvm_target(triple);
>
> snprintf(features, sizeof(features),
> -
> "+DumpCode,+vgpr-spilling,-fp32-denormals,+fp64-denormals%s%s%s%s",
> +"+DumpCode,-fp32-denormals,+fp64-denormals%s%s%s%s%s",
> +HAVE_LLVM >= 0x0800 ? "" : ",+vgpr-spilling",
>  tm_options & AC_TM_SISCHED ? ",+si-scheduler" : "",
>  tm_options & AC_TM_FORCE_ENABLE_XNACK ? ",+xnack" : "",
>  tm_options & AC_TM_FORCE_DISABLE_XNACK ? ",-xnack" : "",
> --
> 2.19.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

Re: [Mesa-dev] [PATCH] winsys/amdgpu: Stop using amdgpu_bo_handle_type_kms_noimport

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Thu, Nov 1, 2018 at 7:33 AM Michel Dänzer  wrote:

> From: Michel Dänzer 
>
> It only behaves any different from amdgpu_bo_handle_type_kms with
> libdrm 2.4.93, and it breaks if an older version is picked up.
>
> Bugzilla: https://bugs.freedesktop.org/108096
> Signed-off-by: Michel Dänzer 
> ---
>  src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> index 68f0562a644..f49fb47b80e 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> @@ -486,7 +486,7 @@ static struct amdgpu_winsys_bo
> *amdgpu_create_bo(struct amdgpu_winsys *ws,
> else if (initial_domain & RADEON_DOMAIN_GTT)
>ws->allocated_gtt += align64(size, ws->info.gart_page_size);
>
> -   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
> >u.real.kms_handle);
> +   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms,
> >u.real.kms_handle);
>
> amdgpu_add_buffer_to_global_list(bo);
>
> @@ -1355,7 +1355,7 @@ static struct pb_buffer
> *amdgpu_bo_from_handle(struct radeon_winsys *rws,
> else if (bo->initial_domain & RADEON_DOMAIN_GTT)
>ws->allocated_gtt += align64(bo->base.size,
> ws->info.gart_page_size);
>
> -   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
> >u.real.kms_handle);
> +   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms,
> >u.real.kms_handle);
>
> amdgpu_add_buffer_to_global_list(bo);
>
> @@ -1463,7 +1463,7 @@ static struct pb_buffer *amdgpu_bo_from_ptr(struct
> radeon_winsys *rws,
>
>  amdgpu_add_buffer_to_global_list(bo);
>
> -amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport,
> >u.real.kms_handle);
> +amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms,
> >u.real.kms_handle);
>
>  return (struct pb_buffer*)bo;
>
> --
> 2.19.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

Re: [Mesa-dev] [Mesa-stable] [PATCH] mapi: avoid text relocation in x86 tsd stubs

[Jonathan Gray]

On Thu, Nov 01, 2018 at 12:26:34PM -0700, Ian Romanick wrote:
> On 10/31/2018 09:08 PM, Jonathan Gray wrote:
> > Make similiar changes to libglvnd to avoid a text relocation in
> > x86 tsd stubs fixing the build with lld.
> > 
> > Signed-off-by: Jonathan Gray 
> > Cc: mesa-sta...@lists.freedesktop.org
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
> > ---
> >  src/mapi/entry_x86_tsd.h | 14 +-
> >  1 file changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
> > index 0c28c8ff068..e08a02f3db2 100644
> > --- a/src/mapi/entry_x86_tsd.h
> > +++ b/src/mapi/entry_x86_tsd.h
> > @@ -31,7 +31,7 @@
> >  #define HIDDEN
> >  #endif
> >  
> > -#define X86_ENTRY_SIZE 32
> > +#define X86_ENTRY_SIZE 64
> >  
> >  __asm__(".text\n"
> >  ".balign 32\n"
> > @@ -44,12 +44,16 @@ __asm__(".text\n"
> > func ":"
> >  
> >  #define STUB_ASM_CODE(slot) \
> > -   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
> > +   "call 1f\n\t"\
> > +   "1:\n\t" \
> > +   "popl %eax\n\t"  \
> > +   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
> > +   "movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
> > +   "mov (%eax), %eax\n\t"   \
> > "testl %eax, %eax\n\t"   \
> > -   "je 1f\n\t"  \
> > -   "jmp *(4 * " slot ")(%eax)\n"\
> > +   "jne 1f\n\t" \
> > +   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
> > "1:\n\t" \
> > -   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
> > "jmp *(4 * " slot ")(%eax)"
> 
> After this change, the code is:
> 
> #define STUB_ASM_CODE(slot) \
>"call 1f\n\t"\
>"1:\n\t" \
>"popl %eax\n\t"  \
>"addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
>"movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
>"mov (%eax), %eax\n\t"   \
>"testl %eax, %eax\n\t"   \
>"jne 1f\n\t" \
>"call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
>"1:\n\t" \
>"jmp *(4 * " slot ")(%eax)"
> 
> So there's going to be two labels "1:".  Does that even assemble?

Yes, the call/jmp is always forward as it is '1f'.
This also runs glxinfo, glxgears etc on a pentium m running OpenBSD/i386.

https://github.com/NVIDIA/libglvnd/blob/master/src/GLdispatch/vnd-glapi/entry_x86_tsd.c#L58

libglvnd has two labels like this as well, the ebx use there isn't needed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/2] glsl: Add pragma to disable all warnings

[Ian Romanick]

From: Ian Romanick 

warnings.  This is a big hammer.  If we ever need a smaller hammer, we
can enhance this functionality.

There is one lame thing about this.  Because we parse everything, create
an AST, then convert the AST to GLSL IR, we have to treat the #pragma
like a statment.  This means that you can't do something like

void
__foo
(float param0);

Fixing that would, as far as I can tell, require a huge amount of work.

I did try just handling the #pragma during parsing (like we do for
state for the whole shader.

Signed-off-by: Ian Romanick 
Cc: Matt Turner 
---
 src/compiler/glsl/ast.h| 14 +
 src/compiler/glsl/ast_to_hir.cpp   |  8 
 src/compiler/glsl/glsl_lexer.ll|  8 
 src/compiler/glsl/glsl_parser.yy   | 24 +-
 src/compiler/glsl/glsl_parser_extras.cpp   | 12 ++-
 src/compiler/glsl/glsl_parser_extras.h |  7 +++
 .../032-__-in-function-name-pragma-disable.vert| 24 ++
 ..._-in-function-name-pragma-disable.vert.expected |  2 ++
 8 files changed, 89 insertions(+), 10 deletions(-)
 create mode 100644 
src/compiler/glsl/tests/warnings/032-__-in-function-name-pragma-disable.vert
 create mode 100644 
src/compiler/glsl/tests/warnings/032-__-in-function-name-pragma-disable.vert.expected

diff --git a/src/compiler/glsl/ast.h b/src/compiler/glsl/ast.h
index 4d5e045b82c..94bcf644a26 100644
--- a/src/compiler/glsl/ast.h
+++ b/src/compiler/glsl/ast.h
@@ -1315,6 +1315,20 @@ private:
ast_layout_expression *local_size[3];
 };
 
+class ast_warnings_toggle : public ast_node {
+public:
+   ast_warnings_toggle(bool _enable)
+  : enable(_enable)
+   {
+  /* empty */
+   }
+
+   virtual ir_rvalue *hir(exec_list *instructions,
+  struct _mesa_glsl_parse_state *state);
+
+private:
+   bool enable;
+};
 /*@}*/
 
 extern void
diff --git a/src/compiler/glsl/ast_to_hir.cpp b/src/compiler/glsl/ast_to_hir.cpp
index 084b7021a9f..fa9f61da2cd 100644
--- a/src/compiler/glsl/ast_to_hir.cpp
+++ b/src/compiler/glsl/ast_to_hir.cpp
@@ -8766,3 +8766,11 @@ remove_per_vertex_blocks(exec_list *instructions,
   }
}
 }
+
+ir_rvalue *
+ast_warnings_toggle::hir(exec_list *,
+ struct _mesa_glsl_parse_state *state)
+{
+   state->warnings_enabled = enable;
+   return NULL;
+}
diff --git a/src/compiler/glsl/glsl_lexer.ll b/src/compiler/glsl/glsl_lexer.ll
index 0a2bba6d38f..224418ed7ce 100644
--- a/src/compiler/glsl/glsl_lexer.ll
+++ b/src/compiler/glsl/glsl_lexer.ll
@@ -295,6 +295,14 @@ HASH   ^{SPC}#{SPC}
  BEGIN PP;
  return PRAGMA_OPTIMIZE_OFF;
}
+^{SPC}#{SPC}pragma{SPCP}warning{SPC}\({SPC}on{SPC}\) {
+ BEGIN PP;
+ return PRAGMA_WARNING_ON;
+   }
+^{SPC}#{SPC}pragma{SPCP}warning{SPC}\({SPC}off{SPC}\) {
+ BEGIN PP;
+ return PRAGMA_WARNING_OFF;
+   }
 ^{SPC}#{SPC}pragma{SPCP}STDGL{SPCP}invariant{SPC}\({SPC}all{SPC}\) {
  BEGIN PP;
  return PRAGMA_INVARIANT_ALL;
diff --git a/src/compiler/glsl/glsl_parser.yy b/src/compiler/glsl/glsl_parser.yy
index fd1592beca0..ddb54f4a4d6 100644
--- a/src/compiler/glsl/glsl_parser.yy
+++ b/src/compiler/glsl/glsl_parser.yy
@@ -164,6 +164,7 @@ static bool match_layout_qualifier(const char *s1, const 
char *s2,
 %token VERSION_TOK EXTENSION LINE COLON EOL INTERFACE OUTPUT
 %token PRAGMA_DEBUG_ON PRAGMA_DEBUG_OFF
 %token PRAGMA_OPTIMIZE_ON PRAGMA_OPTIMIZE_OFF
+%token PRAGMA_WARNING_ON PRAGMA_WARNING_OFF
 %token PRAGMA_INVARIANT_ALL
 %token LAYOUT_TOK
 %token DOT_TOK
@@ -246,6 +247,7 @@ static bool match_layout_qualifier(const char *s1, const 
char *s2,
 %type  unary_operator
 %type  function_identifier
 %type  external_declaration
+%type  pragma_statement
 %type  init_declarator_list
 %type  single_declaration
 %type  initializer
@@ -328,10 +330,10 @@ version_statement:
;
 
 pragma_statement:
-   PRAGMA_DEBUG_ON EOL
-   | PRAGMA_DEBUG_OFF EOL
-   | PRAGMA_OPTIMIZE_ON EOL
-   | PRAGMA_OPTIMIZE_OFF EOL
+   PRAGMA_DEBUG_ON EOL { $$ = NULL; }
+   | PRAGMA_DEBUG_OFF EOL { $$ = NULL; }
+   | PRAGMA_OPTIMIZE_ON EOL { $$ = NULL; }
+   | PRAGMA_OPTIMIZE_OFF EOL { $$ = NULL; }
| PRAGMA_INVARIANT_ALL EOL
{
   /* Pragma invariant(all) cannot be used in a fragment shader.
@@ -353,6 +355,18 @@ pragma_statement:
   } else {
  state->all_invariant = true;
   }
+
+  $$ = NULL;
+   }
+   | PRAGMA_WARNING_ON EOL
+   {
+  void *mem_ctx = state->linalloc;
+  $$ = new(mem_ctx) ast_warnings_toggle(true);
+   }
+   | PRAGMA_WARNING_OFF EOL
+   {
+  void *mem_ctx = state->linalloc;
+  $$ = 

[Mesa-dev] [PATCH 1/2] glsl: Add warning tests for identifiers with __

[Ian Romanick]

From: Ian Romanick 

Signed-off-by: Ian Romanick 
Cc: Matt Turner 
---
 .../tests/warnings/031-__-in-function-name.vert| 22 ++
 .../warnings/031-__-in-function-name.vert.expected |  3 +++
 2 files changed, 25 insertions(+)
 create mode 100644 
src/compiler/glsl/tests/warnings/031-__-in-function-name.vert
 create mode 100644 
src/compiler/glsl/tests/warnings/031-__-in-function-name.vert.expected

diff --git a/src/compiler/glsl/tests/warnings/031-__-in-function-name.vert 
b/src/compiler/glsl/tests/warnings/031-__-in-function-name.vert
new file mode 100644
index 000..84d643d4509
--- /dev/null
+++ b/src/compiler/glsl/tests/warnings/031-__-in-function-name.vert
@@ -0,0 +1,22 @@
+#version 130
+
+float __foo(float x)
+{
+   return 6.0 * x;
+}
+
+float __bar(float x)
+{
+   return 3.0 * x;
+}
+
+float __blat(float x)
+{
+   return 2.0 * x;
+}
+
+void main()
+{
+   gl_Position = vec4(__foo(gl_Vertex.x), __bar(gl_Vertex.y), 
__blat(gl_Vertex.z), 1.0);
+}
+
diff --git 
a/src/compiler/glsl/tests/warnings/031-__-in-function-name.vert.expected 
b/src/compiler/glsl/tests/warnings/031-__-in-function-name.vert.expected
new file mode 100644
index 000..ee44175
--- /dev/null
+++ b/src/compiler/glsl/tests/warnings/031-__-in-function-name.vert.expected
@@ -0,0 +1,3 @@
+0:3(7): warning: identifier `__foo' uses reserved `__' string
+0:8(7): warning: identifier `__bar' uses reserved `__' string
+0:13(7): warning: identifier `__blat' uses reserved `__' string
-- 
2.14.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] nir: allow propagation of if evaluation for bcsel

[Jason Ekstrand]

On Thu, Nov 1, 2018 at 4:53 PM Timothy Arceri  wrote:

> Cc: Jason Ekstrand 
> ---
>  src/compiler/nir/nir_opt_if.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
> index 1fe95e53766..50e8947eaa1 100644
> --- a/src/compiler/nir/nir_opt_if.c
> +++ b/src/compiler/nir/nir_opt_if.c
> @@ -448,7 +448,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif,
> nir_src *use_src,
> if (!evaluate_if_condition(nif, b->cursor, _value))
>return false;
>
> -   nir_ssa_def *def[2] = {0};
> +   nir_ssa_def *def[4] = {0};
> for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
>if (alu->src[i].src.ssa == use_src->ssa) {
>   def[i] = nir_imm_bool(b, bool_value);
> @@ -456,7 +456,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif,
> nir_src *use_src,
>   def[i] = alu->src[i].src.ssa;
>}
> }
> -   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], NULL,
> NULL);
> +   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2],
> def[3]);
>
> /* Rewrite use to use new alu instruction */
> nir_src new_src = nir_src_for_ssa(nalu);
> @@ -472,14 +472,22 @@ propagate_condition_eval(nir_builder *b, nir_if
> *nif, nir_src *use_src,
>  static bool
>  can_propagate_through_alu(nir_src *src)
>  {
> -   if (src->parent_instr->type == nir_instr_type_alu &&
> -   (nir_instr_as_alu(src->parent_instr)->op == nir_op_ior ||
> -nir_instr_as_alu(src->parent_instr)->op == nir_op_iand ||
> -nir_instr_as_alu(src->parent_instr)->op == nir_op_inot ||
> -nir_instr_as_alu(src->parent_instr)->op == nir_op_b2i))
> -  return true;
> +   if (src->parent_instr->type != nir_instr_type_alu)
> +  return false;
>

We can do "nir_alu_instr *alu = nir_instr_as_alu(src->parent_instr)" here
and simplify the code below.


> -   return false;
> +   switch (nir_instr_as_alu(src->parent_instr)->op) {
> +  case nir_op_ior:
> +  case nir_op_iand:
> +  case nir_op_inot:
> +  case nir_op_b2i:
> + return true;
> +  case nir_op_bcsel:
> + if (src == _instr_as_alu(src->parent_instr)->src[0].src)
> +return true;
> + /* fall through */
>

There's no good reason for the fall-through.  Just return false here.  Or,
better yet, "return src == >src[0].src"

With those changes,

Reviewed-by: Jason Ekstrand 


> +  default:
> + return false;
> +   }
>  }
>
>  static bool
> --
> 2.19.1
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] nir: allow propagation of if evaluation for bcsel

[Timothy Arceri]

Cc: Jason Ekstrand 
---
 src/compiler/nir/nir_opt_if.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 1fe95e53766..50e8947eaa1 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -448,7 +448,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
if (!evaluate_if_condition(nif, b->cursor, _value))
   return false;
 
-   nir_ssa_def *def[2] = {0};
+   nir_ssa_def *def[4] = {0};
for (unsigned i = 0; i < nir_op_infos[alu->op].num_inputs; i++) {
   if (alu->src[i].src.ssa == use_src->ssa) {
  def[i] = nir_imm_bool(b, bool_value);
@@ -456,7 +456,7 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
  def[i] = alu->src[i].src.ssa;
   }
}
-   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], NULL, NULL);
+   nir_ssa_def *nalu = nir_build_alu(b, alu->op, def[0], def[1], def[2], 
def[3]);
 
/* Rewrite use to use new alu instruction */
nir_src new_src = nir_src_for_ssa(nalu);
@@ -472,14 +472,22 @@ propagate_condition_eval(nir_builder *b, nir_if *nif, 
nir_src *use_src,
 static bool
 can_propagate_through_alu(nir_src *src)
 {
-   if (src->parent_instr->type == nir_instr_type_alu &&
-   (nir_instr_as_alu(src->parent_instr)->op == nir_op_ior ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_iand ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_inot ||
-nir_instr_as_alu(src->parent_instr)->op == nir_op_b2i))
-  return true;
+   if (src->parent_instr->type != nir_instr_type_alu)
+  return false;
 
-   return false;
+   switch (nir_instr_as_alu(src->parent_instr)->op) {
+  case nir_op_ior:
+  case nir_op_iand:
+  case nir_op_inot:
+  case nir_op_b2i:
+ return true;
+  case nir_op_bcsel:
+ if (src == _instr_as_alu(src->parent_instr)->src[0].src)
+return true;
+ /* fall through */
+  default:
+ return false;
+   }
 }
 
 static bool
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] glsl: Correct several built-in functions availability

[Ian Romanick]

On 10/31/2018 03:05 PM, Timothy Arceri wrote:
> If we are going to start tightening up this stuff I would really really
> like to see CTS tests (not piglit tests) to go along with this stuff.
> 
> We are already way stricter with these type of things than the closed
> source drivers and this leads to some apps not working. Before we go
> ahead and tighten things up more we should get this stuff covered by the
> CTS so that we are not the only ones enforcing the rules (i.e. fighting
> an unwinnable battle).

Yeah, I was pretty surprised by this list of functions.  I think the
absolute minimum bar is a set of piglit tests that pass on at least one
of NVIDIA or AMD closed-source drivers.  Adding CTS tests that only
operate on GLSL 1.10 or 1.20 is unlikely to be successful.  GLSL ES 1.00
tests have more of a chance, but it's still a very slim chance.

> On 1/11/18 5:37 am, Vadym Shovkoplias wrote:
>> In GLSL versions 1.00 ES, 1.10 and 1.20, Mesa includes
>> some built-in functions which shouldn't be present in
>> that version, namely:
>>
>>     genIType abs(genIType x)
>>     genIType sign(genIType x)
>>     genIType min(genIType x, genIType y)
>>     genIType min(genIType x, int y)
>>     genIType max(genIType x, genIType y)
>>     genIType max(genIType x, int y)
>>     genIType clamp(genIType x, genIType minVal, genIType maxVal)
>>     genIType clamp(genIType x, int minVal, int maxVal)
>>     genType trunc(genType x)
>>     genType round(genType x)
>>     genType roundEven(genType x)
>>     genType modf(genType x, out genType i)
>>
>> v2: genIType sign(genIType x) was added in 1.30 GLSL spec, not in
>> 1.50 spec
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108160
>> Signed-off-by: Vadym Shovkoplias 
>> ---
>>   src/compiler/glsl/builtin_functions.cpp | 30 -
>>   1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/compiler/glsl/builtin_functions.cpp
>> b/src/compiler/glsl/builtin_functions.cpp
>> index 5650365d1d..52e0599ad2 100644
>> --- a/src/compiler/glsl/builtin_functions.cpp
>> +++ b/src/compiler/glsl/builtin_functions.cpp
>> @@ -1439,10 +1439,10 @@ builtin_builder::create_builtins()
>>   _##NAME(always_available, glsl_type::vec2_type),  \
>>   _##NAME(always_available, glsl_type::vec3_type),  \
>>   _##NAME(always_available, glsl_type::vec4_type),  \
>> -    _##NAME(always_available, glsl_type::int_type),   \
>> -    _##NAME(always_available, glsl_type::ivec2_type), \
>> -    _##NAME(always_available, glsl_type::ivec3_type), \
>> -    _##NAME(always_available, glsl_type::ivec4_type), \
>> +    _##NAME(v130, glsl_type::int_type),   \
>> +    _##NAME(v130, glsl_type::ivec2_type), \
>> +    _##NAME(v130, glsl_type::ivec3_type), \
>> +    _##NAME(v130, glsl_type::ivec4_type), \
>>   _##NAME(fp64, glsl_type::double_type), \
>>   _##NAME(fp64, glsl_type::dvec2_type),  \
>>   _##NAME(fp64, glsl_type::dvec3_type),  \
>> @@ -1534,14 +1534,14 @@ builtin_builder::create_builtins()
>>   _##NAME(always_available, glsl_type::vec3_type, 
>> glsl_type::vec3_type),  \
>>   _##NAME(always_available, glsl_type::vec4_type, 
>> glsl_type::vec4_type),  \
>>  
>>  
>> \
>> -    _##NAME(always_available, glsl_type::int_type,  
>> glsl_type::int_type),   \
>> -    _##NAME(always_available, glsl_type::ivec2_type,
>> glsl_type::int_type),   \
>> -    _##NAME(always_available, glsl_type::ivec3_type,
>> glsl_type::int_type),   \
>> -    _##NAME(always_available, glsl_type::ivec4_type,
>> glsl_type::int_type),   \
>> +    _##NAME(v130, glsl_type::int_type,  
>> glsl_type::int_type),   \
>> +    _##NAME(v130, glsl_type::ivec2_type,
>> glsl_type::int_type),   \
>> +    _##NAME(v130, glsl_type::ivec3_type,
>> glsl_type::int_type),   \
>> +    _##NAME(v130, glsl_type::ivec4_type,
>> glsl_type::int_type),   \
>>  
>>  
>> \
>> -    _##NAME(always_available, glsl_type::ivec2_type,
>> glsl_type::ivec2_type), \
>> -    _##NAME(always_available, glsl_type::ivec3_type,
>> glsl_type::ivec3_type), \
>> -    _##NAME(always_available, glsl_type::ivec4_type,
>> glsl_type::ivec4_type), \
>> +    _##NAME(v130, glsl_type::ivec2_type,
>> glsl_type::ivec2_type), \
>> +    _##NAME(v130, glsl_type::ivec3_type,
>> glsl_type::ivec3_type), \
>> +    _##NAME(v130, glsl_type::ivec4_type,
>> glsl_type::ivec4_type), \
>>  
>>  
>> \
>>   

Re: [Mesa-dev] [Mesa-stable] [PATCH] mapi: avoid text relocation in x86 tsd stubs

[Ian Romanick]

On 10/31/2018 09:08 PM, Jonathan Gray wrote:
> Make similiar changes to libglvnd to avoid a text relocation in
> x86 tsd stubs fixing the build with lld.
> 
> Signed-off-by: Jonathan Gray 
> Cc: mesa-sta...@lists.freedesktop.org
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108541
> ---
>  src/mapi/entry_x86_tsd.h | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/src/mapi/entry_x86_tsd.h b/src/mapi/entry_x86_tsd.h
> index 0c28c8ff068..e08a02f3db2 100644
> --- a/src/mapi/entry_x86_tsd.h
> +++ b/src/mapi/entry_x86_tsd.h
> @@ -31,7 +31,7 @@
>  #define HIDDEN
>  #endif
>  
> -#define X86_ENTRY_SIZE 32
> +#define X86_ENTRY_SIZE 64
>  
>  __asm__(".text\n"
>  ".balign 32\n"
> @@ -44,12 +44,16 @@ __asm__(".text\n"
> func ":"
>  
>  #define STUB_ASM_CODE(slot) \
> -   "movl " ENTRY_CURRENT_TABLE ", %eax\n\t" \
> +   "call 1f\n\t"\
> +   "1:\n\t" \
> +   "popl %eax\n\t"  \
> +   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
> +   "movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
> +   "mov (%eax), %eax\n\t"   \
> "testl %eax, %eax\n\t"   \
> -   "je 1f\n\t"  \
> -   "jmp *(4 * " slot ")(%eax)\n"\
> +   "jne 1f\n\t" \
> +   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
> "1:\n\t" \
> -   "call " ENTRY_CURRENT_TABLE_GET "\n\t" \
> "jmp *(4 * " slot ")(%eax)"

After this change, the code is:

#define STUB_ASM_CODE(slot) \
   "call 1f\n\t"\
   "1:\n\t" \
   "popl %eax\n\t"  \
   "addl $_GLOBAL_OFFSET_TABLE_+[.-1b], %eax\n\t" \
   "movl " ENTRY_CURRENT_TABLE "@GOT(%eax), %eax\n\t" \
   "mov (%eax), %eax\n\t"   \
   "testl %eax, %eax\n\t"   \
   "jne 1f\n\t" \
   "call " ENTRY_CURRENT_TABLE_GET "@PLT\n\t" \
   "1:\n\t" \
   "jmp *(4 * " slot ")(%eax)"

So there's going to be two labels "1:".  Does that even assemble?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] amd: Make vgpr-spilling depend on llvm version

[Jan Vesely]

The option was removed in LLVM r345763
Signed-off-by: Jan Vesely 
---
 src/amd/common/ac_llvm_util.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 69d9f7b9f3..dc9b684e9d 100644
--- a/src/amd/common/ac_llvm_util.c
+++ b/src/amd/common/ac_llvm_util.c
@@ -153,7 +153,8 @@ static LLVMTargetMachineRef ac_create_target_machine(enum 
radeon_family family,
LLVMTargetRef target = ac_get_llvm_target(triple);
 
snprintf(features, sizeof(features),
-
"+DumpCode,+vgpr-spilling,-fp32-denormals,+fp64-denormals%s%s%s%s",
+"+DumpCode,-fp32-denormals,+fp64-denormals%s%s%s%s%s",
+HAVE_LLVM >= 0x0800 ? "" : ",+vgpr-spilling",
 tm_options & AC_TM_SISCHED ? ",+si-scheduler" : "",
 tm_options & AC_TM_FORCE_ENABLE_XNACK ? ",+xnack" : "",
 tm_options & AC_TM_FORCE_DISABLE_XNACK ? ",-xnack" : "",
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 2/3] mesa/st: enable EXT_sRGB_write_control for Gallium drivers that support it

[Gert Wollny]

Two chunks are leftovers that I have removed locally (see below) 

Am Donnerstag, den 01.11.2018, 12:30 +0100 schrieb Gert Wollny:
> From: Gert Wollny 
> 
> With this patch the extension EXT_sRGB_write_control is enabled for
> gallium drivers that support sRGB formats as render targets.
> 
> Tested (and pass) on r600 (evergreen) and softpipe:
> 
>   dEQP-
> GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*
> 
> with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for
> this), and
> 
>   dEQP-
> GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported
> _enum
> 
> when extension is manually disabled via MESA_EXTENSION_OVERRIDE
> 
> v2: - always enable the extension when sRGB is supported (Ilia
> Mirkin).
> - Correct handling by moving extension initialization to the
>   place where gallium/st actually takes care of this. This also
>   fixes properly disabling the extension via
> MESA_EXTENSION_OVERRIDE
> - reinstate check for desktop GL and add check for the extension
>   when creating the framebuffer
> 
> v3: - Only create sRGB renderbuffers based on Visual.srgbCapable when
>   on desktop GL.
> 
> v4: - Use PIPE_FORMAT_B8G8R8A8_SRGB to check for the capability,
> since this
>   is also the format that is used top check for
> EGL_KHR_gl_colorspace
>   support.  virgl on a GLES host usually doesn't provide this
> format but
>   one can make it available to signal that the host supports this
>   extension.
> 
> v5:  drop check for PIPE_BIND_DISPLAY_TARGET (Marek Olšák)
>  and move the test to the render target format extension table
> 
> Signed-off-by: Gert Wollny 
> ---
>  src/gallium/docs/source/screen.rst |  3 +++
>  src/mesa/state_tracker/st_extensions.c |  5 +++-
>  src/mesa/state_tracker/st_manager.c| 37 --
> 
>  3 files changed, 30 insertions(+), 15 deletions(-)
> 

<<<  removed chunk 1
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/source/screen.rst
> index 0abd164494..da677eb04b 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -477,6 +477,9 @@ subpixel precision bias in bits during
> conservative rasterization.
>0 means no limit.
>  * ``PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET``: The maximum supported
> value for
>of pipe_vertex_element::src_offset.
> +* ``PIPE_CAP_SRGB_WRITE_CONTROL``: Indicates whether the drivers on
> GLES supports
> +  enabling/disabling the conversion from linear space to sRGB at
> framebuffer or
> +  blend time.
>  
>  .. _pipe_capf:
> 
>>>

>  
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 798ee60875..145bcd535b 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -795,6 +795,9 @@ void st_init_extensions(struct pipe_screen
> *screen,
>{ { o(EXT_packed_float) },
>  { PIPE_FORMAT_R11G11B10_FLOAT } },
>  
> +  { { o(EXT_sRGB_write_control) },
> +{ PIPE_FORMAT_B8G8R8A8_SRGB } },
> +
>{ { o(EXT_texture_integer) },
>  { PIPE_FORMAT_R32G32B32A32_UINT,
>PIPE_FORMAT_R32G32B32A32_SINT } },

<<<  removed chunk 2 (whitespace change)
> @@ -1167,7 +1170,7 @@ void st_init_extensions(struct pipe_screen
> *screen,
>consts->MaxFramebufferSamples =
>   get_max_samples_for_formats(screen,
> ARRAY_SIZE(void_formats),
>   void_formats, 32,
> - PIPE_BIND_RENDER_TARGET);
> + PIPE_BIND_RENDER_TARGET);  
>  
>  
>if (extensions->AMD_framebuffer_multisample_advanced) {
>   /* AMD_framebuffer_multisample_advanced */
>>>

> diff --git a/src/mesa/state_tracker/st_manager.c
> b/src/mesa/state_tracker/st_manager.c
> index ceb48dd490..df898beb23 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -295,7 +295,7 @@ st_framebuffer_update_attachments(struct
> st_framebuffer *stfb)
>   */
>  static boolean
>  st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
> -gl_buffer_index idx)
> +gl_buffer_index idx, bool
> prefer_srgb)
>  {
> struct gl_renderbuffer *rb;
> enum pipe_format format;
> @@ -318,7 +318,7 @@ st_framebuffer_add_renderbuffer(struct
> st_framebuffer *stfb,
>break;
> default:
>format = stfb->iface->visual->color_format;
> -  if (stfb->Base.Visual.sRGBCapable)
> +  if (prefer_srgb)
>   format = util_format_srgb(format);
>sw = FALSE;
>break;
> @@ -436,6 +436,7 @@ st_framebuffer_create(struct st_context *st,
> struct st_framebuffer *stfb;
> struct gl_config mode;
> gl_buffer_index idx;
> +   bool prefer_srgb = false;
>  
> if (!stfbi)
>return NULL;
> @@ -457,14 +458,15 @@ st_framebuffer_create(struct 

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Am Donnerstag, den 01.11.2018, 12:32 -0400 schrieb Ilia Mirkin:
> 
> > 
> > It is not different, this extension was specifically written to
> > bring GLES on par with GL in this asspect (although with a
> > different default). 
[...]

> EXT_framebuffer_sRGB is a desktop GL ext. EXT_sRGB_write_control is a
> GLES ext that was meant to provide the same functionality in GLES
Didn't I just write that? 

> You could have hardware that supports neither, or hardware that
> supports both. The differences appear to be at the API level, not at
> the hardware capability level.
That may be so or not (as I said, I don't know why GLES didn't include
this functionality right from the start), but EXT_sRGB_write_control is
locgially different from EXT_framebuffer_sRGB, and I actually think
that it is better to add another flag that names the extension, so that
the code is easier to understand. One example: 

   if (_mesa_is_desktop_gl(st->ctx) ||
   st->ctx->Extensions.EXT_sRGB_write_control)

vs. 

   if (_mesa_is_desktop_gl(st->ctx) ||
   st->ctx->Extensions.EXT_framebuffer_sRGB)

The first one makes it very clear what is going on, with the second
piece of code I have to search to figure out why the desktop extension
EXT_framebuffer_sRGB enables something that is not provided by desktop
GL.

That said, I just saw that there was some cruft left in the second
patch. so I'll have to resubmit it. 

Best, 
Gert
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] egl: use the LC_ALL hammer instead of LANG

[Michel Dänzer]

On 2018-11-01 5:57 p.m., Eric Engestrom wrote:
> Some environment (like Travis apparently) set LC_* vars, messing up the
> sort ordering, so let's use envvar with the highest priority to make
> sure this is actually sorted in ASCII order.
> 
> Suggested-by: Michel Dänzer 
> Fixes: b42dc50a5f1b22103b26 "egl: fix entrypoint sorting test"
> Signed-off-by: Eric Engestrom 
> ---
> Verified, this actually fixes travis:
> https://travis-ci.org/1ace/mesa/jobs/449427385
> ---
>  src/egl/egl-entrypoint-check | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/egl-entrypoint-check b/src/egl/egl-entrypoint-check
> index bb7d6a777a71be5842fc..d6a42722a44c7ed4a5cd 100755
> --- a/src/egl/egl-entrypoint-check
> +++ b/src/egl/egl-entrypoint-check
> @@ -7,5 +7,5 @@ then
>  fi
>  
>  entrypoints=$(grep EGL_ENTRYPOINT "$srcdir"/main/eglentrypoint.h)
> -sorted=$(LANG=C sort <<< "$entrypoints")
> +sorted=$(LC_ALL=C sort <<< "$entrypoints")
>  test "$entrypoints" = "$sorted"
> 

Reviewed-by: Michel Dänzer 

Thanks Eric!


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] egl: use the LC_ALL hammer instead of LANG

[Eric Engestrom]

Some environment (like Travis apparently) set LC_* vars, messing up the
sort ordering, so let's use envvar with the highest priority to make
sure this is actually sorted in ASCII order.

Suggested-by: Michel Dänzer 
Fixes: b42dc50a5f1b22103b26 "egl: fix entrypoint sorting test"
Signed-off-by: Eric Engestrom 
---
Verified, this actually fixes travis:
https://travis-ci.org/1ace/mesa/jobs/449427385
---
 src/egl/egl-entrypoint-check | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/egl-entrypoint-check b/src/egl/egl-entrypoint-check
index bb7d6a777a71be5842fc..d6a42722a44c7ed4a5cd 100755
--- a/src/egl/egl-entrypoint-check
+++ b/src/egl/egl-entrypoint-check
@@ -7,5 +7,5 @@ then
 fi
 
 entrypoints=$(grep EGL_ENTRYPOINT "$srcdir"/main/eglentrypoint.h)
-sorted=$(LANG=C sort <<< "$entrypoints")
+sorted=$(LC_ALL=C sort <<< "$entrypoints")
 test "$entrypoints" = "$sorted"
-- 
Cheers,
  Eric

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Eric Engestrom]

On Thursday, 2018-11-01 17:37:57 +0100, Mathias Fröhlich wrote:
> Hi,
> 
> On Thursday, 1 November 2018 17:28:48 CET Eric Engestrom wrote:
> > Pushed now, but travis still fails:
> > https://travis-ci.org/mesa3d/mesa/jobs/449405406
> > 
> > I'm really confused here, because the LANG is now fixed, so it shouldn't
> > behave differently on different environments?
> > 
> > If anyone has any clue, I'm all ears :)
> 
> May be LC_ALL=C like the sort man page claims or as Michel meant,
> LC_COLLATE=C which is finally the last specific variable to
> overwrite the behavior?

Yeah Michel suggested LC_ALL on irc, which I just tested and it works
even on travis; sending the patch in a minute.

> 
> > > Do I also remember right that the reson for sorting was a binary
> > > search being done on the names for getprocaddress or something?
> > 
> > That's exactly right :)
> > 
> > > So, the ascii table sorting matters, right?
> > 
> > Not sure what you mean? Are you talking about this issue, or something
> > else?
> 
> If the binary search is the reason behind then all is answered.
> Thanks!
> 
> best
> Mathias
> 
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Remove needless indirection in some draw functions.

[Mathias Fröhlich]

Hi Brian,

On Thursday, 1 November 2018 17:02:38 CET Brian Paul wrote:
> Reviewed-by: Brian Paul 

Thanks!
there is more in the queue.

Mathias


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Mathias Fröhlich]

Hi,

On Thursday, 1 November 2018 17:28:48 CET Eric Engestrom wrote:
> Pushed now, but travis still fails:
> https://travis-ci.org/mesa3d/mesa/jobs/449405406
> 
> I'm really confused here, because the LANG is now fixed, so it shouldn't
> behave differently on different environments?
> 
> If anyone has any clue, I'm all ears :)

May be LC_ALL=C like the sort man page claims or as Michel meant,
LC_COLLATE=C which is finally the last specific variable to
overwrite the behavior?

> > Do I also remember right that the reson for sorting was a binary
> > search being done on the names for getprocaddress or something?
> 
> That's exactly right :)
> 
> > So, the ascii table sorting matters, right?
> 
> Not sure what you mean? Are you talking about this issue, or something
> else?

If the binary search is the reason behind then all is answered.
Thanks!

best
Mathias


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Ilia Mirkin]

On Thu, Nov 1, 2018 at 12:17 PM Gert Wollny  wrote:
>
> Am Donnerstag, den 01.11.2018, 12:03 -0400 schrieb Ilia Mirkin:
> > On Thu, Nov 1, 2018 at 11:45 AM Gert Wollny  > m> wrote:
> > >
> > > Am Donnerstag, den 01.11.2018, 11:19 -0400 schrieb Ilia Mirkin:
> > > > On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny  > > > a.co
> > > > m> wrote:
> > > > >
> > > > > Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> > > > > > On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny  > > > > > abor
> > > > > > a.co
> > > > > > m> wrote:
> > > > > > >
> > > > > > > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia
> > > > > > > Mirkin:
> > > > > > > > So ... thinking about this a little more ... how is the
> > > > > > > > new
> > > > > > > > enable
> > > > > > > > different from the existing "EXT_framebuffer_sRGB"
> > > > > > > > enable?
> > > > > > > > When
> > > > > > > > would
> > > > > > > > one be set but not the other?
> > > > > > >
> > > > > > > This one is a GLES extension, there, if the surface
> > > > > > > attached to
> > > > > > > a
> > > > > > > framebuffer is sRGB capable, it behaves always like
> > > > > > > glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension,
> > > > > > > control
> > > > > > > is
> > > > > > > given back to the application. To keep compatibility, the
> > > > > > > default
> > > > > > > is
> > > > > > > still the same behaviour as without the extension (which is
> > > > > > > different
> > > > > > > from desktop GL).
> > > > > >
> > > > > > Yeah, I get that the details of ext itself are different. I'm
> > > > > > talking
> > > > > > about the enable bit -- would one ever be set but not the
> > > > > > other?
> > > > > > If
> > > > > > so, why have two bits?
> > > > >
> > > > > If a virglrenderer GLES host driver doesn't support the
> > > > > extension,
> > > > > then
> > > > > mesa/virgl can not expose the it (I tried it, it doesn't pass
> > > > > the
> > > > > tests), so there you would have EXT_framebuffer_sRGB, but not
> > > > > EXT_sRGB_write_control.
> > > >
> > > > So what does a (mesa backend) driver need to be able to do to
> > > > support
> > > > EXT_sRGB_write_control on top of what's needed for
> > > > EXT_framebuffer_sRGB?
> > > >
> > >
> > > If I attach an sRGB surface to a framebuffer on GLES, then, in
> > > order
> > > to support EXT_sRGB_write_control, the backend must be able switch
> > > on
> > > and off the linear-sRGB conversion on writes to this attachment.
> >
> > Is that different from what's needed to support
> > glEnable/glDisable(GL_FRAMEBUFFER_SRGB) in desktop GL's
> > EXT_framebuffer_sRGB?
>
> It is not different, this extension was specifically written to bring
> GLES on par with GL in this asspect (although with a different
> default). That said, there might be GLES only hardware that
> supports EXT_framebuffer_sRGB but does not support
> EXT_sRGB_write_control, and for these cases you need an extra flag. I
> mean there must be a reason why the GLES spec doesn't require
> EXT_sRGB_write_control ...

EXT_framebuffer_sRGB is a desktop GL ext. EXT_sRGB_write_control is a
GLES ext that was meant to provide the same functionality in GLES
(have a glance at Issue #1 in that spec). You could have hardware that
supports neither, or hardware that supports both. The differences
appear to be at the API level, not at the hardware capability level.

Cheers,

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Eric Engestrom]

On Thursday, 2018-11-01 16:56:50 +0100, Mathias Fröhlich wrote:
> Hi Michel,
> 
> > > There seems to be a failure with the latest patches you pushed.
> > > The patch fixes a failure with the sort order in egl symbols.
> > 
> > Well, now it's broken with other locales. :)
> > 
> > I guess src/egl/egl-entrypoint-check itself should make sure sort runs
> > with locale settings resulting in the expected order.
> 
> I was just about to send something, when Eric sent something.

Pushed now, but travis still fails:
https://travis-ci.org/mesa3d/mesa/jobs/449405406

I'm really confused here, because the LANG is now fixed, so it shouldn't
behave differently on different environments?

If anyone has any clue, I'm all ears :)

> 
> Out of curiosity, which locale does invert the capitals with respect
> to ascii number ordering?

I think pretty much every "human language" locale considers lowercase
and uppercase to be the same letter, which means "DevicesEXT" comes
before "DeviceStringEXT". Nothing's inverted, is just that "devicese"
comes before "devicest". LANG=C behaves differently because it looks at
the ASCII order.

> 
> Do I also remember right that the reson for sorting was a binary
> search being done on the names for getprocaddress or something?

That's exactly right :)

> So, the ascii table sorting matters, right?

Not sure what you mean? Are you talking about this issue, or something
else?

> 
> > BTW, this kind of commentary should be after the --- line, otherwise
> > it's considered part of the commit log by Git tools.
> 
> Ok, thanks!
> Well I should have mentioned, that I usually check if git just rebases fine 
> on a
> branch when it is pushed. And that sent series did not get just eaten up by
> the pushed variant on rebase.
> 
> best
> 
> Mathias
> 
> 
> ___
> 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 v5 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Am Donnerstag, den 01.11.2018, 12:03 -0400 schrieb Ilia Mirkin:
> On Thu, Nov 1, 2018 at 11:45 AM Gert Wollny  m> wrote:
> > 
> > Am Donnerstag, den 01.11.2018, 11:19 -0400 schrieb Ilia Mirkin:
> > > On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny  > > a.co
> > > m> wrote:
> > > > 
> > > > Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> > > > > On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny  > > > > abor
> > > > > a.co
> > > > > m> wrote:
> > > > > > 
> > > > > > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia
> > > > > > Mirkin:
> > > > > > > So ... thinking about this a little more ... how is the
> > > > > > > new
> > > > > > > enable
> > > > > > > different from the existing "EXT_framebuffer_sRGB"
> > > > > > > enable?
> > > > > > > When
> > > > > > > would
> > > > > > > one be set but not the other?
> > > > > > 
> > > > > > This one is a GLES extension, there, if the surface
> > > > > > attached to
> > > > > > a
> > > > > > framebuffer is sRGB capable, it behaves always like
> > > > > > glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension,
> > > > > > control
> > > > > > is
> > > > > > given back to the application. To keep compatibility, the
> > > > > > default
> > > > > > is
> > > > > > still the same behaviour as without the extension (which is
> > > > > > different
> > > > > > from desktop GL).
> > > > > 
> > > > > Yeah, I get that the details of ext itself are different. I'm
> > > > > talking
> > > > > about the enable bit -- would one ever be set but not the
> > > > > other?
> > > > > If
> > > > > so, why have two bits?
> > > > 
> > > > If a virglrenderer GLES host driver doesn't support the
> > > > extension,
> > > > then
> > > > mesa/virgl can not expose the it (I tried it, it doesn't pass
> > > > the
> > > > tests), so there you would have EXT_framebuffer_sRGB, but not
> > > > EXT_sRGB_write_control.
> > > 
> > > So what does a (mesa backend) driver need to be able to do to
> > > support
> > > EXT_sRGB_write_control on top of what's needed for
> > > EXT_framebuffer_sRGB?
> > > 
> > 
> > If I attach an sRGB surface to a framebuffer on GLES, then, in
> > order
> > to support EXT_sRGB_write_control, the backend must be able switch
> > on
> > and off the linear-sRGB conversion on writes to this attachment.
> 
> Is that different from what's needed to support
> glEnable/glDisable(GL_FRAMEBUFFER_SRGB) in desktop GL's
> EXT_framebuffer_sRGB?

It is not different, this extension was specifically written to bring
GLES on par with GL in this asspect (although with a different
default). That said, there might be GLES only hardware that
supports EXT_framebuffer_sRGB but does not support
EXT_sRGB_write_control, and for these cases you need an extra flag. I
mean there must be a reason why the GLES spec doesn't require
EXT_sRGB_write_control ...

Cheers, 
Gert

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: don't install translation files

[Eric Engestrom]

On Thursday, 2018-11-01 09:06:13 -0700, Dylan Baker wrote:
> CC: eric.engest...@intel.com
> Fixes: 7834926a4f5ca0a60ec3d18c87a1e0a68b615820
>("meson: add support for generating translation mo files")

Tested-by: Eric Engestrom 
Reviewed-by: Eric Engestrom 

Thanks :)

> ---
>  src/util/xmlpool/meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/util/xmlpool/meson.build b/src/util/xmlpool/meson.build
> index 1fce397e472..81184fa6b14 100644
> --- a/src/util/xmlpool/meson.build
> +++ b/src/util/xmlpool/meson.build
> @@ -37,4 +37,4 @@ xmlpool_options_h = custom_target(
>  )
>  
>  i18n = import('i18n')
> -i18n.gettext('xmlpool')
> +i18n.gettext('xmlpool', install : false)
> -- 
> 2.19.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Michel Dänzer]

On 2018-11-01 5:03 p.m., Jan Vesely wrote:
> On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote:
>> On Wed, 31 Oct 2018 at 17:41, Jan Vesely  wrote:
>>> On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
 On Wed, 31 Oct 2018 at 16:24, Michel Dänzer  wrote:
> On 2018-10-31 5:19 p.m., Jan Vesely wrote:
>>
>> This might be a stupid question; is the LLVM_CONFIG env var remembered
>> between reconfigure (touch configure.ac; make) or do I need to provide
>> it explicitly every time configure is run?
>
> I don't know the answer, but agree that would be a minimum requirement
> for this change.
>
 Nope, yet it's not really a minimum. LLVM_CONFIG has been around for
 years, it will work for any Mesa checkout since its inception.
 You can safely bisect Mesa and things will just work.
>>>
>>> The question is; Do I have to do "LLVM_CONFIG=..." make every time
>>> bisect changes configure.ac?
>>>
>> You can do (although there's other options if this one seems weird)
>>
>> $ LLVM_CONFIG=... ../autogen.sh
> 
> That does not answer my question.
> 
> suppose the following sequence:
> $ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh
> ...
> llvm:yes
> llvm-config: /usr/local/llvm-4/bin/llvm-config
> llvm-version:4.0.1
> ...
> $ make -j128
> $ touch ../mesa-src/configure.ac
> $ make -j128
> ...
> llvm:yes
> llvm-config: /usr/bin/llvm-config
> llvm-version:7.0.0
> ...
> 
> the second reconfigure silently reverted back to system default llvm.
> That's a loss of capabilty for me.

Thanks for checking, Jan. That's a NAK from me for this patch in the
current form.

FWIW, LLVM_CONFIG is available in the generated Makefiles, so it might
not be too hard to make this work with the environment variable. I don't
know the preferred way to do that however.


P.S. I only just now noticed the discrepancy between the commit log
talking about "deprecation", whereas the patch actually makes the option
ineffective. That's not what deprecation means. Also, I'm not sure how
this patch is related to the series' general theme of bumping the
minimum required LLVM version. Please don't bury unrelated patches in
large series.

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3] autotools: library-dependency when no sse and 32-bit

[Dylan Baker]

Reviewed-by: Dylan Baker 

Quoting Sergii Romantsov (2018-11-01 04:02:43)
> Building of 32bit Mesa may fail if __SSE__ is not specified.
> Added missed dependency from libm.
> 
> v2: avoided dependecy on any flag, just link
> 
> v3: meson doesn't fail, but have added dependency on libm
> 
> CC: Dylan Baker 
> CC: Lionel G Landwerlin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> Signed-off-by: Sergii Romantsov 
> ---
>  src/util/Makefile.am | 3 ++-
>  src/util/meson.build | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/util/Makefile.am b/src/util/Makefile.am
> index d79f2b3..85c7553 100644
> --- a/src/util/Makefile.am
> +++ b/src/util/Makefile.am
> @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
> $(PTHREAD_LIBS) \
> $(CLOCK_LIB) \
> $(ZLIB_LIBS) \
> -   $(LIBATOMIC_LIBS)
> +   $(LIBATOMIC_LIBS) \
> +   -lm
>  
>  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
>  libxmlconfig_la_CFLAGS = \
> diff --git a/src/util/meson.build b/src/util/meson.build
> index 49d84c1..5b82b21 100644
> --- a/src/util/meson.build
> +++ b/src/util/meson.build
> @@ -113,7 +113,7 @@ libmesa_util = static_library(
>'mesa_util',
>[files_mesa_util, format_srgb],
>include_directories : inc_common,
> -  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
> +  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic, dep_m],
>c_args : [c_msvc_compat_args, c_vis_args],
>build_by_default : false
>  )
> -- 
> 2.7.4
> 


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] autotools: library-dependency when no sse and 32-bit

[Dylan Baker]

Please feel free to CC me on the meson patch.

Quoting Sergii Romantsov (2018-11-01 03:46:46)
> Hi,
> meson doesn't fail, but, probably, better to add for sure.
> Will do soon.
> 
> On Thu, Nov 1, 2018 at 12:25 PM Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
> 
> Hi Sergii,
> 
> Do we need the same fix in meson?
> 
> Thanks,
> 
> -
> Lionel
> 
> On 01/11/2018 07:25, Sergii Romantsov wrote:
> 
> Thanks, Dylan.
> Could, please, somebody push it?
> 
> On Tue, Oct 30, 2018 at 5:30 PM Dylan Baker 
> wrote:
> 
> Reviewed-by: Dylan Baker 
> 
> Quoting Sergii Romantsov (2018-10-30 02:45:14)
> > Building of 32bit Mesa may fail if __SSE__ is not specified.
> > Added missed dependency from libm.
> >
> > CC: Dylan Baker 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> > Signed-off-by: Sergii Romantsov 
>  >
> > ---
> >  src/util/Makefile.am | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/util/Makefile.am b/src/util/Makefile.am
> > index d79f2b3..85c7553 100644
> > --- a/src/util/Makefile.am
> > +++ b/src/util/Makefile.am
> > @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
> >         $(PTHREAD_LIBS) \
> >         $(CLOCK_LIB) \
> >         $(ZLIB_LIBS) \
> > -       $(LIBATOMIC_LIBS)
> > +       $(LIBATOMIC_LIBS) \
> > +       -lm
> > 
> >  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
> >  libxmlconfig_la_CFLAGS = \
> > --
> > 2.7.4
> >
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
> 
> --
> Sergii Romantsov
> GlobalLogic Inc.
> www.globallogic.com
> 
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
> 
> 
> 
> --
> Sergii Romantsov
> GlobalLogic Inc.
> www.globallogic.com


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: don't install translation files

[Dylan Baker]

CC: eric.engest...@intel.com
Fixes: 7834926a4f5ca0a60ec3d18c87a1e0a68b615820
   ("meson: add support for generating translation mo files")
---
 src/util/xmlpool/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/xmlpool/meson.build b/src/util/xmlpool/meson.build
index 1fce397e472..81184fa6b14 100644
--- a/src/util/xmlpool/meson.build
+++ b/src/util/xmlpool/meson.build
@@ -37,4 +37,4 @@ xmlpool_options_h = custom_target(
 )
 
 i18n = import('i18n')
-i18n.gettext('xmlpool')
+i18n.gettext('xmlpool', install : false)
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Ilia Mirkin]

On Thu, Nov 1, 2018 at 11:45 AM Gert Wollny  wrote:
>
> Am Donnerstag, den 01.11.2018, 11:19 -0400 schrieb Ilia Mirkin:
> > On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny  > m> wrote:
> > >
> > > Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> > > > On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny  > > > a.co
> > > > m> wrote:
> > > > >
> > > > > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
> > > > > > So ... thinking about this a little more ... how is the new
> > > > > > enable
> > > > > > different from the existing "EXT_framebuffer_sRGB" enable?
> > > > > > When
> > > > > > would
> > > > > > one be set but not the other?
> > > > >
> > > > > This one is a GLES extension, there, if the surface attached to
> > > > > a
> > > > > framebuffer is sRGB capable, it behaves always like
> > > > > glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension,
> > > > > control
> > > > > is
> > > > > given back to the application. To keep compatibility, the
> > > > > default
> > > > > is
> > > > > still the same behaviour as without the extension (which is
> > > > > different
> > > > > from desktop GL).
> > > >
> > > > Yeah, I get that the details of ext itself are different. I'm
> > > > talking
> > > > about the enable bit -- would one ever be set but not the other?
> > > > If
> > > > so, why have two bits?
> > >
> > > If a virglrenderer GLES host driver doesn't support the extension,
> > > then
> > > mesa/virgl can not expose the it (I tried it, it doesn't pass the
> > > tests), so there you would have EXT_framebuffer_sRGB, but not
> > > EXT_sRGB_write_control.
> >
> > So what does a (mesa backend) driver need to be able to do to support
> > EXT_sRGB_write_control on top of what's needed for
> > EXT_framebuffer_sRGB?
> >
> If I attach an sRGB surface to a framebuffer on GLES, then, in order
> to support EXT_sRGB_write_control, the backend must be able switch on
> and off the linear-sRGB conversion on writes to this attachment.

Is that different from what's needed to support
glEnable/glDisable(GL_FRAMEBUFFER_SRGB) in desktop GL's
EXT_framebuffer_sRGB?

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Michel Dänzer]

On 2018-11-01 4:56 p.m., Mathias Fröhlich wrote:
> 
>>> There seems to be a failure with the latest patches you pushed.
>>> The patch fixes a failure with the sort order in egl symbols.
>>
>> Well, now it's broken with other locales. :)
>>
>> I guess src/egl/egl-entrypoint-check itself should make sure sort runs
>> with locale settings resulting in the expected order.
> 
> I was just about to send something, when Eric sent something.
> 
> Out of curiosity, which locale does invert the capitals with respect
> to ascii number ordering?

E.g. LC_COLLATE=de_CH.UTF-8, but I'd be surprised if Emil was using
that, so there are surely others.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 08/12] configure.ac: deprecate --with-llvm-prefix

[Jan Vesely]

On Wed, 2018-10-31 at 18:40 +, Emil Velikov wrote:
> On Wed, 31 Oct 2018 at 17:41, Jan Vesely  wrote:
> > On Wed, 2018-10-31 at 17:22 +, Emil Velikov wrote:
> > > On Wed, 31 Oct 2018 at 16:24, Michel Dänzer  wrote:
> > > > On 2018-10-31 5:19 p.m., Jan Vesely wrote:
> > > > > On Wed, 2018-10-31 at 13:30 +, Emil Velikov wrote:
> > > > > > From: Emil Velikov 
> > > > > > 
> > > > > > The option has been long superseded with LLVM_CONFIG.
> > > > > > Distributions have been using it for a couple of years now.
> > > > > 
> > > > > I've been using it in my configure setup.
> > > > 
> > > > Same here.
> > > > 
> > > Have you tried LLVM_CONFIG, does it not work on your setup?
> > > Alternatively can you update the your scripts, I can provide a patch
> > > if you prefer.
> > 
> > I'm testing mesa/clover for llvm-{5,6,7,git} on three machines, before
> > I start migrating all that setup I wanted to know if a capability is
> > lost and I should start rewriting the scripts or a simple reconfigure
> > in build directories is enough.
> > 
> No capability is lost here.

It is loosing capability to remember configuration. see below.

> 
> > > Even Debian (which I personally consider fairly conservative) has been
> > > using it for a minimum of two years.
> > > https://salsa.debian.org/xorg-team/lib/mesa/commit/436b3472adde14b22e9ce204820dab417cfe00c6
> > 
> > I'm sorry. This is completely irrelevant. I don't care what distros
> > use, I build from source.
> > 
> 
> 
> Hope you don't do the whole distro...
> 
> Although I guess I'm may be an exception by keeping an eye what "my"
> distro does ;-)
> 

Why the mockery? do you not build libraries you work on?
OpenCL programs can run into issues in either mesa or llvm or libclc.
The last one was/is in the relatively worst shape so most of the effort
goes there. Since distros don't offer multiple mesa packages built
against different LLVM versions I need to build from source.

> > > > > This might be a stupid question; is the LLVM_CONFIG env var remembered
> > > > > between reconfigure (touch configure.ac; make) or do I need to provide
> > > > > it explicitly every time configure is run?
> > > > 
> > > > I don't know the answer, but agree that would be a minimum requirement
> > > > for this change.
> > > > 
> > > Nope, yet it's not really a minimum. LLVM_CONFIG has been around for
> > > years, it will work for any Mesa checkout since its inception.
> > > You can safely bisect Mesa and things will just work.
> > 
> > The question is; Do I have to do "LLVM_CONFIG=..." make every time
> > bisect changes configure.ac?
> > 
> You can do (although there's other options if this one seems weird)
> 
> $ LLVM_CONFIG=... ../autogen.sh

That does not answer my question.

suppose the following sequence:
$ LLVM_CONFIG=/usr/local/llvm-4/bin/llvm-config ../mesa-src/autogen.sh
...
llvm:yes
llvm-config: /usr/local/llvm-4/bin/llvm-config
llvm-version:4.0.1
...
$ make -j128
$ touch ../mesa-src/configure.ac
$ make -j128
...
llvm:yes
llvm-config: /usr/bin/llvm-config
llvm-version:7.0.0
...

the second reconfigure silently reverted back to system default llvm.
That's a loss of capabilty for me.
Why was it even moved to env var? what's the problem with having "
--with-llvm-config" (or with-llvm-prefix) configure option?
Why should the build system be focused on distros (with custom
packaging scripts) over those who build from source?

Jan

> HTH
> Emil

-- 
Jan Vesely 


signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Remove needless indirection in some draw functions.

[Brian Paul]

On 11/01/2018 01:46 AM, mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich 
> 
> Hi Paul,
> 
> There is plenty more cleanup opportunity.
> We can probably use a lot more from the generated glapi also for
> these draw functions. But for now what you requested in the last mail.
> 
> please review

Looks great.


Reviewed-by: Brian Paul 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Mathias Fröhlich]

Hi Michel,

> > There seems to be a failure with the latest patches you pushed.
> > The patch fixes a failure with the sort order in egl symbols.
> 
> Well, now it's broken with other locales. :)
> 
> I guess src/egl/egl-entrypoint-check itself should make sure sort runs
> with locale settings resulting in the expected order.

I was just about to send something, when Eric sent something.

Out of curiosity, which locale does invert the capitals with respect
to ascii number ordering?

Do I also remember right that the reson for sorting was a binary
search being done on the names for getprocaddress or something?
So, the ascii table sorting matters, right?

> BTW, this kind of commentary should be after the --- line, otherwise
> it's considered part of the commit log by Git tools.

Ok, thanks!
Well I should have mentioned, that I usually check if git just rebases fine on a
branch when it is pushed. And that sent series did not get just eaten up by
the pushed variant on rebase.

best

Mathias


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] intel: add comment explaining weird-looking code

[Eric Engestrom]

Clang throws warnings here (-Wgnu-variable-sized-type-not-at-end)
because of a variable-sized array at the end of
`drm_i915_query_topology_info` being aliased by the `data` field in
`topology`, but that's the point here, so let's explain it so that
the next me doesn't blindly listen to the compiler :)

Suggested-by: Brian Paul 
Signed-off-by: Eric Engestrom 
---
 src/intel/dev/gen_device_info.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 5dbd06075722f8cc644e..1be76f7bf6fa9da346a0 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -990,6 +990,11 @@ gen_device_info_update_from_masks(struct gen_device_info 
*devinfo,
   uint32_t subslice_mask,
   uint32_t n_eus)
 {
+   /*
+* Note: the `data` field here is the necessary allocation for the
+* zero-length `data` field in drm_i915_query_topology_info.
+* Do not reorder!
+*/
struct {
   struct drm_i915_query_topology_info base;
   uint8_t data[100];
-- 
Cheers,
  Eric

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Am Donnerstag, den 01.11.2018, 11:19 -0400 schrieb Ilia Mirkin:
> On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny  m> wrote:
> > 
> > Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> > > On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny  > > a.co
> > > m> wrote:
> > > > 
> > > > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
> > > > > So ... thinking about this a little more ... how is the new
> > > > > enable
> > > > > different from the existing "EXT_framebuffer_sRGB" enable?
> > > > > When
> > > > > would
> > > > > one be set but not the other?
> > > > 
> > > > This one is a GLES extension, there, if the surface attached to
> > > > a
> > > > framebuffer is sRGB capable, it behaves always like
> > > > glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension,
> > > > control
> > > > is
> > > > given back to the application. To keep compatibility, the
> > > > default
> > > > is
> > > > still the same behaviour as without the extension (which is
> > > > different
> > > > from desktop GL).
> > > 
> > > Yeah, I get that the details of ext itself are different. I'm
> > > talking
> > > about the enable bit -- would one ever be set but not the other?
> > > If
> > > so, why have two bits?
> > 
> > If a virglrenderer GLES host driver doesn't support the extension,
> > then
> > mesa/virgl can not expose the it (I tried it, it doesn't pass the
> > tests), so there you would have EXT_framebuffer_sRGB, but not
> > EXT_sRGB_write_control.
> 
> So what does a (mesa backend) driver need to be able to do to support
> EXT_sRGB_write_control on top of what's needed for
> EXT_framebuffer_sRGB?
> 
If I attach an sRGB surface to a framebuffer on GLES, then, in order
to support EXT_sRGB_write_control, the backend must be able switch on
and off the linear-sRGB conversion on writes to this attachment.

Best, 
Gert

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90157] GLSL ES does not allow non-constant initializers for globals

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=90157

Mark Janes  changed:

   What|Removed |Added

   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |

--- Comment #2 from Mark Janes  ---
Ian, please close if this is a dup

-- 
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

Re: [Mesa-dev] [PATCH mesa] egl: fix entrypoint sorting test

[Mathias Fröhlich]

Hi,

On Thursday, 1 November 2018 16:35:30 CET Eric Engestrom wrote:
> Fixes: 68dc591af16ebb36814e "egl: Fix eglentrypoint.h sort order."
> Cc: Emil Velikov 
> Cc: Mathias Fröhlich 
> Cc: Tapani Pälli 
> Signed-off-by: Eric Engestrom 
> ---
>  src/egl/egl-entrypoint-check | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/egl-entrypoint-check b/src/egl/egl-entrypoint-check
> index 36ee5c615306708d2784..bb7d6a777a71be5842fc 100755
> --- a/src/egl/egl-entrypoint-check
> +++ b/src/egl/egl-entrypoint-check
> @@ -7,5 +7,5 @@ then
>  fi
>  
>  entrypoints=$(grep EGL_ENTRYPOINT "$srcdir"/main/eglentrypoint.h)
> -sorted=$(sort <<< "$entrypoints")
> +sorted=$(LANG=C sort <<< "$entrypoints")
>  test "$entrypoints" = "$sorted"
> 

Of course:

Reviewed-by: Mathias Fröhlich 

Thanks!

Mathias


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa] egl: fix entrypoint sorting test

[Eric Engestrom]

Fixes: 68dc591af16ebb36814e "egl: Fix eglentrypoint.h sort order."
Cc: Emil Velikov 
Cc: Mathias Fröhlich 
Cc: Tapani Pälli 
Signed-off-by: Eric Engestrom 
---
 src/egl/egl-entrypoint-check | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/egl-entrypoint-check b/src/egl/egl-entrypoint-check
index 36ee5c615306708d2784..bb7d6a777a71be5842fc 100755
--- a/src/egl/egl-entrypoint-check
+++ b/src/egl/egl-entrypoint-check
@@ -7,5 +7,5 @@ then
 fi
 
 entrypoints=$(grep EGL_ENTRYPOINT "$srcdir"/main/eglentrypoint.h)
-sorted=$(sort <<< "$entrypoints")
+sorted=$(LANG=C sort <<< "$entrypoints")
 test "$entrypoints" = "$sorted"
-- 
Cheers,
  Eric

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] move variable-sized struct at the end of parent struct

[Brian Paul]

On 11/01/2018 09:29 AM, Eric Engestrom wrote:
> On Thursday, 2018-11-01 12:19:10 +, Lionel Landwerlin wrote:
>> On 01/11/2018 11:59, andrey simiklit wrote:
>>> Hello,
>>>
>>> Please find my comments below:
>>>
>>> On Thu, Nov 1, 2018 at 12:24 PM Eric Engestrom >> > wrote:
>>>
>>>    warning: field 'base' with variable sized type 'struct
>>>  drm_i915_query_topology_info'
>>>    not at the end of a struct or class is a GNU extension
>>>  [-Wgnu-variable-sized-type-not-at-end]
>>>
>>>  Signed-off-by: Eric Engestrom >>  >
>>>  ---
>>>   src/intel/dev/gen_device_info.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>>  diff --git a/src/intel/dev/gen_device_info.c
>>>  b/src/intel/dev/gen_device_info.c
>>>  index 5dbd06075722f8cc644e..242fe163447a4265acfb 100644
>>>  --- a/src/intel/dev/gen_device_info.c
>>>  +++ b/src/intel/dev/gen_device_info.c
>>>  @@ -991,8 +991,8 @@ gen_device_info_update_from_masks(struct
>>>  gen_device_info *devinfo,
>>>                                     uint32_t n_eus)
>>>   {
>>>      struct {
>>>  -      struct drm_i915_query_topology_info base;
>>>         uint8_t data[100];
>>>  +      struct drm_i915_query_topology_info base;
>>>      } topology;
>>>
>>>
>>> I can be wrong, but it seems like here the 'data[100]' field should
>>> rather be placed after the 'base' field
>>> because it was done as far as I understood to allocate memory on the stack
>>> for the 'drm_i915_query_topology_info::data[]' field. I guess that this
>>> patch
>>> may introduce the stack corruption on the following line:
>>>     for (int b = 0; b < topology.base.subslice_offset; b++)
>>>    topology.base.data[b] = (slice_mask >> (b * 8)) & 0xff;
>>
>>
>> Andrey's right, the base field needs to be first and data following.
>>
>> nack :(
> 
> Right, I misunderstood this code (I was confused how it was working in
> the first place, but now I understand).
> Thanks both; the warning is wrong, this code is exactly how it should be :)

But there should probably be a comment explaining what's going on to 
avoid future confusion. :)

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] move variable-sized struct at the end of parent struct

[Eric Engestrom]

On Thursday, 2018-11-01 12:19:10 +, Lionel Landwerlin wrote:
> On 01/11/2018 11:59, andrey simiklit wrote:
> > Hello,
> > 
> > Please find my comments below:
> > 
> > On Thu, Nov 1, 2018 at 12:24 PM Eric Engestrom  > > wrote:
> > 
> >   warning: field 'base' with variable sized type 'struct
> > drm_i915_query_topology_info'
> >   not at the end of a struct or class is a GNU extension
> > [-Wgnu-variable-sized-type-not-at-end]
> > 
> > Signed-off-by: Eric Engestrom  > >
> > ---
> >  src/intel/dev/gen_device_info.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/intel/dev/gen_device_info.c
> > b/src/intel/dev/gen_device_info.c
> > index 5dbd06075722f8cc644e..242fe163447a4265acfb 100644
> > --- a/src/intel/dev/gen_device_info.c
> > +++ b/src/intel/dev/gen_device_info.c
> > @@ -991,8 +991,8 @@ gen_device_info_update_from_masks(struct
> > gen_device_info *devinfo,
> >                                    uint32_t n_eus)
> >  {
> >     struct {
> > -      struct drm_i915_query_topology_info base;
> >        uint8_t data[100];
> > +      struct drm_i915_query_topology_info base;
> >     } topology;
> > 
> > 
> > I can be wrong, but it seems like here the 'data[100]' field should
> > rather be placed after the 'base' field
> > because it was done as far as I understood to allocate memory on the stack
> > for the 'drm_i915_query_topology_info::data[]' field. I guess that this
> > patch
> > may introduce the stack corruption on the following line:
> >    for (int b = 0; b < topology.base.subslice_offset; b++)
> >   topology.base.data[b] = (slice_mask >> (b * 8)) & 0xff;
> 
> 
> Andrey's right, the base field needs to be first and data following.
> 
> nack :(

Right, I misunderstood this code (I was confused how it was working in
the first place, but now I understand).
Thanks both; the warning is wrong, this code is exactly how it should be :)

> 
> 
> > 
> >     assert((slice_mask & 0xff) == slice_mask);
> > -- Cheers,
> >   Eric
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org 
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> > 
> > Regards,
> > Andrii.
> > 
> > ___
> > 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 v2 2/4] Gallium: Add format PIPE_FORMAT_R8_SRGB

[Roland Scheidegger]

Am 01.11.18 um 15:48 schrieb Gert Wollny:
> Am Dienstag, den 30.10.2018, 16:04 + schrieb Roland Scheidegger:
>> With the format ordering in svga_format.c as Ilia mentioned fixed
>> Reviewed-by: Roland Scheidegger 
> 
> CMIIW, but I guess was that your R-b was only for this patch, right?
Right, I didn't have time to look at the others.

Roland


> 
> Best, 
> Gert 
> 
>>
>> Am 30.10.18 um 11:46 schrieb Gert Wollny:
>>> This format is needed to support EXT_texture_sRGB_R8. THe patch
>>> adds a new
>>> format enum, the format entries in Gallium and and svga, the
>>> mapping between
>>> sRGB and linear formats, and tests.
>>>
>>>   v2: - add mapping to linear format for PIPE_FORMATR_R8_SRGB
>>>   v3: - Add texture format to svga format table since otherwise
>>> building
>>> mesa will fail when this driver is enabled. It was not
>>> tested
>>> whether the extension actually works.
>>>   v4: - svga: remove the SVGA specific format definitions and table
>>> entries
>>> and only add correct the location of PIPE_FORMAT_R8_SRGB in
>>> the
>>> format_conversion_table (Ilia Mirkin)
>>>   - Split patch (1/2) to separate Gallium part and mesa/st
>>> part.
>>> (Roland Scheidegger)
>>>   - Trim the commit message to only contain the relevant parts
>>> from the
>>> split.
>>>
>>> Signed-off-by: Gert Wollny 
>>> ---
>>>  src/gallium/auxiliary/util/u_format.csv | 1 +
>>>  src/gallium/auxiliary/util/u_format.h   | 4 
>>>  src/gallium/auxiliary/util/u_format_tests.c | 4 
>>>  src/gallium/drivers/svga/svga_format.c  | 1 +
>>>  src/gallium/include/pipe/p_format.h | 2 ++
>>>  5 files changed, 12 insertions(+)
>>>
>>> diff --git a/src/gallium/auxiliary/util/u_format.csv
>>> b/src/gallium/auxiliary/util/u_format.csv
>>> index f9e4925f27..911ac07d32 100644
>>> --- a/src/gallium/auxiliary/util/u_format.csv
>>> +++ b/src/gallium/auxiliary/util/u_format.csv
>>> @@ -114,6 +114,7 @@ PIPE_FORMAT_I32_FLOAT , plain, 1,
>>> 1, f32 , , , , , r
>>>  
>>>  # SRGB formats
>>>  PIPE_FORMAT_L8_SRGB   , plain, 1, 1, un8
>>> , , , , xxx1, srgb 
>>> +PIPE_FORMAT_R8_SRGB   , plain, 1, 1, un8
>>> , , , , x001, srgb
>>>  PIPE_FORMAT_L8A8_SRGB , plain, 1, 1, un8 , un8
>>> , , , xxxy, srgb 
>>>  PIPE_FORMAT_R8G8B8_SRGB   , plain, 1, 1, un8 , un8 , un8
>>> , , xyz1, srgb 
>>>  PIPE_FORMAT_R8G8B8A8_SRGB , plain, 1, 1, un8 , un8 , un8 ,
>>> un8 , xyzw, srgb 
>>> diff --git a/src/gallium/auxiliary/util/u_format.h
>>> b/src/gallium/auxiliary/util/u_format.h
>>> index e66849c16b..5bcfc1f115 100644
>>> --- a/src/gallium/auxiliary/util/u_format.h
>>> +++ b/src/gallium/auxiliary/util/u_format.h
>>> @@ -925,6 +925,8 @@ util_format_srgb(enum pipe_format format)
>>> switch (format) {
>>> case PIPE_FORMAT_L8_UNORM:
>>>return PIPE_FORMAT_L8_SRGB;
>>> +   case PIPE_FORMAT_R8_UNORM:
>>> +  return PIPE_FORMAT_R8_SRGB;
>>> case PIPE_FORMAT_L8A8_UNORM:
>>>return PIPE_FORMAT_L8A8_SRGB;
>>> case PIPE_FORMAT_R8G8B8_UNORM:
>>> @@ -1001,6 +1003,8 @@ util_format_linear(enum pipe_format format)
>>> switch (format) {
>>> case PIPE_FORMAT_L8_SRGB:
>>>return PIPE_FORMAT_L8_UNORM;
>>> +   case PIPE_FORMAT_R8_SRGB:
>>> +  return PIPE_FORMAT_R8_UNORM;
>>> case PIPE_FORMAT_L8A8_SRGB:
>>>return PIPE_FORMAT_L8A8_UNORM;
>>> case PIPE_FORMAT_R8G8B8_SRGB:
>>> diff --git a/src/gallium/auxiliary/util/u_format_tests.c
>>> b/src/gallium/auxiliary/util/u_format_tests.c
>>> index 9c9a5838d1..dee52533c1 100644
>>> --- a/src/gallium/auxiliary/util/u_format_tests.c
>>> +++ b/src/gallium/auxiliary/util/u_format_tests.c
>>> @@ -236,6 +236,10 @@ util_format_test_cases[] =
>>> {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc),
>>> UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 1.0)},
>>> {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff),
>>> UNPACKED_1x1(1.0, 1.0, 1.0, 1.0)},
>>>  
>>> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0x00),
>>> UNPACKED_1x1(0.0, 0.0, 0.0, 1.0)},
>>> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc),
>>> UNPACKED_1x1(0.502886458033, 0.0, 0.0, 1.0)},
>>> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff),
>>> UNPACKED_1x1(1.0, 0.0, 0.0, 1.0)},
>>> +
>>> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x),
>>> PACKED_1x16(0x), UNPACKED_1x1(0.0, 0.0, 0.0, 0.0)},
>>> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x),
>>> PACKED_1x16(0x00bc), UNPACKED_1x1(0.502886458033, 0.502886458033,
>>> 0.502886458033, 0.0)},
>>> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x),
>>> PACKED_1x16(0x00ff), UNPACKED_1x1(1.0, 1.0, 1.0, 0.0)},
>>> diff --git a/src/gallium/drivers/svga/svga_format.c
>>> b/src/gallium/drivers/svga/svga_format.c
>>> index 9f6a618706..bf1bbca3e2 100644
>>> --- a/src/gallium/drivers/svga/svga_format.c
>>> +++ 

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Ilia Mirkin]

On Thu, Nov 1, 2018 at 10:41 AM Gert Wollny  wrote:
>
> Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> > On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny  > m> wrote:
> > >
> > > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
> > > > So ... thinking about this a little more ... how is the new
> > > > enable
> > > > different from the existing "EXT_framebuffer_sRGB" enable? When
> > > > would
> > > > one be set but not the other?
> > >
> > > This one is a GLES extension, there, if the surface attached to a
> > > framebuffer is sRGB capable, it behaves always like
> > > glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension, control
> > > is
> > > given back to the application. To keep compatibility, the default
> > > is
> > > still the same behaviour as without the extension (which is
> > > different
> > > from desktop GL).
> >
> > Yeah, I get that the details of ext itself are different. I'm talking
> > about the enable bit -- would one ever be set but not the other? If
> > so, why have two bits?
> If a virglrenderer GLES host driver doesn't support the extension, then
> mesa/virgl can not expose the it (I tried it, it doesn't pass the
> tests), so there you would have EXT_framebuffer_sRGB, but not
> EXT_sRGB_write_control.

So what does a (mesa backend) driver need to be able to do to support
EXT_sRGB_write_control on top of what's needed for
EXT_framebuffer_sRGB?

BTW, I'd encourage you to forget about trying to express this in terms
of virgl host driver capabilities -- that's just a backend driver
(virgl) implementation detail, and thus irrelevant to the overall
"what does a backend need to be able to do" question.

Cheers,

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Michel Dänzer]

Hi Mathias,


On 2018-11-01 8:40 a.m., mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich 
> 
> Hi Emil,
> 
> There seems to be a failure with the latest patches you pushed.
> The patch fixes a failure with the sort order in egl symbols.

Well, now it's broken with other locales. :)

I guess src/egl/egl-entrypoint-check itself should make sure sort runs
with locale settings resulting in the expected order.


> FYI, I observed that the latest series that you sent for review
> differs a lot in the individual patches. Kind of looks like a
> problem that may have slipped in during a rebase -i session.
> The total diff past the complete series only differs by this
> current change that introduces the failure.

BTW, this kind of commentary should be after the --- line, otherwise
it's considered part of the commit log by Git tools.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/4] Gallium: Add format PIPE_FORMAT_R8_SRGB

[Gert Wollny]

Am Dienstag, den 30.10.2018, 16:04 + schrieb Roland Scheidegger:
> With the format ordering in svga_format.c as Ilia mentioned fixed
> Reviewed-by: Roland Scheidegger 

CMIIW, but I guess was that your R-b was only for this patch, right?

Best, 
Gert 

> 
> Am 30.10.18 um 11:46 schrieb Gert Wollny:
> > This format is needed to support EXT_texture_sRGB_R8. THe patch
> > adds a new
> > format enum, the format entries in Gallium and and svga, the
> > mapping between
> > sRGB and linear formats, and tests.
> > 
> >   v2: - add mapping to linear format for PIPE_FORMATR_R8_SRGB
> >   v3: - Add texture format to svga format table since otherwise
> > building
> > mesa will fail when this driver is enabled. It was not
> > tested
> > whether the extension actually works.
> >   v4: - svga: remove the SVGA specific format definitions and table
> > entries
> > and only add correct the location of PIPE_FORMAT_R8_SRGB in
> > the
> > format_conversion_table (Ilia Mirkin)
> >   - Split patch (1/2) to separate Gallium part and mesa/st
> > part.
> > (Roland Scheidegger)
> >   - Trim the commit message to only contain the relevant parts
> > from the
> > split.
> > 
> > Signed-off-by: Gert Wollny 
> > ---
> >  src/gallium/auxiliary/util/u_format.csv | 1 +
> >  src/gallium/auxiliary/util/u_format.h   | 4 
> >  src/gallium/auxiliary/util/u_format_tests.c | 4 
> >  src/gallium/drivers/svga/svga_format.c  | 1 +
> >  src/gallium/include/pipe/p_format.h | 2 ++
> >  5 files changed, 12 insertions(+)
> > 
> > diff --git a/src/gallium/auxiliary/util/u_format.csv
> > b/src/gallium/auxiliary/util/u_format.csv
> > index f9e4925f27..911ac07d32 100644
> > --- a/src/gallium/auxiliary/util/u_format.csv
> > +++ b/src/gallium/auxiliary/util/u_format.csv
> > @@ -114,6 +114,7 @@ PIPE_FORMAT_I32_FLOAT , plain, 1,
> > 1, f32 , , , , , r
> >  
> >  # SRGB formats
> >  PIPE_FORMAT_L8_SRGB   , plain, 1, 1, un8
> > , , , , xxx1, srgb 
> > +PIPE_FORMAT_R8_SRGB   , plain, 1, 1, un8
> > , , , , x001, srgb
> >  PIPE_FORMAT_L8A8_SRGB , plain, 1, 1, un8 , un8
> > , , , xxxy, srgb 
> >  PIPE_FORMAT_R8G8B8_SRGB   , plain, 1, 1, un8 , un8 , un8
> > , , xyz1, srgb 
> >  PIPE_FORMAT_R8G8B8A8_SRGB , plain, 1, 1, un8 , un8 , un8 ,
> > un8 , xyzw, srgb 
> > diff --git a/src/gallium/auxiliary/util/u_format.h
> > b/src/gallium/auxiliary/util/u_format.h
> > index e66849c16b..5bcfc1f115 100644
> > --- a/src/gallium/auxiliary/util/u_format.h
> > +++ b/src/gallium/auxiliary/util/u_format.h
> > @@ -925,6 +925,8 @@ util_format_srgb(enum pipe_format format)
> > switch (format) {
> > case PIPE_FORMAT_L8_UNORM:
> >return PIPE_FORMAT_L8_SRGB;
> > +   case PIPE_FORMAT_R8_UNORM:
> > +  return PIPE_FORMAT_R8_SRGB;
> > case PIPE_FORMAT_L8A8_UNORM:
> >return PIPE_FORMAT_L8A8_SRGB;
> > case PIPE_FORMAT_R8G8B8_UNORM:
> > @@ -1001,6 +1003,8 @@ util_format_linear(enum pipe_format format)
> > switch (format) {
> > case PIPE_FORMAT_L8_SRGB:
> >return PIPE_FORMAT_L8_UNORM;
> > +   case PIPE_FORMAT_R8_SRGB:
> > +  return PIPE_FORMAT_R8_UNORM;
> > case PIPE_FORMAT_L8A8_SRGB:
> >return PIPE_FORMAT_L8A8_UNORM;
> > case PIPE_FORMAT_R8G8B8_SRGB:
> > diff --git a/src/gallium/auxiliary/util/u_format_tests.c
> > b/src/gallium/auxiliary/util/u_format_tests.c
> > index 9c9a5838d1..dee52533c1 100644
> > --- a/src/gallium/auxiliary/util/u_format_tests.c
> > +++ b/src/gallium/auxiliary/util/u_format_tests.c
> > @@ -236,6 +236,10 @@ util_format_test_cases[] =
> > {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc),
> > UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 1.0)},
> > {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff),
> > UNPACKED_1x1(1.0, 1.0, 1.0, 1.0)},
> >  
> > +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0x00),
> > UNPACKED_1x1(0.0, 0.0, 0.0, 1.0)},
> > +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc),
> > UNPACKED_1x1(0.502886458033, 0.0, 0.0, 1.0)},
> > +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff),
> > UNPACKED_1x1(1.0, 0.0, 0.0, 1.0)},
> > +
> > {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x),
> > PACKED_1x16(0x), UNPACKED_1x1(0.0, 0.0, 0.0, 0.0)},
> > {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x),
> > PACKED_1x16(0x00bc), UNPACKED_1x1(0.502886458033, 0.502886458033,
> > 0.502886458033, 0.0)},
> > {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x),
> > PACKED_1x16(0x00ff), UNPACKED_1x1(1.0, 1.0, 1.0, 0.0)},
> > diff --git a/src/gallium/drivers/svga/svga_format.c
> > b/src/gallium/drivers/svga/svga_format.c
> > index 9f6a618706..bf1bbca3e2 100644
> > --- a/src/gallium/drivers/svga/svga_format.c
> > +++ b/src/gallium/drivers/svga/svga_format.c
> > @@ -154,6 +154,7 @@ static const struct vgpu10_format_entry
> > format_conversion_table[] =
> >

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Am Donnerstag, den 01.11.2018, 10:34 -0400 schrieb Ilia Mirkin:
> On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny  m> wrote:
> > 
> > Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
> > > So ... thinking about this a little more ... how is the new
> > > enable
> > > different from the existing "EXT_framebuffer_sRGB" enable? When
> > > would
> > > one be set but not the other?
> > 
> > This one is a GLES extension, there, if the surface attached to a
> > framebuffer is sRGB capable, it behaves always like
> > glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension, control
> > is
> > given back to the application. To keep compatibility, the default
> > is
> > still the same behaviour as without the extension (which is
> > different
> > from desktop GL).
> 
> Yeah, I get that the details of ext itself are different. I'm talking
> about the enable bit -- would one ever be set but not the other? If
> so, why have two bits?
If a virglrenderer GLES host driver doesn't support the extension, then
mesa/virgl can not expose the it (I tried it, it doesn't pass the
tests), so there you would have EXT_framebuffer_sRGB, but not
EXT_sRGB_write_control.

Best, 
Gert

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Ilia Mirkin]

On Thu, Nov 1, 2018 at 10:31 AM Gert Wollny  wrote:
>
> Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
> > So ... thinking about this a little more ... how is the new enable
> > different from the existing "EXT_framebuffer_sRGB" enable? When would
> > one be set but not the other?
>
> This one is a GLES extension, there, if the surface attached to a
> framebuffer is sRGB capable, it behaves always like
> glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension, control is
> given back to the application. To keep compatibility, the default is
> still the same behaviour as without the extension (which is different
> from desktop GL).

Yeah, I get that the details of ext itself are different. I'm talking
about the enable bit -- would one ever be set but not the other? If
so, why have two bits?

Cheers,

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

Am Donnerstag, den 01.11.2018, 10:15 -0400 schrieb Ilia Mirkin:
> So ... thinking about this a little more ... how is the new enable
> different from the existing "EXT_framebuffer_sRGB" enable? When would
> one be set but not the other?

This one is a GLES extension, there, if the surface attached to a
framebuffer is sRGB capable, it behaves always like
glEnable(GL_FRAMEBUFFER_SRGB) is set. With this extension, control is
given back to the application. To keep compatibility, the default is
still the same behaviour as without the extension (which is different
from desktop GL).

Best, 
Gert 


> On Thu, Nov 1, 2018 at 7:30 AM Gert Wollny 
> wrote:
> > 
> > From: Gert Wollny 
> > 
> > Dear all,
> > 
> > yet another update, only to the Gallium part: i.e. the format check
> > was
> > simplified according to Mareks comment,
> > 
> > Best,
> > Gert
> > 
> > 
> > Gert Wollny (3):
> >   mesa/core: Add support for EXT_sRGB_write_control
> >   mesa/st: enable EXT_sRGB_write_control for Gallium drivers that
> > support it
> >   intel/i965: Enable extension EXT_sRGB_write_control
> > 
> >  src/gallium/docs/source/screen.rst   |  3 ++
> >  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
> >  src/mesa/main/enable.c   |  4 +--
> >  src/mesa/main/extensions_table.h |  1 +
> >  src/mesa/main/get.c  |  5 +++
> >  src/mesa/main/get_hash_params.py |  1 +
> >  src/mesa/main/mtypes.h   |  1 +
> >  src/mesa/state_tracker/st_extensions.c   |  5 ++-
> >  src/mesa/state_tracker/st_manager.c  | 37 --
> > --
> >  9 files changed, 41 insertions(+), 17 deletions(-)
> > 
> > --
> > 2.18.1
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Ilia Mirkin]

So ... thinking about this a little more ... how is the new enable
different from the existing "EXT_framebuffer_sRGB" enable? When would
one be set but not the other?
On Thu, Nov 1, 2018 at 7:30 AM Gert Wollny  wrote:
>
> From: Gert Wollny 
>
> Dear all,
>
> yet another update, only to the Gallium part: i.e. the format check was
> simplified according to Mareks comment,
>
> Best,
> Gert
>
>
> Gert Wollny (3):
>   mesa/core: Add support for EXT_sRGB_write_control
>   mesa/st: enable EXT_sRGB_write_control for Gallium drivers that
> support it
>   intel/i965: Enable extension EXT_sRGB_write_control
>
>  src/gallium/docs/source/screen.rst   |  3 ++
>  src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
>  src/mesa/main/enable.c   |  4 +--
>  src/mesa/main/extensions_table.h |  1 +
>  src/mesa/main/get.c  |  5 +++
>  src/mesa/main/get_hash_params.py |  1 +
>  src/mesa/main/mtypes.h   |  1 +
>  src/mesa/state_tracker/st_extensions.c   |  5 ++-
>  src/mesa/state_tracker/st_manager.c  | 37 
>  9 files changed, 41 insertions(+), 17 deletions(-)
>
> --
> 2.18.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 3/4] mesa/st: Add support for EXT_texture_sRGB_R8

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 

But one very very minor change, no need to re-send, just fix it up locally:

On Thu, Nov 1, 2018 at 8:00 AM Gert Wollny  wrote:
>
> From: Gert Wollny 
>
> This only adds support on the Gallium core level, for the drivers
> it is likely that additional changes are needed to support the
> new texture format and thereby enabling the extension.
>
> Enables on softpipe and makes pass:
>   dEQP-GLES31.functional.srgb_texture_decode.skip_decode.sr8.*
>
> v2: - add include for getting GL_SR8_EXT
> v4: - since the extension is not required don't bother providing
>   a fallback (Ilia Mirkin)
> - split patch (2/2) to separate Gallium and mesa/st parts
>   (Roland Scheidegger)
> - trim commit message to only contain the history of the patch
>   relevant to this part
> v5: - don't include GLES headers (required enum has been added to glheader.h)
>   (Ilia Mirkin)
>
> Signed-off-by: Gert Wollny 
> ---
>  src/mesa/state_tracker/st_extensions.c | 4 
>  src/mesa/state_tracker/st_format.c | 9 -
>  2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c 
> b/src/mesa/state_tracker/st_extensions.c
> index 798ee60875..16889074f6 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -889,6 +889,10 @@ void st_init_extensions(struct pipe_screen *screen,
>   PIPE_FORMAT_R8G8B8A8_SRGB},
>  GL_TRUE }, /* at least one format must be supported */
>
> +  { { o(EXT_texture_sRGB_R8) },
> +{ PIPE_FORMAT_R8_SRGB },
> +GL_TRUE },
> +
>{ { o(EXT_texture_type_2_10_10_10_REV) },
>  { PIPE_FORMAT_R10G10B10A2_UNORM,
>PIPE_FORMAT_B10G10R10A2_UNORM },
> diff --git a/src/mesa/state_tracker/st_format.c 
> b/src/mesa/state_tracker/st_format.c
> index 16a18c272d..7a57787b23 100644
> --- a/src/mesa/state_tracker/st_format.c
> +++ b/src/mesa/state_tracker/st_format.c
> @@ -54,7 +54,6 @@
>  #include "st_format.h"
>  #include "st_texture.h"
>
> -

Leave this line be. I'm guessing this happened when you removed the
GLES2 header includes.

>  /**
>   * Translate Mesa format to Gallium format.
>   */
> @@ -169,6 +168,8 @@ st_mesa_format_to_pipe_format(const struct st_context *st,
>return PIPE_FORMAT_AL88_SRGB;
> case MESA_FORMAT_L_SRGB8:
>return PIPE_FORMAT_L8_SRGB;
> +   case MESA_FORMAT_R_SRGB8:
> +  return PIPE_FORMAT_R8_SRGB;
> case MESA_FORMAT_BGR_SRGB8:
>return PIPE_FORMAT_R8G8B8_SRGB;
> case MESA_FORMAT_A8B8G8R8_SRGB:
> @@ -719,6 +720,8 @@ st_pipe_format_to_mesa_format(enum pipe_format format)
>return MESA_FORMAT_A8L8_SRGB;
> case PIPE_FORMAT_L8_SRGB:
>return MESA_FORMAT_L_SRGB8;
> +   case PIPE_FORMAT_R8_SRGB:
> +  return MESA_FORMAT_R_SRGB8;
> case PIPE_FORMAT_R8G8B8_SRGB:
>return MESA_FORMAT_BGR_SRGB8;
> case PIPE_FORMAT_ABGR_SRGB:
> @@ -1423,6 +1426,10 @@ static const struct format_mapping format_map[] = {
>  0 },
>{ PIPE_FORMAT_L8_SRGB, DEFAULT_SRGBA_FORMATS }
> },
> +   {
> +  { GL_SR8_EXT, 0 },
> +  { PIPE_FORMAT_R8_SRGB, 0 }
> +   },
>
> /* 16-bit float formats */
> {
> --
> 2.18.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v3 2/4] Gallium: Add format PIPE_FORMAT_R8_SRGB

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 
On Thu, Nov 1, 2018 at 8:00 AM Gert Wollny  wrote:
>
> From: Gert Wollny 
>
> This format is needed to support EXT_texture_sRGB_R8. THe patch adds a new
> format enum, the format entries in Gallium and and svga, the mapping between
> sRGB and linear formats, and tests.
>
>   v2: - add mapping to linear format for PIPE_FORMATR_R8_SRGB
>   v3: - Add texture format to svga format table since otherwise building
> mesa will fail when this driver is enabled. It was not tested
> whether the extension actually works.
>   v4: - svga: remove the SVGA specific format definitions and table entries
> and only add correct the location of PIPE_FORMAT_R8_SRGB in the
> format_conversion_table (Ilia Mirkin)
>   - Split patch (1/2) to separate Gallium part and mesa/st part.
> (Roland Scheidegger)
>   - Trim the commit message to only contain the relevant parts from the
> split.
>   v5: - svga: correct location of PIPE_FORMAT_SRGB_R8 (Ilia Mirkin)
>
> Signed-off-by: Gert Wollny 
> Reviewed-by: Roland Scheidegger 
> ---
>  src/gallium/auxiliary/util/u_format.csv | 1 +
>  src/gallium/auxiliary/util/u_format.h   | 4 
>  src/gallium/auxiliary/util/u_format_tests.c | 4 
>  src/gallium/drivers/svga/svga_format.c  | 1 +
>  src/gallium/include/pipe/p_format.h | 2 ++
>  5 files changed, 12 insertions(+)
>
> diff --git a/src/gallium/auxiliary/util/u_format.csv 
> b/src/gallium/auxiliary/util/u_format.csv
> index f9e4925f27..911ac07d32 100644
> --- a/src/gallium/auxiliary/util/u_format.csv
> +++ b/src/gallium/auxiliary/util/u_format.csv
> @@ -114,6 +114,7 @@ PIPE_FORMAT_I32_FLOAT , plain, 1, 1, f32 ,
>  , , , , r
>
>  # SRGB formats
>  PIPE_FORMAT_L8_SRGB   , plain, 1, 1, un8 , , , , 
> xxx1, srgb
> +PIPE_FORMAT_R8_SRGB   , plain, 1, 1, un8 , , , , 
> x001, srgb
>  PIPE_FORMAT_L8A8_SRGB , plain, 1, 1, un8 , un8 , , , 
> xxxy, srgb
>  PIPE_FORMAT_R8G8B8_SRGB   , plain, 1, 1, un8 , un8 , un8 , , 
> xyz1, srgb
>  PIPE_FORMAT_R8G8B8A8_SRGB , plain, 1, 1, un8 , un8 , un8 , un8 , 
> xyzw, srgb
> diff --git a/src/gallium/auxiliary/util/u_format.h 
> b/src/gallium/auxiliary/util/u_format.h
> index e66849c16b..5bcfc1f115 100644
> --- a/src/gallium/auxiliary/util/u_format.h
> +++ b/src/gallium/auxiliary/util/u_format.h
> @@ -925,6 +925,8 @@ util_format_srgb(enum pipe_format format)
> switch (format) {
> case PIPE_FORMAT_L8_UNORM:
>return PIPE_FORMAT_L8_SRGB;
> +   case PIPE_FORMAT_R8_UNORM:
> +  return PIPE_FORMAT_R8_SRGB;
> case PIPE_FORMAT_L8A8_UNORM:
>return PIPE_FORMAT_L8A8_SRGB;
> case PIPE_FORMAT_R8G8B8_UNORM:
> @@ -1001,6 +1003,8 @@ util_format_linear(enum pipe_format format)
> switch (format) {
> case PIPE_FORMAT_L8_SRGB:
>return PIPE_FORMAT_L8_UNORM;
> +   case PIPE_FORMAT_R8_SRGB:
> +  return PIPE_FORMAT_R8_UNORM;
> case PIPE_FORMAT_L8A8_SRGB:
>return PIPE_FORMAT_L8A8_UNORM;
> case PIPE_FORMAT_R8G8B8_SRGB:
> diff --git a/src/gallium/auxiliary/util/u_format_tests.c 
> b/src/gallium/auxiliary/util/u_format_tests.c
> index 9c9a5838d1..dee52533c1 100644
> --- a/src/gallium/auxiliary/util/u_format_tests.c
> +++ b/src/gallium/auxiliary/util/u_format_tests.c
> @@ -236,6 +236,10 @@ util_format_test_cases[] =
> {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc), 
> UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 1.0)},
> {PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff), 
> UNPACKED_1x1(1.0, 1.0, 1.0, 1.0)},
>
> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0x00), 
> UNPACKED_1x1(0.0, 0.0, 0.0, 1.0)},
> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc), 
> UNPACKED_1x1(0.502886458033, 0.0, 0.0, 1.0)},
> +   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff), 
> UNPACKED_1x1(1.0, 0.0, 0.0, 1.0)},
> +
> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x), 
> UNPACKED_1x1(0.0, 0.0, 0.0, 0.0)},
> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x00bc), 
> UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 0.0)},
> {PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x00ff), 
> UNPACKED_1x1(1.0, 1.0, 1.0, 0.0)},
> diff --git a/src/gallium/drivers/svga/svga_format.c 
> b/src/gallium/drivers/svga/svga_format.c
> index 9f6a618706..cf88e33dfe 100644
> --- a/src/gallium/drivers/svga/svga_format.c
> +++ b/src/gallium/drivers/svga/svga_format.c
> @@ -370,6 +370,7 @@ static const struct vgpu10_format_entry 
> format_conversion_table[] =
> { PIPE_FORMAT_A1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
> { PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
> SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
> { PIPE_FORMAT_A4B4G4R4_UNORM,

Re: [Mesa-dev] [PATCH v3 1/4] mesa/core: Add definitions and translations for EXT_texture_sRGB_R8

[Ilia Mirkin]

Reviewed-by: Ilia Mirkin 
On Thu, Nov 1, 2018 at 8:00 AM Gert Wollny  wrote:
>
> From: Gert Wollny 
>
> v2: - fix format definition line
> - disable  for desktop GL
> - don't add GL_R8_EXT to glext.h since it is already in
>   GLES2/gl2ext.h in glext.h and include this header  where needed
>   (all Emil)
> v3: - swrast: Fill the function table for sRGB_R8
>   The size of the function table is checked at compile time and must
>   correspond to the number of mesa texture formats.
>   dri/swrast being gles-2.0 doesn't support the extension though
> v4: - correct format layout comment (Ilia Mirkin)
> - correct logic for accepting GL_RED only textures (in part Ilia Mirkin)
>   EXT_texture_sRGB_R8 requires OpenGL ES 3.0 which includes
>   ARB_texture_rg/EXT_texture_rg, so one only must check for the first
>   when SR8_EXT is really requested.
> v5: - add define for GL_ES8_XT to glheader.h and don't include GLES
>   headers  (Ilia Mirkin)
>
> Signed-off-by: Gert Wollny 
> ---
>  src/mesa/main/extensions_table.h |  1 +
>  src/mesa/main/formats.c  |  2 ++
>  src/mesa/main/formats.csv|  1 +
>  src/mesa/main/formats.h  |  1 +
>  src/mesa/main/glformats.c| 17 ++---
>  src/mesa/main/glheader.h |  3 +++
>  src/mesa/main/mtypes.h   |  1 +
>  src/mesa/main/texformat.c|  3 +++
>  src/mesa/swrast/s_texfetch.c |  1 +
>  src/mesa/swrast/s_texfetch_tmp.h |  1 +
>  10 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/extensions_table.h 
> b/src/mesa/main/extensions_table.h
> index 47db158313..84084cc3b1 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -295,6 +295,7 @@ EXT(EXT_texture_object  , dummy_true
>  EXT(EXT_texture_rectangle   , NV_texture_rectangle   
> , GLL,  x ,  x ,  x , 2004)
>  EXT(EXT_texture_rg  , ARB_texture_rg 
> ,  x ,  x ,  x , ES2, 2011)
>  EXT(EXT_texture_sRGB, EXT_texture_sRGB   
> , GLL, GLC,  x ,  x , 2004)
> +EXT(EXT_texture_sRGB_R8 , EXT_texture_sRGB_R8
> ,  x ,  x ,  x ,  30, 2015)
>  EXT(EXT_texture_sRGB_decode , EXT_texture_sRGB_decode
> , GLL, GLC,  x ,  30, 2006)
>  EXT(EXT_texture_shared_exponent , EXT_texture_shared_exponent
> , GLL, GLC,  x ,  x , 2004)
>  EXT(EXT_texture_snorm   , EXT_texture_snorm  
> , GLL, GLC,  x ,  x , 2009)
> diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
> index d4cd5d2182..cf2d2bc555 100644
> --- a/src/mesa/main/formats.c
> +++ b/src/mesa/main/formats.c
> @@ -1108,6 +1108,7 @@ _mesa_uncompressed_format_to_type_and_comps(mesa_format 
> format,
>*comps = 4;
>return;
> case MESA_FORMAT_L_SRGB8:
> +   case MESA_FORMAT_R_SRGB8:
>*datatype = GL_UNSIGNED_BYTE;
>*comps = 1;
>return;
> @@ -1670,6 +1671,7 @@ _mesa_format_matches_format_and_type(mesa_format 
> mesa_format,
>(type == GL_UNSIGNED_SHORT_8_8_REV_MESA && littleEndian != 
> swapBytes));
>
> case MESA_FORMAT_R_UNORM8:
> +   case MESA_FORMAT_R_SRGB8:
>return format == GL_RED && type == GL_UNSIGNED_BYTE;
> case MESA_FORMAT_R8G8_UNORM:
>return format == GL_RG && type == GL_UNSIGNED_BYTE && littleEndian;
> diff --git a/src/mesa/main/formats.csv b/src/mesa/main/formats.csv
> index ce53f8f056..cb821fec62 100644
> --- a/src/mesa/main/formats.csv
> +++ b/src/mesa/main/formats.csv
> @@ -158,6 +158,7 @@ MESA_FORMAT_L8A8_SRGB , packed, 1, 1, 
> 1, un8 , un8 , ,
>  MESA_FORMAT_A8L8_SRGB , packed, 1, 1, 1, un8 , un8 , 
> , , yyyx, srgb
>
>  # Array sRGB formats
> +MESA_FORMAT_R_SRGB8   , array , 1, 1, 1, un8 , , 
> , , x001, srgb
>  MESA_FORMAT_L_SRGB8   , array , 1, 1, 1, un8 , , 
> , , xxx1, srgb
>  MESA_FORMAT_BGR_SRGB8 , array , 1, 1, 1, un8 , un8 , un8 
> , , zyx1, srgb
>
> diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
> index 335e4de995..15c561225d 100644
> --- a/src/mesa/main/formats.h
> +++ b/src/mesa/main/formats.h
> @@ -440,6 +440,7 @@ typedef enum
> MESA_FORMAT_X8B8G8R8_SRGB,/*         
> */
> MESA_FORMAT_L8A8_SRGB,/*     
> */
> MESA_FORMAT_A8L8_SRGB,/*     
> */
> +   MESA_FORMAT_R_SRGB8,  /*   */
>
> /* Array sRGB formats */
> MESA_FORMAT_L_SRGB8,   /* ubyte[i] = L */
> diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
> index f8fc36e931..6cdc781875 100644
> --- a/src/mesa/main/glformats.c
> +++ 

[Mesa-dev] [Bug 108508] Graphic glitches with stream output support on OLAND AMD GPU GCN 1.0

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108508

--- Comment #20 from Ahmed Elsayed  ---
Is this record enough or do you need something else? Please, tell me.

-- 
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] [PATCH v2] intel/tools: fix resource leak

[Lionel Landwerlin]

Pushed to master. Thanks Andrey!

On 31/10/2018 11:48, andrey simiklit wrote:

Hello,

Sorry, one more point here.
Could I ask you to push it, because I don't have a push rights :-)

Thanks a lot,
Andrii.

On Fri, Oct 26, 2018 at 6:09 PM Lionel Landwerlin 
mailto:lionel.g.landwer...@intel.com>> 
wrote:


On 26/10/2018 15:29, asimiklit.w...@gmail.com
 wrote:
> From: Andrii Simiklit mailto:andrii.simik...@globallogic.com>>
>
> Some memory and file descriptors are not freed/closed.
>
> v2: fixed case where we skipped the 'aub' variable initialization
>
> Signed-off-by: Andrii Simiklit mailto:andrii.simik...@globallogic.com>>


Still :

Reviewed-by: Lionel Landwerlin mailto:lionel.g.landwer...@intel.com>>


Thanks!


> ---
>   src/intel/tools/error2aub.c | 10 ++
>   1 file changed, 10 insertions(+)
>
> diff --git a/src/intel/tools/error2aub.c
b/src/intel/tools/error2aub.c
> index 8a23d5ef1e..2b850ce885 100644
> --- a/src/intel/tools/error2aub.c
> +++ b/src/intel/tools/error2aub.c
> @@ -326,6 +326,16 @@ main(int argc, char *argv[])
>
>      aub_write_exec(, batch_addr, aub_gtt_size(),
I915_EXEC_RENDER);
>
> +   free(out_filename);
> +   free(line);
> +   if(err_file) {
> +      fclose(err_file);
> +   }
> +   if(aub.file) {
> +      aub_file_finish();
> +   } else if(aub_file) {
> +      fclose(aub_file);
> +   }
>      return EXIT_SUCCESS;
>   }
>


___
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] intel/tools: include stdarg.h in error2aub

[Lionel Landwerlin]

Pushed to master. Thanks!


On 01/11/2018 10:26, Lionel Landwerlin wrote:

Reviewed-by: Lionel Landwerlin 

On 01/11/2018 04:07, Jonathan Gray wrote:

Include stdarg.h in error2aub.c otherwise it fails to build on
OpenBSD due to not finding definitions for va_list va_start va_end.

Signed-off-by: Jonathan Gray 
Cc: mesa-sta...@lists.freedesktop.org
---
  src/intel/tools/error2aub.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 8a23d5ef1e7..b6e056cbcde 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
    #include "aub_write.h"



___
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 mesa] move variable-sized struct at the end of parent struct

[Lionel Landwerlin]

On 01/11/2018 11:59, andrey simiklit wrote:

Hello,

Please find my comments below:

On Thu, Nov 1, 2018 at 12:24 PM Eric Engestrom 
mailto:eric.engest...@intel.com>> wrote:


  warning: field 'base' with variable sized type 'struct
drm_i915_query_topology_info'
  not at the end of a struct or class is a GNU extension
[-Wgnu-variable-sized-type-not-at-end]

Signed-off-by: Eric Engestrom mailto:eric.engest...@intel.com>>
---
 src/intel/dev/gen_device_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/dev/gen_device_info.c
b/src/intel/dev/gen_device_info.c
index 5dbd06075722f8cc644e..242fe163447a4265acfb 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -991,8 +991,8 @@ gen_device_info_update_from_masks(struct
gen_device_info *devinfo,
                                   uint32_t n_eus)
 {
    struct {
-      struct drm_i915_query_topology_info base;
       uint8_t data[100];
+      struct drm_i915_query_topology_info base;
    } topology;


I can be wrong, but it seems like here the 'data[100]' field should 
rather be placed after the 'base' field

because it was done as far as I understood to allocate memory on the stack
for the 'drm_i915_query_topology_info::data[]' field. I guess that 
this patch

may introduce the stack corruption on the following line:
   for (int b = 0; b < topology.base.subslice_offset; b++)
  topology.base.data[b] = (slice_mask >> (b * 8)) & 0xff;



Andrey's right, the base field needs to be first and data following.

nack :(




    assert((slice_mask & 0xff) == slice_mask);
-- 
Cheers,

  Eric

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org 
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Regards,
Andrii.

___
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] [PATCH v3 4/4] r600: Add support for EXT_texture_sRGB_R8

[Gert Wollny]

From: Gert Wollny 

Enables on R600 and makes pass:
  dEQP-GLES31.functional.srgb_texture_decode.skip_decode.sr8.*
  dEQP-GLES31.functional.texture.filtering.cube_array.formats.sr8*

v2: remove chunk for dri/radeon (Emil)

Signed-off-by: Gert Wollny 
---
 src/gallium/drivers/r600/r600_state_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/gallium/drivers/r600/r600_state_common.c 
b/src/gallium/drivers/r600/r600_state_common.c
index e6c1b0be97..2d36541787 100644
--- a/src/gallium/drivers/r600/r600_state_common.c
+++ b/src/gallium/drivers/r600/r600_state_common.c
@@ -2917,6 +2917,7 @@ uint32_t r600_translate_texformat(struct pipe_screen 
*screen,
switch (desc->nr_channels) {
case 1:
result = FMT_8;
+   is_srgb_valid = TRUE;
goto out_word4;
case 2:
result = FMT_8_8;
-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 3/4] mesa/st: Add support for EXT_texture_sRGB_R8

[Gert Wollny]

From: Gert Wollny 

This only adds support on the Gallium core level, for the drivers
it is likely that additional changes are needed to support the
new texture format and thereby enabling the extension.

Enables on softpipe and makes pass:
  dEQP-GLES31.functional.srgb_texture_decode.skip_decode.sr8.*

v2: - add include for getting GL_SR8_EXT
v4: - since the extension is not required don't bother providing
  a fallback (Ilia Mirkin)
- split patch (2/2) to separate Gallium and mesa/st parts
  (Roland Scheidegger)
- trim commit message to only contain the history of the patch
  relevant to this part
v5: - don't include GLES headers (required enum has been added to glheader.h)
  (Ilia Mirkin)

Signed-off-by: Gert Wollny 
---
 src/mesa/state_tracker/st_extensions.c | 4 
 src/mesa/state_tracker/st_format.c | 9 -
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 798ee60875..16889074f6 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -889,6 +889,10 @@ void st_init_extensions(struct pipe_screen *screen,
  PIPE_FORMAT_R8G8B8A8_SRGB},
 GL_TRUE }, /* at least one format must be supported */
 
+  { { o(EXT_texture_sRGB_R8) },
+{ PIPE_FORMAT_R8_SRGB },
+GL_TRUE },
+
   { { o(EXT_texture_type_2_10_10_10_REV) },
 { PIPE_FORMAT_R10G10B10A2_UNORM,
   PIPE_FORMAT_B10G10R10A2_UNORM },
diff --git a/src/mesa/state_tracker/st_format.c 
b/src/mesa/state_tracker/st_format.c
index 16a18c272d..7a57787b23 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -54,7 +54,6 @@
 #include "st_format.h"
 #include "st_texture.h"
 
-
 /**
  * Translate Mesa format to Gallium format.
  */
@@ -169,6 +168,8 @@ st_mesa_format_to_pipe_format(const struct st_context *st,
   return PIPE_FORMAT_AL88_SRGB;
case MESA_FORMAT_L_SRGB8:
   return PIPE_FORMAT_L8_SRGB;
+   case MESA_FORMAT_R_SRGB8:
+  return PIPE_FORMAT_R8_SRGB;
case MESA_FORMAT_BGR_SRGB8:
   return PIPE_FORMAT_R8G8B8_SRGB;
case MESA_FORMAT_A8B8G8R8_SRGB:
@@ -719,6 +720,8 @@ st_pipe_format_to_mesa_format(enum pipe_format format)
   return MESA_FORMAT_A8L8_SRGB;
case PIPE_FORMAT_L8_SRGB:
   return MESA_FORMAT_L_SRGB8;
+   case PIPE_FORMAT_R8_SRGB:
+  return MESA_FORMAT_R_SRGB8;
case PIPE_FORMAT_R8G8B8_SRGB:
   return MESA_FORMAT_BGR_SRGB8;
case PIPE_FORMAT_ABGR_SRGB:
@@ -1423,6 +1426,10 @@ static const struct format_mapping format_map[] = {
 0 },
   { PIPE_FORMAT_L8_SRGB, DEFAULT_SRGBA_FORMATS }
},
+   {
+  { GL_SR8_EXT, 0 },
+  { PIPE_FORMAT_R8_SRGB, 0 }
+   },
 
/* 16-bit float formats */
{
-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 2/4] Gallium: Add format PIPE_FORMAT_R8_SRGB

[Gert Wollny]

From: Gert Wollny 

This format is needed to support EXT_texture_sRGB_R8. THe patch adds a new
format enum, the format entries in Gallium and and svga, the mapping between
sRGB and linear formats, and tests.

  v2: - add mapping to linear format for PIPE_FORMATR_R8_SRGB
  v3: - Add texture format to svga format table since otherwise building
mesa will fail when this driver is enabled. It was not tested
whether the extension actually works.
  v4: - svga: remove the SVGA specific format definitions and table entries
and only add correct the location of PIPE_FORMAT_R8_SRGB in the
format_conversion_table (Ilia Mirkin)
  - Split patch (1/2) to separate Gallium part and mesa/st part.
(Roland Scheidegger)
  - Trim the commit message to only contain the relevant parts from the
split.
  v5: - svga: correct location of PIPE_FORMAT_SRGB_R8 (Ilia Mirkin)

Signed-off-by: Gert Wollny 
Reviewed-by: Roland Scheidegger 
---
 src/gallium/auxiliary/util/u_format.csv | 1 +
 src/gallium/auxiliary/util/u_format.h   | 4 
 src/gallium/auxiliary/util/u_format_tests.c | 4 
 src/gallium/drivers/svga/svga_format.c  | 1 +
 src/gallium/include/pipe/p_format.h | 2 ++
 5 files changed, 12 insertions(+)

diff --git a/src/gallium/auxiliary/util/u_format.csv 
b/src/gallium/auxiliary/util/u_format.csv
index f9e4925f27..911ac07d32 100644
--- a/src/gallium/auxiliary/util/u_format.csv
+++ b/src/gallium/auxiliary/util/u_format.csv
@@ -114,6 +114,7 @@ PIPE_FORMAT_I32_FLOAT , plain, 1, 1, f32 , 
, , , , r
 
 # SRGB formats
 PIPE_FORMAT_L8_SRGB   , plain, 1, 1, un8 , , , , xxx1, 
srgb 
+PIPE_FORMAT_R8_SRGB   , plain, 1, 1, un8 , , , , x001, 
srgb
 PIPE_FORMAT_L8A8_SRGB , plain, 1, 1, un8 , un8 , , , xxxy, 
srgb 
 PIPE_FORMAT_R8G8B8_SRGB   , plain, 1, 1, un8 , un8 , un8 , , xyz1, 
srgb 
 PIPE_FORMAT_R8G8B8A8_SRGB , plain, 1, 1, un8 , un8 , un8 , un8 , xyzw, 
srgb 
diff --git a/src/gallium/auxiliary/util/u_format.h 
b/src/gallium/auxiliary/util/u_format.h
index e66849c16b..5bcfc1f115 100644
--- a/src/gallium/auxiliary/util/u_format.h
+++ b/src/gallium/auxiliary/util/u_format.h
@@ -925,6 +925,8 @@ util_format_srgb(enum pipe_format format)
switch (format) {
case PIPE_FORMAT_L8_UNORM:
   return PIPE_FORMAT_L8_SRGB;
+   case PIPE_FORMAT_R8_UNORM:
+  return PIPE_FORMAT_R8_SRGB;
case PIPE_FORMAT_L8A8_UNORM:
   return PIPE_FORMAT_L8A8_SRGB;
case PIPE_FORMAT_R8G8B8_UNORM:
@@ -1001,6 +1003,8 @@ util_format_linear(enum pipe_format format)
switch (format) {
case PIPE_FORMAT_L8_SRGB:
   return PIPE_FORMAT_L8_UNORM;
+   case PIPE_FORMAT_R8_SRGB:
+  return PIPE_FORMAT_R8_UNORM;
case PIPE_FORMAT_L8A8_SRGB:
   return PIPE_FORMAT_L8A8_UNORM;
case PIPE_FORMAT_R8G8B8_SRGB:
diff --git a/src/gallium/auxiliary/util/u_format_tests.c 
b/src/gallium/auxiliary/util/u_format_tests.c
index 9c9a5838d1..dee52533c1 100644
--- a/src/gallium/auxiliary/util/u_format_tests.c
+++ b/src/gallium/auxiliary/util/u_format_tests.c
@@ -236,6 +236,10 @@ util_format_test_cases[] =
{PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc), 
UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 1.0)},
{PIPE_FORMAT_L8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff), UNPACKED_1x1(1.0, 
1.0, 1.0, 1.0)},
 
+   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0x00), UNPACKED_1x1(0.0, 
0.0, 0.0, 1.0)},
+   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xbc), 
UNPACKED_1x1(0.502886458033, 0.0, 0.0, 1.0)},
+   {PIPE_FORMAT_R8_SRGB, PACKED_1x8(0xff), PACKED_1x8(0xff), UNPACKED_1x1(1.0, 
0.0, 0.0, 1.0)},
+
{PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x), 
UNPACKED_1x1(0.0, 0.0, 0.0, 0.0)},
{PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x00bc), 
UNPACKED_1x1(0.502886458033, 0.502886458033, 0.502886458033, 0.0)},
{PIPE_FORMAT_L8A8_SRGB, PACKED_1x16(0x), PACKED_1x16(0x00ff), 
UNPACKED_1x1(1.0, 1.0, 1.0, 0.0)},
diff --git a/src/gallium/drivers/svga/svga_format.c 
b/src/gallium/drivers/svga/svga_format.c
index 9f6a618706..cf88e33dfe 100644
--- a/src/gallium/drivers/svga/svga_format.c
+++ b/src/gallium/drivers/svga/svga_format.c
@@ -370,6 +370,7 @@ static const struct vgpu10_format_entry 
format_conversion_table[] =
{ PIPE_FORMAT_A1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
{ PIPE_FORMAT_X1B5G5R5_UNORM,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
{ PIPE_FORMAT_A4B4G4R4_UNORM,SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
+   { PIPE_FORMAT_R8_SRGB,   SVGA3D_FORMAT_INVALID,  
SVGA3D_FORMAT_INVALID,   SVGA3D_FORMAT_INVALID,   0 },
 };
 
 
diff --git a/src/gallium/include/pipe/p_format.h 

Re: [Mesa-dev] [PATCH mesa] move variable-sized struct at the end of parent struct

[andrey simiklit]

Hello,

Please find my comments below:

On Thu, Nov 1, 2018 at 12:24 PM Eric Engestrom 
wrote:

>   warning: field 'base' with variable sized type 'struct
> drm_i915_query_topology_info'
>   not at the end of a struct or class is a GNU extension
> [-Wgnu-variable-sized-type-not-at-end]
>
> Signed-off-by: Eric Engestrom 
> ---
>  src/intel/dev/gen_device_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/intel/dev/gen_device_info.c
> b/src/intel/dev/gen_device_info.c
> index 5dbd06075722f8cc644e..242fe163447a4265acfb 100644
> --- a/src/intel/dev/gen_device_info.c
> +++ b/src/intel/dev/gen_device_info.c
> @@ -991,8 +991,8 @@ gen_device_info_update_from_masks(struct
> gen_device_info *devinfo,
>uint32_t n_eus)
>  {
> struct {
> -  struct drm_i915_query_topology_info base;
>uint8_t data[100];
> +  struct drm_i915_query_topology_info base;
> } topology;
>

I can be wrong, but it seems like here the 'data[100]' field should rather
be placed after the 'base' field
because it was done as far as I understood to allocate memory on the stack
for the 'drm_i915_query_topology_info::data[]' field. I guess that this
patch
may introduce the stack corruption on the following line:
   for (int b = 0; b < topology.base.subslice_offset; b++)
  topology.base.data[b] = (slice_mask >> (b * 8)) & 0xff;



assert((slice_mask & 0xff) == slice_mask);
> --
> Cheers,
>   Eric
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

Regards,
Andrii.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 1/4] mesa/core: Add definitions and translations for EXT_texture_sRGB_R8

[Gert Wollny]

From: Gert Wollny 

v2: - fix format definition line
- disable  for desktop GL
- don't add GL_R8_EXT to glext.h since it is already in
  GLES2/gl2ext.h in glext.h and include this header  where needed
  (all Emil)
v3: - swrast: Fill the function table for sRGB_R8
  The size of the function table is checked at compile time and must
  correspond to the number of mesa texture formats.
  dri/swrast being gles-2.0 doesn't support the extension though
v4: - correct format layout comment (Ilia Mirkin)
- correct logic for accepting GL_RED only textures (in part Ilia Mirkin)
  EXT_texture_sRGB_R8 requires OpenGL ES 3.0 which includes
  ARB_texture_rg/EXT_texture_rg, so one only must check for the first
  when SR8_EXT is really requested.
v5: - add define for GL_ES8_XT to glheader.h and don't include GLES
  headers  (Ilia Mirkin)

Signed-off-by: Gert Wollny 
---
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/formats.c  |  2 ++
 src/mesa/main/formats.csv|  1 +
 src/mesa/main/formats.h  |  1 +
 src/mesa/main/glformats.c| 17 ++---
 src/mesa/main/glheader.h |  3 +++
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/main/texformat.c|  3 +++
 src/mesa/swrast/s_texfetch.c |  1 +
 src/mesa/swrast/s_texfetch_tmp.h |  1 +
 10 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 47db158313..84084cc3b1 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -295,6 +295,7 @@ EXT(EXT_texture_object  , dummy_true
 EXT(EXT_texture_rectangle   , NV_texture_rectangle 
  , GLL,  x ,  x ,  x , 2004)
 EXT(EXT_texture_rg  , ARB_texture_rg   
  ,  x ,  x ,  x , ES2, 2011)
 EXT(EXT_texture_sRGB, EXT_texture_sRGB 
  , GLL, GLC,  x ,  x , 2004)
+EXT(EXT_texture_sRGB_R8 , EXT_texture_sRGB_R8  
  ,  x ,  x ,  x ,  30, 2015)
 EXT(EXT_texture_sRGB_decode , EXT_texture_sRGB_decode  
  , GLL, GLC,  x ,  30, 2006)
 EXT(EXT_texture_shared_exponent , EXT_texture_shared_exponent  
  , GLL, GLC,  x ,  x , 2004)
 EXT(EXT_texture_snorm   , EXT_texture_snorm
  , GLL, GLC,  x ,  x , 2009)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index d4cd5d2182..cf2d2bc555 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -1108,6 +1108,7 @@ _mesa_uncompressed_format_to_type_and_comps(mesa_format 
format,
   *comps = 4;
   return;
case MESA_FORMAT_L_SRGB8:
+   case MESA_FORMAT_R_SRGB8:
   *datatype = GL_UNSIGNED_BYTE;
   *comps = 1;
   return;
@@ -1670,6 +1671,7 @@ _mesa_format_matches_format_and_type(mesa_format 
mesa_format,
   (type == GL_UNSIGNED_SHORT_8_8_REV_MESA && littleEndian != 
swapBytes));
 
case MESA_FORMAT_R_UNORM8:
+   case MESA_FORMAT_R_SRGB8:
   return format == GL_RED && type == GL_UNSIGNED_BYTE;
case MESA_FORMAT_R8G8_UNORM:
   return format == GL_RG && type == GL_UNSIGNED_BYTE && littleEndian;
diff --git a/src/mesa/main/formats.csv b/src/mesa/main/formats.csv
index ce53f8f056..cb821fec62 100644
--- a/src/mesa/main/formats.csv
+++ b/src/mesa/main/formats.csv
@@ -158,6 +158,7 @@ MESA_FORMAT_L8A8_SRGB , packed, 1, 1, 
1, un8 , un8 , ,
 MESA_FORMAT_A8L8_SRGB , packed, 1, 1, 1, un8 , un8 , , 
, yyyx, srgb
 
 # Array sRGB formats
+MESA_FORMAT_R_SRGB8   , array , 1, 1, 1, un8 , , , 
, x001, srgb
 MESA_FORMAT_L_SRGB8   , array , 1, 1, 1, un8 , , , 
, xxx1, srgb
 MESA_FORMAT_BGR_SRGB8 , array , 1, 1, 1, un8 , un8 , un8 , 
, zyx1, srgb
 
diff --git a/src/mesa/main/formats.h b/src/mesa/main/formats.h
index 335e4de995..15c561225d 100644
--- a/src/mesa/main/formats.h
+++ b/src/mesa/main/formats.h
@@ -440,6 +440,7 @@ typedef enum
MESA_FORMAT_X8B8G8R8_SRGB,/*         */
MESA_FORMAT_L8A8_SRGB,/*     */
MESA_FORMAT_A8L8_SRGB,/*     */
+   MESA_FORMAT_R_SRGB8,  /*   */
 
/* Array sRGB formats */
MESA_FORMAT_L_SRGB8,   /* ubyte[i] = L */
diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index f8fc36e931..6cdc781875 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -2486,6 +2486,15 @@ _mesa_base_tex_format(const struct gl_context *ctx, 
GLint internalFormat)
   }
}
 
+   if (ctx->Extensions.EXT_texture_sRGB_R8) {
+  switch (internalFormat) {
+  case GL_SR8_EXT:
+ return GL_RED;
+  default:
+ ; /* fallthrough */
+

[Mesa-dev] [PATCH v3 0/4] Add support for EXT_texture_sRGB_R8 to core and gallium

[Gert Wollny]

From: Gert Wollny 

Dear all, 

This is an update to the series, changes applied as suggested by 
Ilia and Roland: 

v3: 
- Add GL_SR8_EXT enum to glheaders.h and don't include GLES2 headers
- reorder svga format table. 

v2: 
- split the Gallium-mesa/st patch in two according parts (Roland) 
- do away most of the SVGA changes and only keep the additional entry 
  in the format table to make the code compile (Ilia) 
- Don't provide a fallback format in mesa/st (Ilia)
- rework the logic when a GL_RED format should be accepted on GLES

Thanks for reviewing, 
Gert 

Gert Wollny (4):
  mesa/core: Add definitions and translations for EXT_texture_sRGB_R8
  Gallium: Add format PIPE_FORMAT_R8_SRGB
  mesa/st: Add support for EXT_texture_sRGB_R8
  r600: Add support for EXT_texture_sRGB_R8

 src/gallium/auxiliary/util/u_format.csv  |  1 +
 src/gallium/auxiliary/util/u_format.h|  4 
 src/gallium/auxiliary/util/u_format_tests.c  |  4 
 src/gallium/drivers/r600/r600_state_common.c |  1 +
 src/gallium/drivers/svga/svga_format.c   |  1 +
 src/gallium/include/pipe/p_format.h  |  2 ++
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/formats.c  |  2 ++
 src/mesa/main/formats.csv|  1 +
 src/mesa/main/formats.h  |  1 +
 src/mesa/main/glformats.c| 17 ++---
 src/mesa/main/glheader.h |  3 +++
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/main/texformat.c|  3 +++
 src/mesa/state_tracker/st_extensions.c   |  4 
 src/mesa/state_tracker/st_format.c   |  9 -
 src/mesa/swrast/s_texfetch.c |  1 +
 src/mesa/swrast/s_texfetch_tmp.h |  1 +
 18 files changed, 53 insertions(+), 4 deletions(-)

-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gbm: Clarify acceptable formats for gbm_bo

[Daniel Stone]

gbm_bo_create() was presumably meant to originally accept gbm_bo_format
enums, but it's accepted GBM_FORMAT_* tokens since the dawn of time.
This is good, since gbm_bo_format is rarely used and covers a lot less
ground than GBM_FORMAT_*.

Change the documentation to refer to both; this involves removing a 'see
also' for gbm_bo_format, since we can't also use \sa to refer to a
family of anonymous #defines.

Signed-off-by: Daniel Stone 
Reported-by: Pekka Paalanen 
---
 src/gbm/main/gbm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 0bf2922bacd..ee4fd3bd444 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -448,14 +448,14 @@ gbm_bo_destroy(struct gbm_bo *bo)
  * \param gbm The gbm device returned from gbm_create_device()
  * \param width The width for the buffer
  * \param height The height for the buffer
- * \param format The format to use for the buffer
+ * \param format The format to use for the buffer, from GBM_FORMAT_* or
+ * GBM_BO_FORMAT_* tokens
  * \param usage The union of the usage flags for this buffer
  *
  * \return A newly allocated buffer that should be freed with gbm_bo_destroy()
  * when no longer needed. If an error occurs during allocation %NULL will be
  * returned and errno set.
  *
- * \sa enum gbm_bo_format for the list of formats
  * \sa enum gbm_bo_flags for the list of usage flags
  */
 GBM_EXPORT struct gbm_bo *
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 2/3] mesa/st: enable EXT_sRGB_write_control for Gallium drivers that support it

[Gert Wollny]

From: Gert Wollny 

With this patch the extension EXT_sRGB_write_control is enabled for
gallium drivers that support sRGB formats as render targets.

Tested (and pass) on r600 (evergreen) and softpipe:

  dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*

with "MESA_GLES_VERSION_OVERRIDE=3.2" (the tests needlessly check for this), and

  
dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_unsupported_enum

when extension is manually disabled via MESA_EXTENSION_OVERRIDE

v2: - always enable the extension when sRGB is supported (Ilia Mirkin).
- Correct handling by moving extension initialization to the
  place where gallium/st actually takes care of this. This also
  fixes properly disabling the extension via MESA_EXTENSION_OVERRIDE
- reinstate check for desktop GL and add check for the extension
  when creating the framebuffer

v3: - Only create sRGB renderbuffers based on Visual.srgbCapable when
  on desktop GL.

v4: - Use PIPE_FORMAT_B8G8R8A8_SRGB to check for the capability, since this
  is also the format that is used top check for EGL_KHR_gl_colorspace
  support.  virgl on a GLES host usually doesn't provide this format but
  one can make it available to signal that the host supports this
  extension.

v5:  drop check for PIPE_BIND_DISPLAY_TARGET (Marek Olšák)
 and move the test to the render target format extension table

Signed-off-by: Gert Wollny 
---
 src/gallium/docs/source/screen.rst |  3 +++
 src/mesa/state_tracker/st_extensions.c |  5 +++-
 src/mesa/state_tracker/st_manager.c| 37 --
 3 files changed, 30 insertions(+), 15 deletions(-)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index 0abd164494..da677eb04b 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -477,6 +477,9 @@ subpixel precision bias in bits during conservative 
rasterization.
   0 means no limit.
 * ``PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET``: The maximum supported value for
   of pipe_vertex_element::src_offset.
+* ``PIPE_CAP_SRGB_WRITE_CONTROL``: Indicates whether the drivers on GLES 
supports
+  enabling/disabling the conversion from linear space to sRGB at framebuffer or
+  blend time.
 
 .. _pipe_capf:
 
diff --git a/src/mesa/state_tracker/st_extensions.c 
b/src/mesa/state_tracker/st_extensions.c
index 798ee60875..145bcd535b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -795,6 +795,9 @@ void st_init_extensions(struct pipe_screen *screen,
   { { o(EXT_packed_float) },
 { PIPE_FORMAT_R11G11B10_FLOAT } },
 
+  { { o(EXT_sRGB_write_control) },
+{ PIPE_FORMAT_B8G8R8A8_SRGB } },
+
   { { o(EXT_texture_integer) },
 { PIPE_FORMAT_R32G32B32A32_UINT,
   PIPE_FORMAT_R32G32B32A32_SINT } },
@@ -1167,7 +1170,7 @@ void st_init_extensions(struct pipe_screen *screen,
   consts->MaxFramebufferSamples =
  get_max_samples_for_formats(screen, ARRAY_SIZE(void_formats),
  void_formats, 32,
- PIPE_BIND_RENDER_TARGET);
+ PIPE_BIND_RENDER_TARGET);   
 
   if (extensions->AMD_framebuffer_multisample_advanced) {
  /* AMD_framebuffer_multisample_advanced */
diff --git a/src/mesa/state_tracker/st_manager.c 
b/src/mesa/state_tracker/st_manager.c
index ceb48dd490..df898beb23 100644
--- a/src/mesa/state_tracker/st_manager.c
+++ b/src/mesa/state_tracker/st_manager.c
@@ -295,7 +295,7 @@ st_framebuffer_update_attachments(struct st_framebuffer 
*stfb)
  */
 static boolean
 st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
-gl_buffer_index idx)
+gl_buffer_index idx, bool prefer_srgb)
 {
struct gl_renderbuffer *rb;
enum pipe_format format;
@@ -318,7 +318,7 @@ st_framebuffer_add_renderbuffer(struct st_framebuffer *stfb,
   break;
default:
   format = stfb->iface->visual->color_format;
-  if (stfb->Base.Visual.sRGBCapable)
+  if (prefer_srgb)
  format = util_format_srgb(format);
   sw = FALSE;
   break;
@@ -436,6 +436,7 @@ st_framebuffer_create(struct st_context *st,
struct st_framebuffer *stfb;
struct gl_config mode;
gl_buffer_index idx;
+   bool prefer_srgb = false;
 
if (!stfbi)
   return NULL;
@@ -457,14 +458,15 @@ st_framebuffer_create(struct st_context *st,
 * format such that util_format_srgb(visual->color_format) can be supported
 * by the pipe driver.  We still need to advertise the capability here.
 *
-* For GLES, however, sRGB framebuffer write is controlled only by the
-* capability of the framebuffer.  There is GL_EXT_sRGB_write_control to
-* give applications the control back, but sRGB write is still enabled by
-* default.  To avoid unexpected results, we should not 

[Mesa-dev] [PATCH v5 3/3] intel/i965: Enable extension EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

v2: Fix ordering of extensions (Ian Romanick)

Enables and passes on i965:
  dEQP-GLES31.functional.fbo.srgb_write_control.framebuffer_srgb_enabled*

Signed-off-by: Gert Wollny 
---
 src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c 
b/src/mesa/drivers/dri/i965/intel_extensions.c
index d7e02efb54..3c147291ff 100644
--- a/src/mesa/drivers/dri/i965/intel_extensions.c
+++ b/src/mesa/drivers/dri/i965/intel_extensions.c
@@ -104,6 +104,7 @@ intelInitExtensions(struct gl_context *ctx)
ctx->Extensions.EXT_point_parameters = true;
ctx->Extensions.EXT_provoking_vertex = true;
ctx->Extensions.EXT_render_snorm = true;
+   ctx->Extensions.EXT_sRGB_write_control = true;
ctx->Extensions.EXT_stencil_two_side = true;
ctx->Extensions.EXT_texture_array = true;
ctx->Extensions.EXT_texture_env_dot3 = true;
-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] winsys/amdgpu: Stop using amdgpu_bo_handle_type_kms_noimport

[Michel Dänzer]

From: Michel Dänzer 

It only behaves any different from amdgpu_bo_handle_type_kms with
libdrm 2.4.93, and it breaks if an older version is picked up.

Bugzilla: https://bugs.freedesktop.org/108096
Signed-off-by: Michel Dänzer 
---
 src/gallium/winsys/amdgpu/drm/amdgpu_bo.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c 
b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
index 68f0562a644..f49fb47b80e 100644
--- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
+++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
@@ -486,7 +486,7 @@ static struct amdgpu_winsys_bo *amdgpu_create_bo(struct 
amdgpu_winsys *ws,
else if (initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align64(size, ws->info.gart_page_size);
 
-   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport, 
>u.real.kms_handle);
+   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms, >u.real.kms_handle);
 
amdgpu_add_buffer_to_global_list(bo);
 
@@ -1355,7 +1355,7 @@ static struct pb_buffer *amdgpu_bo_from_handle(struct 
radeon_winsys *rws,
else if (bo->initial_domain & RADEON_DOMAIN_GTT)
   ws->allocated_gtt += align64(bo->base.size, ws->info.gart_page_size);
 
-   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport, 
>u.real.kms_handle);
+   amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms, >u.real.kms_handle);
 
amdgpu_add_buffer_to_global_list(bo);
 
@@ -1463,7 +1463,7 @@ static struct pb_buffer *amdgpu_bo_from_ptr(struct 
radeon_winsys *rws,
 
 amdgpu_add_buffer_to_global_list(bo);
 
-amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms_noimport, 
>u.real.kms_handle);
+amdgpu_bo_export(bo->bo, amdgpu_bo_handle_type_kms, 
>u.real.kms_handle);
 
 return (struct pb_buffer*)bo;
 
-- 
2.19.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 1/3] mesa/core: Add support for EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

This GLES extension gives the applications the control over deciding whether
the conversion from linear space to sRGB is necessary by enabling or
disabling this conversion at framebuffer write or blending time just
like it is possible for desktop GL.

v2: - Correct the extension table to list the extension as GLES only
- drop EXTRA_API_ES3, the requirements for get operations listed
  here get OR-ed. (both Ilia Mirkin)

Signed-off-by: Gert Wollny 
---
 src/mesa/main/enable.c   | 4 ++--
 src/mesa/main/extensions_table.h | 1 +
 src/mesa/main/get.c  | 5 +
 src/mesa/main/get_hash_params.py | 1 +
 src/mesa/main/mtypes.h   | 1 +
 5 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/enable.c b/src/mesa/main/enable.c
index bd3e493da5..06c5a0eb68 100644
--- a/src/mesa/main/enable.c
+++ b/src/mesa/main/enable.c
@@ -1125,7 +1125,7 @@ _mesa_set_enable(struct gl_context *ctx, GLenum cap, 
GLboolean state)
 
   /* GL3.0 - GL_framebuffer_sRGB */
   case GL_FRAMEBUFFER_SRGB_EXT:
- if (!_mesa_is_desktop_gl(ctx))
+ if (!_mesa_is_desktop_gl(ctx) && 
!ctx->Extensions.EXT_sRGB_write_control)
 goto invalid_enum_error;
  CHECK_EXTENSION(EXT_framebuffer_sRGB, cap);
  _mesa_set_framebuffer_srgb(ctx, state);
@@ -1765,7 +1765,7 @@ _mesa_IsEnabled( GLenum cap )
 
   /* GL3.0 - GL_framebuffer_sRGB */
   case GL_FRAMEBUFFER_SRGB_EXT:
- if (!_mesa_is_desktop_gl(ctx))
+ if (!_mesa_is_desktop_gl(ctx) && 
!ctx->Extensions.EXT_sRGB_write_control)
 goto invalid_enum_error;
  CHECK_EXTENSION(EXT_framebuffer_sRGB);
  return ctx->Color.sRGBEnabled;
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 47db158313..f7d3e78624 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -265,6 +265,7 @@ EXT(EXT_shader_integer_mix  , 
EXT_shader_integer_mix
 EXT(EXT_shader_io_blocks, dummy_true   
  ,  x ,  x ,  x ,  31, 2014)
 EXT(EXT_shader_samples_identical, EXT_shader_samples_identical 
  , GLL, GLC,  x ,  31, 2015)
 EXT(EXT_shadow_funcs, ARB_shadow   
  , GLL,  x ,  x ,  x , 2002)
+EXT(EXT_sRGB_write_control  , EXT_sRGB_write_control   
  ,   x,  x ,  x ,  30, 2013)
 EXT(EXT_stencil_two_side, EXT_stencil_two_side 
  , GLL,  x ,  x ,  x , 2001)
 EXT(EXT_stencil_wrap, dummy_true   
  , GLL,  x ,  x ,  x , 2002)
 EXT(EXT_subtexture  , dummy_true   
  , GLL,  x ,  x ,  x , 1995)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 1b1679e8bf..3a77bc6f8d 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -394,6 +394,11 @@ static const int extra_ARB_compute_shader_es31[] = {
EXTRA_END
 };
 
+static const int extra_EXT_sRGB_write_control_es30[] = {
+   EXT(EXT_sRGB_write_control),
+   EXTRA_END
+};
+
 static const int extra_ARB_shader_storage_buffer_object_es31[] = {
EXT(ARB_shader_storage_buffer_object),
EXTRA_API_ES31,
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 1840db6ebb..822fab8151 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -262,6 +262,7 @@ descriptor=[
 # Enums in GLES2, GLES3
 { "apis": ["GLES2", "GLES3"], "params": [
   [ "GPU_DISJOINT_EXT", "LOC_CUSTOM, TYPE_INT, 0, 
extra_EXT_disjoint_timer_query" ],
+  [ "FRAMEBUFFER_SRGB_EXT", "CONTEXT_BOOL(Color.sRGBEnabled), 
extra_EXT_sRGB_write_control_es30" ],
 ]},
 
 { "apis": ["GL", "GL_CORE", "GLES2"], "params": [
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9ed49b7ff2..31cf62fdb6 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -4253,6 +4253,7 @@ struct gl_extensions
GLboolean EXT_semaphore_fd;
GLboolean EXT_shader_integer_mix;
GLboolean EXT_shader_samples_identical;
+   GLboolean EXT_sRGB_write_control;
GLboolean EXT_stencil_two_side;
GLboolean EXT_texture_array;
GLboolean EXT_texture_compression_latc;
-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v5 0/3] Add and enable extension EXT_sRGB_write_control

[Gert Wollny]

From: Gert Wollny 

Dear all, 

yet another update, only to the Gallium part: i.e. the format check was 
simplified according to Mareks comment, 

Best, 
Gert 


Gert Wollny (3):
  mesa/core: Add support for EXT_sRGB_write_control
  mesa/st: enable EXT_sRGB_write_control for Gallium drivers that
support it
  intel/i965: Enable extension EXT_sRGB_write_control

 src/gallium/docs/source/screen.rst   |  3 ++
 src/mesa/drivers/dri/i965/intel_extensions.c |  1 +
 src/mesa/main/enable.c   |  4 +--
 src/mesa/main/extensions_table.h |  1 +
 src/mesa/main/get.c  |  5 +++
 src/mesa/main/get_hash_params.py |  1 +
 src/mesa/main/mtypes.h   |  1 +
 src/mesa/state_tracker/st_extensions.c   |  5 ++-
 src/mesa/state_tracker/st_manager.c  | 37 
 9 files changed, 41 insertions(+), 17 deletions(-)

-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 90157] GLSL ES does not allow non-constant initializers for globals

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=90157

--- Comment #1 from vadym  ---
Looks like this is a duplicate of Bug 92304.

Piglit tests which testing this are fixed now:

spec/glsl-es-1.00/compiler/global-initializer/from-attribute.vert
spec/glsl-es-1.00/compiler/global-initializer/from-uniform.vert
spec/glsl-es-1.00/compiler/global-initializer/from-uniform.frag
spec/glsl-es-1.00/compiler/global-initializer/from-global.vert
spec/glsl-es-1.00/compiler/global-initializer/from-global.frag
spec/glsl-es-1.00/compiler/global-initializer/from-varying.frag
spec/glsl-es-3.00/compiler/global-initializer/from-uniform.vert
spec/glsl-es-3.00/compiler/global-initializer/from-uniform.frag
spec/glsl-es-3.00/compiler/global-initializer/from-in.vert
spec/glsl-es-3.00/compiler/global-initializer/from-in.frag
spec/glsl-es-3.00/compiler/global-initializer/from-global.vert
spec/glsl-es-3.00/compiler/global-initializer/from-global.frag

-- 
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

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Mathias Fröhlich]

Hi,

On Thursday, 1 November 2018 11:04:27 CET Pekka Paalanen wrote:
> On Wed, 31 Oct 2018 16:41:47 -0400
> Marek Olšák  wrote:
> 
> > On Wed, Oct 31, 2018 at 11:26 AM Michel Dänzer  wrote:
> > 
> > > On 2018-10-31 12:39 a.m., Gustaw Smolarczyk wrote:  
> > > > śr., 31 paź 2018 o 00:23 Marek Olšák  napisał(a):  
> 
> ...
> 
> > > >> As far as we know, it hurts *only* Blender.  
> > >
> > > Why are you still saying that in the light of
> > > https://bugs.freedesktop.org/108330 ?
> > >  
> > 
> > Another candidate for a drirc setting.
> 
> Isn't GTK 4 going to use the GPU (OpenGL or Vulkan) for the UI
> rendering?
> 
> If GTK 4 uses OpenGL, would you not need to blacklist all GTK 4 apps,
> because there would be a high chance that GTK initializes OpenGL before
> the app creates any worker threads? And these would be all kinds of GTK
> apps that divide work over multiple cores, not limited to what one
> would call GL apps or games.
> 
> I don't know GTK, so I hope someone corrects or verifies this.

You have to expect Qt to use OpenGL for gui rendering. Not the only
implementation, but the one that Qt is heading for in most cases.

IMO think the side effects of binding the thread making the context
current at a cpu is too bad.
As an application developer I would not expect that to happen.

You can easily bind all *internal* threads that are never visible to any
calling code to whatever you want but not a thread that is under the
control of the application.

Only slightly related, but related:
Linux does some kind of numa aware scheduling, that is it tries
to keep tasks on that numa node where most of the physical memory
referenced by the task is directly attached to. Well at least kind of
something like that. So, one question, does amdgpu try to allocate
cpu memory on the cpu that has the pcie lanes of the gpu directly
attached to? As a side effect of that, you would
probably observe numa scheduling pulling the task back to the node
where most of the memory is residing. That is, by designed coincidence,
the same cpu.
Is something like that exploitable for the problem to be solved?

There are sched_domains in the kernel that can tell something about
the topology of the cpus in the system. My be there is a way to assign
a 'prefered sched_domain' to a task internally? ... I have not looked into the
kernel side apis for some time. May be somebody from the scheduler guys
can easily provide something like that?

best

Mathias


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3] autotools: library-dependency when no sse and 32-bit

[Sergii Romantsov]

Building of 32bit Mesa may fail if __SSE__ is not specified.
Added missed dependency from libm.

v2: avoided dependecy on any flag, just link

v3: meson doesn't fail, but have added dependency on libm

CC: Dylan Baker 
CC: Lionel G Landwerlin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
Signed-off-by: Sergii Romantsov 
---
 src/util/Makefile.am | 3 ++-
 src/util/meson.build | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/util/Makefile.am b/src/util/Makefile.am
index d79f2b3..85c7553 100644
--- a/src/util/Makefile.am
+++ b/src/util/Makefile.am
@@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
$(PTHREAD_LIBS) \
$(CLOCK_LIB) \
$(ZLIB_LIBS) \
-   $(LIBATOMIC_LIBS)
+   $(LIBATOMIC_LIBS) \
+   -lm
 
 libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
 libxmlconfig_la_CFLAGS = \
diff --git a/src/util/meson.build b/src/util/meson.build
index 49d84c1..5b82b21 100644
--- a/src/util/meson.build
+++ b/src/util/meson.build
@@ -113,7 +113,7 @@ libmesa_util = static_library(
   'mesa_util',
   [files_mesa_util, format_srgb],
   include_directories : inc_common,
-  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
+  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic, dep_m],
   c_args : [c_msvc_compat_args, c_vis_args],
   build_by_default : false
 )
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 00/13] Engine parameter for instructions

[Toni Lönnberg]

On Wed, Oct 31, 2018 at 01:18:11PM -0500, Jason Ekstrand wrote:
> On Wed, Oct 31, 2018 at 11:10 AM Toni Lönnberg 
> wrote:
> 
> > When we debug media or 3d+media workloads, we'd like to be able to see
> > what is
> > in the aub dumps for those workloads. At the moment the decoder can't
> > distinguish instructions which share the same opcode between the render
> > and
> > video pipe, and thus aubinator outputs garbage on media instructions.
> >
> > I was reluctant to make these changes into Mesa in the first place since
> > the
> > work is related to media, not 3d, but as aubinator is now located here,
> > here we
> > are.
> >
> 
> That's fine.  It's fine if these changres live in mesa.
> 
> 
> > As far as I can see, these are the options:
> >
> > 1. Put these in Mesa as aubinator now resides here instead of IGT.
> >a) Put all instruction definitions in the current genxml files, be it
> > with a
> >   tag or an attribute, both methods have their advantages and
> > disadvantages.
> >b) Separate genxml files into common, render and video (and blitter?)
> >
> > 2. Fork aubinator tools and related genxml infra to a completely separate
> >project.
> >
> > If I have missed an option, feel free to suggest.
> >
> 
> I wasn't suggesting we fork the tools and the XML.  I was just wondering
> whether we wanted to do separate sections or an attribute.  I think it
> should land in mesa either way.

I'm not really a fan of any of the methods to be honest as each of them have 
disadvantages.

Using the attribute makes it easier to add instructions which should be handled 
by a set of engines and not others but requires each instruction to have one, 
except the common ones that are always shared which can be made to default to 
all engines like in my version.

The tag makes it easier to group things nicely but adds a new level to the xml 
and requires duplicate definitions of the instruction if more than one engine 
uses that instruction but some engine doesn't.

Splitting the genxml files into different ones for each engine also organizes 
the instructions nicely but has the same problem as the tag and requires 
loading 
and parsing of multiple xml files.

To make things more icky, there are the instructions, like MI_FLUSH_DW, which 
are shared between engines but might use some of the bits for different things.

In the end, I just went with how Lionel saw it because it was as good of an 
option as any, and pretty straight forward to implement, so.. mehhh. I don't 
know if you'd prefer one way or the other.

> 
> --Jason
> 
> 
> > On Wed, Oct 31, 2018 at 09:20:39AM -0500, Jason Ekstrand wrote:
> > > Toni,
> > >
> > > I'm a bit curious where you're going with this.  I started on a similar
> > > project a couple of years ago:
> > >
> > > https://gitlab.freedesktop.org/jekstrand/mesa/commits/wip/genxml-engines
> > >
> > > Mine took a different (not necessarily better) approach of surrounding
> > the
> > > instructions in an  tag.  I'm not sure if that's any better or
> > > worse than an attribute.
> > >
> > > At the time, I was planning to port over the blitter code to genxml and
> > get
> > > aubinator decoding blit streams.  I canned the project because there are
> > > few enough differences in hardware generations for the blitter to be
> > worth
> > > the re-compilation and I had better things to do.  I've always thought it
> > > would be good to support other engines for no other reason than to make
> > > aubinator for blits.  It would also likely be useful to have if we wanted
> > > to start doing media in mesa for some reason.  What's your motivation?  I
> > > ask because I can't really have an opinion on the approach unless I know
> > > where it's headed.
> > >
> > > --Jason
> > >
> > > On Wed, Oct 31, 2018 at 8:12 AM Toni Lönnberg 
> > > wrote:
> > >
> > > > These patches add an engine parameter to the instructions defined in
> > the
> > > > genxml
> > > > files so that they can be distinguished when sending them to different
> > > > engines.
> > > > By default, an instruction is defined to be used by all engines and is
> > > > defined
> > > > for a specific engine by adding the parameter "engine" to the
> > definition.
> > > > Currently the supported engines are "render", "video" and "blitter".
> > > >
> > > > v2:
> > > >
> > > > * gen_engine enum removed and replaced with use of
> > > > drm_i915_gem_engine_class
> > > >
> > > > * The current engine being used is now saved in the decoder context
> > and is
> > > > not
> > > >   being passed through gen_print_batch().
> > > >
> > > > * Split the genxml changes into multiple patches
> > > >
> > > > Toni Lönnberg (13):
> > > >   intel/decoder: tools: gen_engine to drm_i915_gem_engine_class
> > > >   intel/decoder: Engine parameter for instructions
> > > >   intel/decoder: tools: Use engine for decoding batch instructions
> > > >   intel/genxml: Add engine definition to render engine instructions
> > > > (gen4)
> > > >   intel/genxml: Add engine 

Re: [Mesa-dev] [PATCH v2] autotools: library-dependency when no sse and 32-bit

[Sergii Romantsov]

Hi,
meson doesn't fail, but, probably, better to add for sure.
Will do soon.

On Thu, Nov 1, 2018 at 12:25 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:

> Hi Sergii,
>
> Do we need the same fix in meson?
>
> Thanks,
>
> -
> Lionel
>
> On 01/11/2018 07:25, Sergii Romantsov wrote:
>
> Thanks, Dylan.
> Could, please, somebody push it?
>
> On Tue, Oct 30, 2018 at 5:30 PM Dylan Baker  wrote:
>
>> Reviewed-by: Dylan Baker 
>>
>> Quoting Sergii Romantsov (2018-10-30 02:45:14)
>> > Building of 32bit Mesa may fail if __SSE__ is not specified.
>> > Added missed dependency from libm.
>> >
>> > CC: Dylan Baker 
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
>> > Signed-off-by: Sergii Romantsov 
>> > ---
>> >  src/util/Makefile.am | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/src/util/Makefile.am b/src/util/Makefile.am
>> > index d79f2b3..85c7553 100644
>> > --- a/src/util/Makefile.am
>> > +++ b/src/util/Makefile.am
>> > @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
>> > $(PTHREAD_LIBS) \
>> > $(CLOCK_LIB) \
>> > $(ZLIB_LIBS) \
>> > -   $(LIBATOMIC_LIBS)
>> > +   $(LIBATOMIC_LIBS) \
>> > +   -lm
>> >
>> >  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
>> >  libxmlconfig_la_CFLAGS = \
>> > --
>> > 2.7.4
>> >
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
>
> --
> Sergii Romantsov
> GlobalLogic Inc.
> www.globallogic.com
>
> ___
> mesa-dev mailing 
> listmesa-dev@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
>

-- 
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 108620] Vega 8 glitches in VKcube

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108620

--- Comment #4 from Vladislav Kamenev  ---
Vega 8 from Ryzen 2500u cpu. Mesa 18.2.3 in Manjaro

-- 
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 108620] Vega 8 glitches in VKcube

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108620

--- Comment #3 from Vladislav Kamenev  ---
Created attachment 142325
  --> https://bugs.freedesktop.org/attachment.cgi?id=142325=edit
vulkaninfo

-- 
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 108620] Vega 8 glitches in VKcube

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108620

--- Comment #2 from Vladislav Kamenev  ---
Created attachment 142324
  --> https://bugs.freedesktop.org/attachment.cgi?id=142324=edit
glxinfo

-- 
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 108620] Vega 8 glitches in VKcube

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108620

Bug ID: 108620
   Summary: Vega 8 glitches in VKcube
   Product: Mesa
   Version: 18.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: mazahakafore...@ya.ru
QA Contact: mesa-dev@lists.freedesktop.org

Created attachment 142322
  --> https://bugs.freedesktop.org/attachment.cgi?id=142322=edit
trace from vktrace

Seems like vega skips a lot of frames. Video and traces in a sec

-- 
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 108620] Vega 8 glitches in VKcube

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108620

--- Comment #1 from Vladislav Kamenev  ---
Created attachment 142323
  --> https://bugs.freedesktop.org/attachment.cgi?id=142323=edit
Video of the bug

-- 
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] intel/tools: include stdarg.h in error2aub

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin 

On 01/11/2018 04:07, Jonathan Gray wrote:

Include stdarg.h in error2aub.c otherwise it fails to build on
OpenBSD due to not finding definitions for va_list va_start va_end.

Signed-off-by: Jonathan Gray 
Cc: mesa-sta...@lists.freedesktop.org
---
  src/intel/tools/error2aub.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/src/intel/tools/error2aub.c b/src/intel/tools/error2aub.c
index 8a23d5ef1e7..b6e056cbcde 100644
--- a/src/intel/tools/error2aub.c
+++ b/src/intel/tools/error2aub.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "aub_write.h"



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] autotools: library-dependency when no sse and 32-bit

[Lionel Landwerlin]

Hi Sergii,

Do we need the same fix in meson?

Thanks,

-
Lionel

On 01/11/2018 07:25, Sergii Romantsov wrote:

Thanks, Dylan.
Could, please, somebody push it?

On Tue, Oct 30, 2018 at 5:30 PM Dylan Baker > wrote:


Reviewed-by: Dylan Baker mailto:dy...@pnwbakers.com>>

Quoting Sergii Romantsov (2018-10-30 02:45:14)
> Building of 32bit Mesa may fail if __SSE__ is not specified.
> Added missed dependency from libm.
>
> CC: Dylan Baker mailto:dy...@pnwbakers.com>>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108560
> Signed-off-by: Sergii Romantsov
mailto:sergii.romant...@globallogic.com>>
> ---
>  src/util/Makefile.am | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/util/Makefile.am b/src/util/Makefile.am
> index d79f2b3..85c7553 100644
> --- a/src/util/Makefile.am
> +++ b/src/util/Makefile.am
> @@ -60,7 +60,8 @@ libmesautil_la_LIBADD = \
>         $(PTHREAD_LIBS) \
>         $(CLOCK_LIB) \
>         $(ZLIB_LIBS) \
> -       $(LIBATOMIC_LIBS)
> +       $(LIBATOMIC_LIBS) \
> +       -lm
>
>  libxmlconfig_la_SOURCES = $(XMLCONFIG_FILES)
>  libxmlconfig_la_CFLAGS = \
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org 
https://lists.freedesktop.org/mailman/listinfo/mesa-dev



--
Sergii Romantsov
GlobalLogic Inc.
www.globallogic.com 

___
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] [PATCH mesa] move variable-sized struct at the end of parent struct

[Eric Engestrom]

  warning: field 'base' with variable sized type 'struct 
drm_i915_query_topology_info'
  not at the end of a struct or class is a GNU extension 
[-Wgnu-variable-sized-type-not-at-end]

Signed-off-by: Eric Engestrom 
---
 src/intel/dev/gen_device_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
index 5dbd06075722f8cc644e..242fe163447a4265acfb 100644
--- a/src/intel/dev/gen_device_info.c
+++ b/src/intel/dev/gen_device_info.c
@@ -991,8 +991,8 @@ gen_device_info_update_from_masks(struct gen_device_info 
*devinfo,
   uint32_t n_eus)
 {
struct {
-  struct drm_i915_query_topology_info base;
   uint8_t data[100];
+  struct drm_i915_query_topology_info base;
} topology;
 
assert((slice_mask & 0xff) == slice_mask);
-- 
Cheers,
  Eric

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Eric Engestrom]

On Thursday, 2018-11-01 08:40:08 +0100, mathias.froehl...@gmx.net wrote:
> From: Mathias Fröhlich 
> 
> Hi Emil,
> 
> There seems to be a failure with the latest patches you pushed.
> The patch fixes a failure with the sort order in egl symbols.
> 
> please review!
> 
> FYI, I observed that the latest series that you sent for review
> differs a lot in the individual patches. Kind of looks like a
> problem that may have slipped in during a rebase -i session.
> The total diff past the complete series only differs by this
> current change that introduces the failure.
> 
> best
> 
> Mathias
> 
> 
> 
> Fixes a make check failure.
> 
> Signed-off-by: Mathias Fröhlich 

The joys of `sort` vs `LANG=C sort` :/

Fixes: 7552fcb7b9b98392e6a8 "egl: add base EGL_EXT_device_base implementation"
Reviewed-by: Eric Engestrom 

> ---
>  src/egl/main/eglentrypoint.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/main/eglentrypoint.h b/src/egl/main/eglentrypoint.h
> index 95a8814bce..69a6c1bf4c 100644
> --- a/src/egl/main/eglentrypoint.h
> +++ b/src/egl/main/eglentrypoint.h
> @@ -57,8 +57,8 @@ EGL_ENTRYPOINT(eglQueryAPI)
>  EGL_ENTRYPOINT(eglQueryContext)
>  EGL_ENTRYPOINT(eglQueryDebugKHR)
>  EGL_ENTRYPOINT(eglQueryDeviceAttribEXT)
> -EGL_ENTRYPOINT(eglQueryDevicesEXT)
>  EGL_ENTRYPOINT(eglQueryDeviceStringEXT)
> +EGL_ENTRYPOINT(eglQueryDevicesEXT)
>  EGL_ENTRYPOINT(eglQueryDisplayAttribEXT)
>  EGL_ENTRYPOINT(eglQueryDmaBufFormatsEXT)
>  EGL_ENTRYPOINT(eglQueryDmaBufModifiersEXT)
> -- 
> 2.17.2
> 
> ___
> 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 02/12] meson: bump the minimum LLVM version to 5.0.1

[Eric Engestrom]

On Wednesday, 2018-10-31 16:06:19 -0700, Dylan Baker wrote:
> Quoting Emil Velikov (2018-10-31 06:29:54)
> > From: Emil Velikov 
> > 
> > Currently the minimal version is 3.3 with 3.9 for r600+opencl.
> > 
> > We kept it as low, since transitioning to newer ones is pain on Windows.
> > With issues ranging from build problems, memory leaks and various other
> > small nitpicks throughout.
> > 
> > Currently we use 5.0.1 for our Appveyor testing, so we can bump the
> > numbers officially and start ripping out the hacks we had in place.
> > 
> > All recent distribution (versions) have it, with the odd old one left in
> > the dark. On those platforms, realistically nobody is using mesa-git.
> > 
> > Archlinux: 6.0.1

FYI, arch ships 7.0.0:
https://www.archlinux.org/packages/extra/x86_64/llvm/

> > CentOS: ?
> > Debian testing: 6.0
> > Fedora 27: 5.0.1
> > Gentoo: 5.0.2
> > OpenSuse 15: 5.0.1
> > Ubuntu 18.04LTS: 6.0
> > 
> > Cc: Dylan Baker 
> > Cc: Eric Engestrom 
> > Signed-off-by: Emil Velikov 
> > ---
> >  meson.build | 13 ++---
> >  1 file changed, 2 insertions(+), 11 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 18667988bac..492334e1c0a 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -1179,10 +1179,8 @@ if with_amd_vk or with_gallium_radeonsi
> >_llvm_version = '>= 6.0.0'
> >  elif with_gallium_swr
> >_llvm_version = '>= 6.0.0'
> > -elif with_gallium_opencl or with_gallium_r600
> > -  _llvm_version = '>= 3.9.0'
> >  else
> > -  _llvm_version = '>= 3.3.0'
> > +  _llvm_version = '>= 5.0.1'
> >  endif
> >  
> >  _shared_llvm = get_option('shared-llvm')
> > @@ -1207,16 +1205,9 @@ endif
> >  if with_llvm
> >_llvm_version = dep_llvm.version().split('.')
> >  
> > -  # 3 digits versions in LLVM only started from 3.4.1 on
> > -  if dep_llvm.version().version_compare('>= 3.4.1')
> > -_llvm_patch = _llvm_version[2]
> > -  else
> > -_llvm_patch = '0'
> > -  endif
> > -
> >pre_args += [
> >  '-DHAVE_LLVM=0x0@0@0@1@'.format(_llvm_version[0], _llvm_version[1]),
> > -'-DMESA_LLVM_VERSION_PATCH=@0@'.format(_llvm_patch),
> > +'-DMESA_LLVM_VERSION_PATCH=@0@'.format(_llvm_version[2]),
> >]
> >  
> ># LLVM can be built without rtti, turning off rtti changes the ABI of C++
> > -- 
> > 2.19.1
> > 
> 
> For this patch, assuming that the stakeholders (r600, clover, and llvmpipe) 
> are
> okay with the changes:
> 
> Reviewed-by: Dylan Baker 
> 

Same caveat;
Reviewed-by: Eric Engestrom 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 10/12] llvmpipe: remove pre LLVM 5.0 codepath

[Jose Fonseca]

On 31/10/2018 13:30, Emil Velikov wrote:

From: Emil Velikov 

LLVM versions earlier than 5.0.1 are no longer supported.

Cc: Roland Scheidegger 
Cc: Jose Fonseca 
Signed-off-by: Emil Velikov 
---
  src/gallium/drivers/llvmpipe/lp_jit.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/src/gallium/drivers/llvmpipe/lp_jit.c 
b/src/gallium/drivers/llvmpipe/lp_jit.c
index e2309f47157..ae5b0fe8151 100644
--- a/src/gallium/drivers/llvmpipe/lp_jit.c
+++ b/src/gallium/drivers/llvmpipe/lp_jit.c
@@ -223,13 +223,9 @@ lp_jit_create_types(struct lp_fragment_shader_variant *lp)
 }
  
 if (gallivm_debug & GALLIVM_DEBUG_IR) {

-#if HAVE_LLVM >= 0x304
char *str = LLVMPrintModuleToString(gallivm->module);
fprintf(stderr, "%s", str);
LLVMDisposeMessage(str);
-#else
-  LLVMDumpModule(gallivm->module);
-#endif
 }
  }
  



This and patch 3 looks good too.

Reviewed-by: Jose Fonseca 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 09/12] gallivm: remove workarounds for pre LLVM 5.0

[Jose Fonseca]

On 31/10/2018 13:30, Emil Velikov wrote:

From: Emil Velikov 

With LLVM 5.0.1 the minimum required version, we can drop all the dead
code.

Cc: Roland Scheidegger 
Cc: Jose Fonseca 
Signed-off-by: Emil Velikov 
---
Gents this is a quick and dirty grep job. A couple of places may need
the comments to be tweaked/dropped - I've annotated those with XXX.


[..]

Nice cleanup. Thanks.

Could you please re-indent the # pragma for DEBUG macro.  Otherwise 
looks perfect.  I'm also OK leaving the XXX comments for now and revisit 
later.


Reviewed-by: Jose Fonseca 

Jose

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/util: don't let children of fork & exec inherit our thread affinity

[Pekka Paalanen]

On Wed, 31 Oct 2018 16:41:47 -0400
Marek Olšák  wrote:

> On Wed, Oct 31, 2018 at 11:26 AM Michel Dänzer  wrote:
> 
> > On 2018-10-31 12:39 a.m., Gustaw Smolarczyk wrote:  
> > > śr., 31 paź 2018 o 00:23 Marek Olšák  napisał(a):  

...

> > >> As far as we know, it hurts *only* Blender.  
> >
> > Why are you still saying that in the light of
> > https://bugs.freedesktop.org/108330 ?
> >  
> 
> Another candidate for a drirc setting.

Isn't GTK 4 going to use the GPU (OpenGL or Vulkan) for the UI
rendering?

If GTK 4 uses OpenGL, would you not need to blacklist all GTK 4 apps,
because there would be a high chance that GTK initializes OpenGL before
the app creates any worker threads? And these would be all kinds of GTK
apps that divide work over multiple cores, not limited to what one
would call GL apps or games.

I don't know GTK, so I hope someone corrects or verifies this.


Thanks,
pq


pgpw5N8ytpdOT.pgp
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] glsl: fall back to inexact function-match

[Erik Faye-Lund]

On Thu, 2018-11-01 at 07:49 +0200, Tapani Pälli wrote:
> 
> On 10/31/18 7:03 PM, Ilia Mirkin wrote:
> > On Wed, Oct 31, 2018 at 12:37 PM Erik Faye-Lund
> >  wrote:
> > > 
> > > On Wed, 2018-10-31 at 12:01 -0400, Ilia Mirkin wrote:
> > > > I had to do a double (or triple) take on this logic as well.
> > > > Part of
> > > > the subtlety is that the fallback only applies for ES when
> > > > there's a
> > > > match but no exact match. Probably good to mention this.
> > > 
> > > Yeah, that makes sense. I thought I mentioneded this in the
> > > commit
> > > message, but perhaps you want that to be more explicit than the
> > > "In
> > > GLES, "-introduction?
> > > 
> > > How about I simply add something like "This fallback should only
> > > affect
> > > GLES." at the end of the commit message?
> > 
> > Yes, you did mention it in the commit message. But that's unlikely
> > to
> > be visible when reading this code. I was thinking something in this
> > function's comments would be nice.
> > 
> 
> Sounds good, I wouldn't be worried about saying it aloud, at least I 
> would love some 'spoon-feeding comments' now and then with compiler
> and 
> linker parts :)
> 
> 

OK, fair enough. How about this?

---8<---
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -667,7 +667,12 @@ match_function_by_name(const char *name,
/* Local shader has no exact candidates; check the built-ins. */
_mesa_glsl_initialize_builtin_functions();
sig = _mesa_glsl_find_builtin_function(state, name,
actual_parameters);
-   return sig;
+
+   /* if _mesa_glsl_find_builtin_function failed, fall back to th
e result
+* of choose_best_inexact_overload() instead. This should only
affect
+* GLES.
+*/
+   return sig ? sig : local_sig;
 }
 
 static ir_function_signature *
---8<---

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] virgl/vtest-winsys: Use virgl version of bind flags

[Gert Wollny]

From: Gert Wollny 

The bind flags defined by mesa/gallium might not always be in sync
with the ones copied to virglrenderer/gallium. Therefore, use the
flags defined in virgl like it is done for all the other calls to
create resources.

Signed-off-by: Gert Wollny 
---
 src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c 
b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
index a589f694bb..f44d4d74ff 100644
--- a/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
+++ b/src/gallium/winsys/virgl/vtest/virgl_vtest_winsys.c
@@ -559,7 +559,7 @@ virgl_cs_create_fence(struct virgl_winsys *vws)
res = virgl_vtest_winsys_resource_cache_create(vws,
 PIPE_BUFFER,
 PIPE_FORMAT_R8_UNORM,
-PIPE_BIND_CUSTOM,
+VIRGL_BIND_CUSTOM,
 8, 1, 1, 0, 0, 0, 8);
 
return (struct pipe_fence_handle *)res;
-- 
2.18.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl: Fix eglentrypoint.h sort order.

[Tapani Pälli]

Reviewed-by: Tapani Pälli 

This fixes:
dEQP-EGL.functional.get_proc_address.extension.egl_ext_device_base

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108617


On 11/1/18 9:40 AM, mathias.froehl...@gmx.net wrote:

From: Mathias Fröhlich 

Hi Emil,

There seems to be a failure with the latest patches you pushed.
The patch fixes a failure with the sort order in egl symbols.

please review!

FYI, I observed that the latest series that you sent for review
differs a lot in the individual patches. Kind of looks like a
problem that may have slipped in during a rebase -i session.
The total diff past the complete series only differs by this
current change that introduces the failure.

best

Mathias



Fixes a make check failure.

Signed-off-by: Mathias Fröhlich 
---
  src/egl/main/eglentrypoint.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/main/eglentrypoint.h b/src/egl/main/eglentrypoint.h
index 95a8814bce..69a6c1bf4c 100644
--- a/src/egl/main/eglentrypoint.h
+++ b/src/egl/main/eglentrypoint.h
@@ -57,8 +57,8 @@ EGL_ENTRYPOINT(eglQueryAPI)
  EGL_ENTRYPOINT(eglQueryContext)
  EGL_ENTRYPOINT(eglQueryDebugKHR)
  EGL_ENTRYPOINT(eglQueryDeviceAttribEXT)
-EGL_ENTRYPOINT(eglQueryDevicesEXT)
  EGL_ENTRYPOINT(eglQueryDeviceStringEXT)
+EGL_ENTRYPOINT(eglQueryDevicesEXT)
  EGL_ENTRYPOINT(eglQueryDisplayAttribEXT)
  EGL_ENTRYPOINT(eglQueryDmaBufFormatsEXT)
  EGL_ENTRYPOINT(eglQueryDmaBufModifiersEXT)


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600/sb: Fix constant logical operand in assert.

[Gert Wollny]

Good catch,  
Reviewed-By: Gert Wollny  

Am Mittwoch, den 31.10.2018, 15:40 -0700 schrieb Vinson Lee:
> Fixes: da977ad90747 ("r600/sb: start adding GDS support")
> Signed-off-by: Vinson Lee 
> ---
>  src/gallium/drivers/r600/sb/sb_bc_builder.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/r600/sb/sb_bc_builder.cpp
> b/src/gallium/drivers/r600/sb/sb_bc_builder.cpp
> index 5681fdc44253..b7d87eac9f42 100644
> --- a/src/gallium/drivers/r600/sb/sb_bc_builder.cpp
> +++ b/src/gallium/drivers/r600/sb/sb_bc_builder.cpp
> @@ -567,7 +567,7 @@ int bc_builder::build_fetch_gds(fetch_node *n) {
>   const fetch_op_info *fop = bc.op_ptr;
>   unsigned gds_op = (ctx.fetch_opcode(bc.op) >> 8) & 0x3f;
>   unsigned mem_op = 4;
> - assert(fop->flags && FF_GDS);
> + assert(fop->flags & FF_GDS);
>  
>   if (bc.op == FETCH_OP_TF_WRITE) {
>   mem_op = 5;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: fix begin/end transform feedback with 0 counter buffers.

[Samuel Pitoiset]

On 11/1/18 12:59 AM, Dave Airlie wrote:

From: Dave Airlie 

If the user gives 0 counterBuffers then the driver should still
enable transform feedback on all targets. This changes the
driver to always enable xfb, and use counter buffers where
one is defined for the target in question.

Fixes: b4eb029062 (radv: implement VK_EXT_transform_feedback)
---
  src/amd/vulkan/radv_cmd_buffer.c | 30 --
  1 file changed, 16 insertions(+), 14 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 77680268897..ac72a25d272 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4743,13 +4743,14 @@ void radv_CmdBeginTransformFeedbackEXT(
struct radv_streamout_binding *sb = cmd_buffer->streamout_bindings;
struct radv_streamout_state *so = _buffer->state.streamout;
struct radeon_cmdbuf *cs = cmd_buffer->cs;
-
+   uint32_t i;


Please, add a new line here (and in End()).

With that, patch is:

Reviewed-by: Samuel Pitoiset 


radv_flush_vgt_streamout(cmd_buffer);
  
  	assert(firstCounterBuffer + counterBufferCount <= MAX_SO_BUFFERS);

-   for (uint32_t i = firstCounterBuffer; i < counterBufferCount; i++) {
-   if (!(so->enabled_mask & (1 << i)))
-   continue;
+   for_each_bit(i, so->enabled_mask) {
+   int32_t counter_buffer_idx = i - firstCounterBuffer;
+   if (counter_buffer_idx >= 0 && counter_buffer_idx > 
counterBufferCount)
+   counter_buffer_idx = -1;
  
  		/* SI binds streamout buffers as shader resources.

 * VGT only counts primitives and tells the shader through
@@ -4759,12 +4760,12 @@ void radv_CmdBeginTransformFeedbackEXT(
radeon_emit(cs, (sb[i].offset + sb[i].size) >> 2);/* 
BUFFER_SIZE (in DW) */
radeon_emit(cs, so->stride_in_dw[i]);/* 
VTX_STRIDE (in DW) */
  
-		if (pCounterBuffers && pCounterBuffers[i]) {

+   if (counter_buffer_idx >= 0 && pCounterBuffers && 
pCounterBuffers[counter_buffer_idx]) {
/* The array of counter buffers is optional. */
-   RADV_FROM_HANDLE(radv_buffer, buffer, 
pCounterBuffers[i]);
+   RADV_FROM_HANDLE(radv_buffer, buffer, 
pCounterBuffers[counter_buffer_idx]);
uint64_t va = radv_buffer_get_va(buffer->bo);
  
-			va += buffer->offset + pCounterBufferOffsets[i];

+   va += buffer->offset + 
pCounterBufferOffsets[counter_buffer_idx];
  
  			/* Append */

radeon_emit(cs, PKT3(PKT3_STRMOUT_BUFFER_UPDATE, 4, 0));
@@ -4803,20 +4804,21 @@ void radv_CmdEndTransformFeedbackEXT(
RADV_FROM_HANDLE(radv_cmd_buffer, cmd_buffer, commandBuffer);
struct radv_streamout_state *so = _buffer->state.streamout;
struct radeon_cmdbuf *cs = cmd_buffer->cs;
-
+   uint32_t i;
radv_flush_vgt_streamout(cmd_buffer);
  
  	assert(firstCounterBuffer + counterBufferCount <= MAX_SO_BUFFERS);

-   for (uint32_t i = firstCounterBuffer; i < counterBufferCount; i++) {
-   if (!(so->enabled_mask & (1 << i)))
-   continue;
+   for_each_bit(i, so->enabled_mask) {
+   int32_t counter_buffer_idx = i - firstCounterBuffer;
+   if (counter_buffer_idx >= 0 && counter_buffer_idx > 
counterBufferCount)
+   counter_buffer_idx = -1;
  
-		if (pCounterBuffers && pCounterBuffers[i]) {

+   if (counter_buffer_idx >= 0 && pCounterBuffers && 
pCounterBuffers[counter_buffer_idx]) {
/* The array of counters buffer is optional. */
-   RADV_FROM_HANDLE(radv_buffer, buffer, 
pCounterBuffers[i]);
+   RADV_FROM_HANDLE(radv_buffer, buffer, 
pCounterBuffers[counter_buffer_idx]);
uint64_t va = radv_buffer_get_va(buffer->bo);
  
-			va += buffer->offset + pCounterBufferOffsets[i];

+   va += buffer->offset + 
pCounterBufferOffsets[counter_buffer_idx];
  
  			radeon_emit(cs, PKT3(PKT3_STRMOUT_BUFFER_UPDATE, 4, 0));

radeon_emit(cs, STRMOUT_SELECT_BUFFER(i) |


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radv: apply xfb buffer offset at buffer binding time not later. (v2)

[Samuel Pitoiset]

Seems fine.

Reviewed-by: Samuel Pitoiset 

On 11/1/18 4:00 AM, Dave Airlie wrote:

From: Dave Airlie 

In order to handle pause/resume properly, the offset should
be added to the buffer binding not to the begin/end paths.

v2: don't add offset to size
Fixes ext_transform_feedback-alignment* under zink

Fixes: b4eb029062 (radv: implement VK_EXT_transform_feedback)
---
  src/amd/vulkan/radv_cmd_buffer.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index c43e12f6d62..296b626b19c 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1950,6 +1950,8 @@ radv_flush_streamout_descriptors(struct radv_cmd_buffer 
*cmd_buffer)
  
  			va = radv_buffer_get_va(buffer->bo) + buffer->offset;
  
+			va += sb[i].offset;

+
/* Set the descriptor.
 *
 * On VI, the format must be non-INVALID, otherwise
@@ -4754,7 +4756,7 @@ void radv_CmdBeginTransformFeedbackEXT(
 * SGPRs what to do.
 */
radeon_set_context_reg_seq(cs, 
R_028AD0_VGT_STRMOUT_BUFFER_SIZE_0 + 16*i, 2);
-   radeon_emit(cs, (sb[i].offset + sb[i].size) >> 2);/* 
BUFFER_SIZE (in DW) */
+   radeon_emit(cs, sb[i].size >> 2); /* BUFFER_SIZE (in DW) */
radeon_emit(cs, so->stride_in_dw[i]);/* 
VTX_STRIDE (in DW) */
  
  		if (pCounterBuffers && pCounterBuffers[i]) {

@@ -4783,7 +4785,7 @@ void radv_CmdBeginTransformFeedbackEXT(

STRMOUT_OFFSET_SOURCE(STRMOUT_OFFSET_FROM_PACKET)); /* control */
radeon_emit(cs, 0); /* unused */
radeon_emit(cs, 0); /* unused */
-   radeon_emit(cs, sb[i].offset >> 2); /* buffer offset in 
DW */
+   radeon_emit(cs, 0); /* unused */
radeon_emit(cs, 0); /* unused */
}
}


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev