https://bugs.freedesktop.org/show_bug.cgi?id=110673
Bug ID: 110673
Summary: amdgpu hevc encoding problems: segment fault and
contents of garbage
Product: Mesa
Version: unspecified
Hardware: All
OS: Linux
For the series:
Reviewed-by: Marek Olšák
Marek
On Mon, May 13, 2019 at 5:15 PM Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This dumps disassembly to the pipe_debug_callback together with shader
> stats.
>
> Can be used together with shader-db to get full disassembly of all shaders
> in
Besides my comment on one of the patches, the series is:
Reviewed-by: Marek Olšák
Marek
On Sat, May 4, 2019 at 9:39 AM Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This implies that the memory will always be at address 0, which allows
> LLVM to generate slightly better code.
> ---
>
On Sat, May 4, 2019 at 9:39 AM Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Upcoming changes to LLVM will emit LDS objects as symbols in the ELF
> symbol table, with relocations that will be resolved with this change.
>
> Callers will also be able to define LDS symbols that are shared
Acked-by: Alex Deucher
On Mon, May 13, 2019 at 4:01 PM Liu, Leo wrote:
>
> Ping...
>
> On 5/9/19 2:10 PM, Liu, Leo wrote:
> > Since the using output optimization is only for back buffer case
> >
> > Signed-off-by: Leo Liu
> > ---
> > src/gallium/auxiliary/vl/vl_winsys_dri3.c | 1 +
> > 1
r-b for the series.
On Mon, May 13, 2019 at 11:14 PM Nicolai Hähnle wrote:
>
> From: Nicolai Hähnle
>
> ---
> src/gallium/drivers/radeonsi/si_texture.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_texture.c
>
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_query.c | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index
From: Marek Olšák
This helps fix:
piglit/bin/ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
Fixes: d88f3392fff7c6342f3840c4bd8195a1296c2372
---
src/mesa/main/teximage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/teximage.c
By the way: Yes, I'm aware that other "database" formats are in use in
Mesa either directly or indirectly, but for various reasons it wasn't
easily possible to reuse the corresponding code.
On 13.05.19 23:26, Nicolai Hähnle wrote:
Hi all,
this series moves to a description of registers in a
Hi all,
this series moves to a description of registers in a JSON file as the
single source of truth for register descriptions. Both register headers
and the tables used for decoding command buffers for debugging are
derived from this JSON description at build time.
This should make
From: Nicolai Hähnle
This dumps disassembly to the pipe_debug_callback together with shader
stats.
Can be used together with shader-db to get full disassembly of all shaders
in the database.
---
src/gallium/drivers/radeonsi/si_debug_options.h | 1 +
src/gallium/drivers/radeonsi/si_shader.c
From: Nicolai Hähnle
Compute the count since the start of the current line instead of the
count since the start of the the disassembly.
---
src/gallium/drivers/radeonsi/si_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
From: Nicolai Hähnle
This is more convenient for changing it around during debug.
---
src/amd/common/ac_llvm_util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_llvm_util.c b/src/amd/common/ac_llvm_util.c
index 69446863b95..16c1b25d8c2 100644
---
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_texture.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_texture.c
b/src/gallium/drivers/radeonsi/si_texture.c
index 59d50376438..b31a2f6428a 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=109599
--- Comment #30 from Roland Scheidegger ---
Frankly I don't know if the offset scaling makes any sense.
IMHO using the formula for fixed-point depth buffers d3d10 requires (luckily at
least for float formats everybody (gl, vulkan, d3d10) agrees
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #33 from Samuel Pitoiset ---
Ok, I will replay a race all over the night and hopefully I will hit that hang.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
Ping...
On 5/9/19 2:10 PM, Liu, Leo wrote:
> Since the using output optimization is only for back buffer case
>
> Signed-off-by: Leo Liu
> ---
> src/gallium/auxiliary/vl/vl_winsys_dri3.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
>
For the series:
Reviewed-by: Marek Olšák
Marek
On Sun, May 12, 2019 at 9:05 AM wrote:
> From: Mathias Fröhlich
>
> Signed-off-by: Mathias Fröhlich
> ---
> src/mesa/main/state.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/main/state.c
VK_AMD_draw_indirect_count has been promoted with the suffix
changed to KHR.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_cmd_buffer.c | 49 ---
src/amd/vulkan/radv_extensions.py | 2 +-
2 files changed, 1 insertion(+), 50 deletions(-)
diff --git
Nothing to do.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 6 ++
src/amd/vulkan/radv_extensions.py | 1 +
2 files changed, 7 insertions(+)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
index 6daf9f48182..b197d7f9ec8 100644
---
Not, I hope, that anyone is likely to notice, but I've moved the open
GLU and GLUT bugs from bugzilla to gitlab and closed the components in
bugzilla. I say "moved" but really glut only had one open bug and it
was fixed ages ago. Anyway, use gitlab now please.
- ajax
https://bugs.freedesktop.org/show_bug.cgi?id=110516
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=51641
GitLab Migration User changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=91631
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=71665
GitLab Migration User changed:
What|Removed |Added
Resolution|--- |MOVED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=12405
Adam Jackson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
This approach seems entirely incompatible with si_debug_options.h, and
will be an absolute maintenance nightmare going forward for adding /
removing options, because you're introducing a second location where
options are defined.
Quite frankly, this seems like a terrible idea as-is.
If you
From: Nicolai Hähnle
The main motivation for this change is API ergonomics: most operations
on dynarrays are really on elements, not on bytes, so it's weird to have
grow and resize as the odd operations out.
The secondary motivation is memory safety. Users of the old byte-oriented
functions
From: Nicolai Hähnle
We're not very good at handling out-of-memory conditions in general, but
this change at least gives the caller the option of handling it gracefully
and without memory leaks.
This happens to fix an error in out-of-memory handling in i965, which has
the following code in
Hi all,
after reflecting on the comments a bit more, here's a v2 of the series
in which resize and grow are no-ops on reallocation failure, but get
MUST_CHECK attributes so that the compiler warns if the return value
isn't used.
It seems like almost all callers are well-behaved, except for a few
From: Nicolai Hähnle
This is more expressive and simplifies a subsequent change.
v2:
- fix one more call-site after rebase
---
src/gallium/drivers/freedreno/a2xx/fd2_gmem.c | 12 ++--
src/gallium/drivers/freedreno/a3xx/fd3_gmem.c | 4 ++--
src/gallium/drivers/freedreno/a4xx/fd4_gmem.c
Thank you so much for giving me this opportunity to be on the X.org board. I
look forward to active participation in the upcoming conferences as well as
mentorship for Google SOC.
I am currently on vacation till May 16th with limited email access and will
resume attending the board meetings
> Using nir_gather_ssa_types is wrong. In both Midgard and NIR, SSA
> values are just a bunch of bits with no int/float distinction, and
> therefore you shouldn't need to know how a register is used to compile
> the instruction producing it. The only distinction between imov and
> fmov, in both
On Mon, May 13, 2019 at 4:48 PM Alyssa Rosenzweig wrote:
>
> > Using nir_gather_ssa_types is wrong. In both Midgard and NIR, SSA
> > values are just a bunch of bits with no int/float distinction, and
> > therefore you shouldn't need to know how a register is used to compile
> > the instruction
Both are A-b
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This is basically the same issue as with patch #3... it's not so clear
what the best policy actually is.
Cheers,
Nicolai
On 05.05.19 01:24, Caio Marcelo de Oliveira Filho wrote:
> Hi,
>
>>> diff --git a/src/util/u_dynarray.h b/src/util/u_dynarray.h
>>> index b30fd7b1154..f6a81609dbe 100644
>>>
On 04.05.19 17:55, Gustaw Smolarczyk wrote:
> sob., 4 maj 2019 o 15:25 Nicolai Hähnle napisał(a):
>> static inline void
>> util_dynarray_clone(struct util_dynarray *buf, void *mem_ctx,
>> struct util_dynarray *from_buf)
>> {
>> util_dynarray_init(buf, mem_ctx);
>>
On 05.05.19 01:19, Bas Nieuwenhuizen wrote:
>> /* use util_dynarray_trim to reduce the allocated storage */
>> static inline void *
>> -util_dynarray_resize(struct util_dynarray *buf, unsigned newsize)
>> +util_dynarray_resize_bytes(struct util_dynarray *buf, unsigned nelts,
>> size_t
Yes, it does work though the newer Fixes: tag is preferred. The process
hasn't actually involved the mesa-stable making list in a while. Instead,
there are scripts used by the release managers that troll the got lots
looking for Cc: to stable and Fixes: tags and grabs the appropriate
patches.
I've gone through the document and have been working through the ml for the
past few years. When using the ml, putting CC in the message and invoking
git send-email will cause it to also get sent to the stable ml so it wasn't
clear to me that it would still work that way with a merge request. I
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #32 from Thomas Rohloff ---
(In reply to Samuel Pitoiset from comment #31)
> Is there a special race where it crashes more often?
No, it's just random.
> Can you explain again the steps to reproduce?
I'm starting a new race and
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #31 from Samuel Pitoiset ---
Is there a special race where it crashes more often?
Can you explain again the steps to reproduce?
I'm sorry but I can't do anything better without being able to repro myself.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #30 from Thomas Rohloff ---
And it crashed again:
> [ 1104.395697] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled
> seq=231618, emitted seq=231620
> [ 1104.395701] [drm:amdgpu_job_timedout] *ERROR* Process
Am 13.05.2019 11:06, schrieb Eric Engestrom:
On Monday, 2019-05-13 01:05:10 +0200, Dieter Nützel wrote:
Am 13.05.2019 00:03, schrieb Jason Ekstrand:
> Likely you're either getting slightly different build flags for some
> reason it else something extra is getting linked into the gallium
>
https://bugs.freedesktop.org/show_bug.cgi?id=110345
Thomas Rohloff changed:
What|Removed |Added
Attachment #144232|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #28 from Thomas Rohloff ---
(In reply to Samuel Pitoiset from comment #27)
> vulkaninfo reports 2 devices which means you likely have two drivers
> installed.
> Can you first clean up your install to make sure the number of reported
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #27 from Samuel Pitoiset ---
(In reply to Thomas Rohloff from comment #25)
> No, just one (Sapphire NITRO+ Radeon RX 580):
>
> > # lspci | grep VGA
> > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> >
Hello Dylan,
On Fri, 10 May 2019 at 22:57, Dylan Baker wrote:
>
> Hi Sumit,
>
> I haven't looked too closely at this, but there are a couple of things right
> away that jumped out to me. I've noted them inline below
Thanks for your quick review.
>
> Quoting Sumit Semwal (2019-05-09 23:02:57)
> >
On Monday, 2019-05-13 01:05:10 +0200, Dieter Nützel wrote:
> Am 13.05.2019 00:03, schrieb Jason Ekstrand:
> > Likely you're either getting slightly different build flags for some
> > reason it else something extra is getting linked into the gallium
> > driver that want before. Not all they
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #26 from Samuel Pitoiset ---
(In reply to Cameron Banfield from comment #19)
> Cities: Skylines will crash in the same way (but on Ryzen PRO 7 2700U Vega
> 10) so might help with re-producing and testing?
>
> This is guaranteed to
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #25 from Thomas Rohloff ---
No, just one (Sapphire NITRO+ Radeon RX 580):
> # lspci | grep VGA
> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
> Ellesmere [Radeon RX 470/480/570/570X/580/580X] (rev e7)
Update features.txt with misc supported features for r600,
as reported by glxinfo for Cypress XT [Radeon HD 5870].
Signed-off-by: Uros Bizjak
---
docs/features.txt | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/docs/features.txt b/docs/features.txt
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #24 from Samuel Pitoiset ---
You have two Polaris10 in your machine right?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
> > + auto const level_to_string = [](spv_message_level_t level){
>
> "const auto" would be more idiosyncratic.
>
> > + switch (level) {
> > +case SPV_MSG_FATAL:
> > + return std::string("Fatal");
> > +case SPV_MSG_INTERNAL_ERROR:
> > +
Using nir_gather_ssa_types is wrong. In both Midgard and NIR, SSA
values are just a bunch of bits with no int/float distinction, and
therefore you shouldn't need to know how a register is used to compile
the instruction producing it. The only distinction between imov and
fmov, in both NIR and the
Since last Friday, these two tests have been fixed:
dEQP-GLES2.functional.shaders.functions.control_flow.return_in_nested_loop_fragment
dEQP-GLES2.functional.shaders.linkage.varying_7
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/expected-failures.txt | 2 --
1 file changed,
As with the previous value of 5000 we seemed to be reaching OOM in some
circumstances.
Signed-off-by: Tomeu Vizoso
---
src/gallium/drivers/panfrost/ci/deqp-runner.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/panfrost/ci/deqp-runner.sh
57 matches
Mail list logo
