Re: [Mesa-dev] [RFC PATCH v2 1/6] nv50/ir: add nv50_ir_prog_info_out

[Juan A. Suarez Romero]

On Thu, 2020-03-19 at 21:57 +0100, Mark Menzynski wrote:
> From: Karol Herbst 
> 
> Split out the output relevant fields from the nv50_ir_prog_info struct
> in order to have a cleaner separation between the input and output of
> the compilation.
> 


Please, submit the series through GitLab (
https://www.mesa3d.org/submittingpatches.html#submit)

Thanks!

J.A.


> gned-off-by: Karol Herbst 
> ---
>  .../drivers/nouveau/codegen/nv50_ir.cpp   |  49 ++--
>  src/gallium/drivers/nouveau/codegen/nv50_ir.h |   9 +-
>  .../drivers/nouveau/codegen/nv50_ir_driver.h  | 117 +---
>  .../nouveau/codegen/nv50_ir_from_common.cpp   |  14 +-
>  .../nouveau/codegen/nv50_ir_from_common.h |   3 +-
>  .../nouveau/codegen/nv50_ir_from_nir.cpp  | 204 +++---
>  .../nouveau/codegen/nv50_ir_from_tgsi.cpp | 256 +-
>  .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp |   6 +-
>  .../nouveau/codegen/nv50_ir_target.cpp|   2 +-
>  .../drivers/nouveau/codegen/nv50_ir_target.h  |   5 +-
>  .../nouveau/codegen/nv50_ir_target_nv50.cpp   |  17 +-
>  .../nouveau/codegen/nv50_ir_target_nv50.h |   3 +-
>  .../drivers/nouveau/nouveau_compiler.c|   9 +-
>  .../drivers/nouveau/nv50/nv50_program.c   |  62 +++--
>  .../drivers/nouveau/nvc0/nvc0_program.c   |  87 +++---
>  15 files changed, 449 insertions(+), 394 deletions(-)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> index c65853578f6..c2c5956874a 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir.cpp
> @@ -1241,15 +1241,18 @@ void Program::releaseValue(Value *value)
>  extern "C" {
>  
>  static void
> -nv50_ir_init_prog_info(struct nv50_ir_prog_info *info)
> +nv50_ir_init_prog_info(struct nv50_ir_prog_info *info,
> +   struct nv50_ir_prog_info_out *info_out)
>  {
> +   info_out->target = info->target;
> +   info_out->type = info->type;
> if (info->type == PIPE_SHADER_TESS_CTRL || info->type == 
> PIPE_SHADER_TESS_EVAL) {
> -  info->prop.tp.domain = PIPE_PRIM_MAX;
> -  info->prop.tp.outputPrim = PIPE_PRIM_MAX;
> +  info_out->prop.tp.domain = PIPE_PRIM_MAX;
> +  info_out->prop.tp.outputPrim = PIPE_PRIM_MAX;
> }
> if (info->type == PIPE_SHADER_GEOMETRY) {
> -  info->prop.gp.instanceCount = 1;
> -  info->prop.gp.maxVertices = 1;
> +  info_out->prop.gp.instanceCount = 1;
> +  info_out->prop.gp.maxVertices = 1;
> }
> if (info->type == PIPE_SHADER_COMPUTE) {
>info->prop.cp.numThreads[0] =
> @@ -1257,23 +1260,26 @@ nv50_ir_init_prog_info(struct nv50_ir_prog_info *info)
>info->prop.cp.numThreads[2] = 1;
> }
> info->io.pointSize = 0xff;
> -   info->io.instanceId = 0xff;
> -   info->io.vertexId = 0xff;
> -   info->io.edgeFlagIn = 0xff;
> -   info->io.edgeFlagOut = 0xff;
> -   info->io.fragDepth = 0xff;
> -   info->io.sampleMask = 0xff;
> +   info_out->bin.smemSize = info->bin.smemSize;
> +   info_out->io.genUserClip = info->io.genUserClip;
> +   info_out->io.instanceId = 0xff;
> +   info_out->io.vertexId = 0xff;
> +   info_out->io.edgeFlagIn = 0xff;
> +   info_out->io.edgeFlagOut = 0xff;
> +   info_out->io.fragDepth = 0xff;
> +   info_out->io.sampleMask = 0xff;
> info->io.backFaceColor[0] = info->io.backFaceColor[1] = 0xff;
>  }
>  
>  int
> -nv50_ir_generate_code(struct nv50_ir_prog_info *info)
> +nv50_ir_generate_code(struct nv50_ir_prog_info *info,
> +  struct nv50_ir_prog_info_out *info_out)
>  {
> int ret = 0;
>  
> nv50_ir::Program::Type type;
>  
> -   nv50_ir_init_prog_info(info);
> +   nv50_ir_init_prog_info(info, info_out);
>  
>  #define PROG_TYPE_CASE(a, b)  \
> case PIPE_SHADER_##a: type = nv50_ir::Program::TYPE_##b; break
> @@ -1301,15 +1307,16 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
>return -1;
> }
> prog->driver = info;
> +   prog->driver_out = info_out;
> prog->dbgFlags = info->dbgFlags;
> prog->optLevel = info->optLevel;
>  
> switch (info->bin.sourceRep) {
> case PIPE_SHADER_IR_NIR:
> -  ret = prog->makeFromNIR(info) ? 0 : -2;
> +  ret = prog->makeFromNIR(info, info_out) ? 0 : -2;
>break;
> case PIPE_SHADER_IR_TGSI:
> -  ret = prog->makeFromTGSI(info) ? 0 : -2;
> +  ret = prog->makeFromTGSI(info, info_out) ? 0 : -2;
>break;
> default:
>ret = -1;
> @@ -1320,7 +1327,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
> if (prog->dbgFlags & NV50_IR_DEBUG_VERBOSE)
>prog->print();
>  
> -   targ->parseDriverInfo(info);
> +   targ->parseDriverInfo(info, info_out);
> prog->getTarget()->runLegalizePass(prog, nv50_ir::CG_STAGE_PRE_SSA);
>  
> prog->convertToSSA();
> @@ -1342,7 +1349,7 @@ nv50_ir_generate_code(struct nv50_ir_prog_info *info)
>  
> prog->optimizePostRA(info->optLevel);
>  
> -   

Re: [Mesa-dev] [RFC PATCH 1/2] nv50: Add separate functions for varying bits

[Juan A. Suarez Romero]

On Thu, 2020-03-19 at 21:20 +0100, Mark Menzynski wrote:
> This separation will be needed for shader disk caching. The reason for it
> is that when loading shaders from cache, data in info structure already gets
> loaded. That means varying bits for info is needed only when compiling
> shaders and not needed when loading from cache. Varying bits for prog are
> needed in both cases.
> 
> Unfortunately, I don't know how most of the code works, I have separated
> this manually, only by looking at the original code. That means that this
> patch is experimental. Together with following commit it works
> (there seem to be no regressions at all in VK-GL-CTS
> [openglcts/data/mustpass/gl/khronos_mustpass/4.6.1.x/gl33-master.txt]
> and all benchmarks behaved normally). Unfortunately, I cannot test in
> Piglit because of technical problems, so there might be still some
> work needed.
> 
> I am mainly asking to help with the function names,
> look for bugs and pointing out useless code. I will be glad for every
> review.
> 
> Signed-off-by: Mark Menzynski 


Could you submit the patch through GitLab?

Instructions at https://www.mesa3d.org/submittingpatches.html#submit


J.A.



> ---
>  .../drivers/nouveau/nv50/nv50_program.c   | 344 ++
>  1 file changed, 344 insertions(+)
> 
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_program.c
> index a3f3054cbaa..bf63b20f613 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_program.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c
> @@ -139,6 +139,130 @@ nv50_vertprog_assign_slots(struct nv50_ir_prog_info_out 
> *info)
> return 0;
>  }
>  
> +static int
> +nv50_vertprog_assign_slots_info(struct nv50_ir_prog_info_out *info)
> +{
> +   unsigned i, n, c;
> +
> +   n = 0;
> +   for (i = 0; i < info->numInputs; ++i) {
> +   for (c = 0; c < 4; ++c)
> + if (info->in[i].mask & (1 << c))
> +info->in[i].slot[c] = n++;
> +   }
> +
> +   /* VertexID before InstanceID */
> +   if (info->io.vertexId < info->numSysVals)
> +  info->sv[info->io.vertexId].slot[0] = n++;
> +   if (info->io.instanceId < info->numSysVals)
> +  info->sv[info->io.instanceId].slot[0] = n++;
> +
> +   n = 0;
> +   for (i = 0; i < info->numOutputs; ++i) {
> +  for (c = 0; c < 4; ++c)
> + if (info->out[i].mask & (1 << c))
> +info->out[i].slot[c] = n++;
> +   }
> +
> +   return 0;
> +}
> +
> +static int
> +nv50_vertprog_assign_slots_prog(struct nv50_ir_prog_info_out *info)
> +{
> +   struct nv50_program *prog = (struct nv50_program *)info->driverPriv;
> +   unsigned i, n, c;
> +
> +   n = 0;
> +   for (i = 0; i < info->numInputs; ++i) {
> +  prog->in[i].id = i;
> +  prog->in[i].sn = info->in[i].sn;
> +  prog->in[i].si = info->in[i].si;
> +  prog->in[i].hw = n;
> +  prog->in[i].mask = info->in[i].mask;
> +
> +  prog->vp.attrs[(4 * i) / 32] |= info->in[i].mask << ((4 * i) % 32);
> +
> +  for (c = 0; c < 4; ++c)
> + if (info->in[i].mask & (1 << c))
> +n++;
> +
> +  if (info->in[i].sn == TGSI_SEMANTIC_PRIMID)
> + prog->vp.attrs[2] |= NV50_3D_VP_GP_BUILTIN_ATTR_EN_PRIMITIVE_ID;
> +   }
> +   prog->in_nr = info->numInputs;
> +
> +   for (i = 0; i < info->numSysVals; ++i) {
> +  switch (info->sv[i].sn) {
> +  case TGSI_SEMANTIC_INSTANCEID:
> + prog->vp.attrs[2] |= NV50_3D_VP_GP_BUILTIN_ATTR_EN_INSTANCE_ID;
> + continue;
> +  case TGSI_SEMANTIC_VERTEXID:
> + prog->vp.attrs[2] |= NV50_3D_VP_GP_BUILTIN_ATTR_EN_VERTEX_ID;
> + prog->vp.attrs[2] |= 
> NV50_3D_VP_GP_BUILTIN_ATTR_EN_VERTEX_ID_DRAW_ARRAYS_ADD_START;
> + continue;
> +  default:
> + break;
> +  }
> +   }
> +
> +   /*
> +* Corner case: VP has no inputs, but we will still need to submit data to
> +* draw it. HW will shout at us and won't draw anything if we don't enable
> +* any input, so let's just pretend it's the first one.
> +*/
> +   if (prog->vp.attrs[0] == 0 &&
> +   prog->vp.attrs[1] == 0 &&
> +   prog->vp.attrs[2] == 0)
> +  prog->vp.attrs[0] |= 0xf;
> +
> +   n = 0;
> +   for (i = 0; i < info->numOutputs; ++i) {
> +  switch (info->out[i].sn) {
> +  case TGSI_SEMANTIC_PSIZE:
> + prog->vp.psiz = i;
> + break;
> +  case TGSI_SEMANTIC_CLIPDIST:
> + prog->vp.clpd[info->out[i].si] = n;
> + break;
> +  case TGSI_SEMANTIC_EDGEFLAG:
> + prog->vp.edgeflag = i;
> + break;
> +  case TGSI_SEMANTIC_BCOLOR:
> + prog->vp.bfc[info->out[i].si] = i;
> + break;
> +  case TGSI_SEMANTIC_LAYER:
> + prog->gp.has_layer = true;
> + prog->gp.layerid = n;
> + break;
> +  case TGSI_SEMANTIC_VIEWPORT_INDEX:
> + prog->gp.has_viewport = true;
> + prog->gp.viewportid = n;
> + break;
> +  default:
> + break;
> +  }
> +  

Re: [Mesa-dev] Merge bot ("Marge") enabled

[Juan A. Suarez Romero]

On Fri, 2019-12-13 at 13:35 -0800, Eric Anholt wrote:
> I finally got back around to experimenting with the gitlab merge bot,
> and it turns out that the day I spent a few weeks back I had actually
> given up 5 minutes before the finish line.
> 
> Marge is now enabled for mesa/mesa, piglit, and parallel-deqp-runner.
> How you interact with marge:
> 
> - Collect your reviews
> - Put reviewed-by tags in your commits

I don't know if this is possible, but another cool improvement would be using
the approvals feature to replace reviewed-by: a MR should be approved by at
least one person, and Marge could add this information in the commit as a
"Reviewed-by" tag. This way, we ensure all MR are reviewed, and we don't need to
update the MR manually just to ensure a reviewed-by is added.


> - When you would have clicked "Merge when pipeline succeeds" (or,
> worse, rebase and then merge when pipeline succeeds), instead edit the
> assignee of the MR (top right panel of the UI) and assign to Marge Bot
> - Marge will eventually take your MR, rebase it and let the pipeline run.
> - If the pipeline passes, Marge will merge it
> - If the pipeline fails, Marge will note it in the logs and unassign
> herself (so your next push with a "fix" won't get auto-merged until
> you decide to again).
> 
> In the commit logs of the commits that Marge rebased (they'll always
> be rebased), you'll get:
> 
> Part-of: 
> 
> 
> In the final commit of that MR, you'll get:
> 
> Tested-by: Marge Bot
> 
> 
> I feel like this is a major improvement to our workflow, in terms of
> linking commits directly to their discussions without indirecting
> through google.
> 
> Note that one Marge instance will only process one MR at a time, so we
> could end up backed up.  There's a mode that will form merge trains,
> but I don't understand that mode enough yet to trust it. I think for
> Mesa at this point this is going to be fine, as we should still be
> able to push tens of MRs through per day.  As we scale up, we may find
> that we need a separate Marge for piglit and other projects, which I
> should be able to set up reasonably at this point.
> 
> Once we settle in with Marge and learn to trust our robot overlords,
> I'll update the contributor docs to direct people to Marge instead of
> the "merge when pipeline succeeds" button.  I'm also hoping that once
> our commit logs are full of links to discussions, we can drop the
> mandatory squashing of r-b tags into commit messages and thus make our
> process even easier for new contributors.
> ___
> 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] [ANNOUNCE] Mesa 19.1.8

[Juan A. Suarez Romero]

Mesa 19.1.8 is now available.

NOTE: It is anticipated that 19.1.8 will be the final release in the
19.1 series. Users of 19.1 are encouraged to migrate to the 19.2 series
in order to obtain future fixes.

Apologies for the big delay in this release; there were several regressions 
that we
were investigating, which prevented the pre-release to be on time.

Subject: [ANNOUNCE] mesa 19.1.8
To: mesa-annou...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org

Adam Jackson (1):
  docs: Update bug report URLs for the gitlab migration

Alan Coopersmith (5):
  c99_compat.h: Don't try to use 'restrict' in C++ code
  util: Make Solaris implemention of p_atomic_add work with gcc
  util: Workaround lack of flock on Solaris
  meson: recognize "sunos" as the system name for Solaris
  intel/common: include unistd.h for ioctl() prototype on Solaris

Andreas Gottschling (1):
  drisw: Fix shared memory leak on drawable resize

Andres Gomez (3):
  docs: Add the maximum implemented Vulkan API version in 19.1 rel notes
  docs/features: Update VK_KHR_display_swapchain status
  egl: Remove the 565 pbuffer-only EGL config under X11.

Andrii Simiklit (1):
  glsl: disallow incompatible matrices multiplication

Arcady Goldmints-Orlov (1):
  anv: fix descriptor limits on gen8

Bas Nieuwenhuizen (2):
  tu: Set up glsl types.
  radv: Add workaround for hang in The Surge 2.

Danylo Piliaiev (1):
  st/nine: Ignore D3DSIO_RET if it is the last instruction in a shader

Dylan Baker (5):
  meson: fix logic for generating .pc files with old glvnd
  meson: Try finding libxvmcw via pkg-config before using find_library
  meson: Link xvmc with libxv
  meson: gallium media state trackers require libdrm with x11
  meson: Only error building gallium video without libdrm when the platform 
is drm

Eric Engestrom (4):
  gl: drop incorrect pkg-config file for glvnd
  meson: re-add incorrect pkg-config files with GLVND for backward 
compatibility
  util/anon_file: add missing #include
  util/anon_file: const string param

Erik Faye-Lund (1):
  glsl: correct bitcast-helpers

Greg V (1):
  util: add anon_file.h for all memfd/temp file usage

Haihao Xiang (1):
  i965: support AYUV/XYUV for external import only

Hal Gentz (1):
  gallium/osmesa: Fix the inability to set no context as current.

Jason Ekstrand (2):
  nir/repair_ssa: Replace the unreachable check with the phi builder
  intel/fs: Fix fs_inst::flags_read for ANY/ALL predicates

Juan A. Suarez Romero (12):
  docs: add sha256 checksums for 19.1.7
  cherry-ignore: add explicit 19.2 only nominations
  cherry-ignore: add explicit 19.3 only nominations
  Revert "Revert "intel/fs: Move the scalar-region conversion to the 
generator.""
  cherry-ignore: Revert "gallium: remove PIPE_CAP_TEXTURE_SHADOW_MAP"
  bin/get-pick-list.sh: sha1 commits can be smaller than 8 chars
  cherry-ignore: nir/opt_large_constants: Handle store writemasks
  cherry-ignore: util: added missing headers in anon-file
  cherry-ignore: radv: Fix condition for skipping the continue CS.
  cherry-ignore: Revert "radv: disable viewport clamping even if FS doesn't 
write Z"
  Update version to 19.1.8
  docs: add release notes for 19.1.8

Ken Mays (1):
  haiku: fix Mesa build

Kenneth Graunke (4):
  iris: Initialize ice->state.prim_mode to an invalid value
  intel: Increase Gen11 compute shader scratch IDs to 64.
  iris: Disable CCS_E for 32-bit floating point textures.
  iris: Fix iris_rebind_buffer() for VBOs with non-zero offsets.

Lionel Landwerlin (5):
  anv: gem-stubs: return a valid fd got anv_gem_userptr()
  intel: use proper label for Comet Lake skus
  mesa: don't forget to clear _Layer field on texture unit
  intel: fix subslice computation from topology data
  intel/isl: Set null surface format to R32_UINT

Marek Olšák (1):
  gallium/vl: don't set PIPE_HANDLE_USAGE_EXPLICIT_FLUSH

Matt Turner (1):
  util: Drop preprocessor guards for glibc-2.12

Michel Dänzer (1):
  radeonsi: fix VAAPI segfault due to various bugs

Michel Zou (2):
  scons: add py3 support
  scons: For MinGW use -posix flag.

Paulo Zanoni (1):
  intel/fs: fix SHADER_OPCODE_CLUSTER_BROADCAST for SIMD32

Prodea Alexandru-Liviu (1):
  scons/MSYS2-MinGW-W64: Fix build options defaults

Rhys Perry (2):
  radv: always emit a position export in gs copy shaders
  nir/opt_remove_phis: handle phis with no sources

Samuel Iglesias Gonsálvez (1):
  intel/nir: do not apply the fsin and fcos trig workarounds for consts

Stephen Barber (1):
  nouveau: add idep_nir_headers as dep for libnouveau

Tapani Pälli (3):
  iris: close screen fd on iris_destroy_screen
  egl: check for NULL value like eglGetSyncAttribKHR does
  util: fix os_create_anonymous_file on and

[Mesa-dev] [ANNOUNCE] Mesa 19.1.8 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.8 is now available. Currently we have:
 - 58 queued
 - 0 nominated (outstanding)
 - and 4 rejected patch

NOTE: It is anticipated that 19.1.8 will be the final release in the
19.1 series. Users of 19.1 are encouraged to migrate to the 19.2 series
in order to obtain future fixes.

Apologies for the big delay in this release; there were several regressions 
that we
were investigating, which prevented the pre-release to be on time.

The current queue consist as usual on fixes for different parts.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.8 this Monday (21st October), around or shortly after
12:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit dfcde49122b2d6c0920b3e49cd41ef908f668ccd
Author: Alan Coopersmith 

intel/common: include unistd.h for ioctl() prototype on Solaris

(cherry picked from commit 6804b8e1ff4b62b6685418f773041f10db01f879)


commit 9c100e31a2270067802e949c7a7bd61384540a56
Author: Alan Coopersmith 

meson: recognize "sunos" as the system name for Solaris

(cherry picked from commit d8a9420f6f1a9eabe6dffe19779de9ec8fba9ab0)


commit 13120904e463868e4a6eb51644c5e3a1a2c732e4
Author: Alan Coopersmith 

util: Workaround lack of flock on Solaris

(cherry picked from commit b3028a9fb8110fd37f60e9d66dad3cde6e7b062b)


commit 142e51da08f76122176db412941972ca52b2ef7b
Author: Andres Gomez 

egl: Remove the 565 pbuffer-only EGL config under X11.

(cherry picked from commit 02c265be9dcc5c5c23123e716ef62b384540d2fa)


commit 450b808eea7979f973fec7f248a0f3c32e7932a1
Author: Lionel Landwerlin 

intel: use proper label for Comet Lake skus

(cherry picked from commit 813f3460e7d331ad752c48ee08ca8988f8bfabd7)


commit a74657d4aaf40297d575c893d41165eaccc61eb3
Author: Eric Engestrom 

meson: re-add incorrect pkg-config files with GLVND for backward 
compatibility

(cherry picked from commit 93df862b6affb6b8507e40601212a58012bfa873)


commit 9e754647ba88ab9d22a45db5c72a1eaf6bed4afe
Author: Andres Gomez 

docs/features: Update VK_KHR_display_swapchain status

(cherry picked from commit bcd9224728dcb8d8fe4bcddc4bd9b2c36fcfe9dd)


commit d11d2c6def76e6a269afc7bd2a1c68e5b3ee0166
Author: Tapani Pälli 

iris: close screen fd on iris_destroy_screen

(cherry picked from commit 631255387f0469910db99eccbfbaa63345425739)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (58)
===
Adam Jackson (1):
  docs: Update bug report URLs for the gitlab migration

Alan Coopersmith (5):
  c99_compat.h: Don't try to use 'restrict' in C++ code
  util: Make Solaris implemention of p_atomic_add work with gcc
  util: Workaround lack of flock on Solaris
  meson: recognize "sunos" as the system name for Solaris
  intel/common: include unistd.h for ioctl() prototype on Solaris

Andreas Gottschling (1):
  drisw: Fix shared memory leak on drawable resize

Andres Gomez (3):
  docs: Add the maximum implemented Vulkan API version in 19.1 rel notes
  docs/features: Update VK_KHR_display_swapchain status
  egl: Remove the 565 pbuffer-only EGL config under X11.

Andrii Simiklit (1):
  glsl: disallow incompatible matrices multiplication

Arcady Goldmints-Orlov (1):
  anv: fix descriptor limits on gen8

Bas Nieuwenhuizen (2):
  tu: Set up glsl types.
  radv: Add workaround for hang in The Surge 2.

Danylo Piliaiev (1):
  st/nine: Ignore D3DSIO_RET if it is the last instruction in a shader

Dylan Baker (5):
  meson: fix logic for generating .pc files with old glvnd
  meson: Try finding libxvmcw via pkg-config before using find_library
  meson: Link xvmc with libxv
  meson: gallium media state trackers require libdrm with x11
  meson: Only error building gallium video without libdrm when the platform 
is drm

Eric Engestrom (4):
  gl: drop incorrect pkg-config file for glvnd
  meson: re-add incorrect pkg-config files with GLVND for backward 
compatibility
  util/anon_file: add missing #include
  util/anon_file: const string param

Erik Faye-Lund (1):
  glsl: correct bitcast-helpers

Greg V (1):
  util: add anon_file.h for all memfd/temp file usage

Haihao Xiang (1):
  i965: support AYUV/XYUV for external import only

Hal Gentz (1):
  gallium/osmesa: Fix the inability to set no context as current.

Jason Ekstrand (2):
  nir/repair_ssa: Replace the unreachable check with the phi builder
  intel/fs: Fix fs_inst::flags_read for ANY/ALL predicates

Juan A. Suarez Romero (2):
  

Re: [Mesa-dev] Release workflow with gitlab issues

[Juan A. Suarez Romero]

On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote:
> Adding the release managers to the CC to make sure they see the thread...
> 
> Dylan Baker  writes:
> 
> > Hi everyone,
> > 
> > Since we're migrating to gitlab issues, it seems like a good time to review 
> > how
> > we track stable releases, particularly release blockers.
> > 
> > I'd like to use a gitlab milestone as a replacement for the tracker issues 
> > from
> > gitlab. The process would work much the same way as it does now, but with a
> > milestone.
> 
> Right now, anyone can create milestones.  Is there a way to limit the
> capability to release managers?  Would that be desirable?
> 
> I see the same issue with labels...  Anyone could delete a label, and
> I'm not sure how we would recover that information.
> 
> > We'll also need to replace the Bugzilla: tag with a tag that gitlab 
> > recognizes
> > for closing issues. Since we already use "Fixes:" for something else, I'd 
> > like
> > to propose "Closes:"
> > 
> > so we'd replace:
> > Buzilla: https://...
> > with:
> > Closes: !0
> 
> A more exact replacement would be:
>   Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/{issue}
> 

I also prefer this format. This would allow to reference other issues not in the
GitLab.

> Is there an advantage to the !{issue} format?  Perhaps gitlab parses it
> and closes the issue?
> 

Yes, it does when you write something like "closes #issue". But I think I prefer
to close the issue manually; several times I saw MR that should fix an issue but
they actually didn't either because it requires other MR, or because there was
another change in master that requires another change, etc.



> > If we like this, I'll follow up with a script that can fetch issues 
> > information
> > from gitlab and produce release information.
> > 
> > Does this sound reasonable to everyone?
> > 


Sounds nice for me.

J.A.

> > Dylan
> > ___
> > 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] [ANNOUNCE] Mesa 19.1.7

[Juan A. Suarez Romero]

Mesa 19.1.7 is now available.


Caio Marcelo de Oliveira Filho (1):
  glsl/nir: Avoid overflow when setting max_uniform_location

Connor Abbott (1):
  radv: Call nir_propagate_invariant()

Danylo Piliaiev (1):
  tgsi_to_nir: Translate TGSI_INTERPOLATE_COLOR as INTERP_MODE_NONE

Eric Engestrom (10):
  ttn: fix 64-bit shift on 32-bit `1`
  egl: fix deadlock in malloc error path
  util/os_file: fix double-close()
  anv: fix format string in error message
  nir: fix memleak in error path
  anv: add support for driconf
  wsi: add minImageCount override
  anv: add support for vk_x11_override_min_image_count
  amd: move adaptive sync to performance section, as it is defined in 
xmlpool
  radv: add support for vk_x11_override_min_image_count

Erik Faye-Lund (2):
  gallium/auxiliary/indices: consistently apply start only to input
  util: fix SSE-version needed for double opcodes

Hal Gentz (1):
  glx: Fix SEGV due to dereferencing a NULL ptr from XCB-GLX.

Jason Ekstrand (7):
  Revert "intel/fs: Move the scalar-region conversion to the generator."
  anv: Bump maxComputeWorkgroupSize
  nir: Don't infinitely recurse in lower_ssa_defs_to_regs_block
  nir: Add a block_is_unreachable helper
  nir/repair_ssa: Repair dominance for unreachable blocks
  nir/repair_ssa: Insert deref casts when needed
  nir/dead_cf: Repair SSA if the pass makes progress

Juan A. Suarez Romero (4):
  docs: add sha256 checksums for 19.1.6
  cherry-ignore: add explicit 19.2 only nominations
  Update version to 19.1.7
  docs: add release notes for 19.1.7

Kenneth Graunke (1):
  gallium: Fix util_format_get_depth_only

Lionel Landwerlin (1):
  vulkan/overlay: bounce image back to present layout

Mauro Rossi (3):
  android: radv: fix necessary dependecies
  android: amd/common: fix missing include path
  android: anv: libmesa_vulkan_common: add libmesa_util static dependency

Samuel Pitoiset (1):
  radv: fix allocating number of user sgprs if streamout is used

Sergii Romantsov (1):
  intel/dri: finish proper glthread

git tag: mesa-19.1.7

https://mesa.freedesktop.org/archive/mesa-19.1.7.tar.xz
MD5:  cd1345c9b0d5121b860a0bdb20abc347  mesa-19.1.7.tar.xz
SHA1: 5fcd2ee01087c821b5e644e007bb491563b9d4e0  mesa-19.1.7.tar.xz
SHA256: e287920fdb38712a9fed448dc90b3ca95048c7face5db52e58361f8b6e0f3cd5  
mesa-19.1.7.tar.xz
SHA512: 
0865b5f91e5daa00e1da2b3d8b65fe5d2ff6332372bf8fec7d671d05d8d64ec5a7abea1858cdfc506c76b7226d2bea0af3426565f156b796d8e0f949ea33dc15
  mesa-19.1.7.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.7.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.7 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.7 is now available. Currently we have:
 - 30 queued
 - 0 nominated (outstanding)
 - and 0 rejected patch


The current queue consist as usual on fixes for different parts.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.7 this Tuesday (17th September), around or shortly 
after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit 2959de1f92018919c42f2c445fadfc4a01a699e7 (HEAD -> 19.1, 
origin/staging/19.1, staging/19.1)
Author: Samuel Pitoiset 

radv: fix allocating number of user sgprs if streamout is used

(cherry picked from commit 8137df3a46abc6aa6ad0c7179d042e76ca2b2299)


commit 01d452de585560868359729ca459437298789485
Author: Jason Ekstrand 

nir: Don't infinitely recurse in lower_ssa_defs_to_regs_block

(cherry picked from commit 517142252f0c63189293c7176efbf490b7ae95ea)


commit 2977a3e0e1a5f0950001e12402c9936e5d38ab9e
Author: Eric Engestrom 

anv: add support for driconf

(cherry picked from commit 4dcb1fff19383ae451f3228e55d3fc987a7ab46d)


commit 5fcb149a461c3025d643df7aa0713b1d64ab0a6f
Author: Eric Engestrom 

egl: fix deadlock in malloc error path

(cherry picked from commit 43d470404c47d86d1fab93d1345e09375bcf4fb6)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (30)
===
Caio Marcelo de Oliveira Filho (1):
  glsl/nir: Avoid overflow when setting max_uniform_location

Connor Abbott (1):
  radv: Call nir_propagate_invariant()

Danylo Piliaiev (1):
  tgsi_to_nir: Translate TGSI_INTERPOLATE_COLOR as INTERP_MODE_NONE

Eric Engestrom (10):
  ttn: fix 64-bit shift on 32-bit `1`
  egl: fix deadlock in malloc error path
  util/os_file: fix double-close()
  anv: fix format string in error message
  nir: fix memleak in error path
  anv: add support for driconf
  wsi: add minImageCount override
  anv: add support for vk_x11_override_min_image_count
  amd: move adaptive sync to performance section, as it is defined in 
xmlpool
  radv: add support for vk_x11_override_min_image_count

Erik Faye-Lund (2):
  gallium/auxiliary/indices: consistently apply start only to input
  util: fix SSE-version needed for double opcodes

Hal Gentz (1):
  glx: Fix SEGV due to dereferencing a NULL ptr from XCB-GLX.

Jason Ekstrand (7):
  Revert "intel/fs: Move the scalar-region conversion to the generator."
  anv: Bump maxComputeWorkgroupSize
  nir: Don't infinitely recurse in lower_ssa_defs_to_regs_block
  nir: Add a block_is_unreachable helper
  nir/repair_ssa: Repair dominance for unreachable blocks
  nir/repair_ssa: Insert deref casts when needed
  nir/dead_cf: Repair SSA if the pass makes progress

Kenneth Graunke (1):
  gallium: Fix util_format_get_depth_only

Lionel Landwerlin (1):
  vulkan/overlay: bounce image back to present layout

Mauro Rossi (3):
  android: radv: fix necessary dependecies
  android: amd/common: fix missing include path
  android: anv: libmesa_vulkan_common: add libmesa_util static dependency

Samuel Pitoiset (1):
  radv: fix allocating number of user sgprs if streamout is used

Sergii Romantsov (1):
  intel/dri: finish proper glthread


Rejected (0)
=


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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.6

[Juan A. Suarez Romero]

Mesa 19.1.6 is now available.


Andres Rodriguez (1):
  radv: additional query fixes

Daniel Schürmann (1):
  nir/lcssa: handle deref instructions properly

Danylo Piliaiev (1):
  nir/loop_unroll: Prepare loop for unrolling in wrapper_unroll

Ian Romanick (2):
  nir/algrbraic: Don't optimize open-coded bitfield reverse when lowering 
is enabled
  intel/compiler: Request bitfield_reverse lowering on pre-Gen7 hardware

Ilia Mirkin (1):
  gallium/vl: use compute preference for all multimedia, not just blit

Jonas Ådahl (1):
  wayland/egl: Ensure correct buffer size when allocating

Juan A. Suarez Romero (7):
  docs: add sha256 checksums for 19.1.5
  cherry-ignore: add explicit 19.2 only nominations
  cherry-ignore: iris: Replace devinfo->gen with GEN_GEN
  cherry-ignore: iris: Update fast clear colors on Gen9 with direct 
immediate writes.
  cherry-ignore: iris: Avoid unnecessary resolves on transfer maps
  Update version to 19.1.6
  docs: add release notes for 19.1.6

Kenneth Graunke (6):
  iris: Fix broken aux.possible/sampler_usages bitmask handling
  iris: Drop copy format hacks from copy region based transfer path.
  iris: Fix large timeout handling in rel2abs()
  util: Add a _mesa_i64roundevenf() helper.
  mesa: Fix _mesa_float_to_unorm() on 32-bit systems.
  intel/compiler: Fix src0/desc setter ordering

Marek Olšák (1):
  radeonsi: fix scratch buffer WAVESIZE setting leading to corruption

Paulo Zanoni (1):
  intel/fs: grab fail_msg from v32 instead of v16 when v32->run_cs fails

Pierre-Eric Pelloux-Prayer (1):
  glsl: replace 'x + (-x)' with constant 0

Tapani Pälli (1):
  egl: reset blob cache set/get functions on terminate

git tag: mesa-19.1.6

https://mesa.freedesktop.org/archive/mesa-19.1.6.tar.xz
MD5:  7dbb40b8d10e89bee0a5bfc85350647b  mesa-19.1.6.tar.xz
SHA1: 6344c54ff6f66c85c1f0a44a96259263163f9969  mesa-19.1.6.tar.xz
SHA256: 2a369b7b48545c6486e7e44913ad022daca097c8bd937bf30dcf3f17a94d3496  
mesa-19.1.6.tar.xz
SHA512: 
399ce97a293769893ef9a4a6af1f77c7d835f5405bdbc03bbf9b73e052e4ff3b43dec5dafd6b9fedaaf2c59531aeccaa0f685a8bfdc5719a26c3815fc7f68024
  mesa-19.1.6.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.6.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.6 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.6 is now available. Currently we have:
 - 17 queued
 - 0 nominated (outstanding)
 - and 3 rejected patch


The current queue consist as usual on fixes for different parts, but nothing 
outstanding.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.6 this Tuesday (3rd September), around or shortly after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit 938adab8ea75dd473440efa8e7e8719982065eb1
Author: Ian Romanick 

intel/compiler: Request bitfield_reverse lowering on pre-Gen7 hardware

(cherry picked from commit b418269d7dd576a7c9afd728bf8a883b4da98b30)


commit e4df7ffc23e8b48e852c95a7083f6cb86751134f
Author: Paulo Zanoni 

intel/fs: grab fail_msg from v32 instead of v16 when v32->run_cs fails

(cherry picked from commit 848d5e444a881a1a3ac6824f07d95988b312530b)


commit c1959aa26d4fa3c85a23fed2d5588501f2d729c5
Author: Andres Rodriguez 

radv: additional query fixes

(cherry picked from commit a410823b3ede9ff3bf7f56ffca295d1b3d04dbad)


commit 8ad62264d1aba61091994a2a30df076833316701
Author: Kenneth Graunke 

iris: Fix broken aux.possible/sampler_usages bitmask handling

(cherry picked from commit 117a0368b0cc741aec88d2538ffdebd26618a6fb)


commit ac0f71a4afa823f4a6d95bdf0d48cc71d3654c37
Author: Ilia Mirkin 

gallium/vl: use compute preference for all multimedia, not just blit

(cherry picked from commit 958390a9bf8904522a50f8e9c26c50c96179c183)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (17)
===
Andres Rodriguez (1):
  radv: additional query fixes

Daniel Schürmann (1):
  nir/lcssa: handle deref instructions properly

Danylo Piliaiev (1):
  nir/loop_unroll: Prepare loop for unrolling in wrapper_unroll

Ian Romanick (2):
  nir/algrbraic: Don't optimize open-coded bitfield reverse when lowering 
is enabled
  intel/compiler: Request bitfield_reverse lowering on pre-Gen7 hardware

Ilia Mirkin (1):
  gallium/vl: use compute preference for all multimedia, not just blit

Jonas Ådahl (1):
  wayland/egl: Ensure correct buffer size when allocating

Kenneth Graunke (6):
  iris: Fix broken aux.possible/sampler_usages bitmask handling
  iris: Drop copy format hacks from copy region based transfer path.
  iris: Fix large timeout handling in rel2abs()
  util: Add a _mesa_i64roundevenf() helper.
  mesa: Fix _mesa_float_to_unorm() on 32-bit systems.
  intel/compiler: Fix src0/desc setter ordering

Marek Olšák (1):
  radeonsi: fix scratch buffer WAVESIZE setting leading to corruption

Paulo Zanoni (1):
  intel/fs: grab fail_msg from v32 instead of v16 when v32->run_cs fails

Pierre-Eric Pelloux-Prayer (1):
  glsl: replace 'x + (-x)' with constant 0

Tapani Pälli (1):
  egl: reset blob cache set/get functions on terminate


Rejected (3)
=
Kenneth Graunke (3):
  2d799250346 iris: Avoid unnecessary resolves on transfer maps
Reason: This commit depends on commits 77a1070d366a and df4c2ec5e19b
in order to compile, which did not land in the branch.

  1cd13ccee7b iris: Update fast clear colors on Gen9 with direct immediate 
writes.
  f6c44549ee2 iris: Replace devinfo->gen with GEN_GEN
Reason: These two commits do not apply cleanly on 19.1 branch, as they depend on
other commits not present in the branch.


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

Re: [Mesa-dev] [PATCH] gallium/vl: use compute preference for all multimedia, not just blit

[Juan A. Suarez Romero]

On Sat, 2019-08-17 at 12:17 -0400, Ilia Mirkin wrote:
> The compute paths in vl are a bit AMD-specific. For example, they (on
> nouveau), try to use a BGRX8 image format, which is not supported.
> Fixing all this is probably possible, but since the compute paths aren't
> in any way better, it's difficult to care.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111213
> Fixes: 9364d66cb7 (gallium/auxiliary/vl: Add video compositor compute shader 
> render)
> 
> Signed-off-by: Ilia Mirkin 
> ---


This patch didn't apply cleanly on 19.1 branch. I've resolved the conflict as 
https://gitlab.freedesktop.org/mesa/mesa/commit/ac0f71a4afa823f4a6d95bdf0d48cc71d3654c37

J.A.

>  src/gallium/auxiliary/util/u_screen.c| 2 +-
>  src/gallium/auxiliary/vl/vl_compositor.c | 2 +-
>  src/gallium/docs/source/screen.rst   | 4 ++--
>  src/gallium/drivers/radeonsi/si_get.c| 2 +-
>  src/gallium/include/pipe/p_defines.h | 2 +-
>  src/gallium/state_trackers/va/postproc.c | 2 +-
>  6 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_screen.c 
> b/src/gallium/auxiliary/util/u_screen.c
> index 0b4bb067d6d..88f4945e755 100644
> --- a/src/gallium/auxiliary/util/u_screen.c
> +++ b/src/gallium/auxiliary/util/u_screen.c
> @@ -331,7 +331,7 @@ u_pipe_screen_get_param_defaults(struct pipe_screen 
> *pscreen,
> case PIPE_CAP_TGSI_ATOMFADD:
> case PIPE_CAP_TGSI_SKIP_SHRINK_IO_ARRAYS:
> case PIPE_CAP_IMAGE_LOAD_FORMATTED:
> -   case PIPE_CAP_PREFER_COMPUTE_BLIT_FOR_MULTIMEDIA:
> +   case PIPE_CAP_PREFER_COMPUTE_FOR_MULTIMEDIA:
> case PIPE_CAP_FRAGMENT_SHADER_INTERLOCK:
> case PIPE_CAP_CS_DERIVED_SYSTEM_VALUES_SUPPORTED:
> case PIPE_CAP_ATOMIC_FLOAT_MINMAX:
> diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
> b/src/gallium/auxiliary/vl/vl_compositor.c
> index 04808e80d84..a381af108b3 100644
> --- a/src/gallium/auxiliary/vl/vl_compositor.c
> +++ b/src/gallium/auxiliary/vl/vl_compositor.c
> @@ -764,7 +764,7 @@ vl_compositor_init(struct vl_compositor *c, struct 
> pipe_context *pipe)
>  
> memset(c, 0, sizeof(*c));
>  
> -   c->pipe_cs_composit_supported = pipe->screen->get_param(pipe->screen, 
> PIPE_CAP_COMPUTE) &&
> +   c->pipe_cs_composit_supported = pipe->screen->get_param(pipe->screen, 
> PIPE_CAP_PREFER_COMPUTE_FOR_MULTIMEDIA) &&
>  pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_TEX_TXF_LZ) 
> &&
>  pipe->screen->get_param(pipe->screen, PIPE_CAP_TGSI_DIV);
>  
> diff --git a/src/gallium/docs/source/screen.rst 
> b/src/gallium/docs/source/screen.rst
> index c033321ec66..d149a2f4c9f 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -528,8 +528,8 @@ The integer capabilities:
>execution. 0 = throttling is disabled.
>  * ``PIPE_CAP_DMABUF``: Whether Linux DMABUF handles are supported by
>resource_from_handle and resource_get_handle.
> -* ``PIPE_CAP_PREFER_COMPUTE_BLIT_FOR_MULTIMEDIA``: Whether VDPAU, VAAPI, and
> -  OpenMAX should use a compute-based blit instead of pipe_context::blit.
> +* ``PIPE_CAP_PREFER_COMPUTE_FOR_MULTIMEDIA``: Whether VDPAU, VAAPI, and
> +  OpenMAX should use a compute-based blit instead of pipe_context::blit and 
> compute pipeline for compositing images.
>  * ``PIPE_CAP_FRAGMENT_SHADER_INTERLOCK``: True if fragment shader interlock
>functionality is supported.
>  * ``PIPE_CAP_CS_DERIVED_SYSTEM_VALUES_SUPPORTED``: True if driver handles
> diff --git a/src/gallium/drivers/radeonsi/si_get.c 
> b/src/gallium/drivers/radeonsi/si_get.c
> index c9895edafb8..f85a53393aa 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -156,7 +156,7 @@ static int si_get_param(struct pipe_screen *pscreen, enum 
> pipe_cap param)
>   case PIPE_CAP_FBFETCH:
>   case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
>   case PIPE_CAP_IMAGE_LOAD_FORMATTED:
> - case PIPE_CAP_PREFER_COMPUTE_BLIT_FOR_MULTIMEDIA:
> + case PIPE_CAP_PREFER_COMPUTE_FOR_MULTIMEDIA:
>   case PIPE_CAP_TGSI_DIV:
>   return 1;
>  
> diff --git a/src/gallium/include/pipe/p_defines.h 
> b/src/gallium/include/pipe/p_defines.h
> index 0c79cac5cff..808c2b8cfaf 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -885,7 +885,7 @@ enum pipe_cap
> PIPE_CAP_IMAGE_LOAD_FORMATTED,
> PIPE_CAP_MAX_FRAMES_IN_FLIGHT,
> PIPE_CAP_DMABUF,
> -   PIPE_CAP_PREFER_COMPUTE_BLIT_FOR_MULTIMEDIA,
> +   PIPE_CAP_PREFER_COMPUTE_FOR_MULTIMEDIA,
> PIPE_CAP_FRAGMENT_SHADER_INTERLOCK,
> PIPE_CAP_FBFETCH_COHERENT,
> PIPE_CAP_CS_DERIVED_SYSTEM_VALUES_SUPPORTED,
> diff --git a/src/gallium/state_trackers/va/postproc.c 
> b/src/gallium/state_trackers/va/postproc.c
> index fbc55b7714b..3431b1b48c7 100644
> --- a/src/gallium/state_trackers/va/postproc.c
> +++ b/src/gallium/state_trackers/va/postproc.c
> @@ -222,7 +222,7 @@ static VAStatus vlVaPostProcBlit(vlVaDriver 

[Mesa-dev] [ANNOUNCE] Mesa 19.1.5

[Juan A. Suarez Romero]

Mesa 19.1.5 is now available.


Bas Nieuwenhuizen (4):
  radv: Do non-uniform lowering before bool lowering.
  ac/nir: Use correct cast for readfirstlane and ptrs.
  radv: Avoid binning RAVEN hangs.
  radv: Avoid VEGA/RAVEN scissor bug in binning.

Danylo Piliaiev (1):
  i965: Emit a dummy MEDIA_VFE_STATE before switching from GPGPU to 3D

Eric Engestrom (1):
  util: fix mem leak of program path

Erik Faye-Lund (2):
  gallium/dump: add missing query-type to short-list
  gallium/dump: add missing query-type to short-list

Greg V (2):
  anv: remove unused Linux-specific include
  intel/perf: use MAJOR_IN_SYSMACROS/MAJOR_IN_MKDEV

Jason Ekstrand (1):
  anv: Emit a dummy MEDIA_VFE_STATE before switching from GPGPU to 3D

Juan A. Suarez Romero (4):
  docs: add sha256 checksums for 19.1.4
  cherry-ignore: panfrost: Make ctx->job useful
  Update version to 19.1.5
  docs: add release notes for 19.1.5

Marek Olšák (2):
  radeonsi: disable SDMA image copies on dGPUs to fix corruption in games
  radeonsi: fix an assertion failure: assert(!res->b.is_shared)

Matt Turner (1):
  meson: Test for program_invocation_name

Sergii Romantsov (1):
  i965/clear: clear_value better precision

git tag: mesa-19.1.5

https://mesa.freedesktop.org/archive/mesa-19.1.5.tar.xz
MD5:  f64a67ac6f274acc84cd1fd7e325ce98  mesa-19.1.5.tar.xz
SHA1: 7a80ac32b4da4066dd00b3dc8274682be18b35cb  mesa-19.1.5.tar.xz
SHA256: 7b54e14e35c7251b171b4cf9d84cbc1d760eafe00132117db193454999cd6eb4  
mesa-19.1.5.tar.xz
SHA512: 
4d4b3733c13e5c9b3172127f2565b827dc46aab69bdc86791c457ad137a5571c51e3c3a26d5a99e11fe552829a1220028a3968f3086959e038c615f2d75675a4
  mesa-19.1.5.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.5.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.5 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.5 is now available. Currently we have:
 - 15 queued
 - 1 nominated (outstanding)
 - and 1 rejected patch


The current queue is not as big as in previous releases, and it is as usual 
mostly fixes.


Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.5 this Friday (23th August), around or shortly after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit c4ab0e18bbd99664b364936c039edbd7757385c0
Author: Bas Nieuwenhuizen 

radv: Avoid VEGA/RAVEN scissor bug in binning.

(cherry picked from commit 23a9d20997517dfff7f35e3a6c2b954564f0f6c4)


commit 908d85ffce745ea3e417f807d3f9db6fdd9c3f55
Author: Bas Nieuwenhuizen 

radv: Avoid binning RAVEN hangs.

(cherry picked from commit 4a3f987afda6469f274485e9f8b4ecc2308ad815)


commit f837d0a6a36ba2ce2699ff6935c6275ef7dd10e9
Author: Marek Olšák 

radeonsi: disable SDMA image copies on dGPUs to fix corruption in games

(cherry picked from commit 6b3ee86989edb854094d3aba122b40498fca94d8)


Cheers,
J.A.


Mesa stable queue
-

Nominated (1)
==
Daniel Schürmann (1):
204846ad062 nir/lcssa: handle deref instructions properly


Queued (15)
===
Bas Nieuwenhuizen (4):
  radv: Do non-uniform lowering before bool lowering.
  ac/nir: Use correct cast for readfirstlane and ptrs.
  radv: Avoid binning RAVEN hangs.
  radv: Avoid VEGA/RAVEN scissor bug in binning.

Danylo Piliaiev (1):
  i965: Emit a dummy MEDIA_VFE_STATE before switching from GPGPU to 3D

Eric Engestrom (1):
  util: fix mem leak of program path

Erik Faye-Lund (2):
  gallium/dump: add missing query-type to short-list
  gallium/dump: add missing query-type to short-list

Greg V (2):
  anv: remove unused Linux-specific include
  intel/perf: use MAJOR_IN_SYSMACROS/MAJOR_IN_MKDEV

Jason Ekstrand (1):
  anv: Emit a dummy MEDIA_VFE_STATE before switching from GPGPU to 3D

Marek Olšák (2):
  radeonsi: disable SDMA image copies on dGPUs to fix corruption in games
  radeonsi: fix an assertion failure: assert(!res->b.is_shared)

Matt Turner (1):
  meson: Test for program_invocation_name

Sergii Romantsov (1):
  i965/clear: clear_value better precision


Rejected (1)
=
Boris Brezillon (1):
  20b00e1ff24 panfrost: Make ctx->job useful
Reason: This commit requires other commits not landed in branch.


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

Re: [Mesa-dev] [PATCH v2 1/9] panfrost: Make ctx->job useful

[Juan A. Suarez Romero]

On Thu, 2019-08-08 at 15:28 +0200, Boris Brezillon wrote:
> On Thu, 8 Aug 2019 06:08:05 -0700
> Alyssa Rosenzweig  wrote:
> 
> > @Boris I don't see why this patch particularly needs to be backported to
> > 19.1?
> 
> Nope, no reason to backport it to 19.1. It's just a (bad?) kernel dev
> habit to put "Fixes:" tag the patch fixes a problem introduced by a
> previous commit. But it does not necessarily means "backport to stable"
> in mind.
> 

If a patch fixes another patch that is in the stable branch, we try at our best
to include the fix also in the stable branch. I think it makes sense to fix
something that is already in stable.

But if you think this fix is not worth to be on stable, that's fine. I'll keep
it ignored.

Thanks!

> > On Thu, Aug 08, 2019 at 11:46:43AM +0200, Juan A. Suarez Romero wrote:
> > > On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:  
> > > > ctx->job is supposed to serve as a cache to avoid an hash table lookup
> > > > everytime we access the job attached to the currently bound FB, except
> > > > it was never assigned to anything but NULL.
> > > > 
> > > > Fix that by adding the missing assignment in panfrost_get_job_for_fbo().
> > > > Also add a missing NULL assignment in the ->set_framebuffer_state()
> > > > path.
> > > > 
> > > > While at it, add extra assert()s to make sure ctx->job is consistent.
> > > > 
> > > > Fixes: 59c9623d0a75 ("panfrost: Import job data structures from v3d")
> > > > Signed-off-by: Boris Brezillon 
> > > > Changes in v2:
> > > > * New patch (suggested by Alyssa)  
> > > 
> > > This patch is a candidate for 19.1, but unfortunately it does not apply 
> > > cleanly.
> > > It seems it depends on a bunch of other commits not in 19.1
> > > 
> > > At this point, I will ignore/reject this patch for 19.1, unless you can 
> > > provide
> > > me a specific version for 19.1 branch (use staging/19.1 as reference).
> > > 
> > > Thanks.
> > > 
> > >   J.A.
> > >   
> > > > ---
> > > >  src/gallium/drivers/panfrost/pan_context.c |  5 +
> > > >  src/gallium/drivers/panfrost/pan_job.c | 19 ++-
> > > >  2 files changed, 23 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/gallium/drivers/panfrost/pan_context.c 
> > > > b/src/gallium/drivers/panfrost/pan_context.c
> > > > index 014f8f6a9d07..ba2df2ce66ae 100644
> > > > --- a/src/gallium/drivers/panfrost/pan_context.c
> > > > +++ b/src/gallium/drivers/panfrost/pan_context.c
> > > > @@ -2372,6 +2372,11 @@ panfrost_set_framebuffer_state(struct 
> > > > pipe_context *pctx,
> > > >  panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
> > > >  }
> > > >  
> > > > +/* Invalidate the FBO job cache since we've just been assigned 
> > > > a new
> > > > + * FB state.
> > > > + */
> > > > +ctx->job = NULL;
> > > > +
> > > >  util_copy_framebuffer_state(>pipe_framebuffer, fb);
> > > >  
> > > >  /* Given that we're rendering, we'd love to have compression */
> > > > diff --git a/src/gallium/drivers/panfrost/pan_job.c 
> > > > b/src/gallium/drivers/panfrost/pan_job.c
> > > > index 6339b39d29a0..cc81d475165e 100644
> > > > --- a/src/gallium/drivers/panfrost/pan_job.c
> > > > +++ b/src/gallium/drivers/panfrost/pan_job.c
> > > > @@ -23,6 +23,8 @@
> > > >   *
> > > >   */
> > > >  
> > > > +#include 
> > > > +
> > > >  #include "pan_context.h"
> > > >  #include "util/hash_table.h"
> > > >  #include "util/ralloc.h"
> > > > @@ -124,8 +126,13 @@ panfrost_get_job_for_fbo(struct panfrost_context 
> > > > *ctx)
> > > >  
> > > >  /* If we already began rendering, use that */
> > > >  
> > > > -if (ctx->job)
> > > > +if (ctx->job) {
> > > > +assert(ctx->job->key.zsbuf == 
> > > > ctx->pipe_framebuffer.zsbuf &&
> > > > +   !memcmp(ctx->job->key.cbufs,
> > > > +   ctx->pipe_framebuffer.cbufs,
> > > > +   

Re: [Mesa-dev] [PATCH v2 1/9] panfrost: Make ctx->job useful

[Juan A. Suarez Romero]

On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:
> ctx->job is supposed to serve as a cache to avoid an hash table lookup
> everytime we access the job attached to the currently bound FB, except
> it was never assigned to anything but NULL.
> 
> Fix that by adding the missing assignment in panfrost_get_job_for_fbo().
> Also add a missing NULL assignment in the ->set_framebuffer_state()
> path.
> 
> While at it, add extra assert()s to make sure ctx->job is consistent.
> 
> Fixes: 59c9623d0a75 ("panfrost: Import job data structures from v3d")
> Signed-off-by: Boris Brezillon 
> Changes in v2:
> * New patch (suggested by Alyssa)


This patch is a candidate for 19.1, but unfortunately it does not apply cleanly.
It seems it depends on a bunch of other commits not in 19.1

At this point, I will ignore/reject this patch for 19.1, unless you can provide
me a specific version for 19.1 branch (use staging/19.1 as reference).

Thanks.

J.A.

> ---
>  src/gallium/drivers/panfrost/pan_context.c |  5 +
>  src/gallium/drivers/panfrost/pan_job.c | 19 ++-
>  2 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_context.c 
> b/src/gallium/drivers/panfrost/pan_context.c
> index 014f8f6a9d07..ba2df2ce66ae 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -2372,6 +2372,11 @@ panfrost_set_framebuffer_state(struct pipe_context 
> *pctx,
>  panfrost_flush(pctx, NULL, PIPE_FLUSH_END_OF_FRAME);
>  }
>  
> +/* Invalidate the FBO job cache since we've just been assigned a new
> + * FB state.
> + */
> +ctx->job = NULL;
> +
>  util_copy_framebuffer_state(>pipe_framebuffer, fb);
>  
>  /* Given that we're rendering, we'd love to have compression */
> diff --git a/src/gallium/drivers/panfrost/pan_job.c 
> b/src/gallium/drivers/panfrost/pan_job.c
> index 6339b39d29a0..cc81d475165e 100644
> --- a/src/gallium/drivers/panfrost/pan_job.c
> +++ b/src/gallium/drivers/panfrost/pan_job.c
> @@ -23,6 +23,8 @@
>   *
>   */
>  
> +#include 
> +
>  #include "pan_context.h"
>  #include "util/hash_table.h"
>  #include "util/ralloc.h"
> @@ -124,8 +126,13 @@ panfrost_get_job_for_fbo(struct panfrost_context *ctx)
>  
>  /* If we already began rendering, use that */
>  
> -if (ctx->job)
> +if (ctx->job) {
> +assert(ctx->job->key.zsbuf == ctx->pipe_framebuffer.zsbuf &&
> +   !memcmp(ctx->job->key.cbufs,
> +   ctx->pipe_framebuffer.cbufs,
> +   sizeof(ctx->job->key.cbufs)));
>  return ctx->job;
> +}
>  
>  /* If not, look up the job */
>  
> @@ -133,6 +140,10 @@ panfrost_get_job_for_fbo(struct panfrost_context *ctx)
>  struct pipe_surface *zsbuf = ctx->pipe_framebuffer.zsbuf;
>  struct panfrost_job *job = panfrost_get_job(ctx, cbufs, zsbuf);
>  
> +/* Set this job as the current FBO job. Will be reset when updating 
> the
> + * FB state and when submitting or releasing a job.
> + */
> +ctx->job = job;
>  return job;
>  }
>  
> @@ -181,6 +192,12 @@ panfrost_job_submit(struct panfrost_context *ctx, struct 
> panfrost_job *job)
>  
>  if (ret)
>  fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
> +
> +/* The job has been submitted, let's invalidate the current FBO job
> + * cache.
> +  */
> +assert(!ctx->job || job == ctx->job);
> +ctx->job = NULL;
>  }
>  
>  void

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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.4

[Juan A. Suarez Romero]

Mesa 19.1.4 is now available.

In this release we have:

Mostly, as usual, in fixes for different drivers (anv, radv, radeon, nv50,
nvc0) as well as in backend parts (egl, spirv, nir, ...).

Of those fixes, we could highlight several ones:

- Vulkan 24/48 bit formats are now not supported on Ivybridge.

- R8G8B8_UNORM_SRGB is not supported on Haswell.

- A fix for hair artifacts in Max Payne 3 on AMD/RADV.

- Vulkan transform feedback extension is disabled on Intel gen7.


Andres Rodriguez (1):
  radv: fix queries with WAIT_BIT returning VK_NOT_READY

Andrii Simiklit (2):
  intel/compiler: don't use a keyword struct for a class fs_reg
  meson: add a warning for meson < 0.46.0

Arcady Goldmints-Orlov (1):
  anv: report HOST_ALLOCATION as supported for images

Bas Nieuwenhuizen (3):
  radv: Set correct metadata size for GFX9+.
  radv: Take variable descriptor counts into account for buffer entries.
  radv: Fix descriptor set allocation failure.

Boyuan Zhang (4):
  radeon/uvd: fix poc for hevc encode
  radeon/vcn: fix poc for hevc encode
  radeon/uvd: enable rate control for hevc encoding
  radeon/vcn: enable rate control for hevc encoding

Caio Marcelo de Oliveira Filho (1):
  anv: Remove special allocation for anv_push_constants

Connor Abbott (1):
  nir: Allow qualifiers on copy_deref and image instructions

Daniel Schürmann (1):
  spirv: Fix order of barriers in SpvOpControlBarrier

Dave Airlie (1):
  st/nir: fix arb fragment stage conversion

Dylan Baker (1):
  meson: allow building all glx without any drivers

Emil Velikov (1):
  egl/drm: ensure the backing gbm is set before using it

Eric Anholt (1):
  freedreno: Fix data races with allocating/freeing struct ir3.

Eric Engestrom (5):
  nir: don't return void
  util: fix no-op macro (bad number of arguments)
  gallium+mesa: fix tgsi_semantic array type
  scons+meson: suppress spammy build warning on MacOS
  nir: remove explicit nir_intrinsic_index_flag values

Francisco Jerez (1):
  intel/ir: Fix CFG corruption in opt_predicated_break().

Ilia Mirkin (4):
  gallium/vl: fix compute tgsi shaders to not process undefined components
  nv50,nvc0: update sampler/view bind functions to accept NULL array
  nvc0: allow a non-user buffer to be bound at position 0
  nv50/ir: handle insn not being there for definition of CVT arg

Jason Ekstrand (6):
  intel/fs: Stop stack allocating large arrays
  anv: Disable transform feedback on gen7
  isl/formats: R8G8B8_UNORM_SRGB isn't supported on HSW
  anv: Don't claim support for 24 and 48-bit formats on IVB
  intel/fs: Use ALIGN16 instructions for all derivatives on gen <= 7
  intel/fs: Implement quad_swap_horizontal with a swizzle on gen7

Juan A. Suarez Romero (3):
  docs: add sha256 checksums for 19.1.3
  Update version to 19.1.4
  docs: add release notes for 19.1.4

Kenneth Graunke (4):
  mesa: Fix ReadBuffers with pbuffers
  egl: Quiet warning about front buffer rendering for pixmaps/pbuffers
  egl: Make the 565 pbuffer-only config single buffered.
  egl: Only expose 565 pbuffer configs if X can export them as DRI3 images

Lionel Landwerlin (5):
  anv: fix use of comma operator
  nir: add access to image_deref intrinsics
  spirv: wrap push ssa/pointer values
  spirv: propagate access qualifiers through ssa & pointer
  spirv: don't discard access set by vtn_pointer_dereference

Mark Menzynski (1):
  nvc0/ir: Fix assert accessing null pointer

Nataraj Deshpande (1):
  egl/android: Update color_buffers querying for buffer age

Nicolas Dufresne (1):
  egl: Also query modifiers when exporting DMABuf

Rhys Perry (1):
  ac/nir: fix txf_ms with an offset

Samuel Pitoiset (1):
  radv: fix crash in vkCmdClearAttachments with unused attachment

Tapani Pälli (1):
  mesa: add glsl_type ref to one_time_init and decref to atexit

Yevhenii Kolesnikov (1):
  main: Fix memleaks in mesa_use_program

git tag: mesa-19.1.4

https://mesa.freedesktop.org/archive/mesa-19.1.4.tar.xz
MD5:  90eed05e3239c96ad9e92eb11eb67ada  mesa-19.1.4.tar.xz
SHA1: 393053bfa41b7fc65add756713004f034c39c3ce  mesa-19.1.4.tar.xz
SHA256: a6d268a7d9edcfd92b6da80f2e34e6e0a7baaa442efbeba2fc66c404943c6bfb  
mesa-19.1.4.tar.xz
SHA512: 
234032d917c9b378c3f6ceb921677b64e549344c3957331810b50fd73e0dccd2f4f62e2bd39e619590f389bc58fdab10fab4b88f7c117557cbeb1dda049b9fc5
  mesa-19.1.4.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.4.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.4 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.4 is now available. Currently we have:
 - 49 queued
 - 2 nominated (outstanding)
 - and 0 rejected patch


The current queue consist mostly, as usual, in fixes for different drivers (anv,
radv, radeon, nv50, nvc0) as well as in backend parts (egl, spirv, nir, ...).

Of those fixes, we could highlight several ones:

- Vulkan 24/48 bit formats are now not supported on Ivybridge.

- R8G8B8_UNORM_SRGB is not supported on Haswell.

- A fix for hair artifacts in Max Payne 3 on AMD/RADV.

- Vulkan transform feedback extension is disabled on Intel gen7.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.4 this Tuesday (6th August), around or shortly after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit c45c624dce171bfe7b732abab10722638276e166
Author: Lionel Landwerlin 
Date:   Thu May 16 13:03:39 2019 +0100

nir: add access to image_deref intrinsics

(cherry picked from commit 8c330728f3094f2c836e022e57f003d0c82953ef)


commit eb24e60cdc4f2669b69890aeb4f1f7c475b03593
Author: Jason Ekstrand 
Date:   Thu Jul 25 14:54:20 2019 -0500

anv: Disable transform feedback on gen7

(cherry picked from commit 295e5a17da53958c58d6029c6e6cf1e4a7149711)


commit dccd75b60c201f985d980fc8db5b2ac0c788c5b7
Author: Lionel Landwerlin 
Date:   Tue Jul 23 14:12:43 2019 +0300

anv: fix use of comma operator

(cherry picked from commit 772a5f981485d81919f1cb8ab52ddff0412c6ee5)


commit e1800b20f44670829ce4d3ec9c0df2f9f2d87976
Author: Samuel Pitoiset 
Date:   Mon Jul 22 10:12:48 2019 +0200

radv: fix crash in vkCmdClearAttachments with unused attachment

(cherry picked from commit b5116d3cb7b6d81532fa15f8d94942ce94051652)


Cheers,
J.A.


Mesa stable queue
-

Nominated (2)
==
Boris Brezillon (1):
20b00e1ff24 panfrost: Make ctx->job useful

Sergii Romantsov (1):
   a86eccfb780 i965/clear: clear_value better precision


Queued (49)
===
Andres Rodriguez (1):
  radv: fix queries with WAIT_BIT returning VK_NOT_READY

Andrii Simiklit (2):
  intel/compiler: don't use a keyword struct for a class fs_reg
  meson: add a warning for meson < 0.46.0

Arcady Goldmints-Orlov (1):
  anv: report HOST_ALLOCATION as supported for images

Bas Nieuwenhuizen (3):
  radv: Set correct metadata size for GFX9+.
  radv: Take variable descriptor counts into account for buffer entries.
  radv: Fix descriptor set allocation failure.

Boyuan Zhang (4):
  radeon/uvd: fix poc for hevc encode
  radeon/vcn: fix poc for hevc encode
  radeon/uvd: enable rate control for hevc encoding
  radeon/vcn: enable rate control for hevc encoding

Caio Marcelo de Oliveira Filho (1):
  anv: Remove special allocation for anv_push_constants

Connor Abbott (1):
  nir: Allow qualifiers on copy_deref and image instructions

Daniel Schürmann (1):
  spirv: Fix order of barriers in SpvOpControlBarrier

Dave Airlie (1):
  st/nir: fix arb fragment stage conversion

Dylan Baker (1):
  meson: allow building all glx without any drivers

Emil Velikov (1):
  egl/drm: ensure the backing gbm is set before using it

Eric Anholt (1):
  freedreno: Fix data races with allocating/freeing struct ir3.

Eric Engestrom (5):
  nir: don't return void
  util: fix no-op macro (bad number of arguments)
  gallium+mesa: fix tgsi_semantic array type
  scons+meson: suppress spammy build warning on MacOS
  nir: remove explicit nir_intrinsic_index_flag values

Francisco Jerez (1):
  intel/ir: Fix CFG corruption in opt_predicated_break().

Ilia Mirkin (4):
  gallium/vl: fix compute tgsi shaders to not process undefined components
  nv50,nvc0: update sampler/view bind functions to accept NULL array
  nvc0: allow a non-user buffer to be bound at position 0
  nv50/ir: handle insn not being there for definition of CVT arg

Jason Ekstrand (6):
  intel/fs: Stop stack allocating large arrays
  anv: Disable transform feedback on gen7
  isl/formats: R8G8B8_UNORM_SRGB isn't supported on HSW
  anv: Don't claim support for 24 and 48-bit formats on IVB
  intel/fs: Use ALIGN16 instructions for all derivatives on gen <= 7
  intel/fs: Implement quad_swap_horizontal with a swizzle on gen7

Kenneth Graunke (4):
  mesa: Fix ReadBuffers with pbuffers
  egl: Quiet warning about front buffer rendering for pixmaps/pbuffers
  egl: Make the 565 pbuffer-only config single buffered.
  egl: Only expose 565 pbuffer configs if X can export them as DRI3 images

Lionel Landwerlin (5):
  anv: fix use of comma operator
  nir: add 

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Juan A. Suarez Romero]

On Fri, 2019-07-26 at 10:41 -0400, Ilia Mirkin wrote:
> On Wed, Jul 24, 2019 at 9:34 AM Juan A. Suarez Romero
>  wrote:
> > On Wed, 2019-07-24 at 14:27 +0200, Karol Herbst wrote:
> > > it's only fixing a crash in a build with asserts enabled, but if
> > > somebody wants to apply those to stable, then go ahead.
> > > 
> > 
> > OK; in that case I will keep it out.
> 
> Looks like distros build with debug enabled, sadly:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=111218
> 
> Please do include this in stable:


All right! I'll include it then. Thanks!

J.A.

> 
> commit 7493fbf032f5bcbf4c48187bc089c9a34f04a1d5
> Author: Mark Menzynski 
> Date:   Fri Jul 19 13:09:02 2019 +0200
> 
> nvc0/ir: Fix assert accessing null pointer
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67
> 
> Signed-off-by: Mark Menzynski 
> Reviewed-by: Ilia Mirkin 
> Reviewed-by: Tobias Klausmann
> 

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

Re: [Mesa-dev] [PATCH] radeon/uvd: enable rate control for hevc encoding

[Juan A. Suarez Romero]

On Wed, 2019-06-19 at 17:04 -0400, boyuan.zh...@amd.com wrote:
> From: Boyuan Zhang 
> 
> Set cu_qp_delta_enable_flag on when rate control is enabled, and set it
> off when rate control is disabled (e.g. constant qp).
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110673
> Cc: mesa-sta...@lists.freedesktop.org
> 
> V2: fix typo and add bugzilla info
> 
> Signed-off-by: Boyuan Zhang 
> Acked-by: Leo Liu 


What happened with this patch? I see the bug has been closed as resolved, but
neither this patch has been reviewed or landed in master.



> ---
>  src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c 
> b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> index 8f0e0099e7..9acc33d906 100644
> --- a/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> +++ b/src/gallium/drivers/radeon/radeon_uvd_enc_1_1.c
> @@ -573,7 +573,13 @@ radeon_uvd_enc_nalu_pps_hevc(struct radeon_uvd_encoder 
> *enc)
>enc->enc_pic.hevc_spec_misc.
>constrained_intra_pred_flag, 1);
> radeon_uvd_enc_code_fixed_bits(enc, 0x0, 1);
> -   radeon_uvd_enc_code_fixed_bits(enc, 0x0, 1);
> +   if (enc->enc_pic.rc_session_init.rate_control_method ==
> +  RENC_UVD_RATE_CONTROL_METHOD_NONE)
> +  radeon_uvd_enc_code_fixed_bits(enc, 0x0, 1);
> +   else {
> +  radeon_uvd_enc_code_fixed_bits(enc, 0x1, 1);
> +  radeon_uvd_enc_code_ue(enc, 0x0);
> +   }
> radeon_uvd_enc_code_se(enc, enc->enc_pic.hevc_deblock.cb_qp_offset);
> radeon_uvd_enc_code_se(enc, enc->enc_pic.hevc_deblock.cr_qp_offset);
> radeon_uvd_enc_code_fixed_bits(enc, 0x0, 1);

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

Re: [Mesa-dev] [PATCH] nvc0/ir: Fix assert accessing null pointer

[Juan A. Suarez Romero]

On Wed, 2019-07-24 at 14:27 +0200, Karol Herbst wrote:
> it's only fixing a crash in a build with asserts enabled, but if
> somebody wants to apply those to stable, then go ahead.
> 

OK; in that case I will keep it out.

Thanks!

J.A.

> On Wed, Jul 24, 2019 at 12:48 PM Juan A. Suarez Romero
>  wrote:
> > On Fri, 2019-07-19 at 13:56 +0200, Mark Menzynski wrote:
> > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> > > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67
> > > Signed-off-by: Mark Menzynski 
> > > ---
> > >  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Looks like a good candidate for 19.1 stable. WDYT?
> > 
> > J.A.
> > 
> > > diff --git 
> > > a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> > > b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > > index aca3b0afb1e..1f702a987d8 100644
> > > --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > > +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> > > @@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
> > > // Generate movs to the input regs for the call we want to generate
> > > for (int s = 0; i->srcExists(s); ++s) {
> > >Instruction *ld = i->getSrc(s)->getInsn();
> > > -  assert(ld->getSrc(0) != NULL);
> > >// check if we are moving an immediate, propagate it in that case
> > >if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
> > >  !(ld->src(0).getFile() == FILE_IMMEDIATE))
> > >   bld.mkMovToReg(s, i->getSrc(s));
> > >else {
> > > + assert(ld->getSrc(0) != NULL);
> > >   bld.mkMovToReg(s, ld->getSrc(0));
> > >   // Clear the src, to make code elimination possible here before 
> > > we
> > >   // delete the instruction i later
> > 
> > ___
> > 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] nvc0/ir: Fix assert accessing null pointer

[Juan A. Suarez Romero]

On Fri, 2019-07-19 at 13:56 +0200, Mark Menzynski wrote:
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=111007
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=67
> Signed-off-by: Mark Menzynski 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)


Looks like a good candidate for 19.1 stable. WDYT?

J.A.

> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> index aca3b0afb1e..1f702a987d8 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nvc0.cpp
> @@ -51,12 +51,12 @@ NVC0LegalizeSSA::handleDIV(Instruction *i)
> // Generate movs to the input regs for the call we want to generate
> for (int s = 0; i->srcExists(s); ++s) {
>Instruction *ld = i->getSrc(s)->getInsn();
> -  assert(ld->getSrc(0) != NULL);
>// check if we are moving an immediate, propagate it in that case
>if (!ld || ld->fixed || (ld->op != OP_LOAD && ld->op != OP_MOV) ||
>  !(ld->src(0).getFile() == FILE_IMMEDIATE))
>   bld.mkMovToReg(s, i->getSrc(s));
>else {
> + assert(ld->getSrc(0) != NULL);
>   bld.mkMovToReg(s, ld->getSrc(0));
>   // Clear the src, to make code elimination possible here before we
>   // delete the instruction i later

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

Re: [Mesa-dev] [PATCH] radv: fix crash in vkCmdClearAttachments with unused attachment

[Juan A. Suarez Romero]

On Mon, 2019-07-22 at 10:12 +0200, Samuel Pitoiset wrote:
> depth_stencil_attachment and/or ds_resolve attachment can be NULL.
> 
> This fixes crashes with
> dEQP-VK.renderpass.suballocation.unused_clear_attachments.*
> 
> Cc: 19.1 
> Signed-off-by: Samuel Pitoiset 
> ---


This does not apply cleanly, so I've resolved it as 
https://gitlab.freedesktop.org/mesa/mesa/commit/e1800b20f44670829ce4d3ec9c0df2f9f2d87976


J.A.

>  src/amd/vulkan/radv_meta_clear.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/amd/vulkan/radv_meta_clear.c 
> b/src/amd/vulkan/radv_meta_clear.c
> index dd2ba402f40..b93ba3e0b29 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -1688,7 +1688,7 @@ emit_clear(struct radv_cmd_buffer *cmd_buffer,
>   if (ds_resolve_clear)
>   ds_att = subpass->ds_resolve_attachment;
>  
> - if (ds_att->attachment == VK_ATTACHMENT_UNUSED)
> + if (!ds_att || ds_att->attachment == VK_ATTACHMENT_UNUSED)
>   return;
>  
>   VkImageLayout image_layout = ds_att->layout;

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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.3

[Juan A. Suarez Romero]

Mesa 19.1.3 is now available.

In this release we have:

Mostly in fixes for ANV and RADV drivers, as well as NIR backend fixes.

Several of those patches fixe actually crashes with the drivers,
and a couple of them fix memory leaks.


Bas Nieuwenhuizen (3):
  radv: Handle cmask being disallowed by addrlib.
  anv: Add android dependencies on android.
  radv: Only save the descriptor set if we have one.

Caio Marcelo de Oliveira Filho (2):
  anv: Fix pool allocator when first alloc needs to grow
  spirv: Fix stride calculation when lowering Workgroup to offsets

Chia-I Wu (2):
  anv: fix VkExternalBufferProperties for unsupported handles
  anv: fix VkExternalBufferProperties for host allocation

Connor Abbott (1):
  nir: Add a helper to determine if an intrinsic can be reordered

Dave Airlie (1):
  radv: fix crash in shader tracing.

Eric Anholt (1):
  freedreno: Fix assertion failures in context setup in shader-db mode.

Gert Wollny (1):
  softpipe: Remove unused static function

Ian Romanick (4):
  intel/vec4: Reswizzle VF immediates too
  nir: Add unit tests for nir_opt_comparison_pre
  nir: Use nir_src_bit_size instead of alu1->dest.dest.ssa.bit_size
  mesa: Set minimum possible GLSL version

Jason Ekstrand (13):
  nir/instr_set: Expose nir_instrs_equal()
  nir/loop_analyze: Fix phi-of-identical-alu detection
  nir: Add more helpers for working with const values
  nir/loop_analyze: Handle bit sizes correctly in calculate_iterations
  nir/loop_analyze: Bail if we encounter swizzles
  anv: Set Stateless Data Port Access MOCS
  nir/opt_if: Clean up single-src phis in opt_if_loop_terminator
  nir,intel: Add support for lowering 64-bit nir_opt_extract_*
  anv: Account for dynamic stencil write disables in the PMA fix
  nir/regs_to_ssa: Handle regs in phi sources properly
  nir/loop_analyze: Refactor detection of limit vars
  nir: Add some helpers for chasing SSA values properly
  nir/loop_analyze: Properly handle swizzles in loop conditions

Juan A. Suarez Romero (3):
  docs: add sha256 checksums for 19.1.2
  Update version to 19.1.3
  docs: add release notes for 19.1.3

Lepton Wu (1):
  virgl: Set meta data for textures from handle.

Lionel Landwerlin (6):
  vulkan/overlay: fix command buffer stats
  vulkan/overlay: fix crash on freeing NULL command buffer
  anv: fix crash in vkCmdClearAttachments with unused attachment
  vulkan/wsi: update swapchain status on vkQueuePresent
  anv: report timestampComputeAndGraphics true
  anv: fix format mapping for depth/stencil formats

Marek Olšák (1):
  radeonsi: don't set READ_ONLY for const_uploader to fix bindless texture 
hangs

Samuel Iglesias Gonsálvez (1):
  anv: fix alphaToCoverage when there is no color attachment

Samuel Pitoiset (1):
  radv: fix VGT_GS_MODE if VS uses the primitive ID

Sergii Romantsov (1):
  meta: memory leak of CopyPixels usage

Timothy Arceri (1):
  mesa: save/restore SSO flag when using ARB_get_program_binary

Vinson Lee (1):
  meson: Add dep_thread dependency.

Yevhenii Kolesnikov (1):
  meta: leaking of BO with DrawPixels

git tag: mesa-19.1.3

https://mesa.freedesktop.org/archive/mesa-19.1.3.tar.xz
MD5:  9772ebf9ac40289a62a02c046904c8af  mesa-19.1.3.tar.xz
SHA1: ee3b1b4f9dac391d17b5f5325e41c1d3fcd1e730  mesa-19.1.3.tar.xz
SHA256: 845460b2225d15c15d4a9743dec798ff0b7396b533011d43e774e67f7825b7e0  
mesa-19.1.3.tar.xz
SHA512: 
787310c43089142209ff7db298489b0815b630577680d5ce1bc3f796eed3772ba41f03e5e773b77ae084c191ed4e365eac1753166ce60f12b8f5974d55762eeb
  mesa-19.1.3.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.3.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.3 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.3 is now available. Currently we have:
 - 42 queued
 - 0 nominated (outstanding)
 - and 0 rejected patch


The current queue consist mostly in fixes for ANV and RADV
drivers, as well as NIR backend fixes.

Several of those patches fixe actually crashes with the drivers,
and a couple of them fix memory leaks.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.3 this Tuesday (23th July), around or shortly after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit d86b14ecbb71bdbd4512c877c5acb34befd05f2c
Author: Samuel Pitoiset 

radv: fix VGT_GS_MODE if VS uses the primitive ID

(cherry picked from commit 63d670e350e5249ed91b4bebc59bd7920629eb6c)


commit b685e303f7488d10b37736af3ff0011afb4e649b
Author: Jason Ekstrand 

nir: Add some helpers for chasing SSA values properly

(cherry picked from commit 8f7405ed9d473c1729d48c5add4f0d9fe147c75a)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (42)
===
Bas Nieuwenhuizen (3):
  radv: Handle cmask being disallowed by addrlib.
  anv: Add android dependencies on android.
  radv: Only save the descriptor set if we have one.

Caio Marcelo de Oliveira Filho (2):
  anv: Fix pool allocator when first alloc needs to grow
  spirv: Fix stride calculation when lowering Workgroup to offsets

Chia-I Wu (2):
  anv: fix VkExternalBufferProperties for unsupported handles
  anv: fix VkExternalBufferProperties for host allocation

Connor Abbott (1):
  nir: Add a helper to determine if an intrinsic can be reordered

Dave Airlie (1):
  radv: fix crash in shader tracing.

Eric Anholt (1):
  freedreno: Fix assertion failures in context setup in shader-db mode.

Gert Wollny (1):
  softpipe: Remove unused static function

Ian Romanick (4):
  intel/vec4: Reswizzle VF immediates too
  nir: Add unit tests for nir_opt_comparison_pre
  nir: Use nir_src_bit_size instead of alu1->dest.dest.ssa.bit_size
  mesa: Set minimum possible GLSL version

Jason Ekstrand (13):
  nir/instr_set: Expose nir_instrs_equal()
  nir/loop_analyze: Fix phi-of-identical-alu detection
  nir: Add more helpers for working with const values
  nir/loop_analyze: Handle bit sizes correctly in calculate_iterations
  nir/loop_analyze: Bail if we encounter swizzles
  anv: Set Stateless Data Port Access MOCS
  nir/opt_if: Clean up single-src phis in opt_if_loop_terminator
  nir,intel: Add support for lowering 64-bit nir_opt_extract_*
  anv: Account for dynamic stencil write disables in the PMA fix
  nir/regs_to_ssa: Handle regs in phi sources properly
  nir/loop_analyze: Refactor detection of limit vars
  nir: Add some helpers for chasing SSA values properly
  nir/loop_analyze: Properly handle swizzles in loop conditions

Lepton Wu (1):
  virgl: Set meta data for textures from handle.

Lionel Landwerlin (6):
  vulkan/overlay: fix command buffer stats
  vulkan/overlay: fix crash on freeing NULL command buffer
  anv: fix crash in vkCmdClearAttachments with unused attachment
  vulkan/wsi: update swapchain status on vkQueuePresent
  anv: report timestampComputeAndGraphics true
  anv: fix format mapping for depth/stencil formats

Marek Olšák (1):
  radeonsi: don't set READ_ONLY for const_uploader to fix bindless texture 
hangs

Samuel Iglesias Gonsálvez (1):
  anv: fix alphaToCoverage when there is no color attachment

Samuel Pitoiset (1):
  radv: fix VGT_GS_MODE if VS uses the primitive ID

Sergii Romantsov (1):
  meta: memory leak of CopyPixels usage

Timothy Arceri (1):
  mesa: save/restore SSO flag when using ARB_get_program_binary

Vinson Lee (1):
  meson: Add dep_thread dependency.

Yevhenii Kolesnikov (1):
  meta: leaking of BO with DrawPixels


Rejected (0)
=


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

Re: [Mesa-dev] [PATCH v4] anv: fix alphaToCoverage when there is no color attachment

[Juan A. Suarez Romero]

On Mon, 2019-05-06 at 16:01 +0200, Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez 
> 
> There are tests in CTS for alpha to coverage without a color attachment
> that are failing. This happens because we remove the shader color
> outputs when we don't have a valid color attachment for them, but when
> alpha to coverage is enabled we still want to preserve the the output
> at location 0 since we need the alpha component. In that case we will
> also need to create a null render target for RT 0.
> 

I'm adding this commit to the 19.1 stable queue.


J.A.

> v2:
>   - We already create a null rt when we don't have any, so reuse that
> for this case (Jason)
>   - Simplify the code a bit (Iago)
> 
> v3:
>   - Take alpha to coverage from the key and don't tie this to depth-only
> rendering only, we want the same behavior if we have multiple render
> targets but the one at location 0 is not used. (Jason).
>   - Rewrite commit message (Iago)
> 
> v4:
>   - Make sure we take into account the array length of the shader outputs,
> which we were no handling correctly either and make sure we also
> create null render targets for any invalid array entries too. (Jason)
> 
> Fixes the following CTS tests:
> dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
> 
> Signed-off-by: Samuel Iglesias Gonsálvez 
> Signed-off-by: Iago Toral Quiroga 
> ---
>  src/intel/vulkan/anv_pipeline.c | 56 -
>  1 file changed, 42 insertions(+), 14 deletions(-)
> 
> diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
> index 20eab548fb2..f15f0896266 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -823,14 +823,24 @@ anv_pipeline_link_fs(const struct brw_compiler 
> *compiler,
>   continue;
>  
>const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
> -  /* Unused or out-of-bounds */
> -  if (rt >= MAX_RTS || !(stage->key.wm.color_outputs_valid & (1 << rt)))
> +  /* Out-of-bounds */
> +  if (rt >= MAX_RTS)
>   continue;
>  
>const unsigned array_len =
>   glsl_type_is_array(var->type) ? glsl_get_length(var->type) : 1;
>assert(rt + array_len <= max_rt);
>  
> +  /* Unused */
> +  if (!(stage->key.wm.color_outputs_valid & BITFIELD_RANGE(rt, 
> array_len))) {
> + /* If this is the RT at location 0 and we have alpha to coverage
> +  * enabled we will have to create a null RT for it, so mark it as
> +  * used.
> +  */
> + if (rt > 0 || !stage->key.wm.alpha_to_coverage)
> +continue;
> +  }
> +
>for (unsigned i = 0; i < array_len; i++)
>   rt_used[rt + i] = true;
> }
> @@ -841,11 +851,22 @@ anv_pipeline_link_fs(const struct brw_compiler 
> *compiler,
>   continue;
>  
>rt_to_bindings[i] = num_rts;
> -  rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
> - .set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> - .binding = 0,
> - .index = i,
> -  };
> +
> +  if (stage->key.wm.color_outputs_valid & (1 << i)) {
> + rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
> +.set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> +.binding = 0,
> +.index = i,
> + };
> +  } else {
> + /* Setup a null render target */
> + rt_bindings[rt_to_bindings[i]] = (struct anv_pipeline_binding) {
> +.set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> +.binding = 0,
> +.index = UINT32_MAX,
> + };
> +  }
> +
>num_rts++;
> }
>  
> @@ -855,14 +876,21 @@ anv_pipeline_link_fs(const struct brw_compiler 
> *compiler,
>   continue;
>  
>const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
> +  const unsigned array_len =
> + glsl_type_is_array(var->type) ? glsl_get_length(var->type) : 1;
> +
>if (rt >= MAX_RTS ||
> -  !(stage->key.wm.color_outputs_valid & (1 << rt))) {
> - /* Unused or out-of-bounds, throw it away */
> - deleted_output = true;
> - var->data.mode = nir_var_function_temp;
> - exec_node_remove(>node);
> - exec_list_push_tail(>locals, >node);
> - continue;
> +  !(stage->key.wm.color_outputs_valid & BITFIELD_RANGE(rt, 
> array_len))) {
> + /* Unused or out-of-bounds, throw it away, unless it is the first
> +  * RT and we have alpha to coverage enabled.
> +  */
> + if (rt != 0 || !stage->key.wm.alpha_to_coverage) {
> +deleted_output = true;
> +var->data.mode = nir_var_function_temp;
> +exec_node_remove(>node);
> +exec_list_push_tail(>locals, >node);
> +continue;
> + }
>}
>  
>/* Give it the new location */

___

Re: [Mesa-dev] [PATCH] radv: fix gathering clip/cull distance masks for GS

[Juan A. Suarez Romero]

On Tue, 2019-07-16 at 08:37 +0200, Samuel Pitoiset wrote:
> For NGG, the driver relies on the VS outinfo struct.
> 
> This fixes
> dEQP-VK.clipping.user_defined.clip_*_vert_tess_geom_*
> 

Should this be included in 19.1 stable branch?


> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index 76d784b3374..b890ce56f16 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -2407,6 +2407,11 @@ scan_shader_output_decl(struct radv_shader_context 
> *ctx,
>   ctx->shader_info->tes.outinfo.cull_dist_mask = 
> (1 << shader->info.cull_distance_array_size) - 1;
>   ctx->shader_info->tes.outinfo.cull_dist_mask 
> <<= shader->info.clip_distance_array_size;
>   }
> + if (stage == MESA_SHADER_GEOMETRY) {
> + ctx->shader_info->vs.outinfo.clip_dist_mask = 
> (1 << shader->info.clip_distance_array_size) - 1;
> + ctx->shader_info->vs.outinfo.cull_dist_mask = 
> (1 << shader->info.cull_distance_array_size) - 1;
> + ctx->shader_info->vs.outinfo.cull_dist_mask <<= 
> shader->info.clip_distance_array_size;
> + }
>   }
>   }
>  

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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.2

[Juan A. Suarez Romero]

Mesa 19.1.2 is now available.

In this release we have:

Different fixes for the Intel and AMD Vulkan drivers, Freedreno, the Meson 
build system,
and some other fixes for other parts and/or drivers.

Worth to mention a fix for a crash in Wolfenstein II with the RADV driver, and 
another fix
relevant for DXVK on Intel gen7 drivers.


Anuj Phogat (3):
  Revert "i965/icl: Add WA_2204188704 to disable pixel shader panic 
dispatch"
  Revert "anv/icl: Add WA_2204188704 to disable pixel shader panic dispatch"
  Revert "iris/icl: Add WA_2204188704 to disable pixel shader panic 
dispatch"

Arfrever Frehtes Taifersar Arahesis (1):
  meson: Improve detection of Python when using Meson >=0.50.

Bas Nieuwenhuizen (2):
  radv: Only allocate supplied number of descriptors when variable.
  radv: Fix interactions between variable descriptor count and inline 
uniform blocks.

Caio Marcelo de Oliveira Filho (1):
  spirv: Ignore ArrayStride in OpPtrAccessChain for Workgroup

Dylan Baker (2):
  meson: Add support for using cmake for finding LLVM
  Revert "meson: Add support for using cmake for finding LLVM"

Eric Anholt (2):
  freedreno: Fix UBO load range detection on booleans.
  freedreno: Fix up end range of unaligned UBO loads.

Eric Engestrom (1):
  meson: bump required libdrm version to 2.4.81

Gert Wollny (2):
  gallium: Add CAP for opcode DIV
  vl: Use CS composite shader only if TEX_LZ and DIV are supported

Ian Romanick (1):
  glsl: Don't increase the iteration count when there are no terminators

James Clarke (1):
  meson: GNU/kFreeBSD has DRM/KMS and requires -D_GNU_SOURCE

Jason Ekstrand (2):
  anv/descriptor_set: Only write texture swizzles if we have an image view
  iris: Use a uint16_t for key sizes

Jory Pratt (2):
  util: Heap-allocate 256K zlib buffer
  meson: Search for execinfo.h

Juan A. Suarez Romero (4):
  docs: add sha256 checksums for 19.1.1
  intel: fix wrong format usage
  Update version to 19.1.2
  docs: add release notes for 19.1.2

Kenneth Graunke (2):
  iris: Enable PIPE_CAP_SURFACE_REINTERPRET_BLOCKS
  gallium: Make util_copy_image_view handle shader_access

Lionel Landwerlin (2):
  intel/compiler: fix derivative on y axis implementation
  intel/compiler: don't use byte operands for src1 on ICL

Nanley Chery (2):
  intel: Add and use helpers for level0 extent
  isl: Don't align phys_level0_sa by block dimension

Nataraj Deshpande (1):
  anv: Add HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED in vk_format

Pierre-Eric Pelloux-Prayer (2):
  mesa: delete framebuffer texture attachment sampler views
  radeon/uvd: fix calc_ctx_size_h265_main10

Rob Clark (1):
  freedreno/a5xx: fix batch leak in fd5 blitter path

Sagar Ghuge (1):
  glsl: Fix round64 conversion function

Samuel Pitoiset (1):
  radv: only enable VK_AMD_gpu_shader_{half_float,int16} on GFX9+

Sergii Romantsov (1):
  i965: leaking of upload-BO with push constants

Ville Syrjälä (1):
  anv/cmd_buffer: Reuse gen8 Cmd{Set, Reset}Event on gen7

git tag: mesa-19.1.2

https://mesa.freedesktop.org/archive/mesa-19.1.2.tar.xz
MD5:  7cb3df6f46cfc08bba5245d091cd4524  mesa-19.1.2.tar.xz
SHA1: 05e0e5685892504958d7245f6877a8814e235f02  mesa-19.1.2.tar.xz
SHA256: 813a144ea8ebefb7b48b6733f3f603855b0f61268d86cc1cc26a6b4be908fcfd  
mesa-19.1.2.tar.xz
SHA512: 
cab30694a409a5037996dd50cef1567eb9e0b83ed69cdb4fbc893a844ed35434fcd05023d48fce2831219866fa420500b53650c791bea286233f4cd6c2703e19
  mesa-19.1.2.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.2.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.2 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.2 is now available. Currently we have:
 - 35 queued
 - 0? nominated (outstanding)
 - and 0 rejected patch


The current queue consists on different fixes for the Intel and AMD Vulkan 
drivers,
Freedreno, the Meson build system, and some other fixes for other parts and/or 
drivers.

Worth to mention a fix for a crash in Wolfenstein II with the RADV driver, and 
another fix
relevant for DXVK on Intel gen7 drivers.

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.2 this Tuesday (9th July), around or shortly after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit 5cfbe55184fe0519583774b9fbe3f67913926484
Author: Gert Wollny 

gallium: Add CAP for opcode DIV

(cherry picked from commit 843723e2f7c79633cb0fe910b60684b8b2d289f6)


commit adbf808e0c71d855257fdc3194462c39c5119aff
Author: Samuel Pitoiset 

radv: only enable VK_AMD_gpu_shader_{half_float,int16} on GFX9+

(cherry picked from commit ef1787dbc95e138b782fef1fcc93279ccf0e4910)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (35)
===
Anuj Phogat (3):
  Revert "i965/icl: Add WA_2204188704 to disable pixel shader panic 
dispatch"
  Revert "anv/icl: Add WA_2204188704 to disable pixel shader panic dispatch"
  Revert "iris/icl: Add WA_2204188704 to disable pixel shader panic 
dispatch"

Arfrever Frehtes Taifersar Arahesis (1):
  meson: Improve detection of Python when using Meson >=0.50.

Bas Nieuwenhuizen (2):
  radv: Only allocate supplied number of descriptors when variable.
  radv: Fix interactions between variable descriptor count and inline 
uniform blocks.

Caio Marcelo de Oliveira Filho (1):
  spirv: Ignore ArrayStride in OpPtrAccessChain for Workgroup

Dylan Baker (2):
  meson: Add support for using cmake for finding LLVM
  Revert "meson: Add support for using cmake for finding LLVM"

Eric Anholt (2):
  freedreno: Fix UBO load range detection on booleans.
  freedreno: Fix up end range of unaligned UBO loads.

Eric Engestrom (1):
  meson: bump required libdrm version to 2.4.81

Gert Wollny (2):
  gallium: Add CAP for opcode DIV
  vl: Use CS composite shader only if TEX_LZ and DIV are supported

Ian Romanick (1):
  glsl: Don't increase the iteration count when there are no terminators

James Clarke (1):
  meson: GNU/kFreeBSD has DRM/KMS and requires -D_GNU_SOURCE

Jason Ekstrand (2):
  anv/descriptor_set: Only write texture swizzles if we have an image view
  iris: Use a uint16_t for key sizes

Jory Pratt (2):
  util: Heap-allocate 256K zlib buffer
  meson: Search for execinfo.h

Juan A. Suarez Romero (1):
  intel: fix wrong format usage

Kenneth Graunke (2):
  iris: Enable PIPE_CAP_SURFACE_REINTERPRET_BLOCKS
  gallium: Make util_copy_image_view handle shader_access

Lionel Landwerlin (2):
  intel/compiler: fix derivative on y axis implementation
  intel/compiler: don't use byte operands for src1 on ICL

Nanley Chery (2):
  intel: Add and use helpers for level0 extent
  isl: Don't align phys_level0_sa by block dimension

Nataraj Deshpande (1):
  anv: Add HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED in vk_format

Pierre-Eric Pelloux-Prayer (2):
  mesa: delete framebuffer texture attachment sampler views
  radeon/uvd: fix calc_ctx_size_h265_main10

Rob Clark (1):
  freedreno/a5xx: fix batch leak in fd5 blitter path

Sagar Ghuge (1):
  glsl: Fix round64 conversion function

Samuel Pitoiset (1):
  radv: only enable VK_AMD_gpu_shader_{half_float,int16} on GFX9+

Sergii Romantsov (1):
  i965: leaking of upload-BO with push constants

Ville Syrjälä (1):
  anv/cmd_buffer: Reuse gen8 Cmd{Set, Reset}Event on gen7


Rejected (0)
=


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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.1

[Juan A. Suarez Romero]

Mesa 19.1.1 is now available.

In this release we have:

Mostly in fixes for different drivers (RADV, ANV,
Nouveau, Virgl, V3D, R300g, ...)

Also different fixes for different parts (Meson build, GLX,
etc).


Alejandro Piñeiro (1):
  v3d: fix checking twice auf flag

Bas Nieuwenhuizen (5):
  radv: Skip transitions coming from external queue.
  radv: Decompress DCC when the image format is not allowed for buffers.
  radv: Fix vulkan build in meson.
  anv: Fix vulkan build in meson.
  meson: Allow building radeonsi with just the android platform.

Dave Airlie (1):
  nouveau: fix frees in unsupported IR error paths.

Eduardo Lima Mitev (1):
  freedreno/a5xx: Fix indirect draw max_indices calculation

Eric Engestrom (3):
  util/futex: fix dangling pointer use
  glx: fix glvnd pointer types
  util/os_file: resize buffer to what was actually needed

Gert Wollny (1):
  virgl: Assume sRGB write control for older guest kernels or virglrenderer 
hosts

Haihao Xiang (1):
  i965: support UYVY for external import only

Jason Ekstrand (1):
  anv: Set STATE_BASE_ADDRESS upper bounds on gen7

Juan A. Suarez Romero (3):
  docs: Add SHA256 sums for 19.1.0
  Update version to 19.1.1
  docs: add release notes for 19.1.1

Kenneth Graunke (2):
  glsl: Fix out of bounds read in shader_cache_read_program_metadata
  iris: Fix iris_flush_and_dirty_history to actually dirty history.

Kevin Strasser (2):
  gallium/winsys/kms: Fix dumb buffer bpp
  st/mesa: Add rgbx handling for fp formats

Lionel Landwerlin (2):
  anv: do not parse genxml data without INTEL_DEBUG=bat
  intel/dump: fix segfault when the app hasn't accessed the device

Mathias Fröhlich (1):
  egl: Don't add hardware device if there is no render node v2.

Richard Thier (1):
  r300g: restore performance after RADEON_FLAG_NO_INTERPROCESS_SHARING was 
added

Rob Clark (1):
  freedreno/a6xx: un-swap X24S8_UINT

Samuel Pitoiset (4):
  radv: fix occlusion queries on VegaM
  radv: fix VK_EXT_memory_budget if one heap isn't available
  radv: fix FMASK expand with SRGB formats
  radv: disable viewport clamping even if FS doesn't write Z

git tag: mesa-19.1.1

https://mesa.freedesktop.org/archive/mesa-19.1.1.tar.xz
MD5:  07cd8cd79de28ec1a374ee3a06e47789  mesa-19.1.1.tar.xz
SHA1: b906dd39d6cd3aca523429e705c79dabc97ea96d  mesa-19.1.1.tar.xz
SHA256: 72114b16b4a84373b2acda060fe2bb1d45ea2598efab3ef2d44bdeda74f15581  
mesa-19.1.1.tar.xz
SHA512: 
73b190eeb0b5809217c04f39d90edc0844dac476d8284543013a4a8889a4be805bc15b43c91bbf0d3a36f35dc576e7085255f7012d207c74466e81cee7f67922
  mesa-19.1.1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.1.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] Mesa 19.1.1 release candidate

