Hi Faith,
thanks for starting the discussion, we had a bit of an internal chat
here at Igalia to see where we all stand on this and I am sharing some
initial thoughts/questions below:
El vie, 19-01-2024 a las 11:01 -0600, Faith Ekstrand escribió:
> Yeah, this one's gonna hit Phoronix...
>
>
This is great news, congratulations on this first milestone! :)
Iago
On Fri, 2022-03-04 at 09:26 -0800, Emma Anholt wrote:
> Welcome! I'm really excited to see this happening, and your early
> upstreaming work.
>
> On Fri, Mar 4, 2022 at 7:44 AM wrote:
> > Hi All,
> >
> > I'm excited to
On Sun, 2021-10-31 at 11:11 -0400, Michael Blumenkrantz wrote:
> Hi,
>
> I'd like to propose adding/changing two tags:
>
> * change `feature_request` -> `Feature` (this is barely used at
> present, so renaming shouldn't affect anyone negatively)
> * add `Bug`
>
> I would use these primarily for
Also, at runtime, you need to export this environment variable:
MESA_LOADER_DRIVER_OVERRIDE=zink
which will make sure Mesa selects zink instead of any other GL driver
available.
Iago
On Fri, 2021-02-05 at 11:29 +0200, Lionel Landwerlin wrote:
> I'm using these meson options :
>
>
>
>
Hi Lukas,
you need:
-Dgallium-drivers=v3d,vc4,kmsro
Iago
On Wed, 2021-01-06 at 12:22 +0100, li...@luckyxxl.de wrote:
> Hi all,
>
> In order to check whether a OpenGL ES driver bug I'm hitting on the
> Raspberry Pi 4 still appears in the latest Mesa version, I'm trying
> to
> build Mesa
Hi Jason, this is really cool! Very happy to see that support for ray
tracing is in the works!
Iago
On Wed, 2020-10-28 at 17:26 -0500, Jason Ekstrand wrote:
> All,
>
> Some of you may be curious about what I've been up to for most of
> 2020, why I've not been working on IBC, and why I suddenly
Hi Andreas,
that might indeed be something we want to do for Vulkan. I think moving
the defines is fine, however I think that before we start moving data
structures and types around we should probably have a very good
understanding of what we'll need for Vulkan, and that probably requires
that we
On Mon, 2019-05-06 at 14:32 -0500, Jason Ekstrand wrote:
> On Mon, May 6, 2019 at 9:01 AM Iago Toral Quiroga
> wrote:
> > From: Samuel Iglesias Gonsálvez
> >
> >
> >
> > There are tests in CTS for alpha to coverage without a color
> > attachment
>
-by: Iago Toral Quiroga
---
src/intel/vulkan/anv_pipeline.c | 56 -
1 file changed, 42 insertions(+), 14 deletions(-)
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index 20eab548fb2..f15f0896266 100644
--- a/src/intel/vulkan
-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
Signed-off-by: Samuel Iglesias Gonsálvez
Signed-off-by: Iago Toral Quiroga
---
src/intel/vulkan/anv_pipeline.c | 48 +
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/src/intel/vulkan/anv_pipeline.c b
On Thu, 2019-05-02 at 09:03 -0500, Jason Ekstrand wrote:
> 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.
a bit (Iago)
Fixes the following CTS tests:
dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
Signed-off-by: Samuel Iglesias Gonsálvez
Signed-off-by: Iago Toral Quiroga
---
src/intel/vulkan/anv_pipeline.c | 25 ++---
1 file changed, 18 insertions(+),
On Tue, 2019-04-30 at 17:29 -0500, Jason Ekstrand wrote:
> On Tue, Apr 30, 2019 at 4:36 AM Iago Toral wrote:
> > Hi Jason,
> >
> > it seems that this was never addressed so I'll try to take it from
> > here. A couple of comments regarding your feedback:
> >
Specifically, vkCmdCopyQueryPoolResults is required to see the effect
of a previous vkCmdResetQueryPool. This may not work currently when
query execution is still on going, as some of the queries may become
available asynchronously after the reset.
Fixes new CTS tests:
Hi Jason,
it seems that this was never addressed so I'll try to take it from
here. A couple of comments regarding your feedback:
We always setup a null render target if we don't have any, so I think
that part of the patch is not necessary. I checked that simply making
sure that we don't remove the
, Jason Ekstrand wrote:
> 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 <
> jasua...@igalia.com> wrote:
> > On Fri, 2019-03-22 at 17:53 +0100, Iago Toral wro
On Mon, 2019-04-08 at 12:00 -0700, Francisco Jerez wrote:
> "Juan A. Suarez Romero" writes:
>
> > From: Iago Toral Quiroga
> >
> > v2: f32to16/f16to32 can use a :W destination (Curro)
> > ---
> > src/intel/compiler/brw_fs.cpp | 71
> > +++
On Fri, 2019-03-22 at 13:23 -0500, Jason Ekstrand wrote:
> 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
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?
>
> None at all. Also, where are we at wi
> On 2/12/19 12:55 PM, Iago Toral Quiroga wrote:
> > The changes in this version address review feedback to v3. The most
> > significant
> > changes include:
> >
> > 1. A more generic constant combining pass that can handle more
> > constant types (not just F a
On Tue, 2019-03-12 at 15:46 -0700, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2019-03-06 at 09:21 +0100, Iago Toral wrote:
> > > On Tue, 2019-03-05 at 07:35 +0100, Iago Toral wrote:
> > > > On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wr
On Tue, 2019-03-12 at 15:44 -0700, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Tue, 2019-03-05 at 07:35 +0100, Iago Toral wrote:
> > > On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wrote:
> > > > Iago Toral writes:
> > > >
> >
On Wed, 2019-03-06 at 09:21 +0100, Iago Toral wrote:
> On Tue, 2019-03-05 at 07:35 +0100, Iago Toral wrote:
> > On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Fri, 2019-03-01 at 19:04 -0800, Francisco Je
On Tue, 2019-03-05 at 07:35 +0100, Iago Toral wrote:
> On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wrote:
> > Iago Toral writes:
> >
> > > On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
> > > > Iago Toral writes:
> > > >
> &
On Mon, 2019-03-04 at 15:36 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Thu, 2019-02-28 at 09:54 -0800, Francisco
Now that we propagate constants to the first source of 2src instructions we
see more opportunities of constant folding in the backend.
v2:
- The hardware only uses 5 bits (or 6 bits for Q/UQ) from the shift
count parameter in SHL/SHR instructions, so do the same in constant
propagation
And let combine constants promote the constants if needed.
---
src/intel/compiler/brw_fs_combine_constants.cpp | 2 ++
src/intel/compiler/brw_fs_copy_propagation.cpp | 4
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
Even if it is not supported by the hardware, we will fix it up
in the combine constants pass.
v2:
- This will enable new constant folding opportunities in the algebraic pass
for MUL or ADD with types other than F, so do not assert on that type.
For now we just skip anything that is not
to patch 2 to Jenkins and verified that
it came back green.
Iago Toral Quiroga (3):
intel/compiler: allow constant propagation for int quotient and
reminder
intel/compiler: allow constant propagation to first source of 2src
instructions
intel/compiler: implement more algebraic optimizations
On Thu, 2019-02-28 at 16:20 -0800, Ian Romanick wrote:
> On 2/28/19 4:47 AM, Iago Toral wrote:
> > On Wed, 2019-02-27 at 17:04 -0800, Ian Romanick wrote:
> > > On 2/27/19 4:45 AM, Iago Toral Quiroga wrote:
> > > > Now that we propagate constants to the first source o
On Fri, 2019-03-01 at 19:04 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Wed, 2019-02-27 at 13:47 -0800, Francisco
On Fri, 2019-03-01 at 09:39 +0100, Iago Toral wrote:
> On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
> > Iago Toral writes:
> >
> > > On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez wrote:
> > > > Iago Toral writes:
> > > >
> &
On Thu, 2019-02-28 at 09:54 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Tue, 2019-02-26 at 14:54 -0800, Francisco Jerez w
On Wed, 2019-02-27 at 17:04 -0800, Ian Romanick wrote:
> On 2/27/19 4:45 AM, Iago Toral Quiroga wrote:
> > Now that we propagate constants to the first source of 2src
> > instructions we
> > see more opportunities of constant folding in the backend.
> >
&
On Wed, 2019-02-27 at 17:04 -0800, Ian Romanick wrote:
> On 2/27/19 4:45 AM, Iago Toral Quiroga wrote:
> > Now that we propagate constants to the first source of 2src
> > instructions we
> > see more opportunities of constant folding in the backend.
> >
&
On Wed, 2019-02-27 at 15:44 -0800, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > The section 'Execution Data Types' of 3D Media GPGPU volume, which
> > describes execution types, is exactly the same in BDW and SKL+.
> >
> > Also, this section states th
On Wed, 2019-02-27 at 13:47 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Tue, 2019-02-26 at 14:54 -0800, Francisco Jerez wrote:
> > > Iago Toral Quiroga writes:
> > >
> > > > ---
> > > > src/intel/compiler/brw_eu_validat
Even if it is not supported by the hardware, we will fix it up
in the combine constants pass.
---
.../compiler/brw_fs_combine_constants.cpp | 37 ++---
.../compiler/brw_fs_copy_propagation.cpp | 55 +--
2 files changed, 56 insertions(+), 36 deletions(-)
diff
Now that we propagate constants to the first source of 2src instructions we
see more opportunities of constant folding in the backend.
Shader-db results on KBL:
total instructions in shared programs: 14965607 -> 14855983 (-0.73%)
instructions in affected programs: 3988102 -> 3878478 (-2.75%)
And let combine constants promote the constants if needed.
---
src/intel/compiler/brw_fs_combine_constants.cpp | 2 ++
src/intel/compiler/brw_fs_copy_propagation.cpp | 4
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
results, so that part has been
removed.
Iago
Iago Toral Quiroga (3):
intel/compiler: allow constant propagation for int quotient and
reminder
intel/compiler: allow constant propagation to first source of 2-src
instructions
intel/compiler: implement more algebraic optimizations
The section 'Execution Data Types' of 3D Media GPGPU volume, which
describes execution types, is exactly the same in BDW and SKL+.
Also, this section states that there is a single execution type, so it
makes sense that this is the wider of the two floating point types
involved in mixed float
On Tue, 2019-02-26 at 15:50 -0800, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > ---
> > src/intel/compiler/brw_eu_validate.c| 10 +-
> > src/intel/compiler/test_eu_validate.cpp | 46
> > +
> > 2 files c
On Tue, 2019-02-26 at 14:54 -0800, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > ---
> > src/intel/compiler/brw_eu_validate.c| 64 -
> > src/intel/compiler/test_eu_validate.cpp | 122
> >
> > 2 files ch
On Tue, 2019-02-26 at 13:55 -0800, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> > The section 'Execution Data Types' of 3D Media GPGPU volume, which
> > describes execution types, is exactly the same in BDW and SKL+.
> >
> > Also, this section states th
ns aren't my strongest
> area.
>
>
> On Tue, Feb 12, 2019 at 5:56 AM Iago Toral Quiroga > wrote:
> > The section 'Execution Data Types' of 3D Media GPGPU volume, which
> >
> > describes execution types, is exactly the same in BDW and SKL+.
> >
> >
We are now lowering isign in NIR so this patch is no longer needed.
Iago
On Tue, 2019-02-12 at 12:55 +0100, Iago Toral Quiroga wrote:
> Reviewed-by: Jason Ekstrand
> ---
> src/intel/compiler/brw_fs_nir.cpp | 25 +
> 1 file changed, 21 insertions(+),
to convince myself that it doesn't make the compiler
> significantly more bogus than it already is today.
>
> On Tue, Feb 12, 2019 at 5:57 AM
> Iago Toral Quiroga wrote:
> > The changes in this version address review feedback to v3. The most
> > significant
> >
On Sat, 2019-02-16 at 09:42 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 5:56 AM Iago Toral Quiroga > wrote:
> > ---
> >
> > src/intel/compiler/brw_eu_validate.c| 10 +-
> >
> > src/intel/compiler/test_eu_validate.cpp | 46
> > +
On Sat, 2019-02-16 at 09:40 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 11:53 AM Iago Toral Quiroga <
> ito...@igalia.com> wrote:
> > ---
> >
> > src/intel/compiler/brw_eu_validate.c| 64 -
> >
> > src
On Sat, 2019-02-16 at 09:29 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 5:57 AM Iago Toral Quiroga > wrote:
> > At the very least we need it to handle HF too, since we are doing
> >
> > constant propagation for MAD and LRP, which relies on this pass
> >
On Sat, 2019-02-16 at 09:02 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 5:56 AM Iago Toral Quiroga > wrote:
> > Empirical testing shows that gen8 has a bug where MAD instructions
> > with
> >
> > a half-float source starting at a non-zero offset fai
Some conversions are not directly supported in hardware and need to be
split in two conversion instructions going through an intermediary type.
Doing this at the NIR level simplifies a bit the complexity in the backend.
v2:
- Consider fp16 rounding conversion opcodes
- Properly handle swizzles
On Thu, 2019-02-14 at 16:59 -0600, Jason Ekstrand wrote:
> On Tue, Feb 12, 2019 at 5:56 AM Iago Toral Quiroga > wrote:
> > Some conversions are not directly supported in hardware and need to
> > be
> >
> > split in two conversion instructions going th
On Tue, 2019-02-12 at 08:43 -0600, Jason Ekstrand wrote:
> On February 12, 2019 05:57:09 Iago Toral Quiroga
> wrote:
>
> > v2:
> > - Merge Float16 and Int8 capabilities into a single patch (Jason)
> > - Merged patch that enabled SPIR-V front-end checks for these c
---
src/intel/compiler/brw_eu_validate.c| 64 -
src/intel/compiler/test_eu_validate.cpp | 122
2 files changed, 185 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index
Going forward having these split is a bit more convenient since these two
groups have different restrictions.
v2:
- Rebased on top of new regioning lowering pass.
Reviewed-by: Topi Pohjolainen (v1)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 7 +++
1 file changed,
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 3a6e4a2eb60..40c0481ac53 100644
---
We are now using these bits, so don't assert that they are not set. In gen8,
if these bits are set compaction is not possible. On gen9 and CHV platforms
set_3src_control_index() checks these bits (and others) against a table to
validate if the particular bit combination is eligible for compaction
Source0 and Destination extract the floating-point precision automatically
from the SrcType and DstType instruction fields respectively when they are
set to types :F or :HF. For Source1 and Source2 operands, we use the new
1-bit fields Src1Type and Src2Type, where 0 means normal precision and 1
v2:
- make 16-bit be its own separate case (Jason)
v3:
- Drop the result_int temporary (Jason)
Reviewed-by: Topi Pohjolainen (v1)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git
The original SrcType is a 3-bit field that takes a subset of the types
supported for the hardware for 3-source instructions. Since gen8,
when the half-float type was added, 3-source floating point operations
can use use mixed precision mode, where not all the operands have the
same floating-point
This is set to True only for numeric conversion opcodes.
---
src/compiler/nir/nir.h| 3 ++
src/compiler/nir/nir_opcodes.py | 73 +--
src/compiler/nir/nir_opcodes_c.py | 1 +
3 files changed, 44 insertions(+), 33 deletions(-)
diff --git
---
src/intel/compiler/brw_eu_validate.c| 256 ++
src/intel/compiler/test_eu_validate.cpp | 618
2 files changed, 874 insertions(+)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index ed9c8fe59dd..a61d4c46e81 100644
This function is used in two different scenarios that for 32-bit
instructions are the same, but for 16-bit instructions are not.
One scenario is that in which we are working at a SIMD8 register
level and we need to know if a register is fully defined or written.
This is useful, for example, in
for testing in the
itoral/VK_KHR_shader_float16_int8 branch of the Igalia Mesa repository at
https://github.com/Igalia/mesa.
Iago Toral Quiroga (40):
compiler/nir: add an is_conversion field to nir_op_info
intel/compiler: add a NIR pass to lower conversions
intel/compiler: split float to 64-bit
This is available since gen8.
v2: restore previously existing assertion.
v3: don't use separate tables for gen7 and gen8, just assert that we
don't use half-float before gen8 (Matt)
Reviewed-by: Topi Pohjolainen (v1)
---
src/intel/compiler/brw_reg_type.c | 4
1 file changed, 4
And enable it on Intel.
v2:
- Squash the change to enable this lowering on Intel (Jason)
Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir.h| 1 +
src/compiler/nir/nir_opt_algebraic.py | 1 +
src/intel/compiler/brw_compiler.c | 1 +
3 files changed, 3 insertions(+)
Since we handle booleans as integers this makes more sense.
v2:
- rebased to incorporate new boolean conversion opcodes
v3:
- rebased on top regioning lowering pass
Reviewed-by: Jason Ekstrand (v1)
Reviewed-by: Topi Pohjolainen (v2)
---
src/intel/compiler/brw_fs_nir.cpp | 16
The section 'Execution Data Types' of 3D Media GPGPU volume, which
describes execution types, is exactly the same in BDW and SKL+.
Also, this section states that there is a single execution type, so it
makes sense that this is the wider of the two floating point types
involved in mixed float
Mixed float instructions are those that use both F and HF operands as their
sources or destination, except for regular conversions.
There are specific rules for mixed float operation mode with its own set
of restrictions, which involve rules that are incompatible with general
restrictions. For
v2 (Topi):
- Make bit-size handling order be 16-bit, 32-bit, 64-bit
- Clamp lower exponent range at -28 instead of -30.
Reviewed-by: Topi Pohjolainen
Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir_opt_algebraic.py | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
Now that we have the regioning lowering pass we can just put all of these
opcodes together in a single block and we can just assert on the few cases
of conversion instructions that are not supported in hardware and that should
be lowered in brw_nir_lower_conversions.
The only cases what we still
v2:
- Merge Float16 and Int8 capabilities into a single patch (Jason)
- Merged patch that enabled SPIR-V front-end checks for these caps
(except for Int8, which was already merged)
Reviewed-by: Jason Ekstrand (v1)
---
src/compiler/shader_info.h| 1 +
There are no 8-bit immediates, so assert in that case.
16-bit immediates are replicated in each word of a 32-bit immediate, so
we only need to check the lower 16-bits.
v2:
- Fix is_zero with half-float to consider -0 as well (Jason).
- Fix is_negative_one for word type.
Reviewed-by: Jason
v2:
- Fixed typo: meant BRW_REGISTER_TYPE_UB instead BRW_REGISTER_TYPE_UV
Reviewed-by: Jason Ekstrand (v1)
---
src/intel/compiler/brw_reg_type.h | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/intel/compiler/brw_reg_type.h
b/src/intel/compiler/brw_reg_type.h
index
Broadwell has restrictions that apply to Align16 half-float that
make the Align16 implementation of this invalid for this platform.
Use the gen11 path for this instead, which uses Align1 mode.
The restriction is not present in cherryview, gen9 or gen10, where
the Align16 implementation seems to
At the very least we need it to handle HF too, since we are doing
constant propagation for MAD and LRP, which relies on this pass
to promote the immediates to GRF in the end, but ideally
we want it to support even more types so we can take advantage
of it to improve register pressure in some
The hardware only allows a stride of 1 on a Byte destination for raw
byte MOV instructions. This is required even when the destination
is the NULL register.
Rather than making sure that we emit a proper NULL:B destination
every time we need one, just fix it at emission time.
Reviewed-by: Jason
v2:
- Assign BRW_REGISTER_TYPE_B directly for 8-bit (Jason)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index
v2:
- Do not propagate if the bit-size changes
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_cmod_propagation.cpp | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp
---
src/intel/compiler/brw_eu_validate.c| 10 +-
src/intel/compiler/test_eu_validate.cpp | 46 +
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_validate.c
b/src/intel/compiler/brw_eu_validate.c
index
We were assuming 32-bit elements. Also, In SIMD8 we pack 2 vector components
in a single SIMD register, so for example, component Y of a 16-bit vec2
starts is at byte offset 16B. This means that when we compute the offset of
the elements to be differentiated we should not stomp whatever base
So it is right after the checks for the other various Int* capabilities.
---
src/compiler/spirv/spirv_to_nir.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index 1cbc926c818..7e07de2bfc0 100644
And enable it on Intel.
v2:
- Squash the change to enable it on Intel (Jason)
Reviewed-by: Jason Ekstrand
---
src/compiler/nir/nir.h| 1 +
src/compiler/nir/nir_opt_algebraic.py | 1 +
src/intel/compiler/brw_compiler.c | 1 +
3 files changed, 3 insertions(+)
diff --git
Some conversions are not directly supported in hardware and need to be
split in two conversion instructions going through an intermediary type.
Doing this at the NIR level simplifies a bit the complexity in the backend.
v2:
- Consider fp16 rounding conversion opcodes
- Properly handle swizzles
v2 (Jason):
- Merge shaderFloat16 and shaderInt8 enablement into a single patch.
- Merge extension enable.
Reviewed-by: Jason Ekstrand (v1)
---
src/intel/vulkan/anv_device.c | 9 +
src/intel/vulkan/anv_extensions.py | 1 +
2 files changed, 10 insertions(+)
diff --git
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 64e24f86b5a..f59e9ad4e2b 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++
Extended math with half-float operands is only supported since gen9,
but it is limited to SIMD8. In gen8 we lower it to 32-bit.
v2: quashed together the following patches (Jason):
- intel/compiler: allow extended math functions with HF operands
- intel/compiler: lower 16-bit extended math to
Particularly, we need the same lowewrings we use for 16-bit
integers.
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_nir.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 9b26a6c3d6f..1d62f2adde8
NIR already has these and correctly considers exact/inexact qualification,
whereas the backend doesn't and can apply the optimizations where it
shouldn't. This happened to be the case in a handful of Tomb Raider shaders,
where NIR would skip the optimizations because of a precise qualification
but
Reviewed-by: Topi Pohjolainen
Reviewed-by: Jason Ekstrand
Reviewed-by: Matt Turner
---
src/intel/compiler/brw_eu_emit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 2f31d9591fc..30037e71b00
It is very likely that this optimzation is never useful and we'll probably
just end up removing it, so let's not bother adding more cases to it for
now.
---
src/intel/compiler/brw_fs.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/compiler/brw_fs.cpp
Empirical testing shows that gen8 has a bug where MAD instructions with
a half-float source starting at a non-zero offset fail to execute
properly.
This scenario usually happened in SIMD8 executions, where we used to
pack vector components Y and W in the second half of SIMD registers
(therefore,
The hardware doesn't support half-float for these.
Reviewed-by: Topi Pohjolainen
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_nir.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 7e3dbc9e447..75513e5113c
There are some hardware restrictions that brw_nir_lower_conversions should
have taken care of before we get here.
v2:
- rebased on top of regioning lowering pass
Reviewed-by: Topi Pohjolainen (v1)
Reviewed-by: Jason Ekstrand
---
src/intel/compiler/brw_fs_nir.cpp | 5 +++--
1 file changed, 3
On Mon, 2019-02-04 at 08:50 +0100, Iago Toral wrote:
> On Fri, 2019-02-01 at 11:23 -0800, Francisco Jerez wrote:
> > Iago Toral writes:
> >
> > > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> > > > Iago Toral writes:
> > > >
> &
On Fri, 2019-02-01 at 11:23 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Thu, 2019-01-24 at 11:45 -0800, Francisco
On Fri, 2019-02-01 at 12:34 +0100, Iago Toral wrote:
> On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> > Iago Toral writes:
> >
> > > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote:
> > > > Iago Toral writes:
> > > >
> &
On Fri, 2019-01-25 at 12:54 -0800, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Thu, 2019-01-24 at 11:45 -0800, Francisco Jerez wrote:
> > > Iago Toral writes:
> > >
> > > > On Wed, 2019-01-23 at 06:03 -0800, Francisco Jerez w
1 - 100 of 3144 matches
Mail list logo
