[Mesa-dev] [Bug 111039] [radv] - Persona 5 in RPCS3 emulator has glitches when using hardware fp16 (LLVM 9)

[bugzilla-daemon]

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

Bug ID: 111039
   Summary: [radv] - Persona 5 in RPCS3 emulator has glitches when
using hardware fp16 (LLVM 9)
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Vulkan/radeon
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: asheldo...@gmail.com
QA Contact: mesa-dev@lists.freedesktop.org

Since RPCS3 added support for native 16-bit float support, Persona 5 is
exhibiting graphical glitches when using its Vulkan renderer:

With hardware fp16:
https://i.imgur.com/NOyfaN7.jpg

With hardware fp16 disabled (correct rendering):
https://i.imgur.com/7oYKdBi.jpg

System:
Gentoo AMD64
Mesa git (RADV)
LLVM 9 git
RPCS3 git
Vega 56

Here's a link to the corresponding RPCS3 report:
https://github.com/RPCS3/rpcs3/issues/6150

They suggest the problem may be with LLVM code generation. I should note that
AMDVLK also has the same bug, which supports this conclusion. LLVM 8 can't be
tested since it causes a black screen with RPCS3
(https://bugs.freedesktop.org/show_bug.cgi?id=110970).

Also of note, bug doesn't occur with an RX-550 (on RADV or AMDVLK) and the bug
doesn't occur at all on Windows. So it looks to be a Vega specific bug, and
only on Linux.

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

Re: [Mesa-dev] radeonsi: glmark2 - regression (GL_INVALID_OPERATION in glFramebufferTexture2D) - bisected

[Dieter Nützel]

Hello Emil et al.,

sorry Emil you were NOT the right person to blame for this - see below.

Am 22.06.2019 04:55, schrieb Dieter Nützel:

Hello Emil,

I see glmark2 - [desktop] blur-radius=5

libpng warning: iCCP: known incorrect sRGB profile
Mesa: User error: GL_INVALID_OPERATION in
glFramebufferTexture2D(window-system framebuffer)
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4:
FPS: 4879 FrameTime: 0.205 ms

after your commits around beginning of June (2019-06-05) or your
'mapi'-work commited around 2019-06-10.


I had to go much further back...


Have to bisect.


Did it, now. Hello Marek and Mathias ;-)

/opt/mesa> git bisect good
b5697c311b6f29dee40b96c48bad3279e3667c1e is the first bad commit
commit b5697c311b6f29dee40b96c48bad3279e3667c1e
Author: Marek Olšák 
Date:   Thu May 9 21:04:23 2019 -0400

Change a few frequented uses of DEBUG to !NDEBUG

debugoptimized builds don't define NDEBUG, but they also don't 
define

DEBUG. We want to enable cheap debug code for these builds.
I only chose those occurences that I care about.

Reviewed-by: Mathias Fröhlich 

 src/gallium/auxiliary/tgsi/tgsi_ureg.c  | 2 +-
 src/gallium/drivers/radeonsi/si_descriptors.c   | 2 +-
 src/gallium/drivers/radeonsi/si_pipe.h  | 2 +-
 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 6 +++---
 src/gallium/drivers/radeonsi/si_state.c | 4 ++--
 src/mesa/main/context.c | 2 +-
 src/mesa/main/debug.c   | 4 ++--
 src/mesa/main/errors.c  | 6 +++---
 src/mesa/main/feedback.c| 2 +-
 src/mesa/main/formats.c | 2 --
 src/mesa/main/imports.c | 4 ++--
 src/mesa/main/mtypes.h  | 2 +-
 src/mesa/main/shaderapi.c   | 2 +-
 src/mesa/state_tracker/st_atom_framebuffer.c| 2 +-
 src/mesa/state_tracker/st_format.c  | 2 +-
 src/mesa/vbo/vbo_exec.h | 2 +-
 src/mesa/vbo/vbo_exec_api.c | 6 +++---
 src/util/slab.c | 4 ++--
 18 files changed, 27 insertions(+), 29 deletions(-)

After reverting this all is fine, again.

My meson config for Mesa git:
meson ../ --strip --buildtype debugoptimized -Ddri-drivers= 
-Dplatforms=drm,x11 -Dgallium-drivers=r600,radeonsi,swrast 
-Dvulkan-drivers=amd -Dgallium-nine=true -Dgallium-opencl=standalone 
-Dglvnd=true -Dgallium-va=false -Dgallium-xvmc=false 
-Dgallium-omx=disabled -Dgallium-xa=false


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

[Mesa-dev] [Bug 111019] radv doesn't handle variable descriptor count properly

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

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

--- Comment #2 from Bas Nieuwenhuizen  ---
The MR above landed. I'm marking as fixed, but please reopen if there are still
issues. Thanks!

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

Re: [Mesa-dev] [PATCH 5/5] anv: disable repacking for compression for applicable gen

[Anuj Phogat]

On Thu, Jun 27, 2019 at 9:55 AM Dongwon Kim  wrote:
>
> set bit15 (Disable Rebacking for Compression) of CACHE_MODE_0 register
Repacking

With minor nits fixed. This series is:
Reviewed-by: Anuj Phogat 

I'll push the series after testing with these changes. Thanks for the patches :)

> if the gen attribute, 'disable_ccs_repack' is set.
>
> Signed-off-by: Dongwon Kim 
> ---
>  src/intel/vulkan/genX_state.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/src/intel/vulkan/genX_state.c b/src/intel/vulkan/genX_state.c
> index 21b8cd648d4..c1163628cc0 100644
> --- a/src/intel/vulkan/genX_state.c
> +++ b/src/intel/vulkan/genX_state.c
> @@ -225,6 +225,24 @@ genX(init_device_state)(struct anv_device *device)
> }
>  #endif
>
> +#if GEN_GEN >= 11
> +   /* hardware specification recommends disabling repacking for
> +* the compatibility with decompression mechanism in display controller.
> +*/
> +   if (device->info.disable_ccs_repack) {
> +  uint32_t cache_mode_0;
> +  anv_pack_struct(_mode_0,
> +  GENX(CACHE_MODE_0),
> +  .DisableRepackingforCompression = true,
> +  .DisableRepackingforCompressionMask = true);
> +
> +  anv_batch_emit(, GENX(MI_LOAD_REGISTER_IMM), lri) {
> + lri.RegisterOffset = GENX(CACHE_MODE_0_num);
> + lri.DataDWord  = cache_mode_0;
> +  }
> +   }
> +#endif
> +
> /* Set the "CONSTANT_BUFFER Address Offset Disable" bit, so
>  * 3DSTATE_CONSTANT_XS buffer 0 is an absolute address.
>  *
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/5] iris: disable repacking for compression for applicable gen

[Anuj Phogat]

On Thu, Jun 27, 2019 at 9:55 AM Dongwon Kim  wrote:
>
> set bit15 (Disable Rebacking for Compression) of CACHE_MODE_0 register
Repacking
> if the gen attribute, 'disable_ccs_repack' is set.
>
> Signed-off-by: Dongwon Kim 
> ---
>  src/gallium/drivers/iris/iris_state.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/iris/iris_state.c 
> b/src/gallium/drivers/iris/iris_state.c
> index bf31f31f3e4..ce25f1ffcb3 100644
> --- a/src/gallium/drivers/iris/iris_state.c
> +++ b/src/gallium/drivers/iris/iris_state.c
> @@ -755,6 +755,16 @@ iris_init_render_context(struct iris_screen *screen,
>}
>iris_emit_lri(batch, SLICE_COMMON_ECO_CHICKEN1, reg_val);
>
> +  /* hardware specification recommends disabling repacking for
> +   * the compatibility with decompression mechanism in display 
> controller.
> +   */
> +  if (devinfo->disable_ccs_repack) {
> + iris_pack_state(GENX(CACHE_MODE_0), _val, reg) {
> +reg.DisableRepackingforCompression = true;
> +reg.DisableRepackingforCompressionMask = true;
> + }
> + iris_emit_lri(batch, CACHE_MODE_0, reg_val);
> +  }
>
>// XXX: 3D_MODE?
>  #endif
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/5] i965: disable repacking for compression for applicable gen

[Anuj Phogat]

