On Mon, Jun 9, 2014 at 11:51 PM, Tapani Pälli wrote:
> On 06/10/2014 08:28 AM, Tapani Pälli wrote:
>> On 06/09/2014 09:40 PM, Matt Turner wrote:
>>> On Mon, Jun 9, 2014 at 4:29 AM, Tapani Pälli wrote:
Signed-off-by: Tapani Pälli
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79
Nearly all the error cases in *createScreen() issue an error message to diagnose
the failure to initialize before branching to handle_error. The few remaining
error cases which don't should probably do the same.
(At the moment, it seems this can be triggered in drisw with an X server which
report
Revert "build: Build on Cygwin with gnu99 instead of c99." and define
_XOPEN_SOURCE appropriately.
This reverts commit 53e36d333c9b619c1a5fe9a8d2d08665654b0234.
Since Cygwin 1.7.18 (April 2013), it's headers correctly prototype strtoll()
when using -std=c99, and correctly prototype strdup() when
Am 07.06.2014 20:38, schrieb Johannes Obermayr:
> From: Takashi Iwai
>
> Fix the crash of "gnome-control-center info" invocation on QEMU where
> zero height is passed at init.
>
> Fixes: https://bugzilla.novell.com/show_bug.cgi?id=879462
>
> Signed-off-by: Takashi Iwai
> ---
> To: mesa-dev@lis
Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie
>
> This passes the piglit depth clamp tests.
>
> this is required for GL 3.2.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/softpipe/sp_quad_depth_test.c | 37
> ++-
> src/gallium/drivers/softpipe
https://bugs.freedesktop.org/show_bug.cgi?id=79885
Priority: medium
Bug ID: 79885
Assignee: mesa-dev@lists.freedesktop.org
Summary: commit b52a530 (gallium/egl: st_profiles are build
time decision, treat them as such) broke egl
https://bugs.freedesktop.org/show_bug.cgi?id=79885
Marc Dietrich changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
On 10/06/14 03:25, Michel Dänzer wrote:
> From: Michel Dänzer
>
> LLVM is enabled by default for some architectures, but the test was failing
> before that.
>
Thanks for fixing my silly mistake Michel. Would you mind CC-ing stable,
similar to the offending commit (93257a56b5b: configure: error o
Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie
>
> This adds support for GL 3.2 layered rendering to softpipe.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/softpipe/sp_context.h | 3 ++
> src/gallium/drivers/softpipe/sp_quad.h | 1 +
> src/ga
Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie
>
> This crashes on softpipe due to a lack of output memory allocated,
>
> it appears we allocate memory for enough primtives, but not vertices
> so convert to number of vertices.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/
Am 10.06.2014 07:57, schrieb Dave Airlie:
> From: Dave Airlie
>
> This passes tests now on softpipe.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/softpipe/sp_screen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/softpipe/sp_screen.
That looks wrong. The total number of verts per buffer is the maximum number
of verts that can be output per invocation (primitive_boundary) times number of
invocations of geometry shader (num_in_primitives).
It's not maximum number of verts that can be output per invocation
(primitive_boundar
On 06/09/2014 06:58 PM, Dave Airlie wrote:
From: Dave Airlie
This passes the piglit depth clamp tests.
this is required for GL 3.2.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/softpipe/sp_quad_depth_test.c | 37 ++-
src/gallium/drivers/softpipe/sp_screen.c
This fixes automake builds which are broken since
b52a530ce2aada1967bc8fefa83ab53e6a737dae.
Signed-off-by: Niels Ole Salscheider
---
src/gallium/state_trackers/egl/Makefile.am | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/state_trackers/egl/Makefile.am
b/
https://bugs.freedesktop.org/show_bug.cgi?id=79885
--- Comment #2 from Emil Velikov ---
This seems rather odd. I'm assuming that you've tried the parent commit and it
works fine ? Are you building with scons by any change ?
Set the variable EGL_LOG_LEVEL=debug and attach the output of the progra
https://bugs.freedesktop.org/show_bug.cgi?id=79885
--- Comment #3 from Niels Ole Salscheider ---
I have just sent a patch ("egl/gallium: Set defines for supported APIs when
using automake") to the list which should fix your problem, too.
--
You are receiving this mail because:
You are the assig
On Mon, Jun 9, 2014 at 5:53 AM, Pekka Paalanen wrote:
> On Thu, 16 Aug 2012 17:28:19 -0500
> Rob Clark wrote:
>
>> From: Rob Clark
>>
>> Signed-off-by: Rob Clark
>> ---
>> docs/WL_bind_wayland_display.spec |5 +
>> include/EGL/eglmesaext.h |1 +
>> 2 files changed, 6 inser
https://bugs.freedesktop.org/show_bug.cgi?id=79885
--- Comment #4 from Marc Dietrich ---
Patch from Niels fixed it.
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop
On Tue, Jun 10, 2014 at 02:57:41PM +0100, Emil Velikov wrote:
> On 10/06/14 03:25, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > LLVM is enabled by default for some architectures, but the test was failing
> > before that.
> >
> Thanks for fixing my silly mistake Michel. Would you mind CC-
On 10/06/14 15:17, Niels Ole Salscheider wrote:
> This fixes automake builds which are broken since
> b52a530ce2aada1967bc8fefa83ab53e6a737dae.
>
Not sure what I was smoking with the above mentioned patch.
Seem like I've completely forgotten about automake :\
Niels can you please drop the FEATURE
https://bugs.freedesktop.org/show_bug.cgi?id=79885
--- Comment #5 from Emil Velikov ---
Above I mentioned scons, yet completely missed out on our main build system -
automake.
Niels patch is the correct solution but I would appreciate if he can remove the
feature defines from the target as well.
On Tuesday 10 June 2014, 16:18:56, Emil Velikov wrote:
> On 10/06/14 15:17, Niels Ole Salscheider wrote:
> > This fixes automake builds which are broken since
> > b52a530ce2aada1967bc8fefa83ab53e6a737dae.
>
> Not sure what I was smoking with the above mentioned patch.
> Seem like I've completely f
On 06/09/2014 05:26 AM, Brian Paul wrote:
> The code did not correctly handle super-string handling. For example,
> if we were searching for "WGL_ARB_pixel_format" but we found
> "WGL_ARB_pixel_format_float" we'd stop searching and return 0. Now
> we search past that initial, incorrect match.
Th
On 06/09/2014 02:11 PM, Matt Turner wrote:
> +/* Note that this function does not attempt to recognize that reduction trees
> + * are already balanced.
> + */
> +static void
> +is_reduction(ir_instruction *ir, void *data)
> +{
> + struct is_reduction_data *ird = (struct is_reduction_data *)data;
On 06/09/2014 02:11 PM, Matt Turner wrote:
> Cuts five instructions out of SynMark's Gl32VSInstancing benchmark.
> ---
> src/glsl/opt_algebraic.cpp | 46
> ++
> 1 file changed, 46 insertions(+)
>
> diff --git a/src/glsl/opt_algebraic.cpp b/src/glsl/opt
Hi Brian,
I think I've pushed this patch. Could you verify that I haven't broken
anything?
Thanks!
Courtney
On Fri, Jun 6, 2014 at 7:20 PM, Brian Paul wrote:
>
> Reviewed-by: Brian Paul
>
> Do you need someone to commit/push this for you?
>
> -Brian
>
>
> On 06/06/2014 12:04 PM, Cody Northro
On 06/09/2014 07:48 AM, Robert Bragg wrote:
> This makes sure to use a no-op swizzle while iteratively rendering each
> level of a mipmap otherwise we may loose components and effectively
> apply the swizzle twice by the time these levels are sampled.
Right... the swizzle state shouldn't affect mi
On Tue, Jun 10, 2014 at 9:46 AM, Ian Romanick wrote:
> On 06/09/2014 02:11 PM, Matt Turner wrote:
>> Cuts five instructions out of SynMark's Gl32VSInstancing benchmark.
>> ---
>> src/glsl/opt_algebraic.cpp | 46
>> ++
>> 1 file changed, 46 insertions(+
The code that parses LIBGL_DRIVERS_PATH was printing an
error for every attempted dlopen. It's not an error to
have to check multiple items in the path, only an error if
no suitable library is found. Reduced the load error to
a warning to match behavior of dynamic linker.
Signed-off-by: Courtney G
On Tue, Jun 10, 2014 at 12:57:31AM +0200, thomashellan...@gmail.com wrote:
> From: Thomas Helland
>
For the series:
Reviewed-by: Tom Stellard
Do these patches make any measurable improvement in compile time?
-Tom
> This series removes some unused includes in the glsl-directory.
> These were
Our most frequently used list implementation was only usable from
C by manipulating the members of the structs. This series adds a
C API, wraps the C API with the C++ member functions (so no change
for C++ code), makes the foreach_list macros usable from C, and
replaces an open-coded list in the i9
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 29 +++--
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 2 +-
src/mesa/drivers/dri/i965/intel_resolve_map.c | 60 ++-
src/mesa/drivers/dri/i965/intel_resolve_map.h | 16 +++
4 files changed, 45 insertions(+)
---
src/glsl/list.h | 90 +
1 file changed, 13 insertions(+), 77 deletions(-)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 49a9a5e..da81062 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -489,131 +489,67 @@ exec_node_insert_li
---
src/glsl/list.h | 145
1 file changed, 83 insertions(+), 62 deletions(-)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 694b686..6216855 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -83,67 +83,29 @@ struct exec_node {
---
src/glsl/list.h | 141
1 file changed, 141 insertions(+)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index ce7f81f..a1200ac 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -360,6 +360,147 @@ struct exec_list {
#endif
};
+st
---
src/glsl/list.h | 235 ++--
1 file changed, 127 insertions(+), 108 deletions(-)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 6216855..205dc91 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -242,75 +242,19 @@ struct exec_list {
---
src/glsl/list.h | 82 +
1 file changed, 82 insertions(+)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 205dc91..ce7f81f 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -129,6 +129,88 @@ struct exec_node {
#endif
};
+stat
---
src/glsl/list.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index 803aab5..576bc14 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -129,6 +129,13 @@ struct exec_node {
#endif
};
+static inline void
+exec_node_init(struct exec_node *n)
---
src/glsl/list.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index da81062..803aab5 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -556,13 +556,13 @@ inline void exec_node::insert_before(exec_list *before)
---
src/glsl/list.h | 38 +++---
1 file changed, 11 insertions(+), 27 deletions(-)
diff --git a/src/glsl/list.h b/src/glsl/list.h
index a1200ac..49a9a5e 100644
--- a/src/glsl/list.h
+++ b/src/glsl/list.h
@@ -214,73 +214,57 @@ exec_node_is_head_sentinel(const struct
On Sat, Jun 07, 2014 at 01:24:39PM -0700, Greg Fischer wrote:
> LunarG, with support from Valve, announces the GlassyMesa project, an
> effort to bring the LLVM compiler infrastructure to Mesa.
>
This is very interesting. Have you done any testing with any of the
Gallium drivers?
How difficult
On Mon, Jun 9, 2014 at 3:57 PM, wrote:
> From: Thomas Helland
>
> This series removes some unused includes in the glsl-directory.
Thanks. A lot of people use ccache, so series like this cause them to
have to rebuild (and not use ccache).
I've just sent a series that touches src/glsl's list.h,
On Fri, May 30, 2014 at 05:31:10PM +0200, Bruno Jiménez wrote:
> ---
> src/gallium/docs/source/screen.rst | 2 ++
> src/gallium/include/pipe/p_defines.h | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
Reviewed-by: Tom Stellard
>
> diff --git a/src/gallium/docs/source/screen.rst
>
On Fri, May 30, 2014 at 05:31:12PM +0200, Bruno Jiménez wrote:
Reviewed-by: Tom Stellard
> ---
> src/gallium/state_trackers/clover/api/device.cpp | 2 +-
> src/gallium/state_trackers/clover/core/device.cpp | 6 ++
> src/gallium/state_trackers/clover/core/device.hpp | 1 +
> 3 files changed
On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
>
> With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
> And with the attached patch as #2 for my series I can get the correct
> number of compute units for my CEDAR.
>
> But I don't know how or where I should add
On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
> On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
> >
> > With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
> > And with the attached patch as #2 for my series I can get the correct
> > number of compute un
On 06/10/2014 11:00 AM, Matt Turner wrote:
> Our most frequently used list implementation was only usable from
> C by manipulating the members of the structs. This series adds a
> C API, wraps the C API with the C++ member functions (so no change
> for C++ code), makes the foreach_list macros usabl
On 06/10/2014 11:00 AM, Matt Turner wrote:
> ---
> src/glsl/list.h | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/src/glsl/list.h b/src/glsl/list.h
> index da81062..803aab5 100644
> --- a/src/glsl/list.h
> +++ b/src/glsl/list.h
> @@ -556,13 +556,
(I was trying to be too clever with git-sendmail and I accidentally
sent this to the wrong list… sorry!)
Jason wrote:
> Kristian and I were looking at this today, and there seems to be a
> substantial race in the way that we are doing texture locking.
Yes, it does look like this is a problem. I
On 06/09/2014 09:43 AM, Neil Roberts wrote:
> When a multisampled texture is used for sampling the fast clear color value
> needs to be programmed into the surface state. This was being left as all
> zeroes so if the surface was cleared to a value other than black then it
> wouldn't work properly.
On 06/09/2014 12:36 AM, Kenneth Graunke wrote:
> We have this wonderful thing called an optimizer---maybe we should
> consider calling it?
That's really weird. The *only* place this is called is in ir_to_mesa.
It seems like the assember should just call it after assembling any
program. Weird.
On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick wrote:
> On 06/10/2014 11:00 AM, Matt Turner wrote:
>> ---
>> src/glsl/list.h | 22 +++---
>> 1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/glsl/list.h b/src/glsl/list.h
>> index da81062..803aab5 100644
>> -
On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick wrote:
> On 06/10/2014 11:00 AM, Matt Turner wrote:
>> Our most frequently used list implementation was only usable from
>> C by manipulating the members of the structs. This series adds a
>> C API, wraps the C API with the C++ member functions (so no
On 05/22/2014 02:45 PM, Cody Northrop wrote:
> Greetings,
>
> I ran into a problem with how Mesa on i965 handles MaxAnisotropy.
>
> The app I'm looking at sets sampler state min and mag filters to
> GL_NEAREST, but also sets GL_TEXTURE_MAX_ANISOTROPY_EXT, like so:
>
> glSamplerParameteri(po
On 02/24/2014 02:55 PM, Matt Turner wrote:
> On Mon, Feb 24, 2014 at 2:04 PM, Jon Ashburn wrote:
>> Add Intel driver hook for glGetTexImage to accelerate the case of reading
>> texture image into a PBO. This case gets huge performance gains by using
>> GPU BLIT directly to PBO rather than GPU BLI
>
>
> Yep, no new warnings.
>
> I tried a little test program
> % cat t.cpp
> class asdf {
> int x;
> };
>
> void f() {
> asdf a;
> struct asdf b;
> class asdf c;
> }
>
C++ never ceases to amaze.
> and I can't make it generate warnings (other than unused variables)
> regardless of
On 06/10/2014 12:06 PM, Matt Turner wrote:
> On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick wrote:
>> On 06/10/2014 11:00 AM, Matt Turner wrote:
>>> ---
>>> src/glsl/list.h | 22 +++---
>>> 1 file changed, 11 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/src/glsl/list.h b/sr
On Tue, Jun 10, 2014 at 08:36:05PM +0200, Bruno Jimenez wrote:
> On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
> > On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
> > >
> > > With a couple of changes, it applied cleanly to 3.14.5 (Arch's stable).
> > > And with the attached
On Tue, Jun 10, 2014 at 3:23 PM, Tom Stellard wrote:
> On Tue, Jun 10, 2014 at 08:36:05PM +0200, Bruno Jimenez wrote:
>> On Tue, 2014-06-10 at 14:10 -0400, Tom Stellard wrote:
>> > On Thu, Jun 05, 2014 at 08:39:29PM +0200, Bruno Jimenez wrote:
>> > >
>> > > With a couple of changes, it applied cle
See v2 of patch sent to mesa-dev list in early March:
http://lists.freedesktop.org/archives/mesa-dev/2014-March/055350.html
Or I can resend this v2 patch if needed.
Jon
On 06/10/2014 01:14 PM, Ian Romanick wrote:
On 02/24/2014 02:55 PM, Matt Turner wrote:
On Mon, Feb 24, 2014 at 2:04 PM, Jon
On Mon, May 19, 2014 at 06:14:50PM +0200, Bruno Jiménez wrote:
> Hi,
>
> Firstly, I shall introduce myself (at least more formally than just
> sending some patches). My name is Bruno Jiménez, I'm studying
> physics at Zaragoza's University (Spain) and I am participating in
> this year's Google Sum
On Wed, May 28, 2014 at 4:44 PM, Connor Abbott wrote:
> On Tue, May 27, 2014 at 9:47 PM, Matt Turner wrote:
>> Here's a respin of my load_payload series from mid-April with some
>> feedback from Ken addressed and some bugs fixed.
>>
>> This series is available in my tree (with a few unrelated pat
On 06/10/2014 12:10 PM, Matt Turner wrote:
> On Tue, Jun 10, 2014 at 11:38 AM, Ian Romanick wrote:
>> On 06/10/2014 11:00 AM, Matt Turner wrote:
>>> Our most frequently used list implementation was only usable from
>>> C by manipulating the members of the structs. This series adds a
>>> C API, wra
On 06/10/2014 12:26 PM, Jon Ashburn wrote:
> See v2 of patch sent to mesa-dev list in early March:
>
> http://lists.freedesktop.org/archives/mesa-dev/2014-March/055350.html
>
> Or I can resend this v2 patch if needed.
That's weird. I have v1 in my inbox, but I don't have v2. Anyway...
Other
Reviewed-by: Chris Forbes
On Wed, Jun 11, 2014 at 6:51 AM, Ian Romanick wrote:
> On 06/09/2014 09:43 AM, Neil Roberts wrote:
>> When a multisampled texture is used for sampling the fast clear color value
>> needs to be programmed into the surface state. This was being left as all
>> zeroes so if
On 11 June 2014 00:02, Zack Rusin wrote:
> That looks wrong. The total number of verts per buffer is the maximum number
> of verts that can be output per invocation (primitive_boundary) times number
> of invocations of geometry shader (num_in_primitives).
>
> It's not maximum number of verts th
I think the code is already correct and something else goes wrong. The tgsi
geometry shader code was never done properly so it's more than likely that
tgsi_exec is doing something wonky.
Geometry shaders specify the maximum number of vertices that they can emit.
That's what draw_geometry_shader
Hi,
Thank you very much!!
On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák wrote:
> This is probably one of the most difficult tasks. You'll need to:
>
> 1) Add support to Mesa core - new shader stages and the new OpenGL
> functions and queries (src/mesa/main)
>
Ya. This one is straight forward. Th
Tom Stellard writes:
> On Fri, May 30, 2014 at 05:31:10PM +0200, Bruno Jiménez wrote:
>> ---
>> src/gallium/docs/source/screen.rst | 2 ++
>> src/gallium/include/pipe/p_defines.h | 3 ++-
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> Reviewed-by: Tom Stellard
>
Reviewed-by: Francisc
Tom Stellard writes:
> On Fri, May 30, 2014 at 05:31:12PM +0200, Bruno Jiménez wrote:
>
> Reviewed-by: Tom Stellard
Reviewed-by: Francisco Jerez
>
>> ---
>> src/gallium/state_trackers/clover/api/device.cpp | 2 +-
>> src/gallium/state_trackers/clover/core/device.cpp | 6 ++
>> src/galli
Well, we could just pull radeon_drm.h into Mesa to simplify
the process since libdrm_radeon doesn't really need the updated
header anymore.
Marek
On Tue, Jun 10, 2014 at 9:25 PM, Alex Deucher wrote:
> On Tue, Jun 10, 2014 at 3:23 PM, Tom Stellard wrote:
>> On Tue, Jun 10, 2014 at 08:36:05PM +02
On 11 June 2014 06:23, Zack Rusin wrote:
> I think the code is already correct and something else goes wrong. The tgsi
> geometry shader code was never done properly so it's more than likely that
> tgsi_exec is doing something wonky.
>
> Geometry shaders specify the maximum number of vertices th
For the first two points, a partial implementation is already done here:
https://github.com/fabe3k/mesa/commits/tessellation
This predates the addition of ARB_separate_shader_objects, which has
some interactions. There are probably also plenty of rough edges, but
it should give you enough to get
Hi,
On Tue, Jun 10, 2014 at 5:06 PM, Chris Forbes wrote:
> For the first two points, a partial implementation is already done here:
>
> https://github.com/fabe3k/mesa/commits/tessellation
>
> This predates the addition of ARB_separate_shader_objects, which has
> some interactions. There are pro
On Tue, Jun 10, 2014 at 10:45 PM, Aditya Avinash
wrote:
> Hi,
> Thank you very much!!
>
> On Mon, Jun 9, 2014 at 10:19 AM, Marek Olšák wrote:
>>
>> This is probably one of the most difficult tasks. You'll need to:
>>
>> 1) Add support to Mesa core - new shader stages and the new OpenGL
>> functio
Thanks for the review!
These patches, along with 5 more I've put together,
don't have any significant impact on compile time.
But that's only 16 files, so it really shouldn't be expected I guess.
A similar effort on firefox gave a 12.5% compile-time improvement though,
so eventually we should be s
On Tue, Jun 10, 2014 at 3:39 PM, Thomas Helland
wrote:
> Where I do see an impact though is recompiling after changes.
> Less object-files needs to be recompiled, so it's often a lot faster.
> I don't have any specific numbers here though.
Oh, that's a good point that I hadn't considered. Thanks!
This code does nothing useful as the next recursive call on the array element
will override any null values if the element is a record anyway. The code is
also not doing what the comment says as its trying to set the record type
pointer for only the first element of the array not the first leaf
On 06/10/2014 04:39 PM, Thomas Helland wrote:
Thanks for the review!
These patches, along with 5 more I've put together,
don't have any significant impact on compile time.
But that's only 16 files, so it really shouldn't be expected I guess.
A similar effort on firefox gave a 12.5% compile-time
---
I'm planning to squash this in to make Abdiel's patches easier
to merge.
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_fs_
On Sun, Jun 1, 2014 at 12:01 AM, Kenneth Graunke wrote:
> On Friday, April 18, 2014 11:56:51 AM Matt Turner wrote:
>> ---
>> .../drivers/dri/i965/brw_fs_register_coalesce.cpp | 59
> ++
>> 1 file changed, 49 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/mesa/drivers/d
---
I'm planning to squash this in to address review comments.
src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/brw_fs_register
On Tue, May 27, 2014 at 6:47 PM, Matt Turner wrote:
> Here's a respin of my load_payload series from mid-April with some
> feedback from Ken addressed and some bugs fixed.
>
>git://people.freedesktop.org/~mattst88/mesa tex-sources
I've force pushed an updated and rebased branch.
> I'd really
---
Easiest thing for now seems to be to bail if we see these
kinds of dereferences. I'll squash this in, adding a description
of the things we don't handle.
src/glsl/opt_rebalance_tree.cpp | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/glsl/opt_rebalance_tree.cpp
> I'll revisit it today and see if I can spot something else wrong, it
> fails for triangle adj because there are 6 vertices per primitive and
> we have only malloced space for 4.
It has to be something else because that's impossible, in fact it's 2x
impossible ;)
1) It's illegal and impossible
On 11 June 2014 10:18, Zack Rusin wrote:
>> I'll revisit it today and see if I can spot something else wrong, it
>> fails for triangle adj because there are 6 vertices per primitive and
>> we have only malloced space for 4.
>
> It has to be something else because that's impossible, in fact it's 2x
From: Dave Airlie
One of the mismatched tests have a max output vertices of 3,
but emits 6 vertices, this means the output buffer is undersized
and causes problems down the line, so limit things later if we
have a number of vertices lower than the number required to execute
a primitive.
Signed-o
On 11.06.2014 00:07, Tom Stellard wrote:
> On Tue, Jun 10, 2014 at 02:57:41PM +0100, Emil Velikov wrote:
>> On 10/06/14 03:25, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> LLVM is enabled by default for some architectures, but the test was failing
>>> before that.
>>>
>> Thanks for fixing
To be honest I still don't like it. While the tgsi_exec specific paths in
draw_gs don't matter to me and can be as ugly as they need to be, they can't be
polluting the draw_pt_emit code, in other words the primitive_lengths can't be
bogus at that point - prim_info can't lie about the amount of d
On Tuesday, March 04, 2014 05:34:44 PM Jon Ashburn wrote:
> Add Intel driver hook for glGetTexImage to accelerate the case of reading
> texture image into a PBO. This case gets huge performance gains by using
> GPU BLIT directly to PBO rather than GPU BLIT to temporary texture followed
> by memcpy
On 11 June 2014 10:48, Zack Rusin wrote:
> To be honest I still don't like it. While the tgsi_exec specific paths in
> draw_gs don't matter to me and can be as ugly as they need to be, they can't
> be polluting the draw_pt_emit code, in other words the primitive_lengths
> can't be bogus at that
From: Dave Airlie
This limits the number of emitted vertices to the shaders max output
vertices, and avoids us writing things into memory that isn't big
enough for it.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 8
src/gallium/auxiliary/tgsi/tgsi_exec.h | 1
Looks great. If I was into diffs I'd make sweet and passionate love to this one.
Reviewed-by: Zack Rusin
- Original Message -
> From: Dave Airlie
>
> This limits the number of emitted vertices to the shaders max output
> vertices, and avoids us writing things into memory that isn't big
Hi Tom,
On 6/10/2014 12:03 PM, Tom Stellard wrote:
On Sat, Jun 07, 2014 at 01:24:39PM -0700, Greg Fischer wrote:
LunarG, with support from Valve, announces the GlassyMesa project, an
effort to bring the LLVM compiler infrastructure to Mesa.
This is very interesting. Have you done any testing
From: Ian Romanick
brw_vec4_visitor.cpp:2717:1: warning: unused parameter 'ir' [-Wunused-parameter]
brw_vec4_visitor.cpp:2723:1: warning: unused parameter 'ir' [-Wunused-parameter]
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 4 ++--
1 file changed, 2 insert
From: Ian Romanick
Previously we would emit the comparison, emit an AND to mask off extra
bits from the comparison result, then convert the result to float. Now,
do the comparison, then use a cleverly constructed SEL to pick either
0.0f or 1.0f.
No piglit regressions on Ivybridge.
NOTE: I have
From: Ian Romanick
And delete the incorrect comment.
Signed-off-by: Ian Romanick
---
src/glsl/ir_uniform.h| 7 ++-
src/mesa/main/uniforms.c | 2 +-
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/glsl/ir_uniform.h b/src/glsl/ir_uniform.h
index 3508509..4829eb7 100644
Please stop adding them.
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index eaca378..c6664b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -543,7 +543,7 @@ darwin*|mingw*)
*)
AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=
---
configure.ac | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index 17e9e9c..4b27455 100644
--- a/configure.ac
+++ b/configure.ac
@@ -149,7 +149,7 @@ _SAVE_LDFLAGS="$LDFLAGS"
_SAVE_CPPFLAGS="$CPPFLAGS"
dnl Compiler macros
-DEFINES
This isn't supposed to be difficult.
---
configure.ac | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index c6664b9..17e9e9c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2230,23 +2230,23 @@ AC_CONFIG_FILES([Makefile
1 - 100 of 120 matches
Mail list logo
