Jose Fonseca writes:
> On 27/03/17 17:42, Dylan Baker wrote:
>> Quoting Jose Fonseca (2017-03-27 09:31:04)
>>> On 27/03/17 17:24, Dylan Baker wrote:
Quoting Jose Fonseca (2017-03-26 14:53:50)
> I've pushed the branch to mesa/demos, so we can all collaborate without
> wasting time cro
Edmondo Tommasina writes:
> Define a new MESA_USER_DRIRC environment variable to load a customized
> drirc file.
>
> When the variable is not defined, nothing changes and the ${HOME}/.drirc
> file will be loaded.
>
> If the variable is set to a file, this file will be loaded instead of
> the the
Lyude writes:
> Signed-off-by: Lyude
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Dylan Baker writes:
> [ Unknown signature status ]
> Quoting Jose Fonseca (2017-03-24 06:42:18)
>>
>> I tend to disagree. While we can't avoid a transitory period, when we
>> embark on another build system (Meson or something else) I think we
>> should aim at 1) ensure such tool can indeed _c
Alex Deucher writes:
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote:
>> Why bother, and why would we want this?
>> │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a
Rob Clark writes:
> On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker wrote:
>> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>>
>> Notably gnome is moving to meson (and some parts already use it), weston and
>> libinput have ports, libepoxy uses meson, and gstreamer i
We already
> require this restriction for phi instructions. This series adds it for
> intrinsics, texture instructions, and deref indirects.
>
> Cc: Kenneth Graunke
> Cc: Connor Abbott
Other than the comments I gave, and needing to land the lowering patch,
this series is:
Review
Jason Ekstrand writes:
> Some SPIR-V texturing instructions pack more than the texture coordinate
> into the coordinate source. We need to mask off the unused channels.
> ---
> src/compiler/spirv/spirv_to_nir.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/compi
Jason Ekstrand writes:
> Because we suddenly have to know how many components each source has,
> this makes the pass a bit more complicated. Fortunately, copy
> propagation is the only pass that cares about the number of components
> are read by any given source so it's fairly contained.
This c
Jason Ekstrand writes:
In the subject: "load_interpolated_input", and "coord"
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
? 1 : 0") # Boolean-to-int
> conversion
> -unop_convert("b2i64", tint64, tbool, "src0 ? 1 : 0") # Boolean-to-int64_t
> conversion.
> -unop_convert("u2f", tfloat32, tuint32, "src0") # Unsigned-to-float
> conversion.
> -unop_convert("u2d", tfloat64, tuint32, "src0") # Unsigned-to-double
> conversion.
> -# double-to-float conversion
> -unop_convert("d2f", tfloat32, tfloat64, "src0") # Double to single precision
> -unop_convert("f2d", tfloat64, tfloat32, "src0") # Single to double precision
> +unop_convert("b2f", tfloat, tbool, "src0 ? 1.0 : 0.0")
> +unop_convert("b2i", tint, tbool, "src0 ? 1 : 0")
I'm confused. The loop includes "tbool" in src_t iteration, so that
makes me think it would be generating a unop_convert() for, say, b2i64
(despite the commit message saying bool conversions don't get sizes),
but then there are these hand-written unop_converts for bools here and I
don't see b2i64 in any of the code.
Other than this question, patches 1-3 and 6 are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
One of the quirks of NIR is that it has allowed SSA references where the
reference uses fewer channels than exist in the SSA value, which surprises
new developers and makes some analysis harder. Jason is about to remove
that quirk and validate that reference num_components == value
num_components,
From: Jonas Pfeil
The header of ralloc needs to be aligned, because the compiler assumes
that malloc returns will be aligned to 8/16 bytes depending on the
platform, leading to degraded performance or alignment faults with ralloc.
Fixes SIGBUS on Raspberry Pi at high optimization levels.
This p
Emil Velikov writes:
> From: Emil Velikov
>
> Similar to other accompanying documentation we have in-tree.
> For example glsl/README.
>
> Signed-off-by: Emil Velikov
This series is:
Reviewed-by: Eric Anholt
signature.asc
Descript
Emil Velikov writes:
> From: Emil Velikov
>
> The version tag used to nominate has bitten even experienced mesa
> developers. Not to mention that it deviates from the one used in the
> kernel leading to further confusion.
>
> Simplify things and omit it all together.
>
> Signed-off-by: Emil Velc
Ian Romanick writes:
> [ Unknown signature status ]
> On 02/09/2017 05:14 PM, Eric Anholt wrote:
>> Ian Romanick writes:
>>
>>> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>>>> On 07.02.2017 23:54, Matt Turner wrote:
>>>>> On Tue, Feb
Ian Romanick writes:
> On 02/08/2017 10:26 AM, Nicolai Hähnle wrote:
>> On 07.02.2017 23:54, Matt Turner wrote:
>>> On Tue, Feb 7, 2017 at 10:56 AM, Marek Olšák wrote:
On Tue, Feb 7, 2017 at 2:57 AM, Kenneth Graunke
wrote:
> On Monday, February 6, 2017 8:54:40 PM PST Marek Olšák w
Bas Nieuwenhuizen writes:
> On Wed, Feb 8, 2017, at 11:25, Matt Turner wrote:
>> On Wed, Feb 8, 2017 at 12:31 AM, Timothy Arceri
>> wrote:
>> > On Tue, 2017-02-07 at 23:58 +0100, Matt Turner wrote:
>> >> On Tue, Feb 7, 2017 at 4:42 AM, Timothy Arceri > >> > wrote:
>> >> > This series adds suppor
Nicolai Hähnle writes:
> From: Nicolai Hähnle
>
> XXX do we need a separate enable bit?
I don't think so -- the driver can take a normal error path when asked
to create an image, right?
So, if you write some more commit message on this one, the series will
get my r-b. Maybe:
"This will allow
Marek Olšák writes:
> Yes, I'm aware that glthread is far from perfect. However, I don't consider
> that an issue. My idea is that the actual work will take place in master. I
> have zero faith that any work on that will take place outside of master.
Yeah. Now that there's some evidence it's us
Emil Velikov writes:
> On 3 February 2017 at 19:13, Eric Anholt wrote:
>> My vc4 simulator has been implemented so far by having an entrypoint
>> claiming to be i965, which was a bit gross. The simulator would be a lot
>> less special if we entered through the vc4 entry
All the replicated prototypes/function bodies obfuscated the interesting
logic of the file: the mapping from driver enable macros to entrypoints we
expose, and the way that the swrast entrypoints are special compared to
the DRM entrypoints.
---
src/gallium/targets/dri/target.c | 133 +++---
Now that there's MESA_LOADER_DRIVER_OVERRIDE for choosing the driver name
we load, we don't need this any more.
---
src/gallium/targets/dri/target.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/src/gallium/targets/dri/target.c b/src/gallium/targets/dri/target.c
index df93c94ea832
My vc4 simulator has been implemented so far by having an entrypoint
claiming to be i965, which was a bit gross. The simulator would be a lot
less special if we entered through the vc4 entrypoint like normal, so add
a loader environment variable to allow the i965 fd to probe as vc4.
---
src/loade
n the "env:"
section, but this also works. Series is:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Emil Velikov writes:
> On 30 January 2017 at 22:54, Rob Herring wrote:
>> The addition of Neon assembly breaks on arm64 builds because the assembly
>> syntax is different. For now, restrict Neon to ARMv7 builds.
>>
>> Signed-off-by: Rob Herring
>> ---
>> src/gallium/drivers/vc4/vc4_tiling.h |
Rob Herring writes:
> clang throws an error on "%r2" and similar. I couldn't find any
> documentation on what "%r?" is supposed to mean and I've never seen any
> use like that as far as I remember. The parameter is supposed to be
> cpu_stride and just %2/%3 should be sufficient.
>
> There's no ne
Kenneth Graunke writes:
> Applications may delete a shader program, create a new one, and bind it
> before the next draw. With terrible luck, malloc may randomly return a
> chunk of memory for the new gl_program that happened to be the exact
> same pointer as our previously bound gl_program. In
Timothy Arceri writes:
> On Tue, 2017-01-24 at 15:54 -0800, Eric Anholt wrote:
>> Timothy Arceri writes:
>>
>> > From: Timothy Arceri
>> >
>> > This will be used to remove cache items created with old versions
>> > of Mesa or other invalid c
Timothy Arceri writes:
> From: Timothy Arceri
>
> This uses disk_cache.c to write out a serialization of various
> state that's required in order to successfully load and use a
> binary written out by a drivers backend, this state is referred to as
> "metadata" throughout the implementation.
>
>
own to not be fully function), also require
"functional"
> +* the MESA_GLSL_CACHE_ENABLE variable to be set.
> +*/
> + if (! getenv ("MESA_GLSL_CACHE_ENABLE"))
> + goto fail;
cworth-style whitespace to be fixed here.
Other than that, 1-5 are:
Reviewe
Timothy Arceri writes:
> From: Timothy Arceri
>
> This will be used to remove cache items created with old versions
> of Mesa or other invalid cache items from the cache.
I'm not convinced that removing the item from cache when we get a hit on
everything in the key except for Mesa version is th
t; constant arrays. Moving lowering before the opt loop in the GLSL linker
> fixes this and unexpectedly improves some compute shaders also.
It seems like we should figure out what's missing in NIR that the lack
of GLSL copy propagation hurt, but this is a pretty easy fix for now:
xtract optimization working again. It had
> stopped working due to the constant 0xff00ff00 getting sign-extended
> when it shouldn't have.
>
> Cc: "17.0 13.0"
> Cc: Eric Anholt
I like this version better.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP si
The python code stores the integer match values to the 64-bit unsigned
field, so 32-bit values like 0xff00 don't get sign extended. However,
~0 gets printed as -0x1, so it does get stored as ~0ull.
To be able to match both ways that the python code generates integers,
cast the 64-bit int valu
This cuts 1 or 2 instructions in 3 different glmark2 tests.
---
src/compiler/nir/nir_opt_algebraic.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index d7ad1f2fbf3f..1136bfe826b0 100644
--- a/src/compiler/nir
This will let VC4 do some ARM-specific optimizations while still having
the simulator build on x86.
---
I'm finishing building the series for doing NEON optimizations today,
but I wanted to get this out there for review since it touches shared
code.
I didn't replicate the 'case "$host_os"' for th
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 799f5ebda029..d1ffb57f57e3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2382,7 +2382,7 @@ dnl
dnl Gallium helper functions
dnl
gallium_require_llvm() {
-if test "x$enab
mple, the compilation success
> rate with a TGSI->GCN bytecode converter without any optimizations is
> the same. Note that glsl_to_tgsi does its own copy propagation and simple
> register allocation.
Patches 3-7 are:
Reviewed-by: Eric Anholt
I'm looking forward to throwing this swit
Timothy Arceri writes:
> By making it more generic and we can short circuit a bunch of code
> paths.
>
> The new field will also be used in coming changes for more clean-ups.
>
> This change also fixes a regression caused by 700bc94dcebf425
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?
Timothy Arceri writes:
> Instead we caan just use gl_program.
"can"
Other than that, 1-4 are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.fr
Timothy Arceri writes:
> This will allow us to store gl_program rather than gl_shader_program
> as the current program perstage which allows us to simplify code
> that makes use of the CurrentProgram list.
>
> V2: don't change subroutine init helper interface
Revi
set stage for arb asm programs also.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Timothy Arceri writes:
> We no longer need anything from gl_linked_shader.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
5-focused commits that I've skipped.
Patches #31-40 are:
Reviewed-by: Eric Anholt
I particularly liked #33 and #37 (though it took a minute to figure out
why dropping the sh==NULL check was valid).
signature.asc
Description: PGP signature
___
me
Timothy Arceri writes:
> After removing brw_shader in the previous commit this is no longer
> needed.
Nice!
9-12 are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
the loop would be nicer as
for (int i = MESA_SHADER_GEOMETRY; i >= MESA_SHADER_VERTEX; i--)
to match transformfeedback.c's get_xfb_source(). Other than that,
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
it archaeology later.
I'm assuming here that we can't change brw->geometry_program/
LinkedTransformFeedback while active_and_unpaused and !BRW_NEW_FT, which
iirc is true.
Even better than just keeping the comments matched up, it means that we
stop calling this atom on every VP chang
Timothy Arceri writes:
> We no longer need to initialise it because gl_program is never reused.
Patches 3-6 are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
ht
Timothy Arceri writes:
> This will allow us to store gl_program rather than gl_shader_program
> as the current program perstage which allows us to simplify code
> that makes use of the CurrentProgram list.
> ---
> diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
> index 10cee7b
Timothy Arceri writes:
> This will allow us to simplify the current program logic for SSO.
>
> Also since we aim to detach shader_info from nir_shader this will come
> in handy avoiding passing nir_shader around just to keep track of
> the stage we are dealing with.
> ---
> src/compiler/glsl/lin
Our editorconfig file looked sensible, saying that we wanted to indent
with spaces and use 3/4/whatever space indentation. However, the spec has
this little surprise:
"tab_width: a whole number defining the number of columns used to
represent a tab character. This defaults to the value o
Rob Clark writes:
> For dealing w/ 32b vs 64b gpu addresses, I need to rework how we pass
> UBO buffer addresses to shader, and knowing up front the # of UBOs is
> useful. But I noticed ttn wasn't setting this.
I'm surprised you're still using TTN. But:
Thomas Helland writes:
> We are removing the entry right beforehand, so this can never succeed.
> Tested with a shader-db run. No changes in instruction count.
> ---
> src/compiler/glsl/opt_copy_propagation.cpp | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/src/compiler/glsl/opt_c
Thomas Helland writes:
> We do nothing but initialize it, add to it, and delete it.
> This is a fallout from removing constant initializer support.
Maybe in the summary do s/nir_array/derefs_array/, but either way:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP sig
Jason Ekstrand writes:
> This keeps some of Connor's original code. However, while I was at it,
> I updated this very old pass to a bit more modern NIR.
I love how much smaller this code is. Assuming that the phi builder
does that job correctly, this is pretty trivial to read and understand.
Jason Ekstrand writes:
> Ever since I wrote the phi builder and converted vars_to_ssa to use it,
> I've been meaning to convert the other into-SSA pass to use it as well.
> This little series does just that. While I was at it, I also renamed it to
> nir_lower_regs_to_ssa to match nir_lower_vars_
Jason Ekstrand writes:
> Hey All,
> I don't figure this will be terribly controversial (I'm about to be wrong,
> aren't I?) but how do people feel about switching our "primary"
> documentation focus, as far as we have one, to sphinx? Right now, Gallium
> uses sphinx for documenting all of it's "
Jason Ekstrand writes:
> diff --git a/src/compiler/nir/nir_opt_copy_prop_vars.c
> b/src/compiler/nir/nir_opt_copy_prop_vars.c
> new file mode 100644
> index 000..728e476
> --- /dev/null
> +++ b/src/compiler/nir/nir_opt_copy_prop_vars.c
> @@ -0,0 +1,799 @@
> +/*
> + * Copyright © 2016 Intel C
and we use XCB instead.
1 and 2 are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Matt Turner writes:
> On Thu, Dec 8, 2016 at 6:55 AM, Emil Velikov wrote:
>
>> former uses relative paths, while the latter absolute ones.
>> Skimming through - nothing obvious comes up on convincing autoconf to
>> generate/use the absolute ones.
>
>
> So the patch makes what amount to a cosmeti
Emil Velikov writes:
> From: Emil Velikov
>
> Having the "Entering|Leaving directory X" messages it not required nor
> useful in vast majority of the cases.
>
> One can always have them printed by `make -w' or by overriding the
> AM_MAKEFLAGS variable.
>
> Signed-off-by: Emil Velikov
I tried t
Kenneth Graunke writes:
> [ Unknown signature status ]
> On Thursday, December 1, 2016 8:53:19 AM PST Iago Toral Quiroga wrote:
>> This is ported from the Intel lowering pass that we use with GLSL IR.
>> This takes care of lowering texture gradients on shadow samplers other
>> than cube maps. Int
Alex Deucher writes:
> On Tue, Dec 6, 2016 at 8:42 AM, Emil Velikov wrote:
>> On 6 December 2016 at 03:16, Edward O'Callaghan
>> wrote:
>>> This patch is to potentially remove ourself from the maintaince
>>> burden of the ilo driver that appears to now be essentially
>>> unmaintained?
>>>
>>> I
e/most BSD platforms still don't support this, yet this should
> serve as an encouragement to move things forwards.
These two are:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
me
Matt Turner writes:
> On Wed, Nov 30, 2016 at 1:11 PM, Matt Turner wrote:
>> On 11/28, Ian Romanick wrote:
>>>
>>> From: Ian Romanick
>>>
>>> I believe that I have addressed all of the review feedback from the
>>> previous iteration. Many of the patches have been reviewed, and they
>>> should
Brian Paul writes:
> [resending, original msg didn't appear on list]
>
> It seems a bit silly to have two linked list utilities.
>
> git-grep indicates that list.h is used more than simple_list.h so maybe
> we can switch uses of the later to the former. In fact, I've already
> found a few file
Mun Gwan-gyeong writes:
> Add missed free()
>
> CID 1394322
>
> Signed-off-by: Mun Gwan-gyeong
Pushed this yesterday. Thanks!
(I made a little change to the commit message summary, as as time goes
on a project will end up with a lot of commits titled "vc4: Fix resource
leak")
signature.asc
return false;
> + }
> + }
> +
> + /* Get the first instruction in the then block and confirm it is
> +* a discard or a discard_if
> +*/
> + nir_instr *instr = nir_block_first_instr(then_block);
> + if (instr->type != nir_instr_type_intrinsic)
> + retu
NIR bools are ~0 for true, so ((unsigned)a >> 31) != 0 -> ((int)a >> 31).
---
src/compiler/nir/nir_lower_idiv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_lower_idiv.c
b/src/compiler/nir/nir_lower_idiv.c
index b1e7aeb03c8a..6726b718aaa5 100644
--- a
Jason Ekstrand writes:
> Reviewed-by: Jason Ekstrand
>
> Maybe CC stable?
Already pushed. rzalloc changes didn't look like they were in mesa 13,
so stable is fine.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.fr
We were leaving an undefined value since the ralloc zeroing changes.
Fixes nir_validate() failures on vc4.
---
src/compiler/nir/nir_lower_bitmap.c | 1 +
src/compiler/nir/nir_lower_drawpixels.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/compiler/nir/nir_lower_bitmap.c
b/src/com
#x27;s a bit funny to be talking about all this, when the purpose of this
patch in this series is to make it so that the shader_info can be
ralloced. Maybe mention that?
The series as a whole should get things working again, though, so I'd
like to see it land. Reviewed-by: Eric Anholt
(I wa
Timothy Arceri writes:
> I'm about to do some refactoring that will move a bunch of glsl only
> fields from gl_linked_program into gl_program.
>
> If we wan't to share memory it makes sense to do it while I move
> things. I just wanted to see what people think about this before
> I get started as
Nicolai Hähnle writes:
> On 02.11.2016 08:59, Edward O'Callaghan wrote:
>> This maybe somewhat of a striking topic however it is one that has not
>> really had enough attention, I feel, in a way that warrants the gravity
>> of if ramifications. Thus, I really would like to kick this discussion
>>
Dave Airlie writes:
> From: Dave Airlie
>
> This is ported from GLSL and converts
>
> if (cond)
> discard;
>
> into
> discard_if(cond);
>
> This removes a block, but also is needed by radv
> to workaround a bug in the LLVM backend.
I think this is missing "also make sure that after our if
We were implictly making one in create, which would get overwritten by
ns->info = s->info below and hang around until nir_sweep() time.
---
src/compiler/nir/nir_clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_clone.c b/src/compiler/nir/nir_clone.c
i
Fixes use-after-free-caused segfaults in the tgsi_to_nir() path.
---
I don't like the boolean I added here, any better plans, though? I
haven't fully piglited this, but it's enough to get gears to not crash
on master (it at least touches the GLSL to NIR and TGSI to NIR paths.)
src/compiler/nir/
DEQP's clear tests like to give us x + w < 0 or y + h < 0. Since we
were comparing to an unsigned, it would get promoted to unsigned and come
out as bignum >= width or height and we would clear the whole fb instead
of none of the fb.
Fixes 10 tests under deqp-gles2/functional/color_clear.
---
sr
---
I went to test-build my previous bash fix, and another area got broken
in the meantime.
src/intel/Makefile.genxml.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/Makefile.genxml.am b/src/intel/Makefile.genxml.am
index 8d7d40266383..160a41151795 100644
--- a/s
Debian uses dash by default, which doesn't do '+='. Fixes servo's
osmesa-based headless testing system, which was looking for libOSMesa in
the lib/ directory.
---
install-gallium-links.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/install-gallium-links.mk b/install-ga
Marek Olšák writes:
> I'd like to have more feedback on the idea of using jemalloc for ralloc.
>
> Right now, I see these options:
>
> 1) Use jemalloc for ralloc and make it mandatory for all GL drivers.
> - Distributions have shown that they are capable of doing anything
> with the Mesa source c
Dave Airlie writes:
> On 13 March 2016 at 11:29, Ian Romanick wrote:
>> On 03/11/2016 03:46 PM, Eric Anholt wrote:
>>> Ian Romanick writes:
>>>
>>>> On 03/10/2016 05:53 PM, Francisco Jerez wrote:
>>>>> Iago Toral writes:
>>>>
Timothy Arceri writes:
> On Sun, 2016-09-25 at 19:51 -0700, Kenneth Graunke wrote:
>> On Saturday, September 24, 2016 3:26:09 PM PDT Timothy Arceri wrote:
>> >
>> > Pointers will have different lengths so we simple create a
>> > different
>> > sha1 for each platform.
>>
>> I don't understand...
an BRW_NEW_VUE_MAP_GEOM_OUT, which we were using in one case.
>
> According to Eric Anholt, this reduces the CPU overhead of scissor and
> viewport state changes n Glamor from 2.5% or so to .8% or so.
>
> Cc: Eric Anholt
> Signed-off-by: Kenneth Graunke
If this is the same patch I
Timothy Arceri writes:
> On Sun, 2016-09-25 at 13:26 -0700, Eric Anholt wrote:
>> Timothy Arceri writes:
>> > +static void
>> > +test_put_key_and_get_key(void)
>> > +{
>> > + struct program_cache *cache;
>> > + bool result;
>> &
; +
> + cache_put_key(cache, key_b);
> + result = cache_has_key(cache, key_b);
> + expect_equal(result, 1, "2nd cache_has_key after key added");
> +
> + /* Test that a key with the same two bytes as an existing key
> +* forces an eviction.
> +*/
> + ca
Timothy Arceri writes:
> ---
> src/compiler/glsl/cache.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/compiler/glsl/cache.c b/src/compiler/glsl/cache.c
> index a6a9e47..dd53f4e 100644
> --- a/src/compiler/glsl/cache.c
> +++ b/src/compiler/glsl/cache.c
> @@ -141,6 +141,10 @@ c
Kenneth Graunke writes:
> Hello,
>
> This series reworks the GLSL compiler to inline built-in functions
> immediately, at compile time, rather than importing prototypes and
> linking against an extra shader later on.
>
> Without this, compile time optimizations are nearly useless. For example,
>
'm not aware of any apps using the feature (certainly nothing in piglit).
Looks like everything's there.
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lis
Kenneth Graunke writes:
> This is mandatory.
This series is:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Ilia Mirkin writes:
> On Mon, Sep 12, 2016 at 11:55 AM, Emil Velikov
> wrote:
>> On 12 September 2016 at 15:35, Ilia Mirkin wrote:
>>> On Mon, Sep 12, 2016 at 10:10 AM, Emil Velikov
>>> wrote:
Keeping diff/patches in git always felt like a hack, imho. Plus
most/all(?) distros rely
VC4 was running into a major performance regression from enabling control
flow in the glmark2 conditionals test, because of short if statements
containing an ffract.
This pass seems like it was was trying to ensure that we only flattened
IFs that should be entirely a win by guaranteeing that there
Ian Romanick writes:
> On 09/06/2016 03:24 PM, Kenneth Graunke wrote:
>> On Tuesday, September 6, 2016 1:04:43 PM PDT Eric Anholt wrote:
>>> Kenneth Graunke writes:
>>>
>>>> Ian added this check in commit 259fc505454ea6a67aeacf6cdebf1398d9947759.
&g
extension as superseded.
This series is:
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
class_3d != NVEA_3D_CLASS)
>return false;
>
> /* transfers & shared are always supported */
Missed transfers & shared -> shared update on this one.
Other than that,
Reviewed-by: Eric Anholt
Hooray for making this interface less of a mess.
signature.asc
Description: PG
Jason Ekstrand writes:
> ---
This seems fine, but the commit message needs some expansion. Questions
I had:
Does this help compared to an implementation with nir CSE already?
Does nir CSE still get us anything that this doesn't?
signature.asc
Description: PGP signature
_
mpiler/nir/nir_opt_gcm.c
> @@ -483,6 +483,9 @@ opt_gcm_impl(nir_function_impl *impl)
> }
>
> ralloc_free(state.blocks);
> +
> + nir_metadata_preserve(impl, nir_metadata_block_index |
> + nir_metadata_dominance);
> }
Reviewed-b
off-by: Kenneth Graunke
Reviewed-by: Eric Anholt
I was wondering about this change, because glmark2 is failing to compile
its terrain shaders now.
signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https:
t;
> Signed-off-by: Tapani Pälli
> ---
>
> Next I'll attempt to make similar change to opt_copy_propagation_elements.
This all looks correct, though it makes me sad to see work being done on
these passes instead of just removing them from being called by NIR
drivers.
Reviewed-
801 - 900 of 5753 matches
Mail list logo
