Each of the pop functions (and push_else) take a control flow parameter as
their second argument. If NULL, it assumes that the builder is in a block
that's a direct child of the control-flow node you want to pop off the
virtual stack. This is what 90% of consumers will want. The SPIR-V pass,
how
---
src/compiler/nir/nir_lower_indirect_derefs.c | 35
1 file changed, 5 insertions(+), 30 deletions(-)
diff --git a/src/compiler/nir/nir_lower_indirect_derefs.c
b/src/compiler/nir/nir_lower_indirect_derefs.c
index 09cc9a3..c949224 100644
--- a/src/compiler/nir/nir_l
---
src/compiler/glsl/glsl_to_nir.cpp | 38 +++---
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 00f20da..fc2a2c4 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/
---
src/compiler/spirv/vtn_cfg.c | 45 ++--
1 file changed, 14 insertions(+), 31 deletions(-)
diff --git a/src/compiler/spirv/vtn_cfg.c b/src/compiler/spirv/vtn_cfg.c
index 3a31657..54248b1 100644
--- a/src/compiler/spirv/vtn_cfg.c
+++ b/src/compiler/spirv/
---
src/compiler/nir/nir_lower_gs_intrinsics.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/compiler/nir/nir_lower_gs_intrinsics.c
b/src/compiler/nir/nir_lower_gs_intrinsics.c
index 3acb742..68e20dd 100644
--- a/src/compiler/nir/nir_lower_gs_intrinsics.c
+++ b/
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/nir.h | 11 ++
src/compiler/nir/nir_lower_int64.c | 275 +
3 files changed, 287 insertions(+)
create mode 100644 src/compiler/nir/nir_lower_int64.c
diff --git a/src/compiler/Makefile
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 6f570d8..5857ae2 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -478,7 +478,7 @@ void anv_Get
---
src/mesa/drivers/dri/i965/brw_link.cpp | 5 -
src/mesa/drivers/dri/i965/brw_nir.c| 7 +++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_link.cpp
b/src/mesa/drivers/dri/i965/brw_link.cpp
index 977feb3..4159756 100644
--- a/src/mesa/dri
The algorithms used by this pass, especially for division, are heavily
based on the work Ian Romanick did for the similar int64 lowering pass
in the GLSL compiler.
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/nir.h | 11 ++
src/compiler/nir/nir_lower_int64.c | 284
On Feb 23, 2017 11:40 PM, "Iago Toral Quiroga" wrote:
According to the PRM description of the Depth field:
"This field specifies the total number of levels for a volume texture
or the number of array elements allowed to be accessed starting at the
Minimum Array Element for arrayed surfac
g will
require learning a bit about the compiler stack but this is as good a
learning opportunity as any.
--Jason
> --Michael
>
> -Ursprüngliche Nachricht-
> Von: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] Im Auftrag
> von Jason Ekstrand
> Gesendet: Freitag, 24
On Fri, Feb 24, 2017 at 6:05 AM, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:
>
>
> On 24/02/17 02:14, Jason Ekstrand wrote:
> > Each of the pop functions (and push_else) take a control flow parameter
> as
> > their second argument. If NULL, it as
me loops that would unroll with GLSL IR fail to unroll if we set
>> this to 25 so we set it to 26.
>>
>
Sorry its taken so long. That comment looks good to me.
Reviewed-by: Jason Ekstrand
I'll push it as soon as I've verified that it builds.
--Jason
> Elie
>&g
The zy swizzle gives us one component of quotient and one component of
remainder. What we wanted was zw for the remainder.
Cc: Ian Romanick
---
src/compiler/glsl/builtin_int64.h | 22 --
src/compiler/glsl/int64.glsl | 2 +-
2 files changed, 9 insertions(+), 15 deletion
The algorithms used by this pass, especially for division, are heavily
based on the work Ian Romanick did for the similar int64 lowering pass
in the GLSL compiler.
v2: Properly handle vectors
v3: Get rid of log2_denom stuff. Since we're using bcsel, we do all the
calculations anyway and this
On Fri, Feb 24, 2017 at 3:58 PM, Matt Turner wrote:
> On Fri, Feb 24, 2017 at 3:48 PM, Jason Ekstrand
> wrote:
> > The algorithms used by this pass, especially for division, are heavily
> > based on the work Ian Romanick did for the similar int64 lowering pass
> &
This prevents a user from using a cache created on one hardware
generation on a different one. Of course, with Intel hardware, this
requires moving their drive from one machine to another but it's still
possible and we should prevent it.
---
src/intel/vulkan/anv_device.c | 20 +++-
We're about to use the build-id as the starting point for another SHA1
hash in the Intel Vulkan driver, and returning a pointer is far more
convenient.
---
src/intel/vulkan/anv_device.c | 2 +-
src/util/build_id.c | 7 +++
src/util/build_id.h | 5 ++---
3 files changed, 6 i
Why?
On Thu, Feb 23, 2017 at 8:48 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Signed-off-by: Emil Velikov
> ---
> src/intel/vulkan/Makefile.am | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
> index 44
seems reasonable
Reviewed-by: Jason Ekstrand
On Wed, Feb 22, 2017 at 4:33 PM, Nanley Chery wrote:
> Depth buffers aren't allowed to be used as storage images.
>
> Fixes: 055ff2ec521 ("anv: Replace anv_image_has_hiz() with
> ISL_AUX_USAGE_HIZ")
> Signed-off-by: Na
The algorithms used by this pass, especially for division, are heavily
based on the work Ian Romanick did for the similar int64 lowering pass
in the GLSL compiler.
v2: Properly handle vectors
v3: Get rid of log2_denom stuff. Since we're using bcsel, we do all the
calculations anyway and this
es what it
claims to do.
--Jason
Jacob Lifshay
On Feb 19, 2017 02:08, "Kai Wasserbäch" wrote:
> Jason Ekstrand wrote on 19.02.2017 06:01:
> > On Feb 18, 2017 12:37 PM, "Kai Wasserbäch"
> > wrote:
> >
> > Hey Jacob,
> > sorry for not spotting
We've been following the spec changes.
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 5168331..30b5bb3 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_de
On Mon, Feb 27, 2017 at 9:38 AM, Chad Versace
wrote:
> On Fri 24 Feb 2017, Jason Ekstrand wrote:
> > This prevents a user from using a cache created on one hardware
> > generation on a different one. Of course, with Intel hardware, this
> > requires moving their driv
we
should actually merge them into master. This cover letter seems as good a
place as any to hold that discussion. :-)
Chad Versace (1):
anv: Implement VK_KHX_external_memory_capabilities
Jason Ekstrand (6):
anv: Add the pci_id into the shader cache UUID
anv: Refactor device_get_cache
We're about to have more UUIDs for different things so this one really
needs to be properly labeled.
---
src/intel/vulkan/anv_device.c | 5 +++--
src/intel/vulkan/anv_pipeline_cache.c | 4 ++--
src/intel/vulkan/anv_private.h| 2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
This prevents a user from using a cache created on one hardware
generation on a different one. Of course, with Intel hardware, this
requires moving their drive from one machine to another but it's still
possible and we should prevent it.
---
src/intel/vulkan/anv_device.c | 21
---
src/intel/vulkan/anv_device.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index f9e2203..26be55f 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.
There's really nothing for us to do here. So long as the user doesn't
set any crazy environment variables such as INTEL_VK_HIZ=false, all of
the compression formats etc. should "just work" at least for opaque
handle types.
---
src/intel/vulkan/anv_device.c | 6 +-
src/intel/vulkan/a
Co-authored-with: Chad Versace
---
src/intel/vulkan/anv_device.c | 90 +
src/intel/vulkan/anv_entrypoints_gen.py | 1 +
src/intel/vulkan/anv_formats.c | 38 +-
3 files changed, 118 insertions(+), 11 deletions(-)
diff --git a/src/int
---
src/util/vk_util.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/util/vk_util.h b/src/util/vk_util.h
index e0b5d0b..0b9cb47 100644
--- a/src/util/vk_util.h
+++ b/src/util/vk_util.h
@@ -40,4 +40,21 @@ struct vk_struct_common {
for (const struct vk_struct_common
From: Chad Versace
This is a complete but trivial implementation. It's trivial becasue We
support no external memory capabilities yet. Most of the real work in
this commit is in reworking the UUIDs advertised by the driver.
---
src/intel/vulkan/anv_device.c | 53 ++
On Mon, Feb 27, 2017 at 4:56 PM, Ben Widawsky wrote:
> On 17-01-31 13:24:55, Jason Ekstrand wrote:
>
>> On Mon, Jan 23, 2017 at 10:21 PM, Ben Widawsky wrote:
>>
>> v2: Put the commit message as a comment (Topi)
>>>
>>> Cc: Topi Pohjolainen
>
On Mon, Feb 27, 2017 at 5:38 PM, Jason Ekstrand
wrote:
> On Mon, Feb 27, 2017 at 4:56 PM, Ben Widawsky wrote:
>
>> On 17-01-31 13:24:55, Jason Ekstrand wrote:
>>
>>> On Mon, Jan 23, 2017 at 10:21 PM, Ben Widawsky wrote:
>>>
>>> v2: Put the commit m
Reviewed-by: Jason Ekstrand
On Feb 27, 2017 5:20 PM, "Nanley Chery" wrote:
> Cc:
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_pass.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/src/intel/vulka
On Feb 27, 2017 5:21 PM, "Nanley Chery" wrote:
Signed-off-by: Nanley Chery
---
src/intel/vulkan/genX_cmd_buffer.c | 57 ++
1 file changed, 15 insertions(+), 42 deletions(-)
diff --git a/src/intel/vulkan/genX_cmd_buffer.c
b/src/intel/vulkan/genX_cmd_buffer.c
On Feb 27, 2017 5:20 PM, "Nanley Chery" wrote:
Validate the inputs and actually verify that this image has a depth
buffer.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_blorp.c | 1 +
src/intel/vulkan/anv_image.c | 7 +++
src/intel/vulkan/anv_private.h | 7 +--
3 files chang
Why store aux usage and not the just image layout? It doesn't really
matter whether we call layout_to_aux_usage here or when we emit the binding
tables. I'm just wondering why you made the choice this way.
On Feb 27, 2017 5:20 PM, "Nanley Chery" wrote:
Signed-off-by: Nanley Chery
---
src/int
Let me make sure I understand this patch correctly: In the previous patch
we made it so that we no longer unconditionally use HiZ for sampling so,
when the image is in the general layout, we don't need a HiZ resolve
because we are ignoring the HiZ buffer anyway.
On Feb 27, 2017 5:22 PM, "Nanley C
On Feb 27, 2017 5:21 PM, "Nanley Chery" wrote:
We'll loop through this array when performing automatic layout
transitions.
Signed-off-by: Nanley Chery
---
src/intel/vulkan/anv_pass.c| 6 +-
src/intel/vulkan/anv_private.h | 7 +++
2 files changed, 12 insertions(+), 1 deletion(-)
di
Thank you! I've been meaning to do this. That said, I think we need
something in cmd_state_reset as well.
On Feb 27, 2017 5:22 PM, "Nanley Chery" wrote:
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/genX_cmd_buffer.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/sr
Did a read-through and, overall, this looks great. I made a few comments
but they're fairly simple.
One question though: Am I correct in thinking that we are still disabling
HiZ for rendering when the image is in the general layout? I think it
should be easy enough to change now but I didn't se
On Tue, Feb 28, 2017 at 8:02 AM, Nanley Chery wrote:
> On Mon, Feb 27, 2017 at 08:48:48PM -0800, Jason Ekstrand wrote:
> > On Feb 27, 2017 5:20 PM, "Nanley Chery" wrote:
> >
> > Validate the inputs and actually verify that this image has a depth
> > buffer
On Tue, Feb 28, 2017 at 5:54 AM, Nanley Chery wrote:
> On Mon, Feb 27, 2017 at 08:41:56PM -0800, Jason Ekstrand wrote:
> > On Feb 27, 2017 5:21 PM, "Nanley Chery" wrote:
> >
> > Signed-off-by: Nanley Chery
> > ---
> &g
On Tue, Feb 28, 2017 at 8:22 AM, Nanley Chery wrote:
> On Mon, Feb 27, 2017 at 09:00:15PM -0800, Jason Ekstrand wrote:
> > Why store aux usage and not the just image layout? It doesn't really
> > matter whether we call layout_to_aux_usage here or when we emit the
> bindin
On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery wrote:
> This function supersedes layout_to_hiz_usage().
>
> Signed-off-by: Nanley Chery
> ---
> src/intel/vulkan/anv_image.c | 149 ++
> +++
> src/intel/vulkan/anv_private.h | 4 ++
> 2 files changed, 153 ins
ing libdrm for most BO allocations? I'm open to
suggestions.
Cc: Chad Versace
Cc: Kristian H. Kristensen
Jason Ekstrand (9):
anv: Move queues, events, and semaphores to their own file
anv: Add a real semaphore struct
anv: Implement VK_KHX_external_semaphore_capabilities
Things are about to get more complicated, especially as far as
semaphores are concerned.
---
src/intel/vulkan/Makefile.sources | 1 +
src/intel/vulkan/anv_device.c | 440 ---
src/intel/vulkan/anv_queue.c | 470 ++
3 fil
---
src/intel/vulkan/anv_device.c | 4
src/intel/vulkan/anv_entrypoints_gen.py | 1 +
src/intel/vulkan/anv_queue.c| 8
3 files changed, 13 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index a1046c6..6f7c15e 100644
---
This just stubs things out. Real external semaphore support will come
with VK_KHX_external_semaphore_fd.
---
src/intel/vulkan/anv_device.c | 4
src/intel/vulkan/anv_entrypoints_gen.py | 1 +
src/intel/vulkan/anv_queue.c| 12
3 files changed, 17 insertions
It's just a dummy for now, but we'll flesh it out as needed for external
semaphores.
---
src/intel/vulkan/anv_private.h | 15 +++
src/intel/vulkan/anv_queue.c | 30 --
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/src/intel/vulkan/anv_pri
The command is really operating on a Queue not a command buffer and the
nearest object to that with an allocator is VkDevice.
Cc: "17.0"
---
src/intel/vulkan/anv_batch_chain.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/anv_batch_chain.c
b/src/inte
---
src/intel/vulkan/anv_batch_chain.c | 55 +-
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/src/intel/vulkan/anv_batch_chain.c
b/src/intel/vulkan/anv_batch_chain.c
index e5cc21d..c55938a 100644
--- a/src/intel/vulkan/anv_batch_chain.c
+++ b/
---
src/intel/vulkan/anv_batch_chain.c | 91 --
src/intel/vulkan/anv_device.c | 26 +++
src/intel/vulkan/anv_gem.c | 36 +++
src/intel/vulkan/anv_private.h | 9 +++-
src/intel/vulkan/anv_queue.c | 68 ++
---
src/intel/vulkan/anv_gem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_gem.c b/src/intel/vulkan/anv_gem.c
index 0dde6d9..d8beab1 100644
--- a/src/intel/vulkan/anv_gem.c
+++ b/src/intel/vulkan/anv_gem.c
@@ -168,7 +168,10 @@ int
anv_gem_execbuffe
This implementation allocates a 4k BO for each semaphore that can be
exported using OPAQUE_FD and uses the kernel's already-existing
synchronization mechanism on BOs.
---
src/intel/vulkan/anv_batch_chain.c | 44 --
src/intel/vulkan/anv_device.c | 4 +
src/intel/vulkan/anv
On Tue, Feb 28, 2017 at 9:14 AM, Chris Wilson
wrote:
> On Tue, Feb 28, 2017 at 08:56:45AM -0800, Jason Ekstrand wrote:
> > This implementation allocates a 4k BO for each semaphore that can be
> > exported using OPAQUE_FD and uses the kernel's already-existing
> > synchr
On Tue, Feb 28, 2017 at 8:48 AM, Nanley Chery wrote:
> On Mon, Feb 27, 2017 at 09:22:13PM -0800, Jason Ekstrand wrote:
> > On Feb 27, 2017 5:21 PM, "Nanley Chery" wrote:
> >
> > We'll loop through this array when performing automatic layout
> > transi
On Tue, Feb 28, 2017 at 9:29 AM, Nanley Chery wrote:
> On Tue, Feb 28, 2017 at 08:07:35AM -0800, Jason Ekstrand wrote:
> > On Tue, Feb 28, 2017 at 8:02 AM, Nanley Chery
> wrote:
> >
> > > On Mon, Feb 27, 2017 at 08:48:48PM -0800, Jason Ekstrand wrote:
> > >
On Tue, Feb 28, 2017 at 9:25 AM, Chris Wilson
wrote:
> On Tue, Feb 28, 2017 at 08:56:47AM -0800, Jason Ekstrand wrote:
> > ---
> > src/intel/vulkan/anv_batch_chain.c | 91 ++
> ++--
> > src/intel/vulkan/anv_device.c | 26 +
On Tue, Feb 28, 2017 at 10:32 AM, Nanley Chery
wrote:
> On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> > On Mon, Feb 27, 2017 at 5:20 PM, Nanley Chery
> wrote:
> >
> > > This function supersedes layout_to_hiz_usage().
> > &g
On Tue, Feb 28, 2017 at 10:53 AM, Nanley Chery
wrote:
> On Tue, Feb 28, 2017 at 10:38:12AM -0800, Jason Ekstrand wrote:
> > On Tue, Feb 28, 2017 at 10:32 AM, Nanley Chery
> > wrote:
> >
> > > On Tue, Feb 28, 2017 at 08:26:56AM -0800, Jason Ekstrand wrote:
> >
Thanks!
Reviewed-by: Jason Ekstrand
On Tue, Feb 28, 2017 at 10:56 AM, Emil Velikov
wrote:
> From: Emil Velikov
>
> Do not hardcode the file in the python script, but pass it via the build
> system(s). The former is the only one that should know about the file
> locaiton
off to you sir.
Modulo Y-tiling and comments,
Reviewed-by: Jason Ekstrand
On Tue, Jul 21, 2015 at 9:38 AM, Francisco Jerez wrote:
> Define a function to calculate the memory address of the image
> location given by a vector of coordinates. This is required in cases
> where we need to
R-B me
On Jul 24, 2015 6:52 AM, "Francisco Jerez" wrote:
> This hasn't been overallocating space for the header for a long time.
> It still leaves the header uninitialized though until the generator
> fixes it.
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 5 +++--
> 1 file changed, 3 i
On Jul 24, 2015 4:00 AM, "Francisco Jerez" wrote:
>
> Jason Ekstrand writes:
>
> > Ok, I've looked through this again and convinced myself that it's
> > *mostly* correct. I am a bit skeptical of the address swizzling for
> > Y-major tiling.
> &g
On Fri, Jul 24, 2015 at 7:39 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Jul 24, 2015 4:00 AM, "Francisco Jerez" wrote:
>>>
>>> Jason Ekstrand writes:
>>>
>>> > Ok, I've looked through this again and convinced
On Jul 24, 2015 8:02 AM, "Francisco Jerez" wrote:
>
> Jason Ekstrand writes:
>
> > On Fri, Jul 24, 2015 at 7:39 AM, Francisco Jerez
wrote:
> >> Jason Ekstrand writes:
> >>
> >>> On Jul 24, 2015 4:00 AM, "Francisco Jerez"
wrot
Much better.
Reviewed-by: Jason Ekstrand
On Fri, Jul 24, 2015 at 9:33 AM, Francisco Jerez wrote:
> Define a function to calculate the memory address of the image
> location given by a vector of coordinates. This is required in cases
> where we need to fall back to untyped surfa
On Thu, Jul 23, 2015 at 3:16 AM, Eduardo Lima Mitev wrote:
> These methods are essential for the implementation of the NIR->vec4 pass. They
> work similar to their fs_nir counter-parts.
>
> When processing instructions, these methods are invoked to resolve the
> brw registers (source or destinatio
On Fri, Jul 24, 2015 at 12:19 PM, Jason Ekstrand wrote:
> On Thu, Jul 23, 2015 at 3:16 AM, Eduardo Lima Mitev wrote:
>> These methods are essential for the implementation of the NIR->vec4 pass.
>> They
>> work similar to their fs_nir counter-parts.
>>
>>
I think we already agreed to just copy data.location into
data.driver_location and we don't need this special-casing.
Just making a note of it as I review.
--Jason
On Thu, Jul 23, 2015 at 3:17 AM, Eduardo Lima Mitev wrote:
> Non-scalar backends like i965's NIR-vec4 need the orginal variable's v
on non-scalar shaders.
These last two paragraphs are now stale. Otherwise,
Reviewed-by: Jason Ekstrand
> ---
> src/mesa/drivers/dri/i965/brw_nir.c| 2 +-
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 21 +++--
> 2 files changed, 20 insertions(+), 3 del
On Thu, Jul 23, 2015 at 3:17 AM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro
>
> Uses the nir structure to get all the info needed (sources,
> dest reg, etc), and then it uses the common
> vec4_visitor::emit_texture to emit the final code.
> ---
> src/mesa/drivers/dri/i965/brw_vec4_nir.c
This patch needs to go *before* patch 71 so things continue to build.
On Thu, Jul 23, 2015 at 3:17 AM, Eduardo Lima Mitev wrote:
> From: Samuel Iglesias Gonsalvez
>
> So the implementation is independent of GLSL IR and the visit methods of the
> gen6 GS visitor. This way we will be able to reuse
On Thu, Jul 23, 2015 at 3:17 AM, Eduardo Lima Mitev wrote:
> From: Iago Toral Quiroga
>
> For the indirect case we need to take the index delivered by
> NIR and compute the parent uniform that we are accessing (the one
> that we uploaded to a surface) and the constant offset into that
> surface.
On Thu, Jul 23, 2015 at 3:17 AM, Eduardo Lima Mitev wrote:
> From: Alejandro Piñeiro
>
> Splitted in two. The emission is moved to a new vec4_visitor
> method, vec4_visitor::emit_texture, ir order to be reused
> on the nir path.
> ---
> src/mesa/drivers/dri/i965/brw_vec4.h | 15 +
> s
Alright, I got through it again...
I asked for a few trivial changes on a few of the patches. With those
fixed, everything except patch 65 and 66 are
Reviewed-by: Jason Ekstrand
While the requested changes on the texturing patches are not
complicated, I would like to see the updated version
On Jul 26, 2015 1:40 PM, "Eduardo Lima Mitev" wrote:
>
> On 07/23/2015 11:25 PM, Jason Ekstrand wrote:
> > On Thu, Jul 23, 2015 at 3:16 AM, Eduardo Lima Mitev
wrote:
> >> The NIR->vec4 pass will be activated if both the following conditions
are met:
> >>
On Jul 26, 2015 2:09 PM, "Eduardo Lima Mitev" wrote:
>
> On 07/25/2015 12:04 AM, Jason Ekstrand wrote:
> > I think we already agreed to just copy data.location into
> > data.driver_location and we don't need this special-casing.
> >
> > Just
R-B
On Jul 27, 2015 6:12 AM, "Francisco Jerez" wrote:
> This cleans up fs_inst::regs_read() slightly by disentangling the
> calculation of "components" from the handling of message payload
> arguments. This will also simplify the SIMD lowering and logical send
> message lowering passes, because
On Mon, Jul 27, 2015 at 9:22 AM, Antía Puentes wrote:
> Hi! Jason,
>
> On jue, 2015-07-23 at 15:46 -0700, Jason Ekstrand wrote:
>
>> > @@ -332,7 +334,22 @@ vec4_visitor::nir_emit_instr(nir_instr *instr)
>> > void
>> > vec4_visitor::nir_emit
On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez wrote:
> Fixes rewrite by the register coalesce pass of references to
> individual halves of 16-wide coalesced registers.
> ---
> src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
On Mon, Jul 27, 2015 at 2:29 PM, Eduardo Lima Mitev wrote:
> On 07/25/2015 01:19 AM, Jason Ekstrand wrote:
>> This patch needs to go *before* patch 71 so things continue to build.
>>
>
> Both patches build for me in the current order, and also build fine
> changing order
On Mon, Jul 27, 2015 at 2:07 PM, Eduardo Lima Mitev wrote:
> On 07/25/2015 03:08 AM, Jason Ekstrand wrote:
>> Alright, I got through it again...
>>
>> I asked for a few trivial changes on a few of the patches. With those
>> fixed, everything except patch 65 and 66
On Mon, Jul 27, 2015 at 2:47 PM, Eduardo Lima Mitev wrote:
> On 07/27/2015 11:33 PM, Jason Ekstrand wrote:
>> On Mon, Jul 27, 2015 at 2:29 PM, Eduardo Lima Mitev wrote:
>>> On 07/25/2015 01:19 AM, Jason Ekstrand wrote:
>>>> This patch needs to go *before* patch
reg_to_offset[offset + 1] = inst->dst.reg_offset + 1;
> mov[offset] = inst;
> channels_remaining -= inst->regs_written;
And then we use regs_written directly below...
Off you want it to be more consistent, we could use regs_written for both.
Either wary,
Reviewed-by: Jason E
The meta CopyImageSubData path uses BlitFramebuffers to do the actual copy.
The only thing that can affect BlitFramebuffers other than the currently
bound framebuffers is the scissor so we need to save that off and reset it.
If we don't do this, applications that use a scissor together with
CopyIma
R-B me
On Jul 28, 2015 2:43 AM, "Francisco Jerez" wrote:
> For some reason the loop that rewrites all occurrences of the
> coalesced register was iterating over all possible offsets until it
> would find one that compares equal to the offset of a source or
> destination of any instruction in the
nd image_load_store piglit tests on my SIMD-lowering
> branch.
Almost more to the point we don't want to coalesce a register and then not
update something that uses it. (which is what was happening.)
Reviewed-by: Jason Ekstrand
> ---
> .../drivers/dri/i965/brw_fs_register_coalesc
On Tue, Jul 28, 2015 at 1:23 AM, Francisco Jerez wrote:
> Instead of relying on the default one. This shouldn't lead to any
> functional changes because DEP_RESOLVE_MOV overrides the execution
> controls of the instruction anyway.
Actually, DEP_RESOLVE_MOV calls half() on the builder which doesn
All patches in this series except for 8 and 14 are
Reviewed-by: Jason Ekstrand
8 looks fishy and I think the code we have there today is probably not
what we want as well. Shouldn't take too much time to fix.
Once 8 gets sorted, I'm fine with 14 but we obviously can't push it
, coordinate, sampler_reg);
> + } else {
> +mcs = src_reg(0u);
> + }
> + mcs = retype(mcs, BRW_REGISTER_TYPE_UD);
> + break;
> + }
> +
> + case nir_tex_src_offset:
> + offset_value = get_nir_src(in
Reviewed-by: Jason Ekstrand
On Mon, Jul 27, 2015 at 3:26 PM, Alejandro Piñeiro wrote:
> Splitted in two. The emission is moved to a new vec4_visitor
> method, vec4_visitor::emit_texture, ir order to be reused
> on the nir path.
> ---
>
> v3: removed shadow_compare and has_
On Jul 29, 2015 3:12 AM, "Francisco Jerez" wrote:
>
> Jason Ekstrand writes:
>
> > On Tue, Jul 28, 2015 at 1:23 AM, Francisco Jerez
wrote:
> >> Instead of relying on the default one. This shouldn't lead to any
> >> functional changes
Patches 1-8 are
Acked-by: Jason Ekstrand
Thanks for cleaning that stuff up.
On Thu, Jul 30, 2015 at 7:14 AM, Ian Romanick wrote:
> All but the last of these patches have been sitting in one tree or
> another for quite some time. All of these files were touched as part of
> other
On Jul 27, 2015 3:39 PM, "Jason Ekstrand" wrote:
>
> On Mon, Jul 27, 2015 at 2:07 PM, Eduardo Lima Mitev
wrote:
> > On 07/25/2015 03:08 AM, Jason Ekstrand wrote:
> >> Alright, I got through it again...
> >>
> >> I asked for a few trivial change
Currently the validation pass only validates that regs_read and
regs_written are consistent with the sizes of VGRF's. We can add more as
we find it to be useful.
---
src/mesa/drivers/dri/i965/Makefile.sources| 1 +
src/mesa/drivers/dri/i965/brw_fs.cpp | 9
src/mesa/drivers/dri
Reviewed-by: Jason Ekstrand
On Thu, Jul 23, 2015 at 10:30 AM, Francisco Jerez wrote:
> Define bitfield packing, unpacking and type conversion operations in
> terms of which the image format conversion code will be implemented.
> These don't directly know about image formats: T
Reviewed-by: Jason Ekstrand
On Thu, Jul 23, 2015 at 10:31 AM, Francisco Jerez wrote:
> v2: Move array coordinate workaround into the surface builder.
> ---
> src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 106
> +++
> 1 file changed, 106 insertions(+)
&
901 - 1000 of 12089 matches
Mail list logo