[Mesa-dev] [Bug 111510] [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build

[bugzilla-daemon]

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

--- Comment #4 from Dieter Nützel  ---
Maybe duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=111523 ?

-- 
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 111510] [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build

[bugzilla-daemon]

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

LoneVVolf  changed:

   What|Removed |Added

  Component|Gallium/StateTracker/galliu |Gallium/StateTracker/Clover
   |mnine   |

-- 
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 111510] [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build

[bugzilla-daemon]

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

--- Comment #3 from LoneVVolf  ---
You're right, Axel.

I didn't have logs of the fail, so did a fresh build (log attached).
The problem is not with gallium-nine, but with clover / opencl .

When building with gallium-opencl=disabled build finishes normally.

Changing component and title (if that's possible) to reflect this.

-- 
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 111510] [gallium-nine] [build failure] change in clang CompilerInvocation::CreateFromArgs breaks build

[bugzilla-daemon]

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

--- Comment #2 from LoneVVolf  ---
Created attachment 145221
  --> https://bugs.freedesktop.org/attachment.cgi?id=145221=edit
build log

-- 
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] Switching to Gitlab Issues instead of Bugzilla?

[Eric Engestrom]

Just adding to the pile of :+1:

I think an empty repo for drm with just issues enabled is a good solution.

On Thursday, 2019-08-29 11:52:51 -0700, Kenneth Graunke wrote:
> Hi all,
> 
> As a lot of you have probably noticed, Bugzilla seems to be getting a
> lot of spam these days - several of us have been disabling a bunch of
> accounts per day, sweeping new reports under the rug, hiding comments,
> etc.  This bug spam causes emails to be sent (more spam!) and then us
> to have to look at ancient bugs that suddenly have updates.
> 
> I think it's probably time to consider switching away from Bugzilla.
> We are one of the few projects remaining - Mesa, DRM, and a few DDX
> drivers are still there, but almost all other projects are gone:
> 
> https://bugs.freedesktop.org/enter_bug.cgi
> 
> Originally, I was in favor of retaining Bugzilla just to not change too
> many processes all at once.  But we've been using Gitlab a while now,
> and several of us have been using Gitlab issues in our personal repos;
> it's actually pretty nice.
> 
> Some niceities:
> 
> - Bug reporters don't necessarily need to sign up for an account
>   anymore.  They can sign in with their Gitlab.com, Github, Google,
>   or Twitter accounts.  Or make one as before.  This may be nicer for
>   reporters that don't want to open yet another account just to report
>   an issue to us.
> 
> - Anti-spam support is actually maintained.  Bugzilla makes it near
>   impossible to actually delete garbage, Gitlab makes it easier.  It
>   has a better account creation hurdle than Bugzilla's ancient captcha,
>   and Akismet plug-ins for handling spam.
> 
> - The search interface is more modern and easier to use IMO.
> 
> - Permissions & accounts are easier - it's the same unified system.
> 
> - Easy linking between issues and MRs - mention one in the other, and
>   both get updated with cross-links so you don't miss any discussion.
> 
> - Milestone tracking
> 
>   - This could be handy for release trackers - both features people
> want to land, and bugs blocking the release.
> 
>   - We could also use it for big efforts like direct state access,
> getting feature parity with fglrx, or whatnot.
> 
> - Khronos switched a while ago as well, so a number of us are already
>   familiar with using it there.
> 
> Some cons:
> 
> - Moving bug reports between the kernel and Mesa would be harder.
>   We would have to open a bug in the other system.  (Then again,
>   moving bugs between Mesa and X or Wayland would be easier...)
> 
> What do people think?  If folks are in favor, Daniel can migrate
> everything for us, like he did with the other projects.  If not,
> I'd like to hear what people's concerns are.
> 
> --Ken



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

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

[Mesa-dev] [Bug 111493] In the game The Surge (378540) - textures disappear then appear again when I change the camera angle view

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

   Keywords||bisected, regression

-- 
You are receiving this mail because:
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 111493] In the game The Surge (378540) - textures disappear then appear again when I change the camera angle view

[bugzilla-daemon]

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

--- Comment #4 from Ian Romanick  ---
This is almost certainly a dup of
https://bugs.freedesktop.org/show_bug.cgi?id=111490, but I'm going to wait a
bit to close it as such.

-- 
You are receiving this mail because:
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 111493] In the game The Surge (378540) - textures disappear then appear again when I change the camera angle view

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 Blocks||111444
   Assignee|mesa-dev@lists.freedesktop. |i...@freedesktop.org
   |org |
 Status|NEW |ASSIGNED


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=111444
[Bug 111444] [TRACKER] Mesa 19.2 release tracker
-- 
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 111444] [TRACKER] Mesa 19.2 release tracker

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 Depends on||111493


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=111493
[Bug 111493] In the game The Surge (378540) - textures disappear then appear
again when I change the camera angle view
-- 
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 111308] [Regression, NIR, bisected] Black squares in Unigine Heaven via DXVK

[bugzilla-daemon]

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

Ian Romanick  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Ian Romanick  ---
Fixed by commit

commit 33ad2bab4bcb52c0f6be56e2f9cce5f52601a4ea
Author: Ian Romanick 
Date:   Wed Aug 7 08:56:22 2019 -0700

nir/range-analysis: Adjust result range of exp2 to account for
flush-to-zero

Fixes piglit tests (new in piglit!110):

- fs-underflow-exp2-compare-zero.shader_test

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111308
Fixes: 405de7ccb6c ("nir/range-analysis: Rudimentary value range analysis
pass")
Reviewed-by: Caio Marcelo de Oliveira Filho 

Most of the shaders affected are, unsurprisingly, in Unigine Heaven.

All Gen6+ platforms had similar results. (Ice Lake shown)
total instructions in shared programs: 16278207 -> 16278465 (<.01%)
instructions in affected programs: 11374 -> 11632 (2.27%)
helped: 0
HURT: 58
HURT stats (abs)   min: 2 max: 13 x̄: 4.45 x̃: 4
HURT stats (rel)   min: 0.54% max: 4.11% x̄: 2.42% x̃: 2.82%
95% mean confidence interval for instructions value: 3.77 5.13
95% mean confidence interval for instructions %-change: 2.19% 2.64%
Instructions are HURT.

total cycles in shared programs: 367134284 -> 367135159 (<.01%)
cycles in affected programs: 81207 -> 82082 (1.08%)
helped: 17
HURT: 36
helped stats (abs) min: 6 max: 356 x̄: 90.35 x̃: 6
helped stats (rel) min: 0.69% max: 21.45% x̄: 5.71% x̃: 0.78%
HURT stats (abs)   min: 4 max: 235 x̄: 66.97 x̃: 16
HURT stats (rel)   min: 0.35% max: 27.58% x̄: 5.34% x̃: 1.09%
95% mean confidence interval for cycles value: -20.36 53.38
95% mean confidence interval for cycles %-change: -1.08% 4.67%
Inconclusive result (value mean confidence interval includes 0).

No changes on any earlier platforms.

-- 
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/4] panfrost: s/job/batch/

[Boris Brezillon]

On Fri, 30 Aug 2019 10:35:57 -0700
Alyssa Rosenzweig  wrote:

> > +struct panfrost_job_batch *batch = 
> > panfrost_job_get_batch_for_fbo(ctx);  
> 
> This is verbose. Could we do across this patch:
> 
> s/panfrost_job_batch/panfrost_batch/g
> s/panfrost_job_get_batch_for_fbo/panfrost_get_batch_for_fbo/g

Sure, I can do that.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2 1/2] panfrost: Jobs must be per context, not per screen

[Alyssa Rosenzweig]

This series is R-b, provided Boris's comments are addressed (although it
sounds like he'll address them himself and push)

Nice debuging :)

