On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich
wrote:
> Good Morning,
>
> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:
> > BTW, swrast doesn't have to exist on the system. It's not uncommon for me
> > to have no swrast on my development system.
>
> Ok. I see. I use swrast regularly
https://bugs.freedesktop.org/show_bug.cgi?id=110603
Lucas Francesco changed:
What|Removed |Added
CC||lucas.francesc...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=110603
Bug ID: 110603
Summary: Blocky and black opacity/alpha using RADV on some
games
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux
Build mesa 11025 completed
Commit d0ea9877b8 by Connor Abbott on 5/2/2019 8:22 PM:
nir/algebraic: Don't emit empty initializers for MSVC\n\nJust don't emit the transform array at all if there are no transforms\n\nv2:\n- Don't use len(array) > 0 (Dylan)\n- Keep
On Fri, May 3, 2019 at 10:39 PM Jason Ekstrand wrote:
> On Fri, May 3, 2019 at 3:29 PM Connor Abbott wrote:
>
>> FWIW, the reason I changed it away was to keep it consistent with the
>> line directly above that uses the length (since the C array won't exist if
>> it's length 0). Does that
https://bugs.freedesktop.org/show_bug.cgi?id=110459
faalag...@gmail.com changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
On Fri, May 3, 2019 at 3:29 PM Connor Abbott wrote:
> FWIW, the reason I changed it away was to keep it consistent with the line
> directly above that uses the length (since the C array won't exist if it's
> length 0). Does that convince you?
>
Nope. First off, if you take Dylan's suggestions
On Fri, May 3, 2019 at 6:52 AM Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez
>
> There are tests in CTS for alpha to coverage without a color attachment
> that are failing. This happens because when we remove the shader color
> outputs when we don't have a valid color attachment
FWIW, the reason I changed it away was to keep it consistent with the line
directly above that uses the length (since the C array won't exist if it's
length 0). Does that convince you?
On Fri, May 3, 2019 at 10:26 PM Jason Ekstrand wrote:
> On Thu, May 2, 2019 at 3:51 PM Dylan Baker wrote:
>
On Thu, May 2, 2019 at 3:51 PM Dylan Baker wrote:
> Quoting Connor Abbott (2019-05-02 13:34:07)
> > Just don't emit the transform array at all if there are no transforms
> > for a state, and avoid trying to walk over it.
> > ---
> > Brian, does this build on Windows? I tested it on my shader-db
Just don't emit the transform array at all if there are no transforms
for a state, and avoid trying to walk over it.
Original patch by Connor Abbott. Updated with suggestions by
Dylan Baker.
---
src/compiler/nir/nir_algebraic.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
https://bugs.freedesktop.org/show_bug.cgi?id=110573
--- Comment #16 from ant...@gmx.de ---
Great work, thanks again!
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
Build mesa 11022 failed
Commit a381dbf253 by Chuck Atkins on 5/3/2019 4:06 PM:
meson: Fix missing glproto dependency for gallium-glx\n\nSigned-off-by: Chuck Atkins \nCc: mesa-stable \nReviewed-by: Dylan Baker
Configure your notification preferences
Build mesa 11021 completed
Commit a37e0454e1 by Bas Nieuwenhuizen on 5/2/2019 2:03 PM:
radv: Disable VK_EXT_descriptor_indexing.\n\nWe did not implement the required non-uniform indexing features.\n\nThis patch is to disable the extension on 19.0. For 19.1
https://bugs.freedesktop.org/show_bug.cgi?id=110573
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
> Actually, I tried several things, so I might have left it flipped at
> some point, but it doesn't work with with src_factor=one and
> dts_factor=zero.
Hum.
> Good question. I haven't dumped the buffers yet. Another thing to note:
> the texture I'm reloading from is using
On Fri, 3 May 2019 07:29:22 -0700
Alyssa Rosenzweig wrote:
> > +else if (!(job->clear & PIPE_CLEAR_COLOR))
>
> Make sure this is actually being called when you expect. I don't
> remember if job->clear is being zeroed when we expect (hint: it might
> not be due to a missing job_free
Am Freitag, den 03.05.2019, 12:05 +0200 schrieb Philipp Zabel:
> Without this gbm_bo_get_offset() can return 0 where it shouldn't.
Reviewed-by: Lucas Stach
> ---
> src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> +else if (!(job->clear & PIPE_CLEAR_COLOR))
Make sure this is actually being called when you expect. I don't
remember if job->clear is being zeroed when we expect (hint: it might
not be due to a missing job_free routine somewhere, *blush*).
> + .rt[0].rgb_func =
On Fri, May 3, 2019 at 11:42 AM Samuel Pitoiset
wrote:
>
> Because the new raw/struct intrinsics are buggy with LLVM 8
> (they weren't marked as source of divergence), we fallback to the
> old instrinsics for atomic buffer operations. This means we need
> to apply the indexing workaround for
On 05/02/2019 11:18 PM, Mathias Fröhlich wrote:
Hi Brian,
On Friday, 3 May 2019 00:17:51 CEST Brian Paul wrote:
On 05/02/2019 03:27 AM, mathias.froehl...@gmx.net wrote:
From: Mathias Fröhlich
In glArrayElement, use the bitmask trick to just walk the enabled
vao arrays. This should be about
From: Samuel Iglesias Gonsálvez
There are tests in CTS for alpha to coverage without a color attachment
that are failing. This happens because when we remove the shader color
outputs when we don't have a valid color attachment for them, but when
alpha to coverage is enabled we still want to
From: Nicolai Hähnle
The compiler should be able to optimize them away, but still. There's
no point in declaring those as pointers, and if the compiler *doesn't*
optimize them away, they add unnecessary load-time relocations.
---
src/gallium/drivers/radeonsi/si_shader.c | 4 ++--
1 file
From: Nicolai Hähnle
---
src/amd/common/ac_binary.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_binary.h b/src/amd/common/ac_binary.h
index febc4da7fed..8f594a9ce75 100644
--- a/src/amd/common/ac_binary.h
+++ b/src/amd/common/ac_binary.h
@@ -68,21
From: Nicolai Hähnle
---
src/amd/common/ac_binary.c | 77 +-
src/amd/common/ac_binary.h | 4 ++
2 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
index fabeb15a204..44251886b5f 100644
---
From: Nicolai Hähnle
We didn't really use error codes anyway.
---
src/gallium/drivers/radeonsi/si_compute.c | 6 +++---
src/gallium/drivers/radeonsi/si_shader.c | 21 +--
src/gallium/drivers/radeonsi/si_shader.h | 2 +-
.../drivers/radeonsi/si_state_shaders.c
From: Nicolai Hähnle
Using an explicit linker instead of just concatenating .text
sections will allow us to start using .rodata sections and
explicit descriptions of data on LDS that is shared between
stages.
---
src/amd/Makefile.sources | 2 +
src/amd/common/ac_binary.h | 2 +
From: Nicolai Hähnle
A new variant of ac_compile_module_to_binary that allows us to
keep the entire ELF around.
---
src/amd/common/ac_llvm_helper.cpp | 88 ---
src/amd/common/ac_llvm_util.h | 2 +
2 files changed, 83 insertions(+), 7 deletions(-)
diff --git
these patches change the way we load shaders, initially for radeonsi
but ideally radv would adopt the same approach.
Basically, instead of hard-coding that we have a single .text section
in the ELF generated by LLVM, we align ourselves more with the ELF
standard and actually look at all the
From: Nicolai Hähnle
Help identify bugs related to corruption of shaders in memory,
or errors in shader upload / rtld.
---
src/gallium/drivers/radeonsi/si_debug.c| 18 ++
.../drivers/radeonsi/si_debug_options.h| 1 +
2 files changed, 19 insertions(+)
diff --git
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_compute.c | 63 ++--
src/gallium/drivers/radeonsi/si_debug.c | 74 +++--
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
src/gallium/drivers/radeonsi/si_pipe.h| 2 +-
src/gallium/drivers/radeonsi/si_shader.c
From: Nicolai Hähnle
---
src/amd/common/ac_binary.c| 2 +
src/gallium/drivers/radeonsi/si_compute.c | 14 +--
src/gallium/drivers/radeonsi/si_shader.c | 112 +++---
src/gallium/drivers/radeonsi/si_shader.h | 25 +
4 files changed, 27 insertions(+), 126
From: Nicolai Hähnle
We didn't really use error codes anyway.
---
src/gallium/drivers/radeonsi/si_compute.c | 2 +-
src/gallium/drivers/radeonsi/si_shader.c | 18 +-
src/gallium/drivers/radeonsi/si_shader.h | 2 +-
.../drivers/radeonsi/si_state_shaders.c
On 03.05.19 12:36, Nicolai Hähnle wrote:
> On 25.04.19 13:18, Nicolai Hähnle wrote:
>> @@ -4618,21 +4648,27 @@ static void si_bind_vertex_elements(struct
>> pipe_context *ctx, void *state)
>> struct si_vertex_elements *old = sctx->vertex_elements;
>> struct si_vertex_elements *v =
Hello Alyssa,
This week I've tried to make the wallpapering logic to work on panfrost
but I'm not quite there yet.
I've done all my tests with weston that tries to use buffer_age and
update only the parts that have changed (which I know is inefficient,
but before implementing partial_update() I
On 5/3/19 12:39 PM, Nicolai Hähnle wrote:
On 30.04.19 21:20, Marek Olšák wrote:
Why can we not use tbuffer loads?
tbuffer_load_format has the exact same limitations as
buffer_load_format. They both use the same hardware path, the only
difference is that tbuffer_load_format gets the format
On 30.04.19 21:20, Marek Olšák wrote:
Why can we not use tbuffer loads?
tbuffer_load_format has the exact same limitations as
buffer_load_format. They both use the same hardware path, the only
difference is that tbuffer_load_format gets the format information from
the instruction, while
On 25.04.19 13:18, Nicolai Hähnle wrote:
> @@ -4618,21 +4648,27 @@ static void si_bind_vertex_elements(struct
> pipe_context *ctx, void *state)
> struct si_vertex_elements *old = sctx->vertex_elements;
> struct si_vertex_elements *v = (struct si_vertex_elements*)state;
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=110573
--- Comment #14 from ant...@gmx.de ---
Yes that seems to fix the issue!
No more visual artifacts or system hangs. Thanks a lot for the help!
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for
Without this gbm_bo_get_offset() can return 0 where it shouldn't.
---
src/gallium/drivers/etnaviv/etnaviv_resource.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/etnaviv/etnaviv_resource.c
b/src/gallium/drivers/etnaviv/etnaviv_resource.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=110540
--- Comment #14 from Sylvain BERTRAND ---
Don't know why I got the wrong one in my clipboard:
http://bugs.freedesktop.org/show_bug.cgi?id=109550
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
Because the new raw/struct intrinsics are buggy with LLVM 8
(they weren't marked as source of divergence), we fallback to the
old instrinsics for atomic buffer operations. This means we need
to apply the indexing workaround for GFX9.
The fact that we need another workaround is painful but we
https://bugs.freedesktop.org/show_bug.cgi?id=110573
--- Comment #13 from Samuel Pitoiset ---
Can you try https://patchwork.freedesktop.org/series/60252/ ? That should fix
the regression.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110573
--- Comment #12 from Samuel Pitoiset ---
I think I found the problem with a different game, I'm working on.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
On Thu, 2019-05-02 at 09:03 -0500, Jason Ekstrand wrote:
> On Thu, May 2, 2019 at 5:46 AM Iago Toral Quiroga
> wrote:
> > From: Samuel Iglesias Gonsálvez
> >
> >
> >
> > There tests in CTS for for alpha to coverage without a color
> > attachment.
> >
> > First the test draws a primitive with
https://bugs.freedesktop.org/show_bug.cgi?id=92552
Sergii Romantsov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110540
--- Comment #13 from Samuel Pitoiset ---
(In reply to Sylvain BERTRAND from comment #11)
> I did report the regression ages ago: since there is a year in time lag,
> could be anywhere, even in linux drm or worse, in llvm:
>
https://bugs.freedesktop.org/show_bug.cgi?id=110540
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
48 matches
Mail list logo
