On 2019年04月25日 03:22, Eric Anholt wrote:
"Zhou, David(ChunMing)" writes:
Will linux be only mesa-linux? I thought linux is an open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
reject?
For patches 2 - 8:
Reviewed-by: Marek Olšák
Marek
On Wed, Apr 24, 2019 at 9:15 AM Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Force the driver thread to sync immediately with a compiler thread (but
> compilation still happens in a separate thread).
>
> This can be useful to simplify
On Wed, Apr 24, 2019 at 9:14 AM Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Move the definition of radeonsi_clear_db_cache_before_clear there,
> as well as radeonsi_enable_nir.
>
> This removes the AMD_DEBUG=nir option.
>
> We currently still have two places for options: the driconf
https://bugs.freedesktop.org/show_bug.cgi?id=110431
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
We were only setting the used mask for the first component of a
varying. Since the linking opts split vectors into scalars this
has mostly worked ok.
However this causes an issue where for example if we split a
struct on one side of the interface but not the other, then we
can possibly end up
On Wednesday, April 24, 2019 2:29:21 AM PDT Topi Pohjolainen wrote:
> One cannot write the URB arbitrarily and therefore the message
> has to be carefully constructed. The clever tricks originate
> from Kenneth and Jason, I'm just writing the patch.
>
> Fixes GPU hangs on ICL with Vulkan CTS.
>
ACK
On Wed, Apr 24, 2019 at 8:15 AM Juan A. Suarez Romero
wrote:
> This reverts commit 40b3abb4d16af4cef0307e1b4904c2ec0924299e.
>
> It is not clear that this commit was entirely correct, and unfortunately
> it was pushed by error.
>
> CC: Jason Ekstrand
> ---
>
> Jason, we agreed on leaving
R-b
On Wed, Apr 24, 2019, 11:36 PM Marek Olšák wrote:
> From: Marek Olšák
>
> need_cs_space may clear the buffer list.
>
> Fixes: 951d60f8cdc88 "radeonsi: delay adding BOs at the beginning of IBs
> until the first draw"
> ---
> src/gallium/drivers/radeonsi/si_compute.c| 6 +++---
>
Build mesa 10882 completed
Commit 08f3ce4c7d by Lionel Landwerlin on 4/12/2019 10:05 AM:
anv: leave the top 4Gb of the high heap VMA unused\n\nIn 628c9ca9089789 I forgot to apply the same -4Gb of the high address\nof the high heap VMA. This was previously
https://bugs.freedesktop.org/show_bug.cgi?id=109929
--- Comment #17 from Jan Vesely ---
(In reply to Timur Kristóf from comment #16)
> Can you guys try this branch?
>
> https://gitlab.freedesktop.org/Venemo/mesa/commits/nir-lower-samplers
>
> It seems to work for me at least on radeonsi, but I
It should be fixed by the patch "radeonsi: add BOs after need_cs_space".
Marek
On Wed, Apr 24, 2019 at 12:17 PM Michel Dänzer wrote:
> On 2019-04-23 5:39 p.m., GitLab Mirror wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 951d60f8cdc886adff09201ff65002e3ee1a4c61
> > URL:
>
From: Marek Olšák
need_cs_space may clear the buffer list.
Fixes: 951d60f8cdc88 "radeonsi: delay adding BOs at the beginning of IBs until
the first draw"
---
src/gallium/drivers/radeonsi/si_compute.c| 6 +++---
src/gallium/drivers/radeonsi/si_state_draw.c | 6 +++---
2 files changed, 6
Ping
On Thu, Apr 18, 2019 at 5:46 PM Marek Olšák wrote:
> 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
>
Build mesa 10877 failed
Commit 69430d7e59 by Jiang, Sonny on 4/2/2019 5:44 PM:
va: use a compute shader for the blit\n\nSigned-off-by: Sonny Jiang \nSigned-off-by: Marek Olšák
Configure your notification preferences
"Zhou, David(ChunMing)" writes:
> Will linux be only mesa-linux? I thought linux is an open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
> reject?
> 2. one hw feature that opengl/amdvlk
Hi everyone,
I'd like to announce the availability of mesa 19.0.3, the third bugfix release
of the 19.0 cycle. It's continued to be a quiet release with just 19 patches
(excluding release churn) since 19.0.2. No one sub componenet was touched too
much, but there are the normal suspects: virgl,
From: Marek Olšák
---
src/compiler/glsl/builtin_functions.cpp | 78 -
1 file changed, 24 insertions(+), 54 deletions(-)
diff --git a/src/compiler/glsl/builtin_functions.cpp
b/src/compiler/glsl/builtin_functions.cpp
index c8d9e1c9af3..b1ffafa1acf 100644
---
On Wed, 24 Apr 2019 at 13:09, Emil Velikov wrote:
>
> On Tue, 23 Apr 2019 at 23:10, Alyssa Ross wrote:
> >
> > > Off the top of my head - none of the VL code should be build when we
> > > have only a swrast driver.
> > > Can you try and kill that bug, or shall I?
> >
> > Isn't that what this
On 2019-04-23 5:39 p.m., GitLab Mirror wrote:
> Module: Mesa
> Branch: master
> Commit: 951d60f8cdc886adff09201ff65002e3ee1a4c61
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=951d60f8cdc886adff09201ff65002e3ee1a4c61
>
> Author: Marek Olšák
> Date: Wed Feb 27 21:13:15 2019 -0500
Thanks guys, I've replaced my attempt with Marek's for the release.
Dylan
Quoting Marek Olšák (2019-04-23 13:16:15)
> No, the correct backport is attached.
>
> Marek
>
> On Tue, Apr 23, 2019 at 2:51 PM Dylan Baker wrote:
>
> Hi Marek and Samuel,
>
> I've staged this for 19.0, but I
Reviewed-by: Samuel Pitoiset
On 4/24/19 2:54 PM, Bas Nieuwenhuizen wrote:
Reviewed-by: Bas Nieuwenhuizen
On Wed, Apr 24, 2019 at 2:40 PM Eleni Maria Stea wrote:
Before setting the physical device API version, we should check if the
MESA_VK_VERSION_OVERRIDE environment variable is set and
在 2019/4/24 22:36, Daniel Vetter 写道:
> On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter wrote:
>> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
>> wrote:
>>> Will linux be only mesa-linux? I thought linux is an open linux.
>>> Which will impact our opengl/amdvlk(MIT open source), not sure
On Wed, Apr 24, 2019 at 4:28 PM Daniel Vetter wrote:
>
> On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
> wrote:
> > Will linux be only mesa-linux? I thought linux is an open linux.
> > Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> > 1. how to deal with one uapi
On Wed, Apr 24, 2019 at 4:24 PM Zhou, David(ChunMing)
wrote:
> Will linux be only mesa-linux? I thought linux is an open linux.
> Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
> 1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
> reject?
> 2. one
Will linux be only mesa-linux? I thought linux is an open linux.
Which will impact our opengl/amdvlk(MIT open source), not sure Rocm:
1. how to deal with one uapi that opengl/amdvlk needs but mesa dont need?
reject?
2. one hw feature that opengl/amdvlk developers work on that but no mesa
https://bugs.freedesktop.org/show_bug.cgi?id=110356
Eric Engestrom changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Clear rules avoid arguing.
Note that this just aims to document current expectations. If that
shifts (e.g. because gl isn't the main api anymore, replaced by vk),
then we need to update this text.
I think it'd be good to have an equally solid list on the kms side.
But kms is much more meant to
Fixes building errors due to missing libmesa_util generated files include
and libexpat dependencies:
In file included from external/mesa/src/amd/vulkan/radv_device.c:52:
external/mesa/src/util/xmlpool.h:115:10: fatal error: 'xmlpool/options.h' file
not found
^~~
1 error
This reverts commit 40b3abb4d16af4cef0307e1b4904c2ec0924299e.
It is not clear that this commit was entirely correct, and unfortunately
it was pushed by error.
CC: Jason Ekstrand
---
Jason, we agreed on leaving this out of the VK_KHR_shader_float16_int8
patchset, but due a mistake I've pushed
From: Nicolai Hähnle
Enabling this option will create ddebug-style dumps for the aux context,
except that instead of intercepting the pipe_context layer
we just dump the IB contents on flush.
---
src/gallium/drivers/radeonsi/si_debug.c | 17 +
From: Nicolai Hähnle
---
src/gallium/auxiliary/driver_ddebug/dd_draw.c | 63 +-
src/gallium/auxiliary/driver_ddebug/dd_util.h | 66 +++
2 files changed, 70 insertions(+), 59 deletions(-)
diff --git a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
From: Nicolai Hähnle
This can be useful when internal draws lead to a hang.
---
src/gallium/auxiliary/driver_ddebug/dd_draw.c | 75 ++-
src/gallium/auxiliary/driver_ddebug/dd_pipe.h | 6 ++
2 files changed, 61 insertions(+), 20 deletions(-)
diff --git
From: Nicolai Hähnle
Due to asynchronous execution, it's not clear which of the draws the state
may refer to.
This also works around an issue encountered with radeonsi where dumping
the driver state itself caused a hang.
---
src/gallium/auxiliary/driver_ddebug/dd_draw.c | 17 -
From: Nicolai Hähnle
For better debuggability.
---
src/gallium/auxiliary/driver_ddebug/dd_draw.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/auxiliary/driver_ddebug/dd_draw.c
b/src/gallium/auxiliary/driver_ddebug/dd_draw.c
index f5b94356119..4eb0dd096f4 100644
Hi folks,
this is a collection of assorted patches that should help with driver
debugging:
- add driconf-style debug options in a convenient way
- some minor ddebug cleanups
- allow dumping aux context command streams
- allow force-syncing of compile threads
Please review!
Thanks,
Nicolai
--
From: Nicolai Hähnle
Force the driver thread to sync immediately with a compiler thread (but
compilation still happens in a separate thread).
This can be useful to simplify debugging compiler issues.
---
src/gallium/drivers/radeonsi/si_debug_options.inc | 1 +
From: Nicolai Hähnle
Without this, command stream dumps of radeonsi may misleadingly end up
in a later page.
---
src/gallium/auxiliary/util/u_log.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_log.c
b/src/gallium/auxiliary/util/u_log.c
index
From: Nicolai Hähnle
Move the definition of radeonsi_clear_db_cache_before_clear there,
as well as radeonsi_enable_nir.
This removes the AMD_DEBUG=nir option.
We currently still have two places for options: the driconf machinery
and AMD_DEBUG/R600_DEBUG. If we are to have a single place for
Reviewed-by: Bas Nieuwenhuizen
On Wed, Apr 24, 2019 at 2:40 PM Eleni Maria Stea wrote:
>
> Before setting the physical device API version, we should check if the
> MESA_VK_VERSION_OVERRIDE environment variable is set and take it into
> account.
> ---
> src/amd/vulkan/radv_extensions.py | 8
Before setting the physical device API version, we should check if the
MESA_VK_VERSION_OVERRIDE environment variable is set and take it into
account.
---
src/amd/vulkan/radv_extensions.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/amd/vulkan/radv_extensions.py
On Tue, 23 Apr 2019 at 23:10, Alyssa Ross wrote:
>
> > Off the top of my head - none of the VL code should be build when we
> > have only a swrast driver.
> > Can you try and kill that bug, or shall I?
>
> Isn't that what this patch does?
>
> If there's only swrast, this patch prevents enabling
One cannot write the URB arbitrarily and therefore the message
has to be carefully constructed. The clever tricks originate
from Kenneth and Jason, I'm just writing the patch.
Fixes GPU hangs on ICL with Vulkan CTS.
CC: Kenneth Graunke
CC: Jason Ekstrand
CC: Anuj Phogat
CC: Clayton Craft
This patch series goes a complete different route then the one from
Lucas Stach. I am using the integrated YUV tiler instead of using
the 2D core for format conversion. I am reusing some patches from
Lucas and this series sits on-top of Lucas "st/dri: YUV" patches.
Christian Gmeiner (3):
The GPU is able to sample from YUYV/UYVY textures directly.
Passes following piglits:
- ext_image_dma_buf_import-sample_yuv -fmt=YUYV
- ext_image_dma_buf_import-sample_yuv -fmt=UYVY
Signed-off-by: Christian Gmeiner
---
src/gallium/drivers/etnaviv/etnaviv_format.c | 2 +-
From: Lucas Stach
Imported resources might not start at offset 0 into the buffer object.
Make sure to remember the offset that is provided with the handle on
import.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
Reviewed-by: Christian Gmeiner
---
This enables support for NV12, which are really useful when
dealing with hardware video decoders. This patch makes use
of the integrated YUV tiler to convert multi-planar to YUYV.
The binary blob uses the same method to deal with multi-planar
YUV formats. Other formarts will be added in a
From: Lucas Stach
We copy the template resource content into the newly allocated resource.
If the template derived from a planar resource this leads to a non reference
counted copy of the next resource pointer. Make sure to clear this out when
allocating a new resource.
Signed-off-by: Lucas
From: Lucas Stach
We weren't handling this flag at all, which broke some assumptions
made by the users of the resource_create interface. As we can't render
to a linear surface and the usefulness of yet another layout transition
to handle this case seems limited, we only respect the flag when the
Update to etna_viv commit 1ccc35b.
Signed-off-by: Christian Gmeiner
---
src/gallium/drivers/etnaviv/hw/common.xml.h | 2 +-
.../drivers/etnaviv/hw/common_3d.xml.h| 2 +-
src/gallium/drivers/etnaviv/hw/state.xml.h| 4 +--
src/gallium/drivers/etnaviv/hw/state_3d.xml.h | 35
On Wed, Apr 24, 2019 at 12:59 AM Mark Janes wrote:
> I pushed the patches that got review (1-3). I haven't prompted anyone
> for more review, because FrameRetrace is the only app that will
> immediately benefit from the patches. Eventually, the existing
> mechanism will break, and someone that
I pushed the patches that got review (1-3). I haven't prompted anyone
for more review, because FrameRetrace is the only app that will
immediately benefit from the patches. Eventually, the existing
mechanism will break, and someone that needs to debug their shader
assemblies will have a reason to
51 matches
Mail list logo