On Fri, Aug 30, 2019 at 06:00:12PM +0200, Rohan Garg wrote:
> Jobs _must_ only be shared across the same context, having
> the last_job tracked in a screen causes use-after-free issues
> and memory corruptions.
> 
> Signed-off-by: Rohan Garg 
> ---
>  src/gallium/drivers/panfrost/pan_context.c | 10 +-
>  src/gallium/drivers/panfrost/pan_context.h |  6 ++
>  src/gallium/drivers/panfrost/pan_drm.c |  6 +++---
>  src/gallium/drivers/panfrost/pan_screen.c  |  3 ---
>  src/gallium/drivers/panfrost/pan_screen.h  |  6 --
>  5 files changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_context.c 
> b/src/gallium/drivers/panfrost/pan_context.c
> index fa9c92af9f6..94ee9b5bdb2 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -1329,9 +1329,6 @@ panfrost_submit_frame(struct panfrost_context *ctx, 
> bool flush_immediate,
>struct pipe_fence_handle **fence,
>struct panfrost_job *job)
>  {
> -struct pipe_context *gallium = (struct pipe_context *) ctx;
> -struct panfrost_screen *screen = pan_screen(gallium->screen);
> -
>  panfrost_job_submit(ctx, job);
>  
>  /* If visual, we can stall a frame */
> @@ -1339,8 +1336,8 @@ panfrost_submit_frame(struct panfrost_context *ctx, 
> bool flush_immediate,
>  if (!flush_immediate)
>  panfrost_drm_force_flush_fragment(ctx, fence);
>  
> -screen->last_fragment_flushed = false;
> -screen->last_job = job;
> +ctx->last_fragment_flushed = false;
> +ctx->last_job = job;
>  
>  /* If readback, flush now (hurts the pipelined performance) */
>  if (flush_immediate)
> @@ -2856,6 +2853,9 @@ panfrost_create_context(struct pipe_screen *screen, 
> void *priv, unsigned flags)
>  assert(ctx->blitter);
>  assert(ctx->blitter_wallpaper);
>  
> +ctx->last_fragment_flushed = true;
> +ctx->last_job = NULL;
> +
>  /* Prepare for render! */
>  
>  panfrost_job_init(ctx);
> diff --git a/src/gallium/drivers/panfrost/pan_context.h 
> b/src/gallium/drivers/panfrost/pan_context.h
> index 4c1580b3393..9f96e983a86 100644
> --- a/src/gallium/drivers/panfrost/pan_context.h
> +++ b/src/gallium/drivers/panfrost/pan_context.h
> @@ -203,6 +203,12 @@ struct panfrost_context {
>  bool is_t6xx;
>  
>  uint32_t out_sync;
> +
> +/* While we're busy building up the job for frame N, the GPU is
> + * still busy executing frame N-1. So hold a reference to
> + * yesterjob */
> +int last_fragment_flushed;
> +struct panfrost_job *last_job;
>  };
>  
>  /* Corresponds to the CSO */
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
> b/src/gallium/drivers/panfrost/pan_drm.c
> index c3693bff56a..f89bc1d26eb 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -349,12 +349,12 @@ panfrost_drm_force_flush_fragment(struct 
> panfrost_context *ctx,
>  struct pipe_context *gallium = (struct pipe_context *) ctx;
>  struct panfrost_screen *screen = pan_screen(gallium->screen);
>  
> -if (!screen->last_fragment_flushed) {
> +if (!ctx->last_fragment_flushed) {
>  drmSyncobjWait(screen->fd, >out_sync, 1, INT64_MAX, 0, 
> NULL);
> -screen->last_fragment_flushed = true;
> +ctx->last_fragment_flushed = true;
>  
>  /* The job finished up, so we're safe to clean it up now */
> -panfrost_free_job(ctx, screen->last_job);
> +panfrost_free_job(ctx, ctx->last_job);
>  }
>  
>  if (fence) {
> diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
> b/src/gallium/drivers/panfrost/pan_screen.c
> index 36c91a1572e..5c288f52bbd 100644
> --- a/src/gallium/drivers/panfrost/pan_screen.c
> +++ b/src/gallium/drivers/panfrost/pan_screen.c
> @@ -665,9 +665,6 @@ panfrost_create_screen(int fd, struct renderonly *ro)
>  screen->base.fence_finish = panfrost_fence_finish;
>  screen->base.set_damage_region = panfrost_resource_set_damage_region;
>  
> -screen->last_fragment_flushed = true;
> -screen->last_job = NULL;
> -
>  panfrost_resource_screen_init(screen);
>  
>  return >base;
> diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
> b/src/gallium/drivers/panfrost/pan_screen.h
> index 35fb8de2628..7991b395f54 100644
> --- a/src/gallium/drivers/panfrost/pan_screen.h
> +++ b/src/gallium/drivers/panfrost/pan_screen.h
> @@ -118,12 +118,6 @@ struct panfrost_screen {
>   * Each bucket is a linked list of free panfrost_bo objects. */
>  
>  struct list_head bo_cache[NR_BO_CACHE_BUCKETS];
> -
> - 

Re: [Mesa-dev] [PATCH 0/4] panfrost: Random cleanups

[Alyssa Rosenzweig]

Patch 1 is reviewed-by.

Patch 2 I commented on for a v2.

Patch 3 and 4 will be reviewed-by once they're updated with the patch 2
rename (merge conflicts).

On Fri, Aug 30, 2019 at 04:05:33PM +0200, Boris Brezillon wrote:
> Hello,
> 
> I'm currently reworking the job flushing logic to allow and I noticed
> a few things in the existing that could be addressed independently.
> 
> Patch 1 is addressing a TODO, though the additional panfrost_job_add_bo()
> is probably only needed for debug purpose (there's no risk of
> use-after-free here).
> 
> Patch 2 is something Alyssa had in her TODO list, and I thought it'd
> be wise to do it now to avoid misnaming new fields/functions while
> reworking the batch dependency/flushing logic.
> 
> Patch 3 is about making function prototype consistent with the
> function name, and patch 4 is about shrinking the number of args passed
> to some functions when information can be retrieved from other args.
> 
> Regards,
> 
> Boris
> 
> Boris Brezillon (4):
>   panfrost: Add transient BOs to job batches
>   panfrost: s/job/batch/
>   panfrost: Pass a batch to panfrost_drm_submit_vs_fs_batch()
>   panfrost: Stop passing a ctx to functions being passed a batch
> 
>  src/gallium/drivers/panfrost/pan_allocate.c   |   4 +-
>  src/gallium/drivers/panfrost/pan_blend_cso.c  |   4 +-
>  src/gallium/drivers/panfrost/pan_compute.c|   2 +-
>  src/gallium/drivers/panfrost/pan_context.c|  50 ++---
>  src/gallium/drivers/panfrost/pan_context.h|  10 +-
>  src/gallium/drivers/panfrost/pan_drm.c|  35 ++--
>  src/gallium/drivers/panfrost/pan_fragment.c   |  18 +-
>  src/gallium/drivers/panfrost/pan_instancing.c |   4 +-
>  src/gallium/drivers/panfrost/pan_job.c| 182 +-
>  src/gallium/drivers/panfrost/pan_job.h|  53 +++--
>  src/gallium/drivers/panfrost/pan_mfbd.c   |  30 +--
>  src/gallium/drivers/panfrost/pan_resource.c   |   4 +-
>  src/gallium/drivers/panfrost/pan_scoreboard.c |  20 +-
>  src/gallium/drivers/panfrost/pan_screen.c |   2 +-
>  src/gallium/drivers/panfrost/pan_screen.h |   6 +-
>  src/gallium/drivers/panfrost/pan_sfbd.c   |  36 ++--
>  src/gallium/drivers/panfrost/pan_varyings.c   |   2 +-
>  17 files changed, 234 insertions(+), 228 deletions(-)
> 
> -- 
> 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

Re: [Mesa-dev] [PATCH 2/4] panfrost: s/job/batch/

[Alyssa Rosenzweig]

> +struct panfrost_job_batch *batch = 
> panfrost_job_get_batch_for_fbo(ctx);

This is verbose. Could we do across this patch:

s/panfrost_job_batch/panfrost_batch/g
s/panfrost_job_get_batch_for_fbo/panfrost_get_batch_for_fbo/g


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 v2 2/2] panfrost: protect access to shared bo cache and transient pool

[Boris Brezillon]

On Fri, 30 Aug 2019 18:00:13 +0200
Rohan Garg  wrote:

> Both the BO cache and the transient pool are shared across
> context's. Protect access to these with mutexes.
> 
> Signed-off-by: Rohan Garg 

> --- a/src/gallium/drivers/panfrost/pan_screen.c
> +++ b/src/gallium/drivers/panfrost/pan_screen.c
> @@ -639,8 +639,10 @@ panfrost_create_screen(int fd, struct renderonly *ro)
>  return NULL;
>  }
>  
> + pthread_mutex_init(>transient_lock, NULL);

Coding style issue: indentation should use spaces not tabs.

>  util_dynarray_init(>transient_bo, screen);
>  
> + pthread_mutex_init(>bo_cache_lock, NULL);

We should probably call pthread_mutex_destroy() in
panfrost_destroy_screen().

>  for (unsigned i = 0; i < ARRAY_SIZE(screen->bo_cache); ++i)
>  list_inithead(>bo_cache[i]);
>  
> diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
> b/src/gallium/drivers/panfrost/pan_screen.h
> index 7991b395f54..e3ea246d3f3 100644
> --- a/src/gallium/drivers/panfrost/pan_screen.h
> +++ b/src/gallium/drivers/panfrost/pan_screen.h
> @@ -104,6 +104,8 @@ struct panfrost_screen {
>  
>  struct renderonly *ro;
>  
> +pthread_mutex_t transient_lock;
> +
>  /* Transient memory management is based on borrowing fixed-size slabs
>   * off the screen (loaning them out to the batch). Dynamic array
>   * container of panfrost_bo */
> @@ -113,6 +115,8 @@ struct panfrost_screen {
>  /* Set of free transient BOs */
>  BITSET_DECLARE(free_transient, MAX_TRANSIENT_SLABS);
>  
> + pthread_mutex_t bo_cache_lock;

Same indentation issue.

No need to send a new version, I can fix those issues when applying.

Reviewed-by: Boris Brezillon 

> +
>  /* The BO cache is a set of buckets with power-of-two sizes ranging
>   * from 2^12 (4096, the page size) to 2^(12 + MAX_BO_CACHE_BUCKETS).
>   * Each bucket is a linked list of free panfrost_bo objects. */

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

Re: [Mesa-dev] [PATCH v2 1/2] panfrost: Jobs must be per context, not per screen

[Boris Brezillon]

On Fri, 30 Aug 2019 18:00:12 +0200
Rohan Garg  wrote:

> Jobs _must_ only be shared across the same context, having
> the last_job tracked in a screen causes use-after-free issues
> and memory corruptions.
> 
> Signed-off-by: Rohan Garg 

Reviewed-by: Boris Brezillon 

> ---
>  src/gallium/drivers/panfrost/pan_context.c | 10 +-
>  src/gallium/drivers/panfrost/pan_context.h |  6 ++
>  src/gallium/drivers/panfrost/pan_drm.c |  6 +++---
>  src/gallium/drivers/panfrost/pan_screen.c  |  3 ---
>  src/gallium/drivers/panfrost/pan_screen.h  |  6 --
>  5 files changed, 14 insertions(+), 17 deletions(-)
> 
> diff --git a/src/gallium/drivers/panfrost/pan_context.c 
> b/src/gallium/drivers/panfrost/pan_context.c
> index fa9c92af9f6..94ee9b5bdb2 100644
> --- a/src/gallium/drivers/panfrost/pan_context.c
> +++ b/src/gallium/drivers/panfrost/pan_context.c
> @@ -1329,9 +1329,6 @@ panfrost_submit_frame(struct panfrost_context *ctx, 
> bool flush_immediate,
>struct pipe_fence_handle **fence,
>struct panfrost_job *job)
>  {
> -struct pipe_context *gallium = (struct pipe_context *) ctx;
> -struct panfrost_screen *screen = pan_screen(gallium->screen);
> -
>  panfrost_job_submit(ctx, job);
>  
>  /* If visual, we can stall a frame */
> @@ -1339,8 +1336,8 @@ panfrost_submit_frame(struct panfrost_context *ctx, 
> bool flush_immediate,
>  if (!flush_immediate)
>  panfrost_drm_force_flush_fragment(ctx, fence);
>  
> -screen->last_fragment_flushed = false;
> -screen->last_job = job;
> +ctx->last_fragment_flushed = false;
> +ctx->last_job = job;
>  
>  /* If readback, flush now (hurts the pipelined performance) */
>  if (flush_immediate)
> @@ -2856,6 +2853,9 @@ panfrost_create_context(struct pipe_screen *screen, 
> void *priv, unsigned flags)
>  assert(ctx->blitter);
>  assert(ctx->blitter_wallpaper);
>  
> +ctx->last_fragment_flushed = true;
> +ctx->last_job = NULL;
> +
>  /* Prepare for render! */
>  
>  panfrost_job_init(ctx);
> diff --git a/src/gallium/drivers/panfrost/pan_context.h 
> b/src/gallium/drivers/panfrost/pan_context.h
> index 4c1580b3393..9f96e983a86 100644
> --- a/src/gallium/drivers/panfrost/pan_context.h
> +++ b/src/gallium/drivers/panfrost/pan_context.h
> @@ -203,6 +203,12 @@ struct panfrost_context {
>  bool is_t6xx;
>  
>  uint32_t out_sync;
> +
> +/* While we're busy building up the job for frame N, the GPU is
> + * still busy executing frame N-1. So hold a reference to
> + * yesterjob */
> +int last_fragment_flushed;
> +struct panfrost_job *last_job;
>  };
>  
>  /* Corresponds to the CSO */
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
> b/src/gallium/drivers/panfrost/pan_drm.c
> index c3693bff56a..f89bc1d26eb 100644
> --- a/src/gallium/drivers/panfrost/pan_drm.c
> +++ b/src/gallium/drivers/panfrost/pan_drm.c
> @@ -349,12 +349,12 @@ panfrost_drm_force_flush_fragment(struct 
> panfrost_context *ctx,
>  struct pipe_context *gallium = (struct pipe_context *) ctx;
>  struct panfrost_screen *screen = pan_screen(gallium->screen);
>  
> -if (!screen->last_fragment_flushed) {
> +if (!ctx->last_fragment_flushed) {
>  drmSyncobjWait(screen->fd, >out_sync, 1, INT64_MAX, 0, 
> NULL);
> -screen->last_fragment_flushed = true;
> +ctx->last_fragment_flushed = true;
>  
>  /* The job finished up, so we're safe to clean it up now */
> -panfrost_free_job(ctx, screen->last_job);
> +panfrost_free_job(ctx, ctx->last_job);
>  }
>  
>  if (fence) {
> diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
> b/src/gallium/drivers/panfrost/pan_screen.c
> index 36c91a1572e..5c288f52bbd 100644
> --- a/src/gallium/drivers/panfrost/pan_screen.c
> +++ b/src/gallium/drivers/panfrost/pan_screen.c
> @@ -665,9 +665,6 @@ panfrost_create_screen(int fd, struct renderonly *ro)
>  screen->base.fence_finish = panfrost_fence_finish;
>  screen->base.set_damage_region = panfrost_resource_set_damage_region;
>  
> -screen->last_fragment_flushed = true;
> -screen->last_job = NULL;
> -
>  panfrost_resource_screen_init(screen);
>  
>  return >base;
> diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
> b/src/gallium/drivers/panfrost/pan_screen.h
> index 35fb8de2628..7991b395f54 100644
> --- a/src/gallium/drivers/panfrost/pan_screen.h
> +++ b/src/gallium/drivers/panfrost/pan_screen.h
> @@ -118,12 +118,6 @@ struct panfrost_screen {
>   * Each bucket is a linked list of free panfrost_bo objects. */
>  
>  struct list_head bo_cache[NR_BO_CACHE_BUCKETS];
> -
> -/* While we're busy building up the job for frame N, the GPU is
> - * still busy executing frame 

Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()

[Boris Brezillon]

On Fri, 30 Aug 2019 18:56:52 +0200
Michel Dänzer  wrote:

> On 2019-08-30 6:52 p.m., Boris Brezillon wrote:
> > On Fri, 30 Aug 2019 18:43:59 +0200
> > Michel Dänzer  wrote:
> >   
> >>> diff --git a/include/GL/internal/dri_interface.h 
> >>> b/include/GL/internal/dri_interface.h
> >>> index 4c60d349ddd5..e04bed689219 100644
> >>> --- a/include/GL/internal/dri_interface.h
> >>> +++ b/include/GL/internal/dri_interface.h
> >>> @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
> >>>  *
> >>>  * Used to implement EGL_KHR_partial_update.
> >>>  *
> >>> +* \param ctx  context
> >>>  * \param drawable affected drawable
> >>>  * \param nrects   number of rectangles provided
> >>>  * \param rectsthe array of rectangles, lower-left origin
> >>>  */
> >>> -   void (*set_damage_region)(__DRIdrawable *drawable, unsigned int 
> >>> nrects,
> >>> - int *rects);
> >>> +   void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
> >>> + unsigned int nrects, int *rects);
> >>>  };
> >>
> >> This would break the DRI2_BufferDamage extension version 1 ABI. You'd
> >> need to either add a new hook like set_damage_region2 and bump
> >> __DRI2_BUFFER_DAMAGE_VERSION (and make sure that's handled correctly
> >> everywhere), or add a new extension instead.  
> > 
> > I thought this change was only impacting the internal API, but maybe
> > I'm missing something.  
> 
> include/GL/internal/dri_interface.h defines the DRI driver ABI, which
> must be kept backwards compatible.

Okay.

> 
> 
> > In any case, this extension has been merged recently (mesa-19.2.0-rc1),
> > so maybe we can fix it before 19.2 is released to avoid creating  
> > ->set_damage_region2().  
> 
> Ah, yes. I misinterpreted gitk's output, thinking it had already been
> introduced in 19.1. Sorry for the false alarm.

Great! So, next question is, do you think it's acceptable to pass a
DRIcontext here, and if not, do you have any idea how to solve this
problem?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()

[Michel Dänzer]

On 2019-08-30 6:52 p.m., Boris Brezillon wrote:
> On Fri, 30 Aug 2019 18:43:59 +0200
> Michel Dänzer  wrote:
> 
>>> diff --git a/include/GL/internal/dri_interface.h 
>>> b/include/GL/internal/dri_interface.h
>>> index 4c60d349ddd5..e04bed689219 100644
>>> --- a/include/GL/internal/dri_interface.h
>>> +++ b/include/GL/internal/dri_interface.h
>>> @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
>>>  *
>>>  * Used to implement EGL_KHR_partial_update.
>>>  *
>>> +* \param ctx  context
>>>  * \param drawable affected drawable
>>>  * \param nrects   number of rectangles provided
>>>  * \param rectsthe array of rectangles, lower-left origin
>>>  */
>>> -   void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
>>> - int *rects);
>>> +   void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
>>> + unsigned int nrects, int *rects);
>>>  };  
>>
>> This would break the DRI2_BufferDamage extension version 1 ABI. You'd
>> need to either add a new hook like set_damage_region2 and bump
>> __DRI2_BUFFER_DAMAGE_VERSION (and make sure that's handled correctly
>> everywhere), or add a new extension instead.
> 
> I thought this change was only impacting the internal API, but maybe
> I'm missing something.

include/GL/internal/dri_interface.h defines the DRI driver ABI, which
must be kept backwards compatible.


> In any case, this extension has been merged recently (mesa-19.2.0-rc1),
> so maybe we can fix it before 19.2 is released to avoid creating
> ->set_damage_region2().

Ah, yes. I misinterpreted gitk's output, thinking it had already been
introduced in 19.1. Sorry for the false alarm.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()

[Boris Brezillon]

On Fri, 30 Aug 2019 18:43:59 +0200
Michel Dänzer  wrote:

> On 2019-08-29 1:54 p.m., Boris Brezillon wrote:
> > So we can call st_validate_state() from dri2_set_damage_region() in
> > order to update the BACK_LEFT attachement before using it. If we don't
> > do that, the resource passed to pipe_screen->set_damage_region() might
> > be wrong.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Hi,
> > 
> > I honestly don't know if this is the right thing to do. Passing a
> > context for somethings that we decided to bind to a surface (and
> > the underlying resources attached to it) seems wrong, but at the same
> > time I don't see any other option to sync the gallium drawable state
> > with the EGL DRI surface one.
> > 
> > Any ideas/suggestions?
> > 
> > Regards,
> > 
> > Boris
> > ---
> >  include/GL/internal/dri_interface.h   |  5 +++--
> >  src/egl/drivers/dri2/egl_dri2.c   |  7 +--
> >  src/gallium/state_trackers/dri/dri2.c | 11 ++-
> >  3 files changed, 18 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/GL/internal/dri_interface.h 
> > b/include/GL/internal/dri_interface.h
> > index 4c60d349ddd5..e04bed689219 100644
> > --- a/include/GL/internal/dri_interface.h
> > +++ b/include/GL/internal/dri_interface.h
> > @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
> >  *
> >  * Used to implement EGL_KHR_partial_update.
> >  *
> > +* \param ctx  context
> >  * \param drawable affected drawable
> >  * \param nrects   number of rectangles provided
> >  * \param rectsthe array of rectangles, lower-left origin
> >  */
> > -   void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
> > - int *rects);
> > +   void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
> > + unsigned int nrects, int *rects);
> >  };  
> 
> This would break the DRI2_BufferDamage extension version 1 ABI. You'd
> need to either add a new hook like set_damage_region2 and bump
> __DRI2_BUFFER_DAMAGE_VERSION (and make sure that's handled correctly
> everywhere), or add a new extension instead.
> 
> 

I thought this change was only impacting the internal API, but maybe
I'm missing something.
In any case, this extension has been merged recently (mesa-19.2.0-rc1),
so maybe we can fix it before 19.2 is released to avoid creating
->set_damage_region2().
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Juan A. Suarez Romero]

Hello list,

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


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

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


Testing reports/general approval

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

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

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


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

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

(cherry picked from commit b418269d7dd576a7c9afd728bf8a883b4da98b30)


commit e4df7ffc23e8b48e852c95a7083f6cb86751134f
Author: Paulo Zanoni 

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

(cherry picked from commit 848d5e444a881a1a3ac6824f07d95988b312530b)


commit c1959aa26d4fa3c85a23fed2d5588501f2d729c5
Author: Andres Rodriguez 

radv: additional query fixes

(cherry picked from commit a410823b3ede9ff3bf7f56ffca295d1b3d04dbad)


commit 8ad62264d1aba61091994a2a30df076833316701
Author: Kenneth Graunke 

iris: Fix broken aux.possible/sampler_usages bitmask handling

(cherry picked from commit 117a0368b0cc741aec88d2538ffdebd26618a6fb)


commit ac0f71a4afa823f4a6d95bdf0d48cc71d3654c37
Author: Ilia Mirkin 

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

(cherry picked from commit 958390a9bf8904522a50f8e9c26c50c96179c183)


Cheers,
J.A.


Mesa stable queue
-

Nominated (0)
==

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

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

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

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

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

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

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

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

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

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

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


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

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


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

Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()

[Michel Dänzer]

On 2019-08-29 1:54 p.m., Boris Brezillon wrote:
> So we can call st_validate_state() from dri2_set_damage_region() in
> order to update the BACK_LEFT attachement before using it. If we don't
> do that, the resource passed to pipe_screen->set_damage_region() might
> be wrong.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Hi,
> 
> I honestly don't know if this is the right thing to do. Passing a
> context for somethings that we decided to bind to a surface (and
> the underlying resources attached to it) seems wrong, but at the same
> time I don't see any other option to sync the gallium drawable state
> with the EGL DRI surface one.
> 
> Any ideas/suggestions?
> 
> Regards,
> 
> Boris
> ---
>  include/GL/internal/dri_interface.h   |  5 +++--
>  src/egl/drivers/dri2/egl_dri2.c   |  7 +--
>  src/gallium/state_trackers/dri/dri2.c | 11 ++-
>  3 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index 4c60d349ddd5..e04bed689219 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
>  *
>  * Used to implement EGL_KHR_partial_update.
>  *
> +* \param ctx  context
>  * \param drawable affected drawable
>  * \param nrects   number of rectangles provided
>  * \param rectsthe array of rectangles, lower-left origin
>  */
> -   void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
> - int *rects);
> +   void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
> + unsigned int nrects, int *rects);
>  };