[Juan A. Suarez Romero]

Hello list,

The candidate for the Mesa 19.1.1 is now available. Currently we have:
 - 27 queued
 - 0 nominated (outstanding)
 - and 0 rejected patch


The current queue consists mostly in fixes for different drivers (RADV, ANV,
Nouveau, Virgl, V3D, R300g, ...)

The queue also contains different fixes for different parts (Meson build, GLX,
etc).

Take a look at section "Mesa stable queue" for more information


Testing reports/general approval

Any testing reports (or general approval of the state of the branch) will be
greatly appreciated.

The plan is to have 19.1.1 this Tuesday (25th June), around or shortly after
10:00 GMT.

If you have any questions or suggestions - be that about the current patch queue
or otherwise, please go ahead.


Trivial merge conflicts
---
commit 25a34df61439b25645d03510d6354cb1f5e8a185
Author: Kenneth Graunke 

iris: Fix iris_flush_and_dirty_history to actually dirty history.

(cherry picked from commit 64fb20ed326fa0e524582225faaa4bb28f6e4349)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

Queued (27)
===
Alejandro Piñeiro (1):
  v3d: fix checking twice auf flag

Bas Nieuwenhuizen (5):
  radv: Skip transitions coming from external queue.
  radv: Decompress DCC when the image format is not allowed for buffers.
  radv: Fix vulkan build in meson.
  anv: Fix vulkan build in meson.
  meson: Allow building radeonsi with just the android platform.

