On Mon, Feb 25, 2019 at 02:18:52PM -0800, Kenneth Graunke wrote:
> On Monday, February 25, 2019 11:01:33 AM PST Pohjolainen, Topi wrote:
> > On Mon, Feb 25, 2019 at 10:32:27AM -0800, Kenneth Graunke wrote:
> > > On Monday, February 25, 2019 6:33:11 AM PST Pohjolainen, Topi wro
On Mon, Feb 25, 2019 at 10:32:27AM -0800, Kenneth Graunke wrote:
> On Monday, February 25, 2019 6:33:11 AM PST Pohjolainen, Topi wrote:
> > On Thu, Nov 01, 2018 at 08:04:21PM -0700, Kenneth Graunke wrote:
> > > This implements virtually all documented PIPE_CONTROL restr
On Thu, Nov 01, 2018 at 08:04:21PM -0700, Kenneth Graunke wrote:
> This implements virtually all documented PIPE_CONTROL restrictions
> in a centralized helper. You now simply ask for the operations you
> want, and the pipe control "brain" will figure out exactly what pipe
> controls to emit to ma
On Thu, Nov 01, 2018 at 08:04:20PM -0700, Kenneth Graunke wrote:
> While this does add a bunch of boilerplate, it also protects us against
> the hardware moving bits, or changing their meaning. For something as
> finnicky as PIPE_CONTROL, the extra safety seems worth it.
>
> We turn PIPE_CONTROL_
On Thu, Jan 03, 2019 at 08:49:48AM +0100, Iago Toral wrote:
> On Wed, 2019-01-02 at 13:02 +0200, Pohjolainen, Topi wrote:
> > On Wed, Dec 19, 2018 at 12:51:19PM +0100, Iago Toral Quiroga wrote:
> > > ---
> > > .../compiler/brw_fs_combine_constants.cpp | 60
> &g
On Thu, Jan 03, 2019 at 07:50:03AM +0100, Iago Toral wrote:
> On Wed, 2019-01-02 at 11:35 +0200, Pohjolainen, Topi wrote:
> > On Wed, Dec 19, 2018 at 12:50:56PM +0100, Iago Toral Quiroga wrote:
> > > This is available since gen8.
> > > ---
> > > sr
On Wed, Dec 19, 2018 at 12:51:19PM +0100, Iago Toral Quiroga wrote:
> ---
> .../compiler/brw_fs_combine_constants.cpp | 60 +++
> 1 file changed, 49 insertions(+), 11 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_combine_constants.cpp
> b/src/intel/compiler/brw_fs_c
On Wed, Dec 19, 2018 at 12:51:17PM +0100, Iago Toral Quiroga wrote:
> ---
> src/intel/compiler/brw_fs_cmod_propagation.cpp | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_cmod_propagation.cpp
> b/src/intel/compiler/brw_fs_cmod_propagatio
Subject reads a little odd, maybe just: "assert strides in conversion
lowering". The assert itself seems useful:
Reviewed-by: Topi Pohjolainen
On Wed, Dec 19, 2018 at 12:51:09PM +0100, Iago Toral Quiroga wrote:
> The hardware only has two bits to specify the horizontal stride, so the
> maximum
On Wed, Dec 19, 2018 at 12:51:07PM +0100, Iago Toral Quiroga wrote:
> There are hardware restrictions to consider that seem to affect atom platforms
> only.
> ---
> src/intel/compiler/brw_fs_nir.cpp | 32 +++
> 1 file changed, 32 insertions(+)
Reviewed-by: Topi Pohjola
On Wed, Dec 19, 2018 at 12:51:08PM +0100, Iago Toral Quiroga wrote:
> ---
> src/intel/compiler/brw_fs_nir.cpp | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/compiler/brw_fs_nir.cpp
> index a9fd98bab68..57b
On Wed, Dec 19, 2018 at 12:51:06PM +0100, Iago Toral Quiroga wrote:
> These are not directly supported in hardware and brw_nir_lower_conversions
> should have taken care of that before we get here.
It looks that there are two things actually happening here:
1) For int64/uint64 to 8-case the suppo
On Wed, Dec 19, 2018 at 12:51:03PM +0100, Iago Toral Quiroga wrote:
> Broadwell hardware has a bug that manifests in SIMD8 executions of
> 16-bit MAD instructions when any of the sources is a Y or W component.
> We pack these components in the same SIMD register as components X and
> Z respectively
On Wed, Dec 19, 2018 at 12:50:56PM +0100, Iago Toral Quiroga wrote:
> This is available since gen8.
> ---
> src/intel/compiler/brw_reg_type.c | 35 +++
> 1 file changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/src/intel/compiler/brw_reg_type.c
> b/src/intel/
On Wed, Dec 19, 2018 at 12:50:54PM +0100, Iago Toral Quiroga wrote:
> From the Skylake PRM, Extended Math Function:
>
> "The execution size must be no more than 8 when half-floats
>are used in source or destination operand."
>
> Earlier generations do not support Extended Math with half-flo
On Wed, Dec 19, 2018 at 12:50:47PM +0100, Iago Toral Quiroga wrote:
> v2:
> - make 16-bit be its own separate case (Jason)
>
> Reviewed-by: Topi Pohjolainen (v1)
This version also.
> ---
> src/intel/compiler/brw_fs_nir.cpp | 18 +-
> 1 file changed, 17 insertions(+), 1 deletio
On Wed, Dec 19, 2018 at 12:50:44PM +0100, Iago Toral Quiroga wrote:
> There are some hardware restrictions that brw_nir_lower_conversions should
> have taken care of before we get here.
This patch and v2 of the previous:
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_fs_nir.cpp |
On Wed, Dec 19, 2018 at 12:50:42PM +0100, Iago Toral Quiroga wrote:
> Going forward having these split is a bit more convenient since these two
> groups have different restrictions.
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_fs_nir.cpp | 8
> 1 file changed, 8 inserti
On Wed, Dec 19, 2018 at 12:50:41PM +0100, Iago Toral Quiroga wrote:
> ---
> src/intel/compiler/brw_fs_nir.cpp | 55 ++-
> 1 file changed, 33 insertions(+), 22 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/inte
On Wed, Dec 19, 2018 at 12:50:40PM +0100, Iago Toral Quiroga wrote:
> 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.
I li
On Fri, Dec 14, 2018 at 08:47:23AM +0100, Iago Toral wrote:
> On Thu, 2018-12-13 at 12:49 +0200, Pohjolainen, Topi wrote:
> > On Thu, Dec 13, 2018 at 09:10:24AM +0100, Iago Toral wrote:
> > > On Wed, 2018-12-12 at 14:15 +0200, Pohjolainen, Topi wrote:
> > > > On W
On Thu, Dec 13, 2018 at 09:10:24AM +0100, Iago Toral wrote:
> On Wed, 2018-12-12 at 14:15 +0200, Pohjolainen, Topi wrote:
> > On Wed, Dec 12, 2018 at 09:48:20AM +0100, Iago Toral wrote:
> > > On Tue, 2018-12-11 at 18:59 +0200, Pohjolainen, Topi wrote:
> > > > On F
On Wed, Dec 12, 2018 at 09:48:20AM +0100, Iago Toral wrote:
> On Tue, 2018-12-11 at 18:59 +0200, Pohjolainen, Topi wrote:
> > On Fri, Dec 07, 2018 at 03:30:11PM +0200, Pohjolainen, Topi wrote:
> > > On Tue, Dec 04, 2018 at 08:17:05AM +0100, Iago Toral Quiroga wrote:
> > &
On Fri, Dec 07, 2018 at 03:30:11PM +0200, Pohjolainen, Topi wrote:
> On Tue, Dec 04, 2018 at 08:17:05AM +0100, Iago Toral Quiroga wrote:
> > This function is used in two different scenarios that for 32-bit
> > instructions are the same, but for 16-bit instructions are not.
> >
On Fri, Dec 07, 2018 at 12:08:15PM -0600, Jason Ekstrand wrote:
> On Wed, Dec 5, 2018 at 7:14 AM Pohjolainen, Topi
> wrote:
>
> > On Wed, Dec 05, 2018 at 02:04:16PM +0100, Iago Toral wrote:
> > > On Wed, 2018-12-05 at 14:58 +0200, Pohjolainen, Topi wrote:
> > >
On Tue, Dec 04, 2018 at 08:17:05AM +0100, Iago Toral Quiroga wrote:
> 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
On Tue, Dec 04, 2018 at 08:16:58AM +0100, Iago Toral Quiroga wrote:
> We use ALign16 mode for this, since it is more convenient, but the PRM
> for Broadwell states in Volume 3D Media GPGPU, Chapter 'Register region
> restrictions', Section '1. Special Restrictions':
>
>"In Align16 mode, the ch
On Tue, Dec 04, 2018 at 08:16:54AM +0100, Iago Toral Quiroga wrote:
> This optimization depends on two other optimization passes: the
> constant propagation pass, which allows immediate propagation
> on MAD/LRP instructions even though the hardware can't do it,
> and the combine constants pass to f
On Tue, Dec 04, 2018 at 08:16:50AM +0100, Iago Toral Quiroga wrote:
> We are now using these bits, so don't assert that they are not set, just
> avoid compaction in that case.
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_eu_compact.c | 5 -
> 1 file changed, 4 insertions(+),
On Tue, Dec 04, 2018 at 08:16:53AM +0100, Iago Toral Quiroga wrote:
> 3-src instructions don't support immediates, but since 36bc5f06dd22,
> we allow them on MAD and LRP relying on the combine constants pass to
> fix it up later. However, that pass is specialized for 32-bit float
> immediates and c
On Wed, Dec 05, 2018 at 02:04:16PM +0100, Iago Toral wrote:
> On Wed, 2018-12-05 at 14:58 +0200, Pohjolainen, Topi wrote:
> > On Tue, Dec 04, 2018 at 08:16:52AM +0100, Iago Toral Quiroga wrote:
> > > Source0 and Destination extract the floating-point precision
> > > a
Reviewed-by: Topi Pohjolainen
On Tue, Dec 04, 2018 at 08:16:51AM +0100, Iago Toral Quiroga wrote:
> ---
> 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 5
On Tue, Dec 04, 2018 at 08:16:52AM +0100, Iago Toral Quiroga wrote:
> 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
>
On Tue, Dec 04, 2018 at 08:16:48AM +0100, Iago Toral Quiroga wrote:
> 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 mix
On Wed, Dec 05, 2018 at 12:26:06PM +0100, Iago Toral wrote:
> On Wed, 2018-12-05 at 13:20 +0200, Pohjolainen, Topi wrote:
> > On Wed, Dec 05, 2018 at 11:53:44AM +0100, Iago Toral wrote:
> > > On Wed, 2018-12-05 at 11:39 +0200, Pohjolainen, Topi wrote:
> > > > I remem
On Tue, Dec 04, 2018 at 08:16:38AM +0100, Iago Toral Quiroga wrote:
> The hardware doesn't support half-float for these.
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_nir.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/intel/compiler/brw_nir.c b/src/intel/com
On Wed, Dec 05, 2018 at 11:23:06AM +0100, Iago Toral wrote:
> On Tue, 2018-12-04 at 18:16 +0200, Pohjolainen, Topi wrote:
> > On Tue, Dec 04, 2018 at 08:16:36AM +0100, Iago Toral Quiroga wrote:
> > > Since we handle booleans as integers this makes more sense.
> >
>
On Wed, Dec 05, 2018 at 11:53:44AM +0100, Iago Toral wrote:
> On Wed, 2018-12-05 at 11:39 +0200, Pohjolainen, Topi wrote:
> > I remember people preferring to order things 16, 32, 64 before.
> > Should
> > we follow that here as well?
>
> Yes, it makes sense. I'll
On Tue, Dec 04, 2018 at 08:16:47AM +0100, Iago Toral Quiroga wrote:
> From the Skylake PRM, Extended Math Function:
>
> "The execution size must be no more than 8 when half-floats
>are used in source or destination operand."
>
> Earlier generations do not support Extended Math with half-flo
I remember people preferring to order things 16, 32, 64 before. Should
we follow that here as well?
On Tue, Dec 04, 2018 at 08:16:46AM +0100, Iago Toral Quiroga wrote:
> ---
> src/compiler/nir/nir_opt_algebraic.py | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/compiler/nir/ni
On Wed, Dec 05, 2018 at 09:49:29AM +0100, Iago Toral wrote:
> On Tue, 2018-12-04 at 14:57 +0200, Pohjolainen, Topi wrote:
> > On Tue, Dec 04, 2018 at 08:16:35AM +0100, Iago Toral Quiroga wrote:
> > > From: Samuel Iglesias Gonsálvez
> > >
> > > It is not supp
On Wed, Dec 05, 2018 at 09:20:57AM +0100, Iago Toral wrote:
> On Tue, 2018-12-04 at 18:10 +0200, Pohjolainen, Topi wrote:
> > On Tue, Dec 04, 2018 at 02:33:25PM +0200, Pohjolainen, Topi wrote:
> > > On Tue, Dec 04, 2018 at 08:16:34AM +0100, Iago Toral Quiroga wrote:
> > &
On Tue, Dec 04, 2018 at 08:16:41AM +0100, Iago Toral Quiroga wrote:
> The PRM states that half-float operands are supported since gen9.
> ---
> src/intel/compiler/brw_eu_emit.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/inte
On Tue, Dec 04, 2018 at 08:16:40AM +0100, Iago Toral Quiroga wrote:
> ---
> src/intel/compiler/brw_fs_nir.cpp | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/com
On Tue, Dec 04, 2018 at 08:16:36AM +0100, Iago Toral Quiroga wrote:
> Since we handle booleans as integers this makes more sense.
If this is applied before patch 10, can we merge 10 and 13?
> ---
> src/intel/compiler/brw_fs_nir.cpp | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(
On Tue, Dec 04, 2018 at 02:33:25PM +0200, Pohjolainen, Topi wrote:
> On Tue, Dec 04, 2018 at 08:16:34AM +0100, Iago Toral Quiroga wrote:
> > Signed-off-by: Samuel Iglesias Gonsálvez
> > ---
> > src/intel/compiler/brw_fs_nir.cpp | 41 +++
&g
On Tue, Dec 04, 2018 at 08:16:35AM +0100, Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsálvez
>
> It is not supported directly in the HW, we need to convert to a 32-bit
> type first as intermediate step.
>
> v2 (Iago): handle conversions from 64-bit integers as well
>
> Signed-off-by: S
On Tue, Dec 04, 2018 at 08:16:34AM +0100, Iago Toral Quiroga wrote:
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/intel/compiler/brw_fs_nir.cpp | 41 +++
> 1 file changed, 41 insertions(+)
>
> diff --git a/src/intel/compiler/brw_fs_nir.cpp
> b/src/intel/comp
On Fri, Oct 12, 2018 at 01:46:59PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.c | 19 +++
> 1 file changed, 19 insertions(+)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index df4fb94a6fe..2513d2e73d1 100644
> --- a/src/
On Fri, Oct 12, 2018 at 01:46:58PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.c | 45 +++--
> 1 file changed, 35 insertions(+), 10 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 8
On Fri, Oct 12, 2018 at 01:46:57PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.c | 27 ++-
> 1 file changed, 14 insertions(+), 13 deletions(-)
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index c86390bf851..88de14
On Fri, Oct 12, 2018 at 01:46:56PM -0500, Jason Ekstrand wrote:
> Unfortunately, there is no nice way to calculate miptail offsets in
> closed form. Instead, we just copy the tables from the PRM directly
> verbatim.
> ---
> src/intel/isl/isl.c | 217 +++-
>
On Wed, Nov 07, 2018 at 11:17:38AM -0600, Jason Ekstrand wrote:
> On Wed, Nov 7, 2018 at 10:38 AM Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
> > On Fri, Oct 12, 2018 at 01:46:42PM -0500, Jason Ekstrand wrote:
> > > ---
> > > src/intel/isl
On Fri, Oct 12, 2018 at 01:46:55PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.c | 5 +
> src/intel/isl/isl.h | 7 +++
> 2 files changed, 12 insertions(+)
Matches PRM:
Reviewed-by: Topi Pohjolainen
>
> diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
> index 4a8380ad5
On Fri, Oct 12, 2018 at 01:46:54PM -0500, Jason Ekstrand wrote:
> This commit just adds a miptail start field to isl_surf and wires it up
> in the RENDER_SURFACE_STATE and 3DSTATE_DEPTH code. We also add a
> minimum miptail LOD so that client drivers have a knob to control the
> miptails a bit.
>
On Fri, Oct 12, 2018 at 01:46:42PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl_gen7.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/intel/isl/isl_gen7.c b/src/intel/isl/isl_gen7.c
> index f6f7e1ba7dc..fe420e4fbd8 100644
> --- a/src/intel/isl/isl_gen7.c
> +++ b/s
On Fri, Oct 12, 2018 at 01:46:47PM -0500, Jason Ekstrand wrote:
> It doesn't matter for the actual copy rectangle and this makes the
> asserts a bit nicer as we don't need to bother with the intratile
> offsets because there aren't any yet.
Reviewed-by: Topi Pohjolainen
> ---
> src/intel/blorp/
On Fri, Oct 12, 2018 at 01:46:39PM -0500, Jason Ekstrand wrote:
> The tile size calculations use a clever bit of math to make them short
> and simple. We add unit tests to assert that they identically match the
> tables in the PRM.
Compared both the equations and tests against the PRM:
Reviewed-
On Tue, Nov 06, 2018 at 02:08:32PM +0100, Connor Abbott wrote:
> On Tue, Nov 6, 2018 at 1:45 PM Pohjolainen, Topi
> wrote:
> >
> > On Tue, Nov 06, 2018 at 11:31:58AM +0100, Connor Abbott wrote:
> > > On Tue, Nov 6, 2018 at 11:14 AM Pohjolainen, Topi
> > > w
On Tue, Nov 06, 2018 at 11:31:58AM +0100, Connor Abbott wrote:
> On Tue, Nov 6, 2018 at 11:14 AM Pohjolainen, Topi
> wrote:
> >
> > On Tue, Nov 06, 2018 at 10:45:52AM +0100, Connor Abbott wrote:
> > > As far as I understand, mediump handling can be split into two par
On Fri, Oct 12, 2018 at 01:46:38PM -0500, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.c | 9 +++--
> src/intel/isl/isl.h | 12 ++--
> src/intel/isl/isl_drm.c | 2 ++
> src/intel/isl/isl_gen7.c | 8 +++-
> src/intel/isl/isl_surfa
On Tue, Nov 06, 2018 at 10:45:52AM +0100, Connor Abbott wrote:
> As far as I understand, mediump handling can be split into two parts:
>
> 1. Figuring out which operations (instructions or SSA values in NIR)
> can use relaxed precision.
> 2. Deciding which relaxed-precision operations to actually
On Tue, Nov 06, 2018 at 09:40:17AM +0100, Iago Toral wrote:
> On Tue, 2018-11-06 at 08:30 +0200, Topi Pohjolainen wrote:
> > Here is a version 2 of adding support for 16-bit float instructions
> > in
> > the shader compiler. Unlike the first version which did all the
> > analysis
> > at glsl level
On Thu, Sep 06, 2018 at 03:50:42PM -0500, Jason Ekstrand wrote:
> From: Topi Pohjolainen
>
> gen9 hardware has a bug in the sampler cache that can cause GPU hangs
> whenever an texture with aux compression enabled is in the sampler cache
> together with an ASTC5x5 texture. Because we can't contr
On Wed, Jul 11, 2018 at 09:27:23PM -0700, Nanley Chery wrote:
> The current behavior masked two bugs where the flag was not set to true
> after modifying the stencil texture. One case was a regression
> introduced with commit bdbb527a65fc729e7a9319ae67de60d03d06c3fd and
> another was a bug in the d
On Fri, Jul 06, 2018 at 03:39:26PM -0700, Nanley Chery wrote:
> These buffer objects are never accessed with the CPU.
Reviewed-by: Topi Pohjolainen
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/driver
On Fri, Jul 06, 2018 at 01:29:29PM -0700, Nanley Chery wrote:
> On Fri, Jul 06, 2018 at 03:36:01PM +0300, Pohjolainen, Topi wrote:
> > On Tue, Jun 12, 2018 at 12:21:52PM -0700, Nanley Chery wrote:
> > > This series fixes a couple stencil texturing bugs on HSW and
> > >
On Tue, Jun 12, 2018 at 12:21:52PM -0700, Nanley Chery wrote:
> This series fixes a couple stencil texturing bugs on HSW and
> cache-tracking for certain stencil BOs on all platforms.
>
> Nanley Chery (13):
> i965: Set the r8stencil flag in miptree_finish_write
> i965/miptree: Set the r8stenci
On Tue, Jun 12, 2018 at 12:22:05PM -0700, Nanley Chery wrote:
> Note that the separate stencil miptree now has the same alloc_flag as
> the depth component.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 29 ---
> 1 file changed, 6 insertions(+), 23 deletions(-)
>
> diff
On Fri, Jul 06, 2018 at 03:17:14PM +0300, Pohjolainen, Topi wrote:
> On Tue, Jun 12, 2018 at 12:22:02PM -0700, Nanley Chery wrote:
> > ---
> > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 40 ---
> > 1 file changed, 26 insertions(+), 14 deletions(-)
>
On Tue, Jun 12, 2018 at 12:22:02PM -0700, Nanley Chery wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 40 ---
> 1 file changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mip
On Tue, Jun 12, 2018 at 12:22:01PM -0700, Nanley Chery wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
On Wed, Jun 13, 2018 at 09:20:55AM -0700, Nanley Chery wrote:
> On Wed, Jun 13, 2018 at 09:33:41AM +0300, Pohjolainen, Topi wrote:
> > On Tue, Jun 12, 2018 at 12:22:00PM -0700, Nanley Chery wrote:
> > > ---
> > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 30 ++
On Wed, Jun 13, 2018 at 09:25:37AM -0700, Nanley Chery wrote:
> On Wed, Jun 13, 2018 at 09:39:08AM +0300, Pohjolainen, Topi wrote:
> > On Tue, Jun 12, 2018 at 12:22:02PM -0700, Nanley Chery wrote:
> > > ---
> > > src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 40 ++
On Tue, Jun 12, 2018 at 12:22:03PM -0700, Nanley Chery wrote:
> Enable a future patch to create the r8stencil_mt in this function.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 48 +--
> 1 file changed, 12 insertions(+), 36 deletions(-)
>
> diff --git a/src/mesa/drivers/
On Tue, Jun 12, 2018 at 12:22:02PM -0700, Nanley Chery wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 40 ---
> 1 file changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mip
On Tue, Jun 12, 2018 at 12:22:00PM -0700, Nanley Chery wrote:
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 30 +--
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> b/src/mesa/drivers/dri/i965/intel_mip
On Tue, Jun 12, 2018 at 12:21:56PM -0700, Nanley Chery wrote:
> Fix the case where only stencil writes are enabled on a depth stencil
Isn't this an issue even when depth writes are enabled? Both would add the
same bo to cache?
> texture. Found by inspection.
>
> ---
>
> I'm looking into writing
On Wed, May 16, 2018 at 02:00:28PM -0700, Nanley Chery wrote:
> Topi noticed that in intel_miptree_alloc_aux, we allowed CCS surface
> retrieval to fail, but asserted that HiZ and MCS surface retrieval would
> succeed. This series gets rid of that inconsistency and modifies some
> related assertion
On Wed, May 16, 2018 at 09:33:34AM -0700, Nanley Chery wrote:
> On Wed, May 16, 2018 at 09:11:38AM +0300, Pohjolainen, Topi wrote:
> > On Wed, May 09, 2018 at 10:47:24AM -0700, Nanley Chery wrote:
> > > v2: Inline the switch statement (Jason)
> > >
> &
On Wed, May 09, 2018 at 10:47:24AM -0700, Nanley Chery wrote:
> v2: Inline the switch statement (Jason)
>
> Reviewed-by: Jason Ekstrand
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 90 ---
> 1 file changed, 38 insertions(+), 52 deletions(-)
>
> diff --git a/src/mesa/d
On Tue, May 08, 2018 at 02:05:37PM -0700, Nanley Chery wrote:
> On Tue, May 08, 2018 at 08:31:39AM +0300, Pohjolainen, Topi wrote:
> > On Mon, May 07, 2018 at 10:11:39AM -0700, Nanley Chery wrote:
> > > On Mon, May 07, 2018 at 11:30:15AM +0300, Pohjolainen, Topi wrote:
> >
On Tue, May 08, 2018 at 02:55:24PM -0700, Nanley Chery wrote:
> On Tue, May 08, 2018 at 09:24:19AM +0300, Pohjolainen, Topi wrote:
> > On Thu, May 03, 2018 at 12:04:00PM -0700, Nanley Chery wrote:
> > > Although BLORP currently does the update when performing a fast clear,
> &
On Fri, May 11, 2018 at 04:48:17PM -0700, Jason Ekstrand wrote:
> Using meta for anything is fairly aweful and definitely has more CPU
> overhead. However, it also uses the 3D pipe and is therefore likely
> faster in terms of GPU time than the blitter. Also, the blitter code
> has so many early r
On Mon, May 14, 2018 at 10:08:35AM -0700, Jason Ekstrand wrote:
> On Mon, May 14, 2018 at 10:07 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
> > On Fri, May 11, 2018 at 04:48:24PM -0700, Jason Ekstrand wrote:
> > > We still support the blitter on ge
On Fri, May 11, 2018 at 04:48:26PM -0700, Jason Ekstrand wrote:
> It's clear that the original code meant to do this and there is even a
> 10-line comment explaining why. Originally, we had a simple function
> for packing the clear colors which was unaware of sRGB. However, in
> a6b66a7b26ae1, wh
On Fri, May 11, 2018 at 04:48:25PM -0700, Jason Ekstrand wrote:
> The only function that doesn't need to call access_raw is map_blit. If
> it takes the blitter path, it will happen as part of intel_miptree_copy.
> If map_blit takes the blorp path, no brw_blorp_copy_miptrees will handle
The part s
On Fri, May 11, 2018 at 04:48:24PM -0700, Jason Ekstrand wrote:
> We still support the blitter on gen4-5 but it's on the same ring as 3D.
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
Nothing amiss in the patch itself, o
On Fri, May 11, 2018 at 04:48:16PM -0700, Jason Ekstrand wrote:
> This patch series completely kills off our usage of the hardware blitter
> for Sandy Bridge and later. On Sandy Bridge, the blitter was moved to
> another ring and so using it incurs noticable synchronization overhead and,
> at the
On Fri, Jan 26, 2018 at 05:59:58PM -0800, Jason Ekstrand wrote:
> On CNL and above, CCS_E supports 1010102 formats and R11G11B10F. We had
> shut them off during early enabling because blorp_copy couldn't handle
> them. Now it can so we can turn them back on.
> ---
> src/intel/isl/isl_format.c |
On Tue, May 01, 2018 at 02:34:15PM -0700, Jason Ekstrand wrote:
> On Wed, Mar 7, 2018 at 5:08 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
> > On Fri, Jan 26, 2018 at 05:59:55PM -0800, Jason Ekstrand wrote:
> > > By making use of the NIR helper fo
On Mon, May 07, 2018 at 12:49:33PM -0700, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/gen6_depth_state.c | 34
> ++--
> src/mesa/drivers/dri/i965/gen7_misc_state.c | 32 +-
> src/mesa/drivers/dri/i965/gen8_depth_state.c | 28 +++
On Thu, May 03, 2018 at 12:04:00PM -0700, Nanley Chery wrote:
> Although BLORP currently does the update when performing a fast clear,
> it's simpler to do it ourselves. Remove the dependency on BLORP.
Should we note in the commit message that until patch 17 this now gets done
twice in a row in th
On Thu, May 03, 2018 at 12:03:58PM -0700, Nanley Chery wrote:
> Reduce code duplication now and prevent it in the following commits.
> ---
> src/mesa/drivers/dri/i965/brw_clear.c | 3 ++-
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 13 -
> src/mesa/drivers/dri/i965/intel
On Mon, May 07, 2018 at 11:04:20AM -0700, Nanley Chery wrote:
> On Mon, May 07, 2018 at 03:06:29PM +0300, Pohjolainen, Topi wrote:
> > On Thu, May 03, 2018 at 12:03:53PM -0700, Nanley Chery wrote:
> > > We have enough information to determine the optimal flags internally.
> &g
On Mon, May 07, 2018 at 10:11:39AM -0700, Nanley Chery wrote:
> On Mon, May 07, 2018 at 11:30:15AM +0300, Pohjolainen, Topi wrote:
> > On Thu, May 03, 2018 at 12:03:51PM -0700, Nanley Chery wrote:
> > > The indirect clear color isn't correctly tracked in
> > > inte
On Mon, May 07, 2018 at 11:30:12AM -0700, Nanley Chery wrote:
> On Mon, May 07, 2018 at 04:12:24PM +0300, Pohjolainen, Topi wrote:
> > On Thu, May 03, 2018 at 12:03:56PM -0700, Nanley Chery wrote:
> > > There isn't much that changes between the aux allocation functions.
>
On Mon, May 07, 2018 at 11:38:38AM -0700, Nanley Chery wrote:
> On Mon, May 07, 2018 at 11:12:26AM -0700, Nanley Chery wrote:
> > On Mon, May 07, 2018 at 03:36:54PM +0300, Pohjolainen, Topi wrote:
> > > On Thu, May 03, 2018 at 12:03:55PM -0700, Nanley Chery wrote:
> > &
On Mon, May 07, 2018 at 11:35:39AM -0700, Nanley Chery wrote:
> On Mon, May 07, 2018 at 10:10:16AM -0700, Nanley Chery wrote:
> > On Mon, May 07, 2018 at 11:51:50AM +0300, Pohjolainen, Topi wrote:
> > > On Fri, May 04, 2018 at 11:04:40AM -0700, Nanley Chery wrote:
> > >
On Thu, May 03, 2018 at 12:03:56PM -0700, Nanley Chery wrote:
> There isn't much that changes between the aux allocation functions.
> Remove the duplicated code.
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 227
> +++---
> src/mesa/drivers/dri/i965/intel_mipmap_tree
1 - 100 of 1507 matches
Mail list logo
