[Mesa-dev] [Bug 108841] [RADV] SPIRV's control flow attributes do not propagate to LLVM

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108841

--- Comment #4 from Timothy Arceri  ---
I've created a merge request [1] that implements the spirv control masks.

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

-- 
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] softpipe: fix texture view crashes

2019-03-19 Thread Dave Airlie
From: Dave Airlie 

I noticed we crashed piglit arb_texture_view-rendering-formats
when run on softpipe.

This fixes the clear tiles to use the surface format not the
underlying storage format.

This fixes a bunch of srgb piglits as well.
---
 src/gallium/drivers/softpipe/sp_tile_cache.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/softpipe/sp_tile_cache.c 
b/src/gallium/drivers/softpipe/sp_tile_cache.c
index 351736ee421..998939bdf30 100644
--- a/src/gallium/drivers/softpipe/sp_tile_cache.c
+++ b/src/gallium/drivers/softpipe/sp_tile_cache.c
@@ -373,17 +373,18 @@ sp_tile_cache_flush_clear(struct softpipe_tile_cache *tc, 
int layer)
if (util_format_is_pure_uint(tc->surface->format)) {
   pipe_put_tile_ui_format(pt, tc->transfer_map[layer],
   x, y, TILE_SIZE, TILE_SIZE,
-  pt->resource->format,
+  tc->surface->format,
   (unsigned *) 
tc->tile->data.colorui128);
} else if (util_format_is_pure_sint(tc->surface->format)) {
   pipe_put_tile_i_format(pt, tc->transfer_map[layer],
  x, y, TILE_SIZE, TILE_SIZE,
- pt->resource->format,
+ tc->surface->format,
  (int *) tc->tile->data.colori128);
} else {
-  pipe_put_tile_rgba(pt, tc->transfer_map[layer],
- x, y, TILE_SIZE, TILE_SIZE,
- (float *) tc->tile->data.color);
+  pipe_put_tile_rgba_format(pt, tc->transfer_map[layer],
+x, y, TILE_SIZE, TILE_SIZE,
+tc->surface->format,
+(float *) tc->tile->data.color);
}
 }
 numCleared++;
-- 
2.20.1

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

[Mesa-dev] [Bug 108841] [RADV] SPIRV's control flow attributes do not propagate to LLVM

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108841

--- Comment #3 from Timothy Arceri  ---
(In reply to Alex Smith from comment #1)
> I'd also like to see these implemented. AMDVLK supports them and we've had
> several cases where we've been able to get significant performance
> improvements on complex shaders with that driver by manually forcing some
> loops to be unrolled or not unrolled.

Are you able to provide examples of the games you uses these masks in? I'd like
to be able to confirm if the same setting provide a boost/regression in RADV vs
not supporting them.

-- 
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 108841] [RADV] SPIRV's control flow attributes do not propagate to LLVM

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108841

--- Comment #2 from Timothy Arceri  ---
I'll take a look at this it should hopefully not be too difficult.

-- 
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 5/8] ac/nir: implement 8-bit ssbo stores

2019-03-19 Thread Bas Nieuwenhuizen
On Tue, Mar 19, 2019 at 9:28 AM Samuel Pitoiset
 wrote:
>
> From: Rhys Perry 
>
> Signed-off-by: Rhys Perry 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 34c4e2a69fa..f3e8f89ba9b 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1553,7 +1553,7 @@ static void visit_store_ssbo(struct ac_nir_context *ctx,
>
> LLVMValueRef rsrc = ctx->abi->load_ssbo(ctx->abi,
> get_src(ctx, instr->src[1]), true);
> -   LLVMValueRef base_data = ac_to_float(>ac, src_data);
> +   LLVMValueRef base_data = src_data;

Does this work with LLVM 7? (I have vague recollection that the
earlier intrinsics only did floats).

> base_data = ac_trim_vector(>ac, base_data, 
> instr->num_components);
> LLVMValueRef base_offset = get_src(ctx, instr->src[2]);
>
> @@ -1591,7 +1591,12 @@ static void visit_store_ssbo(struct ac_nir_context 
> *ctx,
> offset = LLVMBuildAdd(ctx->ac.builder, base_offset,
>   LLVMConstInt(ctx->ac.i32, start * 
> elem_size_bytes, false), "");
>
> -   if (num_bytes == 2) {
> +   if (num_bytes == 1) {
> +   ac_build_tbuffer_store_byte(>ac, rsrc, data,
> +   offset, ctx->ac.i32_0,
> +   cache_policy & ac_glc,
> +   writeonly_memory);
> +   } else if (num_bytes == 2) {
> ac_build_tbuffer_store_short(>ac, rsrc, data,
>  offset, ctx->ac.i32_0,
>  cache_policy & ac_glc,
> --
> 2.21.0
>
> ___
> 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] ac: use llvm.amdgcn.fract intrinsic for nir_op_ffract

2019-03-19 Thread Bas Nieuwenhuizen
r-b

On Tue, Mar 19, 2019 at 11:37 PM Samuel Pitoiset
 wrote:
>
> Noticed with a Doom shader.
>
> 29077 shaders in 15096 tests
> Totals:
> SGPRS: 1282125 -> 1282133 (0.00 %)
> VGPRS: 908716 -> 908616 (-0.01 %)
> Spilled SGPRs: 24811 -> 24779 (-0.13 %)
> Code Size: 49048176 -> 48936488 (-0.23 %) bytes
> Max Waves: 244232 -> 244226 (-0.00 %)
>
> Totals from affected shaders:
> SGPRS: 229584 -> 229592 (0.00 %)
> VGPRS: 163268 -> 163168 (-0.06 %)
> Spilled SGPRs: 8682 -> 8650 (-0.37 %)
> Code Size: 12819572 -> 12707884 (-0.87 %) bytes
> Max Waves: 24398 -> 24392 (-0.02 %)
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_llvm_build.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index 0cab4d4a9b5..9cf1c6f8792 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -2155,19 +2155,18 @@ LLVMValueRef ac_build_fract(struct ac_llvm_context 
> *ctx, LLVMValueRef src0,
> char *intr;
>
> if (bitsize == 32) {
> -   intr = "llvm.floor.f32";
> +   intr = "llvm.amdgcn.fract.f32";
> type = ctx->f32;
> } else {
> -   intr = "llvm.floor.f64";
> +   intr = "llvm.amdgcn.fract.f64";
> type = ctx->f64;
> }
>
> LLVMValueRef params[] = {
> src0,
> };
> -   LLVMValueRef floor = ac_build_intrinsic(ctx, intr, type, params, 1,
> -   AC_FUNC_ATTR_READNONE);
> -   return LLVMBuildFSub(ctx->builder, src0, floor, "");
> +   return ac_build_intrinsic(ctx, intr, type, params, 1,
> + AC_FUNC_ATTR_READNONE);
>  }
>
>  LLVMValueRef ac_build_isign(struct ac_llvm_context *ctx, LLVMValueRef src0,
> --
> 2.21.0
>
> ___
> 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] ac: use llvm.amdgcn.fract intrinsic for nir_op_ffract

2019-03-19 Thread Samuel Pitoiset
Noticed with a Doom shader.

29077 shaders in 15096 tests
Totals:
SGPRS: 1282125 -> 1282133 (0.00 %)
VGPRS: 908716 -> 908616 (-0.01 %)
Spilled SGPRs: 24811 -> 24779 (-0.13 %)
Code Size: 49048176 -> 48936488 (-0.23 %) bytes
Max Waves: 244232 -> 244226 (-0.00 %)

Totals from affected shaders:
SGPRS: 229584 -> 229592 (0.00 %)
VGPRS: 163268 -> 163168 (-0.06 %)
Spilled SGPRs: 8682 -> 8650 (-0.37 %)
Code Size: 12819572 -> 12707884 (-0.87 %) bytes
Max Waves: 24398 -> 24392 (-0.02 %)

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 0cab4d4a9b5..9cf1c6f8792 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -2155,19 +2155,18 @@ LLVMValueRef ac_build_fract(struct ac_llvm_context 
*ctx, LLVMValueRef src0,
char *intr;
 
if (bitsize == 32) {
-   intr = "llvm.floor.f32";
+   intr = "llvm.amdgcn.fract.f32";
type = ctx->f32;
} else {
-   intr = "llvm.floor.f64";
+   intr = "llvm.amdgcn.fract.f64";
type = ctx->f64;
}
 
LLVMValueRef params[] = {
src0,
};
-   LLVMValueRef floor = ac_build_intrinsic(ctx, intr, type, params, 1,
-   AC_FUNC_ATTR_READNONE);
-   return LLVMBuildFSub(ctx->builder, src0, floor, "");
+   return ac_build_intrinsic(ctx, intr, type, params, 1,
+ AC_FUNC_ATTR_READNONE);
 }
 
 LLVMValueRef ac_build_isign(struct ac_llvm_context *ctx, LLVMValueRef src0,
-- 
2.21.0

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

[Mesa-dev] [Bug 109929] tgsi_to_nir.c:2111: undefined reference to `gl_nir_lower_samplers_as_deref'

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109929

--- Comment #9 from Vinson Lee  ---
(In reply to Timur Kristóf from comment #8)
> Can you tell me how to build libxatracker.la? Ie. what autotools command to
> use? Thanks!

./autogen.sh --enable-autotools --enable-opencl --with-dri-drivers=
--with-gallium-drivers=freedreno --enable-xa

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

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

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108620

Vladislav Kamenev  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #5 from Vladislav Kamenev  ---
Glitches went away with bios update.

-- 
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 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109560

--- Comment #3 from Strangiato  ---
dmesg shows no error.

-- 
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 v3 11/11] ac: use new LLVM 8 intrinsics in ac_build_buffer_store_dword()

2019-03-19 Thread Bas Nieuwenhuizen
Reviewed-by: Bas Nieuwenhuizen 

FYI since the new intrinsics don't merge voffset and soffset anymore,
you can remove the tbuffer variants for LLVM8+.

On Wed, Mar 13, 2019 at 5:38 PM Samuel Pitoiset
 wrote:
>
> New buffer intrinsics have a separate soffset parameter.
>
> v3: - use ac_build_raw_tbuffer_store()
> v2: - use the raw version as vindex is not used
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_llvm_build.c | 66 ++
>  1 file changed, 26 insertions(+), 40 deletions(-)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
> index c86a4f98864..541ad75c877 100644
> --- a/src/amd/common/ac_llvm_build.c
> +++ b/src/amd/common/ac_llvm_build.c
> @@ -1227,59 +1227,45 @@ ac_build_buffer_store_dword(struct ac_llvm_context 
> *ctx,
> if (!swizzle_enable_hint) {
> LLVMValueRef offset = soffset;
>
> -   static const char *types[] = {"f32", "v2f32", "v4f32"};
> -
> if (inst_offset)
> offset = LLVMBuildAdd(ctx->builder, offset,
>   LLVMConstInt(ctx->i32, 
> inst_offset, 0), "");
> -   if (voffset)
> -   offset = LLVMBuildAdd(ctx->builder, offset, voffset, 
> "");
> -
> -   LLVMValueRef args[] = {
> -   ac_to_float(ctx, vdata),
> -   LLVMBuildBitCast(ctx->builder, rsrc, ctx->v4i32, ""),
> -   ctx->i32_0,
> -   offset,
> -   LLVMConstInt(ctx->i1, glc, 0),
> -   LLVMConstInt(ctx->i1, slc, 0),
> -   };
> -
> -   char name[256];
> -   snprintf(name, sizeof(name), "llvm.amdgcn.buffer.store.%s",
> -types[CLAMP(num_channels, 1, 3) - 1]);
>
> -   ac_build_intrinsic(ctx, name, ctx->voidt,
> -  args, ARRAY_SIZE(args),
> -  
> ac_get_store_intr_attribs(writeonly_memory));
> +   if (HAVE_LLVM >= 0x800) {
> +   ac_build_llvm8_buffer_store_common(ctx, rsrc,
> +  ac_to_float(ctx, 
> vdata),
> +  ctx->i32_0,
> +  voffset, offset,
> +  num_channels,
> +  glc, slc,
> +  writeonly_memory,
> +  false, false);
> +   } else {
> +   if (voffset)
> +   offset = LLVMBuildAdd(ctx->builder, offset, 
> voffset, "");
> +
> +   ac_build_buffer_store_common(ctx, rsrc,
> +ac_to_float(ctx, vdata),
> +ctx->i32_0, offset,
> +num_channels, glc, slc,
> +writeonly_memory, false);
> +   }
> return;
> }
>
> -   static const unsigned dfmt[] = {
> +   static const unsigned dfmts[] = {
> V_008F0C_BUF_DATA_FORMAT_32,
> V_008F0C_BUF_DATA_FORMAT_32_32,
> V_008F0C_BUF_DATA_FORMAT_32_32_32,
> V_008F0C_BUF_DATA_FORMAT_32_32_32_32
> };
> -   static const char *types[] = {"i32", "v2i32", "v4i32"};
> -   LLVMValueRef args[] = {
> -   vdata,
> -   LLVMBuildBitCast(ctx->builder, rsrc, ctx->v4i32, ""),
> -   ctx->i32_0,
> -   voffset ? voffset : ctx->i32_0,
> -   soffset,
> -   LLVMConstInt(ctx->i32, inst_offset, 0),
> -   LLVMConstInt(ctx->i32, dfmt[num_channels - 1], 0),
> -   LLVMConstInt(ctx->i32, V_008F0C_BUF_NUM_FORMAT_UINT, 0),
> -   LLVMConstInt(ctx->i1, glc, 0),
> -   LLVMConstInt(ctx->i1, slc, 0),
> -   };
> -   char name[256];
> -   snprintf(name, sizeof(name), "llvm.amdgcn.tbuffer.store.%s",
> -types[CLAMP(num_channels, 1, 3) - 1]);
> +   unsigned dfmt = dfmts[num_channels - 1];
> +   unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
> +   LLVMValueRef immoffset = LLVMConstInt(ctx->i32, inst_offset, 0);
>
> -   ac_build_intrinsic(ctx, name, ctx->voidt,
> -  args, ARRAY_SIZE(args),
> -  ac_get_store_intr_attribs(writeonly_memory));
> +   ac_build_raw_tbuffer_store(ctx, rsrc, vdata, voffset, soffset,
> +  immoffset, num_channels, dfmt, nfmt, glc,
> +  slc, writeonly_memory);
>  }

Re: [Mesa-dev] [PATCH v3 06/11] ac/nir: use ac_build_buffer_load() for SSBO load operations

2019-03-19 Thread Samuel Pitoiset


On 3/19/19 8:24 PM, Bas Nieuwenhuizen wrote:

On Wed, Mar 13, 2019 at 5:38 PM Samuel Pitoiset
 wrote:

Signed-off-by: Samuel Pitoiset 
---
  src/amd/common/ac_nir_to_llvm.c | 35 ++---
  1 file changed, 6 insertions(+), 29 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 7f63b506b93..949a7a74834 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1704,7 +1704,6 @@ static LLVMValueRef visit_load_buffer(struct 
ac_nir_context *ctx,
 int num_components = instr->num_components;
 enum gl_access_qualifier access = nir_intrinsic_access(instr);
 unsigned cache_policy = get_cache_policy(ctx, access, false, false);
-   LLVMValueRef glc = (cache_policy & ac_glc) ? ctx->ac.i1true : 
ctx->ac.i1false;

 LLVMValueRef offset = get_src(ctx, instr->src[1]);
 LLVMValueRef rsrc = ctx->abi->load_ssbo(ctx->abi,
@@ -1734,34 +1733,12 @@ static LLVMValueRef visit_load_buffer(struct 
ac_nir_context *ctx,
   immoffset,
   cache_policy & 
ac_glc);
 } else {
-   const char *load_name;
-   LLVMTypeRef data_type;
-   switch (load_bytes) {
-   case 16:
-   case 12:
-   load_name = "llvm.amdgcn.buffer.load.v4f32";
-   data_type = ctx->ac.v4f32;
-   break;
-   case 8:
-   case 6:
-   load_name = "llvm.amdgcn.buffer.load.v2f32";
-   data_type = ctx->ac.v2f32;
-   break;
-   case 4:
-   load_name = "llvm.amdgcn.buffer.load.f32";
-   data_type = ctx->ac.f32;
-   break;
-   default:
-   unreachable("Malformed load buffer.");
-   }
-   LLVMValueRef params[] = {
-   rsrc,
-   vindex,
-   LLVMBuildAdd(ctx->ac.builder, offset, immoffset, 
""),
-   glc,
-   ctx->ac.i1false,
-   };
-   ret = ac_build_intrinsic(>ac, load_name, 
data_type, params, 5, 0);
+   int num_channels = util_next_power_of_two(load_bytes) / 
4;
+
+   ret = ac_build_buffer_load(>ac, rsrc, num_channels,
+  vindex, offset, immoffset, 0,

immoffset is constant right? Why do we use soffset instead of
inst_offset? (Not blocking anything since pre-existing, just curious)

I don't know, but I assume that using inst_offset would work too.



+  cache_policy & ac_glc, false,
+  false, false);

Change the slc arg to 0? (since it  is unsigned)

Fixed locally.



 }

 LLVMTypeRef byte_vec = LLVMVectorType(ctx->ac.i8, 
ac_get_type_size(LLVMTypeOf(ret)));
--
2.21.0

___
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 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109560

--- Comment #2 from jam...@amd.com  ---
Can you add attachment of dmesg when issue occurred? Thanks! 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

Re: [Mesa-dev] Mesa (master): nir/spirv: handle kernel function parameters

2019-03-19 Thread Jason Ekstrand
There's a MR out to fix this:

https://gitlab.freedesktop.org/mesa/mesa/merge_requests/478/diffs

On Tue, Mar 19, 2019 at 5:32 AM Samuel Pitoiset 
wrote:

> This commit breaks some CTS with RADV (eg.
> dEQP-VK.ssbo.phys.layout.single_basic_type.std430.bvec2) and it
> introduces one compiler warning (minor stuff).
>
> Is the Rb tag missing too?
>
> Thanks!
>
> On 3/19/19 5:57 AM, GitLab Mirror wrote:
> > Module: Mesa
> > Branch: master
> > Commit: c95afe56a8033a87dca71cc93191d448c2981cf7
> > URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=c95afe56a8033a87dca71cc93191d448c2981cf7
> >
> > Author: Karol Herbst 
> > Date:   Tue Nov  6 12:06:08 2018 +0100
> >
> > nir/spirv: handle kernel function parameters
> >
> > the idea here is to generate an entry point stub function wrapping
> around the
> > actual kernel function and turn all parameters into shader inputs with
> byte
> > addressing instead of vec4.
> >
> > This gives us several advantages:
> > 1. calling kernel functions doesn't differ from calling any other
> function
> > 2. CL inputs match uniforms in most ways and we can just take advantage
> of most
> > of nir_lower_io
> >
> > v2: move code into a seperate function
> > v3: verify the entry point got a name
> >  fix minor typo
> > v4: make vtn_emit_kernel_entry_point_wrapper take the old entry point as
> an arg
> >
> > Signed-off-by: Karol Herbst 
> >
> > ---
> >
> >   src/compiler/spirv/spirv_to_nir.c | 66
> +++
> >   1 file changed, 66 insertions(+)
> >
> > diff --git a/src/compiler/spirv/spirv_to_nir.c
> b/src/compiler/spirv/spirv_to_nir.c
> > index 5becd3418da..df5bba2c2a0 100644
> > --- a/src/compiler/spirv/spirv_to_nir.c
> > +++ b/src/compiler/spirv/spirv_to_nir.c
> > @@ -4453,6 +4453,68 @@ vtn_create_builder(const uint32_t *words, size_t
> word_count,
> >  return NULL;
> >   }
> >
> > +static nir_function *
> > +vtn_emit_kernel_entry_point_wrapper(struct vtn_builder *b,
> > +const nir_function *entry_point)
> > +{
> > +   vtn_assert(entry_point == b->entry_point->func->impl->function);
> > +   vtn_fail_if(!entry_point->name, "entry points are required to have a
> name");
> > +   const char *func_name =
> > +  ralloc_asprintf(b->shader, "__wrapped_%s", entry_point->name);
> > +
> > +   /* we shouldn't have any inputs yet */
> > +   vtn_assert(!entry_point->shader->num_inputs);
> > +   vtn_assert(b->shader->info.stage == MESA_SHADER_KERNEL);
> > +
> > +   nir_function *main_entry_point = nir_function_create(b->shader,
> func_name);
> > +   main_entry_point->impl = nir_function_impl_create(main_entry_point);
> > +   nir_builder_init(>nb, main_entry_point->impl);
> > +   b->nb.cursor = nir_after_cf_list(_entry_point->impl->body);
> > +   b->func_param_idx = 0;
> > +
> > +   nir_call_instr *call = nir_call_instr_create(b->nb.shader,
> entry_point);
> > +
> > +   for (unsigned i = 0; i < entry_point->num_params; ++i) {
> > +  struct vtn_type *param_type =
> b->entry_point->func->type->params[i];
> > +
> > +  /* consider all pointers to function memory to be parameters
> passed
> > +   * by value
> > +   */
> > +  bool is_by_val = param_type->base_type == vtn_base_type_pointer &&
> > + param_type->storage_class == SpvStorageClassFunction;
> > +
> > +  /* input variable */
> > +  nir_variable *in_var = rzalloc(b->nb.shader, nir_variable);
> > +  in_var->data.mode = nir_var_shader_in;
> > +  in_var->data.read_only = true;
> > +  in_var->data.location = i;
> > +
> > +  if (is_by_val)
> > + in_var->type = param_type->deref->type;
> > +  else
> > + in_var->type = param_type->type;
> > +
> > +  nir_shader_add_variable(b->nb.shader, in_var);
> > +  b->nb.shader->num_inputs++;
> > +
> > +  /* we have to copy the entire variable into function memory */
> > +  if (is_by_val) {
> > + nir_variable *copy_var =
> > +nir_local_variable_create(main_entry_point->impl,
> in_var->type,
> > +  "copy_in");
> > + nir_copy_var(>nb, copy_var, in_var);
> > + call->params[i] =
> > +nir_src_for_ssa(_build_deref_var(>nb,
> copy_var)->dest.ssa);
> > +  } else {
> > + call->params[i] = nir_src_for_ssa(nir_load_var(>nb,
> in_var));
> > +  }
> > +   }
> > +
> > +   nir_builder_instr_insert(>nb, >instr);
> > +
> > +   return main_entry_point;
> > +}
> > +
> >   nir_function *
> >   spirv_to_nir(const uint32_t *words, size_t word_count,
> >struct nir_spirv_specialization *spec, unsigned num_spec,
> > @@ -4542,6 +4604,10 @@ spirv_to_nir(const uint32_t *words, size_t
> word_count,
> >  nir_function *entry_point = b->entry_point->func->impl->function;
> >  vtn_assert(entry_point);
> >
> > +   /* post process entry_points with input params */
> > +   if (entry_point->num_params && b->shader->info.stage ==
> MESA_SHADER_KERNEL)
> > + 

[Mesa-dev] [Bug 109560] Sometimes VLC player process gets stuck in memory after closure if video output used is Auto or OpenGL

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109560

Strangiato  changed:

   What|Removed |Added

Version|18.3|19.0

--- Comment #1 from Strangiato  ---
This bug persists on Arch Linux after upgrade to mesa 19.

-- 
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 110141] glesv1_cm.pc and glesv2.pc missing after b01524fff05eef66e8cd24f1c5aacefed4209f03

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110141

Parker Reed  changed:

   What|Removed |Added

 CC||parker.l.r...@gmail.com

-- 
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 v3 06/11] ac/nir: use ac_build_buffer_load() for SSBO load operations

2019-03-19 Thread Bas Nieuwenhuizen
On Wed, Mar 13, 2019 at 5:38 PM Samuel Pitoiset
 wrote:
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/common/ac_nir_to_llvm.c | 35 ++---
>  1 file changed, 6 insertions(+), 29 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 7f63b506b93..949a7a74834 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1704,7 +1704,6 @@ static LLVMValueRef visit_load_buffer(struct 
> ac_nir_context *ctx,
> int num_components = instr->num_components;
> enum gl_access_qualifier access = nir_intrinsic_access(instr);
> unsigned cache_policy = get_cache_policy(ctx, access, false, false);
> -   LLVMValueRef glc = (cache_policy & ac_glc) ? ctx->ac.i1true : 
> ctx->ac.i1false;
>
> LLVMValueRef offset = get_src(ctx, instr->src[1]);
> LLVMValueRef rsrc = ctx->abi->load_ssbo(ctx->abi,
> @@ -1734,34 +1733,12 @@ static LLVMValueRef visit_load_buffer(struct 
> ac_nir_context *ctx,
>   immoffset,
>   cache_policy & 
> ac_glc);
> } else {
> -   const char *load_name;
> -   LLVMTypeRef data_type;
> -   switch (load_bytes) {
> -   case 16:
> -   case 12:
> -   load_name = "llvm.amdgcn.buffer.load.v4f32";
> -   data_type = ctx->ac.v4f32;
> -   break;
> -   case 8:
> -   case 6:
> -   load_name = "llvm.amdgcn.buffer.load.v2f32";
> -   data_type = ctx->ac.v2f32;
> -   break;
> -   case 4:
> -   load_name = "llvm.amdgcn.buffer.load.f32";
> -   data_type = ctx->ac.f32;
> -   break;
> -   default:
> -   unreachable("Malformed load buffer.");
> -   }
> -   LLVMValueRef params[] = {
> -   rsrc,
> -   vindex,
> -   LLVMBuildAdd(ctx->ac.builder, offset, 
> immoffset, ""),
> -   glc,
> -   ctx->ac.i1false,
> -   };
> -   ret = ac_build_intrinsic(>ac, load_name, 
> data_type, params, 5, 0);
> +   int num_channels = util_next_power_of_two(load_bytes) 
> / 4;
> +
> +   ret = ac_build_buffer_load(>ac, rsrc, 
> num_channels,
> +  vindex, offset, immoffset, 
> 0,

immoffset is constant right? Why do we use soffset instead of
inst_offset? (Not blocking anything since pre-existing, just curious)

> +  cache_policy & ac_glc, 
> false,
> +  false, false);

Change the slc arg to 0? (since it  is unsigned)

> }
>
> LLVMTypeRef byte_vec = LLVMVectorType(ctx->ac.i8, 
> ac_get_type_size(LLVMTypeOf(ret)));
> --
> 2.21.0
>
> ___
> 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] nir: Constant values are per-column not per-component

2019-03-19 Thread Jason Ekstrand
---
 src/compiler/nir/nir.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 67304af1d64..e4f012809e5 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -59,6 +59,7 @@ extern "C" {
 #define NIR_FALSE 0u
 #define NIR_TRUE (~0u)
 #define NIR_MAX_VEC_COMPONENTS 4
+#define NIR_MAX_MATRIX_COLUMNS 4
 typedef uint8_t nir_component_mask_t;
 
 /** Defines a cast function
@@ -141,7 +142,7 @@ typedef struct nir_constant {
 * by the type associated with the \c nir_variable.  Constants may be
 * scalars, vectors, or matrices.
 */
-   nir_const_value values[NIR_MAX_VEC_COMPONENTS];
+   nir_const_value values[NIR_MAX_MATRIX_COLUMNS];
 
/* we could get this from the var->type but makes clone *much* easier to
 * not have to care about the type.
-- 
2.20.1

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

[Mesa-dev] [Bug 109393] [vega10] hang with Mario Party 9 through Dolphin

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109393

--- Comment #18 from Samuel Pitoiset  ---
Thanks for confirming. Feel free to re-open if needed, hopefully not. :)

-- 
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 110116] Neverball particles are broken (GL_POINT_SPRITE)

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110116

--- Comment #9 from QwertyChouskie  ---
Created attachment 143734
  --> https://bugs.freedesktop.org/attachment.cgi?id=143734=edit
apitrace from self-compiled Neverball 1.6.0

I seem to be unable to reproduce the issue using Neverball master or self-built
0.6.0 thus far.  I wondered if this is not a GL issue, but a loading of assets
issue, so I compiled as normal, then overwrote the generated binary with the
one from the installed package.  The squares showed up, so it's definitely
linked to that specific binary somehow.

It may be an issue with the package being compiled for older libraries, and
having trouble with operating with the newer libraries, or alternatively, the
compiler version may affect things.

Attached is an apitrace with my self-built 1.6.0 for comparison.  Maybe someone
can compare the two and see what the difference is.

-- 
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] anv: Bump maxComputeWorkgroupInvocations

2019-03-19 Thread Lionel Landwerlin

Reviewed-by: Lionel Landwerlin 

On 19/03/2019 17:08, Jason Ekstrand wrote:

We initially set this lower because we didn't have SIMD32 support yet
but we've supported SIMD32 for quite some time now.  We should bump it
up to the real limit.
---
  src/intel/vulkan/anv_device.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index a6ecc657f4b..7ba2e802c25 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1132,7 +1132,7 @@ void anv_GetPhysicalDeviceProperties(
.maxFragmentCombinedOutputResources   = 8,
.maxComputeSharedMemorySize   = 32768,
.maxComputeWorkGroupCount = { 65535, 65535, 65535 },
-  .maxComputeWorkGroupInvocations   = 16 * devinfo->max_cs_threads,
+  .maxComputeWorkGroupInvocations   = 32 * devinfo->max_cs_threads,
.maxComputeWorkGroupSize = {
   16 * devinfo->max_cs_threads,
   16 * devinfo->max_cs_threads,



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

[Mesa-dev] [PATCH] anv: Bump maxComputeWorkgroupInvocations

2019-03-19 Thread Jason Ekstrand
We initially set this lower because we didn't have SIMD32 support yet
but we've supported SIMD32 for quite some time now.  We should bump it
up to the real limit.
---
 src/intel/vulkan/anv_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index a6ecc657f4b..7ba2e802c25 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1132,7 +1132,7 @@ void anv_GetPhysicalDeviceProperties(
   .maxFragmentCombinedOutputResources   = 8,
   .maxComputeSharedMemorySize   = 32768,
   .maxComputeWorkGroupCount = { 65535, 65535, 65535 },
-  .maxComputeWorkGroupInvocations   = 16 * devinfo->max_cs_threads,
+  .maxComputeWorkGroupInvocations   = 32 * devinfo->max_cs_threads,
   .maxComputeWorkGroupSize = {
  16 * devinfo->max_cs_threads,
  16 * devinfo->max_cs_threads,
-- 
2.20.1

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

[Mesa-dev] [Bug 109393] [vega10] hang with Mario Party 9 through Dolphin

2019-03-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=109393

Jaap Buurman  changed:

   What|Removed |Added

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

--- Comment #17 from Jaap Buurman  ---
Just got the Mesa 19.0 update in Arch's official repository, and the issue
seems to be fixed :) I have been running Mario Party 9 in the main menu for
many minutes now, where it would usually crash within 20-30 seconds. I will
report back if it happens again, but if you don't hear back from me, consider
this issue solved. Thank you very much for the amazing work you guys are doing
on Mesa and RADV!

-- 
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 4/6] glsl/linker: don't fail non static used inputs without matching outputs

2019-03-19 Thread Andres Gomez
On Sat, 2019-02-16 at 10:25 +1100, Timothy Arceri wrote:
> If the updated piglit tests pass on the Nvidia blob as per my reply to 
> those patches and this patch passes on the new and old piglit tests. 
> Then this patch is:

As commented in the piglit thread, the nVIDIA blob has many other
problems with those tests but those changes (in the piglit test) are
only improving the situation.

With i965, the new and old piglit tests still show the same behavior:
they all pass but for the problem discussed here:

https://lists.freedesktop.org/archives/piglit/2019-February/025686.html

Hence, I'll understand I can land this with your Rb.

> 
> Reviewed-by: Timothy Arceri 
> 
> Thanks for fixing this!
> 
> On 7/2/19 2:58 am, Andres Gomez wrote:
> > If there is no Static Use of an input variable, the linker shouldn't
> > fail whenever there is no defined matching output variable in the
> > previous stage.
> > 
> >  From page 47 (page 51 of the PDF) of the GLSL 4.60 v.5 spec:
> > 
> >" Only the input variables that are statically read need to be
> >  written by the previous stage; it is allowed to have superfluous
> >  declarations of input variables."
> > 
> > Now, we complete this exception whenever the input variable has an
> > explicit location. Previously, 18004c338f6 ("glsl: fail when a
> > shader's input var has not an equivalent out var in previous") took
> > care of the cases in which the input variable didn't have an explicit
> > location.
> > 
> > v2: do the location based interface matching check regardless on
> >  whehter it is a separable program or not (Ilia).
> > 
> > Cc: Timothy Arceri 
> > Cc: Iago Toral Quiroga 
> > Cc: Samuel Iglesias Gonsálvez 
> > Cc: Tapani Pälli 
> > Cc: Ian Romanick 
> > Cc: Ilia Mirkin 
> > Signed-off-by: Andres Gomez 
> > ---
> >   src/compiler/glsl/link_varyings.cpp | 16 ++--
> >   1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/compiler/glsl/link_varyings.cpp 
> > b/src/compiler/glsl/link_varyings.cpp
> > index e5f7d3e322a..36908d95263 100644
> > --- a/src/compiler/glsl/link_varyings.cpp
> > +++ b/src/compiler/glsl/link_varyings.cpp
> > @@ -808,8 +808,20 @@ cross_validate_outputs_to_inputs(struct gl_context 
> > *ctx,
> >   
> >  output = 
> > output_explicit_locations[idx][input->data.location_frac].var;
> >   
> > -   if (output == NULL ||
> > -   input->data.location != output->data.location) {
> > +   if (output == NULL) {
> > +  /* A linker failure should only happen when there is no
> > +   * output declaration and there is Static Use of the
> > +   * declared input.
> > +   */
> > +  if (input->data.used) {
> > + linker_error(prog,
> > +  "%s shader input `%s' with explicit 
> > location "
> > +  "has no matching output\n",
> > +  
> > _mesa_shader_stage_to_string(consumer->Stage),
> > +  input->name);
> > + break;
> > +  }
> > +   } else if (input->data.location != output->data.location) {
> > linker_error(prog,
> >  "%s shader input `%s' with explicit 
> > location "
> >  "has no matching output\n",
> > 
-- 
Br,

Andres

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

Re: [Mesa-dev] [PATCH 2/3] radv: remove unnecessary FLUSH_AND_INV_CB when initializing DCC

2019-03-19 Thread Samuel Pitoiset
After having a deeper look at the cache flushes when initializing DCC, 
it seems like we are dumb.


In case the compute path is used for clearing DCC, we set the following 
flags:


- CS_PARTIAL_FLUSH

- INV_VMEM_L1

- WRITEBACK_GLOBAL_L2

- FLUSH_AND_INV_CB

- FLUSH_ANV_INV_CB_META

On GFX9, the driver will emit:

- one RELEASE_MEM with TC_ACTION_ENA | TC_MD_ACTION_ENA

- one ACQUIRE_MEM with TC_WB_ACTION_ENA | TC_NC_ACTION_ENA

- one ACQUIRE_MEM with TCL1_ACTION_ENA

This seems overkill to me... Emitting one RELEASE_MEM with TC_ACTION_ENA 
| TC_WB_ACTION_ENA (ie. INV_GLOBAL_L2) should be enough?


On 3/19/19 2:03 PM, Samuel Pitoiset wrote:


On 3/19/19 1:56 PM, Bas Nieuwenhuizen wrote:

That it does not use it is exactly why we need to make sure the CB
data is not in the CB cache by flushing it?

Why only for DCC?


On Tue, Mar 19, 2019 at 12:15 PM Samuel Pitoiset
 wrote:

The clear operation (ie. compute) doesn't use the CB caches.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
b/src/amd/vulkan/radv_cmd_buffer.c

index 5bb3b51684e..b6035dfbbc5 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4583,8 +4583,7 @@ static void 
radv_init_color_image_metadata(struct radv_cmd_buffer *cmd_buffer,


 state->flush_bits |= radv_clear_dcc(cmd_buffer, 
image, value);


-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
- RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+   state->flush_bits |= 
RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;


 radv_update_fce_metadata(cmd_buffer, image,
need_decompress_pass);
--
2.21.0

___
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 2/3] radv: remove unnecessary FLUSH_AND_INV_CB when initializing DCC

2019-03-19 Thread Samuel Pitoiset


On 3/19/19 1:56 PM, Bas Nieuwenhuizen wrote:

That it does not use it is exactly why we need to make sure the CB
data is not in the CB cache by flushing it?

Why only for DCC?


On Tue, Mar 19, 2019 at 12:15 PM Samuel Pitoiset
 wrote:

The clear operation (ie. compute) doesn't use the CB caches.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_cmd_buffer.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 5bb3b51684e..b6035dfbbc5 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4583,8 +4583,7 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,

 state->flush_bits |= radv_clear_dcc(cmd_buffer, image, value);

-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
-RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;

 radv_update_fce_metadata(cmd_buffer, image,
  need_decompress_pass);
--
2.21.0

___
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 2/3] radv: remove unnecessary FLUSH_AND_INV_CB when initializing DCC

2019-03-19 Thread Bas Nieuwenhuizen
That it does not use it is exactly why we need to make sure the CB
data is not in the CB cache by flushing it?

On Tue, Mar 19, 2019 at 12:15 PM Samuel Pitoiset
 wrote:
>
> The clear operation (ie. compute) doesn't use the CB caches.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 5bb3b51684e..b6035dfbbc5 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -4583,8 +4583,7 @@ static void radv_init_color_image_metadata(struct 
> radv_cmd_buffer *cmd_buffer,
>
> state->flush_bits |= radv_clear_dcc(cmd_buffer, image, value);
>
> -   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
> -RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
> +   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
>
> radv_update_fce_metadata(cmd_buffer, image,
>  need_decompress_pass);
> --
> 2.21.0
>
> ___
> 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] virgl: Set bind when creating temp resource.

2019-03-19 Thread Erik Faye-Lund
On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason is that a zero bind value was given for temp resource.
> 
> Signed-off-by: Lepton Wu 
> ---
>  src/gallium/drivers/virgl/virgl_texture.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/gallium/drivers/virgl/virgl_texture.c
> b/src/gallium/drivers/virgl/virgl_texture.c
> index 231319899e0..563dbacba7e 100644
> --- a/src/gallium/drivers/virgl/virgl_texture.c
> +++ b/src/gallium/drivers/virgl/virgl_texture.c
> @@ -66,6 +66,7 @@ static void
> virgl_init_temp_resource_from_box(struct pipe_resource *res,
>unsigned level,
> unsigned flags)
>  {
> memset(res, 0, sizeof(*res));
> +   res->bind = orig->bind;
> res->format = orig->format;
> res->width0 = box->width;
> res->height0 = box->height;

I have a similar-ish patch for the same issue in a branch I'll be
sending out soon:

https://gitlab.freedesktop.org/kusma/mesa/commit/6c19b6b98025a1be31eabdb559709b18eecdbafa#note_132855

Now, as Dave pointed out, there might be some more cases missing in my
patch. I also tried your approach, and it works for me. But I'm not
entirely sure it's the right one; for instance I don't think we'd ever
want to carry flags like PIPE_BIND_DISPLAY_TARGET and
PIPE_BIND_BLENDABLE forward.

Perhaps the right thing is to do something like:

res->bind = orig->bind & (PIPE_BIND_DEPTH_STENCIL |
  PIPE_BIND_RENDER_TARGET);

But I'm not sure if that's enough; what if we get a surface with
PIPE_BIND_SHADER_IMAGE set? We probably still want to use
PIPE_BIND_RENDER_TARGET for the blit then...


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

[Mesa-dev] [PATCH 2/3] radv: remove unnecessary FLUSH_AND_INV_CB when initializing DCC

2019-03-19 Thread Samuel Pitoiset
The clear operation (ie. compute) doesn't use the CB caches.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 5bb3b51684e..b6035dfbbc5 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4583,8 +4583,7 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
 
state->flush_bits |= radv_clear_dcc(cmd_buffer, image, value);
 
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
-RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 
radv_update_fce_metadata(cmd_buffer, image,
 need_decompress_pass);
-- 
2.21.0

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

[Mesa-dev] [PATCH 3/3] radv: improve color image metadata (CMASK/FMASK/DCC) initialization

2019-03-19 Thread Samuel Pitoiset
If an image has CMASK/FMASK or FMASK/DCC it shouldn't be needed
to sync between the two clears because they don't initialize
the same memory range.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 31 +--
 1 file changed, 13 insertions(+), 18 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index b6035dfbbc5..e9df9da70bb 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4540,6 +4540,14 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
   unsigned dst_queue_mask)
 {
struct radv_cmd_state *state = _buffer->state;
+   enum radv_cmd_flush_bits post_flush = 0;
+
+   if (!radv_image_has_CB_metadata(image))
+   return;
+
+   /* XXX: Figure out if this is really needed! */
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
+RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 
if (radv_image_has_cmask(image)) {
uint32_t value = 0xu; /* Fully expanded mode. */
@@ -4549,23 +4557,13 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
value = 0xu;
}
 
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
-RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
-
-   state->flush_bits |= radv_clear_cmask(cmd_buffer, image, value);
-
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+   post_flush |= radv_clear_cmask(cmd_buffer, image, value);
}
 
if (radv_image_has_fmask(image)) {
uint32_t value = radv_image_get_fmask_init_value(image);
 
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
-RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
-
-   state->flush_bits |= radv_clear_fmask(cmd_buffer, image, value);
-
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+   post_flush |= radv_clear_fmask(cmd_buffer, image, value);
}
 
if (radv_image_has_dcc(image)) {
@@ -4578,12 +4576,7 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
need_decompress_pass = true;
}
 
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
-RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
-
-   state->flush_bits |= radv_clear_dcc(cmd_buffer, image, value);
-
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+   post_flush |= radv_clear_dcc(cmd_buffer, image, value);
 
radv_update_fce_metadata(cmd_buffer, image,
 need_decompress_pass);
@@ -4593,6 +4586,8 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
uint32_t color_values[2] = {};
radv_set_color_clear_metadata(cmd_buffer, image, color_values);
}
+
+   state->flush_bits |= post_flush | RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 }
 
 /**
-- 
2.21.0

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

[Mesa-dev] [PATCH 1/3] radv: rework radv_init_color_image_metadata()

2019-03-19 Thread Samuel Pitoiset
Unnecessary to have a separate function for CMASK, and calling
the radv_clear_XXX() helpers will allow us to remove some
cache flushes.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 48 
 src/amd/vulkan/radv_private.h| 18 
 2 files changed, 42 insertions(+), 24 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ae8f50d0348..5bb3b51684e 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4501,31 +4501,11 @@ static void radv_handle_depth_image_transition(struct 
radv_cmd_buffer *cmd_buffe
}
 }
 
-static void radv_initialise_cmask(struct radv_cmd_buffer *cmd_buffer,
- struct radv_image *image, uint32_t value)
-{
-   struct radv_cmd_state *state = _buffer->state;
-
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
-   RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
-
-   state->flush_bits |= radv_clear_cmask(cmd_buffer, image, value);
-
-   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
-}
-
 void radv_initialize_fmask(struct radv_cmd_buffer *cmd_buffer,
   struct radv_image *image)
 {
struct radv_cmd_state *state = _buffer->state;
-   static const uint32_t fmask_clear_values[4] = {
-   0x,
-   0x02020202,
-   0xE4E4E4E4,
-   0x76543210
-   };
-   uint32_t log2_samples = util_logbase2(image->info.samples);
-   uint32_t value = fmask_clear_values[log2_samples];
+   uint32_t value = radv_image_get_fmask_init_value(image);
 
state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
 RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
@@ -4559,6 +4539,8 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
   unsigned src_queue_mask,
   unsigned dst_queue_mask)
 {
+   struct radv_cmd_state *state = _buffer->state;
+
if (radv_image_has_cmask(image)) {
uint32_t value = 0xu; /* Fully expanded mode. */
 
