On Thu, 5 Sep 2019 19:28:04 -0400
Alyssa Rosenzweig wrote:
> Ah, ignore my previous comment. Could we squash this into the patch that
> added the PAN_SHARED_BO_RW define?
Absolutely (I don't know why I did that separately).
>
> On Thu, Sep 05, 2019 at 09:41:48PM +0200, Boris Brezillon wrote:
>
Reviewed-by: Jose Fonseca
From: srol...@vmware.com
Sent: Friday, September 6, 2019 03:13
To: Jose Fonseca ; airl...@redhat.com
; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] llvmpipe: fix CALLOC vs. free mismatches
From: Roland Sche
On Fri, 6 Sep 2019 at 12:13, wrote:
>
> From: Roland Scheidegger
>
> Should fix some issues we're seeing. And use REALLOC instead of realloc.
Oops sorry
Reviewed-by: Dave Airlie
> ---
> src/gallium/drivers/llvmpipe/lp_cs_tpool.c | 6 +++---
> src/gallium/drivers/llvmpipe/lp_state_cs.c | 3 ++-
From: Roland Scheidegger
Should fix some issues we're seeing. And use REALLOC instead of realloc.
---
src/gallium/drivers/llvmpipe/lp_cs_tpool.c | 6 +++---
src/gallium/drivers/llvmpipe/lp_state_cs.c | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/llvm
On Wed, Sep 4, 2019 at 1:42 PM Eric Anholt wrote:
>
> If you haven't seen this MR:
>
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1632
>
> I feel ready to enable CI of freedreno on Mesa MRs. There are some docs
> here:
>
> https://gitlab.freedesktop.org/mesa/mesa/blob/e81a2d3b4024065
Ah, ignore my previous comment. Could we squash this into the patch that
added the PAN_SHARED_BO_RW define?
On Thu, Sep 05, 2019 at 09:41:48PM +0200, Boris Brezillon wrote:
> Should already be added in panfrost_draw_vbo() and panfrost_clear(),
> no need to add it here too.
>
> Signed-off-by: Bori
> --- a/src/gallium/drivers/panfrost/pan_fragment.c
> +++ b/src/gallium/drivers/panfrost/pan_fragment.c
> @@ -44,7 +44,7 @@ panfrost_initialize_surface(
> rsrc->slices[level].initialized = true;
>
> assert(rsrc->bo);
> -panfrost_batch_add_bo(batch, rsrc->bo);
> +
> panfrost_draw_vbo() Might call the primeconvert/without_prim_restart
s/M/m/ s/prime/prim/ but R-b
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b
On Thu, Sep 05, 2019 at 09:41:44PM +0200, Boris Brezillon wrote:
> So we can emit SET_VALUE jobs for a batch that's not currently bound
> to the context.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_scoreboard.c | 6 ++
> 1 file changed, 2 insertions(+), 4
R-b
On Thu, Sep 05, 2019 at 09:41:43PM +0200, Boris Brezillon wrote:
> We'll soon be able to flush a batch that's not currently bound to the
> context, which means ctx->pipe_framebuffer will not necessarily be the
> FBO targeted by the wallpaper draw. Let's prepare for this case and
> use ctx->wal
Very happily R-b, this is a good cleanup :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> We need that if we want to emit CMDs to a job that's not currenlty
Nit but s/emit CMDs/upload transient buffers/; s/job/batch/;
s/currenlty/currently/
Midgard/Bifrost don't have commands (c.f. Utgard), just descriptors and
data buffers. We just call the stuff we submit with the batch "the
comma
> +out:
> +if (ctx->batch == batch)
> +panfrost_invalidate_frame(ctx);
Could you explain the logic a bit? I think the idea is that "if this is
the bound batch, the panfrost_context parameters are relevant so
submitting it invalidates those paramaters, but if it's not bound,
Reviewed-by: Alyssa Rosenzweig
On Thu, Sep 05, 2019 at 09:41:39PM +0200, Boris Brezillon wrote:
> panfrost_flush() is about to be reworked to flush all pending batches,
> but we want the fence to block on the last one. Let's move the fence
> creation logic in panfrost_flush() to prepare for this
> Will document that.
+1
> Evict won't help here as memory will only be released after the jobs
> are done using it. And madvise doesn't help either, for the same reason.
Ah-ha, I understand the distinction; thank you.
> The behavior hasn't changed regarding allocation failures: it's still
> an
I've added it to the staging/19.2 branch, thanks.
Dylan
Quoting apinheiro (2019-09-05 01:21:23)
>
> On 5/9/19 0:57, Dylan Baker wrote:
>
> Hi List,
>
> I'd like to announce the availability of mesa-19.2.0-rc2. This is the
> culmination of two weeks worth of work. Due to maintenance
> > I notice this had a print to stderr before with an assertion out, but
> > now it fails silently. Is this change of behaviour intentional?
>
> It is.
Alright! :-)
> > BO
> > creation would previously return a valid BO gauranteed. This is no
> > longer so obviously true -- although I see we l
https://bugs.freedesktop.org/show_bug.cgi?id=111522
--- Comment #11 from MWATTT ---
I can confirm that the last MR + .drirc solves this issue, at least on radv.
Anv may have additional issues.
May be unrelated but I have a lot of
"SPIR-V WARNING:
In file ../src/compiler/spirv/spirv_to_nir.c:
https://bugs.freedesktop.org/show_bug.cgi?id=111549
--- Comment #2 from Roland Scheidegger ---
This cpu doesn't support sse 4.1, and some of the fallbacks for rounding aren't
quite kosher for the sake of simplicity / performance (I believe the format
tests fail for similar reason).
I suppose it c
On Thu, 5 Sep 2019 16:43:23 -0400
Alyssa Rosenzweig wrote:
> > +bool
> > +panfrost_bo_wait(struct panfrost_bo *bo, int64_t timeout_ns)
> > +{
> > +struct drm_panfrost_wait_bo req = {
> > +.handle = bo->gem_handle,
> > + .timeout_ns = timeout_ns,
> > +};
>
https://bugs.freedesktop.org/show_bug.cgi?id=111522
Lionel Landwerlin changed:
What|Removed |Added
Assignee|fdo-b...@engestrom.ch |mesa-dev@lists.freedesktop.
On Thu, 5 Sep 2019 16:31:04 -0400
Alyssa Rosenzweig wrote:
> > +static struct panfrost_bo *
> > +panfrost_bo_alloc(struct panfrost_screen *screen, size_t size,
> > + uint32_t flags)
> > +{
> ...
> > +ret = drmIoctl(screen->fd, DRM_IOCTL_PANFROST_CREATE_BO,
> > &create_
R-b
On Thu, Sep 05, 2019 at 09:41:38PM +0200, Boris Brezillon wrote:
> Rename panfrost_is_scanout() into panfrost_batch_is_scanout(), pass it
> a batch instead of a context and move the code to pan_job.c.
>
> With this in place, we can now test if a batch is targeting a scanout
> FB even if this
Fair enough, R-b
On Thu, Sep 05, 2019 at 09:41:37PM +0200, Boris Brezillon wrote:
> Will be replaced by something similar but using a BOs as keys instead
> of resources.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_context.h | 3 --
> src/gallium/drivers/panfrost
Hrm. I'm not sure I'm 100% comfortable using a Gallium object for this,
since many of these properties could be inferred, but this is still
probably the best compromise for now, so R-b.
On Thu, Sep 05, 2019 at 09:41:36PM +0200, Boris Brezillon wrote:
> This way we have all the fb_state information
> +bool
> +panfrost_bo_wait(struct panfrost_bo *bo, int64_t timeout_ns)
> +{
> +struct drm_panfrost_wait_bo req = {
> +.handle = bo->gem_handle,
> + .timeout_ns = timeout_ns,
> +};
> +int ret;
> +
> +ret = drmIoctl(bo->screen->fd, DRM_IOCT
> +static struct panfrost_bo *
> +panfrost_bo_alloc(struct panfrost_screen *screen, size_t size,
> + uint32_t flags)
> +{
...
> +ret = drmIoctl(screen->fd, DRM_IOCTL_PANFROST_CREATE_BO, &create_bo);
> +if (ret)
> +return NULL;
I notice this had a pr
R-b
On Thu, Sep 05, 2019 at 09:41:33PM +0200, Boris Brezillon wrote:
> So we can move all the BO logic into this file instead of having it
> spread over pan_resource.c, pan_drm.c and pan_bo_cache.c.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/meson.build
Glad to see this gone, thank you! R-b
On Thu, Sep 05, 2019 at 09:41:32PM +0200, Boris Brezillon wrote:
> The last users have been converted to use plain BOs. Let's get rid of
> this abstraction. We can always consider adding it back if we need it
> at some point.
>
> Signed-off-by: Boris Brezillo
Reviewed-by: Alyssa Rosenzweig
I wish static analysis and friends would identify these automatically.
On Thu, Sep 05, 2019 at 09:41:31PM +0200, Boris Brezillon wrote:
> Some fields in panfrost_context are unused (probably leftovers from
> previous refactor). Let's get rid of them.
>
> Signed-of
Reviewed-by: Alyssa Rosenzweig
On Thu, Sep 05, 2019 at 09:41:30PM +0200, Boris Brezillon wrote:
> ctx->{scratchpad,tiler_heap,tiler_dummy} are allocated using
> panfrost_drm_allocate_slab() but they never any of the SLAB-based
> allocation logic. Let's convert those fields to plain BOs.
>
> Sign
Reviewed-by: Alyssa Rosenzweig
> Right now, the transient memory allocator implements its own BO caching
> mechanism, which is not really needed since we already have a generic
> BO cache. Let's simplify things a bit.
>
> Signed-off-by: Boris Brezillon
> Alyssa Rosenzweig
> ---
> Changes in v3
Reviewed-by: Alyssa Rosenzweig
On Thu, Sep 05, 2019 at 09:41:28PM +0200, Boris Brezillon wrote:
> The context can be retrieved from batch->ctx.
>
> Signed-off-by: Boris Brezillon
> Alyssa Rosenzweig
> Reviewed-by: Daniel Stone
> ---
> Changes in v3:
> * Collect R-bs
>
> Changes in v2:
> * s/
Reviewed-by: Alyssa Rosenzweig
On Thu, Sep 05, 2019 at 09:41:27PM +0200, Boris Brezillon wrote:
> Given the function name it makes more sense to pass it a job batch
> directly.
>
> Signed-off-by: Boris Brezillon
> Alyssa Rosenzweig
> Reviewed-by: Daniel Stone
> ---
> Changes in v3:
> * Collec
Reviewed-by: Alyssa Rosenzweig
On Thu, Sep 05, 2019 at 09:41:26PM +0200, Boris Brezillon wrote:
> 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 t
panfrost_flush() is about to be reworked to flush all pending batches,
but we want the fence to block on the last one. Let's move the fence
creation logic in panfrost_flush() to prepare for this situation.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 13 +++
Should already be added in panfrost_draw_vbo() and panfrost_clear(),
no need to add it here too.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_fragment.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_fragment.c
b/src/gallium/drivers
Batch ordering is most of the time enforced by the resources they are
reading/writing from/to. This patch adds some new helpers to keep track
of that and modifies the existing add_bo() helper to pass flags encoding
the type of access a batch intends to do on this BO.
Since all resources are backed
All dEQP-GLES2.functional.fbo.render.texsubimage.* tests are now
passing.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/ci/expected-failures.txt | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt
b/src/gallium/drivers/p
So we can emit SET_VALUE jobs for a batch that's not currently bound
to the context.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_scoreboard.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_scoreboard.c
b/src/gal
We need that if we want to emit CMDs to a job that's not currenlty
bound to the context, which in turn will be needed if we want to relax
the job serialization we have right now (only flush jobs when we need
to: on a flush request, or when one job depends on results of other
jobs).
Signed-off-by:
panfrost_attach_vt_xxx() functions are now passed a batch, and the
generated FB desc is kept in panfrost_batch so we can switch FBs
without forcing a flush. The postfix->framebuffer field is restored
on the next attach_vt_framebuffer() call if the batch already has an
FB desc.
Signed-off-by: Boris
panfrost_draw_vbo() Might call the primeconvert/without_prim_restart
helpers which will enter the ->draw_vbo() again. Let's delay
payloads[].offset_start initialization so we don't initialize them
twice.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 6 +++---
1
We are about to patch panfrost_flush() to flush all pending batches,
not only the current one. In order to do that, we need to move the
'flush single batch' code to panfrost_batch_submit().
While at it, we get rid of the existing pipelining logic, which is
currently unused and replace it by an unc
We'll soon be able to flush a batch that's not currently bound to the
context, which means ctx->pipe_framebuffer will not necessarily be the
FBO targeted by the wallpaper draw. Let's prepare for this case and
use ctx->wallpaper_batch in panfrost_blit_wallpaper().
Signed-off-by: Boris Brezillon
--
Rename panfrost_is_scanout() into panfrost_batch_is_scanout(), pass it
a batch instead of a context and move the code to pan_job.c.
With this in place, we can now test if a batch is targeting a scanout
FB even if this batch is not bound to the context.
Signed-off-by: Boris Brezillon
---
src/gal
* BO related functions/structs are now exposed in pan_bo.h instead of
being spread in pan_screen.h/pan_resource.h
* cache related functions are no longer exposed
* panfrost_bo now has a ->screen field to avoid passing screen around
* the function names are made consistent (all BO related function
We adjust the code to explicitly request flush of batches accessing
BOs they care about. Thanks to that, we can get rid of the implicit
serialization done in panfrost_batch_submit() and
panfrost_set_framebuffer_state(). Finally, panfrost_flush() is
changed to to flush all pending batches.
Signed-o
So we can emit such jobs to a batch that's not currently bound to the
context.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 36 ++---
src/gallium/drivers/panfrost/pan_context.h | 10 +++---
src/gallium/drivers/panfrost/pan_drm.c | 2 +-
The last users have been converted to use plain BOs. Let's get rid of
this abstraction. We can always consider adding it back if we need it
at some point.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.h | 13
src/gallium/drivers/panfrost/pan_drm.c
So we can move all the BO logic into this file instead of having it
spread over pan_resource.c, pan_drm.c and pan_bo_cache.c.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/meson.build | 2 +-
src/gallium/drivers/panfrost/{pan_bo_cache.c => pan_bo.c} | 0
2 file
ctx->{scratchpad,tiler_heap,tiler_dummy} are allocated using
panfrost_drm_allocate_slab() but they never any of the SLAB-based
allocation logic. Let's convert those fields to plain BOs.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 29 --
src
Some fields in panfrost_context are unused (probably leftovers from
previous refactor). Let's get rid of them.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.h
b/src/ga
Will be replaced by something similar but using a BOs as keys instead
of resources.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h | 3 --
src/gallium/drivers/panfrost/pan_job.c | 38 --
src/gallium/drivers/panfrost/pan_job.h | 8 -
This way we have all the fb_state information directly attached to a
batch and can pass only the batch to functions emitting CMDs, which is
needed if we want to be able to queue CMDs to a batch that's not
currently bound to the context.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panf
This is needed if we want to free the panfrost_batch object at submit
time in order to not have to GC the batch on the next job submission.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 68 ++-
src/gallium/drivers/panfrost/pan_bo.h | 2 +
2 f
Right now, the transient memory allocator implements its own BO caching
mechanism, which is not really needed since we already have a generic
BO cache. Let's simplify things a bit.
Signed-off-by: Boris Brezillon
Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
Changes in v2:
* None
---
src/g
Given the function name it makes more sense to pass it a job batch
directly.
Signed-off-by: Boris Brezillon
Alyssa Rosenzweig
Reviewed-by: Daniel Stone
---
Changes in v3:
* Collect R-bs
Changes in v2:
* s/panfrost_job_get_batch_for_fbo/panfrost_get_batch_for_fbo/
* s/panfrost_job_batch/panfros
Hello,
This is actually a v1 expect for patches 1 to 4, which have already
been submitted separately.
The goal here is to rework the panfrost_job logic (renamed
panfrost_batch at the beginning of the series) to avoid unnecessary
flushes when we can.
The new solution is based on the VC4/V3D imple
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
---
Changes in v3:
The context can be retrieved from batch->ctx.
Signed-off-by: Boris Brezillon
Alyssa Rosenzweig
Reviewed-by: Daniel Stone
---
Changes in v3:
* Collect R-bs
Changes in v2:
* s/panfrost_job_get_batch_for_fbo/panfrost_get_batch_for_fbo/
* s/panfrost_job_batch/panfrost_batch/g
---
src/gallium/driv
https://bugs.freedesktop.org/show_bug.cgi?id=111529
--- Comment #6 from Jean Hertel ---
Curious, as for me it keeps failing to recognize the extension, both with my
own compiled version and with Arch-provided version.
Any other idea what could be wrong?
--
You are receiving this mail because:
On Thursday, 2019-09-05 17:58:22 +0200, Mauro Rossi wrote:
> Hi Eric, Emil,
> we have Tapani ok, in my understanding
>
> Please follow up on this one
Sure, feel free to push the android revert until we can figure out a fix:
Acked-by: Eric Engestrom
> Mauro
>
> On Fri, Aug 16, 2019 at 4:29 AM
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Ian Romanick changed:
What|Removed |Added
Depends on||110295
Referenced Bugs:
https://bugs.f
https://bugs.freedesktop.org/show_bug.cgi?id=111522
Mark Janes changed:
What|Removed |Added
Status|NEEDINFO|ASSIGNED
Assignee|mesa-dev@lists
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Bug 111444 depends on bug 111384, which changed state.
Bug 111384 Summary: [BXT/Iris] (recoverable) GPU hang in SynMark compute CSCloth
https://bugs.freedesktop.org/show_bug.cgi?id=111384
What|Removed |Added
--
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Mark Janes changed:
What|Removed |Added
Depends on||111405
Referenced Bugs:
https://bugs.fre
Hi Eric, Emil,
we have Tapani ok, in my understanding
Please follow up on this one
Mauro
On Fri, Aug 16, 2019 at 4:29 AM Mauro Rossi wrote:
> Hi Tapani, Eric,
>
> On Thu, Aug 15, 2019 at 1:00 PM Tapani Pälli
> wrote:
>
>>
>> On 8/15/19 12:52 PM, Mauro Rossi wrote:
>> > Hi Tapani,
>> >
>> > On
https://bugs.freedesktop.org/show_bug.cgi?id=111444
Mark Janes changed:
What|Removed |Added
Depends on|110507 |
Referenced Bugs:
https://bugs.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=111522
--- Comment #7 from Lionel Landwerlin ---
Just to confirm, is this the title causing problems? :
https://store.steampowered.com/app/813630/Supraland/
--
You are receiving this mail because:
You are the assignee for the bug.
On 5/9/19 0:57, Dylan Baker wrote:
Hi List,
I'd like to announce the availability of mesa-19.2.0-rc2. This is the
culmination of two weeks worth of work. Due to maintenance the Intel CI is not
running, but I've built and tested this locally. I would have preferred to get
more testing, but being
https://bugs.freedesktop.org/show_bug.cgi?id=111454
--- Comment #8 from Gert Wollny ---
Virgl sends the TGSI as text so I think we are save.
At least Dave and me we run the patches through piglit and the virglrenderer CI
on a hardware host (the fdo one only used softpipe) and there all passes a
73 matches
Mail list logo
