[Mesa-dev] [Bug 109446] Shadow of the Tomb Raider Trial freezes the system at startup
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
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
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
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(&screen->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(&screen->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(&screen->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(&screen->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(st
Re: [Mesa-dev] [PATCH] nir: allow stitching of non-empty block
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(&after->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'
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
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
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 &bld, 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.
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
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(&after->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.
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.
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.
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
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'
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.
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
