ponsible
> for the change? I ask because...
>
If it's one of the precise ones, we should port it to NIR...
> >
> > Suggested-by: Jason Ekstrand
> > ---
> > src/intel/compiler/brw_fs.cpp | 37 ---
> > 1 file changed, 37 deletions(-)
I'm done for the day but I've read through most of the patches. I think
I've got 4 or 5 tricky ones left. By and large, I think things are looking
really good. I don't know that we'll make 19.0 but there's a possibility.
If not, it'll likely land shortly after.
On Tue, Jan 15, 2019 at 7:54 AM
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> Reviewed-by: Topi Pohjolainen
> ---
> .../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
>
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> NIR already has these so they are redundant. A run of shader-db confirms
> that the only cases where these backend optimizations are activated
> are some Tomb Raider shaders where the affected
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> v2:
> - Do not propagate if the bit-size changes
> ---
> src/intel/compiler/brw_fs_cmod_propagation.cpp | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> d
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> 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
TYPE_D :
> +
> BRW_REGISTER_TYPE_F);
>
If it were me, I'd do
const brw_reg_type reg_type = reg->bit_size == 8 ? BRW_REGISTER_TYPE_B :
brw_reg_type_for_bit_size(reg->bit_size, BRW_REGISTER_TYPE_F);
I just find that a tiny bit easier to parse. Either way is fine though.
Revi
On Thu, Jan 17, 2019 at 5:11 PM Francisco Jerez
wrote:
> Subject is still inaccurate. How about "intel/fs: Don't touch
> accumulator destination while applying regioning alignment rule."
>
Sounds good to me. I'll fix it.
>
> Jason Ekstrand writes:
>
> &g
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> The changes in this version address review feedback to v2 and, most
> importantly,
> rebase on top of relevant changes in master, specifically Curro's regioning
> lowering pass. This new regioning pass simplifies some of the NIR
>
This patch doesn't really do what the commit message says. What it really
does is implement float -> 8-bit converions for *any* size float.
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> These are not directly supported in hardware and brw_nir_lower_conversions
> should have taken
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM 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 f
In some shaders, you can end up with a stride in the source of a
SHADER_OPCODE_MULH. One way this can happen is if the MULH is acting on
the top bits of a 64-bit value due to 64-bit integer lowering. In this
case, the compiler will produce something like this:
mul(8)acc0<1>UD g5<8,4,2>UD
On Thu, Jan 17, 2019 at 3:34 PM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > Bah... previous e-mail unfinished. Please ignore.
> >
> > On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
> > wrote:
> >
> >> Jason Ekstrand writes:
> >
rt(src0.type == BRW_REGISTER_TYPE_F || src0.type ==
BRW_REGISTER_TYPE_HF);
just to be sure? Either way, this and patch 20 are
Reviewed-by: Jason Ekstrand
> +
> + if (src2.type == BRW_REGISTER_TYPE_HF)
> +brw_inst_set_3src_a16_src2_type(devinfo, inst, 1);
>
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> We open coded this in a couple of places, so a helper function is probably
> sensible. Plus it makes it more consistent with the 3src hardware type
> case.
>
> Suggested-by: Topi Pohjolainen
> ---
> src/intel/compiler/brw_reg_type.c |
On Tue, Jan 15, 2019 at 7:55 AM 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(+), 1
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM 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."
>
> Earlie
Again, please squash with the previous patch. Splitting stuff this
granular just makes review harder.
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> Reviewed-by: Jason Ekstrand
> ---
> src/intel/compiler/brw_compiler.c | 1 +
> 1 file changed, 1 insertion(+)
>
>
Patches 10 and 11 really could be one patch.
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> Reviewed-by: Jason Ekstrand
> ---
> src/intel/compiler/brw_compiler.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/intel/compiler/brw_compiler.c
>
This should probably be squashed into patch 7 so that it's clear from one
patch that it's being properly handed on both sides of the gen9 boundary.
I'd also squash in patch 15 and just give the whole thing the title "Handle
extended math restrictions for half-float" with a detailed message
re going to whack
result.type (which is fine), just use result for the rest of it. With that
fixed,
Reviewed-by: Jason Ekstrand
> + bld.AND(result_int, op[0], brw_imm_uw(0x8000u));
> +
> + inst = bld.OR(result_int, result_int, brw_imm_uw(0x3c00u));
> + inst->pr
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:54 AM Iago Toral Quiroga
wrote:
> 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
Reviewed-by: Jason Ekstrand
On Tue, Jan 15, 2019 at 7:55 AM Iago Toral Quiroga
wrote:
> 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
On Tue, Jan 15, 2019 at 7:54 AM 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.
>
> v2:
> -
Yup, that'll do it. Gotta watch out for ++... Assuming it fixes the
problem, that patch is
Reviewed-by: Jason Ekstrand
On Thu, Jan 17, 2019 at 12:35 PM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Looking at the change the binding table emission, I think the image++ h
Reviewed-by: Jason Ekstrand
On Wed, Jan 16, 2019 at 1:32 AM Francisco Jerez
wrote:
> The docs are fairly incomplete and inconsistent about it, but this
> seems to be the reason why half-float destinations are required to be
> DWORD-aligned on BDW+ projects. This way the regioning
TM, so assuming it passes intel CI:
>
> Reviewed-by: Alejandro Piñeiro
>
> On 15/1/19 12:08, Sergii Romantsov wrote:
> > During conversion type-length was lost due to math.
> >
> > CC: Jason Ekstrand
> > Fixes: 44227453ec03 (nir: Switch to using 1-bit Booleans fo
On January 17, 2019 08:58:03 Erik Faye-Lund
wrote:
On Thu, 2019-01-17 at 14:37 +, Daniel Stone wrote:
Hi,
On Thu, 17 Jan 2019 at 07:38, Erik Faye-Lund
wrote:
1. New MRs should probably get their cover-letter automatically
sent to
the mailing list for incrased visibility.
[...]
I
Bah... previous e-mail unfinished. Please ignore.
On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > The pass was discovered to cause problems with the MUL+MACH combination
> > we emit for nir_[iu]mul_high. In an experimental bra
On Thu, Jan 17, 2019 at 4:15 AM Francisco Jerez
wrote:
> Jason Ekstrand writes:
>
> > The pass was discovered to cause problems with the MUL+MACH combination
> > we emit for nir_[iu]mul_high. In an experimental branch of mine, I ran
> > into issues where the MUL+MACH
The pass was discovered to cause problems with the MUL+MACH combination
we emit for nir_[iu]mul_high. In an experimental branch of mine, I ran
into issues where the MUL+MACH ended up using a strided source due to
working on half of a uint64_t and the new lowering pass helpfully tried
to fix the
Yup.
Reviewed-by: Jason Ekstrand
On Wed, Jan 16, 2019 at 6:08 AM Iago Toral wrote:
> Jason, does this version look good to you?
>
> On Mon, 2019-01-14 at 12:42 +0100, Iago Toral Quiroga wrote:
> > We had defined MAX_IMAGES as 8, which we used to size the array for
> > ima
On January 15, 2019 17:55:31 Matt Turner wrote:
On Tue, Jan 15, 2019 at 8:58 AM Jason Ekstrand wrote:
Previously, we only applied the fix to shaders with a dispatch mode of
SIMD8 but the code it relies on for SIMD16 mode only applies to SIMD16
instructions. If you have a SIMD8 instruction
On Tue, Jan 15, 2019 at 12:52 PM Eric Anholt wrote:
> Daniel Stone writes:
>
> > Hi,
> >
> > On Tue, 15 Jan 2019 at 12:21, Rob Clark wrote:
> >> On Tue, Jan 15, 2019 at 1:02 AM Tapani Pälli
> wrote:
> >> > On 1/14/19 2:36 PM, Daniel Stone wro
Previously, we only applied the fix to shaders with a dispatch mode of
SIMD8 but the code it relies on for SIMD16 mode only applies to SIMD16
instructions. If you have a SIMD8 instruction in a SIMD16 shader,
neither would trigger and the restriction could still be hit.
Cc: Jose Maria Casanova
On Mon, Jan 14, 2019 at 1:16 AM Iago Toral wrote:
> On Fri, 2019-01-11 at 12:31 -0600, Jason Ekstrand wrote:
>
>
> On Fri, Jan 11, 2019 at 3:21 AM Iago Toral wrote:
>
> On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> > ---
> > src/intel/vulkan/anv_devic
For a long time, we based exec sizes on destination register widths.
We've not been doing that since 1ca3a9442760b6f7 but a few remnants
accidentally remained.
---
src/intel/compiler/brw_eu_emit.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c
rkin
> >>
> >> [nouveau]
> >>
> >>> Acked-by: Eric Engestrom
> >>> Acked-by: Kenneth Graunke
> >>> Acked-by: Lionel Landwerlin
> >>> Acked-by: Jason Ekstrand
> >>> Reviewed-by: Matt Turner
> >>
> >
On January 12, 2019 03:06:07 Lionel Landwerlin
wrote:
On 12/01/2019 03:45, Jason Ekstrand wrote:
Instead of emitting all of the conditions for the cases of a switch
statement up-front, emit them on-the-fly as we emit the code for each
case. The original justification for this was that we
Even though no one's been brave enough to ever use this pass, I like to
keep it functionally working.
---
src/compiler/nir/nir_opt_gcm.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/compiler/nir/nir_opt_gcm.c b/src/compiler/nir/nir_opt_gcm.c
index 879a77a884b..e7d3f8ec424 100644
Instead of emitting all of the conditions for the cases of a switch
statement up-front, emit them on-the-fly as we emit the code for each
case. The original justification for this was that we were going to
have to build a default case anyway which would need them all. However,
we can just trust
Acked-by: Eric Engestrom
> Acked-by: Kenneth Graunke
> Acked-by: Lionel Landwerlin
> Acked-by: Jason Ekstrand
> Acked-by: Rob Clark
> Acked-by: Marek Olšák
> Reviewed-by: Christian Gmeiner
> Reviewed-by: Matt Turner
> Reviewed-by: Eric Anholt
> Signed-off-by: Gert Wol
A long time in a galaxy far far away, there was a GLSLang bug with how
it handled samplers passed in as function parameters. (The bug can be
found here: https://github.com/KhronosGroup/glslang/issues/179.)
Unfortunately, that version was shipped in several apps and has been
causing heartburn for
It's an optimization so we should probably be calling it in the
optimization loop.
---
src/intel/compiler/brw_nir.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 749c00ebcc6..92d7fe4bede 100644
---
Instead of applying the workaround universally, detect semi-old GLSLang
via the generator ID and only enable the workaround on old GLSLang.
This isn't nearly as precise as one would like it to be because the
first GLSLang generator id version bump was on October 7, 2017 which is
about 1.5 years
On Fri, Jan 11, 2019 at 1:55 PM Kenneth Graunke
wrote:
> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> > I think I kind of like having "mem" be on external things. Shared is a
> > little weird there because it never leaves the chip so is it mem
On Fri, Jan 11, 2019 at 1:50 PM Kenneth Graunke
wrote:
> On Friday, January 11, 2019 9:32:20 AM PST Eric Anholt wrote:
> > Jason Ekstrand writes:
> >
> > > On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke <
> kenn...@whitecape.org>
> > > wrote:
> &
On Fri, Jan 11, 2019 at 3:21 AM Iago Toral wrote:
> On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> > ---
> > src/intel/vulkan/anv_device.c | 28 ++
> > src/intel/vulkan/anv_extensions.py | 1 +
> > src/intel/vulkan/anv_pass.c| 37 +++
On Fri, Jan 11, 2019 at 2:19 AM Iago Toral wrote:
> On Mon, 2019-01-07 at 09:39 -0600, Jason Ekstrand wrote:
> > This function is modeled after the aux_op functions except that it
> > has a
> > lot more parameters because it deals with two images as well as
> > source
This merge request, which I've marked WIP, is trying to push ANV in a more
modern direction. Whereas most other drivers have abandon binding tables
in favour of descriptor buffers, we've been holding on to binding tables
like our lives depended on it. This MR attempts to start moving us into
the
tor of merge request to add/change
> tags if he doesn't have "Developer" role?
>
I'm not sure.
> - Maybe adding more tags/more granular tags would be a good idea.
> - Could Intel CI be integrated in some way with gitlab?
>
> Overall as someone who didn't interact with mai
On Fri, Jan 11, 2019 at 11:11 AM Kenneth Graunke
wrote:
> On Friday, January 11, 2019 8:33:41 AM PST Jason Ekstrand wrote:
> > On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke wrote:
> > > Those names (nir_var_func_local, nir_var_thread_local, and
> > > nir_var_thr
On Fri, Jan 11, 2019 at 9:13 AM Iago Toral Quiroga
wrote:
> We had defined MAX_IMAGES as 8, which we used to size the array for
> image push constant data. The comment there stated that this was for
> gen8, but anv_nir_apply_pipeline_layout runs for all gens and writes
> that array, asserting
ly
applied as part of the merging process. This makes merging a bit more
manual than it needs to be but is really no worse than it was before.
Ok, there you have my thoughts. I'd be happy to hear others.
--Jason
On Fri, Jan 11, 2019 at 10:57 AM Jason Ekstrand
wrote:
> All,
>
> The mesa
All,
The mesa project has now hit 100 merge requests (36 are still open). I
(and I'm sure others) would be curious to hear people's initial thoughts on
the process. What's working well? What's not working? Is it total fail
and should we go back to mailing lists?
--Jason
On Fri, Jan 11, 2019 at 10:19 AM Kenneth Graunke
wrote:
> On Wednesday, January 9, 2019 5:33:22 PM PST Ian Romanick wrote:
> > On 1/8/19 9:57 PM, Kenneth Graunke wrote:
> > > On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> > >> the naming is a bit confusing no matter how you
> Reviewed-by: Matt Turner
> Acked-by: Eric Engestrom
> Acked-by: Kenneth Graunke
>
Acked-by: Jason Ekstrand
> and I would probably include Jason and Marek in this group as well,
> though they did not offer a *-by.
>
> I don't think there's anything to continue deb
Topi just asked me on IRC what I thought about handling 16-bit booleans on
Intel hardware in the light of the 1-bit boolean stuff. The current state
of the driver is that we use nir_lower_bool_to_int32 pass to produce NIR
that looks basically identical to the NIR we were getting in the back-end
Pushed.
On Thu, Jan 10, 2019 at 10:35 AM Jason Ekstrand
wrote:
> Reviewed-by: Jason Ekstrand
>
> On Thu, Jan 10, 2019 at 5:57 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
>
>> Reviewed-by: Erik Faye-Lund
>>
>> On Thu, 2019-01-10 at 11
Reviewed-by: Jason Ekstrand
On Thu, Jan 10, 2019 at 5:57 AM Erik Faye-Lund
wrote:
> Reviewed-by: Erik Faye-Lund
>
> On Thu, 2019-01-10 at 11:23 +, Rhys Perry wrote:
> > Fixes: 393b59e0772e7bf0426bdf61c740752c4e09dde1
> > ('nir: Rework nir_lower_constant_ini
Anyone?
On Mon, Jan 7, 2019 at 9:39 AM Jason Ekstrand wrote:
> ---
> src/intel/vulkan/anv_device.c | 28 ++
> src/intel/vulkan/anv_extensions.py | 1 +
> src/intel/vulkan/anv_pass.c| 37 +++-
> src/intel/vulkan/anv_private.h | 3 +
>
Thanks to the new NIR load_descriptor intrinsic added by the UBO/SSBO
lowering series, we weren't getting UBO pushing because the UBO range
detection pass couldn't see the constants it needed. This fixes that
problem with a quick round of constant folding. Because we're folding
we no longer need
On Tue, Jan 8, 2019 at 11:57 PM Kenneth Graunke
wrote:
> On Tuesday, December 4, 2018 10:26:43 AM PST Karol Herbst wrote:
> > the naming is a bit confusing no matter how you look at it. Within SPIR-V
> > "global" memory is memory accessible from all threads. glsl "global"
> memory
> > normally
ACK
On Tue, Jan 8, 2019 at 12:27 PM Caio Marcelo de Oliveira Filho <
caio.olive...@intel.com> wrote:
> Initialize the variable with NULL. Fixes the following
>
> In file included from ../src/compiler/nir/nir_lower_io.c:34:
> ../src/compiler/nir/nir_lower_io.c: In function
>
On Tue, Jan 8, 2019 at 1:03 PM Karol Herbst wrote:
> On Mon, Jan 7, 2019 at 6:16 PM Jason Ekstrand
> wrote:
> >
> > On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> >>
> >> With OpenCL some system values match the address bits, but in GLSL we
> als
There are two things I'd like to land prior to the branch point (as an FYI):
- Rafiel's code to stop using userptr for ANV state pools (!11)
- VK_EXT_transform_feedback (!2)
Both are pretty close at this point so I think it's feasible.
--Jason
On Tue, Jan 8, 2019 at 11:52 AM Dylan Baker
We've had split send instructions in the hardware since Sky Lake but
haven't bothered to wire them up yet. In order to get there, this MR adds
a new SHADER_OPCODE_SEND opcode which does a generic send without all the
special-casing in fs_generator. At the end, it switches us to sends for
surface
Thanks! Pushed.
On Mon, Jan 7, 2019 at 9:46 AM Samuel Pitoiset
wrote:
> Acked-by: Samuel Pitoiset
>
> On 1/7/19 4:39 PM, Jason Ekstrand wrote:
> > ---
> > include/vulkan/vulkan.h | 2 +-
> > include/vulkan/vulkan_android.h | 2 +-
> &g
Reviewed-by: Jason Ekstrand
On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> Signed-off-by: Karol Herbst
> ---
> src/compiler/spirv/spirv_info.h| 1 +
> src/compiler/spirv/spirv_info_c.py | 1 +
> src/compiler/spirv/spirv_to_nir.c | 9 -
> src/compil
On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> Signed-off-by: Karol Herbst
> ---
> src/amd/vulkan/radv_meta_buffer.c | 8 ++--
> src/amd/vulkan/radv_meta_bufimage.c| 28 +++---
> src/amd/vulkan/radv_meta_clear.c | 4 +-
>
First off, thank you very much for cleaning this up!
On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> Signed-off-by: Karol Herbst
> ---
> src/compiler/nir/nir_builder_opcodes_h.py | 14 --
> src/compiler/nir/nir_lower_system_values.c| 4 ++--
>
On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> With OpenCL some system values match the address bits, but in GLSL we also
> have some system values being 64 bit like subgroup masks.
>
> With this it is possible to adjust the builder functions so that depending
> on the bit_sizes the
This seems reasonable. However, I'd like to ask that you land patch 5 ASAP
and wait a little while on landing this one. Having a at least couple
weeks with the rename but without adding back in nir_var_global with a
different meaning will increase the liklihood that merge conflicts will
result
Assuming it builds everywhere (probably best to double-check before pushing
anything)
Reviewed-by: Jason Ekstrand
On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> the naming is a bit confusing no matter how you look at it. Within SPIR-V
> "global" memory is memory acc
On Tue, Dec 4, 2018 at 12:27 PM Karol Herbst wrote:
> Signed-off-by: Karol Herbst
> ---
> src/compiler/nir/nir.h| 8
> src/compiler/nir/nir_clone.c | 1 +
> src/compiler/nir/nir_serialize.c | 2 ++
> src/compiler/spirv/spirv_to_nir.c | 26
at this list isn't sorted in any meaningful way.
I just sent out a patch to sort it. With that fixed and these put in the
right order, the first three patches are
Reviewed-by: Jason Ekstrand
> };
>
> typedef struct shader_info {
> diff --git a/src/compiler/spirv/spirv_to_nir.c
>
---
src/amd/vulkan/radv_shader.c| 24 -
src/compiler/shader_info.h | 34 -
src/intel/vulkan/anv_pipeline.c | 18 ++---
src/mesa/drivers/dri/i965/brw_context.c | 10
4 files changed, 43 insertions(+), 43
---
src/intel/vulkan/anv_device.c | 84 +--
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 2a3919d2949..cd179e6801c 100644
--- a/src/intel/vulkan/anv_device.c
+++
---
include/vulkan/vulkan.h | 2 +-
include/vulkan/vulkan_android.h | 2 +-
include/vulkan/vulkan_core.h| 155 +++-
include/vulkan/vulkan_fuchsia.h | 2 +-
include/vulkan/vulkan_ios.h | 2 +-
include/vulkan/vulkan_macos.h | 2
---
src/intel/vulkan/anv_blorp.c | 2 +-
src/intel/vulkan/anv_pass.c| 4 ++--
src/intel/vulkan/anv_private.h | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index 478b8e7a3db..eee7a8c3b3c 100644
---
---
src/intel/vulkan/anv_device.c | 28 ++
src/intel/vulkan/anv_extensions.py | 1 +
src/intel/vulkan/anv_pass.c| 37 +++-
src/intel/vulkan/anv_private.h | 3 +
src/intel/vulkan/genX_cmd_buffer.c | 136 +
5 files changed, 204
We may have to do transitions around certain kinds of resolves so it
helps to have it genX code.
---
src/intel/vulkan/anv_blorp.c | 66 --
src/intel/vulkan/anv_private.h | 2 -
src/intel/vulkan/genX_cmd_buffer.c | 61 ++-
3 files
This function is modeled after the aux_op functions except that it has a
lot more parameters because it deals with two images as well as source
and destination regions.
---
src/intel/vulkan/anv_blorp.c | 225 ++---
src/intel/vulkan/anv_private.h | 14 ++
2 files
---
src/intel/blorp/blorp.h | 2 ++
src/intel/blorp/blorp_blit.c | 62 +---
2 files changed, 52 insertions(+), 12 deletions(-)
diff --git a/src/intel/blorp/blorp.h b/src/intel/blorp/blorp.h
index 1e22712602d..bb83650092a 100644
--- a/src/intel/blorp/blorp.h
On Sat, Jan 5, 2019 at 2:40 PM Ilia Mirkin wrote:
> It looks like as of Chromium 71, nouveau is completely blacklisted.
>
That's rather unfortunate. :-( The intel mesa drivers were also
blacklisted for quite some time a while back. I'm not really sure what we
did to get blacklisted or what we
12:40 AM Ilia Mirkin wrote:
> >
> > On Fri, Jan 4, 2019 at 10:46 AM Jason Ekstrand
> wrote:
> > >
> > > On Fri, Jan 4, 2019 at 4:07 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > >>
> > >> On Thu, 2019-01-0
This new pass (which isn't even compile-tested) attempts to determine
the ALU type of all the SSA values in a function impl. It takes a
greedy approach and assigns intness or floatness to everything it thinks
can possibly contain an int or a float. Some values will be labled as
both int and
In 92eb5bbc68d7324 we attempted to avoid copying clear colors whenever
we weren't doing a resolve. However, this broke MSAA resolves because
we need the clear color in the source. This patch makes blorp much more
conservative such that it only avoids the clear color copy if either
aux_usage ==
On Fri, Jan 4, 2019 at 4:07 AM Erik Faye-Lund
wrote:
> On Thu, 2019-01-03 at 11:58 -0600, Jason Ekstrand wrote:
> > On Thu, Jan 3, 2019 at 3:39 AM Erik Faye-Lund <
> > erik.faye-l...@collabora.com> wrote:
> > > On Wed, 2019-01-02 at 10:16 -0600, Jason Ekstrand wrot
On Thu, Jan 3, 2019 at 2:03 PM Bas Nieuwenhuizen
wrote:
> On Thu, Jan 3, 2019 at 6:59 PM Jason Ekstrand
> wrote:
> >
> > On Thu, Jan 3, 2019 at 3:39 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> >>
> >> On Wed, 2019-01-02 at 10:16 -060
On Thu, Jan 3, 2019 at 1:37 PM Roland Scheidegger
wrote:
> Am 03.01.19 um 18:58 schrieb Jason Ekstrand:
> > On Thu, Jan 3, 2019 at 3:39 AM Erik Faye-Lund
> > mailto:erik.faye-l...@collabora.com>>
> wrote:
> >
> > On Wed, 2019-01-02 at 10:16 -0600, Jason E
On Thu, Jan 3, 2019 at 3:39 AM Erik Faye-Lund
wrote:
> On Wed, 2019-01-02 at 10:16 -0600, Jason Ekstrand wrote:
> > On Wed, Jan 2, 2019 at 9:43 AM Ilia Mirkin
> > wrote:
> > > Have a look at the first 4 patches in the series from Jonathan
> > > Marek
>
On Wed, Jan 2, 2019 at 9:43 AM Ilia Mirkin wrote:
> Have a look at the first 4 patches in the series from Jonathan Marek
> to address some of these issues:
>
> https://patchwork.freedesktop.org/series/54295/
>
> Not sure exactly what state that work is in, but I've added Jonathan
> to CC,
Finally! I haven't read the patch but whole-heartedly
Acked-by: Jason Ekstrand
On December 30, 2018 00:01:46 Kenneth Graunke wrote:
The original idea was that the backend compiler could eliminate
surfaces, so we would have it mark which ones are actually used,
then shrink the binding table
is R8G8B8A8_UNORM while the view is
R8G8B8A8_SRGB.
I think this might be the problem.
Currently looking at adding
anv_image_view_mcs_op/anv_image_view_ccs_op and see if that breaks the
world.
-
Lionel
On 21/12/2018 13:09, Jason Ekstrand wrote:
This isn't quite true. Fast-clear without CCS compression (also
This isn't quite true. Fast-clear without CCS compression (also known as
CCS_D) is supported on gen9. There is, however, a bug with blending and
non-0/1 clear colors that we don't currently bother handling in anv. See also:
On Wed, Dec 19, 2018 at 4:06 PM Bas Nieuwenhuizen
wrote:
> On Wed, Dec 19, 2018 at 8:45 PM Jason Ekstrand
> wrote:
> >
> > This is little more than an iadd_imm right now but it will help in the
> > next commit where we refactor things further.
> > ---
> &g
Fixes: 44227453ec03f "nir: Switch to using 1-bit Booleans for almost..."
Reviewed-by: Rhys Perry
---
src/amd/vulkan/radv_query.c | 42 ++---
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
On Wed, Dec 19, 2018 at 12:22 PM Eric Anholt wrote:
> Jonathan Marek writes:
>
> > Note: the backend must take care that uniform index is now a float
>
> This makes me think that lowering ints to float should be done near the
> end of the compile (followed by maybe an algebraic and a dce). As
Fixes: 44227453ec03f "nir: Switch to using 1-bit Booleans for almost..."
---
src/amd/vulkan/radv_query.c | 38 ++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index
401 - 500 of 12044 matches
Mail list logo
