Gently pinging if someone could do a quick review.
Thanks in advance!
J.A.
On Thu, 2016-11-24 at 13:36 +0100, Juan A. Suarez Romero wrote:
> Fixes a warning.
> ---
> src/gallium/auxiliary/nir/tgsi_to_nir.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src
On Fri, 2016-07-29 at 12:59 -0700, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> >
> > From: "Juan A. Suarez Romero"
> >
> > Our current data flow analysis does not take into account that
> > channels
> > on 64-bit operands are
On Mon, 2019-01-07 at 19:04 +0200, Andres Gomez wrote:
> As suggested by Emil Velikov.
>
> Cc: Dylan Baker
> Cc: Juan A. Suarez
> Cc: Emil Velikov
> Signed-off-by: Andres Gomez
> ---
> docs/release-calendar.html | 10 ++
> docs/releasing.html| 1
On Fri, 2019-01-11 at 16:42 +0200, Andres Gomez wrote:
> "--summary" will also print extended header information such as
> creations, renames and mode changes.
>
> Let's just use "-s", which suppresses the diff output.
Reviewed-by: Juan A. Suarez
J
On Fri, 2019-01-11 at 16:43 +0200, Andres Gomez wrote:
> "&>" is bash specific.
>
Reviewed-by: Juan A. Suarez
J.A.
> Fixes: e0dbfc99537 ("bin/get-pick-list.sh: warn when commit lists invalid
> sha")
> Cc: Juan A. Suarez
> Cc: Eric Eng
On Tue, 2019-01-15 at 07:21 -0500, Rob Clark wrote:
> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli wrote:
> >
> >
> > On 1/14/19 2:36 PM, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Fri, 11 Jan 2019 at 17:05, Jason Ekstrand wrote:
> > > > 5. There's no way with gitlab for Reviewed-by tags t
When stitching two blocks A and B, where A's last instruction is a jump,
it is not required that B is empty; it can be plainly removed.
This can happen in a situation like this:
vec1 1 ssa_1 = load_const (true)
vec1 1 ssa_2 = load_const (false)
block block_1:
[...]
loop {
vec1 ssa_3 = phi block
On Fri, 2019-01-25 at 13:26 -0800, Eric Anholt wrote:
> Rob Clark writes:
>
> > I guess as discovered with
> > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/47 maybe we
> > should wait to turn on merging MRs via web until we have at least some
> > basic build-test CI wired up.. the down
This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.
CC: Jason Ekstrand
---
src/intel/vulkan/gen7_cmd_buffer.c | 13 +++--
1 file changed, 11 inser
On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> > was created inheriting from the primary buffer, but with the framebuffer
>
On Mon, 2019-02-04 at 10:01 -0600, Jason Ekstrand wrote:
> On Mon, Feb 4, 2019 at 3:02 AM Juan A. Suarez Romero
> wrote:
> > On Fri, 2019-02-01 at 15:33 -0600, Jason Ekstrand wrote:
> >
> > > On Fri, Feb 1, 2019 at 10:14 AM Juan A. Suarez Romero
> > > wrot
This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.
Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) that all renderin
On Sat, 2019-01-26 at 08:37 -0800, Jason Ekstrand wrote:
> This makes me a bit nervous. I'll have to look at it in more detail.
>
Did you have time to take a look at this?
J.A.
> On January 25, 2019 09:37:52 "Juan A. Suarez Romero"
> wrote:
>
> &g
On Fri, 2019-02-08 at 10:29 -0800, Ian Romanick wrote:
> On 2/8/19 5:21 AM, Juan A. Suarez Romero wrote:
> > On Sat, 2019-01-26 at 08:37 -0800, Jason Ekstrand wrote:
> > > This makes me a bit nervous. I'll have to look at it in more detail.
> > >
> >
> &
On Fri, 2019-02-08 at 15:47 -0600, Jason Ekstrand wrote:
> On Fri, Feb 8, 2019 at 7:15 AM Juan A. Suarez Romero
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> >
> > was created inheriting from the primary buffer, but with the fra
This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.
Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) that all renderin
moved to a
different place.
J.A.
> --Jason
>
>
> On Fri, Jan 25, 2019 at 11:37 AM Juan A. Suarez Romero
> wrote:
> > When stitching two blocks A and B, where A's last instruction is a jump,
> >
> > it is not required that B is empty; it can
opt_split_alu_of_phi moves ALU instruction to the end of continue block.
But if the continue block ends with a jump instruction (an explicit
"continue" instruction) then the ALU must be inserted before the jump,
as it is illegal to add instructions after the jump.
CC: Ian Romanick
Fixes: 0881e90
this situation and just get rid
of the jump instruction in the continue block, before the stitching. After all,
after the merge it won't never be called.
I'm sending a new patch for this.
J.A.
> --Jason
>
>
> On Fri, Jan 25, 2019 at 11:37 AM Juan A. Suarez Romer
In opt_peel_initial_if optimization, when moving the continue list to
end of the continue block, before the jump, could happen that the
continue list itself also ends with a jump.
This would mean that we would have two jump instructions in a row: the
first one from the continue list and the second
This can happen when we record a VkCmdDraw in a secondary buffer that
was created inheriting from the primary buffer, but with the framebuffer
set to NULL in the VkCommandBufferInheritanceInfo.
Vulkan 1.1.81 spec says that "the application must ensure (using scissor
if neccesary) that all renderin
On Tue, 2019-02-12 at 11:31 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 10:48 AM Juan A. Suarez Romero
> wrote:
> > This can happen when we record a VkCmdDraw in a secondary buffer that
> >
> > was created inheriting from the primary buffer, but with the fra
On Tue, 2019-02-12 at 09:38 -0800, Caio Marcelo de Oliveira Filho wrote:
> Hi Juan,
>
> On Tue, Feb 12, 2019 at 04:37:23PM +0100, Juan A. Suarez Romero wrote:
> > On Fri, 2019-02-08 at 15:39 -0600, Jason Ekstrand wrote:
> > > I had a chat with Caio about this and I'm
On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote:
> > opt_split_alu_of_phi moves ALU instruction to the end of continue block.
> >
> > But if the continue block ends with a jump instruction (an explicit
> > "
On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > On 2/12/19 12:58 AM, Juan A. Suarez Romero wrote:
> > > > opt_split_alu_of_phi moves ALU inst
On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote:
> On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote:
> > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > > > On Tue, 2019-02-12 at 16:22 -0800, Ian
On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.
On the other side, in the Vulkan CTS tests, if the r
On one side, when emitting 3DSTATE_SF, VertexSubPixelPrecisionSelect is
used to select between 8 bit subpixel precision (value 0) or 4 bit
subpixel precision (value 1). As this value is not set, means it is
taking the value 0, so 8 bit are used.
On the other side, in the Vulkan CTS tests, if the r
::VertexSubPixelPrecisionSelect (Jason)
v3: use _8Bit definition as value (Jason)
CC: Jason Ekstrand
CC: Kenneth Graunke
Signed-off-by: Juan A. Suarez Romero
---
src/intel/vulkan/anv_device.c| 2 +-
src/intel/vulkan/genX_pipeline.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel
Fill out "Vertex Sub Pixel Precision Select" possible values.
Signed-off-by: Juan A. Suarez Romero
---
src/intel/genxml/gen10.xml | 5 -
src/intel/genxml/gen11.xml | 5 -
src/intel/genxml/gen7.xml | 5 -
src/intel/genxml/gen75.xml | 5 -
src/intel/genxml/gen
On Fri, 2019-02-22 at 10:04 -0600, Jason Ekstrand wrote:
> On Fri, Feb 22, 2019 at 9:58 AM Jason Ekstrand wrote:
> > On Fri, Feb 22, 2019 at 9:57 AM Lionel Landwerlin
> > wrote:
> > > On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
> > >
> > &g
When emitting a branch in a block, it does not make sense to continue
processing further instructions, as they will not be reachable.
This fixes a nasty case with a loop with a branch that both then-part
and else-part exits the loop:
%1 = OpLabel
OpLoopMerge %2 %3 None
OpBranchCondition
This fixes the case when the SPIR-V code has two nested conditional
branches, but only one selection merge:
[...]
%1 = OpLabel
OpSelectionMerge %2 None
OpBranchConditional %3 %4 %2
%4 = OpLabel
OpBranchConditional %3 %5 %2
%5 = OpLabel
OpBranch %2
%2 = OpLabel
[...]
In the sec
the rules, as both conditionals branches to the construct's merge
block.
J.A.
>
> --Jason
>
>
> On March 6, 2019 05:25:26 "Juan A. Suarez Romero" wrote:
>
> > This fixes the case when the SPIR-V code has two nested conditional
> > bra
As stated in Vulkan spec:
"Resetting a descriptor pool recycles all of the resources from all
of the descriptor sets allocated from the descriptor pool back to
the descriptor pool, and the descriptor sets are implicitly freed."
This fixes dEQP-VK.api.descriptor_pool.*
Fixes: 14f6275c92
On Fri, 2019-03-08 at 13:29 -0600, Jason Ekstrand wrote:
> On Fri, Mar 8, 2019 at 9:30 AM Juan A. Suarez Romero
> wrote:
> > On Thu, 2019-03-07 at 07:15 -0600, Jason Ekstrand wrote:
> >
> > > Woah, is this legal SPIR-V? I think a second OpSelectionMerge is required.
Hello.
I'm working on providing piglit with tests for the
GL_ARB_gpu_shader_fp64 extension[1].
One of the modifications it does is referring uniform variables:
"Modify Section 2.14.4, Uniform Variables, p. 89
(modify third paragraph, p. 90) ... uniform variable storage for vertex
shader. A un
On Mon, 2016-02-22 at 13:47 +0200, Tapani Pälli wrote:
> Maybe one way would be to include these matrices in UBO or SSBO and
> then
> query BUFFER_DATA_SIZE for that buffer. That should return
> "implementation-dependent minimum total buffer object size".
>
> https://www.opengl.org/registry/spec
On Mon, 2016-02-22 at 14:13 +0200, Tapani Pälli wrote:
> > So rather than reporting the number of uniform components it is
> > consuming, is reporting the bytes used in the layout.
> >
>
> Ah right, I see. Maybe you can query OFFSET then, this should differ
> then when matrix has a different type
LOST: 0
GAINED: 0
v2: change vectorize_mov() signature (Matt).
v3: take in account predicates (Juan).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 62 ++
src/mesa/drivers/dri/i965/brw_vec4.h | 4 +++
2 files changed, 44
On Wed, 2016-03-02 at 13:21 +0100, Juan A. Suarez Romero wrote:
> opt_vector_float() transforms several scalar MOV operations to a
> single
> vectorial MOV.
>
I had sent this patch a couple of months ago, but seems I lost its
track. So I've rebased it, check it still gets some
---
docs/envvars.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/envvars.html b/docs/envvars.html
index 06aa0ac..e21b7c1 100644
--- a/docs/envvars.html
+++ b/docs/envvars.html
@@ -163,6 +163,7 @@ See the Xlib software driver
page for details.
blorp - emit messages about the blor
(like
iteration) make it easier to indentify for each file in which call it was
generated.
As example, in original master I get 138 files for FS/VS optimizations when
running a piglit test, while now I get 225, meaning I'm recovering 87 missing
steps.
Juan A. Suarez Romero (1):
i965: Do not
When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk,
in a separate file.
But as fs_visitor::optimize() and vec4_visitor::run() are called more
than once, it ends up overwriting the files already on disk, loosing
then previous optimizer steps.
To avoid this, add a new static var
On Wed, 2015-11-25 at 13:15 +0100, Juan A. Suarez Romero wrote:
> When using INTEL_DEBUG=optimizer, each optimizing step is dump to
> disk,
> in a separate file.
>
> But as fs_visitor::optimize() and vec4_visitor::run() are called more
> than once, it ends up overwriting the fil
variable that tracks the global
iteration across the entire life of the program running.
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
src/mesa/drivers/dri/i965/brw_vec4.cpp | 11 +++
2 files changed, 16 insertions(+), 8 deletions
instructions in shared programs: 6819828 -> 6819468 (-0.01%)
instructions in affected programs: 30516 -> 30156 (-1.18%)
total loops in shared programs:1971 -> 1971 (0.00%)
helped:154
HURT: 0
GAIN
GAINED: 0
LOST: 0
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/d
than once, that doesn't happen when we have a constant.
So this commit ensures CSE is not applied to MOV immediate (as it
provides no gain, and it is reverted later by copy-propagation
optimization).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_vec4_cse.cpp | 13 +
On Wed, 2015-11-25 at 16:16 -0800, Matt Turner wrote:
> I think in this case a better solution -- at least until we learn
> something more -- would be to initialize opt_vector_float()'s
> remaining_channels to only the live components of the register. Do
> you
> want to try that?
Sure! There's a
On Wed, 2015-11-25 at 11:05 -0800, Jason Ekstrand wrote:
> Right. I didn't pay that much attention to the exact implementation.
> But we could do something like.
>
> atomic int global_iteration_atomic = 0;
>
> const int global_iteration = atomic_inc(global_iteration_atomic);
>
> // use global_i
variable that tracks the global
iteration across the entire life of the program running.
v2: use atomic_inc() for the static variable (Jason).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 15 +++
src/mesa/drivers/dri/i965/brw_vec4.cpp | 13
On Wed, 2015-11-25 at 16:16 -0800, Matt Turner wrote:
> In the piglit test you cited, opt_vector_float() does this to the
> relevant code:
>
> cmp.nz.f0.0 null:F, vgrf6.xyzz:F, vgrf14.xyzz:F
> -mov vgrf2.0.x:D, 0D
> (+f0.0.any4h) mov vgrf2.0.x:D, -1D
> -mov vgrf2.0.yzw:D, 0D
> +mov vgrf2.0:F, [0
variable that tracks the global
iteration across the entire life of the program running.
v2: use atomic_inc() for the static variable (Jason).
v3: define local variable as const (Jason).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
src/mesa
variable that tracks the global
iteration across the entire life of the program running.
v2: use atomic_inc() for the static variable (Jason).
v3: define local variable as const (Jason).
v4: undo empty line removal (Jason).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965
On Wed, 2015-11-25 at 16:16 -0800, Matt Turner wrote:
> I had a look at a helped shader from shader-db (borderlands-2/3701)
>
> Its vec4 IR at the time we call opt_vector_float() contains:
>
> 0: mov vgrf2.0.x:D, 1073741824D
> 1: mov vgrf3.0.xy:D, 0D
> 2: mov vgrf3.0.w:D, 1065353216D
>
(-2.01%)
total loops in shared programs:1971 -> 1971 (0.00%)
helped:3980
HURT: 0
GAINED:3
LOST: 0
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers
letting it for a future improvement.
* I commented about a wrong application of opt_vector_float() in an example Matt
found. He told that probably it lacks resetting last_reg to -1. This patch is
covering that error.
Juan A. Suarez Romero (1):
i965: add opportunistic behaviour to opt_vector_fl
On Wed, 2015-12-02 at 16:43 +0100, Juan A. Suarez Romero wrote:
> This patch, based on Matt suggestion, replaces the former two ones,
> as it gets
> better results.
This patch replaces the ones sent in
http://lists.freedesktop.org/archives/mesa-dev/2015-November/101448.htm
l
entitled
On Thu, 2015-12-03 at 11:04 -0800, Matt Turner wrote:
> The GAINED: 3 is almost certainly because of a sporadic failure in
> shader-db (or Mesa...?) during the baseline shader-db run. When you
> ran shader-db with your patch applied, the same failure didn't occur,
> so report.py thinks this means 3
On Thu, 2015-12-03 at 11:04 -0800, Matt Turner wrote:
> > The improvement obtained regarding current upstream (56aff6bb4eaf)
> is:
> >
> > total instructions in shared programs: 6819484 -> 6811698 (-0.11%)
> > instructions in affected programs: 387245 -> 379459 (-2.01%)
> > total loops in share
igned-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 61 ++
src/mesa/drivers/dri/i965/brw_vec4.h | 4 +++
2 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers
On Mon, 2015-11-30 at 12:26 +0100, Juan A. Suarez Romero wrote:
> When using INTEL_DEBUG=optimizer, each optimizing step is dump to
> disk,
> in a separate file.
Any news on this? Can be considered as reviewed? Thanks in advance
On Thu, 2015-12-10 at 09:47 -0800, Matt Turner wrote:
> Assuming that the cause is indeed non-orthogonal state changes, yes.
> But I never saw an answer to that question.
>
> Reviewed-by: Matt Turner
After rebasing and testing against master (11.1-branchpoint-653-
g5c5ad4d) I can't reproduce th
the result it is always 0. Problem is that when applying the
optimization, it was ignoring the predicate.
The next patch updates the previous version to fix this problem.
*** BLURB HERE ***
Juan A. Suarez Romero (1):
i965: add opportunistic behaviour to opt_vector_float()
src/mesa/drivers/dri
: take in account predicates (Juan).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 62 ++
src/mesa/drivers/dri/i965/brw_vec4.h | 4 +++
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/i965
On Fri, 2017-04-28 at 14:14 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> In the early days of Xorg and Mesa we had multiple providers of the
> GLAPI. All of those were the ones responsible for dlopening the DRI
> module. Hence it was perfectly fine, and actually expected, for the DRI
> mod
On Tue, 2017-05-16 at 20:40 +0200, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This reverts commit 0e9991f957e296f46cfff40a94ffba0adf2a58e1.
>
> At least when we fallback because of TGSI, the gl_program objects are
> re-allocated, and we don't in fact already have a reference to the
> gl_sh
On Thu, 2017-06-01 at 10:09 +1000, Timothy Arceri wrote:
> On 01/06/17 07:30, Juan A. Suarez Romero wrote:
> > On Tue, 2017-05-16 at 20:40 +0200, Nicolai Hähnle wrote:
> > > From: Nicolai Hähnle
> > >
> > > This reverts commit 0e9991f957e296f46cfff40a94ffba0a
48bit support on gen >= 8
anv: Set up memory types and heaps during physical device init
anv: Set image memory types based on the type count
i965/blorp: Do and end-of-pipe sync on both sides of fast-clear ops
i965: Round copy size to the nearest block in intel_miptree_co
On Thu, 2017-06-01 at 16:35 -0700, Jason Ekstrand wrote:
> On Thu, Jun 1, 2017 at 4:20 PM, Juan A. Suarez Romero
> wrote:
> > Hello list,
> >
> >
> >
> > The candidate for the Mesa 17.1.2 is now available. Currently we have:
> >
> >
On Sat, 2017-06-03 at 11:10 -0700, Jason Ekstrand wrote:
> On Sat, Jun 3, 2017 at 10:05 AM, Juan A. Suarez Romero ia.com> wrote:
> > On Thu, 2017-06-01 at 16:35 -0700, Jason Ekstrand wrote:
> > > On Thu, Jun 1, 2017 at 4:20 PM, Juan A. Suarez Romero > > galia.com
e supports_48bit_addresses a heap property
anv: Refactor memory type setup
anv: Advertise both 32-bit and 48-bit heaps when we have enough memory
i965: Rework Sandy Bridge HiZ and stencil layouts
anv: Require vertex buffers to come from a 32-bit heap
Juan A. Suarez Romero (14):
There was a typo in the subject.
I meant mesa 17.1.2
BR,
J.A.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Juan A. Suarez Romero
On Thu, 2017-06-08 at 07:21 +, Vinson Lee wrote:
> Fix build error.
>
> CC i915_surface.lo
> i915_surface.c:108:63: error: too few arguments to function call, expected 4,
> have 3
>util_blitter_default_src_texture(&src
LLVMAddEarlyCSEMemSSAPass() is defined in LLVM 4.0.
Fixes: 257b538 ("radeonsi: do EarlyCSEMemSSA LLVM pass)
---
src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
b/src/gallium/drivers/rade
Otherwise, `make distcheck` will fail.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index 762aefc..e2d5992 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/me
Otherwise, `make distcheck` will fail.
---
src/gallium/drivers/r600/Makefile.am | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/Makefile.am
b/src/gallium/drivers/r600/Makefile.am
index 44fd51d..2b1ffb5 100644
--- a/src/gallium/drivers/r600/Makefile.am
+++ b/src/ga
According to GLSL.std.450 spec, the operand for step() function must be
a floating-point. It does not restrict the value to 32-bit floats.
---
src/compiler/nir/nir_opcodes.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_
(), NMax() and NClamp() SPIR-V
instructions.
Juan A. Suarez Romero (5):
nir: sge operation is defined for floating-point types
nir: add support for 64-bit in SmoothStep function
nir: implement GLSL.std.450 NMin operation
nir: implement GLSL.std.450 NMax operation
nir: implement GLSL.std.450
According to GLSL.std.450 spec, SmoothStep expects input to be a
floating-point type, but it does not restrict the bitsize.
Current implementation relies on inputs to be 32-bit.
This commit extends the support to 64-bit size inputs.
---
src/compiler/spirv/vtn_glsl450.c | 8 +---
1 file chang
---
src/compiler/spirv/vtn_glsl450.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 5e75c3c..ce80360 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -225,
---
src/compiler/spirv/vtn_glsl450.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 96e3407..5e75c3c 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -206,
---
src/compiler/spirv/vtn_glsl450.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index ce80360..cfff7a6 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -578,6 +578,10 @@ handle_g
.
I'll use them to implement NMax, NMin and NClamp.
J.A.
> On Mon, Jun 12, 2017 at 9:33 AM, Juan A. Suarez Romero
> wrote:
> > ---
> > src/compiler/spirv/vtn_glsl450.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> &
() and NClamp() SPIR-V
instructions, using NIR fmax and fmin opcodes. These NIR opcodes already handle
NaN as expected by the SPIR-v instructions.
Juan A. Suarez Romero (3):
nir: sge operation is defined for floating-point types
nir: add support for 64-bit in SmoothStep function
nir
According to GLSL.std.450 spec, the operand for step() function must be
a floating-point. It does not restrict the value to 32-bit floats.
Reviewed by: Elie Tournier
---
src/compiler/nir/nir_opcodes.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_opcod
According to GLSL.std.450 spec, SmoothStep expects input to be a
floating-point type, but it does not restrict the bitsize.
Current implementation relies on inputs to be 32-bit.
This commit extends the support to 64-bit size inputs.
Reviewed by: Elie Tournier
---
src/compiler/spirv/vtn_glsl450
v2: NIR fmax/fmin already handles NaN (Connor).
---
src/compiler/spirv/vtn_glsl450.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index 96e3407dee..1d7e2b8d95 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compi
On Wed, 2017-06-14 at 17:02 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> We tend to use the sources, as opposed to EXTRA_DIST to include the
> headers.
>
Reviewed-by: Juan A. Suarez Romero
> Cc: Juan A. Suarez Romero
> Signed-off-by: Emil Velikov
> ---
>
On Wed, 2017-10-18 at 23:23 -0700, Kenneth Graunke wrote:
> The restriction is supposed to apply if the width *field* is >= 8192,
> meaning the actual width *value* is >= 8193.
>
> The code also incorrectly used == for some reason.
Reviewed-by: Juan A. Suarez Romero
>
---
src/amd/vulkan/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/vulkan/Makefile.am b/src/amd/vulkan/Makefile.am
index 7364e54f61..6b352aebf9 100644
--- a/src/amd/vulkan/Makefile.am
+++ b/src/amd/vulkan/Makefile.am
@@ -132,6 +132,7 @@ EXTRA_DIST = \
dev_icd.json.i
This patch is mostly a patch done by Ilia Mirkin.
It fixes KHR-GL45.enhanced_layouts.varying_structure_locations.
CC: Ilia Mirkin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103098
Signed-off-by: Juan A. Suarez Romero
---
src/compiler/glsl/linker.cpp | 36
On Fri, 2017-10-27 at 10:27 -0400, Ilia Mirkin wrote:
> On Fri, Oct 27, 2017 at 10:03 AM, Juan A. Suarez Romero
> wrote:
> > This patch is mostly a patch done by Ilia Mirkin.
> >
> > It fixes KHR-GL45.enhanced_layouts.varying_structure_locations.
> >
> >
On Fri, 2017-10-27 at 11:09 -0400, Ilia Mirkin wrote:
> > > With the latter ones getting bogus locations? What is it supposed to
> > > do in this case?
> >
> > Why it would get bogus locations?
>
> Because it'll do elem_location += stride every time, but they each
> should get the same location.
This patch is mostly a patch done by Ilia Mirkin.
It fixes KHR-GL45.enhanced_layouts.varying_structure_locations.
v2: fix locations for TCS/TES/GS inputs and outputs (Ilia)
CC: Ilia Mirkin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103098
Signed-off-by: Juan A. Suarez Romero
Fixes:
make[2]: Leaving directory '/home/local/mesa/mesa-17.4.0-devel/_build/sub/src'
make[2]: *** No rule to make target '../../../src/git_sha1.h.in', needed by
'git_sha1.h'. Stop.
Makefile:660: recipe for target 'all-recursive' failed
Signed
Fixes: f1e1c60ff6 ("etnaviv: Update from rnndb")
---
src/gallium/drivers/etnaviv/Makefile.sources | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/etnaviv/Makefile.sources
b/src/gallium/drivers/etnaviv/Makefile.sources
index ea8df807f66..aafcc380aa5 100644
--- a/src/gallium
v2: include the file also in the meson.build (Eric Engestrom).
Fixes: f1e1c60ff6 ("etnaviv: Update from rnndb")
---
src/gallium/drivers/etnaviv/Makefile.sources | 1 +
src/gallium/drivers/etnaviv/meson.build | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/gallium/drivers/etnaviv/Ma
On Tue, 2017-11-07 at 15:30 +, Eric Engestrom wrote:
> On Tuesday, 2017-11-07 16:18:55 +0100, Juan A. Suarez Romero wrote:
> > Fixes: f1e1c60ff6 ("etnaviv: Update from rnndb")
> > ---
> > src/gallium/drivers/etnaviv/Makefile.sources | 1 +
> > 1 file
101 - 200 of 903 matches
Mail list logo