This would break the DRI2_BufferDamage extension version 1 ABI. You'd
need to either add a new hook like set_damage_region2 and bump
__DRI2_BUFFER_DAMAGE_VERSION (and make sure that's handled correctly
everywhere), or add a new extension instead.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111522] [bisected] Supraland no longer start

[bugzilla-daemon]

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

--- Comment #6 from MWATTT  ---
Applying 1819 patch + /.drirc file doesn't have any effects.

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

[Mesa-dev] [PATCH v2 1/2] panfrost: Jobs must be per context, not per screen

[Rohan Garg]

Jobs _must_ only be shared across the same context, having
the last_job tracked in a screen causes use-after-free issues
and memory corruptions.

Signed-off-by: Rohan Garg 
---
 src/gallium/drivers/panfrost/pan_context.c | 10 +-
 src/gallium/drivers/panfrost/pan_context.h |  6 ++
 src/gallium/drivers/panfrost/pan_drm.c |  6 +++---
 src/gallium/drivers/panfrost/pan_screen.c  |  3 ---
 src/gallium/drivers/panfrost/pan_screen.h  |  6 --
 5 files changed, 14 insertions(+), 17 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index fa9c92af9f6..94ee9b5bdb2 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -1329,9 +1329,6 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool 
flush_immediate,
   struct pipe_fence_handle **fence,
   struct panfrost_job *job)
 {
-struct pipe_context *gallium = (struct pipe_context *) ctx;
-struct panfrost_screen *screen = pan_screen(gallium->screen);
-
 panfrost_job_submit(ctx, job);
 
 /* If visual, we can stall a frame */
@@ -1339,8 +1336,8 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool 
flush_immediate,
 if (!flush_immediate)
 panfrost_drm_force_flush_fragment(ctx, fence);
 
-screen->last_fragment_flushed = false;
-screen->last_job = job;
+ctx->last_fragment_flushed = false;
+ctx->last_job = job;
 
 /* If readback, flush now (hurts the pipelined performance) */
 if (flush_immediate)
@@ -2856,6 +2853,9 @@ panfrost_create_context(struct pipe_screen *screen, void 
*priv, unsigned flags)
 assert(ctx->blitter);
 assert(ctx->blitter_wallpaper);
 
+ctx->last_fragment_flushed = true;
+ctx->last_job = NULL;
+
 /* Prepare for render! */
 
 panfrost_job_init(ctx);
diff --git a/src/gallium/drivers/panfrost/pan_context.h 
b/src/gallium/drivers/panfrost/pan_context.h
index 4c1580b3393..9f96e983a86 100644
--- a/src/gallium/drivers/panfrost/pan_context.h
+++ b/src/gallium/drivers/panfrost/pan_context.h
@@ -203,6 +203,12 @@ struct panfrost_context {
 bool is_t6xx;
 
 uint32_t out_sync;
+
+/* While we're busy building up the job for frame N, the GPU is
+ * still busy executing frame N-1. So hold a reference to
+ * yesterjob */
+int last_fragment_flushed;
+struct panfrost_job *last_job;
 };
 
 /* Corresponds to the CSO */
diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index c3693bff56a..f89bc1d26eb 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -349,12 +349,12 @@ panfrost_drm_force_flush_fragment(struct panfrost_context 
*ctx,
 struct pipe_context *gallium = (struct pipe_context *) ctx;
 struct panfrost_screen *screen = pan_screen(gallium->screen);
 
-if (!screen->last_fragment_flushed) {
+if (!ctx->last_fragment_flushed) {
 drmSyncobjWait(screen->fd, >out_sync, 1, INT64_MAX, 0, 
NULL);
-screen->last_fragment_flushed = true;
+ctx->last_fragment_flushed = true;
 
 /* The job finished up, so we're safe to clean it up now */
-panfrost_free_job(ctx, screen->last_job);
+panfrost_free_job(ctx, ctx->last_job);
 }
 
 if (fence) {
diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index 36c91a1572e..5c288f52bbd 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -665,9 +665,6 @@ panfrost_create_screen(int fd, struct renderonly *ro)
 screen->base.fence_finish = panfrost_fence_finish;
 screen->base.set_damage_region = panfrost_resource_set_damage_region;
 
-screen->last_fragment_flushed = true;
-screen->last_job = NULL;
-
 panfrost_resource_screen_init(screen);
 
 return >base;
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 35fb8de2628..7991b395f54 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -118,12 +118,6 @@ struct panfrost_screen {
  * Each bucket is a linked list of free panfrost_bo objects. */
 
 struct list_head bo_cache[NR_BO_CACHE_BUCKETS];
-
-/* While we're busy building up the job for frame N, the GPU is
- * still busy executing frame N-1. So hold a reference to
- * yesterjob */
-int last_fragment_flushed;
-struct panfrost_job *last_job;
 };
 
 static inline struct panfrost_screen *
-- 
2.17.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

[Mesa-dev] [PATCH v2 2/2] panfrost: protect access to shared bo cache and transient pool

[Rohan Garg]

Both the BO cache and the transient pool are shared across
context's. Protect access to these with mutexes.

Signed-off-by: Rohan Garg 
---
 src/gallium/drivers/panfrost/pan_allocate.c |  2 ++
 src/gallium/drivers/panfrost/pan_bo_cache.c | 16 +++-
 src/gallium/drivers/panfrost/pan_job.c  |  2 ++
 src/gallium/drivers/panfrost/pan_screen.c   |  2 ++
 src/gallium/drivers/panfrost/pan_screen.h   |  4 
 5 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_allocate.c 
b/src/gallium/drivers/panfrost/pan_allocate.c
index f549c864c70..fb8b18fe718 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.c
+++ b/src/gallium/drivers/panfrost/pan_allocate.c
@@ -74,6 +74,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx, 
size_t sz)
 unsigned offset = 0;
 bool update_offset = false;
 
+pthread_mutex_lock(>transient_lock);
 bool has_current = batch->transient_indices.size;
 bool fits_in_current = (batch->transient_offset + sz) < 
TRANSIENT_SLAB_SIZE;
 
@@ -131,6 +132,7 @@ panfrost_allocate_transient(struct panfrost_context *ctx, 
size_t sz)
 
 if (update_offset)
 batch->transient_offset = offset + sz;
+pthread_mutex_unlock(>transient_lock);
 
 return ret;
 
diff --git a/src/gallium/drivers/panfrost/pan_bo_cache.c 
b/src/gallium/drivers/panfrost/pan_bo_cache.c
index 9dd6b694b72..f2f49437a89 100644
--- a/src/gallium/drivers/panfrost/pan_bo_cache.c
+++ b/src/gallium/drivers/panfrost/pan_bo_cache.c
@@ -24,6 +24,7 @@
  *   Alyssa Rosenzweig 
  */
 #include 
+#include 
 #include "drm-uapi/panfrost_drm.h"
 
 #include "pan_screen.h"
@@ -84,7 +85,9 @@ panfrost_bo_cache_fetch(
 struct panfrost_screen *screen,
 size_t size, uint32_t flags)
 {
+pthread_mutex_lock(>bo_cache_lock);
 struct list_head *bucket = pan_bucket(screen, size);
+struct panfrost_bo *bo = NULL;
 
 /* Iterate the bucket looking for something suitable */
 list_for_each_entry_safe(struct panfrost_bo, entry, bucket, link) {
@@ -106,12 +109,13 @@ panfrost_bo_cache_fetch(
 continue;
 }
 /* Let's go! */
-return entry;
+bo = entry;
+break;
 }
 }
+pthread_mutex_unlock(>bo_cache_lock);
 
-/* We didn't find anything */
-return NULL;
+return bo;
 }
 
 /* Tries to add a BO to the cache. Returns if it was
@@ -122,6 +126,7 @@ panfrost_bo_cache_put(
 struct panfrost_screen *screen,
 struct panfrost_bo *bo)
 {
+pthread_mutex_lock(>bo_cache_lock);
 struct list_head *bucket = pan_bucket(screen, bo->size);
 struct drm_panfrost_madvise madv;
 
@@ -133,6 +138,7 @@ panfrost_bo_cache_put(
 
 /* Add us to the bucket */
 list_addtail(>link, bucket);
+pthread_mutex_unlock(>bo_cache_lock);
 
 return true;
 }
@@ -147,6 +153,7 @@ void
 panfrost_bo_cache_evict_all(
 struct panfrost_screen *screen)
 {
+pthread_mutex_lock(>bo_cache_lock);
 for (unsigned i = 0; i < ARRAY_SIZE(screen->bo_cache); ++i) {
 struct list_head *bucket = >bo_cache[i];
 
@@ -155,7 +162,6 @@ panfrost_bo_cache_evict_all(
 panfrost_drm_release_bo(screen, entry, false);
 }
 }
-
-return;
+pthread_mutex_unlock(>bo_cache_lock);
 }
 
diff --git a/src/gallium/drivers/panfrost/pan_job.c 
b/src/gallium/drivers/panfrost/pan_job.c
index 4d8ec2eadc9..4d2908a58b7 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -67,10 +67,12 @@ panfrost_free_job(struct panfrost_context *ctx, struct 
panfrost_job *job)
 /* Free up the transient BOs we're sitting on */
 struct panfrost_screen *screen = pan_screen(ctx->base.screen);
 
+pthread_mutex_lock(>transient_lock);
 util_dynarray_foreach(>transient_indices, unsigned, index) {
 /* Mark it free */
 BITSET_SET(screen->free_transient, *index);
 }
+pthread_mutex_unlock(>transient_lock);
 
 /* Unreference the polygon list */
 panfrost_bo_unreference(ctx->base.screen, job->polygon_list);
diff --git a/src/gallium/drivers/panfrost/pan_screen.c 
b/src/gallium/drivers/panfrost/pan_screen.c
index 5c288f52bbd..5ceceac33ae 100644
--- a/src/gallium/drivers/panfrost/pan_screen.c
+++ b/src/gallium/drivers/panfrost/pan_screen.c
@@ -639,8 +639,10 @@ panfrost_create_screen(int fd, struct renderonly *ro)
 return NULL;
 }
 
