On Mon, Feb 13, 2012 at 5:10 AM, Zhigang Gong
wrote:
> On Sun, Feb 12, 2012 at 09:02:44AM -0500, nobled wrote:
>> Judging by the patch that tried to change the tls_model:
>> https://bugs.freedesktop.org/show_bug.cgi?id=35268
>> It looks like we'd need to disable enable_asm if the tls_model
>> attr
From: Zhigang Gong
This version fixed the CFLAGS setting when check whether support
tls model.
---
This patchset enable GLX_USE_TLS if the system support
it. And this patchset will check whether we support tls
model and choose propriate method to define those TLS
variables rather than define th
From: Zhigang Gong
If the system support tls, we prefer to enable it by default
just as xserver does. Actually, the checking code is copied
from xserver/configure.ac.
According to nobled's suggestion, move the checking before
enable_asm. As if tls_model is not supported, then asm may
can't work c
From: Zhigang Gong
Use the properate way detected in autoconf stage to define
those TLS variables rather than using hard coded
"attribute..."
Signed-off-by: Zhigang Gong
---
src/egl/main/eglcurrent.c |3 +--
src/glx/glxclient.h|3 +--
src/glx/glxcurrent
Personally i don't care much about non-autoconf builds, but as this relies on a
-DTLS= setting during configuration time, it will break non-ac builds (which
need tls), no?
Other than that, LGTM.
-tom
On 15.02.2012, at 12:41, zhigang.g...@linux.intel.com wrote:
> From: Zhigang Gong
>
> Use t
Hi everyone,
this series adds the ARB_debug_output extension. It implements the minimum
feature set required by the spec, which is GL API error logging.
I've added a new piglit test for this: arb_debug_output-api_error. I'd like to
push this series in a week if there are no concerns.
The whole
From: nobled
Also add _mesa_vsnprintf.
---
src/mesa/SConscript |1 +
src/mesa/main/descrip.mms |3 +
src/mesa/main/errors.c| 276 +
src/mesa/main/errors.h| 66 +++
src/mesa/main/imports.c | 245 +-
From: nobled
Marek v2: replace GLDEBUGPROCARB with void*
---
src/mapi/glapi/gen/ARB_debug_output.xml | 93 +++
src/mapi/glapi/gen/Makefile |1 +
src/mapi/glapi/gen/gl_API.xml |2 +
3 files changed, 96 insertions(+), 0 deletions(-)
crea
From: nobled
Marek v2: don't add the extension to extensions.c yet
---
src/mesa/main/config.h|6 ++
src/mesa/main/context.c |1 +
src/mesa/main/enable.c|5 +
src/mesa/main/errors.c| 13 -
src/mesa/main/errors.h|3 +++
src/mesa/main/get.c
From: nobled
---
src/mesa/main/api_exec.c | 12 ++-
src/mesa/main/errors.c | 274 ++
src/mesa/main/errors.h |4 +
3 files changed, 286 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/api_exec.c b/src/mesa/main/api_exec.c
index 605a
From: nobled
---
src/mesa/main/errors.c |2 +-
src/mesa/main/mtypes.h | 28 +++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index e43b31f..ed94841 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa
From: nobled
Controlling the output of client-provided messages
isn't done yet.
---
src/mesa/main/errors.c | 134
1 files changed, 134 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index ed94841..3b0a
From: nobled
---
src/mesa/main/mtypes.h | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 5c2afa2..be7e721 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3229,6 +3229,13 @@ typedef enum {
From: nobled
This state is needed for deciding whether or not to log
application messages with IDs that haven't been specifically
passed to glDebugMessageControlARB yet.
State for each individual ID number ever passed to
glDebugMessageControlARB (per-context) still needs to be added.
---
src/me
From: nobled
The final piece of the puzzle for GL_ARB_debug_output.
---
src/mesa/main/mtypes.h | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index be7e721..e79c809 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/me
From: nobled
Store client-defined message IDs in a hash table,
and sort them by severity into three linked lists
so they can be selected by severity level later.
---
src/mesa/main/context.c |2 +
src/mesa/main/errors.c | 268 ++-
src/mesa/main/er
---
src/mesa/main/errors.c | 97 ---
1 files changed, 66 insertions(+), 31 deletions(-)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index e736e04..611c77d 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -939,21 +93
---
src/mesa/main/dlist.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index 677debf..231d7e4 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -10390,6 +10390,9 @@ _mesa_create_save_table(void)
SET_Tex
---
src/mesa/main/extensions.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index d945124..732b9a6 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -82,6 +82,7 @@ static const struct exte
Even if the system supports tls, the x server may not have been built with it.
As i recall, there is an issue with mismatching tls between x and drivers...
Can a non-tls server load a tls driver?
Anyway, if there's an issue there, this check must be more complicated -- it
can't be just, "does
On Wed, Feb 15, 2012 at 7:52 AM, tf (mobile) wrote:
> Even if the system supports tls, the x server may not have been built with
> it. As i recall, there is an issue with mismatching tls between x and
> drivers... Can a non-tls server load a tls driver?
I don't think mismatching TLS/non-TLS Me
On Wed, Feb 15, 2012 at 8:28 AM, Marek Olšák wrote:
> nobled (10):
Linus doesn't even accept patches from people who don't set their name
in ~/.gitconfig. Can you please set your name?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://list
On Tue, 14 Feb 2012 12:43:22 -0800, Kenneth Graunke
wrote:
> Commit dc7f449d1ac53a66e6efb56ccf2a5953418a26ca introduced a new method
> for avoiding MOVs: try to rewrite the destination of the instruction
> that produced the RHS so it writes into the LHS.
>
> Unfortunately, this is not safe for s
https://bugs.freedesktop.org/show_bug.cgi?id=46082
--- Comment #1 from Brian Paul 2012-02-15 14:18:47 PST ---
I think this is actually a bug in the piglit test.
The glTexSubImage call in question can generate either GL_INVALID_ENUM or
GL_INVALID_OPERATION depending on what order glTexSubImage()
On 02/08/2012 11:41 AM, Kenneth Graunke wrote:
On 02/08/2012 06:59 AM, Brian Paul wrote:
On 02/08/2012 06:08 AM, Kenneth Graunke wrote:
The application supplied [start, end] range is merely a conservative
hint of the ranges of index values inside the index buffer. There is no
requirement that a
If the texture format is integer, the incoming user data must also be
integer (and similarly for non-integer textures).
NOTE: This is a candidate for the stable branches.
---
src/mesa/main/teximage.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main
We always say no. Improves VS state change microbenchmark performance
7.68747% +/- 1.40826% (n=10).
---
src/mesa/drivers/dri/i965/brw_state_upload.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_state_upload.c
b/src/mesa/drivers/dri/i965/b
Improves VS state change microbenchmark performance by 7.08729% +/-
1.22289% (n=10) on gen7, because we don't upload the 64 dwords of
unused binding table any more.
---
src/mesa/drivers/dri/i965/brw_context.h | 23 +++---
src/mesa/drivers/dri/i965/brw_misc_state.c |2 +-
src/mesa/
This is a step toward making the samplers/binding tables reflect
sampler uniform mappings instead of embedding those in the programs.
No significant performance difference on the microbenchmark (n=10).
---
src/mesa/drivers/dri/i965/brw_context.h | 34 +++---
src/mesa/drivers/dri
Improves VS state change microbenchmark performance 2.38246% +/-
1.15046% (n=20).
---
src/mesa/drivers/dri/i965/brw_context.h |4 ---
src/mesa/drivers/dri/i965/gen6_clip_state.c | 31 --
src/mesa/drivers/dri/i965/gen7_clip_state.c | 11 -
3 files changed
Improves VS state change microbenchmark performance 1.78817% +/-
0.556878% (n=25).
---
src/mesa/drivers/dri/i965/brw_context.h | 11 ++-
src/mesa/drivers/dri/i965/brw_wm.c|9 +
src/mesa/drivers/dri/i965/gen6_wm_state.c |7 ++-
src/mesa/drivers/dri/i965/gen7_
Over the last six months a lot of feature work has happened in Mesa, and
the load has been carried by a lot of different people / organization.
In the process, we discovered a number of development process issues
that made things more difficult than they needed to be.
The biggest problem the w
---
src/mesa/drivers/dri/i965/brw_context.h | 10 +++
src/mesa/drivers/dri/i965/brw_misc_state.c|4 +-
src/mesa/drivers/dri/i965/brw_state.h |2 +-
src/mesa/drivers/dri/i965/brw_state_upload.c |6 ++--
src/mesa/drivers/dri/i965/brw_wm_surface_st
As suggested by Brian, for a 1D texture array, the border only applies to
the width. For a 2D texture array the border applies to the width and
height but not to the depth. This was not handled correctly in
_mesa_init_teximage_fields().
Note: This is a candidate for stable branches
Signed-off-b
> -Original Message-
> From: tf (mobile) [mailto:tfo...@sci.utah.edu]
> Sent: Wednesday, February 15, 2012 8:53 PM
> To: zhigang.g...@linux.intel.com
> Cc: dbn.li...@gmail.com; nob...@dreamwidth.org;
> mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH v3 1/2] configure.ac: Ena
On Wed, Feb 15, 2012 at 03:41:01PM -0700, Brian Paul wrote:
> If the texture format is integer, the incoming user data must also be
> integer (and similarly for non-integer textures).
>
> NOTE: This is a candidate for the stable branches.
> ---
> src/mesa/main/teximage.c | 11 +++
> 1 f
Here's an attempt at cutting update_texture_state overhead, which has
been noted a few times as a big CPU consumer in Mesa. It looks pretty
promising on gen7 (though the binding table patches in the other
series would make the impact of patch 2 less significant). However,
with the GPU hangs in th
There are three reasons left for this function flagging it:
Re-computing completeness (and therefore the number of levels),
binding a new current texture object, or you're doing some sort of
fixed function (and nobody cares). For other cases, like rebinding a
shader, we no longer trigger the drive
None of the consumers of this state will be called while the fs or vs
is in place, and the update_texture_state() call will get re-called on
fs/vs change, so it should be safe to skip the computation. Improves
the performance of a VS state change microbenchmark by 1.60186% +/-
0.443318% (n=20).
--
On Wed, Feb 15, 2012 at 18:01, Eric Anholt wrote:
> There are three reasons left for this function flagging it:
> Re-computing completeness (and therefore the number of levels),
> binding a new current texture object, or you're doing some sort of
> fixed function (and nobody cares). For other cas
On 02/15/2012 05:15 PM, Matt Turner wrote:
On Wed, Feb 15, 2012 at 7:52 AM, tf (mobile) wrote:
Even if the system supports tls, the x server may not have been built with it.
As i recall, there is an issue with mismatching tls between x and drivers...
Can a non-tls server load a tls driver?
On 02/16/2012 01:57 AM, Zhigang Gong wrote:
-Original Message-
From: tf (mobile) [mailto:tfo...@sci.utah.edu]
Sent: Wednesday, February 15, 2012 8:53 PM
To: zhigang.g...@linux.intel.com
Cc: dbn.li...@gmail.com; nob...@dreamwidth.org;
mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev]
42 matches
Mail list logo