@@ -4567,11 +4549,23 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
value = 0xu;
}
 
-   radv_initialise_cmask(cmd_buffer, image, value);
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
+RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+
+   state->flush_bits |= radv_clear_cmask(cmd_buffer, image, value);
+
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
}
 
if (radv_image_has_fmask(image)) {
-   radv_initialize_fmask(cmd_buffer, image);
+   uint32_t value = radv_image_get_fmask_init_value(image);
+
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
+RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+
+   state->flush_bits |= radv_clear_fmask(cmd_buffer, image, value);
+
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
}
 
if (radv_image_has_dcc(image)) {
@@ -4584,7 +4578,13 @@ static void radv_init_color_image_metadata(struct 
radv_cmd_buffer *cmd_buffer,
need_decompress_pass = true;
}
 
-   radv_initialize_dcc(cmd_buffer, image, value);
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
+RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
+
+   state->flush_bits |= radv_clear_dcc(cmd_buffer, image, value);
+
+   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
+RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
 
radv_update_fce_metadata(cmd_buffer, image,
 need_decompress_pass);
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 39fa6110fde..064fe3b02a4 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1603,6 +1603,24 @@ radv_image_has_CB_metadata(const struct radv_image 
*image)
   radv_image_has_dcc(image);
 }
 
+/**
+ * Return the initial FMASK value.
+ */
+static inline uint32_t
+radv_image_get_fmask_init_value(const struct radv_image *image)
+{
+   static const uint32_t fmask_clear_values[4] = {
+   0x,
+   0x02020202,
+   0xE4E4E4E4,
+   0x76543210
+   };
+   uint32_t log2_samples = util_logbase2(image->info.samples);
+   uint32_t value = fmask_clear_values[log2_samples];
+
+   return value;
+}
+
 /**
  * Return whether the image has HTILE metadata for depth surfaces.
  */
