Signed-off-by: Tomeu Vizoso
Reviewed-by: Alyssa Rosenzweig
---
src/gallium/drivers/panfrost/pan_drm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/panfrost/pan_drm.c
b/src/gallium/drivers/panfrost/pan_drm.c
index 71eda2d1e328..36a6b975680a
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 in BOs marked as executable (before
they were allocated in the transient pool, which shouldn't be
executable).
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 INVISIBLE.
This allows us to allocate a big heap upfront (16MB) without actually
reserving space unless it's needed.
Some hash functions (eg. key_u64_hash) will attempt to dereference the
key, causing an invalid access when passed DELETED_KEY_VALUE (0x1) or
FREED_KEY_VALUE (0x0).
To avoid this problem, stuff the fake keys into a hash_key_u64 struct
and pass the pointer to it instead.
Signed-off-by: Tomeu
Unless a BO has the EXECUTABLE flag, mark it as NOEXEC.
v2: - Rework version detection (Alyssa).
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h | 27 +++
src/gallium/drivers/panfrost/pan_drm.c| 6 -
Hi Ilia,
Actually I wasn't sure that the PIPE_CAP_IMAGE_LOAD_FORMATTED was needed.
Your reasonning and your patch series make sense, thanks for fixing this.
Best,
Pierre-Eric
On 07/08/2019 02:10, Ilia Mirkin wrote:
> Hi Pierre-Eric,
>
> I see you recently added EXT_shader_image_load_store -
Hi all,
On Wed, 31 Jul 2019 at 09:37, Emil Velikov wrote:
>
> Hi all,
>
> Here is the tentative release plan for 19.2.0.
>
> As many of you are well aware, it's time to the next branch point.
> The calendar is already updated, so these are the tentative dates:
>
> Aug 06 2019 - Feature
https://bugs.freedesktop.org/show_bug.cgi?id=111308
Danylo changed:
What|Removed |Added
CC||danylo.pilia...@gmail.com
--- Comment #3 from
https://bugs.freedesktop.org/show_bug.cgi?id=111316
Pekka Paalanen changed:
What|Removed |Added
CC||ch...@chris-wilson.co.uk,
https://bugs.freedesktop.org/show_bug.cgi?id=111288
--- Comment #6 from Denis ---
Thanks for the trace and explanations. I installed minecraft (demo version).
First observation - is that the app versions available for me 1.14.4 and 1.14
I ran it thru the valgrind. Result below:
==9226== LEAK
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
https://bugs.freedesktop.org/show_bug.cgi?id=111316
Bug ID: 111316
Summary: Imported GBM BO released with DESTROY_DUMB
Product: Mesa
Version: 18.3
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=111288
--- Comment #8 from Greg ---
>First observation - is that the app versions available for me 1.14.4 and 1.14
I use older version (to play with specific mods), but issue also persists on
newest (1.14.4) and oldest versions (1.0 release)
https://bugs.freedesktop.org/show_bug.cgi?id=111306
Michel Dänzer changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |intel-3d-bugs@lists.freedes
Mesa 19.1.4 is now available.
In this release we have:
Mostly, as usual, in fixes for different drivers (anv, radv, radeon, nv50,
nvc0) as well as in backend parts (egl, spirv, nir, ...).
Of those fixes, we could highlight several ones:
- Vulkan 24/48 bit formats are now not supported on
https://bugs.freedesktop.org/show_bug.cgi?id=111288
--- Comment #7 from Greg ---
>why did you decide that those records relate to memory leaks
I've decided that there's memory leak since memory used by minecraft grows
indefinitely and it's surely not how it should be (I played minecraft on other
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 ---
https://bugs.freedesktop.org/show_bug.cgi?id=111308
--- Comment #4 from Ian Romanick ---
I think I have an idea what could be happening. There are a lot of occurrences
of a pattern like
y = exp2(-(x*x)) * small_constant + y;
At the end, y is compared 0 < y, and that comparison is
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 -
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
On Wed, Aug 07, 2019 at 10:36:53AM +0200, Tomeu Vizoso wrote:
> Some hash functions (eg. key_u64_hash) will attempt to dereference the
> key, causing an invalid access when passed DELETED_KEY_VALUE (0x1) or
> FREED_KEY_VALUE (0x0).
>
> To avoid this problem, stuff the fake keys into a
https://bugs.freedesktop.org/show_bug.cgi?id=111308
--- Comment #5 from Danylo ---
Interesting observation. I would be able to try tomorrow.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
Eric Engestrom writes:
> On 2019-07-31 at 09:38, Emil Velikov wrote:
>> Hi all,
>>
>> Here is the tentative release plan for 19.2.0.
>>
>> As many of you are well aware, it's time to the next branch point.
>> The calendar is already updated, so these are the tentative dates:
>>
>> Aug 06
From: Rob Clark
I noticed slab_free() showing up at the top of perf results in
gl_driver2, due to "streaming" GPU state objects, which are allocated
and destroyed within a single draw call.
In this case, it is guaranteed that we free on the same child pool,
from the same (only) thread accessing
Reviewed-by: Marek Olšák
Marek
On Wed, Aug 7, 2019 at 6:02 PM Rob Clark wrote:
> From: Rob Clark
>
> I noticed slab_free() showing up at the top of perf results in
> gl_driver2, due to "streaming" GPU state objects, which are allocated
> and destroyed within a single draw call.
>
> In this
On Wed, Aug 7, 2019 at 2:37 AM 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 in BOs marked as executable (before
> they were
> 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
> 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
Do you have any actual numbers for this?
On August 7, 2019 17:02:22 Rob Clark wrote:
From: Rob Clark
I noticed slab_free() showing up at the top of perf results in
gl_driver2, due to "streaming" GPU state objects, which are allocated
and destroyed within a single draw call.
In this case,
It'd be nice to throw some numbers in the donut message before you push.
"Real" ones of it's convenient but what you have below is probably fine if
you've already thrown the data away.
On August 7, 2019 19:13:21 Rob Clark wrote:
Yes, although not in front of me.. overall for gl_driver2 it
On Wed, Aug 7, 2019 at 2:37 AM Tomeu Vizoso wrote:
>
> Signed-off-by: Tomeu Vizoso
> Reviewed-by: Alyssa Rosenzweig
> ---
> src/gallium/drivers/panfrost/pan_drm.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/panfrost/pan_drm.c
>
On Thu, 8 Aug 2019 at 00:47, Rob Herring wrote:
>
> On Wed, Aug 7, 2019 at 2:37 AM 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
On Thu, 8 Aug 2019 at 00:52, Rob Herring wrote:
>
> On Wed, Aug 7, 2019 at 2:37 AM Tomeu Vizoso
> wrote:
> >
> > Signed-off-by: Tomeu Vizoso
> > Reviewed-by: Alyssa Rosenzweig
> > ---
> > src/gallium/drivers/panfrost/pan_drm.c | 10 +-
> > 1 file changed, 5 insertions(+), 5
should be easy enough to re-create.. I will note that the perf
results differ a *lot* if I pin things to small (in-order) calls, so
I'm guestimating that what perf is showing me w/ slab_free() is where
reality catches up to mis-predicted branches.
BR,
-R
On Wed, Aug 7, 2019 at 9:44 PM Jason
34 matches
Mail list logo