Dave Airlie (1):
  nouveau: fix frees in unsupported IR error paths.

Eduardo Lima Mitev (1):
  freedreno/a5xx: Fix indirect draw max_indices calculation

Eric Engestrom (3):
  util/futex: fix dangling pointer use
  glx: fix glvnd pointer types
  util/os_file: resize buffer to what was actually needed

Gert Wollny (1):
  virgl: Assume sRGB write control for older guest kernels or virglrenderer 
hosts

Haihao Xiang (1):
  i965: support UYVY for external import only

Jason Ekstrand (1):
  anv: Set STATE_BASE_ADDRESS upper bounds on gen7

Kenneth Graunke (2):
  glsl: Fix out of bounds read in shader_cache_read_program_metadata
  iris: Fix iris_flush_and_dirty_history to actually dirty history.

Kevin Strasser (2):
  gallium/winsys/kms: Fix dumb buffer bpp
  st/mesa: Add rgbx handling for fp formats

Lionel Landwerlin (2):
  anv: do not parse genxml data without INTEL_DEBUG=bat
  intel/dump: fix segfault when the app hasn't accessed the device

Mathias Fröhlich (1):
  egl: Don't add hardware device if there is no render node v2.

Richard Thier (1):
  r300g: restore performance after RADEON_FLAG_NO_INTERPROCESS_SHARING was 
added

Rob Clark (1):
  freedreno/a6xx: un-swap X24S8_UINT

Samuel Pitoiset (4):
  radv: fix occlusion queries on VegaM
  radv: fix VK_EXT_memory_budget if one heap isn't available
  radv: fix FMASK expand with SRGB formats
  radv: disable viewport clamping even if FS doesn't write Z


Rejected (0)
=


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

Re: [Mesa-dev] [PATCH] radv: disable viewport clamping even if FS doesn't write Z

[Juan A. Suarez Romero]

On Tue, 2019-06-18 at 18:58 +0200, Samuel Pitoiset wrote:
> This fixes new CTS dEQP-VK.pipeline.depth_range_unrestricted.*.
> 
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_pipeline.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 


could this patch be a candidate for stable release?


J.A.

> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index 8bc0d9b53e6..765f6105f7d 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -2788,8 +2788,7 @@ radv_pipeline_generate_depth_stencil_state(struct 
> radeon_cmdbuf *ctx_cs,
>   db_render_override |= 
> S_02800C_FORCE_HIS_ENABLE0(V_02800C_FORCE_DISABLE) |
> 
> S_02800C_FORCE_HIS_ENABLE1(V_02800C_FORCE_DISABLE);
>  
> - if (!pCreateInfo->pRasterizationState->depthClampEnable &&
> - ps->info.info.ps.writes_z) {
> + if (!pCreateInfo->pRasterizationState->depthClampEnable) {
>   /* From VK_EXT_depth_range_unrestricted spec:
>*
>* "The behavior described in Primitive Clipping still applies.

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] radv: make sure to init the DCC decompress compute path state

[Juan A. Suarez Romero]

On Tue, 2019-06-18 at 12:12 +0200, Samuel Pitoiset wrote:
> On 6/18/19 12:05 PM, Juan A. Suarez Romero wrote:
> > On Thu, 2019-06-13 at 12:44 +0200, Samuel Pitoiset wrote:
> > > This fixes a segfault when forcing DCC decompressions on compute
> > > because internal meta objects are not created since the on-demand
> > > stuff.
> > > 
> > Does it make sense to nominate this to stable?
> No, that's useless.


Thanks for the feedback!

J.A.

> > J.A.
> > 
> > > Signed-off-by: Samuel Pitoiset 
> > > ---
> > >   src/amd/vulkan/radv_meta_fast_clear.c | 8 
> > >   1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/src/amd/vulkan/radv_meta_fast_clear.c 
> > > b/src/amd/vulkan/radv_meta_fast_clear.c
> > > index 8f97c1a8f15..176f9803b45 100644
> > > --- a/src/amd/vulkan/radv_meta_fast_clear.c
> > > +++ b/src/amd/vulkan/radv_meta_fast_clear.c
> > > @@ -753,6 +753,14 @@ radv_decompress_dcc_compute(struct radv_cmd_buffer 
> > > *cmd_buffer,
> > >   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
> > >RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
> > >   
> > > + if 
> > > (!cmd_buffer->device->meta_state.fast_clear_flush.cmask_eliminate_pipeline)
> > >  {
> > > + VkResult ret = 
> > > radv_device_init_meta_fast_clear_flush_state_internal(cmd_buffer->device);
> > > + if (ret != VK_SUCCESS) {
> > > + cmd_buffer->record_result = ret;
> > > + return;
> > > + }
> > > + }
> > > +
> > >   radv_meta_save(_state, cmd_buffer, 
> > > RADV_META_SAVE_DESCRIPTORS |
> > >
> > > RADV_META_SAVE_COMPUTE_PIPELINE);
> > >   
> ___
> mesa-stable mailing list
> mesa-sta...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable

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

Re: [Mesa-dev] [PATCH] radv: make sure to init the DCC decompress compute path state

[Juan A. Suarez Romero]

On Thu, 2019-06-13 at 12:44 +0200, Samuel Pitoiset wrote:
> This fixes a segfault when forcing DCC decompressions on compute
> because internal meta objects are not created since the on-demand
> stuff.
> 

Does it make sense to nominate this to stable?

J.A.

> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_fast_clear.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/src/amd/vulkan/radv_meta_fast_clear.c 
> b/src/amd/vulkan/radv_meta_fast_clear.c
> index 8f97c1a8f15..176f9803b45 100644
> --- a/src/amd/vulkan/radv_meta_fast_clear.c
> +++ b/src/amd/vulkan/radv_meta_fast_clear.c
> @@ -753,6 +753,14 @@ radv_decompress_dcc_compute(struct radv_cmd_buffer 
> *cmd_buffer,
>   state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
>RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
>  
> + if 
> (!cmd_buffer->device->meta_state.fast_clear_flush.cmask_eliminate_pipeline) {
> + VkResult ret = 
> radv_device_init_meta_fast_clear_flush_state_internal(cmd_buffer->device);
> + if (ret != VK_SUCCESS) {
> + cmd_buffer->record_result = ret;
> + return;
> + }
> + }
> +
>   radv_meta_save(_state, cmd_buffer, RADV_META_SAVE_DESCRIPTORS |
>
> RADV_META_SAVE_COMPUTE_PIPELINE);
>  

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

Re: [Mesa-dev] [PATCH] radeonsi: reduce MAX_GEOMETRY_OUTPUT_VERTICES

[Juan A. Suarez Romero]

On Fri, 2019-06-14 at 19:00 -0400, Marek Olšák wrote:
> From: Nicolai Hähnle 
> 
> This fixes piglit spec@glsl-1.50@gs-max-output.
> ---


Does it make sense to nominate this for stable?

J.A.

>  src/gallium/drivers/radeonsi/si_get.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_get.c 
> b/src/gallium/drivers/radeonsi/si_get.c
> index c1bddca1a66..9496817ac84 100644
> --- a/src/gallium/drivers/radeonsi/si_get.c
> +++ b/src/gallium/drivers/radeonsi/si_get.c
> @@ -256,21 +256,23 @@ static int si_get_param(struct pipe_screen *pscreen, 
> enum pipe_cap param)
>   return sscreen->info.chip_class <= GFX8 ?
>   PIPE_QUIRK_TEXTURE_BORDER_COLOR_SWIZZLE_R600 : 0;
>  
>   /* Stream output. */
>   case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
>   case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
>   return 32*4;
>  
>   /* Geometry shader output. */
>   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
> - return 1024;
> + /* gfx8 and earlier can do more, but nobody uses it because it
> +  * would be a bad idea for performance. */
> + return 256;
>   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
>   return 4095;
>   case PIPE_CAP_MAX_GS_INVOCATIONS:
>   /* The closed driver exposes 127, but 125 is the greatest
>* number that works. */
>   return 125;
>  
>   case PIPE_CAP_MAX_VERTEX_ATTRIB_STRIDE:
>   return 2048;
>  

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

Re: [Mesa-dev] [ANNOUNCE] mesa 19.1.0

[Juan A. Suarez Romero]

On Tue, 2019-06-11 at 20:28 +0300, Thomas Backlund wrote:
> Den 11.6.2019 kl. 19:00, skrev Juan A. Suarez Romero:
> > Mesa 19.1.0 is now available.
> > 
> > Emil Velikov (3):
> >mapi: add static_date offset to MaxShaderCompilerThreadsKHR
> >mapi: correctly handle the full offset table
> > 
> 
> Question...
> 
> Wasn't "mapi: add static_date offset to EXT_dsa"
> https://cgit.freedesktop.org/mesa/mesa/commit/?id=497de977bdfe79469638e351d1363275c5954ea6
> 
> also supposed to be part of the fix for:
> https://bugs.freedesktop.org/show_bug.cgi?id=110302
> 


It is required to fix the issue with master branch, but not with 19.1 stable
branch.

The reason is that this commit is required due commit d2906293c43 ("mesa:
EXT_dsa add selectorless matrix stackfunctions"), which is not part of the 19.1
stable release.


J.A.

> --
> Thomas
> 

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

[Mesa-dev] [ANNOUNCE] mesa 19.1.0

[Juan A. Suarez Romero]

Mesa 19.1.0 is now available.

This release consists of approximately 3700 commits from 158
developers.

Huge thanks to all the developers, testers and users for their
ongoing work and support shaping up the 19.1.0 release.

The top highlights include:

 - GL_ARB_parallel_shader_compile for all drivers.
-  GL_EXT_gpu_shader4 on all GL 3.1 drivers.
-  GL_EXT_shader_image_load_formatted on radeonsi.
-  GL_EXT_texture_buffer_object on all GL 3.1 drivers.
-  GL_EXT_texture_compression_s3tc_srgb on Gallium and i965 drivers (ES 
extension).
-  GL_NV_compute_shader_derivatives on Iris and i965 drivers.
-  GL_KHR_parallel_shader_compile on all drivers.
-  GL_INTEL_conservative_rasterization on Iris.


Additional features:

ANV
 - VK_EXT_buffer_device_address
 - VK_EXT_depth_clip_enable
 - VK_KHR_ycbcr_image_arrays
 - VK_EXT_inline_uniform_block
 - VK_EXT_external_memory_host
 - VK_EXT_host_query_reset
 - VK_KHR_surface_protected_capabilities
 - VK_EXT_pipeline_creation_feedback
 - VK_NV_compute_shader_derivatives
 - VK_KHR_shader_float16_int8
 - VK_KHR_shader_atomic_int64
 - VK_EXT_descriptor_indexing
 - VK_EXT_memory_budget
 
RADV 
 - VK_EXT_buffer_device_address
 - VK_EXT_depth_clip_enable
 - VK_EXT_inline_uniform_block
 - VK_EXT_host_query_reset
 - VK_KHR_surface_protected_capabilities
 - VK_EXT_pipeline_creation_feedback
 - VK_KHR_8bit_storage
 - VK_AMD_gpu_shader_int16
 - VK_AMD_gpu_shader_half_float
 - VK_KHR_shader_float16_int8


For the full log see:
   git log 19.0-branchpoint..mesa-19.1.0


Changes since rc5:

Bas Nieuwenhuizen (1):
  radv: Prevent out of bound shift on 32-bit builds.

Charmaine Lee (1):
  svga: Remove unnecessary check for the pre flush bit for setting vertex 
buffers

Deepak Rawat (2):
  winsys/drm: Fix out of scope variable usage
  winsys/svga/drm: Fix 32-bit RPCI send message

Emil Velikov (3):
  egl/dri: flesh out and use dri2_create_drawable()
  mapi: add static_date offset to MaxShaderCompilerThreadsKHR
  mapi: correctly handle the full offset table

Eric Engestrom (1):
  util/os_file: actually return the error read() gave us

Jason Ekstrand (1):
  nir/propagate_invariant: Don't add NULL vars to the hash table

Juan A. Suarez Romero (2):
  Update version to 19.1.0
  docs: Add release notes for 19.1.0

Kenneth Graunke (1):
  egl/x11: calloc dri2_surf so it's properly zeroed

Lionel Landwerlin (2):
  intel/perf: fix EuThreadsCount value in performance equations
  intel/perf: improve dynamic loading config detection

Nanley Chery (1):
  anv/cmd_buffer: Initalize the clear color struct for CNL+

Nataraj Deshpande (1):
  anv: Fix check for isl_fmt in assert

Rob Clark (2):
  freedreno/a6xx: fix issues with gallium HUD
  freedreno/a6xx: fix hangs with newer sqe fw

Samuel Pitoiset (2):
  radv: fix alpha-to-coverage when there is unused color attachments
  radv: fix setting CB_SHADER_MASK for dual source blending

git tag: mesa-19.1.0

https://mesa.freedesktop.org/archive/mesa-19.1.0.tar.xz
MD5:  090cd351cf938fc1729dee983520216a  mesa-19.1.0.tar.xz
SHA1: e2088e1d4fd9c113c5fc4ee416702f35f32ce668  mesa-19.1.0.tar.xz
SHA256: 2a6c3af3a803389183168e449c536304cf03e0f82c4c9333077933543b9d02f3  
mesa-19.1.0.tar.xz
SHA512: 
25b186ae8037dedea5691e0b77b22f2065f3c877838378651726dfa1b34ef49dcc56f1dbd124e99285e5f14489db936a886a6740495b5b279e8363424bfb3433
  mesa-19.1.0.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.0.tar.xz.sig



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

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

[Juan A. Suarez Romero]

Hello, list.

The fifth release candidate for Mesa 19.1.0 is now available.

We have extended the release candidates because there are two bugs blocking the 
final release:

#110302 - [bisected][regression] piglit egl-create-pbuffer-surface and 
egl-gl-colorspace regressions
#110357 - [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in 
new attempted "41" configuration

We hope to unblock them as soon as possible.


Axel Davy (1):
  d3dadapter9: Revert to old throttling limit value

Bas Nieuwenhuizen (1):
  nir: Actually propagate progress in nir_opt_move_load_ubo.

Jan Zielinski (1):
  swr/rast: fix 32-bit compilation on Linux

Jason Ekstrand (4):
  iris: Don't assume UBO indices are constant
  intel/fs,vec4: Use g0 as the header for MFENCE
  intel/fs: Do a stalling MFENCE in endInvocationInterlock()
  nir/dead_cf: Call instructions aren't dead

Jonathan Marek (1):
  freedreno/ir3: fix input ncomp for vertex shaders

Juan A. Suarez Romero (1):
  Update version to 19.1.0-rc5

Lionel Landwerlin (1):
  nir/lower_non_uniform: safely iterate over blocks

Marek Olšák (2):
  u_blitter: don't fail mipmap generation for depth formats containing 
stencil
  ac: fix a typo in ac_build_wg_scan_bottom

Pierre-Eric Pelloux-Prayer (1):
  radeonsi: init sctx->dma_copy before using it

Rhys Perry (1):
  ac/nir: mark some texture intrinsics as convergent

Rob Clark (2):
  freedreno/ir3: set more barrier bits
  freedreno/a6xx: fix GPU crash on small render targets

Sagar Ghuge (1):
  intel/compiler: Fix assertions in brw_alu3

Samuel Pitoiset (2):
  radv: allocate more space in the CS when emitting events
  radv: do not use gfx fast depth clears for layered depth/stencil images

Timothy Arceri (1):
  st/glsl: make sure to propagate initialisers to driver storage

Vinson Lee (1):
  freedreno: Fix GCC build error.

git tag: mesa-19.1.0-rc5

https://mesa.freedesktop.org/archive/mesa-19.1.0-rc5.tar.xz
MD5:  e18f28edd04c36e1a4fc0ac7026187b9  mesa-19.1.0-rc5.tar.xz
SHA1: 90bd39c330ece4e795fe5dfeefb0bc5703f36bbc  mesa-19.1.0-rc5.tar.xz
SHA256: a753a8f1fd72b98d47eb99e1c5fb880b1046b05b6504346c5f947c40d9c32486  
mesa-19.1.0-rc5.tar.xz
SHA512: 
033920bbbf395104bfb6ffe9482e0f504b5cb0009be25bb1b0a4269bc6cf9c737de82350e994d568f454ed5b3206fc23927122032b3702122fe7edbc2d749e6d
  mesa-19.1.0-rc5.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.0-rc5.tar.xz.sig




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

Re: [Mesa-dev] [PATCH] radeonsi/nir: Fix type in bindless address computation

[Juan A. Suarez Romero]

On Tue, 2019-06-04 at 16:52 +0200, Connor Abbott wrote:
> On Tue, Jun 4, 2019 at 4:24 PM Juan A. Suarez Romero
>  wrote:
> > On Fri, 2019-05-31 at 14:55 +0200, Connor Abbott wrote:
> > > Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
> > 
> > Does it make sense to nominate this for stable release?
> 
> I don't think so, since radeonsi NIR still isn't enabled by default
> yet. This is work towards being able to do that.
> 

Thanks for the feedback!


J.A.

> Connor
> 

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

Re: [Mesa-dev] [PATCH] radeonsi/nir: Fix type in bindless address computation

[Juan A. Suarez Romero]

On Fri, 2019-05-31 at 14:55 +0200, Connor Abbott wrote:
> Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.

Does it make sense to nominate this for stable release?

J.A.

> ---
> 
> With this patch, we now have Piglit parity in debug mode.
> 
>  src/gallium/drivers/radeonsi/si_shader_nir.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_shader_nir.c 
> b/src/gallium/drivers/radeonsi/si_shader_nir.c
> index 19ed71ae05d..72e6ffbac8a 100644
> --- a/src/gallium/drivers/radeonsi/si_shader_nir.c
> +++ b/src/gallium/drivers/radeonsi/si_shader_nir.c
> @@ -1020,7 +1020,7 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
>* 16-dword slots for now.
>*/
>   dynamic_index = LLVMBuildMul(ctx->ac.builder, 
> dynamic_index,
> -  LLVMConstInt(ctx->i32, 2, 0), "");
> +  LLVMConstInt(ctx->i64, 2, 0), "");
>  
>   return si_load_image_desc(ctx, list, dynamic_index, 
> desc_type,
> dcc_off, true);
> @@ -1032,7 +1032,7 @@ si_nir_load_sampler_desc(struct ac_shader_abi *abi,
>* to prevent incorrect code generation and hangs.
>*/
>   dynamic_index = LLVMBuildMul(ctx->ac.builder, dynamic_index,
> -  LLVMConstInt(ctx->i32, 2, 0), "");
> +  LLVMConstInt(ctx->i64, 2, 0), "");
>   list = ac_build_pointer_add(>ac, list, dynamic_index);
>   return si_load_sampler_desc(ctx, list, ctx->i32_0, desc_type);
>   }

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

Re: [Mesa-dev] [PATCH] freedreno: Fix GCC build error.

[Juan A. Suarez Romero]

On Thu, 2019-05-30 at 21:48 +, Vinson Lee wrote:
> ../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is not 
> constant
> .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> ^
> 

Shouldn't this be nominated to stable?


J.A.

> Suggested-by: Kristian Høgsberg 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110698
> Signed-off-by: Vinson Lee 
> ---
>  src/freedreno/vulkan/tu_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/freedreno/vulkan/tu_device.c 
> b/src/freedreno/vulkan/tu_device.c
> index 2e930d9841fe..fdb9e1e0a1e2 100644
> --- a/src/freedreno/vulkan/tu_device.c
> +++ b/src/freedreno/vulkan/tu_device.c
> @@ -897,7 +897,7 @@ static const VkQueueFamilyProperties 
> tu_queue_family_properties = {
>VK_QUEUE_GRAPHICS_BIT | VK_QUEUE_COMPUTE_BIT | VK_QUEUE_TRANSFER_BIT,
> .queueCount = 1,
> .timestampValidBits = 64,
> -   .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> +   .minImageTransferGranularity = { 1, 1, 1 },
>  };
>  
>  void

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

Re: [Mesa-dev] Mesa 19.1.0 release plan

[Juan A. Suarez Romero]

On Mon, 2019-04-15 at 16:15 +0200, Juan A. Suarez Romero wrote:
> Hi all,
> 
> Here is the tentative release plan for 19.1.0.
> 
> As many of you are well aware, it's time to the next branch point.
> The calendar is already updated, so these are the tentative dates:
> 
>  Apr 30 2019 - Feature freeze/Release candidate 1
>  May 07 2019 - Release candidate 2
>  May 14 2019 - Release candidate 3
>  May 21 2019 - Release candidate 4/final release
> 

Last week we published the RC4, which should be in theory the last RC.

Unfortunately, there are still two issues blocking the release:

- https://bugs.freedesktop.org/show_bug.cgi?id=110357: there's a general feeling
that this shouldn't block the release. We are waiting to confirm if it is fine
remove this issue from the blocking list.

- https://bugs.freedesktop.org/show_bug.cgi?id=110302: seems Emil is working on
a fix for this. So we need to wait for it.


Hence, unless said the contrary, I'll go with another RC round (RC5) this week.
Hope those issues are unblocked this week so we can make the final release next
week.



J.A.

> This gives us around 2 weeks until the branch point.
> 
> Note: In the spirit of keeping things clearer and more transparent, we
> will be keeping track of any features planned for the release in
> Bugzilla [1].
> 
> Do add a separate "Depends on" for each work you have planned.
> Alternatively you can reply to this email and I'll add them for you.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=110439
> 
> Thanks
> 
>   J.A.
> 
> 
> ___
> 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] [ANNOUNCE] mesa 19.1.0-rc4

[Juan A. Suarez Romero]

Hello, list.

The fourth release candidate for Mesa 19.1.0 is now available.

Remind that right now there are two bugs blocking the final release:

#110302 - [bisected][regression] piglit egl-create-pbuffer-surface and 
egl-gl-colorspace regressions
#110357 - [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in 
new attempted "41" configuration


Chenglei Ren (1):
  anv/android: fix missing dependencies issue during parallel build

Christian Gmeiner (1):
  etnaviv: use the correct uniform dirty bits

Danylo Piliaiev (1):
  anv: Do not emulate texture swizzle for INPUT_ATTACHMENT, STORAGE_IMAGE

Dave Airlie (1):
  Revert "mesa: unreference current winsys buffers when unbinding winsys 
buffers"

Greg V (1):
  gallium: enable dmabuf on BSD as well

Juan A. Suarez Romero (1):
  Update version to 19.1.0-rc4

Lionel Landwerlin (3):
  vulkan/overlay: fix timestamp query emission with no pipeline stats
  vulkan: fix build dependency issue with generated files
  anv: fix apply_pipeline_layout pass for arrays of YCbCr descriptors

Marek Olšák (2):
  radeonsi: update buffer descriptors in all contexts after buffer 
invalidation
  radeonsi: fix a regression in si_rebind_buffer

Philipp Zabel (1):
  etnaviv: fill missing offset in etna_resource_get_handle

Qiang Yu (2):
  lima: fix lima_blit with non-zero level source resource
  lima: fix render to non-zero level texture

Timothy Arceri (1):
  Revert "st/mesa: expose 0 shader binary formats for compat profiles for 
Qt"

git tag: mesa-19.1.0-rc4

https://mesa.freedesktop.org/archive/mesa-19.1.0-rc4.tar.xz
MD5:  b95104cfa0edcd5877f3d58197e145bb  mesa-19.1.0-rc4.tar.xz
SHA1: 11203b0bfb44c77410795067f3ce8b6eed2afdae  mesa-19.1.0-rc4.tar.xz
SHA256: 3ca81ca19f4f76eae397e98a3e20772ae53d04cd8038370696fe4f9bd4ab489c  
mesa-19.1.0-rc4.tar.xz
SHA512: 
04cc5a537d803359b9eb3207f7b7ab1357126fe78ae0a0ba24df51d2fbbf4e0cf1815a60f99a10b33c822c08af0c84adef44849e73c883f5ce30fdae142c5b61
  mesa-19.1.0-rc4.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.0-rc4.tar.xz.sig




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

Re: [Mesa-dev] [PATCH] gallivm: fix default cbuf info.

[Juan A. Suarez Romero]

On Tue, 2019-05-28 at 02:08 +0200, Roland Scheidegger wrote:
> Am 27.05.19 um 11:39 schrieb Juan A. Suarez Romero:
> > On Fri, 2019-05-24 at 03:08 +0200, srol...@vmware.com wrote:
> > > From: Roland Scheidegger 
> > > 
> > > The default null_output really needs to be static, otherwise the values
> > > we'll eventually get later are doubly random (they are not initialized,
> > > and even if they were it's a pointer to a local stack variable).
> > > VMware bug 2349556.
> > 
> > Shouldn't this be CC to @stable ?
> I forgot to mention this, but it should not actually be an issue in the
> public branch, since that part of the information gathered there isn't
> actually used by llvmpipe, hence if it contains garbage or not doesn't
> matter. So there isn't really any need for stable.
> But we have a branch where llvmpipe uses it.
> 

Thanks for the feedback!

J.A.

> Roland
> 
> > 
> > > ---
> > >  src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c 
> > > b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> > > index b4e3c2fbc8..9fc9b8c77e 100644
> > > --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> > > +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> > > @@ -608,7 +608,7 @@ finished:
> > >  */
> > >  
> > > for (index = 0; index < PIPE_MAX_COLOR_BUFS; ++index) {
> > > -  const struct lp_tgsi_channel_info null_output[4];
> > > +  static const struct lp_tgsi_channel_info null_output[4];
> > >info->cbuf[index] = null_output;
> > > }
> > >  
> 
> 

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

Re: [Mesa-dev] [PATCH] gallivm: fix default cbuf info.

[Juan A. Suarez Romero]

On Fri, 2019-05-24 at 03:08 +0200, srol...@vmware.com wrote:
> From: Roland Scheidegger 
> 
> The default null_output really needs to be static, otherwise the values
> we'll eventually get later are doubly random (they are not initialized,
> and even if they were it's a pointer to a local stack variable).
> VMware bug 2349556.


Shouldn't this be CC to @stable ?


> ---
>  src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> index b4e3c2fbc8..9fc9b8c77e 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
> @@ -608,7 +608,7 @@ finished:
>  */
>  
> for (index = 0; index < PIPE_MAX_COLOR_BUFS; ++index) {
> -  const struct lp_tgsi_channel_info null_output[4];
> +  static const struct lp_tgsi_channel_info null_output[4];
>info->cbuf[index] = null_output;
> }
>  

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

Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation

[Juan A. Suarez Romero]

On Tue, 2019-05-21 at 15:10 -0400, Marek Olšák wrote:
> It should be fixed with: "[PATCH] radeonsi: fix a regression in 
> si_rebind_buffer"
> 
> Marek

Thanks! I'll reintroduce both commits for next 19.1 release.

J.A.
> On Tue, May 21, 2019, 6:24 AM Mike Lothian  wrote:
> > Can someone with access revert from master until this is fixed? It's
> > 
> > been broken for 3 days now
> > 
> > 
> > 
> > On Tue, 21 May 2019 at 09:01, Juan A. Suarez Romero  
> > wrote:
> > 
> > >
> > 
> > > On Tue, 2019-05-21 at 09:36 +0200, Gert Wollny wrote:
> > 
> > > > Hi Marek,
> > 
> > > >
> > 
> > > > it seems that this patch is causing a few issues [1], any idea what is
> > 
> > > > going on? Maybe it is best to revert the patch for now?
> > 
> > > >
> > 
> > > > Best,
> > 
> > > > Gert
> > 
> > > >
> > 
> > >
> > 
> > >
> > 
> > > As this is commit is causing issues, I'm withdrawing it out of 19.1 
> > > branch.
> > 
> > >
> > 
> > > If later a fix is provided, let me know so I can re-add it to the branch,
> > 
> > > together with the fix.
> > 
> > >
> > 
> > > Thanks.
> > 
> > >
> > 
> > > J.A.
> > 
> > >
> > 
> > > > [1] https://bugzilla.freedesktop.org/show_bug.cgi?id=110701
> > 
> > > >
> > 
> > > > On Fr, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> > 
> > > > > From: Marek Olšák 
> > 
> > > > >
> > 
> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108824
> > 
> > > > >
> > 
> > > > > Cc: 19.1 
> > 
> > > > > ---
> > 
> > > > >  src/gallium/drivers/radeonsi/si_descriptors.c | 94 -
> > 
> > > > > --
> > 
> > > > >  src/gallium/drivers/radeonsi/si_pipe.h|  2 +
> > 
> > > > >  src/gallium/drivers/radeonsi/si_state_draw.c  |  9 +-
> > 
> > > > >  3 files changed, 72 insertions(+), 33 deletions(-)
> > 
> > > > >
> > 
> > > > > diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> > 
> > > > > b/src/gallium/drivers/radeonsi/si_descriptors.c
> > 
> > > > > index 744fc9a15d7..6a4dcacc0f3 100644
> > 
> > > > > --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> > 
> > > > > +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> > 
> > > > > @@ -1580,242 +1580,272 @@ void
> > 
> > > > > si_update_needs_color_decompress_masks(struct si_context *sctx)
> > 
> > > > > si_samplers_update_needs_color_decompress_mask(
> > 
> > > > > > samplers[i]);
> > 
> > > > > si_images_update_needs_color_decompress_mask(
> > 
> > > > > > images[i]);
> > 
> > > > > si_update_shader_needs_decompress_mask(sctx, i);
> > 
> > > > > }
> > 
> > > > >
> > 
> > > > > si_resident_handles_update_needs_color_decompress(sctx);
> > 
> > > > >  }
> > 
> > > > >
> > 
> > > > >  /* BUFFER DISCARD/INVALIDATION */
> > 
> > > > >
> > 
> > > > > -/** Reset descriptors of buffer resources after \p buf has been
> > 
> > > > > invalidated. */
> > 
> > > > > +/* Reset descriptors of buffer resources after \p buf has been
> > 
> > > > > invalidated.
> > 
> > > > > + * If buf == NULL, reset all descriptors.
> > 
> > > > > + */
> > 
> > > > >  static void si_reset_buffer_resources(struct si_context *sctx,
> > 
> > > > >   struct si_buffer_resources
> > 
> > > > > *buffers,
> > 
> > > > >   unsigned descriptors_idx,
> > 
> > > > >   unsigned slot_mask,
> > 
> > > > >   struct pipe_resource *buf,
> > 
> > > > >   enum radeon_bo_priority priority)
> > 
> > > > >  {
> > 
> > >

[Mesa-dev] [ANNOUNCE] mesa 19.1.0-rc3

[Juan A. Suarez Romero]

Hello, list.

The third release candidate for Mesa 19.1.0 is now available.

Remind that right now there are two bugs blocking the final release:

#110302 - [bisected][regression] piglit egl-create-pbuffer-surface and 
egl-gl-colorspace regressions
#110357 - [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in 
new attempted "41" configuration


Caio Marcelo de Oliveira Filho (2):
  nir: Fix nir_opt_idiv_const when negatives are involved
  nir: Fix clone of nir_variable state slots

Charmaine Lee (2):
  st/mesa: purge framebuffers with current context after unbinding winsys 
buffers
  mesa: unreference current winsys buffers when unbinding winsys buffers

Dave Airlie (1):
  glsl: init packed in more constructors.

Eric Engestrom (2):
  util/os_file: always use the 'grow' mechanism
  meson: expose glapi through osmesa

Gert Wollny (1):
  Revert "softpipe/buffer: load only as many components as the the buffer 
resource type provides"

Ian Romanick (1):
  Revert "nir: add late opt to turn inot/b2f combos back to bcsel"

Jason Ekstrand (5):
  intel/fs/ra: Only add dest interference to sources that exist
  intel/fs/ra: Stop adding RA interference to too many SENDS nodes
  anv: Emulate texture swizzle in the shader when needed
  anv: Stop forcing bindless for images
  anv: Only consider minSampleShading when sampleShadingEnable is set

Juan A. Suarez Romero (2):
  cherry-ignore: radeonsi: update buffer descriptors in all contexts after 
buffer invalidation
  Update version to 19.1.0-rc3

Lionel Landwerlin (4):
  nir: fix lower_non_uniform_access pass
  vulkan/overlay-layer: fix cast errors
  vulkan/overlay: fix truncating error on 32bit platforms
  nir: lower_non_uniform_access: iterate over instructions safely

Marek Olšák (1):
  radeonsi: remove old_va parameter from si_rebind_buffer by remembering 
offsets

Nanley Chery (1):
  anv: Fix some depth buffer sampling cases on ICL+

Neha Bhende (1):
  draw: fix memory leak introduced 7720ce32a

Samuel Pitoiset (1):
  radv: add a workaround for Monster Hunter World and LLVM 7&8

git tag: mesa-19.1.0-rc3

https://mesa.freedesktop.org/archive/mesa-19.1.0-rc3.tar.xz
MD5:  414c5e038f3d16ff741236dda6065418  mesa-19.1.0-rc3.tar.xz
SHA1: c1e984fbeb7e86c8cd8b21f40b81372e0147d720  mesa-19.1.0-rc3.tar.xz
SHA256: 3c67d2114c48f0b8006208ec04e0b216e16e57cdff2e95ac8f05dd1e443a354f  
mesa-19.1.0-rc3.tar.xz
SHA512: 
740d5d13458b54e1942bfe7165938ec414aa7949aa60109ba872236f3b483c7305ac76b1b48c38dc6fd7691748106447757ac081f364952cc9e00f45fa9e2ea5
  mesa-19.1.0-rc3.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.0-rc3.tar.xz.sig



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

Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation

[Juan A. Suarez Romero]

On Tue, 2019-05-21 at 09:36 +0200, Gert Wollny wrote:
> Hi Marek, 
> 
> it seems that this patch is causing a few issues [1], any idea what is
> going on? Maybe it is best to revert the patch for now? 
> 
> Best, 
> Gert 
> 


As this is commit is causing issues, I'm withdrawing it out of 19.1 branch.

If later a fix is provided, let me know so I can re-add it to the branch,
together with the fix.

Thanks.

J.A.

> [1] https://bugzilla.freedesktop.org/show_bug.cgi?id=110701
> 
> On Fr, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> > From: Marek Olšák 
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108824
> > 
> > Cc: 19.1 
> > ---
> >  src/gallium/drivers/radeonsi/si_descriptors.c | 94 -
> > --
> >  src/gallium/drivers/radeonsi/si_pipe.h|  2 +
> >  src/gallium/drivers/radeonsi/si_state_draw.c  |  9 +-
> >  3 files changed, 72 insertions(+), 33 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> > b/src/gallium/drivers/radeonsi/si_descriptors.c
> > index 744fc9a15d7..6a4dcacc0f3 100644
> > --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> > +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> > @@ -1580,242 +1580,272 @@ void
> > si_update_needs_color_decompress_masks(struct si_context *sctx)
> > si_samplers_update_needs_color_decompress_mask(
> > > samplers[i]);
> > si_images_update_needs_color_decompress_mask(
> > > images[i]);
> > si_update_shader_needs_decompress_mask(sctx, i);
> > }
> >  
> > si_resident_handles_update_needs_color_decompress(sctx);
> >  }
> >  
> >  /* BUFFER DISCARD/INVALIDATION */
> >  
> > -/** Reset descriptors of buffer resources after \p buf has been
> > invalidated. */
> > +/* Reset descriptors of buffer resources after \p buf has been
> > invalidated.
> > + * If buf == NULL, reset all descriptors.
> > + */
> >  static void si_reset_buffer_resources(struct si_context *sctx,
> >   struct si_buffer_resources
> > *buffers,
> >   unsigned descriptors_idx,
> >   unsigned slot_mask,
> >   struct pipe_resource *buf,
> >   enum radeon_bo_priority priority)
> >  {
> > struct si_descriptors *descs = 
> > > descriptors[descriptors_idx];
> > unsigned mask = buffers->enabled_mask & slot_mask;
> >  
> > while (mask) {
> > unsigned i = u_bit_scan();
> > -   if (buffers->buffers[i] == buf) {
> > -   si_set_buf_desc_address(si_resource(buf),
> > buffers->offsets[i],
> > +   struct pipe_resource *buffer = buffers->buffers[i];
> > +
> > +   if (buffer && (!buf || buffer == buf)) {
> > +   si_set_buf_desc_address(si_resource(buffer),
> > buffers->offsets[i],
> > descs->list + i*4);
> > sctx->descriptors_dirty |= 1u <<
> > descriptors_idx;
> >  
> > radeon_add_to_gfx_buffer_list_check_mem(sctx,
> > -   si_reso
> > urce(buf),
> > +   si_reso
> > urce(buffer),
> > buffers
> > ->writable_mask & (1u << i) ?
> > 
> > RADEON_USAGE_READWRITE :
> > 
> > RADEON_USAGE_READ,
> > priorit
> > y, true);
> > }
> > }
> >  }
> >  
> > -/* Update all resource bindings where the buffer is bound, including
> > +/* Update all buffer bindings where the buffer is bound, including
> >   * all resource descriptors. This is invalidate_buffer without
> > - * the invalidation. */
> > + * the invalidation.
> > + *
> > + * If buf == NULL, update all buffer bindings.
> > + */
> >  void si_rebind_buffer(struct si_context *sctx, struct pipe_resource
> > *buf)
> >  {
> > struct si_resource *buffer = si_resource(buf);
> > unsigned i, shader;
> > unsigned num_elems = sctx->vertex_elements ?
> >sctx->vertex_elements->count :
> > 0;
> >  
> > /* We changed the buffer, now we need to bind it where the old
> > one
> >  * was bound. This consists of 2 things:
> >  *   1) Updating the resource descriptor and dirtying it.
> >  *   2) Adding a relocation to the CS, so that it's usable.
> >  */
> >  
> > /* Vertex buffers. */
> > -   if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> > +   if (!buffer) {
> > +   if (num_elems)
> > +   sctx->vertex_buffers_dirty = true;
> > +   } else if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> > for (i = 0; i < num_elems; i++) {
> > int vb = 

Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation

[Juan A. Suarez Romero]

nel: amdgpu :08:00.0:   in page starting
> at address 0x80010105 from 27
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> pid 839 thread systemsett:cs0 pid 842)
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> at address 0x80010105 from 27
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> pid 839 thread systemsett:cs0 pid 842)
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> at address 0x80010105 from 27
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> pid 839 thread systemsett:cs0 pid 842)
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> at address 0x80010105 from 27
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> pid 839 thread systemsett:cs0 pid 842)
> May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> at address 0x80010105 from 27
> May 18 15:31:44 quark kernel: amdgpu 0000:08:00.0:
> VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> May 18 15:31:49 quark kernel: gmc_v9_0_process_interrupt: 5337
> callbacks suppressed
> 
> Reverting 78e35df52aa2f7d770f929a0866a0faa89c261a9 fixes the issue for me
> 
> On Fri, 17 May 2019 at 20:59, Marek Olšák  wrote:
> > Thanks. It looks good.
> > 
> > Marek
> > 
> > On Fri, May 17, 2019 at 3:56 AM Juan A. Suarez Romero  
> > wrote:
> > > On Fri, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> > > > From: Marek Olšák 
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108824
> > > > 
> > > > Cc: 19.1 
> > > 
> > > Hi, Marek,
> > > 
> > > This patch didn't apply cleanly on 19.1 branch, so I've fixed the 
> > > conflicts.
> > > 
> > > You can find the solved patch in
> > > https://gitlab.freedesktop.org/mesa/mesa/commit/21620c889e3fc78be13f096fa273cfd27a3d
> > > 
> > > 
> > > Thanks!
> > > 
> > > 
> > > J.A.
> > > 
> > > > ---
> > > >  src/gallium/drivers/radeonsi/si_descriptors.c | 94 ---
> > > >  src/gallium/drivers/radeonsi/si_pipe.h|  2 +
> > > >  src/gallium/drivers/radeonsi/si_state_draw.c  |  9 +-
> > > >  3 files changed, 72 insertions(+), 33 deletions(-)
> > > > 
> > > > diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
> > > > b/src/gallium/drivers/radeonsi/si_descriptors.c
> > > > index 744fc9a15d7..6a4dcacc0f3 100644
> > > > --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> > > > +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> > > > @@ -1580,242 +1580,272 @@ void 
> > > > si_update_needs_color_decompress_masks(struct si_context *sctx)
> > > >   
> > > > si_samplers_update_needs_color_decompress_mask(>samplers[i]);
> > > >   
> > > > si_images_update_needs_color_decompress_mask(>images[i]);
> > > >   si_update_shader_needs_decompress_mask(sctx, i);
> > > >   }
> > > > 
> > > >   si_resident_handles_update_needs_color_decompress(sctx);
> > > >  }
> > > > 
> > > >  /* BUFFER DISCARD/INVALIDATION */
> > > > 
> > > > -/** Reset descriptors of buffer resources after \p buf has been 
> > > > invalidated. */
> > > > +/* Reset descriptors of buffer resources after \p buf has been 
> > > > invalidated.
> > > > + * If buf == NULL, reset all descriptors.
> > > > + */
> > > >  static void si_reset_buffer_resources(struct si_context *sctx,
> > > > struct si_buffer_resources *buffers,
> > > > unsigned descri

Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation

[Juan A. Suarez Romero]

On Fri, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> From: Marek Olšák 
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108824
> 
> Cc: 19.1 

Hi, Marek,

This patch didn't apply cleanly on 19.1 branch, so I've fixed the conflicts.

You can find the solved patch in 
https://gitlab.freedesktop.org/mesa/mesa/commit/21620c889e3fc78be13f096fa273cfd27a3d


Thanks!


J.A.

> ---
>  src/gallium/drivers/radeonsi/si_descriptors.c | 94 ---
>  src/gallium/drivers/radeonsi/si_pipe.h|  2 +
>  src/gallium/drivers/radeonsi/si_state_draw.c  |  9 +-
>  3 files changed, 72 insertions(+), 33 deletions(-)
> 
> diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
> b/src/gallium/drivers/radeonsi/si_descriptors.c
> index 744fc9a15d7..6a4dcacc0f3 100644
> --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> @@ -1580,242 +1580,272 @@ void si_update_needs_color_decompress_masks(struct 
> si_context *sctx)
>   
> si_samplers_update_needs_color_decompress_mask(>samplers[i]);
>   si_images_update_needs_color_decompress_mask(>images[i]);
>   si_update_shader_needs_decompress_mask(sctx, i);
>   }
>  
>   si_resident_handles_update_needs_color_decompress(sctx);
>  }
>  
>  /* BUFFER DISCARD/INVALIDATION */
>  
> -/** Reset descriptors of buffer resources after \p buf has been invalidated. 
> */
> +/* Reset descriptors of buffer resources after \p buf has been invalidated.
> + * If buf == NULL, reset all descriptors.
> + */
>  static void si_reset_buffer_resources(struct si_context *sctx,
> struct si_buffer_resources *buffers,
> unsigned descriptors_idx,
> unsigned slot_mask,
> struct pipe_resource *buf,
> enum radeon_bo_priority priority)
>  {
>   struct si_descriptors *descs = >descriptors[descriptors_idx];
>   unsigned mask = buffers->enabled_mask & slot_mask;
>  
>   while (mask) {
>   unsigned i = u_bit_scan();
> - if (buffers->buffers[i] == buf) {
> - si_set_buf_desc_address(si_resource(buf), 
> buffers->offsets[i],
> + struct pipe_resource *buffer = buffers->buffers[i];
> +
> + if (buffer && (!buf || buffer == buf)) {
> + si_set_buf_desc_address(si_resource(buffer), 
> buffers->offsets[i],
>   descs->list + i*4);
>   sctx->descriptors_dirty |= 1u << descriptors_idx;
>  
>   radeon_add_to_gfx_buffer_list_check_mem(sctx,
> - 
> si_resource(buf),
> + 
> si_resource(buffer),
>   
> buffers->writable_mask & (1u << i) ?
>   
> RADEON_USAGE_READWRITE :
>   
> RADEON_USAGE_READ,
>   priority, true);
>   }
>   }
>  }
>  
> -/* Update all resource bindings where the buffer is bound, including
> +/* Update all buffer bindings where the buffer is bound, including
>   * all resource descriptors. This is invalidate_buffer without
> - * the invalidation. */
> + * the invalidation.
> + *
> + * If buf == NULL, update all buffer bindings.
> + */
>  void si_rebind_buffer(struct si_context *sctx, struct pipe_resource *buf)
>  {
>   struct si_resource *buffer = si_resource(buf);
>   unsigned i, shader;
>   unsigned num_elems = sctx->vertex_elements ?
>  sctx->vertex_elements->count : 0;
>  
>   /* We changed the buffer, now we need to bind it where the old one
>* was bound. This consists of 2 things:
>*   1) Updating the resource descriptor and dirtying it.
>*   2) Adding a relocation to the CS, so that it's usable.
>*/
>  
>   /* Vertex buffers. */
> - if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> + if (!buffer) {
> + if (num_elems)
> + sctx->vertex_buffers_dirty = true;
> + } else if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
>   for (i = 0; i < num_elems; i++) {
>   int vb = sctx->vertex_elements->vertex_buffer_index[i];
>  
>   if (vb >= ARRAY_SIZE(sctx->vertex_buffer))
>   continue;
>   if (!sctx->vertex_buffer[vb].buffer.resource)
>   continue;
>  
>   if (sctx->vertex_buffer[vb].buffer.resource == buf) {
>   

[Mesa-dev] [ANNOUNCE] mesa 19.1.0-rc2

[Juan A. Suarez Romero]

Hello, list.

The second release candidate for Mesa 19.1.0 is now available.

Remind that right now there are two bugs blocking the final release:

#110302 - [bisected][regression] piglit egl-create-pbuffer-surface and 
egl-gl-colorspace regressions
#110357 - [REGRESSION] [BISECTED] [OpenGL CTS] cts-runner --type=gl46 fails in 
new attempted "41" configuration


Bas Nieuwenhuizen (1):
  radv: Do not use extra descriptor space for the 3rd plane.

Caio Marcelo de Oliveira Filho (1):
  anv: Fix limits when VK_EXT_descriptor_indexing is used

Dave Airlie (1):
  kmsro: add _dri.so to two of the kmsro drivers.

Dylan Baker (1):
  meson: Force the use of config-tool for llvm

Eric Engestrom (1):
  travis: fix syntax, and drop unused stuff

Gert Wollny (1):
  softpipe/buffer: load only as many components as the the buffer resource 
type provides

Juan A. Suarez Romero (1):
  Update version to 19.1.0-rc2

Józef Kucia (1):
  radv: clear vertex bindings while resetting command buffer

Kenneth Graunke (5):
  i965: Fix BRW_MEMZONE_LOW_4G heap size.
  i965: Force VMA alignment to be a multiple of the page size.
  i965: leave the top 4Gb of the high heap VMA unused
  i965: Fix memory leaks in brw_upload_cs_work_groups_surface().
  iris: Use full ways for L3 cache setup on Icelake.

Leo Liu (1):
  winsys/amdgpu: add VCN JPEG to no user fence group

Lionel Landwerlin (4):
  anv: rework queries writes to ensure ordering memory writes
  anv: fix use after free
  anv: Use corresponding type from the vector allocation
  vulkan/overlay: keep allocating draw data until it can be reused

Marek Olšák (1):
  st/mesa: fix 2 crashes in st_tgsi_lower_yuv

Rob Clark (1):
  freedreno/ir3: fix rasterflat/glxgears

Samuel Pitoiset (1):
  radv: fix setting the number of rectangles when it's dyanmic

Timothy Arceri (1):
  Revert "glx: Fix synthetic error generation in __glXSendError"

Tomeu Vizoso (2):
  panfrost: Fix two uninitialized accesses in compiler
  panfrost: Only take the fast paths on buffers aligned to block size

git tag: mesa-19.1.0-rc2

https://mesa.freedesktop.org/archive/mesa-19.1.0-rc2.tar.xz
MD5:  2607547a72c2b7a4dcc4fc09ebf0909a  mesa-19.1.0-rc2.tar.xz
SHA1: a38366408d6e10b323bc10c39cf217e486142be0  mesa-19.1.0-rc2.tar.xz
SHA256: 33ad7dce6e2c96f95a905bb898a488ff71d206f5787693115997d88a87fbccae  
mesa-19.1.0-rc2.tar.xz
SHA512: 
4d04bec48cbfb17d6dbe7b7700083612e46cbaad3e3630d6219fd1988f5e793cdb5100b8c2531a94b6078f8bb239fef27ed440122d12a2473be5be8648b6a8b1
  mesa-19.1.0-rc2.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.0-rc2.tar.xz.sig



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

[Mesa-dev] [ANNOUNCE] mesa 19.1.0-rc1

[Juan A. Suarez Romero]

The first release candidate for Mesa 19.1.0 is now available, with
1 week of delay.

The plan is to have one release candidate every Tuesday, until the
anticipated final release on 28th May 2019 (one week later the schedule
in the calendar, due the delay).

The expectation is that the 19.0 branch will remain alive with bi-
weekly releases until the 19.1.1 release.

In the path to 19.1.0 release, there is a tracker bug for the regressions found 
since 19.0:
https://bugs.freedesktop.org/show_bug.cgi?id=110625

Here are the people which helped shape the current release.

 1  Adam Jackson
 1  Albert Pal
12  Alejandro Piñeiro
 1  Alexander von Gluck IV
 1  Alexandros Frantzis
32  Alok Hota
   192  Alyssa Rosenzweig
 1  Alyssa Ross
 1  Amit Pundir
 5  Andre Heider
 2  Andreas Baierl
12  Andres Gomez
 5  Andrii Simiklit
 1  Antia Puentes
 7  Anuj Phogat
48  Axel Davy
 1  Bart Oldeman
   102  Bas Nieuwenhuizen
 1  Benjamin Gordon
 1  Benjamin Tissoires
 3  Boyan Ding
 1  Boyuan Zhang
51  Brian Paul
58  Caio Marcelo de Oliveira Filho
 1  Carlos Garnacho
17  Chad Versace
2  Charmaine Lee
78  Chia-I Wu
 3  Chris Forbes
19  Chris Wilson
11  Christian Gmeiner
 1  Chuck Atkins
 6  Connor Abbott
 2  Daniel Schürmann
 2  Daniel Stone
12  Danylo Piliaiev
60  Dave Airlie
 3  David Riley
 1  David Shao
 1  Dominik Drees
 1  Drew Davenport
39  Dylan Baker
 5  Eduardo Lima Mitev
 1  El Christianito
 6  Eleni Maria Stea
 3  Elie Tournier
27  Emil Velikov
 1  Emmanuel Gil Peyrot
   121  Eric Anholt
   138  Eric Engestrom
 5  Erico Nunes
79  Erik Faye-Lund
 2  Ernestas Kulik
 6  Francisco Jerez
 4  Fritz Koenig
33  Gert Wollny
 2  Greg V
 1  Grigori Goronzy
 4  Guido Günther
44  Gurchetan Singh
 1  Guttula, Suresh
 1  Hal Gentz
 1  Heinrich
39  Iago Toral Quiroga
54  Ian Romanick
 5  Icenowy Zheng
14  Ilia Mirkin
 1  Illia Iorin
12  James Zhu
 2  Jan Vesely
   202  Jason Ekstrand
 1  Jian-Hong Pan
 1  Jiang, Sonny
 3  John Stultz
 1  Jon Turney
   21  Jonathan Marek
22  Jordan Justen
 4  Jose Maria Casanova Crespo
 1  José Fonseca
16  Juan A. Suarez Romero
 5  Julien Isorce
 2  Józef Kucia
82  Karol Herbst
 3  Kasireddy, Vivek
   866  Kenneth Graunke
 1  Kevin Strasser
 1  Khaled Emara
 1  Khem Raj
 1  Kishore Kadiyala
 1  Konstantin Kharlamov
49  Kristian Høgsberg
 5  Leo Liu
 2  Lepton Wu
   113  Lionel Landwerlin
 3  Lubomir Rintel
 3  Lucas Stach
   115  Marek Olšák
 1  Mario Kleiner
 5  Mark Janes
 2  Mateusz Krzak
22  Mathias Fröhlich
 7  Matt Turner
 1  Matthias Lorenz
 6  Mauro Rossi
 1  Maya Rashish
19  Michel Dänzer
 6  Mike Blumenkrantz
 1  Nanley Chery
 1  Neha Bhende
 9  Nicolai Hähnle
 3  Oscar Blumberg
 1  Patrick Lerda
 1  Patrick Rudolph
12  Pierre Moreau
 3  Plamena Manolova
 7  Qiang Yu
45  Rafael Antognolli
 1  Ray Zhang
 1  Rhys Kidd
27  Rhys Perry
   130  Rob Clark
 2  Rob Herring
 1  Rodrigo Vivi
 2  Roland Scheidegger
 1  Romain Failliot
 1  Ross Burton
 1  Ryan Houdek
 9  Sagar Ghuge
 4  Samuel Iglesias Gonsálvez
   141  Samuel Pitoiset
 4  Sergii Romantsov
 1  Sonny Jiang
42  Tapani Pälli
 5  Thomas Hellstrom
 1  Timo Aaltonen
69  Timothy Arceri
19  Timur Kristóf
 1  Tobias Klausmann
 1  Tomasz Figa
17  Tomeu Vizoso
 8  Toni Lönnberg
 2  Topi Pohjolainen
 2  Vasily Khoruzhick
 4  Vinson Lee
 1  Vivek Kasireddy
 1  Xavier Bouchoux
 1  Yevhenii Kolesnikov
 1  coypu
 1  davidbepo
 1  grmat
 1  pal1000
 3  suresh guttula


git tag: mesa-19.1.0-rc1

https://mesa.freedesktop.org/archive/mesa-19.1.0-rc1.tar.xz
MD5:  3d94c1cebf9d607f361f312906efdad5  mesa-19.1.0-rc1.tar.xz
SHA1: a0abdc582beaba6f31f24ef622b32f9b8391cb76  mesa-19.1.0-rc1.tar.xz
SHA256: a09d0319e18783e2416d6dfce401bb872675874b332a91bfe880841eb6156e73  
mesa-19.1.0-rc1.tar.xz
SHA512: 
a56215882a7c22b7b8fe57d5703914d674841e4045676e2cc2e7834d17f4d5a765516bec4f01eea6772c50e1d979cc430e032302f38c6e7a4274bc43a4d647b1
  mesa-19.1.0-rc1.tar.xz
PGP:  https://mesa.freedesktop.org/archive/mesa-19.1.0-rc1.tar.xz.sig



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

[Mesa-dev] [PATCH] util: include missing stdlib header

[Juan A. Suarez Romero]

Fixes scons/mingw building:

src/util/os_file.c: In function ‘os_read_file’:
src/util/os_file.c:126:11: error: ‘NULL’ undeclared (first use in this 
function); did you mean ‘_DLL’?
return NULL;
   ^~~~
   _DLL
src/util/os_file.c:126:11: note: each undeclared identifier is reported only 
once for each function it appears in

Fixes: 316964709e2 ("util: add os_read_file() helper")
CC: Eric Engestrom 
---
 src/util/os_file.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/util/os_file.h b/src/util/os_file.h
index 2f97c19ed55..97c42b0aefc 100644
--- a/src/util/os_file.h
+++ b/src/util/os_file.h
@@ -12,6 +12,7 @@
 extern "C" {
 #endif
 
+#include 
 /*
  * Read a file.
  * Returns a char* that the caller must free(), or NULL and sets errno.
-- 
2.20.1

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

[Mesa-dev] [PATCH] Revert "intel/compiler: split is_partial_write() into two variants"

[Juan A. Suarez Romero]

This reverts commit 40b3abb4d16af4cef0307e1b4904c2ec0924299e.

It is not clear that this commit was entirely correct, and unfortunately
it was pushed by error.

CC: Jason Ekstrand 
---

Jason, we agreed on leaving this out of the VK_KHR_shader_float16_int8
patchset, but due a mistake I've pushed it with the other patches.

So here is the revert.


 src/intel/compiler/brw_fs.cpp | 31 ---
 .../compiler/brw_fs_cmod_propagation.cpp  | 20 ++--
 .../compiler/brw_fs_copy_propagation.cpp  |  8 ++---
 src/intel/compiler/brw_fs_cse.cpp |  3 +-
 .../compiler/brw_fs_dead_code_eliminate.cpp   |  2 +-
 src/intel/compiler/brw_fs_live_variables.cpp  |  2 +-
 src/intel/compiler/brw_fs_reg_allocate.cpp|  2 +-
 .../compiler/brw_fs_register_coalesce.cpp |  2 +-
 .../compiler/brw_fs_saturate_propagation.cpp  |  7 ++---
 src/intel/compiler/brw_fs_sel_peephole.cpp|  4 +--
 src/intel/compiler/brw_ir_fs.h|  3 +-
 11 files changed, 30 insertions(+), 54 deletions(-)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 22eefd4ef49..335eaa0e934 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -734,33 +734,14 @@ fs_visitor::limit_dispatch_width(unsigned n, const char 
*msg)
  * it.
  */
 bool
-fs_inst::is_partial_reg_write() const
+fs_inst::is_partial_write() const
 {
return ((this->predicate && this->opcode != BRW_OPCODE_SEL) ||
+   (this->exec_size * type_sz(this->dst.type)) < 32 ||
!this->dst.is_contiguous() ||
-   (this->exec_size * type_sz(this->dst.type)) < REG_SIZE ||
this->dst.offset % REG_SIZE != 0);
 }
 
-/**
- * Returns true if the instruction has a flag that means it won't
- * update an entire variable for the given dispatch width.
- *
- * This is only different from is_partial_reg_write() for SIMD8
- * dispatches of 16-bit (or smaller) instructions.
- */
-bool
-fs_inst::is_partial_var_write(uint32_t dispatch_width) const
-{
-   const uint32_t type_size = type_sz(this->dst.type);
-   uint32_t var_size = MIN2(REG_SIZE, dispatch_width * type_size);
-
-   return ((this->predicate && this->opcode != BRW_OPCODE_SEL) ||
-   !this->dst.is_contiguous() ||
-   (this->exec_size * type_sz(this->dst.type)) < var_size ||
-   this->dst.offset % var_size != 0);
-}
-
 unsigned
 fs_inst::components_read(unsigned i) const
 {
@@ -2943,7 +2924,7 @@ fs_visitor::opt_register_renaming()
   if (depth == 0 &&
   inst->dst.file == VGRF &&
   alloc.sizes[inst->dst.nr] * REG_SIZE == inst->size_written &&
-  !inst->is_partial_reg_write()) {
+  !inst->is_partial_write()) {
  if (remap[dst] == ~0u) {
 remap[dst] = dst;
  } else {
@@ -3147,7 +3128,7 @@ fs_visitor::compute_to_mrf()
   next_ip++;
 
   if (inst->opcode != BRW_OPCODE_MOV ||
- inst->is_partial_reg_write() ||
+ inst->is_partial_write() ||
  inst->dst.file != MRF || inst->src[0].file != VGRF ||
  inst->dst.type != inst->src[0].type ||
  inst->src[0].abs || inst->src[0].negate ||
@@ -3180,7 +3161,7 @@ fs_visitor::compute_to_mrf()
 * that writes that reg, but it would require smarter
 * tracking.
 */
-   if (scan_inst->is_partial_reg_write())
+   if (scan_inst->is_partial_write())
   break;
 
 /* Handling things not fully contained in the source of the copy
@@ -3498,7 +3479,7 @@ fs_visitor::remove_duplicate_mrf_writes()
   if (inst->opcode == BRW_OPCODE_MOV &&
  inst->dst.file == MRF &&
  inst->src[0].file != ARF &&
- !inst->is_partial_reg_write()) {
+ !inst->is_partial_write()) {
  last_mrf_move[inst->dst.nr] = inst;
   }
}
diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp 
b/src/intel/compiler/brw_fs_cmod_propagation.cpp
index a2c11e0959c..c9725263929 100644
--- a/src/intel/compiler/brw_fs_cmod_propagation.cpp
+++ b/src/intel/compiler/brw_fs_cmod_propagation.cpp
@@ -50,13 +50,13 @@
 
 static bool
 cmod_propagate_cmp_to_add(const gen_device_info *devinfo, bblock_t *block,
-  fs_inst *inst, unsigned dispatch_width)
+  fs_inst *inst)
 {
bool read_flag = false;
 
foreach_inst_in_block_reverse_starting_from(fs_inst, scan_inst, inst) {
   if (scan_inst->opcode == BRW_OPCODE_ADD &&
-  !scan_inst->is_partial_var_write(dispatch_width) &&
+  !scan_inst->is_partial_write() &&
   scan_inst->exec_size == inst->exec_size) {
  bool negate;
 
@@ -126,7 +126,7 @@ cmod_propagate_cmp_to_add(const gen_device_info *devinfo, 
bblock_t *block,
  */
 static bool
 cmod_propagate_not(const gen_device_info *devinfo, bblock_t *block,
-   fs_inst *inst, unsigned dispatch_width)
+   fs_inst *inst)
 {
const enum brw_conditional_mod cond = 

Re: [Mesa-dev] [PATCH] nir/spirv: short-circuit when conditional branch contains end block

[Juan A. Suarez Romero]

On Thu, 2019-03-14 at 11:25 -0500, Jason Ekstrand wrote:
> Looking at this a bit more, I'm not sure that just short-circuiting actually 
> covers all the cases.  Unfortunately, we don't know what all the cases are 
> because the SPIR-V spec doesn't say.  I'm trying to work towards fixing that 
> right now.
> 
> 

Did you have time to check this?
J.A.
> --Jason
> 
> 
> On Wed, Mar 6, 2019 at 5:25 AM Juan A. Suarez Romero  
> wrote:
> > This fixes the case when the SPIR-V code has two nested conditional
> > 
> > branches, but only one selection merge:
> > 
> > 
> > 
> > [...]
> > 
> > %1 = OpLabel
> > 
> >  OpSelectionMerge %2 None
> > 
> >  OpBranchConditional %3 %4 %2
> > 
> > %4 = OpLabel
> > 
> >  OpBranchConditional %3 %5 %2
> > 
> > %5 = OpLabel
> > 
> >  OpBranch %2
> > 
> > %2 = OpLabel
> > 
> > [...]
> > 
> > 
> > 
> > In the second OpBranchConditional, as the else-part is the end
> > 
> > block (started in the first OpBranchConditional) we can just follow the
> > 
> > then-part.
> > 
> > 
> > 
> > This fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle
> > 
> > 
> > 
> > CC: Jason Ekstrand 
> > 
> > ---
> > 
> >  src/compiler/spirv/vtn_cfg.c | 11 ++-
> > 
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > 
> > 
> > diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
> > 
> > index 7868eeb60bc..f749118efbe 100644
> > 
> > --- a/src/compiler/spirv/vtn_cfg.c
> > 
> > +++ b/src/compiler/spirv/vtn_cfg.c
> > 
> > @@ -605,7 +605,16 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct 
> > list_head *cf_list,
> > 
> >  }
> > 
> >   } else if (if_stmt->then_type == vtn_branch_type_none &&
> > 
> >  if_stmt->else_type == vtn_branch_type_none) {
> > 
> > -/* Neither side of the if is something we can short-circuit. */
> > 
> > +/* Neither side of the if is something we can short-circuit,
> > 
> > + * unless one of the blocks is the end block. */
> > 
> > +if (then_block == end) {
> > 
> > +   block = else_block;
> > 
> > +   continue;
> > 
> > +} else if (else_block == end) {
> > 
> > +   block = then_block;
> > 
> > +   continue;
> > 
> > +}
> > 
> > +
> > 
> >  vtn_assert((*block->merge & SpvOpCodeMask) == 
> > SpvOpSelectionMerge);
> > 
> >  struct vtn_block *merge_block =
> > 
> > vtn_value(b, block->merge[1], vtn_value_type_block)->block;
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v7] intel/compiler: validate region restrictions for mixed float mode

[Juan A. Suarez Romero]

On Wed, 2019-04-17 at 13:17 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero"  writes:
> 
> > From: Iago Toral Quiroga 
> > 
> > v2:
> >  - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-float conversions.
> > 
> > v3 (Curro):
> > - Check all the accummulators
> > - Constify declarations
> > - Do not check src1 type in single-source instructions.
> > - Check for all instructions that read accumulator (either implicitly or
> >   explicitly)
> > - Check restrictions in src1 too.
> > - Merge conditional block
> > - Add invalid test case.
> > 
> > v4 (Curro):
> > - Assert on 3-src instructions, as they are not validated.
> > - Get rid of types_are_mixed_float(), as we know instruction is mixed
> >   float at that point.
> > - Remove conditions from not verified case.
> > - Fix brackets on conditional.
> > ---
> >  src/intel/compiler/brw_eu_validate.c| 268 ++
> >  src/intel/compiler/test_eu_validate.cpp | 630 
> >  2 files changed, 898 insertions(+)
> > 
> > diff --git a/src/intel/compiler/brw_eu_validate.c 
> > b/src/intel/compiler/brw_eu_validate.c
> > index cfaf126e2f5..9530d4da209 100644
> > --- a/src/intel/compiler/brw_eu_validate.c
> > +++ b/src/intel/compiler/brw_eu_validate.c
> > @@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info *devinfo, 
> > const brw_inst *inst)
> >brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
> >  }
> >  
> > +static bool
> > +src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> > +{
> > +   return brw_inst_src0_reg_file(devinfo, inst) == 
> > BRW_ARCHITECTURE_REGISTER_FILE &&
> > +  (brw_inst_src0_da_reg_nr(devinfo, inst) & 0xF0) == 
> > BRW_ARF_ACCUMULATOR;
> > +}
> > +
> > +static bool
> > +src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> > +{
> > +   return brw_inst_src1_reg_file(devinfo, inst) == 
> > BRW_ARCHITECTURE_REGISTER_FILE &&
> > +  (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) == 
> > BRW_ARF_ACCUMULATOR;
> > +}
> > +
> >  static bool
> >  src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
> >  {
> > @@ -275,6 +289,24 @@ sources_not_null(const struct gen_device_info *devinfo,
> > return error_msg;
> >  }
> >  
> > +static bool
> > +inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst 
> > *inst)
> > +{
> > +   /* Check instructions that use implicit accumulator sources */
> > +   switch (brw_inst_opcode(devinfo, inst)) {
> > +   case BRW_OPCODE_MAC:
> > +   case BRW_OPCODE_MACH:
> > +   case BRW_OPCODE_SADA2:
> > +  return true;
> > +   }
> > +
> > +   /* FIXME: support 3-src instructions */
> > +   unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > +   assert(num_sources < 3);
> > +
> > +   return src0_is_acc(devinfo, inst) || (num_sources > 1 && 
> > src1_is_acc(devinfo, inst));
> > +}
> > +
> >  static struct string
> >  send_restrictions(const struct gen_device_info *devinfo,
> >const brw_inst *inst)
> > @@ -938,6 +970,241 @@ general_restrictions_on_region_parameters(const 
> > struct gen_device_info *devinfo,
> > return error_msg;
> >  }
> >  
> > +static struct string
> > +special_restrictions_for_mixed_float_mode(const struct gen_device_info 
> > *devinfo,
> > +  const brw_inst *inst)
> > +{
> > +   struct string error_msg = { .str = NULL, .len = 0 };
> > +
> > +   const unsigned opcode = brw_inst_opcode(devinfo, inst);
> > +   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > +   if (num_sources >= 3)
> > +  return error_msg;
> > +
> > +   if (!is_mixed_float(devinfo, inst))
> > +  return error_msg;
> > +
> > +   unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
> > +   bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
> > +
> > +   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> > +   enum brw_reg_type src1_type = num_sources > 1 ?
> > + brw_inst_src1_type(devinfo, inst) : 0;
> > +   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> > +
> > +   unsigned dst_stride = STRIDE(brw_i

[Mesa-dev] [PATCH v7] intel/compiler: validate region restrictions for mixed float mode

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

v2:
 - Adapted unit tests to make them consistent with the changes done
   to the validation of half-float conversions.

v3 (Curro):
- Check all the accummulators
- Constify declarations
- Do not check src1 type in single-source instructions.
- Check for all instructions that read accumulator (either implicitly or
  explicitly)
- Check restrictions in src1 too.
- Merge conditional block
- Add invalid test case.

v4 (Curro):
- Assert on 3-src instructions, as they are not validated.
- Get rid of types_are_mixed_float(), as we know instruction is mixed
  float at that point.
- Remove conditions from not verified case.
- Fix brackets on conditional.
---
 src/intel/compiler/brw_eu_validate.c| 268 ++
 src/intel/compiler/test_eu_validate.cpp | 630 
 2 files changed, 898 insertions(+)

diff --git a/src/intel/compiler/brw_eu_validate.c 
b/src/intel/compiler/brw_eu_validate.c
index cfaf126e2f5..9530d4da209 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info *devinfo, const 
brw_inst *inst)
   brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
 }
 
+static bool
+src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   return brw_inst_src0_reg_file(devinfo, inst) == 
BRW_ARCHITECTURE_REGISTER_FILE &&
+  (brw_inst_src0_da_reg_nr(devinfo, inst) & 0xF0) == 
BRW_ARF_ACCUMULATOR;
+}
+
+static bool
+src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   return brw_inst_src1_reg_file(devinfo, inst) == 
BRW_ARCHITECTURE_REGISTER_FILE &&
+  (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) == 
BRW_ARF_ACCUMULATOR;
+}
+
 static bool
 src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
 {
@@ -275,6 +289,24 @@ sources_not_null(const struct gen_device_info *devinfo,
return error_msg;
 }
 
+static bool
+inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   /* Check instructions that use implicit accumulator sources */
+   switch (brw_inst_opcode(devinfo, inst)) {
+   case BRW_OPCODE_MAC:
+   case BRW_OPCODE_MACH:
+   case BRW_OPCODE_SADA2:
+  return true;
+   }
+
+   /* FIXME: support 3-src instructions */
+   unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   assert(num_sources < 3);
+
+   return src0_is_acc(devinfo, inst) || (num_sources > 1 && 
src1_is_acc(devinfo, inst));
+}
+
 static struct string
 send_restrictions(const struct gen_device_info *devinfo,
   const brw_inst *inst)
@@ -938,6 +970,241 @@ general_restrictions_on_region_parameters(const struct 
gen_device_info *devinfo,
return error_msg;
 }
 
+static struct string
+special_restrictions_for_mixed_float_mode(const struct gen_device_info 
*devinfo,
+  const brw_inst *inst)
+{
+   struct string error_msg = { .str = NULL, .len = 0 };
+
+   const unsigned opcode = brw_inst_opcode(devinfo, inst);
+   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   if (num_sources >= 3)
+  return error_msg;
+
+   if (!is_mixed_float(devinfo, inst))
+  return error_msg;
+
+   unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
+   bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
+
+   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+   enum brw_reg_type src1_type = num_sources > 1 ?
+ brw_inst_src1_type(devinfo, inst) : 0;
+   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+
+   unsigned dst_stride = STRIDE(brw_inst_dst_hstride(devinfo, inst));
+   bool dst_is_packed = is_packed(exec_size * dst_stride, exec_size, 
dst_stride);
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"Indirect addressing on source is not supported when source and
+* destination data types are mixed float."
+*/
+   ERROR_IF(brw_inst_src0_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT ||
+(num_sources > 1 &&
+ brw_inst_src1_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT),
+"Indirect addressing on source is not supported when source and "
+"destination data types are mixed float");
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is f32. Instruction
+* execution size must be no more than 8."
+*/
+   ERROR_IF(exec_size > 8 && dst_type == BRW_REGISTER_TYPE_F,
+"Mixed float mode with 32-bit float destination is limited "
+"to SIMD8");
+
+   if (is_align16) {
+  /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+   * Float Operations:
+   *
+   *   "In Align16 mode, when half float and float data types are mixed
+   *

Re: [Mesa-dev] Mesa 19.1.0 release plan

[Juan A. Suarez Romero]

On Mon, 2019-04-15 at 18:57 +0300, Eero Tamminen wrote:
> Hi,
> 
> On 15.4.2019 17.15, Juan A. Suarez Romero wrote:
> > Here is the tentative release plan for 19.1.0.
> > 
> > As many of you are well aware, it's time to the next branch point.
> > The calendar is already updated, so these are the tentative dates:
> > 
> >   Apr 30 2019 - Feature freeze/Release candidate 1
> >   May 07 2019 - Release candidate 2
> >   May 14 2019 - Release candidate 3
> >   May 21 2019 - Release candidate 4/final release
> > 
> > This gives us around 2 weeks until the branch point.
> > 
> > Note: In the spirit of keeping things clearer and more transparent, we
> > will be keeping track of any features planned for the release in
> > Bugzilla [1].
> > 
> > Do add a separate "Depends on" for each work you have planned.
> > Alternatively you can reply to this email and I'll add them for you.
> > 
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=110439
> 
> Should the current GPU hang bugs initially be blockers for that?
> 
> For example the remaining (open) mesa-19.0 blocker bug:
>   https://bugs.freedesktop.org/show_bug.cgi?id=108820
> 

I understand as 19.0 was released anyway, that issue is not actually a blocker.


J.A.



> (There has been no comment for the attached error states from Mesa devs
> since Lionel's initial comment 4 months ago, e.g. on whether Jakub's and
> my cases are same or should they be filed as separate bugs.)
> 
> 
>   - Eero
> ___
> 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] Mesa 19.1.0 release plan

[Juan A. Suarez Romero]

Hi all,

Here is the tentative release plan for 19.1.0.

As many of you are well aware, it's time to the next branch point.
The calendar is already updated, so these are the tentative dates:

 Apr 30 2019 - Feature freeze/Release candidate 1
 May 07 2019 - Release candidate 2
 May 14 2019 - Release candidate 3
 May 21 2019 - Release candidate 4/final release

This gives us around 2 weeks until the branch point.

Note: In the spirit of keeping things clearer and more transparent, we
will be keeping track of any features planned for the release in
Bugzilla [1].

Do add a separate "Depends on" for each work you have planned.
Alternatively you can reply to this email and I'll add them for you.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=110439

Thanks

J.A.


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

Re: [Mesa-dev] [PATCH v6 32/35] intel/compiler: validate region restrictions for mixed float mode

[Juan A. Suarez Romero]

On Wed, 2019-04-10 at 17:13 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero"  writes:
> 
> > From: Iago Toral Quiroga 
> > 
> > v2:
> >  - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-float conversions.
> > 
> > v3 (Curro):
> > - Check all the accummulators
> > - Constify declarations
> > - Do not check src1 type in single-source instructions.
> > - Check for all instructions that read accumulator (either implicitly or
> >   explicitly)
> > - Check restrictions in src1 too.
> > - Merge conditional block
> > - Add invalid test case.
> > ---
> >  src/intel/compiler/brw_eu_validate.c| 290 +++
> >  src/intel/compiler/test_eu_validate.cpp | 631 
> >  2 files changed, 921 insertions(+)
> > 
> > diff --git a/src/intel/compiler/brw_eu_validate.c 
> > b/src/intel/compiler/brw_eu_validate.c
> > index cfaf126e2f5..4a735641c86 100644
> > --- a/src/intel/compiler/brw_eu_validate.c
> > +++ b/src/intel/compiler/brw_eu_validate.c
> > @@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info *devinfo, 
> > const brw_inst *inst)
> >brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
> >  }
> >  
> > +static bool
> > +src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> > +{
> > +   return brw_inst_src0_reg_file(devinfo, inst) == 
> > BRW_ARCHITECTURE_REGISTER_FILE &&
> > +  (brw_inst_src0_da_reg_nr(devinfo, inst) & 0xF0) == 
> > BRW_ARF_ACCUMULATOR;
> > +}
> > +
> > +static bool
> > +src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> > +{
> > +   return brw_inst_src1_reg_file(devinfo, inst) == 
> > BRW_ARCHITECTURE_REGISTER_FILE &&
> > +  (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) == 
> > BRW_ARF_ACCUMULATOR;
> > +}
> > +
> >  static bool
> >  src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
> >  {
> > @@ -275,6 +289,27 @@ sources_not_null(const struct gen_device_info *devinfo,
> > return error_msg;
> >  }
> >  
> > +static bool
> > +inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst 
> > *inst)
> > +{
> > +   /* Check instructions that use implicit accumulator sources */
> > +   switch (brw_inst_opcode(devinfo, inst)) {
> > +   case BRW_OPCODE_MAC:
> > +   case BRW_OPCODE_MACH:
> > +   case BRW_OPCODE_SADA2:
> > +  return true;
> > +   }
> > +
> > +   /* Instructions with three source operands cannot use explicit 
> > accumulator
> > +* operands.
> > +*/
> 
> They can on Gen10+.  Yeah, I know, it's quite a pain to have to
> special-case 3src instructions everywhere in the validator code...


Checking other parts of code, I'll assume that srcN_is_acc() should return false
for align16 mode; at least in them there're assertions that in this mode srcs
can only be GRF.

OTOH, is it worth to handle here the case for 3src instructions allowing
explicit accumulator? If other parts of drive asume this is not possible, I
understand it would be better to fix this in all the code in a separate patchset
(not related with float16).


> 
> > +   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > +   if (num_sources > 2)
> > +  return false;
> > +
> > +   return src0_is_acc(devinfo, inst) || (num_sources > 1 && 
> > src1_is_acc(devinfo, inst));
> > +}
> > +
> >  static struct string
> >  send_restrictions(const struct gen_device_info *devinfo,
> >const brw_inst *inst)
> > @@ -938,6 +973,260 @@ general_restrictions_on_region_parameters(const 
> > struct gen_device_info *devinfo,
> > return error_msg;
> >  }
> >  
> > +static struct string
> > +special_restrictions_for_mixed_float_mode(const struct gen_device_info 
> > *devinfo,
> > +  const brw_inst *inst)
> > +{
> > +   struct string error_msg = { .str = NULL, .len = 0 };
> > +
> > +   const unsigned opcode = brw_inst_opcode(devinfo, inst);
> > +   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > +   if (num_sources >= 3)
> > +  return error_msg;
> > +
> > +   if (!is_mixed_float(devinfo, inst))
> > +  return error_msg;
> > +
> > +   unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
> > +   bool is_align16 = brw

Re: [Mesa-dev] [PATCH v6 32/35] intel/compiler: validate region restrictions for mixed float mode

[Juan A. Suarez Romero]

On Wed, 2019-04-10 at 17:13 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero"  writes:
> 
> > From: Iago Toral Quiroga 
> > 
> > v2:
> >  - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-float conversions.
> > 
> > v3 (Curro):
> > - Check all the accummulators
> > - Constify declarations
> > - Do not check src1 type in single-source instructions.
> > - Check for all instructions that read accumulator (either implicitly or
> >   explicitly)
> > - Check restrictions in src1 too.
> > - Merge conditional block
> > - Add invalid test case.
> > ---
> >  src/intel/compiler/brw_eu_validate.c| 290 +++
> >  src/intel/compiler/test_eu_validate.cpp | 631 
> >  2 files changed, 921 insertions(+)
> > 
> > diff --git a/src/intel/compiler/brw_eu_validate.c 
> > b/src/intel/compiler/brw_eu_validate.c
> > index cfaf126e2f5..4a735641c86 100644
> > --- a/src/intel/compiler/brw_eu_validate.c
> > +++ b/src/intel/compiler/brw_eu_validate.c
> > @@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info *devinfo, 
> > const brw_inst *inst)
> >brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
> >  }
> >  
> > +static bool
> > +src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> > +{
> > +   return brw_inst_src0_reg_file(devinfo, inst) == 
> > BRW_ARCHITECTURE_REGISTER_FILE &&
> > +  (brw_inst_src0_da_reg_nr(devinfo, inst) & 0xF0) == 
> > BRW_ARF_ACCUMULATOR;
> > +}
> > +
> > +static bool
> > +src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> > +{
> > +   return brw_inst_src1_reg_file(devinfo, inst) == 
> > BRW_ARCHITECTURE_REGISTER_FILE &&
> > +  (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) == 
> > BRW_ARF_ACCUMULATOR;
> > +}
> > +
> >  static bool
> >  src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
> >  {
> > @@ -275,6 +289,27 @@ sources_not_null(const struct gen_device_info *devinfo,
> > return error_msg;
> >  }
> >  
> > +static bool
> > +inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst 
> > *inst)
> > +{
> > +   /* Check instructions that use implicit accumulator sources */
> > +   switch (brw_inst_opcode(devinfo, inst)) {
> > +   case BRW_OPCODE_MAC:
> > +   case BRW_OPCODE_MACH:
> > +   case BRW_OPCODE_SADA2:
> > +  return true;
> > +   }
> > +
> > +   /* Instructions with three source operands cannot use explicit 
> > accumulator
> > +* operands.
> > +*/
> 
> They can on Gen10+.  Yeah, I know, it's quite a pain to have to
> special-case 3src instructions everywhere in the validator code...

Is this strictly for Gen>10 or includes Gen10? In the Gen10 PRM still says that
3-src opearand instructions cannot use explicit accumulator


> 
> > +   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > +   if (num_sources > 2)
> > +  return false;
> > +
> > +   return src0_is_acc(devinfo, inst) || (num_sources > 1 && 
> > src1_is_acc(devinfo, inst));
> > +}
> > +
> >  static struct string
> >  send_restrictions(const struct gen_device_info *devinfo,
> >const brw_inst *inst)
> > @@ -938,6 +973,260 @@ general_restrictions_on_region_parameters(const 
> > struct gen_device_info *devinfo,
> > return error_msg;
> >  }
> >  
> > +static struct string
> > +special_restrictions_for_mixed_float_mode(const struct gen_device_info 
> > *devinfo,
> > +  const brw_inst *inst)
> > +{
> > +   struct string error_msg = { .str = NULL, .len = 0 };
> > +
> > +   const unsigned opcode = brw_inst_opcode(devinfo, inst);
> > +   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > +   if (num_sources >= 3)
> > +  return error_msg;
> > +
> > +   if (!is_mixed_float(devinfo, inst))
> > +  return error_msg;
> > +
> > +   unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
> > +   bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
> > +
> > +   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> > +   enum brw_reg_type src1_type = num_sources > 1 ?
> > + brw_inst_src1_type(devinfo, inst) : 0;
> > +   enum br

[Mesa-dev] [PATCH v6 32/35] intel/compiler: validate region restrictions for mixed float mode

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

v2:
 - Adapted unit tests to make them consistent with the changes done
   to the validation of half-float conversions.

v3 (Curro):
- Check all the accummulators
- Constify declarations
- Do not check src1 type in single-source instructions.
- Check for all instructions that read accumulator (either implicitly or
  explicitly)
- Check restrictions in src1 too.
- Merge conditional block
- Add invalid test case.
---
 src/intel/compiler/brw_eu_validate.c| 290 +++
 src/intel/compiler/test_eu_validate.cpp | 631 
 2 files changed, 921 insertions(+)

diff --git a/src/intel/compiler/brw_eu_validate.c 
b/src/intel/compiler/brw_eu_validate.c
index cfaf126e2f5..4a735641c86 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -170,6 +170,20 @@ src1_is_null(const struct gen_device_info *devinfo, const 
brw_inst *inst)
   brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
 }
 
+static bool
+src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   return brw_inst_src0_reg_file(devinfo, inst) == 
BRW_ARCHITECTURE_REGISTER_FILE &&
+  (brw_inst_src0_da_reg_nr(devinfo, inst) & 0xF0) == 
BRW_ARF_ACCUMULATOR;
+}
+
+static bool
+src1_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   return brw_inst_src1_reg_file(devinfo, inst) == 
BRW_ARCHITECTURE_REGISTER_FILE &&
+  (brw_inst_src1_da_reg_nr(devinfo, inst) & 0xF0) == 
BRW_ARF_ACCUMULATOR;
+}
+
 static bool
 src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
 {
@@ -275,6 +289,27 @@ sources_not_null(const struct gen_device_info *devinfo,
return error_msg;
 }
 
+static bool
+inst_uses_src_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   /* Check instructions that use implicit accumulator sources */
+   switch (brw_inst_opcode(devinfo, inst)) {
+   case BRW_OPCODE_MAC:
+   case BRW_OPCODE_MACH:
+   case BRW_OPCODE_SADA2:
+  return true;
+   }
+
+   /* Instructions with three source operands cannot use explicit accumulator
+* operands.
+*/
+   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   if (num_sources > 2)
+  return false;
+
+   return src0_is_acc(devinfo, inst) || (num_sources > 1 && 
src1_is_acc(devinfo, inst));
+}
+
 static struct string
 send_restrictions(const struct gen_device_info *devinfo,
   const brw_inst *inst)