On Thu, Jun 27, 2019 at 9:55 AM Dongwon Kim  wrote:
>
> set bit15 (Disable Rebacking for Compression) of CACHE_MODE_0 register
Disable Repacking
> if the gen attribute, 'disable_ccs_repack' is set.
>
> Signed-off-by: Dongwon Kim 
> ---
>  src/mesa/drivers/dri/i965/brw_defines.h  | 1 +
>  src/mesa/drivers/dri/i965/brw_state_upload.c | 9 +
>  2 files changed, 10 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index 17bca1991f1..e8507b7e5ff 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -1576,6 +1576,7 @@ enum brw_pixel_shader_coverage_mask_mode {
>  # define GEN9_PARTIAL_RESOLVE_DISABLE_IN_VC (1 << 1)
>  # define GEN8_HIZ_PMA_MASK_BITS \
> REG_MASK(GEN8_HIZ_NP_PMA_FIX_ENABLE | GEN8_HIZ_NP_EARLY_Z_FAILS_DISABLE)
> +# define GEN11_DISABLE_REPACKING_FOR_COMPRESSION (1 << 15)
>
>  #define GEN7_GT_MODE0x7008
>  # define GEN9_SUBSLICE_HASHING_8x8  (0 << 8)
> diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c 
> b/src/mesa/drivers/dri/i965/brw_state_upload.c
> index 938b9defeda..09303600308 100644
> --- a/src/mesa/drivers/dri/i965/brw_state_upload.c
> +++ b/src/mesa/drivers/dri/i965/brw_state_upload.c
> @@ -121,6 +121,15 @@ brw_upload_initial_gpu_state(struct brw_context *brw)
> 
> REG_MASK(GEN11_STATE_CACHE_REDIRECT_TO_CS_SECTION_ENABLE));
> }
>
> +   /* hardware specification recommends disabling repacking for
> +* the compatibility with decompression mechanism in display controller.
> +*/
> +   if (devinfo->disable_ccs_repack) {
> +  brw_load_register_imm32(brw, GEN7_CACHE_MODE_0,
> +  GEN11_DISABLE_REPACKING_FOR_COMPRESSION |
> +  
> REG_MASK(GEN11_DISABLE_REPACKING_FOR_COMPRESSION));
> +   }
> +
> if (devinfo->gen == 10 || devinfo->gen == 11) {
>/* From gen10 workaround table in h/w specs:
> *
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/5] intel: add disable_ccs_repack to gen_device_info

[Anuj Phogat]

On Thu, Jun 27, 2019 at 9:55 AM Dongwon Kim  wrote:
>
> add a new attribute, 'disable_ccs_repack' to gen_device info, which
> indicates whether repacking of components in certain pixel formats
> before compression needs to be disabled to keep the compatibility
> with decompression capability of display controller (gen11+)
>
> Signed-off-by: Dongwon Kim 
> ---
>  src/intel/dev/gen_device_info.c | 3 +++
>  src/intel/dev/gen_device_info.h | 1 +
>  2 files changed, 4 insertions(+)
>
> diff --git a/src/intel/dev/gen_device_info.c b/src/intel/dev/gen_device_info.c
> index fec6159fd37..2b5be842a4e 100644
> --- a/src/intel/dev/gen_device_info.c
> +++ b/src/intel/dev/gen_device_info.c
> @@ -958,6 +958,7 @@ static const struct gen_device_info 
> gen_device_info_ehl_4x8 = {
>   [MESA_SHADER_GEOMETRY]  = 1032,
>},
> },
> +   .disable_ccs_repack = 1,
disable_ccs_repack = true

Similar change at few other places in this patch.
> .simulator_id = 28,
>  };
>
> @@ -978,6 +979,7 @@ static const struct gen_device_info 
> gen_device_info_ehl_4x4 = {
>   [MESA_SHADER_GEOMETRY]  = 1032,
>},
> },
> +   .disable_ccs_repack = 1,
> .num_eu_per_subslice = 4,
> .simulator_id = 28,
>  };
> @@ -999,6 +1001,7 @@ static const struct gen_device_info 
> gen_device_info_ehl_2x4 = {
>   [MESA_SHADER_GEOMETRY]  = 1032,
>},
> },
> +   .disable_ccs_repack = 1,
> .num_eu_per_subslice =4,
> .simulator_id = 28,
>  };
> diff --git a/src/intel/dev/gen_device_info.h b/src/intel/dev/gen_device_info.h
> index af13615be2b..4fe937355a7 100644
> --- a/src/intel/dev/gen_device_info.h
> +++ b/src/intel/dev/gen_device_info.h
> @@ -74,6 +74,7 @@ struct gen_device_info
> bool has_surface_tile_offset;
> bool supports_simd16_3src;
> bool has_resource_streamer;
> +   bool disable_ccs_repack;
>
> /**
>  * \name Intel hardware quirks
> --
> 2.17.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 110345] Unrecoverable GPU crash with DiRT 4

[bugzilla-daemon]

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

Francisco Pina Martins  changed:

   What|Removed |Added

 CC||f.pinamart...@gmail.com

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

Re: [Mesa-dev] What does WIP really mean in an MR?

[Nanley Chery]

On Sat, Jun 29, 2019 at 4:40 PM Eric Engestrom  wrote:
>
> On Saturday, 2019-06-29 22:59:21 +0200, apinheiro wrote:
> >
> > On 29/6/19 2:30, Rob Clark wrote:
> > > I had interpreted it as literally the "block the gitlab merge button"
> > > option, ie. "I want to get feedback but it is not ready to merge and
> > > I'll drop the WIP tag when I think it is"..
> >
> >
> > >
> > > (comments inline)
> > >
> > > On Fri, Jun 28, 2019 at 5:12 PM Ian Romanick  wrote:
> > > > After a conversation yesterday with a couple of the other Intel devs,
> > > > I've come to the conclusion that *everyone* interprets WIP to mean
> > > > something different.  I heard no less than four interpretations.
> > > >
> > > > * This series is good.  It hasn't been reviewed, so don't click "merge."
> > > isn't that the point of a MR.. doesn't seem like a reason for "WIP"
> >
> >
> > I agree with Rob here. What I understand of WIP is that there is some reason
> > that prevents a MR to be merged, even if I still want it to be reviewed, or
> > if it is fully reviewed. For example, I send a MR with patches that I think
> > that are correct, so people can start to review it. But on a rebase, I found
> > that the branch causes regressions on piglit/cts/whatever. I still think
> > that the patches are correct, but those regressions need to be investigated
> > before pushing. So I just add a WIP on the MR to prevent to be merged by
> > mistake.
>
> Kind of just saying "+1" here, but yeah that's also my understanding of "WIP".
>

A help page in our gitlab instance [1] suggests a more relaxed/broader usage
of the WIP tag. So, I had been using WIP to block accidental merges that don't
meet the usual merge criteria (e.g., the code isn't ready or it lacks
reviewed-by tags).
I don't mind avoiding it on MRs that are gated only on the review tags.

1. 
https://gitlab.freedesktop.org/help/user/project/merge_requests/work_in_progress_merge_requests.md

> >
> > >
> > > > * This series has some sketchy bits.  It probably isn't ready for review
> > > > unless you've been tagged for design feedback.
> > > I guess I'd also use WIP for "I want some early feedback, but it isn't
> > > ready yet".. but in this case I'd also poke people who I wanted to
> > > look at it
> >
> >
> > I thought that in this case RFC was used. Or RFC was dropped on gitlab MRs?
>
> Agreed; and "RFC" is definitely being used:
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests?state=all=RFC
>
> Adding "WIP" as well prevents accidental merging, so it makes sense.
>
> >
> >
> > >
> > > > * This series has been reviewed.  Incorporation of detailed feedback is
> > > > in progress, but it's going to take some time.
> > > I suppose also a case for "WIP"..
> > >
> > > > * This series is good, but there are some questionable patches at the 
> > > > end.
> > > I guess in this case, I'd reform things into multiple MR's, one with
> > > the parts ready to go, and one w/ the remaining WIP bits
> > >
> > > BR,
> > > -R
> > >
> > > > Due to this lack of common understanding, we discovered at least one MR
> > > > that was ready to go but had been ignored for months. :(  This makes me
> > > > wonder if other MRs have similarly languished for no good reason.
> > > >
> > > > Can we formulate some guidelines for how people should apply WIP to
> > > > their MRs and how people should interpret WIP when they see it on an MR?
>
> Once we reach a consensus, we should write it down in 
> docs/submittingpatches.html

Agreed.

-Nanley

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

Re: [Mesa-dev] [PATCH v2 7/7] radv: enable DCC for layers on GFX8

[Bas Nieuwenhuizen]

r-b for the series

On Mon, Jul 1, 2019 at 4:27 PM Samuel Pitoiset
 wrote:
>
> It's currently only enabled if dcc_slice_size is equal to
> dcc_slice_fast_clear_size because the driver assumes that
> portions of multiple layers are contiguous but it's not
> always true.
>
> Still not supported on GFX9.
>
> v2: - only if dcc_slice_size == dcc_slice_fast_clear_size
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_image.c | 32 +++-
>  1 file changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
> index 07d89d32edf..eeccce0d82f 100644
> --- a/src/amd/vulkan/radv_image.c
> +++ b/src/amd/vulkan/radv_image.c
> @@ -171,14 +171,10 @@ radv_use_dcc_for_image(struct radv_device *device,
> return false;
>
> /* TODO: Enable DCC for mipmaps on GFX9+. */
> -   if (pCreateInfo->mipLevels > 1 &&
> +   if ((pCreateInfo->arrayLayers > 1 || pCreateInfo->mipLevels > 1) &&
> device->physical_device->rad_info.chip_class >= GFX9)
> return false;
>
> -   /* TODO: Enable DCC for array layers. */
> -   if (pCreateInfo->arrayLayers > 1)
> -   return false;
> -
> /* Do not enable DCC for mipmapped arrays because performance is 
> worse. */
> if (pCreateInfo->arrayLayers > 1 && pCreateInfo->mipLevels > 1)
> return false;
> @@ -1018,10 +1014,28 @@ radv_image_can_enable_dcc_or_cmask(struct radv_image 
> *image)
>  }
>
>  static inline bool
> -radv_image_can_enable_dcc(struct radv_image *image)
> +radv_image_can_enable_dcc(struct radv_device *device, struct radv_image 
> *image)
>  {
> -   return radv_image_can_enable_dcc_or_cmask(image) &&
> -  radv_image_has_dcc(image);
> +   if (!radv_image_can_enable_dcc_or_cmask(image) ||
> +   !radv_image_has_dcc(image))
> +   return false;
> +
> +   /* On GFX8, DCC layers can be interleaved and it's currently only
> +* enabled if slice size is equal to the per slice fast clear size
> +* because the driver assumes that portions of multiple layers are
> +* contiguous during fast clears.
> +*/
> +   if (image->info.array_size > 1) {
> +   const struct legacy_surf_level *surf_level =
> +   >planes[0].surface.u.legacy.level[0];
> +
> +   assert(device->physical_device->rad_info.chip_class == GFX8);
> +
> +   if (image->planes[0].surface.dcc_slice_size != 
> surf_level->dcc_fast_clear_size)
> +   return false;
> +   }
> +
> +   return true;
>  }
>
>  static inline bool
> @@ -1151,7 +1165,7 @@ radv_image_create(VkDevice _device,
>
> if (!create_info->no_metadata_planes) {
> /* Try to enable DCC first. */
> -   if (radv_image_can_enable_dcc(image)) {
> +   if (radv_image_can_enable_dcc(device, image)) {
> radv_image_alloc_dcc(image);
> if (image->info.samples > 1) {
> /* CMASK should be enabled because DCC fast
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] panfrost: Add the sampled texture BO to the job

[Alyssa Rosenzweig]

R-b, thank you! :)

On Mon, Jul 01, 2019 at 07:04:44PM +0200, Boris Brezillon wrote:
> Otherwise we get random use-after-{free,unmap} errors.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> - Move the panfrost_job_add_bo() call out of the loop
> ---
>  src/gallium/drivers/panfrost/pan_context.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_context.c 
> b/src/gallium/drivers/panfrost/pan_context.c
> index bf98d3853f16..c103a764edd9 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -840,6 +840,10 @@ panfrost_upload_tex(
>  bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
>  unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
>  
> + /* Add the BO to the job so it's retained until the job is done. */
> +struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
> +panfrost_job_add_bo(job, rsrc->bo);
> +
>  /* Inject the addresses in, interleaving mip levels, cube faces, and
>   * strides in that order */
>  
> -- 
> 2.21.0
> 


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

[Mesa-dev] [Bug 111016] Building Mesa GLX with Meson for macOS fails

[bugzilla-daemon]

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

--- Comment #5 from Dylan Baker  ---
I've proposed a fix here for the glx bits:

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

You really should turn off xvmc and vdpau, as even if those happen to compile
(which meson should error on) they're useless. Those are state trackers that
have a hard requirement on a gallium driver (for macos swrast), and are useless
without one. I don't think that glvnd doesn't work on macos either, but I could
be wrong

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

[Mesa-dev] [PATCH v2] panfrost: Add the sampled texture BO to the job

[Boris Brezillon]

Otherwise we get random use-after-{free,unmap} errors.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- Move the panfrost_job_add_bo() call out of the loop
---
 src/gallium/drivers/panfrost/pan_context.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index bf98d3853f16..c103a764edd9 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -840,6 +840,10 @@ panfrost_upload_tex(
 bool is_zs = rsrc->base.bind & PIPE_BIND_DEPTH_STENCIL;
 unsigned afbc_bit = (is_afbc && !is_zs) ? 1 : 0;
 
+   /* Add the BO to the job so it's retained until the job is done. */
+struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
+panfrost_job_add_bo(job, rsrc->bo);
+
 /* Inject the addresses in, interleaving mip levels, cube faces, and
  * strides in that order */
 
-- 
2.21.0

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

[Mesa-dev] [Bug 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1

[bugzilla-daemon]

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

Emil Velikov  changed:

   What|Removed |Added

 Resolution|NOTABUG |---
 Status|RESOLVED|REOPENED

--- Comment #15 from Emil Velikov  ---
Let's reopen this. Can someone provide a simple how-to, for example:

HW X, weston/wayland server vY
env.variables A, B, C - before and after launching wayland server

Chances are we end up going through some strange mix of swrast and kms_swrast.


Note: Usually the Wayland server itself uses platform_drm, while apps within
the Wayland server platform_wayland.

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

[Mesa-dev] [Bug 111036] 5.2-rc7 19.1.1-1 repetitive error loop

[bugzilla-daemon]

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

--- Comment #6 from Stuart Naylor  ---
whoops xorg

[rock@rockpi4 lib]$ cat /var/log/Xorg.0.log
[  1102.877] (--) Log file renamed from "/var/log/Xorg.pid-1950.log" to
"/var/log/Xorg.0.log"
[  1102.878]
X.Org X Server 1.20.5
X Protocol Version 11, Revision 0
[  1102.878] Build Operating System: Linux Arch Linux
[  1102.878] Current Operating System: Linux rockpi4 5.2.0-rc7-4-MANJARO-ARM #1
SMP Mon Jul 1 09:03:24 UTC 2019 aarch64
[  1102.878] Kernel command line: console=ttyS2,150
root=PARTUUID=f316cff5-01 rw rootwait initrd=0x0400,20M ramdisk_size=10M
[  1102.878] Build Date: 01 June 2019  04:42:15PM
[  1102.878]
[  1102.878] Current version of pixman: 0.38.4
[  1102.878]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1102.878] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1102.878] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul  1 16:51:31
2019
[  1102.878] (==) Using config directory: "/etc/X11/xorg.conf.d"
[  1102.878] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1102.927] (==) No Layout section.  Using the first Screen section.
[  1102.927] (==) No screen section available. Using defaults.
[  1102.927] (**) |-->Screen "Default Screen Section" (0)
[  1102.927] (**) |   |-->Monitor ""
[  1102.928] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1102.928] (==) Automatically adding devices
[  1102.928] (==) Automatically enabling devices
[  1102.928] (==) Automatically adding GPU devices
[  1102.928] (==) Automatically binding GPU devices
[  1102.928] (==) Max clients allowed: 256, resource mask: 0x1f
[  1102.928] (WW) The directory "/usr/share/fonts/misc" does not exist.
[  1102.928]Entry deleted from font path.
[  1102.928] (WW) The directory "/usr/share/fonts/OTF" does not exist.
[  1102.928]Entry deleted from font path.
[  1102.928] (WW) The directory "/usr/share/fonts/Type1" does not exist.
[  1102.928]Entry deleted from font path.
[  1102.928] (WW) The directory "/usr/share/fonts/100dpi" does not exist.
[  1102.928]Entry deleted from font path.
[  1102.928] (WW) The directory "/usr/share/fonts/75dpi" does not exist.
[  1102.928]Entry deleted from font path.
[  1102.928] (==) FontPath set to:
/usr/share/fonts/TTF
[  1102.928] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1102.928] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable
AutoAddDevices.
[  1102.928] (II) Module ABI versions:
[  1102.928]X.Org ANSI C Emulation: 0.4
[  1102.928]X.Org Video Driver: 24.0
[  1102.928]X.Org XInput driver : 24.1
[  1102.928]X.Org Server Extension : 10.0
[  1102.931] (++) using VT number 1

[  1102.931] (II) systemd-logind: logind integration requires -keeptty and
-keeptty was not provided, disabling logind integration
[  1102.933] (II) xfree86: Adding drm device (/dev/dri/card1)
[  1102.933] (II) xfree86: Adding drm device (/dev/dri/card0)
[  1102.934] (II) no primary bus or device found
[  1102.934]falling back to
/sys/devices/platform/display-subsystem/drm/card1
[  1102.934] (II) LoadModule: "glx"
[  1102.935] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  1102.959] (II) Module glx: vendor="X.Org Foundation"
[  1102.959]compiled for 1.20.5, module version = 1.0.0
[  1102.959]ABI class: X.Org Server Extension, version 10.0
[  1102.959] (==) Matched modesetting as autoconfigured driver 0
[  1102.959] (==) Matched fbdev as autoconfigured driver 1
[  1102.959] (==) Assigned the driver to the xf86ConfigLayout
[  1102.959] (II) LoadModule: "modesetting"
[  1102.959] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  1103.866] (II) Module modesetting: vendor="X.Org Foundation"
[  1103.910]compiled for 1.20.5, module version = 1.20.5
[  1103.910]Module class: X.Org Video Driver
[  1103.910]ABI class: X.Org Video Driver, version 24.0
[  1103.910] (II) LoadModule: "fbdev"
[  1103.911] (WW) Warning, couldn't open module fbdev
[  1103.911] (EE) Failed to load module "fbdev" (module does not exist, 0)
[  1103.911] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  1103.911] (II) modeset(0): using drv /dev/dri/card1
[  1103.912] (II) modeset(0): Creating default Display subsection in Screen
section
"Default Screen Section" for depth/fbbpp 24/32
[  1103.912] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
[  1103.912] (==) modeset(0): RGB weight 888
[  1103.912] (==) modeset(0): Default visual is TrueColor
[  1103.912] (II) Loading sub module "glamoregl"
[  1103.912] (II) LoadModule: "glamoregl"
[  1103.913] (II) Loading 

[Mesa-dev] [Bug 111036] 5.2-rc7 19.1.1-1 repetitive error loop

[bugzilla-daemon]

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

--- Comment #5 from Stuart Naylor  ---
  PROCESSOR:  ARMv8 Cortex-A72 @ 1.42GHz
Core Count:   6
Scaling Driver:   cpufreq-dt ondemand

  GRAPHICS:   rockchipdrmfb
Display Driver:   modesetting 1.20.5
Monitor:  S22C570
Screen:   1920x1080

  MOTHERBOARD:Radxa ROCK Pi 4

  MEMORY: 2048MB

  DISK:   31GB SD32G
File-System:  ext4
Mount Options:relatime rw

  OPERATING SYSTEM:   Manjaro-ARM 19.06
Kernel:   5.2.0-rc7-4-MANJARO-ARM (aarch64) 20190701
Desktop:  LXQt
Display Server:   X Server 1.20.5
Compiler: GCC 8.3.0
Security: l1tf: Not affected
  + mds: Not affected
  + meltdown: Not affected
  + spec_store_bypass: Vulnerable
  + spectre_v1: Mitigation of __user pointer sanitization
  + spectre_v2: Vulnerable

git clone https://gitlab.freedesktop.org/mesa/drm.git --depth=1
git clone https://gitlab.freedesktop.org/mesa/mesa.git --depth=1

