https://bugs.freedesktop.org/show_bug.cgi?id=111265
Kenneth Graunke changed:
What|Removed |Added
Depends on||111301
Referenced Bugs:
https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=111300
Bug ID: 111300
Summary: Steam overlay flickers on Doom
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority
On Mon, Aug 05, 2019 at 10:02:43AM -0700, Alyssa Rosenzweig wrote:
> 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?)
The
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 +
> +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 INVISIBLE.
>
> Th
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
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
> +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
-- Forwarded message -
From: Mini Cherian
Date: Mon, 5 Aug 2019, 22:12
Subject: We have some issues in using mesa drivers.
To:
Can you please please help us?
We are using an Intel processor 3930 with HD 400 gpu.
We are using scade display to generate open gl code.
Also we are us
https://bugs.freedesktop.org/show_bug.cgi?id=26
--- Comment #12 from Jussi Pakkanen ---
Could someone please test if this issue is fixed if you use the following Meson
PR:
https://github.com/mesonbuild/meson/pull/5674
Upon confirmation we'll get the 0.52.2 release out.
Thanks,
--
You are
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_KEY_VALUE (0x1) or
> FREED_KEY_VALUE (0x0).
>
> The entry.hash field isn't needed by the delete_function, so j
> 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.
Signed-off-by: Tomeu Vizoso
---
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 122bc5f3db36..46cceb808919 100644
--- a/src/gallium/drivers/
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).
S
Unless a BO has the EXECUTABLE flag, mark it as NOEXEC.
Signed-off-by: Tomeu Vizoso
---
include/drm-uapi/panfrost_drm.h | 27 +++
src/gallium/drivers/panfrost/pan_drm.c| 7 +-
src/gallium/drivers/panfrost/pan_screen.c | 12 ++
src/gallium/drivers/pa
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).
The entry.hash field isn't needed by the delete_function, so just stop
populating it.
Signed-off-by: Tomeu Vizoso
Cc: Samuel Pitoise
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.
We need to make sure we adjust offset_start and vertex_count in order to
take into account the index_bias as required by a glDrawElementsB
Am Samstag, den 03.08.2019, 13:01 -0400 schrieb Ilia Mirkin:
>
> Gert - your change should be all good from what I can tell
> experimentally. Although I still don't understand why.
Thanks for testing, and I think Mareks explanation is spot on.
Best,
Gert
>
> -ilia
>
> On Sat, Aug 3, 2019
20 matches
Mail list logo
