On Fri, May 3, 2019 at 6:52 AM Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez
>
> There are tests in CTS for alpha to coverage without a color attachment
> that are failing. This happens because when we remove the shader color
> outputs when we don't have a valid color attachment fo
.state_patterns)):
> >case ${i}:
> > - for (unsigned i = 0; i <
> ARRAY_SIZE(${pass_name}_state${i}_xforms); i++) {
>
I'd rather keep the ARRAY_SIZE unless we've got a really good reason to
drop it. With that and Dylan's changes,
Reviewed-by: Jas
Reviewed-by: Jason Ekstrand
On Thu, May 2, 2019 at 10:25 PM Dave Airlie wrote:
> From: Dave Airlie
>
> This has a couple of hardcoded vec4 limits in it, change them
> to the proper sizing to avoid future issues.
> ---
> src/compiler/nir/nir_lower_vars_to_ssa.c | 8
Drp...
Reviewed-by: Jason Ekstrand
On Thu, May 2, 2019 at 10:25 PM Dave Airlie wrote:
> From: Dave Airlie
>
> The spir-v spec says this returns a bool.
> ---
> src/compiler/spirv/vtn_alu.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --
On Thu, May 2, 2019 at 5:46 AM Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez
>
> There tests in CTS for for alpha to coverage without a color attachment.
> First the test draws a primitive with alpha 0 and a subpass with only
> a depth buffer. No writes to a depth buffer are expect
ng the current hole. The optimization can come later.
I'm not sure that we would actually need a bit. This would be an implicit
combination of the color_outputs_valid and dual-src blending which is
already part of the shader. That might need a big fat comment though. :)
--Jason
>
>
Reviewed-by: Jason Ekstrand
On Thu, Apr 25, 2019 at 9:50 PM Dave Airlie wrote:
> From: Dave Airlie
>
> This fixes a case where we are expecting 64-bit but generate
> 32-bit consts and validate gets angry.
>
> Signed-off-by: Dave Airlie
> ---
> src/compiler/nir/nir
On Thu, Apr 25, 2019 at 5:37 PM Alyssa Rosenzweig
wrote:
> In addition to the familiar iand/ior/ixor, some architectures feature
> destination-inverted versions inand/inor/inxor. Certain
> architectures also have source-inverted forms, dubbed iandnot/iornot
> here. Midgard has the all of these op
ACK
On Wed, Apr 24, 2019 at 8:15 AM Juan A. Suarez Romero
wrote:
> This reverts commit 40b3abb4d16af4cef0307e1b4904c2ec0924299e.
>
> It is not clear that this commit was entirely correct, and unfortunately
> it was pushed by error.
>
> CC: Jason Ekstrand
> ---
>
>
and someone that needs to debug their shader
> assemblies will have a reason to review.
>
> I can make a MR in gitlab if you think it would help.
>
That seems like a good way to hang on to it.
--Jason
> Jason Ekstrand writes:
>
> > Did this get dropped on the ground
Did this get dropped on the ground?
On Fri, Dec 7, 2018 at 12:07 PM Mark Janes wrote:
> Ilia Mirkin writes:
>
> > On Thu, Dec 6, 2018 at 7:36 PM Mark Janes
> wrote:
> >>
> >> This series provides Intel shader compilation debug information via
> >> KHR_debug. Previously, shader assembly and re
On Tue, Apr 23, 2019 at 7:39 PM Timothy Arceri
wrote:
> On 24/4/19 1:45 am, Samuel Pitoiset wrote:
> >
> > On 4/23/19 5:16 PM, Jason Ekstrand wrote:
> >> On Tue, Apr 23, 2019 at 7:46 AM Samuel Pitoiset
> >> mailto:samuel.pitoi...@gmail.com>> wrote:
>
On Tue, Apr 23, 2019 at 7:46 AM Samuel Pitoiset
wrote:
>
> On 4/23/19 10:45 AM, Bas Nieuwenhuizen wrote:
> > On Tue, Apr 23, 2019 at 9:35 AM Samuel Pitoiset
> > wrote:
> >> Signed-off-by: Samuel Pitoiset
> >> ---
> >> src/amd/vulkan/radv_shader.c | 2 +-
> >> src/compiler/ni
All,
I've seen discussions come up several times lately about whether you should
use MAYBE_UNUSED or UNUSED in what scenario and why do we have two of them
anyway. That got me thinking a bit. Maybe what we actually want instead
of MAYBE_UNUSED is something like this:
#ifdef NDEBUG
#define ASSER
On Thu, Apr 18, 2019 at 9:13 AM Juan A. Suarez Romero
wrote:
> On Thu, 2019-03-14 at 11:25 -0500, Jason Ekstrand wrote:
>
> Looking at this a bit more, I'm not sure that just short-circuiting
> actually covers all the cases. Unfortunately, we don't know what all the
> c
On Wed, Apr 17, 2019 at 3:31 PM Nanley Chery wrote:
> On Wed, Apr 17, 2019 at 11:34:15AM -0700, Rafael Antognolli wrote:
> > On Wed, Apr 17, 2019 at 09:04:09AM -0700, Kenneth Graunke wrote:
> > > On Wednesday, April 17, 2019 7:16:28 AM PDT Topi Pohjolainen wrote:
> > > > From: Rafael Antognolli
Quick status check. Mesa 19.1 is supposed to branch in two weeks. Are we
about ready to land this?
On Mon, Mar 25, 2019 at 11:13 AM Juan A. Suarez Romero
wrote:
> On Fri, 2019-03-22 at 17:53 +0100, Iago Toral wrote:
> > Yes, I think those should be fine to land now, they are very few
> > actua
o Qiang for this suggestion!
>
> v3: Bikeshed continues.
>
> Signed-off-by: Alyssa Rosenzweig
> Suggested-by: Qiang Yu
> Cc: Jason Ekstrand
> Cc: Eric Anholt
> ---
> src/compiler/nir/meson.build | 1 +
> src/compiler/nir/nir.h
Why not just do this in a way that common to the two drivers? Forcing FIFO
and MAILBOX both seem useful. For that matter, why not just
MESA_VK_WSI_PRESENT_MODE=FIFO/mailbox/immediate?
On April 8, 2019 13:39:20 Samuel Pitoiset wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=1073
On Thu, Apr 4, 2019 at 11:16 AM Emil Velikov
wrote:
> On Tue, 2 Apr 2019 at 20:13, Matt Turner wrote:
> >
> > On Mon, Apr 1, 2019 at 5:18 AM Emil Velikov
> wrote:
> > > For anyone wondering about the delay:
> > >
> > > We have been using LunarG OpenGL and Vulkan testing service to
> > > validat
47472 -> 47884 (0.87 %)
> Spilled SGPRs: 5079 -> 5105 (0.51 %)
> Spilled VGPRs: 0 -> 0 (0.00 %)
> Private memory VGPRs: 0 -> 0 (0.00 %)
> Scratch size: 0 -> 0 (0.00 %) dwords per thread
> Code Size: 4760924 -> 4815596 (1.15 %) bytes
> LDS: 26 -> 26 (0.00 %) blocks
> Ma
On Thu, Mar 28, 2019 at 9:29 AM Jason Ekstrand wrote:
> I did some benchmarking of Assassin's Creed Odyssey today on ANV.
> Disabling the SSBO optimization possibilities in ANV that moving to derefs
> unlocks (I just moved the lowering super-early; moving back to index/offset
>
n Thu, Mar 28, 2019 at 9:08 AM Jason Ekstrand wrote:
> On Wed, Mar 27, 2019 at 4:13 AM Samuel Pitoiset
> wrote:
>
>> This helps few compute shaders, mostly for F12017.
>>
>> 27670 shaders in 14347 tests
>> Totals:
>> SGPRS: 1231173 -> 1231173 (0.00 %)
On Wed, Mar 27, 2019 at 4:13 AM Samuel Pitoiset
wrote:
> This helps few compute shaders, mostly for F12017.
>
> 27670 shaders in 14347 tests
> Totals:
> SGPRS: 1231173 -> 1231173 (0.00 %)
> VGPRS: 866056 -> 865928 (-0.01 %)
> Spilled SGPRs: 24201 -> 24201 (0.00 %)
> Code Size: 46137040 -> 4614486
---
src/compiler/nir/nir_validate.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/compiler/nir/nir_validate.c b/src/compiler/nir/nir_validate.c
index ef2e2b62783..f8327c0dd45 100644
--- a/src/compiler/nir/nir_validate.c
+++ b/src/compiler/nir/nir_validate.c
@@ -26,6 +26,7 @@
Reviewed-by:
Also applies to the other patch with or without the suggested change.
On March 26, 2019 17:10:53 Samuel Pitoiset wrote:
It was only propagated when UBO/SSBO access are lowered to offsets.
Signed-off-by: Samuel Pitoiset
---
src/compiler/spirv/vtn_cfg.c | 8 +++---
src/com
You could make the old ones call these. It'd make for a smaller diff and
less code to maintain.
On March 26, 2019 17:10:52 Samuel Pitoiset wrote:
Signed-off-by: Samuel Pitoiset
---
src/compiler/nir/nir_builder.h | 30 ++
1 file changed, 30 insertions(+)
diff --git
On Fri, Mar 22, 2019 at 1:13 PM Iago Toral wrote:
> On Fri, 2019-03-22 at 12:47 -0500, Jason Ekstrand wrote:
>
> On Fri, Mar 22, 2019 at 11:53 AM Iago Toral wrote:
>
> Yes, I think those should be fine to land now, they are very few
> actually. Jason, any objections?
>
&
On Fri, Mar 22, 2019 at 11:53 AM Iago Toral wrote:
> Yes, I think those should be fine to land now, they are very few
> actually. Jason, any objections?
>
None at all. Also, where are we at with the last few patches?
--Jason
> Iago
>
> On Fri, 2019-03-22 at 17:26 +0100, Samuel Pitoiset wrot
s or substantial portions of
> the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON
gt; + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
> SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> + * LIABILITY, WHETHER IN AN AC
I'm confused. Don't we always have a NULL render target at location 0? Is
the problem really that we need the NULL render target or is it that we
can't throw away the alpha component of the RT write in the shader? If
it's that we can't throw away the alpha component of the RT write, then I'd
sug
Reviewed-by: Jason Ekstrand
The second will require non-trivial review.
On Fri, Mar 22, 2019 at 8:41 AM Samuel Pitoiset
wrote:
> Only the exponent needs to be 32-bit signed integer.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/compiler/nir/nir_opcodes.py | 4 ++--
>
Reviewed-by: Jason Ekstrand
On Thu, Mar 21, 2019 at 8:20 PM Brian Paul wrote:
> ---
> src/compiler/nir_types.cpp | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/compiler/nir_types.cpp b/src/compiler/nir_types.cpp
> index aff575c..3bf93c5
There's a MR out to fix this:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/478/diffs
On Tue, Mar 19, 2019 at 5:32 AM Samuel Pitoiset
wrote:
> This commit breaks some CTS with RADV (eg.
> dEQP-VK.ssbo.phys.layout.single_basic_type.std430.bvec2) and it
> introduces one compiler warning
---
src/compiler/nir/nir.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 67304af1d64..e4f012809e5 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -59,6 +59,7 @@ extern "C" {
#define NIR_FALSE 0u
#de
We initially set this lower because we didn't have SIMD32 support yet
but we've supported SIMD32 for quite some time now. We should bump it
up to the real limit.
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/s
On Thu, Mar 14, 2019 at 7:08 PM Jason Ekstrand wrote:
> From: Eleni Maria Stea
>
> Added support for setting the locations when the pipeline has been
> created with the dynamic state bit enabled according to the Vulkan
> Specification section [26.5. Custom Sample Locations] f
On Thu, Mar 14, 2019 at 7:08 PM Jason Ekstrand wrote:
> Eleni,
>
> I made a comment on one of your patches and then I started getting lost in
> the churn. It's easier to see what's going on if things are reordered and
> refactored a bit. Unfortunately, what need
mples
per platform to avoid extra checks. (Sagar Ghuge)
v3: 1- Replaced VK_FALSE with false as Jason has sent a patch to replace
VK_FALSE with false in other places. (Jason Ekstrand)
2- Removed unecessary defines and set the grid size to 1 (Jason Ekstrand)
Reviewed-by: Sagar Ghuge
---
(Jason Ekstrand)
2- Simplified the code that sets the grid size (Jason Ekstrand)
3- Instead of filling the whole struct, we only fill the parts we
should override (sType, grid size) and we call
anv_debug_ignored_stype to any pNext elements (Jason Ekstrand)
---
src/intel
From: Eleni Maria Stea
In src/intel/vulkan/genX_blorp_exec.c we included the file:
common/gen_sample_positions.h but not use it. Removed.
Reviewed-by: Sagar Ghuge
Reviewed-by: Jason Ekstrand
---
src/intel/vulkan/genX_blorp_exec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/intel
---
src/intel/vulkan/anv_genX.h | 4 ++
src/intel/vulkan/genX_pipeline.c | 40 +--
src/intel/vulkan/genX_state.c| 84
3 files changed, 70 insertions(+), 58 deletions(-)
diff --git a/src/intel/vulkan/anv_genX.h b/src/intel/vulkan/anv_genX.h
in
From: Eleni Maria Stea
We only emit sample locations when the extension is enabled by the user.
In all other cases the default locations are emitted once when the device
is initialized to increase performance.
---
src/intel/vulkan/genX_cmd_buffer.c | 1 +
src/intel/vulkan/genX_pipeline.c | 3 +
ment that it be the
one closest to center. (Jason Ekstrand)
For that we made the following changes:
1- We removed the custom structs and functions from anv_private.h
and anv_sample_locations.h and anv_sample_locations.c (the last
two files were removed). (Jason Ekstrand)
2-
From: Eleni Maria Stea
Added the VK_EXT_sample_locations to the anv_extensions.py list to
generate the related entrypoints.
Reviewed-by: Sagar Ghuge
---
src/intel/vulkan/anv_extensions.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_extensions.py
b/src/intel/vulkan
ns
anv: Added support for dynamic sample locations
anv: Optimized the emission of the default locations on Gen8+
anv: Removed unused header file
anv: Enabled the VK_EXT_sample_locations extension
Jason Ekstrand (2):
anv/pipeline: Refactor 3DSTATE_SAMPLE_MASK setup
anv: Break SAMPLE_PATTERN
From: Eleni Maria Stea
Enabled the VK_EXT_sample_locations for Intel Gen >= 7.
v2: Replaced device.info->gen >= 7 with True, as Anv doesn't support
anything below Gen7. (Lionel Landwerlin)
Reviewed-by: Sagar Ghuge
---
src/intel/vulkan/anv_extensions.py | 2 +-
1 file changed, 1 insertion(
From: Eleni Maria Stea
This commit adds a "locations" parameter to emit_multisample and
emit_sample_pattern which, if provided, will override the default
sample locations.
---
src/intel/common/gen_sample_positions.h | 57 +
src/intel/vulkan/anv_genX.h | 6 +-
src/intel
cations to store
the locations in order for dynamic case. (see also the patch for
the non-dynamic case. (Jason Ekstrand)
---
src/intel/vulkan/anv_cmd_buffer.c | 17 +
src/intel/vulkan/anv_private.h | 6 ++
src/intel/vulkan/genX_cmd_buffer.c | 11 +++
3 files c
---
src/intel/vulkan/genX_pipeline.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 975052deb79..8ba206ed8c4 100644
--- a/src/intel/vulkan/genX_pipeline.c
+++ b/src/intel/
and Vulkan only
> require that the centroid be some lit sample and that it's the same
> for all samples in a pixel; they have no requirement that it be the
> one closest to center. (Jason Ekstrand)
> For that we made the following changes:
> 1- We
Yup. Not getting used at all.
Reviewed-by: Jason Ekstrand
On Thu, Mar 14, 2019 at 12:10 PM Rafael Antognolli <
rafael.antogno...@intel.com> wrote:
> It seems pretty useless nowadays.
> ---
> src/mesa/drivers/dri/i965/brw_blorp.c | 36 +--
>
itional %3 %5 %2
> %5 = OpLabel
> OpBranch %2
> %2 = OpLabel
> [...]
>
> In the second OpBranchConditional, as the else-part is the end
> block (started in the first OpBranchConditional) we can just follow the
> then-part.
>
> This fixes dEQP-VK.vkrunner.controlflo
On Thu, Mar 14, 2019 at 4:09 AM Juan A. Suarez Romero
wrote:
> 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
We don't set it on HSW and earlier in i965 and disabling it appears to
make derivatives somewhat more reliable.
Cc: Kenneth Graunke
---
src/intel/vulkan/genX_pipeline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pi
On Wed, Mar 13, 2019 at 3:56 PM Nanley Chery wrote:
> On Tue, Mar 12, 2019 at 10:56:27PM -0500, Jason Ekstrand wrote:
> > Cc: mesa-sta...@lists.freedesktop.org
> > Cc: Nanley Chery
> > ---
> > src/intel/vulkan/anv_pass.c | 18 +-
> > 1 file chan
On Wed, Mar 13, 2019 at 8:43 AM Eleni Maria Stea wrote:
> On Wed, 13 Mar 2019 08:16:10 -0500
> Jason Ekstrand wrote:
>
> > On Mon, Mar 11, 2019 at 10:05 AM Eleni Maria Stea
> > wrote:
> >
> > > Allowing the user to set custom sample locations non-dynamic
On Mon, Mar 11, 2019 at 10:05 AM Eleni Maria Stea wrote:
> Allowing the user to set custom sample locations non-dynamically, by
> filling the extension structs and chaining them to the pipeline structs
> according to the Vulkan specification section [26.5. Custom Sample
> Locations]
> for the fol
On Mon, Mar 11, 2019 at 10:05 AM Eleni Maria Stea wrote:
> Allowing the user to set custom sample locations non-dynamically, by
> filling the extension structs and chaining them to the pipeline structs
> according to the Vulkan specification section [26.5. Custom Sample
> Locations]
> for the fol
On Tue, Mar 12, 2019 at 5:35 AM Eleni Maria Stea wrote:
> The VkPhysicalDeviceSampleLocationPropertiesEXT struct is filled with
> implementation dependent values and according to the table from the
> Vulkan Specification section [36.1. Limit Requirements]:
>
> pname | max | min
> pname:sampleLoca
This doesn't need to be in it's open file. Just put it in anv_device.c
after all the other physical device queries.
On March 13, 2019 06:01:33 Eleni Maria Stea wrote:
Implemented the vkGetPhysicalDeviceMultisamplePropertiesEXT according to
the Vulkan Specification section [36.2. Additional Mu
Rb
On March 13, 2019 06:01:53 Eleni Maria Stea wrote:
In src/intel/vulkan/genX_blorp_exec.c we included the file:
common/gen_sample_positions.h but not use it. Removed.
Reviewed-by: Sagar Ghuge
---
src/intel/vulkan/genX_blorp_exec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/intel
Cc: mesa-sta...@lists.freedesktop.org
Cc: Nanley Chery
---
src/intel/vulkan/anv_pass.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_pass.c b/src/intel/vulkan/anv_pass.c
index 5fac5bbb31c..ec217abfda0 100644
--- a/src/intel/vulkan/anv_
Pushed. Thanks!
On Tue, Mar 12, 2019 at 6:35 PM Sagar Ghuge wrote:
> Reviewed-by: Sagar Ghuge
>
> On 3/12/19 4:21 PM, Jason Ekstrand wrote:
> > We don't care about the information but there's no sense in throwing a
> > debug warning about it. It&#
Pushed! Thanks.
On Tue, Mar 12, 2019 at 5:42 PM Timothy Arceri
wrote:
>
>
> On 13/3/19 8:30 am, Jason Ekstrand wrote:
> > The previous code was completely broken when it came to constructing the
> > undef values. I'm not sure how it ever worked. For the case o
We don't care about the information but there's no sense in throwing a
debug warning about it. It's harmless but annoying to users.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109984
Cc: Craig Stout
---
src/intel/vulkan/anv_pass.c | 4
1 file changed, 4 insertions(+)
diff --git
The previous code was completely broken when it came to constructing the
undef values. I'm not sure how it ever worked. For the case of a copy
that reads an undefined value, we can just delete the copy because the
destination is a valid undefined value. This saves us the effort of
trying to cons
We've been fairly inconsistent about this so we should really choose
whether we're going to use VK_TRUE/FALSE or the C boolean values. The
Vulkan #defines are set to 1 and 0 respectively so it's the same value
as C gives you when you cast a boolean expression to an integer. Since
there are severa
On March 11, 2019 22:17:38 Alyssa Rosenzweig wrote:
[1] https://patchwork.freedesktop.org/patch/291616/
Ah-ha, somebody who knows what they're doing. That's good; ignore this
series then :)
The first patch was fine. Just not the second.
---
So is this a "no" for the deleting ~/mesa/sr
This patch is
Reviewed-by: Jason Ekstrand
On March 11, 2019 21:31:03 Alyssa Rosenzweig wrote:
Fixes a gcc warning (and a theoretical NULL dereference error, though I
suppose shortcircuiting avoids that).
Signed-off-by: Alyssa Rosenzweig
---
src/compiler/nir/nir_loop_analyze.c | 2 +-
1
set layouts")
>
> I ran this though CI and these tests are no longer failing. I didn't see
> any
> regressions either.
>
>
> >CC: Tapani Pälli
> >CC: Lionel Landwerlin
> >CC: Jason Ekstrand
> >---
> > src/intel/vulkan/anv_descriptor_set.
Reviewed-by: Jason Ekstrand
On Mon, Mar 11, 2019 at 12:34 PM Juan A. Suarez Romero
wrote:
> 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 des
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.
>
> I'd say it is legal. The spec does not mandate that each bra
---
src/compiler/nir/nir_serialize.c | 56 ---
src/compiler/nir/nir_serialize.h | 3 +-
.../drivers/radeonsi/si_state_shaders.c | 2 +-
src/intel/vulkan/anv_pipeline_cache.c | 2 +-
.../drivers/dri/i965/brw_program_binary.c | 2 +-
sr
Because we already know the immediate right-hand parameter, we can
potentially save the optimizer a bit of work.
---
src/compiler/nir/nir_builder.h | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_b
fixes dEQP-VK.vkrunner.controlflow.2-obc-triangle-triangle
CC: Jason Ekstrand
---
src/compiler/spirv/vtn_cfg.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 7868eeb60bc..f749118efbe 100644
--- a/sr
There's no guarantee when build_deref_follower is called that the two
derefs have the same bit size destination. Insert a cast on the array
index in case we have differing bit sizes. While we're here, insert
some asserts in build_deref_array and build_deref_ptr_as_array. The
validator will catch
Those fuzzing guys are mean...
This stuff is subtle but I think this is correct. Assuming you've run it
through our CI and everything is good,
Reviewed-by: Jason Ekstrand
On Wed, Feb 27, 2019 at 5:05 AM Juan A. Suarez Romero
wrote:
> When emitting a branch in a block, it does not ma
No idea how this fell through the cracks besides the fact that the
sampler bound at 0 almost always works and the CTS isn't amazing. In
any case, this appears to have been broken for almost forever.
Cc: mesa-sta...@lists.freedesktop.org
---
src/compiler/spirv/spirv_to_nir.c | 2 +-
1 file change
On Wed, Feb 13, 2019 at 3:30 PM Eduardo Lima Mitev wrote:
> ir3 compiler has an integer multiply-add instruction (MAD_S24)
> that is used for different offset calculations in the backend.
> Since we intend to move some of these calculations to NIR, we need
> a new ALU op that can directly represe
Rb
On February 25, 2019 05:35:17 Tapani Pälli wrote:
Fixes: 3d7611e9 "st/nir: use NIR for asm programs"
Reported-by: Matthias Lorenz
Signed-off-by: Tapani Pälli
---
src/mesa/program/prog_to_nir.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/mesa/program/p
This is correct. However, it's probably better to just replace most of
that code with a call to nir_variable_create which will do everything in
that block except set the data.read_only bit including the strdup
(properly) and adding it to the list.
--Jason
On Mon, Feb 25, 2019 at 3:06 AM Tapani P
---
src/compiler/nir/nir_split_vars.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/compiler/nir/nir_split_vars.c
b/src/compiler/nir/nir_split_vars.c
index 244ffd6dcf0..96b6042e6d9 100644
--- a/src/compiler/nir/nir_split_vars.c
+++ b/src/compiler/nir/nir_split_vars.c
@@ -1423,6 +1
The nir_swizzle helper is used some on it's own but it's also called by
nir_channel and nir_channels which are used everywhere. It's pretty
quick to check while we're walking the swizzle anyway whether or not
it's an identity swizzle. If it is, we now don't bother emitting the
instruction. Sure,
i_src *src,
>return should_lower_phi(nir_instr_as_phi(src_instr), state);
>
> case nir_instr_type_load_const:
> - case nir_instr_type_ssa_undef:
>
Instead of removing it, would you mind handling it as
case nir_instr_type_ssa_undef:
/* The caller of this function is going to OR the
On Fri, Feb 22, 2019 at 4:05 PM Timothy Arceri
wrote:
>
>
> On 23/2/19 8:54 am, Jason Ekstrand wrote:
> > On Fri, Feb 22, 2019 at 2:47 PM Timothy Arceri > <mailto:tarc...@itsqueeze.com>> wrote:
> >
> >
> >
> > On 23/2/19 6:31 am, Rob Clark
On Fri, Feb 22, 2019 at 2:47 PM Timothy Arceri
wrote:
>
>
> On 23/2/19 6:31 am, Rob Clark wrote:
> > On Fri, Feb 22, 2019 at 12:39 PM Jason Ekstrand
> wrote:
> >>
> >> On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt wrote:
> >>>
> >>>
On Fri, Feb 22, 2019 at 9:51 AM Eric Anholt wrote:
> Timothy Arceri writes:
>
> > shader-db results i965 (SKL):
> >
> > total instructions in shared programs: 13219105 -> 13024761 (-1.47%)
> > instructions in affected programs: 1169457 -> 975113 (-16.62%)
> > helped: 599
> > HURT: 154
> >
> > to
Reviewed-by: Jason Ekstrand
On Fri, Feb 22, 2019 at 9:56 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
> > Fill out "Vertex Sub Pixel Precision Select" possible values.
> >
> >
On Fri, Feb 22, 2019 at 9:58 AM Jason Ekstrand wrote:
> On Fri, Feb 22, 2019 at 9:57 AM Lionel Landwerlin <
> lionel.g.landwer...@intel.com> wrote:
>
>> On 22/02/2019 15:51, Juan A. Suarez Romero wrote:
>> > On one side, when emitting 3DSTATE_SF, VertexSubPixelP
This field was added on gen8 even though there's an identically defined
one in 3DSTATE_SF.
---
src/intel/vulkan/genX_pipeline.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/vulkan/genX_pipeline.c b/src/intel/vulkan/genX_pipeline.c
index 6255e5d83c5..192a121324d 100644
--- a/sr
should be the
> > expected value for the tests, is changed to use 4 bit as ANV was
> > advertising so far, some of the tests will fail.
> >
> > So it seems ANV is actually using 8 bits.
> >
> > v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
&g
Copy+paste error. It was supposed to test cull and not clip.
Fixes: 4e69fba534e "nir: Rewrite lower_clip_cull_distance_arrays..."
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109717
Cc: Kenneth Graunke
---
src/compiler/nir/nir_lower_clip_cull_distance_arrays.c | 2 +-
1 file changed,
On Thu, Feb 14, 2019 at 4:53 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
> > wrote:
> >
> >> This is required in combination with the following commit, because
> >> otherwise if a source re
On Thu, Feb 14, 2019 at 9:33 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > On Fri, Jan 18, 2019 at 6:09 PM Francisco Jerez
> > wrote:
> >
> >> Currently the execution type calculation will return a bogus value in
> >> cases like:
> >
This MR cleans up some old cruft lying around in our back-end compiler
surrounding images.
The first three commits provide an enum for surface opcode sources and drop
the surface builder from the scalar back-end. Now that image format
lowering has moved to NIR and we have logical opcodes for HW i
tests will fail.
>
> So it seems ANV is actually using 8 bits.
>
> v2: explicitly set 3DSTATE_SF::VertexSubPixelPrecisionSelect (Jason)
>
> CC: Jason Ekstrand
> CC: Kenneth Graunke
> ---
> src/intel/vulkan/anv_device.c| 2 +-
> src/intel/vulkan/genX_pipelin
Reviewed-by: Jason Ekstrand
On Thu, Feb 21, 2019 at 5:33 AM Thomas Helland
wrote:
> This patch is:
>
> Reviewed-by: Thomas Helland
>
> Den ons. 20. feb. 2019 kl. 04:04 skrev Timothy Arceri <
> tarc...@itsqueeze.com>:
> >
> > This reduces the time spe
Reviewed-by: Jason Ekstrand
On Wed, Feb 20, 2019 at 12:30 AM Timothy Arceri
wrote:
> Even in a very basic shader this reduces the time spent in
> nir_copy_prop() by ~17%.
>
> No shader-db changes for radeonsi NIR or i965.
> ---
> src/compiler/nir/nir_opt_cop
201 - 300 of 12089 matches
Mail list logo