meson -Ddri-drivers= -Dvulkan-drivers= -Dgallium-drivers=panfrost,kmsro
-Dlibunwind=false -Dplatforms=x11,drm,surfaceless -Dprefix=/usr build/

[  194.629122] panfrost ff9a.gpu: mmu irq status=1
[  194.629575] panfrost ff9a.gpu: Unhandled Page fault in AS0 at VA
0x178F50C0
[  194.629575] Reason: TODO
[  194.629575] raw fault status: 0x8002C3
[  194.629575] decoded fault status: SLAVE FAULT
[  194.629575] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[  194.629575] access type 0x2: READ
[  194.629575] source id 0x80
[  195.134200] panfrost ff9a.gpu: gpu sched timeout, js=0, status=0x8,
head=0x2401c80, tail=0x2401c80, sched_job=1b4c4a39
[  195.899844] panfrost ff9a.gpu: mmu irq status=1
[  195.900315] panfrost ff9a.gpu: Unhandled Page fault in AS0 at VA
0x178F5000
[  195.900315] Reason: TODO
[  195.900315] raw fault status: 0x8002C3
[  195.900315] decoded fault status: SLAVE FAULT
[  195.900315] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[  195.900315] access type 0x2: READ
[  195.900315] source id 0x80
[  196.404157] panfrost ff9a.gpu: gpu sched timeout, js=0, status=0x8,
head=0x2001c80, tail=0x2001c80, sched_job=bc0611d5
[  196.473152] panfrost ff9a.gpu: mmu irq status=1
[  196.473606] panfrost ff9a.gpu: Unhandled Page fault in AS0 at VA
0x17957500
[  196.473606] Reason: TODO
[  196.473606] raw fault status: 0x28002C3
[  196.473606] decoded fault status: SLAVE FAULT
[  196.473606] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[  196.473606] access type 0x2: READ
[  196.473606] source id 0x280
[  196.974223] panfrost ff9a.gpu: gpu sched timeout, js=0, status=0x8,
head=0x2001c80, tail=0x2001c80, sched_job=cc8338f8
[  196.981008] panfrost ff9a.gpu: mmu irq status=1
[  196.981480] panfrost ff9a.gpu: Unhandled Page fault in AS0 at VA
0x17957300
[  196.981480] Reason: TODO
[  196.981480] raw fault status: 0x8002C3
[  196.981480] decoded fault status: SLAVE FAULT
[  196.981480] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[  196.981480] access type 0x2: READ
[  196.981480] source id 0x80
[  197.484023] panfrost ff9a.gpu: gpu sched timeout, js=0, status=0x8,
head=0x2401c80, tail=0x2401c80, sched_job=5a464365
youtube..[  366.557396] panfrost ff9a.gpu: mmu irq status=1
[  366.557873] panfrost ff9a.gpu: Unhandled Page fault in AS0 at VA
0x189BFA00
[  366.557873] Reason: TODO
[  366.557873] raw fault status: 0x28002C3
[  366.557873] decoded fault status: SLAVE FAULT
[  366.557873] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[  366.557873] access type 0x2: READ
[  366.557873] source id 0x280
[  367.061470] panfrost ff9a.gpu: gpu sched timeout, js=0, status=0x8,
head=0x2002a00, tail=0x2002a00, sched_job=93523800
[  367.086392] panfrost ff9a.gpu: mmu irq status=1
[  367.086843] panfrost ff9a.gpu: Unhandled Page fault in AS0 at VA
0x189AB000
[  367.086843] Reason: TODO
[  367.086843] raw fault status: 0x48002C3
[  367.086843] decoded fault status: SLAVE FAULT
[  367.086843] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[  367.086843] access type 0x2: READ
[  367.086843] source id 0x480
[  367.591679] panfrost ff9a.gpu: gpu sched timeout, js=0, status=0x8,
head=0x200e080, tail=0x200e080, sched_job=44afd636
[  367.615810] panfrost ff9a.gpu: mmu irq status=1
[  367.616262] panfrost ff9a.gpu: Unhandled Page fault in AS0 at VA
0x1791DD40
[  367.616262] Reason: TODO
[  367.616262] raw fault status: 0x28002C3
[  367.616262] decoded fault status: SLAVE FAULT
[  367.616262] exception type 0xC3: TRANSLATION_FAULT_LEVEL3
[  367.616262] access type 0x2: READ
[  367.616262] source id 0x280
[  368.121598] panfrost ff9a.gpu: gpu sched timeout, js=0, status=0x8,
head=0x200a200, tail=0x200a200, sched_job

[Mesa-dev] radv: use rtld for shader uploads

[Nicolai Hähnle-Montoro]

Hey folks,

the merge request at
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1220 moves
radv to using the rtld for shader uploads for parity with radeonsi and
to address some issues that arose with changes in LLVM behavior.
Please review!

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrost: Add the sampled texture BO to the job

[Boris Brezillon]

On Mon, 1 Jul 2019 08:28:03 -0700
Alyssa Rosenzweig  wrote:

