We see the hardware doesn't actually support float framebuffers in the
native sense -- rather, it just allows higher bpp framebuffers and lets
a blend shader / additional clear_color fields sort out the formats.
This will be.. interesting.
Signed-off-by: Alyssa Rosenzweig
---
src/ga
This series is focused on rendering to more render target formats,
particularly ones that require the use of a blend shader. As an aside in
the middle, this leads us to implement preliminary fp16/i16 support in
the Midgard compiler.
Depends on the accompanying NIR and Gallium patches.
Alyssa
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/meson.build | 1 +
.../panfrost/midgard/nir_lower_blend.h| 3 +
.../panfrost/midgard/nir_lower_framebuffer.c | 102 ++
.../drivers/panfrost/pan_blend_shaders.c | 2 +
4 files changed, 108
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_compile.c| 11 +++
.../panfrost/midgard/nir_lower_framebuffer.c | 15 ---
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index 32cc55c52ee
, which here is handled via an
algebraic pass.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 51 ++-
.../panfrost/midgard/midgard_nir_algebraic.py | 14 -
2 files changed, 62 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers
This begins the process of removing blend shader specific MIR into a
more general NIR lowering pass for formats.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_compile.c | 13 +
.../panfrost/midgard/nir_lower_framebuffer.c| 4 ++--
2 files
Rather than using a dest_override, we upscale integers by using a half
field with a sign-extend bit. A variant of this trick should also work
for floats, but one step at a time!
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 73 +++
1 file
Blend constant conflicts run in two directions.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_schedule.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_schedule.c
b/src/gallium/drivers/panfrost/midgard
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 17 +++---
.../panfrost/midgard/nir_lower_framebuffer.c | 33 +--
2 files changed, 36 insertions(+), 14 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b
The packing is a little different, so implement that.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_emit.c | 47 ++-
.../panfrost/midgard/midgard_schedule.c | 21 +++--
2 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/src
The scale and type-convert can now be expressed in NIR, rather than MIR,
which is significantly more maintainable and demonstrates correctness of
the type conversion patches.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 52
These conversions handle half-floats within the shader.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_compile.c | 18 ++
.../panfrost/midgard/midgard_nir_algebraic.py | 5 -
.../panfrost/midgard/nir_lower_framebuffer.c | 7 +--
3 files
It's not clear where the extra indirection was from (older hardware or
just older blobs?)
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 28 ---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/src/gallium/drivers/pan
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
b/src/gallium/drivers/panfrost/midgard/midgard_nir_algebraic.py
index
as we might like).
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/compiler.h | 7 ++-
.../drivers/panfrost/midgard/helpers.h| 21 ++---
.../panfrost/midgard/midgard_compile.c| 43 +--
.../drivers/panfrost/midgard/midgard_emit.c
We can handle differing, but we'd prefer not to because there are
restrictions on sizing which aren't accounted for yet.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff -
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_compile.c
index
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/nir_lower_blend.c| 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/nir_lower_blend.c
b/src/gallium/drivers/panfrost/midgard/nir_lower_blend.c
index af0a7ac31cf
Not all framebuffer formats are supported by the fixed-function blender.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blending.c | 41 -
src/gallium/drivers/panfrost/pan_blending.h | 7 +++-
src/gallium/drivers/panfrost/pan_context.c | 11 +++---
3
We'll need some careful handling, but for now, get some baseline code
out for handling float formats in a blend shader.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/nir_lower_framebuffer.c | 40 +++
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git
Normally, disabled blend can definitely be fixed-function'd away, but
if a blend shader is used merely for format conversion rather than
blending, this code path can be nevertheless hit.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/pan_blend_shaders.c
precision). Just be clearer about how/why.
Also, RGB5_A1 support is still broken; let's not worry about that quite
yet.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_screen.c | 50 +--
1 file changed, 10 insertions(+), 40 deletions(-)
diff --git
We would like to permit keying blend shaders against the framebuffer
format, which requires some new blending abstractions.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/meson.build | 1 +
src/gallium/drivers/panfrost/pan_blend.h | 109 +++
src/gallium
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blending.c | 4
src/gallium/drivers/panfrost/pan_mfbd.c | 11 ++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_blending.c
b/src/gallium/drivers/panfrost
omentarily while we're not interested in actually blending.
As an aside, I'd be fascinated by an integer-based blending
implementation.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/nir_lower_framebuffer.c | 40 ---
1 file changed, 26 insertions(+), 14 dele
Rather than have random variables flying around and a long if-else
chain, use a switch. They're literally *designed* for this.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blending.c | 5 +
src/gallium/drivers/panfrost/pan_mfbd.c | 162 +++---
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/nir_lower_blend.h| 3 ++-
.../drivers/panfrost/midgard/nir_lower_framebuffer.c | 3 +--
src/gallium/drivers/panfrost/pan_blend_shaders.c | 8 ++--
src/gallium/drivers/panfrost/pan_blend_shaders.h
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/nir_lower_framebuffer.c | 49 ---
1 file changed, 31 insertions(+), 18 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/nir_lower_framebuffer.c
b/src/gallium/drivers/panfrost/midgard
Ideally, we would keep Galliumisms far away from the compiler;
unfortunately, Mesa hasn't standardized on system of format codes to be
shared across APIs and across drivers, so using Gallium formats is our
best bet in the short run.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/mi
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_schedule.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_schedule.c
b/src/gallium/drivers/panfrost/midgard/midgard_schedule.c
index caa29b7a2e4
Eventually this should be replaced by proper tex RA / not emitting so
many silly moves to begin with / better general copy prop. For now
remove it since it breaks things.
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_compile.c| 50 ---
1 file changed
We would like the offset field to be unsigned, letting 0 represent "no
offset" and positive represent an offset.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/galli
We see that the render target itself turns out to be typeless
(surprise!)
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_mfbd.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_mfbd.c
b/src/gallium
We now have some preliminary fp16 support available. We're not able to
expose this for GLSL quite yet, but for internal blend shaders, we're
able to do control bitness ourselves just fine. So let's fp16 that
stuff!
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/p
We add support for writing out (via a blend shader):
- RGBA4
- RGB10_A2_UNORM
- RGB10_A2_UINT
- RGB5_A1_UNORM
- R11G11B10_FLOAT
Signed-off-by: Alyssa Rosenzweig
---
.../panfrost/midgard/midgard_nir_algebraic.py | 2 +
.../panfrost/midgard/nir_lower_framebuffer.c | 113
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_emit.c | 3 ++-
.../panfrost/midgard/midgard_schedule.c | 27 ---
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_emit.c
b/src/gallium
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 5 +
src/gallium/drivers/panfrost/midgard/nir_lower_framebuffer.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_mfbd.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_mfbd.c
b/src/gallium/drivers/panfrost/pan_mfbd.c
index d14fb4269db..f262f6a592d 100644
--- a/src/gallium/drivers/panfrost
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/nir_lower_framebuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/nir_lower_framebuffer.c
b/src/gallium/drivers/panfrost/midgard/nir_lower_framebuffer.c
A step in the right direction, but not totally right I don't think.
> +struct pipe_surface *surf = ctx->pipe_framebuffer.zsbuf;
> +struct panfrost_resource *rsrc = pan_resource(surf->texture);
> +sfbd->depth_buffer = rsrc->bo->gpu;
Critically, ctx->
It won't work. Just, stop it.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard_compile.c
b/src/gallium/drivers/panfrost/midgard/midgard_comp
Fixes a buggy dEQP test.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/ci/expected-failures.txt | 6 --
src/gallium/drivers/panfrost/meson.build | 1 +
.../drivers/panfrost/midgard/compiler.h | 6 ++
.../panfrost/midgard/midgard_compile.c| 4 +
.../panfrost
We have to emit it anyway for the report to be happy (with respect to
unrolling), so return an actual count rather than dummy numbers.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/compiler.h| 3 +++
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 8
bany/ball type ops read from all 4 channels even though they only write
to 1; specify this in the opcode table like we do for dot products.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard_ops.c | 16
1 file changed, 8 insertions(+), 8 deletions
Panfrost is known to only work on a select few CPU/GPU combinations at
the moment (tested system-on-chips: RK3288, RK3399, and S912). Whitelist
the combinations known to work and refuse to load on others where
nothing works yet to avoid user confusion.
Signed-off-by: Alyssa Rosenzweig
---
src
All the kool kids are doing it.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/midgard/midgard.h| 1 +
.../panfrost/midgard/midgard_compile.c| 39 +++
2 files changed, 40 insertions(+)
diff --git a/src/gallium/drivers/panfrost/midgard/midgard.h
b
The asterisks were inherited from... softpipe, maybe?
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_screen.c | 46 +++
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers
It's easy to forget about, but shader size does matter for things like
i-cache, so let's include it in the analysis.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_compile.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff -
(rel) min: 1.27% max: 7.69% x̄: 4.30% x̃: 4.77%
95% mean confidence interval for bundles value: -1.68 -0.75
95% mean confidence interval for bundles %-change: -5.63% -2.97%
Bundles are helped.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/midgard_schedule.c | 2 +-
1
Oops.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_blend.h | 2 +-
src/gallium/drivers/panfrost/pan_blend_cso.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_blend.h
b/src/gallium/drivers/panfrost
to access higher dEQP versions (i.e. in
order to debug the features we're hiding behind the CAP). For these, we
hide the CAP behind a special PAN_MESA_DEBUG=deqp option to avoid
apps randomly using these in-development features.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfro
It's a known upstream issue; it was taken off the mustpass list but... I
have issues, ok? I just really wanted 100/100 passing :)
I think it was 16.
On Wed, Jul 10, 2019 at 03:48:35PM +0200, Erik Faye-Lund wrote:
> On Wed, 2019-07-10 at 06:24 -0700, Alyssa Rosenzweig wrote:
> >
> I don't think other drivers have had to do this. I've definitely
> resisted stuff like that in nouveau in the past. Are you sure this is
> necessary? Would be good to check if these tests pass or fail on
> nouveau, for example. (Although by coincidence, they could be ending
> up with zero values,
This hunk is R-b, the rest are NAK-ed due to reasons I'm sure you
realize (breaking MFBD ;) )
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
R-b
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Thank you for the patch!
Could you add a comment to include/panfrost_job.h explaining why this
works?
Thanks,
Alyssa
On Thu, Jul 18, 2019 at 01:11:21PM +0200, Rohan Garg wrote:
> Make sure we adjust draw_start and vertex_count in order to
> take into account a index_bias as required by a glDraw
We don't need to guesstimate this ourselves. This will help when we
bringup derivatives.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 1 +
src/gallium/drivers/panfrost/pan_context.c | 2 +-
src/gallium/drivers/panfrost/pan_context.h | 3 +++
3
No need to track this ourselves!
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 2 +-
src/panfrost/midgard/compiler.h | 3 ---
src/panfrost/midgard/midgard_compile.c | 4
src/panfrost/midgard/midgard_compile.h | 1 -
4 files changed
Again, it's in shader_info for us!
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 8 ++--
src/panfrost/midgard/midgard_compile.h | 3 ---
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_assemble
will be a win when wiring in Bifrost support.
Alyssa Rosenzweig (4):
panfrost: Use NIR helper invocations info
panfrost: Use nir_gather_info information about discards
panfrost: Don't DIY point size/coord fields
panfrost: Compute I/O counts from shader_info
src/gallium/driver
...rather than exposing it in the vendored compiler region.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 17 ++---
src/panfrost/midgard/midgard_compile.c | 3 ---
src/panfrost/midgard/midgard_compile.h | 3 ---
3 files changed, 14
A-b
On Thu, Jul 25, 2019 at 01:26:07PM +0200, Tomeu Vizoso wrote:
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/ci/debian-install.sh | 4 ++--
> src/gallium/drivers/panfrost/ci/gitlab-ci.yml | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/
Theoretically we were supposed to set ctx->job to the current job, I
guess cacheing the result of panfrost_get_job_for_fbo()
See v3d's implementation which this is a carbon clone of.
On Fri, Aug 02, 2019 at 12:12:49PM +0200, Boris Brezillon wrote:
> This field is never set to anything but NULL, w
What happens if the CPU creates jobs significiantly faster than the GPU
processes them? Could you have four jobs for the same framebuffer in
flight at once?
At present, we do some heavy flushing so "no" but in the future we'll
want to lax up for performance.
On Fri, Aug 02, 2019 at 12:12:50PM +02
R-b
On Fri, Aug 02, 2019 at 12:12:52PM +0200, Boris Brezillon wrote:
> If the current FB matches the new one there's nothing to be done in
> panfrost_set_framebuffer_state(). By bailing out early in that case we
> avoid emitting new FB descriptors (the old ones are still valid).
>
> Signed-off-by
R-b, thank you :)
On Fri, Aug 02, 2019 at 12:12:51PM +0200, Boris Brezillon wrote:
> No need to emit SFBD/MFBD at frame invalidation. They can be emitted
> when the framebuffer is attached, which saves us a potential FB desc
> re-allocation if a new FB is bound after the swap.
>
> Signed-off-by:
R-b, thank you especially for the comment deconstructing this magic.
On Fri, Aug 02, 2019 at 12:12:53PM +0200, Boris Brezillon wrote:
> The wallpaper blit is a bit special in that the operation is targetting
> the current FB, but the u_blitter logic creates a new surface for it
> which makes util_
So, in the future, we'll want to have multiple jobs for different
framebuffers independently in flight at the same time. As an
illustrative example, we would like the app to be able to do a sequence
like:
bind scanout
clear
draw something
bind FBO
clear
R-b, I think.
On Fri, Aug 02, 2019 at 12:12:55PM +0200, Boris Brezillon wrote:
> The only user of this function always passes true.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/drivers/panfrost/pan_context.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git
Is there any cleanup we can simultaneously? (Where the check was done
outside?) Or is this a futureproofing?
On Fri, Aug 02, 2019 at 12:12:56PM +0200, Boris Brezillon wrote:
> Allows us to pass BOs without checking if they're NULL or not.
>
> Signed-off-by: Boris Brezillon
> ---
> src/gallium/d
R-b, but I guess I'm biased :)
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> Note that before this patch, someone trying to get a new job for an FB
> that already has a job running would actually get the old job object
> and might start messing up with it. Not sure that's what we want.
I don't think that's what we want either, and I think I took pains to
ensure this woul
> Was hitting a NULL pointer dereference when on the
> panfrost_bo_unreference(job->polygon_list) done in panfrost_free_job().
> Don't know having a NULL polygon_list is valid case (I guess that's
> possible for a job that does not involve the tiler) but I was facing
> this problem when running the
R-b! Nice! :)
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> Bifrost does not accept a index_bias and relies instead on a bias
> correction offset ( offset_bias_correction ) in order to calculate the
> unbiased vertex index.
Bifrost?
> +/* Negative of min_index. This is done in order to identify each
> vertex
> + in vertex shader runs.
> +for (unsigned c = 0; c < 4; ++c) {
> +struct panfrost_blend_rt *rt = &blend->rt[c];
> +_mesa_hash_table_u64_clear(rt->shaders,
> panfrost_delete_blend_shader);
> +}
What's the implication of the clear call? Does that recursively free
the blend C
What's the implication of this for Panfrost? (I.e. which patch/es in the
series are pending on this change)
On Mon, Aug 05, 2019 at 05:18:32PM +0200, Tomeu Vizoso wrote:
> Some hash functions (eg. key_u64_hash) will attempt to dereference the
> key, causing an invalid access when passed DELETED_KE
To be clear, Panfrost relies on stuffing (bogus) magic numbers into u64
keys and u64 values. Is this going to break on us? That is, when you
mention this is a bug, who's buggy here? (Panfrost or hash_table_u64 or
both?)
On Mon, Aug 05, 2019 at 09:10:00AM -0700, Caio Marcelo de Oliveira Filho wrote
> +if (screen->kernel_version >= 1) {
Maybe have some #defines for kernel versions instead of magic numbers?
Also, maybe make it clear that this is a minor version -- what does
happen if we bump the major version at some point...?
> panfrost_create_screen(int fd, struct renderonly *ro)
>
Reviewed-by: Alyssa Rosenzweig
On Mon, Aug 05, 2019 at 05:18:35PM +0200, Tomeu Vizoso wrote:
> What we call GROWABLE in Mesa corresponds to the HEAP BO flag in the
> kernel. These buffers cannot be memory mapped in the CPU side at the
> moment, so make sure they are also marked
I didn't know about %m, nifty.
I don't think this is portable, though... which might be a problem
if/when someone tries to port Android, etc.
On Mon, Aug 05, 2019 at 05:18:36PM +0200, Tomeu Vizoso wrote:
> Signed-off-by: Tomeu Vizoso
> ---
> src/gallium/drivers/panfrost/pan_drm.c | 10 +
> Yeah, there's the wastage you describe, but we are currently wasting
> several megs so it's a vast improvement in this regard.
Ah, touche.
> For more fine-grained performance and memory usage improvements, I
> think we should track these kind of regressions in CI, or we'll
> struggle to consist
> Android should be fine, as they use it in their own code.
Hmm, still uncomfortable, but tentative R-b I guess :/
I just.. don't like relying on glibc specific behaviour. Even if bionic
implements it too, I mean... what happens for the postmarketOS guys?
They've been interested in Panfrost f
R-b but already been pushed.. please use my Collabora email so I see
stuff on time! :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Alright, you win ;) R-b!
On Tue, Aug 06, 2019 at 05:06:32PM +0200, Tomeu Vizoso wrote:
> On Tue, 6 Aug 2019 at 16:58, Alyssa Rosenzweig wrote:
> >
> > > Android should be fine, as they use it in their own code.
> >
> > Hmm, still uncomfortable, but tentative R-b
Patches 2-5 have my R-b, looks good! :)
On Wed, Aug 07, 2019 at 10:36:54AM +0200, Tomeu Vizoso wrote:
> Instead of all shaders being stored in a single BO, have each shader in
> its own.
>
> This removes the need for a 16MB allocation per context, and allows us
> to place transient blend shaders
Rather than hardcoding certain varying buffer indices "by convention",
work it out at draw time. This added flexibility is needed for
futureproofing and will be enable streamout.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 6 ---
src/galli
This will allow us to shuffle buffers.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_varyings.c | 71 ++---
1 file changed, 63 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_varyings.c
b/src/gallium/drivers/panfrost
This code is fairly self-contained, so let's factor it out of the giant
pan_context.c monster.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/meson.build| 1 +
src/gallium/drivers/panfrost/pan_context.c | 156 -
src/gallium/drivers/pan
> This is using the
> untranslated flags, but I think it should be the 'translated_flags' as
> those are the ones changing the allocation.
It's a little more complex than that. There some hypothetical
untranslated flags that I would want to match on. For instance, future
CPU read-only/write-only m
> Is this going to work on Android and bionic? stderr goes to /dev/null
> anyways on Android, so probably not a big deal.
Tomeu said yes.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.fr
@Boris I don't see why this patch particularly needs to be backported to
19.1?
On Thu, Aug 08, 2019 at 11:46:43AM +0200, Juan A. Suarez Romero wrote:
> On Fri, 2019-08-02 at 19:18 +0200, Boris Brezillon wrote:
> > ctx->job is supposed to serve as a cache to avoid an hash table lookup
> > everytime
GL_TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN should now be handled.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost
We're just going to compute them in the driver but let's get the
structures setup to handle them. Implementation from v3d.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 52 --
src/gallium/drivers/panfrost/pan_context.h | 15
This is a huge hack to workaround incomplete BO flushing logic, but it's
enough for the dEQP transform feedback tests, and doing the resource
management to get this right is out-of-scope for this patch series.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.
It's there in shader_info, but we need to access it from pan_context.c
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 6 +-
src/gallium/drivers/panfrost/pan_compute.c | 2 +-
src/gallium/drivers/panfrost/pan_context.c | 5 -
src/gallium/dr
We could probably get away with doing this once per pipe_shader_state
but let's not jump down that rabbit hole quite yet.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 7 +++
src/gallium/drivers/panfrost/pan_context.h | 2 ++
2 files changed, 9 inser
We have to maintain the internal offset ourselves. Per v3d.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 10 ++
src/gallium/drivers/panfrost/pan_context.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/src/gallium/drivers/panfrost
We'll need this in a moment. Ken's implementation, lightly edited for
Panfrost.
Signed-off-by: Alyssa Rosenzweig
Suggested-by: Kenneth Graunke
---
src/gallium/drivers/panfrost/pan_context.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/src/gallium/driver
301 - 400 of 991 matches
Mail list logo
