On Friday, February 27, 2015 10:22:08 AM Ben Widawsky wrote:
> I'm not really sure of the origins of the existing flag names. Modern docs
> have
> some slightly different names. Having the correct names makes it easier to
> determine if existing PIPE_CONTROL flag settings are correct, as well as
On Friday, February 27, 2015 10:22:11 AM Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> b/src/mesa/drivers/dri/i965
On Friday, February 27, 2015 10:22:10 AM Ben Widawsky wrote:
> From the comments in the code:
>
>Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END and
>sending it off.
>
> This fixes a possible, unlikely infinite recursion in our batch flush path.
> More
> importantl
Thanks Matt -- yes, for 10.5 as well.
I'll also note that this fixes:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=5
On Sat, Feb 28, 2015 at 8:48 PM, Matt Turner wrote:
> On Fri, Feb 27, 2015 at 11:03 PM, Chris Forbes wrote:
>> Previously, we compared our new GS-out VUE map to th
On Sat, 2015-02-28 at 14:56 +1100, Timothy Arceri wrote:
> Hi all,
>
> I'm in the process of extending this code to support arrays of arrays
> but I'm struggling to find piglit tests that exercise it. Does anyone
> know if there are tests designed to test this code path specifically?
Never mind I
On 28/02/15 00:47, Brian Paul wrote:
> ---
> include/c99_math.h | 4
> src/mesa/main/compiler.h | 4
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/c99_math.h b/include/c99_math.h
> index 35173c6..0a49950 100644
> --- a/include/c99_math.h
> +++ b/inclu
On 28/02/15 00:47, Brian Paul wrote:
> Move it to the only place it's used.
> ---
> src/mesa/main/compiler.h | 8
> src/mesa/main/imports.h | 8
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
> index 9d7df
On 27/02/15 17:42, Matt Turner wrote:
> On Fri, Feb 27, 2015 at 7:27 AM, Samuel Iglesias Gonsalvez
> wrote:
>> This could be the case of trying to compile a Mesa tarball (from 'make dist'
>> command) in a machine without Python interpreter installed. The autogenerated
>> files from mako templates
On 28/02/15 10:48, Emil Velikov wrote:
> On 28/02/15 00:47, Brian Paul wrote:
>> ---
>> include/c99_math.h | 4
>> src/mesa/main/compiler.h | 4
>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/c99_math.h b/include/c99_math.h
>> index 35173c6..0a49950
https://bugs.freedesktop.org/show_bug.cgi?id=89363
Fabio Pedretti changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=86958
Chris Vine changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=86958
--- Comment #4 from Chris Vine ---
In addition, MM looks as if it should be set to 0 after line 504 to prevent a
double delete (the initialization of the std::unique_ptr object at line 504
will presumably take ownership).
--
You are receiving t
So here comes my hash-table series mentioned earlier.
So, first of all, there's some issues.
I've been strugling with hitting assertion failures.
The table returns null at times when it apparently should not.
It occurs after patch 1, and is fixed by patch 2.
It also occured when I was tweaking the
Should decrease collisions and therefore improve performance.
Result from oprofile on a run of shader-db shows:
mesa_hash_data 3.23 ---> 3.25
hash_table_insert 2.71 ---> 2.52
hash_table_search 2.87 ---> 2.64
set_add 1.69 ---> 1.65
set_search 2.11 -
Less code, and gives a small speedup due to
avoiding the extra modulo operation.
Also less memory footprint since rehash gets dropped.
Results from oprofile on a shader-db run:
set_add 2.80 ---> 2.70
set_search 2.86 ---> 2.74
runtime 162 ---> 165
---
Should be more efficient as we can use a bitmask
operation instead of an expensive modulo.
Results from oprofile on a shader-db run:
set_add 2.70 ---> 1.69
set_search 2.74 ---> 2.11
runtime 165 ---> 157
---
src/util/set.c | 82
This gives better performance as we can do bitmasking
instead of modulo operations.
This reduces oprofile hits on a shader-db run accordingly:
hash_table_insert 4.28 ---> 2.57
hash_table_search 4.59 ---> 2.67
runtime 175 ---> 170
Since the last patch hits assertion fa
This should give better cache locality, less memory consumption,
less code, and should also be faster since we avoid a modulo operation.
This is not the quadratic probing function you see most places.
They do not accumulate, so you try hash +1, +4, +9, etc.
My code accumulates; so it becomes hash
Copy-pasta from the wikipedia article.
Results from oprofile on a shader-db run:
mesa_hash_data 3.25 ---> 3.11
hash_table_insert 2.52 ---> 2.52
hash_table_search 2.64 ---> 2.64
set_add 1.65 ---> 1.74
set_search 2.07 ---> 2.08
runtime
This is faster than program_hash_table,
and we don't need the extra capabilities.
Results from oprofile on a shader-db run:
mesa_hash_data 3.09 ---> 3.05
hash_table_insert 2.57 ---> 2.58
hash_table_search 2.67 ---> 2.72
runtime 170 ---> 162
---
src/glsl/ir_co
There are probably better ways to do this.
Results from oprofile on a shader-db run:
mesa_hash_data 3.11 ---> 3.12
hash_table_insert 2.52 ---> 2.50
hash_table_search 2.64 ---> 2.59
set_add 1.74 ---> 1.72
set_search 2.08 ---> 2.09
runtime
>
> With regards to cheaper hash-functions:
> It seems this is a case of "much pain for no gain".
>
Not sure if you looked at it, but xxHash is an extremely fast 32 bit hash
function, about 2x faster than murmur https://code.google.com/p/xxhash/
--
Aras Pranckevičius
work: http://unity3d.com
ho
Forgot to run piglit on this before sending out.
And well, it looks bad, really bad.
I'm looking into it now.
Will report back when I get some more data.
Regards,
Thomas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.or
This is the commit that regresses piglit.
With this reverted there are no regressions.
Regards,
Thomas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=86958
Emil Velikov changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On 26 February 2015 at 23:31, Thomas Helland wrote:
>
> On Feb 26, 2015 4:32 PM, "Emil Velikov" wrote:
>>
>> On 26/02/15 01:30, Brian Paul wrote:
>> > Another clean-up series. Mostly trimming down on unneeded #includes.
>> >
>> > I tested DRI, non-DRI and MSVC builds of this series but it's poss
https://bugs.freedesktop.org/show_bug.cgi?id=89364
--- Comment #4 from Brian Paul ---
Created attachment 113888
--> https://bugs.freedesktop.org/attachment.cgi?id=113888&action=edit
Proposed fix for FreeBSD
Vinson, can you try this patch?
--
You are receiving this mail because:
You are the Q
On 02/28/2015 03:48 AM, Emil Velikov wrote:
On 28/02/15 00:47, Brian Paul wrote:
---
include/c99_math.h | 4
src/mesa/main/compiler.h | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/c99_math.h b/include/c99_math.h
index 35173c6..0a49950 100644
---
On 02/28/2015 03:50 AM, Emil Velikov wrote:
On 28/02/15 00:47, Brian Paul wrote:
Move it to the only place it's used.
---
src/mesa/main/compiler.h | 8
src/mesa/main/imports.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/compiler.h b/sr
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 0eab053..57c4d66 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
+++ b/src/mesa/drivers/
Only used in one place. Just use conventional initializers there.
---
src/mesa/main/compiler.h | 8
src/mesa/x86/common_x86.c | 3 +--
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index 796870d..a0ef75a 100644
--- a/s
On 02/27/2015 08:53 PM, Ian Romanick wrote:
Patches 1 through 5 seem innocuous enough and are
Reviewed-by: Ian Romanick
Do you have a tree somewhere that I could pull to make sure the others
don't break my build? :)
I don't, actually. But I've tested the i965 / DRI build here. OK?
-Brian
On Feb 28, 2015 4:55 AM, "Thomas Helland" wrote:
>
> So here comes my hash-table series mentioned earlier.
>
> So, first of all, there's some issues.
> I've been strugling with hitting assertion failures.
> The table returns null at times when it apparently should not.
> It occurs after patch 1, a
On 28 February 2015 at 15:40, Brian Paul wrote:
> On 02/28/2015 03:50 AM, Emil Velikov wrote:
>>
>> On 28/02/15 00:47, Brian Paul wrote:
>>>
>>> Move it to the only place it's used.
>>> ---
>>> src/mesa/main/compiler.h | 8
>>> src/mesa/main/imports.h | 8
>>> 2 files change
---
src/mesa/drivers/dri/r200/r200_sanity.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/r200/r200_sanity.c
b/src/mesa/drivers/dri/r200/r200_sanity.c
index 8f7c0fe..ab922e5 100644
--- a/src/mesa/drivers/dri/r200/r200_sanity.c
+++
---
src/gallium/state_trackers/dri/dri_screen.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_screen.c
b/src/gallium/state_trackers/dri/dri_screen.c
index 9cdebf8..1b14ab1 100644
--- a/src/gallium/state_trackers/dri/dri_screen.c
+++
---
src/mesa/drivers/dri/nouveau/nouveau_screen.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_screen.c
b/src/mesa/drivers/dri/nouveau/nouveau_screen.c
index 150dd8e..b9ae959 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_scre
---
src/mesa/program/ir_to_mesa.cpp | 2 +-
src/mesa/program/prog_execute.c | 2 +-
src/mesa/program/prog_print.c | 16
src/mesa/program/prog_statevars.c | 4 ++--
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/mesa/program/ir_to_mesa.cpp b/src/mes
---
src/mapi/glapi/gen/gl_enums.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_enums.py b/src/mapi/glapi/gen/gl_enums.py
index 35919d6..d61618f 100644
--- a/src/mapi/glapi/gen/gl_enums.py
+++ b/src/mapi/glapi/gen/gl_enums.py
@@ -83,7 +83,7 @@ const
---
src/mesa/vbo/vbo_context.c| 4 ++--
src/mesa/vbo/vbo_exec_api.c | 12 ++--
src/mesa/vbo/vbo_exec_array.c | 4 ++--
src/mesa/vbo/vbo_exec_draw.c | 8
src/mesa/vbo/vbo_exec_eval.c | 8
5 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/mesa
---
src/mesa/drivers/dri/radeon/radeon_sanity.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_sanity.c
b/src/mesa/drivers/dri/radeon/radeon_sanity.c
index bb2a3bf..ca10fc3 100644
--- a/src/mesa/drivers/dri/radeon/rade
---
src/mesa/swrast/s_points.c | 2 +-
src/mesa/swrast/s_texfetch.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/swrast/s_points.c b/src/mesa/swrast/s_points.c
index 52a7222..8180483 100644
--- a/src/mesa/swrast/s_points.c
+++ b/src/mesa/swrast/s_points.c
@@ -1
---
src/mesa/state_tracker/st_atom.c | 4 ++--
src/mesa/state_tracker/st_cb_drawpixels.c | 4 ++--
src/mesa/state_tracker/st_cb_rasterpos.c | 2 +-
src/mesa/state_tracker/st_cb_xformfb.c | 8
src/mesa/state_tracker/st_context.c| 6 +++---
src/mesa/state_track
---
src/mesa/drivers/dri/i965/brw_eu_emit.c| 8
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
src/mesa/drivers/dri/i965/gen6_sol.c | 2 +-
src/mesa/drivers/dri/i965/intel_fbo.c | 2 +-
5 files chang
We've been using a mix of these two macros for a while now. Let's
just use the later everywhere. It seems to be the convention used
by other open-source projects.
---
src/mesa/main/arrayobj.c | 6 +++---
src/mesa/main/attrib.c| 2 +-
src/mesa/main/blend.c | 2
---
src/mesa/drivers/dri/i915/intel_fbo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i915/intel_fbo.c
b/src/mesa/drivers/dri/i915/intel_fbo.c
index 2a34385..1e1397d 100644
--- a/src/mesa/drivers/dri/i915/intel_fbo.c
+++ b/src/mesa/drivers/dri/i915/int
---
src/glsl/builtin_functions.cpp| 2 +-
src/glsl/builtin_variables.cpp| 2 +-
src/glsl/glsl_parser.yy | 4 ++--
src/glsl/glsl_parser_extras.cpp | 8
src/glsl/ir.cpp
No longer used.
---
src/mesa/main/compiler.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/mesa/main/compiler.h b/src/mesa/main/compiler.h
index a0ef75a..7f2d732 100644
--- a/src/mesa/main/compiler.h
+++ b/src/mesa/main/compiler.h
@@ -175,9 +175,6 @@ static inline GLuint CPU_TO_LE32(GL
This patch is
Reviewed-by: Fredrik Höglund
On Saturday 28 February 2015, Laura Ekstrand wrote:
> ---
> src/mesa/main/bufferobj.c | 19 +++
> src/mesa/main/bufferobj.h | 4
> 2 files changed, 23 insertions(+)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/buffe
I pulled down the patches from patchwork and verified using tools that
the only changes (except for the last patch) are Elements ->
ARRAY_SIZE. This is the command I used:
diff -u <( git diff e8cf8d013fcd7a15e94103b9367d89394de7a067^.. | grep
-P '^\+[^+]' | sed 's/^+//' ) <( git diff
e8cf8d013fcd7
Series Reviewed-by: Jordan Justen
On 2015-02-27 18:50:45, Ian Romanick wrote:
> From: Ian Romanick
>
> brw_fs_visitor.cpp:2162:56: warning: unused parameter 'offset_components'
> [-Wunused-parameter]
> fs_reg offset_value, unsigned offset_components,
>
The latter is a C99 standard, and our current wrapper c99_compat.h
should handle non-compliant compilers.
Drop the c99_compat.h inclusion from eglcompiler.h altogether, as it's
no longer required.
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 6 +++---
src/egl/main/eglcompiler.h |
With the split of the gallium egl module we had previously it required
access to some of the internal functions. As the only build (automake)
that did this no longer builds it we can now appropriately hide those
functions.
Signed-off-by: Emil Velikov
---
src/egl/main/eglarray.h | 4 ++--
src/
All the users directly include the header, plus we have a in-tree
replacements for non C99 compilers which we already use.
Signed-off-by: Emil Velikov
---
src/egl/main/eglcompiler.h | 32
1 file changed, 32 deletions(-)
diff --git a/src/egl/main/eglcompiler.h b/
Here is to another round of cleanups :-)
Namely we drop the use and definition of INLINE, __FUNCTION__ and use
their c99 brothers.
Patch 3 hides the internal _egl* symbols, which is no longer needed
since we disabled st/egl. We might want to have this patch in 10.5 but
I won't push on it.
Wit
Drop the custom keyword in favour of the C99 one. All the places using
it now directly include c99_compat.h which should handle things on
platforms which lack it.
Signed-off-by: Emil Velikov
---
src/egl/main/eglapi.c | 19 ++-
src/egl/main/eglarray.h| 3 ++-
src/egl/mai
Should no longer be used. As many places indirectly include
eglcompiler.h keep this change separate, so that it can be easily
reverted, if needed.
Signed-off-by: Emil Velikov
---
src/egl/main/eglcompiler.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/src/egl/main/eglcompile
Currently these files are including it indirectly via eglcompiler.h
The latter of which will be removed with follow up commits.
Signed-off-by: Emil Velikov
---
src/egl/drivers/dri2/egl_dri2.c | 1 +
src/egl/drivers/dri2/egl_dri2.h | 2 ++
src/egl/drivers/dri2/platform_drm.c |
On Sat, Feb 28, 2015 at 9:48 AM, Emil Velikov wrote:
> Here is to another round of cleanups :-)
The series is
Reviewed-by: Matt Turner
> Namely we drop the use and definition of INLINE, __FUNCTION__ and use
> their c99 brothers.
>
> Patch 3 hides the internal _egl* symbols, which is no longer
On Fri, 2015-02-27 at 18:50 -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> Both the AMD and Intel APIs provide a dataSize parameter, and this
> function would merrily ignore it. Neither API specifies what to do when
> the buffer isn't big enough. I take the easy route of writing all the
>
On Sat, Feb 28, 2015 at 7:44 AM, Brian Paul wrote:
> On 02/27/2015 08:53 PM, Ian Romanick wrote:
>>
>> Patches 1 through 5 seem innocuous enough and are
>>
>> Reviewed-by: Ian Romanick
>>
>> Do you have a tree somewhere that I could pull to make sure the others
>> don't break my build? :)
>
>
> I
The use of the uninitialized_var() macro was to silence an uninitialized
variable warning that I assumed stemmed from gcc being unable to see
inside __get_cpuid() or understand its inline assembly.
In fact, it was because the __get_cpuid() function can fail, and not
initialize its arguments. Inste
On Sat, Feb 28, 2015 at 7:43 AM, Brian Paul wrote:
> Only used in one place. Just use conventional initializers there.
> ---
> src/mesa/main/compiler.h | 8
> src/mesa/x86/common_x86.c | 3 +--
> 2 files changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/src/mesa/main/compiler.h
Reviewed-by: Matt Turner
Thanks Brian!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Feb 27 2015, Ian Romanick wrote:
> From: Ian Romanick
>
> What a useful warning. #ThanksGCC
Reviewed-by: Carl Worth
Sarcasm-by: Ian Romanick? ;-)
-Carl
pgph3XoYbTHGG.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.fr
On Fri, Feb 27 2015, Ian Romanick wrote:
> All dd functions take a gl_context as the first parameter. Instead of
> removing it, just silence the warning.
For code using gcc, I really prefer the __attribute__((__unused__))
style, (though, obviously hidden in a reasonable looking macro). That
resul
On Sat, Feb 28, 2015 at 1:26 PM, Carl Worth wrote:
> On Fri, Feb 27 2015, Ian Romanick wrote:
>> All dd functions take a gl_context as the first parameter. Instead of
>> removing it, just silence the warning.
>
> For code using gcc, I really prefer the __attribute__((__unused__))
> style, (though
On Fri, Feb 27, 2015 at 8:13 PM, Jason Ekstrand wrote:
> Previously, the nir_if control-flow node had a source built straight into
> it that was the if condition. This has been the source of a lot of
> edge-case headaches due to, in particular, the two different use sets that
> we were carrying a
On Sat, Feb 28 2015, Ilia Mirkin wrote:
> Another clean alternative is to leave the name of the variable out, i.e.
>
> function(struct gl_context *)
Wow. Less is more! I hadn't realized that's a solution for this, but
it's really elegant.
-Carl
pgpHapVflSAmW.pgp
Description: PGP signature
_
On Sat, 2015-02-28 at 10:39 -0800, Carl Worth wrote:
> On Sat, Feb 28 2015, Ilia Mirkin wrote:
> > Another clean alternative is to leave the name of the variable out, i.e.
> >
> > function(struct gl_context *)
>
> Wow. Less is more! I hadn't realized that's a solution for this, but
> it's really e
https://bugs.freedesktop.org/show_bug.cgi?id=78892
Serge Martin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sat, Feb 28, 2015 at 1:51 PM, Jan Vesely wrote:
> On Sat, 2015-02-28 at 10:39 -0800, Carl Worth wrote:
>> On Sat, Feb 28 2015, Ilia Mirkin wrote:
>> > Another clean alternative is to leave the name of the variable out, i.e.
>> >
>> > function(struct gl_context *)
>>
>> Wow. Less is more! I hadn
Always indenting break statements makes spotting missing ones easier.
Cc: 10.5
---
src/mesa/main/pack.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index 3b77c49..f723608 100644
--- a/src/mesa/main/pack.c
+++ b/src/m
---
src/mesa/main/readpix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index 2e4a460..ed0104c 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -594,6 +594,7 @@ read_rgba_pixels( struct gl_context *ctx,
_mesa_for
Cc: "10.4, 10.5"
---
src/mesa/main/shaderapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index dd536cd..5731d58 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1739,7 +1739,7 @@ _mesa_GetPro
Shader-db i965 instructions:
total instructions in shared programs: 1715894 -> 1710802 (-0.30%)
instructions in affected programs: 443080 -> 437988 (-1.15%)
helped:1502
HURT: 13
GAINED:4
LOST:
Shader-db i965 instructions:
total instructions in shared programs: 1711180 -> 1711159 (-0.00%)
instructions in affected programs: 825 -> 804 (-2.55%)
helped:9
HURT: 0
GAINED:3
LOST:
On 28/02/15 19:15, Matt Turner wrote:
> Cc: "10.4, 10.5"
I swear that was brought up already...
Seems that v2 of commit 4fd8b301237 was supposed to address it, but only
the commit message ended updated :-(
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev
Both patches are
Reviewed-by: Jason Ekstrand
On Sat, Feb 28, 2015 at 11:32 AM, Thomas Helland
wrote:
> Shader-db i965 instructions:
> total instructions in shared programs: 1711180 -> 1711159 (-0.00%)
> instructions in affected programs: 825 -> 804 (-2.55%)
> helped:
On Sat, Feb 28, 2015 at 11:32 AM, Thomas Helland
wrote:
> Shader-db i965 instructions:
> total instructions in shared programs: 1715894 -> 1710802 (-0.30%)
> instructions in affected programs: 443080 -> 437988 (-1.15%)
> helped:1502
> HURT:
On Feb 28, 2015 8:39 PM, "Jason Ekstrand" wrote:
>
> Both patches are
>
> Reviewed-by: Jason Ekstrand
Could you commit them?
I don't have commit access.
Regards,
Thomas
>
> On Sat, Feb 28, 2015 at 11:32 AM, Thomas Helland <
thomashellan...@gmail.com> wrote:
>>
>> Shader-db i965 instructions:
>
Reviewed-by: Brian Paul
On 02/28/2015 12:02 PM, Matt Turner wrote:
Always indenting break statements makes spotting missing ones easier.
Cc: 10.5
---
src/mesa/main/pack.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/pack.c b/src/mesa/main/pa
Reviewed-by: Brian Paul
On 02/28/2015 11:09 AM, Matt Turner wrote:
The use of the uninitialized_var() macro was to silence an uninitialized
variable warning that I assumed stemmed from gcc being unable to see
inside __get_cpuid() or understand its inline assembly.
In fact, it was because the _
On 02/28/2015 10:48 AM, Emil Velikov wrote:
Here is to another round of cleanups :-)
Namely we drop the use and definition of INLINE, __FUNCTION__ and use
their c99 brothers.
Patch 3 hides the internal _egl* symbols, which is no longer needed
since we disabled st/egl. We might want to have this
On 02/28/2015 11:11 AM, Matt Turner wrote:
On Sat, Feb 28, 2015 at 7:43 AM, Brian Paul wrote:
Only used in one place. Just use conventional initializers there.
---
src/mesa/main/compiler.h | 8
src/mesa/x86/common_x86.c | 3 +--
2 files changed, 1 insertion(+), 10 deletions(-)
d
On Sat, Feb 28, 2015 at 11:47 AM, Thomas Helland
wrote:
> On Feb 28, 2015 8:39 PM, "Jason Ekstrand" wrote:
>>
>> Both patches are
>>
>> Reviewed-by: Jason Ekstrand
>
> Could you commit them?
> I don't have commit access.
I'd like to wait a few days to see if there are any comments about the
flo
On Sat, Feb 28, 2015 at 12:17 PM, Brian Paul wrote:
> Reviewed-by: Brian Paul
Thanks. I just pushed it so that I'm not blocking any further clean ups.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinf
On Feb 28, 2015 5:05 PM, "Jason Ekstrand" wrote:
>
>
> On Feb 28, 2015 4:55 AM, "Thomas Helland"
wrote:
> >
> > So here comes my hash-table series mentioned earlier.
> >
> > So, first of all, there's some issues.
> > I've been strugling with hitting assertion failures.
> > The table returns null
On 02/28/2015 10:32 AM, Ilia Mirkin wrote:
I pulled down the patches from patchwork and verified using tools that
the only changes (except for the last patch) are Elements ->
ARRAY_SIZE. This is the command I used:
diff -u <( git diff e8cf8d013fcd7a15e94103b9367d89394de7a067^.. | grep
-P '^\+[^+
Already defined in src/util/macros.h
---
src/mesa/main/macros.h | 4
1 file changed, 4 deletions(-)
diff --git a/src/mesa/main/macros.h b/src/mesa/main/macros.h
index da5e8e8..2d7a6a1 100644
--- a/src/mesa/main/macros.h
+++ b/src/mesa/main/macros.h
@@ -803,10 +803,6 @@ DIFFERENT_SIGNS(GLfloa
---
src/util/bitset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/bitset.h b/src/util/bitset.h
index 17c5d5d..febcdde 100644
--- a/src/util/bitset.h
+++ b/src/util/bitset.h
@@ -94,6 +94,6 @@ __bitset_ffs(const BITSET_WORD *x, int n)
return 0;
}
-#define BITS
On Sat, Feb 28, 2015 at 3:10 AM, Emil Velikov wrote:
> On 27/02/15 17:42, Matt Turner wrote:
>> For flex and bison, we check if a generated source file exists, which
>> is probably a good idea. That way configure will fail in a git
>> checkout if you don't have python.
>>
> Checking for the presen
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Feb 28, 2015 at 12:31:59AM -0800, Kenneth Graunke wrote:
> On Friday, February 27, 2015 10:22:10 AM Ben Widawsky wrote:
> > From the comments in the code:
> >
> >Called from intel_batchbuffer_flush before emitting MI_BATCHBUFFER_END
> > and
> >sending it off.
> >
> > This fixes a
On Sat, Feb 28, 2015 at 12:27:05AM -0800, Kenneth Graunke wrote:
> On Friday, February 27, 2015 10:22:11 AM Ben Widawsky wrote:
> > Signed-off-by: Ben Widawsky
> > ---
> > src/mesa/drivers/dri/i965/intel_batchbuffer.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git
We could do better by tracking scratch reads and writes.
Cc: 10.5
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88793
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/br
https://bugs.freedesktop.org/show_bug.cgi?id=89372
Bug ID: 89372
Summary: [softpipe] piglit glsl-1.50 generate-zero-primitives
regression
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=86958
--- Comment #6 from Chris Vine ---
Emil,
OK about your first point, and thanks.
On your second, as the name suggests the whole purpose of std::unique_ptr is to
take unique ownership. a unique_ptr will delete any object it still owns, in
its de
https://bugs.freedesktop.org/show_bug.cgi?id=89372
Vinson Lee changed:
What|Removed |Added
Keywords||bisected
CC|
1 - 100 of 107 matches
Mail list logo