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)
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
--- 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 #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=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=110452
Eero Tamminen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110452
Eero Tamminen changed:
What|Removed |Added
CC||eero.t.tammi...@intel.com
--
You are r
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=110462
Bug ID: 110462
Summary: Epic Games Launcher renders nothing with "-opengl"
option
Product: Mesa
Version: unspecified
Hardware: Other
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=110462
Danylo changed:
What|Removed |Added
CC||danylo.pilia...@gmail.com
--- Comment #1 from
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=110454
Roland Scheidegger changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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 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
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
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
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
Alexander changed:
What|Removed |Added
Version|18.3|19.0
--
You are receiving this mail becaus
> 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=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
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,
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
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 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 +
>
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 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
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 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
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
"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
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
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
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
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
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
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
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
---
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
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
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 ---
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
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
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 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
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-
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
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: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 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: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: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
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
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
58 matches
Mail list logo
