[Mesa-dev] [Bug 109446] Shadow of the Tomb Raider Trial freezes the system at startup

2019-01-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109446

--- Comment #1 from fin4...@hotmail.com ---
I tested with a clean wine prefix, dxvk 0.96 and I  have the  same problem.
When starting the game, I have the following lines in the virtual terminal:

[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
[drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
...

-- 
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 0/4] Common KMS renderonly support

2019-01-26 Thread Qiang Yu
Sorry, I missed this part of change and thought there's only
kmsro_dri.so. Then there's no concern on my side.

Thanks,
Qiang

Rob Herring  于 2019年1月27日周日 上午3:43写道:

> On Fri, Jan 25, 2019 at 9:00 PM Qiang Yu  wrote:
> >
> > Thanks Rob, I'm OK with this kmsro approach.
> >
> > But I have to point out that this will break XServer AIGLX:
> > 1. modesetting DDX will report the display drm driver name like meson
> >   as DRI2 driver name
> > 2. libglx.so used by xserver will look after meson_dri.so for dlopen
> > 3. then dlsym __driDriverGetExtensions_meson for init
>
> 2 and 3 are now the only things you have to add to add a platform. Now
> it is a 2 line patch to add a platform. Specifically what you have to
> add are shown in the lima branch I sent you.
>
> Rob
>
___
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

2019-01-26 Thread Rob Herring
On Fri, Jan 25, 2019 at 9:00 PM Qiang Yu  wrote:
>
> Thanks Rob, I'm OK with this kmsro approach.
>
> But I have to point out that this will break XServer AIGLX:
> 1. modesetting DDX will report the display drm driver name like meson
>   as DRI2 driver name
> 2. libglx.so used by xserver will look after meson_dri.so for dlopen
> 3. then dlsym __driDriverGetExtensions_meson for init

2 and 3 are now the only things you have to add to add a platform. Now
it is a 2 line patch to add a platform. Specifically what you have to
add are shown in the lima branch I sent you.

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


[Mesa-dev] [PATCH v2] nvc0: don't put text segment into bufctx

2019-01-26 Thread Ilia Mirkin
The text segment is shared among multiple contexts, while each one has
its own bufctx. So when reallocating the text segment, some contexts may
end up with stale values in their bufctx's. Instead limit the exposure
to the bufctx to within a single draw.

Signed-off-by: Ilia Mirkin 
---

v2: actually compiles, not sure how I managed to screw it up. also
bumped the push space reservations because PUSH_SPACE actually inserts
an extra buffer itself.

 src/gallium/drivers/nouveau/nvc0/nvc0_compute.c |  5 -
 src/gallium/drivers/nouveau/nvc0/nvc0_context.c |  2 --
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c | 10 --
 src/gallium/drivers/nouveau/nvc0/nvc0_surface.c |  4 
 src/gallium/drivers/nouveau/nvc0/nvc0_vbo.c |  5 +
 src/gallium/drivers/nouveau/nvc0/nve4_compute.c |  3 +++
 6 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
index 4963493877b..28e16367326 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_compute.c
@@ -423,6 +423,7 @@ void
 nvc0_launch_grid(struct pipe_context *pipe, const struct pipe_grid_info *info)
 {
struct nvc0_context *nvc0 = nvc0_context(pipe);
+   struct nvc0_screen *screen = nvc0->screen;
struct nouveau_pushbuf *push = nvc0->base.pushbuf;
struct nvc0_program *cp = nvc0->compprog;
int ret;
@@ -463,12 +464,14 @@ nvc0_launch_grid(struct pipe_context *pipe, const struct 
pipe_grid_info *info)
PUSH_DATA (push, (info->block[1] << 16) | info->block[0]);
PUSH_DATA (push, info->block[2]);
 
+   nouveau_pushbuf_space(push, 32, 2, 1);
+   PUSH_REFN(push, screen->text, NV_VRAM_DOMAIN(>base) | 
NOUVEAU_BO_RD);
+
if (unlikely(info->indirect)) {
   struct nv04_resource *res = nv04_resource(info->indirect);
   uint32_t offset = res->offset + info->indirect_offset;
   unsigned macro = NVC0_CP_MACRO_LAUNCH_GRID_INDIRECT;
 
-  nouveau_pushbuf_space(push, 16, 0, 1);
   PUSH_REFN(push, res->bo, NOUVEAU_BO_RD | res->domain);
   PUSH_DATA(push, NVC0_FIFO_PKHDR_1I(1, macro, 3));
   nouveau_pushbuf_data(push, res->bo, offset,
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
index 08ca0a204d3..356016c7225 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_context.c
@@ -449,11 +449,9 @@ nvc0_create(struct pipe_screen *pscreen, void *priv, 
unsigned ctxflags)
 
flags = NV_VRAM_DOMAIN(>base) | NOUVEAU_BO_RD;
 
-   BCTX_REFN_bo(nvc0->bufctx_3d, 3D_TEXT, flags, screen->text);
BCTX_REFN_bo(nvc0->bufctx_3d, 3D_SCREEN, flags, screen->uniform_bo);
BCTX_REFN_bo(nvc0->bufctx_3d, 3D_SCREEN, flags, screen->txc);
if (screen->compute) {
-  BCTX_REFN_bo(nvc0->bufctx_cp, CP_TEXT, flags, screen->text);
   BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->uniform_bo);
   BCTX_REFN_bo(nvc0->bufctx_cp, CP_SCREEN, flags, screen->txc);
}
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index 57d98753f45..1bbfa4a9428 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -831,16 +831,6 @@ nvc0_program_upload(struct nvc0_context *nvc0, struct 
nvc0_program *prog)
 NOUVEAU_ERR("Error allocating TEXT area: %d\n", ret);
 return false;
  }
- nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEXT);
- BCTX_REFN_bo(nvc0->bufctx_3d, 3D_TEXT,
-  NV_VRAM_DOMAIN(>base) | NOUVEAU_BO_RD,
-  screen->text);
- if (screen->compute) {
-nouveau_bufctx_reset(nvc0->bufctx_cp, NVC0_BIND_CP_TEXT);
-BCTX_REFN_bo(nvc0->bufctx_cp, CP_TEXT,
- NV_VRAM_DOMAIN(>base) | NOUVEAU_BO_RD,
- screen->text);
- }
 
  /* Re-upload the builtin function into the new code segment. */
  nvc0_program_library_upload(nvc0);
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index ccfe7ffb18b..e5311ab6ee0 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
@@ -1178,6 +1178,7 @@ nvc0_blitctx_post_blit(struct nvc0_blitctx *blit)
nvc0->cond_cond, nvc0->cond_mode);
 
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_VTX_TMP);
+   nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEXT);
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_FB);
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEX(4, 0));
nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_3D_TEX(4, 1));
@@ -1200,6 +1201,7 @@ nvc0_blitctx_post_blit(struct nvc0_blitctx *blit)
 static void
 nvc0_blit_3d(struct nvc0_context *nvc0, const 

Re: [Mesa-dev] [PATCH] nir: allow stitching of non-empty block

2019-01-26 Thread Jason Ekstrand

This makes me a bit nervous. I'll have to look at it in more detail.

On January 25, 2019 09:37:52 "Juan A. Suarez Romero"  
wrote:



When stitching two blocks A and B, where A's last instruction is a jump,
it is not required that B is empty; it can be plainly removed.

This can happen in a situation like this:

vec1 1 ssa_1 = load_const (true)
vec1 1 ssa_2 = load_const (false)
block block_1:
[...]
loop {
 vec1 ssa_3 = phi block_1: ssa_2, block_4: ssa_1
 if ssa_3 {
   block block_2:
   [...]
   break
 } else {
   block block_3:
 }
 vec1 ssa_4 = 
 if ssa_4 {
   block block_4:
   continue
 } else {
   block block_5:
 }
 block block_6:
 [...]
}

And opt_peel_loop_initial_if is applied. In this case, we would be
ending up stitching block_2 (which finalizes with a jump) with
block_4, which is not empty.

CC: Jason Ekstrand 
---
src/compiler/nir/nir_control_flow.c | 1 -
1 file changed, 1 deletion(-)

diff --git a/src/compiler/nir/nir_control_flow.c 
b/src/compiler/nir/nir_control_flow.c

index ddba2e55b45..27508f230d6 100644
--- a/src/compiler/nir/nir_control_flow.c
+++ b/src/compiler/nir/nir_control_flow.c
@@ -550,7 +550,6 @@ stitch_blocks(nir_block *before, nir_block *after)
*/

   if (nir_block_ends_in_jump(before)) {
-  assert(exec_list_is_empty(>instr_list));
  if (after->successors[0])
 remove_phi_src(after->successors[0], after);
  if (after->successors[1])
--
2.20.1




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


Re: [Mesa-dev] [RFC 1/4] nir: Add a new intrinsic 'load_image_stride'

2019-01-26 Thread Jason Ekstrand
Mind suffixing it with _ir3 or something since it's a back-end-specific 
intrinsic?  Incidentally, this looks a lot like load_image_param_intel.


On January 25, 2019 07:48:54 Eduardo Lima Mitev  wrote:


This is an internal intrinsic intended to be injected by a
(freedreno-specific) 'lower_sampler_io' pass that will be introduced
later in this series; and consumed by ir3_compiler_nir.

The intrinsic will load in SSA values for various constants
for images (image_dims), namely the format's bytes-per-pixel,
y-stride and z-stride; for which the backend compiler will emit
the corresponding uniforms.

const_index[0] is the image index, and const_index[1] is the index
into image_dims' register file for a given image: 0 for bpp, 1 to
y-stride and 2 for z-stride.
---
src/compiler/nir/nir_intrinsics.py | 2 ++
1 file changed, 2 insertions(+)

diff --git a/src/compiler/nir/nir_intrinsics.py 
b/src/compiler/nir/nir_intrinsics.py

index a5cc3f7401c..169c835d746 100644
--- a/src/compiler/nir/nir_intrinsics.py
+++ b/src/compiler/nir/nir_intrinsics.py
@@ -590,6 +590,8 @@ load("shared", 1, [BASE, ALIGN_MUL, ALIGN_OFFSET], 
[CAN_ELIMINATE])

load("push_constant", 1, [BASE, RANGE], [CAN_ELIMINATE, CAN_REORDER])
# src[] = { offset }. const_index[] = { base, range }
load("constant", 1, [BASE, RANGE], [CAN_ELIMINATE, CAN_REORDER])
+# src[] = { offset }. const_index[] = { image_idx, dim_idx }
+load("image_stride", 1, [], [CAN_REORDER])

# Stores work the same way as loads, except now the first source is the value
# to store and the second (and possibly third) source specify where to store
--
2.20.1

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




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


[Mesa-dev] [Bug 77449] Tracker bug for all bugs related to Steam titles

2019-01-26 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=77449

Kai  changed:

   What|Removed |Added

 Depends on||109461


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109461
[Bug 109461] [amdgpu/radeonsi,HAWAII] Hand of Fate 2 leads to GPU lock up
(display powered off, SSH works, keyboard dead): "flip_done timed out"
-- 
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] intel/fs: Fix memory corruption when compiling a CS

2019-01-26 Thread Oscar Blumberg
Missing check for shader stage in the fs_visitor would corrupt the
cs_prog_data.push information and trigger crashes / corruption later
when uploading the CS state.
---
 src/intel/compiler/brw_fs_nir.cpp | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/intel/compiler/brw_fs_nir.cpp 
b/src/intel/compiler/brw_fs_nir.cpp
index bdc883e53..21b03a089 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -3779,8 +3779,9 @@ fs_visitor::nir_emit_intrinsic(const fs_builder , 
nir_intrinsic_instr *instr
  BRW_REGISTER_TYPE_UD);
   const fs_reg data = retype(get_nir_src(instr->src[2]),
  BRW_REGISTER_TYPE_UD);
-
-  brw_wm_prog_data(prog_data)->has_side_effects = true;
+  
+  if (stage == MESA_SHADER_FRAGMENT)
+ brw_wm_prog_data(prog_data)->has_side_effects = true;
 
   emit_untyped_write(bld, image, addr, data, 1,
  instr->num_components);
-- 
2.20.1

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


Re: [Mesa-dev] [PATCH 3/8] i965: Faking the ETC2 compression on Gen < 8 GPUs using two miptrees.

2019-01-26 Thread Eleni Maria Stea
Hi Nanley,

On Fri, 18 Jan 2019 15:32:02 -0800
Nanley Chery  wrote:


> > diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c index
> > e214fae140..4d1eafac91 100644 ---
> > a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c +++
> > b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c @@ -329,6
[...]

> > @@ -474,6 +485,11 @@ static void brw_update_texture_surface(struct
> > gl_context *ctx, struct intel_texture_object *intel_obj =
> > intel_texture_object(obj); struct intel_mipmap_tree *mt =
> > intel_obj->mt; 
> > +  if (mt->needs_fake_etc) {
> > + assert(mt->shadow_mt);
> > + mt = mt->shadow_mt;
> > +  }
> > +
> >if (plane > 0) {
> >   if (mt->plane[plane - 1] == NULL)
> >  return;
> > @@ -512,7 +528,7 @@ static void brw_update_texture_surface(struct
> > gl_context *ctx,
> >* is safe because texture views aren't allowed on
> > depth/stencil. */
> >   mesa_fmt = mt->format;
> > -  } else if (mt->etc_format != MESA_FORMAT_NONE) {
> > +  } else if (intel_obj->mt->etc_format != MESA_FORMAT_NONE) {
> >   mesa_fmt = mt->format;  
> 
> For uniformity, lets access mt->shadow_mt->format here and move the
> mt->needs_fake_etc check from above to below this condition:
> 
>   } else if (devinfo->gen <= 7 && mt->format ==
> MESA_FORMAT_S_UINT8) {

I'd like to ask you one more question on this change: if I do the check
for the fake etc later, the following code will run for the main
miptree that contains the compressed data and has ETC2 format:

> >if (plane > 0) {
> >   if (mt->plane[plane - 1] == NULL)
> >  return;
> > @@ -512,7 +528,7 @@ static void brw_update_texture_surface(struct
> > gl_context *ctx,
> >* is safe because texture views aren't allowed on
> > depth/stencil. */
> >   mesa_fmt = mt->format;

Wouldn't this be a problem?

Thank you in advance,
Eleni

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


Re: [Mesa-dev] [PATCH] nir: allow stitching of non-empty block

2019-01-26 Thread Caio Marcelo de Oliveira Filho
This patch is

Reviewed-by: Caio Marcelo de Oliveira Filho 


On Fri, Jan 25, 2019 at 06:37:33PM +0100, Juan A. Suarez Romero wrote:
> When stitching two blocks A and B, where A's last instruction is a jump,
> it is not required that B is empty; it can be plainly removed.
> 
> This can happen in a situation like this:
> 
> vec1 1 ssa_1 = load_const (true)
> vec1 1 ssa_2 = load_const (false)
> block block_1:
> [...]
> loop {
>   vec1 ssa_3 = phi block_1: ssa_2, block_4: ssa_1
>   if ssa_3 {
> block block_2:
> [...]
> break
>   } else {
> block block_3:
>   }
>   vec1 ssa_4 = 
>   if ssa_4 {
> block block_4:
> continue
>   } else {
> block block_5:
>   }
>   block block_6:
>   [...]
> }
> 
> And opt_peel_loop_initial_if is applied. In this case, we would be
> ending up stitching block_2 (which finalizes with a jump) with
> block_4, which is not empty.
> 
> CC: Jason Ekstrand 
> ---
>  src/compiler/nir/nir_control_flow.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/src/compiler/nir/nir_control_flow.c 
> b/src/compiler/nir/nir_control_flow.c
> index ddba2e55b45..27508f230d6 100644
> --- a/src/compiler/nir/nir_control_flow.c
> +++ b/src/compiler/nir/nir_control_flow.c
> @@ -550,7 +550,6 @@ stitch_blocks(nir_block *before, nir_block *after)
>  */
>  
> if (nir_block_ends_in_jump(before)) {
> -  assert(exec_list_is_empty(>instr_list));
>if (after->successors[0])
>   remove_phi_src(after->successors[0], after);
>if (after->successors[1])
> -- 
> 2.20.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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


Re: [Mesa-dev] [PATCH] meson: Fix typo.

2019-01-26 Thread Eric Engestrom
On Saturday, 2019-01-26 00:50:40 -0800, Caio Marcelo de Oliveira Filho wrote:
> This patch is
> 
> Reviewed-by: Caio Marcelo de Oliveira Filho 
> 
> Since it fixes a patch that were marked for stable, maybe add CC:
> stable for this one too?

`Fixes:` already means it will be applied everywhere the fixed commit
has been ported.
That said, duplicating the information with a `cc: stable` shouldn't
hurt :)

> 
> On Sat, Jan 26, 2019 at 08:28:20AM +, Vinson Lee wrote:
> > meson.build:166:21: ERROR:  Unknown method "verson_compare" for a string.
> > 
> > Fixes: c1efa240c91e ("meson: Add warnings and errors when using ICC")
> > Signed-off-by: Vinson Lee 
> > ---
> >  meson.build | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meson.build b/meson.build
> > index 2d730708d067..287d9e0eed2b 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -163,9 +163,9 @@ with_gallium_virgl = _drivers.contains('virgl')
> >  with_gallium_swr = _drivers.contains('swr')
> >  
> >  if cc.get_id() == 'intel'
> > -  if meson.version().verson_compare('< 0.49.0')
> > +  if meson.version().version_compare('< 0.49.0')
> >  error('Meson does not have sufficient support of ICC before 0.49.0 to 
> > compile mesa')
> > -  elif with_gallium_swr and meson.version().verson_compare('== 0.49.0')
> > +  elif with_gallium_swr and meson.version().version_compare('== 0.49.0')
> >  warning('Meson as of 0.49.0 is sufficient for compiling mesa with ICC, 
> > but there are some caveats with SWR. 0.49.1 should resolve all of these')
> >endif
> >  endif
> > -- 
> > 2.20.1
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> 
>   Caio
> ___
> 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] meson: Fix typo.

2019-01-26 Thread Eric Engestrom
On Saturday, 2019-01-26 08:28:20 +, Vinson Lee wrote:
> meson.build:166:21: ERROR:  Unknown method "verson_compare" for a string.

Oops, thanks for the patch.
Reviewed-by: Eric Engestrom 

> 
> Fixes: c1efa240c91e ("meson: Add warnings and errors when using ICC")
> Signed-off-by: Vinson Lee 
> ---
>  meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 2d730708d067..287d9e0eed2b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -163,9 +163,9 @@ with_gallium_virgl = _drivers.contains('virgl')
>  with_gallium_swr = _drivers.contains('swr')
>  
>  if cc.get_id() == 'intel'
> -  if meson.version().verson_compare('< 0.49.0')
> +  if meson.version().version_compare('< 0.49.0')
>  error('Meson does not have sufficient support of ICC before 0.49.0 to 
> compile mesa')
> -  elif with_gallium_swr and meson.version().verson_compare('== 0.49.0')
> +  elif with_gallium_swr and meson.version().version_compare('== 0.49.0')
>  warning('Meson as of 0.49.0 is sufficient for compiling mesa with ICC, 
> but there are some caveats with SWR. 0.49.1 should resolve all of these')
>endif
>  endif
> -- 
> 2.20.1
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] meson: Fix typo.

2019-01-26 Thread Caio Marcelo de Oliveira Filho
This patch is

Reviewed-by: Caio Marcelo de Oliveira Filho 

Since it fixes a patch that were marked for stable, maybe add CC:
stable for this one too?

On Sat, Jan 26, 2019 at 08:28:20AM +, Vinson Lee wrote:
> meson.build:166:21: ERROR:  Unknown method "verson_compare" for a string.
> 
> Fixes: c1efa240c91e ("meson: Add warnings and errors when using ICC")
> Signed-off-by: Vinson Lee 
> ---
>  meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 2d730708d067..287d9e0eed2b 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -163,9 +163,9 @@ with_gallium_virgl = _drivers.contains('virgl')
>  with_gallium_swr = _drivers.contains('swr')
>  
>  if cc.get_id() == 'intel'
> -  if meson.version().verson_compare('< 0.49.0')
> +  if meson.version().version_compare('< 0.49.0')
>  error('Meson does not have sufficient support of ICC before 0.49.0 to 
> compile mesa')
> -  elif with_gallium_swr and meson.version().verson_compare('== 0.49.0')
> +  elif with_gallium_swr and meson.version().version_compare('== 0.49.0')
>  warning('Meson as of 0.49.0 is sufficient for compiling mesa with ICC, 
> but there are some caveats with SWR. 0.49.1 should resolve all of these')
>endif
>  endif
> -- 
> 2.20.1
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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


Re: [Mesa-dev] [RFC 2/4] nir: Add a new ALU nir_op_imad

2019-01-26 Thread Eduardo Lima Mitev
On 1/25/19 6:46 PM, Eric Anholt wrote:
> Eduardo Lima Mitev  writes:
> 
>> ir3 compiler has an integer multiply-add instruction (IMAD_S24)
>> that is used for different offset calculations in the backend.
>> Since we intend to move some of these calculations to NIR, we need
>> a new ALU op that can represent it.
>> ---
>>  src/compiler/nir/nir_opcodes.py | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/src/compiler/nir/nir_opcodes.py 
>> b/src/compiler/nir/nir_opcodes.py
>> index d32005846a6..b61845fd514 100644
>> --- a/src/compiler/nir/nir_opcodes.py
>> +++ b/src/compiler/nir/nir_opcodes.py
>> @@ -754,6 +754,7 @@ def triop_horiz(name, output_size, src1_size, src2_size, 
>> src3_size, const_expr):
>> [tuint, tuint, tuint], "", const_expr)
>>  
>>  triop("ffma", tfloat, "src0 * src1 + src2")
>> +triop("imad", tint, "src0 * src1 + src2")
> 
> The constant-folding expression should be corrected to what the backend
> operation actually does, and you should probably call it imad24 or
> something in that case.
> 

Roger. Got similar feedback from Ilia. Will fix that.

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


Re: [Mesa-dev] [RFC 1/4] nir: Add a new intrinsic 'load_image_stride'

2019-01-26 Thread Eduardo Lima Mitev
On 1/25/19 6:42 PM, Eric Anholt wrote:
> Eduardo Lima Mitev  writes:
> 
>> This is an internal intrinsic intended to be injected by a
>> (freedreno-specific) 'lower_sampler_io' pass that will be introduced
>> later in this series; and consumed by ir3_compiler_nir.
>>
>> The intrinsic will load in SSA values for various constants
>> for images (image_dims), namely the format's bytes-per-pixel,
>> y-stride and z-stride; for which the backend compiler will emit
>> the corresponding uniforms.
>>
>> const_index[0] is the image index, and const_index[1] is the index
>> into image_dims' register file for a given image: 0 for bpp, 1 to
>> y-stride and 2 for z-stride.
> 
> Can you move this documentation of the meaning of the intrinsic into a
> comment in the file?
> 

Yes, will do that.
Thanks!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] meson: Fix typo.

2019-01-26 Thread Vinson Lee
meson.build:166:21: ERROR:  Unknown method "verson_compare" for a string.

Fixes: c1efa240c91e ("meson: Add warnings and errors when using ICC")
Signed-off-by: Vinson Lee 
---
 meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 2d730708d067..287d9e0eed2b 100644
--- a/meson.build
+++ b/meson.build
@@ -163,9 +163,9 @@ with_gallium_virgl = _drivers.contains('virgl')
 with_gallium_swr = _drivers.contains('swr')
 
 if cc.get_id() == 'intel'
-  if meson.version().verson_compare('< 0.49.0')
+  if meson.version().version_compare('< 0.49.0')
 error('Meson does not have sufficient support of ICC before 0.49.0 to 
compile mesa')
-  elif with_gallium_swr and meson.version().verson_compare('== 0.49.0')
+  elif with_gallium_swr and meson.version().version_compare('== 0.49.0')
 warning('Meson as of 0.49.0 is sufficient for compiling mesa with ICC, but 
there are some caveats with SWR. 0.49.1 should resolve all of these')
   endif
 endif
-- 
2.20.1

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