when dri2_add_config, driver_configs may add to exist dri2_conf,
the config id should not increase in this case.
In the code, when ConfigID equal to count+1, it's mean a new config,
config_count will increase. otherwise it's a exist config.
Signed-off-by: Liu Zhiquan
This reverts commit 4d6d55deef291b489af4d7870c6f5eb223c8da5d.
SurfaceType added EGL_PBUFFER_BIT when dri_single_config is null.
This will fix in "egl: correct surface_type when add config" patch.
---
src/egl/drivers/dri2/egl_dri2.c | 9 -
1 file changed, 9 deletions(-)
diff --git
When add config, dri_config is double or single. Should only add
EGL_WINDOW_BIT to surface_type for double dri_config, Should only add
EGL_PBUFFER_BIT EGL_PIXMAP_BIT to surface_type for single dri_config.
This avoid crash when operate on wrong surface_type which
dri_double_config or
I'm done reviewing things for the evening. I've got a little more looking
to do but it all looks fantastic so far. All of my comments have been
pretty cosmetic. I'll finish tomorrow and we can go over things in the
office if you'd like.
--Jason
On Wed, Jan 11, 2017 at 6:01 PM, Nanley Chery
On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery wrote:
> Avoid the resolves that would be required if fast depth clears were
> allowed for such buffers.
>
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_blorp.c | 9 +
> 1 file
On Thu, 2017-01-12 at 15:20 +1100, Timothy Arceri wrote:
> If one of the inputs to the multiplcation in ffma is the result of
> an fmul there is a chance that we can reuse the result of that
> fmul in other ffma calls if we do the multiplication in the right
> order.
>
> For example it is a
On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery wrote:
> Signed-off-by: Nanley Chery
> ---
> src/intel/isl/isl_surface_state.c | 38 ++
> +---
> 1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git
On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery wrote:
> This is a better mapping to the Vulkan API and improves performance in
> all tested workloads.
>
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_blorp.c | 48
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
I can change this to use a symbol e.g. '!' for non const but since we
are moving towards helpers I did it this way for now.
On Thu, 2017-01-12 at 15:20 +1100, Timothy Arceri wrote:
> If one of the inputs to the multiplcation in ffma is the result of
> an fmul there is a chance that we can reuse
If one of the inputs to the multiplcation in ffma is the result of
an fmul there is a chance that we can reuse the result of that
fmul in other ffma calls if we do the multiplication in the right
order.
For example it is a fairly common pattern for shaders to do something
similar to this:
On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery wrote:
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_image.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
>
On Wed, Jan 11, 2017 at 8:05 PM, Jason Ekstrand
wrote:
> On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery
> wrote:
>
>> Signed-off-by: Nanley Chery
>> ---
>> src/intel/vulkan/anv_image.c | 17 +
>>
On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery wrote:
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_image.c | 17 +
> src/intel/vulkan/genX_cmd_buffer.c | 10 --
> 2 files changed, 17 insertions(+), 10
On Wed, Jan 11, 2017 at 5:55 PM, Nanley Chery wrote:
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_blorp.c | 9 +++--
> src/intel/vulkan/anv_private.h | 15 +++
> src/intel/vulkan/genX_cmd_buffer.c | 5
Shader-db results BDW:
total instructions in shared programs: 13059905 -> 13059274 (-0.00%)
instructions in affected programs: 88407 -> 87776 (-0.71%)
helped: 329
HURT: 0
total cycles in shared programs: 256570054 -> 256548062 (-0.01%)
cycles in affected programs: 2308020 -> 2286028 (-0.95%)
On Wed, 2017-01-11 at 13:19 +, Emil Velikov wrote:
> On 30 November 2016 at 20:23, Emil Velikov
> wrote:
> > Hi all,
> >
> > With holidays not far off, it might be a nice idea to consider the
> > branchpoint/release schedule for the next release.
> >
> > I will be
I would rather not... Those asserts exist precisely to prevent someone
from doing a blorp copy with HiZ enabled when it's not actually supported.
The right thing to do is to set aux_usage to ISL_AUX_USAGE_NONE if you want
blorp to ignore aux.
On Wed, Jan 11, 2017 at 5:54 PM, Nanley Chery
On Wed, Jan 11, 2017 at 5:54 PM, Nanley Chery wrote:
> The helper doesn't provide additional functionality over the current
> infrastructure.
>
Actually... It does. The point of anv_image::aux_usage is to say how the
aux surface is supposed to be used outside of a render
On Wednesday, January 11, 2017 6:32:34 PM PST Jason Ekstrand wrote:
> Once again, SPIR-V is insane... It allows you to place "patch"
> decorations on structure members. Presumably, this is so that you can
> do something such as
>
> out struct S {
>layout(location = 0) patch vec4 thing1;
>
Once again, SPIR-V is insane... It allows you to place "patch"
decorations on structure members. Presumably, this is so that you can
do something such as
out struct S {
layout(location = 0) patch vec4 thing1;
layout(location = 0) vec4 thing2;
} str;
And have your I/O "nicely" organized.
On Wed, Jan 11, 2017 at 05:54:46PM -0800, Nanley Chery wrote:
> In my testing, this series completely removes HiZ resolves for the
> following Vulkan applications: Dota 2, Talos Principle, and the Sascha
> Willems Vulkan examples and demos. This is accomplished with two major
> changes. The first
Signed-off-by: Nanley Chery
---
src/intel/vulkan/TODO| 1 -
src/intel/vulkan/anv_image.c | 19 ---
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/intel/vulkan/TODO b/src/intel/vulkan/TODO
index 37fd16b437..38acc0dd5b 100644
Signed-off-by: Nanley Chery
---
src/intel/vulkan/genX_cmd_buffer.c | 54 +-
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_private.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/intel/vulkan/anv_private.h b/src/intel/vulkan/anv_private.h
index 98692b5913..fc7b6d1ec8 100644
--- a/src/intel/vulkan/anv_private.h
+++
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_pass.c| 3 +++
src/intel/vulkan/anv_private.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/intel/vulkan/anv_pass.c b/src/intel/vulkan/anv_pass.c
index ea86fa9ff2..5df6330c6a 100644
---
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_image.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index f8a21c2982..7d5beeabbe 100644
--- a/src/intel/vulkan/anv_image.c
+++
Signed-off-by: Nanley Chery
---
src/intel/isl/isl_surface_state.c | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/src/intel/isl/isl_surface_state.c
b/src/intel/isl/isl_surface_state.c
index
Add an entry point for the optimized gen8 BLORP HiZ sequence. commit
c9eaf12de20ac4143fe79d42018bdbb5a391356f fixed a bug that was
unknowingly worked around by forcing additional clear rectangle
alignment restrictions not specified in the PRMs. Now that the bug is no
longer present, omit the
Avoid the resolves that would be required if fast depth clears were
allowed for such buffers.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_blorp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/intel/vulkan/anv_blorp.c
This is a better mapping to the Vulkan API and improves performance in
all tested workloads.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_blorp.c | 48 ++---
src/intel/vulkan/genX_cmd_buffer.c | 54
Add an entry point for resolving using BLORP's gen8 HiZ op function.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_blorp.c | 74 ++
src/intel/vulkan/anv_private.h | 5 +++
2 files changed, 79 insertions(+)
diff --git
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_blorp.c | 9 +++--
src/intel/vulkan/anv_private.h | 15 +++
src/intel/vulkan/genX_cmd_buffer.c | 5 +
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git
Signed-off-by: Nanley Chery
---
src/intel/vulkan/genX_cmd_buffer.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 63f6be12a8..74369f6ba1
This is no longer used.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_genX.h| 3 -
src/intel/vulkan/gen7_cmd_buffer.c | 7 --
src/intel/vulkan/gen8_cmd_buffer.c | 223 -
3 files changed, 233 deletions(-)
diff
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_image.c | 17 +
src/intel/vulkan/genX_cmd_buffer.c | 10 --
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
Store the current and requested depth stencil layouts so that we can
perform the appropriate HiZ resolves for a given transition while
recording a render pass.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_pass.c| 5 +
src/intel/vulkan/anv_private.h
Signed-off-by: Nanley Chery
---
src/intel/vulkan/genX_cmd_buffer.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
index 74369f6ba1..fff9bd37c0 100644
We'll be switching to layout-transition based resolves which can occur
outside of a render pass. Add this sequence to BLORP, as using BLORP
will enable emitting depth stencil state outside of a render pass (among
other benefits). The depth buffer extent is ignored to enable eventual
usage of
We'll be using layout transitions later on in the series which can occur
within and between subpasses. Turn this on now to simplify the change
later.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/TODO | 2 +-
src/intel/vulkan/gen8_cmd_buffer.c | 11
We're about to enable HiZ support for multiple subpasses. Use this field
to keep track of whether or not subpass operations should treat the
depth buffer as having an auxiliary HiZ buffer.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/genX_cmd_buffer.c | 6 --
1
Prevent assert failures that would occur in the next patch. BLORP
ignores this flag internally, so no protections are lost here.
Signed-off-by: Nanley Chery
---
src/intel/blorp/blorp_blit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
The helper doesn't provide additional functionality over the current
infrastructure.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_blorp.c | 2 +-
src/intel/vulkan/anv_image.c | 10 --
src/intel/vulkan/anv_private.h | 10 --
In my testing, this series completely removes HiZ resolves for the
following Vulkan applications: Dota 2, Talos Principle, and the Sascha
Willems Vulkan examples and demos. This is accomplished with two major
changes. The first change is to transition the current HiZ resolving
algorithm from
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_blorp.c | 54 +++---
src/intel/vulkan/genX_cmd_buffer.c | 1 -
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c
Reviewed-by: Jason Ekstrand
On Wed, Jan 11, 2017 at 5:25 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> On Wed, 2017-01-11 at 16:09 -0800, Kenneth Graunke wrote:
> > When multiple shader stages exist in the same SPIR-V module, we
> > compile
> > all entry
On Wed, 2017-01-11 at 16:09 -0800, Kenneth Graunke wrote:
> When multiple shader stages exist in the same SPIR-V module, we
> compile
> all entry points and their inputs/outputs, then dead code eliminate
> the
> ones not related to the specific entry point later.
>
> nir_lower_wpos_center was
Reviewed-by: Bruce Cherniak
> On Jan 11, 2017, at 5:19 PM, George Kyriazis
> wrote:
>
> Defer delete on regular resources. This ensures that any work being done
> on the resource is completed before freeing up the resource's memory.
> ---
On Thu, Jan 12, 2017 at 12:33 AM, Ilia Mirkin wrote:
> On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger
> wrote:
>> Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>>>
>>>
>>> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
I don't think
On 2017-01-11 09:53:15, Juan A. Suarez Romero wrote:
> ---
> docs/envvars.html | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/docs/envvars.html b/docs/envvars.html
> index 9eee8db..4f05d7f 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -187,6 +187,7 @@ See the Xlib
Hi,
I'm sending a patch to support recent changes in radeonsi and amd/common,
in order to fix android building errors due to files moved to amd/common.
The patch has been implemented as a merge of the two ports,
in order to fully test the build.
Please consider that patches to fix
When multiple shader stages exist in the same SPIR-V module, we compile
all entry points and their inputs/outputs, then dead code eliminate the
ones not related to the specific entry point later.
nir_lower_wpos_center was being run prior to eliminating those random
other variables, which made it
b838f642 "ac/debug: Move sid_tables.h generation to common code." moved
sid_tables.h but forgot the corresponding .gitignore.
Signed-off-by: Grazvydas Ignotas
---
no commit access
src/amd/common/.gitignore | 1 +
src/gallium/drivers/radeonsi/.gitignore | 1 -
2
On Wed, Jan 11, 2017 at 4:00 PM, Roland Scheidegger wrote:
> Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>>
>>
>> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
>>> I don't think there's any glsl, es or otherwise, specification which
>>> would require denorms (since
On 05.01.2017 23:29, Kyle Brenneman wrote:
> ---
> src/egl/generate/eglFunctionList.py | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/egl/generate/eglFunctionList.py
> b/src/egl/generate/eglFunctionList.py
> index b19b5f7..80cb834 100644
> ---
Defer delete on regular resources. This ensures that any work being done
on the resource is completed before freeing up the resource's memory.
---
src/gallium/drivers/swr/swr_screen.cpp | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git
Hey Everyone,
I started a small project called gputool to help me debug issues on AMD
platforms. I think it may be useful to other driver devs, so I've made
it available on github:
https://github.com/lostgoat/gputool
Mainly I wanted something that could read and decode registers, so that
On Wed, Jan 11, 2017 at 2:00 PM, Alejandro Piñeiro wrote:
> Before 4.5, GL_BACK was not allowed as a value of bufs. Since 4.5 it
> is allowed under some circunstances:
>
> From the OpenGL 4.5 specification, Section 17.4.1 "Selecting Buffers
> for Writing", page 493 (page 515
On Wed, Jan 11, 2017 at 2:18 PM, Jordan Justen
wrote:
> On 2017-01-11 12:31:28, Kenneth Graunke wrote:
> > On Wednesday, January 11, 2017 10:48:53 AM PST Jason Ekstrand wrote:
> > > On Wed, Jan 11, 2017 at 10:34 AM, Jordan Justen <
> jordan.l.jus...@intel.com>
> > >
On 2017-01-11 12:31:28, Kenneth Graunke wrote:
> On Wednesday, January 11, 2017 10:48:53 AM PST Jason Ekstrand wrote:
> > On Wed, Jan 11, 2017 at 10:34 AM, Jordan Justen
> > wrote:
> >
> > > On 2017-01-11 09:53:15, Juan A. Suarez Romero wrote:
> > > >
Before 4.5, GL_BACK was not allowed as a value of bufs. Since 4.5 it
is allowed under some circunstances:
From the OpenGL 4.5 specification, Section 17.4.1 "Selecting Buffers
for Writing", page 493 (page 515 of the PDF):
"An INVALID_ENUM error is generated if any value in bufs is FRONT ,
LEFT
From OpenGL 3.1 spec, section 4.3.1 "Reading Pixels", page 190 (203 PDF)
"When READ FRAMEBUFFER BINDING is zero, i.e. the default
framebuffer, src must be one of the values listed in table 4.4,
including NONE . FRONT_AND_BACK , FRONT , and LEFT refer to the
front left buffer."
There
Before 4.5, GL_BACK was not allowed as a value of bufs. Since 4.5 it
is allowed under some circunstances:
From the OpenGL 4.5 specification, Section 17.4.1 "Selecting Buffers
for Writing", page 493 (page 515 of the PDF):
"An INVALID_ENUM error is generated if any value in bufs is FRONT ,
LEFT
Am 11.01.2017 um 21:08 schrieb Samuel Pitoiset:
>
>
> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
>> I don't think there's any glsl, es or otherwise, specification which
>> would require denorms (since obviously lots of hw can't do it, d3d10
>> forbids them), with any precision qualifier.
On Wed, 2017-01-11 at 12:54 +, Lionel Landwerlin wrote:
> On 09/01/17 05:13, Timothy Arceri wrote:
> > ---
> > src/compiler/glsl/linker.cpp | 35 +++--
> > --
> > src/mesa/main/mtypes.h | 10 --
> > src/mesa/main/shaderapi.c| 6 ++
> >
On Tue, Jan 10, 2017 at 2:46 AM, Daniel Stone wrote:
> Hi,
>
> On 10 January 2017 at 05:49, Ben Widawsky
> wrote:
> > On 17-01-09 11:56:04, Jason Ekstrand wrote:
> >> Do we need to do any error checking here? Do we need to check for the
> >>
On Wed, Jan 11, 2017 at 1:12 PM, Erik Faye-Lund wrote:
> On Wed, Jan 11, 2017 at 9:49 PM, Erik Faye-Lund
> wrote:
> > On Wed, Jan 11, 2017 at 9:42 PM, Erik Faye-Lund
> wrote:
> >> On Wed, Jan 11, 2017 at 9:22 PM, Samuel Pitoiset
>
On Wed, Jan 11, 2017 at 9:49 PM, Erik Faye-Lund wrote:
> On Wed, Jan 11, 2017 at 9:42 PM, Erik Faye-Lund wrote:
>> On Wed, Jan 11, 2017 at 9:22 PM, Samuel Pitoiset
>> wrote:
>>>
>>>
>>> On 01/11/2017 07:34 PM, Erik Faye-Lund
On Wed, Jan 11, 2017 at 12:08 PM, Samuel Pitoiset wrote:
>
>
> On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
>
>> I don't think there's any glsl, es or otherwise, specification which
>> would require denorms (since obviously lots of hw can't do it, d3d10
>>
On Wed, Jan 11, 2017 at 12:49 PM, Jason Ekstrand
wrote:
> I just sent three squash-in patches that I think improve this pass a bit
> and make things more clear. With those (or a good reason why not),
>
FYI, they've already been run through Jenkins. :-)
> Reviewed-by:
On Wed, Jan 11, 2017 at 9:42 PM, Erik Faye-Lund wrote:
> On Wed, Jan 11, 2017 at 9:22 PM, Samuel Pitoiset
> wrote:
>>
>>
>> On 01/11/2017 07:34 PM, Erik Faye-Lund wrote:
>>>
>>> On Wed, Jan 11, 2017 at 7:33 PM, Jason Ekstrand
I just sent three squash-in patches that I think improve this pass a bit
and make things more clear. With those (or a good reason why not),
Reviewed-by: Jason Ekstrand
On Tue, Jan 10, 2017 at 1:41 AM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> From: Kenneth
---
src/compiler/nir/nir_opt_move_comparisons.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/compiler/nir/nir_opt_move_comparisons.c
b/src/compiler/nir/nir_opt_move_comparisons.c
index 2bfd940..617c2ca 100644
---
---
src/compiler/nir/nir_opt_move_comparisons.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/src/compiler/nir/nir_opt_move_comparisons.c
b/src/compiler/nir/nir_opt_move_comparisons.c
index 535009b..2bfd940 100644
---
---
src/compiler/nir/nir_opt_move_comparisons.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/compiler/nir/nir_opt_move_comparisons.c
b/src/compiler/nir/nir_opt_move_comparisons.c
index 651b937..535009b 100644
---
On Tue, Jan 10, 2017 at 1:41 AM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> If we just check that we are not dealing with an identity swizzle
> in match_value() before calling match_expression() we can avoid
> a bunch of temp swizzle arrays and the passing it around and
> resetting
On Wed, Jan 11, 2017 at 9:22 PM, Samuel Pitoiset
wrote:
>
>
> On 01/11/2017 07:34 PM, Erik Faye-Lund wrote:
>>
>> On Wed, Jan 11, 2017 at 7:33 PM, Jason Ekstrand
>> wrote:
>>>
>>> On Wed, Jan 11, 2017 at 10:31 AM, Erik Faye-Lund
On Wednesday, January 11, 2017 10:48:53 AM PST Jason Ekstrand wrote:
> On Wed, Jan 11, 2017 at 10:34 AM, Jordan Justen
> wrote:
>
> > On 2017-01-11 09:53:15, Juan A. Suarez Romero wrote:
> > > ---
> > > docs/envvars.html | 1 +
> > > 1 file changed, 1 insertion(+)
> >
On Wed, Jan 11, 2017 at 1:45 AM, Grazvydas Ignotas wrote:
> Unfortunately this one breaks at least (surprise!) texturecubemap
> SaschaWillemsVulkan demo.
> I recommend you try it yourself, there are even precompiled binaries
> available (see README.md):
>
These two patches provide a slightly different approach to what Tim did. I
think Tim's is fine but I also like the idea of conditions working based on
SSA def, type, and read mask so I consider this a unification/cleanup
rather than a counter-proposal. Thoughts?
On Wed, Jan 11, 2017 at 11:13
This patch appears to cause regressions on Haswell. I'm not sure why. The
fact that it's only haswell strikes me as a bit odd so it's possible it's
not your patch's fault. I'm looking into it.
On Tue, Jan 10, 2017 at 1:41 AM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> If we just
On 01/11/2017 07:34 PM, Erik Faye-Lund wrote:
On Wed, Jan 11, 2017 at 7:33 PM, Jason Ekstrand wrote:
On Wed, Jan 11, 2017 at 10:31 AM, Erik Faye-Lund
wrote:
On Wed, Jan 11, 2017 at 7:22 PM, Marek Olšák wrote:
On Wed, Jan 11,
On 01/11/2017 07:33 PM, Jason Ekstrand wrote:
One trivial request: If we do land this patch, please include a link
the the mailing list archives in the commit message so that we can
easily track down this discussion if we ever need to in the future.
Sure, I was planning to do it. :-)
But
On 01/11/2017 07:00 PM, Roland Scheidegger wrote:
I don't think there's any glsl, es or otherwise, specification which
would require denorms (since obviously lots of hw can't do it, d3d10
forbids them), with any precision qualifier. Hence these look like bugs
of the test suite to me?
On 01/11/2017 07:49 PM, Marek Olšák wrote:
I've realized there is a small problem with this. MAD never supports
denorms, but MUL+ADD do. That can cause issues, because the compiler
assumes that MAD = MUL+ADD.
We need to use MAD for good performance, which means we should
probably never enable
On 01/11/2017 07:18 PM, Ilia Mirkin wrote:
So, I don't know whether this affects more than compute shaders
without reading the code, but I explicitly had to enable denorm
flushing on nvc0 in order to fix some sad artifacts in Unigine Heaven.
Right now nouveau only does denorm flushes on
On 01/11/2017 07:09 PM, Marek Olšák wrote:
Reviewed-by: Marek Olšák
Would you please run a GPU-bound benchmark of your choice to make sure
it doesn't affect performance?
I tried Furmark and Pixmark Piano on my rx 480. With 3 runs before and
after that change, the
This patch and 5-9 are
Reviewed-by: Jason Ekstrand
If others think the "unified" approach is nicer, I'll rebase on top and we
shouldn't need any nir_opt_algebraic.py changes since the syntax won't
change.
On Tue, Jan 10, 2017 at 1:41 AM, Timothy Arceri <
Reviewed-by: Jason Ekstrand
Please CC stable.
On Tue, Jan 10, 2017 at 8:13 PM, Timothy Arceri <
timothy.arc...@collabora.com> wrote:
> Currently its dependant on the user calling and checking the result
> of list_empty() before using the result of list_is_singular().
>
On Wed, Jan 11, 2017 at 2:33 PM, Marek Olšák wrote:
> On Wed, Jan 11, 2017 at 7:34 PM, Erik Faye-Lund wrote:
>> On Wed, Jan 11, 2017 at 7:33 PM, Jason Ekstrand wrote:
>>> On Wed, Jan 11, 2017 at 10:31 AM, Erik Faye-Lund
On 10/01/17 15:54, Emil Velikov wrote:
On 6 January 2017 at 17:35, Wu Zhen wrote:
From: WuZhen
since (cf410574 gallivm: Make MCJIT a runtime optioni.), llvmpipe assume
MCJIT is available on x86(_64). this is not the case for android prior to M.
Wu
On Wed, Jan 11, 2017 at 7:34 PM, Erik Faye-Lund wrote:
> On Wed, Jan 11, 2017 at 7:33 PM, Jason Ekstrand wrote:
>> On Wed, Jan 11, 2017 at 10:31 AM, Erik Faye-Lund
>> wrote:
>>>
>>> On Wed, Jan 11, 2017 at 7:22 PM, Marek Olšák
On 2017-01-11 12:50 AM, Michel Dänzer wrote:
On 10/01/17 09:07 PM, Andy Furniss wrote:
Andy Furniss wrote:
Though recent testing shows this is not true with DAL/DC on 3.7 -
todo test DC on new drm-next branch.
todo done, DC for some reason on both amd-staging-4.7 and
amd-staging-drm-next is
Instead of passing all of the ALU op information, we just pass what you
need: The SSA def, the type it's being read as, and a component mask.
---
src/compiler/nir/nir_search.c | 12 +--
src/compiler/nir/nir_search.h | 3 +-
src/compiler/nir/nir_search_helpers.h | 62
---
src/compiler/nir/nir_algebraic.py | 10 +++---
src/compiler/nir/nir_search.c | 28 +---
src/compiler/nir/nir_search.h | 18 +-
3 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/src/compiler/nir/nir_algebraic.py
I've realized there is a small problem with this. MAD never supports
denorms, but MUL+ADD do. That can cause issues, because the compiler
assumes that MAD = MUL+ADD.
We need to use MAD for good performance, which means we should
probably never enable FP32 denorms.
Marek
On Wed, Jan 11, 2017 at
On Wed, Jan 11, 2017 at 10:34 AM, Jordan Justen
wrote:
> On 2017-01-11 09:53:15, Juan A. Suarez Romero wrote:
> > ---
> > docs/envvars.html | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/docs/envvars.html b/docs/envvars.html
> > index 9eee8db..4f05d7f
On Wed, Jan 11, 2017 at 7:33 PM, Jason Ekstrand wrote:
> On Wed, Jan 11, 2017 at 10:31 AM, Erik Faye-Lund
> wrote:
>>
>> On Wed, Jan 11, 2017 at 7:22 PM, Marek Olšák wrote:
>> > On Wed, Jan 11, 2017 at 7:09 PM, Jason Ekstrand
On 2017-01-11 09:53:15, Juan A. Suarez Romero wrote:
> ---
> docs/envvars.html | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/docs/envvars.html b/docs/envvars.html
> index 9eee8db..4f05d7f 100644
> --- a/docs/envvars.html
> +++ b/docs/envvars.html
> @@ -187,6 +187,7 @@ See the Xlib
One trivial request: If we do land this patch, please include a link the
the mailing list archives in the commit message so that we can easily track
down this discussion if we ever need to in the future.
On Fri, Jan 6, 2017 at 1:42 AM, Samuel Pitoiset
wrote:
> D3D
1 - 100 of 178 matches
Mail list logo