glClear()s are expected to be the first thing GL apps do before drawing
new things. If there's already an existing batch targetting the same
FBO that has draws attached to it, we should make sure the new clear
gets a new batch assigned to guaranteed that the FB content is actually
cleared with the
When only the depth/stencil bufs are cleared, we should make sure the
color content is reloaded into the tile buffers if we want to preserve
their content.
Signed-off-by: Boris Brezillon
---
There might be a more optimal solution to do that (like not passing the
color bufs to the fragment job?),
Remove the tests that are now passing.
Signed-off-by: Boris Brezillon
---
.../drivers/panfrost/ci/expected-failures.txt | 153 --
1 file changed, 153 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt
b/src/gallium/drivers/panfrost/ci/expected-failu
On Wed, Sep 18, 2019 at 2:08 PM Mark Janes wrote:
> Right now, anyone can create milestones. Is there a way to limit the
> capability to release managers? Would that be desirable?
>
I don't think so. We may want to use milestones for other task tracking
beyond just releases such as "Switch ra
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 4 +---
src/gallium/drivers/nouveau/codegen/nv50_ir.h | 2 +-
src/gallium/drivers/nouveau/codegen/nv50_ir_target.cpp | 2 +-
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/src/gallium
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_util.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_util.h
b/src/gallium/drivers/nouveau/codegen/nv50_ir_util.h
index 307c23d5e03..b1766f48205 100644
---
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_from_nir.cpp
index 4e86ab8f8cc..95b6
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/nv50/nv50_state.c | 10 +++---
src/gallium/drivers/nouveau/nvc0/nvc0_state.c | 10 +++---
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state.c
b/src/gallium/drivers/nouvea
To be clear, if we have a batch and do the following operations:
clear red
draw 1
clear green
draw 2
flush
All we should see is #2 on a green background, which this patch handles
by the second clear invalidating all the clears/draws that came before
it (pro
R-b, nice fix :)
On Fri, Sep 20, 2019 at 04:53:38PM +0200, Boris Brezillon wrote:
> When only the depth/stencil bufs are cleared, we should make sure the
> color content is reloaded into the tile buffers if we want to preserve
> their content.
>
> Signed-off-by: Boris Brezillon
> ---
> There mig
R-b with pleasure! Glad to see those tests fixed, those have stumped me
for a *long* time :D
Congratulations! Thank you!
On Fri, Sep 20, 2019 at 04:53:39PM +0200, Boris Brezillon wrote:
> Remove the tests that are now passing.
>
> Signed-off-by: Boris Brezillon
> ---
> .../drivers/panfrost/ci/
> @@ -1121,7 +1134,11 @@ panfrost_emit_for_draw(struct panfrost_context *ctx,
> bool with_vertex_data)
>
> struct panfrost_shader_state *ss =
> &all->variants[all->active_variant];
>
> -panfrost_batch_add_bo(batch, ss->bo);
> +panfrost_batch_ad
R-b
On Wed, Sep 18, 2019 at 03:24:24PM +0200, Boris Brezillon wrote:
> So we can store the flags as data and keep the BO as a key. This way
> we keep track of the type of access done on BOs.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * None
> ---
> src/gallium/drivers/panfrost/p
R-b
On Wed, Sep 18, 2019 at 03:24:25PM +0200, Boris Brezillon wrote:
> So we can implement fine-grained dependency tracking between batches.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * Fix typos
> * Do not initialize the syncobj in a signaled state, and set
> fence->signaled
R-b
On Wed, Sep 18, 2019 at 03:24:26PM +0200, Boris Brezillon wrote:
> We just replace the per-context out_sync object by a pointer to the
> the fence of the last last submitted batch. Pipelining of batches will
> come later.
>
> Signed-off-by: Boris Brezillon
> ---
> Alyssa, I dropped your R-b s
Still r-b, but please use the collabora address:)
On Wed, Sep 18, 2019 at 03:24:27PM +0200, Boris Brezillon wrote:
> We'll soon need to freeze a batch not only when it's flushed, but also
> when another batch depends on us, so let's add a helper to avoid
> duplicating the logic.
>
> Signed-off-by:
R-b. nice work!
On Wed, Sep 18, 2019 at 03:24:28PM +0200, Boris Brezillon wrote:
> The idea is to track which BO are being accessed and the type of access
> to determine when a dependency exists. Thanks to that we can build a
> dependency graph that will allow us to flush batches in the correct
>
(Still r-b)
On Wed, Sep 18, 2019 at 03:24:29PM +0200, Boris Brezillon wrote:
> The panfrost_fence logic currently waits on the last submitted batch,
> but the batch serialization that was enforced in
> panfrost_batch_submit() is about to go away, allowing for several
> batches to be pipelined, and
"
On Wed, Sep 18, 2019 at 03:24:31PM +0200, Boris Brezillon wrote:
> This will allow us to only flush batches touching a specific resource,
> which is particularly useful when the CPU needs to access a BO.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Alyssa Rosenzweig
> ---
> Changes in v3:
(Still r-b)
On Wed, Sep 18, 2019 at 03:24:30PM +0200, Boris Brezillon wrote:
> And use it in panfrost_flush() to flush all batches, and not only the
> one currently bound to the context.
>
> We also replace all internal calls to panfrost_flush() by
> panfrost_flush_all_batches() ones.
>
> Signed
Very nice! I'm quite happy with this version, all considered, so R-b!
On Wed, Sep 18, 2019 at 03:24:35PM +0200, Boris Brezillon wrote:
> 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:
Looks good, still r-b. But while we're here, let's get this right:
> @@ -578,10 +578,8 @@ panfrost_transfer_map(struct pipe_context *pctx,
> is_bound |= fb->cbufs[c]->texture == resource;
> }
>
> -if (is_bound && (usage & PIPE_TRANSFER_READ)) {
> -
R-b
On Wed, Sep 18, 2019 at 03:24:37PM +0200, Boris Brezillon wrote:
> We are about to add a batch queue to keep track of submission order.
> Let's rename the existing batches hash table (which is used to get the
> batch attached to an FBO) into fbo_to_batch to avoid confusion.
>
> Signed-off-by:
Erm, un r-b, sorry, didn't realize this was the optional. Let's hold off
on this patch and the succeeding one for now.
On Wed, Sep 18, 2019 at 03:24:37PM +0200, Boris Brezillon wrote:
> We are about to add a batch queue to keep track of submission order.
> Let's rename the existing batches hash ta
Series looks quite good, overall. Just a few minor issues, but probably
not even enough to justify a respin. Congratulations! :p
On Wed, Sep 18, 2019 at 03:24:22PM +0200, Boris Brezillon wrote:
> Hello,
>
> This is the third attempt at supporting batch pipelining. This time I
> implemented it usi
25 matches
Mail list logo
