FYI for people who don't follow GitLab--
We've now removed the following deprecated functionality from NIR:
* nir_register
* ALU write masks
* abs/neg/sat modifiers
For background on how we did it and why, see the description of
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23089
> Among the people present in this discussion, the consensus was that we
> should delete them.
I wasn't present but +1 from me.
> > + for not requiring rb/ab tags ...
>
> I think it's time to think about making this change all over Mesa as
> well. We're deeply in bed with GitLab by now, so I don't think there's
> a realistic chance that this isn't going to just be duplicate info any
> time soon...
I agree, but I don't
+ for not requiring rb/ab tags ... I kinda like the s-o-b tags but those
don't require fiddly rebases, just -s in the right place..
On Tue, Oct 04, 2022 at 10:44:31PM -0500, Mike Blumenkrantz wrote:
>Hi,
>After some vigorous and robust discussion with Erik, we've decided that
>zink
> 2. repo is growing large. Amber kinda requires long history, modern
> mesa not. This may be good spot to split if cleanup is required.
mesa absolutely uses long history. there is nothing to clean up. those
bytes of disk space are well worth it.
(Neutral on the other points, I
Having spent enough time wrangling Mesa/MacOS on Arm Macs
the correct solution is to migrate to Linux. everything else is pain.
On Wed, May 04, 2022 at 12:38:55AM +, Jose Fonseca wrote:
>I'm not sure exactly what Homebrew provides, and I'm not able to
>investigate it now.
>
> 2022-03-14 FIXES d5870c45ae panfrost: Optimise recalculation of max sampler
> view
Unless Icecream95 feels otherwise, I'd drop this one for stable. It
*is* a fix but only impacts a bit of CPU overhead.
>In principle, all the properties you highlight in your blog as key points
>of NIR also apply to SPIR-V.
Those key points are relative to GLSL IR, the IR it displaces. The
purpose of SPIR-V is so different than both NIR and GLSL IR it isn't
interesting to do a comparison. Comparing with
Remind me the difference between MALLOC and malloc (etc)? Like, why
don't we s/MALLOC/malloc/g the whole codebase and drop u_memory.h? I
guess portability (?) even though this is presumably stdlib...
On Thu, Dec 23, 2021 at 08:35:38AM +1000, Dave Airlie wrote:
> Hey,
>
> Happy holidays, and as
> 1. Move src/mesa into src/gallium/frontends/mesa (I have patches for
>this)
>
>Seems like a pretty obvoius thing to do, given that all of the other
>gallium state trackers live there (OpenCL, video, d3d9, etc)
Ack from me.
> 2. Move src/compiler/glsl into
>If we're going to do this, I wonder if we don't want to go even further
>and get rid of src/gallium/drivers and move the respective folders to
>src/vendor.** So, instead of src/gallium/drivers/(iris|crocus), we'd have
>src/intel/gallium/iris and src/intel/gallium/crocus or maybe
>
> I'd like to propose adding/changing two tags:
>
> * change `feature_request` -> `Feature` (this is barely used at present, so
> renaming shouldn't affect anyone negatively)
> * add `Bug`
>
> I would use these primarily for tagging open MRs so that reviewers can more
> appropriately
> > >> Upstream should do what's best for upstream, not for Intel's "unique"
> > >> management.
> > >>
> > >>Not sure how from Emma explaining how Rb tags were used by Intel
> > >>management it came the conclusion that it were used in that way only
> > >> by
> > >>Intel management.
> > >> I would love to see this be the process across Mesa. We already don't
> > >> rewrite commit messages for freedreno and i915g, and I only have to do
> > >> the rebase (busy-)work for my projects in other areas of the tree.
> > > Likewise for Panfrost. At least, I don't do the rewriting.
> Upstream should do what's best for upstream, not for Intel's "unique"
> management.
>
>Not sure how from Emma explaining how Rb tags were used by Intel
>management it came the conclusion that it were used in that way only by
>Intel management. Spoiler: it is not.
Sorry, I'll make
> I would love to see this be the process across Mesa. We already don't
> rewrite commit messages for freedreno and i915g, and I only have to do
> the rebase (busy-)work for my projects in other areas of the tree.
Likewise for Panfrost. At least, I don't do the rewriting. Some Panfrost
devs do,
> By far the limiting factor for i915g progress now that I've got some
> CI rigged up is review. My preference would be that we all agree that
> nobody wants to look at i915, and some responsible folks (ajax and a
> couple Intel volunteers, perhaps?) bless me to merge without review
> once an
Hi Dylan,
Commentary on the two Panfrost patches:
> cff5c40fc3 pan/bi: Fix blend shaders using LD_TILE with MRT
>
>
>
> Probably nv30 would do well to "move on" as well. But it also presents
> an interesting question -- the nv30 driver has lots of problems. I
> have no plans to fix them, nor am I aware of anyone else with such
> plans. However if such a developer were to turn up, would it be
> reasonable to
> And, yeah, I'd love to drop vec4 but yeah... One advantage to keeping
> vec4 in the tree for some stuff is that it means we have full-featured
> hardware able to test vec4 NIR. That seems like a feature.
I have to keep caring about Midgard for the next indefinitely so please
don't break vec4
I'd like to see it happen, though I don't understand how to make these
coexist for distros. Would like to hear from the Debian/etc maintainers
of mesa.
Then again I *think* classic-lts doesn't need to be built for
armhf/arm64 at all, so I suppose I'm personally unaffected :-P
On Mon, Mar 22,
>Absolutely. Apparently I forgot to write the final line which is that I
>think standardising on US English across the board is a good thing
Standardise on any flavour of English you'd like, one of them is still
wrong ;-)
___
mesa-dev mailing
> 3436e5295b pan/bi: Treat +DISCARD.f32 as message-passing
>
>
>
Hi Tommy,
Unfortunately NIR is a bit lacking for documentation, save for comments
in src/compiler/nir/nir_intrinsics.py. For Vulkan ones, the best bet is
likely looking at spirv_to_nir (src/compiler/spirv/) and seeing what
generates it, and working up from there.
Debug strategy varies per driver
> But on many other embedded OSes - at least Google ones like CrOS and
> Android - the security model is way stricter. We could argue that is
> bad / undesirable / too draconian but that is something that any of us
> has the power to change. At some point each platform decides where it
> wants
> That said, I'm ok with making perfetto support a build-time option
> that is default disabled. And I think it would be even ok to limit
> use of perfetto to individual drivers (ie. no core mesa/gallium
> perfetto dependency) to start. And, well, CrOS has plenty of mesa
> contributors so I
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
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
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
>
> 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
> > 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
> 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,
>
> 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,
> 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
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
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
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
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
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
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
index
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
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(+), 1
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
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
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/midgard
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
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
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
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 Rosenzweig (30):
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
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 insertions(+), 37
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
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/midgard
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/panfrost/midgard
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
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_schedule.c | 39
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
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 100644
-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
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 insertions(+)
diff
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
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 a/src
> 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.
> +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
> > 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
> > 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
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
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
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:
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)) {
> -
ex 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
> #incl
_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 +++-
"
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
&
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
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
>
> 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 a/src/gallium/d
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
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: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
> ---
>
> @@ -1121,7 +1134,11 @@ panfrost_emit_for_draw(struct panfrost_context *ctx,
> bool with_vertex_data)
>
> struct panfrost_shader_state *ss =
> >variants[all->active_variant];
>
> -panfrost_batch_add_bo(batch, ss->bo);
> +
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
> ---
>
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
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
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
llon 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.
> > > uniform buffer updates)
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
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
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.
>
>
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
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
> ---
>
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
> ---
>
> > 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,
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
> > > +/* 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.
>
>
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_ta
1 - 100 of 991 matches
Mail list logo
