Like many free software projects, Nouveau recently moved from Freenode
to OFTC. Update the reference.
v3: Add acks.
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Karol Herbst
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-ker...@vger.kernel.org
---
Documentation/driver-api/thermal
.
v2: Correct typo in commit message pointed out by Lukas and Jonathan.
Add Hector's ack.
v3: Add acks.
[1] https://lists.freedesktop.org/archives/dri-devel/2021-May/307605.html
Signed-off-by: Alyssa Rosenzweig
Acked-By: Hector Martin
Acked-by: Jani Nikula
Cc: Karol Herbst
Cc: David Airli
Not that you need it but this patch is Reviewed-by: Alyssa Rosenzweig
On Wed, Apr 21, 2021 at 01:28:55PM +0800, Nicolas Boichat wrote:
> Add support for MT8183's G72 Bifrost.
>
> Signed-off-by: Nicolas Boichat
> Reviewed-by: Tomeu Vizoso
> Reviewed-by: Steven Price
&g
Acked-by: Alyssa Rosenzweig
On Thu, Aug 05, 2021 at 12:46:52PM +0200, Daniel Vetter wrote:
> Just deletes some code that's now more shared.
>
> Note that thanks to the split into drm_sched_job_init/arm we can now
> easily pull the _init() part from under the submission lock
uint8_t actual = region_width(test);
assert(expected == actual);
}
}
Alyssa Rosenzweig (3):
drm/panfrost: Simplify lock_region calculation
drm/panfrost: Use u64 for size in lock_region
drm/panfrost: Clamp lock region to Bifrost minimum
drivers/g
undefined behaviour when locking all memory (size ~0),
caught by UBSAN.
Signed-off-by: Alyssa Rosenzweig
Reported-and-tested-by: Chris Morgan
Cc:
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm
Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure
we can express the "lock everything" condition as ~0ULL without relying
on platform-specific behaviour.
Signed-off-by: Alyssa Rosenzweig
Suggested-by: Rob Herring
Tested-by: Chris Morgan
---
drivers/gpu/dr
KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it.
Signed-off-by: Alyssa Rosenzweig
Tested-by: Chris Morgan
Cc:
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
> > In lock_region, simplify the calculation of the region_width parameter.
> > This field is the size, but encoded as log2(ceil(size)) - 1.
> > log2(ceil(size)) may be computed directly as fls(size - 1). However, we
> > want to use the 64-bit versions as the amount to lock can exceed
> > 32-bits.
> > Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure
> > we can express the "lock everything" condition as ~0ULL without relying
> > on platform-specific behaviour.
>
> 'platform-specific behaviour' makes it sound like this is something to
> do with a particular board. This
> > When locking a region, we currently clamp to a PAGE_SIZE as the minimum
> > lock region. While this is valid for Midgard, it is invalid for Bifrost,
>
> While the spec does seem to state it's invalid for Bifrost - kbase
> didn't bother with a lower clamp for a long time. I actually think this
Use upper_32_bits/lower_32_bits helpers instead of open-coding them.
This is easier to scan quickly compared to bitwise manipulation, and it
is pleasingly symmetric. I noticed this when debugging lock_region,
which had a particularly "creative" way of writing upper_32_bits.
Signed-off-
on-aligned lock addresses
* Commit message improvements.
* Add Steven's tags.
Alyssa Rosenzweig (4):
drm/panfrost: Simplify lock_region calculation
drm/panfrost: Use u64 for size in lock_region
drm/panfrost: Clamp lock region to Bifrost minimum
drm/panfrost: Handle non-aligned lock add
s shifting by a negative number is undefined,
UBSAN flags the bug. Of course, even if it were defined the behaviour is
wrong, instead of locking all memory almost none would get locked.
The new form of the calculation corrects this special case and avoids
the undefined behaviour.
Signed-off-
ich remain in use with panfrost. (Mainly RK3288)
Signed-off-by: Alyssa Rosenzweig
Suggested-by: Rob Herring
Tested-by: Chris Morgan
Reviewed-by: Steven Price
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc:
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 12
KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it.
Signed-off-by: Alyssa Rosenzweig
Tested-by: Chris Morgan
Reviewed-by: Steven Price
Cc:
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff
. Therefore this doesn't need to be backported. Still, that's a
happy accident and not a precondition of lock_region, so we let's do the
right thing to future proof.
Signed-off-by: Alyssa Rosenzweig
Reported-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 3 +++
1
> > In practice, the current callers pass PAGE_SIZE aligned inputs, avoiding
> > the bug. Therefore this doesn't need to be backported. Still, that's a
> > happy accident and not a precondition of lock_region, so we let's do the
> > right thing to future proof.
>
> Actually it's worse than that du
> > Horrifying, and not what I wanted to read my last day before 2 weeks of
> > leave. Let's drop this patch, hopefully by the time I'm back, your
> > friends in GPU can confirm that's a spec bug and not an actual
> > hardware/driver one...
> >
> > Can you apply the other 3 patches in the mean tim
elpers for one more call site and add review tag (Steven).
Signed-off-by: Alyssa Rosenzweig
Reviewed-by: Rob Herring (v1)
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_job.c | 8
drivers/gpu/drm/panfrost/panfrost_mmu.c | 12 ++--
drivers/gpu/dr
n mode setting (x11). So this is
Tested-by: Alyssa Rosenzweig
I've cherry-picked the patch into my M1 staging/downstream tree, so I
guess that's an Acked-by. I don't know anything about the vm_* stuff in
the kernel yet, though, since can't give a reviewed-by. Will leave that
> > 3. Each VkCommandBuffer is two command buffers: one for compute and
> > one for binning, and you use some sort of HW synchronization mechanism
> > to handle the dependencies as you ping-pong between them.
>
> I didn't consider that option. We have a DOORBELL instruction on Bifrost
> to wake u
Panfrost hunks
Acked-by: Alyssa Rosenzweig
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> Yeah plus Cc: stable for backporting and I think an igt or similar for
> panfrost to check this works correctly would be pretty good too. Since
> if it took us over 1 year to notice this bug it's pretty clear that
> normal testing doesn't catch this. So very likely we'll break this
> again.
Unfo
> If YTR can't be turned off, then according to the AFBC spec - correct.
There is no public AFBC spec, so I'm not sure how to respond to this.
> If the hardware allows it to be configured to use YTR with other
> component orders, I don't know exactly what the impact would be -
> maybe nothing.
I
> I'm not familiar with panfrost's needs and I don't work on a tiler and
> I know there are different issues there. But...
The primary issue is we submit vertex+compute and fragment for each
batch as two disjoint jobs (with a dependency of course), reflecting the
internal hardware structure as pa
Reviewed-by: Alyssa Rosenzweig
On Wed, Jun 30, 2021 at 08:27:40AM +0200, Boris Brezillon wrote:
> Currently unused. We'll add it back if we need per-GPU definitions.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Steven Price
> ---
> drivers/gpu/drm/panfros
> > My Vulkan knowledge is limited so I'm not sure whether this is the right
> > approach or not. In particular is it correct that an application can
> > create a high priority queue which could affect other (normal priority)
> > applications?
>
> That's what msm does (with no extra CAPS check AFA
```
> +/* Syncobj reference passed at job submission time to encode explicit
> + * input/output fences.
> + */
> +struct drm_panfrost_syncobj_ref {
> + __u32 handle;
> + __u32 pad;
> + __u64 point;
> +};
```
What is handle? What is point? Why is there padding instead of putting
point f
> Better, but I was hoping we can mostly delete panfrost_ioctl_submit(),
> leaving something along the lines of:
>
> static int panfrost_ioctl_submit(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> struct panfrost_submitqueue *queue;
> struct drm_panfro
> > What is handle? What is point?
>
> Handle is a syncobj handle, point is the point in a syncobj timeline.
> I'll document those fields.
OK.
> > Why is there padding instead of putting point first?
>
> We can move the point field first, but we need to keep the explicit
> padding: the struct h
> My concern is if we ever find a security bug which requires new
> information/behaviour in the submit ABI to properly fix. In this case it
> would be appropriate to backport a 'feature' (bug fix) which provides a
> new ABI but it would need to be a small change. A flags field where we
> can set a
On Tue, Mar 15, 2022 at 01:42:53AM +0300, Dmitry Osipenko wrote:
> Replace Panfrost's memory shrinker with a generic DRM memory shrinker.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/panfrost/Makefile | 1 -
> drivers/gpu/drm/panfrost/panfrost_device.h | 4
> driver
Minor typofix noticed when reading the KMS documentation.
Signed-off-by: Alyssa Rosenzweig
---
include/drm/drm_plane.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index fed97e35626f..0c1102dc4d88 100644
--- a/include/drm
This constructs a fixed 16.16 rational, useful to specify the minimum
and maximum scaling in drm_atomic_helper_check_plane_state. It is
open-coded as a macro in multiple drivers, so let's share the helper.
Signed-off-by: Alyssa Rosenzweig
---
include/drm/drm_fixed.h | 5 +
1 file chang
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-amlo...@lists.infradead.org
---
drivers/gpu/drm/meson/meson_overlay.c | 7 +++
drivers/gpu/drm/meson/meson_plane.c | 5 ++---
2
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-arm-...@vger.kernel.org
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 8
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
Cc: linux-rockc...@lists.infradead.org
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h
Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
helper to reduce code duplication between drivers.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/zte/zx_plane.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_plane.c b
> Missing documentation :-)
Ack.
> > +static inline int drm_fixed_16_16(s32 mult, s32 div)
>
> You should return a s32.
Ack.
> The function name isn't very explicit, and departs from the naming
> scheme of other functions in the same file. As fixed-point numbers are
> stored in a s64 for the d
Took me a careful read, but this is
Reviewed-by: Alyssa Rosenzweig
Thanks for hunting this down!
; this fix is
required for DCP to be mainlined.
Signed-off-by: Robin Murphy
Reviewed-and-tested-by: Alyssa Rosenzweig
---
drivers/gpu/drm/drm_gem_cma_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index
> > From: Robin Murphy
> >
> > drm_gem_cma_mmap() cannot assume every implementation of dma_mmap_wc()
> > will end up calling remap_pfn_range() (which happens to set the relevant
> > vma flag, among others), so in order to make sure expectations around
> > VM_DONTEXPAND are met, let it explicitly
Reviewed-by: Alyssa Rosenzweig
> index bd9b7be63b0f..fd4309209088 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.c
> @@ -400,8 +400,7 @@ void panfrost_device_reset(struct panfrost_device *pfdev)
> #ifdef C
> + /* Executable implies readable */
> + if ((args->flags & PANFROST_BO_NOREAD) &&
> + !(args->flags & PANFROST_BO_NOEXEC))
> + return -EINVAL;
Generally, executable also implies not-writeable. Should we check that?
> > > + /* Executable implies readable */
> > > + if ((args->flags & PANFROST_BO_NOREAD) &&
> > > + !(args->flags & PANFROST_BO_NOEXEC))
> > > + return -EINVAL;
> >
> > Generally, executable also implies not-writeable. Should we check that?
>
> We were allowing it until now, so doin
nel
> know about the UABI used by this userspace program. I mean, we could
> add one, or add a new PANFROST_BO_EXTENDED_FLAGS flag to enforce this
> 'noexec implies nowrite' behavior, but is it really simpler than
> explicitly passing the NOWRITE flag when NOEXEC is passed?
For some reason I thought the ABI version was negotiated (it is in
kbase). Don't worry about it.
That commit is
Reviewed-by: Alyssa Rosenzweig
> > This seems reasonable to me - it matches the kbase
> > BASE_MEM_COHERENT_SYSTEM (only backwards obviously) and it worked
> > reasonably well for the blob.
Oh, is that what that was for? I remember seeing it set on Midgard for
varyings. Good to go full circle now.
> > But I'm wondering if we n
> The IOMMU_DEVONLY flag allows the caller to flag a mappings backed by
> device-private buffers. That means other devices or CPUs are not
> expected to access the physical memory region pointed by the mapping,
> and the MMU driver can safely restrict the shareability domain to the
> device itself.
> Add support for MT8183's G-57 Bifrost.
G72
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> GPUs with more than a single regulator (e.g. G-57 on MT8183) will
G72
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> This provides an easy method for user
> space to trigger the OOM killer (by temporarily allocating large amounts
> of kernel memory)
panfrost user space has a lot of easy ways to trigger to the OOM killer
unfortunately if this is something we want to fix there are a lot
more patches coming
> The kernel driver itself can't guess which jobs need a such a strict
> affinity, so setting proper requirements is the responsibility of
> the userspace (Mesa). However the userspace is not smart enough [yet].
> Therefore this patch applies the above affinity rule to all jobs on
> dual core group
> With these patches panfrost is able to drive mali T628 (r1p0) GPU
> on some armv8 SoCs (in particular BE-M1000).
> r0 GPUs are still not supported [yet] (tested with Exynos 5422).
What's needed for r0?
Update a comment stating create_bo took no flags, since it now takes a
bit mask of optional flags NOEXEC and HEAP.
Signed-off-by: Alyssa Rosenzweig
---
include/uapi/drm/panfrost_drm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/drm/panfrost_drm.h b
We've cargo culted a large number of useless feature bits from kbase.
We're about to add support for a number of new Mali GPUs into mainline.
Let's cut down on the copy-paste required and clean up the feature lists
first.
Alyssa Rosenzweig (2):
drm/panfrost: Remove features mean
vacuously set for all Bifrost
hardware, even though this conveys no useful information.
To clean up the feature list, delete feature bits which could not
possibly matter to the kernel, leaving only those which do affect the
register-level operation of the chip.
Signed-off-by: Alyssa Rosenzweig
features affecting Bifrost kernel space that we do not
yet hanlde.
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_features.h | 40
1 file changed, 7 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_features.h
b/drivers/gpu/drm
first.
(That's pure cleaunp, this is a behaviour change RFC needing
discussion.)
Signed-off-by: Alyssa Rosenzweig
---
drivers/gpu/drm/panfrost/panfrost_features.h | 3 +++
drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 +++
drivers/gpu/drm/panfrost/panfrost_regs.h | 1 +
3 files chang
un, Jan 09, 2022 at 12:12:54PM -0500, Alyssa Rosenzweig wrote:
> The IDVS group size feature was missing. It is used on some Bifrost and
> Valhall GPUs, and is the last kernel-relevant Bifrost feature we're
> missing.
>
> This feature adds an extra IDVS group size field to the
> > This feature adds an extra IDVS group size field to the JM_CONFIG
> > register. In kbase, the value is configurable via the device tree; kbase
> > uses 0xF as a default if no value is specified. Until we find a device
> > demanding otherwise, let's always set the 0xF default on devices which
>
> Whether it's worth the effort depends on whether anyone really cares
> about getting the full performance out of this particular GPU.
>
> At this stage I think the main UABI change would be to add the opposite
> flag to kbase, (e.g. "PANFROST_JD_DOESNT_NEED_COHERENCY_ON_GPU"[1]) to
> opt-in to a
> (although it's a good thing kbase never did this cleanup - it's a useful
> source of public information ;) )
Haha, yes. Actually, kbase did do the clean up recently (Valhall era
kbase, I guess). To be fair, I still don't know what some of these were,
like "T7xx pairing rules"... Presumably somet
> > Now that we only list features of interest to kernel space, lots of GPUs
> > have the same feature bits. To cut down on the repetition in the file,
> > merge feature lists that are identical between similar GPUs.
> >
> > Note that this leaves some unmerged identical Bifrost feature lists, as
>
> >>> Note that this leaves some unmerged identical Bifrost feature lists, as
> >>> there are more features affecting Bifrost kernel space that we do not
> >>> yet hanlde.
> >>
> >> NIT: s/hanlde/handle/ ;)
> >>
> >> Do you have any features in mind that we're missing? The list looks very
> >> simi
Hi all,
As Steven Price explained, the "GPU top" kbase approach is often more
useful and accurate than per-draw timing.
For a 3D game inside a GPU-accelerated desktop, the games' counters
*should* include desktop overhead. This external overhead does affect
the game's performance, especially if
> This being said, I think I'll go for a simple debugfs-based iface to
> unblock Alyssa. debugfs is not part of the stable-ABI and I guess we
> can agree on explicitly marking it as "unstable" so that when we settle
> on a generic interface to expose such counters we can get rid of the
> old one.
Providing maintainers more aware of the substance review it and ok it,
patches 1-2 are:
Acked-by: Alyssa Rosenzweig
Patch 3 should be:
Reviewed-by: Alyssa Rosenzweig
> + /*
> + * In v4 HW we have one tiler per core group, with the number
> + * of core groups being equal to the number of L2 caches. Other
> + * HW versions just have one tiler and the number of L2 caches
> + * can be extracted from the mem_features field.
> + */
Norma
> memcmp() does not account for the case where 2 jobs contain exactly the
> same perfmons but in a different order. This being said, it's rather
> unlikely to happen, so maybe we can accept the perf penalty for that
> case.
If you say so!
> Yes, all numbers above 0xfff are bifrost GPUs. I'll add
> Sorry - "Thread Local Storage" - e.g. registers spilled to memory from a
> shader program.
Gotcha, thank you. Register spilling isn't implemented yet, so I haven't
run into this. (Partially because the blob's RA is very good so it's
somewhat nontrivial to get it to spill... not that I've tried,
> I'm also somewhat surprised that you don't need loads of other
> properties from the GPU - in particular knowing the number of shader
> cores is useful for allocating the right amount of memory for TLS (and
> can't be obtained purely from the GPU_ID).
Since I have no idea what TLS is (and in my
> Since one of the primary use cases is to draw pretty graphs of the
> system load [1], this "per-job" information isn't all that relevant (and
> minimal performance overhead is important). And if you want to monitor
> just one application it is usually easiest to ensure that it is the only
> thing
> You can extend ioctl structs safely. When older userspace passes theirs
> in, it has the shorter length encoded in the cmd. The kernel allocates
> the newest version's space, copies in the shorter struct, and
> zero-extends the rest.
Understood, thank you!
__
+1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Acked-by: Alyssa Rosenzweig
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > Another one: What's the plan with extending this to panfrost? Or are the
> > architectures for command submission totally different, and we'll need
> > separate kernel drivers for utgard/midgard/bifrost?
> + Alyssa & Rob
> There is a gitlab issue about sharing kernel driver:
> https://gitlab.fr
> I really think to write a decent vulkan driver, you need to take
> arrays of in sync,
Vulkan? What's that? ;)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Oh my onions, it's really here! It's really coming! It's really here!
> + DRM driver for ARM Mali Midgard (t6xx, t7xx, t8xx) and
> + Bifrost (G3x, G5x, G7x) GPUs.
Nitpick: the model names should maybe be capitalized? Or at least, the
T/G should be consistent? I'm not sure what t
> bitmasks in the kernel use unsigned long arrays. A strange choice
> which I guess was either because it predated 64-bit or enables atomic
> ops which tend to be on the native size. So this just fixes the size
> to 64-bits for 32 and 64 bit systems.
Bizarre, but if that's the standard, then OK.
> It was given to me and a bunch of other ARM kernel devs, but I think
> it was in production by then. It's an A01 rev which matches this:
>
> https://www.notebookcheck.net/Samsung-Chromebook-XE303C12-A01US.84022.0.html
>
> The only other rev is a UK version.
Wacky. Something seems decidedly odd
> Then DRM_FORMAT_MOD_ARM_TYPE_GPU? I really don't know what's the
> official name for this kind of format, so have to name it with the
> device. Any better
> suggestion?
Maybe DRM_FORMAT_MOD_ARM_TYPE_TILED? I wonder if the Mali-DP folks have
a suggestion.
> Is tiled buffer rendering not reverse
> If you think Midgard/Bifrost is compatible with AFBC and don't have it's
> own format, and name "device" is improper, I can rename
> DRM_FORMAT_MOD_ARM_DEVICE_AFBC to DRM_FORMAT_MOD_ARM_TYPE_AFBC
> DRM_FORMAT_MOD_ARM_DEVICE_GPU to DRM_FORMAT_MOD_ARM_TYPE_UTGARD
That name is misleading, too. Mid
DRM_FORMAT_MOD_ARM_GPU(mode) \
> + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_DEVICE_GPU, mode)
> +
Although Utgard does not support AFBC, both Midgard and Bifrost natively
support AFBC for both texturing and rendering. Separating "AFBC" from
"GPU" is incorrect.
It&
> You might want to re-use the exisiting modifier
> AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
>
> I would suggest you to have a look at the exisiting AFBC modifiers
> (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is
> something you cannot reuse.
So, the "tiled" format in question (that Qiang
Woohoo! Patches 1-3 are R-b; patch 4 is A-b. Exciting progress! Hoping
to hear what Rob and Steven think :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 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
> 1. Does AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 without any
> AFBC_FORMAT_MOD_XXX uncompressed format just reorder the pixels
> in one 16x16 block same way as GPU "tiled" format? Or just no reorder
> (linear)?
>
> 2. Is there any unreleased AFBC_FORMAT_MOD_XXX bit for this GPU
> "tiled" format?
I bel
"AGTB" is jargon-y, but then again, so is "AFBC"... Unless Arm wants to
publish the actual name for the format, this works :)
Thank you for the clarification (in the other emails)
Reviewed-by: Alyssa Rosenzweig
___
dri-devel ma
> AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 denotes the superblock size to be
> used only in case of AFBC buffers.
> For non compressed tiled format, none of the AFBC_FORMAT_MOD_XXX
> should be used.
Alright, understood. Thank you for the clarification :)
___
dri
> We don't know if this is a "category" per-se, or just a single Utgard
> tiling format - as discussed I'm trying to get an answer for that.
FWIW, as I think I mentioned on an message, this format is used on
Midgard as well, and presumably also Bifrost.
On Midgard, when a texture is uploaded (jus
Nice job!
Patches 1-2 are Acked-by: Alyssa Rosenzweig
Patch 3 is Reviewed-by: Alyssa Rosenzweig
Excited to see this mainlined!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> the userspace definitely doesn't support T624
This is true, yes. Shouldn't be too hard to backport; if there's still
interest in Midgard 1st/2nd gen, I suppose I can grab hardware and sort
it out...
> You probably want a dma_set_mask_and_coherent() call for your 'real' output
> address size som
> #define PANFROST_BO_NOEXEC 1
> +#define PANFROST_BO_HEAP 2
Bikeshedding, but I don't like this name. There are, I think, multiple
GPU-mapped buffers (at least in Panfrost -- I don't know how the blob
manages memory) that can be considered heaps of sorts. Some of those are
just regular old
> Seems like almost 4GB executable
> buffer should be enough for anyone(TM).
(TM) indeed. For stats, Panfrost right now uses a single 16MB shader
buffer per context and never reallocates.
I have never seen it run out of space, not even once on a conformance
test.
Mali shader binaries are small (
> A fair bit of the complexity of kbase comes from trying to avoid the
> possibility of one process DoSing another by submitting malicious jobs.
...and yet it was still doable so easily (by accident, with buggy jobs
instead of malicious jobs) sigh...
Still is on the mainline kernel (e.g. runn
> While I agree an executable heap is pretty weird, I'd prefer making this
> explicit - i.e. failing the allocation if the flags don't make sense.
The only use case for an executable heap I can think of is an attacker
trying to exploit a GPU-side heap overflow, and that's seriously
stretching it ;
This patch is:
Acked-by: Alyssa Rosenzweig
On Wed, Jul 17, 2019 at 12:33:50PM -0600, Rob Herring wrote:
> Executable buffers have an alignment restriction that they can't cross
> 16MB boundary as the GPU program counter is 24-bits. This restriction is
> currently not handl
> User space shouldn't care too much - other than the size of buffers
> allocated being rounded up to the CPU's page size. At least the Panfrost
> user/kernel ABI has sizes in bytes not pages (unlike kbase).
We've been rounding everything up to the nearest 4k in mesa, out of old
habit from kbase.
This is definitely helpful!
My one concern is, supposing userspace really does need all of this
information, is it wasteful to have to do 30+ ioctls just to get this?
kbase had a single ioctl to grab all of the properties, whether
userspace wanted them or not. I'm not sure if that's better -- the
1 - 100 of 272 matches
Mail list logo