@@ -938,6 +973,260 @@ general_restrictions_on_region_parameters(const struct 
gen_device_info *devinfo,
return error_msg;
 }
 
+static struct string
+special_restrictions_for_mixed_float_mode(const struct gen_device_info 
*devinfo,
+  const brw_inst *inst)
+{
+   struct string error_msg = { .str = NULL, .len = 0 };
+
+   const unsigned opcode = brw_inst_opcode(devinfo, inst);
+   const unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   if (num_sources >= 3)
+  return error_msg;
+
+   if (!is_mixed_float(devinfo, inst))
+  return error_msg;
+
+   unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
+   bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
+
+   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+   enum brw_reg_type src1_type = num_sources > 1 ?
+ brw_inst_src1_type(devinfo, inst) : 0;
+   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+
+   unsigned dst_stride = STRIDE(brw_inst_dst_hstride(devinfo, inst));
+   bool dst_is_packed = is_packed(exec_size * dst_stride, exec_size, 
dst_stride);
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"Indirect addressing on source is not supported when source and
+* destination data types are mixed float."
+*/
+   ERROR_IF((types_are_mixed_float(dst_type, src0_type) &&
+ brw_inst_src0_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT) 
||
+(num_sources > 1 &&
+ types_are_mixed_float(dst_type, src1_type) &&
+ brw_inst_src1_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT),
+"Indirect addressing on source is not supported when source and "
+"destination data types are mixed float");
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is f32. Instruction
+* execution size must be no more than 8."
+*/
+   ERROR_IF(exec_size > 8 && dst_type == BRW_REGISTER_TYPE_F,
+"Mixed float mode with 32-bit float destination is limited "
+"to SIMD8");
+
+   if (is_align16) {
+  /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+   * Float Operations:
+   *
+   *   "In Align16 mode, when half float and float data types are mixed
+   *between source operands OR between 

[Mesa-dev] [PATCH v6 30/35] intel/compiler: validate region restrictions for half-float conversions

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

v2:
 - Consider implicit conversions in 2-src instructions too (Curro)
 - For restrictions that involve destination stride requirements
   only validate them for Align1, since Align16 always requires
   packed data.
 - Skip general rule for the dst/execution type size ratio for
   mixed float instructions on CHV and SKL+, these have their own
   set of rules that we'll be validated separately.

v3 (Curro):
 - Do not check src1 type in single-source instructions.
 - Check restriction on src1.
 - Remove invalid test.
---
 src/intel/compiler/brw_eu_validate.c| 155 +++-
 src/intel/compiler/test_eu_validate.cpp | 116 ++
 2 files changed, 270 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_eu_validate.c 
b/src/intel/compiler/brw_eu_validate.c
index bd0e48a5e5c..54bffb3af03 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -469,6 +469,66 @@ is_packed(unsigned vstride, unsigned width, unsigned 
hstride)
return false;
 }
 
+/**
+ * Returns whether an instruction is an explicit or implicit conversion
+ * to/from half-float.
+ */
+static bool
+is_half_float_conversion(const struct gen_device_info *devinfo,
+ const brw_inst *inst)
+{
+   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+
+   unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+
+   if (dst_type != src0_type &&
+   (dst_type == BRW_REGISTER_TYPE_HF || src0_type == 
BRW_REGISTER_TYPE_HF)) {
+  return true;
+   } else if (num_sources > 1) {
+  enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+  return dst_type != src1_type &&
+(dst_type == BRW_REGISTER_TYPE_HF ||
+ src1_type == BRW_REGISTER_TYPE_HF);
+   }
+
+   return false;
+}
+
+/*
+ * Returns whether an instruction is using mixed float operation mode
+ */
+static bool
+is_mixed_float(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   if (devinfo->gen < 8)
+  return false;
+
+   if (inst_is_send(devinfo, inst))
+  return false;
+
+   unsigned opcode = brw_inst_opcode(devinfo, inst);
+   const struct opcode_desc *desc = brw_opcode_desc(devinfo, opcode);
+   if (desc->ndst == 0)
+  return false;
+
+   /* FIXME: support 3-src instructions */
+   unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   assert(num_sources < 3);
+
+   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+
+   if (num_sources == 1)
+  return types_are_mixed_float(src0_type, dst_type);
+
+   enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+
+   return types_are_mixed_float(src0_type, src1_type) ||
+  types_are_mixed_float(src0_type, dst_type) ||
+  types_are_mixed_float(src1_type, dst_type);
+}
+
 /**
  * Checks restrictions listed in "General Restrictions Based on Operand Types"
  * in the "Register Region Restrictions" section.
@@ -539,7 +599,100 @@ general_restrictions_based_on_operand_types(const struct 
gen_device_info *devinf
exec_type_size == 8 && dst_type_size == 4)
   dst_type_size = 8;
 
-   if (exec_type_size > dst_type_size) {
+   if (is_half_float_conversion(devinfo, inst)) {
+  /**
+   * A helper to validate used in the validation of the following 
restriction
+   * from the BDW+ PRM, Volume 2a, Command Reference, Instructions - MOV:
+   *
+   *"There is no direct conversion from HF to DF or DF to HF.
+   * There is no direct conversion from HF to Q/UQ or Q/UQ to HF."
+   *
+   * Even if these restrictions are listed for the MOV instruction, we
+   * validate this more generally, since there is the possibility
+   * of implicit conversions from other instructions, such us implicit
+   * conversion from integer to HF with the ADD instruction in SKL+.
+   */
+  enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+  enum brw_reg_type src1_type = num_sources > 1 ?
+brw_inst_src1_type(devinfo, inst) : 0;
+  ERROR_IF(dst_type == BRW_REGISTER_TYPE_HF &&
+   (type_sz(src0_type) == 8 ||
+(num_sources > 1 && type_sz(src1_type) == 8)),
+   "There are no direct conversions between 64-bit types and HF");
+
+  ERROR_IF(type_sz(dst_type) == 8 &&
+   (src0_type == BRW_REGISTER_TYPE_HF ||
+(num_sources > 1 && src1_type == BRW_REGISTER_TYPE_HF)),
+   "There are no direct conversions between 64-bit types and HF");
+
+  /* From the BDW+ PRM:
+   *
+   *   "Conversion between Integer and HF (Half Float) must be
+   *DWord-aligned and strided by a DWord on the destination."
+   *
+   * Also, the above restrictions seems to be expanded on CHV and 

[Mesa-dev] [PATCH v7 28/35] intel/compiler: implement SIMD16 restrictions for mixed-float instructions

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

v2: f32to16/f16to32 can use a :W destination (Curro)
---
 src/intel/compiler/brw_fs.cpp | 71 +++
 1 file changed, 71 insertions(+)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index d4803c63b93..48b5cc6c403 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -5606,6 +5606,48 @@ fs_visitor::lower_logical_sends()
return progress;
 }
 
+static bool
+is_mixed_float_with_fp32_dst(const fs_inst *inst)
+{
+   /* This opcode sometimes uses :W type on the source even if the operand is
+* a :HF, because in gen7 there is no support for :HF, and thus it uses :W.
+*/
+   if (inst->opcode == BRW_OPCODE_F16TO32)
+  return true;
+
+   if (inst->dst.type != BRW_REGISTER_TYPE_F)
+  return false;
+
+   for (int i = 0; i < inst->sources; i++) {
+  if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
+ return true;
+   }
+
+   return false;
+}
+
+static bool
+is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
+{
+   /* This opcode sometimes uses :W type on the destination even if the
+* destination is a :HF, because in gen7 there is no support for :HF, and
+* thus it uses :W.
+*/
+   if (inst->opcode == BRW_OPCODE_F32TO16)
+  return true;
+
+   if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
+   inst->dst.stride != 1)
+  return false;
+
+   for (int i = 0; i < inst->sources; i++) {
+  if (inst->src[i].type == BRW_REGISTER_TYPE_F)
+ return true;
+   }
+
+   return false;
+}
+
 /**
  * Get the closest allowed SIMD width for instruction \p inst accounting for
  * some common regioning and execution control restrictions that apply to FPU
@@ -5768,6 +5810,35 @@ get_fpu_lowered_simd_width(const struct gen_device_info 
*devinfo,
  max_width = MIN2(max_width, 4);
}
 
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is f32. Instruction
+* execution size must be no more than 8."
+*
+* FIXME: the simulator doesn't seem to complain if we don't do this and
+* empirical testing with existing CTS tests show that they pass just fine
+* without implementing this, however, since our interpretation of the PRM
+* is that conversion MOVs between HF and F are still mixed-float
+* instructions (and therefore subject to this restriction) we decided to
+* split them to be safe. Might be useful to do additional investigation to
+* lift the restriction if we can ensure that it is safe though, since these
+* conversions are common when half-float types are involved since many
+* instructions do not support HF types and conversions from/to F are
+* required.
+*/
+   if (is_mixed_float_with_fp32_dst(inst))
+  max_width = MIN2(max_width, 8);
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is packed f16 for both
+* Align1 and Align16."
+*/
+   if (is_mixed_float_with_packed_fp16_dst(inst))
+  max_width = MIN2(max_width, 8);
+
/* Only power-of-two execution sizes are representable in the instruction
 * control fields.
 */
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH v5 35/38] intel/compiler: validate region restrictions for mixed float mode

