Re: [Mesa-dev] A few NIR compile time optimisations

[Connor Abbott]

On Wed, Feb 20, 2019 at 4:29 AM Marek Olšák  wrote:

> On Tue, Feb 19, 2019 at 7:57 PM Rob Clark  wrote:
>
>> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák  wrote:
>> >
>> > st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
>> >
>> > nir_validate_shader 49%
>> >
>> > nir_validate_shader is overused. It doesn't make sense even in debug
>> builds.
>>
>> tbh, I like nir_validate enabled when I do piglit/deqp runs.. and I
>> already do separate release vs debug builds (which meson kinda
>> encourages by disallowing in-tree builds in the first place, but is
>> totally possible with autotools builds).. I kinda think benchmarking
>> debug build in the first place is a flawed process.
>>
>> So I wouldn't profile/benchmark nir vs tgsi (or really anything) with
>> debug builds.. I could get behind a separate compiler-debug option
>> that changed the default NIR_VALIDATE setting and maybe some other nir
>> debug features to get some features of debug builds without enabling
>> the heavier nir debug features.  But other than making debug options a
>> bit more fine grained, I wouldn't change things in response to a
>> flawed benchmarking process..
>>
>
> That's a harsh reaction to a relatively good benchmarking setup. I use
> debugoptimized with -DDEBUG. My performance is probably more affected by
> -fno-omit-frame-pointer than -DDEBUG.
>

Why would you enable DEBUG in a profiling build? AFAIK it's supposed to
enable validation more expensive than simple asserts, which you probably
don't want in a benchmarking setup, although from grepping the source it's
not used much. It might be a good idea to move running NIR validation
behind DEBUG instead of !NDEBUG. In the meantime, unless you really want to
benchmark things with assertions enabled in which case NIR_VALIDATE=0 works
(but why would you?), you can set -Db_ndebug=false in Meson. I just saw
today that they're enabled by default in debugoptimized builds (whoops,
better go fix that and re-profile...).


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

[Mesa-dev] [PATCH] nir: remove non-ssa support from nir_copy_prop()

[Timothy Arceri]

Even in a very basic shader this reduces the time spent in
nir_copy_prop() by ~17%.

No shader-db changes for radeonsi NIR or i965.
---
 src/compiler/nir/nir_opt_copy_propagate.c | 41 +++
 1 file changed, 5 insertions(+), 36 deletions(-)

diff --git a/src/compiler/nir/nir_opt_copy_propagate.c 
b/src/compiler/nir/nir_opt_copy_propagate.c
index 534f127c0d3..10b81c0a684 100644
--- a/src/compiler/nir/nir_opt_copy_propagate.c
+++ b/src/compiler/nir/nir_opt_copy_propagate.c
@@ -34,6 +34,8 @@
 
 static bool is_move(nir_alu_instr *instr)
 {
+   assert(instr->src[0].src.is_ssa);
+
if (instr->op != nir_op_fmov &&
instr->op != nir_op_imov)
   return false;
@@ -46,9 +48,6 @@ static bool is_move(nir_alu_instr *instr)
if (instr->src[0].abs || instr->src[0].negate)
   return false;
 
-   if (!instr->src[0].src.is_ssa)
-  return false;
-
return true;
 
 }
@@ -56,8 +55,7 @@ static bool is_move(nir_alu_instr *instr)
 static bool is_vec(nir_alu_instr *instr)
 {
for (unsigned i = 0; i < nir_op_infos[instr->op].num_inputs; i++) {
-  if (!instr->src[i].src.is_ssa)
- return false;
+  assert(instr->src[i].src.is_ssa);
 
   /* we handle modifiers in a separate pass */
   if (instr->src[i].abs || instr->src[i].negate)
@@ -102,11 +100,7 @@ static bool
 copy_prop_src(nir_src *src, nir_instr *parent_instr, nir_if *parent_if,
   unsigned num_components)
 {
-   if (!src->is_ssa) {
-  if (src->reg.indirect)
- return copy_prop_src(src->reg.indirect, parent_instr, parent_if, 1);
-  return false;
-   }
+   assert(src->is_ssa);
 
nir_instr *src_instr = src->ssa->parent_instr;
nir_ssa_def *copy_def;
@@ -137,12 +131,7 @@ static bool
 copy_prop_alu_src(nir_alu_instr *parent_alu_instr, unsigned index)
 {
nir_alu_src *src = &parent_alu_instr->src[index];
-   if (!src->src.is_ssa) {
-  if (src->src.reg.indirect)
- return copy_prop_src(src->src.reg.indirect, &parent_alu_instr->instr,
-  NULL, 1);
-  return false;
-   }
+   assert(src->src.is_ssa);
 
nir_instr *src_instr =  src->src.ssa->parent_instr;
if (src_instr->type != nir_instr_type_alu)
@@ -187,15 +176,6 @@ copy_prop_alu_src(nir_alu_instr *parent_alu_instr, 
unsigned index)
return true;
 }
 
-static bool
-copy_prop_dest(nir_dest *dest, nir_instr *instr)
-{
-   if (!dest->is_ssa && dest->reg.indirect)
-  return copy_prop_src(dest->reg.indirect, instr, NULL, 1);
-
-   return false;
-}
-
 static bool
 copy_prop_instr(nir_instr *instr)
 {
@@ -208,9 +188,6 @@ copy_prop_instr(nir_instr *instr)
  while (copy_prop_alu_src(alu_instr, i))
 progress = true;
 
-  while (copy_prop_dest(&alu_instr->dest.dest, instr))
- progress = true;
-
   return progress;
}
 
@@ -241,9 +218,6 @@ copy_prop_instr(nir_instr *instr)
 progress = true;
   }
 
-  while (copy_prop_dest(&tex->dest, instr))
- progress = true;
-
   return progress;
}
 
@@ -257,11 +231,6 @@ copy_prop_instr(nir_instr *instr)
 progress = true;
   }
 
-  if (nir_intrinsic_infos[intrin->intrinsic].has_dest) {
- while (copy_prop_dest(&intrin->dest, instr))
-progress = true;
-  }
-
   return progress;
}
 
-- 
2.20.1

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

[Mesa-dev] [Bug 104376] [ILK] Browser crashes while switching between fullscreen and windowed video on youtube.

[bugzilla-daemon]

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

Anjala  changed:

   What|Removed |Added

 CC||anjala.thulasi...@sjsu.edu

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] panfrost: Implement pantrace (command stream dump)

[Alyssa Rosenzweig]

Historically, Panfrost debugging entailed the use of the LD_PRELOADable
`panwrap` tool. This setup is a tad fragile; Panfrost can be traced
directly without the intermediate layer. pantrace implements the
quivalent functionality of panwrap into Panfrost proper, allowing dumps
to work regardless of the kernel layer in use.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/meson.build  |   1 +
 src/gallium/drivers/panfrost/pan_screen.c |   7 ++
 src/gallium/drivers/panfrost/pan_screen.h |   1 +
 src/gallium/drivers/panfrost/pan_trace.c  | 146 ++
 src/gallium/drivers/panfrost/pan_trace.h  |  33 +
 5 files changed, 188 insertions(+)
 create mode 100644 src/gallium/drivers/panfrost/pan_trace.c
 create mode 100644 src/gallium/drivers/panfrost/pan_trace.h

diff --git a/src/gallium/drivers/panfrost/meson.build 
b/src/gallium/drivers/panfrost/meson.build
index 81f18c33d18..81021d08468 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -31,6 +31,7 @@ files_panfrost = files(
   'midgard/disassemble.c',
 
   'pan_context.c',
+  'pan_trace.c',
   'pan_drm.c',
   'pan_allocate.c',
   'pan_assemble.c',
diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index 0995d2f3142..f61758d1bb9 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -551,6 +551,13 @@ panfrost_create_screen(int fd, struct renderonly *ro, bool 
is_drm)
 #endif
 }
 
+/* Enable pantrace iff asked for in the environment */
+const char *pantrace_base = getenv("PANTRACE_BASE");
+
+if (pantrace_base) {
+pantrace_initialize(pantrace_base);
+}
+
 #ifdef DUMP_PERFORMANCE_COUNTERS
 screen->driver->allocate_slab(screen, &screen->perf_counters, 64, 
true, 0, 0, 0);
 screen->driver->enable_counters(screen);
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 646923c9864..4ff690de658 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -35,6 +35,7 @@
 
 #include 
 #include "pan_allocate.h"
+#include "pan_trace.h"
 
 struct panfrost_context;
 struct panfrost_resource;
