R-b, but could we move this patch before the one adding the WAIT_BO? And
I guess some succeeding patches we'll want to move before as well, and
then the final one using it get squashed? Let's see.
On Mon, Sep 16, 2019 at 11:36:56AM +0200, Boris Brezillon wrote:
> Will be useful to make the ioctl(W
R-b, wonderful
On Mon, Sep 16, 2019 at 11:36:57AM +0200, Boris Brezillon wrote:
> 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/panfro
R-b
On Mon, Sep 16, 2019 at 11:36:58AM +0200, Boris Brezillon wrote:
> 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_a
> Note to Alyssa: I tried removing the dummy_tiler BO replacing it by a
> dummy value (tried both 0xdeafbeef and 0x0) and unfortunately it
> crashed, so I decided to keep this dummy allocation for now.
Very well. That'd be a neat but very low prio RE task, so *shrug*
> -static void
> -panfrost_se
PAN_BO_GPU_ACCESS_* is rather wordy. We're a GPU driver, of course it's
GPU access :)
Could we just do PAN_BO_ACCESS_* instead?
> static mali_ptr
> panfrost_upload_tex(
> struct panfrost_context *ctx,
> +enum pipe_shader_type st,
> struct panfrost_sampler_view *view)
>
What if flags = 0?
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 keep track of the type of access done on BOs.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_job.c | 33 ++
> +/* 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)
> +return true;
> +else if (!(access_type &
> > 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.
Yes, but we won't be marking them off this way ever, no?
> > > +panfrost_batch_add_bo(batch, rsrc->bo,
> > > +
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.
On Mon, Sep 16, 2019 at 04:17:37PM +0200, Boris Brezillon wrote:
> On Mon, 16 Sep 2019 10:00:13 -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)
> > > +return true;
> > > +
> +/* 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 whatsoever,
it doesn't make sense to wait on it.
> #include "pan_resource.h"
>
>
Also, some typos:
> + * since other batches might want to wait on an fence of already
a fence.
> +/* panfrost_batch_fence is the out fence of batch that users or other batches
a batch
> +/* Cached value of the signaled state to avoid calling WAIC_SYNCOBJs
WAIT_SYNCOBJs
___
R-b
On Mon, Sep 16, 2019 at 11:37:04AM +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
> ---
> src/gallium/drivers/panfro
> +/* Remove the entry in the FBO -> batch hash table if the batch
> + * matches. This way, next draws/clears targeting this FBO will
> trigger
> + * the creation of a new batch.
> + */
> +entry = _mesa_hash_table_search(ctx->batches, &batch->key);
> + i
> + * 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)?
> +util_dynarray_foreach(&batch->dependencies,
> + struct panfrost_batch_fence *, dep)
> +/* Export fences from all pending pending batches. */
Pending pending batches, from the Department of Redundancy Department.
Aside from that, R-b :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailma
> diff --git a/src/gallium/drivers/panfrost/pan_compute.c
> b/src/gallium/drivers/panfrost/pan_compute.c
> index 4639c1b03c38..036dffbb17be 100644
> --- a/src/gallium/drivers/panfrost/pan_compute.c
> +++ b/src/gallium/drivers/panfrost/pan_compute.c
> @@ -133,7 +133,7 @@ panfrost_launch_grid(struct
> 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, so that you have "shadow" BO's when the
> original BO is
Ah, perhaps, yes. My bad.
On Tue, Sep 17, 2019 at 12:18:17AM +0200, Boris Brezillon wrote:
> 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_
> > > +/* 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 whatsoever,
> > it doesn't make sense to wait on it.
>
> Was
R-b
On Mon, Sep 16, 2019 at 11:37:09AM +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
> ---
> src/gallium/drivers/panfrost/pan_job.c | 31
> > I'm wondering if batch->dependencies should be expressed as a set,
> > rather than a dynarray, such that testing whether a batch has a
> > given dependency is ideally O(1), not O(N).
> >
> > In practice I don't know if the asymptotic complexity matters, esp. for
> > small numbers of batches, a
R-b with enthusiasm :)
On Mon, Sep 16, 2019 at 11:37:10AM +0200, Boris Brezillon wrote:
> 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/galli
R-b :D
On Mon, Sep 16, 2019 at 11:37:11AM +0200, Boris Brezillon wrote:
> 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
R-b
On Mon, Sep 16, 2019 at 11:37:12AM +0200, Boris Brezillon wrote:
> 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
R-b
On Mon, Sep 16, 2019 at 11:37:13AM +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:
Hmm, could you explain a bit why this is necessary?
I would think if there's no dependency, there's no dependency, and if
this fixes bugs, that's a dependency tracking issue that we're just
papering over.
(Also, I guess r-b on previous patch retracted temporarily since it was a setup
for
this.)
R-b, nice :)
On Mon, Sep 16, 2019 at 11:37:15AM +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
> 1 file changed, 4 deletions(-)
00, Boris Brezillon wrote:
> 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.
> > > u
R-b
On Wed, Sep 18, 2019 at 03:54:37PM +0200, Boris Brezillon wrote:
> ->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 B
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
ogic.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Alyssa Rosenzweig
> ---
> Changes in v3:
> * Collect R-b
> ---
> src/gallium/drivers/panfrost/pan_job.c | 62 ++
> 1 file changed, 44 insertions(+), 18 deletions(-)
>
> diff --git
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
>
be pipelined, and the last submitted one is not necessarily
> the one that will finish last.
>
> We need to make sure the fence logic waits on all flushed batches, not
> only the last one.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Alyssa Rosenzweig
> ---
> Chan
"
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
&
_batches() ones.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Alyssa Rosenzweig
> ---
> Changes in v3:
> * Add missing blank line
> * Collect R-b
> ---
> src/gallium/drivers/panfrost/pan_compute.c | 2 +-
> src/gallium/drivers/panfrost/pan_context.c | 23 +++-
c
> index 9daddf9d0cc2..37602688d630 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
> */
> +#include
> #include
> #include
&
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
> > 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 buffers; the shaders themselves were added
>
> I'll double check. I couldn't find where BOs containin
> > 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
> +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
> > >
> > > I'll double check. I couldn't find where BOs containing shader programs
> > > were added l
> One more thing: optimization of the above scenario is probably
> something we'll want to have at some point, but I think the current
> patch is worth applying in the meantime. All this patch does is
> enforcing ordering of clears/draws to make sure the end result matches
> users expectation.
Hum
TODO: Move me to front of series.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/helpers.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/panfrost/midgard/helpers.h b/src/panfrost/midgard/helpers.h
index ac58fd50327..343fad0fea8 100644
--- a/src/panfrost
We don't actually do any scheduling here yet, but add per-tag helpers to
consume an instruction, print it, pop it off the worklist.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 190
1 file changed, 190 insertions(+)
diff --git
This flows naturally from the dependency graph
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index 70fa030390c
It's not always obvious what the optimal bundle type should be. Let's
break out the logic to decide.
Currently set for purely in-order operation.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 25 +
1 file changed, 25 insertion
-powerful out-of-order model. So rather
than discriminating by a register pressure estimate, we simply choose
the latest possible instruction in the worklist.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 55 +
1 file changed, 55 insertions
This allows node_count to be correct while scheduling.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index b8d9b5ec9be
After we've chosen an instruction, popped it off, and processed it, it's
time to update the worklist, removing that instruction from the
dependency graph to allow its dependents to be put onto the worklist.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_sched
o add an actual dependency practically speaking, since the new
synthetic imov doesn't have a node associated.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/panfro
This allows ALUs to select for each unit of the bundle separately.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_compile.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/panfrost/midgard/midgard_compile.c
b/src/panfrost/midgard/midgard_compile.c
index 585591d9356..95ec48e9563 100644
--- a/src/panfrost/midgard/midgard_compile.c
ly do better, of course.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index 72c6ec42980..86a77149c78 1
We require chosen instructions to be "close", to avoid ballooning
register pressure. This is a kludge that will go away once we have
proper liveness tracking in the scheduler, but for now it prevents a lot
of needless spilling.
Signed-off-by: Alyssa Rosenzweig
---
src/panfro
Based on a given unit.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 24
1 file changed, 24 insertions(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index e2641ea0180..dea8b023e9d
conditionals correct is surprisingly complex. Essentially, we see if we
could stuff the conditional within the same bundle as the csel/branch
without breaking anything; if we can, we do that. If we can't, we add a
dummy move to make room.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/mi
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 10 ++
src/panfrost/midgard/midgard_schedule.c | 121
2 files changed, 131 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index 8612bab7686
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index e71f65f6004..094451ceb9d 100644
--- a/src/panfrost/midgard
Conditions for branches don't have a swizzle explicitly in the emitted
binary, but they do implicitly get swizzled in whatever instruction
wrote r31, so we need to handle that.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h| 4 ++--
src/panfrost/mi
We still emit in-order but we switch to using the bundles created from
the new scheduler, which will allow greater flexibility and room for
out-of-order optimization.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 6 -
src/panfrost/midgard/midgard_compile.c
If an instruction could be scheduled to vmul to satisfy the writeout
conditions, let's do that and save an instruction+cycle per fragment
shader.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 41 -
1 file changed, 40 insertions(
We can bundle two load/store together. This eliminates the need for
explicit load/store pairing in a prepass, as well.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 67 +
1 file changed, 12 insertions(+), 55 deletions(-)
diff --git a/src
It's not based on the writemask and it can't be inferred; it's just
intrinsic to the op itself.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/helpers.h | 15 +++--
src/panfrost/midgard/mir.c | 59 ++
2 files changed, 37 in
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index f883830cf86..e71f65f6004 100644
--- a/src/panfrost/midgard
We would like to flatten a linked list of midgard_instructions into an
array of midgard_instruction pointers on the heap.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/panfrost/midgard
confidence interval for threads %-change: 100.00% 100.00%
total spills in shared programs: 3 -> 3 (0.00%)
spills in affected programs: 0 -> 0
helped: 0
HURT: 0
total fills in shared programs: 5 -> 6 (20.00%)
fills in affected programs: 5 -> 6 (20.00%)
helped: 0
HURT: 1
Alyssa Rosenzwei
There's no r32 to save ya after you use up r31 :)
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/panfrost/midgard/midgard_schedule.c
b/src/panfrost/midgard/midgard_schedule.c
index 094451ceb9d..5f271608a30 100644
--- a/src/panfrost/midgard
Useful for various operations on both commutative and anticommutative
ops.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 1 +
src/panfrost/midgard/midgard_opt_invert.c | 13 +++--
src/panfrost/midgard/mir.c| 17 +
3
We never had a scheduler good enough to hit this case before! :)
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/panfrost/midgard/compiler.h b/src/panfrost/midgard/compiler.h
index cf943ea6995
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/compiler.h | 1 +
src/panfrost/midgard/midgard_compile.c| 1 +
src/panfrost/midgard/midgard_opt_invert.c | 25 +++
3 files changed, 27 insertions(+)
diff --git a/src/panfrost/midgard/compiler.h b/src
If we can reuse constant slots from other instructions, we would like to
do so to include more instructions per bundle.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 129 +---
1 file changed, 113 insertions(+), 16 deletions(-)
diff --git a
Now that we have constant adjustment logic abstracted, we can do this
safely. Along with the csel inversion patch, this allows many more
common csel ops to inline their condition in the bundle.
Signed-off-by: Alyssa Rosenzweig
---
src/panfrost/midgard/midgard_schedule.c | 14 ++
1
Hi all,
Recently I've been thinking about the potential for the Rust programming
language in Mesa. Rust bills itself a safe system programming language
with comparable performance to C [0], which is a naturally fit for
graphics driver development.
Mesa today is written primarily in C, a notorious
Cc'd.
On Sun, Oct 04, 2020 at 03:17:28PM +0300, Michael Shigorin wrote:
> Hello,
> regarding this proposal:
> http://lists.freedesktop.org/archives/mesa-dev/2020-October/224639.html
>
> Alyssa, Rust is not "naturally fit for graphics driver
> development" since it's not as universally avail
> drive-by comment: for something like a gl driver that a lot of other
> things depend on, making it harder for us to depend on other external
> things is actually a good thing
I agree with this as well. The Rust standard library is richer than C's,
if we can get by fine with C + util/, that shoul
> Yep. Before we can land a single bit of code, we need to do a bunch of
> annoying things like build-system integration, FFI bridging, agreeing
> on conventions and style, etc etc. Trying to do that whilst also
> replacing the GLSL compiler or vtn is way too much; it's 100% doomed
> to failure, ev
> I have found that other tools like RAII/drop, the closely related smart
> pointer types, and safe containers (vectors, strings etc.) even without
> the borrow checker niceties, to be relatively more useful in preventing
> memory errors. However, these are features that modern C++ also offers,
> a
> > I think it's just going to get more messy and complicated for people who
> > don't want to learn or use another language. Mesa already requires people
> > to know C, Python, and now newly Gitlab CI scripts just to get stuff done
> > and merged. Another language would only exacerbate the issu
> Since the majority opinion seemed to be "if someone wanted to use it
> in a leaf node without making everyone use it, that's fine", I've
> started trying to put together the CI bits necessary to enable it.
> Currently fighting with meson cross files a bit, but the linting works
> and the amd64 bu
Hi all,
Icecream95[1], a long-time Mesa/Panfrost contributor, has requested
developer access to mesa on the GitLab issue tracker [2]. Quoting here
for convenience of those who monitor the mailing list but not the
tracker:
> @alyssa keeps complaining about getting poked to assign stuff to Marge
>
My 2c for Mali/Panfrost --
For us, capturing GPU perf counters is orthogonal to rendering. It's
expected (e.g. with Arm's tools) to do this from a separate process.
Neither Mesa nor the DDK should require custom instrumentation for the
low-level data. Fahien's gfx-pps handles this correctly for Pa
bine them with kernel ftrace
> events are a big plus. Admittedly, there is no HW counters and my
> needs are simpler (inserting function begin/end and wait begin/end and
> combining them with virtio-gpu and dma-fence ftrace events).
>
> On Fri, Feb 12, 2021 at 2:13 PM Alyssa Rosenzw
> +
> +static bool gpir_lower_viewport_transform(gpir_compiler *comp)
> +{
> + gpir_node *rcpw = NULL;
> +
> + /* rcpw = 1 / w */
> + list_for_each_entry(gpir_block, block, &comp->block_list, list) {
> + list_for_each_entry(gpir_node, node, &block->node_list, list) {
> + if (node
> + f->temp_write.dest = 0x03; // 11 - temporary
Maybe make a #define, enum
[poofs, again]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This code is probably a wholesale duplication of the corresponding code
in mesa/src/vbo/vbo_minmax_indices.c; we should investigate reusing
that.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 108 ++--
src/gallium/drivers/panfrost
handled, while drawing some attention to the blit
code.
Mipmaps are still disabled at this point, as autogeneration is not yet
implemented; enabling as-is would cause regressions.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 49 ++---
src/gallium/drivers
Fixes a bunch of crashes in dEQP-GLES2.functional.buffer.*
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers
Fixes issues in most of dEQP-GLES2.functional.shaders.*
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_compile.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src
Whereas a normal fcsel acts on a boolean input in r31.w, the fcsel_i
variant acts on an integer input in r31.w, which can be preloaded with
an instruction like imov (with the appropriate negate flag on the
source).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard
Though they output scalars, they need a vector unit to make sense.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/helpers.h
b/src/gallium
501 - 600 of 991 matches
Mail list logo