> >  
> > @@ -848,6 +850,7 @@ panfrost_upload_tex(
> >  for (unsigned l = first_level; l <= last_level; ++l) {
> >  for (unsigned f = first_layer; f <= last_layer; ++f) {
> >  
> > +panfrost_job_add_bo(job, rsrc->bo);
> >  view->hw.payload[idx++] =
> >  panfrost_get_texture_address(rsrc, l, f) + 
> > afbc_bit;  
> 
> The bo is guaranteed to be the same for all levels and layers. So this
> should be pulled out of both loops.

Absolutely, guess I was to prompt at sending the patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] panfrost: Add the sampled texture BO to the job

[Alyssa Rosenzweig]

>  
> @@ -848,6 +850,7 @@ panfrost_upload_tex(
>  for (unsigned l = first_level; l <= last_level; ++l) {
>  for (unsigned f = first_layer; f <= last_layer; ++f) {
>  
> +panfrost_job_add_bo(job, rsrc->bo);
>  view->hw.payload[idx++] =
>  panfrost_get_texture_address(rsrc, l, f) + 
> afbc_bit;

The bo is guaranteed to be the same for all levels and layers. So this
should be pulled out of both loops.


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

[Mesa-dev] [PATCH] panfrost: Add the sampled texture BO to the job

[Boris Brezillon]

Otherwise we get random use-after-{free,unmap} errors.

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/panfrost/pan_context.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index bf98d3853f16..37207398e82b 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -816,6 +816,8 @@ panfrost_upload_tex(
 struct panfrost_context *ctx,
 struct panfrost_sampler_view *view)
 {
+struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
+
 if (!view)
 return (mali_ptr) NULL;
 
@@ -848,6 +850,7 @@ panfrost_upload_tex(
 for (unsigned l = first_level; l <= last_level; ++l) {
 for (unsigned f = first_layer; f <= last_layer; ++f) {
 
+panfrost_job_add_bo(job, rsrc->bo);
 view->hw.payload[idx++] =
 panfrost_get_texture_address(rsrc, l, f) + 
afbc_bit;
 
-- 
2.21.0

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

Re: [Mesa-dev] [PATCH 7/7] panfrost: Implement instanced rendering

[Alyssa Rosenzweig]

> If you're interested, nouveau has logic to optionally go the shared
> (1:N) or non-shared (1:1) way of doing it. Have a look at nvc0_vbo.c
> if you're curious -- look for mentions of "shared".

Hmm, I see. A bit more complex than I was hoping for the moment.


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

Re: [Mesa-dev] [PATCH 7/7] panfrost: Implement instanced rendering

[Ilia Mirkin]

On Mon, Jul 1, 2019 at 10:56 AM Alyssa Rosenzweig
 wrote:
> As a side effect, we rework how vertex buffers are handled, duplicating
> them to be 1:1 with vertex descriptors to simplify instancing code paths
> dramatically. This might be a performance regression, but this remains
> to be seen; if so, we can always deduplicate later with some added logic
> in pan_instancing.c

If you're interested, nouveau has logic to optionally go the shared
(1:N) or non-shared (1:1) way of doing it. Have a look at nvc0_vbo.c
if you're curious -- look for mentions of "shared".

Cheers,

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

[Mesa-dev] [PATCH 2/7] panfrost: Implement dispatch helpers

[Alyssa Rosenzweig]

Rather than open-coding workgroups_shift_* type fields, we include a
general routine for packing the vertex/tiler/compute descriptor based on
the provided dispatch parameters.

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/meson.build  |   1 +
 src/gallium/drivers/panfrost/pan_context.c|  24 ++--
 src/gallium/drivers/panfrost/pan_context.h|  23 
 src/gallium/drivers/panfrost/pan_invocation.c | 130 ++
 4 files changed, 165 insertions(+), 13 deletions(-)
 create mode 100644 src/gallium/drivers/panfrost/pan_invocation.c

diff --git a/src/gallium/drivers/panfrost/meson.build 
b/src/gallium/drivers/panfrost/meson.build
index 4298242f6b9..80cfee794db 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -57,6 +57,7 @@ files_panfrost = files(
   'pan_blend_shaders.c',
   'pan_pretty_print.c',
   'pan_fragment.c',
+  'pan_invocation.c',
   'pan_scoreboard.c',
   'pan_sfbd.c',
   'pan_mfbd.c',
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index bf98d3853f1..871b168040c 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -283,11 +283,6 @@ static void
 panfrost_emit_vertex_payload(struct panfrost_context *ctx)
 {
 struct midgard_payload_vertex_tiler payload = {
-.prefix = {
-.workgroups_z_shift = 32,
-.workgroups_x_shift_2 = 0x2,
-.workgroups_x_shift_3 = 0x5,
-},
.gl_enables = 0x4 | (ctx->is_t6xx ? 0 : 0x2),
 };
 
@@ -299,10 +294,6 @@ panfrost_emit_tiler_payload(struct panfrost_context *ctx)
 {
 struct midgard_payload_vertex_tiler payload = {
 .prefix = {
-.workgroups_z_shift = 32,
-.workgroups_x_shift_2 = 0x2,
-.workgroups_x_shift_3 = 0x6,
-
 .zero1 = 0x, /* Why is this only seen on 
test-quad-textured? */
 },
 };
@@ -1668,7 +1659,7 @@ panfrost_draw_vbo(
 ctx->vertex_count = info->count;
 
 /* For non-indexed draws, they're the same */
-unsigned invocation_count = ctx->vertex_count;
+unsigned vertex_count = ctx->vertex_count;
 
 unsigned draw_flags = 0;
 
@@ -1701,7 +1692,7 @@ panfrost_draw_vbo(
 }
 
 /* Use the corresponding values */
-invocation_count = max_index - min_index + 1;
+vertex_count = max_index - min_index + 1;
 ctx->payload_vertex.draw_start = min_index;
 ctx->payload_tiler.draw_start = min_index;
 
@@ -1724,8 +1715,15 @@ panfrost_draw_vbo(
 ctx->payload_tiler.prefix.indices = (uintptr_t) NULL;
 }
 
-ctx->payload_vertex.prefix.invocation_count = 
MALI_POSITIVE(invocation_count);
-ctx->payload_tiler.prefix.invocation_count = 
MALI_POSITIVE(invocation_count);
+/* Dispatch "compute jobs" for the vertex/tiler pair as (1,
+ * vertex_count, 1) */
+
+panfrost_pack_work_groups_fused(
+>payload_vertex.prefix,
+>payload_tiler.prefix,
+1, vertex_count, 1,
+1, 1, 1);
+
 ctx->payload_tiler.prefix.unknown_draw = draw_flags;
 
 /* Fire off the draw itself */
diff --git a/src/gallium/drivers/panfrost/pan_context.h 
b/src/gallium/drivers/panfrost/pan_context.h
index ca6f8deef33..f83083be0fc 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -343,4 +343,27 @@ panfrost_fragment_job(struct panfrost_context *ctx, bool 
has_draws);
 void
 panfrost_shader_compile(struct panfrost_context *ctx, struct mali_shader_meta 
*meta, const char *src, int type, struct panfrost_shader_state *state);
 
+void
+panfrost_pack_work_groups_compute(
+struct mali_vertex_tiler_prefix *out,
+unsigned num_x,
+unsigned num_y,
+unsigned num_z,
+unsigned size_x,
+unsigned size_y,
+unsigned size_z);
+
+void
+panfrost_pack_work_groups_fused(
+struct mali_vertex_tiler_prefix *vertex,
+struct mali_vertex_tiler_prefix *tiler,
+unsigned num_x,
+unsigned num_y,
+unsigned num_z,
+unsigned size_x,
+unsigned size_y,
+unsigned size_z);
+
+
+
 #endif
diff --git a/src/gallium/drivers/panfrost/pan_invocation.c 
b/src/gallium/drivers/panfrost/pan_invocation.c
new file mode 100644
index 000..0d4945d05b1
--- /dev/null
+++ b/src/gallium/drivers/panfrost/pan_invocation.c
@@ -0,0 +1,130 @@
+/*
+ * Copyright (C) 2019 Collabora, Ltd.
+ *
+ * Permission is hereby granted, free 

[Mesa-dev] [PATCH 3/7] panfrost/midgard: Use the appropriate ld_attr type

[Alyssa Rosenzweig]

Signed-off-by: Alyssa Rosenzweig 
---
 .../panfrost/midgard/midgard_compile.c| 20 +++
 1 file changed, 20 insertions(+)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 13f4ed9e283..edf7eb0b16a 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1237,6 +1237,10 @@ emit_intrinsic(compiler_context *ctx, 
nir_intrinsic_instr *instr)
 bool is_uniform = instr->intrinsic == 
nir_intrinsic_load_uniform;
 bool is_ubo = instr->intrinsic == nir_intrinsic_load_ubo;
 
+/* Get the base type of the intrinsic */
+nir_alu_type t = nir_intrinsic_type(instr);
+t = nir_alu_type_get_base_type(t);
+
 if (!is_ubo) {
 offset = nir_intrinsic_base(instr);
 }
@@ -1287,6 +1291,22 @@ emit_intrinsic(compiler_context *ctx, 
nir_intrinsic_instr *instr)
 midgard_instruction ins = m_ld_attr_32(reg, offset);
 ins.load_store.unknown = 0x1E1E; /* XXX: What is this? 
*/
 ins.load_store.mask = mask_of(nr_comp);
+
+/* Use the type appropriate load */
+switch (t) {
+case nir_type_int:
+case nir_type_uint:
+case nir_type_bool:
+ins.load_store.op = 
midgard_op_ld_attr_32i;
+break;
+case nir_type_float:
+ins.load_store.op = 
midgard_op_ld_attr_32;
+break;
+default:
+unreachable("Attempted to load unknown 
type");
+break;
+}
+
 emit_mir_instruction(ctx, ins);
 } else {
 DBG("Unknown load\n");
-- 
2.20.1

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

[Mesa-dev] [PATCH 4/7] panfrost/midgard: Add unsigned ld/st ops

[Alyssa Rosenzweig]

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/midgard/midgard.h | 4 
 src/gallium/drivers/panfrost/midgard/midgard_compile.c | 4 +++-
 src/gallium/drivers/panfrost/midgard/midgard_ops.c | 4 
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h 
b/src/gallium/drivers/panfrost/midgard/midgard.h
index 0a121c3a5b4..d632063e8a4 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard.h
+++ b/src/gallium/drivers/panfrost/midgard/midgard.h
@@ -419,13 +419,16 @@ typedef enum {
 
 midgard_op_ld_attr_32 = 0x94,
 midgard_op_ld_attr_16 = 0x95,
+midgard_op_ld_attr_32u = 0x96,
 midgard_op_ld_attr_32i = 0x97,
 midgard_op_ld_vary_32 = 0x98,
 midgard_op_ld_vary_16 = 0x99,
+midgard_op_ld_vary_32u = 0x9A,
 midgard_op_ld_vary_32i = 0x9B,
 midgard_op_ld_color_buffer_16 = 0x9D,
 
 midgard_op_ld_uniform_16 = 0xAC,
+midgard_op_ld_uniform_32i = 0xA8,
 
 midgard_op_ld_uniform_32 = 0xB0,
 midgard_op_ld_color_buffer_8 = 0xBA,
@@ -438,6 +441,7 @@ typedef enum {
 
 midgard_op_st_vary_32 = 0xD4,
 midgard_op_st_vary_16 = 0xD5,
+midgard_op_st_vary_32u = 0xD6,
 midgard_op_st_vary_32i = 0xD7,
 
 /* Value to st in r27, location r26.w as short2 */
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index edf7eb0b16a..d7155289a71 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1294,9 +1294,11 @@ emit_intrinsic(compiler_context *ctx, 
nir_intrinsic_instr *instr)
 
 /* Use the type appropriate load */
 switch (t) {
-case nir_type_int:
 case nir_type_uint:
 case nir_type_bool:
+ins.load_store.op = 
midgard_op_ld_attr_32u;
+break;
+case nir_type_int:
 ins.load_store.op = 
midgard_op_ld_attr_32i;
 break;
 case nir_type_float:
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_ops.c 
b/src/gallium/drivers/panfrost/midgard/midgard_ops.c
index 3c8535ae09a..089d5cecb1f 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_ops.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_ops.c
@@ -190,15 +190,18 @@ const char *load_store_opcode_names[256] = {
 [midgard_op_ld_attr_32] = "ld_attr_32",
 [midgard_op_ld_attr_16] = "ld_attr_16",
 [midgard_op_ld_attr_32i] = "ld_attr_32i",
+[midgard_op_ld_attr_32u] = "ld_attr_32u",
 
 [midgard_op_ld_vary_32] = "ld_vary_32",
 [midgard_op_ld_vary_16] = "ld_vary_16",
 [midgard_op_ld_vary_32i] = "ld_vary_32i",
+[midgard_op_ld_vary_32u] = "ld_vary_32u",
 
 [midgard_op_ld_color_buffer_16] = "ld_color_buffer_16",
 
 [midgard_op_ld_uniform_16] = "ld_uniform_16",
 [midgard_op_ld_uniform_32] = "ld_uniform_32",
+[midgard_op_ld_uniform_32i] = "ld_uniform_32i",
 [midgard_op_ld_color_buffer_8] = "ld_color_buffer_8",
 
 [midgard_op_st_char] = "st_char",
@@ -210,6 +213,7 @@ const char *load_store_opcode_names[256] = {
 [midgard_op_st_vary_32] = "st_vary_32",
 [midgard_op_st_vary_16] = "st_vary_16",
 [midgard_op_st_vary_32i] = "st_vary_32i",
+[midgard_op_st_vary_32u] = "st_vary_32u",
 
 [midgard_op_st_image_f] = "st_image_f",
 [midgard_op_st_image_ui] = "st_image_ui",
-- 
2.20.1

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

[Mesa-dev] [PATCH 6/7] panfrost/decode: Compute padded_num_vertices for MODULO

[Alyssa Rosenzweig]

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/pandecode/decode.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c 
b/src/gallium/drivers/panfrost/pandecode/decode.c
index 129e769cace..4cc7ca03995 100644
--- a/src/gallium/drivers/panfrost/pandecode/decode.c
+++ b/src/gallium/drivers/panfrost/pandecode/decode.c
@@ -895,15 +895,25 @@ pandecode_replay_attributes(const struct 
pandecode_mapped_memory *mem,
 pandecode_log("{\n");
 pandecode_indent++;
 
-   pandecode_prop("elements = (%s_%d_p) | %s", base, i, 
pandecode_attr_mode_name(attr[i].elements & 7));
+unsigned mode = attr[i].elements & 7;
+   pandecode_prop("elements = (%s_%d_p) | %s", base, i, 
pandecode_attr_mode_name(mode));
pandecode_prop("shift = %d", attr[i].shift);
pandecode_prop("extra_flags = %d", attr[i].extra_flags);
 pandecode_prop("stride = 0x%" PRIx32, attr[i].stride);
 pandecode_prop("size = 0x%" PRIx32, attr[i].size);
+
+/* Decode further where possible */
+
+if (mode == MALI_ATTR_MODULO) {
+unsigned odd = (2 * attr[i].extra_flags) + 1;
+unsigned pot = (1 << attr[i].shift);
+pandecode_msg("padded_num_vertices = %d\n", odd * pot);
+}
+
 pandecode_indent--;
 pandecode_log("}, \n");
 
-   if ((attr[i].elements & 7) == MALI_ATTR_NPOT_DIVIDE) {
+   if (mode == MALI_ATTR_NPOT_DIVIDE) {
i++;
pandecode_log("{\n");
pandecode_indent++;
-- 
2.20.1

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

[Mesa-dev] [PATCH 7/7] panfrost: Implement instanced rendering

[Alyssa Rosenzweig]

We implement GLES3.0 instanced rendering with full support for instanced
arrays (via instance divisors). To do so, we use the new invocation
helpers to invoke a triplet of (1, vertex_count, instance_count), rather
than simply (1, vertex_count, 1). We rewrite the attribute handling code
into a new pan_instancing.c file which handles both the simple LINEAR
case for non-instanced as well as each of the new instancing cases:
MODULO (for per-vertex attributes), POT and NPOT divisors.

As a side effect, we rework how vertex buffers are handled, duplicating
them to be 1:1 with vertex descriptors to simplify instancing code paths
dramatically. This might be a performance regression, but this remains
to be seen; if so, we can always deduplicate later with some added logic
in pan_instancing.c

Signed-off-by: Alyssa Rosenzweig 
---
 .../drivers/panfrost/include/panfrost-job.h   |  16 +-
 src/gallium/drivers/panfrost/meson.build  |   1 +
 .../panfrost/midgard/midgard_compile.c|   4 +-
 src/gallium/drivers/panfrost/pan_context.c| 123 ---
 src/gallium/drivers/panfrost/pan_context.h|  26 ++
 src/gallium/drivers/panfrost/pan_instancing.c | 341 ++
 src/gallium/drivers/panfrost/pan_invocation.c |   1 +
 src/gallium/drivers/panfrost/pan_screen.c |   4 +
 .../drivers/panfrost/pandecode/decode.c   | 112 +-
 9 files changed, 568 insertions(+), 60 deletions(-)
 create mode 100644 src/gallium/drivers/panfrost/pan_instancing.c

diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h 
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 444e5ad9e69..5c93f319b65 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -834,8 +834,9 @@ struct mali_attr_meta {
 /* Always observed to be zero at the moment */
 unsigned unknown3 : 2;
 
-/* When packing multiple attributes in a buffer, offset addresses by 
this value */
-uint32_t src_offset;
+/* When packing multiple attributes in a buffer, offset addresses by
+ * this value. Obscurely, this is signed. */
+int32_t src_offset;
 } __attribute__((packed));
 
 enum mali_fbd_type {
@@ -1061,7 +1062,16 @@ struct midgard_payload_vertex_tiler {
 u32 zero3;
 #endif
 
-u32 gl_enables; // 0x5
+u16 gl_enables; // 0x5
+
+/* Both zero for non-instanced draws. For instanced draws, a
+ * decomposition of padded_num_vertices. See the comments about the
+ * corresponding fields in mali_attr for context. */
+
+unsigned instance_shift : 5;
+unsigned instance_odd : 3;
+
+u8 zero4;
 
 /* Offset for first vertex in buffer */
 u32 draw_start;
diff --git a/src/gallium/drivers/panfrost/meson.build 
b/src/gallium/drivers/panfrost/meson.build
index 80cfee794db..b69b41bfd90 100644
--- a/src/gallium/drivers/panfrost/meson.build
+++ b/src/gallium/drivers/panfrost/meson.build
@@ -58,6 +58,7 @@ files_panfrost = files(
   'pan_pretty_print.c',
   'pan_fragment.c',
   'pan_invocation.c',
+  'pan_instancing.c',
   'pan_scoreboard.c',
   'pan_sfbd.c',
   'pan_mfbd.c',
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 4a399293af0..5559aa44454 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1255,7 +1255,9 @@ emit_intrinsic(compiler_context *ctx, nir_intrinsic_instr 
*instr)
 bool is_ubo = instr->intrinsic == nir_intrinsic_load_ubo;
 
 /* Get the base type of the intrinsic */
-nir_alu_type t = nir_intrinsic_type(instr);
+/* TODO: Infer type? Does it matter? */
+nir_alu_type t =
+is_ubo ? nir_type_uint : nir_intrinsic_type(instr);
 t = nir_alu_type_get_base_type(t);
 
 if (!is_ubo) {
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 871b168040c..88e70c97881 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -552,7 +552,7 @@ panfrost_emit_point_coord(union mali_attr *slot)
 static void
 panfrost_emit_varying_descriptor(
 struct panfrost_context *ctx,
-unsigned invocation_count)
+unsigned vertex_count)
 {
 /* Load the shaders */
 
@@ -638,19 +638,19 @@ panfrost_emit_varying_descriptor(
 unsigned idx = 0;
 
 panfrost_emit_varyings(ctx, [idx++], num_gen_varyings * 16,
-   invocation_count);
+   vertex_count);
 
 /* fp32 vec4 gl_Position */
 ctx->payload_tiler.postfix.position_varying =
 panfrost_emit_varyings(ctx, [idx++],
-sizeof(float) * 4, 

[Mesa-dev] [PATCH 1/7] panfrost: Remove ancient comment

[Alyssa Rosenzweig]

Signed-off-by: Alyssa Rosenzweig 
---
 src/gallium/drivers/panfrost/include/panfrost-job.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h 
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 4abff22f33c..444e5ad9e69 100644
--- a/src/gallium/drivers/panfrost/include/panfrost-job.h
+++ b/src/gallium/drivers/panfrost/include/panfrost-job.h
@@ -1096,9 +1096,6 @@ struct bifrost_payload_fused {
 struct mali_vertex_tiler_postfix vertex_postfix;
 } __attribute__((packed));
 
-/* Pointed to from texture_trampoline, mostly unknown still, haven't
- * managed to replay successfully */
-
 /* Purposeful off-by-one in width, height fields. For example, a (64, 64)
  * texture is stored as (63, 63) in these fields. This adjusts for that.
  * There's an identical pattern in the framebuffer descriptor. Even vertex
-- 
2.20.1

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

[Mesa-dev] [PATCH 5/7] panfrost/midgard: Emit type appropriate ld_vary

[Alyssa Rosenzweig]

Signed-off-by: Alyssa Rosenzweig 
---
 .../panfrost/midgard/midgard_compile.c| 21 +--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c 
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index d7155289a71..4a399293af0 100644
--- a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
+++ b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
@@ -1091,7 +1091,7 @@ emit_varying_read(
 compiler_context *ctx,
 unsigned dest, unsigned offset,
 unsigned nr_comp, unsigned component,
-nir_src *indirect_offset)
+nir_src *indirect_offset, nir_alu_type type)
 {
 /* XXX: Half-floats? */
 /* TODO: swizzle, mask */
@@ -1119,6 +1119,23 @@ emit_varying_read(
 ins.load_store.unknown = 0x1e9e; /* xxx: what is this? */
 }
 
+/* Use the type appropriate load */
+switch (type) {
+case nir_type_uint:
+case nir_type_bool:
+ins.load_store.op = midgard_op_ld_vary_32u;
+break;
+case nir_type_int:
+ins.load_store.op = midgard_op_ld_vary_32i;
+break;
+case nir_type_float:
+ins.load_store.op = midgard_op_ld_vary_32;
+break;
+default:
+unreachable("Attempted to load unknown type");
+break;
+}
+
 emit_mir_instruction(ctx, ins);
 }
 
@@ -1280,7 +1297,7 @@ emit_intrinsic(compiler_context *ctx, nir_intrinsic_instr 
*instr)
 uint32_t uindex = nir_src_as_uint(index) + 1;
 emit_ubo_read(ctx, reg, offset / 16, NULL, uindex);
 } else if (ctx->stage == MESA_SHADER_FRAGMENT && 
!ctx->is_blend) {
-emit_varying_read(ctx, reg, offset, nr_comp, 
component, !direct ? >src[0] : NULL);
+emit_varying_read(ctx, reg, offset, nr_comp, 
component, !direct ? >src[0] : NULL, t);
 } else if (ctx->is_blend) {
 /* For blend shaders, load the input color, which is
  * preloaded to r0 */
-- 
2.20.1

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

[Mesa-dev] [PATCH v2 2/7] ac: compute the DCC fast clear size per slice on GFX8

[Samuel Pitoiset]

v2: - add dcc_slice_fast_clear_size to be more confortable about RadeonSI

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_surface.c | 27 +++
 src/amd/common/ac_surface.h |  1 +
 2 files changed, 28 insertions(+)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 9e45bd44b72..55237eb1eef 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -308,6 +308,33 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
 * slice is the same size) it's easy to compute.
 */
surf->dcc_slice_size = AddrDccOut->dccRamSize / 
config->info.array_size;
+
+   /* For arrays, we have to compute the DCC info again
+* with one slice size to get a correct fast clear
+* size.
+*/
+   if (config->info.array_size > 1) {
+   AddrDccIn->colorSurfSize = 
AddrSurfInfoOut->sliceSize;
+   AddrDccIn->tileMode = AddrSurfInfoOut->tileMode;
+   AddrDccIn->tileInfo = 
*AddrSurfInfoOut->pTileInfo;
+   AddrDccIn->tileIndex = 
AddrSurfInfoOut->tileIndex;
+   AddrDccIn->macroModeIndex = 
AddrSurfInfoOut->macroModeIndex;
+
+   ret = AddrComputeDccInfo(addrlib,
+AddrDccIn, AddrDccOut);
+   if (ret == ADDR_OK) {
+   /* If the DCC memory isn't properly
+* aligned, the data are interleaved
+* accross slices.
+*/
+   if (AddrDccOut->dccRamSizeAligned)
+   
surf_level->dcc_slice_fast_clear_size = AddrDccOut->dccFastClearSize;
+   else
+   
surf_level->dcc_slice_fast_clear_size = 0;
+   }
+   } else {
+   surf_level->dcc_slice_fast_clear_size = 
surf_level->dcc_fast_clear_size;
+   }
}
}
 
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 8143c9f9a0e..a4144a4e16c 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -76,6 +76,7 @@ struct legacy_surf_level {
 uint32_tslice_size_dw; /* in dwords; max = 4GB / 4. */
 uint32_tdcc_offset; /* relative offset within DCC mip 
tree */
 uint32_tdcc_fast_clear_size;
+uint32_tdcc_slice_fast_clear_size;
 unsignednblk_x:15;
 unsignednblk_y:15;
 enum radeon_surf_mode   mode:2;
-- 
2.22.0

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

[Mesa-dev] [PATCH v2 7/7] radv: enable DCC for layers on GFX8

[Samuel Pitoiset]

It's currently only enabled if dcc_slice_size is equal to
dcc_slice_fast_clear_size because the driver assumes that
portions of multiple layers are contiguous but it's not
always true.

Still not supported on GFX9.

v2: - only if dcc_slice_size == dcc_slice_fast_clear_size

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_image.c | 32 +++-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 07d89d32edf..eeccce0d82f 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -171,14 +171,10 @@ radv_use_dcc_for_image(struct radv_device *device,
return false;
 
/* TODO: Enable DCC for mipmaps on GFX9+. */
-   if (pCreateInfo->mipLevels > 1 &&
+   if ((pCreateInfo->arrayLayers > 1 || pCreateInfo->mipLevels > 1) &&
device->physical_device->rad_info.chip_class >= GFX9)
return false;
 
-   /* TODO: Enable DCC for array layers. */
-   if (pCreateInfo->arrayLayers > 1)
-   return false;
-
/* Do not enable DCC for mipmapped arrays because performance is worse. 
*/
if (pCreateInfo->arrayLayers > 1 && pCreateInfo->mipLevels > 1)
return false;
@@ -1018,10 +1014,28 @@ radv_image_can_enable_dcc_or_cmask(struct radv_image 
*image)
 }
 
 static inline bool
-radv_image_can_enable_dcc(struct radv_image *image)
+radv_image_can_enable_dcc(struct radv_device *device, struct radv_image *image)
 {
-   return radv_image_can_enable_dcc_or_cmask(image) &&
-  radv_image_has_dcc(image);
+   if (!radv_image_can_enable_dcc_or_cmask(image) ||
+   !radv_image_has_dcc(image))
+   return false;
+
+   /* On GFX8, DCC layers can be interleaved and it's currently only
+* enabled if slice size is equal to the per slice fast clear size
+* because the driver assumes that portions of multiple layers are
+* contiguous during fast clears.
+*/
+   if (image->info.array_size > 1) {
+   const struct legacy_surf_level *surf_level =
+   >planes[0].surface.u.legacy.level[0];
+
+   assert(device->physical_device->rad_info.chip_class == GFX8);
+
+   if (image->planes[0].surface.dcc_slice_size != 
surf_level->dcc_fast_clear_size)
+   return false;
+   }
+
+   return true;
 }
 
 static inline bool
@@ -1151,7 +1165,7 @@ radv_image_create(VkDevice _device,
 
if (!create_info->no_metadata_planes) {
/* Try to enable DCC first. */
-   if (radv_image_can_enable_dcc(image)) {
+   if (radv_image_can_enable_dcc(device, image)) {
radv_image_alloc_dcc(image);
if (image->info.samples > 1) {
/* CMASK should be enabled because DCC fast
-- 
2.22.0

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

[Mesa-dev] [PATCH v2 6/7] radv: do not enable DCC for mipmapped arrays because performance is worse

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_image.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/amd/vulkan/radv_image.c b/src/amd/vulkan/radv_image.c
index 4099c57aa85..07d89d32edf 100644
--- a/src/amd/vulkan/radv_image.c
+++ b/src/amd/vulkan/radv_image.c
@@ -179,6 +179,10 @@ radv_use_dcc_for_image(struct radv_device *device,
if (pCreateInfo->arrayLayers > 1)
return false;
 
+   /* Do not enable DCC for mipmapped arrays because performance is worse. 
*/
+   if (pCreateInfo->arrayLayers > 1 && pCreateInfo->mipLevels > 1)
+   return false;
+
if (radv_surface_has_scanout(device, create_info))
return false;
 
-- 
2.22.0

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

[Mesa-dev] [PATCH v2 5/7] radv: implement clearing DCC layers on GFX8

[Samuel Pitoiset]

v2: - use dcc_slice_fast_clear_size

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_cmd_buffer.c | 6 --
 src/amd/vulkan/radv_meta_clear.c | 5 +++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 1f3fdd1abd0..fc8184200fc 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -4968,11 +4968,13 @@ void radv_initialize_dcc(struct radv_cmd_buffer 
*cmd_buffer,
for (unsigned i = 0; i < 
image->planes[0].surface.num_dcc_levels; i++) {
struct legacy_surf_level *surf_level =
>planes[0].surface.u.legacy.level[i];
+   unsigned dcc_fast_clear_size =
+   surf_level->dcc_slice_fast_clear_size * 
image->info.array_size;
 
-   if (!surf_level->dcc_fast_clear_size)
+   if (!dcc_fast_clear_size)
break;
 
-   size = surf_level->dcc_offset + 
surf_level->dcc_fast_clear_size;
+   size = surf_level->dcc_offset + dcc_fast_clear_size;
}
 
/* Initialize the mipmap levels without DCC. */
diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index e5181daf0f2..08d9ea3e1db 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1397,8 +1397,9 @@ radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
 * fast clear path fallbacks to slow clears if one
 * level can't be fast cleared.
 */
-   offset += surf_level->dcc_offset;
-   size = surf_level->dcc_fast_clear_size;
+   offset += surf_level->dcc_offset +
+ surf_level->dcc_slice_fast_clear_size * 
range->baseArrayLayer;
+   size = surf_level->dcc_slice_fast_clear_size * 
radv_get_layerCount(image, range);
}
 
flush_bits |= radv_fill_buffer(cmd_buffer, image->bo, offset,
-- 
2.22.0

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

[Mesa-dev] [PATCH v2 4/7] radv: merge radv_dcc_clear_level() into radv_clear_dcc()

[Samuel Pitoiset]

This will help for clearing DCC arrays because we need to know
the subresource range.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_clear.c | 52 ++--
 1 file changed, 22 insertions(+), 30 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index b0b17f4f7b3..e5181daf0f2 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1367,34 +1367,6 @@ radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
return radv_fill_buffer(cmd_buffer, image->bo, offset, size, value);
 }
 
-static uint32_t
-radv_dcc_clear_level(struct radv_cmd_buffer *cmd_buffer,
-const struct radv_image *image,
-uint32_t level, uint32_t value)
-{
-   uint64_t offset = image->offset + image->dcc_offset;
-   uint32_t size;
-
-   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
-   /* Mipmap levels aren't implemented. */
-   assert(level == 0);
-   size = image->planes[0].surface.dcc_size;
-   } else {
-   const struct legacy_surf_level *surf_level =
-   >planes[0].surface.u.legacy.level[level];
-
-   /* If dcc_fast_clear_size is 0 (which might happens for
-* mipmaps) the fill buffer operation below is a no-op. This
-* can only happen during initialization as the fast clear path
-* fallbacks to slow clears if one level can't be fast cleared.
-*/
-   offset += surf_level->dcc_offset;
-   size = surf_level->dcc_fast_clear_size;
-   }
-
-   return radv_fill_buffer(cmd_buffer, image->bo, offset, size, value);
-}
-
 uint32_t
 radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
   struct radv_image *image,
@@ -1407,10 +1379,30 @@ radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
radv_update_dcc_metadata(cmd_buffer, image, range, true);
 
for (uint32_t l = 0; l < level_count; l++) {
+   uint64_t offset = image->offset + image->dcc_offset;
uint32_t level = range->baseMipLevel + l;
+   uint64_t size;
+
+   if (cmd_buffer->device->physical_device->rad_info.chip_class >= 
GFX9) {
+   /* Mipmap levels aren't implemented. */
+   assert(level == 0);
+   size = image->planes[0].surface.dcc_size;
+   } else {
+   const struct legacy_surf_level *surf_level =
+   >planes[0].surface.u.legacy.level[level];
+
+   /* If dcc_fast_clear_size is 0 (which might happens for
+* mipmaps) the fill buffer operation below is a no-op.
+* This can only happen during initialization as the
+* fast clear path fallbacks to slow clears if one
+* level can't be fast cleared.
+*/
+   offset += surf_level->dcc_offset;
+   size = surf_level->dcc_fast_clear_size;
+   }
 
-   flush_bits |= radv_dcc_clear_level(cmd_buffer, image,
-  level, value);
+   flush_bits |= radv_fill_buffer(cmd_buffer, image->bo, offset,
+  size, value);
}
 
return flush_bits;
-- 
2.22.0

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

[Mesa-dev] [PATCH v2 3/7] radv: add support for decompressing DCC layers with compute

[Samuel Pitoiset]

Signed-off-by: Samuel Pitoiset 
---
 src/amd/vulkan/radv_meta_fast_clear.c | 104 +-
 1 file changed, 53 insertions(+), 51 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_fast_clear.c 
b/src/amd/vulkan/radv_meta_fast_clear.c
index a642d6243d4..d601686f8f6 100644
--- a/src/amd/vulkan/radv_meta_fast_clear.c
+++ b/src/amd/vulkan/radv_meta_fast_clear.c
@@ -818,58 +818,60 @@ radv_decompress_dcc_compute(struct radv_cmd_buffer 
*cmd_buffer,
height = radv_minify(image->info.height,
subresourceRange->baseMipLevel + l);
 
-   radv_image_view_init(, cmd_buffer->device,
-&(VkImageViewCreateInfo) {
-.sType = 
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
-.image = 
radv_image_to_handle(image),
-.viewType = 
VK_IMAGE_VIEW_TYPE_2D,
-.format = image->vk_format,
-.subresourceRange = {
-   .aspectMask = 
VK_IMAGE_ASPECT_COLOR_BIT,
-   .baseMipLevel = 
subresourceRange->baseMipLevel + l,
-   .levelCount = 1,
-   .baseArrayLayer = 0,
-   .layerCount = 1
-},
-});
-
-   radv_meta_push_descriptor_set(cmd_buffer,
- VK_PIPELINE_BIND_POINT_COMPUTE,
- 
device->meta_state.fast_clear_flush.dcc_decompress_compute_p_layout,
- 0, /* set */
- 2, /* descriptorWriteCount */
- (VkWriteDescriptorSet[]) {
- {
-  .sType = 
VK_STRUCTURE_TYPE_WRITE_DESCRIPTOR_SET,
-  .dstBinding = 0,
-  .dstArrayElement 
= 0,
-  .descriptorCount 
= 1,
-  .descriptorType 
= VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE,
-  .pImageInfo = 
(VkDescriptorImageInfo[]) {
-  {
-  
.sampler = VK_NULL_HANDLE,
-  
.imageView = radv_image_view_to_handle(),
-  
.imageLayout = VK_IMAGE_LAYOUT_GENERAL,
-  },
-  }
- },
+   for (uint32_t s = 0; s < radv_get_layerCount(image, 
subresourceRange); s++) {
+   radv_image_view_init(, cmd_buffer->device,
+&(VkImageViewCreateInfo) {
+.sType = 
VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
+.image = 
radv_image_to_handle(image),
+.viewType = 
VK_IMAGE_VIEW_TYPE_2D,
+.format = 
image->vk_format,
+.subresourceRange 
= {
+   .aspectMask = 
VK_IMAGE_ASPECT_COLOR_BIT,
+   .baseMipLevel = 
subresourceRange->baseMipLevel + l,
+   .levelCount = 1,
+   .baseArrayLayer 
= subresourceRange->baseArrayLayer + s,
+   .layerCount = 1
+},
+});
+
+   radv_meta_push_descriptor_set(cmd_buffer,
+ 
VK_PIPELINE_BIND_POINT_COMPUTE,
+ 

[Mesa-dev] [PATCH v2 1/7] ac: compute the size of one DCC slice on GFX8

[Samuel Pitoiset]

Addrlib doesn't provide this info. Because DCC is linear, at least
on GFX8, it's easy to compute the size of one slice.

Signed-off-by: Samuel Pitoiset 
---
 src/amd/common/ac_surface.c | 6 ++
 src/amd/common/ac_surface.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index f8b9d2b70f8..9e45bd44b72 100644
--- a/src/amd/common/ac_surface.c
+++ b/src/amd/common/ac_surface.c
@@ -302,6 +302,12 @@ static int gfx6_compute_level(ADDR_HANDLE addrlib,
surf_level->dcc_fast_clear_size = 
AddrDccOut->dccFastClearSize;
else
surf_level->dcc_fast_clear_size = 0;
+
+   /* Compute the DCC slice size because addrlib doesn't
+* provide this info. As DCC memory is linear (each
+* slice is the same size) it's easy to compute.
+*/
+   surf->dcc_slice_size = AddrDccOut->dccRamSize / 
config->info.array_size;
}
}
 
diff --git a/src/amd/common/ac_surface.h b/src/amd/common/ac_surface.h
index 31623634936..8143c9f9a0e 100644
--- a/src/amd/common/ac_surface.h
+++ b/src/amd/common/ac_surface.h
@@ -212,6 +212,7 @@ struct radeon_surf {
 
 /* DCC and HTILE are very small. */
 uint32_tdcc_size;
+uint32_tdcc_slice_size;
 uint32_tdcc_alignment;
 
 uint32_thtile_size;
-- 
2.22.0

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

[Mesa-dev] [Bug 109258] Weston drm-backend.so seems to fail with Mesa master and LIBGL_ALWAYS_SOFTWARE=1

[bugzilla-daemon]

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

--- Comment #14 from Brendan King  ---
That block of code in platform_drm.c appears to be incorrect. The ForceSoftware
flag is derived from the LIBGL_ALWAYS_SOFTWARE environment variable, but
platform_drm uses GBM, with the DRM backend, which uses the GBM_ALWAYS_SOFTWARE
environment variable to force software rendering, not LIBGL_ALWAYS_SOFTWARE. In
any case, software rendering does appear to be supported, despite what the
comment says.

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

[Mesa-dev] [Bug 111036] 5.2-rc7 19.1.1-1 repetitive error loop

[bugzilla-daemon]

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

--- Comment #4 from Stuart Naylor  ---
Apols in future I will add much more.

I saw the ToDos i the error messages so was a bit half assed as expecting you
know and are working on things.

Its RK3399 Rockpi4 running Manjaro 19.04 they are banging out updates as soon
as they are released.

Should I give Master another try with RC7 and feed back?

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

[Mesa-dev] [Bug 111036] 5.2-rc7 19.1.1-1 repetitive error loop

[bugzilla-daemon]

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

--- Comment #3 from Daniel Stone  ---
Could you please tell us which SoC you're running on? Knowing which GPU you
actually have - Panfrost supports multiple different hardware generations - is
pretty critical to finding out what's going on. Kernel version is also
critical.

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

[Mesa-dev] [Bug 111026] TODO 5.2rc6 with mesa 19.1.1 on manjaro SLAVE FAULT

[bugzilla-daemon]

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

--- Comment #2 from Stuart Naylor  ---
Yeah I have and it seems like things are better still not completely fixed.
But from first error with rc6 and rc6 it logged on and ran a firefox window.

I got a feeling of wow this feels quite snappy and quick.
On closing the window the compositor messed up the layout slightly but its
master and current so as said waiting for 5.2 release and  2019-07-09   
19.1.2 but thinking actually Panfrost is going to be quite awesome.

Many Thanks

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

[Mesa-dev] [Bug 111036] 5.2-rc7 19.1.1-1 repetitive error loop

[bugzilla-daemon]

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

--- Comment #2 from Stuart Naylor  ---
I am not sure with rc6 I would get a greeter but logon would throw out back to
greeter with the error in #111026

rc7 no greeter and white screen that is continually flooding that error
message.

Just thought I would post but presuming its all todo's for 5.2 release and
2019-07-09 19.1.2 and will stop posting :)

Thanks

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

[Mesa-dev] [Bug 111024] Commit 69f9fbab8a92a2bb797723f28fe8dad5cd8c8a64 breaks building mesa on Arch Linux.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #4 from Michel Dänzer  ---
FWIW, this was triggered by clang SVN r364424, not directly related to that
Mesa commit. Anyway, fixed now with:

https://gitlab.freedesktop.org/mesa/mesa/commit/3fd21a6b776e0f874e0e14d9943ac2b06bcc4aad

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

[Mesa-dev] [Bug 111036] 5.2-rc7 19.1.1-1 repetitive error loop

[bugzilla-daemon]

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

--- Comment #1 from Daniel Stone  ---
Same comment as #111026.

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

[Mesa-dev] [Bug 111026] TODO 5.2rc6 with mesa 19.1.1 on manjaro SLAVE FAULT

[bugzilla-daemon]

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

--- Comment #1 from Daniel Stone  ---
Can you please include the exact system you're running on (e.g. which GPU?),
which kernel version, and the full dmesg output?

You may also be better off trying Mesa master.

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

[Mesa-dev] [Bug 111036] 5.2-rc7 19.1.1-1 repetitive error loop

[bugzilla-daemon]

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

Bug ID: 111036
   Summary: 5.2-rc7 19.1.1-1 repetitive error loop
   Product: Mesa
   Version: 19.1
  Hardware: ARM
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/Panfrost
  Assignee: mesa-dev@lists.freedesktop.org
  Reporter: stuartiannay...@outlook.com

[  177.949444] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5480, tail=0x18ca5480
[  177.950479] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5480, tail=0x18ca5480, sched_job=ef248ea9
[  177.965989] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  177.967067] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=ae32c035
[  178.026538] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  178.027485] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=140ad16f
[  178.050864] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  178.051793] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=4d000b68
[  178.059179] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  178.060121] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=ae32c035
[  178.075976] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  178.076978] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=160abd48
[  178.092064] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  178.092993] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=28327f6f
[  178.108758] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  178.109683] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=3a76db5a
[  178.125755] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  178.126749] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=b12fbc76
[  178.529955] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  178.530969] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=3a76db5a
[  179.019580] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  179.052410] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  179.053324] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=a8dd3c68
[  179.578528] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  179.579477] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=eb555323
[  180.106581] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  180.107569] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=bd3de6f0
[  180.630235] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  180.631235] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=ae32c035
[  181.155112] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  181.156111] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=160abd48
[  181.679843] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  181.680824] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x188a5080, tail=0x188a5080, sched_job=777eb8b1
[  182.186598] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x18ca5080, tail=0x18ca5080
[  182.187584] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,
head=0x18ca5080, tail=0x18ca5080, sched_job=67ab9506
[  182.685901] panfrost ff9a.gpu: js fault, js=1,
status=DATA_INVALID_FAULT, head=0x188a5080, tail=0x188a5080
[  182.686880] panfrost ff9a.gpu: gpu sched timeout, js=1, status=0x58,

[Mesa-dev] [Bug 111023] build regression: ERROR: ['/usr/bin/python3']> is not a valid python

[bugzilla-daemon]

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

Sergii Romantsov  changed:

   What|Removed |Added

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

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

[Mesa-dev] [Bug 111023] build regression: ERROR: ['/usr/bin/python3']> is not a valid python

[bugzilla-daemon]

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

--- Comment #2 from Fabio Pedretti  ---
Indeed, with it it compiles, thanks.

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

[Mesa-dev] [Bug 111023] build regression: ERROR: ['/usr/bin/python3']> is not a valid python

[bugzilla-daemon]

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

--- Comment #1 from Sergii Romantsov  ---
Hello, Fabia.
Seems its meson-issue: https://github.com/mesonbuild/meson/issues/5422
Please, try to install package python3-distutils (at least on Ubuntu)

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

Re: [Mesa-dev] [PATCH 2/3] radv: merge radv_dcc_clear_level() into radv_clear_dcc()

[Bas Nieuwenhuizen]

On Mon, Jul 1, 2019 at 2:15 PM Samuel Pitoiset
 wrote:
>
>
> On 7/1/19 2:13 PM, Bas Nieuwenhuizen wrote:
> > On Thu, Jun 27, 2019 at 3:02 PM Samuel Pitoiset
> >  wrote:
> >> This will help for clearing DCC arrays because we need to know
> >> the subresource range.
> > How will it help? I don't think we use it in the next commit in the series?
> It will help for arrays, not levels. I can add it into a different
> series if you prefer.

Please do. IMO it makes the code messier, so I'd be great if we keep
it in the same series as the user of the change.
> >> Signed-off-by: Samuel Pitoiset 
> >> ---
> >>   src/amd/vulkan/radv_meta_clear.c | 52 ++--
> >>   1 file changed, 22 insertions(+), 30 deletions(-)
> >>
> >> diff --git a/src/amd/vulkan/radv_meta_clear.c 
> >> b/src/amd/vulkan/radv_meta_clear.c
> >> index b0b17f4f7b3..e5181daf0f2 100644
> >> --- a/src/amd/vulkan/radv_meta_clear.c
> >> +++ b/src/amd/vulkan/radv_meta_clear.c
> >> @@ -1367,34 +1367,6 @@ radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
> >>  return radv_fill_buffer(cmd_buffer, image->bo, offset, size, 
> >> value);
> >>   }
> >>
> >> -static uint32_t
> >> -radv_dcc_clear_level(struct radv_cmd_buffer *cmd_buffer,
> >> -const struct radv_image *image,
> >> -uint32_t level, uint32_t value)
> >> -{
> >> -   uint64_t offset = image->offset + image->dcc_offset;
> >> -   uint32_t size;
> >> -
> >> -   if (cmd_buffer->device->physical_device->rad_info.chip_class >= 
> >> GFX9) {
> >> -   /* Mipmap levels aren't implemented. */
> >> -   assert(level == 0);
> >> -   size = image->planes[0].surface.dcc_size;
> >> -   } else {
> >> -   const struct legacy_surf_level *surf_level =
> >> -   >planes[0].surface.u.legacy.level[level];
> >> -
> >> -   /* If dcc_fast_clear_size is 0 (which might happens for
> >> -* mipmaps) the fill buffer operation below is a no-op. 
> >> This
> >> -* can only happen during initialization as the fast clear 
> >> path
> >> -* fallbacks to slow clears if one level can't be fast 
> >> cleared.
> >> -*/
> >> -   offset += surf_level->dcc_offset;
> >> -   size = surf_level->dcc_fast_clear_size;
> >> -   }
> >> -
> >> -   return radv_fill_buffer(cmd_buffer, image->bo, offset, size, 
> >> value);
> >> -}
> >> -
> >>   uint32_t
> >>   radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
> >> struct radv_image *image,
> >> @@ -1407,10 +1379,30 @@ radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
> >>  radv_update_dcc_metadata(cmd_buffer, image, range, true);
> >>
> >>  for (uint32_t l = 0; l < level_count; l++) {
> >> +   uint64_t offset = image->offset + image->dcc_offset;
> >>  uint32_t level = range->baseMipLevel + l;
> >> +   uint64_t size;
> >> +
> >> +   if 
> >> (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
> >> +   /* Mipmap levels aren't implemented. */
> >> +   assert(level == 0);
> >> +   size = image->planes[0].surface.dcc_size;
> >> +   } else {
> >> +   const struct legacy_surf_level *surf_level =
> >> +   
> >> >planes[0].surface.u.legacy.level[level];
> >> +
> >> +   /* If dcc_fast_clear_size is 0 (which might 
> >> happens for
> >> +* mipmaps) the fill buffer operation below is a 
> >> no-op.
> >> +* This can only happen during initialization as 
> >> the
> >> +* fast clear path fallbacks to slow clears if one
> >> +* level can't be fast cleared.
> >> +*/
> >> +   offset += surf_level->dcc_offset;
> >> +   size = surf_level->dcc_fast_clear_size;
> >> +   }
> >>
> >> -   flush_bits |= radv_dcc_clear_level(cmd_buffer, image,
> >> -  level, value);
> >> +   flush_bits |= radv_fill_buffer(cmd_buffer, image->bo, 
> >> offset,
> >> +  size, value);
> >>  }
> >>
> >>  return flush_bits;
> >> --
> >> 2.22.0
> >>
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] radv: merge radv_dcc_clear_level() into radv_clear_dcc()

[Samuel Pitoiset]

On 7/1/19 2:13 PM, Bas Nieuwenhuizen wrote:

On Thu, Jun 27, 2019 at 3:02 PM Samuel Pitoiset
 wrote:

This will help for clearing DCC arrays because we need to know
the subresource range.

How will it help? I don't think we use it in the next commit in the series?
It will help for arrays, not levels. I can add it into a different 
series if you prefer.

Signed-off-by: Samuel Pitoiset 
---
  src/amd/vulkan/radv_meta_clear.c | 52 ++--
  1 file changed, 22 insertions(+), 30 deletions(-)

diff --git a/src/amd/vulkan/radv_meta_clear.c b/src/amd/vulkan/radv_meta_clear.c
index b0b17f4f7b3..e5181daf0f2 100644
--- a/src/amd/vulkan/radv_meta_clear.c
+++ b/src/amd/vulkan/radv_meta_clear.c
@@ -1367,34 +1367,6 @@ radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
 return radv_fill_buffer(cmd_buffer, image->bo, offset, size, value);
  }

-static uint32_t
-radv_dcc_clear_level(struct radv_cmd_buffer *cmd_buffer,
-const struct radv_image *image,
-uint32_t level, uint32_t value)
-{
-   uint64_t offset = image->offset + image->dcc_offset;
-   uint32_t size;
-
-   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) {
-   /* Mipmap levels aren't implemented. */
-   assert(level == 0);
-   size = image->planes[0].surface.dcc_size;
-   } else {
-   const struct legacy_surf_level *surf_level =
-   >planes[0].surface.u.legacy.level[level];
-
-   /* If dcc_fast_clear_size is 0 (which might happens for
-* mipmaps) the fill buffer operation below is a no-op. This
-* can only happen during initialization as the fast clear path
-* fallbacks to slow clears if one level can't be fast cleared.
-*/
-   offset += surf_level->dcc_offset;
-   size = surf_level->dcc_fast_clear_size;
-   }
-
-   return radv_fill_buffer(cmd_buffer, image->bo, offset, size, value);
-}
-
  uint32_t
  radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
struct radv_image *image,
@@ -1407,10 +1379,30 @@ radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
 radv_update_dcc_metadata(cmd_buffer, image, range, true);

 for (uint32_t l = 0; l < level_count; l++) {
+   uint64_t offset = image->offset + image->dcc_offset;
 uint32_t level = range->baseMipLevel + l;
+   uint64_t size;
+
+   if (cmd_buffer->device->physical_device->rad_info.chip_class >= 
GFX9) {
+   /* Mipmap levels aren't implemented. */
+   assert(level == 0);
+   size = image->planes[0].surface.dcc_size;
+   } else {
+   const struct legacy_surf_level *surf_level =
+   >planes[0].surface.u.legacy.level[level];
+
+   /* If dcc_fast_clear_size is 0 (which might happens for
+* mipmaps) the fill buffer operation below is a no-op.
+* This can only happen during initialization as the
+* fast clear path fallbacks to slow clears if one
+* level can't be fast cleared.
+*/
+   offset += surf_level->dcc_offset;
+   size = surf_level->dcc_fast_clear_size;
+   }

-   flush_bits |= radv_dcc_clear_level(cmd_buffer, image,
-  level, value);
+   flush_bits |= radv_fill_buffer(cmd_buffer, image->bo, offset,
+  size, value);
 }

 return flush_bits;
--
2.22.0

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

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

Re: [Mesa-dev] [PATCH 2/3] radv: merge radv_dcc_clear_level() into radv_clear_dcc()

[Bas Nieuwenhuizen]

On Thu, Jun 27, 2019 at 3:02 PM Samuel Pitoiset
 wrote:
>
> This will help for clearing DCC arrays because we need to know
> the subresource range.

How will it help? I don't think we use it in the next commit in the series?
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_clear.c | 52 ++--
>  1 file changed, 22 insertions(+), 30 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_meta_clear.c 
> b/src/amd/vulkan/radv_meta_clear.c
> index b0b17f4f7b3..e5181daf0f2 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -1367,34 +1367,6 @@ radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
> return radv_fill_buffer(cmd_buffer, image->bo, offset, size, value);
>  }
>
> -static uint32_t
> -radv_dcc_clear_level(struct radv_cmd_buffer *cmd_buffer,
> -const struct radv_image *image,
> -uint32_t level, uint32_t value)
> -{
> -   uint64_t offset = image->offset + image->dcc_offset;
> -   uint32_t size;
> -
> -   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) 
> {
> -   /* Mipmap levels aren't implemented. */
> -   assert(level == 0);
> -   size = image->planes[0].surface.dcc_size;
> -   } else {
> -   const struct legacy_surf_level *surf_level =
> -   >planes[0].surface.u.legacy.level[level];
> -
> -   /* If dcc_fast_clear_size is 0 (which might happens for
> -* mipmaps) the fill buffer operation below is a no-op. This
> -* can only happen during initialization as the fast clear 
> path
> -* fallbacks to slow clears if one level can't be fast 
> cleared.
> -*/
> -   offset += surf_level->dcc_offset;
> -   size = surf_level->dcc_fast_clear_size;
> -   }
> -
> -   return radv_fill_buffer(cmd_buffer, image->bo, offset, size, value);
> -}
> -
>  uint32_t
>  radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
>struct radv_image *image,
> @@ -1407,10 +1379,30 @@ radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
> radv_update_dcc_metadata(cmd_buffer, image, range, true);
>
> for (uint32_t l = 0; l < level_count; l++) {
> +   uint64_t offset = image->offset + image->dcc_offset;
> uint32_t level = range->baseMipLevel + l;
> +   uint64_t size;
> +
> +   if (cmd_buffer->device->physical_device->rad_info.chip_class 
> >= GFX9) {
> +   /* Mipmap levels aren't implemented. */
> +   assert(level == 0);
> +   size = image->planes[0].surface.dcc_size;
> +   } else {
> +   const struct legacy_surf_level *surf_level =
> +   
> >planes[0].surface.u.legacy.level[level];
> +
> +   /* If dcc_fast_clear_size is 0 (which might happens 
> for
> +* mipmaps) the fill buffer operation below is a 
> no-op.
> +* This can only happen during initialization as the
> +* fast clear path fallbacks to slow clears if one
> +* level can't be fast cleared.
> +*/
> +   offset += surf_level->dcc_offset;
> +   size = surf_level->dcc_fast_clear_size;
> +   }
>
> -   flush_bits |= radv_dcc_clear_level(cmd_buffer, image,
> -  level, value);
> +   flush_bits |= radv_fill_buffer(cmd_buffer, image->bo, offset,
> +  size, value);
> }
>
> return flush_bits;
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] radv: fix decompressing DCC levels with compute

[Bas Nieuwenhuizen]

r-b

On Thu, Jun 27, 2019 at 3:02 PM Samuel Pitoiset
 wrote:
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_meta_fast_clear.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/amd/vulkan/radv_meta_fast_clear.c 
> b/src/amd/vulkan/radv_meta_fast_clear.c
> index f18f7637593..a642d6243d4 100644
> --- a/src/amd/vulkan/radv_meta_fast_clear.c
> +++ b/src/amd/vulkan/radv_meta_fast_clear.c
> @@ -807,11 +807,17 @@ radv_decompress_dcc_compute(struct radv_cmd_buffer 
> *cmd_buffer,
>  
> device->meta_state.fast_clear_flush.dcc_decompress_compute_pipeline);
>
> for (uint32_t l = 0; l < radv_get_levelCount(image, 
> subresourceRange); l++) {
> +   uint32_t width, height;
>
> /* Do not decompress levels without DCC. */
> if (!radv_dcc_enabled(image, subresourceRange->baseMipLevel + 
> l))
> continue;
>
> +   width = radv_minify(image->info.width,
> +   subresourceRange->baseMipLevel + l);
> +   height = radv_minify(image->info.height,
> +   subresourceRange->baseMipLevel + l);
> +
> radv_image_view_init(, cmd_buffer->device,
>  &(VkImageViewCreateInfo) {
>  .sType = 
> VK_STRUCTURE_TYPE_IMAGE_VIEW_CREATE_INFO,
> @@ -863,7 +869,7 @@ radv_decompress_dcc_compute(struct radv_cmd_buffer 
> *cmd_buffer,
>   }
>   });
>
> -   radv_unaligned_dispatch(cmd_buffer, image->info.width, 
> image->info.height, 1);
> +   radv_unaligned_dispatch(cmd_buffer, width, height, 1);
> }
>
> /* Mark this image as actually being decompressed. */
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] radv: make sure to mark the image as compressed when clearing DCC levels

[Bas Nieuwenhuizen]

r-b

On Thu, Jun 27, 2019 at 3:02 PM Samuel Pitoiset
 wrote:
>
> Found while working on DCC for arrays.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_cmd_buffer.c | 22 ++
>  src/amd/vulkan/radv_meta.h   |  3 ---
>  src/amd/vulkan/radv_meta_clear.c | 10 ++
>  3 files changed, 8 insertions(+), 27 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_cmd_buffer.c 
> b/src/amd/vulkan/radv_cmd_buffer.c
> index 8ffd3989634..362fcc343c0 100644
> --- a/src/amd/vulkan/radv_cmd_buffer.c
> +++ b/src/amd/vulkan/radv_cmd_buffer.c
> @@ -4936,32 +4936,14 @@ void radv_initialize_dcc(struct radv_cmd_buffer 
> *cmd_buffer,
>  const VkImageSubresourceRange *range, uint32_t value)
>  {
> struct radv_cmd_state *state = _buffer->state;
> -   uint32_t level_count = radv_get_levelCount(image, range);
> unsigned size = 0;
>
> state->flush_bits |= RADV_CMD_FLAG_FLUSH_AND_INV_CB |
>  RADV_CMD_FLAG_FLUSH_AND_INV_CB_META;
>
> -   if (cmd_buffer->device->physical_device->rad_info.chip_class >= GFX9) 
> {
> -   /* Mipmap level aren't implemented. */
> -   assert(level_count == 1);
> -   state->flush_bits |= radv_clear_dcc(cmd_buffer, image,
> -   range, value);
> -   } else {
> -   /* Initialize the mipmap levels with DCC first. */
> -   for (unsigned l = 0; l < level_count; l++) {
> -   uint32_t level = range->baseMipLevel + l;
> -   struct legacy_surf_level *surf_level =
> -   
> >planes[0].surface.u.legacy.level[level];
> -
> -   if (!surf_level->dcc_fast_clear_size)
> -   break;
> -
> -   state->flush_bits |=
> -   radv_dcc_clear_level(cmd_buffer, image,
> -level, value);
> -   }
> +   state->flush_bits |= radv_clear_dcc(cmd_buffer, image, range, value);
>
> +   if (cmd_buffer->device->physical_device->rad_info.chip_class == GFX8) 
> {
> /* When DCC is enabled with mipmaps, some levels might not
>  * support fast clears and we have to initialize them as 
> "fully
>  * expanded".
> diff --git a/src/amd/vulkan/radv_meta.h b/src/amd/vulkan/radv_meta.h
> index c3d37bb07d2..e916b788d0e 100644
> --- a/src/amd/vulkan/radv_meta.h
> +++ b/src/amd/vulkan/radv_meta.h
> @@ -220,9 +220,6 @@ uint32_t radv_clear_fmask(struct radv_cmd_buffer 
> *cmd_buffer,
>  uint32_t radv_clear_dcc(struct radv_cmd_buffer *cmd_buffer,
> struct radv_image *image,
> const VkImageSubresourceRange *range, uint32_t value);
> -uint32_t radv_dcc_clear_level(struct radv_cmd_buffer *cmd_buffer,
> - const struct radv_image *image,
> - uint32_t level, uint32_t value);
>  uint32_t radv_clear_htile(struct radv_cmd_buffer *cmd_buffer,
>   struct radv_image *image,
>   const VkImageSubresourceRange *range, uint32_t 
> value);
> diff --git a/src/amd/vulkan/radv_meta_clear.c 
> b/src/amd/vulkan/radv_meta_clear.c
> index 091b73841f8..b0b17f4f7b3 100644
> --- a/src/amd/vulkan/radv_meta_clear.c
> +++ b/src/amd/vulkan/radv_meta_clear.c
> @@ -1367,7 +1367,7 @@ radv_clear_fmask(struct radv_cmd_buffer *cmd_buffer,
> return radv_fill_buffer(cmd_buffer, image->bo, offset, size, value);
>  }
>
> -uint32_t
> +static uint32_t
>  radv_dcc_clear_level(struct radv_cmd_buffer *cmd_buffer,
>  const struct radv_image *image,
>  uint32_t level, uint32_t value)
> @@ -1383,9 +1383,11 @@ radv_dcc_clear_level(struct radv_cmd_buffer 
> *cmd_buffer,
> const struct legacy_surf_level *surf_level =
> >planes[0].surface.u.legacy.level[level];
>
> -   /* If this is 0, fast clear isn't possible. */
> -   assert(surf_level->dcc_fast_clear_size);
> -
> +   /* If dcc_fast_clear_size is 0 (which might happens for
> +* mipmaps) the fill buffer operation below is a no-op. This
> +* can only happen during initialization as the fast clear 
> path
> +* fallbacks to slow clears if one level can't be fast 
> cleared.
> +*/
> offset += surf_level->dcc_offset;
> size = surf_level->dcc_fast_clear_size;
> }
> --
> 2.22.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH 4/4] radv: rework how the number of VGPRs is computed

[Bas Nieuwenhuizen]

r-b for the series

On Wed, Jun 26, 2019 at 3:07 PM Samuel Pitoiset
 wrote:
>
> Just a cleanup, it shouldn't change anything.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c | 22 
>  src/amd/vulkan/radv_shader.c  | 34 ---
>  src/amd/vulkan/radv_shader.h  |  1 -
>  3 files changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index d6f286fe4ec..211fc4aec47 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -2191,14 +2191,6 @@ handle_vs_input_decl(struct radv_shader_context *ctx,
> buffer_index = 
> LLVMBuildUDiv(ctx->ac.builder, buffer_index,
>  
> LLVMConstInt(ctx->ac.i32, divisor, 0), "");
> }
> -
> -   if (ctx->options->key.vs.as_ls) {
> -   ctx->shader_info->vs.vgpr_comp_cnt =
> -   MAX2(2, 
> ctx->shader_info->vs.vgpr_comp_cnt);
> -   } else {
> -   ctx->shader_info->vs.vgpr_comp_cnt =
> -   MAX2(1, 
> ctx->shader_info->vs.vgpr_comp_cnt);
> -   }
> } else {
> buffer_index = ctx->ac.i32_0;
> }
> @@ -3044,8 +3036,6 @@ handle_vs_outputs_post(struct radv_shader_context *ctx,
> LLVMValueRef values[4];
>
> values[0] = ctx->vs_prim_id;
> -   ctx->shader_info->vs.vgpr_comp_cnt = MAX2(2,
> - 
> ctx->shader_info->vs.vgpr_comp_cnt);
> for (unsigned j = 1; j < 4; j++)
> values[j] = ctx->ac.f32_0;
>
> @@ -3751,15 +3741,6 @@ LLVMModuleRef ac_translate_nir_to_llvm(struct 
> ac_llvm_compiler *ac_llvm,
> ctx.tcs_vertices_per_patch = 
> shaders[i]->info.tess.tcs_vertices_out;
> ctx.tcs_num_patches = 
> ctx.options->key.tes.num_patches;
> } else if (shaders[i]->info.stage == MESA_SHADER_VERTEX) {
> -   if (shader_info->info.vs.needs_instance_id) {
> -   if (ctx.options->key.vs.as_ls) {
> -   ctx.shader_info->vs.vgpr_comp_cnt =
> -   MAX2(2, 
> ctx.shader_info->vs.vgpr_comp_cnt);
> -   } else {
> -   ctx.shader_info->vs.vgpr_comp_cnt =
> -   MAX2(1, 
> ctx.shader_info->vs.vgpr_comp_cnt);
> -   }
> -   }
> ctx.abi.load_base_vertex = radv_load_base_vertex;
> } else if (shaders[i]->info.stage == MESA_SHADER_FRAGMENT) {
> shader_info->fs.can_discard = 
> shaders[i]->info.fs.uses_discard;
> @@ -3994,9 +3975,6 @@ ac_fill_shader_info(struct radv_shader_variant_info 
> *shader_info, struct nir_sha
>  case MESA_SHADER_VERTEX:
>  shader_info->vs.as_es = options->key.vs.as_es;
>  shader_info->vs.as_ls = options->key.vs.as_ls;
> -/* in LS mode we need at least 1, invocation id needs 2, 
> handled elsewhere */
> -if (options->key.vs.as_ls)
> -shader_info->vs.vgpr_comp_cnt = MAX2(1, 
> shader_info->vs.vgpr_comp_cnt);
>  break;
>  default:
>  break;
> diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
> index 5205dc1bfc5..0ec0d67e3b6 100644
> --- a/src/amd/vulkan/radv_shader.c
> +++ b/src/amd/vulkan/radv_shader.c
> @@ -507,13 +507,40 @@ radv_fill_shader_variant(struct radv_device *device,
> break;
> case MESA_SHADER_TESS_CTRL:
> if (device->physical_device->rad_info.chip_class >= GFX9) {
> -   vgpr_comp_cnt = variant->info.vs.vgpr_comp_cnt;
> +   /* We need at least 2 components for LS.
> +* VGPR0-3: (VertexID, RelAutoindex, InstanceID / 
> StepRate0, InstanceID).
> +* StepRate0 is set to 1. so that VGPR3 doesn't have 
> to be loaded.
> +*/
> +   vgpr_comp_cnt = info->vs.needs_instance_id ? 2 : 1;
> } else {
> variant->rsrc2 |= S_00B12C_OC_LDS_EN(1);
> }
> break;
> case MESA_SHADER_VERTEX:
> -   vgpr_comp_cnt = variant->info.vs.vgpr_comp_cnt;
> +   if (variant->info.vs.as_ls) {
> +   

Re: [Mesa-dev] boolean usage in gallium

[Jose Fonseca]

Yep.  It's better to just use C99 bool everywhere.

Jose

On 30/06/2019 06:00, Marek Olšák wrote:
> boolean predates c99 support in MSVC. I think there is no reason for 
> boolean in gallium now.
> 
> Marek
> 
> On Sat., Jun. 29, 2019, 00:09 Ilia Mirkin,  > wrote:
> 
> Ken pointed out on IRC today that there was still a lot of "boolean"
> (vs bool/_Bool) usage in gallium. In fact, many interfaces are
> specified with boolean.
> 
> I had it in my mind that I had at some point removed most boolean
> usage, but that is just not the case - first of all, the interfaces
> remain with it, and I could find no evidence of such a commit. I must
> have imagined it.
> 
> Is there any reason to keep boolean around? I know conversions must be
> done carefully (since incorrect-but-working usage would not currently
> be caught by the compiler), but are there any practical reasons to
> avoid C99 _Bool in gallium code?
> 
> If not, I may begin converting things over.
> 
> Cheers,
> 
>    -ilia
> ___
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7C513e439c4dbe42d80f8808d6fd17f8f1%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636974676763494464sdata=PudvVZvCoB3oP58vHYwF%2Bq3y14psK3z%2F7PUfayMpidI%3Dreserved=0
> 

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

Re: [Mesa-dev] [PATCH] panfrost: Rewrite u-interleaving code

[Andreas Baierl]

Am 28.06.2019 um 22:56 schrieb Vasily Khoruzhick:

On Tue, Jun 25, 2019 at 1:26 PM Alyssa Rosenzweig
 wrote:

Rather than using a magic lookup table with no explanations, let's add
liberal comments to the code to explain what this tiling scheme is and
how to encode/decode it efficiently.

It's not so mysterious after all -- just reordering bits with some XORs
thrown in.

v2: Correct copyright identifier. Fix spelling error. Switch space_4 to
a LUT. Fix comment typo. Use LUT instead of space_x tricks. Fallback on
generic rather than split up unaligned writes.

Signed-off-by: Alyssa Rosenzweig 
Cc: Vasily Khoruzhick 

LGTM however I haven't tested it.

+CC: Erico and Andreas

Erico, Andreas could you test this change? I'm away from my board till July 2nd.

Reviewed-by: Vasily Khoruzhick 


I just ran some piglit tests (http://imkreisrum.de/piglit/pan_tiling/) 
and this patch series (v3) doesn't seem to cause any regressions for 
lima with piglit.


So, if this is enough for a tested-by, it's Tested-by: Andreas Baierl 





---
  src/panfrost/shared/pan_tiling.c | 290 ---
  1 file changed, 189 insertions(+), 101 deletions(-)

diff --git a/src/panfrost/shared/pan_tiling.c b/src/panfrost/shared/pan_tiling.c
index 413cd89420b..c8b09887037 100644
--- a/src/panfrost/shared/pan_tiling.c
+++ b/src/panfrost/shared/pan_tiling.c
@@ -2,6 +2,7 @@
   * Copyright (c) 2011-2013 Luc Verhaegen 
   * Copyright (c) 2018 Alyssa Rosenzweig 
   * Copyright (c) 2018 Vasily Khoruzhick 
+ * Copyright (c) 2019 Collabora, Ltd.
   *
   * Permission is hereby granted, free of charge, to any person obtaining a
   * copy of this software and associated documentation files (the "Software"),
@@ -24,129 +25,212 @@
   *
   */

+#include 
  #include "pan_tiling.h"

-uint32_t space_filler[16][16] = {
-   { 0,   1,   4,   5,   16,  17,  20,  21,  64,  65,  68,  69,  80,  81,  84, 
 85, },
-   { 3,   2,   7,   6,   19,  18,  23,  22,  67,  66,  71,  70,  83,  82,  87, 
 86, },
-   { 12,  13,  8,   9,   28,  29,  24,  25,  76,  77,  72,  73,  92,  93,  88, 
 89, },
-   { 15,  14,  11,  10,  31,  30,  27,  26,  79,  78,  75,  74,  95,  94,  91, 
 90, },
-   { 48,  49,  52,  53,  32,  33,  36,  37,  112, 113, 116, 117, 96,  97,  
100, 101, },
-   { 51,  50,  55,  54,  35,  34,  39,  38,  115, 114, 119, 118, 99,  98,  
103, 102, },
-   { 60,  61,  56,  57,  44,  45,  40,  41,  124, 125, 120, 121, 108, 109, 
104, 105, },
-   { 63,  62,  59,  58,  47,  46,  43,  42,  127, 126, 123, 122, 111, 110, 
107, 106, },
-   { 192, 193, 196, 197, 208, 209, 212, 213, 128, 129, 132, 133, 144, 145, 
148, 149, },
-   { 195, 194, 199, 198, 211, 210, 215, 214, 131, 130, 135, 134, 147, 146, 
151, 150, },
-   { 204, 205, 200, 201, 220, 221, 216, 217, 140, 141, 136, 137, 156, 157, 
152, 153, },
-   { 207, 206, 203, 202, 223, 222, 219, 218, 143, 142, 139, 138, 159, 158, 
155, 154, },
-   { 240, 241, 244, 245, 224, 225, 228, 229, 176, 177, 180, 181, 160, 161, 
164, 165, },
-   { 243, 242, 247, 246, 227, 226, 231, 230, 179, 178, 183, 182, 163, 162, 
167, 166, },
-   { 252, 253, 248, 249, 236, 237, 232, 233, 188, 189, 184, 185, 172, 173, 
168, 169, },
-   { 255, 254, 251, 250, 239, 238, 235, 234, 191, 190, 187, 186, 175, 174, 
171, 170, },
+/* This file implements software encode/decode of the tiling format used for
+ * textures and framebuffers primarily on Utgard GPUs. Names for this format
+ * include "Utgard-style tiling", "(Mali) swizzled textures", and
+ * "U-interleaved" (the former two names being used in the community
+ * Lima/Panfrost drivers; the latter name used internally at Arm).
+ * Conceptually, like any tiling scheme, the pixel reordering attempts to 2D
+ * spatial locality, to improve cache locality in both horizontal and vertical
+ * directions.
+ *
+ * This format is tiled: first, the image dimensions must be aligned to 16
+ * pixels in each axis. Once aligned, the image is divided into 16x16 tiles.
+ * This size harmonizes with other properties of the GPU; on Midgard,
+ * framebuffer tiles are logically 16x16 (this is the tile size used in
+ * Transaction Elimination and the minimum tile size used in Hierarchical
+ * Tiling). Conversely, for a standard 4 bytes-per-pixel format (like
+ * RGBA), 16 pixels * 4 bytes/pixel = 64 bytes, equal to the cache line
+ * size.
+ *
+ * Within each 16x16 block, the bits are reordered according to this pattern:
+ *
+ * | y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^ x0) |
+ *
+ * Basically, interleaving the X and Y bits, with XORs thrown in for every
+ * adjacent bit pair.
+ *
+ * This is cheap to implement both encode/decode in both hardware and software.
+ * In hardware, lines are simply rerouted to reorder and some XOR gates are
+ * thrown in. Software has to be a bit more clever.
+ *
+ * In software, the trick is to divide the pattern into two lines:
+ *
+ *| y3 | y3 | y2 | y2 | y1 | y1 | y0 | y0 |
+ *  ^ |  0 | x3 |  0 | x2 |  0 | x1 |  0 | x0 |
+ *
+ * That is, 

Re: [Mesa-dev] [PATCH] panfrost: Rewrite u-interleaving code

[Vasily Khoruzhick]

On Tue, Jun 25, 2019 at 1:26 PM Alyssa Rosenzweig
 wrote:
>
> Rather than using a magic lookup table with no explanations, let's add
> liberal comments to the code to explain what this tiling scheme is and
> how to encode/decode it efficiently.
>
> It's not so mysterious after all -- just reordering bits with some XORs
> thrown in.
>
> v2: Correct copyright identifier. Fix spelling error. Switch space_4 to
> a LUT. Fix comment typo. Use LUT instead of space_x tricks. Fallback on
> generic rather than split up unaligned writes.
>
> Signed-off-by: Alyssa Rosenzweig 
> Cc: Vasily Khoruzhick 

LGTM however I haven't tested it.

+CC: Erico and Andreas

Erico, Andreas could you test this change? I'm away from my board till July 2nd.

Reviewed-by: Vasily Khoruzhick 


> ---
>  src/panfrost/shared/pan_tiling.c | 290 ---
>  1 file changed, 189 insertions(+), 101 deletions(-)
>
> diff --git a/src/panfrost/shared/pan_tiling.c 
> b/src/panfrost/shared/pan_tiling.c
> index 413cd89420b..c8b09887037 100644
> --- a/src/panfrost/shared/pan_tiling.c
> +++ b/src/panfrost/shared/pan_tiling.c
> @@ -2,6 +2,7 @@
>   * Copyright (c) 2011-2013 Luc Verhaegen 
>   * Copyright (c) 2018 Alyssa Rosenzweig 
>   * Copyright (c) 2018 Vasily Khoruzhick 
> + * Copyright (c) 2019 Collabora, Ltd.
>   *
>   * Permission is hereby granted, free of charge, to any person obtaining a
>   * copy of this software and associated documentation files (the "Software"),
> @@ -24,129 +25,212 @@
>   *
>   */
>
> +#include 
>  #include "pan_tiling.h"
>
> -uint32_t space_filler[16][16] = {
> -   { 0,   1,   4,   5,   16,  17,  20,  21,  64,  65,  68,  69,  80,  81,  
> 84,  85, },
> -   { 3,   2,   7,   6,   19,  18,  23,  22,  67,  66,  71,  70,  83,  82,  
> 87,  86, },
> -   { 12,  13,  8,   9,   28,  29,  24,  25,  76,  77,  72,  73,  92,  93,  
> 88,  89, },
> -   { 15,  14,  11,  10,  31,  30,  27,  26,  79,  78,  75,  74,  95,  94,  
> 91,  90, },
> -   { 48,  49,  52,  53,  32,  33,  36,  37,  112, 113, 116, 117, 96,  97,  
> 100, 101, },
> -   { 51,  50,  55,  54,  35,  34,  39,  38,  115, 114, 119, 118, 99,  98,  
> 103, 102, },
> -   { 60,  61,  56,  57,  44,  45,  40,  41,  124, 125, 120, 121, 108, 109, 
> 104, 105, },
> -   { 63,  62,  59,  58,  47,  46,  43,  42,  127, 126, 123, 122, 111, 110, 
> 107, 106, },
> -   { 192, 193, 196, 197, 208, 209, 212, 213, 128, 129, 132, 133, 144, 145, 
> 148, 149, },
> -   { 195, 194, 199, 198, 211, 210, 215, 214, 131, 130, 135, 134, 147, 146, 
> 151, 150, },
> -   { 204, 205, 200, 201, 220, 221, 216, 217, 140, 141, 136, 137, 156, 157, 
> 152, 153, },
> -   { 207, 206, 203, 202, 223, 222, 219, 218, 143, 142, 139, 138, 159, 158, 
> 155, 154, },
> -   { 240, 241, 244, 245, 224, 225, 228, 229, 176, 177, 180, 181, 160, 161, 
> 164, 165, },
> -   { 243, 242, 247, 246, 227, 226, 231, 230, 179, 178, 183, 182, 163, 162, 
> 167, 166, },
> -   { 252, 253, 248, 249, 236, 237, 232, 233, 188, 189, 184, 185, 172, 173, 
> 168, 169, },
> -   { 255, 254, 251, 250, 239, 238, 235, 234, 191, 190, 187, 186, 175, 174, 
> 171, 170, },
> +/* This file implements software encode/decode of the tiling format used for
> + * textures and framebuffers primarily on Utgard GPUs. Names for this format
> + * include "Utgard-style tiling", "(Mali) swizzled textures", and
> + * "U-interleaved" (the former two names being used in the community
> + * Lima/Panfrost drivers; the latter name used internally at Arm).
> + * Conceptually, like any tiling scheme, the pixel reordering attempts to 2D
> + * spatial locality, to improve cache locality in both horizontal and 
> vertical
> + * directions.
> + *
> + * This format is tiled: first, the image dimensions must be aligned to 16
> + * pixels in each axis. Once aligned, the image is divided into 16x16 tiles.
> + * This size harmonizes with other properties of the GPU; on Midgard,
> + * framebuffer tiles are logically 16x16 (this is the tile size used in
> + * Transaction Elimination and the minimum tile size used in Hierarchical
> + * Tiling). Conversely, for a standard 4 bytes-per-pixel format (like
> + * RGBA), 16 pixels * 4 bytes/pixel = 64 bytes, equal to the cache line
> + * size.
> + *
> + * Within each 16x16 block, the bits are reordered according to this pattern:
> + *
> + * | y3 | (x3 ^ y3) | y2 | (y2 ^ x2) | y1 | (y1 ^ x1) | y0 | (y0 ^ x0) |
> + *
> + * Basically, interleaving the X and Y bits, with XORs thrown in for every
> + * adjacent bit pair.
> + *
> + * This is cheap to implement both encode/decode in both hardware and 
> software.
> + * In hardware, lines are simply rerouted to reorder and some XOR gates are
> + * thrown in. Software has to be a bit more clever.
> + *
> + * In software, the trick is to divide the pattern into two lines:
> + *
> + *| y3 | y3 | y2 | y2 | y1 | y1 | y0 | y0 |
> + *  ^ |  0 | x3 |  0 | x2 |  0 | x1 |  0 | x0 |
> + *
> + * That is, duplicate the bits of the Y and space out the bits of the X. The
> + * top line is a