Verified to fix the test as initializers get propagated;
Reviewed-by: Tapani Pälli
On 5/29/19 6:13 AM, Timothy Arceri wrote:
This essentially reverts 20234cfe3a20.
Fixes piglit test:
tests/spec/arb_get_program_binary/execution/uniform-after-restore.shader_test
Fixes: 20234cfe3a20 "st/mesa: d
https://bugs.freedesktop.org/show_bug.cgi?id=110811
--- Comment #3 from Andrew Sheldon ---
(In reply to Samuel Pitoiset from comment #2)
> Can you upload your renderdoc trace please?
How odd, I did upload it, but it's marked as deleted. Will try again.
--
You are receiving this mail because:
Y
On Mon, 3 Jun 2019 at 11:37, Jan Vesely wrote:
>
> On Mon, 2019-06-03 at 11:12 +1000, Dave Airlie wrote:
> > On Mon, 3 Jun 2019 at 10:58, Jan Vesely wrote:
> > > On Sun, 2019-06-02 at 20:09 -0400, James Harvey wrote:
> > > > I've started a thread on the llvm mailing list. See
> > > > https://nam
On Sun, 2 Jun 2019 at 11:59, Bas Nieuwenhuizen
wrote:
> On Sun, Jun 2, 2019 at 12:32 PM Alex Smith
> wrote:
> >
> > Put the uncached GTT type at a higher index than the visible VRAM type,
> > rather than having GTT first.
> >
> > When we don't have dedicated VRAM, we don't have a non-visible VRA
On 6/3/19 9:46 AM, Alex Smith wrote:
On Sun, 2 Jun 2019 at 11:59, Bas Nieuwenhuizen
mailto:b...@basnieuwenhuizen.nl>> wrote:
On Sun, Jun 2, 2019 at 12:32 PM Alex Smith
mailto:asm...@feralinteractive.com>>
wrote:
>
> Put the uncached GTT type at a higher index than the visib
The following patch [1] is still waiting for a review.
[1] https://lists.freedesktop.org/archives/mesa-dev/2019-May/219217.html
Uros.
On Sat, May 11, 2019 at 12:20 PM Uros Bizjak wrote:
>
> Update features.txt with misc supported features for r600,
> as reported by glxinfo for Cypress XT [Radeo
https://bugs.freedesktop.org/show_bug.cgi?id=110811
--- Comment #4 from Andrew Sheldon ---
Okay, so uploading on freedesktop is timing out with Error 500. Here's a GDrive
link to the renderdoc trace:
https://drive.google.com/file/d/1PM0zJcw7KZyOsMTmDJYarxXy1hrja_fh/view
--
You are receiving thi
On 6/3/19 1:17 PM, Tapani Pälli wrote:
Hi;
On 5/30/19 12:03 PM, Rudrappa, Shiva Kumara wrote:
Hi,
Can someone please help to validate below MESA features.
“system shall allow 3D rendering to make use of OpenCL buffers in a
zero-copy manner”
“system shall allow 3D rendering to make use of
Hi;
On 5/30/19 12:03 PM, Rudrappa, Shiva Kumara wrote:
Hi,
Can someone please help to validate below MESA features.
“system shall allow 3D rendering to make use of OpenCL buffers in a
zero-copy manner”
“system shall allow 3D rendering to make use of Media SDK buffers in a
zero-copy manner.
On Sat, Jun 1, 2019 at 11:24 PM Marek Olšák wrote:
>
> clover is not supported by AMD officially, because AMD has its own OpenCL
> driver called ROCm.
>
> Marek
ROCm isn't a viable option for many. Official support only goes back
to Fiji . Running without PCIe atomics support only applies to V
https://bugs.freedesktop.org/show_bug.cgi?id=105171
--- Comment #19 from Richard Thier ---
Possibly related problem on r300 code paths:
https://bugs.freedesktop.org/show_bug.cgi?id=110781
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1099745-how-to-tell
Am 02.06.19 um 12:32 schrieb Alex Smith:
> Put the uncached GTT type at a higher index than the visible VRAM type,
> rather than having GTT first.
>
> When we don't have dedicated VRAM, we don't have a non-visible VRAM
> type, and the property flags for GTT and visible VRAM are identical.
> Accordi
On Mon, 2019-04-15 at 16:15 +0200, Juan A. Suarez Romero wrote:
> Hi all,
>
> Here is the tentative release plan for 19.1.0.
>
> As many of you are well aware, it's time to the next branch point.
> The calendar is already updated, so these are the tentative dates:
>
> Apr 30 2019 - Feature free
https://bugs.freedesktop.org/show_bug.cgi?id=110811
--- Comment #5 from Samuel Pitoiset ---
Does https://reviews.llvm.org/D62614 help?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mes
On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
wrote:
> Am 02.06.19 um 12:32 schrieb Alex Smith:
> > Put the uncached GTT type at a higher index than the visible VRAM type,
> > rather than having GTT first.
> >
> > When we don't have dedicated VRAM, we don't have a non-visible VRAM
> > type, and
Am 03.06.19 um 14:21 schrieb Alex Smith:
On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
mailto:christian.koe...@amd.com>> wrote:
Am 02.06.19 um 12:32 schrieb Alex Smith:
> Put the uncached GTT type at a higher index than the visible VRAM type,
> rather than having GTT first.
>
> When we don't have
Thanks, will have a look - can't look right now, will see if I can sometime
tomorrow.
Alex
On Mon, 3 Jun 2019 at 13:27, Koenig, Christian
wrote:
> Am 03.06.19 um 14:21 schrieb Alex Smith:
>
> On Mon, 3 Jun 2019 at 11:57, Koenig, Christian
> wrote:
>
>> Am 02.06.19 um 12:32 schrieb Alex Smith:
I thought LLVM was able to handle that itself but actually it
does not. That means we shouldn't try to emit vec3 on SI because
it's unsupported.
Fixes: 6970a9a6ca9 ("ac,radv: remove the vec3 restriction with LLVM 9+")"
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c| 12 +++
r-b
On Fri, May 24, 2019 at 10:06 AM Samuel Pitoiset
wrote:
>
> From the Vulkan spec 1.1.108:
>"vkCmdCopyQueryPoolResults is guaranteed to see the effect of
> previous uses of vkCmdResetQueryPool in the same queue, without any
> additional synchronization."
>
> Signed-off-by: Samuel P
On Thu, May 30, 2019 at 2:48 PM Vinson Lee wrote:
>
> ../src/freedreno/vulkan/tu_device.c:900:4: error: initializer element is not
> constant
> .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> ^
>
> Suggested-by: Kristian Høgsberg
> Bugzilla: https://bugs.freedesktop.org/show_b
While it is not wrong, I don't think this is the right fix, as the
current_layout is not necessarily accurate.
Will try to get something better.
On Thu, May 30, 2019 at 3:10 PM Samuel Pitoiset
wrote:
>
> This might fix initial subpass transitions when multiview is used.
> Noticed while implement
> On Jun 3, 2019, at 9:13 AM, Samuel Pitoiset wrote:
>
> I thought LLVM was able to handle that itself but actually it
> does not. That means we shouldn't try to emit vec3 on SI because
> it's unsupported.
>
It should. Can you file a bug with an example that doesn’t work?
> Fixes: 6970a9a6
https://bugs.freedesktop.org/show_bug.cgi?id=110815
--- Comment #4 from Bas Nieuwenhuizen ---
>From that description, sounds like poolSizeCount is wrong. It should
be equal to the number of structs in pPoolSizes, not the sum of their
descriptorCount. So sounds like it should be 1.
>From spec:
"
On 6/3/19 3:48 PM, Matt Arsenault wrote:
On Jun 3, 2019, at 9:13 AM, Samuel Pitoiset wrote:
I thought LLVM was able to handle that itself but actually it
does not. That means we shouldn't try to emit vec3 on SI because
it's unsupported.
It should. Can you file a bug with an example that do
The driver should only fast depth clears with the graphics path
when the view covers all image layers, otherwise this might
corrupt layers when HTILE is enabled.
Cc: 19.0 19.1 mesa-sta...@lists.freedesktop.org
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_meta_clear.c | 1 +
1 file chan
r-b
On Mon, Jun 3, 2019 at 5:49 PM Samuel Pitoiset
wrote:
>
> The driver should only fast depth clears with the graphics path
> when the view covers all image layers, otherwise this might
> corrupt layers when HTILE is enabled.
>
> Cc: 19.0 19.1 mesa-sta...@lists.freedesktop.org
> Signed-off-by:
https://bugs.freedesktop.org/show_bug.cgi?id=110345
--- Comment #38 from ant...@gmx.de ---
Running mesa-git 19.2 together with LLVM8 does not expose the issue for me as
well. So I assume it's LLVM causing the issue.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You
https://bugs.freedesktop.org/show_bug.cgi?id=110815
--- Comment #5 from Alex Fuller ---
Hi Baz,
I am not in front of that computer right now, but I believe the function is
being passed an array of size 'CONF_DESCRIPTOR_TYPE_RANGE_SIZE' which is
'VK_DESCRIPTOR_TYPE_RANGE_SIZE' or VK_DESCRIPTOR_TY
From: Emil Velikov
Cc: Brian Paul
Cc: Jose Fonseca
Cc: Roland Scheidegger
Signed-off-by: Emil Velikov
---
src/gallium/winsys/svga/drm/vmw_screen_dri.c | 29
1 file changed, 6 insertions(+), 23 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
b/src
I've got no comments on this,
but it should be safe to push and find a better solution later.
Axel
On 30/05/2019 12:43, Axel Davy wrote:
Thanks Juan for warning me it didn't make it to mesa-dev.
Here it is.
Axel
Forwarded Message
Subject:[PATCH] d3dadapter9: Rever
Reviewed-by: Marek Olšák
Marek
On Fri, May 31, 2019 at 8:55 AM Connor Abbott wrote:
> Bindless handles in GL are 64-bit. This fixes an assert failure in LLVM.
> ---
>
> With this patch, we now have Piglit parity in debug mode.
>
> src/gallium/drivers/radeonsi/si_shader_nir.c | 4 ++--
> 1 fil
SI doesn't support buffer_load_dwordx3 and buffer_store_dwordx3, but it
supports buffer_load_format_xyz and buffer_store_format_xyz.
Marek
On Mon, Jun 3, 2019 at 9:09 AM Samuel Pitoiset
wrote:
> I thought LLVM was able to handle that itself but actually it
> does not. That means we shouldn't tr
On 6/3/19 9:33 PM, Marek Olšák wrote:
SI doesn't support buffer_load_dwordx3 and buffer_store_dwordx3, but
it supports buffer_load_format_xyz and buffer_store_format_xyz.
OK, I will update.
Marek
On Mon, Jun 3, 2019 at 9:09 AM Samuel Pitoiset
mailto:samuel.pitoi...@gmail.com>> wrote:
It's unsupported, only load/store format with vec3 are supported.
v2: - allow to use load/store format with vec3
Fixes: 6970a9a6ca9 ("ac,radv: remove the vec3 restriction with LLVM 9+")"
Signed-off-by: Samuel Pitoiset
---
src/amd/common/ac_llvm_build.c| 12 ++--
src/amd/common/ac_ll
https://bugs.freedesktop.org/show_bug.cgi?id=110832
Bug ID: 110832
Summary: Commit 911ea2c66fc54c5066707f7fe4451ec573792ae7 breaks
Elite Dangerous shader compiling
Product: Mesa
Version: git
Hardware: Other
From: Marek Olšák
It skipped slab allocators and the buffer cache.
Cc: 19.1
---
src/gallium/drivers/r300/r300_query.c | 3 ++-
src/gallium/drivers/r300/r300_render.c| 3 ++-
src/gallium/drivers/r300/r300_screen_buffer.c | 6 --
src/gallium/drivers/r300/r300_texture.c
https://bugs.freedesktop.org/show_bug.cgi?id=110832
Mark Janes changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |ja...@jlekstrand.net
|or
tbuffer loads and stores should set use_format=true, and the *_xyz variants
are supported. Other than that:
Reviewed-by: Marek Olšák
Marek
On Mon, Jun 3, 2019 at 3:52 PM Samuel Pitoiset
wrote:
> It's unsupported, only load/store format with vec3 are supported.
>
> v2: - allow to use load/stor
https://bugs.freedesktop.org/show_bug.cgi?id=110833
Bug ID: 110833
Summary: [bisected][regression] Android build test failing on
matrix.c (-Wformat-security 'format string is not a
string literal' error)
Product: Mesa
Would you please review this fixed version:
https://cgit.freedesktop.org/~mareko/mesa/commit/?h=master&id=40e4702ef815410f74130f349e2b40cc0524e422
It trivially solves the GBM crash by checking that gbm_surf != NULL before
using it.
Marek
On Mon, May 20, 2019 at 3:03 PM Mathias Fröhlich
wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=110833
--- Comment #1 from Mark Janes ---
Fix:
https://gitlab.freedesktop.org/majanes/mesa/commit/713523f85b31f5c144ca557a51bfc7e4adcc43e6
--
You are receiving this mail because:
You are the QA Contact for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110833
Mark Janes changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
The flush callback may be called on the same pipe context, and thus
the same stream, from two different threads of execution. However,
etna_cmd_stream_flush{,2}() must not be called on the same stream
from two different threads of execution as that would mess up the
etna_bo refcounting and likely h
From: Marek Olšák
Cc: 19.1
---
src/amd/common/ac_llvm_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index d0e11141b81..79058f53b4e 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/common/ac_ll
From: Marek Olšák
---
src/amd/common/ac_llvm_build.c | 74 +-
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 79058f53b4e..2a1a133c392 100644
--- a/src/amd/common/ac_llvm_build.c
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index e044e180778..3610ec90a89 100644
--- a/src/gallium/drivers/r
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
b/src/gallium/drivers/radeonsi/si_state_shaders.c
index c26acbbc927..c4517fcf538 100644
--- a/src/gallium/d
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 147 +++
1 file changed, 67 insertions(+), 80 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader.c
b/src/gallium/drivers/radeonsi/si_shader.c
index 3610ec90a89..8c4f4e75653 100644
--- a/src/galli
From: Marek Olšák
---
src/amd/common/ac_llvm_build.c| 5 +++--
src/amd/common/ac_llvm_build.h| 1 +
src/amd/common/ac_nir_to_llvm.c | 2 +-
.../radeonsi/si_compute_prim_discard.c| 21 ---
.../drivers/radeonsi/si_shader_tgsi
From: Marek Olšák
---
.../drivers/radeonsi/si_shader_tgsi_mem.c | 38 ---
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index c5704bc0eae..63184a4f396 1006
From: Marek Olšák
---
.../drivers/radeonsi/si_shader_tgsi_mem.c | 35 ---
1 file changed, 6 insertions(+), 29 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
b/src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c
index 63184a4f396..cc634f495ef 10064
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_test_dma_perf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_test_dma_perf.c
b/src/gallium/drivers/radeonsi/si_test_dma_perf.c
index 263187d683f..0b5a4a38ab7 100644
--- a/src/gallium/drivers/radeonsi
Fixes piglits:
call.cl
calls-larget-struct.cl
calls-struct.cl
calls-workitem-id.cl
realign-stack.cl
tail-calls.cl
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely
---
The piglit test now pass using llvm-7,8,git.
ImageMagick works on m
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely
---
src/amd/common/ac_binary.c | 2 ++
src/amd/common/ac_binary.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/src/amd/common/ac_binary.c b/src/amd/common/ac_binary.c
index 8f4755ebe16..18dc72c61f0 100644
--- a/src/amd/comm
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Jan Vesely
---
src/gallium/drivers/radeonsi/si_compute.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 51da06fe550..b9cea00e
https://bugs.freedesktop.org/show_bug.cgi?id=110815
--- Comment #6 from Alex Fuller ---
I managed to do some testing and I can now trigger the bug. It looks like when
creating a vkCreateDescriptorPool of size 11 which is the default
VK_DESCRIPTOR_TYPE_RANGE_SIZE everything is fine which is the be
This series will probably conflict with the new linker, which will also
handle relocations and more:
https://patchwork.freedesktop.org/series/60255/
Marek
On Mon, Jun 3, 2019 at 10:39 PM Jan Vesely wrote:
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Jan Vesely
> ---
> src/amd/comm
On Tue, 2019-06-04 at 00:20 -0400, Marek Olšák wrote:
> This series will probably conflict with the new linker, which will
> also
> handle relocations and more:
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F60255%2F&data=02%7C01%7Cjan.vesel
Patches 1-2:
Reviewed-by: Samuel Pitoiset
On 6/4/19 2:02 AM, Marek Olšák wrote:
From: Marek Olšák
---
src/amd/common/ac_llvm_build.c | 74 +-
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_
59 matches
Mail list logo