[Juan A. Suarez Romero]

On Wed, 2019-03-27 at 19:37 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero"  writes:
> 
> > From: Iago Toral Quiroga 
> > 
> > v2:
> >  - Adapted unit tests to make them consistent with the changes done
> >to the validation of half-float conversions.
> > ---
> >  src/intel/compiler/brw_eu_validate.c| 256 ++
> >  src/intel/compiler/test_eu_validate.cpp | 620 
> >  2 files changed, 876 insertions(+)
> > 
> > diff --git a/src/intel/compiler/brw_eu_validate.c 
> > b/src/intel/compiler/brw_eu_validate.c
> > index 18c95efb05b..5eea02f5c94 100644
> > --- a/src/intel/compiler/brw_eu_validate.c
> > +++ b/src/intel/compiler/brw_eu_validate.c
> > @@ -170,6 +170,13 @@ src1_is_null(const struct gen_device_info *devinfo, 
> > const brw_inst *inst)
> >brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
> >  }
> >  
> > +static bool
> > +src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
> > +{
> > +   return brw_inst_src0_reg_file(devinfo, inst) == 
> > BRW_ARCHITECTURE_REGISTER_FILE &&
> > +  brw_inst_src0_da_reg_nr(devinfo, inst) == BRW_ARF_ACCUMULATOR;
> > +}
> > +
> 
> There are multiple accumulator registers.  The above only checks for
> acc0.
> 

 static bool
> >  src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
> >  {
> > @@ -937,6 +944,254 @@ general_restrictions_on_region_parameters(const 
> > struct gen_device_info *devinfo,
> > return error_msg;
> >  }
> >  
> > +static struct string
> > +special_restrictions_for_mixed_float_mode(const struct gen_device_info 
> > *devinfo,
> > +  const brw_inst *inst)
> > +{
> > +   struct string error_msg = { .str = NULL, .len = 0 };
> > +
> > +   unsigned opcode = brw_inst_opcode(devinfo, inst);
> 
> Constify this and the declarations below.
> 
> > +   unsigned num_sources = num_sources_from_inst(devinfo, inst);
> > +   if (num_sources >= 3)
> > +  return error_msg;
> > +
> > +   if (!is_mixed_float(devinfo, inst))
> > +  return error_msg;
> > +
> > +   unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
> > +   bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
> > +
> > +   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
> > +   enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
> 
> Same comment as in the previous patch, this can possibly blow up for
> instructions with less than two sources.
> 
> > +   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
> > +
> > +   unsigned dst_stride = STRIDE(brw_inst_dst_hstride(devinfo, inst));
> > +   bool dst_is_packed = is_packed(exec_size * dst_stride, exec_size, 
> > dst_stride);
> > +
> > +   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> > +* Float Operations:
> > +*
> > +*"Indirect addressing on source is not supported when source and
> > +* destination data types are mixed float."
> > +*
> > +* Indirect addressing is only supported on the first source, so we only
> > +* check that.
> 
> I don't think that's true.  The hardware spec has the following example
> of a valid but kind of funky instruction with indirect regioning:
> 
> > add (16) r[a0.0]:f r[a0.2]:f r[a0.4]:f 

Interesting, because looking at the driver implementation of
brw_set_src1, for anything that is not an immediate we do:

/* This is a hardware restriction, which may or may not be lifted
 * in the future:
 */
assert (reg.address_mode == BRW_ADDRESS_DIRECT);

I guess this assertion was written for older platforms then?

> > +*/
> > +   ERROR_IF(types_are_mixed_float(dst_type, src0_type) &&
> 
> I doubt that it makes a difference whether there is a mismatch between
> the type of src0 and the type of the destination for indirect addressing
> to be disallowed.  Things are likely to blow up with indirect addressing
> in src0 even if the instruction is mixed-mode due to the effect of the
> type of src1 alone.  But it's hard to tell for sure, spec wording seems
> fairly ambiguous...
> 
> > +brw_inst_src0_address_mode(devinfo, inst) != 
> > BRW_ADDRESS_DIRECT,
> > +"Indirect addressing on source is not supported when source 
> > and "
> > +"destination data types are mixed float");
> > +
> > +   /* From the SKL PRM, Special Restri

Re: [Mesa-dev] [PATCH v4 00/40] intel: VK_KHR_shader_float16_int8 implementation

[Juan A. Suarez Romero]

On Fri, 2019-03-22 at 17:53 +0100, Iago Toral wrote:
> Yes, I think those should be fine to land now, they are very few
> actually. Jason, any objections?
> 

Pushed:
- [PATCH v4 10/40] compiler/nir: add lowering option for 16-bit fmod
- [PATCH v4 11/40] compiler/nir: add lowering for 16-bit flrp
- [PATCH v4 12/40] compiler/nir: add lowering for 16-bit ldexp

J.A.

> Iago
> 
> On Fri, 2019-03-22 at 17:26 +0100, Samuel Pitoiset wrote:
> > Can you eventually merge all NIR patches now? We should be able to
> > hook 
> > up that extension for RADV quite soon.
> > 
> > On 2/12/19 12:55 PM, Iago Toral Quiroga wrote:
> > > The changes in this version address review feedback to v3. The most
> > > significant
> > > changes include:
> > > 
> > > 1. A more generic constant combining pass that can handle more
> > > constant types (not just F and HF) requested by Jason.
> > > 
> > > 2. The addition of assembly validation for half-float restrictions,
> > > and also
> > > for mixed float mode, requested by Curro. It should be noted that
> > > this
> > > implementation of VK_KHR_shader_float16_int8 does not emit any
> > > mixed mode float
> > > instructions at this moment so I have not empirically validated the
> > > restictions
> > > implemented here.
> > > 
> > > As always, a branch with these patches is available for testing in
> > > the
> > > itoral/VK_KHR_shader_float16_int8 branch of the Igalia Mesa
> > > repository at
> > > https://github.com/Igalia/mesa.
> > > 
> > > Iago Toral Quiroga (40):
> > >compiler/nir: add an is_conversion field to nir_op_info
> > >intel/compiler: add a NIR pass to lower conversions
> > >intel/compiler: split float to 64-bit opcodes from int to 64-bit
> > >intel/compiler: handle b2i/b2f with other integer conversion
> > > opcodes
> > >intel/compiler: assert restrictions on conversions to half-float
> > >intel/compiler: lower some 16-bit float operations to 32-bit
> > >intel/compiler: handle extended math restrictions for half-float
> > >intel/compiler: implement 16-bit fsign
> > >intel/compiler: drop unnecessary temporary from 32-bit fsign
> > >  implementation
> > >compiler/nir: add lowering option for 16-bit fmod
> > >compiler/nir: add lowering for 16-bit flrp
> > >compiler/nir: add lowering for 16-bit ldexp
> > >intel/compiler: add instruction setters for Src1Type and
> > > Src2Type.
> > >intel/compiler: add new half-float register type for 3-src
> > >  instructions
> > >intel/compiler: don't compact 3-src instructions with Src1Type
> > > or
> > >  Src2Type bits
> > >intel/compiler: allow half-float on 3-source instructions since
> > > gen8
> > >intel/compiler: set correct precision fields for 3-source float
> > >  instructions
> > >intel/compiler: fix ddx and ddy for 16-bit float
> > >intel/compiler: fix ddy for half-float in Broadwell
> > >intel/compiler: workaround for SIMD8 half-float MAD in gen8
> > >intel/compiler: split is_partial_write() into two variants
> > >intel/compiler: activate 16-bit bit-size lowerings also for 8-
> > > bit
> > >intel/compiler: rework conversion opcodes
> > >intel/compiler: implement isign for int8
> > >intel/compiler: ask for an integer type if requesting an 8-bit
> > > type
> > >intel/eu: force stride of 2 on NULL register for Byte
> > > instructions
> > >intel/compiler: generalize the combine constants pass
> > >intel/compiler: implement is_zero, is_one, is_negative_one for
> > >  8-bit/16-bit
> > >intel/compiler: add a brw_reg_type_is_integer helper
> > >intel/compiler: fix cmod propagation for non 32-bit types
> > >intel/compiler: remove inexact algebraic optimizations from the
> > >  backend
> > >intel/compiler: skip MAD algebraic optimization for half-float
> > > or
> > >  mixed mode
> > >intel/compiler: also set F execution type for mixed float mode
> > > in BDW
> > >intel/compiler: validate region restrictions for half-float
> > >  conversions
> > >intel/compiler: validate conversions between 64-bit and 8-bit
> > > types
> > >intel/compiler: skip validating restrictions on operand types
> > > for
> > >  mixed float
> > >intel/compiler: validate region restrictions for mixed float
> > > mode
> > >compiler/spirv: move the check for Int8 capability
> > >anv/pipeline: support Float16 and Int8 SPIR-V capabilities in
> > > gen8+
> > >anv/device: expose VK_KHR_shader_float16_int8 in gen8+
> > > 
> > >   src/compiler/nir/nir.h|   5 +
> > >   src/compiler/nir/nir_opcodes.py   |  73 +-
> > >   src/compiler/nir/nir_opcodes_c.py |   1 +
> > >   src/compiler/nir/nir_opt_algebraic.py |  11 +-
> > >   src/compiler/shader_info.h|   1 +
> > >   src/compiler/spirv/spirv_to_nir.c |  11 +-
> > >   src/intel/Makefile.sources|   1 +
> > >   

[Mesa-dev] [PATCH v5 35/38] intel/compiler: validate region restrictions for mixed float mode

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

v2:
 - Adapted unit tests to make them consistent with the changes done
   to the validation of half-float conversions.
---
 src/intel/compiler/brw_eu_validate.c| 256 ++
 src/intel/compiler/test_eu_validate.cpp | 620 
 2 files changed, 876 insertions(+)

diff --git a/src/intel/compiler/brw_eu_validate.c 
b/src/intel/compiler/brw_eu_validate.c
index 18c95efb05b..5eea02f5c94 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -170,6 +170,13 @@ src1_is_null(const struct gen_device_info *devinfo, const 
brw_inst *inst)
   brw_inst_src1_da_reg_nr(devinfo, inst) == BRW_ARF_NULL;
 }
 
+static bool
+src0_is_acc(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   return brw_inst_src0_reg_file(devinfo, inst) == 
BRW_ARCHITECTURE_REGISTER_FILE &&
+  brw_inst_src0_da_reg_nr(devinfo, inst) == BRW_ARF_ACCUMULATOR;
+}
+
 static bool
 src0_is_grf(const struct gen_device_info *devinfo, const brw_inst *inst)
 {
@@ -937,6 +944,254 @@ general_restrictions_on_region_parameters(const struct 
gen_device_info *devinfo,
return error_msg;
 }
 
+static struct string
+special_restrictions_for_mixed_float_mode(const struct gen_device_info 
*devinfo,
+  const brw_inst *inst)
+{
+   struct string error_msg = { .str = NULL, .len = 0 };
+
+   unsigned opcode = brw_inst_opcode(devinfo, inst);
+   unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   if (num_sources >= 3)
+  return error_msg;
+
+   if (!is_mixed_float(devinfo, inst))
+  return error_msg;
+
+   unsigned exec_size = 1 << brw_inst_exec_size(devinfo, inst);
+   bool is_align16 = brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_16;
+
+   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+   enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+
+   unsigned dst_stride = STRIDE(brw_inst_dst_hstride(devinfo, inst));
+   bool dst_is_packed = is_packed(exec_size * dst_stride, exec_size, 
dst_stride);
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"Indirect addressing on source is not supported when source and
+* destination data types are mixed float."
+*
+* Indirect addressing is only supported on the first source, so we only
+* check that.
+*/
+   ERROR_IF(types_are_mixed_float(dst_type, src0_type) &&
+brw_inst_src0_address_mode(devinfo, inst) != BRW_ADDRESS_DIRECT,
+"Indirect addressing on source is not supported when source and "
+"destination data types are mixed float");
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is f32. Instruction
+* execution size must be no more than 8."
+*/
+   ERROR_IF(exec_size > 8 && dst_type == BRW_REGISTER_TYPE_F,
+"Mixed float mode with 32-bit float destination is limited "
+"to SIMD8");
+
+   if (is_align16) {
+  /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+   * Float Operations:
+   *
+   *   "In Align16 mode, when half float and float data types are mixed
+   *between source operands OR between source and destination operands,
+   *the register content are assumed to be packed."
+   *
+   * Since Align16 doesn't have a concept of horizontal stride (or width),
+   * it means that vertical stride must always be 4, since 0 and 2 would
+   * lead to replicated data, and any other value is disallowed in Align16.
+   * However, the PRM also says:
+   *
+   *   "In Align16, vertical stride can never be zero for f16"
+   *
+   * Which is oddly redundant and specific considering the more general
+   * assumption that all operands are assumed to be packed, so we
+   * understand that this might be hinting that there may be an exception
+   * for f32 operands with a vstride of 0, so we don't validate this for
+   * them while we don't have empirical evidence that it is forbidden.
+   */
+  ERROR_IF(brw_inst_src0_vstride(devinfo, inst) != BRW_VERTICAL_STRIDE_4 &&
+   (src0_type != BRW_REGISTER_TYPE_F ||
+brw_inst_src0_vstride(devinfo, inst) != BRW_VERTICAL_STRIDE_0),
+   "Align16 mixed float mode assumes packed data (vstride must "
+   "be 4 -or 0 for f32 operands-)");
+
+  ERROR_IF(num_sources >= 2 &&
+   brw_inst_src1_vstride(devinfo, inst) != BRW_VERTICAL_STRIDE_4 &&
+   (src1_type != BRW_REGISTER_TYPE_F ||
+brw_inst_src1_vstride(devinfo, inst) != BRW_VERTICAL_STRIDE_0),
+   "Align16 mixed float mode assumes packed data (vstride must "
+   "be 4 -or 0 for f32 

[Mesa-dev] [PATCH v5 33/38] intel/compiler: validate region restrictions for half-float conversions

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

v2:
 - Consider implicit conversions in 2-src instructions too (Curro)
 - For restrictions that involve destination stride requirements
   only validate them for Align1, since Align16 always requires
   packed data.
 - Skip general rule for the dst/execution type size ratio for
   mixed float instructions on CHV and SKL+, these have their own
   set of rules that we'll be validated separately.
---
 src/intel/compiler/brw_eu_validate.c| 156 +++-
 src/intel/compiler/test_eu_validate.cpp | 117 ++
 2 files changed, 272 insertions(+), 1 deletion(-)

diff --git a/src/intel/compiler/brw_eu_validate.c 
b/src/intel/compiler/brw_eu_validate.c
index bd0e48a5e5c..cad50469c65 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -469,6 +469,66 @@ is_packed(unsigned vstride, unsigned width, unsigned 
hstride)
return false;
 }
 
+/**
+ * Returns whether an instruction is an explicit or implicit conversion
+ * to/from half-float.
+ */
+static bool
+is_half_float_conversion(const struct gen_device_info *devinfo,
+ const brw_inst *inst)
+{
+   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+
+   unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+
+   if (dst_type != src0_type &&
+   (dst_type == BRW_REGISTER_TYPE_HF || src0_type == 
BRW_REGISTER_TYPE_HF)) {
+  return true;
+   } else if (num_sources > 1) {
+  enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+  return dst_type != src1_type &&
+(dst_type == BRW_REGISTER_TYPE_HF ||
+ src1_type == BRW_REGISTER_TYPE_HF);
+   }
+
+   return false;
+}
+
+/*
+ * Returns whether an instruction is using mixed float operation mode
+ */
+static bool
+is_mixed_float(const struct gen_device_info *devinfo, const brw_inst *inst)
+{
+   if (devinfo->gen < 8)
+  return false;
+
+   if (inst_is_send(devinfo, inst))
+  return false;
+
+   unsigned opcode = brw_inst_opcode(devinfo, inst);
+   const struct opcode_desc *desc = brw_opcode_desc(devinfo, opcode);
+   if (desc->ndst == 0)
+  return false;
+
+   /* FIXME: support 3-src instructions */
+   unsigned num_sources = num_sources_from_inst(devinfo, inst);
+   assert(num_sources < 3);
+
+   enum brw_reg_type dst_type = brw_inst_dst_type(devinfo, inst);
+   enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+
+   if (num_sources == 1)
+  return types_are_mixed_float(src0_type, dst_type);
+
+   enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+
+   return types_are_mixed_float(src0_type, src1_type) ||
+  types_are_mixed_float(src0_type, dst_type) ||
+  types_are_mixed_float(src1_type, dst_type);
+}
+
 /**
  * Checks restrictions listed in "General Restrictions Based on Operand Types"
  * in the "Register Region Restrictions" section.
@@ -539,7 +599,101 @@ general_restrictions_based_on_operand_types(const struct 
gen_device_info *devinf
exec_type_size == 8 && dst_type_size == 4)
   dst_type_size = 8;
 
-   if (exec_type_size > dst_type_size) {
+   if (is_half_float_conversion(devinfo, inst)) {
+  /**
+   * A helper to validate used in the validation of the following 
restriction
+   * from the BDW+ PRM, Volume 2a, Command Reference, Instructions - MOV:
+   *
+   *"There is no direct conversion from HF to DF or DF to HF.
+   * There is no direct conversion from HF to Q/UQ or Q/UQ to HF."
+   *
+   * Even if these restrictions are listed for the MOV instruction, we
+   * validate this more generally, since there is the possibility
+   * of implicit conversions from other instructions, such us implicit
+   * conversion from integer to HF with the ADD instruction in SKL+.
+   */
+  enum brw_reg_type src0_type = brw_inst_src0_type(devinfo, inst);
+  enum brw_reg_type src1_type = brw_inst_src1_type(devinfo, inst);
+  ERROR_IF(dst_type == BRW_REGISTER_TYPE_HF &&
+   (type_sz(src0_type) == 8 ||
+(num_sources > 1 && type_sz(src1_type) == 8)),
+   "There are no direct conversions between 64-bit types and HF");
+
+  ERROR_IF(type_sz(dst_type) == 8 &&
+   (src0_type == BRW_REGISTER_TYPE_HF ||
+(num_sources > 1 && src1_type == BRW_REGISTER_TYPE_HF)),
+   "There are no direct conversions between 64-bit types and HF");
+
+  /* From the BDW+ PRM:
+   *
+   *   "Conversion between Integer and HF (Half Float) must be
+   *DWord-aligned and strided by a DWord on the destination."
+   *
+   * Since mixing floating point and integer types on sources is not
+   * allowed we can verify this by only looking at the type of the first
+   * source only ehen there is more than one source.
+   *
+   * Also, the above 

Re: [Mesa-dev] [PATCH v6 32/38] intel/compiler: also set F execution type for mixed float mode in BDW

[Juan A. Suarez Romero]

CCing Iago and Curro.

On Fri, 2019-03-22 at 10:08 +0100, Juan A. Suarez Romero wrote:
> From: Iago Toral Quiroga 
> 
> The section 'Execution Data Types' of 3D Media GPGPU volume, which
> describes execution types, is exactly the same in BDW and SKL+.
> 
> Also, this section states that there is a single execution type, so it
> makes sense that this is the wider of the two floating point types
> involved in mixed float mode, which is what we do for SKL+ and CHV.
> 
> v2:
>  - Make sure we also account for the destination type in mixed mode (Curro).
> 
> Acked-by: Francisco Jerez 
> ---
>  src/intel/compiler/brw_eu_validate.c | 36 +++-
>  1 file changed, 20 insertions(+), 16 deletions(-)
> 
> diff --git a/src/intel/compiler/brw_eu_validate.c 
> b/src/intel/compiler/brw_eu_validate.c
> index 358a0347a93..bd0e48a5e5c 100644
> --- a/src/intel/compiler/brw_eu_validate.c
> +++ b/src/intel/compiler/brw_eu_validate.c
> @@ -348,6 +348,17 @@ is_unsupported_inst(const struct gen_device_info 
> *devinfo,
> return brw_opcode_desc(devinfo, brw_inst_opcode(devinfo, inst)) == NULL;
>  }
>  
> +/**
> + * Returns whether a combination of two types would qualify as mixed float
> + * operation mode
> + */
> +static inline bool
> +types_are_mixed_float(enum brw_reg_type t0, enum brw_reg_type t1)
> +{
> +   return (t0 == BRW_REGISTER_TYPE_F && t1 == BRW_REGISTER_TYPE_HF) ||
> +  (t1 == BRW_REGISTER_TYPE_F && t0 == BRW_REGISTER_TYPE_HF);
> +}
> +
>  static enum brw_reg_type
>  execution_type_for_type(enum brw_reg_type type)
>  {
> @@ -390,20 +401,24 @@ execution_type(const struct gen_device_info *devinfo, 
> const brw_inst *inst)
> enum brw_reg_type src0_exec_type, src1_exec_type;
>  
> /* Execution data type is independent of destination data type, except in
> -* mixed F/HF instructions on CHV and SKL+.
> +* mixed F/HF instructions.
>  */
> enum brw_reg_type dst_exec_type = brw_inst_dst_type(devinfo, inst);
>  
> src0_exec_type = execution_type_for_type(brw_inst_src0_type(devinfo, 
> inst));
> if (num_sources == 1) {
> -  if ((devinfo->gen >= 9 || devinfo->is_cherryview) &&
> -  src0_exec_type == BRW_REGISTER_TYPE_HF) {
> +  if (src0_exec_type == BRW_REGISTER_TYPE_HF)
>   return dst_exec_type;
> -  }
>return src0_exec_type;
> }
>  
> src1_exec_type = execution_type_for_type(brw_inst_src1_type(devinfo, 
> inst));
> +   if (types_are_mixed_float(src0_exec_type, src1_exec_type) ||
> +   types_are_mixed_float(src0_exec_type, dst_exec_type) ||
> +   types_are_mixed_float(src1_exec_type, dst_exec_type)) {
> +  return BRW_REGISTER_TYPE_F;
> +   }
> +
> if (src0_exec_type == src1_exec_type)
>return src0_exec_type;
>  
> @@ -431,18 +446,7 @@ execution_type(const struct gen_device_info *devinfo, 
> const brw_inst *inst)
> src1_exec_type == BRW_REGISTER_TYPE_DF)
>return BRW_REGISTER_TYPE_DF;
>  
> -   if (devinfo->gen >= 9 || devinfo->is_cherryview) {
> -  if (dst_exec_type == BRW_REGISTER_TYPE_F ||
> -  src0_exec_type == BRW_REGISTER_TYPE_F ||
> -  src1_exec_type == BRW_REGISTER_TYPE_F) {
> - return BRW_REGISTER_TYPE_F;
> -  } else {
> - return BRW_REGISTER_TYPE_HF;
> -  }
> -   }
> -
> -   assert(src0_exec_type == BRW_REGISTER_TYPE_F);
> -   return BRW_REGISTER_TYPE_F;
> +   unreachable("not reached");
>  }
>  
>  /**

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

Re: [Mesa-dev] [PATCH v6 31/38] intel/compiler: implement SIMD16 restrictions for mixed-float instructions

[Juan A. Suarez Romero]

CCing Iago and Curro.

On Fri, 2019-03-22 at 10:07 +0100, Juan A. Suarez Romero wrote:
> From: Iago Toral Quiroga 
> 
> ---
>  src/intel/compiler/brw_fs.cpp | 65 +++
>  1 file changed, 65 insertions(+)
> 
> diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
> index 2fc7793709b..3616a7afc31 100644
> --- a/src/intel/compiler/brw_fs.cpp
> +++ b/src/intel/compiler/brw_fs.cpp
> @@ -5607,6 +5607,42 @@ fs_visitor::lower_logical_sends()
> return progress;
>  }
>  
> +static bool
> +is_mixed_float_with_fp32_dst(const fs_inst *inst)
> +{
> +   /* FIXME: This opcode sometimes uses :W type on the source
> +* for some reason even if the operand is a half-float, we
> +* should probably fix it to use the correct type.
> +*/
> +   if (inst->opcode == BRW_OPCODE_F16TO32)
> +  return true;
> +
> +   if (inst->dst.type != BRW_REGISTER_TYPE_F)
> +  return false;
> +
> +   for (int i = 0; i < inst->sources; i++) {
> +  if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
> + return true;
> +   }
> +
> +   return false;
> +}
> +
> +static bool
> +is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
> +{
> +   if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
> +   inst->dst.stride != 1)
> +  return false;
> +
> +   for (int i = 0; i < inst->sources; i++) {
> +  if (inst->src[i].type == BRW_REGISTER_TYPE_F)
> + return true;
> +   }
> +
> +   return false;
> +}
> +
>  /**
>   * Get the closest allowed SIMD width for instruction \p inst accounting for
>   * some common regioning and execution control restrictions that apply to FPU
> @@ -5769,6 +5805,35 @@ get_fpu_lowered_simd_width(const struct 
> gen_device_info *devinfo,
>   max_width = MIN2(max_width, 4);
> }
>  
> +   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is f32. Instruction
> +* execution size must be no more than 8."
> +*
> +* FIXME: the simulator doesn't seem to complain if we don't do this and
> +* empirical testing with existing CTS tests show that they pass just fine
> +* without implementing this, however, since our interpretation of the PRM
> +* is that conversion MOVs between HF and F are still mixed-float
> +* instructions (and therefore subject to this restriction) we decided to
> +* split them to be safe. Might be useful to do additional investigation 
> to
> +* lift the restriction if we can ensure that it is safe though, since 
> these
> +* conversions are common when half-float types are involved since many
> +* instructions do not support HF types and conversions from/to F are
> +* required.
> +*/
> +   if (is_mixed_float_with_fp32_dst(inst))
> +  max_width = MIN2(max_width, 8);
> +
> +   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
> +* Float Operations:
> +*
> +*"No SIMD16 in mixed mode when destination is packed f16 for both
> +* Align1 and Align16."
> +*/
> +   if (is_mixed_float_with_packed_fp16_dst(inst))
> +  max_width = MIN2(max_width, 8);
> +
> /* Only power-of-two execution sizes are representable in the instruction
>  * control fields.
>  */

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

