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.
>Yes
> 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 don
+ 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 wil
> > + 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 wan
> Among the people present in this discussion, the consensus was that we
> should delete them.
I wasn't present but +1 from me.
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 and
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/include/state_tracker/graw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/include/state_tracker/graw.h
b/src/gallium/include/state_tracker/graw.h
index 217fa31ba1..78ddf0a87f 100644
--- a/src/gallium/include
Both patches pushed :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
We look at the highest set bit in the UBO enable mask to work out the
maximum indexable UBO, i.e. the UBO count as we need to report to the
hardware.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 17 +++--
1 file changed, 15 insertions(+), 2
We refactor panfrost_constant_buffer to mirror v3d's constant buffer
handling, to enable UBOs as well as a single set of uniforms.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 66 ++
src/gallium/drivers/panfrost/pan_context.h | 6
We've known about this for a while, but it was never formally in the
machine header files / decoder, so let's add them in.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h| 15 +++
src/gallium/drivers/panfrost/pan_context.
We already uploaded UBOs, but only a fixed number (1) for uniforms;
let's upload as many as we compute we need.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 27 +-
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git
Prevents an assert(0) later in this (not so edge) case. We still have to
have a dummy there.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost
This implements loads from direct vec4-aligned fields in UBOs. More
future work is needed for indirect or unaligned loads (just compiler changes),
but the core command stream work is handled here.
Alyssa Rosenzweig (9):
panfrost: Constant buffer refactor
panfrost: Report UBO count
panfrost
Now that all the counting is sorted, it's a matter of passing along a
GPU address and going.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_context
Just a little spring cleanup, extending UBOs to vertex shaders in the
process.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 55 ++
1 file changed, 36 insertions(+), 19 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
UBOs and uniforms now use a common code path with an explicit `index`
argument passed, enabling UBO reads.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 65 +++
1 file changed, 51 insertions(+), 14 deletions(-)
diff --git a/src/gallium
This is the hardware max, as far as I can tell.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index
> +if (!supported_gpu) {
> +fprintf(stderr, "Unsupported GPU\n");
> +free(screen);
> +return NULL;
> +}
End users may see this. Is it better to silently fail or to print a
message that Panfrost isn't loaded (either way, the swrast wou
Texturing is very broken, especially anywhere mipmapping is involved,
revolving around issues blitting and bugs with AFBC.
Let's fix this :)
Several hundred dEQP-GLES2 tests are now passing; see the updated
failures list at the end of the series.
Alyssa Rosenzweig (20):
panfrost: Di
If a mipfilter is not set, it's legal to have an incomplete mipmap; we
should handle this accordingly. An "easy way out" is to rig the LOD
clamps.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 16
1 file changed, 16 insertions
Now that all the prerequisites breaking u_blitter are fixed, we can
finally hook up panfrost_blit.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blit.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_blit.c
b/src/gallium/drivers
txf instructions can result from blits, so handle them rather than
crash. Only works for 2D textures (not even 2D array texture) due to a
register allocation constraint that may not be sorted for a while.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 41
Now the autogeneration of mipmaps is working (via u_blitter), we can
finally enable mipmaps!
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src
We need the flush from u_blitter for a normal blit (e.g. for mipmaps);
it's only wallpaper-related blits that are special-cased.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/ga
As far as we know, Utgard-style tiling only works for color render
targets, not depth/stencil, so ensure we don't try to tile it (rather
than compress or plain old linear) and drive ourselves into a corner.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.
both before and after generating a mipmap
since our usual set_framebuffer_state flushing isn't quite there yet.
Ideally better optimizations would save the flush but I digress.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 52 +
src/galli
We just implemented the routine; we may as well use it.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blit.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_blit.c
b/src/gallium/drivers/panfrost/pan_blit.c
index
It doesn't make sense to try to render to multiple array elements at
once.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_mfbd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/panfrost/pan_mfbd.c
b/src/gallium/drivers/panfrost/pan_mfbd.c
Allows for sharing some code as well as theoretically allowing cubemap
rendering.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 19 ---
src/gallium/drivers/panfrost/pan_mfbd.c | 11 +--
src/gallium/drivers/panfrost/pan_resource.c
Fixes TILE_RANGE_FAULT raised on some tests in
dEQP-GLES3.functional.fbo.blit.*
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_fragment.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_fragment.c
b/src/gallium
This is similar to the AFBC merge; now all (non-imported) buffers use a
common backing buffer. Reenables checksumming, eliminating a performance
regression.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 16 --
src/gallium/drivers/panfrost/pan_drm.c
off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blit.c| 40 --
src/gallium/drivers/panfrost/pan_context.c | 6
src/gallium/drivers/panfrost/pan_context.h | 8 +
3 files changed, 35 insertions(+), 19 deletions(-)
diff --git a/src/gallium/driv
I thought I already fixed this. Maybe that was a dream...? Then again, I
might be dreaming now.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pandecode/decode.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost
AFBC (and checksumming) in the
meantime to avoid functional regressions, as we don't know _a priori_ if
we'll need to access a resource from software (which is not yet hooked
up with AFBC) and we don't yet have routines to switch the layout of a
BO at runtime.
Signed-off-by: Alyssa Rosenzweig
In a vertex shader, a tex op should map to txl, as there *must* be a LOD
given to the hardware (implicitly or explicitly).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/drivers
Addresses the disparity between Mali and Gallium definitions of
array_size.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost
Identify the seamless cubemap bit and passthrough the Gallium state
rather than setting unconditionally.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/include/panfrost-job.h | 5 +++--
src/gallium/drivers/panfrost/pan_context.c | 2 +-
src/gallium/drivers/panfrost
A ton of tests were fixed by this series. A few were incorrectly passing
before (QualityError, for instance) and now are explicitly failing. A
few legitimate regressions but overwhelmingly positive.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/ci/expected-failures.txt | 304
Let's match the blob. It's not clear what exactly this controls yet,
though.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_compile.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compil
This doesn't handle Y-flipping, but it's good enough to render the stars
in Neverball.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 28 +-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/src/gallium/driver
A pretty basic implementation of half of point sprites. No coordinate
flipping (either from the FB transform or from the sprite coord key).
Probably room for optimizations. Just enough to make the stars show up
in neverball, basically.
Alyssa Rosenzweig (2):
panfrost: Track point sprites in
In preparation for lowering point sprites, track them like we track
alpha testing state.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 39 --
src/gallium/drivers/panfrost/pan_context.h | 3 ++
2 files changed, 39 insertions(+), 3
This series is:
Reviewed-by: Alyssa Rosenzweig
---
I will caution you about the fault_pointer -- it doesn't do what you
think it does. I once spent about a week chasing a bug in the FBD, since
that's what the fault_pointer said. It was in the mali_viewport. It was
the right *job* --
Rather than using a magic lookup table with no explanations, let's add
liberal comments to the code to explain what this tiling scheme is and
how to encode/decode it efficiently.
It's not so mysterious after all -- just reordering bits with some XORs
thrown in.
Signed-off-by: Alyssa
identifier. Fix spelling error. Switch space_4 to
a LUT. Fix comment typo. Use LUT instead of space_x tricks. Fallback on
generic rather than split up unaligned writes.
Signed-off-by: Alyssa Rosenzweig
Cc: Vasily Khoruzhick
---
src/panfrost/shared/pan_tiling.c | 290 -
"Collabora, Ltd." should be listed in lieu of simply "Collabora"
Signed-off-by: Alyssa Rosenzweig
Suggested-by: Daniel Stone
---
src/gallium/drivers/panfrost/include/panfrost-job.h| 2 +-
src/gallium/drivers/panfrost/midgard/midgard_ra.c | 2 +-
src/gall
R-b, thank you
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Acked-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Also A-b, should have batched these, heh.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Also A-b :)
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Ah-ha, now we're into parts of the stack I can claim to understand! >:)
Reviewed-by: Alyssa Rosenzweig
On Tue, Jun 25, 2019 at 06:37:48PM +0200, Boris Brezillon wrote:
> From: Daniel Stone
>
> Add a pipe_screen->set_damage_region() hook to propagate
> set-damage-region
Overall, I'm quite happy with how this turns out; I was fearful it would
be a lot more complicated, though there's always time for that ;)
Some specific comments follow: (mostly minor):
---
> +panfrost_blit_wallpaper(struct panfrost_context *ctx, struct
> There's no need to intersect the partial_update region with the
> scissor, since rendering outside of the partial_update area is
> explicitly undefined.
I think the idea is less about need and more about an extra
optimization. *Because* that outside rendering is explicitly undefined,
it's valid
> > > +/* We set the damage extent to the full resource size but keep
> > > the
> > > + * damage box empty so that the FB content is reloaded by
> > > default.
> > > + */
> >
> > English, please? Francais, s'il te plait? I'm not too familiar with
> > winsys or the e
> The symptom is, black areas around the damage rect when the rendering
> area (the area you define in mali_payload_fragment) is not
> 32x32-aligned. If you want to test it, remove the "* 2" in the code and
> run weston+desktop-shell (the partial_update() logic has been merged
> earlier today, so y
This series is:
Reviewed-by: Alyssa Rosenzweig
On Thu, Jun 27, 2019 at 09:10:33AM +0200, Tomeu Vizoso wrote:
> Panfrost has grown and doesn't leak as much as before.
>
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/ci/deqp-runner.sh | 9 ++---
We already *can* support texture formats with bpp > 4, so..
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
in
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_screen.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index 17e9287b537..ddb0b7f75fd 100644
--- a/src/gallium
For GLES3, just pass the flag through.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 967d7116c24
Turns out one of the magic bits in the texture instruction meant
'float'. Different magic bits mean int and uint then :)
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/disassemble.c| 22 +++
.../drivers/panfrost/midgard/midgard.h
Just a bit of potpourrie of low-hanging fruit for GLES3 features, e.g.
floating-point textures and ES-class primitive restart.
Alyssa Rosenzweig (7):
panfrost: Implement primitive restart
panfrost: Remove dubious assert
panfrost/midgard: Implement integer sampler
panfrost: Add some
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/include/panfrost-job.h | 1 +
src/gallium/drivers/panfrost/pan_format.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index da01c9d6780
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_format.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/panfrost/pan_format.c
b/src/gallium/drivers/panfrost/pan_format.c
index 3ab39ed3069..563b381574b 100644
--- a/src/gallium/drivers/panfrost
Maybe at some point? I don't think we support enough yet.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b, *blush*
On Fri, Jun 28, 2019 at 09:27:34AM +0200, Tomeu Vizoso wrote:
> Rendering to AFBC was broken, as the HW will complaint loudly if we pass
> a tagged pointer in bifrost_render_target.
>
> Signed-off-by: Tomeu Vizoso
> Fixes: 3609b50a6443 ("panfrost: Merge AFBC slab with BO backing")
>
shared/pan_tiling.c
> > @@ -2,6 +2,7 @@
> > * Copyright (c) 2011-2013 Luc Verhaegen
> > * Copyright (c) 2018 Alyssa Rosenzweig
> > * Copyright (c) 2018 Vasily Khoruzhick
> > + * Copyright (c) 2019 Collabora, Ltd.
> > *
> > * Permission
identifier. Fix spelling error. Switch space_4 to
a LUT. Fix comment typo. Use LUT instead of space_x tricks. Fallback on
generic rather than split up unaligned writes.
v3: Correct stride order (fixes crash loading). Correct coordinate
system mishap.
Signed-off-by: Alyssa Rosenzweig
Reviewed-
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/include/panfrost-job.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/include/panfrost-job.h
b/src/gallium/drivers/panfrost/include/panfrost-job.h
index 4abff22f33c..444e5ad9e69 100644
--- a
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 21 +--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index
simplify instancing code paths
dramatically. This might be a performance regression, but this remains
to be seen; if so, we can always deduplicate later with some added logic
in pan_instancing.c
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h | 16 +-
src
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard.h | 4
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 4 +++-
src/gallium/drivers/panfrost/midgard/midgard_ops.c | 4
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pandecode/decode.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c
b/src/gallium/drivers/panfrost/pandecode/decode.c
index 129e769cace
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 20 +++
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 13f4ed9e283
Rather than open-coding workgroups_shift_* type fields, we include a
general routine for packing the vertex/tiler/compute descriptor based on
the provided dispatch parameters.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/meson.build | 1 +
src/gallium/drivers
> If you're interested, nouveau has logic to optionally go the shared
> (1:N) or non-shared (1:1) way of doing it. Have a look at nvc0_vbo.c
> if you're curious -- look for mentions of "shared".
Hmm, I see. A bit more complex than I was hoping for the moment.
signature.asc
Description: PGP signa
>
> @@ -848,6 +850,7 @@ panfrost_upload_tex(
> for (unsigned l = first_level; l <= last_level; ++l) {
> for (unsigned f = first_layer; f <= last_layer; ++f) {
>
> +panfrost_job_add_bo(job, rsrc->bo);
> view->hw.payload[i
R-b, thank you! :)
On Mon, Jul 01, 2019 at 07:04:44PM +0200, Boris Brezillon wrote:
> Otherwise we get random use-after-{free,unmap} errors.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v2:
> - Move the panfrost_job_add_bo() call out of the loop
> ---
> src/gallium/drivers/panfrost/pan
Oh, not controversial at all, I'm quite happy with this!
Just a question -- I remember some panfrost_resources didn't have a bo
but had a winsys thingy instead. How does that interact?
On Tue, Jul 02, 2019 at 03:23:48PM +0200, Boris Brezillon wrote:
> That's what most (all?) implementation seem to
I haven't checked the logic extensively, but provided CI/Tomeu is happy,
oatches 1-4 are:
Reviewed-by: Alyssa Rosenzweig
On Tue, Jul 02, 2019 at 03:23:43PM +0200, Boris Brezillon wrote:
> Hello,
>
> This patch series is an attempt at making memory allocation more
&
Question: Does this allow us to map arbitrary CPU buffers into GPU
space? Stuff with no relation to the winsys, just... arbitrary user
memory? That might be useful for index/vertex buffers (which we
currently are forced to memcpy() into a BO we create if given a user
pointer rather than a resource)
A-b, let's wait for Tomeu on these few
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
A-b
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b, thank you!
On Tue, Jul 02, 2019 at 03:23:52PM +0200, Boris Brezillon wrote:
> There's no point duplicating the code, and it will help us simplify
> the bo_handles[] filling logic in panfrost_drm_submit_job().
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_alloc
R-b with pleasure! I'm not sure why we didn't get around to this
earlier, but this is awesome. Thank you! :)
On Tue, Jul 02, 2019 at 03:23:53PM +0200, Boris Brezillon wrote:
> Instead of manually adding the BOs from the various SLAB pools plus
> the one backing the color FB, we insert them in the B
> > Stuff with no relation to the winsys, just... arbitrary user
> > memory?
>
> Nope, I don't think so. That might work if you allocate things through
> udmabuf, but then you're better off allocating a BO directly.
Alright, no worries, I was just curious.
signature.asc
Description: PGP signat
:+1:, A-b
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> We need a wrapper that contains a BO plus a pb_slab object for
> SLAB-based allocations (allocation of sub-page-size objects), that's
> exactly what panfrost_memory is right now. We can rename it if you
> like, but I don't think we can get rid of it.
Eventually I do think we'll want to toss thes
Very nice work!
Reviewed-by: Alyssa Rosenzweig
On Tue, Jul 02, 2019 at 03:50:02PM +0200, Boris Brezillon wrote:
> Implement ->set_damage_region() region to support partial updates.
>
> This is a dummy implementation in that it does not try to merge
> damage rects. It also doe
> Since the same discussion is happening with etnaviv: Why exactly does mesa
> need to mmap imported buffers?
The golden question!
Seemingly, (one of the) reasons is that the state tracker does
colourspace conversion in software if the winsys wants a format that the
driver doesn't advertise. Unre
> struct panfrost_bo {
> -struct pipe_reference reference;
> +int refcnt;
>
> /* Mapping for the entire object (all levels) */
Why are we open-coding this instead of using pipe_reference?
> +pthread_mutex_lock(&screen->handle_table_lock);
> +_mesa_hash_
> +bool should_tile = !is_streaming && is_texture && is_2d &&
> !is_scanout;
I'm not opposed, but why can't we tile PIPE_BIND_SHARED textures? lima
does exactly that. If we can't tile them, we certainly can't AFBC them.
signature.asc
Description: PGP signature
__
> + switch(whandle->modifier) {
> + case DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_ROCKCHIP):
> + rsc->layout = PAN_AFBC;
> + break;
Why ROCKCHIP in particular? AFBC fourcc codes are based on modifiers,
and there are a *lot* of them. We need to figure out which upstre
> Again, the winsys just pulls the list of acceptable format/modifier
> pairs from the EGL format query. If Panfrost declares 1555+AFBC to be
> a supported combination, then the winsys will pass that on for clients
> to use. If it isn't working, my suggestion is to just never advertise
> it in the
Ah, sure. Thank you for clarifying!
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
We had vendored duplicates from pre-Mesa days; clean that up.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_afbc.c | 6 +++---
src/gallium/drivers/panfrost/pan_allocate.c | 4 ++--
src/gallium/drivers/panfrost/pan_allocate.h | 6 --
src/gallium/drivers
for the hardware, but works for many formats and is a sane
default for the moment.)
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_job.c | 86 +
src/gallium/drivers/panfrost/pan_job.h | 8 ++-
src/gallium/drivers/panfrost/pan_mfbd.c | 18
Full MRT support is a while away, but in the mean time, we can remove
code that explicitly assumes nr_cbufs <= 0, to minimize the obstacles
we'll face later when we add the whole thing.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_contex
Now that we have u2u8 implemented, we can move everything up into NIR
and eliminate the silly "blend epilogue" (no such thing; it's just a
fragment epilogue).
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 63 +--
.../p
201 - 300 of 991 matches
Mail list logo
