On Wed, 2016-01-27 at 12:29 -0800, Matt Turner wrote:
> On Wed, Jan 27, 2016 at 5:22 AM, Iago Toral wrote:
> > I think it would be a good idea to change the shortlog so it is clear
> > that we are only talking about the scalarization aspect. There is still
> > GLSL IR lowering for un/packHalf2x16
On Wednesday, January 27, 2016 5:18:29 PM PST Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> OK, ran piglit on all of this and noticed the issue with state == NULL in
> can_implicitly_convert_to. With that fixed, the only piglit regression is
>
> spec/arb_blend_func_extended/arb_blend
Reviewed-by: Tapani Pälli
On 01/27/2016 03:55 PM, Samuel Iglesias Gonsálvez wrote:
ARB_gpu_shader_fp64 spec says:
"This extension does not support interpolation of double-precision
values; doubles used as fragment shader inputs must be qualified as
"flat"."
Fixes the regressions adde
On 27.01.2016 23:54, Daniel Stone wrote:
> On 27 January 2016 at 14:16, Axel Davy wrote:
>> On 27/01/2016 13:43, Daniel Stone wrote:
>>> On 27 January 2016 at 09:34, Michel Dänzer
>>> wrote:
The compositor may have the hardware scan out directly from the
buffers sent by the client, so w
Topi, you are one of my favorite people. I love how you prove how circuitous and
difficult meta can be, without actually saying it explicitly.
On Wed, Jan 27, 2016 at 01:44:10PM +0200, Topi Pohjolainen wrote:
> Part of brw_try_draw_prims() is a check to validate textures
> (brw_validate_textures()
On 27.01.2016 19:38, Axel Davy wrote:
> There was this other version
> http://lists.freedesktop.org/archives/mesa-dev/2015-October/097917.html
Sorry, I totally forgot about that. With the bugzilla reference added,
your patch is
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer
On Wed, 2016-01-27 at 17:18 -0500, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
Surprising the CTS or deqp hasn't flushed this out already. I ran this
through Intels CI system and the only change in test results was the
bad piglit test.
Looks corrent to me.
Reviewed-by: Timothy Arceri
> --
On Wed, 2016-01-27 at 14:55 +0100, Samuel Iglesias Gonsálvez wrote:
> ARB_gpu_shader_fp64 spec says:
>
> "This extension does not support interpolation of double-precision
> values; doubles used as fragment shader inputs must be qualified as
> "flat"."
>
> Fixes the regressions added by com
Signed-off-by: Ilia Mirkin
---
OK, ran piglit on all of this and noticed the issue with state == NULL in
can_implicitly_convert_to. With that fixed, the only piglit regression is
spec/arb_blend_func_extended/arb_blend_func_extended-fbo-extended-blend-pattern_gles3:
pass fail
Which is precisely
On 25 July 2015 at 00:19, Jonny Lamb wrote:
> Here is an initial patchset implementing EGL_EXT_device_base (in
> practice nothing to do), device_enumeration (for listing devices), and
> device_query (for querying information about a device).
>
> I worked on this because I want to then move onto ad
On Wed, Jan 27, 2016 at 6:01 AM, Iago Toral wrote:
> On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
>> The uint versions zero extend while the int versions sign extend.
>> ---
>> src/glsl/nir/nir.h| 3 +++
>> src/glsl/nir/nir_opcodes.py | 9 +
>> src/glsl/ni
On Wed, Jan 27, 2016 at 5:22 AM, Iago Toral wrote:
> I think it would be a good idea to change the shortlog so it is clear
> that we are only talking about the scalarization aspect. There is still
> GLSL IR lowering for un/packHalf2x16 that remains in use after this
> patch, as made clear by the l
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Jan 27, 2016 at 5:34 AM, Iago Toral wrote:
> Eric said he would like to keep these opcodes so I guess we don't want
> to do this. In any case this is:
With the lowering done in NIR and no other consumers of the GLSL IR
opcodes, we can just remove the GLSL IR opcodes -- I don't think he
wa
Signed-off-by: Ilia Mirkin
---
Just discovered we were allowing these after a discussion with Ryan Houdek. No
clue how many piglits this will break though...
src/compiler/glsl/ast_to_hir.cpp | 4
src/compiler/glsl_types.cpp | 4
2 files changed, 8 insertions(+)
diff --git a/src
Signed-off-by: Ilia Mirkin
---
src/compiler/glsl/builtin_functions.cpp | 35 +
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/src/compiler/glsl/builtin_functions.cpp
b/src/compiler/glsl/builtin_functions.cpp
index 95e86df..5512a33 100644
--- a/src
https://bugs.freedesktop.org/show_bug.cgi?id=93820
--- Comment #4 from Ian Romanick ---
(In reply to Ilia Mirkin from comment #3)
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=d0da0e9c3
>
> Apparently Xorg 1.17 disables indirect GLX by default. Try starting the X
> server with +iglx.
Ug
On Wed, Jan 27, 2016 at 12:25 PM, Karol Herbst wrote:
> From: Karol Herbst
>
> helps shaders in saints row IV, bioshock infinite and shadow warrior
>
> total instructions in shared programs : 1921966 -> 1910935 (-0.57%)
> total gprs used in shared programs: 251863 -> 251728 (-0.05%)
> total l
Please make this work for all chips. I don't want to have these
partial optimizations in place. The reason it was OK for nv50 is that
I thought this only ever applied to nv50, didn't realize that (a) we
didn't have FFMA32I not hooked up and (b) that it had this
restriction. Also you'd want to drop
From: Karol Herbst
total instructions in shared programs : 1895008 -> 1894759 (-0.01%)
total gprs used in shared programs: 251728 -> 251715 (-0.01%)
total local used in shared programs : 5673 -> 5673 (0.00%)
total bytes used in shared programs : 17377840 -> 17375696 (-0.01%)
From: Karol Herbst
helps shaders in multiple games
total instructions in shared programs : 1910935 -> 1901781 (-0.48%)
total gprs used in shared programs: 251728 -> 251728 (0.00%)
total local used in shared programs : 5673 -> 5673 (0.00%)
total bytes used in shared programs : 17521824 ->
total instructions in shared programs : 1922112 -> 1921966 (-0.01%)
total gprs used in shared programs: 251863 -> 251863 (0.00%)
total local used in shared programs : 5673 -> 5673 (0.00%)
total bytes used in shared programs : 17624080 -> 17622728 (-0.01%)
localgpr
changes in my shader-db:
total instructions in shared programs : 1925865 -> 1894759 (-1.62%)
total gprs used in shared programs: 251863 -> 251715 (-0.06%)
total local used in shared programs : 5673 -> 5673 (0.00%)
total bytes used in shared programs : 17657840 -> 17375696 (-1.60%)
reduces calls up to 50%
Signed-off-by: Karol Herbst
Reviewed-by: Ilia Mirkin
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nou
From: Karol Herbst
helps shaders in multiple games
total instructions in shared programs : 1925865 -> 1922112 (-0.19%)
total gprs used in shared programs: 251863 -> 251863 (0.00%)
total local used in shared programs : 5673 -> 5673 (0.00%)
total bytes used in shared programs : 17657840 ->
From: Karol Herbst
helps shaders in saints row IV, bioshock infinite and shadow warrior
total instructions in shared programs : 1921966 -> 1910935 (-0.57%)
total gprs used in shared programs: 251863 -> 251728 (-0.05%)
total local used in shared programs : 5673 -> 5673 (0.00%)
total bytes u
https://bugs.freedesktop.org/show_bug.cgi?id=93820
Ilia Mirkin changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Hi,
On 27 January 2016 at 14:16, Axel Davy wrote:
> On 27/01/2016 13:43, Daniel Stone wrote:
>> On 27 January 2016 at 09:34, Michel Dänzer wrote:
>>> The compositor may have the hardware scan out directly from the buffers
>>> sent by the client, so we must make sure the buffers we create are
>>>
Hi,
On 27/01/2016 13:43, Daniel Stone wrote:
Hi,
On 27 January 2016 at 09:34, Michel Dänzer wrote:
The compositor may have the hardware scan out directly from the buffers
sent by the client, so we must make sure the buffers we create are
suitable for scanout.
If the compositor wants to scan
Reviewed-by: Iago Toral Quiroga
On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> The vec4 backend will lower it.
> ---
> src/mesa/drivers/dri/i965/brw_defines.h| 12
> src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 ++
> src/mesa/drivers/dri/i965/brw_fs_generator
https://bugs.freedesktop.org/show_bug.cgi?id=58446
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEEDINFO
On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> The uint versions zero extend while the int versions sign extend.
> ---
> src/glsl/nir/nir.h| 3 +++
> src/glsl/nir/nir_opcodes.py | 9 +
> src/glsl/nir/nir_opt_algebraic.py | 16
> 3 files cha
ARB_gpu_shader_fp64 spec says:
"This extension does not support interpolation of double-precision
values; doubles used as fragment shader inputs must be qualified as
"flat"."
Fixes the regressions added by commit 781d278:
arb_gpu_shader_fp64-double-gettransformfeedbackvarying
arb_gpu_shade
https://bugs.freedesktop.org/show_bug.cgi?id=20898
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Eric said he would like to keep these opcodes so I guess we don't want
to do this. In any case this is:
Reviewed-by: Iago Toral Quiroga
On Mon, 2016-01-25 at 15:18 -0800, Matt Turner wrote:
> i965/fs was the only consumer, and we're now doing the lowering in NIR.
> ---
> src/glsl/ir.cpp
I think it would be a good idea to change the shortlog so it is clear
that we are only talking about the scalarization aspect. There is still
GLSL IR lowering for un/packHalf2x16 that remains in use after this
patch, as made clear by the last hunk in this patch.
On Mon, 2016-01-25 at 15:18 -0800,
Hi,
On 27 January 2016 at 09:34, Michel Dänzer wrote:
> The compositor may have the hardware scan out directly from the buffers
> sent by the client, so we must make sure the buffers we create are
> suitable for scanout.
If the compositor wants to scan out directly, it will import via GBM,
which
https://bugs.freedesktop.org/show_bug.cgi?id=31587
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Part of brw_try_draw_prims() is a check to validate textures
(brw_validate_textures()). In case of textures that currently have
only level zero but are marked for mipmap generation, i965 driver
will decide to replace the underlying buffer with a larger one
capable of holding also the additional lev
There was this other version
http://lists.freedesktop.org/archives/mesa-dev/2015-October/097917.html
Reviewed-by: Axel Davy
On 27/01/2016 10:34, Michel Dänzer wrote:
From: Michel Dänzer
The compositor may have the hardware scan out directly from the buffers
sent by the client, so we must ma
On Wed, Jan 27, 2016 at 1:14 AM, Ilia Mirkin wrote:
> On Tue, Jan 26, 2016 at 7:05 PM, Marek Olšák wrote:
>> On Tue, Jan 26, 2016 at 9:48 PM, Ilia Mirkin wrote:
>>> On Tue, Jan 26, 2016 at 3:23 PM, Marek Olšák wrote:
On Tue, Jan 26, 2016 at 3:12 PM, Ilia Mirkin wrote:
> On Tue, Jan 26
https://bugs.freedesktop.org/show_bug.cgi?id=93878
Samuel Iglesias changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |sigles...@igalia.com
From: Michel Dänzer
The compositor may have the hardware scan out directly from the buffers
sent by the client, so we must make sure the buffers we create are
suitable for scanout.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93866
Cc: 11.0 11.1
Signed-off-by: Michel Dänzer
---
src/
On Tue, 2016-01-26 at 14:59 +1100, Timothy Arceri wrote:
> On Tue, 2016-01-19 at 07:20 +0100, Samuel Iglesias Gonsálvez wrote:
> > Commit 781d278 did not restrict consumer_stage only to separate
> > shader
> > objects, which is when we don't know if the consumer stage would be
> > a
> > fragment
44 matches
Mail list logo
