rez wrote:
> Jason Ekstrand writes:
>
>> *whew*, I've made it through the entire series...
>>
> Thanks!
>
>> On Tue, Jul 21, 2015 at 9:38 AM, Francisco Jerez
>> wrote:
>>> Another resend of the i965 compiler-related changes for
>>> A
On Thu, Jul 23, 2015 at 4:38 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> This all looks correct as far as I can tell. However, I'm very
>> concerned about the number of checks such as
>> has_matching_typed_format() that are built-in to the compiler (via
On Fri, Jul 31, 2015 at 6:15 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Thu, Jul 23, 2015 at 4:38 AM, Francisco Jerez
>> wrote:
>>> Jason Ekstrand writes:
>>>
>>>> This all looks correct as far as I can tell. However, I'
t that 18ms represents about 50% of the time it takes
> to start X, though why X instantiates an intel_screen at all remains a
> mystery).
>
> Signed-off-by: Chris Wilson
> Cc: Matt Turner
> Cc: Jason Ekstrand
> Cc: Martin Peres ---
> src/mesa/drivers/dri/i965/brw_fs_
On Fri, Jul 31, 2015 at 9:38 AM, Chris Wilson wrote:
> On Fri, Jul 31, 2015 at 09:30:36AM -0700, Jason Ekstrand wrote:
>> This patch looks really sketchy to me. First, you fundamentally
>> changed some of register_allocate's internal data structures with no
>> explana
All this commit does is change an early return to an if with an else
clause.
---
src/util/register_allocate.c | 51 ++--
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index 95be20f
. This series also contains a patch to avoid setting up registers
more times than needed on platforms where RA is the same for SIMD8 vs
SIMD16.
The whole series seems to cut about 4 minutes off a piglit run on BYT. It
usually takes around 31 minutes and this time it ran in 27.
Jason Ekstrand (5
I'm not 100% sure that this is the right patch. Instead of baking 256 into
the allocator, we could allow the user to pass in an initial constant.
Since the maximum is statically known, we could also make said constant a
hard limit and allocate everything up-front in a single array and save all
the
reg_width is kind of an outdated concept.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 6a7ed64.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index 211f70e..512da22 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocat
They are never used after the set is finalized so there's no reason to keep
them around.
---
src/util/register_allocate.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index 129d58d..436e008 100644
--- a/src/util/register_alloc
This looks better. Sorry I didn't catch the scalar vs problems before.
R-B
On Aug 1, 2015 5:16 AM, "Eduardo Lima Mitev" wrote:
> The upcoming introduction of NIR->vec4 pass will require that some NIR
> lowering
> passes are enabled/disabled depending on the type of shader (scalar vs.
> vector).
>
LGTM RB
On Aug 1, 2015 5:16 AM, "Eduardo Lima Mitev" wrote:
> From: Antia Puentes
>
> ---
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 47
> +-
> 1 file changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> b/src/mesa/
On Aug 3, 2015 4:17 AM, "Eduardo Lima Mitev" wrote:
>
> On 08/01/2015 02:59 PM, Eduardo Lima Mitev wrote:
> > On 07/31/2015 10:48 AM, Eduardo Lima Mitev wrote:
> >> On 07/30/2015 09:48 PM, Jason Ekstrand wrote:
> >>>
> >>> On
On Mon, Aug 3, 2015 at 8:54 AM, Eduardo Lima Mitev wrote:
> On 08/03/2015 04:57 PM, Jason Ekstrand wrote:
>>
>> On Aug 3, 2015 4:17 AM, "Eduardo Lima Mitev" > <mailto:el...@igalia.com>> wrote:
>>>
>>> On 08/01/2015 02:59 PM, Eduardo Lima
The analysis code was already there and running, we just weren't doing
anything with the result of it yet.
---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw_v
ly ok. We
should definitely verify that at some point.
I'm not 100% sure what I think about the first two patches. They actually
end up canceling each other out in effect. However, I do think that the
end result is better. Opinions welcome.
Jason Ekstrand (5):
i965/nir: Use nir_op_info.
---
.../dri/i965/brw_nir_analyze_boolean_resolves.c| 23 ++
1 file changed, 23 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_nir_analyze_boolean_resolves.c
b/src/mesa/drivers/dri/i965/brw_nir_analyze_boolean_resolves.c
index d1fc06d..c995d2b 100644
--- a/src/me
On BDW+, the negation source modifier on NOT, AND, OR, and XOR, is actually
a boolean negate and not an integer negate. However, NIR's soruce
modifiers are the integer version. We have to resolve it with a MOV prior
to emitting the actual instruction. This is basically the same thing we do
in th
Previously, we were explicitly listing every instruction that needs a
resolve. However, those instructions were precicely the ones that returned
booleans so there's no reason why we shouldn't just have that check. Also,
all of the reduction opcodes such as bany and ball were missing so it
didn't
---
src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 52 --
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
index 1b7fb5e..7251ca0 100644
--- a/src/mesa/drivers/dri/i965
On Mon, Aug 3, 2015 at 9:51 AM, Jason Ekstrand wrote:
> On Mon, Aug 3, 2015 at 8:54 AM, Eduardo Lima Mitev wrote:
>> On 08/03/2015 04:57 PM, Jason Ekstrand wrote:
>>>
>>> On Aug 3, 2015 4:17 AM, "Eduardo Lima Mitev" >> <mailto:el...@igalia.com>&
On Mon, Aug 3, 2015 at 6:12 PM, Eric Anholt wrote:
> Jason Ekstrand writes:
>
>> I'm not 100% sure that this is the right patch. Instead of baking 256 into
>> the allocator, we could allow the user to pass in an initial constant.
>> Since the maximum is statically k
On Tue, Aug 4, 2015 at 2:42 AM, AntÃa Puentes wrote:
> Hi! Jason,
>
> On lun, 2015-08-03 at 17:25 -0700, Jason Ekstrand wrote:
>> On Mon, Aug 3, 2015 at 9:51 AM, Jason Ekstrand wrote:
>
>> > I also pushed a version to our CI system that switched the
>> > INTE
On Tue, Aug 4, 2015 at 5:09 PM, Jordan Justen wrote:
> I checked the extension spec, and it appears that like image
> load/store, ssbo is only required in fragment and compute stages. I
> don't think the ssbo support in vec4 is quite as problematic as image
> load/store, so I'm not sure this infor
On Tue, Aug 4, 2015 at 5:54 PM, Jason Ekstrand wrote:
> On Tue, Aug 4, 2015 at 5:09 PM, Jordan Justen
> wrote:
>> I checked the extension spec, and it appears that like image
>> load/store, ssbo is only required in fragment and compute stages. I
>> don't think the
You can have my R-B on both patches too.
On Wed, Aug 5, 2015 at 11:14 AM, Connor Abbott wrote:
> FWIW, both patches are:
>
> Reviewed-by: Connor Abbott
>
> I'm working on FP64 support (I've been using no16 up till now) so this
> is obviously very useful to me.
>
> On Wed, Aug 5, 2015 at 10:38 AM
Shader-db results for vec4 programs using NIR on HSW:
total instructions in shared programs: 1838157 -> 1828469 (-0.53%)
instructions in affected programs: 275978 -> 266290 (-3.51%)
helped:2827
HURT: 244
GAINED:
Out of pure curiosity, why did you choose to do this at the GLSL IR
level? Why not pass it through to NIR and do the lowering there? Not
that you *should* do it there, but I'm curious as to what motivated
the choice. I'm honestly not sure which would have been easier.
--Jason
On Thu, Aug 6, 201
-P
> On Fri, Aug 7, 2015 at 5:56 PM, Jason Ekstrand wrote:
>> Out of pure curiosity, why did you choose to do this at the GLSL IR
>> level? Why not pass it through to NIR and do the lowering there? Not
>> that you *should* do it there, but I'm curious as to what motivate
On Fri, Jul 31, 2015 at 9:58 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Fri, Jul 31, 2015 at 6:15 AM, Francisco Jerez
>> wrote:
>>> Jason Ekstrand writes:
>>>
>>>> On Thu, Jul 23, 2015 at 4:38 AM, Francisco Jerez
>>>
dims =
> +(surf_dims == 1 && arr_dims == 1 && array_index_at_z ? 1 : 0);
Would you mind putting parens around the three equalities. I don't
want to have to think about whether "&&" or "? :" comes first in
precedence order. Other th
I'm not 100% sure what's going on here but Topi reviewed it and it all
looks sane to me, so
Acked-by: Jason Ekstrand
On Mon, Jul 20, 2015 at 9:23 AM, Francisco Jerez wrote:
> v2: Add CS support. Move the image_params array back to
> brw_stage_prog_data.
> ---
> src
Reviewed-by: Jason Ekstrand
On Mon, Jul 20, 2015 at 9:23 AM, Francisco Jerez wrote:
> v2: Add CS support.
> ---
> src/mesa/drivers/dri/i965/brw_cs.cpp | 3 ++-
> src/mesa/drivers/dri/i965/brw_gs.c | 1 +
> src/mesa/drivers/dri/i965/brw_vs.c | 3 ++-
> src/mesa/drivers
Thanks for adding the comments.
Reviewed-by: Jason Ekstrand
On Thu, Aug 6, 2015 at 7:19 AM, Francisco Jerez wrote:
> Francisco Jerez writes:
>
>> "Pohjolainen, Topi" writes:
>>
>>> On Wed, Aug 05, 2015 at 12:11:02PM +0300, Pohjolainen, Topi wrote:
&g
On Wed, May 13, 2015 at 9:43 AM, Francisco Jerez wrote:
> v2: Add SKL support.
> ---
> src/mesa/drivers/dri/i965/brw_context.h | 2 +
> src/mesa/drivers/dri/i965/brw_surface_formats.c | 109
> +++
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 77 ++
I'm not a huge fan of this patch. Really, given how complicated 3-D
textures are on SKL, there really is no sensible horizontal slice
pitch. We could return 0 as an "invalid value" but I think I'd rather
keep it an assert. Code that is dealing with 3-D textures should no
better than to just blin
I don't see anything in the docs that changes with SKL that affects
this function.
Reviewed-by: Jason Ekstrand
On Wed, May 13, 2015 at 9:37 AM, Francisco Jerez wrote:
> This works as-is on SKL, only the assertion needs to be relaxed.
> ---
> src/mesa/drivers/dri/i965/brw_program
On Fri, Jul 31, 2015 at 5:20 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> Curro,
>> What are we still wainting on for the image_load_store extension? I
>> think I've given you R-B's on all but one or two of the compiler
>> patches. Is t
On Fri, Aug 7, 2015 at 12:24 PM, Oded Gabbay wrote:
> This patch fixes a bug that is manifested in the read path of mesa when
> running on big-endian machines. The effects can be seen when running
> piglit sanity test and/or taking a screen capture.
piglit sanity isn't all that convincing. It's
On Aug 7, 2015 21:08, "Rob Clark" wrote:
>
> On Fri, Aug 7, 2015 at 8:11 PM, Jason Ekstrand
wrote:
> > On Fri, Aug 7, 2015 at 12:24 PM, Oded Gabbay
wrote:
> >> This patch fixes a bug that is manifested in the read path of mesa when
> >> running on big-
Cc: Iago Toral
Cc: Oded Gabbay
---
src/mesa/main/formats.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index baeb1bf..d927073 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -372,10 +372,10 @@ u
On Fri, Aug 7, 2015 at 10:38 PM, Oded Gabbay wrote:
> On Sat, Aug 8, 2015 at 3:11 AM, Jason Ekstrand wrote:
>> On Fri, Aug 7, 2015 at 12:24 PM, Oded Gabbay wrote:
>>> This patch fixes a bug that is manifested in the read path of mesa when
>>> running on big-endian m
On Sat, Aug 8, 2015 at 1:01 PM, Oded Gabbay wrote:
> On Sat, Aug 8, 2015 at 7:34 PM, Jason Ekstrand wrote:
>> On Fri, Aug 7, 2015 at 10:38 PM, Oded Gabbay wrote:
>>> On Sat, Aug 8, 2015 at 3:11 AM, Jason Ekstrand wrote:
>>>> On Fri, Aug 7, 2015 at 12:24 PM, Oded G
Mesa formats and gallium formats are defined a bit differently. In mesa
there are "packed" formats which are based on byte-order within a 8, 16, or
32-bit word and there are "array" formats which are simply an array of 8,
16, or 32-bit values. In gallium, they do something different called
"plain
t mesa core has them
defined as I find it much simpler to understand. However, changing
either is probably going to be a buggy mess. :-(
--Jason
On Sat, Aug 8, 2015 at 1:45 PM, Jason Ekstrand wrote:
> Mesa formats and gallium formats are defined a bit differently. In mesa
> there are &
On Sat, Aug 8, 2015 at 2:10 PM, Rob Clark wrote:
> On Sat, Aug 8, 2015 at 4:26 PM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 1:01 PM, Oded Gabbay wrote:
>>> On Sat, Aug 8, 2015 at 7:34 PM, Jason Ekstrand wrote:
>>>> On Fri, Aug 7, 2015 at 10:38 PM, Oded Gabb
On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger wrote:
> Am 08.08.2015 um 22:45 schrieb Jason Ekstrand:
>> Mesa formats and gallium formats are defined a bit differently. In mesa
>> there are "packed" formats which are based on byte-order within a 8, 16, or
>> 3
On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 2:14 PM, Roland Scheidegger
>> wrote:
>>> Am 08.08.2015 um 22:45 schrieb Jason Ekstrand:
>>>> Mesa formats and gallium f
On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstrand
>>> wrote:
>>>
>>> If I under
On Sun, Aug 9, 2015 at 6:46 AM, Roland Scheidegger wrote:
> Am 09.08.2015 um 12:11 schrieb Oded Gabbay:
>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>>> On Sat, Aug 8, 2015 at 3:14 PM, Oded Gabbay wrote:
>>>> On Sun, Aug 9, 2015 at 12:26 AM, Jason Ekstr
This better ensures that the src_bits == dst_bits case gets optimized away.
---
src/mesa/main/format_utils.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/format_utils.h b/src/mesa/main/format_utils.h
index 00ec777..65314e6 100644
--- a/src/mesa/main/for
The swizzle defines where in the format you should look for any given
channel. When we flip the format around for BE targets, we need to change
the destinations of the swizzles, not the sources. For example, say the
format is an RGBX format with a swizzle of xyz1 on LE. Then it should be
wzy1 on
this, I'll
try and keep this branch updated to the current "best known patches".
Hopefully, we can find/fix all of the bogus code and get BE at least
sort-of working again.
--Jason
On Sun, Aug 9, 2015 at 11:50 PM, Jason Ekstrand wrote:
> The swizzle defines where in the format y
On Sun, Aug 9, 2015 at 11:55 PM, Oded Gabbay wrote:
> On Mon, Aug 10, 2015 at 9:52 AM, Jason Ekstrand wrote:
>> For those of you tracking the big-endian stuff, I've pushed a couple
>> patches to a branch:
>>
>> http://cgit.freedesktop.org/~jekstrand/mesa/log/?h
On Mon, Aug 10, 2015 at 12:07 AM, Oded Gabbay wrote:
> On Mon, Aug 10, 2015 at 7:58 AM, Jason Ekstrand wrote:
>> On Sun, Aug 9, 2015 at 3:11 AM, Oded Gabbay wrote:
>>> On Sun, Aug 9, 2015 at 2:43 AM, Jason Ekstrand wrote:
>>>> On Sat, Aug 8, 2015 at 3:14 PM, Od
On Mon, Aug 10, 2015 at 12:41 AM, Oded Gabbay wrote:
> On Mon, Aug 10, 2015 at 10:30 AM, Jason Ekstrand wrote:
>> On Mon, Aug 10, 2015 at 12:07 AM, Oded Gabbay wrote:
>>> On Mon, Aug 10, 2015 at 7:58 AM, Jason Ekstrand
>>> wrote:
>>>> On Sun, Aug
Before, if we encountered an array format of 0 on a BE system, we would
flip all the channels even though it's an invalid format. This would
result in a mostly invalid format with a swizzle of or . Instead,
we should just return 0 if the array format stashed in the format info is
invalid
> > There is a functional change here. If you're using new mesa on an old
> > kernel/libdrm, the revid will be -1, and we'll use new SKL values
instead of
> > early ones (a hopefully irrelevant improvement IMO).
> >
> > Cc: Jason Ekstrand
>
On Mon, Aug 10, 2015 at 9:49 AM, Ben Widawsky wrote:
> On Mon, Aug 10, 2015 at 09:09:41AM -0700, Jason Ekstrand wrote:
>> On Aug 10, 2015 4:14 AM, "Neil Roberts" wrote:
>> >
>> > If we go with this patch perhaps it would be good to remove
>> > supp
On Mon, Aug 10, 2015 at 4:35 AM, Neil Roberts wrote:
> Jason Ekstrand writes:
>
>> @@ -151,8 +153,10 @@ _mesa_snorm_to_snorm(int x, unsigned src_bits, unsigned
>> dst_bits)
>>return -MAX_INT(dst_bits);
>> else if (src_bits < dst_bits)
>>
On Mon, Aug 10, 2015 at 5:49 AM, Martin Peres
wrote:
> On 10/08/15 15:45, Chris Wilson wrote:
>>
>> On Mon, Aug 10, 2015 at 03:37:24PM +0300, Martin Peres wrote:
>>>
>>> 10-12 are:
>>>
>>> Reviewed-by: Martin Peres
>>
>> One thing to consider, do we want to do a s/typedef/struct brw_batch/
>> cle
On Mon, Aug 10, 2015 at 11:16 AM, Matt Turner wrote:
> On Mon, Aug 3, 2015 at 5:22 PM, Jason Ekstrand wrote:
>> On BDW+, the negation source modifier on NOT, AND, OR, and XOR, is actually
>> a boolean negate and not an integer negate. However, NIR's soruce
>> modifie
On Sat, Aug 8, 2015 at 4:04 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Wed, May 13, 2015 at 9:43 AM, Francisco Jerez
>> wrote:
>>> v2: Add SKL support.
>>> ---
>>> src/mesa/drivers/dri/i965/brw_context.h | 2 +
>>
On Mon, Aug 10, 2015 at 11:30 AM, Matt Turner wrote:
> On Mon, Aug 10, 2015 at 11:19 AM, Jason Ekstrand wrote:
>> On Mon, Aug 10, 2015 at 11:16 AM, Matt Turner wrote:
>>> On Mon, Aug 3, 2015 at 5:22 PM, Jason Ekstrand wrote:
>>>> On BDW+, the negation source mod
---
src/mesa/drivers/dri/i965/brw_vec4.h | 4 ++--
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/i965/brw_vec4.h
index 0c13d43..24bf354 100644
--- a/src/
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 15 ---
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 14 +++---
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drive
On Mon, Aug 10, 2015 at 11:24 AM, Matt Turner wrote:
> On Fri, Jul 31, 2015 at 10:05 AM, Jason Ekstrand wrote:
>> The following 5 patches contain a few register allocation cleanups and
>> performance improvements. Chris Wilson noticed that setting up register
>> sets on i
On Sat, Aug 8, 2015 at 2:58 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> I'm not a huge fan of this patch. Really, given how complicated 3-D
>> textures are on SKL, there really is no sensible horizontal slice
>> pitch. We could return 0 as an "inv
On Tue, Aug 11, 2015 at 2:45 AM, Francisco Jerez wrote:
> Jason Ekstrand writes:
>
>> On Sat, Aug 8, 2015 at 2:58 AM, Francisco Jerez
>> wrote:
>>> Jason Ekstrand writes:
>>>
>>>> I'm not a huge fan of this patch. Really, given how complic
On Aug 12, 2015 3:55 AM, "Oded Gabbay" wrote:
>
> Because we build here an array format, we don't need to swap the
> bytes for big endian.
> If it isn't an array format, the bytes will be swapped in
> _mesa_format_convert.
>
> Signed-off-by: Oded Gabba
Reviewed-by: Jason Ekstrand
On Wed, Aug 12, 2015 at 8:22 AM, Oded Gabbay wrote:
> Because we build here an array format, we don't need to swap the
> bytes for big endian.
> If it isn't an array format, the bytes will be swapped in
> _mesa_format_convert.
>
> v2: rem
On Wed, Aug 12, 2015 at 11:55 AM, Eric Anholt wrote:
> NIR instruction count results on i965:
> total instructions in shared programs: 1261954 -> 1261937 (-0.00%)
> instructions in affected programs: 455 -> 438 (-3.74%)
>
> One in yofrankie, two in tropics. Apparently i965 had also optimized
838 (-3.22%)
> helped:5762
Nice catch!
Reviewed-by: Jason Ekstrand
> ---
> The shader-db numbers are from a tree with the scalar_vs fixup.
>
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 21 ++---
> 1 file changed, 18 insertions(
On Aug 12, 2015 4:21 PM, "Eric Anholt" wrote:
>
> Jason Ekstrand writes:
>
> > On Wed, Aug 12, 2015 at 11:55 AM, Eric Anholt wrote:
> >> NIR instruction count results on i965:
> >> total instructions in shared programs: 1261954 -> 1261937 (-0.00%)
&
On Aug 12, 2015 4:41 AM, "Francisco Jerez" wrote:
>
> Francisco Jerez writes:
>
> > Neil Roberts writes:
> >
> >> Ok, that makes sense, thanks for the detailed explanation. I think
> >> you're right, given the extra restrictions avoiding the integer dword
> >> multiplication seems like the simpl
I don't think this applies on top of the patch Matt sent yesterday to use
fewer moves for loading constants.
On Aug 14, 2015 4:56 AM, "Antia Puentes" wrote:
>
> Loads constants using integer as their register type, this is done
> for consistency with the FS backend.
> ---
> src/mesa/drivers/dri/i
---
src/util/register_allocate.c | 23 +++
src/util/register_allocate.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/src/util/register_allocate.c b/src/util/register_allocate.c
index 436e008..c9867e3 100644
--- a/src/util/register_allocate.c
+++ b/src/util/register_a
Instead of adding transitive conflicts as we go, we now add regular
conflicts and them make them all transitive at the end. This should be
more efficient.
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 10 --
src/mesa/drivers/dri/i965/brw_vec4_reg_allocate.cpp | 5 -
2 fil
Since i965 is now using make_reg_conflicts_transitive and doesn't need
q-value computations, they are disabled on i965. They are enabled
everywhere else so that they get the old behavior.
---
src/gallium/drivers/freedreno/ir3/ir3_ra.c | 2 +-
.../drivers/r300/compiler/radeon_pair_regallo
---
src/gallium/auxiliary/util/u_math.h | 12
1 file changed, 12 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 56bd185..5814421 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@
Cc: Kristian Hogsberg
---
src/util/bitset.h | 36
1 file changed, 36 insertions(+)
diff --git a/src/util/bitset.h b/src/util/bitset.h
index febcdde..c452819 100644
--- a/src/util/bitset.h
+++ b/src/util/bitset.h
@@ -96,4 +96,40 @@ __bitset_ffs(const BITSET_W
atch makes BITSET_WORD a 64-bit value on 64-bit systems. I don't
actually have perf numbers for that, but it should help ra setup as well as
liveness analysis and a whole host of other compiler tasks.
Cc: Chris Wilson
Cc: Eric Anholt
Jason Ekstrand (6):
util/bitset: Add a BITSET_FOREACH_S
This means that it will now be a 64-bit word on 64-bit linux systems but a
32-bit word on 32-bit systems and windows. This should gain us a little
efficiency on 64-bit systems.
---
src/util/bitset.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/util/bitset.h b/src/u
On Sat, Aug 15, 2015 at 11:31 AM, Jason Ekstrand wrote:
> This series was inspired by a patch from Chris Willson entitled
> "util/register_allocate: Compute transitive conflicts using 2-passes"
>
> The basic idea is the same: Instead of marking transitive conflicts
rid of the (now unneeded) conflict list allocations.
On Sat, Aug 15, 2015 at 11:31 AM, Jason Ekstrand wrote:
> Instead of adding transitive conflicts as we go, we now add regular
> conflicts and them make them all transitive at the end. This should be
> more efficient.
> ---
> sr
The first four are
Reviewed-by: Jason Ekstrand
I'll get to the others later.
On Mon, Aug 17, 2015 at 4:07 PM, Kenneth Graunke wrote:
> Previously, there were four type_size() functions in play - the i965
> compiler backend defined scalar and vec4 type_size() functions, and
>
On Aug 17, 2015 4:08 PM, "Kenneth Graunke" wrote:
>
> Previously, we used nir_lower_io with the scalar type_size function,
> which mapped VERT_ATTRIB_* locations to...some numbers. Then, in
> fs_visitor::nir_setup_inputs(), we created temporaries indexed by
> those numbers, and emitted MOVs from
On Aug 17, 2015 4:08 PM, "Kenneth Graunke" wrote:
>
> Previously, we used nir_lower_io with the scalar type_size function,
> which mapped VERT_ATTRIB_* locations to...some numbers. Then, in
> fs_visitor::nir_setup_inputs(), we created temporaries indexed by
> those numbers, and emitted MOVs from
On Aug 17, 2015 4:08 PM, "Kenneth Graunke" wrote:
>
> Previously, ATTR was indexed by VERT_ATTRIB_* slots; at the end of
> compilation, assign_vs_urb_setup() translated those into GRF units,
> and converted ATTR to HW_REGs.
>
> This patch moves the transslation earlier, making ATTR work in terms o
ARRANTIES OF
MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
> + *
On Mon, Jun 1, 2015 at 3:29 AM, Pohjolainen, Topi
wrote:
> On Fri, May 22, 2015 at 02:24:51PM -0400, Connor Abbott wrote:
>> This can be used for both CSE and value numbering.
>>
>> Signed-off-by: Connor Abbott
>> ---
>> src/glsl/Makefile.sources | 2 +
>> src/glsl/nir/nir_instr_hash.c | 2
On Tue, Aug 18, 2015 at 1:28 AM, Kenneth Graunke wrote:
> On Monday, August 17, 2015 09:53:20 PM Jason Ekstrand wrote:
>> On Aug 17, 2015 4:08 PM, "Kenneth Graunke" wrote:
>> >
>> > Previously, ATTR was indexed by VERT_ATTRIB_* slots; at the end of
On Fri, May 22, 2015 at 11:24 AM, Connor Abbott wrote:
> This can be used for both CSE and value numbering.
>
> Signed-off-by: Connor Abbott
> ---
> src/glsl/Makefile.sources | 2 +
> src/glsl/nir/nir_instr_hash.c | 255
> ++
> src/glsl/nir/nir_inst
I really like this. It's nice, straight-forward, and to-the-point.
Once the other issues have been cleared up,
Reviewed-by: Jason Ekstrand
On Fri, May 22, 2015 at 11:24 AM, Connor Abbott wrote:
> This replaces an O(n^2) algorithm with an O(n) one, while allowing us to
> import
- a/src/glsl/nir/nir_opt_cse.c
> +++ b/src/glsl/nir/nir_opt_cse.c
> @@ -22,10 +22,11 @@
> *
> * Authors:
> *Jason Ekstrand (ja...@jlekstrand.net)
> + *Connor Abbott (cwabbo...@gmail.com)
> *
> */
>
> -#include "nir.h"
> +#include "n
On Mon, Aug 17, 2015 at 4:07 PM, Kenneth Graunke wrote:
> I want to use C function pointers to these, and they don't use anything
> in the visitor classes anyway.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 10 +-
> src/mesa/drivers/dri/i96
On Tue, Aug 18, 2015 at 3:42 PM, Eric Anholt wrote:
> Jason Ekstrand writes:
>
>> This series was inspired by a patch from Chris Willson entitled
>> "util/register_allocate: Compute transitive conflicts using 2-passes"
>>
>> The basic idea is the same: In
On Tue, Aug 18, 2015 at 5:36 PM, Ian Romanick wrote:
> On 08/18/2015 10:08 AM, Connor Abbott wrote:
>> On Tue, Aug 18, 2015 at 9:56 AM, Kenneth Graunke
>> wrote:
>>> Hey,
>>>
>>> I was thinking about using an anonymous union. Specifically, something
>>> like:
>>>
>>> struct shader {
>>>...
Previously, setting up image uniforms relied on being called after
fs_visitor::uniforms was set and with fs_visitor::uniforms not allocating
space for it. This made sense in an ir_visitor world because the visitor
assigns locations and uploads data as it walks through the variables. In
NIR it als
1001 - 1100 of 12089 matches
Mail list logo