-- 
2.21.0

___
mesa-dev 

Re: [Mesa-dev] Mesa (master): nir/spirv: handle kernel function parameters

2019-03-19 Thread Samuel Pitoiset
This commit breaks some CTS with RADV (eg. 
dEQP-VK.ssbo.phys.layout.single_basic_type.std430.bvec2) and it 
introduces one compiler warning (minor stuff).


Is the Rb tag missing too?

Thanks!

On 3/19/19 5:57 AM, GitLab Mirror wrote:

Module: Mesa
Branch: master
Commit: c95afe56a8033a87dca71cc93191d448c2981cf7
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=c95afe56a8033a87dca71cc93191d448c2981cf7

Author: Karol Herbst 
Date:   Tue Nov  6 12:06:08 2018 +0100

nir/spirv: handle kernel function parameters

the idea here is to generate an entry point stub function wrapping around the
actual kernel function and turn all parameters into shader inputs with byte
addressing instead of vec4.

This gives us several advantages:
1. calling kernel functions doesn't differ from calling any other function
2. CL inputs match uniforms in most ways and we can just take advantage of most
of nir_lower_io

v2: move code into a seperate function
v3: verify the entry point got a name
 fix minor typo
v4: make vtn_emit_kernel_entry_point_wrapper take the old entry point as an arg