diff --git a/src/gallium/drivers/panfrost/pan_trace.c 
b/src/gallium/drivers/panfrost/pan_trace.c
new file mode 100644
index 000..205a822dee9
--- /dev/null
+++ b/src/gallium/drivers/panfrost/pan_trace.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2019 Alyssa Rosenzweig
+ *
+ * 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 (including the next
+ * paragraph) 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "pan_trace.h"
+#include "util/list.h"
+
+/* The pandecode utility is capable of parsing a command stream trace and
+ * disassembling any referenced shaders. Traces themselves are glorified memory
+ * dumps, a directory consisting of .bin's for each memory segment, and a
+ * simple plain-text description of the interesting kernel activity.
+ * Historically, these dumps have been produced via panwrap, an LD_PRELOAD shim
+ * sitting between the driver and the kernel. However, for modern Panfrost, we
+ * can just produce the dumps ourselves, which is rather less fragile. This
+ * file (pantrace) implements this functionality. */
+
+static FILE *pan_control_log;
+static const char *pan_control_base;
+
+/* Represent the abstraction for a single mmap chunk */
+
+static unsigned pantrace_memory_count = 0;
+
+struct pantrace_memory {
+struct list_head node;
+
+mali_ptr gpu;
+void *cpu;
+size_t sz;
+char *full_filename;
+};
+
+static struct pantrace_memory mmaps;
+
+void
+pantrace_initialize(const char *base)
+{
+/* Open the control.log */
+char fn[128];
+snprintf(fn, 128, "%s/control.log", base);
+pan_control_log = fopen(fn, "w+");

Re: [Mesa-dev] A few NIR compile time optimisations

[Marek Olšák]

On Tue, Feb 19, 2019 at 7:57 PM Rob Clark  wrote:

> On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák  wrote:
> >
> > st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
> >
> > nir_validate_shader 49%
> >
> > nir_validate_shader is overused. It doesn't make sense even in debug
> builds.
>
> tbh, I like nir_validate enabled when I do piglit/deqp runs.. and I
> already do separate release vs debug builds (which meson kinda
> encourages by disallowing in-tree builds in the first place, but is
> totally possible with autotools builds).. I kinda think benchmarking
> debug build in the first place is a flawed process.
>
> So I wouldn't profile/benchmark nir vs tgsi (or really anything) with
> debug builds.. I could get behind a separate compiler-debug option
> that changed the default NIR_VALIDATE setting and maybe some other nir
> debug features to get some features of debug builds without enabling
> the heavier nir debug features.  But other than making debug options a
> bit more fine grained, I wouldn't change things in response to a
> flawed benchmarking process..
>

That's a harsh reaction to a relatively good benchmarking setup. I use
debugoptimized with -DDEBUG. My performance is probably more affected by
-fno-omit-frame-pointer than -DDEBUG.

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

[Mesa-dev] [PATCH] nir: clone instruction set rather than removing individual entries

[Timothy Arceri]

This reduces the time spent in nir_opt_cse() by almost a half.
---
 src/compiler/nir/nir_opt_cse.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/compiler/nir/nir_opt_cse.c b/src/compiler/nir/nir_opt_cse.c
index bf42a6a33dc..3c3617d852a 100644
--- a/src/compiler/nir/nir_opt_cse.c
+++ b/src/compiler/nir/nir_opt_cse.c
@@ -39,9 +39,10 @@
  */
 
 static bool
-cse_block(nir_block *block, struct set *instr_set)
+cse_block(nir_block *block, struct set *dominance_set)
 {
bool progress = false;
+   struct set *instr_set = _mesa_set_clone(dominance_set, NULL);
 
nir_foreach_instr_safe(instr, block) {
   if (nir_instr_set_add_or_rewrite(instr_set, instr)) {
@@ -55,8 +56,7 @@ cse_block(nir_block *block, struct set *instr_set)
   progress |= cse_block(child, instr_set);
}
 
-   nir_foreach_instr(instr, block)
- nir_instr_set_remove(instr_set, instr);
+   _mesa_set_destroy(instr_set, NULL);
 
return progress;
 }
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH 4/4] radeonsi: use SDMA for uploading data through const_uploader

[Marek Olšák]

I'll remove the env var.

Additionally, I'm amending this:

diff --git a/src/gallium/drivers/radeonsi/si_buffer.c
b/src/gallium/drivers/radeonsi/si_buffer.c
index 3f8db7cf4f0..4936eb5a5b1 100644
--- a/src/gallium/drivers/radeonsi/si_buffer.c
+++ b/src/gallium/drivers/radeonsi/si_buffer.c
@@ -461,10 +461,20 @@ static void *si_buffer_transfer_map(struct
pipe_context *ctx,
si_rings_is_buffer_referenced(sctx, buf->buf,
RADEON_USAGE_READWRITE) ||
!sctx->ws->buffer_wait(buf->buf, 0,
RADEON_USAGE_READWRITE)) {
/* Do a wait-free write-only transfer using a
temporary buffer. */
-   unsigned offset;
+   struct u_upload_mgr *uploader;
struct si_resource *staging = NULL;
+   unsigned offset;
+
+   /* If we are not called from the driver thread, we
have
+* to use the uploader from u_threaded_context,
which is
+* local to the calling thread.
+*/
+   if (usage & TC_TRANSFER_MAP_THREADED_UNSYNC)
+   uploader = sctx->tc->base.stream_uploader;
+   else
+   uploader = sctx->b.stream_uploader;

-   u_upload_alloc(ctx->stream_uploader, 0,
+   u_upload_alloc(uploader, 0,
box->width + (box->x %
SI_MAP_BUFFER_ALIGNMENT),

sctx->screen->info.tcc_cache_line_size,
   &offset, (struct
pipe_resource**)&staging,

Marek

On Mon, Feb 11, 2019 at 4:38 AM Nicolai Hähnle  wrote:

> On 07.02.19 02:22, Marek Olšák wrote:
> > + bool use_sdma_upload = sscreen->info.has_dedicated_vram &&
> sctx->dma_cs && debug_get_bool_option("SDMA", true);
>
> Could you please namespace the environment variable, e.g. RADEONSI_SDMA?
>
> Apart from that, series is
>
> Reviewed-by: Nicolai Hähnle 
>
>
> > + sctx->b.const_uploader = u_upload_create(&sctx->b, 256 * 1024,
> > +  0, PIPE_USAGE_DEFAULT,
> > +  SI_RESOURCE_FLAG_32BIT |
> > +  (use_sdma_upload ?
> > +
>  SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA :
> > +
>  (sscreen->cpdma_prefetch_writes_memory ?
> > +0 :
> SI_RESOURCE_FLAG_READ_ONLY)));
> > + if (!sctx->b.const_uploader)
> > + goto fail;
> > +
> > + if (use_sdma_upload)
> > + u_upload_enable_flush_explicit(sctx->b.const_uploader);
> > +
> >   si_init_buffer_functions(sctx);
> >   si_init_clear_functions(sctx);
> >   si_init_blit_functions(sctx);
> >   si_init_compute_functions(sctx);
> >   si_init_compute_blit_functions(sctx);
> >   si_init_debug_functions(sctx);
> >   si_init_msaa_functions(sctx);
> >   si_init_streamout_functions(sctx);
> >
> >   if (sscreen->info.has_hw_decode) {
> > diff --git a/src/gallium/drivers/radeonsi/si_pipe.h
> b/src/gallium/drivers/radeonsi/si_pipe.h
> > index b01d5744752..b208bdeb848 100644
> > --- a/src/gallium/drivers/radeonsi/si_pipe.h
> > +++ b/src/gallium/drivers/radeonsi/si_pipe.h
> > @@ -103,20 +103,22 @@
> >   #define SI_MAX_VARIABLE_THREADS_PER_BLOCK 1024
> >
> >   #define SI_RESOURCE_FLAG_TRANSFER   (PIPE_RESOURCE_FLAG_DRV_PRIV << 0)
> >   #define SI_RESOURCE_FLAG_FLUSHED_DEPTH
> (PIPE_RESOURCE_FLAG_DRV_PRIV << 1)
> >   #define SI_RESOURCE_FLAG_FORCE_MSAA_TILING
> (PIPE_RESOURCE_FLAG_DRV_PRIV << 2)
> >   #define SI_RESOURCE_FLAG_DISABLE_DCC
> (PIPE_RESOURCE_FLAG_DRV_PRIV << 3)
> >   #define SI_RESOURCE_FLAG_UNMAPPABLE (PIPE_RESOURCE_FLAG_DRV_PRIV << 4)
> >   #define SI_RESOURCE_FLAG_READ_ONLY  (PIPE_RESOURCE_FLAG_DRV_PRIV << 5)
> >   #define SI_RESOURCE_FLAG_32BIT
> (PIPE_RESOURCE_FLAG_DRV_PRIV << 6)
> >   #define SI_RESOURCE_FLAG_CLEAR
> (PIPE_RESOURCE_FLAG_DRV_PRIV << 7)
> > +/* For const_uploader, upload data via GTT and copy to VRAM on context
> flush via SDMA. */
> > +#define SI_RESOURCE_FLAG_UPLOAD_FLUSH_EXPLICIT_VIA_SDMA
> (PIPE_RESOURCE_FLAG_DRV_PRIV << 8)
> >
> >   enum si_clear_code
> >   {
> >   DCC_CLEAR_COLOR_   = 0x,
> >   DCC_CLEAR_COLOR_0001   = 0x40404040,
> >   DCC_CLEAR_COLOR_1110   = 0x80808080,
> >   DCC_CLEAR_COLOR_   = 0xC0C0C0C0,
> >   DCC_CLEAR_COLOR_REG= 0x20202020,
> >   DCC_UNCOMPRESSED   = 0x,
> >   };
> > @@ -769,20 +771,28 @@ struct si_saved_cs {
> >   struct si_context   *ctx;
> >   struct radeon_saved_cs  gfx;
> >   struct si_resource  *trace_buf;
> >   unsignedtrace_id;
> >
> >   unsignedgfx_last_dw;
> >   boolflushed;
> >   int64_t time_flush;
> >   };
> >
> > +struct si_sdma_upload {
> > + struct si_

Re: [Mesa-dev] [PATCH 0/4] RadeonSI: Upload constants to VRAM via SDMA

[Marek Olšák]

Yeah, u_threaded_context is broken.

Marek

On Thu, Feb 14, 2019 at 8:06 PM Dieter Nützel  wrote:

> Am 12.02.2019 05:10, schrieb Dieter Nützel:
> > Am 12.02.2019 03:22, schrieb Dieter Nützel:
> >> Am 12.02.2019 00:40, schrieb Dieter Nützel:
> >>> Sorry that I step in so late, but the whole family recover slowly
> >>> from
> >>> a bad flu...
> >>>
> >>> Tried your 'latest" three series altogether with my Polaris 20
> >>> (NIR!).
> >>> UH and UV hang after some seconds reliable. VM faults. Have to dig
> >>> deeper in (remote) to get some logs.
> >>
> >> UH
> >>
> >> [47001.185090] amdgpu :01:00.0: GPU fault detected: 147 0x0b384801
> >> for process heaven_x64 pid 18565 thread heaven_x64:cs0 pid 18586
> >> [47001.185094] amdgpu :01:00.0:
> >> VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0373EF67
> >> [47001.185096] amdgpu :01:00.0:
> >> VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x06048001
> >> [47001.185098] amdgpu :01:00.0: VM fault (0x01, vmid 3, pasid
> >> 32786) at page 57929575, read from 'TC4' (0x54433400) (72)
> >> [47011.401741] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
> >> timeout, signaled seq=11380701, emitted seq=11380703
> >> [47011.401784] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process
> >> information: process  pid 0 thread  pid 0
> >> [47011.401787] amdgpu :01:00.0: GPU reset begin!
> >> [47021.631605] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR*
> >> [CRTC:49:crtc-0] hw_done or flip_done timed out
> >
> > These GPU faults are SOLVED after reverting the SDMA (1-4) series.
>
> So I gave this a second change with LLVM 9.0 git.
> + some other patches
>
> e83af67eed7 (HEAD -> master) ac: use new LLVM 8 intrinsic when loading
> 16-bit values
> 7f32d569ffc ac: add ac_build_llvm8_tbuffer_load() helper
> 037bda54a7d nir: remove simple dead if detection from nir_opt_dead_cf()
> 51fe88ff1ab radeonsi/nir: set shader_buffers_declared properly
> e66a73aa1a6 radeonsi/nir: set colors_read properly
> 83955dfc81a radeonsi/nir: set input_usage_mask properly
> 4c355a562db radeonsi: use SDMA for uploading data through const_uploader
> 6855f871e47 gallium/u_upload_mgr: allow use of FLUSH_EXPLICIT with
> persistent mappings
> 2116355fc01 gallium/u_threaded: always unmap const_uploader
> 6e70cce39f3 st/mesa: always unmap the uploader in st_atom_array.c
> 22a88ca1d92 radeonsi: re-initialize query buffers if they are reused
> 6775665e5ee (origin/master, origin/HEAD) spirv: Eliminate dead
> input/output variables after translation.
>
> UH
> run some sences but (same? - Yes.) GPU fault. - Shit, sadly overwritten
> my dmesg.log. :-(
>
> UV
> run some sences but (same? - Yes.) GPU fault.
>
> Unigine Valley Benchmark 1.0 (1.0)Unigine~# world_load valley/valley
> Loading "valley/valley.cpp" 126ms
> Loading "valley/valley.mat" 72 materials 1160ms
> Loading "valley/sound/sound.prop" 142 properties 1ms
> Loading "valley/valley.world" 2253ms
> valley_x64: ../src/gallium/auxiliary/util/u_inlines.h:81:
> pipe_reference_described: Assertion `count != 1' failed.
>
> [ 1079.415836] amdgpu :01:00.0: GPU fault detected: 147 0x0ca04801
> for process valley_x64 pid 18050 thread valley_x64:cs0 pid 18071
> [ 1079.415841] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR
>   0x094A9594
> [ 1079.415842] amdgpu :01:00.0:
> VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x08048001
> [ 1079.415845] amdgpu :01:00.0: VM fault (0x01, vmid 4, pasid 32769)
> at page 155882900, read from 'TC4' (0x54433400) (72)
> [ 1089.543336] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
> timeout, signaled seq=91489, emitted seq=91491
> [ 1089.543379] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process
> information: process valley_x64 pid 18050 thread valley_x64:cs0 pid
> 18071
> [ 1089.543382] amdgpu :01:00.0: GPU reset begin!
> [ 1099.773342] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR*
> [CRTC:49:crtc-0] hw_done or flip_done timed out
>
> Hope that helps some.
>
> Dieter
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] spirv: handle function pointer returns.

[Dave Airlie]

From: Dave Airlie 

This was hardcoded to 32, use the physical bit size we setup.

Signed-off-by: Dave Airlie 
---
 src/compiler/spirv/vtn_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index c32d54e9006..2000c84832e 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -276,7 +276,7 @@ vtn_cfg_handle_prepass_instruction(struct vtn_builder *b, 
SpvOp opcode,
   if (func_type->return_type->base_type != vtn_base_type_void) {
  /* The return value is a regular pointer */
  func->params[idx++] = (nir_parameter) {
-.num_components = 1, .bit_size = 32,
+.num_components = 1, .bit_size = b->shader->info.cs.ptr_size,
  };
   }
 
-- 
2.20.1

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

[Mesa-dev] [PATCH] radv: Sync ETC2 whitelisted devices.

[Bas Nieuwenhuizen]

Fixes: 4bb6c49375e "radv: Allow ETC2 on RAVEN and VEGA10 instead of all GFX9."
---
 src/amd/vulkan/radv_device.c  |  3 +--
 src/amd/vulkan/radv_formats.c | 12 +---
 src/amd/vulkan/radv_private.h |  1 +
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 190de86b2cd..53f2c05fc42 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -739,8 +739,7 @@ void radv_GetPhysicalDeviceFeatures(
.alphaToOne   = true,
.multiViewport= true,
.samplerAnisotropy= true,
-   .textureCompressionETC2   = 
pdevice->rad_info.chip_class >= GFX9 ||
-   
pdevice->rad_info.family == CHIP_STONEY,
+   .textureCompressionETC2   = 
radv_device_supports_etc(pdevice),
.textureCompressionASTC_LDR   = false,
.textureCompressionBC = true,
.occlusionQueryPrecise= true,
diff --git a/src/amd/vulkan/radv_formats.c b/src/amd/vulkan/radv_formats.c
index 499d94befeb..0a3ff9ebbd9 100644
--- a/src/amd/vulkan/radv_formats.c
+++ b/src/amd/vulkan/radv_formats.c
@@ -595,6 +595,14 @@ static bool 
radv_is_filter_minmax_format_supported(VkFormat format)
}
 }
 
+bool
+radv_device_supports_etc(struct radv_physical_device *physical_device)
+{
+   return physical_device->rad_info.family == CHIP_VEGA10 ||
+  physical_device->rad_info.family == CHIP_RAVEN ||
+  physical_device->rad_info.family == CHIP_STONEY;
+}
+
 static void
 radv_physical_device_get_format_properties(struct radv_physical_device 
*physical_device,
   VkFormat format,
@@ -612,9 +620,7 @@ radv_physical_device_get_format_properties(struct 
radv_physical_device *physical
}
 
if (desc->layout == VK_FORMAT_LAYOUT_ETC &&
-   physical_device->rad_info.family != CHIP_VEGA10 &&
-   physical_device->rad_info.family != CHIP_RAVEN &&
-   physical_device->rad_info.family != CHIP_STONEY) {
+   !radv_device_supports_etc(physical_device)) {
out_properties->linearTilingFeatures = linear;
out_properties->optimalTilingFeatures = tiled;
out_properties->bufferFeatures = buffer;
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index ddabcedc958..27b5a9e77cd 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1465,6 +1465,7 @@ bool radv_format_pack_clear_color(VkFormat format,
 bool radv_is_colorbuffer_format_supported(VkFormat format, bool *blendable);
 bool radv_dcc_formats_compatible(VkFormat format1,
  VkFormat format2);
+bool radv_device_supports_etc(struct radv_physical_device *physical_device);
 
 struct radv_fmask_info {
uint64_t offset;
-- 
2.20.1

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

Re: [Mesa-dev] A few NIR compile time optimisations

[Rob Clark]

On Tue, Feb 19, 2019 at 6:49 PM Marek Olšák  wrote:
>
> st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.
>
> nir_validate_shader 49%
>
> nir_validate_shader is overused. It doesn't make sense even in debug builds.

tbh, I like nir_validate enabled when I do piglit/deqp runs.. and I
already do separate release vs debug builds (which meson kinda
encourages by disallowing in-tree builds in the first place, but is
totally possible with autotools builds).. I kinda think benchmarking
debug build in the first place is a flawed process.

So I wouldn't profile/benchmark nir vs tgsi (or really anything) with
debug builds.. I could get behind a separate compiler-debug option
that changed the default NIR_VALIDATE setting and maybe some other nir
debug features to get some features of debug builds without enabling
the heavier nir debug features.  But other than making debug options a
bit more fine grained, I wouldn't change things in response to a
flawed benchmarking process..

BR,
-R


>
> Marek
>
> On Wed, Feb 13, 2019 at 4:26 AM Connor Abbott  wrote:
>>
>> Reviewed-by: Connor Abbott 
>>
>> I'm a bit surprised it's that slow... do you have any idea what's going on? 
>> I've made flamegraphs in the past on i965 to see where most of the time is 
>> spent.
>>
>> On Wed, Feb 13, 2019 at 9:00 AM Timothy Arceri  wrote:
>>>
>>> Currently the radeonsi NIR backend takes around twice the time
>>> of the tgsi backend to compile shader-db. These are some first
>>> steps at reducing the overhead of NIR.
>>>
>>> This series reduces the compile time of a Deus Ex program I was
>>> profiling by around 5%.
>>>
>>>
>>> ___
>>> 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 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] Error: unsupported relocations

[james harvey]

Commit 9baacf3f is: "radeonsi: Refuse to accept code with unhandled
relocations".

This has broken ImageMagick for many people using AMD graphics cards.
See https://github.com/ImageMagick/ImageMagick/issues/1366

ImageMagick responded: "It looks like this error message is created by
the mesa driver. I have no idea what causes this message and if there
is anything what we could do to prevent this from happening."

And, hasn't responded back for requests for what additional
information I could tell mesa.

I see the mesa commit is to prevent GPU hangs, so I'm all for the commit.

I'm just asking what would need to be done by who to get ImageMagick
working again, using opencl-mesa.  Using opencl-amd has been a
workaround for some people.  Not sure if this is something mesa just
hasn't implemented that opencl-amd has, or if it's something
ImageMagick needs to do differently.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: fixed clamping in set_scissor_bits when the y is flipped

[Nanley Chery]

On Mon, Dec 10, 2018 at 12:42:40PM +0200, Eleni Maria Stea wrote:
> Calculating the scissor rectangle fields with the y flipped (0 on top)
> can generate negative values that will cause assertion failure later on
> as the scissor fields are all unsigned. We must clamp the bbox values
> again to make sure they don't exceed the fb_height. Also fixed a
> calculation error.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108999

Good find. Could you send the test to the piglit list?

> ---
>  src/mesa/drivers/dri/i965/genX_state_upload.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/genX_state_upload.c 
> b/src/mesa/drivers/dri/i965/genX_state_upload.c
> index 8e3fcbf12e..5d8fc8214e 100644
> --- a/src/mesa/drivers/dri/i965/genX_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/genX_state_upload.c
> @@ -2424,8 +2424,21 @@ set_scissor_bits(const struct gl_context *ctx, int i,
>/* memory: Y=0=top */
>sc->ScissorRectangleXMin = bbox[0];
>sc->ScissorRectangleXMax = bbox[1] - 1;
> +
> +  /* Clamping to fb_height is necessary because otherwise the
> +   * subtractions below would produce a negative result, which would
> +   * then be assigned to the unsigned YMin/YMax scissor fields,
> +   * resulting in an assertion failure in GENX(SCISSOR_RECT_pack)
> +   */
> +
> +  if (bbox[3] > fb_height)
> + bbox[3] = fb_height;
> +
> +  if (bbox[2] > fb_height)
> + bbox[2] = fb_height;
> +

We should be able to fix this bug in a simpler manner by changing the
MAX2 calls at the top of this function to CLAMP calls.

>sc->ScissorRectangleYMin = fb_height - bbox[3];
> -  sc->ScissorRectangleYMax = fb_height - bbox[2] - 1;
> +  sc->ScissorRectangleYMax = fb_height - (bbox[2] - 1);

I don't think we want to start adding 1 instead of subtracting 1. The
subtraction is there to satisfy the requirement for the HW packet.

-Nanley

> }
>  }
>  
> -- 
> 2.20.0.rc2
> 
> ___
> 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] A few NIR compile time optimisations

[Timothy Arceri]

On 20/2/19 10:59 am, Timothy Arceri wrote:

On 20/2/19 10:49 am, Marek Olšák wrote:

st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.

nir_validate_shader 49%

nir_validate_shader is overused. It doesn't make sense even in debug 
builds.


It's used to validate the IR between optimisation/lowering passes. For 
debug builds you can use NIR_VALIDATE=0 to avoid it.


Note since I sent this we have tracked down and removed some excessive 
processing in nir_opt_dead_cf() and Connor has also sent a MR to 
significantly reduce time spent in nir_opt_algebraic [1].


The overhead from NIR has reduce to about 30% of time spent compiling 
shader-db with everything that's already landed and Connors series.


To clarify that is ~30% extra time to compile shader-db on the NIR 
backed vs the TGSI backend.


So in other words the NIR overhead has almost halved since I sent this 
series a week ago :)




I intend to do some more profiling today. I added compile times to 
shader-db so that I can pinpoint problem shaders.


[1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/269



Marek

On Wed, Feb 13, 2019 at 4:26 AM Connor Abbott > wrote:


    Reviewed-by: Connor Abbott mailto:cwabbo...@gmail.com>>

    I'm a bit surprised it's that slow... do you have any idea what's
    going on? I've made flamegraphs in the past on i965 to see where
    most of the time is spent.

    On Wed, Feb 13, 2019 at 9:00 AM Timothy Arceri
    mailto:tarc...@itsqueeze.com>> wrote:

    Currently the radeonsi NIR backend takes around twice the time
    of the tgsi backend to compile shader-db. These are some first
    steps at reducing the overhead of NIR.

    This series reduces the compile time of a Deus Ex program I was
    profiling by around 5%.


    ___
    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 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] A few NIR compile time optimisations

[Timothy Arceri]

On 20/2/19 10:49 am, Marek Olšák wrote:

st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.

nir_validate_shader 49%

nir_validate_shader is overused. It doesn't make sense even in debug builds.


It's used to validate the IR between optimisation/lowering passes. For 
debug builds you can use NIR_VALIDATE=0 to avoid it.


Note since I sent this we have tracked down and removed some excessive 
processing in nir_opt_dead_cf() and Connor has also sent a MR to 
significantly reduce time spent in nir_opt_algebraic [1].


The overhead from NIR has reduce to about 30% of time spent compiling 
shader-db with everything that's already landed and Connors series.


I intend to do some more profiling today. I added compile times to 
shader-db so that I can pinpoint problem shaders.


[1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/269



Marek

On Wed, Feb 13, 2019 at 4:26 AM Connor Abbott > wrote:


Reviewed-by: Connor Abbott mailto:cwabbo...@gmail.com>>

I'm a bit surprised it's that slow... do you have any idea what's
going on? I've made flamegraphs in the past on i965 to see where
most of the time is spent.

On Wed, Feb 13, 2019 at 9:00 AM Timothy Arceri
mailto:tarc...@itsqueeze.com>> wrote:

Currently the radeonsi NIR backend takes around twice the time
of the tgsi backend to compile shader-db. These are some first
steps at reducing the overhead of NIR.

This series reduces the compile time of a Deus Ex program I was
profiling by around 5%.


___
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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109615] 19.0.0_rc4 fails u_format_test on ppc64

[bugzilla-daemon]

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

--- Comment #4 from erhar...@mailbox.org ---
(In reply to Dylan Baker from comment #3)
> Do these tests pass on 18.3?
Mesa 18.3.x passes all tests on ppc64 BE. The failing tests in question are not
part of 18.3 as far as I've seen.

-- 
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] A few NIR compile time optimisations

[Marek Olšák]

st_link_shader takes 55% of CPU time with NIR, and 9% with TGSI.

nir_validate_shader 49%

nir_validate_shader is overused. It doesn't make sense even in debug builds.

Marek

On Wed, Feb 13, 2019 at 4:26 AM Connor Abbott  wrote:

> Reviewed-by: Connor Abbott 
>
> I'm a bit surprised it's that slow... do you have any idea what's going
> on? I've made flamegraphs in the past on i965 to see where most of the time
> is spent.
>
> On Wed, Feb 13, 2019 at 9:00 AM Timothy Arceri 
> wrote:
>
>> Currently the radeonsi NIR backend takes around twice the time
>> of the tgsi backend to compile shader-db. These are some first
>> steps at reducing the overhead of NIR.
>>
>> This series reduces the compile time of a Deus Ex program I was
>> profiling by around 5%.
>>
>>
>> ___
>> 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi/nir: set shader_buffers_declared properly

[Marek Olšák]

Reviewed-by: Marek Olšák 

Marek

On Mon, Feb 11, 2019 at 10:46 PM Timothy Arceri 
wrote:

> ---
>  src/gallium/drivers/radeonsi/si_shader_nir.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 55a950a675c..c547f5f1c30 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -687,10 +687,15 @@ void si_nir_scan_shader(const struct nir_shader *nir,
>
> struct set *ubo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
>_mesa_key_pointer_equal);
> +   struct set *ssbo_set = _mesa_set_create(NULL, _mesa_hash_pointer,
> +   _mesa_key_pointer_equal);
>
> /* Intialise const_file_max[0] */
> info->const_file_max[0] = -1;
>
> +   /* The first 8 are reserved for atomic counters using ssbo */
> +   unsigned ssbo_idx = 8;
> +
> unsigned ubo_idx = 1;
> nir_foreach_variable(variable, &nir->uniforms) {
> const struct glsl_type *type = variable->type;
> @@ -705,12 +710,16 @@ void si_nir_scan_shader(const struct nir_shader *nir,
>  */
> if (variable->interface_type != NULL) {
> if (variable->data.mode == nir_var_uniform ||
> -   variable->data.mode == nir_var_mem_ubo) {
> +   variable->data.mode == nir_var_mem_ubo ||
> +   variable->data.mode == nir_var_mem_ssbo) {
> +
> +   struct set *buf_set = variable->data.mode
> == nir_var_mem_ssbo ?
> +   ssbo_set : ubo_set;
>
> unsigned block_count;
> if (base_type != GLSL_TYPE_INTERFACE) {
> struct set_entry *entry =
> -   _mesa_set_search(ubo_set,
> variable->interface_type);
> +   _mesa_set_search(buf_set,
> variable->interface_type);
>
> /* Check if we have already
> processed
>  * a member from this ubo.
> @@ -723,16 +732,18 @@ void si_nir_scan_shader(const struct nir_shader *nir,
> block_count = aoa_size;
> }
>
> -   info->const_buffers_declared |=
> u_bit_consecutive(ubo_idx, block_count);
> -   ubo_idx += block_count;
> +   if (variable->data.mode == nir_var_uniform
> ||
> +   variable->data.mode ==
> nir_var_mem_ubo) {
> +   info->const_buffers_declared |=
> u_bit_consecutive(ubo_idx, block_count);
> +   ubo_idx += block_count;
> +   } else {
> +   assert(variable->data.mode ==
> nir_var_mem_ssbo);
>
> -   _mesa_set_add(ubo_set,
> variable->interface_type);
> -   }
> +   info->shader_buffers_declared |=
> u_bit_consecutive(ssbo_idx, block_count);
> +   ssbo_idx += block_count;
> +   }
>
> -   if (variable->data.mode == nir_var_mem_ssbo) {
> -   /* TODO: make this more accurate */
> -   info->shader_buffers_declared =
> -   u_bit_consecutive(0,
> SI_NUM_SHADER_BUFFERS);
> +   _mesa_set_add(buf_set,
> variable->interface_type);
> }
>
> continue;
> @@ -776,6 +787,7 @@ void si_nir_scan_shader(const struct nir_shader *nir,
> }
>
> _mesa_set_destroy(ubo_set, NULL);
> +   _mesa_set_destroy(ssbo_set, NULL);
>
> info->num_written_clipdistance =
> nir->info.clip_distance_array_size;
> info->num_written_culldistance =
> nir->info.cull_distance_array_size;
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 2/2] radeonsi/nir: set colors_read properly

[Marek Olšák]

For the series:

Reviewed-by: Marek Olšák 

Marek

On Mon, Feb 11, 2019 at 7:15 PM Timothy Arceri 
wrote:

> shader-db results for VEGA64:
>
> Totals from affected shaders:
> SGPRS: 1976 -> 1976 (0.00 %)
> VGPRS: 1240 -> 1144 (-7.74 %)
> Spilled SGPRs: 145 -> 145 (0.00 %)
> Spilled VGPRs: 0 -> 0 (0.00 %)
> Private memory VGPRs: 0 -> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 34632 -> 34604 (-0.08 %) bytes
> LDS: 0 -> 0 (0.00 %) blocks
> Max Waves: 261 -> 285 (9.20 %)
> Wait states: 0 -> 0 (0.00 %)
> ---
>  src/gallium/drivers/radeonsi/si_shader_nir.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 4eec57b406d..55a950a675c 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -74,9 +74,18 @@ static void gather_intrinsic_load_deref_info(const
> nir_shader *nir,
> }
> break;
> }
> -   default:
> +   default: {
> +   unsigned semantic_name, semantic_index;
> +   tgsi_get_gl_varying_semantic(var->data.location, true,
> +&semantic_name,
> &semantic_index);
> +
> +   if (semantic_name == TGSI_SEMANTIC_COLOR) {
> +   uint8_t mask =
> nir_ssa_def_components_read(&instr->dest.ssa);
> +   info->colors_read |= mask << (semantic_index * 4);
> +   }
> break;
> }
> +   }
>  }
>
>  static void scan_instruction(const struct nir_shader *nir,
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Mesa-stable] [PATCH] drirc: Add sddm-greeter to adaptive_sync blacklist.

[Marek Olšák]

Pushed, thanks!

Marek

On Mon, Feb 18, 2019 at 10:01 PM Mario Kleiner 
wrote:

> This is the sddm login screen.
>
> Fixes: a9c36dbf9c56 ("drirc: Initial blacklist for adaptive sync")
> Signed-off-by: Mario Kleiner 
> Cc: 19.0 
> ---
>  src/util/00-mesa-defaults.conf | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/util/00-mesa-defaults.conf
> b/src/util/00-mesa-defaults.conf
> index cb0e6e659e2..43fe95b8810 100644
> --- a/src/util/00-mesa-defaults.conf
> +++ b/src/util/00-mesa-defaults.conf
> @@ -346,6 +346,9 @@ TODO: document the other workarounds.
>  
>  
>  
> +
> +
> +
>  
>  
>  
> --
> 2.17.1
>
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] driconf: add Civ6Sub executable for Civilization 6

[Timothy Arceri]

Series:

Reviewed-by: Timothy Arceri 

We might want to tag this for stable too? NIR should work fine with this 
game with the current stable releases.


On 20/2/19 9:31 am, Marek Olšák wrote:

From: Marek Olšák 

I'm getting Civ6Sub instead of Civ6.
---
  src/util/00-mesa-defaults.conf | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index 81f23c97941..8abc50c9f26 100644
--- a/src/util/00-mesa-defaults.conf
+++ b/src/util/00-mesa-defaults.conf
@@ -222,20 +222,23 @@ TODO: document the other workarounds.
  
  
  
  
  

  
  
  
  
  
+
+
+
  
  

  
  
  
  

  
  
  
  

@@ -422,12 +425,15 @@ TODO: document the other workarounds.
  
  
  
  
  
  
  
  
  
  
+
+
+
  
  


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

[Mesa-dev] [ANNOUNCE] mesa 19.0.0-rc5

[Dylan Baker]

Hi List,

Hot off the press is mesa 19.0-rc5. Due to a number of still opened bugs in the
release tracker this will not be the final release, and I predict at least one
more release candidate before the final release happens.

Just an FYI, I will not be working Thursday or Friday this week, so if I don't
respond to nominations after tommorrow don't be surprised :)

Anyway, in the rc5 release we have a little bit of everything, but not too much
of any one thing:

 - nir
 - radv
 - v3d
 - intel
 - swr
 - anv
 - spirv
 - meson
 - radeonsi

Dylan

git tag: mesa-19.0.0-rc5

https://mesa.freedesktop.org/archive/mesa-19.0.0-rc5.tar.gz
MD5:  0effb3b43cf9664351a4297aeb4c4fe0  mesa-19.0.0-rc5.tar.gz
SHA1: 3a5264c102faab892c5cc2ce3c701f8916df1460  mesa-19.0.0-rc5.tar.gz
SHA256: ba7010851903eec1a9d95d6ccd02a83ca7c9c1175306775daccf8a09f111dba1  
mesa-19.0.0-rc5.tar.gz
SHA512: 
c6388333e43f372f3bc99356c06c984d96889ca32bffa0cdb5d0387a670b956e416c34d434be6432680bc4dc64c2dead8897095c4775829a6b7781a47f26
  mesa-19.0.0-rc5.tar.gz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.0-rc5.tar.gz.sig

https://mesa.freedesktop.org/archive/mesa-19.0.0-rc5.tar.xz
MD5:  d4787a5081630d2c6936f19bc118e826  mesa-19.0.0-rc5.tar.xz
SHA1: 22f567408a740ac4c0766c2afd7cd7855f27d6d1  mesa-19.0.0-rc5.tar.xz
SHA256: d81e8af724cf3dc9dff537a890853b1088e97e07d416373745e5eabfaa80f1eb  
mesa-19.0.0-rc5.tar.xz
SHA512: 
f73bafa6d63576720a0aa6254b6fc97ba4e6e1ecf8b62bc62dd83967d5624fc83caed150707f1e5bfda87aff0bc3ebcd4872f8020ba5c23d3f6b42ab4523a91f
  mesa-19.0.0-rc5.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.0.0-rc5.tar.xz.sig



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

[Mesa-dev] [Bug 109615] 19.0.0_rc4 fails u_format_test on ppc64

[bugzilla-daemon]

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

--- Comment #3 from Dylan Baker  ---
Do these tests pass on 18.3?

-- 
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] [PATCH 2/3] radeonsi: always enable NIR for Civilization 6 to fix corruption

[Marek Olšák]

From: Marek Olšák 

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104602
---
 src/util/00-mesa-defaults.conf | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index cb0e6e659e2..81f23c97941 100644
--- a/src/util/00-mesa-defaults.conf
+++ b/src/util/00-mesa-defaults.conf
@@ -419,12 +419,15 @@ TODO: document the other workarounds.
 
 
 
 
 
 
 
 
 
 
+
+
+
 
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 3/3] driconf: add Civ6Sub executable for Civilization 6

[Marek Olšák]

From: Marek Olšák 

I'm getting Civ6Sub instead of Civ6.
---
 src/util/00-mesa-defaults.conf | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/util/00-mesa-defaults.conf b/src/util/00-mesa-defaults.conf
index 81f23c97941..8abc50c9f26 100644
--- a/src/util/00-mesa-defaults.conf
+++ b/src/util/00-mesa-defaults.conf
@@ -222,20 +222,23 @@ TODO: document the other workarounds.
 
 
 
 
 
 
 
 
 
 
+
+
+
 
 
 
 
 
 
 
 
 
 
@@ -422,12 +425,15 @@ TODO: document the other workarounds.
 
 
 
 
 
 
 
 
 
 
+
+
+
 
 
-- 
2.17.1

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

[Mesa-dev] [PATCH 1/3] radeonsi: add driconf option radeonsi_enable_nir

[Marek Olšák]

From: Marek Olšák 

---
 src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 1 +
 src/gallium/drivers/radeonsi/si_pipe.c  | 3 ++-
 src/util/xmlpool/t_options.h| 5 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h 
b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
index cbf3bb01fb3..edf8edba035 100644
--- a/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
+++ b/src/gallium/drivers/radeonsi/driinfo_radeonsi.h
@@ -5,11 +5,12 @@ DRI_CONF_SECTION_END
 
 DRI_CONF_SECTION_PERFORMANCE
 DRI_CONF_RADEONSI_ENABLE_SISCHED("false")
 DRI_CONF_RADEONSI_ASSUME_NO_Z_FIGHTS("false")
 DRI_CONF_RADEONSI_COMMUTATIVE_BLEND_ADD("false")
 DRI_CONF_RADEONSI_ZERO_ALL_VRAM_ALLOCS("false")
 DRI_CONF_SECTION_END
 
 DRI_CONF_SECTION_DEBUG
DRI_CONF_RADEONSI_CLEAR_DB_CACHE_BEFORE_CLEAR("false")
+   DRI_CONF_RADEONSI_ENABLE_NIR("false")
 DRI_CONF_SECTION_END
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
b/src/gallium/drivers/radeonsi/si_pipe.c
index c2ec664d5a4..47494e4194d 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -878,21 +878,22 @@ struct pipe_screen *radeonsi_screen_create(struct 
radeon_winsys *ws,
si_init_screen_query_functions(sscreen);
 
/* Set these flags in debug_flags early, so that the shader cache takes
 * them into account.
 */
if (driQueryOptionb(config->options,
"glsl_correct_derivatives_after_discard"))
sscreen->debug_flags |= DBG(FS_CORRECT_DERIVS_AFTER_KILL);
if (driQueryOptionb(config->options, "radeonsi_enable_sisched"))
sscreen->debug_flags |= DBG(SI_SCHED);
-
+   if (driQueryOptionb(config->options, "radeonsi_enable_nir"))
+   sscreen->debug_flags |= DBG(NIR);
 
if (sscreen->debug_flags & DBG(INFO))
ac_print_gpu_info(&sscreen->info);
 
slab_create_parent(&sscreen->pool_transfers,
   sizeof(struct si_transfer), 64);
 
sscreen->force_aniso = MIN2(16, debug_get_num_option("R600_TEX_ANISO", 
-1));
if (sscreen->force_aniso >= 0) {
printf("radeonsi: Forcing anisotropy filter to %ix\n",
diff --git a/src/util/xmlpool/t_options.h b/src/util/xmlpool/t_options.h
index f48758f5706..a7cba3417cc 100644
--- a/src/util/xmlpool/t_options.h
+++ b/src/util/xmlpool/t_options.h
@@ -345,10 +345,15 @@ DRI_CONF_OPT_END
 
 #define DRI_CONF_RADEONSI_CLEAR_DB_CACHE_BEFORE_CLEAR(def) \
 DRI_CONF_OPT_BEGIN_B(radeonsi_clear_db_cache_before_clear, def) \
 DRI_CONF_DESC(en,"Clear DB cache before fast depth clear") \
 DRI_CONF_OPT_END
 
 #define DRI_CONF_RADEONSI_ZERO_ALL_VRAM_ALLOCS(def) \
 DRI_CONF_OPT_BEGIN_B(radeonsi_zerovram, def) \
 DRI_CONF_DESC(en,"Zero all vram allocations") \
 DRI_CONF_OPT_END
+
+#define DRI_CONF_RADEONSI_ENABLE_NIR(def) \
+DRI_CONF_OPT_BEGIN_B(radeonsi_enable_nir, def) \
+DRI_CONF_DESC(en,gettext("Enable NIR")) \
+DRI_CONF_OPT_END
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Kenneth Graunke]

On Tuesday, February 19, 2019 10:08:13 AM PST Ville Syrjälä wrote:
> On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> > On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> > > 
> > > 0x0f30
> > > ff049b6ce21d2814451afd4a116d001712e0116b
> > > drm/i915: bind driver to ValleyView chipsets
> > > 
> > > 0x8A70
> > > d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> > > drm/i915/icl: Add the ICL PCI IDs
> > > 
> > > The Intel Media SDK describes these as
> > > 
> > > /* VLV */
> > > { 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */
> > 
> > hmmm... no idea about this one...
> > Ville?
> > maybe we should just remove from kernel since it was never
> > missed from Mesa?
> 
> Bspec says that is the infamous X0. Assuming it's not
> lying to us it should be safe to remove.

That fits my memory too, 0f30 was never a PCI ID for a product that
actually shipped.

--Ken


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] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Rodrigo Vivi]

On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> 
> 0x0f30
> ff049b6ce21d2814451afd4a116d001712e0116b
> drm/i915: bind driver to ValleyView chipsets
> 
> 0x8A70
> d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> drm/i915/icl: Add the ICL PCI IDs
> 
> The Intel Media SDK describes these as
> 
> /* VLV */
> { 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */

hmmm... no idea about this one...
Ville?
maybe we should just remove from kernel since it was never
missed from Mesa?

> 
> /* ICL LP */
> { 0x8A70, MFX_HW_ICL_LP, MFX_GT1 }

This is pure display so no Mesa needed for this ID.

> 
> and libdrm's intel_chipset.h describes the VLV id as
> 
> #define PCI_CHIP_VALLEYVIEW_PO0x0f30 /* VLV PO board */
> 
> It isn't clear what the ICL configuration should be from public
> information.
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index b91abd7a3f9..3568007b1ef 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -86,6 +86,7 @@ CHIPSET(0x0D2B, hsw_gt3, "Intel(R) Haswell")
>  CHIPSET(0x0D0E, hsw_gt1, "Intel(R) Haswell")
>  CHIPSET(0x0D1E, hsw_gt2, "Intel(R) Haswell")
>  CHIPSET(0x0D2E, hsw_gt3, "Intel(R) Haswell")
> +CHIPSET(0x0F30, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F31, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F32, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F33, byt, "Intel(R) Bay Trail")
> @@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 
> 6x8 GT1.5)")
>  CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>  CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
>  CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> +CHIPSET(0x8A70, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>  CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/4] Common KMS renderonly support

[Emil Velikov]

On Mon, 18 Feb 2019 at 19:06, Kyle Russell  wrote:
>
> Thanks for this.  Sorry I'm just now seeing it.  I'll try this out on the 
> armada+etnaviv configuration.
>
Considering the driver name (as returned by drmGetVersion()::name) is
"armada", all you need is:
 - src/gallium/targets/dri/meson.build [with_gallium_kmsro, 'armada_dri.so'],
 - src/gallium/drivers/etnaviv/Automake.inc:TARGET_DRIVERS += armada
 - src/gallium/targets/dri/target.c DEFINE_LOADER_DRM_ENTRYPOINT(armada)
 - 
src/gallium/auxiliary/target-helpers/drm_helper_public.h:pipe_armada_create_screen(int
fd, const struct pipe_screen_config *config);

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

[Mesa-dev] GitLab CI is now opt-in - tl;dr: push to ci/*

[Eric Engestrom]

Hi all,

The GitLab CI translated from Travis is really resource-hungry (see the
discussion DanielS started [1]).

Efforts are ongoing to make it nicer to its runners, but as
a (hopefully) temporary measure, the CI is now opt-in to avoid wasting
cycles if the dev pushing commits didn't want to run it through the CI
yet.

If you're interested, the actual change is here:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/268

Technically, the CI now runs automatically on master and merge requests,
and you can always trigger builds manually by going on your fork's
https://gitlab.freedesktop.org/$USERNAME/mesa/pipelines/new
(or use an app like `lab` [2] which uses the GitLab API)

But to make it easier, you can also push to any branch starting with
`ci/*` or `ci-*`, or a branch simply named `ci`, and the CI will run
automatically on it.

I'm sure I'm breaking someone's workflow [3], but remember that the plan
is to tame this CI beast and turn it back on for everything :)

Cheers,
  Eric


[1] https://lists.freedesktop.org/archives/mesa-dev/2019-February/215481.html
[2] https://github.com/zaquestion/lab
[3] https://xkcd.com/1172/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrost: Backport driver to Mali T600/T700

[Connor Abbott]

On Tue, Feb 19, 2019 at 5:33 PM Emil Velikov 
wrote:

> On Fri, 15 Feb 2019 at 21:39, Alyssa Rosenzweig 
> wrote:
> >
> > > - about 1/5 of the patch seems to be white space changes
> >
> > ...Oops. Any tips for avoiding this type of diff churn in the future? I
> > suppose it's not inherently harmful, but maybe it could make merging
> > more difficult than strictly necessary.
> >
> Splitting/polishing patches can be fiddly - but IMHO pays in the long run.
> IIRC not too long ago Dave mentioned that specific work took him more
> time to polish+split than to write+debug the code.
>
> > > - doesn't seem like BIFROST is defined anywhere
> >
> > Indeed it's not; Bifrost is not yet supported, but at least this way we
> > can share headers with the out-of-tree work on Bifrost (is anyone
> > working on these parts right now..?)
> >
> > > - other drivers keep details like is_t6xx, require_sfbd, others in
> > > driver/screen specific struct
> >
> > Aye, that'll be fixed next patch :)
> >
> > > - the __LP64__ checks seems suspicious, no other mesa driver has those
> >
> > Is there a better way to handle mixed bit-ness? We have shared memory
> > (sort of -- separate MMUs, separate address spaces, but they're mapped
> > together with shared physical RAM and we opt for SAME_VA where gpu_va ==
> > user_cpu_va). As such, 32-bit Mali and 64-bit Mali behave differently,
> > since pointers are larger and then some fields get rearranged to pack
> > tighter/less-so depending on pointer sizes. There's no real benefit to
> > support both modes in the same build of the driver; by far, having a
> > 32-bit build for armhf with 32-bit Mali descriptors and a 64-bit build
> > for aarch64 with 64-bit descriptors is the sane approach. Accordingly,
> > I reasoned that __LP64__ is the cleanest way to check what type of
> > system we're building for, and from there which descriptor flavour we
> > should use. Is there something inherently problematic about this scheme?
> >
> I might not be the best person for this, but I think subtle
> differences like these should not be exposed to userspace (be part of
> the UABI).
> In the x86 world running 64bit kernels with 32bit userspace is fairly
> common, but from what I hear it's less so in Arm land.
>

This isn't UABI, since it has absolutely nothing to do with the kernel. The
hardware supports two command stream formats, the 32-bit one where pointers
are expanded from 32-bit to 64-bit internally by the HW and the 64-bit one,
and userspace tells the hardware which one it wants to use by setting a bit
in the job header which is only interpreted by the hardware. Right now the
idea is to select which one based on what bitsize the userspace is compiled
for, hence uintptr_t for pointers, but this could change in the future
without having to notify the kernel. Nothing in the kernel is reading these
pointers at all besides some HW workarounds in the vendor kernel which read
the same "which bitsize am I" bit the HW does.


>
> > In theory we can mix and match, the hardware can do both regardless of
> > the CPU as far as I know, but that complicates things dramatically for
> > little benefit.
> >
> > Keep in mind that Midgard onwards uses descriptors in shared memory,
> > rather than a true command stream, so it's possible no other mesa driver
> > does this since no other mesa-supported hardware needs this.
> >
> I don't know all the drivers but it sounds possible.
>
> Thanks for the extensive reply
> Emil
> ___
> 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] [Bug 109443] Build failure with MSVC 2017 when using Scons >= 3.0.2

[bugzilla-daemon]

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

Alex Granni  changed:

   What|Removed |Added

 Attachment #143412|scons-bisect-finish.txt |scons-bisect.txt
   filename||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109443] Build failure with MSVC 2017 when using Scons >= 3.0.2

[bugzilla-daemon]

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

--- Comment #1 from Alex Granni  ---
Created attachment 143412
  --> https://bugs.freedesktop.org/attachment.cgi?id=143412&action=edit
Scons source code bisect to determine when this became an issue.

-- 
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] panfrost: Backport driver to Mali T600/T700

[Emil Velikov]

On Fri, 15 Feb 2019 at 21:39, Alyssa Rosenzweig  wrote:
>
> > - about 1/5 of the patch seems to be white space changes
>
> ...Oops. Any tips for avoiding this type of diff churn in the future? I
> suppose it's not inherently harmful, but maybe it could make merging
> more difficult than strictly necessary.
>
Splitting/polishing patches can be fiddly - but IMHO pays in the long run.
IIRC not too long ago Dave mentioned that specific work took him more
time to polish+split than to write+debug the code.

> > - doesn't seem like BIFROST is defined anywhere
>
> Indeed it's not; Bifrost is not yet supported, but at least this way we
> can share headers with the out-of-tree work on Bifrost (is anyone
> working on these parts right now..?)
>
> > - other drivers keep details like is_t6xx, require_sfbd, others in
> > driver/screen specific struct
>
> Aye, that'll be fixed next patch :)
>
> > - the __LP64__ checks seems suspicious, no other mesa driver has those
>
> Is there a better way to handle mixed bit-ness? We have shared memory
> (sort of -- separate MMUs, separate address spaces, but they're mapped
> together with shared physical RAM and we opt for SAME_VA where gpu_va ==
> user_cpu_va). As such, 32-bit Mali and 64-bit Mali behave differently,
> since pointers are larger and then some fields get rearranged to pack
> tighter/less-so depending on pointer sizes. There's no real benefit to
> support both modes in the same build of the driver; by far, having a
> 32-bit build for armhf with 32-bit Mali descriptors and a 64-bit build
> for aarch64 with 64-bit descriptors is the sane approach. Accordingly,
> I reasoned that __LP64__ is the cleanest way to check what type of
> system we're building for, and from there which descriptor flavour we
> should use. Is there something inherently problematic about this scheme?
>
I might not be the best person for this, but I think subtle
differences like these should not be exposed to userspace (be part of
the UABI).
In the x86 world running 64bit kernels with 32bit userspace is fairly
common, but from what I hear it's less so in Arm land.

> In theory we can mix and match, the hardware can do both regardless of
> the CPU as far as I know, but that complicates things dramatically for
> little benefit.
>
> Keep in mind that Midgard onwards uses descriptors in shared memory,
> rather than a true command stream, so it's possible no other mesa driver
> does this since no other mesa-supported hardware needs this.
>
I don't know all the drivers but it sounds possible.

Thanks for the extensive reply
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] loader: use loader_open_device() to handle O_CLOEXEC

[Eric Engestrom]

On Tuesday, 2019-02-19 15:30:39 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Some platforms lack O_CLOEXEC. The loader_open_device() handles those
> appropriately, so use the helper.
> 
> Signed-off-by: Emil Velikov 

I'll review 1 & 3 later, but 2 & 4 are:
Reviewed-by: Eric Engestrom 

> ---
>  src/loader/loader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 56187080bbc..c578e3f0849 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -125,7 +125,7 @@ loader_open_render_node(const char *name)
>(device->bustype == DRM_BUS_PLATFORM)) {
>   drmVersionPtr version;
>  
> - fd = open(device->nodes[DRM_NODE_RENDER], O_RDWR | O_CLOEXEC);
> + fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
>   if (fd < 0)
>  continue;
>  
> -- 
> 2.20.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] gallium/auxiliary/vl: Fix duplicate symbol build errors.

[Emil Velikov]

On Tue, 19 Feb 2019 at 03:32, Vinson Lee  wrote:
>
>   CXXLDgallium_dri.la
> duplicate symbol _compute_shader_video_buffer in:
> 
> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
> 
> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor_cs.o)
> duplicate symbol _compute_shader_weave in:
> 
> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
> 
> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor_cs.o)
> duplicate symbol _compute_shader_rgba in:
> 
> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor.o)
> 
> ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a(libgalliumvl_la-vl_compositor_cs.o)
>
> Fixes: 9364d66cb7f7 ("gallium/auxiliary/vl: Add video compositor compute 
> shader render")
> Signed-off-by: Vinson Lee 
> ---
>  src/gallium/auxiliary/vl/vl_compositor_cs.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_compositor_cs.h 
> b/src/gallium/auxiliary/vl/vl_compositor_cs.h
> index 7a203d327eda..a73a8755fc2a 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor_cs.h
> +++ b/src/gallium/auxiliary/vl/vl_compositor_cs.h
> @@ -32,9 +32,9 @@
>
>  #include "vl_compositor.h"
>
> -char *compute_shader_video_buffer;
> -char *compute_shader_weave;
> -char *compute_shader_rgba;
> +extern char *compute_shader_video_buffer;
> +extern char *compute_shader_weave;
> +extern char *compute_shader_rgba;
>
Please make them also "const" - in both here and C file.

With that the patch is
Reviewed-by: Emil Velikov 

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

Re: [Mesa-dev] [PATCH v2 3/3] egl/sl: use kms_swrast with vgem instead of a random GPU

[Eric Engestrom]

On Tuesday, 2019-02-19 14:08:08 +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> VGEM and kms_swrast were introduced to work with one another.
> 
> All we do is CPU rendering to dumb buffers. There is no reason to carve
> out GPU memory, increasing the memory pressure on a device that could
> make a better use of it.
> 
> Note:
>  - The original code did not work out of the box, since the dumb buffer
> ioctls are not exposed to render nodes.
>  - This requires libdrm commit 3df8a7f0 ("xf86drm: fallback to MODALIAS
> for OF less platform devices")
>  - The non-kms, swrast is unaffected by this change.
> 
> v2:
>  - elaborate what and how is/isn't working (Eric)
>  - simplify driver_name handling (Eric)
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/egl/drivers/dri2/platform_surfaceless.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
> b/src/egl/drivers/dri2/platform_surfaceless.c
> index ccdc370d059..0917c15e16d 100644
> --- a/src/egl/drivers/dri2/platform_surfaceless.c
> +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> @@ -286,10 +286,11 @@ surfaceless_probe_device(_EGLDisplay *disp, bool swrast)
> for (i = 0; i < num_devices; ++i) {
>device = devices[i];
>  
> -  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
> +  const unsigned node_type = swrast ? DRM_NODE_PRIMARY : DRM_NODE_RENDER;

Nittiest of nits: this could be outside the loop :)

> +  if (!(device->available_nodes & (1 << node_type)))
>   continue;
>  
> -  dri2_dpy->fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
> +  dri2_dpy->fd = loader_open_device(device->nodes[node_type]);
>if (dri2_dpy->fd < 0)
>   continue;
>  
> @@ -300,10 +301,16 @@ surfaceless_probe_device(_EGLDisplay *disp, bool swrast)
>   continue;
>}
>  
> -  if (swrast)
> - dri2_dpy->driver_name = strdup("kms_swrast");
> -  else
> - dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> +  char *driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
> +  if (swrast) {
> + /* Use kms swrast only with vgem */
> + if (strcmp(driver_name, "vgem") == 0)
> +dri2_dpy->driver_name = strdup("kms_swrast");
> + free(driver_name);
> +  } else {
> + /* Use the given hardware driver */
> + dri2_dpy->driver_name = driver_name;
> +  }

That's easier to follow, thanks!

Please wait for the chromium guys to weigh in, but:
Reviewed-by: Eric Engestrom 

>  
>if (dri2_dpy->driver_name && dri2_load_driver_dri3(disp))
>   break;
> -- 
> 2.20.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 109190] virgl: buffer flushing error with some dEQP tests [bisected]

[bugzilla-daemon]

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

Gert Wollny  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Gert Wollny  ---
This has been fixed with ca66457b0516ef8af5ef17c54460ab8d9aefc5fa

-- 
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] [PATCH 2/4] loader: use loader_open_device() to handle O_CLOEXEC

[Emil Velikov]

From: Emil Velikov 

Some platforms lack O_CLOEXEC. The loader_open_device() handles those
appropriately, so use the helper.

Signed-off-by: Emil Velikov 
---
 src/loader/loader.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 56187080bbc..c578e3f0849 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -125,7 +125,7 @@ loader_open_render_node(const char *name)
   (device->bustype == DRM_BUS_PLATFORM)) {
  drmVersionPtr version;
 
- fd = open(device->nodes[DRM_NODE_RENDER], O_RDWR | O_CLOEXEC);
+ fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
  if (fd < 0)
 continue;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 4/4] egl/android: bump the number of drmDevices to 64

[Emil Velikov]

From: Emil Velikov 

It's the current maximum supported by the kernel. Stay consistent with
the rest of Mesa and use the same number.

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_android.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/drivers/dri2/platform_android.c 
b/src/egl/drivers/dri2/platform_android.c
index 7e1d61052db..5b530f2ba73 100644
--- a/src/egl/drivers/dri2/platform_android.c
+++ b/src/egl/drivers/dri2/platform_android.c
@@ -1457,7 +1457,7 @@ droid_probe_device(_EGLDisplay *disp)
 static EGLBoolean
 droid_open_device(_EGLDisplay *disp)
 {
-#define MAX_DRM_DEVICES 32
+#define MAX_DRM_DEVICES 64
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
int num_devices;
-- 
2.20.1

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

[Mesa-dev] [PATCH 3/4] loader: simplify loader_get_user_preferred_fd()

[Emil Velikov]

From: Emil Velikov 

Reoder the function a bit to make the code-flow more obvious and short.

Signed-off-by: Emil Velikov 
---
git show -w produces a nicer diff
---
 src/loader/loader.c | 42 --
 1 file changed, 16 insertions(+), 26 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index c578e3f0849..cea1aac5b56 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -280,7 +280,6 @@ int loader_get_user_preferred_fd(int default_fd, bool 
*different_device)
char *default_tag, *prime = NULL;
drmDevicePtr devices[MAX_DRM_DEVICES];
int i, num_devices, fd;
-   bool found = false;
 
if (dri_prime)
   prime = strdup(dri_prime);
@@ -302,41 +301,32 @@ int loader_get_user_preferred_fd(int default_fd, bool 
*different_device)
if (num_devices < 0)
   goto err;
 
-   /* two format are supported:
-* "1": choose any other card than the card used by default.
-* id_path_tag: (for example "pci-_02_00_0") choose the card
-* with this id_path_tag.
-*/
-   if (!strcmp(prime,"1")) {
-  /* Hmm... detection for 2-7 seems to be broken. Oh well ...
-   * Pick the first render device that is not our own.
-   */
-  for (i = 0; i < num_devices; i++) {
- if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
- !drm_device_matches_tag(devices[i], default_tag)) {
+   for (i = 0; i < num_devices; i++) {
+  if (!(devices[i]->available_nodes & 1 << DRM_NODE_RENDER))
+ continue;
 
-found = true;
+  /* two formats of DRI_PRIME are supported:
+   * "1": choose any other card than the card used by default.
+   * id_path_tag: (for example "pci-_02_00_0") choose the card
+   * with this id_path_tag.
+   */
+  if (!strcmp(prime,"1")) {
+ if (!drm_device_matches_tag(devices[i], default_tag)) {
+fd = loader_open_device(devices[i]->nodes[DRM_NODE_RENDER]);
 break;
  }
-  }
-   } else {
-  for (i = 0; i < num_devices; i++) {
- if (devices[i]->available_nodes & 1 << DRM_NODE_RENDER &&
-drm_device_matches_tag(devices[i], prime)) {
-
-found = true;
+  } else {
+ if (drm_device_matches_tag(devices[i], prime)) {
+fd = loader_open_device(devices[i]->nodes[DRM_NODE_RENDER]);
 break;
  }
   }
}
+   drmFreeDevices(devices, num_devices);
 
-   if (!found) {
-  drmFreeDevices(devices, num_devices);
+   if (i == num_devices)
   goto err;
-   }
 
-   fd = loader_open_device(devices[i]->nodes[DRM_NODE_RENDER]);
-   drmFreeDevices(devices, num_devices);
if (fd < 0)
   goto err;
 
-- 
2.20.1

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

[Mesa-dev] [PATCH 1/4] loader: use a maximum of 64 drmDevices

[Emil Velikov]

From: Emil Velikov 

Currently that's the hard-coded maximum in the kernel, even though the
libdrm API allows for more. Latter is done with extendability in mind.

Allocate 64 pointers^Wdevices on stack for now. Making for shorter and
ever-so-slightly faster code.

Signed-off-by: Emil Velikov 
---
 src/loader/loader.c | 40 ++--
 1 file changed, 14 insertions(+), 26 deletions(-)

diff --git a/src/loader/loader.c b/src/loader/loader.c
index 0f799c14fd8..56187080bbc 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -110,27 +110,15 @@ static char *loader_get_kernel_driver_name(int fd)
 int
 loader_open_render_node(const char *name)
 {
-   drmDevicePtr *devices, device;
-   int err, render = -ENOENT, fd;
-   unsigned int num, i;
-
-   err = drmGetDevices2(0, NULL, 0);
-   if (err < 0)
-  return err;
-
-   num = err;
-
-   devices = calloc(num, sizeof(*devices));
-   if (!devices)
-  return -ENOMEM;
+#define MAX_DRM_DEVICES 64
+   drmDevicePtr devices[MAX_DRM_DEVICES], device;
+   int i, num_devices, fd;
 
-   err = drmGetDevices2(0, devices, num);
-   if (err < 0) {
-  render = err;
-  goto free;
-   }
+   num_devices = drmGetDevices2(0, devices, MAX_DRM_DEVICES);
+   if (num_devices < 0)
+  return num_devices;
 
-   for (i = 0; i < num; i++) {
+   for (i = 0; i < num_devices; i++) {
   device = devices[i];
 
   if ((device->available_nodes & (1 << DRM_NODE_RENDER)) &&
@@ -154,16 +142,16 @@ loader_open_render_node(const char *name)
  }
 
  drmFreeVersion(version);
- render = fd;
  break;
   }
}
+   drmFreeDevices(devices, num_devices);
 
-   drmFreeDevices(devices, num);
+   if (i == num_devices)
+  return -ENOENT;
 
-free:
-   free(devices);
-   return render;
+   return fd;
+#undef MAX_DRM_DEVICES
 }
 
 #ifdef USE_DRICONF
@@ -287,8 +275,7 @@ static char *drm_get_id_path_tag_for_fd(int fd)
 
 int loader_get_user_preferred_fd(int default_fd, bool *different_device)
 {
-/* Arbitrary "maximum" value of drm devices. */
-#define MAX_DRM_DEVICES 32
+#define MAX_DRM_DEVICES 64
const char *dri_prime = getenv("DRI_PRIME");
char *default_tag, *prime = NULL;
drmDevicePtr devices[MAX_DRM_DEVICES];
@@ -367,6 +354,7 @@ int loader_get_user_preferred_fd(int default_fd, bool 
*different_device)
free(default_tag);
free(prime);
return default_fd;
+#undef MAX_DRM_DEVICES
 }
 #else
 int
-- 
2.20.1

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

[Mesa-dev] [Bug 109659] Missing OpenGL symbols in OSMesa Gallium when building with meson

[bugzilla-daemon]

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

Dylan Baker  changed:

   What|Removed |Added

 CC||baker.dyla...@gmail.com,
   ||bri...@vmware.com

--- Comment #1 from Dylan Baker  ---
I think your suggestion to use `link_Whole` is probably the correct one,
autotools has the link whole behavior by default in that case. I just want to
Cc Brian, who knows how osmesa is supposed to work.

-- 
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] [MR] radeonsi: Use uniform location when calculating const_file_max.

[Timur Kristóf]

Hi,

The following MR fixes an issue we've discovered while working on NIR
support for Gallium Nine. When there are NIR uniform variables whose
location is explicitly set, radeonsi did not take that into account
when calculating const_file_max, resulting in rendering glitches in
some games. This patch fixes that.

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/271

Best regards,
Tim

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

Re: [Mesa-dev] [MR] WIP: Improve TTN so it can be used by Gallium Nine

[Timur Kristóf]

Hi,

I've polished the MR according to feedback, and also added some
additional fixes. Also removed the WIP tag. With these changes, most
nine games we tested can work flawlessly on radeonsi with NIR.

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225

Code reviews are very welcome.

Best regards,
Tim


On Fri, 2019-02-08 at 12:09 +0100, Timur Kristóf wrote:
> Hi,
> 
> This MR is part of our ongoing work to support NIR in nine. We are 
> currently testing on radeonsi, but our ultimate goal with this is to
> make it possible for nine to run with iris (and eventually zink).
> 
> These patches give some polish to tgsi_to_nir (aka. TTN), so that it
> can handle the TGSI input that it receives from nine. Any feedback on
> this patch series is greatly welcome.
> 
> Some games we tested are already playable on radeonsi with NIR (and
> to
> some degree on iris too, but with glitches).
> 
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/225
> 
> Best regards,
> Tim
> 
> 

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

[Mesa-dev] [Bug 109645] build error on arm64: tegra_screen.c:33: /usr/include/xf86drm.h:41:10: fatal error: drm.h: No such file or directory

[bugzilla-daemon]

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

Fabio Pedretti  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/2] isl: remove the cache line size alignment requirement

[Jason Ekstrand]

Rb

On February 19, 2019 06:06:41 Samuel Iglesias Gonsálvez 
 wrote:



The cacheline size was a requirement for using the BLT engine, which
we don't use anymore except for a few things on old HW, so we drop it.

Fixes CTS's CL#3500 test:

dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r8g8b8_unorm

Signed-off-by: Samuel Iglesias Gonsálvez 
---
src/intel/isl/isl.c | 14 --
1 file changed, 14 deletions(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index eaaa28014a3..5c34efb9a13 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1381,20 +1381,6 @@ isl_calc_row_pitch(const struct isl_device *dev,
   uint32_t alignment_B =
  isl_calc_row_pitch_alignment(surf_info, tile_info);

-   /* If pitch isn't given and it can be chosen freely, align it by cache line
-* allowing one to use blit engine on the surface.
-*/
-   if (surf_info->row_pitch_B == 0 && tile_info->tiling == 
ISL_TILING_LINEAR) {

-  /* From the Broadwell PRM docs for XY_SRC_COPY_BLT::SourceBaseAddress:
-   *
-   *"Base address of the destination surface: X=0, Y=0. Lower 32bits
-   *of the 48bit addressing. When Src Tiling is enabled (Bit_15
-   *enabled), this address must be 4KB-aligned. When Tiling is not
-   *enabled, this address should be CL (64byte) aligned."
-   */
-  alignment_B = MAX2(alignment_B, 64);
-   }
-
   const uint32_t min_row_pitch_B =
  isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_total_el,
 alignment_B);
--
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

[Mesa-dev] [PATCH v2 1/3] egl/sl: split out swrast probe into separate function

[Emil Velikov]

From: Emil Velikov 

Make the code a bit easier to read.

As a bonus point this makes it obvious that we forgot to call
_eglAddDevice() for the device - do so.

v2:
 - s/dpy/disp/ (Eric)
 - free(driver_name) on dri2_load_driver_swrast() failure (Eric)

Signed-off-by: Emil Velikov 
Reviewed-by: Eric Engestrom 
Reviewed-by: Mathias Fröhlich  (v1)
---
 src/egl/drivers/dri2/platform_surfaceless.c | 43 +
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index 0c018a35234..42bd17e8341 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -322,25 +322,30 @@ surfaceless_probe_device(_EGLDisplay *disp, bool swrast)
   dri2_dpy->loader_extensions = NULL;
}
 
-   /* No DRM device, so attempt to fall back to software path w/o DRM. */
-   if (swrast) {
-  _eglLog(_EGL_DEBUG, "Falling back to surfaceless swrast without DRM.");
-  dri2_dpy->fd = -1;
-  dri2_dpy->driver_name = strdup("swrast");
-  if (!dri2_dpy->driver_name) {
- return false;
-  }
+   return false;
+}
 
-  if (dri2_load_driver_swrast(disp)) {
- dri2_dpy->loader_extensions = swrast_loader_extensions;
- return true;
-  }
+static bool
+surfaceless_probe_device_sw(_EGLDisplay *disp)
+{
+   struct dri2_egl_display *dri2_dpy = disp->DriverData;
+
+   dri2_dpy->fd = -1;
+   disp->Device = _eglAddDevice(dri2_dpy->fd, true);
+   assert(disp->Device);
+
+   dri2_dpy->driver_name = strdup("swrast");
+   if (!dri2_dpy->driver_name)
+  return false;
 
+   if (!dri2_load_driver_swrast(disp)) {
   free(dri2_dpy->driver_name);
   dri2_dpy->driver_name = NULL;
+  return false;
}
 
-   return false;
+   dri2_dpy->loader_extensions = swrast_loader_extensions;
+   return true;
 }
 
 EGLBoolean
@@ -364,9 +369,15 @@ dri2_initialize_surfaceless(_EGLDriver *drv, _EGLDisplay 
*disp)
  "No hardware driver found, falling back to software 
rendering");
}
 
-   if (!driver_loaded && !surfaceless_probe_device(disp, true)) {
-  err = "DRI2: failed to load driver";
-  goto cleanup;
+   if (!driver_loaded)
+  driver_loaded = surfaceless_probe_device(disp, true);
+
+   if (!driver_loaded) {
+  _eglLog(_EGL_DEBUG, "Falling back to surfaceless swrast without DRM.");
+  if (!surfaceless_probe_device_sw(disp)) {
+ err = "DRI2: failed to load driver";
+ goto cleanup;
+  }
}
 
if (!dri2_create_screen(disp)) {
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 3/3] egl/sl: use kms_swrast with vgem instead of a random GPU

[Emil Velikov]

From: Emil Velikov 

VGEM and kms_swrast were introduced to work with one another.

All we do is CPU rendering to dumb buffers. There is no reason to carve
out GPU memory, increasing the memory pressure on a device that could
make a better use of it.

Note:
 - The original code did not work out of the box, since the dumb buffer
ioctls are not exposed to render nodes.
 - This requires libdrm commit 3df8a7f0 ("xf86drm: fallback to MODALIAS
for OF less platform devices")
 - The non-kms, swrast is unaffected by this change.

v2:
 - elaborate what and how is/isn't working (Eric)
 - simplify driver_name handling (Eric)

Signed-off-by: Emil Velikov 
---
 src/egl/drivers/dri2/platform_surfaceless.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index ccdc370d059..0917c15e16d 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -286,10 +286,11 @@ surfaceless_probe_device(_EGLDisplay *disp, bool swrast)
for (i = 0; i < num_devices; ++i) {
   device = devices[i];
 
-  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
+  const unsigned node_type = swrast ? DRM_NODE_PRIMARY : DRM_NODE_RENDER;
+  if (!(device->available_nodes & (1 << node_type)))
  continue;
 
-  dri2_dpy->fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
+  dri2_dpy->fd = loader_open_device(device->nodes[node_type]);
   if (dri2_dpy->fd < 0)
  continue;
 
@@ -300,10 +301,16 @@ surfaceless_probe_device(_EGLDisplay *disp, bool swrast)
  continue;
   }
 
-  if (swrast)
- dri2_dpy->driver_name = strdup("kms_swrast");
-  else
- dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+  char *driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+  if (swrast) {
+ /* Use kms swrast only with vgem */
+ if (strcmp(driver_name, "vgem") == 0)
+dri2_dpy->driver_name = strdup("kms_swrast");
+ free(driver_name);
+  } else {
+ /* Use the given hardware driver */
+ dri2_dpy->driver_name = driver_name;
+  }
 
   if (dri2_dpy->driver_name && dri2_load_driver_dri3(disp))
  break;
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 2/3] egl/sl: use drmDevice API to enumerate available devices

[Emil Velikov]

From: Emil Velikov 

This provides for a more comprehensive iteration and slightly more
straight-forward codebase.

v2:
 - s/dpy/disp/
 - keep original 64 devices (Eric)

Signed-off-by: Emil Velikov 
Reviewed-by: Eric Engestrom 
Reviewed-by: Mathias Fröhlich 
---
 src/egl/drivers/dri2/platform_surfaceless.c | 73 +++--
 1 file changed, 37 insertions(+), 36 deletions(-)

diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
b/src/egl/drivers/dri2/platform_surfaceless.c
index 42bd17e8341..ccdc370d059 100644
--- a/src/egl/drivers/dri2/platform_surfaceless.c
+++ b/src/egl/drivers/dri2/platform_surfaceless.c
@@ -274,55 +274,56 @@ static const __DRIextension *swrast_loader_extensions[] = 
{
 static bool
 surfaceless_probe_device(_EGLDisplay *disp, bool swrast)
 {
+#define MAX_DRM_DEVICES 64
struct dri2_egl_display *dri2_dpy = disp->DriverData;
-   const int limit = 64;
-   const int base = 128;
-   int fd;
-   int i;
-
-   /* Attempt to find DRM device. */
-   for (i = 0; i < limit; ++i) {
-  char *card_path;
-  if (asprintf(&card_path, DRM_RENDER_DEV_NAME, DRM_DIR_NAME, base + i) < 
0)
+   drmDevicePtr device, devices[MAX_DRM_DEVICES] = { NULL };
+   int i, num_devices;
+
+   num_devices = drmGetDevices2(0, devices, ARRAY_SIZE(devices));
+   if (num_devices < 0)
+  return false;
+
+   for (i = 0; i < num_devices; ++i) {
+  device = devices[i];
+
+  if (!(device->available_nodes & (1 << DRM_NODE_RENDER)))
  continue;
 
-  fd = loader_open_device(card_path);
-  free(card_path);
-  if (fd < 0)
+  dri2_dpy->fd = loader_open_device(device->nodes[DRM_NODE_RENDER]);
+  if (dri2_dpy->fd < 0)
  continue;
 
-  if (swrast) {
- dri2_dpy->driver_name = strdup("kms_swrast");
- dri2_dpy->loader_extensions = swrast_loader_extensions;
-  } else {
- dri2_dpy->driver_name = loader_get_driver_for_fd(fd);
- dri2_dpy->loader_extensions = image_loader_extensions;
-  }
-  if (!dri2_dpy->driver_name) {
- close(fd);
+  disp->Device = _eglAddDevice(dri2_dpy->fd, swrast);
+  if (!disp->Device) {
+ close(dri2_dpy->fd);
+ dri2_dpy->fd = -1;
  continue;
   }
 
-  dri2_dpy->fd = fd;
-  if (dri2_load_driver_dri3(disp)) {
- _EGLDevice *dev = _eglAddDevice(dri2_dpy->fd, swrast);
- if (!dev) {
-dlclose(dri2_dpy->driver);
-_eglLog(_EGL_WARNING, "DRI2: failed to find EGLDevice");
-continue;
- }
- disp->Device = dev;
- return true;
-  }
+  if (swrast)
+ dri2_dpy->driver_name = strdup("kms_swrast");
+  else
+ dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
+
+  if (dri2_dpy->driver_name && dri2_load_driver_dri3(disp))
+ break;
 
-  close(fd);
-  dri2_dpy->fd = -1;
   free(dri2_dpy->driver_name);
   dri2_dpy->driver_name = NULL;
-  dri2_dpy->loader_extensions = NULL;
+  close(dri2_dpy->fd);
+  dri2_dpy->fd = -1;
}
+   drmFreeDevices(devices, num_devices);
+
+   if (i == num_devices)
+  return false;
+
+   if (swrast)
+  dri2_dpy->loader_extensions = swrast_loader_extensions;
+   else
+  dri2_dpy->loader_extensions = image_loader_extensions;
 
-   return false;
+   return true;
 }
 
 static bool
-- 
2.20.1

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

[Mesa-dev] [Bug 109646] New video compositor compute shader render glitches mpv

[bugzilla-daemon]

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

--- Comment #6 from jam...@amd.com  ---
Sorry,  https://www.youtube.com/watch?v=LXb3EKWsInQ is the clip. James

-- 
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 109646] New video compositor compute shader render glitches mpv

[bugzilla-daemon]

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

--- Comment #5 from jam...@amd.com  ---
Thanks so much! By the way, can you provide me the source to reproduce the
jagginess issue at my side?
James

-- 
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 2/3] egl/sl: use drmDevice API to enumerate available devices

[Emil Velikov]

On Mon, 18 Feb 2019 at 16:50, Eric Engestrom  wrote:
>
> On Tuesday, 2019-02-05 15:31:07 +, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > This provides for a more comprehensive iteration and a more
> > straight-forward codebase, while minimising the platform specifics.
> >
> > Signed-off-by: Emil Velikov 
> > ---
> >  src/egl/drivers/dri2/platform_surfaceless.c | 73 +++--
> >  1 file changed, 37 insertions(+), 36 deletions(-)
> >
> > diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
> > b/src/egl/drivers/dri2/platform_surfaceless.c
> > index d6e48ba11b2..e1151e3585c 100644
> > --- a/src/egl/drivers/dri2/platform_surfaceless.c
> > +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> > @@ -274,55 +274,56 @@ static const __DRIextension 
> > *swrast_loader_extensions[] = {
> >  static bool
> >  surfaceless_probe_device(_EGLDisplay *dpy, bool swrast)
> >  {
> > +#define MAX_DRM_DEVICES 32
> > struct dri2_egl_display *dri2_dpy = dpy->DriverData;
> > -   const int limit = 64;
>
> Any reason to drop the 64 down to 32?
>
Copy/paste from src/loader and platform_android.c. I don't see us
reaching 16 anytime soon, but sure.
Will tweak and send patches for the other instances.

> Other than that, looks good to me:
> Reviewed-by: Eric Engestrom 

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

[Mesa-dev] [Bug 109645] build error on arm64: tegra_screen.c:33: /usr/include/xf86drm.h:41:10: fatal error: drm.h: No such file or directory

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Eric Engestrom  ---
Fixed by:

commit b787403a21de8eeb21336274ba6ff19392a216da
Author: Eric Engestrom 
Date:   Tue Feb 19 10:57:58 2019 +

tegra/meson: add missing dep_libdrm

Fixes: f1374805a86d0d506557 "drm-uapi: use local files, not system libdrm"
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109645
Signed-off-by: Eric Engestrom 
Reviewed-by: Emil Velikov 

-- 
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 109647] /usr/include/xf86drm.h:40:10: fatal error: drm.h: No such file or directory

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #3 from Eric Engestrom  ---
Fixed by:

commit f84f833981286b2955f40f98e4beeecbcc67a69b
Author: Eric Engestrom 
Date:   Tue Feb 19 11:18:07 2019 +

tegra/autotools: add missing libdrm cflags

Fixes: f1374805a86d0d506557 "drm-uapi: use local files, not system libdrm"
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=109647
Signed-off-by: Eric Engestrom 
Reviewed-by: Emil Velikov 

-- 
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] egl/dri: de-duplicate dri2_load_driver*

[Emil Velikov]

On Wed, 6 Feb 2019 at 12:38, Eric Engestrom  wrote:
>
> On Tuesday, 2019-02-05 15:19:46 +, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > The difference between the tree functions is the list of mandatory
> > driver extensions. Pass that as an argument to the common helper.
> >
> > Signed-off-by: Emil Velikov 
>
> Pretty sure I also have this patch somewhere... I should send out my
> patches more regularly :]
>
> With Frank's typo fix
> Reviewed-by: Eric Engestrom 
>
Thanks guys. Typo fixed.

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

Re: [Mesa-dev] [PATCH 3/3] panfrost: Swap order of tiled texture (de)alloc

[Emil Velikov]

On Fri, 15 Feb 2019 at 22:12, Alyssa Rosenzweig  wrote:
>
> > Am I reading this correctly, that now we free a slab [for a tiled
> > texture] before allocating new one? The commit message seems rather
> > cryptic.
>
> Yeah, it's a super minor fix. Rather than allocating a new slab for the
> texture and then freeing the old slab, we free then allocate.
> Practically, it's identical (since there's no dependency, and they ought
> to be the same size...), but it does avoid having to expand the pool if
> we're right on the edge. Almost nitpick level, but hey, if it makes
> memory use slightly lower and performance slightly more predictable :)

Right, thanks. Just double-checking since I was struggling with the
commit message.

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

Re: [Mesa-dev] [PATCH 1/3] egl/sl: split out swrast probe into separate function

[Emil Velikov]

On Mon, 18 Feb 2019 at 16:07, Eric Engestrom  wrote:
>
> On Tuesday, 2019-02-05 15:31:06 +, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > Make the code a bit easier to read.
> >
> > As a bonus point this makes it obvious that we forgot to call
> > _eglAddDevice() for the device - do so.
> >
> > Signed-off-by: Emil Velikov 
> > ---
> >  src/egl/drivers/dri2/platform_surfaceless.c | 46 -
> >  1 file changed, 27 insertions(+), 19 deletions(-)
> >
> > diff --git a/src/egl/drivers/dri2/platform_surfaceless.c 
> > b/src/egl/drivers/dri2/platform_surfaceless.c
> > index f9809561611..d6e48ba11b2 100644
> > --- a/src/egl/drivers/dri2/platform_surfaceless.c
> > +++ b/src/egl/drivers/dri2/platform_surfaceless.c
> > @@ -322,25 +322,27 @@ surfaceless_probe_device(_EGLDisplay *dpy, bool 
> > swrast)
> >dri2_dpy->loader_extensions = NULL;
> > }
> >
> > -   /* No DRM device, so attempt to fall back to software path w/o DRM. */
> > -   if (swrast) {
> > -  _eglLog(_EGL_DEBUG, "Falling back to surfaceless swrast without 
> > DRM.");
> > -  dri2_dpy->fd = -1;
> > -  dri2_dpy->driver_name = strdup("swrast");
> > -  if (!dri2_dpy->driver_name) {
> > - return false;
> > -  }
> > +   return false;
> > +}
> >
> > -  if (dri2_load_driver_swrast(dpy)) {
> > - dri2_dpy->loader_extensions = swrast_loader_extensions;
> > - return true;
> > -  }
> > +static bool
> > +surfaceless_probe_device_sw(_EGLDisplay *dpy)
>
> Don't forget to rename s/dpy/disp/ :)
>
Fixed.

> > +{
> > +   struct dri2_egl_display *dri2_dpy = dpy->DriverData;
> >
> > -  free(dri2_dpy->driver_name);
> > -  dri2_dpy->driver_name = NULL;
> > -   }
> > +   dri2_dpy->fd = -1;
> > +   dpy->Device = _eglAddDevice(dri2_dpy->fd, true);
> > +   assert(dpy->Device);
> >
> > -   return false;
> > +   dri2_dpy->driver_name = strdup("swrast");
> > +   if (!dri2_dpy->driver_name)
> > +  return false;
> > +
> > +   if (!dri2_load_driver_swrast(dpy))
>
> free(dri2_dpy->driver_name);
>
Ditto.

> With that:
> Reviewed-by: Eric Engestrom 
>
Thank you!

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

Re: [Mesa-dev] [PATCH 1/3] panfrost: Fix various leaks unmapping resources

[Emil Velikov]

On Fri, 15 Feb 2019 at 21:42, Alyssa Rosenzweig  wrote:
>
> > Nit: staying consistent with "foo != NULL" vs "foo" checks helps a
> > lot.
>
> Which form is preferred?
>
I think that varies across parts of mesa. I'd pick one and use it
through panfrost.

> > free(NULL); is perfectly valid.
>
> Huh, TIL, thank you.
>
> > The function pointer seems to be NULL. Did you forget to git add the
> > file which sets it?
>
> See my comment in the other mail about the overlay. Generally, functions
> of the form "screen->driver->..." are specific to the kernel module in
> question, and we're not able to upstream the code specific to the vendor
> kernel for various reasons. It may be a good idea to stub out the
> corresponding routines in pan_drm.c, but that's up to Rob and Tomeu.

Are there any legal reasons? Alternatively, I think it's reasonable to
have the code merged.
Sure it may not be perfect yet it's something people can grab and
start hacking with.

Plus, as in this example the fix cannot be easily verified :-(

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

Re: [Mesa-dev] [PATCH] panfrost: Fix build; depend on libdrm

[Emil Velikov]

On Fri, 15 Feb 2019 at 21:33, Alyssa Rosenzweig  wrote:
>
> > Feel free to reuse:
> > meson: panfrost: add missing libdrm dependency
>
> Hmm?
Was a minor wording suggestion. Personally the "Fix build" phase is quite meh.
Doesn't matter though - fix has landed.

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

[Mesa-dev] [PATCH v2 1/2] isl: remove the cache line size alignment requirement

[Samuel Iglesias Gonsálvez]

The cacheline size was a requirement for using the BLT engine, which
we don't use anymore except for a few things on old HW, so we drop it.

Fixes CTS's CL#3500 test:

dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r8g8b8_unorm

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/isl/isl.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index eaaa28014a3..5c34efb9a13 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1381,20 +1381,6 @@ isl_calc_row_pitch(const struct isl_device *dev,
uint32_t alignment_B =
   isl_calc_row_pitch_alignment(surf_info, tile_info);
 
-   /* If pitch isn't given and it can be chosen freely, align it by cache line
-* allowing one to use blit engine on the surface.
-*/
-   if (surf_info->row_pitch_B == 0 && tile_info->tiling == ISL_TILING_LINEAR) {
-  /* From the Broadwell PRM docs for XY_SRC_COPY_BLT::SourceBaseAddress:
-   *
-   *"Base address of the destination surface: X=0, Y=0. Lower 32bits
-   *of the 48bit addressing. When Src Tiling is enabled (Bit_15
-   *enabled), this address must be 4KB-aligned. When Tiling is not
-   *enabled, this address should be CL (64byte) aligned."
-   */
-  alignment_B = MAX2(alignment_B, 64);
-   }
-
const uint32_t min_row_pitch_B =
   isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_total_el,
  alignment_B);
-- 
2.19.1

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

[Mesa-dev] [PATCH v2 2/2] isl: the display engine requires 64B alignment for linear surfaces

[Samuel Iglesias Gonsálvez]

Signed-off-by: Samuel Iglesias Gonsálvez 
---
 src/intel/isl/isl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 5c34efb9a13..7fb469687fa 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1519,6 +1519,9 @@ isl_surf_init_s(const struct isl_device *dev,
  }
   }
   base_alignment_B = isl_round_up_to_power_of_two(base_alignment_B);
+  /* The display engine requires 64B alignment for linear surfaces.  */
+  if (isl_surf_usage_is_display(info->usage))
+ base_alignment_B = MAX(base_alignment_B, 64);
} else {
   const uint32_t total_h_tl =
  isl_align_div(phys_total_el.h, tile_info.logical_extent_el.height);
-- 
2.19.1

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

Re: [Mesa-dev] [PATCH 3/3] egl/sl: use kms_swrast with vgem instead of a random GPU

[Emil Velikov]

Hi Eric,

Thanks for having a look!

On Mon, 18 Feb 2019 at 17:05, Eric Engestrom  wrote:
>
> On Tuesday, 2019-02-05 15:31:08 +, Emil Velikov wrote:
> > From: Emil Velikov 
> >
> > VGEM and kms_swrast were introduced to work with one another.
> >
> > All we do is CPU rendering to dumb buffers. There is no reason to carve
> > out GPU memory, increasing the memory pressure on a device that could
> > make a better use of it.
> >
> > For kms_swrast to work properly we require the primary node, as the dumb
> > buffer ioctls are not exposed via the render node.
> >
> > Note that this requires libdrm commit 3df8a7f0 ("xf86drm: fallback to
> > MODALIAS for OF less platform devices")
>
> Without this, what happens? swrast stops working?
>
kms_swrast never worked OOTB - extra patches were needed.
There is no change to swrast itself.

> A couple style comments below, but this question is my main concern.
>

> > +  dri2_dpy->driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
>
> Can you keep the else branch like before? Makes it more readable IMO,
> and avoids allocating memory just to free it a couple lines below.
>
We need to get the driver name first, since we compare it against
"vgem" on the very next line.
Fully admit though as-is the code isn't that easy to read.

> > +  if (swrast) {
> > + /* Use kms swrast only with vgem */
> > + if (strcmp(dri2_dpy->driver_name, "vgem") != 0) {
> > +free(dri2_dpy->driver_name);
> > +dri2_dpy->driver_name = NULL;
> > + } else {
> > +free(dri2_dpy->driver_name);
> > +dri2_dpy->driver_name = strdup("kms_swrast");
>
> Again, IMO this would be more readable as "if vgem use kms_swrast"
> instead of "if not vgem skip else use kms_swrast".
>
> The above two comments combined give us this code instead:
>
>   if swrast
> if driver == vgem
>   driver = kms_swrast
>   else
> driver = get_driver(fd)
>
Sure can flip the if/else. Might as well add a local driver_name to
simplify the free()/NULL bits.

char *driver_name = loader_get_driver_for_fd(dri2_dpy->fd);
if (swrast) {
   /* Use kms_swrast only with vgem */
   if (strcmp(driver_name, "vgem") == 0)
  dri2_dpy->driver_name = strdup("kms_swrast");
   free(driver_name);
} else {
   /* Use the given hardware driver */
dri2_dpy->driver_name = driver_name;
}

Will send out v2 in a moment.

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

[Mesa-dev] [Bug 109645] build error on arm64: tegra_screen.c:33: /usr/include/xf86drm.h:41:10: fatal error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #4 from Eric Engestrom  ---
Instead of testing a copy/pasted patch, you can test the branch in this MR:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/270

-- 
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 109647] /usr/include/xf86drm.h:40:10: fatal error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #2 from Eric Engestrom  ---
Actually not really a duplicate; although the issue was shown by the same
commit (f1374805a86d0), this bug report is for the bug that was there in the
autotools config and the other is for the bug that was in the meson config.

Both should be fixed by this MR:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/270

-- 
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 109645] build error on arm64: tegra_screen.c:33: /usr/include/xf86drm.h:41:10: fatal error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #3 from Eric Engestrom  ---
Sorry, I broke two libdrm things within a few days and I got confused between
the issues. Looking at this one now, but at first glance it looks like
src/gallium/drivers/tegra/meson.build is just missing its dep_libdrm.

@Fabio could you test this for me?

8<
diff --git a/src/gallium/drivers/tegra/meson.build
b/src/gallium/drivers/tegra/meson.build
index d24438edc1383d571552..939d6294601cd07b3f51 100644
--- a/src/gallium/drivers/tegra/meson.build
+++ b/src/gallium/drivers/tegra/meson.build
@@ -33,6 +33,7 @@ libtegra = static_library(
 inc_include, inc_src, inc_gallium, inc_gallium_aux, inc_gallium_drivers,
 inc_gallium_winsys,
   ],
+  dependencies : dep_libdrm,
 )

 driver_tegra = declare_dependency(
>8

-- 
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 109645] build error on arm64: tegra_screen.c:33: /usr/include/xf86drm.h:41:10: fatal error: drm.h: No such file or directory

[bugzilla-daemon]

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

--- Comment #2 from Fabio Pedretti  ---
@Eric Engestrom: any news on this build issue?

-- 
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 v4 24/40] intel/compiler: implement isign for int8

[Iago Toral]

We are now lowering isign in NIR so this patch is no longer needed.

Iago

On Tue, 2019-02-12 at 12:55 +0100, Iago Toral Quiroga wrote:
> Reviewed-by: Jason Ekstrand 
> ---
>  src/intel/compiler/brw_fs_nir.cpp | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index 3a6e4a2eb60..40c0481ac53 100644
> --- a/src/intel/compiler/brw_fs_nir.cpp
> +++ b/src/intel/compiler/brw_fs_nir.cpp
> @@ -906,11 +906,28 @@ fs_visitor::nir_emit_alu(const fs_builder &bld,
> nir_alu_instr *instr)
> *  Predicated OR sets 1 if val is positive.
> */
>uint32_t bit_size = nir_dest_bit_size(instr->dest.dest);
> -  assert(bit_size == 32 || bit_size == 16);
>  
> -  fs_reg zero = bit_size == 32 ? brw_imm_d(0) : brw_imm_w(0);
> -  fs_reg one = bit_size == 32 ? brw_imm_d(1) : brw_imm_w(1);
> -  fs_reg shift = bit_size == 32 ? brw_imm_d(31) : brw_imm_w(15);
> +  fs_reg zero, one, shift;
> +  switch (bit_size) {
> +  case 32:
> + zero = brw_imm_d(0);
> + one = brw_imm_d(1);
> + shift = brw_imm_d(31);
> + break;
> +  case 16:
> + zero = brw_imm_w(0);
> + one = brw_imm_w(1);
> + shift = brw_imm_w(15);
> + break;
> +  case 8: {
> + zero = setup_imm_b(bld, 0);
> + one = setup_imm_b(bld, 1);
> + shift = setup_imm_b(bld, 7);
> + break;
> +  }
> +  default:
> + unreachable("unsupported bit-size");
> +  };
>  
>bld.CMP(bld.null_reg_d(), op[0], zero, BRW_CONDITIONAL_G);
>bld.ASR(result, op[0], shift);

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