On 29.09.2017 14:25, Marek Olšák wrote:
From: Marek Olšák
just don't propagate output reads
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to
On 29.09.2017 14:25, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 45 +-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gallium/auxiliary/tgsi/tgsi_scan.c
index 2
ivers before it
goes into stable, but it looks good to me.
Reviewed-by: Nicolai Hähnle
---
src/mesa/state_tracker/st_cb_eglimage.c | 96 +
1 file changed, 50 insertions(+), 46 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_eglimage.c
b/src
ion is inconsistent about whether builder or ctx->ac.builder
is used here. Would be nice to still clean this up, but either way,
patches 2-11 are a nice cleanup and:
Reviewed-by: Nicolai Hähnle
LLVMConstInt(ctx->i32, 3, 0), "");
- samples = LLVMBuildLSh
On 29.09.2017 16:49, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_shader.c | 147 -
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 14 +-
src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 38 +++---
.../drivers/radeonsi/s
On 29.09.2017 14:26, Marek Olšák wrote:
From: Marek Olšák
This should be sufficient for testing all kernel/libdrm/radeonsi codepaths
that are used by radeonsi.
Reviewed-by: Nicolai Hähnle
---
src/gallium/auxiliary/util/u_tests.c | 101 +++
1 file
if
Just FYI, we're also calling LLVMParseCommandLineOptions from
ac_llvm_util.c, and that function doesn't seem to appreciate being
called multiple times. Not really an issue here since this will surely
only be used for llvmpipe, so:
Acked-by: Nicolai Hähnle
}
ex
l into u_atomic_test
(cherry picked from commit d075a4089ec62c489c8a3423f82371bf85f2ea6c)
commit 688f8415f7598addad9cd2a9d080fc5b3a48f9d2
Author: Nicolai Hähnle
amd/common: round cube array slice in ac_prepare_cube_coords
(cherry picked from commit e0af3bed2cb52b5d8cf1da08b42cf28
On 29.09.2017 17:01, Marek Olšák wrote:
I think it can still be renderable in desktop OpenGL.
The function has an early exit for desktop OpenGL.
Cheers,
Nicolai
Marek
On Fri, Sep 29, 2017 at 1:30 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
The EXT_texture_type_2_10_10_10_REV (ES
Hi all,
there are a bunch of dEQP tests for the GL_UNSIGNED_INT_2_10_10_10_REV
"format" in ES. This format doesn't exist as a proper internal format,
but ES expects it to be derived for a texture when using internal format
GL_RGB or GL_RGBA and type GL_UNSIGNED_INT_2_10_10_10_REV for the
texture u
From: Nicolai Hähnle
The EXT_texture_type_2_10_10_10_REV (ES only) states the following issue:
"1. Should textures specified with this type be renderable?
UNRESOLVED: No. A separate extension could provide this functionality."
This partially fixes
From: Nicolai Hähnle
This is the last step of fixing
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb_unsigned_int_2_10_10_10_rev
for radeonsi.
---
src/mesa/state_tracker/st_format.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/mesa
From: Nicolai Hähnle
---
src/gallium/auxiliary/util/u_format.csv | 1 +
src/gallium/auxiliary/util/u_format_tests.c | 6 ++
src/gallium/include/pipe/p_format.h | 2 ++
3 files changed, 9 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.csv
b/src/gallium/auxiliary
From: Nicolai Hähnle
ES requires it. This is a partial fix for
dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb_unsigned_int_2_10_10_10_rev
---
src/mesa/main/formats.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/formats.c b/src/mesa
On 28.09.2017 20:02, Roland Scheidegger wrote:
Am 28.09.2017 um 18:19 schrieb Jose Fonseca:
On 28/09/17 17:16, Roland Scheidegger wrote:
Am 28.09.2017 um 17:53 schrieb Jose Fonseca:
On 28/09/17 16:29, Roland Scheidegger wrote:
Am 28.09.2017 um 16:12 schrieb Jose Fonseca:
On 27/09/17 15:07, R
From: Nicolai Hähnle
v2: rebase fixes
---
src/gallium/drivers/radeon/r600_pipe_common.c | 4
src/gallium/drivers/radeon/r600_pipe_common.h | 1 -
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
src/gallium/drivers/radeonsi/si_state_draw.c| 10 +-
src/gallium
From: Nicolai Hähnle
We'll use it in the scissors / clip / guardband state.
v2: avoid a performance regression on r600 when applied to
(pre-fork) stable branches
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeon/r600_pipe_common.c | 4
src/gallium/drivers/r
On 29.09.2017 12:58, Eric Engestrom wrote:
On Thursday, 2017-09-28 20:23:16 +0200, Nicolai Hähnle wrote:
On 28.09.2017 18:37, Eric Engestrom wrote:
On Thursday, 2017-09-28 16:10:51 +, Nicolai Hähnle wrote:
From: Nicolai Hähnle
A tempting alternative fix would be adding a lock/unlock
From: Nicolai Hähnle
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 -
src/gallium/drivers/radeon/r600_pipe_common.h | 35
src/gallium/drivers/radeonsi/si_blit.c | 4 +-
src/gallium/drivers/radeonsi/si_hw_context.c| 10 +-
src/gallium/drivers/radeonsi
From: Nicolai Hähnle
They are just copies of the rasterizer state.
---
src/gallium/drivers/radeonsi/si_pipe.h | 4
src/gallium/drivers/radeonsi/si_state.c| 14 +++--
src/gallium/drivers/radeonsi/si_viewport.c | 32 +++---
3 files changed, 24
From: Nicolai Hähnle
It only affects pre-SI chips.
---
src/gallium/drivers/radeon/r600_pipe_common.h | 2 --
src/gallium/drivers/radeonsi/si_viewport.c| 17 -
2 files changed, 19 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers
From: Nicolai Hähnle
Together with the previous patches, this fixes
dEQP-GLES31.functional.primitive_bounding_box.wide_points.*
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_state_draw.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a
From: Nicolai Hähnle
This is purely a file-move + #include fixup + build system changes.
Other cleanups will follow in subsequent commits.
---
src/gallium/drivers/radeon/Makefile.sources| 1 -
src/gallium/drivers/radeonsi/Makefile.sources | 3
From: Nicolai Hähnle
This is a bit conservative, but a more precise solution requires access
to the rasterizer state. This is something to tackle after the fork between
r600 and radeonsi.
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeon/r600_viewport.c | 21
From: Nicolai Hähnle
The hardware registers store the half-size/width in 12.4 fixed point
format, so 8192 is the maximum.
Fixes dEQP-GLES3.functional.rasterization.*
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeon/r600_pipe_common.c | 7 +--
src/gallium/drivers
From: Nicolai Hähnle
We'll use it in the scissors / clip / guardband state.
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeonsi/si_pipe.h | 1 -
src/gallium/drivers/radeonsi/si_state_draw.c| 8
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_state.c| 7 ++-
src/gallium/drivers/radeonsi/si_state.h| 2 ++
src/gallium/drivers/radeonsi/si_viewport.c | 29 +++--
3 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/src/gallium
Hi all,
the situation of wide points and lines in ES is a bit confused since
EXT_primitive_bounding_box (and ES 3.2, which promotes that to core).
The traditional language surrounding clipping says that points are
discarded when their coordinates are outside the viewport, and similar
for lines. T
From: Nicolai Hähnle
---
src/gallium/drivers/radeon/r600_pipe_common.h | 1 -
src/gallium/drivers/radeonsi/si_pipe.h | 1 +
src/gallium/drivers/radeonsi/si_state_draw.c| 10 +-
src/gallium/drivers/radeonsi/si_state_shaders.c | 8
src/gallium/drivers/radeonsi
From: Nicolai Hähnle
---
src/gallium/drivers/radeonsi/si_pipe.h | 3 +--
src/gallium/drivers/radeonsi/si_state_shaders.c | 6 +++---
src/gallium/drivers/radeonsi/si_viewport.c | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi
From: Nicolai Hähnle
---
src/amd/common/ac_llvm_build.c | 14 ++
src/amd/common/ac_llvm_build.h | 5 +
src/gallium/drivers/radeonsi/si_shader.c | 20 +++-
3 files changed, 22 insertions(+), 17 deletions(-)
diff --git a/src/amd/common
From: Nicolai Hähnle
A recent commit fixed the case of integer cube maps, which need the
workaround of replacing the data format with USCALED/SSCALED. However,
this broke the case of non- integer cube maps; those still need the
fix of shifting the texture coordinates.
Fixes KHR-GL45
On 29.09.2017 00:54, Matt Turner wrote:
On Sat, Sep 16, 2017 at 4:23 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
GLSL ES requires both, and while GLSL explicitly doesn't require correct
overflow handling, it does appear to require handling input inf/denorms
correctly.
Fixes dEQP-G
On 29.09.2017 00:51, Matt Turner wrote:
On Thu, Sep 28, 2017 at 3:42 PM, Matt Turner wrote:
On Sat, Sep 16, 2017 at 4:23 AM, Nicolai Hähnle wrote:
Hi all,
This series was motivated by radeonsi failing some ldexp tests due to
not handling denorms correctly and not handling overflows (which
From: Nicolai Hähnle
---
src/gallium/drivers/r300/r300_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/r300/r300_screen.c
b/src/gallium/drivers/r300/r300_screen.c
index f41d09d263f..0c3e097535d 100644
--- a/src/gallium/drivers/r300/r300_screen.c
+++ b/src
From: Nicolai Hähnle
This fixes a warning caused by the fork (note the change in the function
signature):
../../../../../mesa-src/src/gallium/drivers/r600/r600_state_common.c: In
function ‘r600_init_common_state_functions’:
../../../../../mesa-src/src/gallium/drivers/r600/r600_state_common.c
Cheers,
Nicolai
Marek
On Wed, Sep 13, 2017 at 7:04 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
This is the same workaround that radv already applied in commit
3ece76f03dc0 ("radv/ac: gather4 cube workaround integer").
Fixes dEQP-GLES31.functional.texture.gather.basic.cube.
On 28.09.2017 18:37, Eric Engestrom wrote:
On Thursday, 2017-09-28 16:10:51 +, Nicolai Hähnle wrote:
From: Nicolai Hähnle
A tempting alternative fix would be adding a lock/unlock pair in
util_queue_fence_is_signalled. However, that wouldn't actually
improve anything in the semanti
On 28.09.2017 19:18, Gustaw Smolarczyk wrote:
2017-09-28 18:52 GMT+02:00 Marek Olšák :
A clearer comment would be: "Don't destroy the fence when it's in the
middle of util_queue_fence_signal (signalled but not unlocked yet
because util_queue_fence_is_signalled doesn't lock). Instead, wait
until
From: Nicolai Hähnle
A tempting alternative fix would be adding a lock/unlock pair in
util_queue_fence_is_signalled. However, that wouldn't actually
improve anything in the semantics of util_queue_fence_is_signalled,
while making that test much more heavy-weight. So this lock/unlock
pa
).
Acked-by: Nicolai Hähnle
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 14
src/gallium/auxiliary/tgsi/tgsi_exec.c | 48 ++---
src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h | 1 +
src/gallium/docs/source/tgsi.rst| 12
On 27.09.2017 20:42, Nicholas Miell wrote:
Giving the same name to two different types violates the C++ One Definition
Rule and gcc will complain about it in LTO builds.
Oh my. What does the gcc warning look like? (I assume it's just a warning.)
Since these are auto-generated headers which are
Didn't you send this already? It looks familiar, even in the v2.
Anyway, both patches:
Reviewed-by: Nicolai Hähnle
On 27.09.2017 16:01, Brian Paul wrote:
---
src/gallium/auxiliary/util/u_log.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxi
-
commit f348cd1430b7ca436bd83043c3f0155c4a045c1c
Author: Nicolai Hähnle
radeonsi: apply a mask to gl_SampleMaskIn in the PS prolog
(cherry picked from commit
92c4277990799641d4986ce66a62366228713945)
commit 21b223ebac2aba61bcf35201792c03ffca415afd
Author: Jason Ekstrand
On 27.09.2017 10:45, Marek Olšák wrote:
On Wed, Sep 6, 2017 at 12:35 PM, Nicolai Hähnle wrote:
https://travis-ci.org/nhaehnle/mesa-1/jobs/272422053
I suspect the se of $(top_srcdir) is the problem. Are you testing
out-of-tree builds?
No, I'm not testing out-of-tree builds. I don'
ren't for stable, I would
have just waited :)
Cheers,
Nicolai
On 09/26/2017 07:42 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Overriding the default (no-op) swizzle is clearly counter-productive,
since the whole point is putting the destination register as one of
the source operands
On 26.09.2017 18:55, Gustaw Smolarczyk wrote:
2017-09-26 16:46 GMT+02:00 Nicolai Hähnle :
From: Nicolai Hähnle
This fixes the extremely unlikely case that an application uses
0x8000 or 0x3f80 as border color for an integer texture and
helps in the also, but perhaps slightly less
From: Nicolai Hähnle
It leads to surprising states with integer inputs and outputs on
vertex processing stages (e.g. geometry stages). Instead, rely on the
driver to choose smooth interpolation by default.
We still allow varyings to match when one stage declares it as smooth
and the other
From: Nicolai Hähnle
The hardware usually does this automatically. However, we upgrade
depth to Z32_FLOAT to enable TC-compatible HTILE, which means the
hardware no longer clamps the comparison value for us.
The only way to tell in the shader whether a clamp is required
seems to be to
From: Nicolai Hähnle
The hardware does this automatically for unorm formats, but we need to
do it manually for unorm depth formats that have been upgraded to
Z32_FLOAT.
Fixes
dEQP-GLES31.functional.texture.border_clamp.range_clamp.nearest_unorm_depth
and others.
Fixes: d4d9ec55c589 ("rad
From: Nicolai Hähnle
This fixes the extremely unlikely case that an application uses
0x8000 or 0x3f80 as border color for an integer texture and
helps in the also, but perhaps slightly less, unlikely case that 1 is
used as a border color.
---
src/gallium/drivers/radeonsi
Hi all,
radeonsi can transparently upgrade unorm depth textures to float,
which means that some of the depth value clamping that is usually
performed in hardware must be done manually.
Also, setting the border color for integer textures properly
requires doing it slightly differently. This is som
From: Nicolai Hähnle
Fix the custom cube coord selection sequence to be identical to
the hardware v_cubesc/tc and OpenGL spec. Affects texture sampling
with user-provided derivatives.
Fixes dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*
Cc: mesa-sta...@lists.freedesktop.org
From: Nicolai Hähnle
Not that those are super common or useful, but hey! Fun corner cases
of the API...
Fixes dEQP-GLES31.functional.geometry_shading.emit.*
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_state_shaders.c | 8 +---
1 file changed, 5 insertions
From: Nicolai Hähnle
Found by address sanitizer.
The loop here tries to be safe, but in doing so, it ends up doing
exactly the wrong thing: the safe foreach is for when the loop
variable (inst) could be deleted and nothing else. However, this
particular can delete inst's successor, but not
From: Nicolai Hähnle
Avoid a v_cndmask: the absolute value is free due to input modifiers.
---
src/amd/common/ac_llvm_build.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/amd/common/ac_llvm_build.c b/src/amd/common/ac_llvm_build.c
index 8c050f31a76
From: Nicolai Hähnle
Overriding the default (no-op) swizzle is clearly counter-productive,
since the whole point is putting the destination register as one of
the source operands so that it remains unmodified when the assignment
condition is false.
Fragment depth and stencil outputs are a
Hi all,
There isn't much of a theme to this series, except that all those
patches are vaguely compiler-related.
Please review!
Thanks,
Nicolai
--
src/amd/common/ac_llvm_build.c| 17 +
.../drivers/radeonsi/si_state_shaders.c | 8 +---
src/mesa/state_tra
From: Nicolai Hähnle
---
src/gallium/drivers/radeon/cayman_msaa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/cayman_msaa.c
b/src/gallium/drivers/radeon/cayman_msaa.c
index 33f1040185a..ec6c49bafa0 100644
--- a/src/gallium/drivers/radeon
From: Nicolai Hähnle
It has to happen after descriptor uploads since otherwise we'll print out
the wrong GPU list / incorrectly claim descriptor corruption.
---
src/gallium/drivers/radeonsi/si_compute.c| 7 +++
src/gallium/drivers/radeonsi/si_state_draw.c | 7 +++
2 files chang
From: Nicolai Hähnle
Redundant with the recently added ac_llvm_context::chip_class.
---
src/amd/common/ac_nir_to_llvm.c | 21 ++---
src/amd/common/ac_shader_abi.h | 2 --
src/gallium/drivers/radeonsi/si_shader.c | 2 --
3 files changed, 10 insertions(+), 15
Ping.
On 16.09.2017 13:23, Nicolai Hähnle wrote:
Hi all,
This series was motivated by radeonsi failing some ldexp tests due to
not handling denorms correctly and not handling overflows (which GLSL
doesn't require, but GLSL ES does).
The first patch fixes the GLSL IR lowering of ldexp
mesa very well,
do you know how I could do the same thing in the new st_convert_sampler
function?
Thanks
Il 2017-09-26 12:56, Nicolai Hähnle ha scritto:
On 25.09.2017 18:50, Federico Dossena wrote:
Hello everyone,
you may remember that a few months ago I was trying to fix KOTOR to
work with
Thanks :)
Both patches:
Reviewed-by: Nicolai Hähnle
On 25.09.2017 23:08, Brian Paul wrote:
---
src/gallium/auxiliary/util/u_log.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_log.c
b/src/gallium/auxiliary/util/u_log.c
index 359b3e1
s
________
De: Marek Olšák
Para: Nicolai Hähnle
CC: "mesa-dev@lists.freedesktop.org" ; Nicolai
Hähnle
Enviado: Miércoles, 13 de septiembre, 2017 21:19:26
Asunto: Re: [Mesa-dev] [PATCH 5/5] radeonsi: allow out-of-order rasterization
in commutative blending cases
On 25.09.2017 18:50, Federico Dossena wrote:
Hello everyone,
you may remember that a few months ago I was trying to fix KOTOR to work
with Mesa to use the Gallium llvmpipe software renderer.
Well, it's been a while and I'm happy to see that things are a bit
better with Mesa 17.2. The game sti
Gert's suggestion makes sense. Apart from that, the series is
Reviewed-by: Nicolai Hähnle
On 22.09.2017 09:22, Samuel Pitoiset wrote:
That's unnecessary to double-check that dcc_offset is not 0
because all callers already check that.
Signed-off-by: Samuel Pitoiset
---
src/galli
send out the R-b. So:
Reviewed-by: Nicolai Hähnle
2017-09-11 22:21 GMT+02:00 Thomas Helland :
More tests could probably be added, but this should cover
concatenation, resizing, clearing, formatted printing,
and checking the length, so it should be quite complete.
V2: Address review feedback
On 21.09.2017 12:03, Eric Engestrom wrote:
Hmm, just noticed the title should be fixed. Something like this?
amd/addrlib: drop unnecessary va_copy()
Makes sense, but I already pushed it...
On Wednesday, 2017-09-20 14:48:46 +, Nicolai Hähnle wrote:
From: Nicolai Hähnle
There'
duplicating all of this for android eventually.
Dylan
Quoting Nicolai Hähnle (2017-09-20 13:57:17)
On 20.09.2017 22:27, Dylan Baker wrote:
+amd_common_files = files(
+ 'ac_binary.c',
+ 'ac_binary.h',
+ 'ac_exp_param.h',
+ 'ac_llvm_build.c',
+ 'ac
On 20.09.2017 22:27, Dylan Baker wrote:
+amd_common_files = files(
+ 'ac_binary.c',
+ 'ac_binary.h',
+ 'ac_exp_param.h',
+ 'ac_llvm_build.c',
+ 'ac_llvm_build.h',
+ 'ac_llvm_helper.cpp',
+ 'ac_llvm_util.c',
+ 'ac_llvm_util.h',
+ 'ac_shader_abi.h',
+ 'ac_shader_info.c',
+ 'ac_shader_inf
From: Nicolai Hähnle
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102904
Fixes: 15cae12804e ("glsl/linker: fix output variable overlap check")
---
src/compiler/glsl/linker.cpp | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/com
nment.
Reviewed-by: Nicolai Hähnle
---
src/gallium/auxiliary/util/u_mm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/util/u_mm.c
b/src/gallium/auxiliary/util/u_mm.c
index bd4c4e1b1060..7a45e291920e 100644
--- a/src/gallium/auxiliary/util/u_mm.c
From: Nicolai Hähnle
There's no reason to use va_copy here.
CID: 1418113
---
I have a slight preference for this variant.
--
src/amd/addrlib/core/addrobject.cpp | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/src/amd/addrlib/core/addrobject.cpp
b/src/amd/ad
From: Nicolai Hähnle
CID: 1418140
Fixes: c4ac522511d2 ("ac/surface: handle S8 on gfx9")
---
src/amd/common/ac_surface.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/amd/common/ac_surface.c b/src/amd/common/ac_surface.c
index 850d70715e5..22c653f0c4f 10
Looks good to me. I guess Emil didn't find any problems either. Feel
free to push with
Reviewed-by: Nicolai Hähnle
On 18.09.2017 18:08, Marek Olšák wrote:
On Thu, Sep 14, 2017 at 4:52 PM, Nicolai Hähnle wrote:
On 14.09.2017 16:19, Emil Velikov wrote:
Hi Marek,
On 14 September 2017
Reviewed-by: Nicolai Hähnle
On 18.09.2017 18:07, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_buffer_common.c | 13 -
src/gallium/drivers/radeon/r600_texture.c | 4
2 files changed, 4 insertions(+), 13 deletions(-)
diff --git a/src
On 18.09.2017 15:27, Benedikt Schemmer wrote:
There is a small typo that prevents compilation.
Please kindly review and push.
Cheers,
Benedikt
Signed-off-by: Benedikt Schemmer
Ilia pointed this out to me, but I dropped it (I think because the mail
didn't go to the mailing list. Or something.
On 18.09.2017 17:22, Jan Vesely wrote:
On Wed, 2017-09-13 at 18:53 +0200, Nicolai Hähnle wrote:
From: Nicolai Hähnle
To be able to properly distinguish between GL_ANY_SAMPLES_PASSED
and GL_ANY_SAMPLES_PASSED_CONSERVATIVE.
This patch goes through all drivers, having them treat the two
query
re leeway. Together with the D3D10 behavior, this
is a good argument for changing the test. I'm going to look into that.
Cheers,
Nicolai
Roland
Am 18.09.2017 um 11:44 schrieb Nicolai Hähnle:
Hi all,
This series fixes an issue we have on GCN due to the arguably inconsistent
handling of
From: Nicolai Hähnle
Like for cube map (array) gather, we need to round to nearest on <= VI.
Fixes tests in dEQP-GLES3.functional.shaders.texture_functions.texture.*
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_shader_tgsi_mem.c | 12 +++-
1 file chan
From: Nicolai Hähnle
This fixes a bug with nearest ("point") mip selection when the fractional
part of max_lod is in (0.5,1). In this case, the spec mandates that
we still select the mip level ceil(max_lod) in the clamping case. However,
MIP_POINT_PRECLAMP will clamp before the mip
-VK.image.image_size.1d_array.writeonly_1x1
dEQP-VK.image.image_size.1d_array.writeonly_32x32
dEQP-VK.image.image_size.1d_array.writeonly_7x1
Fixes: 1bcb953e166 "radv: handle GFX9 1D textures"
Acked-by: Nicolai Hähnle
---
src/amd/common/ac_nir_to_llvm.c | 3 ++-
1 file changed, 2 insert
On 14.09.2017 06:47, Timothy Arceri wrote:
The old code incorrectly assumed that loop terminators will always
be at the start of the loop. It really seems to be just luck that
we haven't triggered any bugs here, for example if there is a loop
terminator at the start of the loop we might actually
es, this patch is
Reviewed-by: Nicolai Hähnle
---
src/compiler/glsl/loop_analysis.cpp | 38 +
1 file changed, 38 insertions(+)
diff --git a/src/compiler/glsl/loop_analysis.cpp
b/src/compiler/glsl/loop_analysis.cpp
index b9bae43536..8a0425d185 100644
-
On 14.09.2017 06:47, Timothy Arceri wrote:
These instruction will be executed on every iteration of the loop
*instructions
Als, the title of the patch is missing an s ;)
Cheers,
Nicolai
we cannot drop them.
---
src/compiler/glsl/loop_analysis.h | 7 +++
src/compiler/glsl/loop_con
On 14.09.2017 06:47, Timothy Arceri wrote:
These instruction will be executed on every iteration of the loop
we cannot drop them.
---
src/compiler/glsl/loop_analysis.h | 7 +++
src/compiler/glsl/loop_controls.cpp | 15 +++
src/compiler/glsl/loop_unroll.cpp | 7 ---
Both patches:
Reviewed-by: Nicolai Hähnle
On 14.09.2017 19:40, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_texture.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_texture.c
b/src/gallium/drivers
From: Nicolai Hähnle
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h| 1 +
src/gallium/auxiliary/tgsi/tgsi_exec.h | 1 +
src/gallium/auxiliary/tgsi/tgsi_info_opcodes.h | 2 +-
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/docs/source/tgsi.rst
From: Nicolai Hähnle
We canonicalize floating point values before storing them anywhere where
the application could potentially examine the underlying bit pattern.
This includes GLSL bitcases, buffer stores (but not atomics, since they're
all operating on integer types) and imageStor
Hi all,
This series fixes an issue we have on GCN due to the arguably inconsistent
handling of denormal floating point values. We disable denormals for 32-bit
floating point numbers, because enabling them would cost a lot of
performance. By and large, GCN floating point instructions flush denormal
From: Nicolai Hähnle
Fixes
dEQP-GLES31.functional.shaders.builtin_functions.precision.{clamp,min,max}.*
---
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/src
From: Nicolai Hähnle
Prevent an overflow caused by too many output variables. To limit the
scope of the issue, write to the assigned array only for the non-ES
fragment shader path, which is the only place where it's needed.
Since the function will bail with an error when output variables
If you want to test, you can find the series at
https://cgit.freedesktop.org/~nh/mesa/log/?h=ldexp
On 16.09.2017 13:23, Nicolai Hähnle wrote:
Hi all,
This series was motivated by radeonsi failing some ldexp tests due to
not handling denorms correctly and not handling overflows (which GLSL
From: Nicolai Hähnle
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index cf6e8f8fde1..196b547d3d9 100644
--- a/src/mesa
From: Nicolai Hähnle
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h| 1 +
src/gallium/auxiliary/tgsi/tgsi_exec.c | 15 +++
src/gallium/auxiliary/tgsi/tgsi_exec.h | 1 +
src/gallium/auxiliary/tgsi/tgsi_info.c | 3 ++-
src/gallium/auxiliary/tgsi
From: Nicolai Hähnle
The status quo is quite the mess:
1. tgsi_exec will do a per-channel computation, and store the dst[0]
result (significand) correctly for each channel. The dst[1] result
(exponent) will be written to the first bit set in the writemask.
So per-component calculation
From: Nicolai Hähnle
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi.c| 18 +-
src/gallium/auxiliary/gallivm/lp_bld_tgsi_action.h | 5 +
src/gallium/auxiliary/tgsi/tgsi_exec.h | 9 +
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a
From: Nicolai Hähnle
The LLVM intrinsic has existed for a long time. The current name was
established in LLVM 3.9.
---
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
src/gallium/drivers/radeonsi/si_shader_tgsi_alu.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Nicolai Hähnle
Note: this causes spurious regressions in some current piglit tests,
because the tests incorrectly assume that there is no denorm support for
doubles. I'm going to send out a fix for those tests as well.
---
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
701 - 800 of 4145 matches
Mail list logo
