> + __u32 out_sync;
Why __u32 instead of u32 or uint32_t? I don't think we use the prefixed
types anywhere else.
> + int (*init_context) (struct panfrost_context *ctx);
> + void (*fence_reference) (struct pipe_screen *screen,
> + struct pipe_fence_handle **ptr,
//printf("Uploaded transient %d bytes\n", transient_count);
This will raised an unused variable warning for transient_count, better
comment both or neither.
Other than that, Reviewed-by: Alyssa Rosenzweig
I wonder if this will fix some of the memory leaks on non-DRM a
> "is_t6xx" is not going to scale. We need to do feature and issues.
> Doesn't have to be in this series though.
Indeed, that's not my concern for this particular series. On that note,
I suppose it doesn't matter right now; we only advertise out-of-the-box
support for T860 so it doesn't matter if
Reviewed-by: Alyssa Rosenzweig
Out of curiosity, when would this code path be needed? Was this a
problem on the non-DRM driver too, or just the new kernel which makes
heavier use of real BOs?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Wooo!!!
Seeing this patch in my inbox has been some of the best news all day!
Without further ado, my (solicited?) comments:
> +/* Copyright 2018, Linaro, Ltd., Rob Herring */
Please triple check upstream that this license is okay; the other files
in include/drm-uapi are BSDish.
> +/* tim
> I get roughly the same demos working with it as with Arm's driver, but
> there's lots of improvements to be made (mostly in the kernel) to how
> memory is managed and jobs are scheduled.
Which demos have regressed, just so we can keep track?
___
mesa-d
> Why aren't we using regular dma-buf fences here? The submit ioctl
> should be able to take a number of in fences to wait on and return an
> out fence if requested.
Ah-ha, that sounds like the "proper" approach for mainline. Much of this
was (incorrectly) inherited from the Arm driver. Thank you
> You should more likely be using syncobjects, not fences.
...I still don't know what either of them actually are...?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> The patches in this MR are needed so the nondrm backend keeps working:
>
> https://gitlab.freedesktop.org/panfrost/nondrm/merge_requests/1
Oh, thank you! I didn't see this the first time around; ignore all the
comments about nondrm regressions. Sorry for the confusion.
-A
_
> With non-DRM this code doesn't execute (at least on the workloads I tested
> with) because we don't support GEM handles for !scanout.
Gotcha, thank you.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/list
> One is that with kbase I don't see any noticeable pauses during the very
> first scene in glmark2.
...That sounds like a good thing? :)
> Another is that with the DRM driver I don't see the wallpaper in GNOME Shell.
GNOME Shell is very broken under Panfrost; that's not a kernel-space
regressio
> Alyssa: do you see any problem if we change to submit only one atom per
> ioctl?
I don't think so; aesthetically I don't like the extra kernel traffic,
but that's not a real concern, and it sounds like that's the correct
approach anyway.
A big reason we submit together on non-DRM is so we can g
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_assemble.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_assemble.c
b/src/gallium/drivers/panfrost/pan_assemble.c
index f3b339d8184..7e2f24edd71 100644
--- a/src
Patches 1-7 are Reviewed-by: Alyssa Rosenzweig
Patch 8 I don't have time to read through right now but will get to this
evening.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> This doesn't work for t604 which has a special version of 0x6???. That
> helpfully also collides with bifrost versions. We could fix this up in
> the kernel to expose it as 0x0600. Then an 'is_bifrost' would be an
> easy (gpu_id & 0xf000).
I think there's a fundamental question here, do we want
> +/**
> + * struct drm_panfrost_wait_bo - ioctl argument for waiting for
> + * completion of the last DRM_PANFROST_SUBMIT_CL on a BO.
Nit: Should be plain DRM_PANFROST_SUBMIT, there is no CL for us.
> + __s64 timeout_ns; /* absolute */
Erm, why is this signed? Semantically, what does
With a unified layout field, we can specify the logic for BO layout
explicitly, deciding between linear/tiled/AFBC based on the specified
usage/binding flags.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 64 ++---
1 file changed, 44
In an effort to cleanup framebuffer management code, we delay
colour buffer setup until the FRAGMENT job is actually emitted, allowing
the AFBC and linear codepaths to be unified.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 93 --
1 file
I'm not sure why we were checking for these additional criteria (likely
inherited from some other driver); remove the needless checks to cleanup
the code and perhaps fix some bugs down the line.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c
This emit is only implemented for AFBC depth/stencil buffers, so
conceptually there is no change here, but we follow the style of the
previous patch to improve robustness and clarity.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 71 +-
1
needed to let layouts switch seemlessly to handle edge
cases, but this series is already a nontrivial improvement (and it *is*
getting long).
Alyssa Rosenzweig (12):
panfrost: Cleanup needless if in create_bo
panfrost: Combine has_afbc/tiled in layout enum
panfrost: Delay color buffer setup
tiled for depth).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 9db667d8287..099d6d0389b 100644
--
To be clear, the layout switching voodoo is still a hack that needs to
be cleaned up. But that's a job as big as this patch series always-is,
so at least explain _why_ we're working counterintuitively.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resou
We were setting this bit as a magic value for a while when using depth
FBOs, but it is only now clear what the meaning is.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/include/panfrost-job.h | 8
src/gallium/drivers/panfrost/pan_context.c | 5 ++---
2
else, having this implemented helps with
understanding the hardware, bringing to light some magic bits.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 30 +-
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers
.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 59 +++---
1 file changed, 42 insertions(+), 17 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index d54b3df5962..9db667d8287
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h| 8 +++-
src/gallium/drivers/panfrost/pan_context.c | 16
.../drivers/panfrost/pandecode/decode.c| 18 +-
3 files changed, 28 insertions(+), 14 deletions(-)
diff -
, though not introduced (so not a real regression) in the
previous commit.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 32 -
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b
AFBC, tiled, and linear BO layouts are mutually exclusive; they should
be coupled via a single enum rather than ad hoc checks of booleans.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 33 ++--
src/gallium/drivers/panfrost/pan_resource.c | 34
> I'm pretty sure it will be obsolete in only 240 years too. :)
Ecclesiastes 1:9, alas :P
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> Can we use a constant instead?
The right solution is to actually RE the format bits for SFBD (which
will be necessary if we're serious about supporting https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> If I comment the line immediately above, things work as expected.
Interesting, okay, this is definitely a regression on kbase too. I'll
investigate this evening -- I think I need to be checking the depth mask
before setting this bit..?
___
mesa-dev mai
Fixes a gcc warning.
Signed-off-by: Alyssa Rosenzweig
---
src/compiler/nir/nir_opt_loop_unroll.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/compiler/nir/nir_opt_loop_unroll.c
b/src/compiler/nir/nir_opt_loop_unroll.c
index 9ab0a924c82..41f7a834164 100644
--- a/src/compiler/nir
Fixes a gcc warning (and a theoretical NULL dereference error, though I
suppose shortcircuiting avoids that).
Signed-off-by: Alyssa Rosenzweig
---
src/compiler/nir/nir_loop_analyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_loop_analyze.c
b/src
> A better fix might be to delete the Mesa src tree, that should fix up any
> warnings :P
Huh, so it does!
No regressions on dEQP, possibly since all the tests were failing to
begin with on Panfrost.
> I can only assume this was sent out by mistake?
This was sent out by "I don't know what I'm d
> [1] https://patchwork.freedesktop.org/patch/291616/
Ah-ha, somebody who knows what they're doing. That's good; ignore this
series then :)
---
So is this a "no" for the deleting ~/mesa/src idea?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
> The first patch was fine. Just not the second.
First patch is a duplicate of the linked patch.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Both patches are:
Reviewed-by: Alyssa Rosenzweig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
as a major hack and probably causing issues.
Alyssa Rosenzweig (10):
panfrost: Break out fragment to SFBD/MFBD files
panfrost: Remove staging SFBD for pan_context
panfrost: Remove staging MFBD
panfrost: Minor comment cleanup (version detection)
panfrost/mfbd: Implement linear depth buffers
ff-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 108 -
src/gallium/drivers/panfrost/pan_context.h | 1 -
2 files changed, 38 insertions(+), 71 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/pan
The fragment framebuffer descriptor should not be a context entry;
rather, it should be constructed only at fragment time to keep analysis
tractable.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.h | 5 +-
src/gallium/drivers/panfrost/pan_fragment.c | 7
This substantially cleans up the corresponding logic at the expense of a
bit of code duplication; nevertheless, it's a net win since otherwise
incompatible hardware code is mixed confusingly.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/meson.build| 3 +
src/ga
Same idea as the previous commit, but for the MFBD this time instead of
the SFBD.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.h | 13 --
src/gallium/drivers/panfrost/pan_mfbd.c| 194 +++--
2 files changed, 98 insertions(+), 109 deletions
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_mfbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_mfbd.c
b/src/gallium/drivers/panfrost/pan_mfbd.c
index 68c842981f3..ac7f9ed665f 100644
--- a/src/gallium/drivers
For inexplicable reasons, the depth buffer is faster if kept as linear,
whereas the colour buffers are faster if AFBC. Given both code paths are
available, we'll choose the faster one of each (which also helps with
testing coverage).
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/dr
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_context.c
b/src/gallium/drivers/panfrost/pan_context.c
index 48e471eace2..cb226cc2220 100644
--- a/src
This removes a clunky hack where the depth buffer was enabled during the
*clear*, instead of during depth buffer linking. That said, this does
not yet support writeback like AFBC depth buffers.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_mfbd.c | 19
It's not clear why the hardware "spills" a little bit, but if we don't
do this, we get MMU faults with linear depth buffers.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gall
depth buffers.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 30 --
src/gallium/drivers/panfrost/pan_job.h | 9 +--
src/gallium/drivers/panfrost/pan_mfbd.c| 21 ---
src/gallium/drivers/panfrost/pan_sfbd.c| 2
We have a native op for this, which was just found in a disassembly --
so instead of lowering, use it!
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/midgard/helpers.h | 1 +
src/gallium/drivers/panfrost/midgard/midgard.h | 2 ++
src/gallium/drivers/panfrost
This function is replicated across vc4/v3d/freedreno and is needed in
Panfrost; let's make this shared code.
Signed-off-by: Alyssa Rosenzweig
---
src/util/u_drm.h | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 src/util/u_drm.h
Signed-off-by: Alyssa Rosenzweig
Cc: Eric Anholt
---
src/gallium/drivers/vc4/vc4_resource.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/vc4/vc4_resource.c
b/src/gallium/drivers/vc4/vc4_resource.c
index c12187d7872..93688cde998
Signed-off-by: Alyssa Rosenzweig
Cc: Eric Anholt
---
src/gallium/drivers/v3d/v3d_resource.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/src/gallium/drivers/v3d/v3d_resource.c
b/src/gallium/drivers/v3d/v3d_resource.c
index ddecafe2ec9..71248e9ca1e
Signed-off-by: Alyssa Rosenzweig
Cc: Rob Clark
---
.../drivers/freedreno/freedreno_resource.c| 20 ---
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c
b/src/gallium/drivers/freedreno/freedreno_resource.c
Reviewed-by: Alyssa Rosenzweig
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> hmm, I guess there are already two or three other places that already
> copy/pasta'd this specifically for modifiers.. so I'm ok with the less
> generic name, since it (IMHO) makes the code calling it more clear.
This was my reasoning, yeah... I'm not sure why it is so generic,
honestly (should
I don't know why this was on to begin with...?
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_screen.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_screen.c
b/src/gallium/drivers/panfrost/pan_screen.c
index 9cd65c
In addition to fixing actual primconvert bugs, this prevents an infinite
loop when trying to draw POINTS.
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
Mipmaps are still broken, but at least this way we don't crash on some
apps using mipmaps.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_resource.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pan_resource.c
b/src/gallium/dr
This is required for gl_PointCoord to show up on decodes.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pandecode/decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c
b/src/gallium/drivers/panfrost
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pandecode/decode.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pandecode/decode.c
b/src/gallium/drivers/panfrost/pandecode/decode.c
index e6932744939..28bc0509feb
> This is needed if you can only handle point sprites on certain
> varyings but not others. This is the case for nv30- and nvc0-based
> GPUs, which is why the cap was introduced.
>
> If your GPU does not have such restrictions, you can safely remove the cap.
Ah-ha, I see, thank you.
I can't hand
There is no BO tracking for vertex buffers yet, so it is not safe to
directly map even when we can according to alignment restrictions. For
now, always create a shadow buffer.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_context.c | 5 -
1 file changed, 4 insertions
> So you have to be able to generate both S,T and S,1-T. [Or
> perhaps there's an explicit control for it, I forget.] With GLES2+,
> it's just gl_PointCoord though.
FWIW, the blob emits a linear (er, affine technically?) transformation
in the shader to do the flip, loading the matrix from a specia
y; support for gl_PointCoord is included with this patch.
All in all, I'm quite happy with how this turned out.
Signed-off-by: Alyssa Rosenzweig
---
.../drivers/panfrost/include/panfrost-job.h | 7 +
.../panfrost/midgard/midgard_compile.c| 52 +--
.../panfrost/midgard/mi
in
nir_opt_algebraic.py, hanging the compiler. This patch thus makes the
existing pass optional (default on -- all other backends should remain
unaffected), adding an optional pass for lowering the opposite
direction.
Signed-off-by: Alyssa Rosenzweig
---
src/compiler/nir/nir.h| 3 +++
> Tell me a little more about what your hardware supports.
Both integers and floats are first-class; they are each natively 32-bit,
with 16-bit versions to be supported down the line. There's support for
int8 and float64, but I haven't seen these used with GLSL, so I don't
know how they work.
Fr
ion itself.
Signed-off-by: Alyssa Rosenzweig
---
src/compiler/nir/nir.h| 3 +++
src/compiler/nir/nir_opt_algebraic.py | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 5b28c727c8..fe0887865c 100644
--- a/
> That all sounds good. Those are exactly the things we wanted when
> creating NIR, so it's nice to hear :)
Hooray!
> It might be beneficial for you to lower b2f there
Ah, I had not noticed that section was seperate. Yes, I think you're
right about that.
Updated patch sent. (I hope I did this r
Hi all,
Certain embedded GPUs do not implement coordinate transformation in
hardware. Instead, section 12.5 "Coordinate Transformation" of the ES
3.2 specification is implemented in the vertex shader itself. Relevant
examples include Midgard and vc4.
To handle this, a lowering pass is needed to c
For how this affects Lima, see
https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg189216.html
Signed-off-by: Alyssa Rosenzweig
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_nir.cpp
> I'm also working on a pass to recombine io to vectors which should
> hopefully allow you to have the best of both worlds in future.
Ooo, exciting. Thank you! :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mail
For what it's worth, Midgard has real integers (including int32
support), using hardware-level D3D10 boolean conventions. I'm trying to
wrap my head around how this interacts with 5d85a0a.
I'm tempted to think the standard lower_bool_to_int32 pass would work,
with an emulated b2f instruction in th
> Right. Sorry. I forgot who's working on what chip these days. Maybe Ilia
> can CC the right person.
No worries at all! It may well have been me (I had touched the b2f code;
our hardware lacks a dedicated instruction and needs `iand 1.0` to do
the conversion). I'm not sure which hardware lacks
> If you want to set me straight, that's probably the better patch to
> argue it out. :)
No, I thought about it; you're right. I understand my hardware (and NIR)
much better now than what I wrote the earlier patch; you have now shown
me the error of my ways :)
Nothing special should be needed for
I think so?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
regs is only set and used on x86; on other platforms (like ARM), this
code causes a trivial warning, solved by moving the regs declaration to
the architecture-dependent usage.
Signed-off-by: Alyssa Rosenzweig
---
src/util/u_cpu_detect.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
nd non-ES2 modes like logic ops are
planned for the future.
Signed-off-by: Alyssa Rosenzweig
---
src/gallium/auxiliary/meson.build | 2 +
src/gallium/auxiliary/nir/nir_lower_blend.c | 188
src/gallium/auxiliary/nir/nir_lower_blend.h | 36
3 files changed, 226
Alright, thank you :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> I would love to see this up in src/compiler/nir.
Is there a compelling reason to have it in NIR rather in Gallium, adding
an extra layer of translation overhead / indirection when coming from
Gallium blend state? (Mythical future Vulkan support, I guess?)
> Also, we should probably convert vc4
> 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 think
> 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 t
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
> 3436e5295b pan/bi: Treat +DISCARD.f32 as message-passing
>
>
>
>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 lis
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, 2021
> 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 N
> 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 assume
Hi Dylan,
Commentary on the two Panfrost patches:
> cff5c40fc3 pan/bi: Fix blend shaders using LD_TILE with MRT
>
>
>
> 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 i915
> 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, w
> 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
> > >> 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. S
> 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 prioritize
> 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 src/gallium/frontends/mesa
>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
>
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 th
>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 LL
> 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.
101 - 200 of 991 matches
Mail list logo