[Mesa-dev] [PATCH v6 32/38] intel/compiler: also set F execution type for mixed float mode in BDW

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

The section 'Execution Data Types' of 3D Media GPGPU volume, which
describes execution types, is exactly the same in BDW and SKL+.

Also, this section states that there is a single execution type, so it
makes sense that this is the wider of the two floating point types
involved in mixed float mode, which is what we do for SKL+ and CHV.

v2:
 - Make sure we also account for the destination type in mixed mode (Curro).

Acked-by: Francisco Jerez 
---
 src/intel/compiler/brw_eu_validate.c | 36 +++-
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/src/intel/compiler/brw_eu_validate.c 
b/src/intel/compiler/brw_eu_validate.c
index 358a0347a93..bd0e48a5e5c 100644
--- a/src/intel/compiler/brw_eu_validate.c
+++ b/src/intel/compiler/brw_eu_validate.c
@@ -348,6 +348,17 @@ is_unsupported_inst(const struct gen_device_info *devinfo,
return brw_opcode_desc(devinfo, brw_inst_opcode(devinfo, inst)) == NULL;
 }
 
+/**
+ * Returns whether a combination of two types would qualify as mixed float
+ * operation mode
+ */
+static inline bool
+types_are_mixed_float(enum brw_reg_type t0, enum brw_reg_type t1)
+{
+   return (t0 == BRW_REGISTER_TYPE_F && t1 == BRW_REGISTER_TYPE_HF) ||
+  (t1 == BRW_REGISTER_TYPE_F && t0 == BRW_REGISTER_TYPE_HF);
+}
+
 static enum brw_reg_type
 execution_type_for_type(enum brw_reg_type type)
 {
@@ -390,20 +401,24 @@ execution_type(const struct gen_device_info *devinfo, 
const brw_inst *inst)
enum brw_reg_type src0_exec_type, src1_exec_type;
 
/* Execution data type is independent of destination data type, except in
-* mixed F/HF instructions on CHV and SKL+.
+* mixed F/HF instructions.
 */
enum brw_reg_type dst_exec_type = brw_inst_dst_type(devinfo, inst);
 
src0_exec_type = execution_type_for_type(brw_inst_src0_type(devinfo, inst));
if (num_sources == 1) {
-  if ((devinfo->gen >= 9 || devinfo->is_cherryview) &&
-  src0_exec_type == BRW_REGISTER_TYPE_HF) {
+  if (src0_exec_type == BRW_REGISTER_TYPE_HF)
  return dst_exec_type;
-  }
   return src0_exec_type;
}
 
src1_exec_type = execution_type_for_type(brw_inst_src1_type(devinfo, inst));
+   if (types_are_mixed_float(src0_exec_type, src1_exec_type) ||
+   types_are_mixed_float(src0_exec_type, dst_exec_type) ||
+   types_are_mixed_float(src1_exec_type, dst_exec_type)) {
+  return BRW_REGISTER_TYPE_F;
+   }
+
if (src0_exec_type == src1_exec_type)
   return src0_exec_type;
 
@@ -431,18 +446,7 @@ execution_type(const struct gen_device_info *devinfo, 
const brw_inst *inst)
src1_exec_type == BRW_REGISTER_TYPE_DF)
   return BRW_REGISTER_TYPE_DF;
 
-   if (devinfo->gen >= 9 || devinfo->is_cherryview) {
-  if (dst_exec_type == BRW_REGISTER_TYPE_F ||
-  src0_exec_type == BRW_REGISTER_TYPE_F ||
-  src1_exec_type == BRW_REGISTER_TYPE_F) {
- return BRW_REGISTER_TYPE_F;
-  } else {
- return BRW_REGISTER_TYPE_HF;
-  }
-   }
-
-   assert(src0_exec_type == BRW_REGISTER_TYPE_F);
-   return BRW_REGISTER_TYPE_F;
+   unreachable("not reached");
 }
 
 /**
-- 
2.20.1

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

[Mesa-dev] [PATCH v6 31/38] intel/compiler: implement SIMD16 restrictions for mixed-float instructions

[Juan A. Suarez Romero]

From: Iago Toral Quiroga 

---
 src/intel/compiler/brw_fs.cpp | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 2fc7793709b..3616a7afc31 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -5607,6 +5607,42 @@ fs_visitor::lower_logical_sends()
return progress;
 }
 
+static bool
+is_mixed_float_with_fp32_dst(const fs_inst *inst)
+{
+   /* FIXME: This opcode sometimes uses :W type on the source
+* for some reason even if the operand is a half-float, we
+* should probably fix it to use the correct type.
+*/
+   if (inst->opcode == BRW_OPCODE_F16TO32)
+  return true;
+
+   if (inst->dst.type != BRW_REGISTER_TYPE_F)
+  return false;
+
+   for (int i = 0; i < inst->sources; i++) {
+  if (inst->src[i].type == BRW_REGISTER_TYPE_HF)
+ return true;
+   }
+
+   return false;
+}
+
+static bool
+is_mixed_float_with_packed_fp16_dst(const fs_inst *inst)
+{
+   if (inst->dst.type != BRW_REGISTER_TYPE_HF ||
+   inst->dst.stride != 1)
+  return false;
+
+   for (int i = 0; i < inst->sources; i++) {
+  if (inst->src[i].type == BRW_REGISTER_TYPE_F)
+ return true;
+   }
+
+   return false;
+}
+
 /**
  * Get the closest allowed SIMD width for instruction \p inst accounting for
  * some common regioning and execution control restrictions that apply to FPU
@@ -5769,6 +5805,35 @@ get_fpu_lowered_simd_width(const struct gen_device_info 
*devinfo,
  max_width = MIN2(max_width, 4);
}
 
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is f32. Instruction
+* execution size must be no more than 8."
+*
+* FIXME: the simulator doesn't seem to complain if we don't do this and
+* empirical testing with existing CTS tests show that they pass just fine
+* without implementing this, however, since our interpretation of the PRM
+* is that conversion MOVs between HF and F are still mixed-float
+* instructions (and therefore subject to this restriction) we decided to
+* split them to be safe. Might be useful to do additional investigation to
+* lift the restriction if we can ensure that it is safe though, since these
+* conversions are common when half-float types are involved since many
+* instructions do not support HF types and conversions from/to F are
+* required.
+*/
+   if (is_mixed_float_with_fp32_dst(inst))
+  max_width = MIN2(max_width, 8);
+
+   /* From the SKL PRM, Special Restrictions for Handling Mixed Mode
+* Float Operations:
+*
+*"No SIMD16 in mixed mode when destination is packed f16 for both
+* Align1 and Align16."
+*/
+   if (is_mixed_float_with_packed_fp16_dst(inst))
+  max_width = MIN2(max_width, 8);
+
/* Only power-of-two execution sizes are representable in the instruction
 * control fields.
 */
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir/spirv: short-circuit when conditional branch contains end block

[Juan A. Suarez Romero]

On Fri, 2019-03-08 at 13:29 -0600, Jason Ekstrand wrote:
> On Fri, Mar 8, 2019 at 9:30 AM Juan A. Suarez Romero  
> wrote:
> > On Thu, 2019-03-07 at 07:15 -0600, Jason Ekstrand wrote:
> > 
> > > Woah, is this legal SPIR-V? I think a second OpSelectionMerge is required.
> > 
> > 
> > 
> > I'd say it is legal. The spec does not mandate that each branch has its own
> > 
> > merge instruction; only that the control flow must be structured for 
> > shaders.
> 
> That's exactly the problem.  It says how merge instructions work and how they 
> have to be nested but never that or where you have to use them. :-(  This is 
> a spec bug.  The closest I can find is this line from the structured control 
> flow section: "These explicitly declare a header block before the control 
> flow diverges and a merge block where control flow subsequently converges."  
> If you read that as "you must declare divergence" then it would imply that 
> every OpBranchConditional must be preceded by an OpSelectionMerge.  If we 
> don't require this, there are lots of weird cases where you can get into 
> diamond patters and other things that aren't trivially structurizable.
> 

I agree, but I understand in this case the second branch is not diverging, but 
converging to the merge case already defined in the selection merge.
I found a couple of similar questions in public github, which were resolved by 
stating that not all OpBranchConditional must be immediately preceded by an 
OpSelectionMerge or OpLoopMerge.
https://github.com/KhronosGroup/glslang/issues/150#issuecomment-178185325https://github.com/KhronosGroup/SPIRV-Tools/issues/1185#issuecomment-356457613
J.A.
> --Jason
>  
> > In section 2.11 ("Structured Control Flow"), about structured control-flow
> > 
> > constructs:
> > 
> > 
> > 
> > 
> > 
> > - A structured control-flow construct is then defined as one of:
> > 
> >   - a selection construct: the set of blocks dominated by a selection 
> > header,
> > 
> > minus the set of blocks dominated by the header’s merge block
> > 
> >   - [...]
> > 
> > 
> > 
> > - The above structured control-flow constructs must satisfy the following 
> > rules:
> > 
> >   - [...]
> > 
> >   - the only blocks in a construct that can branch outside the construct are
> > 
> > - a block branching to the construct’s merge block
> > 
> > - a block branching from one case construct to another, for the same
> > 
> > OpSwitch
> > 
> > - a back-edge block
> > 
> > - a continue block for the innermost loop it is nested inside of
> > 
> > - a break block for the innermost loop it is nested inside of
> > 
> > - a return block
> > 
> > 
> > 
> > 
> > 
> > Our selection construct, which contains the two nested conditional branches,
> > 
> > satisfies the rules, as both conditionals branches to the construct's merge
> > 
> > block.
> > 
> > 
> > 
> > 
> > 
> > J.A.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > > --Jason
> > 
> > > 
> > 
> > > 
> > 
> > > On March 6, 2019 05:25:26 "Juan A. Suarez Romero"  
> > > wrote:
> > 
> > > 
> > 
> > > > This fixes the case when the SPIR-V code has two nested conditional
> > 
> > > > branches, but only one selection merge:
> > 
> > > > 
> > 
> > > > 
> > 
> > > > [...]
> > 
> > > > %1 = OpLabel
> > 
> > > > OpSelectionMerge %2 None
> > 
> > > > OpBranchConditional %3 %4 %2
> > 
> > > > %4 = OpLabel
> > 
> > > > OpBranchConditional %3 %5 %2
> > 
> > > > %5 = OpLabel
> > 
> > > > OpBranch %2
> > 
> > > > %2 = OpLabel
> > 
> > > > [...]
> > 
> > > > 
> > 
> > > > 
> > 
> > > > In the second OpBranchConditional, as the else-part is the end
> > 
> > > > block (started in the first OpBranchConditional) we can just follow the
> > 
> > > > then-part.
> > 
> > > > 
> > 
> > > > 
> > 
> > > > This fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle
> > 

[Mesa-dev] [PATCH] anv: destroy descriptor sets when pool gets reset

[Juan A. Suarez Romero]

As stated in Vulkan spec:
   "Resetting a descriptor pool recycles all of the resources from all
of the descriptor sets allocated from the descriptor pool back to
the descriptor pool, and the descriptor sets are implicitly freed."

This fixes dEQP-VK.api.descriptor_pool.*

Fixes: 14f6275c92f1 ("anv/descriptor_set: add reference counting for descriptor 
set layouts")
CC: Tapani Pälli 
CC: Lionel Landwerlin 
CC: Jason Ekstrand 
---
 src/intel/vulkan/anv_descriptor_set.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/intel/vulkan/anv_descriptor_set.c 
b/src/intel/vulkan/anv_descriptor_set.c
index f293cf469ee..f34a44aefd7 100644
--- a/src/intel/vulkan/anv_descriptor_set.c
+++ b/src/intel/vulkan/anv_descriptor_set.c
@@ -636,6 +636,12 @@ VkResult anv_ResetDescriptorPool(
}
 
anv_state_stream_finish(>surface_state_stream);
+
+   list_for_each_entry_safe(struct anv_descriptor_set, set,
+>desc_sets, pool_link) {
+  anv_descriptor_set_destroy(device, pool, set);
+   }
+
anv_state_stream_init(>surface_state_stream,
  >surface_state_pool, 4096);
pool->surface_state_free_list = NULL;
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir/spirv: short-circuit when conditional branch contains end block

[Juan A. Suarez Romero]

On Thu, 2019-03-07 at 07:15 -0600, Jason Ekstrand wrote:
> Woah, is this legal SPIR-V? I think a second OpSelectionMerge is required.

I'd say it is legal. The spec does not mandate that each branch has its own
merge instruction; only that the control flow must be structured for shaders.

In section 2.11 ("Structured Control Flow"), about structured control-flow
constructs:


- A structured control-flow construct is then defined as one of:
  - a selection construct: the set of blocks dominated by a selection header,
minus the set of blocks dominated by the header’s merge block
  - [...]

- The above structured control-flow constructs must satisfy the following rules:
  - [...]
  - the only blocks in a construct that can branch outside the construct are
- a block branching to the construct’s merge block
- a block branching from one case construct to another, for the same
OpSwitch
- a back-edge block
- a continue block for the innermost loop it is nested inside of
- a break block for the innermost loop it is nested inside of
- a return block


Our selection construct, which contains the two nested conditional branches,
satisfies the rules, as both conditionals branches to the construct's merge
block.


J.A.






> 


> --Jason
> 
> 
> On March 6, 2019 05:25:26 "Juan A. Suarez Romero"  wrote:
> 
> > This fixes the case when the SPIR-V code has two nested conditional
> > branches, but only one selection merge:
> > 
> > 
> > [...]
> > %1 = OpLabel
> > OpSelectionMerge %2 None
> > OpBranchConditional %3 %4 %2
> > %4 = OpLabel
> > OpBranchConditional %3 %5 %2
> > %5 = OpLabel
> > OpBranch %2
> > %2 = OpLabel
> > [...]
> > 
> > 
> > In the second OpBranchConditional, as the else-part is the end
> > block (started in the first OpBranchConditional) we can just follow the
> > then-part.
> > 
> > 
> > This fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle
> > 
> > 
> > CC: Jason Ekstrand 
> > ---
> > src/compiler/spirv/vtn_cfg.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > 
> > diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
> > index 7868eeb60bc..f749118efbe 100644
> > --- a/src/compiler/spirv/vtn_cfg.c
> > +++ b/src/compiler/spirv/vtn_cfg.c
> > @@ -605,7 +605,16 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct 
> > list_head *cf_list,
> > }
> >  } else if (if_stmt->then_type == vtn_branch_type_none &&
> > if_stmt->else_type == vtn_branch_type_none) {
> > -/* Neither side of the if is something we can short-circuit. */
> > +/* Neither side of the if is something we can short-circuit,
> > + * unless one of the blocks is the end block. */
> > +if (then_block == end) {
> > +   block = else_block;
> > +   continue;
> > +} else if (else_block == end) {
> > +   block = then_block;
> > +   continue;
> > +}
> > +
> > vtn_assert((*block->merge & SpvOpCodeMask) == 
> > SpvOpSelectionMerge);
> > struct vtn_block *merge_block =
> >vtn_value(b, block->merge[1], vtn_value_type_block)->block;
> > --
> > 2.20.1
> 
> 
> 

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

[Mesa-dev] [PATCH] nir/spirv: short-circuit when conditional branch contains end block

[Juan A. Suarez Romero]

This fixes the case when the SPIR-V code has two nested conditional
branches, but only one selection merge:

[...]
%1 = OpLabel
 OpSelectionMerge %2 None
 OpBranchConditional %3 %4 %2
%4 = OpLabel
 OpBranchConditional %3 %5 %2
%5 = OpLabel
 OpBranch %2
%2 = OpLabel
[...]

In the second OpBranchConditional, as the else-part is the end
block (started in the first OpBranchConditional) we can just follow the
then-part.

This fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle

CC: Jason Ekstrand 
---
 src/compiler/spirv/vtn_cfg.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 7868eeb60bc..f749118efbe 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -605,7 +605,16 @@ vtn_cfg_walk_blocks(struct vtn_builder *b, struct 
list_head *cf_list,
 }
  } else if (if_stmt->then_type == vtn_branch_type_none &&
 if_stmt->else_type == vtn_branch_type_none) {
-/* Neither side of the if is something we can short-circuit. */
+/* Neither side of the if is something we can short-circuit,
+ * unless one of the blocks is the end block. */
+if (then_block == end) {
+   block = else_block;
+   continue;
+} else if (else_block == end) {
+   block = then_block;
+   continue;
+}
+
 vtn_assert((*block->merge & SpvOpCodeMask) == SpvOpSelectionMerge);
 struct vtn_block *merge_block =
vtn_value(b, block->merge[1], vtn_value_type_block)->block;
-- 
2.20.1

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

[Mesa-dev] [PATCH] nir/spirv: return after emitting a branch in block

[Juan A. Suarez Romero]

When emitting a branch in a block, it does not make sense to continue
processing further instructions, as they will not be reachable.

This fixes a nasty case with a loop with a branch that both then-part
and else-part exits the loop:

%1 = OpLabel
 OpLoopMerge %2 %3 None
 OpBranchConditional %false %2 %2
%3 = OpLabel
 OpBranch %1
%2 = OpLabel
[...]

We know that block %1 will branch always to block %2, which is the merge
block for the loop. And thus a break is emitted. If we keep continuing
processing further instructions, we will be processing the branch
conditional and thus emitting the proper NIR conditional, which leads to
instructions after the break.

This fixes dEQP-VK.graphicsfuzz.continue-and-merge.

CC: Jason Ekstrand 
---
 src/compiler/spirv/vtn_cfg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index c32d54e9006..7868eeb60bc 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/vtn_cfg.c
@@ -916,6 +916,7 @@ vtn_emit_cf_list(struct vtn_builder *b, struct list_head 
*cf_list,
  if (block->branch_type != vtn_branch_type_none) {
 vtn_emit_branch(b, block->branch_type,
 switch_fall_var, has_switch_break);
+return;
  }
 
  break;
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH v3 2/2] anv: advertise 8 subpixel precision bits

[Juan A. Suarez Romero]

On Fri, 2019-02-22 at 10:04 -0600, Jason Ekstrand wrote:
> On Fri, Feb 22, 2019 at 9:58 AM Jason Ekstrand  wrote:
> > On Fri, Feb 22, 2019 at 9:57 AM Lionel Landwerlin 
> >  wrote:
> > > On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
> > > 
> > > > On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
> > > 
> > > > used to select between 8 bit subpixel precision (value 0) or 4 bit
> > > 
> > > > subpixel precision (value 1). As this value is not set, means it is
> > > 
> > > > taking the value 0, so 8 bit are used.
> > > 
> > > >
> > > 
> > > > On the other side, in the Vulkan CTS tests, if the reference rasterizer,
> > > 
> > > > which uses 8 bit precision, as it is used to check what should be the
> > > 
> > > > expected value for the tests, is changed to use 4 bit as ANV was
> > > 
> > > > advertising so far, some of the tests will fail.
> > > 
> > > >
> > > 
> > > > So it seems ANV is actually using 8 bits.
> > > 
> > > >
> > > 
> > > > v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
> > > 
> > > > v3: use _8Bit definition as value (Jason)
> > > 
> > > >
> > > 
> > > > CC: Jason Ekstrand 
> > > 
> > > > CC: Kenneth Graunke 
> > > 
> > > > Signed-off-by: Juan A. Suarez Romero 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Reviewed-by: Lionel Landwerlin 
> > 
> > Reviewed-by: Jason Ekstrand 
> > 
> 
> I just sent a patch which also sets the corresponding bit in 3DSTATE_CLIP on 
> gen8+.  Feel free to squash it into this one before merging.  The information 
> is redundant but we should be explicitly setting it both places.  I think the 
> one in 3DSTATE_CLIP is for the viewport clip test that got added on gen8.
> 
Squashed into this one, and CCed the series to @stable.
Thank you both!
J.A.
> --Jason
>  
> >  
> > > Cc: stable?
> > 
> > Not a bad idea.
> > --Jason
> >  
> > > 
> > > > ---
> > > 
> > > >   src/intel/vulkan/anv_device.c| 2 +-
> > > 
> > > >   src/intel/vulkan/genX_pipeline.c | 1 +
> > > 
> > > >   2 files changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > >
> > > 
> > > > diff --git a/src/intel/vulkan/anv_device.c 
> > > > b/src/intel/vulkan/anv_device.c
> > > 
> > > > index 3120865466a..95224407318 100644
> > > 
> > > > --- a/src/intel/vulkan/anv_device.c
> > > 
> > > > +++ b/src/intel/vulkan/anv_device.c
> > > 
> > > > @@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
> > > 
> > > >16 * devinfo->max_cs_threads,
> > > 
> > > >16 * devinfo->max_cs_threads,
> > > 
> > > > },
> > > 
> > > > -  .subPixelPrecisionBits= 4 /* FIXME */,
> > > 
> > > > +  .subPixelPrecisionBits= 8,
> > > 
> > > > .subTexelPrecisionBits= 4 /* FIXME */,
> > > 
> > > > .mipmapPrecisionBits  = 4 /* FIXME */,
> > > 
> > > > .maxDrawIndexedIndexValue = UINT32_MAX,
> > > 
> > > > diff --git a/src/intel/vulkan/genX_pipeline.c 
> > > > b/src/intel/vulkan/genX_pipeline.c
> > > 
> > > > index 6255e5d83c5..3d36bb773e1 100644
> > > 
> > > > --- a/src/intel/vulkan/genX_pipeline.c
> > > 
> > > > +++ b/src/intel/vulkan/genX_pipeline.c
> > > 
> > > > @@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
> > > 
> > > >  sf.TriangleStripListProvokingVertexSelect = 0;
> > > 
> > > >  sf.LineStripListProvokingVertexSelect = 0;
> > > 
> > > >  sf.TriangleFanProvokingVertexSelect = 1;
> > > 
> > > > +   sf.VertexSubPixelPrecisionSelect = _8Bit;
> > > 
> > > >   
> > > 
> > > >  const struct brw_vue_prog_data *last_vue_prog_data =
> > > 
> > > > anv_pipeline_get_last_vue_prog_data(pipeline);
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > 
> > > mesa-dev mailing list
> > > 
> > > mesa-dev@lists.freedesktop.org
> > > 
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 1/2] genxml: add missing field values for 3DSTATE_SF

[Juan A. Suarez Romero]

Fill out "Vertex Sub Pixel Precision Select" possible values.

Signed-off-by: Juan A. Suarez Romero 
---
 src/intel/genxml/gen10.xml | 5 -
 src/intel/genxml/gen11.xml | 5 -
 src/intel/genxml/gen7.xml  | 5 -
 src/intel/genxml/gen75.xml | 5 -
 src/intel/genxml/gen8.xml  | 5 -
 src/intel/genxml/gen9.xml  | 5 -
 6 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/src/intel/genxml/gen10.xml b/src/intel/genxml/gen10.xml
index 284633aedd4..4cb1f05ae25 100644
--- a/src/intel/genxml/gen10.xml
+++ b/src/intel/genxml/gen10.xml
@@ -2043,7 +2043,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen11.xml b/src/intel/genxml/gen11.xml
index 95a84a2f597..a7c06c5ab60 100644
--- a/src/intel/genxml/gen11.xml
+++ b/src/intel/genxml/gen11.xml
@@ -2063,7 +2063,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen7.xml b/src/intel/genxml/gen7.xml
index 363fd8664bf..1b2c7d996f9 100644
--- a/src/intel/genxml/gen7.xml
+++ b/src/intel/genxml/gen7.xml
@@ -1399,7 +1399,10 @@
 
   
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen75.xml b/src/intel/genxml/gen75.xml
index a1da9cae041..95b306139eb 100644
--- a/src/intel/genxml/gen75.xml
+++ b/src/intel/genxml/gen75.xml
@@ -1713,7 +1713,10 @@
 
   
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen8.xml b/src/intel/genxml/gen8.xml
index 4676d9bca9c..0226d7c0c66 100644
--- a/src/intel/genxml/gen8.xml
+++ b/src/intel/genxml/gen8.xml
@@ -1816,7 +1816,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
diff --git a/src/intel/genxml/gen9.xml b/src/intel/genxml/gen9.xml
index 8afa986df55..88fc2da7885 100644
--- a/src/intel/genxml/gen9.xml
+++ b/src/intel/genxml/gen9.xml
@@ -1995,7 +1995,10 @@
   
 
 
-
+
+  
+  
+
 
   
   
-- 
2.20.1

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

[Mesa-dev] [PATCH v3 2/2] anv: advertise 8 subpixel precision bits

[Juan A. Suarez Romero]

On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.

On the other side, in the Vulkan CTS tests, if the reference rasterizer,
which uses 8 bit precision, as it is used to check what should be the
expected value for the tests, is changed to use 4 bit as ANV was
advertising so far, some of the tests will fail.

So it seems ANV is actually using 8 bits.

v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
v3: use _8Bit definition as value (Jason)

CC: Jason Ekstrand 
CC: Kenneth Graunke 
Signed-off-by: Juan A. Suarez Romero 
---
 src/intel/vulkan/anv_device.c| 2 +-
 src/intel/vulkan/genX_pipeline.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3120865466a..95224407318 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
  16 * devinfo->max_cs_threads,
  16 * devinfo->max_cs_threads,
   },
-  .subPixelPrecisionBits= 4 /* FIXME */,
+  .subPixelPrecisionBits= 8,
   .subTexelPrecisionBits= 4 /* FIXME */,
   .mipmapPrecisionBits  = 4 /* FIXME */,
   .maxDrawIndexedIndexValue = UINT32_MAX,
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 6255e5d83c5..3d36bb773e1 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
sf.TriangleStripListProvokingVertexSelect = 0;
sf.LineStripListProvokingVertexSelect = 0;
sf.TriangleFanProvokingVertexSelect = 1;
+   sf.VertexSubPixelPrecisionSelect = _8Bit;
 
const struct brw_vue_prog_data *last_vue_prog_data =
   anv_pipeline_get_last_vue_prog_data(pipeline);
-- 
2.20.1

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

[Mesa-dev] [PATCH v2] anv: advertise 8 subpixel precision bits

[Juan A. Suarez Romero]

On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.

On the other side, in the Vulkan CTS tests, if the reference rasterizer,
which uses 8 bit precision, as it is used to check what should be the
expected value for the tests, is changed to use 4 bit as ANV was
advertising so far, some of the tests will fail.

So it seems ANV is actually using 8 bits.

v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)

CC: Jason Ekstrand 
CC: Kenneth Graunke 
---
 src/intel/vulkan/anv_device.c| 2 +-
 src/intel/vulkan/genX_pipeline.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 3120865466a..95224407318 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
  16 * devinfo->max_cs_threads,
  16 * devinfo->max_cs_threads,
   },
-  .subPixelPrecisionBits= 4 /* FIXME */,
+  .subPixelPrecisionBits= 8,
   .subTexelPrecisionBits= 4 /* FIXME */,
   .mipmapPrecisionBits  = 4 /* FIXME */,
   .maxDrawIndexedIndexValue = UINT32_MAX,
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 6255e5d83c5..b06036a6fc7 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/vulkan/genX_pipeline.c
@@ -464,6 +464,7 @@ emit_rs_state(struct anv_pipeline *pipeline,
sf.TriangleStripListProvokingVertexSelect = 0;
sf.LineStripListProvokingVertexSelect = 0;
sf.TriangleFanProvokingVertexSelect = 1;
+   sf.VertexSubPixelPrecisionSelect = 0;
 
const struct brw_vue_prog_data *last_vue_prog_data =
   anv_pipeline_get_last_vue_prog_data(pipeline);
-- 
2.20.1

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

[Mesa-dev] [PATCH] anv: advertise 8 subpixel precision bits

[Juan A. Suarez Romero]

On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.

On the other side, in the Vulkan CTS tests, if the reference rasterizer,
which uses 8 bit precision, as it is used to check what should be the
expected value for the tests, is changed to use 4 bit as ANV was
advertising so far, some of the tests will fail.

So it seems ANV is actually using 8 bits.

CC: Jason Ekstrand 
CC: Kenneth Graunke 
---
 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 3120865466a..95224407318 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1095,7 +1095,7 @@ void anv_GetPhysicalDeviceProperties(
  16 * devinfo->max_cs_threads,
  16 * devinfo->max_cs_threads,
   },
-  .subPixelPrecisionBits= 4 /* FIXME */,
+  .subPixelPrecisionBits= 8,
   .subTexelPrecisionBits= 4 /* FIXME */,
   .mipmapPrecisionBits  = 4 /* FIXME */,
   .maxDrawIndexedIndexValue = UINT32_MAX,
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction

[Juan A. Suarez Romero]

On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote:
> On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote:
> > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > > > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > > > On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote:
> > > > > > opt_split_alu_of_phi moves ALU instruction to the end of continue 
> > > > > > block.
> > > > > > 
> > > > > > But if the continue block ends with a jump instruction (an explicit
> > > > > > "continue" instruction) then the ALU must be inserted before the 
> > > > > > jump,
> > > > > > as it is illegal to add instructions after the jump.
> > > > > 
> > > > > I'm assuming you found this by inspection?  Since this pass only
> > > > > operates when the first block of the loop only has two predecessors 
> > > > > (the
> > > > > block before the loop and the implicit continue at the end of the 
> > > > > loop),
> > > > > this shouldn't be a a problem in practice... or were you able to 
> > > > > trigger
> > > > > it somehow?
> > > > 
> > > > Found when dealing with the SPIR-V code that I've sent in 
> > > > https://lists.freedesktop.org/archives/mesa-dev/2019-February/214906.html
> > > > 
> > > > 
> > > > The obtained NIR code has an explicit continue at the end of the loop 
> > > > (see 
> > > > http://paste.debian.net/1067619/, in particular the loop with header 
> > > > block_2).
> > > 
> > > That loop is a mess.  Wow... I'm impressed. :) I see a continue inside
> > > an else-clause at line 107 and a break at line 112.  I now understand
> > > the fundamental problem.  Am I correct that this problem would also
> > > occur before 8fb8ebfbb05?  And that's what "nir: allow stitching of
> > > non-empty block" fixes?
> > 
> > Yeah :) It's a SPIR-V code generated with some fuzzy tool.
> > 
> > 
> > And yes, even with this patch applied, it will break later when stitching 
> > the
> > code. 
> > 
> > Fortunately, I got rid of the "nir: allow stitching of non-empty block" 
> > patch
> > and sent instead another one that removes one of the jumps to avoid the 
> > issue.
> > 
> > > Did nir_validate trip on this?  If not, it seems like it should...
> > > though that might cause problems when nir_validate is run immediately
> > > following translation into NIR.
> > 
> > The NIR code seems valid. The error (assert) was caught by nir_instr_insert,
> > when applying the optimization.
> 
> Having instructions in a block after an unconditional jump seems bogus.
>  It's technically valid, but it can never be correct.  I'm pretty sure
> we scrub that from the GLSL frontend, and I'm not sure it's legal in
> SPIR-V.  I'll look into it more.
> 

Not sure if incorrect. In fact while working on this I thought if it would make
sense just to allow momentaneously to accept instructions after jumps, if that
simplifies the optimization algorithm, and run later a DCE pass, or similar, to
eliminate those instructions that are after the jump and that will not be never
reached and executed.

Example is for the stitch case later: we need to check for this situation and
remove the instruction ourselves before calling stitch to avoid inserting after
jump.


> > > It seems like we could craft a couple *simple* piglit tests that
> > > exercise this.  I don't want to rely on a giant, ugly test case as our
> > > only coverage for this issue.  I'm sure debugging this was not fun, and
> > > I don't want someone to have to go through that again should a similar
> > > issue creep back in.  I can take a stab at that if you don't already
> > > have something ready.
> > > 
> > 
> > I didn't write a piglit test for this, as this test will end up in the 
> > Vulkan
> > CTS.
> 
> Right.  We've always had a preference for simpler tests that poke at one
> specific thing.  I'll come up with a couple tests, and I'll CC you on them.
> 

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

Re: [Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction

[Juan A. Suarez Romero]

On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote:
> > > > opt_split_alu_of_phi moves ALU instruction to the end of continue block.
> > > > 
> > > > But if the continue block ends with a jump instruction (an explicit
> > > > "continue" instruction) then the ALU must be inserted before the jump,
> > > > as it is illegal to add instructions after the jump.
> > > 
> > > I'm assuming you found this by inspection?  Since this pass only
> > > operates when the first block of the loop only has two predecessors (the
> > > block before the loop and the implicit continue at the end of the loop),
> > > this shouldn't be a a problem in practice... or were you able to trigger
> > > it somehow?
> > 
> > Found when dealing with the SPIR-V code that I've sent in 
> > https://lists.freedesktop.org/archives/mesa-dev/2019-February/214906.html
> > 
> > 
> > The obtained NIR code has an explicit continue at the end of the loop (see 
> > http://paste.debian.net/1067619/, in particular the loop with header 
> > block_2).
> 
> That loop is a mess.  Wow... I'm impressed. :) I see a continue inside
> an else-clause at line 107 and a break at line 112.  I now understand
> the fundamental problem.  Am I correct that this problem would also
> occur before 8fb8ebfbb05?  And that's what "nir: allow stitching of
> non-empty block" fixes?
> 

Yeah :) It's a SPIR-V code generated with some fuzzy tool.


And yes, even with this patch applied, it will break later when stitching the
code. 

Fortunately, I got rid of the "nir: allow stitching of non-empty block" patch
and sent instead another one that removes one of the jumps to avoid the issue.


