o handle that properly.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_screen.c | 1 -
src/gallium/include/pipe/p_screen.h | 17 ---
src/gallium/state_trackers/dri/dri2.c | 35 ---
3 files changed, 53 d
On Mon, 2 Sep 2019 16:32:01 +0200
Michel Dänzer wrote:
> On 2019-08-30 7:00 p.m., Boris Brezillon wrote:
> >
> > 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?
&g
On Sat, 28 Sep 2019 15:02:06 -0400
Alyssa Rosenzweig wrote:
> TODO: Move me to front of series.
Looks like you've already done that :).
>
> Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Boris Brezillon
> ---
> src/panfrost/midgard/helpers.h | 2 +-
> 1 file cha
On Sun, 22 Sep 2019 15:24:10 +0200
Boris Brezillon wrote:
> On Sun, 22 Sep 2019 08:38:30 -0400
> Alyssa Rosenzweig wrote:
>
> > > > To be clear, if we have a batch and do the following operations:
> > > >
> > > > clear red
>
On Sun, 22 Sep 2019 09:26:45 -0400
Alyssa Rosenzweig wrote:
> > +your collabora address
>
> Thank you
>
> > > > > I think this batch_add_bo should probably dropped altogether? This
> > > > > loop
> > > > > is dealing with constant buffers; the shaders themselves were added
> > > > >
> >
On Sun, 22 Sep 2019 08:38:30 -0400
Alyssa Rosenzweig wrote:
> > > 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
+your collabora address
On Sun, 22 Sep 2019 08:31:40 -0400
Alyssa Rosenzweig wrote:
> > > Although actually I am not at all sure what this batch_add_bo is doing
> > > at all?
> > >
> > > I think this batch_add_bo should probably dropped altogether? This loop
> > > is dealing with constant buffe
ded that's the idea (and we're not somehow saving the original draw
> 1), it's Reviewed-by A R
>
> On Fri, Sep 20, 2019 at 04:53:37PM +0200, Boris Brezillon wrote:
> > glClear()s are expected to be the first thing GL apps do before drawing
> > new things. If th
On Fri, 20 Sep 2019 16:53:49 -0400
Alyssa Rosenzweig wrote:
> > @@ -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];
> >
> > -
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
h the requested color/depth/stencil values.
We create a panfrost_get_fresh_batch_for_fbo() helper for that and
call it from panfrost_clear().
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
src/gallium/drivers/panfrost/pan_job.c
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/ci/expected-failures.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/ci/expected-failures.txt
b/src/gallium/drivers/panfrost/ci/expected-failures.txt
index b0fc872a3009..0cadaa20cdb2 100644
->padded_count should be large enough to cover all vertices pointed by
the index array. Use the local vertex_count variable that contains the
updated vertex_count value for the indexed draw case.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
1 f
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
---
Changes in v3:
* Move the patch later in the series and squash "panfrost: Cache GPU
accesses to BOs" in it
*
All dEQP-GLES2.functional.fbo.render.texsubimage.* tests are now
passing.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/ci/expected-failures.txt | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium
Will be useful to make the ioctl(WAIT_BO) call conditional on BOs that
are not exported/imported (meaning that all GPU accesses are known
by the context).
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_bo.c
This is not strictly required, but let's try to match the draw call
orders, just in case the app had a reason to do it in this order.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h | 6 ++
src/gallium/drivers/panfrost/pan_job.c
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: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
We don't have to flush all batches when we're only interested in
reading/writing a specific BO. Thanks to the
panfrost_flush_batches_accessing_bo() and panfrost_bo_wait() helpers
we can now flush only the batches touching the BO we want to access
from the CPU.
Signed-off-by: Boris
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
order.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Fix coding style issues
* Do
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:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_job.c | 31
make sure the fence logic waits on all flushed batches, not
only the last one.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Fix a comment
* Adjust things to match the changes done in "panfrost: Add a batch fence"
---
src/gallium/driver
Now that we have all the pieces in place to support pipelining batches
we can get rid of the drmSyncobjWait() at the end of
panfrost_batch_submit().
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_job.c | 12
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/pan_job.c | 33 +-
src/gallium/drivers/panfrost/pan_job.h | 2
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: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/d
Now that we have track inter-batch dependencies, the flush done in
panfrost_set_framebuffer_state() is no longer needed. Let's get rid of
it.
Signed-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Collect R-b
---
src/gallium/drivers/panfrost/pan_context.c
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 to true when submitting a dummy batch (one with no
draw/clear queued)
---
e just patching callers to pass the correct flags here.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* s/PAN_BO_GPU_ACCESS/PAN_BO_ACCESS/
* Fix wrong access types for streamout and vertex index buf
* Add a panfrost_bo_access_for_stage() helper
---
src/gallium/drivers/panfrost/pan_al
render
operations for different frames (frame N should ideally be ready before
frame N+1). Not sure if enforcing draw call order is enough to guarantee
that rendering of frame N always finishes before frame N+1 though.
If that's something you don't want to merge, I can drop it.
Regards,
Bo
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 since the other changes you asked me to do
in "panfrost: Add a batch fence
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-off-by: Boris Brezillon
Reviewed-by: Alyssa Rosenzweig
---
Changes in v3:
* Add missing
+Rob
On Tue, 17 Sep 2019 17:13:04 +0200
Boris Brezillon wrote:
> On Tue, 17 Sep 2019 08:36:56 -0400
> Alyssa Rosenzweig wrote:
>
> > "Can't use pipe_framebuffer_state as a hash key" Is this still relevant?
> > I thought we did this.
>
> I did thi
On Tue, 17 Sep 2019 08:36:56 -0400
Alyssa Rosenzweig wrote:
> "Can't use pipe_framebuffer_state as a hash key" Is this still relevant?
> I thought we did this.
I did this yes. I thought it was only a problem for the wallpaper
draw, but it's actually wrong for any kind of blit where src and
dst p
ects the opposite, such that it can output frame N as soon
as possible.
Anyway, I'm fine dropping patch 35 and 36 (see the note in my cover
letter ;-)).
>
> (Also, I guess r-b on previous patch retracted temporarily since it was a
> setup for
> this.)
>
> On Mon, Sep 16,
On Mon, 16 Sep 2019 15:26:12 -0400
Alyssa Rosenzweig wrote:
> Well, the hash tables strongly assume you're not using NULLs for things.
>
> See _mesa_hash_table_set_deleted_key for how to change that behaviour.
Maybe I'm missing something, but AFAICT it's the key field that requires
special care
On Mon, 16 Sep 2019 16:29:05 -0400
Alyssa Rosenzweig wrote:
> > As a drive-by comment, in case you didn't know, the "standard"
> > solution for avoiding flushing when BO's are written by the CPU (e.g.
> > uniform buffer updates) as documented in ARM's performance guide is to
> > add a copy-on-wri
On Mon, 16 Sep 2019 16:15:14 -0400
Alyssa Rosenzweig wrote:
> > + * A BO is either being written or read at any time, that's what the type
> > field
> > + * encodes.
>
> Might this be inferred from (writer != NULL) and (readers->length > 0)?
No, I need to keep the old writer around when the
On Mon, 16 Sep 2019 15:38:10 -0400
Alyssa Rosenzweig wrote:
> > +/* Start in a signaled state so that even non-submitted batches
> > + * (those that have no draw/clear) can be waited upon.
> > + */
>
> When would this happen? Presumably if a batch does nothing whatsoeve
On Mon, 16 Sep 2019 10:05:52 -0400
Alyssa Rosenzweig wrote:
> > +/* If ->gpu_access is 0, the BO is idle, and if the WRITE
> > flag
> > + * is cleared, that means we only have readers.
> > + */
> > +if (!bo->gpu_access)
> > +
27;re
worried about having hentry->data = (uintptr_t)0 (IOW hentry->data =
NULL), I don't see the problem.
>
> On Mon, Sep 16, 2019 at 11:37:01AM +0200, Boris Brezillon wrote:
> > So we can store the flags as data and keep the BO as a key. This way
> > we ke
On Mon, 16 Sep 2019 09:59:15 -0400
Alyssa Rosenzweig wrote:
> PAN_BO_GPU_ACCESS_* is rather wordy. We're a GPU driver, of course it's
> GPU access :)
Well, the driver can also do CPU accesses to the same BOs :P.
>
> Could we just do PAN_BO_ACCESS_* instead?
I guess that's fine as long as it's
On Mon, 16 Sep 2019 17:11:01 +0700
Connor Abbott wrote:
> As a drive-by comment, in case you didn't know, the "standard"
> solution for avoiding flushing when BO's are written by the CPU (e.g.
> uniform buffer updates) as documented in ARM's performance guide is to
> add a copy-on-write mechanism
This is not strictly required, but let's try to match the draw call
orders, just in case the app had a reason to do it in this order.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h | 6 ++
src/gallium/drivers/panfrost/pan_job.c
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/panfrost/pan_bo.h | 6 --
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git
rsion() in pan_screen.c
* submit related functions in pan_job.c
While at it, we rename the functions according to the place they're
being moved to.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/meson.build | 1 -
src/gallium/drivers/panfrost/pan_allocate.c | 2 +-
src/
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/panfrost/pan_bo.c | 5 +
src/gallium/drivers/panfrost/pan_bo.h | 4
2 files changed, 9 insertions(+)
diff --git a/s
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-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_compute.c | 2 +-
src
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_resource.c | 19 ---
2 files changed, 20 insertions(+), 19
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 Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 2 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 2 +-
src/gallium/drivers/pan
make sure the fence logic waits on all flushed batches, not
only the last one.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 18 ++-
src/gallium/drivers/panfrost/pan_context.h | 5 +-
src/gallium/drivers/panfrost/pan_job.c | 7 ---
src/gallium/drivers
If we want the batch dependency tracking to work correctly we must
make sure all BOs are added to the batch->bos set early enough. Adding
FBO BOs when generating the fragment job is clearly to late. Add a
panfrost_batch_add_fbo_bos helper and call it in the clear/draw path.
Signed-off-by: Bo
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
---
src/gallium/drivers/panfrost/pan_context.c | 6 --
src/gallium/drivers/panfrost/pan_context.h | 3
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 | 78 +++
src/gallium/drivers/panfrost/pan_bo.h | 2 +
2
Thanks to that we avoid the recursive call into panfrost_bo_create()
and we can get rid of panfrost_bo_release() by inlining the code in
panfrost_bo_unreference().
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 146 --
1 file changed, 69
This helper automates the panfrost_bo_create()+panfrost_batch_add_bo()+
panfrost_bo_unreference() sequence that's done for all per-batch BOs.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 9 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 8 ++---
This way we can avoid calling ioctl(WAIT_BO) when we already know the
BO is idle because it hasn't been touched by a GPU job or because the
previous call to panfrost_bo_wait() returned true.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c
e just patching callers to pass the correct flags here.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 14 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 6 ++-
src/gallium/drivers/panfrost/pan_bo.h | 18
src/gallium/drivers/panfros
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/drivers/panfrost/pan_resource.c
b/src/gallium/drivers/panfrost/pan_resource.c
index
apparently is not the case since
transient BOs are already returned to the per-FD cache (and all contexts
share the same address space anyway, so enforcing context isolation
is almost impossible).
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 5 -
src/gallium
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_job.c| 4 +---
src/gallium/drivers/panfrost/pan_screen.h | 2 +-
3 fi
Now that we have track inter-batch dependencies, the flush done in
panfrost_set_framebuffer_state() is no longer needed. Let's get rid of
it.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 46 ++
1 file changed, 3 insertions(+), 43 dele
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: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
We don't have to flush all batches when we're only interested in
reading/writing a specific BO. Thanks to the
panfrost_flush_batches_accessing_bo() and panfrost_bo_wait() helpers
we can now flush only the batches touching the BO we want to access
from the CPU.
Signed-off-by: Boris
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: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 62 ++
1 file changed
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
Now that we have all the pieces in place to support pipelining batches
we can get rid of the drmSyncobjWait() at the end of
panfrost_batch_submit().
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/src/gallium
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
---
src/gallium/drivers/panfrost/pan_job.c | 31 ++
src/gallium/drivers/panfrost/pan_job.h | 4
2
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
---
src/gallium/drivers/panfrost/pan_job.c | 33 +-
src/gallium/drivers/panfrost/pan_job.h | 2 +-
2 files changed, 23
So we can implement fine-grained dependency tracking between batches.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_job.c | 51 ++
src/gallium/drivers/panfrost/pan_job.h | 39
2 files changed, 90 insertions(+)
diff --git a/src
Will be useful to make the ioctl(WAIT_BO) call conditional on BOs that
are not exported/imported (meaning that all GPU accesses are known
by the context).
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_bo.c | 4 ++--
src/gallium/drivers/panfrost/pan_bo.h | 6 ++
2 files
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
order.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.h
Right now, the BO API is spread over pan_{allocate,resource,screen}.h.
Let's move all BO related definitions to a separate header file.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 1 +
src/gallium/drivers/panfrost/pan_allocate.h | 20
src/ga
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 changed, 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src
If we want to execute several batches in parallel they need to have
their own tiler and scratchpad BOs. Let move those objects to
panfrost_batch and allocate them on a per-batch basis.
Signed-off-by: Boris Brezillon
---
Note to Alyssa: I tried removing the dummy_tiler BO replacing it by a
dummy
Change the prefix for BO allocation flags to make it consistent with
the rest of the BO API.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_assemble.c | 2 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 2 +-
src/gallium/drivers/panfrost/pan_bo.c| 12
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
---
src/gallium/drivers/panfrost/pan_drm.c | 1 -
src/
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 BO, but we will soon relax
this rule.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost
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 Brezillon
---
src/gallium/drivers/panfrost/pan_drm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -
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_job.c | 6 +++---
src/gallium/drivers/panfrost/pan_job.h | 11 ---
2 files changed, 3 insertions(+), 14 deletions(-)
finishes before frame N+1 though.
Regards,
Boris
Boris Brezillon (37):
panfrost: Stop exposing internal panfrost_*_batch() functions
panfrost: Use the correct type for the bo_handle array
panfrost: Add missing panfrost_batch_add_bo() calls
panfrost: Add polygon_list to the batch BO set at
On Thu, 5 Sep 2019 21:41:25 +0200
Boris Brezillon wrote:
> 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
On Fri, 6 Sep 2019 08:10:55 -0400
Alyssa Rosenzweig wrote:
> > 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'
On Fri, 6 Sep 2019 07:40:17 -0400
Alyssa Rosenzweig wrote:
> 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 genericall
On Thu, 5 Sep 2019 19:26:45 -0400
Alyssa Rosenzweig wrote:
> > --- 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(
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, Bori
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,
> > +};
>
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_
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
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
backed by BOs, and
given we might want to describe dependencies on BOs that are not
exposed as resources, we decided to use BOs as keys on our hash tables.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 2 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 2
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
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
ff-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 10 ++--
src/gallium/drivers/panfrost/pan_allocate.h | 7 +--
src/gallium/drivers/panfrost/pan_compute.c| 10 ++--
src/gallium/drivers/panfrost/pan_context.c| 51 +++
src/gallium/drivers/pan
-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 17 +
src/gallium/drivers/panfrost/pan_job.h | 3 +++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
in
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
e it by an unconditional wait at the end of
panfrost_batch_submit(). A new pipeline logic will be introduced later
on.
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_context.c | 145 +
src/gallium/drivers/panfrost/pan_context.h | 9 +-
src/gallium/driver
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-of
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
ted functions are
prefixed with panfrost_bo_)
* release functions are no longer exposed, existing users are converted
to use panfrost_bo_unreference() instead
Signed-off-by: Boris Brezillon
---
src/gallium/drivers/panfrost/pan_allocate.c | 5 +-
src/gallium/drivers/panfrost/pan_allocate.h |
1 - 100 of 332 matches
Mail list logo