Signed-off-by: Karol Herbst 

---

  src/compiler/spirv/spirv_to_nir.c | 66 +++
  1 file changed, 66 insertions(+)

diff --git a/src/compiler/spirv/spirv_to_nir.c 
b/src/compiler/spirv/spirv_to_nir.c
index 5becd3418da..df5bba2c2a0 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -4453,6 +4453,68 @@ vtn_create_builder(const uint32_t *words, size_t 
word_count,
 return NULL;
  }
  
+static nir_function *

+vtn_emit_kernel_entry_point_wrapper(struct vtn_builder *b,
+const nir_function *entry_point)
+{
+   vtn_assert(entry_point == b->entry_point->func->impl->function);
+   vtn_fail_if(!entry_point->name, "entry points are required to have a name");
+   const char *func_name =
+  ralloc_asprintf(b->shader, "__wrapped_%s", entry_point->name);
+
+   /* we shouldn't have any inputs yet */
+   vtn_assert(!entry_point->shader->num_inputs);
+   vtn_assert(b->shader->info.stage == MESA_SHADER_KERNEL);
+
+   nir_function *main_entry_point = nir_function_create(b->shader, func_name);
+   main_entry_point->impl = nir_function_impl_create(main_entry_point);
+   nir_builder_init(>nb, main_entry_point->impl);
+   b->nb.cursor = nir_after_cf_list(_entry_point->impl->body);
+   b->func_param_idx = 0;
+
+   nir_call_instr *call = nir_call_instr_create(b->nb.shader, entry_point);
+
+   for (unsigned i = 0; i < entry_point->num_params; ++i) {
+  struct vtn_type *param_type = b->entry_point->func->type->params[i];
+
+  /* consider all pointers to function memory to be parameters passed
+   * by value
+   */
+  bool is_by_val = param_type->base_type == vtn_base_type_pointer &&
+ param_type->storage_class == SpvStorageClassFunction;
+
+  /* input variable */
+  nir_variable *in_var = rzalloc(b->nb.shader, nir_variable);
+  in_var->data.mode = nir_var_shader_in;
+  in_var->data.read_only = true;
+  in_var->data.location = i;
+
+  if (is_by_val)
+ in_var->type = param_type->deref->type;
+  else
+ in_var->type = param_type->type;
+
+  nir_shader_add_variable(b->nb.shader, in_var);
+  b->nb.shader->num_inputs++;
+
+  /* we have to copy the entire variable into function memory */
+  if (is_by_val) {
+ nir_variable *copy_var =
+nir_local_variable_create(main_entry_point->impl, in_var->type,
+  "copy_in");
+ nir_copy_var(>nb, copy_var, in_var);
+ call->params[i] =
+nir_src_for_ssa(_build_deref_var(>nb, copy_var)->dest.ssa);
+  } else {
+ call->params[i] = nir_src_for_ssa(nir_load_var(>nb, in_var));
+  }
+   }
+
+   nir_builder_instr_insert(>nb, >instr);
+
+   return main_entry_point;
+}
+
  nir_function *
  spirv_to_nir(const uint32_t *words, size_t word_count,
   struct nir_spirv_specialization *spec, unsigned num_spec,
@@ -4542,6 +4604,10 @@ spirv_to_nir(const uint32_t *words, size_t word_count,
 nir_function *entry_point = b->entry_point->func->impl->function;
 vtn_assert(entry_point);
  
+   /* post process entry_points with input params */

+   if (entry_point->num_params && b->shader->info.stage == MESA_SHADER_KERNEL)
+  entry_point = vtn_emit_kernel_entry_point_wrapper(b, entry_point);
+
 entry_point->is_entrypoint = true;
  
 /* When multiple shader stages exist in the same SPIR-V module, we


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

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

[Mesa-dev] [PATCH v2] radv: only load 2-dwords for vertex buffers when robustness is disabled

2019-03-19 Thread Samuel Pitoiset
This patch requires the typed vertex fetches series.

Totals from affected shaders:
SGPRS: 445574 -> 452638 (1.59 %)
VGPRS: 373392 -> 370436 (-0.79 %)
Spilled SGPRs: 77 -> 14 (-81.82 %)
Spilled VGPRs: 0 -> 0 (0.00 %)
Code Size: 14162288 -> 14413036 (1.77 %) bytes
Max Waves: 11 -> 120509 (0.43 %)

v2: - fix vertex descriptors

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c  | 32 +++
 src/amd/vulkan/radv_device.c  |  2 ++
 src/amd/vulkan/radv_nir_to_llvm.c | 21 +++-
 src/amd/vulkan/radv_private.h |  1 +
 src/amd/vulkan/radv_shader.c  |  1 +
 src/amd/vulkan/radv_shader.h  |  1 +
 6 files changed, 45 insertions(+), 13 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index ae8f50d0348..0c8572bd1e5 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -1991,6 +1991,7 @@ radv_flush_vertex_descriptors(struct radv_cmd_buffer 
*cmd_buffer,
cmd_buffer->state.pipeline->num_vertex_bindings &&
radv_get_shader(cmd_buffer->state.pipeline, 
MESA_SHADER_VERTEX)->info.info.vs.has_vertex_buffers) {
struct radv_vertex_elements_info *velems = 
_buffer->state.pipeline->vertex_elements;
+   unsigned desc_size_bytes = 
cmd_buffer->device->robust_buffer_access ? 16 : 8;
unsigned vb_offset;
void *vb_ptr;
uint32_t i = 0;
@@ -1998,12 +1999,13 @@ radv_flush_vertex_descriptors(struct radv_cmd_buffer 
*cmd_buffer,
uint64_t va;
 
/* allocate some descriptor state for vertex buffers */
-   if (!radv_cmd_buffer_upload_alloc(cmd_buffer, count * 16, 256,
+   if (!radv_cmd_buffer_upload_alloc(cmd_buffer,
+ count * desc_size_bytes, 256,
  _offset, _ptr))
return;
 
for (i = 0; i < count; i++) {
-   uint32_t *desc = &((uint32_t *)vb_ptr)[i * 4];
+   uint32_t *desc = &((uint32_t *)vb_ptr)[i * 
(desc_size_bytes / 4)];
uint32_t offset;
struct radv_buffer *buffer = 
cmd_buffer->vertex_bindings[i].buffer;
uint32_t stride = 
cmd_buffer->state.pipeline->binding_stride[i];
@@ -2017,16 +2019,22 @@ radv_flush_vertex_descriptors(struct radv_cmd_buffer 
*cmd_buffer,
va += offset + buffer->offset;
desc[0] = va;
desc[1] = S_008F04_BASE_ADDRESS_HI(va >> 32) | 
S_008F04_STRIDE(stride);
-   if 
(cmd_buffer->device->physical_device->rad_info.chip_class <= CIK && stride)
-   desc[2] = (buffer->size - offset - 
velems->format_size[i]) / stride + 1;
-   else
-   desc[2] = buffer->size - offset;
-   desc[3] = S_008F0C_DST_SEL_X(V_008F0C_SQ_SEL_X) |
- S_008F0C_DST_SEL_Y(V_008F0C_SQ_SEL_Y) |
- S_008F0C_DST_SEL_Z(V_008F0C_SQ_SEL_Z) |
- S_008F0C_DST_SEL_W(V_008F0C_SQ_SEL_W) |
- 
S_008F0C_NUM_FORMAT(V_008F0C_BUF_NUM_FORMAT_UINT) |
- 
S_008F0C_DATA_FORMAT(V_008F0C_BUF_DATA_FORMAT_32);
+
+   if (cmd_buffer->device->robust_buffer_access) {
+   /* Enable out of bounds checking only when
+* robust buffer access is requested.
+*/
+   if 
(cmd_buffer->device->physical_device->rad_info.chip_class <= CIK && stride)
+   desc[2] = (buffer->size - offset - 
velems->format_size[i]) / stride + 1;
+   else
+   desc[2] = buffer->size - offset;
+   desc[3] = S_008F0C_DST_SEL_X(V_008F0C_SQ_SEL_X) 
|
+ S_008F0C_DST_SEL_Y(V_008F0C_SQ_SEL_Y) 
|
+ S_008F0C_DST_SEL_Z(V_008F0C_SQ_SEL_Z) 
|
+ S_008F0C_DST_SEL_W(V_008F0C_SQ_SEL_W) 
|
+ 
S_008F0C_NUM_FORMAT(V_008F0C_BUF_NUM_FORMAT_UINT) |
+ 
S_008F0C_DATA_FORMAT(V_008F0C_BUF_DATA_FORMAT_32);
+   }
}
 
va = radv_buffer_get_va(cmd_buffer->upload.upload_bo);
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index dc4346b7498..895e7d67d50 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -1798,6 +1798,8 @@ VkResult radv_CreateDevice(
device->has_distributed_tess =

[Mesa-dev] [PATCH 3/8] ac/nir: implement 8-bit push constant, ssbo and ubo loads

2019-03-19 Thread Samuel Pitoiset
From: Rhys Perry 

Signed-off-by: Rhys Perry 
---
 src/amd/common/ac_nir_to_llvm.c | 65 -
 1 file changed, 55 insertions(+), 10 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 7a03e9c15b2..34c4e2a69fa 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1430,7 +1430,30 @@ static LLVMValueRef visit_load_push_constant(struct 
ac_nir_context *ctx,
 
ptr = ac_build_gep0(>ac, ctx->abi->push_constants, addr);
 
-   if (instr->dest.ssa.bit_size == 16) {
+   if (instr->dest.ssa.bit_size == 8) {
+   unsigned load_dwords = instr->dest.ssa.num_components > 1 ? 2 : 
1;
+   LLVMTypeRef vec_type = 
LLVMVectorType(LLVMInt8TypeInContext(ctx->ac.context), 4 * load_dwords);
+   ptr = ac_cast_ptr(>ac, ptr, vec_type);
+   LLVMValueRef res = LLVMBuildLoad(ctx->ac.builder, ptr, "");
+
+   LLVMValueRef params[3];
+   if (load_dwords > 1) {
+   LLVMValueRef res_vec = 
LLVMBuildBitCast(ctx->ac.builder, res, LLVMVectorType(ctx->ac.i32, 2), "");
+   params[0] = LLVMBuildExtractElement(ctx->ac.builder, 
res_vec, LLVMConstInt(ctx->ac.i32, 1, false), "");
+   params[1] = LLVMBuildExtractElement(ctx->ac.builder, 
res_vec, LLVMConstInt(ctx->ac.i32, 0, false), "");
+   } else {
+   res = LLVMBuildBitCast(ctx->ac.builder, res, 
ctx->ac.i32, "");
+   params[0] = ctx->ac.i32_0;
+   params[1] = res;
+   }
+   params[2] = addr;
+   res = ac_build_intrinsic(>ac, "llvm.amdgcn.alignbyte", 
ctx->ac.i32, params, 3, 0);
+
+   res = LLVMBuildTrunc(ctx->ac.builder, res, 
LLVMIntTypeInContext(ctx->ac.context, instr->dest.ssa.num_components * 8), "");
+   if (instr->dest.ssa.num_components > 1)
+   res = LLVMBuildBitCast(ctx->ac.builder, res, 
LLVMVectorType(LLVMInt8TypeInContext(ctx->ac.context), 
instr->dest.ssa.num_components), "");
+   return res;
+   } else if (instr->dest.ssa.bit_size == 16) {
unsigned load_dwords = instr->dest.ssa.num_components / 2 + 1;
LLVMTypeRef vec_type = 
LLVMVectorType(LLVMInt16TypeInContext(ctx->ac.context), 2 * load_dwords);
ptr = ac_cast_ptr(>ac, ptr, vec_type);
@@ -1703,13 +1726,21 @@ static LLVMValueRef visit_load_buffer(struct 
ac_nir_context *ctx,
LLVMValueRef immoffset = LLVMConstInt(ctx->ac.i32, i * 
elem_size_bytes, false);
 
LLVMValueRef ret;
-   if (load_bytes == 2) {
-   ret = ac_build_tbuffer_load_short(>ac,
+
+   if (load_bytes == 1) {
+   ret = ac_build_tbuffer_load_byte(>ac,
  rsrc,
  offset,
  ctx->ac.i32_0,
  immoffset,
  cache_policy & 
ac_glc);
+   } else if (load_bytes == 2) {
+   ret = ac_build_tbuffer_load_short(>ac,
+rsrc,
+offset,
+ctx->ac.i32_0,
+immoffset,
+cache_policy & ac_glc);
} else {
int num_channels = util_next_power_of_two(load_bytes) / 
4;
 
@@ -1749,15 +1780,29 @@ static LLVMValueRef visit_load_ubo_buffer(struct 
ac_nir_context *ctx,
if (instr->dest.ssa.bit_size == 64)
num_components *= 2;
 
-   if (instr->dest.ssa.bit_size == 16) {
+   if (instr->dest.ssa.bit_size == 16 || instr->dest.ssa.bit_size == 8) {
+   unsigned load_bytes = instr->dest.ssa.bit_size / 8;
LLVMValueRef results[num_components];
for (unsigned i = 0; i < num_components; ++i) {
-   results[i] = ac_build_tbuffer_load_short(>ac,
-rsrc,
-offset,
-ctx->ac.i32_0,
-
LLVMConstInt(ctx->ac.i32, 2 * i, 0),
-false);
+   LLVMValueRef immoffset = LLVMConstInt(ctx->ac.i32,
+ load_bytes * i, 
0);
+
+   if (load_bytes == 1) {
+   

[Mesa-dev] [PATCH 7/8] ac/nir: implement 8-bit conversions

2019-03-19 Thread Samuel Pitoiset
From: Rhys Perry 

Signed-off-by: Rhys Perry 
---
 src/amd/common/ac_nir_to_llvm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index c7212ff3293..f0b0c24ec08 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -862,12 +862,14 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
src[i] = ac_to_integer(>ac, src[i]);
result = ac_build_gather_values(>ac, src, num_components);
break;
+   case nir_op_f2i8:
case nir_op_f2i16:
case nir_op_f2i32:
case nir_op_f2i64:
src[0] = ac_to_float(>ac, src[0]);
result = LLVMBuildFPToSI(ctx->ac.builder, src[0], def_type, "");
break;
+   case nir_op_f2u8:
case nir_op_f2u16:
case nir_op_f2u32:
case nir_op_f2u64:
@@ -904,6 +906,7 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
else
result = LLVMBuildFPTrunc(ctx->ac.builder, src[0], 
ac_to_float_type(>ac, def_type), "");
break;
+   case nir_op_u2u8:
case nir_op_u2u16:
case nir_op_u2u32:
case nir_op_u2u64:
@@ -913,6 +916,7 @@ static void visit_alu(struct ac_nir_context *ctx, const 
nir_alu_instr *instr)
else
result = LLVMBuildTrunc(ctx->ac.builder, src[0], 
def_type, "");
break;
+   case nir_op_i2i8:
case nir_op_i2i16:
case nir_op_i2i32:
case nir_op_i2i64:
-- 
2.21.0

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

[Mesa-dev] [PATCH 4/8] ac: add ac_build_tbuffer_store_byte() helper

2019-03-19 Thread Samuel Pitoiset
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 19 +++
 src/amd/common/ac_llvm_build.h |  9 +
 2 files changed, 28 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index d52f1b3f42d..f6078634336 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1771,6 +1771,25 @@ ac_build_tbuffer_store_short(struct ac_llvm_context *ctx,
   writeonly_memory);
 }
 
+void
+ac_build_tbuffer_store_byte(struct ac_llvm_context *ctx,
+   LLVMValueRef rsrc,
+   LLVMValueRef vdata,
+   LLVMValueRef voffset,
+   LLVMValueRef soffset,
+   bool glc,
+   bool writeonly_memory)
+{
+   unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_8;
+   unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
+
+   vdata = LLVMBuildBitCast(ctx->builder, vdata, ctx->i8, "");
+   vdata = LLVMBuildZExt(ctx->builder, vdata, ctx->i32, "");
+
+   ac_build_raw_tbuffer_store(ctx, rsrc, vdata, voffset, soffset,
+  ctx->i32_0, 1, dfmt, nfmt, glc, false,
+  writeonly_memory);
+}
 /**
  * Set range metadata on an instruction.  This can only be used on load and
  * call instructions.  If you know an instruction can only produce the values
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 0162986e454..aa6e913c6c6 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -362,6 +362,15 @@ ac_build_tbuffer_store_short(struct ac_llvm_context *ctx,
 bool glc,
 bool writeonly_memory);
 
+void
+ac_build_tbuffer_store_byte(struct ac_llvm_context *ctx,
+   LLVMValueRef rsrc,
+   LLVMValueRef vdata,
+   LLVMValueRef voffset,
+   LLVMValueRef soffset,
+   bool glc,
+   bool writeonly_memory);
+
 void
 ac_build_struct_tbuffer_store(struct ac_llvm_context *ctx,
  LLVMValueRef rsrc,
-- 
2.21.0

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

[Mesa-dev] [PATCH 6/8] ac/nir: add 8-bit types to glsl_base_to_llvm_type

2019-03-19 Thread Samuel Pitoiset
From: Rhys Perry 

v2: remove 16-bit additions and rebase

Signed-off-by: Rhys Perry 
---
 src/amd/common/ac_nir_to_llvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index f3e8f89ba9b..c7212ff3293 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -3942,6 +3942,9 @@ glsl_base_to_llvm_type(struct ac_llvm_context *ac,
case GLSL_TYPE_BOOL:
case GLSL_TYPE_SUBROUTINE:
return ac->i32;
+   case GLSL_TYPE_INT8:
+   case GLSL_TYPE_UINT8:
+   return ac->i8;
case GLSL_TYPE_INT16:
case GLSL_TYPE_UINT16:
return ac->i16;
-- 
2.21.0

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

[Mesa-dev] [PATCH 5/8] ac/nir: implement 8-bit ssbo stores

2019-03-19 Thread Samuel Pitoiset
From: Rhys Perry 

Signed-off-by: Rhys Perry 
---
 src/amd/common/ac_nir_to_llvm.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index 34c4e2a69fa..f3e8f89ba9b 100644
--- a/src/amd/common/ac_nir_to_llvm.c
+++ b/src/amd/common/ac_nir_to_llvm.c
@@ -1553,7 +1553,7 @@ static void visit_store_ssbo(struct ac_nir_context *ctx,
 
LLVMValueRef rsrc = ctx->abi->load_ssbo(ctx->abi,
get_src(ctx, instr->src[1]), true);
-   LLVMValueRef base_data = ac_to_float(>ac, src_data);
+   LLVMValueRef base_data = src_data;
base_data = ac_trim_vector(>ac, base_data, instr->num_components);
LLVMValueRef base_offset = get_src(ctx, instr->src[2]);
 
@@ -1591,7 +1591,12 @@ static void visit_store_ssbo(struct ac_nir_context *ctx,
offset = LLVMBuildAdd(ctx->ac.builder, base_offset,
  LLVMConstInt(ctx->ac.i32, start * 
elem_size_bytes, false), "");
 
-   if (num_bytes == 2) {
+   if (num_bytes == 1) {
+   ac_build_tbuffer_store_byte(>ac, rsrc, data,
+   offset, ctx->ac.i32_0,
+   cache_policy & ac_glc,
+   writeonly_memory);
+   } else if (num_bytes == 2) {
ac_build_tbuffer_store_short(>ac, rsrc, data,
 offset, ctx->ac.i32_0,
 cache_policy & ac_glc,
-- 
2.21.0

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

[Mesa-dev] [PATCH 8/8] radv: enable VK_KHR_8bit_storage

2019-03-19 Thread Samuel Pitoiset
From: Rhys Perry 

Signed-off-by: Rhys Perry 
---
 docs/features.txt | 2 +-
 src/amd/vulkan/radv_device.c  | 9 +
 src/amd/vulkan/radv_extensions.py | 1 +
 src/amd/vulkan/radv_shader.c  | 1 +
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/docs/features.txt b/docs/features.txt
index 6c2b6d59377..ded753b0182 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -439,7 +439,7 @@ Vulkan 1.1 -- all DONE: anv, radv
   VK_KHR_variable_pointers  DONE (anv, radv)
 
 Khronos extensions that are not part of any Vulkan version:
-  VK_KHR_8bit_storage   DONE (anv)
+  VK_KHR_8bit_storage   DONE (anv, radv)
   VK_KHR_android_surfacenot started
   VK_KHR_create_renderpass2 DONE (anv, radv)
   VK_KHR_displayDONE (anv, radv)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 9570c15af02..e8248ceda88 100644
--- a/src/amd/vulkan/radv_device.c
+++ b/src/amd/vulkan/radv_device.c
@@ -887,6 +887,15 @@ void radv_GetPhysicalDeviceFeatures2(
features->depthClipEnable = true;
break;
}
+   case 
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_8BIT_STORAGE_FEATURES_KHR: {
+   VkPhysicalDevice8BitStorageFeaturesKHR *features =
+   (VkPhysicalDevice8BitStorageFeaturesKHR*)ext;
+   bool enabled = pdevice->rad_info.chip_class >= VI;
+   features->storageBuffer8BitAccess = enabled;
+   features->uniformAndStorageBuffer8BitAccess = enabled;
+   features->storagePushConstant8 = enabled;
+   break;
+   }
default:
break;
}
diff --git a/src/amd/vulkan/radv_extensions.py 
b/src/amd/vulkan/radv_extensions.py
index 0440a2ec9d9..4f87dc05264 100644
--- a/src/amd/vulkan/radv_extensions.py
+++ b/src/amd/vulkan/radv_extensions.py
@@ -91,6 +91,7 @@ EXTENSIONS = [
 Extension('VK_KHR_xlib_surface',  6, 
'VK_USE_PLATFORM_XLIB_KHR'),
 Extension('VK_KHR_multiview', 1, True),
 Extension('VK_KHR_display',  23, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
+Extension('VK_KHR_8bit_storage',  1, 
'device->rad_info.chip_class >= VI'),
 Extension('VK_EXT_direct_mode_display',   1, 
'VK_USE_PLATFORM_DISPLAY_KHR'),
 Extension('VK_EXT_acquire_xlib_display',  1, 
'VK_USE_PLATFORM_XLIB_XRANDR_EXT'),
 Extension('VK_EXT_buffer_device_address', 1, True),
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index bd045a0b92f..a280959b658 100644
--- a/src/amd/vulkan/radv_shader.c
+++ b/src/amd/vulkan/radv_shader.c
@@ -249,6 +249,7 @@ radv_shader_compile_to_nir(struct radv_device *device,
.transform_feedback = true,
.trinary_minmax = true,
.variable_pointers = true,
+   .storage_8bit = true,
},
.ubo_ptr_type = glsl_vector_type(GLSL_TYPE_UINT, 2),
.ssbo_ptr_type = glsl_vector_type(GLSL_TYPE_UINT, 2),
-- 
2.21.0

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

[Mesa-dev] [PATCH 2/8] ac: add ac_build_tbuffer_load_byte() helper

2019-03-19 Thread Samuel Pitoiset
Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 18 ++
 src/amd/common/ac_llvm_build.h |  8 
 2 files changed, 26 insertions(+)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index c5f1c85f269..d52f1b3f42d 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -1606,6 +1606,24 @@ ac_build_tbuffer_load_short(struct ac_llvm_context *ctx,
return LLVMBuildTrunc(ctx->builder, res, ctx->i16, "");
 }
 
+LLVMValueRef
+ac_build_tbuffer_load_byte(struct ac_llvm_context *ctx,
+  LLVMValueRef rsrc,
+  LLVMValueRef voffset,
+  LLVMValueRef soffset,
+  LLVMValueRef immoffset,
+  bool glc)
+{
+   unsigned dfmt = V_008F0C_BUF_DATA_FORMAT_8;
+   unsigned nfmt = V_008F0C_BUF_NUM_FORMAT_UINT;
+   LLVMValueRef res;
+
+   res = ac_build_raw_tbuffer_load(ctx, rsrc, voffset, soffset,
+   immoffset, 1, dfmt, nfmt, glc, false,
+   false);
+
+   return LLVMBuildTrunc(ctx->builder, res, ctx->i8, "");
+}
 static void
 ac_build_llvm8_tbuffer_store(struct ac_llvm_context *ctx,
 LLVMValueRef rsrc,
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index f6bf473f6a1..0162986e454 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -318,6 +318,14 @@ ac_build_tbuffer_load_short(struct ac_llvm_context *ctx,
LLVMValueRef immoffset,
bool glc);
 
+LLVMValueRef
+ac_build_tbuffer_load_byte(struct ac_llvm_context *ctx,
+  LLVMValueRef rsrc,
+  LLVMValueRef voffset,
+  LLVMValueRef soffset,
+  LLVMValueRef immoffset,
+  bool glc);
+
 LLVMValueRef
 ac_build_struct_tbuffer_load(struct ac_llvm_context *ctx,
 LLVMValueRef rsrc,
-- 
2.21.0

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

[Mesa-dev] [PATCH 0/8] radv: VK_KHR_8bit_storage

2019-03-19 Thread Samuel Pitoiset
Hi,

This series implements VK_KHR_8bit_storage for RADV. Original work
is from Rhys Perry, I did rebase, update some patches and test.

Please review,
thanks!

Rhys Perry (5):
  ac/nir: implement 8-bit push constant, ssbo and ubo loads
  ac/nir: implement 8-bit ssbo stores
  ac/nir: add 8-bit types to glsl_base_to_llvm_type
  ac/nir: implement 8-bit conversions
  radv: enable VK_KHR_8bit_storage

Samuel Pitoiset (3):
  ac: add various int8 definitions
  ac: add ac_build_tbuffer_load_byte() helper
  ac: add ac_build_tbuffer_store_byte() helper

 docs/features.txt |  2 +-
 src/amd/common/ac_llvm_build.c| 47 +-
 src/amd/common/ac_llvm_build.h| 19 
 src/amd/common/ac_nir_to_llvm.c   | 81 ++-
 src/amd/vulkan/radv_device.c  |  9 
 src/amd/vulkan/radv_extensions.py |  1 +
 src/amd/vulkan/radv_shader.c  |  1 +
 7 files changed, 145 insertions(+), 15 deletions(-)

-- 
2.21.0

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

[Mesa-dev] [PATCH 1/8] ac: add various int8 definitions

2019-03-19 Thread Samuel Pitoiset
Original patch by Rhys Perry.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_llvm_build.c | 10 --
 src/amd/common/ac_llvm_build.h |  2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 541ad75c877..c5f1c85f269 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_llvm_build.c
@@ -87,6 +87,8 @@ ac_llvm_context_init(struct ac_llvm_context *ctx,
ctx->v4f32 = LLVMVectorType(ctx->f32, 4);
ctx->v8i32 = LLVMVectorType(ctx->i32, 8);
 
+   ctx->i8_0 = LLVMConstInt(ctx->i8, 0, false);
+   ctx->i8_1 = LLVMConstInt(ctx->i8, 1, false);
ctx->i16_0 = LLVMConstInt(ctx->i16, 0, false);
ctx->i16_1 = LLVMConstInt(ctx->i16, 1, false);
ctx->i32_0 = LLVMConstInt(ctx->i32, 0, false);
@@ -201,7 +203,9 @@ ac_get_type_size(LLVMTypeRef type)
 
 static LLVMTypeRef to_integer_type_scalar(struct ac_llvm_context *ctx, 
LLVMTypeRef t)
 {
-   if (t == ctx->f16 || t == ctx->i16)
+   if (t == ctx->i8)
+   return ctx->i8;
+   else if (t == ctx->f16 || t == ctx->i16)
return ctx->i16;
else if (t == ctx->f32 || t == ctx->i32)
return ctx->i32;
@@ -253,7 +257,9 @@ ac_to_integer_or_pointer(struct ac_llvm_context *ctx, 
LLVMValueRef v)
 
 static LLVMTypeRef to_float_type_scalar(struct ac_llvm_context *ctx, 
LLVMTypeRef t)
 {
-   if (t == ctx->i16 || t == ctx->f16)
+   if (t == ctx->i8)
+   return ctx->i8;
+   else if (t == ctx->i16 || t == ctx->f16)
return ctx->f16;
else if (t == ctx->i32 || t == ctx->f32)
return ctx->f32;
diff --git a/src/amd/common/ac_llvm_build.h b/src/amd/common/ac_llvm_build.h
index 723aec53cbe..f6bf473f6a1 100644
--- a/src/amd/common/ac_llvm_build.h
+++ b/src/amd/common/ac_llvm_build.h
@@ -74,6 +74,8 @@ struct ac_llvm_context {
LLVMTypeRef v4f32;
LLVMTypeRef v8i32;
 
+   LLVMValueRef i8_0;
+   LLVMValueRef i8_1;
LLVMValueRef i16_0;
LLVMValueRef i16_1;
LLVMValueRef i32_0;
-- 
2.21.0

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