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
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 ++-
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
---
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
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 +++-
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 +-
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
---
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
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
"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
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
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 atomic operations.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 10 ++
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
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 atomic operations.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 10 ++
src/amd/vulkan/radv_extensions.py | 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
On Tue, Apr 16, 2019 at 10:35 AM Samuel Pitoiset
wrote:
>
> No support for 64-bit compare 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 +
> 3
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
> >
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
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
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"
> 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
>
https://bugs.freedesktop.org/show_bug.cgi?id=109183
Alexander changed:
What|Removed |Added
Version|18.3|19.0
--
You are receiving this mail
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
https://bugs.freedesktop.org/show_bug.cgi?id=109183
--- Comment #6 from Alexander ---
Created attachment 144012
--> https://bugs.freedesktop.org/attachment.cgi?id=144012=edit
dmesg
Here I have something interesting maybe
--
You are receiving this mail because:
You are the QA Contact for the
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
> > > +++
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 =
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
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
> ---
>
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
hi Augusto. Could you please create ticket here =>
https://bugs.freedesktop.org/buglist.cgi?component=Drivers%2FDRI%2Fi965_id=669448=Mesa=---
Please provide all below information there also. And the last thing -
could you please clarify conditions, when/how apps hang - also in the
ticket.
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
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
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
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
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=edit
Without RADV_DEBUG=nohiz
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are
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)
46 matches
Mail list logo