+   pthread_mutex_init(>transient_lock, NULL);
 util_dynarray_init(>transient_bo, screen);
 
+   pthread_mutex_init(>bo_cache_lock, NULL);
 for (unsigned i = 0; i < 

[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker

[bugzilla-daemon]

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

Clayton Craft  changed:

   What|Removed |Added

 Depends on||110507


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=110507
[Bug 110507] [Regression] [Bisected] assert in fragment shader compilation when
SIMD32 is enabled
-- 
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 111444] [TRACKER] Mesa 19.2 release tracker

[bugzilla-daemon]

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

Clayton Craft  changed:

   What|Removed |Added

 Depends on||110814


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=110814
[Bug 110814] KWin compositor crashes on launch
-- 
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 111125] [RADV] Graphic glitches regression in The Witcher 3 with DXVK on AMD Radeon HD7850

[bugzilla-daemon]

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

--- Comment #5 from zefkerri...@gmail.com ---
(In reply to Samuel Pitoiset from comment #4)
> Are you still able to reproduce the problem?

Yes, it's still here with the latest Mesa commit.

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

[Mesa-dev] [PATCH 3/4] panfrost: Pass a batch to panfrost_drm_submit_vs_fs_batch()

[Boris Brezillon]

Given the function name it makes more sense to pass it a job batch
directly.

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/panfrost/pan_drm.c| 13 ++---
 src/gallium/drivers/panfrost/pan_job.c|  2 +-
 src/gallium/drivers/panfrost/pan_screen.h |  2 +-
 3 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index 3fea1274ca1a..e7f1b7225b4a 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -248,12 +248,12 @@ panfrost_drm_export_bo(struct panfrost_screen *screen, 
const struct panfrost_bo
 }
 
 static int
-panfrost_drm_submit_batch(struct panfrost_context *ctx, u64 first_job_desc,
+panfrost_drm_submit_batch(struct panfrost_job_batch *batch, u64 first_job_desc,
   int reqs)
 {
+struct panfrost_context *ctx = batch->ctx;
 struct pipe_context *gallium = (struct pipe_context *) ctx;
 struct panfrost_screen *screen = pan_screen(gallium->screen);
-struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
 struct drm_panfrost_submit submit = {0,};
 int *bo_handles, ret;
 
@@ -293,23 +293,22 @@ panfrost_drm_submit_batch(struct panfrost_context *ctx, 
u64 first_job_desc,
 }
 
 int
-panfrost_drm_submit_vs_fs_batch(struct panfrost_context *ctx, bool has_draws)
+panfrost_drm_submit_vs_fs_batch(struct panfrost_job_batch *batch, bool 
has_draws)
 {
+struct panfrost_context *ctx = batch->ctx;
 int ret = 0;
 
-struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
-
 panfrost_job_add_bo(batch, ctx->scratchpad.bo);
 panfrost_job_add_bo(batch, ctx->tiler_heap.bo);
 panfrost_job_add_bo(batch, batch->polygon_list);
 
 if (batch->first_job.gpu) {
-ret = panfrost_drm_submit_batch(ctx, batch->first_job.gpu, 0);
+ret = panfrost_drm_submit_batch(batch, batch->first_job.gpu, 
0);
 assert(!ret);
 }
 
 if (batch->first_tiler.gpu || batch->clear) {
-ret = panfrost_drm_submit_batch(ctx,
+ret = panfrost_drm_submit_batch(batch,
 panfrost_fragment_job(ctx, 
has_draws),
 PANFROST_JD_REQ_FS);
 assert(!ret);
diff --git a/src/gallium/drivers/panfrost/pan_job.c 
b/src/gallium/drivers/panfrost/pan_job.c
index f9f02161d661..b308a1722c66 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -209,7 +209,7 @@ panfrost_job_submit(struct panfrost_context *ctx, struct 
panfrost_job_batch *bat
 
 bool has_draws = batch->last_job.gpu;
 
-ret = panfrost_drm_submit_vs_fs_batch(ctx, has_draws);
+ret = panfrost_drm_submit_vs_fs_batch(batch, has_draws);
 
 if (ret)
 fprintf(stderr, "panfrost_job_submit failed: %d\n", ret);
diff --git a/src/gallium/drivers/panfrost/pan_screen.h 
b/src/gallium/drivers/panfrost/pan_screen.h
index 15a88ac25569..c70f8bdd0507 100644
--- a/src/gallium/drivers/panfrost/pan_screen.h
+++ b/src/gallium/drivers/panfrost/pan_screen.h
@@ -165,7 +165,7 @@ panfrost_drm_import_bo(struct panfrost_screen *screen, int 
fd);
 int
 panfrost_drm_export_bo(struct panfrost_screen *screen, const struct 
panfrost_bo *bo);
 int
-panfrost_drm_submit_vs_fs_batch(struct panfrost_context *ctx, bool has_draws);
+panfrost_drm_submit_vs_fs_batch(struct panfrost_job_batch *batch, bool 
has_draws);
 void
 panfrost_drm_force_flush_fragment(struct panfrost_context *ctx,
   struct pipe_fence_handle **fence);
-- 
2.21.0

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

[Mesa-dev] [PATCH 2/4] panfrost: s/job/batch/

[Boris Brezillon]

What we currently call a job is actually a batch containing several jobs
all attached to a rendering operation targeting a specific FBO.

Let's rename structs, functions, variables and fields to reflect this
fact.

Suggested-by: Alyssa Rosenzweig 
Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/panfrost/pan_allocate.c   |   2 +-
 src/gallium/drivers/panfrost/pan_blend_cso.c  |   4 +-
 src/gallium/drivers/panfrost/pan_compute.c|   2 +-
 src/gallium/drivers/panfrost/pan_context.c|  50 +++---
 src/gallium/drivers/panfrost/pan_context.h|  10 +-
 src/gallium/drivers/panfrost/pan_drm.c|  33 ++--
 src/gallium/drivers/panfrost/pan_fragment.c   |  18 +-
 src/gallium/drivers/panfrost/pan_instancing.c |   4 +-
 src/gallium/drivers/panfrost/pan_job.c| 168 +-
 src/gallium/drivers/panfrost/pan_job.h|  52 +++---
 src/gallium/drivers/panfrost/pan_mfbd.c   |  30 ++--
 src/gallium/drivers/panfrost/pan_resource.c   |   4 +-
 src/gallium/drivers/panfrost/pan_scoreboard.c |  20 +--
 src/gallium/drivers/panfrost/pan_screen.c |   2 +-
 src/gallium/drivers/panfrost/pan_screen.h |   6 +-
 src/gallium/drivers/panfrost/pan_sfbd.c   |  36 ++--
 src/gallium/drivers/panfrost/pan_varyings.c   |   2 +-
 17 files changed, 223 insertions(+), 220 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_allocate.c 
b/src/gallium/drivers/panfrost/pan_allocate.c
index 080f917bccdc..414faeee5361 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.c
+++ b/src/gallium/drivers/panfrost/pan_allocate.c
@@ -63,7 +63,7 @@ struct panfrost_transfer
 panfrost_allocate_transient(struct panfrost_context *ctx, size_t sz)
 {
 struct panfrost_screen *screen = pan_screen(ctx->base.screen);
-struct panfrost_job *batch = panfrost_get_job_for_fbo(ctx);
+struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
 
 /* Pad the size */
 sz = ALIGN_POT(sz, ALIGNMENT);
diff --git a/src/gallium/drivers/panfrost/pan_blend_cso.c 
b/src/gallium/drivers/panfrost/pan_blend_cso.c
index 43121335f5e7..7465bbae4fcb 100644
--- a/src/gallium/drivers/panfrost/pan_blend_cso.c
+++ b/src/gallium/drivers/panfrost/pan_blend_cso.c
@@ -227,7 +227,7 @@ struct panfrost_blend_final
 panfrost_get_blend_for_context(struct panfrost_context *ctx, unsigned rti)
 {
 struct panfrost_screen *screen = pan_screen(ctx->base.screen);
-struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
+struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
 
 /* Grab the format, falling back gracefully if called invalidly (which
  * has to happen for no-color-attachment FBOs, for instance)  */
@@ -276,7 +276,7 @@ panfrost_get_blend_for_context(struct panfrost_context 
*ctx, unsigned rti)
 memcpy(final.shader.bo->cpu, shader->buffer, shader->size);
 
 /* Pass BO ownership to job */
-panfrost_job_add_bo(job, final.shader.bo);
+panfrost_job_add_bo(batch, final.shader.bo);
 panfrost_bo_unreference(ctx->base.screen, final.shader.bo);
 
 if (shader->patch_index) {
diff --git a/src/gallium/drivers/panfrost/pan_compute.c 
b/src/gallium/drivers/panfrost/pan_compute.c
index 50e70cd8298e..797439aee717 100644
--- a/src/gallium/drivers/panfrost/pan_compute.c
+++ b/src/gallium/drivers/panfrost/pan_compute.c
@@ -128,7 +128,7 @@ panfrost_launch_grid(struct pipe_context *pipe,
 memcpy(transfer.cpu + sizeof(job), payload, sizeof(*payload));
 
 /* TODO: Do we want a special compute-only batch? */
-struct panfrost_job *batch = panfrost_get_job_for_fbo(ctx);
+struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
 
 /* Queue the job */
 panfrost_scoreboard_queue_compute_job(batch, transfer);
diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index fa9c92af9f6a..9e7c6ba5c21c 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -61,7 +61,7 @@ panfrost_emit_midg_tiler(
 unsigned vertex_count)
 {
 struct midgard_tiler_descriptor t = {};
-struct panfrost_job *batch = panfrost_get_job_for_fbo(ctx);
+struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
 
 t.hierarchy_mask =
 panfrost_choose_hierarchy_mask(width, height, vertex_count);
@@ -177,9 +177,9 @@ panfrost_clear(
 double depth, unsigned stencil)
 {
 struct panfrost_context *ctx = pan_context(pipe);
-struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
+struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
 
-panfrost_job_clear(ctx, job, buffers, color, depth, stencil);
+panfrost_job_clear(ctx, batch, buffers, color, depth, stencil);
 }
 
 static mali_ptr
@@ -617,8 +617,8 @@ panfrost_upload_tex(
 unsigned afbc_bit = (is_afbc && 

[Mesa-dev] [PATCH 0/4] panfrost: Random cleanups

[Boris Brezillon]

Hello,

I'm currently reworking the job flushing logic to allow and I noticed
a few things in the existing that could be addressed independently.

Patch 1 is addressing a TODO, though the additional panfrost_job_add_bo()
is probably only needed for debug purpose (there's no risk of
use-after-free here).

Patch 2 is something Alyssa had in her TODO list, and I thought it'd
be wise to do it now to avoid misnaming new fields/functions while
reworking the batch dependency/flushing logic.

Patch 3 is about making function prototype consistent with the
function name, and patch 4 is about shrinking the number of args passed
to some functions when information can be retrieved from other args.

Regards,

Boris

Boris Brezillon (4):
  panfrost: Add transient BOs to job batches
  panfrost: s/job/batch/
  panfrost: Pass a batch to panfrost_drm_submit_vs_fs_batch()
  panfrost: Stop passing a ctx to functions being passed a batch

 src/gallium/drivers/panfrost/pan_allocate.c   |   4 +-
 src/gallium/drivers/panfrost/pan_blend_cso.c  |   4 +-
 src/gallium/drivers/panfrost/pan_compute.c|   2 +-
 src/gallium/drivers/panfrost/pan_context.c|  50 ++---
 src/gallium/drivers/panfrost/pan_context.h|  10 +-
 src/gallium/drivers/panfrost/pan_drm.c|  35 ++--
 src/gallium/drivers/panfrost/pan_fragment.c   |  18 +-
 src/gallium/drivers/panfrost/pan_instancing.c |   4 +-
 src/gallium/drivers/panfrost/pan_job.c| 182 +-
 src/gallium/drivers/panfrost/pan_job.h|  53 +++--
 src/gallium/drivers/panfrost/pan_mfbd.c   |  30 +--
 src/gallium/drivers/panfrost/pan_resource.c   |   4 +-
 src/gallium/drivers/panfrost/pan_scoreboard.c |  20 +-
 src/gallium/drivers/panfrost/pan_screen.c |   2 +-
 src/gallium/drivers/panfrost/pan_screen.h |   6 +-
 src/gallium/drivers/panfrost/pan_sfbd.c   |  36 ++--
 src/gallium/drivers/panfrost/pan_varyings.c   |   2 +-
 17 files changed, 234 insertions(+), 228 deletions(-)

-- 
2.21.0

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

[Mesa-dev] [PATCH 1/4] panfrost: Add transient BOs to job batches

[Boris Brezillon]

Memory allocated through panfrost_allocate_transient() is likely to
come from the transient pool. Let's add the BO backing the allocated
memory region to the job batch so the kernel can retain this BO while
jobs are executed.

In practice that has never been a problem because the transient pool
is never shrinked, and even if it was, we still control the lifetime of
the job, so there's no reason for this BO to be freed before the GPU is
done executing the batch. But it still make sense to add the BO for
debugging purpose.

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/panfrost/pan_allocate.c | 2 ++
 src/gallium/drivers/panfrost/pan_drm.c  | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/pan_allocate.c 
b/src/gallium/drivers/panfrost/pan_allocate.c
index f549c864c70b..080f917bccdc 100644
--- a/src/gallium/drivers/panfrost/pan_allocate.c
+++ b/src/gallium/drivers/panfrost/pan_allocate.c
@@ -110,6 +110,8 @@ panfrost_allocate_transient(struct panfrost_context *ctx, 
size_t sz)
 bo = panfrost_create_slab(screen, );
 }
 
+panfrost_job_add_bo(batch, bo);
+
 /* Remember we created this */
 util_dynarray_append(>transient_indices, unsigned, 
index);
 
diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index 8e05fc936b25..1399b1afd48e 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -298,7 +298,6 @@ panfrost_drm_submit_vs_fs_job(struct panfrost_context *ctx, 
bool has_draws)
 
 struct panfrost_job *job = panfrost_get_job_for_fbo(ctx);
 
-/* TODO: Add here the transient pools */
 panfrost_job_add_bo(job, ctx->scratchpad.bo);
 panfrost_job_add_bo(job, ctx->tiler_heap.bo);
 panfrost_job_add_bo(job, job->polygon_list);
-- 
2.21.0

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

[Mesa-dev] [PATCH 4/4] panfrost: Stop passing a ctx to functions being passed a batch

[Boris Brezillon]

The context can be retrieved from batch->ctx.

Signed-off-by: Boris Brezillon 
---
 src/gallium/drivers/panfrost/pan_context.c |  6 +++---
 src/gallium/drivers/panfrost/pan_drm.c |  2 +-
 src/gallium/drivers/panfrost/pan_job.c | 24 ++
 src/gallium/drivers/panfrost/pan_job.h | 11 --
 4 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/src/gallium/drivers/panfrost/pan_context.c 
b/src/gallium/drivers/panfrost/pan_context.c
index 9e7c6ba5c21c..25e23537bc0a 100644
--- a/src/gallium/drivers/panfrost/pan_context.c
+++ b/src/gallium/drivers/panfrost/pan_context.c
@@ -179,7 +179,7 @@ panfrost_clear(
 struct panfrost_context *ctx = pan_context(pipe);
 struct panfrost_job_batch *batch = panfrost_job_get_batch_for_fbo(ctx);
 
-panfrost_job_clear(ctx, batch, buffers, color, depth, stencil);
+panfrost_job_clear(batch, buffers, color, depth, stencil);
 }
 
 static mali_ptr
@@ -906,7 +906,7 @@ panfrost_emit_for_draw(struct panfrost_context *ctx, bool 
with_vertex_data)
 SET_BIT(ctx->fragment_shader_core.unknown2_4, MALI_NO_MSAA, 
!msaa);
 }
 
-panfrost_job_set_requirements(ctx, batch);
+panfrost_job_set_requirements(batch);
 
 if (ctx->occlusion_query) {
 ctx->payloads[PIPE_SHADER_FRAGMENT].gl_enables |= 
MALI_OCCLUSION_QUERY | MALI_OCCLUSION_PRECISE;
@@ -1332,7 +1332,7 @@ panfrost_submit_frame(struct panfrost_context *ctx, bool 
flush_immediate,
 struct pipe_context *gallium = (struct pipe_context *) ctx;
 struct panfrost_screen *screen = pan_screen(gallium->screen);
 
-panfrost_job_submit(ctx, batch);
+panfrost_job_submit(batch);
 
 /* If visual, we can stall a frame */
 
diff --git a/src/gallium/drivers/panfrost/pan_drm.c 
b/src/gallium/drivers/panfrost/pan_drm.c
index e7f1b7225b4a..f9bf9d94dafb 100644
--- a/src/gallium/drivers/panfrost/pan_drm.c
+++ b/src/gallium/drivers/panfrost/pan_drm.c
@@ -355,7 +355,7 @@ panfrost_drm_force_flush_fragment(struct panfrost_context 
*ctx,
 screen->last_fragment_flushed = true;
 
 /* The job finished up, so we're safe to clean it up now */
-panfrost_job_free_batch(ctx, screen->last_batch);
+panfrost_job_free_batch(screen->last_batch);
 }
 
 if (fence) {
diff --git a/src/gallium/drivers/panfrost/pan_job.c 
b/src/gallium/drivers/panfrost/pan_job.c
index b308a1722c66..8ab92bc09fd6 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -54,11 +54,13 @@ panfrost_job_create_batch(struct panfrost_context *ctx)
 }
 
 void
-panfrost_job_free_batch(struct panfrost_context *ctx, struct 
panfrost_job_batch *batch)
+panfrost_job_free_batch(struct panfrost_job_batch *batch)
 {
 if (!batch)
 return;
 
+struct panfrost_context *ctx = batch->ctx;
+
 set_foreach(batch->bos, entry) {
 struct panfrost_bo *bo = (struct panfrost_bo *)entry->key;
 panfrost_bo_unreference(ctx->base.screen, bo);
@@ -193,18 +195,20 @@ panfrost_flush_jobs_writing_resource(struct 
panfrost_context *panfrost,
prsc);
 if (entry) {
 struct panfrost_job_batch *batch = entry->data;
-panfrost_job_submit(panfrost, job);
+panfrost_job_submit(batch);
 }
 #endif
 /* TODO stub */
 }
 
 void
-panfrost_job_submit(struct panfrost_context *ctx, struct panfrost_job_batch 
*batch)
+panfrost_job_submit(struct panfrost_job_batch *batch)
 {
+assert(batch);
+
+struct panfrost_context *ctx = batch->ctx;
 int ret;
 
-assert(batch);
 panfrost_scoreboard_link_batch(batch);
 
 bool has_draws = batch->last_job.gpu;
@@ -230,9 +234,10 @@ panfrost_job_submit(struct panfrost_context *ctx, struct 
panfrost_job_batch *bat
 }
 
 void
-panfrost_job_set_requirements(struct panfrost_context *ctx,
-  struct panfrost_job_batch *batch)
+panfrost_job_set_requirements(struct panfrost_job_batch *batch)
 {
+struct panfrost_context *ctx = batch->ctx;
+
 if (ctx->rasterizer && ctx->rasterizer->base.multisample)
 batch->requirements |= PAN_REQ_MSAA;
 
@@ -334,13 +339,14 @@ pan_pack_color(uint32_t *packed, const union 
pipe_color_union *color, enum pipe_
 }
 
 void
-panfrost_job_clear(struct panfrost_context *ctx,
-   struct panfrost_job_batch *batch,
+panfrost_job_clear(struct panfrost_job_batch *batch,
unsigned buffers,
const union pipe_color_union *color,
double depth, unsigned stencil)
 
 {
+struct panfrost_context *ctx = batch->ctx;
+
 if (buffers & PIPE_CLEAR_COLOR) {
 for (unsigned i = 0; i < PIPE_MAX_COLOR_BUFS; ++i) {
 if (!(buffers & 

Re: [Mesa-dev] Switching to Gitlab Issues instead of Bugzilla?

[Chris Wilson]

Quoting Daniel Stone (2019-08-30 14:13:08)
> Hi,
> 
> On Thu, 29 Aug 2019 at 21:35, Chris Wilson  wrote:
> > Quoting Kristian Høgsberg (2019-08-29 21:20:12)
> > > On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson  
> > > wrote:
> > > > Quoting Kenneth Graunke (2019-08-29 19:52:51)
> > > > > - Moving bug reports between the kernel and Mesa would be harder.
> > > > >   We would have to open a bug in the other system.  (Then again,
> > > > >   moving bugs between Mesa and X or Wayland would be easier...)
> > > >
> > > > All that I ask is that we move the kernel bugzilla along with it. Trying
> > > > to keep abreast of the bugs in the whole stack is important. Fwiw, the
> > > > kernel contains the 
> > > > https:bugs.freedesktop.org/enter_bug.cgi?product=DRI
> > > > URL so would need some redirection for a few years...
> > >
> > > Would Rob's suggestion of creating a placeholder drm kernel repo for
> > > the purpose of issue tracking work for you?
> 
> We can definitely get placeholder DRM repos and move those issues too.
> And set up redirects.
> 
> (To be honest, rather than one-by-one redirects, my thought with
> Bugzilla was just to statically scrape all the bug pages and leave
> them as read-only static copies frozen in amber for time eternal. I'd
> welcome help from anyone who had the time to figure out the scripting
> and Apache runes required to make those be proper HTTP redirects, but
> am definitely not going to be able to do that myself.)

I'd be happy with a static page telling them how to file a new issue on
gitlab.

> > I think so. I just want a list of all bugs that may affect the code I'm
> > working on, wherever they were filed. I have a search in bugs.fdo, I
> > just need instructions on how to get the same from gitlab, hopefully in
> > a compact format.
> 
> It's not clear to me what you need. Can you please give more details?

At the moment, I always have open a couple of searches which are basically

Product: DRI, Mesa, xorg
Component: Driver/intel, Drivers/DRI/i830, Drivers/DRI/i915, Drivers/DRI/i965, 
Drivers/Vulkan/intel, DRM/AMDgpu, DRM/Intel, IGT
Status: NEW, ASSIGNED, REOPENED, NEEDINFO

I would like a similar way of getting a quick glance at the issues under
discussion and any new issues across the products -- basically I want a
heads up in case I've broken something, however subtle. And sometimes
you just need to trawl through every bug in case you missed something.

> If you want cross-component search results in a single list, that's
> not really something we can do today, and I don't know if it would
> land any time soon. You can however subscribe to particular issue
> labels, and when you see something that catches your eye add a 'todo'
> for it, then the main UI shows all your outstanding todos, including
> where people have mentioned you etc.

One thing we did for bugzilla was set the default QA component to a
mailing list, so we had a single place to subscribe to get all the spam.
I presume something similar would be available to subscribe to every
issue across a range of categories.

> > The issue URL will also need to be stable so that we can include it in
> > commits. From a glance,
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/861,
> > looks like it will be adjusted if it ever gets moved.
> 
> Sorry, 'moved' how? If you mean moved between components, yes the
> issue will move and there will be a new URL for that. However, going
> to that old URL will auto-redirect you to the new one.

That's fine. I was just worrying about old links becoming stale, or
worse replaced, if the issue was moved (or whatever).
-Chris
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111493] In the game The Surge (378540) - textures disappear then appear again when I change the camera angle view

[bugzilla-daemon]

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

James B  changed:

   What|Removed |Added

 CC||lejims...@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] Switching to Gitlab Issues instead of Bugzilla?

[Daniel Stone]

Hi,

On Thu, 29 Aug 2019 at 21:35, Chris Wilson  wrote:
> Quoting Kristian Høgsberg (2019-08-29 21:20:12)
> > On Thu, Aug 29, 2019 at 12:44 PM Chris Wilson  
> > wrote:
> > > Quoting Kenneth Graunke (2019-08-29 19:52:51)
> > > > - Moving bug reports between the kernel and Mesa would be harder.
> > > >   We would have to open a bug in the other system.  (Then again,
> > > >   moving bugs between Mesa and X or Wayland would be easier...)
> > >
> > > All that I ask is that we move the kernel bugzilla along with it. Trying
> > > to keep abreast of the bugs in the whole stack is important. Fwiw, the
> > > kernel contains the 
> > > https:bugs.freedesktop.org/enter_bug.cgi?product=DRI
> > > URL so would need some redirection for a few years...
> >
> > Would Rob's suggestion of creating a placeholder drm kernel repo for
> > the purpose of issue tracking work for you?

We can definitely get placeholder DRM repos and move those issues too.
And set up redirects.

(To be honest, rather than one-by-one redirects, my thought with
Bugzilla was just to statically scrape all the bug pages and leave
them as read-only static copies frozen in amber for time eternal. I'd
welcome help from anyone who had the time to figure out the scripting
and Apache runes required to make those be proper HTTP redirects, but
am definitely not going to be able to do that myself.)

> I think so. I just want a list of all bugs that may affect the code I'm
> working on, wherever they were filed. I have a search in bugs.fdo, I
> just need instructions on how to get the same from gitlab, hopefully in
> a compact format.

It's not clear to me what you need. Can you please give more details?
If you want cross-component search results in a single list, that's
not really something we can do today, and I don't know if it would
land any time soon. You can however subscribe to particular issue
labels, and when you see something that catches your eye add a 'todo'
for it, then the main UI shows all your outstanding todos, including
where people have mentioned you etc.

> The issue URL will also need to be stable so that we can include it in
> commits. From a glance,
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/861,
> looks like it will be adjusted if it ever gets moved.

Sorry, 'moved' how? If you mean moved between components, yes the
issue will move and there will be a new URL for that. However, going
to that old URL will auto-redirect you to the new one.

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

[Mesa-dev] [Bug 111522] [bisected] Supraland no longer start

[bugzilla-daemon]

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

--- Comment #5 from Eric Engestrom  ---
Alright, you'll need to add this to your ~/.drirc on top of MR !1819:









If you could test other UE4 games too that would be great :)

-- 
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 111522] [bisected] Supraland no longer start

[bugzilla-daemon]

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

--- Comment #4 from MWATTT  ---
The binary is "Supraland-Linux-Shipping"
It may also affect others UE4 games. Haven't tested yet

-- 
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 111522] [bisected] Supraland no longer start

[bugzilla-daemon]

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

Eero Tamminen  changed:

   What|Removed |Added

 Blocks||111444


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=111444
[Bug 111444] [TRACKER] Mesa 19.2 release tracker
-- 
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 111444] [TRACKER] Mesa 19.2 release tracker

[bugzilla-daemon]

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

Eero Tamminen  changed:

   What|Removed |Added

 Depends on||111522


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=111522
[Bug 111522] [bisected] Supraland no longer start
-- 
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 111522] [bisected] Supraland no longer start

[bugzilla-daemon]

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

--- Comment #3 from Eero Tamminen  ---
(In reply to Eric Engestrom from comment #2)
> Could you try if this fixes your issue?
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1819

Not alone, as that MR enables the workaround only for gfxbench (testfw_app
binary name).

What binary name Supraland uses?

-- 
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 111444] [TRACKER] Mesa 19.2 release tracker

[bugzilla-daemon]

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

Denis  changed:

   What|Removed |Added

 CC||denys.kos...@globallogic.co
   ||m, emil.l.veli...@gmail.com

--- Comment #1 from Denis  ---
Emil, please review this ticket according to "blocking" for release. Pavlo sent
a question according to it about 3 weeks ago, in the mailing threads, but
possibly it was lost.

https://bugs.freedesktop.org/show_bug.cgi?id=110814 - this ticket is regression
from 19 mesa version, there is a patch, which fixed an issue (me and reporter
tested it, but would be great to review it and merge, if it is ok)

-- 
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 111522] [bisected] Supraland no longer start

[bugzilla-daemon]

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

Eric Engestrom  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Eric Engestrom  ---
Could you try if this fixes your issue?
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1819

-- 
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 106348] Vulkan apps fail when run under Intel DDX on Xserver 1.20-rc5+

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

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

Re: [Mesa-dev] [PATCH 4/4] scons: Make GCC builds stricter.

[Michel Dänzer]

On 2019-08-28 1:56 p.m., Jose Fonseca wrote:
> Hi Michel,
> 
>> Good to see you guys starting to take better advantage of the
>> GitLab CI pipeline.
> 
> Gitlab CI integration is complicated (very configurable), but I can
> tell from my experience with my own personal Github projects that
> having tests run during PRs are a god send.

Yeah.


>> With my last name spelled correctly Dänzer or Daenzer,
> 
> Oops.  I worried about getting the "ae" right and forgot the "n"..
> m(_ _)m

No worries, I appreciate your effort! :)


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 19.2.0 release plan

[apinheiro]

On 30/8/19 0:52, apinheiro wrote:


On 7/8/19 10:44, Emil Velikov wrote:

Hi all,



Hi Emil,




On Wed, 31 Jul 2019 at 09:37, Emil Velikov  
wrote:

Hi all,

Here is the tentative release plan for 19.2.0.

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

  Aug 06 2019 - Feature freeze/Release candidate 1
  Aug 13 2019 - Release candidate 2
  Aug 20 2019 - Release candidate 3
  Aug 27 2019 - Release candidate 4/final release


With multiple teams finalising the final features for their drivers,
I've decided to push the branch point by one week.


Are we still in time to add this v3d patch:

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

It is not still on master, but I would try to get it merged on master 
tomorrow Friday. 



Just landed on master.


But if there isn't any possibility to get it included on 19.2.X at 
this point, I would not bother anyone to get an extra Rb/Ack.


Thanks in advance, and sorry if at this point the answer is evident




I would like to remind teams that they are welcome to merge
functionality early and keep it disabled by default.
This way they can address outstanding issues and enable, during the
stabilisation period.

Thanks
Emil
___
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] Switching to Gitlab Issues instead of Bugzilla?

[Michel Dänzer]

On 2019-08-29 9:36 p.m., Rob Clark wrote:
> On Thu, Aug 29, 2019 at 12:02 PM Kenneth Graunke  
> wrote:
>>
>> - Moving bug reports between the kernel and Mesa would be harder.
>>   We would have to open a bug in the other system.  (Then again,
>>   moving bugs between Mesa and X or Wayland would be easier...)
> 
> If that was a concern, we could setup a kernel gitlab project that has
> an empty git repository (at least until we are ready to move drm git
> tree).

Yeah, the obvious solution for this is to migrate everything that's left
together (which is what I've been asking all along :).

Given that, I'm in favour.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 111522] [bisected] Supraland no longer start

[bugzilla-daemon]

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

--- Comment #1 from Eero Tamminen  ---
Related to bug 110765 ?

-- 
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] Switching to Gitlab Issues instead of Bugzilla?

[Samuel Pitoiset]

+1

On 8/29/19 8:52 PM, Kenneth Graunke wrote:

Hi all,

As a lot of you have probably noticed, Bugzilla seems to be getting a
lot of spam these days - several of us have been disabling a bunch of
accounts per day, sweeping new reports under the rug, hiding comments,
etc.  This bug spam causes emails to be sent (more spam!) and then us
to have to look at ancient bugs that suddenly have updates.

I think it's probably time to consider switching away from Bugzilla.
We are one of the few projects remaining - Mesa, DRM, and a few DDX
drivers are still there, but almost all other projects are gone:

https://bugs.freedesktop.org/enter_bug.cgi

Originally, I was in favor of retaining Bugzilla just to not change too
many processes all at once.  But we've been using Gitlab a while now,
and several of us have been using Gitlab issues in our personal repos;
it's actually pretty nice.

Some niceities:

- Bug reporters don't necessarily need to sign up for an account
   anymore.  They can sign in with their Gitlab.com, Github, Google,
   or Twitter accounts.  Or make one as before.  This may be nicer for
   reporters that don't want to open yet another account just to report
   an issue to us.

- Anti-spam support is actually maintained.  Bugzilla makes it near
   impossible to actually delete garbage, Gitlab makes it easier.  It
   has a better account creation hurdle than Bugzilla's ancient captcha,
   and Akismet plug-ins for handling spam.

- The search interface is more modern and easier to use IMO.

- Permissions & accounts are easier - it's the same unified system.

- Easy linking between issues and MRs - mention one in the other, and
   both get updated with cross-links so you don't miss any discussion.

- Milestone tracking

   - This could be handy for release trackers - both features people
 want to land, and bugs blocking the release.

   - We could also use it for big efforts like direct state access,
 getting feature parity with fglrx, or whatnot.

- Khronos switched a while ago as well, so a number of us are already
   familiar with using it there.

Some cons:

- Moving bug reports between the kernel and Mesa would be harder.
   We would have to open a bug in the other system.  (Then again,
   moving bugs between Mesa and X or Wayland would be easier...)

What do people think?  If folks are in favor, Daniel can migrate
everything for us, like he did with the other projects.  If not,
I'd like to hear what people's concerns are.

--Ken

___
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