> Did nir_validate trip on this?  If not, it seems like it should...
> though that might cause problems when nir_validate is run immediately
> following translation into NIR.
> 

The NIR code seems valid. The error (assert) was caught by nir_instr_insert,
when applying the optimization.

> It seems like we could craft a couple *simple* piglit tests that
> exercise this.  I don't want to rely on a giant, ugly test case as our
> only coverage for this issue.  I'm sure debugging this was not fun, and
> I don't want someone to have to go through that again should a similar
> issue creep back in.  I can take a stab at that if you don't already
> have something ready.
> 

I didn't write a piglit test for this, as this test will end up in the Vulkan
CTS.

> Either way, I think this change is obviously correct.  This patch is
> 
> Reviewed-by: Ian Romanick 
> 


Thanks!


> > J.A.
> > 
> > 
> > 
> > > > CC: Ian Romanick 
> > > > Fixes: 0881e90c099 ("nir: Split ALU instructions in loops that read 
> > > > phis")
> > > > ---
> > > >  src/compiler/nir/nir_opt_if.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/src/compiler/nir/nir_opt_if.c 
> > > > b/src/compiler/nir/nir_opt_if.c
> > > > index 9afb901be14..932af9e37ab 100644
> > > > --- a/src/compiler/nir/nir_opt_if.c
> > > > +++ b/src/compiler/nir/nir_opt_if.c
> > > > @@ -488,7 +488,7 @@ opt_split_alu_of_phi(nir_builder *b, nir_loop *loop)
> > > >*
> > > >* Insert the new instruction at the end of the continue 
> > > > block.
> > > >*/
> > > > - b->cursor = nir_after_block(continue_block);
> > > > + b->cursor = nir_after_block_before_jump(continue_block);
> > > >  
> > > >   nir_ssa_def *const alu_copy =
> > > >  clone_alu_and_replace_src_defs(b, alu, continue_srcs);
> 
> 

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

Re: [Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction

[Juan A. Suarez Romero]

On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote:
> > opt_split_alu_of_phi moves ALU instruction to the end of continue block.
> > 
> > But if the continue block ends with a jump instruction (an explicit
> > "continue" instruction) then the ALU must be inserted before the jump,
> > as it is illegal to add instructions after the jump.
> 
> I'm assuming you found this by inspection?  Since this pass only
> operates when the first block of the loop only has two predecessors (the
> block before the loop and the implicit continue at the end of the loop),
> this shouldn't be a a problem in practice... or were you able to trigger
> it somehow?
> 

Found when dealing with the SPIR-V code that I've sent in 
https://lists.freedesktop.org/archives/mesa-dev/2019-February/214906.html


The obtained NIR code has an explicit continue at the end of the loop (see 
http://paste.debian.net/1067619/, in particular the loop with header block_2).


J.A.



> > CC: Ian Romanick 
> > Fixes: 0881e90c099 ("nir: Split ALU instructions in loops that read phis")
> > ---
> >  src/compiler/nir/nir_opt_if.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
> > index 9afb901be14..932af9e37ab 100644
> > --- a/src/compiler/nir/nir_opt_if.c
> > +++ b/src/compiler/nir/nir_opt_if.c
> > @@ -488,7 +488,7 @@ opt_split_alu_of_phi(nir_builder *b, nir_loop *loop)
> >*
> >* Insert the new instruction at the end of the continue block.
> >*/
> > - b->cursor = nir_after_block(continue_block);
> > + b->cursor = nir_after_block_before_jump(continue_block);
> >  
> >   nir_ssa_def *const alu_copy =
> >  clone_alu_and_replace_src_defs(b, alu, continue_srcs);

___
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

[Juan A. Suarez Romero]

On Tue, 2019-02-12 at 09:38 -0800, Caio Marcelo de Oliveira Filho wrote:
> Hi Juan,
> 
> On Tue, Feb 12, 2019 at 04:37:23PM +0100, Juan A. Suarez Romero wrote:
> > On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> > > I had a chat with Caio about this and I'm skeptical.  In general, users 
> > > of the CF manipulation code shouldn't be stitching two blocks together 
> > > where the first contains a jump and the second is non-empty.  If the 
> > > caller knows that this case is ok, then they can check for it and empty 
> > > out the one block before stitching.  Also, I'm not really seeing how 
> > > peel_initial_if would hit this case from your example.
> > > 
> > > 
> > The problem happens when moving the continous list to the end of continue 
> > block in loop; the former ends in a jump ("break") and the later also ends 
> > in a jump ("continue"), so stitch block complains because there will be an 
> > instruction (the "continue") after the jump (the "break").
> 
> I was investigating this yesterday and attempted to write a MR, could
> you take a look?
> 
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/238
> 
> 


I had sent a patch to fix it (https://patchwork.freedesktop.org/patch/285649/)
which is similar to your MR.

Other than that, your MR also fixes the issue.

J.A.



>   Caio
> 

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

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

On Tue, 2019-02-12 at 11:31 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 10:48 AM Juan A. Suarez Romero  
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> > 
> > was created inheriting from the primary buffer, but with the framebuffer
> > 
> > set to NULL in the VkCommandBufferInheritanceInfo.
> > 
> > 
> > 
> > Vulkan 1.1.81 spec says that "the application must ensure (using scissor
> > 
> > if neccesary) that all rendering is contained in the render area [...]
> > 
> > [which] must be contained within the framebuffer dimesions".
> > 
> > 
> > 
> > While this should be done by the application, commit 465e5a86 added the
> > 
> > clamp to the framebuffer size, in case of application does not do it.
> > 
> > But this requires to know the framebuffer dimensions.
> > 
> > 
> > 
> > If we do not have a framebuffer at that moment, the best compromise we
> > 
> > can do is to just apply the scissor as it is, and let the application to
> > 
> > ensure the rendering is contained in the render area.
> > 
> > 
> > 
> > v2: do not clamp to framebuffer if there isn't a framebuffer
> > 
> > 
> > 
> > v3 (Jason):
> > 
> > - clamp earlier in the conditional
> > 
> > - clamp to render area if command buffer is primary
> > 
> > 
> > 
> > v4: clamp also x and y to render area (Jason)
> > 
> > 
> > 
> > Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary")
> > 
> > CC: Jason Ekstrand 
> > 
> > ---
> > 
> >  src/intel/vulkan/gen7_cmd_buffer.c | 32 +-
> > 
> >  1 file changed, 27 insertions(+), 5 deletions(-)
> > 
> > 
> > 
> > diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
> > b/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > index 352892aee33..2924c6031fd 100644
> > 
> > --- a/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > @@ -70,12 +70,34 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
> > *cmd_buffer)
> > 
> >};
> > 
> > 
> > 
> >const int max = 0x;
> > 
> > +
> > 
> > +  uint32_t y = s->offset.y;
> > 
> > +  uint32_t x = s->offset.x;
> > 
> > +  uint32_t height = s->offset.y + s->extent.height - 1;
> > 
> > +  uint32_t width = s->offset.x + s->extent.width - 1;
> 
> These should be x_max and y_max not width and height.  With that changed,

Right. I'll change also "x" and "y" by "x_min" and "y_min".
> Reviewed-by: Jason Ekstrand 
> 
> Sorry we're going to v5...
> 
 Not problem!
J.A.
> --Jason
>  
> > +
> > 
> > +  /* Do this math using int64_t so overflow gets clamped correctly. */
> > 
> > +  if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY) {
> > 
> > + y = clamp_int64((uint64_t) y, 
> > cmd_buffer->state.render_area.offset.y, max);
> > 
> > + x = clamp_int64((uint64_t) x, 
> > cmd_buffer->state.render_area.offset.x, max);
> > 
> > + height = clamp_int64((uint64_t) height, 0,
> > 
> > +  cmd_buffer->state.render_area.offset.y +
> > 
> > +  cmd_buffer->state.render_area.extent.height 
> > - 1);
> > 
> > + width = clamp_int64((uint64_t) width, 0,
> > 
> > + cmd_buffer->state.render_area.offset.x +
> > 
> > + cmd_buffer->state.render_area.extent.width - 
> > 1);
> > 
> > +  } else if (fb) {
> > 
> > + y = clamp_int64((uint64_t) y, 0, max);
> > 
> > + x = clamp_int64((uint64_t) x, 0, max);
> > 
> > + height = clamp_int64((uint64_t) height, 0, fb->height - 1);
> > 
> > + width = clamp_int64((uint64_t) width, 0, fb->width - 1);
> > 
> > +  }
> > 
> > +
> > 
> >struct GEN7_SCISSOR_RECT scissor = {
> > 
> > - /* Do this math using int64_t so overflow gets clamped correctly. 
> > */
> > 
> > - .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
> > 
> > - .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
> > 
> > - .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > s->extent.height - 1, 0, fb->height - 1),
> > 
> > - .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > s->extent.width - 1, 0, fb->width - 1)
> > 
> > + .ScissorRectangleYMin = y,
> > 
> > + .ScissorRectangleXMin = x,
> > 
> > + .ScissorRectangleYMax = height,
> > 
> > + .ScissorRectangleXMax = width
> > 
> >};
> > 
> > 
> > 
> >if (s->extent.width <= 0 || s->extent.height <= 0) {
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.

Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) that all rendering is contained in the render area [...]
[which] must be contained within the framebuffer dimesions".

While this should be done by the application, commit 465e5a86 added the
clamp to the framebuffer size, in case of application does not do it.
But this requires to know the framebuffer dimensions.

If we do not have a framebuffer at that moment, the best compromise we
can do is to just apply the scissor as it is, and let the application to
ensure the rendering is contained in the render area.

v2: do not clamp to framebuffer if there isn't a framebuffer

v3 (Jason):
- clamp earlier in the conditional
- clamp to render area if command buffer is primary

v4: clamp also x and y to render area (Jason)

Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary")
CC: Jason Ekstrand 
---
 src/intel/vulkan/gen7_cmd_buffer.c | 32 +-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 352892aee33..2924c6031fd 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -70,12 +70,34 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
*cmd_buffer)
   };
 
   const int max = 0x;
+
+  uint32_t y = s->offset.y;
+  uint32_t x = s->offset.x;
+  uint32_t height = s->offset.y + s->extent.height - 1;
+  uint32_t width = s->offset.x + s->extent.width - 1;
+
+  /* Do this math using int64_t so overflow gets clamped correctly. */
+  if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY) {
+ y = clamp_int64((uint64_t) y, cmd_buffer->state.render_area.offset.y, 
max);
+ x = clamp_int64((uint64_t) x, cmd_buffer->state.render_area.offset.x, 
max);
+ height = clamp_int64((uint64_t) height, 0,
+  cmd_buffer->state.render_area.offset.y +
+  cmd_buffer->state.render_area.extent.height - 1);
+ width = clamp_int64((uint64_t) width, 0,
+ cmd_buffer->state.render_area.offset.x +
+ cmd_buffer->state.render_area.extent.width - 1);
+  } else if (fb) {
+ y = clamp_int64((uint64_t) y, 0, max);
+ x = clamp_int64((uint64_t) x, 0, max);
+ height = clamp_int64((uint64_t) height, 0, fb->height - 1);
+ width = clamp_int64((uint64_t) width, 0, fb->width - 1);
+  }
+
   struct GEN7_SCISSOR_RECT scissor = {
- /* Do this math using int64_t so overflow gets clamped correctly. */
- .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
- .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
- .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
s->extent.height - 1, 0, fb->height - 1),
- .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
s->extent.width - 1, 0, fb->width - 1)
+ .ScissorRectangleYMin = y,
+ .ScissorRectangleXMin = x,
+ .ScissorRectangleYMax = height,
+ .ScissorRectangleXMax = width
   };
 
   if (s->extent.width <= 0 || s->extent.height <= 0) {
-- 
2.20.1

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

[Mesa-dev] [PATCH] nir: remove jump from two merging jump-ending blocks

[Juan A. Suarez Romero]

In opt_peel_initial_if optimization, when moving the continue list to
end of the continue block, before the jump, could happen that the
continue list itself also ends with a jump.

This would mean that we would have two jump instructions in a row: the
first one from the continue list and the second one from the contine
block.

As inserting an instruction after a jump is not allowed (and it does not
make sense, as it will not be executed), remove the jump from the
continue block and keep the one from continue list, as it will be
executed first.

CC: Jason Ekstrand 
---
 src/compiler/nir/nir_opt_if.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 932af9e37ab..a011401b3b4 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -241,12 +241,29 @@ opt_peel_loop_initial_if(nir_loop *loop)
nir_cf_reinsert(,
nir_after_block_before_jump(find_continue_block(loop)));
 
+   bool continue_list_jumps =
+  nir_block_ends_in_jump(exec_node_data(nir_block,
+exec_list_get_tail(continue_list),
+cf_node.node));
+
nir_cf_extract(, nir_before_cf_list(continue_list),
 nir_after_cf_list(continue_list));
 
-   /* Get continue block again as the previous reinsert might have removed the 
block. */
+   /* Get continue block again as the previous reinsert might have removed the
+* block.  Also, if both the continue list and the continue block ends in
+* jump instructions, removes the jump from the later, as it will not be
+* executed if we insert the continue list before it */
+
+   nir_block *continue_block = find_continue_block(loop);
+
+   if (continue_list_jumps) {
+  nir_instr *last_instr = nir_block_last_instr(continue_block);
+  if (last_instr && last_instr->type == nir_instr_type_jump)
+ nir_instr_remove(last_instr);
+   }
+
nir_cf_reinsert(,
-   nir_after_block_before_jump(find_continue_block(loop)));
+   nir_after_block_before_jump(continue_block));
 
nir_cf_node_remove(>cf_node);
 
-- 
2.20.1

___
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

[Juan A. Suarez Romero]

On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> I had a chat with Caio about this and I'm skeptical.  In general, users of 
> the CF manipulation code shouldn't be stitching two blocks together where the 
> first contains a jump and the second is non-empty.  If the caller knows that 
> this case is ok, then they can check for it and empty out the one block 
> before stitching.  Also, I'm not really seeing how peel_initial_if would hit 
> this case from your example.
> 
> 
The problem happens when moving the continous list to the end of continue block 
in loop; the former ends in a jump ("break") and the later also ends in a jump 
("continue"), so stitch block complains because there will be an instruction 
(the "continue") after the jump (the "break").
As you mentioned, maybe the caller can detect this situation and just get rid 
of the jump instruction in the continue block, before the stitching. After all, 
after the merge it won't never be called.
I'm sending a new patch for this.

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

[Mesa-dev] [PATCH] nir: move ALU instruction before the jump instruction

[Juan A. Suarez Romero]

opt_split_alu_of_phi moves ALU instruction to the end of continue block.

But if the continue block ends with a jump instruction (an explicit
"continue" instruction) then the ALU must be inserted before the jump,
as it is illegal to add instructions after the jump.

CC: Ian Romanick 
Fixes: 0881e90c099 ("nir: Split ALU instructions in loops that read phis")
---
 src/compiler/nir/nir_opt_if.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compiler/nir/nir_opt_if.c b/src/compiler/nir/nir_opt_if.c
index 9afb901be14..932af9e37ab 100644
--- a/src/compiler/nir/nir_opt_if.c
+++ b/src/compiler/nir/nir_opt_if.c
@@ -488,7 +488,7 @@ opt_split_alu_of_phi(nir_builder *b, nir_loop *loop)
   *
   * Insert the new instruction at the end of the continue block.
   */
- b->cursor = nir_after_block(continue_block);
+ b->cursor = nir_after_block_before_jump(continue_block);
 
  nir_ssa_def *const alu_copy =
 clone_alu_and_replace_src_defs(b, alu, continue_srcs);
-- 
2.20.1

___
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

[Juan A. Suarez Romero]

On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> I had a chat with Caio about this and I'm skeptical.  In general, users of 
> the CF manipulation code shouldn't be stitching two blocks together where the 
> first contains a jump and the second is non-empty.  If the caller knows that 
> this case is ok, then they can check for it and empty out the one block 
> before stitching.  Also, I'm not really seeing how peel_initial_if would hit 
> this case from your example.
> 

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

[Mesa-dev] [PATCH v3] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.

Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) that all rendering is contained in the render area [...]
[which] must be contained within the framebuffer dimesions".

While this should be done by the application, commit 465e5a86 added the
clamp to the framebuffer size, in case of application does not do it.
But this requires to know the framebuffer dimensions.

If we do not have a framebuffer at that moment, the best compromise we
can do is to just apply the scissor as it is, and let the application to
ensure the rendering is contained in the render area.

v2: do not clamp to framebuffer if there isn't a framebuffer

v3 (Jason):
- clamp earlier in the conditional
- clamp to render area if command buffer is primary

Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary")
CC: Jason Ekstrand 
---
 src/intel/vulkan/gen7_cmd_buffer.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 352892aee33..1a8507fc94c 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -70,12 +70,28 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
*cmd_buffer)
   };
 
   const int max = 0x;
+
+  uint32_t height = s->offset.y + s->extent.height - 1;
+  uint32_t width = s->offset.x + s->extent.width - 1;
+
+  /* Do this math using int64_t so overflow gets clamped correctly. */
+  if (cmd_buffer->level == VK_COMMAND_BUFFER_LEVEL_PRIMARY) {
+ height = clamp_int64((uint64_t) height, 0,
+  cmd_buffer->state.render_area.offset.y +
+  cmd_buffer->state.render_area.extent.height - 1);
+ width = clamp_int64((uint64_t) width, 0,
+ cmd_buffer->state.render_area.offset.x +
+ cmd_buffer->state.render_area.extent.width - 1);
+  } else if (fb) {
+ height = clamp_int64((uint64_t) height, 0, fb->height - 1);
+ width = clamp_int64((uint64_t) width, 0, fb->width - 1);
+  }
+
   struct GEN7_SCISSOR_RECT scissor = {
- /* Do this math using int64_t so overflow gets clamped correctly. */
  .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
  .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
- .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
s->extent.height - 1, 0, fb->height - 1),
- .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
s->extent.width - 1, 0, fb->width - 1)
+ .ScissorRectangleYMax = height,
+ .ScissorRectangleXMax = width
   };
 
   if (s->extent.width <= 0 || s->extent.height <= 0) {
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH v2] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

On Fri, 2019-02-08 at 15:47 -0600, Jason Ekstrand wrote:
> On Fri, Feb 8, 2019 at 7:15 AM Juan A. Suarez Romero  
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> > 
> > was created inheriting from the primary buffer, but with the framebuffer
> > 
> > set to NULL in the VkCommandBufferInheritanceInfo.
> > 
> > 
> > 
> > Vulkan 1.1.81 spec says that "the application must ensure (using scissor
> > 
> > if neccesary) that all rendering is contained in the render area [...]
> > 
> > [which] must be contained within the framebuffer dimesions".
> > 
> > 
> > 
> > While this should be done by the application, commit 465e5a86 added the
> > 
> > clamp to the framebuffer size, in case of application does not do it.
> > 
> > But this requires to know the framebuffer dimensions.
> > 
> > 
> > 
> > If we do not have a framebuffer at that moment, the best compromise we
> > 
> > can do is to just apply the scissor as it is, and let the application to
> > 
> > ensure the rendering is contained in the render area.
> > 
> > 
> > 
> > v2: do not clamp to framebuffer if there isn't a framebuffer
> > 
> > 
> > 
> > Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary")
> > 
> > CC: Jason Ekstrand 
> > 
> > ---
> > 
> >  src/intel/vulkan/gen7_cmd_buffer.c | 15 +--
> > 
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > 
> > 
> > diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
> > b/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > index 352892aee33..6e3c8079dc5 100644
> > 
> > --- a/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > @@ -70,12 +70,23 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
> > *cmd_buffer)
> > 
> >};
> > 
> > 
> > 
> >const int max = 0x;
> > 
> > +
> > 
> > +  uint32_t max_height, max_width;
> > 
> > +
> > 
> > +  if (fb) {
> > 
> > + max_height = fb->height;
> > 
> > + max_width = fb->width;
> 
> Why aren't we clamping here?
> 
Right, a mistake.
> Also, I realized while we were e-mailing that if we're in the primary command 
> buffer, we can actually clamp to renderArea instead of the framebuffer.  
> That'd be even better.

OK. 
I'm sending a v3.
J.A.
>  
> > +  } else {
> > 
> > + max_height = s->offset.y + s->extent.height;
> > 
> > + max_width = s->offset.x + s->extent.width;
> > 
> > +  }
> > 
> > +
> > 
> >struct GEN7_SCISSOR_RECT scissor = {
> > 
> >   /* Do this math using int64_t so overflow gets clamped correctly. 
> > */
> > 
> >   .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
> > 
> >   .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
> > 
> > - .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > s->extent.height - 1, 0, fb->height - 1),
> > 
> > - .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > s->extent.width - 1, 0, fb->width - 1)
> > 
> > + .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > s->extent.height - 1, 0, max_height - 1),
> > 
> > + .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > s->extent.width - 1, 0, max_width - 1)
> > 
> >};
> > 
> > 
> > 
> >if (s->extent.width <= 0 || s->extent.height <= 0) {
> > 
___
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

[Juan A. Suarez Romero]

On Fri, 2019-02-08 at 10:29 -0800, Ian Romanick wrote:
> On 2/8/19 5:21 AM, Juan A. Suarez Romero wrote:
> > On Sat, 2019-01-26 at 08:37 -0800, Jason Ekstrand wrote:
> > > This makes me a bit nervous. I'll have to look at it in more detail.
> > > 
> > 
> > Did you have time to take a look at this?
> 
> Is there a test case that hits this?  Was it found by inspection?  I'm
> curious what the back story is...
> 

Found when dealing with this SPIR-V code:

   OpCapability Shader
  %1 = OpExtInstImport "GLSL.std.450"
   OpMemoryModel Logical GLSL450
   OpEntryPoint Fragment %main "main" %_GLF_color %gl_FragCoord
   OpExecutionMode %main OriginUpperLeft
   OpSource ESSL 310
   OpName %main "main"
   OpName %_GLF_color "_GLF_color"
   OpName %gl_FragCoord "gl_FragCoord"
   OpDecorate %_GLF_color Location 0
   OpDecorate %gl_FragCoord BuiltIn FragCoord
   %void = OpTypeVoid
  %3 = OpTypeFunction %void
  %float = OpTypeFloat 32
%v4float = OpTypeVector %float 4
%_ptr_Output_v4float = OpTypePointer Output %v4float
 %_GLF_color = OpVariable %_ptr_Output_v4float Output
%float_1 = OpConstant %float 1
%float_0 = OpConstant %float 0
 %12 = OpConstantComposite %v4float %float_1 %float_0 %float_0 %float_1
%int = OpTypeInt 32 1
  %int_0 = OpConstant %int 0
  %int_1 = OpConstant %int 1
   %bool = OpTypeBool
%_ptr_Input_v4float = OpTypePointer Input %v4float
%gl_FragCoord = OpVariable %_ptr_Input_v4float Input
   %uint = OpTypeInt 32 0
 %uint_0 = OpConstant %uint 0
%_ptr_Input_float = OpTypePointer Input %float
   %float_40 = OpConstant %float 40
  %float_140 = OpConstant %float 140
  %float_160 = OpConstant %float 160
 %uint_1 = OpConstant %uint 1
  %float_180 = OpConstant %float 180
  %false = OpConstantFalse %bool
   %true = OpConstantTrue %bool
%181 = OpUndef %v4float
   %main = OpFunction %void None %3
  %5 = OpLabel
   OpBranch %157
%157 = OpLabel
   OpStore %_GLF_color %12
   OpLoopMerge %156 %159 None
   OpBranch %17
 %17 = OpLabel
%167 = OpPhi %int %int_0 %157 %44 %41
 %25 = OpSLessThan %bool %167 %int_1
   OpLoopMerge %19 %41 None
   OpBranchConditional %25 %18 %19
 %18 = OpLabel
 %31 = OpAccessChain %_ptr_Input_float %gl_FragCoord %uint_0
 %32 = OpLoad %float %31
 %33 = OpFOrdLessThan %bool %float_1 %32
   OpSelectionMerge %35 None
   OpBranchConditional %33 %34 %35
 %34 = OpLabel
   OpBranch %19
 %35 = OpLabel
 %39 = OpFOrdLessThan %bool %32 %float_0
   OpSelectionMerge %41 None
   OpBranchConditional %39 %40 %41
 %40 = OpLabel
   OpBranch %19
 %41 = OpLabel
 %44 = OpIAdd %int %167 %int_1
   OpBranch %17
 %19 = OpLabel
%168 = OpPhi %bool %false %17 %false %34 %true %40
   OpSelectionMerge %163 None
   OpBranchConditional %168 %156 %163
%163 = OpLabel
   OpBranch %45
 %45 = OpLabel
   OpLoopMerge %47 %53 None
   OpBranch %46
 %46 = OpLabel
 %49 = OpAccessChain %_ptr_Input_float %gl_FragCoord %uint_0
 %50 = OpLoad %float %49
 %52 = OpFOrdLessThan %bool %50 %float_40
   OpSelectionMerge %53 None
   OpBranchConditional %52 %53 %55
 %53 = OpLabel
   OpStore %_GLF_color %12
   OpBranchConditional %false %45 %47
 %55 = OpLabel
 %59 = OpFOrdLessThan %bool %50 %float_140
   OpSelectionMerge %61 None
   OpBranchConditional %59 %60 %62
 %60 = OpLabel
   OpBranch %61
 %62 = OpLabel
   OpBranch %64
 %64 = OpLabel
%176 = OpPhi %v4float %181 %62 %197 %76
%171 = OpPhi %int %int_1 %62 %153 %76
 %70 = OpSGreaterThan %bool %171 %int_0
   OpLoopMerge %66 %76 None
   OpBranchConditional %70 %65 %66
 %65 = OpLabel
 %74 = OpFOrdLessThan %bool %50 %float_160
   OpSelectionMerge %76 None
   OpBranchConditional %74 %75 %94
 %75 = OpLabel
   OpBranch %78
 %78 = OpLabel
%185 = OpPhi %int %int_1 %75 %93 %90
 %84 = OpSGreaterThan %bool %185 %int_0
   OpLoopMerge %80 %90 None
   OpBranchConditional %84 %79 %80
 %79 = OpLabel
 %86 = OpAccessChain %_ptr_Input_float %gl_FragCoord %uint_1
 %87 = OpLoad %float %86
 %88 = OpFOrdLessThan %bool %87 %float_0
   OpSelectionMerge %90 None
   OpBr

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

[Juan A. Suarez Romero]

On Sat, 2019-01-26 at 08:37 -0800, Jason Ekstrand wrote:
> This makes me a bit nervous. I'll have to look at it in more detail.
> 

Did you have time to take a look at this?


J.A.

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

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

[Mesa-dev] [PATCH v2] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.

Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) that all rendering is contained in the render area [...]
[which] must be contained within the framebuffer dimesions".

While this should be done by the application, commit 465e5a86 added the
clamp to the framebuffer size, in case of application does not do it.
But this requires to know the framebuffer dimensions.

If we do not have a framebuffer at that moment, the best compromise we
can do is to just apply the scissor as it is, and let the application to
ensure the rendering is contained in the render area.

v2: do not clamp to framebuffer if there isn't a framebuffer

Fixes: 465e5a86 ("anv: Clamp scissors to the framebuffer boundary")
CC: Jason Ekstrand 
---
 src/intel/vulkan/gen7_cmd_buffer.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 352892aee33..6e3c8079dc5 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -70,12 +70,23 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
*cmd_buffer)
   };
 
   const int max = 0x;
+
+  uint32_t max_height, max_width;
+
+  if (fb) {
+ max_height = fb->height;
+ max_width = fb->width;
+  } else {
+ max_height = s->offset.y + s->extent.height;
+ max_width = s->offset.x + s->extent.width;
+  }
+
   struct GEN7_SCISSOR_RECT scissor = {
  /* Do this math using int64_t so overflow gets clamped correctly. */
  .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
  .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
- .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
s->extent.height - 1, 0, fb->height - 1),
- .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
s->extent.width - 1, 0, fb->width - 1)
+ .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
s->extent.height - 1, 0, max_height - 1),
+ .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
s->extent.width - 1, 0, max_width - 1)
   };
 
   if (s->extent.width <= 0 || s->extent.height <= 0) {
-- 
2.20.1

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

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

On Mon, 2019-02-04 at 10:01 -0600, Jason Ekstrand wrote:
> On Mon, Feb 4, 2019 at 3:02 AM Juan A. Suarez Romero  
> wrote:
> > On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> > 
> > > On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero 
> > >  wrote:
> > 
> > > > This can happen when we record a VkCmdDraw in a secondary buffer that
> > 
> > > > was created inheriting from the primary buffer, but with the framebuffer
> > 
> > > > set to NULL in the VkCommandBufferInheritanceInfo.
> > 
> > > > 
> > 
> > > > CC: Jason Ekstrand 
> > 
> > > > ---
> > 
> > > >  src/intel/vulkan/gen7_cmd_buffer.c | 13 +++--
> > 
> > > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > > > 
> > 
> > > > diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
> > > > b/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > > > index 352892aee33..fe1a47f6ce6 100644
> > 
> > > > --- a/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > > > +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> > 
> > > > @@ -70,12 +70,21 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
> > > > *cmd_buffer)
> > 
> > > >};
> > 
> > > > 
> > 
> > > >const int max = 0x;
> > 
> > > > +
> > 
> > > > +  uint32_t height = 0;
> > 
> > > > +  uint32_t width = 0;
> > 
> > > > +
> > 
> > > > +  if (fb) {
> > 
> > > > +height = fb->height;
> > 
> > > > +width = fb->width;
> > 
> > > > +  }
> > 
> > > > +
> > 
> > > >struct GEN7_SCISSOR_RECT scissor = {
> > 
> > > >   /* Do this math using int64_t so overflow gets clamped 
> > > > correctly. */
> > 
> > > >   .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
> > 
> > > >   .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
> > 
> > > > - .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > > > s->extent.height - 1, 0, fb->height - 1),
> > 
> > > > - .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > > > s->extent.width - 1, 0, fb->width - 1)
> > 
> > > > + .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > > > s->extent.height - 1, 0, height - 1),
> > 
> > > > + .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > > > s->extent.width - 1, 0, width - 1)
> > 
> > > 
> > 
> > > If fb == NULL, won't width/height be 0 and this be -1 and we end up 
> > > clamping to -1?  I think we want to rather make the clamp conditional on 
> > > having the framebuffer.
> > 
> > > 
> > 
> > 
> > 
> > Right. And as ScissorRectangle(X/Y)Max is an uint value, its value would be
> > 
> > MAX_UINT.
> 
> Which is fine if they specified a scissor that is >= the framebuffer size.  
> However, if they are actually trying to scissor something, this makes their 
> scissor disappear.  That's bad. :-)
> 
I see :)
So we are setting the clamping to ensure that the rendering happens inside the 
render area, which must be contained withing the framebuffer area.
This is something that actually the application should ensure, but we do it 
ourselves because it takes little effort to do it.
But if we do not have a framebuffer, we can't do it, so in this case I think 
the best compromise is go ahead with the scissor, and let the application to 
ensure later that the framebuffer is big enough for the rendering area.
I'm sending a V2 patch.
J.A.
> --Jason
>  
> > I think as we do not know the framebuffer size (which will be know later, 
> > IIUC),
> > 
> > we are emitting the scissor for the full rectangle.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > > --Jason
> > 
> > >  
> > 
> > > >};
> > 
> > > > 
> > 
> > > >if (s->extent.width <= 0 || s->extent.height <= 0) {
> > 
> > 
> > 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero  
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> > was created inheriting from the primary buffer, but with the framebuffer
> > set to NULL in the VkCommandBufferInheritanceInfo.
> > 
> > CC: Jason Ekstrand 
> > ---
> >  src/intel/vulkan/gen7_cmd_buffer.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
> > b/src/intel/vulkan/gen7_cmd_buffer.c
> > index 352892aee33..fe1a47f6ce6 100644
> > --- a/src/intel/vulkan/gen7_cmd_buffer.c
> > +++ b/src/intel/vulkan/gen7_cmd_buffer.c
> > @@ -70,12 +70,21 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
> > *cmd_buffer)
> >};
> > 
> >const int max = 0x;
> > +
> > +  uint32_t height = 0;
> > +  uint32_t width = 0;
> > +
> > +  if (fb) {
> > +height = fb->height;
> > +width = fb->width;
> > +  }
> > +
> >struct GEN7_SCISSOR_RECT scissor = {
> >   /* Do this math using int64_t so overflow gets clamped correctly. 
> > */
> >   .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
> >   .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
> > - .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > s->extent.height - 1, 0, fb->height - 1),
> > - .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > s->extent.width - 1, 0, fb->width - 1)
> > + .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
> > s->extent.height - 1, 0, height - 1),
> > + .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
> > s->extent.width - 1, 0, width - 1)
> 
> If fb == NULL, won't width/height be 0 and this be -1 and we end up clamping 
> to -1?  I think we want to rather make the clamp conditional on having the 
> framebuffer.
> 

Right. And as ScissorRectangle(X/Y)Max is an uint value, its value would be
MAX_UINT.

I think as we do not know the framebuffer size (which will be know later, IIUC),
we are emitting the scissor for the full rectangle.




> --Jason
>  
> >};
> > 
> >if (s->extent.width <= 0 || s->extent.height <= 0) {

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

[Mesa-dev] [PATCH] anv/cmd_buffer: check for NULL framebuffer

[Juan A. Suarez Romero]

This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.

CC: Jason Ekstrand 
---
 src/intel/vulkan/gen7_cmd_buffer.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/intel/vulkan/gen7_cmd_buffer.c 
b/src/intel/vulkan/gen7_cmd_buffer.c
index 352892aee33..fe1a47f6ce6 100644
--- a/src/intel/vulkan/gen7_cmd_buffer.c
+++ b/src/intel/vulkan/gen7_cmd_buffer.c
@@ -70,12 +70,21 @@ gen7_cmd_buffer_emit_scissor(struct anv_cmd_buffer 
*cmd_buffer)
   };
 
   const int max = 0x;
+
+  uint32_t height = 0;
+  uint32_t width = 0;
+
+  if (fb) {
+height = fb->height;
+width = fb->width;
+  }
+
   struct GEN7_SCISSOR_RECT scissor = {
  /* Do this math using int64_t so overflow gets clamped correctly. */
  .ScissorRectangleYMin = clamp_int64(s->offset.y, 0, max),
  .ScissorRectangleXMin = clamp_int64(s->offset.x, 0, max),
- .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
s->extent.height - 1, 0, fb->height - 1),
- .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
s->extent.width - 1, 0, fb->width - 1)
+ .ScissorRectangleYMax = clamp_int64((uint64_t) s->offset.y + 
s->extent.height - 1, 0, height - 1),
+ .ScissorRectangleXMax = clamp_int64((uint64_t) s->offset.x + 
s->extent.width - 1, 0, width - 1)
   };
 
   if (s->extent.width <= 0 || s->extent.height <= 0) {
-- 
2.20.1

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

Re: [Mesa-dev] Thoughts after hitting 100 merge requests?

[Juan A. Suarez Romero]

On Fri, 2019-01-25 at 13:26 -0800, Eric Anholt wrote:
> Rob Clark  writes:
> 
> > I guess as discovered with
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
> > should wait to turn on merging MRs via web until we have at least some
> > basic build-test CI wired up.. the downside is slower 'maintainer'
> > response (if I am working on some long running branch I tend to
> > postpone pushing changes from others until I am in a good state to
> > rebase, but at least when I merge things via cmdline I do a build test
> > and sanity test on at at least one driver ;-))
> 
> We should be days, not weeks, away from having build-test CI wired up.
> I actually thought Igalia was supposed to be working on it again
> already, but then Eric Engestrom started working on a new variation, so
> I'm not sure what's going on.
> 

Yes, I had the plan to update and create a MR with the GitLab CI proposal that I
had sent to mailing list at the beginning of the month, but for personal issues
I completely forgot about it. I'm really really sorry about it.

I don't know how much late I'm are to propose it. In any case, I've everything
ready to create a MR. But as it would be impolite impolite to do it after Eric
created one, I've left a comment in Eric's MR#146 with the proposal, explaining
it.

If Eric and others are fine, I can create a MR too.

J.A.

> I'm skeptical that we need to do an MR policy change given that
> build-breakage and especially unit-test-breakage has been a recurring
> issue in the absence of CI, even before MRs.
> ___
> 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