It doesn't really make sense, since we don't have special texture
coordinate varyings, but it'll make some code simpler for XFB and it
doesn't hurt us, even if I lose a bit of my soul setting it.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_scree
support for geometry *or* tessellation
shaders, despite advertising support. They get compiled to *massive*
compute shaders. How's that for checkbox compliance?
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_varyings.c | 254 +---
1 file changed, 217 insert
Patch #1 is R-b
On Fri, Aug 09, 2019 at 01:53:12PM -0600, Rob Herring wrote:
> Sync the panfrost_drm.h UAPI header with the latest from the kernel.
> This adds madvise ioctl and GPU feature params.
>
> Signed-off-by: Rob Herring
> ---
> include/drm-uapi/panfrost_drm.h | 61 ++
I'm not one to care, but fwiw, spacing is inconsistent..?
> + if (!ret && !madv.retained) {
What's the logic here? (What does a 0/!0 return code mean here?) I'm
wondering if this meant to be ||?
Or is the idea that an older kernel will have ret!=0 (since it doesn't
recognize
/gallium/drivers/panfrost/pan_bo_cache.c
> index 7378d0a8abea..239ea0b46cb2 100644
> --- a/src/gallium/drivers/panfrost/pan_bo_cache.c
> +++ b/src/gallium/drivers/panfrost/pan_bo_cache.c
> @@ -23,6 +23,8 @@
> * Authors (Collabora):
> * Alyssa Rosenzweig
> */
> +#incl
> +++ b/src/panfrost/midgard/midgard_opt_perspective.c
> @@ -71,7 +71,7 @@ midgard_opt_combine_projection(compiler_context *ctx,
> midgard_block *block)
> unsigned frcp_component = 0;
> unsigned frcp_from = 0;
>
> -mir_foreach_instr_in_block_safe
Could you explain a little bit more why this is neded? What do these
helpers do that the generic list.h helpers can't? Would it be possible
to extend the shared list.h helpers (might this contain functionality
interesting to other drivers as well)?
What about the new next_ins argument -- should th
> I don't see any remove_ins()/insert_before() call in there. Do you see
> any reason for using the _safe() variant here?
Er, I think I meant the outer loop, which has a remove/insert pair at
the bottom to change the current instruction.
signature.asc
Description: PGP signature
_
> > Could you explain a little bit more why this is neded? What do these
> > helpers do that the generic list.h helpers can't?
>
> The _safe attribute in generic helpers is just about handling the case
> where the current item is removed from the list (or a new one is
> inserted and you want to sk
> > > Would it be possible
> > > to extend the shared list.h helpers (might this contain functionality
> > > interesting to other drivers as well)?
> >
> > Hm, not without making them more complex I'm afraid. And since
> > most users are happy with the current implementation I'm not entirely
> >
Reviewed-by: Alyssa Rosenzweig
On Tue, Aug 13, 2019 at 08:35:21PM +0200, Boris Brezillon wrote:
> The !job test is done after dereferencing the job pointer, which means
> it's either always false or we have a NULL pointer exception.
>
> Replace that test by an assert() at the
This will allow us to get some level of automatic memory management.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_compile.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/src/panfrost/midgard/midgard_compile.c
b/src
A block can't have more.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index 942d288a326..61fe8a92b2e 100644
--- a/src/panfrost/mi
This series was motivated by RA failures in a Krita shader. The fix --
rewriting liveness analysis entirely -- turned out to be rather more
involved than I expected. Ah well, I think it was worth it (as the issue
fixed really does apply to GLES2 even, it was just missed in dEQP).
Alyssa
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index a78d933e9e4..6f953d48cb8 100644
--- a/src/panfrost/midgard/compiler.h
+++ b/src/panfrost/midgard
It's always been ambiguous which they are, but their primary register is
their output, not their input; therefore, they are loads.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/helpers.h | 5 ++---
src/panfrost/midgard/midgard.h | 9 -
src/panfrost/mi
If we need to lower a move for a read from a vec2 texture coordinate, we
shouldn't write zw, even incidentally.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_ra.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/panfrost/midgard/midgard_ra.c
b/src/panfrost/mi
Fixes shaders with control flow like:
out = 0;
if (A) {
if (B)
out = texture(A, ...)
} else {
out = texture(B, ...)
}
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_ra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_compile.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/panfrost/midgard/midgard_compile.c
b/src/panfrost/midgard/midgard_compile.c
index 73ba3173eb3..705c3b32778 100644
--- a/src/panfrost/midgard/midgard_compile.c
al registers in shared programs: 341 -> 338 (-0.88%)
registers in affected programs: 9 -> 6 (-33.33%)
helped: 3
HURT: 0
helped stats (abs) min: 1 max: 1 x̄: 1.00 x̃: 1
helped stats (rel) min: 33.33% max: 33.33% x̄: 33.33% x̃: 33.33%
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/mi
Just as a sanity check.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_print.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/panfrost/midgard/midgard_print.c
b/src/panfrost/midgard/midgard_print.c
index 240780a1f7d..1f8bd12680e 100644
--- a/src/panfrost
If there's a nontrivial swizzle fed into an extra (shortened) argument,
we bail on copyprop. No glmark changes (since it doesn't use fancy
texturing/loads).
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_opt_copy_prop.c | 24 +---
1 file changed, 21
The exit block is gauranteed to be empty, signaling the end of the
program.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index fb47c3475bf
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 1 +
src/panfrost/midgard/mir.c | 9 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index 1fddd3f1fe8..1cbebdbef2e 100644
--- a
The texture coordinate for a 2D texture could be a vec2 or a vec3,
depending if it's an array texture or not. If it's vec2 (non-array
texture), we should not reference the z component; otherwise, liveness
analysis will get very confused when z is never written.
Signed-off-by: Alyssa
The exit block has been 'dangling' in the successors graph, so let's
ensure it's linked in.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_compile.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/panfrost/midgard/midg
While we already compute the successors array, for backwards data flow
analysis, it is useful to walk the control flow graph backwards based on
predecessors, so let's compute that information as well.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h| 2 ++
Same issue with liveness analysis. If we store out a vec3, we should not
reference the .w component.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_compile.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/panfrost/midgard/midgard_compile.c
b/src
Better than having pointers flying about.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h| 6 ++
src/panfrost/midgard/midgard_compile.c | 2 ++
src/panfrost/midgard/midgard_print.c | 4 ++--
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src
Now we should be able to walk the control-flow graph naturally.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 8
1 file changed, 8 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index f196389c36a..a78d933e9e4
This is repeated often enough.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index 6f953d48cb8..217ab317090 100644
--- a/src/panfrost/midgard
It's ugly, but c'est la vie.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index e51ea8ba602..f196389c36a 100644
--- a/src/panfro
Thanks, fixed in v2.
On Fri, Aug 16, 2019 at 11:55:59AM -0400, Ilia Mirkin wrote:
> On Fri, Aug 16, 2019 at 11:38 AM Alyssa Rosenzweig
> wrote:
> >
> > The texture coordinate for a 2D texture could be a vec2 or a vec3,
> > depending if it's an array texture or
> +# FIXME: These tests fail in RK3288 but pass on RK3399
> +FLIP_FLOPS="$FLIP_FLOPS
> +dEQP-GLES2.functional.fragment_ops.blend.*
> +dEQP-GLES2.functional.shaders.builtin_variable.max_draw_buffers_vertex
> +dEQP-GLES2.functional.shaders.matrix.div.const_lowp_mat2_mat2_vertex
> +
>
R-b
On Wed, Aug 21, 2019 at 10:17:50AM +0200, Tomeu Vizoso wrote:
> A number of things can go wrong when building the rootfs from within a
> non-native chroot, so make sure to print the bootstrap.log so we can
> tell what's going on.
>
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/p
R-b
On Wed, Aug 21, 2019 at 10:17:51AM +0200, Tomeu Vizoso wrote:
> There's lots of locking changes going into the Panfrost kernel driver,
> so better be prepared.
>
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/ci/arm64.config | 6 --
> 1 file changed, 4 insertions(+),
R-b
On Wed, Aug 21, 2019 at 10:17:52AM +0200, Tomeu Vizoso wrote:
> Some runners may be configured such that the qemu binary might not be
> available by the time we need to start running commands within the
> chroot.
>
> So make sure that it's there to avoid suprising problems in that case.
>
>
R-b
On Wed, Aug 21, 2019 at 10:17:53AM +0200, Tomeu Vizoso wrote:
> To help make sure we are running tests in the ideal number of threads,
> print load stats to make obvious when there's a problem with
> utilization.
>
> This will be specially useful when we run tests on a wider variety of
> devi
Otherwise, there is too much noise to see what's going on.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh
b/src/gallium/drivers/panfro
> > Otherwise, there is too much noise to see what's going on.
>
> I'm afraid this doesn't improve things much, as you can see below:
>
> https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/524402
>
> Jakob has kindly offered to add this weekend a mode that prints only
> regressions and improvement
Patches 1, 2, and 5 are:
Reviewed-by: Alyssa Rosenzweig
Patches 3 and 4 are modifying the guts of the scheduler which I plan to
rewrite in full, like, today.
On Tue, Aug 27, 2019 at 12:36:40PM +0200, Boris Brezillon wrote:
> To avoid memory leaks.
>
> Signed-off-by: Boris
Assuming it passes CI, feel free to apply it :)
On Tue, Aug 27, 2019 at 12:40:08PM +0200, Boris Brezillon wrote:
> On Tue, 13 Aug 2019 15:30:20 -0700
> Alyssa Rosenzweig wrote:
>
> > > I don't see any remove_ins()/insert_before() call in there. Do you see
> > >
Looks good, r-b.
Is it tested?
On Wed, Aug 28, 2019 at 09:32:04AM +0200, Boris Brezillon wrote:
> Instructions attached to blocks are never explicitly freed. Let's
> use ralloc() to attach those objects to the compiler context so that
> they are automatically freed when the ctx object is freed.
>
:+1:
On Wed, Aug 28, 2019 at 04:14:33PM +0200, Boris Brezillon wrote:
> On Wed, 28 Aug 2019 07:08:18 -0700
> Alyssa Rosenzweig wrote:
>
> > Looks good, r-b.
> >
> > Is it tested?
>
> Tested locally, and CI is green (this time I made sure the tests were
R-b
On Wed, Aug 28, 2019 at 04:53:15PM +0200, Boris Brezillon wrote:
> Reset the damage area in the resource_from_handle() path (as done in
> panfrost_resource_create()).
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_resource.c | 23 +++--
> 1 file
Yeah, I gathered given the temporal proximity w/ IRC :)
On Wed, Aug 28, 2019 at 05:02:43PM +0200, Boris Brezillon wrote:
> On Wed, 28 Aug 2019 07:59:21 -0700
> Alyssa Rosenzweig wrote:
>
> > R-b
>
> For the record, that was the reason for those damage_width/height = 0
>
A-b
On Thu, Aug 29, 2019 at 04:15:32PM +0200, Tomeu Vizoso wrote:
> Some functionality has been added to deqp-volt to only print
> regressions, so update our version of it and use the new options.
>
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/ci/deqp-runner.sh | 9 ++-
> +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
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
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 ca
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-of
Lovely cleanup! R-b.
I think I had a reason for separating the two -- or maybe the BO cache
is just newer than the transient BO cache? -- but seeing as I haven't
the foggiest what it was, this is a lovely improvement.
On Sat, Aug 31, 2019 at 12:47:18PM +0200, Boris Brezillon wrote:
> Right now, t
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, var
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
>
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-b
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 Rosenzw
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 fi
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.
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
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
> +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
> +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
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
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
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
> > 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
> 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
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 pr
> +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,
> 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
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
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
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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 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
> --- 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);
> +
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
I think we can simplify `panfrost_flush_draw_deps`. We need to flush
any BOs that write where we read/write and any BOs that read where we
write. Since we collect this information via add_bo, we can
implement this logic generically, without requiring a special case
for every kind of BO we might nee
Conceptually R-b but see patch 24 comments.
On Thu, Sep 05, 2019 at 09:41:50PM +0200, Boris Brezillon wrote:
> 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
>
> Now, if we go for the dep graph solution, that's probably a non issue,
> since deps can be added at any point as long as they are described
> before the flush happens.
>
> [snip]
>
> Thanks for the detailed explanation. I'll look into that. This being
> said, I was wondering if we shouldn't merge
> I'm definitely biased :-), but I do find the changes at hand not that
> invasive: most of the logic is placed in helpers that are called in one
> or 2 places. I mean, removing those explicit flushes when the time
> comes shouldn't be too hard, and I do think it's one step in the right
> direction
Series (and the timeouts one following) are Acked-by: Alyssa Rosenzweig
On Fri, Sep 06, 2019 at 04:12:12PM +0200, Tomeu Vizoso wrote:
> Now that Volt supports armhf, build again images and submit to LAVA for
> RK3288.
>
> Signed-off-by: Tomeu Vizoso
> ---
> .../drivers/
Series A-b
On Tue, Sep 10, 2019 at 07:13:07PM +0100, Tomeu Vizoso wrote:
> Instead of running it with the Wayland platform, which introduces
> unwanted dependencies and complexity.
>
> Makes tests run 30% faster, as well.
>
> Signed-off-by: Tomeu Vizoso
> ---
> .../drivers/panfrost/ci/create-r
Reviewed-by: Alyssa Rosenzweig
On Mon, Sep 16, 2019 at 11:36:39AM +0200, Boris Brezillon wrote:
> panfrost_{create,free,get}_batch() are only called inside pan_job.c.
> Let's make them static.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_j
Reviewed-by: Alyssa Rosenzweig
On Mon, Sep 16, 2019 at 11:36:40AM +0200, Boris Brezillon wrote:
> The DRM driver expects an array of u32, let's use the correct type, even
> if using an int works in practice because it's still a 32-bit integer.
>
> Signed-off-by: Boris B
Reviewed-by: Alyssa Rosenzweig
On Mon, Sep 16, 2019 at 11:36:41AM +0200, Boris Brezillon wrote:
> Some BOs are used by batches but never explicitly added to the BO set.
> This is currently not a problem because we wait for the execution of
> a batch to be finished before releasing a B
R-b
On Mon, Sep 16, 2019 at 11:36:44AM +0200, Boris Brezillon wrote:
> has_draws can be inferred directly from the batch->last_job value, no
> need to pass it around.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_drm.c| 3 ++-
> src/gallium/drivers/panfrost/pan
R-b'
On Mon, Sep 16, 2019 at 11:36:43AM +0200, Boris Brezillon wrote:
> ctx is allocated with rzalloc() which takes care of zero-ing the memory
> region. No need to call memset(0) on top.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_context.c | 1 -
> 1 file chang
Reviewed-by: Alyssa Rosenzweig
> That's what we do for other per-batch BOs, and we'll soon add an helper
> to automate this create_bo()+add_bo()+bo_unreference() sequence, so
> let's prepare the code to ease this transition.
>
> Signed-off-by: Boris Brezillon
R-b
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b
On Mon, Sep 16, 2019 at 11:36:46AM +0200, Boris Brezillon wrote:
> This way we have all BO related functions placed in the same source
> file.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_bo.c | 20
> src/gallium/drivers/panfrost/pan_
I like removing DRM.
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 Mon, Sep 16, 2019 at 11:36:49AM +0200, Boris Brezillon wrote:
> They are not expected to be called directly, users should use
> panfrost_bo_{create,release}() instead.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_bo.c | 4 ++--
> src/gallium/drivers/panfros
R-b
On Mon, Sep 16, 2019 at 11:36:50AM +0200, Boris Brezillon wrote:
> panfrost_bo_mmap() already takes care of that.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_resource.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/src/gallium
R-b, this is a nice cleanup and can probably prevent some WATs down the
line.
On Mon, Sep 16, 2019 at 11:36:51AM +0200, Boris Brezillon wrote:
> Store a screen pointer in panfrost_bo so we don't have to pass a screen
> object to all functions manipulating the BO.
>
> Signed-off-by: Boris Brezillo
> The only difference caused by this change is that the scratchpad,
> tiler_heap and tiler_dummy BOs are now returned to the cache instead
> of being freed when a context is destroyed.
That sounds fine to me.
> This is only a problem if
> we care about context isolation, which apparently is not t
R-b, I think
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b. Wonder why this never broke anything else either.
On Mon, Sep 16, 2019 at 11:36:54AM +0200, Boris Brezillon wrote:
> We don't know who else is using the BO in that case, and thus shouldn't
> re-use it for something else.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfro
_bo.c
> b/src/gallium/drivers/panfrost/pan_bo.c
> index 209d1e0d71e5..3f05226f96f4 100644
> --- a/src/gallium/drivers/panfrost/pan_bo.c
> +++ b/src/gallium/drivers/panfrost/pan_bo.c
> @@ -23,6 +23,7 @@
> * Authors (Collabora):
> * Alyssa Rosenzweig
> */
> +#in
401 - 500 of 991 matches
Mail list logo
