https://bugs.freedesktop.org/show_bug.cgi?id=110440
--- Comment #3 from Tapani Pälli ---
This is possibly related to sampler arrays inside a struct? There are 4
locations set (by the referred change) during this test and 3 of those are
sampler arrays. Not sure what could be going wrong there thou
https://bugs.freedesktop.org/show_bug.cgi?id=110323
--- Comment #3 from john.frank...@outlook.com ---
Thanks.
The workaround builds without error on 64-bit, but fails with 32-bit.
Note that with a 64-bit build, glxgears segfaults with software acceleration -
is glxgears hardware acceleration onl
On 4/18/19 8:39 AM, Samuel Pitoiset wrote:
On 4/18/19 8:38 AM, Samuel Pitoiset wrote:
On 4/18/19 8:34 AM, Timothy Arceri wrote:
On 18/4/19 4:34 pm, Samuel Pitoiset wrote:
On 4/18/19 8:16 AM, Timothy Arceri wrote:
Meant to add this was tested on LLVM 9.
What do you mean?
I meant to say
On 4/18/19 8:50 AM, Timothy Arceri wrote:
On 18/4/19 3:08 pm, Tapani Pälli wrote:
On 4/18/19 8:05 AM, Timothy Arceri wrote:
This reverts commit 624789e3708c87ea2a4c8d2266266b489b421cba.
It caused 400+ piglit tests to crash on radeonsi, I haven't been able
to track down the reason yet.
Co
On 4/18/19 8:38 AM, Samuel Pitoiset wrote:
On 4/18/19 8:34 AM, Timothy Arceri wrote:
On 18/4/19 4:34 pm, Samuel Pitoiset wrote:
On 4/18/19 8:16 AM, Timothy Arceri wrote:
Meant to add this was tested on LLVM 9.
What do you mean?
I meant to say in the commit messages:
This first patch in
On 4/18/19 8:34 AM, Timothy Arceri wrote:
On 18/4/19 4:34 pm, Samuel Pitoiset wrote:
On 4/18/19 8:16 AM, Timothy Arceri wrote:
Meant to add this was tested on LLVM 9.
What do you mean?
I meant to say in the commit messages:
This first patch in this series caused a piglit regression with
On 18/4/19 4:34 pm, Samuel Pitoiset wrote:
On 4/18/19 8:16 AM, Timothy Arceri wrote:
Meant to add this was tested on LLVM 9.
What do you mean?
I meant to say in the commit messages:
This first patch in this series caused a piglit regression with radeonsi
NIR on my VEGA64 with LLVM 9.
We
On 4/18/19 8:16 AM, Timothy Arceri wrote:
Meant to add this was tested on LLVM 9.
What do you mean?
Well, there is something really strange with RadeonSI NIR then.
On 18/4/19 4:15 pm, Timothy Arceri wrote:
This reverts commit 9cf55b022dfa43f8fe3163edeb87a1c25ebf5a16.
This first patch in
Meant to add this was tested on LLVM 9.
On 18/4/19 4:15 pm, Timothy Arceri wrote:
This reverts commit 9cf55b022dfa43f8fe3163edeb87a1c25ebf5a16.
This first patch in this series caused a piglit regression with
radeonsi NIR on my VEGA64.
tests/spec/arb_shader_storage_buffer_object/execution/ssbo-
This reverts commit 9cf55b022dfa43f8fe3163edeb87a1c25ebf5a16.
This first patch in this series caused a piglit regression with
radeonsi NIR on my VEGA64.
tests/spec/arb_shader_storage_buffer_object/execution/ssbo-atomicAdd-int.shader_test
---
src/amd/vulkan/radv_device.c | 10 --
src
This reverts commit 78c551aca1c785470e3c0480e33a072b0b5f8928.
This patch caused a piglit regression with radeonsi NIR on my VEGA64.
tests/spec/arb_shader_storage_buffer_object/execution/ssbo-atomicAdd-int.shader_test
---
src/amd/common/ac_nir_to_llvm.c | 31 +--
1 fil
This reverts commit d118e382dd037696ff904e230b11028abf214e80.
This first patch in this series caused a piglit regression with
radeonsi NIR on my VEGA64.
tests/spec/arb_shader_storage_buffer_object/execution/ssbo-atomicAdd-int.shader_test
---
src/amd/common/ac_nir_to_llvm.c | 10 +++---
1 fil
On 18/4/19 3:08 pm, Tapani Pälli wrote:
On 4/18/19 8:05 AM, Timothy Arceri wrote:
This reverts commit 624789e3708c87ea2a4c8d2266266b489b421cba.
It caused 400+ piglit tests to crash on radeonsi, I haven't been able
to track down the reason yet.
Could you share the backtrace?
It's more comp
On 4/18/19 8:05 AM, Timothy Arceri wrote:
This reverts commit 624789e3708c87ea2a4c8d2266266b489b421cba.
It caused 400+ piglit tests to crash on radeonsi, I haven't been able
to track down the reason yet.
Could you share the backtrace?
---
src/amd/vulkan/radv_device.c | 3 ---
This reverts commit 624789e3708c87ea2a4c8d2266266b489b421cba.
It caused 400+ piglit tests to crash on radeonsi, I haven't been able
to track down the reason yet.
---
src/amd/vulkan/radv_device.c | 3 ---
src/compiler/glsl/glsl_parser_extras.cpp | 20 ++-
src/compiler/glsl
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state_viewport.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_viewport.c
b/src/gallium/drivers/radeonsi/si_state_viewport.c
index 1ec69216841..83905d36ee6 100644
--- a/src/galliu
https://bugs.freedesktop.org/show_bug.cgi?id=110462
--- Comment #2 from Timothy Arceri ---
Are you sure it is actually requesting a core profile?
On i965 and older versions of radeonsi we fall back to core profile because
they don't/didn't support compat profile in GL 4.4.
--
You are receiving
From: Marek Olšák
si_emit_streamout_end is called directly, it's not a state.
Cc: 19.0
---
src/gallium/drivers/radeonsi/si_pipe.c| 2 ++
src/gallium/drivers/radeonsi/si_pipe.h| 1 +
src/gallium/drivers/radeonsi/si_state_draw.c | 2 +-
src/gallium/drivers/radeons
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pipe.h | 2 +-
src/gallium/drivers/radeonsi/si_state.c | 8 +++
src/gallium/drivers/radeonsi/si_state_binning.c | 4 ++--
src/gallium/drivers/radeonsi/si_state_draw.c | 30 +++-
src/gallium/d
From: Marek Olšák
The rework is needed to include ACQUIRE_MEM in the workaround by moving
the workaround logic out of si_emit_all_states.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110355
Cc: 19.0
---
src/gallium/drivers/radeonsi/si_state_draw.c | 60 +---
From: Marek Olšák
Cc: 19.0
---
src/gallium/drivers/radeonsi/si_state.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.h
b/src/gallium/drivers/radeonsi/si_state.h
index 311e1a4..119558b 100644
--- a/src/gallium/drivers/radeonsi/si_sta
Hi Lei,
You are right. The width alignment for HEVC encoding should be 64. This is
actually a hardware requirement that we missed here. Thanks for catching it.
Just a small suggestion, can we use macros to define width alignment for hevc
and h264 instead of the number 64 and 16? So that we can
On Wed, Apr 17, 2019 at 11:34:15AM -0700, Rafael Antognolli wrote:
> On Wed, Apr 17, 2019 at 09:04:09AM -0700, Kenneth Graunke wrote:
> > On Wednesday, April 17, 2019 7:16:28 AM PDT Topi Pohjolainen wrote:
> > > From: Rafael Antognolli
> > >
> > > Fixes MCS fast clear gpu hangs with Vulkan CTS on
So I have trouble making sense of what did you change but on its own
the patch looks good to me. r-b
On Tue, Apr 16, 2019 at 5:26 PM Samuel Pitoiset
wrote:
>
> From: Bas Nieuwenhuizen
>
> Basically just reserve the memory in the descriptor sets.
>
> On the shader side we construct a buffer descr
"Juan A. Suarez Romero" writes:
> From: Iago Toral Quiroga
>
> v2:
> - Adapted unit tests to make them consistent with the changes done
>to the validation of half-float conversions.
>
> v3 (Curro):
> - Check all the accummulators
> - Constify declarations
> - Do not check src1 type in singl
hmm, should work by design if we keep the entry but make it False. Let
me look into it.
On Wed, Apr 17, 2019 at 9:59 PM Samuel Pitoiset
wrote:
>
>
> On 4/17/19 9:05 PM, Samuel Pitoiset wrote:
> >
> > On 4/17/19 8:52 PM, Bas Nieuwenhuizen wrote:
> >> On Tue, Apr 16, 2019 at 10:35 AM Samuel Pitoise
On 4/17/19 9:05 PM, Samuel Pitoiset wrote:
On 4/17/19 8:52 PM, Bas Nieuwenhuizen wrote:
On Tue, Apr 16, 2019 at 10:35 AM Samuel Pitoiset
wrote:
No support for 64-bit compare&swap atomic operations.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 10 ++
src
r-b for the series
On Tue, Mar 26, 2019 at 12:36 PM Samuel Pitoiset
wrote:
>
> LLVM 9+ now supports 8-bit and 16-bit types.
>
> This changes requires LLVM r356465.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/common/ac_llvm_build.c | 51 +++---
> 1 file changed
On 4/17/19 8:52 PM, Bas Nieuwenhuizen wrote:
On Tue, Apr 16, 2019 at 10:35 AM Samuel Pitoiset
wrote:
No support for 64-bit compare&swap atomic operations.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 10 ++
src/amd/vulkan/radv_extensions.py | 1 +
src/a
If this was specified and a non-NULL display was passed to
eglGetPlatformDisplay, we would ignore the attribute and instead use
whatever xcb thought the default screen would be.
To fix this, store a copy of the attribute list in the _EGLDisplay, and
use that to look up any non-default screen numbe
On Tue, Apr 16, 2019 at 10:35 AM Samuel Pitoiset
wrote:
>
> No support for 64-bit compare&swap atomic operations.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/amd/vulkan/radv_device.c | 10 ++
> src/amd/vulkan/radv_extensions.py | 1 +
> src/amd/vulkan/radv_shader.c | 1 +
>
On Wed, Apr 17, 2019 at 09:04:09AM -0700, Kenneth Graunke wrote:
> On Wednesday, April 17, 2019 7:16:28 AM PDT Topi Pohjolainen wrote:
> > From: Rafael Antognolli
> >
> > Fixes MCS fast clear gpu hangs with Vulkan CTS on ICL in CI.
> >
> > CC: Anuj Phogat
> > CC: Kenneth Graunke
> > Tested-by:
On Wed, 17 Apr 2019 at 19:25, Bas Nieuwenhuizen
wrote:
>
> This will not work as-is for radv, as failure to initialize from
> wsi_display_init_wsi (->wsi_device_init -> radv_init_wsi) will cause
> us to fail initializing the whole device.
>
Indeed - same applies across the board.
I'll send out v
This will not work as-is for radv, as failure to initialize from
wsi_display_init_wsi (->wsi_device_init -> radv_init_wsi) will cause
us to fail initializing the whole device.
On Wed, Apr 17, 2019 at 7:02 PM Emil Velikov wrote:
>
> From: Emil Velikov
>
> As effectively required by the extension,
https://bugs.freedesktop.org/show_bug.cgi?id=110253
--- Comment #3 from Bruce Cherniak ---
The patch is OpenSWR specific, however, it is in response to a gallium API
change:
"gallium: add pipe_resource::nr_storage_samples, and set it same as nr_samples"
https://cgit.freedesktop.org/mesa/mesa/com
> I think the only (valid) reason not to use pipe_reference would be if
> it was some code that might someday be useful for a vulkan driver.
Good to know :)
> (That said, maybe we should move more and more of gallium's helpful
> util stuff out of gallium so they can be re-used across the mesa
> t
https://bugs.freedesktop.org/show_bug.cgi?id=109183
Alexander changed:
What|Removed |Added
Version|18.3|19.0
--
You are receiving this mail becaus
From: Emil Velikov
As effectively required by the extension, we need to ensure we're master
Currently drivers employ vendor specific solutions, which check if the
device behind the fd is capable*, yet none of them do the master check.
*In the radv case, if acceleration is available.
Instead of
https://bugs.freedesktop.org/show_bug.cgi?id=109183
--- Comment #6 from Alexander ---
Created attachment 144012
--> https://bugs.freedesktop.org/attachment.cgi?id=144012&action=edit
dmesg
Here I have something interesting maybe
--
You are receiving this mail because:
You are the QA Contact f
On Tue, Apr 16, 2019 at 8:07 AM Alyssa Rosenzweig wrote:
>
> > > diff --git a/src/gallium/drivers/panfrost/pan_job.c
> > > b/src/gallium/drivers/panfrost/pan_job.c
> > > index 66a8b0d4b07..6c68575158f 100644
> > > --- a/src/gallium/drivers/panfrost/pan_job.c
> > > +++ b/src/gallium/drivers/panfros
On Tue, Apr 16, 2019 at 12:31 AM Boris Brezillon
wrote:
>
> On Tue, 16 Apr 2019 01:49:21 +
> Alyssa Rosenzweig wrote:
>
> > @@ -1793,22 +1799,9 @@ panfrost_set_vertex_buffers(
> > const struct pipe_vertex_buffer *buffers)
> > {
> > struct panfrost_context *ctx = pan_context
https://bugs.freedesktop.org/show_bug.cgi?id=110323
--- Comment #2 from Jan Zielinski ---
I've reproduced the issue.
It is connected to auto-generated files in swr/rasterizer/jitter directory
(gen_*). Those files may have to be regenerated when switching to a different
LLVM version, but are not.
On Wednesday, April 17, 2019 7:16:28 AM PDT Topi Pohjolainen wrote:
> From: Rafael Antognolli
>
> Fixes MCS fast clear gpu hangs with Vulkan CTS on ICL in CI.
>
> CC: Anuj Phogat
> CC: Kenneth Graunke
> Tested-by: Topi Pohjolainen
> Signed-off-by: Rafael Antognolli
> ---
> src/intel/isl/isl
https://bugs.freedesktop.org/show_bug.cgi?id=110454
Roland Scheidegger changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
From: Rafael Antognolli
Fixes MCS fast clear gpu hangs with Vulkan CTS on ICL in CI.
CC: Anuj Phogat
CC: Kenneth Graunke
Tested-by: Topi Pohjolainen
Signed-off-by: Rafael Antognolli
---
src/intel/isl/isl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/isl/i
hi Augusto. Could you please create ticket here =>
https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fi965&list_id=669448&product=Mesa&resolution=---
Please provide all below information there also. And the last thing -
could you please clarify conditions, when/how apps hang - a
Hi,
Recently applications using Mesa/DRI libraries started fo freeze
randomly in my system...
I'm running Fedora 29 x86_64:
- Kernel: x86_64 Linux 5.0.7-200.fc29.x86_64
- X.Org X Server 1.20.4
- mesa 18.3.6
$ lspci -k | grep -EA3 'VGA compatible'
00:02.0 VGA compatible controller: Intel Corporat
On 04/16/2019 06:35 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
llvm 8 removed saturated unsigned add / sub x86 sse2 intrinsics, and
now llvm 9 removed the signed versions as well - they were proposed for
removal earlier, but the pattern to recognize those was very complex,
so it was
https://bugs.freedesktop.org/show_bug.cgi?id=110462
Danylo changed:
What|Removed |Added
CC||danylo.pilia...@gmail.com
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=110462
Bug ID: 110462
Summary: Epic Games Launcher renders nothing with "-opengl"
option
Product: Mesa
Version: unspecified
Hardware: Other
OS: Linux (All)
From: Iago Toral Quiroga
v2:
- Adapted unit tests to make them consistent with the changes done
to the validation of half-float conversions.
v3 (Curro):
- Check all the accummulators
- Constify declarations
- Do not check src1 type in single-source instructions.
- Check for all instructions
https://bugs.freedesktop.org/show_bug.cgi?id=110452
Eero Tamminen changed:
What|Removed |Added
CC||eero.t.tammi...@intel.com
--
You are r
https://bugs.freedesktop.org/show_bug.cgi?id=110452
Eero Tamminen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110440
--- Comment #2 from Andrés Gómez García ---
(In reply to Mark Janes from comment #1)
> FWIW, this test is not in the dEQP mustpass list.
It is. I found this regression running:
$ ./cts-runner --type=es32
On the "opengl-es-cts-3.2.5" branch.
https://bugs.freedesktop.org/show_bug.cgi?id=110459
--- Comment #3 from faalag...@gmail.com ---
Thanks for the reply! I will take a look later today or tomorrow hopefully;
guess I should not be overly worried about it triggering some anticheat
protection? The launcher needs online connection to ru
https://bugs.freedesktop.org/show_bug.cgi?id=110459
--- Comment #2 from Samuel Pitoiset ---
Can you record a renderdoc capture ?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=110459
--- Comment #1 from faalag...@gmail.com ---
Created attachment 144011
--> https://bugs.freedesktop.org/attachment.cgi?id=144011&action=edit
Without RADV_DEBUG=nohiz
--
You are receiving this mail because:
You are the QA Contact for the bug.
Y
https://bugs.freedesktop.org/show_bug.cgi?id=110459
Bug ID: 110459
Summary: Escape from Tarkov on DXVK renders wrong windows
reflection unless RADV_DEBUG=nohiz is passed
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
58 matches
Mail list logo
