Why not just use LLVMConstNull()?
On Mon, Feb 26, 2018 at 12:14 AM, Timothy Arceri wrote:
> ---
> src/amd/common/ac_llvm_build.c | 15 +++
> src/amd/common/ac_llvm_build.h | 3 +++
> 2 files changed, 18 insertions(+)
>
> diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/a
Without this llvm was asserting in debug builds.
---
src/amd/common/ac_nir_to_llvm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
index f37f19404e..1ff074e2ff 100644
--- a/src/amd/common/ac_nir_to_llvm.c
---
src/amd/common/ac_llvm_build.c | 15 +++
src/amd/common/ac_llvm_build.h | 3 +++
2 files changed, 18 insertions(+)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 15144addb9..f3775938e5 100644
--- a/src/amd/common/ac_llvm_build.c
+++ b/src/amd/c
Previously, we would always apply the layout transition at the beginning
of the subpass and then do the clear whether fast or slow. This meant
that there were some cases, specifically when the initial layout is
VK_IMAGE_LAYOUT_UNDEFINED, where we would end up doing a fast-clear or
ambiguate follow
On Sun, Feb 25, 2018 at 3:00 PM, Francisco Jerez wrote:
> Seems like a serious hack to me to work around broken linking... IMO we
> should just fix the linking issue. The symbols for the various GLSL
> types need to be linked with the proper binding and visibility -- I
> assume that the cause of
Am 25.02.2018 um 21:12 schrieb Francisco Jerez:
> Roland Scheidegger writes:
>
>> Am 25.02.2018 um 03:35 schrieb Francisco Jerez:
>>> Roland Scheidegger writes:
>>>
This seems to have broken compilation with some gcc versions (with scons
build):
In file included from src/comp
From: Dave Airlie
Inspired by a passing commit to radeonsi.
---
src/amd/vulkan/radv_device.c | 93 ++-
src/amd/vulkan/radv_private.h | 3 +-
2 files changed, 40 insertions(+), 56 deletions(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/ra
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Roland Scheidegger writes:
> Am 25.02.2018 um 03:35 schrieb Francisco Jerez:
>> Roland Scheidegger writes:
>>
>>> This seems to have broken compilation with some gcc versions (with scons
>>> build):
>>>
>>> In file included from src/compiler/glsl/ast_array_index.cpp:24:0:
>>> src/compiler/glsl/
Seems like a serious hack to me to work around broken linking... IMO we
should just fix the linking issue. The symbols for the various GLSL
types need to be linked with the proper binding and visibility -- I
assume that the cause of your problem is that people are making
assumptions about the equ
https://bugs.freedesktop.org/show_bug.cgi?id=105243
--- Comment #1 from Frank ---
Created attachment 137595
--> https://bugs.freedesktop.org/attachment.cgi?id=137595&action=edit
Example 2
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the
https://bugs.freedesktop.org/show_bug.cgi?id=105243
Bug ID: 105243
Summary: vsync(?) artifact
Product: Mesa
Version: 17.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Prio
This is a sort of workaround for an issue encountered with the ongoing
work for clover clc->spirv->nir work for supporting OpenCL with drivers
that support consuming nir instead of llvm-ir. The problem is that
libnir (and therefore glsl_types) ends up statically linked into both
clover and the pip
https://bugs.freedesktop.org/show_bug.cgi?id=105207
--- Comment #6 from pritzl3...@gmail.com ---
Created attachment 137591
--> https://bugs.freedesktop.org/attachment.cgi?id=137591&action=edit
steam output
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=105207
--- Comment #5 from pritzl3...@gmail.com ---
I dont seen to be able to get a backtrace. When I try to attach the Talos
process after a hang gdb just sits there trying to attach to the process. I'm
not a developer so I dont really know what else t
https://bugs.freedesktop.org/show_bug.cgi?id=105238
Bug ID: 105238
Summary: ast.h:648:16: error: union member 'i' has a
non-trivial constructor
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: All
From: Marek Olšák
The old function treats high values as negative, which LLVM interprets as 0.
---
src/amd/common/ac_llvm_util.c| 4 ++--
src/amd/common/ac_llvm_util.h| 2 +-
src/gallium/drivers/radeonsi/si_shader.c | 7 +--
3 files changed, 8 insertions(+), 5 deletio
From: Marek Olšák
Cc: 18.0
---
src/gallium/drivers/radeonsi/si_descriptors.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index a4dae44..89fb614 100644
--- a/src/gallium/d
This seems to have broken compilation with some gcc versions (with scons
build):
In file included from src/compiler/glsl/ast_array_index.cpp:24:0:
src/compiler/glsl/ast.h:648:16: error: member
‘ast_type_qualifier::bitset_t ast_type_qualifier::flags::i’ with
constructor not allowed in union
https://bugs.freedesktop.org/show_bug.cgi?id=104302
--- Comment #5 from gloriouseggr...@gmail.com ---
@Samuel Pitoiset
both patches work great with mesa! the distance render blackness is fixed and
the shooting bloom and light effect bloom bugs are fixed. now just need the
melty-faces fixed and the
For the series:
Tested-by: Dieter Nützel
at least on openSUSE Tumbleweed with
wayland-protocols-devel-1.13-1.1.noarch removed.
Thanks!
Dieter
Am 23.02.2018 12:22, schrieb Daniel Stone:
Also only check for wayland-scanner if building for the Wayland
platform.
Signed-off-by: Daniel Stone
F
Am 25.02.2018 um 03:35 schrieb Francisco Jerez:
> Roland Scheidegger writes:
>
>> This seems to have broken compilation with some gcc versions (with scons
>> build):
>>
>> In file included from src/compiler/glsl/ast_array_index.cpp:24:0:
>> src/compiler/glsl/ast.h:648:16: error: member
>> ‘ast_ty
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 28 -
src/gallium/drivers/radeon/r600_pipe_common.c | 24 -
2 files changed, 18 insertions(+), 34 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/sr
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 15 +--
src/gallium/drivers/radeonsi/si_descriptors.c | 6 +-
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r
Roland Scheidegger writes:
> This seems to have broken compilation with some gcc versions (with scons
> build):
>
> In file included from src/compiler/glsl/ast_array_index.cpp:24:0:
> src/compiler/glsl/ast.h:648:16: error: member
> ‘ast_type_qualifier::bitset_t ast_type_qualifier::flags::i’ with
Tested-by: Dieter Nützel
with $R600_DEBUG=sisched,nir on UH and UV.
Thank you guys.
Dieter
Am 23.02.2018 07:04, schrieb Timothy Arceri:
Lowering fpow in NIR rather than LLVM can be beneficial.
Polaris results:
Totals from affected shaders:
SGPRS: 124928 -> 124896 (-0.03 %)
VGPRS: 68616 -> 6
So what is wrong with patches 9-13?
We can do cleanups after those.
Marek
On Thu, Feb 22, 2018 at 5:17 PM, Marek Olšák wrote:
> I don't think that adding "uint32_t userdata_XX[16];" would simplify anything.
>
> The bottom line is, patches 9-13 are prerequisites for VBO descriptors
> in user SGP
Fixes: a25093de7188 ("swr/rast: Implement JIT shader caching to disk")
Signed-off-by: Vinson Lee
---
src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/JitManager.cpp
b/src/gal
From: Marek Olšák
Cc: 17.3 18.0
---
src/gallium/drivers/radeonsi/si_descriptors.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 89fb614..49b5a2c 100644
--- a/src/gal
From: Marek Olšák
Cc: 17.3 18.0
---
src/gallium/drivers/radeonsi/si_descriptors.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 49b5a2c..6d5738b 100644
--- a/src/gal
From: Marek Olšák
Cc: 17.3 18.0
---
src/gallium/drivers/radeonsi/si_compute.c | 4 ++--
src/gallium/drivers/radeonsi/si_state.c | 24 +---
src/gallium/drivers/radeonsi/si_state_shaders.c | 18 +-
3 files changed, 24 insertions(+), 22 deletions(
https://bugs.freedesktop.org/show_bug.cgi?id=105052
--- Comment #3 from Vinson Lee ---
(In reply to Francisco Jerez from comment #2)
> Created attachment 137473 [details] [review]
> 0001-intel-ir-Fix-invalid-type-aliasing-with-undefined-be.patch
>
> Does it go away with the attached patch? I had
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 31 +++---
src/gallium/drivers/radeonsi/si_shader_internal.h | 2 --
.../drivers/radeonsi/si_shader_tgsi_setup.c| 8 --
3 files changed, 16 insertions(+), 25 deletions(-)
diff --git a/src/g
test_fuzz_compact_instruction() was attempting to modify the uint64_t
data array of a brw_inst through a pointer to uint32_t, which has
undefined behavior. This was causing the test_eu_compact unit test to
fail mysteriously for me on GCC 7 with some additional
harmless-looking changes I had applie
Build mesa 7013 failed
Commit 51562ea7a0 by Francisco Jerez on 2/24/2018 2:35 AM:
mesa: Expose EXT_shader_framebuffer_fetch(_non_coherent) on desktop and embedded GL.\n\nReviewed-by: Plamena Manolova
Configure your notification preferences
_
https://bugs.freedesktop.org/show_bug.cgi?id=105208
--- Comment #4 from Mario Kleiner ---
Jonas has completed some work to fix this in Mutter:
https://gitlab.gnome.org/GNOME/mutter/issues/2
https://gitlab.gnome.org/GNOME/mutter/merge_requests/36
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=105232
--- Comment #1 from Ilia Mirkin ---
Theory: The tests didn't run prior to this commit because of the format
matching fail, since the original commit that broke argb8 formats,
2ed344645d65. They have now started running again and are as broken no
On Feb 24, 2018 5:52 AM, "Timothy Arceri" wrote:
Using this on its own I believe will cause CTS regressions, which is what
the other patches were about. Feel free to take on the feedback and come up
with a proper solution. I'm not really sure how to progress this.
The patch is correct. If there
currently while insterting barriers, writes and reads to FILE_FLAGS aren't
considered. This can lead to WaR hazards in some situations.
With the previous commit fixes shaders with intstructions like this:
mad u32 $r2 $r4 $r11 $r2
mad u32 { $r5 $c0 } $r4 $r10 $r6
mad (SUBOP:1) u32 $r3 $r4 $r1
ALU_EXTENDED needs 4 DWORDS instead of the usual 2, hence if the last ALU
clause within a IF-JUMP or ELSE branch is ALU_EXTENDED the target jump
offset needs to be adjusted accordingly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104654
Signed-off-by: Gert Wollny
---
* An additional
In the sched data calculator we have to track first use of defs by iterating
over all defs of an instruction, not just the first one.
v2: fix minGRP and maxGRP values
Signed-off-by: Karol Herbst
---
.../drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 34 --
1 file changed,
Hi,
On 24 February 2018 at 00:43, Jason Ekstrand wrote:
> On Tue, Feb 13, 2018 at 4:31 PM, Keith Packard wrote:
>> + image->chain = chain;
>> + image->state = wsi_image_idle;
>> + image->fb_id = 0;
>> +
>> + /* XXX extract depth and bpp from image somehow */
>
> You have the format in cr
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 0bbf21312f..48c
43 matches
Mail list logo
