[Mesa-dev] [PATCH] ra: Add ra_set_node_reg()

[Tom Stellard]

This function makes it possible to include input / payload registers in
the interference graph.
---
 src/mesa/program/register_allocate.c |   21 ++---
 src/mesa/program/register_allocate.h |1 +
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/src/mesa/program/register_allocate.c 
b/src/mesa/program/register_allocate.c
index 95a9bde..40df95b 100644
--- a/src/mesa/program/register_allocate.c
+++ b/src/mesa/program/register_allocate.c
@@ -37,6 +37,8 @@
 #include "main/mtypes.h"
 #include "register_allocate.h"
 
+#define NO_REG ~0
+
 struct ra_reg {
GLboolean *conflicts;
unsigned int *conflict_list;
@@ -227,7 +229,7 @@ ra_alloc_interference_graph(struct ra_regs *regs, unsigned 
int count)
   g->nodes[i].adjacency_list = ralloc_array(g, unsigned int, count);
   g->nodes[i].adjacency_count = 0;
   ra_add_node_adjacency(g, i, i);
-  g->nodes[i].reg = ~0;
+  g->nodes[i].reg = NO_REG;
}
 
return g;
@@ -287,7 +289,7 @@ ra_simplify(struct ra_graph *g)
   progress = GL_FALSE;
 
   for (i = g->count - 1; i >= 0; i--) {
-if (g->nodes[i].in_stack)
+if (g->nodes[i].in_stack || g->nodes[i].reg != NO_REG)
continue;
 
 if (pq_test(g, i)) {
@@ -367,7 +369,7 @@ ra_optimistic_color(struct ra_graph *g)
unsigned int i;
 
for (i = 0; i < g->count; i++) {
-  if (g->nodes[i].in_stack)
+  if (g->nodes[i].in_stack || g->nodes[i].reg != NO_REG)
 continue;
 
   g->stack[g->stack_count] = i;
@@ -391,6 +393,19 @@ ra_get_node_reg(struct ra_graph *g, unsigned int n)
return g->nodes[n].reg;
 }
 
+/**
+ * This function allows a user to manually assign a register to a node.  This
+ * is useful for nodes that belong to register classes that contain a very 
small
+ * number of registers that are not likely to be allocated if they end up at
+ * the bottom of the stack.
+ */
+void
+ra_set_node_reg(struct ra_graph *g, unsigned int n, unsigned int reg)
+{
+   g->nodes[n].reg = reg;
+   g->nodes[n].in_stack = GL_FALSE;
+}
+
 static float
 ra_get_spill_benefit(struct ra_graph *g, unsigned int n)
 {
diff --git a/src/mesa/program/register_allocate.h 
b/src/mesa/program/register_allocate.h
index 198b89f..5b95833 100644
--- a/src/mesa/program/register_allocate.h
+++ b/src/mesa/program/register_allocate.h
@@ -65,6 +65,7 @@ GLboolean ra_select(struct ra_graph *g);
 GLboolean ra_allocate_no_spills(struct ra_graph *g);
 
 unsigned int ra_get_node_reg(struct ra_graph *g, unsigned int n);
+void ra_set_node_reg(struct ra_graph * g, unsigned int n, unsigned int reg);
 void ra_set_node_spill_cost(struct ra_graph *g, unsigned int n, float cost);
 int ra_get_best_spill_node(struct ra_graph *g);
 /** @} */
-- 
1.7.3.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glsl: correctly handle conversions between int and uint

[Bryan Cain]

On 04/19/2011 05:43 PM, Ian Romanick wrote:
> On 04/18/2011 04:51 PM, Bryan Cain wrote:
> > This patch was revised several times before submitting, and even after
> > that I still wasn't sure that adding conversion operations was the right
> > solution.  So I'm not really surprised that there are problems with this
> > one. :)
>
> > On 04/18/2011 06:36 PM, Ian Romanick wrote:
> >> On 04/17/2011 11:39 PM, Bryan Cain wrote:
> >>> From the GLSL 1.30 specification, section 4.1.10 ("Implicit
> >> Conversions"):
> >>> "There are no implicit conversions between signed and unsigned
> >> integers."
> >>
> >>> However, convert_component() was assuming that conversions between
> >> int and uint were implicit.
> >>
> >> The conversions applied in convert_component only apply to constructor
> >> parameters.  As Ken mentions, in those cases we want
> >>
> >> Internally we treat signed and unsigned identically because the
> >> representation is the same.  There's no way for an application to
> >> observe the difference between:
> >>
> >> ivec4 a = ivec4(5 , 6 , 7 , 8 );
> >> ivec4 b = ivec4(5 , 6 , 7 , 8u);
> >> ivec4 c = ivec4(5 , 6 , 7u, 8 );
> >> ivec4 d = ivec4(5 , 6 , 7u, 8u);
> >> ivec4 e = ivec4(5 , 6u, 7 , 8 );
> >> ivec4 f = ivec4(5 , 6u, 7 , 8u);
> >> ivec4 g = ivec4(5 , 6u, 7u, 8 );
> >> ivec4 h = ivec4(5 , 6u, 7u, 8u);
> >> // etc.
> >>
> >> The type checker ensures that operands to operations that could exhibit
> >> differing behavior (e.g., ir_bin_mul) have identical types.  That code
> >> lives in arithmetic_result_type in ast_to_hir.cpp.  There is similar
> >> code in match_function_by_name in ast_function.cpp.
> >>
> >> Do you have any specific test cases in mind that don't produce correct
> >> results with the existing code?
> > Yes, usages like this:
>
> > int var1 = 7;
> > uint var2 = uint(var1);
>
> > They were causing a type mismatch error in ast_to_hir.cpp because
> > convert_component() was treating the uint(int) constructor as a no-op.
>
> Ah, that makes sense.  I just sent some patches to the piglit mailing
> list with some tests in this vein.
>
> You've convinced me that we need i2u and u2i unary operators.  I don't
> think we need b2u and u2b operators because we can just do (i2b(u2i
> value)) and (i2u(b2i value)).  Ditto for f2i.  This should result in
> less churn in the backends since u2i and i2u will universally be no-ops.
>
> Almost every place that checks is_integer() will need to check for the
> specific type, either GLSL_TYPE_UINT or GLSL_TYPE_INT, that it expects.
>  This means that your patch 2/3, which is already applied, will need to
> be reverted.

Wouldn't it only apply to checks for destination types of most
operations, not source types?

In fact, if instructions store the destination type, what cases would
require the compiler beyond ast_to_hir to even care about the difference
between int and uint?

>
> >>> ---
> >>>  src/glsl/ast_function.cpp   |   16 
> >>>  src/glsl/ir.cpp |8 
> >>>  src/glsl/ir.h   |2 ++
> >>>  src/glsl/ir_constant_expression.cpp |8 
> >>>  src/glsl/ir_validate.cpp|8 
> >>>  5 files changed, 38 insertions(+), 4 deletions(-)
> >>
> >>> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
> >>> index e5cb873..cc3f032 100644
> >>> --- a/src/glsl/ast_function.cpp
> >>> +++ b/src/glsl/ast_function.cpp
> >>> @@ -267,17 +267,25 @@ convert_component(ir_rvalue *src, const
> >> glsl_type *desired_type)
> >>> assert(a <= GLSL_TYPE_BOOL);
> >>> assert(b <= GLSL_TYPE_BOOL);
> >>
> >>> -   if ((a == b) || (src->type->is_integer() &&
> >> desired_type->is_integer()))
> >>> +   if (a == b)
> >>>return src;
> >>
> >>> switch (a) {
> >>> case GLSL_TYPE_UINT:
> >>> case GLSL_TYPE_INT:
> >>> -  if (b == GLSL_TYPE_FLOAT)
> >>> +  switch(b) {
> >>> +  case GLSL_TYPE_UINT:
> >>> + result = new(ctx) ir_expression(ir_unop_u2i, desired_type,
> >> src, NULL);
> >>> + break;
> >>> +  case GLSL_TYPE_INT:
> >>> + result = new(ctx) ir_expression(ir_unop_i2u, desired_type,
> >> src, NULL);
> >>> + break;
> >>> +  case GLSL_TYPE_FLOAT:
> >>>   result = new(ctx) ir_expression(ir_unop_f2i, desired_type,
> >> src, NULL);
> >>
> >> With the other changes, leaving this as-is is kind of hinkey.  Here the
> >> result base type will be GLSL_TYPE_INT, but the desired based type
> could
> >> be GLSL_TYPE_UINT.
> > Unless I'm missing something, that case is handled by the line "if (a ==
> > b)".
>
> What I meant was uint(float) and int(float) will both generate an
> ir_unop_f2i, which has type int.  So, 'uint x = uint(5.2);' will result
> in a type error.  Right?

It's not resulting in one for me with the patch applied.  Are the exact
source and destination types not stored as part of an expression in GLSL IR?
___
mesa-dev

Re: [Mesa-dev] KWin and Mesa

[Henri Verbeet]

On 19 April 2011 16:52, Martin Gräßlin  wrote:
> Hi Mesa-devs,
>
> yesterday I published a rant about Mesa breaking KWin and given some
> comments on Phoronix Forums it seems like there is the wish for more
> communication between our development groups and so I want to start it. Please
> note that I am not subscribed to this mailing list, so please keep me in CC (I
> might not be able to reply this week at all). It is my wish to never have to
> rant about the state of Linux drivers any more and that I never have to see
> Mesa breaking KWin again.
>

I think there are a couple of points here, some of them already made
by others. Note that the following is mostly just how I personally see
things, not necessarily what anyone else thinks.

First, there's the specific issue your blog post talks about. While I
understand the issue, and can sympathize somewhat, I essentially think
you're just wrong there. (Yeah, I can be direct too.) It's perhaps
unfortunate that this change happened on a minor release, but the
basic issues are that blacklisting / whitelisting drivers is just a
bad idea, and you can't depend on renderer strings being stable. If
you do it anyway, it's going to break, you get to keep all the pieces,
and you can't blame the drivers.

In the more general case, I think hacking around driver bugs is about
the worst way to deal with driver bugs in GL applications. In the best
case you're just removing an incentive to fix the bug, but it's more
likely you just end up creating fragile code or depending on the bug
somehow. IMHO it's better to just direct users to the appropriate bug
tracker in those cases. You'll get some flak for that, but it's worth
it in the long term. Of course the best way would be to work on fixing
the bug in the upstream project, but I realize that may not always be
practical.

Note that I think distributions have some role to play here as well. I
think it's just about as unreasonable to expect driver developers to
test with every application as it would be to expect KWin developers
to test with every possible hardware / driver combination. (And you
can't say "My application is more important." either. You're going to
find plenty of users that would gladly have us e.g. completely break
KWin to make StarCraft 2 run faster, and viceversa.) Realistically
speaking we'll have to depend on users / testers testing with
development versions to find bugs before releases. If nobody reports
bugs that either means nobody noticed or nobody cares. An important
part of what distributions are supposed to do is making sure things
work well together, so I don't think it's all that unreasonable to
expect them to do that kind of testing and report / fix bugs where
appropriate. If it does come to the point of writing hacks (pending a
proper fix) it's probably also more appropriate for a distribution to
carry those than KWin.

Something else. Blogging is all modern and all, but it's really not
the most constructive way to make things actually happen. In fact, I
could certainly imagine this specific blog post causing some
resentment. In general, for specific bugs / regressions, please just
create a bug report, preferably with a small test case or even a
proposed patch. For more general issues posting to the mailing list or
just talking to people in IRC (#dri-devel) tends to work best. If you
really consider Mesa your most important upstream, it's probably a
good idea to be on the mailing list and IRC anyway, just to be aware
of what's going on, even if you end up not reading most of it.

Some more random remarks below:

> Due to the bugs KWin had hit in Mesa, KDE got a pretty bad Media coverage.
> This was something I did not like. The bugs were not in our software. I have
> no problems with admitting bugs in my part and I take blame for it, but I
> cannot stand being blamed for problems due to 3rd party breakage. So I wrote a
I'm afraid that's just reality. There's certainly enough
misinformation going around about e.g. Mesa, Wine, CrossOver, and just
about everything else as well. "News" sites with less than stellar
editorial standards don't exactly help either.

> hurts. Now feel free to shoot the messenger of bad news, but sorry it is the
> truth that Mesa just broke KWin.
I disagree with this, see the first part of my reply.

> mind. Given how important KWin is for you as a downstream I am really
> surprised to see that you do not do regression tests against KWin. What can we
> do to help you there?
Making sure the functionality required by KWin is covered by piglit
would probably go a long way. If KWin has its own set of automated
regression tests that's likely very helpful as well, though likely
more so for distributions than for Mesa directly. Mesa (like everyone
else?) doesn't exactly have huge amounts of developers / QA staff
waiting for something to do, so to make something happen there you'll
probably either have to automate it or find some people who care
specifically about KWin on Mesa and 

[Mesa-dev] [PATCH 8/8] glapi: add ARB_robustness xml

[nobled]

---
 src/mapi/glapi/gen/ARB_robustness.xml |  185 +
 src/mapi/glapi/gen/Makefile   |1 +
 src/mapi/glapi/gen/gl_API.xml |2 +
 3 files changed, 188 insertions(+), 0 deletions(-)
 create mode 100644 src/mapi/glapi/gen/ARB_robustness.xml

diff --git a/src/mapi/glapi/gen/ARB_robustness.xml
b/src/mapi/glapi/gen/ARB_robustness.xml
new file mode 100644
index 000..07c87ac
--- /dev/null
+++ b/src/mapi/glapi/gen/ARB_robustness.xml
@@ -0,0 +1,185 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/mapi/glapi/gen/Makefile b/src/mapi/glapi/gen/Makefile
index b56ce86..f02e5d2 100644
--- a/src/mapi/glapi/gen/Makefile
+++ b/src/mapi/glapi/gen/Makefile
@@ -80,6 +80,7 @@ API_XML = \
ARB_geometry_shader4.xml \
ARB_instanced_arrays.xml \
ARB_map_buffer_range.xml \
+   ARB_robustness.xml \
ARB_sampler_objects.xml \
ARB_seamless_cube_map.xml \
ARB_sync.xml \
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/mapi/glapi/gen/gl_API.xml
index ef68ad6..669be60 100644
--- a/src/mapi/glapi/gen/gl_API.xml
+++ b/src/mapi/glapi/gen/gl_API.xml
@@ -7983,6 +7983,8 @@

 http://www.w3.org/2001/XInclude"/>

+http://www.w3.org/2001/XInclude"/>
+
 

 
-- 
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 7/8] mesa: implement GL_ARB_robustness functions

[nobled]

As long as GLX_ARB_create_context_robustness isn't
implemented yet, these function calls are all that's
needed to implement the spec.

The function pointers just need to be hooked up
to the GLAPI dispatch table and such.
---
 src/mesa/main/colortab.c|   13 -
 src/mesa/main/convolve.c|   27 ++--
 src/mesa/main/eval.c|   90 +-
 src/mesa/main/get.h |4 ++
 src/mesa/main/getstring.c   |   17 +++
 src/mesa/main/histogram.c   |   22 -
 src/mesa/main/pixel.c   |   34 +++---
 src/mesa/main/polygon.c |   11 -
 src/mesa/main/polygon.h |3 +
 src/mesa/main/readpix.c |   16 +--
 src/mesa/main/readpix.h |4 ++
 src/mesa/main/texgetimage.c |   25 --
 src/mesa/main/texgetimage.h |7 +++-
 src/mesa/main/uniforms.c|  101 +--
 src/mesa/main/uniforms.h|   17 +++-
 15 files changed, 345 insertions(+), 46 deletions(-)

diff --git a/src/mesa/main/colortab.c b/src/mesa/main/colortab.c
index 5414acc..e3a77d8 100644
--- a/src/mesa/main/colortab.c
+++ b/src/mesa/main/colortab.c
@@ -509,8 +509,8 @@ _mesa_CopyColorSubTable(GLenum target, GLsizei start,


 static void GLAPIENTRY
-_mesa_GetColorTable( GLenum target, GLenum format,
- GLenum type, GLvoid *data )
+_mesa_GetnColorTableARB( GLenum target, GLenum format, GLenum type,
+ GLsizei bufSize, GLvoid *data )
 {
GET_CURRENT_CONTEXT(ctx);
struct gl_texture_unit *texUnit = _mesa_get_current_tex_unit(ctx);
@@ -614,7 +614,7 @@ _mesa_GetColorTable( GLenum target, GLenum format,

data = _mesa_map_validate_pbo_dest(ctx,
   1, &ctx->Pack, table->Size, 1, 1,
-  format, type, INT_MAX, data,
+  format, type, bufSize, data,
   "glGetColorTable");
if (!data)
   return;
@@ -630,6 +630,13 @@ _mesa_GetColorTable( GLenum target, GLenum format,
 }


+static void GLAPIENTRY
+_mesa_GetColorTable( GLenum target, GLenum format,
+ GLenum type, GLvoid *data )
+{
+   _mesa_GetnColorTableARB(target, format, type, INT_MAX, data);
+}
+

 static void GLAPIENTRY
 _mesa_ColorTableParameterfv(GLenum target, GLenum pname, const GLfloat *params)
diff --git a/src/mesa/main/convolve.c b/src/mesa/main/convolve.c
index 5d286eb..d5b3d5b 100644
--- a/src/mesa/main/convolve.c
+++ b/src/mesa/main/convolve.c
@@ -115,8 +115,8 @@ _mesa_CopyConvolutionFilter2D(GLenum target,
GLenum internalFormat, GLint x, GLi


 static void GLAPIENTRY
-_mesa_GetConvolutionFilter(GLenum target, GLenum format, GLenum type,
-   GLvoid *image)
+_mesa_GetnConvolutionFilterARB(GLenum target, GLenum format, GLenum type,
+   GLsizei bufSize, GLvoid *image)
 {
GET_CURRENT_CONTEXT(ctx);

@@ -125,6 +125,14 @@ _mesa_GetConvolutionFilter(GLenum target, GLenum
format, GLenum type,


 static void GLAPIENTRY
+_mesa_GetConvolutionFilter(GLenum target, GLenum format, GLenum type,
+   GLvoid *image)
+{
+   _mesa_GetnConvolutionFilterARB(target, format, type, INT_MAX, image);
+}
+
+
+static void GLAPIENTRY
 _mesa_GetConvolutionParameterfv(GLenum target, GLenum pname, GLfloat *params)
 {
GET_CURRENT_CONTEXT(ctx);
@@ -143,8 +151,10 @@ _mesa_GetConvolutionParameteriv(GLenum target,
GLenum pname, GLint *params)


 static void GLAPIENTRY
-_mesa_GetSeparableFilter(GLenum target, GLenum format, GLenum type,
- GLvoid *row, GLvoid *column, GLvoid *span)
+_mesa_GetnSeparableFilterARB(GLenum target, GLenum format, GLenum type,
+ GLsizei rowBufSize, GLvoid *row,
+ GLsizei columnBufSize,  GLvoid *column,
+ GLvoid *span)
 {
GET_CURRENT_CONTEXT(ctx);

@@ -153,6 +163,15 @@ _mesa_GetSeparableFilter(GLenum target, GLenum
format, GLenum type,


 static void GLAPIENTRY
+_mesa_GetSeparableFilter(GLenum target, GLenum format, GLenum type,
+ GLvoid *row, GLvoid *column, GLvoid *span)
+{
+   _mesa_GetnSeparableFilterARB(target, format, type, INT_MAX, row,
+INT_MAX, column, span);
+}
+
+
+static void GLAPIENTRY
 _mesa_SeparableFilter2D(GLenum target, GLenum internalFormat, GLsizei
width, GLsizei height, GLenum format, GLenum type, const GLvoid *row,
const GLvoid *column)
 {
GET_CURRENT_CONTEXT(ctx);
diff --git a/src/mesa/main/eval.c b/src/mesa/main/eval.c
index 9ab5507..9eb4f67 100644
--- a/src/mesa/main/eval.c
+++ b/src/mesa/main/eval.c
@@ -545,7 +545,7 @@ _mesa_Map2d( GLenum target,


 static void GLAPIENTRY
-_mesa_GetMapdv( GLenum target, GLenum query, GLdouble *v )
+_mesa_GetnMapdvARB( GLenum target, GLenum query, GLsizei bufSize, GLdouble *v )
 {
GET_CURRENT_CONTEXT(ctx);
struct gl_1d_map *map1d;
@@ -553,6 +553,7

[Mesa-dev] [PATCH 6/8] mesa: add context fields for GL_ARB_robustness

[nobled]

---
 src/mesa/main/context.c|4 
 src/mesa/main/extensions.c |1 +
 src/mesa/main/get.c|3 +++
 src/mesa/main/mtypes.h |6 ++
 4 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 8053edc..ea13bdd 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -658,6 +658,9 @@ _mesa_init_constants(struct gl_context *ctx)
/** GL_EXT_gpu_shader4 */
ctx->Const.MinProgramTexelOffset = -8;
ctx->Const.MaxProgramTexelOffset = 7;
+
+   /* GL_ARB_robustness */
+   ctx->Const.ResetStrategy = GL_NO_RESET_NOTIFICATION_ARB;
 }


@@ -793,6 +796,7 @@ init_attrib_groups(struct gl_context *ctx)
/* Miscellaneous */
ctx->NewState = _NEW_ALL;
ctx->ErrorValue = (GLenum) GL_NO_ERROR;
+   ctx->ResetStatus = (GLenum) GL_NO_ERROR;
ctx->varying_vp_inputs = ~0;

return GL_TRUE;
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 8a0ab96..b7ba7ed 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -107,6 +107,7 @@ static const struct extension extension_table[] = {
{ "GL_ARB_point_parameters",
o(EXT_point_parameters),GL, 1997 },
{ "GL_ARB_point_sprite",
o(ARB_point_sprite),GL, 2003 },
{ "GL_ARB_provoking_vertex",
o(EXT_provoking_vertex),GL, 2009 },
+   { "GL_ARB_robustness",  o(dummy_false),
 GL, 2010 },
{ "GL_ARB_sampler_objects",
o(ARB_sampler_objects), GL, 2009 },
{ "GL_ARB_seamless_cube_map",
o(ARB_seamless_cube_map),   GL, 2009 },
{ "GL_ARB_shader_objects",
o(ARB_shader_objects),  GL, 2002 },
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index e188032..e933bbe 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -1281,6 +1281,9 @@ static const struct value_desc values[] = {
/* GL 3.2 */
{ GL_CONTEXT_PROFILE_MASK, CONTEXT_INT(Const.ProfileMask),
  extra_version_32 },
+
+   /* GL_ARB_robustness */
+   { GL_RESET_NOTIFICATION_STRATEGY_ARB,
CONTEXT_ENUM(Const.ResetStrategy), NO_EXTRA },
 #endif /* FEATURE_GL */
 };

diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 5a25d64..63629fc 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2739,6 +2739,9 @@ struct gl_constants

/* GL_EXT_framebuffer_sRGB */
GLboolean sRGBCapable; /* can enable sRGB blend/update on FBOs */
+
+   /* GL_ARB_robustness */
+   GLenum ResetStrategy;
 };


@@ -3298,6 +3301,9 @@ struct gl_context

GLenum ErrorValue;/**< Last error code */

+   /* GL_ARB_robustness */
+   GLenum ResetStatus;
+
/**
 * Recognize and silence repeated error debug messages in buggy apps.
 */
-- 
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 5/8] mesa: standardize more bounds-checking error messages

[nobled]

---
 src/mesa/main/readpix.c |   25 ++---
 src/mesa/main/texgetimage.c |   63 ++-
 2 files changed, 53 insertions(+), 35 deletions(-)

diff --git a/src/mesa/main/readpix.c b/src/mesa/main/readpix.c
index fd6752b..465be9f 100644
--- a/src/mesa/main/readpix.c
+++ b/src/mesa/main/readpix.c
@@ -224,19 +224,24 @@ _mesa_ReadPixels( GLint x, GLint y, GLsizei
width, GLsizei height,
if (width == 0 || height == 0)
   return; /* nothing to do */

-   if (_mesa_is_bufferobj(ctx->Pack.BufferObj)) {
-  if (!_mesa_validate_pbo_access(2, &ctx->Pack, width, height, 1,
- format, type, 0, pixels)) {
+   if (!_mesa_validate_pbo_access(2, &ctx->Pack, width, height, 1,
+  format, type, INT_MAX, pixels)) {
+  if (_mesa_is_bufferobj(ctx->Pack.BufferObj)) {
  _mesa_error(ctx, GL_INVALID_OPERATION,
- "glReadPixels(invalid PBO access)");
- return;
+ "glReadPixels(out of bounds PBO access)");
+  } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glReadnPixelsARB(out of bounds access:"
+ " bufSize (%d) is too small)", INT_MAX);
   }
+  return;
+   }

-  if (_mesa_bufferobj_mapped(ctx->Pack.BufferObj)) {
- /* buffer is mapped - that's an error */
- _mesa_error(ctx, GL_INVALID_OPERATION, "glReadPixels(PBO is mapped)");
- return;
-  }
+   if (_mesa_is_bufferobj(ctx->Pack.BufferObj) &&
+   _mesa_bufferobj_mapped(ctx->Pack.BufferObj)) {
+  /* buffer is mapped - that's an error */
+  _mesa_error(ctx, GL_INVALID_OPERATION, "glReadPixels(PBO is mapped)");
+  return;
}

ctx->Driver.ReadPixels(ctx, x, y, width, height,
diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
index 79af23f..581d7fd 100644
--- a/src/mesa/main/texgetimage.c
+++ b/src/mesa/main/texgetimage.c
@@ -623,11 +623,13 @@ _mesa_get_compressed_teximage(struct gl_context
*ctx, GLenum target, GLint level
  */
 static GLboolean
 getteximage_error_check(struct gl_context *ctx, GLenum target, GLint level,
-GLenum format, GLenum type, GLvoid *pixels )
+GLenum format, GLenum type, GLsizei clientMemSize,
+GLvoid *pixels )
 {
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
const GLint maxLevels = _mesa_max_texture_levels(ctx, target);
+   const GLuint dimensions = (target == GL_TEXTURE_3D) ? 3 : 2;
GLenum baseFormat;

if (maxLevels == 0) {
@@ -730,17 +732,21 @@ getteximage_error_check(struct gl_context *ctx,
GLenum target, GLint level,
   return GL_TRUE;
}

-   if (_mesa_is_bufferobj(ctx->Pack.BufferObj)) {
-  /* packing texture image into a PBO */
-  const GLuint dimensions = (target == GL_TEXTURE_3D) ? 3 : 2;
-  if (!_mesa_validate_pbo_access(dimensions, &ctx->Pack, texImage->Width,
- texImage->Height, texImage->Depth,
- format, type, INT_MAX, pixels)) {
+   if (!_mesa_validate_pbo_access(dimensions, &ctx->Pack, texImage->Width,
+  texImage->Height, texImage->Depth,
+  format, type, clientMemSize, pixels)) {
+  if (_mesa_is_bufferobj(ctx->Pack.BufferObj)) {
  _mesa_error(ctx, GL_INVALID_OPERATION,
- "glGetTexImage(out of bounds PBO write)");
- return GL_TRUE;
+ "glGetTexImage(out of bounds PBO access)");
+  } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glGetnTexImageARB(out of bounds access:"
+ " bufSize (%d) is too small)", clientMemSize);
   }
+  return GL_TRUE;
+   }

+   if (_mesa_is_bufferobj(ctx->Pack.BufferObj)) {
   /* PBO should not be mapped */
   if (_mesa_bufferobj_mapped(ctx->Pack.BufferObj)) {
  _mesa_error(ctx, GL_INVALID_OPERATION,
@@ -772,7 +778,8 @@ _mesa_GetTexImage( GLenum target, GLint level,
GLenum format,
GET_CURRENT_CONTEXT(ctx);
ASSERT_OUTSIDE_BEGIN_END_AND_FLUSH(ctx);

-   if (getteximage_error_check(ctx, target, level, format, type, pixels)) {
+   if (getteximage_error_check(ctx, target, level, format, type,
+   INT_MAX, pixels)) {
   return;
}

@@ -809,11 +816,12 @@ _mesa_GetTexImage( GLenum target, GLint level,
GLenum format,
  */
 static GLboolean
 getcompressedteximage_error_check(struct gl_context *ctx, GLenum target,
-  GLint level, GLvoid *img)
+  GLint level, GLsizei clientMemSize,
GLvoid *img)
 {
struct gl_texture_object *texObj;
struct gl_texture_image *texImage;
const GLint maxLevels = _mesa_max_texture_levels(ctx, target);
+   GLuint compressedSize;

if (maxLevels == 0) {
   _mesa_error(ctx, 

[Mesa-dev] [PATCH 4/8] mesa: standardize some bounds-checking error messages

[nobled]

---
 src/mesa/main/pixel.c |   41 -
 1 files changed, 24 insertions(+), 17 deletions(-)

diff --git a/src/mesa/main/pixel.c b/src/mesa/main/pixel.c
index 6e4ed99..62dd13e 100644
--- a/src/mesa/main/pixel.c
+++ b/src/mesa/main/pixel.c
@@ -145,8 +145,9 @@ store_pixelmap(struct gl_context *ctx, GLenum map,
GLsizei mapsize,
  * Convenience wrapper for _mesa_validate_pbo_access() for gl[Get]PixelMap().
  */
 static GLboolean
-validate_pbo_access(struct gl_context *ctx, struct gl_pixelstore_attrib *pack,
-GLsizei mapsize, GLenum format, GLenum type,
+validate_pbo_access(struct gl_context *ctx,
+struct gl_pixelstore_attrib *pack, GLsizei mapsize,
+GLenum format, GLenum type, GLsizei clientMemSize,
 const GLvoid *ptr)
 {
GLboolean ok;
@@ -157,7 +158,7 @@ validate_pbo_access(struct gl_context *ctx, struct
gl_pixelstore_attrib *pack,
  pack->BufferObj);

ok = _mesa_validate_pbo_access(1, &ctx->DefaultPacking, mapsize, 1, 1,
-  format, type, INT_MAX, ptr);
+  format, type, clientMemSize, ptr);

/* restore */
_mesa_reference_buffer_object(ctx,
@@ -165,8 +166,14 @@ validate_pbo_access(struct gl_context *ctx,
struct gl_pixelstore_attrib *pack,
  ctx->Shared->NullBufferObj);

if (!ok) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "glPixelMap(invalid PBO access)");
+  if (_mesa_is_bufferobj(pack->BufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "gl[Get]PixelMap*v(out of bounds PBO access)");
+  } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "glGetnPixelMap*vARB(out of bounds access:"
+ " bufSize (%d) is too small)", clientMemSize);
+  }
}
return ok;
 }
@@ -194,8 +201,8 @@ _mesa_PixelMapfv( GLenum map, GLsizei mapsize,
const GLfloat *values )

FLUSH_VERTICES(ctx, _NEW_PIXEL);

-   if (!validate_pbo_access(ctx, &ctx->Unpack, mapsize,
-GL_INTENSITY, GL_FLOAT, values)) {
+   if (!validate_pbo_access(ctx, &ctx->Unpack, mapsize, GL_INTENSITY,
+GL_FLOAT, INT_MAX, values)) {
   return;
}

@@ -236,8 +243,8 @@ _mesa_PixelMapuiv(GLenum map, GLsizei mapsize,
const GLuint *values )

FLUSH_VERTICES(ctx, _NEW_PIXEL);

-   if (!validate_pbo_access(ctx, &ctx->Unpack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_INT, values)) {
+   if (!validate_pbo_access(ctx, &ctx->Unpack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_INT, INT_MAX, values)) {
   return;
}

@@ -292,8 +299,8 @@ _mesa_PixelMapusv(GLenum map, GLsizei mapsize,
const GLushort *values )

FLUSH_VERTICES(ctx, _NEW_PIXEL);

-   if (!validate_pbo_access(ctx, &ctx->Unpack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_SHORT, values)) {
+   if (!validate_pbo_access(ctx, &ctx->Unpack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_SHORT, INT_MAX, values)) {
   return;
}

@@ -343,8 +350,8 @@ _mesa_GetPixelMapfv( GLenum map, GLfloat *values )

mapsize = pm->Size;

-   if (!validate_pbo_access(ctx, &ctx->Pack, mapsize,
-GL_INTENSITY, GL_FLOAT, values)) {
+   if (!validate_pbo_access(ctx, &ctx->Pack, mapsize, GL_INTENSITY,
+GL_FLOAT, INT_MAX, values)) {
   return;
}

@@ -387,8 +394,8 @@ _mesa_GetPixelMapuiv( GLenum map, GLuint *values )
}
mapsize = pm->Size;

-   if (!validate_pbo_access(ctx, &ctx->Pack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_INT, values)) {
+   if (!validate_pbo_access(ctx, &ctx->Pack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_INT, INT_MAX, values)) {
   return;
}

@@ -431,8 +438,8 @@ _mesa_GetPixelMapusv( GLenum map, GLushort *values )
}
mapsize = pm->Size;

-   if (!validate_pbo_access(ctx, &ctx->Pack, mapsize,
-GL_INTENSITY, GL_UNSIGNED_SHORT, values)) {
+   if (!validate_pbo_access(ctx, &ctx->Pack, mapsize, GL_INTENSITY,
+GL_UNSIGNED_SHORT, INT_MAX, values)) {
   return;
}

-- 
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/8] mesa: add more bounds-checking support for client memory buffers

[nobled]

---
 src/mesa/main/colortab.c |4 +-
 src/mesa/main/pbo.c  |   64 +++--
 src/mesa/main/pbo.h  |8 +++---
 src/mesa/main/polygon.c  |7 +++--
 4 files changed, 48 insertions(+), 35 deletions(-)

diff --git a/src/mesa/main/colortab.c b/src/mesa/main/colortab.c
index 35b3096..5414acc 100644
--- a/src/mesa/main/colortab.c
+++ b/src/mesa/main/colortab.c
@@ -190,7 +190,7 @@ store_colortable_entries(struct gl_context *ctx,
struct gl_color_table *table,
 {
data = _mesa_map_validate_pbo_source(ctx,
 1, &ctx->Unpack, count, 1, 1,
-format, type, data,
+format, type, INT_MAX, data,
 "glColor[Sub]Table");
if (!data)
   return;
@@ -614,7 +614,7 @@ _mesa_GetColorTable( GLenum target, GLenum format,

data = _mesa_map_validate_pbo_dest(ctx,
   1, &ctx->Pack, table->Size, 1, 1,
-  format, type, data,
+  format, type, INT_MAX, data,
   "glGetColorTable");
if (!data)
   return;
diff --git a/src/mesa/main/pbo.c b/src/mesa/main/pbo.c
index 0a686db..15e0480 100644
--- a/src/mesa/main/pbo.c
+++ b/src/mesa/main/pbo.c
@@ -155,26 +155,32 @@ _mesa_map_pbo_source(struct gl_context *ctx,
  */
 const GLvoid *
 _mesa_map_validate_pbo_source(struct gl_context *ctx,
-  GLuint dimensions,
-  const struct gl_pixelstore_attrib *unpack,
-  GLsizei width, GLsizei height, GLsizei depth,
-  GLenum format, GLenum type, const GLvoid *ptr,
-  const char *where)
+ GLuint dimensions,
+ const struct gl_pixelstore_attrib *unpack,
+ GLsizei width, GLsizei height, GLsizei depth,
+ GLenum format, GLenum type, GLsizei
clientMemSize,
+ const GLvoid *ptr, const char *where)
 {
ASSERT(dimensions == 1 || dimensions == 2 || dimensions == 3);

-   if (!_mesa_is_bufferobj(unpack->BufferObj)) {
-  /* non-PBO access: no validation to be done */
-  return ptr;
-   }
-
if (!_mesa_validate_pbo_access(dimensions, unpack, width, height, depth,
- format, type, INT_MAX, ptr)) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "%s(out of bounds PBO access)", where);
+  format, type, clientMemSize, ptr)) {
+  if (_mesa_is_bufferobj(unpack->BufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "%s(out of bounds PBO access)", where);
+  } else {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "%s(out of bounds access: bufSize (%d) is too small)",
+ where, clientMemSize);
+  }
   return NULL;
}

+   if (!_mesa_is_bufferobj(unpack->BufferObj)) {
+  /* non-PBO access: no further validation to be done */
+  return ptr;
+   }
+
if (_mesa_bufferobj_mapped(unpack->BufferObj)) {
   /* buffer is already mapped - that's an error */
   _mesa_error(ctx, GL_INVALID_OPERATION, "%s(PBO is mapped)", where);
@@ -245,26 +251,32 @@ _mesa_map_pbo_dest(struct gl_context *ctx,
  */
 GLvoid *
 _mesa_map_validate_pbo_dest(struct gl_context *ctx,
-GLuint dimensions,
-const struct gl_pixelstore_attrib *unpack,
-GLsizei width, GLsizei height, GLsizei depth,
-GLenum format, GLenum type, GLvoid *ptr,
-const char *where)
+   GLuint dimensions,
+   const struct gl_pixelstore_attrib *unpack,
+   GLsizei width, GLsizei height, GLsizei depth,
+   GLenum format, GLenum type, GLsizei
clientMemSize,
+   GLvoid *ptr, const char *where)
 {
ASSERT(dimensions == 1 || dimensions == 2 || dimensions == 3);

-   if (!_mesa_is_bufferobj(unpack->BufferObj)) {
-  /* non-PBO access: no validation to be done */
-  return ptr;
-   }
-
if (!_mesa_validate_pbo_access(dimensions, unpack, width, height, depth,
-  format, type, INT_MAX, ptr)) {
-  _mesa_error(ctx, GL_INVALID_OPERATION,
-  "%s(out of bounds PBO access)", where);
+  format, type, clientMemSize, ptr)) {
+  if (_mesa_is_bufferobj(unpack->BufferObj)) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ "%s(out of bounds PBO access)", where);
+  } else {
+ _mesa_error(ctx, GL_INVAL

[Mesa-dev] [PATCH 2/8] mesa: add bounds-checking support for client memory buffers

[nobled]

This is the first step towards supporting the extension
GL_ARB_robustness.
---
 src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |2 +-
 src/mesa/drivers/x11/xm_dd.c|6 +-
 src/mesa/main/dlist.c   |4 +-
 src/mesa/main/drawpix.c |   10 ++--
 src/mesa/main/pbo.c |   52 +--
 src/mesa/main/pbo.h |3 +-
 src/mesa/main/pixel.c   |2 +-
 src/mesa/main/readpix.c |2 +-
 src/mesa/main/texgetimage.c |2 +-
 9 files changed, 46 insertions(+), 37 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
index 43cdd0d..e59b41d 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
@@ -68,7 +68,7 @@ static const GLubyte *map_pbo( struct gl_context *ctx,

if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
  GL_COLOR_INDEX, GL_BITMAP,
- (GLvoid *) bitmap)) {
+ INT_MAX, (const GLvoid *) bitmap)) {
   _mesa_error(ctx, GL_INVALID_OPERATION,"glBitmap(invalid PBO access)");
   return NULL;
}
diff --git a/src/mesa/drivers/x11/xm_dd.c b/src/mesa/drivers/x11/xm_dd.c
index 1369946..81f48f9 100644
--- a/src/mesa/drivers/x11/xm_dd.c
+++ b/src/mesa/drivers/x11/xm_dd.c
@@ -449,7 +449,7 @@ xmesa_DrawPixels_8R8G8B( struct gl_context *ctx,
  /* unpack from PBO */
  GLubyte *buf;
  if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
-format, type, pixels)) {
+format, type, INT_MAX, pixels)) {
 _mesa_error(ctx, GL_INVALID_OPERATION,
 "glDrawPixels(invalid PBO access)");
 return;
@@ -580,11 +580,11 @@ xmesa_DrawPixels_5R6G5B( struct gl_context *ctx,
   if (swrast->NewState)
  _swrast_validate_derived( ctx );

-  if (unpack->BufferObj->Name) {
+  if (_mesa_is_bufferobj(unpack->BufferObj)) {
  /* unpack from PBO */
  GLubyte *buf;
  if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
-format, type, pixels)) {
+format, type, INT_MAX, pixels)) {
 _mesa_error(ctx, GL_INVALID_OPERATION,
 "glDrawPixels(invalid PBO access)");
 return;
diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index f66082e..63653df 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -859,8 +859,8 @@ unpack_image(struct gl_context *ctx, GLuint dimensions,
   }
   return image;
}
-   else if (_mesa_validate_pbo_access(dimensions, unpack, width, height, depth,
-  format, type, pixels)) {
+   else if (_mesa_validate_pbo_access(dimensions, unpack, width, height,
+  depth, format, type, INT_MAX, pixels)) {
   const GLubyte *map, *src;
   GLvoid *image;

diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index a8b948d..89c2b26 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -92,8 +92,8 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,

  if (_mesa_is_bufferobj(ctx->Unpack.BufferObj)) {
 /* unpack from PBO */
-if (!_mesa_validate_pbo_access(2, &ctx->Unpack, width, height, 1,
-   format, type, pixels)) {
+if (!_mesa_validate_pbo_access(2, &ctx->Unpack, width, height,
+   1, format, type, INT_MAX, pixels)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glDrawPixels(invalid PBO access)");
goto end;
@@ -251,9 +251,9 @@ _mesa_Bitmap( GLsizei width, GLsizei height,

  if (_mesa_is_bufferobj(ctx->Unpack.BufferObj)) {
 /* unpack from PBO */
-if (!_mesa_validate_pbo_access(2, &ctx->Unpack, width, height, 1,
-   GL_COLOR_INDEX, GL_BITMAP,
-   (GLvoid *) bitmap)) {
+if (!_mesa_validate_pbo_access(2, &ctx->Unpack, width, height,
+   1, GL_COLOR_INDEX, GL_BITMAP,
+   INT_MAX, (const GLvoid *) bitmap)) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glBitmap(invalid PBO access)");
return;
diff --git a/src/mesa/main/pbo.c b/src/mesa/main/pbo.c
index 56b26a9..0a686db 100644
--- a/src/mesa/main/pbo.c
+++ b/src/mesa/main/pbo.c
@@ -43,7 +43,7 @@
  * When we're about to read pixel data out of a PBO (via glDrawPixels,
  

[Mesa-dev] [PATCH 1/8] mesa: use is_bufferobj() helper function

[nobled]

---
 src/mesa/drivers/x11/xm_dd.c |4 ++--
 src/mesa/main/drawpix.c  |4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/x11/xm_dd.c b/src/mesa/drivers/x11/xm_dd.c
index 3031b7b..1369946 100644
--- a/src/mesa/drivers/x11/xm_dd.c
+++ b/src/mesa/drivers/x11/xm_dd.c
@@ -445,7 +445,7 @@ xmesa_DrawPixels_8R8G8B( struct gl_context *ctx,
   if (swrast->NewState)
  _swrast_validate_derived( ctx );

-  if (unpack->BufferObj->Name) {
+  if (_mesa_is_bufferobj(unpack->BufferObj)) {
  /* unpack from PBO */
  GLubyte *buf;
  if (!_mesa_validate_pbo_access(2, unpack, width, height, 1,
@@ -507,7 +507,7 @@ xmesa_DrawPixels_8R8G8B( struct gl_context *ctx,
  XPutImage(dpy, xrb->pixmap, gc, &ximage, 0, 0, dstX, dstY, w, h);
   }

-  if (unpack->BufferObj->Name) {
+  if (_mesa_is_bufferobj(unpack->BufferObj)) {
  ctx->Driver.UnmapBuffer(ctx, GL_PIXEL_UNPACK_BUFFER_EXT,
  unpack->BufferObj);
   }
diff --git a/src/mesa/main/drawpix.c b/src/mesa/main/drawpix.c
index ee379f7..a8b948d 100644
--- a/src/mesa/main/drawpix.c
+++ b/src/mesa/main/drawpix.c
@@ -90,7 +90,7 @@ _mesa_DrawPixels( GLsizei width, GLsizei height,
  GLint x = IROUND(ctx->Current.RasterPos[0]);
  GLint y = IROUND(ctx->Current.RasterPos[1]);

- if (ctx->Unpack.BufferObj->Name) {
+ if (_mesa_is_bufferobj(ctx->Unpack.BufferObj)) {
 /* unpack from PBO */
 if (!_mesa_validate_pbo_access(2, &ctx->Unpack, width, height, 1,
format, type, pixels)) {
@@ -249,7 +249,7 @@ _mesa_Bitmap( GLsizei width, GLsizei height,
  GLint x = IFLOOR(ctx->Current.RasterPos[0] + epsilon - xorig);
  GLint y = IFLOOR(ctx->Current.RasterPos[1] + epsilon - yorig);

- if (ctx->Unpack.BufferObj->Name) {
+ if (_mesa_is_bufferobj(ctx->Unpack.BufferObj)) {
 /* unpack from PBO */
 if (!_mesa_validate_pbo_access(2, &ctx->Unpack, width, height, 1,
GL_COLOR_INDEX, GL_BITMAP,
-- 
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36295] Incorrect rendering in SPECviewperf benchmark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36295

--- Comment #15 from Ian Romanick  2011-04-19 17:21:46 
PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > The downside is that app developers never fix *THEIR* bugs.
> > 
> [...]
> >
> > And this is the disaster that we're trying to fix via conformance testing. 
> > This crap has to STOP.  This is why people think OpenGL is joke.
> 
> (This is slightly OT, but I'd argue that the OpenGL problem is not that spec
> conformance per se, but the proliferation of vendor specific extensions, and
> extensions in general; and the fix is not conformance testing but the ARB
> ratifying the extensions people care and lumping extensions in core versions.
> It looks things are moving on the right direction. That said, latest core
> version is 4.0 and we're still in 2.1, so I'm thankful for extensions that get
> us half way there.)
> 
> Anyway, Ian, I see you strongly feel against the proposed patch, but I still 
> am
> not sure exactly what you oppose: diverging the spec, or adding the extensions
> to meet an application's requirement? That is, would fully implementing
> NV_fragment_program2 to the spec and advertising it for SPECviewperf11's sake
> be OK with you or not, and why?

I don't care too much what extensions we decide to support.  We already support
most of NV_fragment_program2.  The primary missing bits are support for clip
distance, and we need to add that for GLSL 1.30 anyway.  I don't recall if the
rest of the support is in master or on an old, dusty branch.  It might be one
one of my asm-shader-rework branches...

I am strongly opposed to allowing an application to use functionality that is
not advertised or, in the case of GLSL extensions, not enabled because it
prevents us from removing those features in the future.  Over the last 18
months we've removed a lot of old extensions that we did not want the on going
burden of supporting.  I fully expect that we will do more of this in the
future.  When applications either gracefully don't work or fallback to
different rendering paths, this is fine.  When apps start to explode, it's not
fine.  When we let applications use undocumented features or use documented
features in illegal ways, we paint ourselves into a corner.  We effectively
trade short-term gain for long-term pain.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/9] Big pile of fog clean up

[Corbin Simpson]

Acked-by: Corbin Simpson 

Sending from a mobile, pardon the brevity. ~ C.
On Apr 19, 2011 4:13 PM, "Ian Romanick"  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/16/2011 09:45 AM, Corbin Simpson wrote:
>> On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick 
wrote:
>>> This patch series cleans out the last vestiges of fixed-function fog
>>> support with ARB_fragment_program. We talked about doing this quite
>>> some time ago, but we decided to hold off. The thinking at the time
>>> was that there was still a chance that someone might add support for
>>> the fixed-function fog on either i915 or r300.
>>>
>>> Reality check: there is no chance because nobody cares. :)
>>>
>>> Patch 1/9 cleans up a couple minor bugs in the fixed-function
>>> fragment program code.
>>>
>>> Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to
>>> be non-GL_NONE. Thanks to the first patch, this can *never* happen.
>>>
>>> Patch 5/9 removes gl_fragment_program::FogOption.
>>>
>>> The remaining four patches remove all the dangling bits of support for
>>> fixed-function fog on i915. Since fog is (and always has been)
>>> handled by fragment programs on i915, this code is completely useless.
>>>
>>> I have tested this whole series on Ironlake (i965 driver) and G33
>>> (i915 driver). There were no piglit or GTF regressions in either
>>> case.
>>>
>>> I believe that, at the very least, the first four patches are suitable
>>> for the stable branches (after a suitable settling period on master,
>>> of course). The remaining five patches may also be suitable.
>>>
>>> src/mesa/drivers/dri/i915/i915_context.c | 8 +-
>>> src/mesa/drivers/dri/i915/i915_context.h | 15 --
>>> src/mesa/drivers/dri/i915/i915_fragprog.c | 11 +--
>>> src/mesa/drivers/dri/i915/i915_state.c | 164 +---
>>> src/mesa/drivers/dri/i915/i915_vtbl.c | 9 -
>>> src/mesa/drivers/dri/i965/brw_program.c | 5 -
>>> .../drivers/dri/r300/compiler/r300_fragprog_emit.c | 2 -
>>> src/mesa/main/ff_fragment_shader.cpp | 44 +++---
>>> src/mesa/main/mtypes.h | 1 -
>>> src/mesa/program/arbprogparse.c | 18 +--
>>> src/mesa/program/program.c | 1 -
>>> src/mesa/program/programopt.c | 33 +++--
>>> src/mesa/program/programopt.h | 4 +-
>>> src/mesa/swrast/s_context.c | 15 +--
>>> src/mesa/tnl/t_context.c | 12 +-
>>> 15 files changed, 70 insertions(+), 272 deletions(-)
>>
>> r300 *did* support FF fog at one point, but it got tossed out because
>> we couldn't get it to work with fog coordinates. (Well, *I* couldn't
>> get it to work; I think osiris got it mostly-working-sort-of at one
>> point.) This code will not be missed.
>
> Right. I believe people eventually figured out that fglrx didn't use
> the fixed-function fog either. It seems likely that it was for the same
> reason. :) Looking at the i915 docs, there a bunch of restrictions and
> weird quirks that look like they'd make it more trouble that it's worth.
> Plus, I don't think a lot of applications use part shader / part
> fixed-function anyway.
>
> Can I call this an Acked-by?
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2uFxIACgkQX1gOwKyEAw9zuACfWUW9RLRqeauVKPK103E//BNb
> /swAnixkaFG6jKh0FrgPk3hoi6wFu+uY
> =p6R3
> -END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/9] Big pile of fog clean up

[Alex Deucher]

On Tue, Apr 19, 2011 at 7:13 PM, Ian Romanick  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/16/2011 09:45 AM, Corbin Simpson wrote:
>> On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick  wrote:
>>> This patch series cleans out the last vestiges of fixed-function fog
>>> support with ARB_fragment_program.  We talked about doing this quite
>>> some time ago, but we decided to hold off.  The thinking at the time
>>> was that there was still a chance that someone might add support for
>>> the fixed-function fog on either i915 or r300.
>>>
>>> Reality check: there is no chance because nobody cares. :)
>>>
>>> Patch 1/9 cleans up a couple minor bugs in the fixed-function
>>> fragment program code.
>>>
>>> Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to
>>> be non-GL_NONE.  Thanks to the first patch, this can *never* happen.
>>>
>>> Patch 5/9 removes gl_fragment_program::FogOption.
>>>
>>> The remaining four patches remove all the dangling bits of support for
>>> fixed-function fog on i915.  Since fog is (and always has been)
>>> handled by fragment programs on i915, this code is completely useless.
>>>
>>> I have tested this whole series on Ironlake (i965 driver) and G33
>>> (i915 driver).  There were no piglit or GTF regressions in either
>>> case.
>>>
>>> I believe that, at the very least, the first four patches are suitable
>>> for the stable branches (after a suitable settling period on master,
>>> of course).  The remaining five patches may also be suitable.
>>>
>>>  src/mesa/drivers/dri/i915/i915_context.c           |    8 +-
>>>  src/mesa/drivers/dri/i915/i915_context.h           |   15 --
>>>  src/mesa/drivers/dri/i915/i915_fragprog.c          |   11 +--
>>>  src/mesa/drivers/dri/i915/i915_state.c             |  164 
>>> +---
>>>  src/mesa/drivers/dri/i915/i915_vtbl.c              |    9 -
>>>  src/mesa/drivers/dri/i965/brw_program.c            |    5 -
>>>  .../drivers/dri/r300/compiler/r300_fragprog_emit.c |    2 -
>>>  src/mesa/main/ff_fragment_shader.cpp               |   44 +++---
>>>  src/mesa/main/mtypes.h                             |    1 -
>>>  src/mesa/program/arbprogparse.c                    |   18 +--
>>>  src/mesa/program/program.c                         |    1 -
>>>  src/mesa/program/programopt.c                      |   33 +++--
>>>  src/mesa/program/programopt.h                      |    4 +-
>>>  src/mesa/swrast/s_context.c                        |   15 +--
>>>  src/mesa/tnl/t_context.c                           |   12 +-
>>>  15 files changed, 70 insertions(+), 272 deletions(-)
>>
>> r300 *did* support FF fog at one point, but it got tossed out because
>> we couldn't get it to work with fog coordinates. (Well, *I* couldn't
>> get it to work; I think osiris got it mostly-working-sort-of at one
>> point.) This code will not be missed.
>
> Right.  I believe people eventually figured out that fglrx didn't use
> the fixed-function fog either.  It seems likely that it was for the same
> reason. :)  Looking at the i915 docs, there a bunch of restrictions and
> weird quirks that look like they'd make it more trouble that it's worth.
>  Plus, I don't think a lot of applications use part shader / part
> fixed-function anyway.
>
> Can I call this an Acked-by?

Looks good to me.

Acked-by: Alex Deucher 

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk2uFxIACgkQX1gOwKyEAw9zuACfWUW9RLRqeauVKPK103E//BNb
> /swAnixkaFG6jKh0FrgPk3hoi6wFu+uY
> =p6R3
> -END PGP SIGNATURE-
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/9] mesa: gl_fragment_program::FogOption is always GL_NONE so don't check it

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/16/2011 06:48 AM, Brian Paul wrote:
> On Sat, Apr 16, 2011 at 12:10 AM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> ---
>>  src/mesa/swrast/s_context.c |   15 ---
>>  src/mesa/tnl/t_context.c|   12 
>>  2 files changed, 8 insertions(+), 19 deletions(-)
>>
>> diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
>> index 491fcfc..b3e3968 100644
>> --- a/src/mesa/swrast/s_context.c
>> +++ b/src/mesa/swrast/s_context.c
>> @@ -248,18 +248,11 @@ _swrast_update_fog_state( struct gl_context *ctx )
>>SWcontext *swrast = SWRAST_CONTEXT(ctx);
>>const struct gl_fragment_program *fp = ctx->FragmentProgram._Current;
>>
>> +   assert((fp == NULL) || (fp->Base.Target == GL_FRAGMENT_PROGRAM_ARB));
>> +
>>/* determine if fog is needed, and if so, which fog mode */
>> -   swrast->_FogEnabled = GL_FALSE;
>> -   if (fp && fp->Base.Target == GL_FRAGMENT_PROGRAM_ARB) {
>> -  if (fp->FogOption != GL_NONE) {
>> - swrast->_FogEnabled = GL_TRUE;
>> - swrast->_FogMode = fp->FogOption;
>> -  }
>> -   }
>> -   else if (ctx->Fog.Enabled) {
>> -  swrast->_FogEnabled = GL_TRUE;
>> -  swrast->_FogMode = ctx->Fog.Mode;
>> -   }
>> +   swrast->_FogEnabled = (fp == NULL && ctx->Fog.Enabled);
>> +   swrast->_FogMode = ctx->Fog.Mode;
> 
> We might as well get rid of swrast->_FogMode and just use
> ctx->Fog.Mode everywhere.

Yeah, that would probably work.  I'll send that as a follow-on patch.
Can I call this a Reviewed-by on the patches that are here?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2uF1MACgkQX1gOwKyEAw8TqgCgnoC8rHdAeBJRPInR7xMqXPoe
EHkAn2s5UGSQVEmdcYqbb3joJzBB7RSc
=CUjP
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/9] Big pile of fog clean up

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/16/2011 09:45 AM, Corbin Simpson wrote:
> On Fri, Apr 15, 2011 at 11:10 PM, Ian Romanick  wrote:
>> This patch series cleans out the last vestiges of fixed-function fog
>> support with ARB_fragment_program.  We talked about doing this quite
>> some time ago, but we decided to hold off.  The thinking at the time
>> was that there was still a chance that someone might add support for
>> the fixed-function fog on either i915 or r300.
>>
>> Reality check: there is no chance because nobody cares. :)
>>
>> Patch 1/9 cleans up a couple minor bugs in the fixed-function
>> fragment program code.
>>
>> Patches 2/9, 3/9, and 4/9 remove code that checks for fp.FogOption to
>> be non-GL_NONE.  Thanks to the first patch, this can *never* happen.
>>
>> Patch 5/9 removes gl_fragment_program::FogOption.
>>
>> The remaining four patches remove all the dangling bits of support for
>> fixed-function fog on i915.  Since fog is (and always has been)
>> handled by fragment programs on i915, this code is completely useless.
>>
>> I have tested this whole series on Ironlake (i965 driver) and G33
>> (i915 driver).  There were no piglit or GTF regressions in either
>> case.
>>
>> I believe that, at the very least, the first four patches are suitable
>> for the stable branches (after a suitable settling period on master,
>> of course).  The remaining five patches may also be suitable.
>>
>>  src/mesa/drivers/dri/i915/i915_context.c   |8 +-
>>  src/mesa/drivers/dri/i915/i915_context.h   |   15 --
>>  src/mesa/drivers/dri/i915/i915_fragprog.c  |   11 +--
>>  src/mesa/drivers/dri/i915/i915_state.c |  164 
>> +---
>>  src/mesa/drivers/dri/i915/i915_vtbl.c  |9 -
>>  src/mesa/drivers/dri/i965/brw_program.c|5 -
>>  .../drivers/dri/r300/compiler/r300_fragprog_emit.c |2 -
>>  src/mesa/main/ff_fragment_shader.cpp   |   44 +++---
>>  src/mesa/main/mtypes.h |1 -
>>  src/mesa/program/arbprogparse.c|   18 +--
>>  src/mesa/program/program.c |1 -
>>  src/mesa/program/programopt.c  |   33 +++--
>>  src/mesa/program/programopt.h  |4 +-
>>  src/mesa/swrast/s_context.c|   15 +--
>>  src/mesa/tnl/t_context.c   |   12 +-
>>  15 files changed, 70 insertions(+), 272 deletions(-)
> 
> r300 *did* support FF fog at one point, but it got tossed out because
> we couldn't get it to work with fog coordinates. (Well, *I* couldn't
> get it to work; I think osiris got it mostly-working-sort-of at one
> point.) This code will not be missed.

Right.  I believe people eventually figured out that fglrx didn't use
the fixed-function fog either.  It seems likely that it was for the same
reason. :)  Looking at the i915 docs, there a bunch of restrictions and
weird quirks that look like they'd make it more trouble that it's worth.
 Plus, I don't think a lot of applications use part shader / part
fixed-function anyway.

Can I call this an Acked-by?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2uFxIACgkQX1gOwKyEAw9zuACfWUW9RLRqeauVKPK103E//BNb
/swAnixkaFG6jKh0FrgPk3hoi6wFu+uY
=p6R3
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/3] glsl: correctly handle conversions between int and uint

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/18/2011 04:51 PM, Bryan Cain wrote:
> This patch was revised several times before submitting, and even after
> that I still wasn't sure that adding conversion operations was the right
> solution.  So I'm not really surprised that there are problems with this
> one. :)
> 
> On 04/18/2011 06:36 PM, Ian Romanick wrote:
>> On 04/17/2011 11:39 PM, Bryan Cain wrote:
>>> From the GLSL 1.30 specification, section 4.1.10 ("Implicit
>> Conversions"):
>>> "There are no implicit conversions between signed and unsigned
>> integers."
>>
>>> However, convert_component() was assuming that conversions between
>> int and uint were implicit.
>>
>> The conversions applied in convert_component only apply to constructor
>> parameters.  As Ken mentions, in those cases we want
>>
>> Internally we treat signed and unsigned identically because the
>> representation is the same.  There's no way for an application to
>> observe the difference between:
>>
>> ivec4 a = ivec4(5 , 6 , 7 , 8 );
>> ivec4 b = ivec4(5 , 6 , 7 , 8u);
>> ivec4 c = ivec4(5 , 6 , 7u, 8 );
>> ivec4 d = ivec4(5 , 6 , 7u, 8u);
>> ivec4 e = ivec4(5 , 6u, 7 , 8 );
>> ivec4 f = ivec4(5 , 6u, 7 , 8u);
>> ivec4 g = ivec4(5 , 6u, 7u, 8 );
>> ivec4 h = ivec4(5 , 6u, 7u, 8u);
>> // etc.
>>
>> The type checker ensures that operands to operations that could exhibit
>> differing behavior (e.g., ir_bin_mul) have identical types.  That code
>> lives in arithmetic_result_type in ast_to_hir.cpp.  There is similar
>> code in match_function_by_name in ast_function.cpp.
>>
>> Do you have any specific test cases in mind that don't produce correct
>> results with the existing code?
> Yes, usages like this:
> 
> int var1 = 7;
> uint var2 = uint(var1);
> 
> They were causing a type mismatch error in ast_to_hir.cpp because
> convert_component() was treating the uint(int) constructor as a no-op.

Ah, that makes sense.  I just sent some patches to the piglit mailing
list with some tests in this vein.

You've convinced me that we need i2u and u2i unary operators.  I don't
think we need b2u and u2b operators because we can just do (i2b(u2i
value)) and (i2u(b2i value)).  Ditto for f2i.  This should result in
less churn in the backends since u2i and i2u will universally be no-ops.

Almost every place that checks is_integer() will need to check for the
specific type, either GLSL_TYPE_UINT or GLSL_TYPE_INT, that it expects.
 This means that your patch 2/3, which is already applied, will need to
be reverted.

>>> ---
>>>  src/glsl/ast_function.cpp   |   16 
>>>  src/glsl/ir.cpp |8 
>>>  src/glsl/ir.h   |2 ++
>>>  src/glsl/ir_constant_expression.cpp |8 
>>>  src/glsl/ir_validate.cpp|8 
>>>  5 files changed, 38 insertions(+), 4 deletions(-)
>>
>>> diff --git a/src/glsl/ast_function.cpp b/src/glsl/ast_function.cpp
>>> index e5cb873..cc3f032 100644
>>> --- a/src/glsl/ast_function.cpp
>>> +++ b/src/glsl/ast_function.cpp
>>> @@ -267,17 +267,25 @@ convert_component(ir_rvalue *src, const
>> glsl_type *desired_type)
>>> assert(a <= GLSL_TYPE_BOOL);
>>> assert(b <= GLSL_TYPE_BOOL);
>>
>>> -   if ((a == b) || (src->type->is_integer() &&
>> desired_type->is_integer()))
>>> +   if (a == b)
>>>return src;
>>
>>> switch (a) {
>>> case GLSL_TYPE_UINT:
>>> case GLSL_TYPE_INT:
>>> -  if (b == GLSL_TYPE_FLOAT)
>>> +  switch(b) {
>>> +  case GLSL_TYPE_UINT:
>>> + result = new(ctx) ir_expression(ir_unop_u2i, desired_type,
>> src, NULL);
>>> + break;
>>> +  case GLSL_TYPE_INT:
>>> + result = new(ctx) ir_expression(ir_unop_i2u, desired_type,
>> src, NULL);
>>> + break;
>>> +  case GLSL_TYPE_FLOAT:
>>>   result = new(ctx) ir_expression(ir_unop_f2i, desired_type,
>> src, NULL);
>>
>> With the other changes, leaving this as-is is kind of hinkey.  Here the
>> result base type will be GLSL_TYPE_INT, but the desired based type could
>> be GLSL_TYPE_UINT.
> Unless I'm missing something, that case is handled by the line "if (a ==
> b)".

What I meant was uint(float) and int(float) will both generate an
ir_unop_f2i, which has type int.  So, 'uint x = uint(5.2);' will result
in a type error.  Right?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2uEBkACgkQX1gOwKyEAw8esQCdEawL5QiLogZuqLrstfyI7Dz9
ub0AoJuTNzMseA2K3vdrtSzjEQ8sLctO
=yFr3
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r600g: don't flush the dest caches on every draw

[Fredrik Höglund]

Keep track of when the caches are dirty, and only flush them when
the framebuffer state is set and when the context is flushed.
---
 src/gallium/drivers/r600/evergreen_state.c |   19 +++-
 src/gallium/drivers/r600/evergreend.h  |1 +
 src/gallium/drivers/r600/r600.h|6 +
 src/gallium/drivers/r600/r600_pipe.h   |2 -
 src/gallium/drivers/r600/r600_state.c  |   12 ++-
 src/gallium/winsys/r600/drm/evergreen_hw_context.c |   86 +-
 src/gallium/winsys/r600/drm/r600_hw_context.c  |  122 ++--
 7 files changed, 176 insertions(+), 72 deletions(-)

diff --git a/src/gallium/drivers/r600/evergreen_state.c 
b/src/gallium/drivers/r600/evergreen_state.c
index febc613..a972f82 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -822,6 +822,9 @@ static void evergreen_set_framebuffer_state(struct 
pipe_context *ctx,
if (rstate == NULL)
return;
 
+   evergreen_context_flush_dest_caches(&rctx->ctx);
+   rctx->ctx.num_dest_buffers = state->nr_cbufs;
+
/* unreference old buffer and reference new one */
rstate->id = R600_PIPE_STATE_FRAMEBUFFER;
 
@@ -833,6 +836,7 @@ static void evergreen_set_framebuffer_state(struct 
pipe_context *ctx,
}
if (state->zsbuf) {
evergreen_db(rctx, rstate, state);
+   rctx->ctx.num_dest_buffers++;
}
 
target_mask = 0x;
@@ -894,6 +898,19 @@ static void evergreen_set_framebuffer_state(struct 
pipe_context *ctx,
}
 }
 
+static void evergreen_texture_barrier(struct pipe_context *ctx)
+{
+   struct r600_pipe_context *rctx = (struct r600_pipe_context *)ctx;
+
+   r600_context_flush_all(&rctx->ctx, S_0085F0_TC_ACTION_ENA(1) | 
S_0085F0_CB_ACTION_ENA(1) |
+   S_0085F0_CB0_DEST_BASE_ENA(1) | 
S_0085F0_CB1_DEST_BASE_ENA(1) |
+   S_0085F0_CB2_DEST_BASE_ENA(1) | 
S_0085F0_CB3_DEST_BASE_ENA(1) |
+   S_0085F0_CB4_DEST_BASE_ENA(1) | 
S_0085F0_CB5_DEST_BASE_ENA(1) |
+   S_0085F0_CB6_DEST_BASE_ENA(1) | 
S_0085F0_CB7_DEST_BASE_ENA(1) |
+   S_0085F0_CB8_DEST_BASE_ENA(1) | 
S_0085F0_CB9_DEST_BASE_ENA(1) |
+   S_0085F0_CB10_DEST_BASE_ENA(1) | 
S_0085F0_CB11_DEST_BASE_ENA(1));
+}
+
 void evergreen_init_state_functions(struct r600_pipe_context *rctx)
 {
rctx->context.create_blend_state = evergreen_create_blend_state;
@@ -934,7 +951,7 @@ void evergreen_init_state_functions(struct 
r600_pipe_context *rctx)
rctx->context.set_viewport_state = evergreen_set_viewport_state;
rctx->context.sampler_view_destroy = r600_sampler_view_destroy;
rctx->context.redefine_user_buffer = u_default_redefine_user_buffer;
-   rctx->context.texture_barrier = r600_texture_barrier;
+   rctx->context.texture_barrier = evergreen_texture_barrier;
 }
 
 void evergreen_init_config(struct r600_pipe_context *rctx)
diff --git a/src/gallium/drivers/r600/evergreend.h 
b/src/gallium/drivers/r600/evergreend.h
index 8489c29..de445b8 100644
--- a/src/gallium/drivers/r600/evergreend.h
+++ b/src/gallium/drivers/r600/evergreend.h
@@ -43,6 +43,7 @@
 #define EVERGREEN_CTL_CONST_OFFSET  0x0003CFF0
 #define EVERGREEN_CTL_CONST_END 0x0003E200
 
+#define EVENT_TYPE_PS_PARTIAL_FLUSH0x10
 #define EVENT_TYPE_ZPASS_DONE  0x15
 #define EVENT_TYPE_CACHE_FLUSH_AND_INV_EVENT   0x16
 #defineEVENT_TYPE(x)   ((x) << 0)
diff --git a/src/gallium/drivers/r600/r600.h b/src/gallium/drivers/r600/r600.h
index 41666f2..0b0df9d 100644
--- a/src/gallium/drivers/r600/r600.h
+++ b/src/gallium/drivers/r600/r600.h
@@ -233,6 +233,8 @@ struct r600_query {
 #define R600_QUERY_STATE_ENDED (1 << 1)
 #define R600_QUERY_STATE_SUSPENDED (1 << 2)
 
+#define R600_CONTEXT_DRAW_PENDING  (1 << 0)
+#define R600_CONTEXT_DST_CACHES_DIRTY  (1 << 1)
 
 struct r600_context {
struct radeon   *radeon;
@@ -255,6 +257,8 @@ struct r600_context {
unsignednum_query_running;
struct list_headfenced_bo;
unsignedmax_db; /* for OQ */
+   unsignednum_dest_buffers;
+   unsignedflags;
boolean predicate_drawing;
 };
 
@@ -293,9 +297,11 @@ void r600_query_predication(struct r600_context *ctx, 
struct r600_query *query,
 void r600_context_emit_fence(struct r600_context *ctx, struct r600_bo *fence,
  unsigned offset, unsigned value);
 void r600_context_flush_all(struct r600_context *ctx, unsigned flush_flags);
+void r600_context_flush_dest_caches(struct r600_context *ctx);
 
 int evergreen_context_init(struct r600_context *ctx, struct radeon *radeon);
 void evergreen_context_draw(struct r600_context *ctx

Re: [Mesa-dev] [PATCHES] implement GL_ARB_robustness

[Brian Paul]

On 04/19/2011 02:43 PM, Ian Romanick wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/19/2011 12:23 PM, nobled wrote:

spec file:
http://www.opengl.org/registry/specs/ARB/robustness.txt

The first four parts of this series add infrastructure to support
bounds-checking client memory buffers by re-using the PBO
bounds-checking code; the fifth patch adds the actual functions of the
extension. However, the series is incomplete because I'm not sure how
to turn the spec file into an xml file for
src/mapi/glapi/gen/ARB_robustness.xml, and then generate the dispatch
stuff from it with the python script(*which* python script?) -- the
docs on this point seem to be a classic combination of completely
outdated and "hey, can you vague that up for me?":

http://cgit.freedesktop.org/mesa/mesa/tree/docs/devinfo.html
   In the src/mesa/glapi/ directory, add the new extension functions and
   enums to the gl_API.xml file.
   Then, a bunch of source files must be regenerated by executing the
   corresponding Python scripts.


It's not too hard to write the xml file.  Just use another extension 
as an example (ex: ARB_sampler_objects.xml which was just recently 
added).  Then add the new filename to the Makefile and in gl_API.xml, 
then run the Makefile.  Make commits for the stuff you added/changed 
and another for the regenerated files.




I think I covered all the other steps, though. At least enough to be
faithful to the spec, as long as these two aren't exposed yet on the
GLX side of things:
http://www.opengl.org/registry/specs/ARB/glx_create_context.txt
http://www.opengl.org/registry/specs/ARB/glx_create_context_robustness.txt

Still todo: adding piglit tests.


It's *REALLY* hard to review patches sent as attachments.  It is much
better and easier for reviewers to put comments alongside the code they
are commenting about.  In the future, could you please send patches
using git-send-email?

Patch 1/5 looks like it's doing to separate things.  It renames / alters
_mesa_validate_pbo_access and it starts using _mesa_is_bufferobj in some
places.  That should probably be split into two patches.  First change
over to using _mesa_is_bufferobj, then make the other changes.

I'm also not sure _mesa_validate_buffer_access is a particularly good
name.   This loses the information that the validation is for pixel
reads / writes.  This also applies to _mesa_map_validate_buffer_dest and
friends in later patches.


I agree.  I'd like to keep pbo in the name to indicate that we're 
talking about pixel/image buffers.  OpenGL has many kinds of buffers 
and it's good to clarify what kind of buffer we're talking about here.




For the internal Mesa functions, I think I might also change the
parameter bufSize to clientMemorySize or similar.  Using bufSize in the
API functions (added in patch 5/5) matches the API definition and is fine.

The changes to readpix.c in patch 4/5 looks odd.  If the access is
out-of-bounds and there is PBO, nothing happens but no error is
generated.  Is that what the spec says to do?

It also looks like a lot of the checking for out-of-bounds followed by
checking for being mapped could be refactored.

Patch 5/5 also does two separate things.  It adds data structure
infrastructure for the extension and it adds a bunch of entry points.
Usually gl_context::ResetStatus and gl_constants::ResetStratgy would be
added in a separate patch from adding all the new functions.


I agree with these items too.



In patch 5/5 why

+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+   const GLsizei bufSize = INT_MAX;
+   _mesa_GetnMinmaxARB(target, reset, format, type, bufSize, values);
+}

instead of

+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+   _mesa_GetnMinmaxARB(target, reset, format, type, INT_MAX, values);
+}


I sometimes do that to convey what the argument is without having to 
look at the prototype.  In this case though, it doesn't add a lot.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCHES] implement GL_ARB_robustness

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/19/2011 12:23 PM, nobled wrote:
> spec file:
> http://www.opengl.org/registry/specs/ARB/robustness.txt
> 
> The first four parts of this series add infrastructure to support
> bounds-checking client memory buffers by re-using the PBO
> bounds-checking code; the fifth patch adds the actual functions of the
> extension. However, the series is incomplete because I'm not sure how
> to turn the spec file into an xml file for
> src/mapi/glapi/gen/ARB_robustness.xml, and then generate the dispatch
> stuff from it with the python script(*which* python script?) -- the
> docs on this point seem to be a classic combination of completely
> outdated and "hey, can you vague that up for me?":
>> http://cgit.freedesktop.org/mesa/mesa/tree/docs/devinfo.html
>>   In the src/mesa/glapi/ directory, add the new extension functions and
>>   enums to the gl_API.xml file.
>>   Then, a bunch of source files must be regenerated by executing the
>>   corresponding Python scripts.
> 
> I think I covered all the other steps, though. At least enough to be
> faithful to the spec, as long as these two aren't exposed yet on the
> GLX side of things:
> http://www.opengl.org/registry/specs/ARB/glx_create_context.txt
> http://www.opengl.org/registry/specs/ARB/glx_create_context_robustness.txt
> 
> Still todo: adding piglit tests.

It's *REALLY* hard to review patches sent as attachments.  It is much
better and easier for reviewers to put comments alongside the code they
are commenting about.  In the future, could you please send patches
using git-send-email?

Patch 1/5 looks like it's doing to separate things.  It renames / alters
_mesa_validate_pbo_access and it starts using _mesa_is_bufferobj in some
places.  That should probably be split into two patches.  First change
over to using _mesa_is_bufferobj, then make the other changes.

I'm also not sure _mesa_validate_buffer_access is a particularly good
name.   This loses the information that the validation is for pixel
reads / writes.  This also applies to _mesa_map_validate_buffer_dest and
friends in later patches.

For the internal Mesa functions, I think I might also change the
parameter bufSize to clientMemorySize or similar.  Using bufSize in the
API functions (added in patch 5/5) matches the API definition and is fine.

The changes to readpix.c in patch 4/5 looks odd.  If the access is
out-of-bounds and there is PBO, nothing happens but no error is
generated.  Is that what the spec says to do?

It also looks like a lot of the checking for out-of-bounds followed by
checking for being mapped could be refactored.

Patch 5/5 also does two separate things.  It adds data structure
infrastructure for the extension and it adds a bunch of entry points.
Usually gl_context::ResetStatus and gl_constants::ResetStratgy would be
added in a separate patch from adding all the new functions.

In patch 5/5 why

+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+   const GLsizei bufSize = INT_MAX;
+   _mesa_GetnMinmaxARB(target, reset, format, type, bufSize, values);
+}

instead of

+_mesa_GetMinmax(GLenum target, GLboolean reset, GLenum format, GLenum type,
+GLvoid *values)
+{
+   _mesa_GetnMinmaxARB(target, reset, format, type, INT_MAX, values);
+}

On a different note, I explicitly *approve* of the use of 'goto
overflow'. :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2t8+oACgkQX1gOwKyEAw9wGQCgnMkLFee64zCdN/c1UutZ613x
4qIAn2ZKxnEuqClIzemoTuc98bewOY8X
=Qc3X
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): swrastg: Add __DRI_TEX_BUFFER support (patches}

[nobled]

> http://cgit.freedesktop.org/mesa/mesa/commit/?id=2b64886c817ffa2d86abb9b4a5d79d1e2451
> 2011-03-11 19:49:28 (GMT)
>
> Without this, EXT_texture_from_pixmap is trivially broken.  With it,
> it's merely subtly broken.
>
> Signed-off-by: Adam Jackson 

What does 'subtly broken' mean in this case? Is it related to this
backtrace from August? Or the lack of GLX direct-rendering support?

> http://cgit.freedesktop.org/mesa/mesa/commit/?id=c14b4371ed58859d264b7b2581cfedc9cfd8401f
> 2010-08-13 19:58:11 (GMT)
>
> st/dri: move TFP code to dri_drawable.c
> This is based on a patch by nobled  and allows the TFP
> extension to be enabled for DRISW also. This patch does not enable TFP for 
> DRISW
> though, because testing on xephyr segfaults here (for both classic and 
> gallium):
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00786a4a in _mesa_GenTextures (n=1, textures=0xbfffee4c) at 
> main/texobj.c:788
> 788  ASSERT_OUTSIDE_BEGIN_END(ctx);
> (gdb)
> (gdb) where
> \#0  0x00786a4a in _mesa_GenTextures (n=1, textures=0xbfffee4c) at 
> main/texobj.c:788
> \#1  0x0817a004 in __glXDisp_GenTextures ()
> \#2  0x08168498 in __glXDispatch ()
> \#3  0x0808b6ce in Dispatch ()
> \#4  0x08084435 in main ()
>
> The TFP code is generic except for the teximage call. We need to verify that
> DRISW correclty implements whatever hook teximage finally calls.

Do we have a bug report about that somewhere? I'm wondering if it
happens with swrast-classic's TFP implementation, too...

Anyway, hey, anyone remember these GLX patches from September? Anyone
want to commit them? Because other bugs aside, indirect-only
texture-from-pixmap sucks.
From 8fd545534aab1e3f6641b37759d70cab1560d3fa Mon Sep 17 00:00:00 2001
From: nobled 
Date: Sun, 5 Sep 2010 16:14:01 +
Subject: [PATCH 1/3] glx: Add teximage vfuncs to drisw

Copied the implementation from dri2_glx.c.
---
 src/glx/drisw_glx.c |   51 ---
 1 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 5c7f40c..9eb80e4 100644
--- a/src/glx/drisw_glx.c
+++ b/src/glx/drisw_glx.c
@@ -46,8 +46,10 @@ struct drisw_screen
 
__DRIscreen *driScreen;
__GLXDRIscreen vtable;
-   const __DRIcoreExtension *core;
const __DRIswrastExtension *swrast;
+   const __DRIcoreExtension *core;
+
+   const __DRItexBufferExtension *texBuffer;
const __DRIconfig **driver_configs;
 
void *driver;
@@ -287,6 +289,49 @@ drisw_unbind_context(struct glx_context *context, struct glx_context *new)
driReleaseDrawables(&pcp->base);
 }
 
+static void
+drisw_bind_tex_image(Display * dpy,
+		GLXDrawable drawable,
+		int buffer, const int *attrib_list)
+{
+   struct glx_context *gc = __glXGetCurrentContext();
+   struct drisw_context *pcp = (struct drisw_context *) gc;
+   __GLXDRIdrawable *base = GetGLXDRIDrawable(dpy, drawable);
+   struct drisw_drawable *pdraw = (struct drisw_drawable *) base;
+   struct glx_display *dpyPriv = __glXInitialize(dpy);
+   struct drisw_display *pdp =
+  (struct drisw_display *) dpyPriv->dri2Display;
+   struct drisw_screen *psc;
+
+   if (pdraw != NULL) {
+  psc = (struct drisw_screen *) base->psc;
+
+/* FIXME: copied from dri2_glx.c. Can, should drisw do something like this? */
+#if 0 && __DRI2_FLUSH_VERSION >= 3
+  if (!pdp->invalidateAvailable && psc->f)
+	 psc->f->invalidate(pdraw->driDrawable);
+#endif
+
+  if (psc->texBuffer->base.version >= 2 &&
+	  psc->texBuffer->setTexBuffer2 != NULL) {
+	 (*psc->texBuffer->setTexBuffer2) (pcp->driContext,
+	   pdraw->base.textureTarget,
+	   pdraw->base.textureFormat,
+	   pdraw->driDrawable);
+  }
+  else {
+	 (*psc->texBuffer->setTexBuffer) (pcp->driContext,
+	  pdraw->base.textureTarget,
+	  pdraw->driDrawable);
+  }
+   }
+}
+
+static void
+drisw_release_tex_image(Display * dpy, GLXDrawable drawable, int buffer)
+{
+}
+
 static const struct glx_context_vtable drisw_context_vtable = {
drisw_destroy_context,
drisw_bind_context,
@@ -294,8 +339,8 @@ static const struct glx_context_vtable drisw_context_vtable = {
NULL,
NULL,
DRI_glXUseXFont,
-   NULL,
-   NULL,
+   drisw_bind_tex_image,
+   drisw_release_tex_image,
 };
 
 static struct glx_context *
-- 
1.7.0.4

From ad0013ef4c24c931679eabb7aec8c9210c6b5868 Mon Sep 17 00:00:00 2001
From: nobled 
Date: Sun, 5 Sep 2010 16:21:03 +
Subject: [PATCH 2/3] glx: Enable GLX_EXT_texture_from_pixmap in software

This makes commits 8d789be03430b80e0ba2fef19d56dd0b8e699ea2,
c14b4371ed58859d264b7b2581cfedc9cfd8401f,
and 2b64886c817ffa2d86abb9b4a5d79d1e2451 much more useful.

Now if a software DRI driver advertises it, we can use it in
direct-rendering contexts, instead of only indirect-rendering.
---
 src/glx/drisw_glx.c |   17 +
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/src/glx/drisw_glx.c b/src/glx/drisw_glx.c
index 9eb80e4..cae4a6b 100644
--- a/src/glx/

Re: [Mesa-dev] [PATCH 01/10] swrast: Add LUMINANCE, INTENSITY, LUMINANCE_ALPHA to span asserts.

[Brian Paul]

On 04/19/2011 12:25 PM, Ian Romanick wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/18/2011 08:43 PM, Brian Paul wrote:

On Mon, Apr 18, 2011 at 8:10 PM, Eric Anholt  wrote:

On Mon, 18 Apr 2011 16:16:37 -0700, Ian Romanick  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/18/2011 01:37 PM, Eric Anholt wrote:

Fixes ARB_texture_float/fbo-alphatest-formats.
---
  src/mesa/swrast/s_readpix.c |3 +++
  src/mesa/swrast/s_span.c|3 +++
  2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
index 5604c2e..a201a63 100644
--- a/src/mesa/swrast/s_readpix.c
+++ b/src/mesa/swrast/s_readpix.c
@@ -195,6 +195,9 @@ fast_read_rgba_pixels( struct gl_context *ctx,
   rb->_BaseFormat == GL_RGB ||
   rb->_BaseFormat == GL_RG ||
   rb->_BaseFormat == GL_RED ||
+ rb->_BaseFormat == GL_LUMINANCE ||
+ rb->_BaseFormat == GL_INTENSITY ||
+ rb->_BaseFormat == GL_LUMINANCE_ALPHA ||
   rb->_BaseFormat == GL_ALPHA);


At this point would it be easier to just assert the formats that are not
allowed?  Is there even anything that's left as a valid _BaseFormat that
isn't allowed here?


I keep wanting to remove asserts like this, and Brian says he likes
them.


I'm sorry you feel inconvenienced, but I'm a big believer in assertions.


I don't think the problem is the existence of assertions.  I think the
problem is that the format assertions have gotten a bit out of control.
  They're increasingly difficult to maintain, and we often get false
negatives.  This diminishes their value significantly.


Yes, I understand the downside of that.



That was my point in the initial review comment.  Once the assertion is
expanded to be correct, it basically asserts that _BaseFormat must have
a value.


I'm sorry to be pedantic but that's not accurate.  Illegal values for 
_BaseFormat at this point include GL_STENCIL_INDEX, 
GL_DEPTH_COMPONENT, GL_DEPTH_STENCIL, GL_COLOR_INDEX and GL_DUDV_ATI. 
 That's 5 illegal cases vs. 8 legal so it's not a huge difference.



> Since this should have been handled elsewhere, does having it
> here add anything other than maintenance burden?

That's just it, trying to read a non-color renderbuffer as a color 
format _should_ have been caught earlier (GL_INVALID_OPERATION).  The 
point of the assertion is to double-check that proper error detection 
was done earlier - and, to tell the reader that the subsequent code is 
prepared to handle these formats only.  If that assertions fails, the 
subsequent code should be reviewed to see if it can handle the new format.




I also think that many of these assertions could be improved by checking
for the negative condition instead of the positive condition.  There are
far fewer values that cannot be used than there are values that can be
used.  When someone is adding support for formats GL_FOO, it is more
clear that

assert(x != GL_FOO&&  x != GL_BAR);

needs to be changed than

assert(x == GL_ASDF || x == GL_QWERTY);


It could go either way.  In the case above, if GL_FOO is a new 
non-color format you'd still need to update assertions.




In these recent cases, perhaps we just need a better, extendable
assertion.  Something  like

assert(_mesa_is_base_color_format(rb->_BaseFormat));


That would certainly be more maintainable for this case, but I don't
think it's a general fix.  I think someone will have to look over this
code and come up with a plan.  1, 2, 3, not it! :)


I'd rather not make a mountain out of a molehill.  We've already spent 
more time typing emails about the topic than just fixing the assertions.


-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 01/10] swrast: Add LUMINANCE, INTENSITY, LUMINANCE_ALPHA to span asserts.

[Ian Romanick]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/18/2011 08:43 PM, Brian Paul wrote:
> On Mon, Apr 18, 2011 at 8:10 PM, Eric Anholt  wrote:
>> On Mon, 18 Apr 2011 16:16:37 -0700, Ian Romanick  
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 04/18/2011 01:37 PM, Eric Anholt wrote:
 Fixes ARB_texture_float/fbo-alphatest-formats.
 ---
  src/mesa/swrast/s_readpix.c |3 +++
  src/mesa/swrast/s_span.c|3 +++
  2 files changed, 6 insertions(+), 0 deletions(-)

 diff --git a/src/mesa/swrast/s_readpix.c b/src/mesa/swrast/s_readpix.c
 index 5604c2e..a201a63 100644
 --- a/src/mesa/swrast/s_readpix.c
 +++ b/src/mesa/swrast/s_readpix.c
 @@ -195,6 +195,9 @@ fast_read_rgba_pixels( struct gl_context *ctx,
   rb->_BaseFormat == GL_RGB ||
   rb->_BaseFormat == GL_RG ||
   rb->_BaseFormat == GL_RED ||
 + rb->_BaseFormat == GL_LUMINANCE ||
 + rb->_BaseFormat == GL_INTENSITY ||
 + rb->_BaseFormat == GL_LUMINANCE_ALPHA ||
   rb->_BaseFormat == GL_ALPHA);
>>>
>>> At this point would it be easier to just assert the formats that are not
>>> allowed?  Is there even anything that's left as a valid _BaseFormat that
>>> isn't allowed here?
>>
>> I keep wanting to remove asserts like this, and Brian says he likes
>> them.
> 
> I'm sorry you feel inconvenienced, but I'm a big believer in assertions.

I don't think the problem is the existence of assertions.  I think the
problem is that the format assertions have gotten a bit out of control.
 They're increasingly difficult to maintain, and we often get false
negatives.  This diminishes their value significantly.

That was my point in the initial review comment.  Once the assertion is
expanded to be correct, it basically asserts that _BaseFormat must have
a value.  Since this should have been handled elsewhere, does having it
here add anything other than maintenance burden?

I also think that many of these assertions could be improved by checking
for the negative condition instead of the positive condition.  There are
far fewer values that cannot be used than there are values that can be
used.  When someone is adding support for formats GL_FOO, it is more
clear that

assert(x != GL_FOO && x != GL_BAR);

needs to be changed than

assert(x == GL_ASDF || x == GL_QWERTY);

> In these recent cases, perhaps we just need a better, extendable
> assertion.  Something  like
> 
> assert(_mesa_is_base_color_format(rb->_BaseFormat));

That would certainly be more maintainable for this case, but I don't
think it's a general fix.  I think someone will have to look over this
code and come up with a plan.  1, 2, 3, not it! :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2t07YACgkQX1gOwKyEAw8IKACcCNkd99BcCttmiBq4ekDezSED
fjkAniwnDIZPPjW1VPQNwKZyVO4xv1TK
=mzoJ
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] st/egl: expose EGL_MESA_drm_image on x11 displays

[nobled]

Date: Sun, 13 Feb 2011 23:45:47 +

This makes it useable with the egl_gallium driver in X11.

It only works for the DRI2 backend, not ximage.
---
 src/gallium/state_trackers/egl/common/egl_g3d.c|3 ++
 .../state_trackers/egl/common/native_buffer.h  |3 +-
 src/gallium/state_trackers/egl/x11/native_dri2.c   |   24 
 3 files changed, 29 insertions(+), 1 deletions(-)

diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c
b/src/gallium/state_trackers/egl/common/egl_g3d.c
index ddca140..f0fb22b 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d.c
@@ -551,6 +551,9 @@ egl_g3d_initialize(_EGLDriver *drv, _EGLDisplay *dpy)
  dpy->Extensions.MESA_drm_image = EGL_TRUE;
}

+   if (dpy->Platform == _EGL_PLATFORM_X11 && gdpy->native->buffer)
+  dpy->Extensions.MESA_drm_image = EGL_TRUE;
+
if (dpy->Platform == _EGL_PLATFORM_WAYLAND && gdpy->native->buffer)
   dpy->Extensions.MESA_drm_image = EGL_TRUE;

diff --git a/src/gallium/state_trackers/egl/common/native_buffer.h
b/src/gallium/state_trackers/egl/common/native_buffer.h
index 5c29ab9..2c99381 100644
--- a/src/gallium/state_trackers/egl/common/native_buffer.h
+++ b/src/gallium/state_trackers/egl/common/native_buffer.h
@@ -41,7 +41,8 @@ struct pipe_resource;
  * Just like a native window or a native pixmap, a native buffer is another
  * native type.  Its definition depends on the native display.
  *
- * For DRM platform, the type of a native buffer is struct winsys_handle.
+ * For DRM, Wayland, and X11 platforms, the type of a native buffer
+ * is struct winsys_handle.
  */
 struct native_display_buffer {
struct pipe_resource *(*import_buffer)(struct native_display *ndpy,
diff --git a/src/gallium/state_trackers/egl/x11/native_dri2.c
b/src/gallium/state_trackers/egl/x11/native_dri2.c
index b18c313..46c7bb9 100644
--- a/src/gallium/state_trackers/egl/x11/native_dri2.c
+++ b/src/gallium/state_trackers/egl/x11/native_dri2.c
@@ -789,6 +789,29 @@ dri2_display_init_screen(struct native_display *ndpy)
return TRUE;
 }

+static struct pipe_resource *
+dri2_display_import_buffer(struct native_display *ndpy,
+  const struct pipe_resource *templ,
+  void *buf)
+{
+   return ndpy->screen->resource_from_handle(ndpy->screen,
+ templ, (struct winsys_handle *) buf);
+}
+
+static boolean
+dri2_display_export_buffer(struct native_display *ndpy,
+  struct pipe_resource *res,
+  void *buf)
+{
+   return ndpy->screen->resource_get_handle(ndpy->screen,
+ res, (struct winsys_handle *) buf);
+}
+
+static struct native_display_buffer dri2_display_buffer = {
+   dri2_display_import_buffer,
+   dri2_display_export_buffer
+};
+
 static unsigned
 dri2_display_hash_table_hash(void *key)
 {
@@ -851,6 +874,7 @@ x11_create_dri2_display(Display *dpy,
dri2dpy->base.is_pixmap_supported = dri2_display_is_pixmap_supported;
dri2dpy->base.create_window_surface = dri2_display_create_window_surface;
dri2dpy->base.create_pixmap_surface = dri2_display_create_pixmap_surface;
+   dri2dpy->base.buffer = &dri2_display_buffer;

return &dri2dpy->base;
 }
-- 
1.7.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms

[Alex Deucher]

On Tue, Apr 19, 2011 at 1:24 PM, Henri Verbeet  wrote:
> On 19 April 2011 18:11, Alex Deucher  wrote:
>> I've pushed the r600c patch.  I'll take a look at the r600g patch later 
>> today.
>>
> I'm without r600 hardware this week, but personally I think I'd be
> happier with a helper function for the endian swap, instead of
> sprinkling ifdefs all over the source code.

Yeah, that would probably be nicer.  I'm not inclined to put more
effort into r600c.  It might be a useful cleanup for r600g, but I'm
not sure it would make that much difference since the r600g code is
already pretty clean.

Alex

>
> E.g., something along these lines:
>
> static inline unsigned r600_endian_swap(unsigned size)
> {
> #ifdef PIPE_ARCH_BIG_ENDIAN
>    switch (size)
>    {
>        case 16:
>            return ENDIAN_8IN16;
>        case 32:
>            return ENDIAN_8IN32;
>        case 64:
>            return ENDIAN_8IN64;
>        default:
>            return ENDIAN_NONE;
>    }
> #else
>    return ENDIAN_NONE;
> #endif
> }
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms

[Alex Deucher]

On Tue, Apr 19, 2011 at 12:11 PM, Alex Deucher  wrote:
> On Tue, Apr 19, 2011 at 4:06 AM, Cédric Cano  
> wrote:
>> Hi
>>
>> Few days ago, I posted a couple of patches on dri-devel but it doesn't seem
>> to be the correct place. Here you are 2 patches that adds support for RV730
>> in r600c and r600g.
>>
>
> I've pushed the r600c patch.  I'll take a look at the r600g patch later today.
>

I've gone ahead and pushed the r600g patches as well.  thanks!

Alex

> Thanks!
>
> Alex
>
>> More details are available here :
>> http://lists.freedesktop.org/archives/dri-devel/2011-April/010056.html
>> http://lists.freedesktop.org/archives/dri-devel/2011-April/010281.html
>>
>> Regards,
>> Cedric
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 9/9] i915: Gut all remaining bits of hardware fog

[Eric Anholt]

On Fri, 15 Apr 2011 23:10:52 -0700, "Ian Romanick"  wrote:
> From: Ian Romanick 
> 
> None of this ever gets used.  Fog is always calculated by a fragment
> program.  Even though the fixed-function fog unit is never used, state
> updates are still sent to the hardware.  Removing those spurious state
> updates can't hurt performance.

Looks like a couple of those statechange functions could get just
removed now that they do nothing.  Other than that, the series is:

Reviewed-by: Eric Anholt 


pgpvZ43E4BOQx.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms

[Henri Verbeet]

On 19 April 2011 18:11, Alex Deucher  wrote:
> I've pushed the r600c patch.  I'll take a look at the r600g patch later today.
>
I'm without r600 hardware this week, but personally I think I'd be
happier with a helper function for the endian swap, instead of
sprinkling ifdefs all over the source code.

E.g., something along these lines:

static inline unsigned r600_endian_swap(unsigned size)
{
#ifdef PIPE_ARCH_BIG_ENDIAN
switch (size)
{
case 16:
return ENDIAN_8IN16;
case 32:
return ENDIAN_8IN32;
case 64:
return ENDIAN_8IN64;
default:
return ENDIAN_NONE;
}
#else
return ENDIAN_NONE;
#endif
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] KWin and Mesa

[Jerome Glisse]

On Tue, Apr 19, 2011 at 10:52 AM, Martin Gräßlin  wrote:
> Hi Mesa-devs,
>
> yesterday I published a rant about Mesa breaking KWin and given some
> comments on Phoronix Forums it seems like there is the wish for more
> communication between our development groups and so I want to start it. Please
> note that I am not subscribed to this mailing list, so please keep me in CC (I
> might not be able to reply this week at all). It is my wish to never have to
> rant about the state of Linux drivers any more and that I never have to see
> Mesa breaking KWin again.
>
> First of all I want to give a little bit personal history to help you
> understand why I so far did not contact you and up to now wrote two rants
> about Mesa breaking KWin. Let's go back to 2010 and the 4.5 release. In March
> 2010 I finished my Master Thesis and in April 2010 I started my first job. KDE
> hat the feature freeze for the 4.5 release around End of April, beginning of
> May. All new functionality including the Blur and Lanczos filter were
> implemented at that time. Given the change in my life due to end of my studies
> I did not contribute much to the release.
>
> At the time when we implemented the features the current Mesa version was 7.7.
> Version 7.8 was under development and when it got released marked as a
> "development version". I read this information and considered "ok we don't
> have to deal with 7.8 - it is development". At that time I had a notebook with
> NVIDIA graphics and an old system with a rather modern Ati card, with a
> crashing X server if I tried to use the radeon driver. I had no chance to test
> Mesa drivers at that time!
>
> In the time leading to the 4.5 release KWin had no active maintainer. Lubos
> had been inactive for quite some time and made me maintainer in November. At
> that time I considered Lubos still to be the maintainer and to be responsible
> for decisions whether to ship the new features or not. I considered myself
> only responsible for my own code (which did not cause any problems in that
> release). I was also running the stable version of KDE (4.4) at that time and
> the development only for testing.
>
> During the beta phase we realized that we had a problem. Mesa 7.8.2 was
> marked as stable (which I did not expect due to the fact that 7.8.0 and 7.8.1
> were unstable) and distributions started to include it. Users were complaining
> about broken features mostly concerning blur and lanczos filters and mostly
> with Ati and Intel drivers. Nobody in our development team had an Intel system
> at that time. I had had access to a system before through a friend of mine,
> but unfortunately it broke down in exactly that important time. Later on my
> friend got a new Intel powered device but run Debian Testing on it which did
> not show any of the problems the users reported with Mesa 7.7. Concerning Ati
> I knew that Fredrik had been in contact with Mesa developers and that all the
> new functionality had been implemented on his Ati systems. So we knew that the
> functionality worked at least with some systems.
>
> With the looming release and more and more obvious problems we faced two
> possible solutions: remove the code completely (disable by default would not
> have solved it) or try to get it working somehow. I did not see any reason why
> we should have punished the users of working drivers (e.g. NVIDIA) because
> other drivers did not work. After all the new functionality was an important
> feature for our provided user experience and our designers and the Plasma team
> were demanding it. So we had only the option to make it work. Now you can
> imagine how difficult it is to workaround bugs in hardware you do not have. My
> solution was to implement a black list and to crowd source the creation to all
> our users. Another of the changes was to have the test whether to use direct
> rendering in an external application (due to drivers crashing when trying to
> create a GLContext) and there the "hack" was introduced which now backfired.
>
> Now why did I not contact you when we were facing these problems? Given that I
> had a day job, 2 h travel each day and trying at the same time to make the
> experience as smooth as possible for our users in the evenings, I seriously
> had not the time to even think about it. And what would it have changed? We
> need to get KDE supporting the drivers out there and not the next version! I
> am sorry that I did not contact you at that time but I think everybody will
> understand that sometimes as a volunteer developer you don't have the time to
> do everything which would help. Last but not least I did not feel responsible
> as I was not the maintainer of KWin.
>
> When we released 4.5 I was positive that we had successfully established a
> black list which ensures that no user would face issues. Unfortunately I was
> wrong. Users still faced the issue and even worse: the desktop started to
> freeze if you changed settings in KWin. A problem which had b

Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms

[Alex Deucher]

On Tue, Apr 19, 2011 at 4:06 AM, Cédric Cano  wrote:
> Hi
>
> Few days ago, I posted a couple of patches on dri-devel but it doesn't seem
> to be the correct place. Here you are 2 patches that adds support for RV730
> in r600c and r600g.
>

I've pushed the r600c patch.  I'll take a look at the r600g patch later today.

Thanks!

Alex

> More details are available here :
> http://lists.freedesktop.org/archives/dri-devel/2011-April/010056.html
> http://lists.freedesktop.org/archives/dri-devel/2011-April/010281.html
>
> Regards,
> Cedric
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] KWin and Mesa

[Lucas Stach]

Hello Martin,

sorry for the kick-in, but I feel obligated to speak up here.

First of all you wrote a rather long text, but you don't make a single
point _how_ to make the collaboration between mesa and kwin devs any
better. It seems you just want to explain why you are doing things the
way you are doing them.

Please understand that mesa is also a community driven project and many
of the contributions (especially for hardware drivers) come from
volunteers, too. What you are calling for is to make them watch for
regressions in all applications using mesa. I don't see why those devs
should have more time for such things than kwin devs. It just won't work
out to let one side do all the work. Trying to setup an automated
regression test together with the kwin devs sounds more like a plan. It
would end up in some work for both sides, but in the end it will result
in a better quality.

Also as said half a year ago, blacklisting features in kwin based on
some renderer string is a _very_ bad idea. OpenGL has ways standardized
ways to query functionality. If advertised features do not work as
expected this is a bug in mesa and should be reported, not silenced on
the applications side. Writing and testing applications only against the
proprietary drivers doesn't make the situation any better as these
drivers let you get away with a pile of brainfuck, which you won't find
in any OpenGL standard. I think in this respect kwin devs (as well as
every other app developer) should also ask themselfes if their stuff is
really valid OpenGL. It's not always mesa breaking stuff, sometimes it
is also the application breaking mesa.

You should really try to find a way which both sides can agree with.
Demanding one-sided things is not the way to go. We can't take the
hassle of testing your application from you. You will find many open
minded people in the mesa community who will gladly help you if
something breaks, but there is also some work you have to do. Real
communication between devs of both sides is the way to go if you want to
make for a better user experience.

Regards,
Lucas


Am Dienstag, den 19.04.2011, 16:52 +0200 schrieb Martin Gräßlin:
> Hi Mesa-devs,
> 
> yesterday I published a rant about Mesa breaking KWin and given some 
> comments on Phoronix Forums it seems like there is the wish for more 
> communication between our development groups and so I want to start it. 
> Please 
> note that I am not subscribed to this mailing list, so please keep me in CC 
> (I 
> might not be able to reply this week at all). It is my wish to never have to 
> rant about the state of Linux drivers any more and that I never have to see 
> Mesa breaking KWin again.
> 
> First of all I want to give a little bit personal history to help you 
> understand why I so far did not contact you and up to now wrote two rants 
> about Mesa breaking KWin. Let's go back to 2010 and the 4.5 release. In March 
> 2010 I finished my Master Thesis and in April 2010 I started my first job. 
> KDE 
> hat the feature freeze for the 4.5 release around End of April, beginning of 
> May. All new functionality including the Blur and Lanczos filter were 
> implemented at that time. Given the change in my life due to end of my 
> studies 
> I did not contribute much to the release.
> 
> At the time when we implemented the features the current Mesa version was 
> 7.7. 
> Version 7.8 was under development and when it got released marked as a 
> "development version". I read this information and considered "ok we don't 
> have to deal with 7.8 - it is development". At that time I had a notebook 
> with 
> NVIDIA graphics and an old system with a rather modern Ati card, with a 
> crashing X server if I tried to use the radeon driver. I had no chance to 
> test 
> Mesa drivers at that time!
> 
> In the time leading to the 4.5 release KWin had no active maintainer. Lubos 
> had been inactive for quite some time and made me maintainer in November. At 
> that time I considered Lubos still to be the maintainer and to be responsible 
> for decisions whether to ship the new features or not. I considered myself 
> only responsible for my own code (which did not cause any problems in that 
> release). I was also running the stable version of KDE (4.4) at that time and 
> the development only for testing.
> 
> During the beta phase we realized that we had a problem. Mesa 7.8.2 was 
> marked as stable (which I did not expect due to the fact that 7.8.0 and 7.8.1 
> were unstable) and distributions started to include it. Users were 
> complaining 
> about broken features mostly concerning blur and lanczos filters and mostly 
> with Ati and Intel drivers. Nobody in our development team had an Intel 
> system 
> at that time. I had had access to a system before through a friend of mine, 
> but unfortunately it broke down in exactly that important time. Later on my 
> friend got a new Intel powered device but run Debian Testing on it which did 
> not show any of the problems the u

Re: [Mesa-dev] KWin and Mesa

[Zack Rusin]

On Tuesday 19 April 2011 10:52:08 Martin Gräßlin wrote:
> Hi Mesa-devs,
> 
> yesterday I published a rant about Mesa breaking KWin and given some 
> comments on Phoronix Forums it seems like there is the wish for more 
> communication between our development groups and so I want to start it.
> Please  note that I am not subscribed to this mailing list, so please keep
> me in CC (I might not be able to reply this week at all). It is my wish to
> never have to rant about the state of Linux drivers any more and that I
> never have to see Mesa breaking KWin again.

Hi Martin,

I cannot speak for the others but your email is way too long. I doubt anyone 
will read it. Let me just point out the following:
"Mesa is our most important upstream and KWin (together with Compiz 
and Mutter) are your most important downstreams."
is not even close to be true. They're very important, but they're not even 
close to be the most important. Reality is that no one is getting paid to make 
sure KWin works on latest Mesa3D and that by itself makes it pretty 
insignificant. In fact there's very few people running KDE as their main DE at 
all here.

Your plead to understand that KWin has only three developer falls on deaf ears 
given that basically everyone here works 12 hour jobs as it is. The reality is 
that if you want things to never break you'll need to make sure of that 
yourself. I'd probably start with some Piglit tests. Otherwise I suggest you 
subscribe and keep that mouse cursor on "report new bug" button our bugzilla.

z
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36238] Mesa release files don't contain scons control files

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36238

--- Comment #1 from Brian Paul  2011-04-19 08:13:32 PDT 
---
Ok, I've fixed this in git on master and the 7.10 branch.  I did test builds
and everything seems in order, but there's still a chance that I might have
missed something.  If I make some updated tarballs of 7.10.2 will you test
them?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] KWin and Mesa

[Martin Gräßlin]

Hi Mesa-devs,

yesterday I published a rant about Mesa breaking KWin and given some 
comments on Phoronix Forums it seems like there is the wish for more 
communication between our development groups and so I want to start it. Please 
note that I am not subscribed to this mailing list, so please keep me in CC (I 
might not be able to reply this week at all). It is my wish to never have to 
rant about the state of Linux drivers any more and that I never have to see 
Mesa breaking KWin again.

First of all I want to give a little bit personal history to help you 
understand why I so far did not contact you and up to now wrote two rants 
about Mesa breaking KWin. Let's go back to 2010 and the 4.5 release. In March 
2010 I finished my Master Thesis and in April 2010 I started my first job. KDE 
hat the feature freeze for the 4.5 release around End of April, beginning of 
May. All new functionality including the Blur and Lanczos filter were 
implemented at that time. Given the change in my life due to end of my studies 
I did not contribute much to the release.

At the time when we implemented the features the current Mesa version was 7.7. 
Version 7.8 was under development and when it got released marked as a 
"development version". I read this information and considered "ok we don't 
have to deal with 7.8 - it is development". At that time I had a notebook with 
NVIDIA graphics and an old system with a rather modern Ati card, with a 
crashing X server if I tried to use the radeon driver. I had no chance to test 
Mesa drivers at that time!

In the time leading to the 4.5 release KWin had no active maintainer. Lubos 
had been inactive for quite some time and made me maintainer in November. At 
that time I considered Lubos still to be the maintainer and to be responsible 
for decisions whether to ship the new features or not. I considered myself 
only responsible for my own code (which did not cause any problems in that 
release). I was also running the stable version of KDE (4.4) at that time and 
the development only for testing.

During the beta phase we realized that we had a problem. Mesa 7.8.2 was 
marked as stable (which I did not expect due to the fact that 7.8.0 and 7.8.1 
were unstable) and distributions started to include it. Users were complaining 
about broken features mostly concerning blur and lanczos filters and mostly 
with Ati and Intel drivers. Nobody in our development team had an Intel system 
at that time. I had had access to a system before through a friend of mine, 
but unfortunately it broke down in exactly that important time. Later on my 
friend got a new Intel powered device but run Debian Testing on it which did 
not show any of the problems the users reported with Mesa 7.7. Concerning Ati 
I knew that Fredrik had been in contact with Mesa developers and that all the 
new functionality had been implemented on his Ati systems. So we knew that the 
functionality worked at least with some systems.

With the looming release and more and more obvious problems we faced two 
possible solutions: remove the code completely (disable by default would not 
have solved it) or try to get it working somehow. I did not see any reason why 
we should have punished the users of working drivers (e.g. NVIDIA) because 
other drivers did not work. After all the new functionality was an important 
feature for our provided user experience and our designers and the Plasma team 
were demanding it. So we had only the option to make it work. Now you can 
imagine how difficult it is to workaround bugs in hardware you do not have. My 
solution was to implement a black list and to crowd source the creation to all 
our users. Another of the changes was to have the test whether to use direct 
rendering in an external application (due to drivers crashing when trying to 
create a GLContext) and there the "hack" was introduced which now backfired.

Now why did I not contact you when we were facing these problems? Given that I 
had a day job, 2 h travel each day and trying at the same time to make the 
experience as smooth as possible for our users in the evenings, I seriously 
had not the time to even think about it. And what would it have changed? We 
need to get KDE supporting the drivers out there and not the next version! I 
am sorry that I did not contact you at that time but I think everybody will 
understand that sometimes as a volunteer developer you don't have the time to 
do everything which would help. Last but not least I did not feel responsible 
as I was not the maintainer of KWin. 

When we released 4.5 I was positive that we had successfully established a 
black list which ensures that no user would face issues. Unfortunately I was 
wrong. Users still faced the issue and even worse: the desktop started to 
freeze if you changed settings in KWin. A problem which had been completely 
unknown to us before the release (there was a bug report by one user but it 
was unconfirmed). None of us was able to reprod

[Mesa-dev] [Bug 36282] 34a5d3b9f4740601708c82093e2114356d749e65: glxgears segfaults (swrast, r600g, nouveau_vieux)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36282

--- Comment #12 from Alexandre Demers  2011-04-19 
07:36:02 PDT ---
(In reply to comment #11)
> only happens here when shared-glapi is enabled (r600g)

Confirmed also here that the bug only appears when Mesa is compiled with
--enable-shared-glapi.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment

[Brian]

On 04/19/2011 04:00 AM, Christoph Bumiller wrote:

  On 16.04.2011 18:50, Christoph Bumiller wrote:

I hope the new version is correct, the commit message describes why I
did the first change, and the second change is described in a comment.

Note that the MAD for inversion uses Height - 1 instead of Height.

With this, piglit glsl-arb-fragment-coord-conventions and
fbo-depth-sample-compare pass on nvc0.

I was assuming that integer pixel centers for size 100 range from 0 to
99 and half-integer pixel centers from 0.5 to 99.5.


Attached a better version of the patch, potentially saving an
instruction and avoiding precision issues with NEAREST filtering that
made piglit's blending-in-shader fail.

The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was
r600 classic, which should also work more correctly now since (at
least according to gallium caps) it uses half-integer pixel center,
and for H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5.

Please review.


All the relevant piglit tests seem to pass with softpipe, llvmpipe and 
swrast.


Tested-by: Brian Paul 

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] docs: Update for Intel ARB_texture_float and ARB_color_buffer_float.

[Brian]

On 04/18/2011 02:53 PM, Eric Anholt wrote:

---
  docs/relnotes-7.11.html |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/relnotes-7.11.html b/docs/relnotes-7.11.html
index 131fecd..2bd126c 100644
--- a/docs/relnotes-7.11.html
+++ b/docs/relnotes-7.11.html
@@ -36,21 +36,21 @@ tbd

  New features
  
-GL_ARB_color_buffer_float (gallium drivers)
+GL_ARB_color_buffer_float (gallium drivers, i965)
  GL_ARB_draw_buffers_blend (gallium)
  GL_ARB_draw_instanced extension (gallium drivers, swrast)
  GL_ARB_instanced_arrays extension (gallium drivers)
  GL_ARB_occlusion_query2 (gallium drivers, swrast)
  GL_ARB_sampler_objects (gallium drivers)
  GL_ARB_texture_compression_rgtc (gallium drivers, swrast)
-GL_ARB_texture_float (gallium)
+GL_ARB_texture_float (gallium, i965)
  GL_EXT_texture_compression_latc (gallium drivers, swrast)
  GL_EXT_texture_compression_rgtc (gallium drivers, swrast)
  GL_EXT_texture_sRGB_decode (gallium drivers, swrast, i965)
  GL_EXT_texture_snorm (gallium drivers)
  GL_ATI_draw_buffers (all drivers)
  GL_ATI_texture_compression_3dc (gallium drivers, swrast)
-GL_ATI_texture_float (gallium)
+GL_ATI_texture_float (gallium, i965)
  GL_NV_texture_barrier (gallium drivers)
  



AFAIC, you don't have to post patches like this for review, but 
anyway, Reviewed-by: Brian Paul 


-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 05/10] mesa: Add renderbuffer accessors for A, I, L, FLOAT32.

[Brian]

On 04/18/2011 02:37 PM, Eric Anholt wrote:

Of these, intel will be using I and L initially, and A once we rewrite
fragment shaders and the CC for rendering to it as R.
---
  src/mesa/main/renderbuffer.c |  218 ++
  1 files changed, 218 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/renderbuffer.c b/src/mesa/main/renderbuffer.c
index 7826e44..2fa9e27 100644
--- a/src/mesa/main/renderbuffer.c
+++ b/src/mesa/main/renderbuffer.c
@@ -1114,6 +1114,194 @@ get_values_rg1616(struct gl_context *ctx, struct 
gl_renderbuffer *rb,
  }

  /**
+ * Functions for MESA_FORMAT_INTENSITY_FLOAT32.
+ */
+static void
+get_row_i_float32(struct gl_context *ctx, struct gl_renderbuffer *rb,
+ GLuint count, GLint x, GLint y, void *values)
+{
+   const GLfloat *src = rb->GetPointer(ctx, rb, x, y);
+   GLfloat *dst = values;
+   GLuint i;
+
+   for (i = 0; i<  count; i++) {
+  dst[i * 4 + RCOMP] = src[i];
+  dst[i * 4 + GCOMP] = dst[i * 4 + RCOMP];
+  dst[i * 4 + BCOMP] = dst[i * 4 + RCOMP];
+  dst[i * 4 + ACOMP] = dst[i * 4 + RCOMP];


Just a small nit, but I'd write this as follows:

for (i = 0; i<  count; i++) {
   dst[i * 4 + RCOMP] =
   dst[i * 4 + GCOMP] =
   dst[i * 4 + BCOMP] =
   dst[i * 4 + ACOMP] = src[i];
}

It's less typing and seeing dst[] on the RHS is a little distracting 
at first glance.


Otherwise, for the series:
Reviewed-by: Brian Paul 

-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36384] configure tips

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36384

--- Comment #3 from Brian Paul  2011-04-19 06:56:18 PDT 
---
Hmmm, I can't seem to add George Sapountzis  to the cc
list.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36384] configure tips

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36384

Brian Paul  changed:

   What|Removed |Added

 CC||wallbra...@gmail.com

--- Comment #2 from Brian Paul  2011-04-19 06:54:55 PDT 
---
I believe George and Jakob should sign off on #1.  Cc'ing them.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] libxml2 (python) dependency

[Dan Nicholson]

On Mon, Apr 18, 2011 at 11:14 PM, Tilman Sauerbeck
 wrote:
> Ian Romanick [2011-04-18 17:12]:
>> On 04/18/2011 04:48 PM, tom fogal wrote:
>> > Hey all,
>> >
>> > We recently became more aware of a dependency on python's libxml2 for
>> > building Mesa.  We're not as proactive as we should be, but tend to
>> > upgrade Mesa every few releases; I think this was a jump from 7.8 to 7.10.
>> >
>> > Anyway, libxml2 is a bit arduous for us because it's not installed by
>> > default on Linux or Mac.  On Linux, it's easy to grab via a package
>> > manager, but still does not exist by default on some distros.  In
>> > general, non-standard dependencies are difficult because they make our
>> > (already very large) software stack more complex.
>> >
>> > Is the package truly needed?  I think it's used to parse spec files and
>> > autogenerate trampolines or callbacks or something like that.  Didn't we
>> > used to have plain text files for that?  Any reason we can't go back to
>> > something simpler?  Does code speak loud than words, here? :)
>>
>> We haven't used plain-text for years.  What has changed is that the
>> generated files are no longer tracked in source control.  They are
>> generated at compile time because anything else is just nuts. :)  I know
>
> What about generating them at 'make dist' time, too...?
> That way the Python dependency would only hit developers, but not
> people building from proper release tarballs.

I think this is a good idea, but it might be a little difficult with
the mesa build machinery.

--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g)

[Jose Fonseca]

- Original Message -
> From: "Michel Dänzer" 
> To: "Cédric Cano" 
> Cc: "icthj" , mesa-dev@lists.freedesktop.org
> Sent: Tuesday, April 19, 2011 10:39:41 AM
> Subject: Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g)
> 
> [ Moving to the mesa-dev list ]
> 
> On Fre, 2011-04-15 at 18:20 +0200, Cédric Cano wrote:
> > 
> > Here you are a patch that adds big endian support for rv730 in r600
> > gallium driver.
> > 
> > I used the mesa-demos to test the driver status on big endian
> > platform.
> > Except with demos using accumulation buffer, the rendering is the
> > same
> > as on Intel platform. Albeit there are still some artefacts with
> > some
> > demos.
> > 
> > I manage to fix accumulation buffer demos but then, glReadPixels
> > demos
> > won't work. I still can figure out (like with r600c) what and when
> > I
> > must enable swap. It will depends on object's domains. That's what
> > I
> > tried to do in r600_cb and r600_create_sampler_view.
> 
> That's probably because it hasn't been fully thought through yet how
> to
> deal with big endian CPUs vs. little endian GPUs in Gallium. When
> this
> was discussed previously, the basic rule decided was that all data
> passed across the Gallium driver interface was supposed to be little
> endian. That should probably be feasible in general for at least
> 'standard' pixel formats, but I'm afraid it doesn't really work for
> vertex data[0], which could be fed from the application (which will
> use
> CPU native byte order) to the GPU more or less directly.
> 
> Maybe byte order should be handled explicitly by the Gallium format
> definitions, and then it would be up to the state tracker to use the
> appropriate byte order formats. José, have you had any further
> thoughts
> on this?

I'm not sure either.  The design principle we've used in the past for this in 
the past is to match what the hardware can and cannot do.  It appears from 
Cédric's patch that r600 is able to toggle between bit/little ending values in 
vertices.  Vertex/index buffers are indeed special because, unlike pixel data, 
the types can only be inferred at draw time, and not at data upload, so 
transcoding at BufferMap/BufferData is not really feasible.

Does other hardware allow to toggle vertex data reads between little/big 
endian?  If so then perhaps a per-vertex-element state bit indicating 
endianness might be sensible.

Jose


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g: track dirty registers better.

[Benjamin BELLEC]

Le 18/04/2011 16:37, Benjamin BELLEC a écrit :
> Le 18/04/2011 10:20, Dave Airlie a écrit :
>> On Mon, Apr 18, 2011 at 11:00 AM, Dave Airlie  wrote:
>>> From: Dave Airlie 
>>>
>>> This is a first step to decreasing the CPU usage, by decreasing how much
>>> stuff we pass to the GPU and hence to the kernel CS checker.
>>>
>>> This adds a check to see if the values we need to write are actually dirty,
>>> and avoids writing if they are. However certain register need to always
>>> be written so we add a new flag to say which ones should be always written
>>> if used. (Note this could probably be done cleaner with a larger 
>>> refactoring,
>>>  since I think the CONST_BUFFER_SIZE_PS/VS and CONST_CACHE_PS/VS might
>>> be better off as a special state).
>>>
>>> It also moves the need_bo to be a flags on the register now.
>>>
>>> With this, a frame of gears goes from emitting 3k dwords to emitting 2k 
>>> dwords,
>>> and I'm sure it could get a lot smaller.
>>>
>>> TODO:
>>> Currently we flush if we have a BO, this could probably be improved.
>>> Drop the special flush flag and move the buffer size ps/vs to a special 
>>> state.
>>>
>>
>> I've pushed a v2 of this to the r600g-dirty branch in my repo with
>> another couple of patches on top
>>
>> the v2 just fixes the evergreen paths.
>>
>> The other patches cause regressions, but decrease further the amount
>> of dwords per frame which should decrease time in the kernel parser,
>> just have to figure out the regressions.
>>
>> Dave.
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
> Hello,
> 
> I just test your branch, it breaks the 3 apps I tested :
> 
> - glxgears, I do not see gears. I can see them quickly by moving the
> window at the border of my screen
> - nexuiz-sdl : the menu is break. (not tested ingame)
> - etqw : the menu is break too. In game, I have "phantom" frame. This is
> hard to describe, and I have no screenshots to show you exactly. To sum
> up, I have the impression that the frames are mixed.
> 
> I will test your future patches (if any).
> 
> Benjamin

All is now fixed.
Also, I have 15.50 % of framerate improvements in nexuiz-sdl on my
system (x86 - RV770 - 1680*1050 - No HDR - No sound)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment

[Marek Olšák]

2011/4/19 Michel Dänzer 

> On Die, 2011-04-19 at 12:00 +0200, Christoph Bumiller wrote:
> > On 16.04.2011 18:50, Christoph Bumiller wrote:
> > > I hope the new version is correct, the commit message describes why I
> > > did the first change, and the second change is described in a comment.
> > >
> > > Note that the MAD for inversion uses Height - 1 instead of Height.
> > >
> > > With this, piglit glsl-arb-fragment-coord-conventions and
> > > fbo-depth-sample-compare pass on nvc0.
> > >
> > > I was assuming that integer pixel centers for size 100 range from 0 to
> > > 99 and half-integer pixel centers from 0.5 to 99.5.
> > >
> > Attached a better version of the patch, potentially saving an
> > instruction and avoiding precision issues with NEAREST filtering that
> > made piglit's blending-in-shader fail.
> >
> > The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was
> > r600 classic, which should also work more correctly now since (at
> > least according to gallium caps) it uses half-integer pixel center,
> > and for H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5.
>
> FWIW, this fixes compiz alpha-blurred contents being off by one
> vertically on r300g. Thanks!
>

If that's true, it should be a candidate for 7.10 as well.

Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36384] configure tips

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36384

--- Comment #1 from Marek Olšák  2011-04-19 03:45:45 PDT ---
(2) and (3) is done. I leave (1) to swrastg maintainers.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment

[Michel Dänzer]

On Die, 2011-04-19 at 12:00 +0200, Christoph Bumiller wrote:
> On 16.04.2011 18:50, Christoph Bumiller wrote: 
> > I hope the new version is correct, the commit message describes why I
> > did the first change, and the second change is described in a comment.
> > 
> > Note that the MAD for inversion uses Height - 1 instead of Height.
> > 
> > With this, piglit glsl-arb-fragment-coord-conventions and
> > fbo-depth-sample-compare pass on nvc0.
> > 
> > I was assuming that integer pixel centers for size 100 range from 0 to
> > 99 and half-integer pixel centers from 0.5 to 99.5.
> > 
> Attached a better version of the patch, potentially saving an
> instruction and avoiding precision issues with NEAREST filtering that
> made piglit's blending-in-shader fail.
> 
> The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was
> r600 classic, which should also work more correctly now since (at
> least according to gallium caps) it uses half-integer pixel center,
> and for H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5.

FWIW, this fixes compiz alpha-blurred contents being off by one
vertically on r300g. Thanks!


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r200: enable EXT_gpu_program_parameters

[Marek Olšák]

OK, thanks for testing. I have pushed the patch.

Marek

On Tue, Apr 19, 2011 at 11:54 AM, Nicolas Kaiser  wrote:

> * Ian Romanick :
> > > ./src/demos/vao_demo
> > > GL_RENDERER = Mesa DRI R200 (R200 514D)  TCL DRI2
> > > GL_VERSION = 1.3 Mesa 7.11-devel (git-4ee40c3)
> >
> > Do we have VAO (either ARB or APPLE) in piglit?  That would actually be
> > a more interesting test.   The Mesa demos exercise extensions pretty
> > minimally in most cases.
>
> I found two piglit tests, general/vao-01 and general/vao-02.
>
> ./piglit-run.py -t vao tests/all.tests results/vao.results
>
> With Marek's patch, they pass:
>
> ./piglit-run.py -t vao tests/all.tests results/vao.enabled.results
> ./piglit-summary-html.py summary/compare.vao results/vao.results
> results/vao.enabled.results
>
>vao.results vao.enabled.results
>
> All 0/0 2/2
> general 0/0 2/2
> vao-01  skippass
> vao-02  skippass
>
>
> Best regards,
> Nicolas Kaiser
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] st/mesa: fix WPOS adjustment

[Christoph Bumiller]

On 16.04.2011 18:50, Christoph Bumiller wrote:
> I hope the new version is correct, the commit message describes why I
> did the first change, and the second change is described in a comment.
>
> Note that the MAD for inversion uses Height - 1 instead of Height.
>
> With this, piglit glsl-arb-fragment-coord-conventions and
> fbo-depth-sample-compare pass on nvc0.
>
> I was assuming that integer pixel centers for size 100 range from 0 to
> 99 and half-integer pixel centers from 0.5 to 99.5.
>
Attached a better version of the patch, potentially saving an
instruction and avoiding precision issues with NEAREST filtering that
made piglit's blending-in-shader fail.

The only other location I found STATE_FB_WPOS_Y_TRANSFORM used was r600
classic, which should also work more correctly now since (at least
according to gallium caps) it uses half-integer pixel center, and for
H=100, 0.5 * -1 + 99 obviously isn't the desired 99.5.

Please review.

Christoph
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

>From 0214363d8bfc1084b93f4c2541c483313caafbc4 Mon Sep 17 00:00:00 2001
From: Christoph Bumiller 
Date: Tue, 19 Apr 2011 11:54:41 +0200
Subject: [PATCH] mesa,st/mesa: fix WPOS adjustment

---
 src/mesa/program/prog_statevars.c|4 ++--
 src/mesa/program/prog_statevars.h|2 +-
 src/mesa/state_tracker/st_mesa_to_tgsi.c |4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/program/prog_statevars.c 
b/src/mesa/program/prog_statevars.c
index 1fd26f4..d94d7fe 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -602,11 +602,11 @@ _mesa_fetch_state(struct gl_context *ctx, const 
gl_state_index state[],
 value[0] = 1.0F;
 value[1] = 0.0F;
 value[2] = -1.0F;
-value[3] = (GLfloat) (ctx->DrawBuffer->Height - 1);
+value[3] = (GLfloat) ctx->DrawBuffer->Height;
  } else {
 /* Flipping Y upside down (XY) followed by identity (ZW). */
 value[0] = -1.0F;
-value[1] = (GLfloat) (ctx->DrawBuffer->Height - 1);
+value[1] = (GLfloat) ctx->DrawBuffer->Height;
 value[2] = 1.0F;
 value[3] = 0.0F;
  }
diff --git a/src/mesa/program/prog_statevars.h 
b/src/mesa/program/prog_statevars.h
index 9fe8d81..04af3f4 100644
--- a/src/mesa/program/prog_statevars.h
+++ b/src/mesa/program/prog_statevars.h
@@ -120,7 +120,7 @@ typedef enum gl_state_index_ {
STATE_PT_BIAS,   /**< Pixel transfer RGBA bias */
STATE_SHADOW_AMBIENT,/**< ARB_shadow_ambient fail value; token[2] 
is texture unit index */
STATE_FB_SIZE,   /**< (width-1, height-1, 0, 0) */
-   STATE_FB_WPOS_Y_TRANSFORM,   /**< (1, 0, -1, height-1) if a FBO is bound, 
(-1, height-1, 1, 0) otherwise */
+   STATE_FB_WPOS_Y_TRANSFORM,   /**< (1, 0, -1, height) if a FBO is bound, 
(-1, height, 1, 0) otherwise */
STATE_ROT_MATRIX_0,  /**< ATI_envmap_bumpmap, rot matrix row 0 */
STATE_ROT_MATRIX_1,  /**< ATI_envmap_bumpmap, rot matrix row 1 */
STATE_INTERNAL_DRIVER   /* first available state index for drivers 
(must be last) */
diff --git a/src/mesa/state_tracker/st_mesa_to_tgsi.c 
b/src/mesa/state_tracker/st_mesa_to_tgsi.c
index c07739f..21c5c82 100644
--- a/src/mesa/state_tracker/st_mesa_to_tgsi.c
+++ b/src/mesa/state_tracker/st_mesa_to_tgsi.c
@@ -883,7 +883,7 @@ emit_wpos(struct st_context *st,
  ureg_property_fs_coord_pixel_center(ureg, 
TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
   else if (pscreen->get_param(pscreen, 
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER))
  /* the driver supports pixel center half integer, need to bias X,Y */
- emit_adjusted_wpos(t, program, 0.5f, invert ? 0.5f : -0.5f);
+ emit_adjusted_wpos(t, program, -0.5f, -0.5f);
   else
  assert(0);
}
@@ -895,7 +895,7 @@ emit_wpos(struct st_context *st,
   else if (pscreen->get_param(pscreen, 
PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER)) {
  /* the driver supports pixel center integer, need to bias X,Y */
  ureg_property_fs_coord_pixel_center(ureg, 
TGSI_FS_COORD_PIXEL_CENTER_INTEGER);
- emit_adjusted_wpos(t, program, 0.5f, invert ? -0.5f : 0.5f);
+ emit_adjusted_wpos(t, program, 0.5f, 0.5f);
   }
   else
  assert(0);
-- 
1.7.3.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r200: enable EXT_gpu_program_parameters

[Nicolas Kaiser]

* Ian Romanick :
> > ./src/demos/vao_demo
> > GL_RENDERER = Mesa DRI R200 (R200 514D)  TCL DRI2
> > GL_VERSION = 1.3 Mesa 7.11-devel (git-4ee40c3)  
> 
> Do we have VAO (either ARB or APPLE) in piglit?  That would actually be
> a more interesting test.   The Mesa demos exercise extensions pretty
> minimally in most cases.

I found two piglit tests, general/vao-01 and general/vao-02.

./piglit-run.py -t vao tests/all.tests results/vao.results

With Marek's patch, they pass:

./piglit-run.py -t vao tests/all.tests results/vao.enabled.results
./piglit-summary-html.py summary/compare.vao results/vao.results 
results/vao.enabled.results

vao.results vao.enabled.results

All 0/0 2/2
general 0/0 2/2
vao-01  skippass
vao-02  skippass


Best regards,
Nicolas Kaiser
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] Big endian support for RV730 (Gallium r600g)

[Michel Dänzer]

[ Moving to the mesa-dev list ]

On Fre, 2011-04-15 at 18:20 +0200, Cédric Cano wrote: 
> 
> Here you are a patch that adds big endian support for rv730 in r600 
> gallium driver.
> 
> I used the mesa-demos to test the driver status on big endian platform. 
> Except with demos using accumulation buffer, the rendering is the same 
> as on Intel platform. Albeit there are still some artefacts with some 
> demos.
> 
> I manage to fix accumulation buffer demos but then, glReadPixels demos 
> won't work. I still can figure out (like with r600c) what and when I 
> must enable swap. It will depends on object's domains. That's what I 
> tried to do in r600_cb and r600_create_sampler_view.

That's probably because it hasn't been fully thought through yet how to
deal with big endian CPUs vs. little endian GPUs in Gallium. When this
was discussed previously, the basic rule decided was that all data
passed across the Gallium driver interface was supposed to be little
endian. That should probably be feasible in general for at least
'standard' pixel formats, but I'm afraid it doesn't really work for
vertex data[0], which could be fed from the application (which will use
CPU native byte order) to the GPU more or less directly.

Maybe byte order should be handled explicitly by the Gallium format
definitions, and then it would be up to the state tracker to use the
appropriate byte order formats. José, have you had any further thoughts
on this?

[0] Though there might also be ambiguities e.g. with multi-byte
component pixel formats: Does the little endian rule apply to the pixel
value as a whole, or only for each component? 


> @@ -266,11 +268,31 @@ void r600_upload_const_buffer(struct r600_pipe_context 
> *rctx, struct r600_resour
> uint8_t *ptr = (*rbuffer)->r.b.user_ptr;
> unsigned size = (*rbuffer)->r.b.b.b.width0;
> boolean flushed;
> +#ifdef PIPE_ARCH_BIG_ENDIAN
> +   int i;
> +   uint32_t *tmpPtr;
> +
> +   *rbuffer = NULL;
> +
> +   tmpPtr = (uint32_t *)malloc(size);
> +   /* big endian swap */
> +   if(tmpPtr == NULL) {
> +   return;
> +   }
> +   for(i = 0; i < size / 4; i++) {
> +   tmpPtr[i] = bswap_32(*((uint32_t *)ptr + i));
> +   }
> +   
> +   u_upload_data(rctx->vbuf_mgr->uploader, 0, size, tmpPtr, 
> const_offset,
> + (struct pipe_resource**)rbuffer, &flushed);

Might be better to add a helper like u_upload_data_to_le32().


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36384] New: configure tips

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36384

   Summary: configure tips
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: fabio@libero.it


1) what about renaming swrastg_dri.so to swrast_dri.so so that it is consistent
with the other gallium drivers (r300/r600) and one doesn't need to rename it
when installing? It is already clear it's a gallium driver since it's inside
lib/gallium.

2) --enable-gallium-radeon should probably be changed to --enable-gallium-r300:
  --enable-gallium-r300   build gallium r300 [default=disabled]

3) this should say 'build gallium r600':
  --enable-gallium-r600   build gallium radeon [default=disabled]

(Even better the gallium drivers should be enabled with something similar to
--with-dri-drivers="..." )

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms

[Cédric Cano]

Signed-off-by: Cedric Cano
---
diff --git a/src/gallium/drivers/r600/r600_asm.c 
b/src/gallium/drivers/r600/r600_asm.c

index c22bd8e..7e854b1 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -22,6 +22,7 @@
  */
 #include 
 #include 
+#include 
 #include "util/u_format.h"
 #include "util/u_memory.h"
 #include "pipe/p_shader_tokens.h"
@@ -32,6 +33,12 @@
 #include "r600_formats.h"
 #include "r600d.h"

+#ifdef PIPE_ARCH_BIG_ENDIAN
+#define CPU_TO_LE32(x)bswap_32(x)
+#else
+#define CPU_TO_LE32(x)(x)
+#endif
+
 #define NUM_OF_CYCLES 3
 #define NUM_OF_COMPONENTS 4

@@ -1383,6 +1390,7 @@ static int r600_bc_vtx_build(struct r600_bc *bc, 
struct r600_bc_vtx *vtx, unsign

 S_SQ_VTX_WORD1_SRF_MODE_ALL(vtx->srf_mode_all) |
 S_SQ_VTX_WORD1_GPR_DST_GPR(vtx->dst_gpr);
 bc->bytecode[id++] = S_SQ_VTX_WORD2_OFFSET(vtx->offset) |
+   S_SQ_VTX_WORD2_ENDIAN_SWAP(vtx->endian) |
 S_SQ_VTX_WORD2_MEGA_FETCH(1);
 bc->bytecode[id++] = 0;
 return 0;
@@ -1917,6 +1925,7 @@ void r600_bc_dump(struct r600_bc *bc)
 fprintf(stderr, "MODE:%d)\n", vtx->srf_mode_all);
 id++;
 fprintf(stderr, "%04d %08X   ", id, bc->bytecode[id]);
+fprintf(stderr, "ENDIAN:%d ", vtx->endian);
 fprintf(stderr, "OFFSET:%d\n", vtx->offset);
 //TODO
 id++;
@@ -1929,7 +1938,7 @@ void r600_bc_dump(struct r600_bc *bc)
 }

 static void r600_vertex_data_type(enum pipe_format pformat, unsigned 
*format,

-unsigned *num_format, unsigned *format_comp)
+unsigned *num_format, unsigned *format_comp, unsigned 
*endian)

 {
 const struct util_format_description *desc;
 unsigned i;
@@ -1937,6 +1946,7 @@ static void r600_vertex_data_type(enum pipe_format 
pformat, unsigned *format,

 *format = 0;
 *num_format = 0;
 *format_comp = 0;
+*endian = ENDIAN_NONE;

 desc = util_format_description(pformat);
 if (desc->layout != UTIL_FORMAT_LAYOUT_PLAIN) {
@@ -1967,6 +1977,9 @@ static void r600_vertex_data_type(enum pipe_format 
pformat, unsigned *format,

 *format = FMT_16_16_16_16_FLOAT;
 break;
 }
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN16;
+#endif
 break;
 case 32:
 switch (desc->nr_channels) {
@@ -1983,6 +1996,9 @@ static void r600_vertex_data_type(enum pipe_format 
pformat, unsigned *format,

 *format = FMT_32_32_32_32_FLOAT;
 break;
 }
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN32;
+#endif
 break;
 default:
 goto out_unknown;
@@ -2020,6 +2036,9 @@ static void r600_vertex_data_type(enum pipe_format 
pformat, unsigned *format,

 *format = FMT_16_16_16_16;
 break;
 }
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN16;
+#endif
 break;
 case 32:
 switch (desc->nr_channels) {
@@ -2036,6 +2055,9 @@ static void r600_vertex_data_type(enum pipe_format 
pformat, unsigned *format,

 *format = FMT_32_32_32_32;
 break;
 }
+#ifdef PIPE_ARCH_BIG_ENDIAN
+*endian = ENDIAN_8IN32;
+#endif
 break;
 default:
 goto out_unknown;
@@ -2067,7 +2089,7 @@ int r600_vertex_elements_build_fetch_shader(struct 
r600_pipe_context *rctx, stru

 struct pipe_vertex_element *elements = ve->elements;
 const struct util_format_description *desc;
 unsigned fetch_resource_start = rctx->family >= CHIP_CEDAR ? 0 : 160;
-unsigned format, num_format, format_comp;
+unsigned format, num_format, format_comp, endian;
 u32 *bytecode;
 int i, r;

@@ -2114,7 +2136,7 @@ int r600_vertex_elements_build_fetch_shader(struct 
r600_pipe_context *rctx, stru


 for (i = 0; i < ve->count; i++) {
 unsigned vbuffer_index;
-r600_vertex_data_type(ve->elements[i].src_format, &format, 
&num_format, &format_comp);
+r600_vertex_data_type(ve->elements[i].src_format, &format, 
&num_format, &format_comp, &endian);

 desc = util_format_description(ve->elements[i].src_format);
 if (desc == NULL) {
 r600_bc_clear(&bc);
@@ -2140,6 +2162,7 @@ int r600_vertex_elements_build_fetch_shader(struct 
r600_pipe_context *rctx, stru

 vtx.format_comp_all = format_comp;
 vtx.srf_mode_all = 1;
 vtx.offset = elements[i].src_offset;
+vtx.endian = endian;

 if ((r = r600_bc_add_vtx(&bc, &vtx))) {
 r600_bc_clear(&bc);
@@ -2179,7 +2202,9 @@ int r600_vertex_elements_build_fetch_shader(struct 
r600_pipe_context *rctx, stru

 return -ENOMEM;
 }

-memcpy(bytecode, bc.bytecode, ve->fs_size);
+for(i = 0; i < ve->fs_size / 4; i++) {
+*(bytecode + i) = CPU_TO_LE32(*(bc.bytecode + i));
+   

Re: [Mesa-dev] [PATCH] RV730 support for Big Endian platforms

[Cédric Cano]

Signed-off-by: Cedric Cano
---
diff -Naur Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h 
Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h
--- Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h 2010-02-05 
01:10:40.0 +0100
+++ Mesa-7.10/src/mesa/drivers/dri/r600/defaultendian.h 2011-04-07 
16:19:50.0 +0200
@@ -29,8 +29,8 @@
 #define _DEFINEENDIAN_H_

 //We have to choose a reg bits orientation if there is no compile flag for it.
-#if defined(LITTLEENDIAN_CPU)
-#elif defined(BIGENDIAN_CPU)
+#ifdef MESA_BIG_ENDIAN
+#define BIGENDIAN_CPU
 #else
 #define LITTLEENDIAN_CPU
 #endif
diff -Naur Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c 
Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c
--- Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c 2010-12-14 
22:43:15.0 +0100
+++ Mesa-7.10/src/mesa/drivers/dri/r600/r600_blit.c 2011-04-11 
16:43:40.0 +0200
@@ -94,17 +94,17 @@
 {
 uint32_t cb_color0_base, cb_color0_size = 0, cb_color0_info = 0, 
cb_color0_view = 0;
 int id = 0;
-uint32_t comp_swap, format;
+uint32_t endian, comp_swap, format;
 BATCH_LOCALS(&context->radeon);

 cb_color0_base = dst_offset / 256;
+   endian = ENDIAN_NONE;

 SETfield(cb_color0_size, (nPitchInPixel / 8) - 1,
  PITCH_TILE_MAX_shift, PITCH_TILE_MAX_mask);
 SETfield(cb_color0_size, ((nPitchInPixel * h) / 64) - 1,
  SLICE_TILE_MAX_shift, SLICE_TILE_MAX_mask);

-SETfield(cb_color0_info, ENDIAN_NONE, ENDIAN_shift, ENDIAN_mask);
 SETfield(cb_color0_info, ARRAY_LINEAR_GENERAL,
  CB_COLOR0_INFO__ARRAY_MODE_shift, 
CB_COLOR0_INFO__ARRAY_MODE_mask);

@@ -112,24 +112,36 @@

 switch(mesa_format) {
 case MESA_FORMAT_RGBA:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN32;
+#endif
 format = COLOR_8_8_8_8;
 comp_swap = SWAP_STD_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift, 
NUMBER_TYPE_mask);
 break;
 case MESA_FORMAT_SIGNED_RGBA:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN32;
+#endif
 format = COLOR_8_8_8_8;
 comp_swap = SWAP_STD_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_SNORM, NUMBER_TYPE_shift, 
NUMBER_TYPE_mask);
 break;
 case MESA_FORMAT_RGBA_REV:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN32;
+#endif
 format = COLOR_8_8_8_8;
 comp_swap = SWAP_STD;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift, 
NUMBER_TYPE_mask);
 break;
 case MESA_FORMAT_SIGNED_RGBA_REV:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN32;
+#endif
 format = COLOR_8_8_8_8;
 comp_swap = SWAP_STD;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
@@ -137,6 +149,9 @@
 break;
 case MESA_FORMAT_ARGB:
 case MESA_FORMAT_XRGB:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN32;
+#endif
 format = COLOR_8_8_8_8;
 comp_swap = SWAP_ALT;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
@@ -144,54 +159,81 @@
 break;
 case MESA_FORMAT_ARGB_REV:
 case MESA_FORMAT_XRGB_REV:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN32;
+#endif
 format = COLOR_8_8_8_8;
 comp_swap = SWAP_ALT_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift, 
NUMBER_TYPE_mask);
 break;
 case MESA_FORMAT_RGB565:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN16;
+#endif
+   comp_swap = SWAP_STD_REV;   
 format = COLOR_5_6_5;
-comp_swap = SWAP_STD_REV;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift, 
NUMBER_TYPE_mask);
 break;
 case MESA_FORMAT_RGB565_REV:
-format = COLOR_5_6_5;
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN16;
+#endif
 comp_swap = SWAP_STD;
+format = COLOR_5_6_5;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift, 
NUMBER_TYPE_mask);
 break;
 case MESA_FORMAT_ARGB:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN16;
+#endif
 format = COLOR_4_4_4_4;
 comp_swap = SWAP_ALT;
SETbit(cb_color0_info, SOURCE_FORMAT_bit);
SETfield(cb_color0_info, NUMBER_UNORM, NUMBER_TYPE_shift, 
NUMBER_TYPE_mask);
 break;
 case MESA_FORMAT_ARGB_REV:
+#ifdef MESA_BIG_ENDIAN
+   endian = ENDIAN_8IN16;
+

[Mesa-dev] [PATCH] RV730 support for Big Endian platforms

[Cédric Cano]

Hi

Few days ago, I posted a couple of patches on dri-devel but it doesn't 
seem to be the correct place. Here you are 2 patches that adds support 
for RV730 in r600c and r600g.


More details are available here :
http://lists.freedesktop.org/archives/dri-devel/2011-April/010056.html
http://lists.freedesktop.org/archives/dri-devel/2011-April/010281.html

Regards,
Cedric
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36282] 34a5d3b9f4740601708c82093e2114356d749e65: glxgears segfaults (swrast, r600g, nouveau_vieux)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36282

Marc  changed:

   What|Removed |Added

 CC||marvi...@gmx.de

--- Comment #11 from Marc  2011-04-19 01:40:14 PDT ---
only happens here when shared-glapi is enabled (r600g)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] libxml2 (python) dependency

[Corbin Simpson]

On Mon, Apr 18, 2011 at 4:48 PM, tom fogal  wrote:
> Hey all,
>
> We recently became more aware of a dependency on python's libxml2 for
> building Mesa.  We're not as proactive as we should be, but tend to upgrade
> Mesa every few releases; I think this was a jump from 7.8 to 7.10.
>
> Anyway, libxml2 is a bit arduous for us because it's not installed by
> default on Linux or Mac.  On Linux, it's easy to grab via a package manager,
> but still does not exist by default on some distros.  In general,
> non-standard dependencies are difficult because they make our (already very
> large) software stack more complex.
>
> Is the package truly needed?  I think it's used to parse spec files and
> autogenerate trampolines or callbacks or something like that.  Didn't we
> used to have plain text files for that?  Any reason we can't go back to
> something simpler?  Does code speak loud than words, here? :)

Python comes with three or four different XML parsers, and of those,
etree is both relatively speedy and sane. Certainly easier to handle
than libxml2 directly. If people want it to be even speedier, there's
a libxml2 library for Python, lxml, which has the etree API and is
quite nice.

This has been on my TODO list for a year or so, but no real useful
work has been made. Knowing that people actually care about it gives
me some incentive, but I can't promise anything.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36295] Incorrect rendering in SPECviewperf benchmark

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36295

--- Comment #14 from José Fonseca  2011-04-19 00:19:54 PDT 
---
(In reply to comment #13)
> The downside is that app developers never fix *THEIR* bugs.
> 
[...]
>
> And this is the disaster that we're trying to fix via conformance testing. 
> This crap has to STOP.  This is why people think OpenGL is joke.

(This is slightly OT, but I'd argue that the OpenGL problem is not that spec
conformance per se, but the proliferation of vendor specific extensions, and
extensions in general; and the fix is not conformance testing but the ARB
ratifying the extensions people care and lumping extensions in core versions.
It looks things are moving on the right direction. That said, latest core
version is 4.0 and we're still in 2.1, so I'm thankful for extensions that get
us half way there.)

Anyway, Ian, I see you strongly feel against the proposed patch, but I still am
not sure exactly what you oppose: diverging the spec, or adding the extensions
to meet an application's requirement? That is, would fully implementing
NV_fragment_program2 to the spec and advertising it for SPECviewperf11's sake
be OK with you or not, and why?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 36341] Mesa can't find ubuntu llvm

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36341

Fabio Pedretti  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #4 from Fabio Pedretti  2011-04-19 00:15:49 
PDT ---
(In reply to comment #3)
> Have you installed "llvm" package? It provides llvm-config (without suffix) 
> and
> others as symlinks to llvm-2.8 versions on my ubuntu system.

You are right here. Strange however that llvm-dev doesn't depend on it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] r128: fix lockups (bug #9379)

[Christopher Egert]

Hi,
I found this patch by Andrew Péteri on the bugtracker (#9379), it seems
like it's still incomplete (projective textures were disabled), but it
fixes a lockup problems with r128 (like the game cube, some farbrausch
demos and gta vice city in wine (not very fast but meh) works now).

--- a/src/mesa/drivers/dri/r128/r128_span.c 2009-01-22
18:38:33.0 +0100
+++ b/src/mesa/drivers/dri/r128/r128_span.c 2009-04-19
13:24:48.0 +0200
@@ -122,12 +122,6 @@
  * Depth buffer
  */
 
-/* These functions require locking */
-#undef HW_LOCK
-#undef HW_UNLOCK
-#define HW_LOCK()LOCK_HARDWARE(R128_CONTEXT(ctx));
-#define HW_UNLOCK()  UNLOCK_HARDWARE(R128_CONTEXT(ctx));
-
 /* 16-bit depth buffer functions
  */
 #define VALUE_TYPE GLushort

--- a/src/mesa/drivers/dri/r128/r128_tris.c 2009-01-22
18:38:33.0 +0100
+++ b/src/mesa/drivers/dri/r128/r128_tris.c 2009-04-18
19:31:36.0 +0200
@@ -48,6 +48,7 @@
 #include "r128_state.h"
 #include "r128_tex.h"
 #include "r128_ioctl.h"
+#include "r128_lock.h"
 
 static const GLuint hw_prim[GL_POLYGON+1] = {
R128_CCE_VC_CNTL_PRIM_TYPE_POINT,
@@ -349,7 +350,9 @@
_swsetup_Translate( ctx, v0, &v[0] );
_swsetup_Translate( ctx, v1, &v[1] );
_swsetup_Translate( ctx, v2, &v[2] );
+   LOCK_HARDWARE( rmesa );
_swrast_Triangle( ctx, &v[0], &v[1], &v[2] );
+   UNLOCK_HARDWARE( rmesa );
 }
 
 
@@ -362,7 +365,9 @@
SWvertex v[2];
_swsetup_Translate( ctx, v0, &v[0] );
_swsetup_Translate( ctx, v1, &v[1] );
+   LOCK_HARDWARE( rmesa );
_swrast_Line( ctx, &v[0], &v[1] );
+   UNLOCK_HARDWARE( rmesa );
 }
 
 
@@ -373,7 +378,9 @@
GLcontext *ctx = rmesa->glCtx;
SWvertex v[1];
_swsetup_Translate( ctx, v0, &v[0] );
+   LOCK_HARDWARE( rmesa );
_swrast_Point( ctx, &v[0] );
+   UNLOCK_HARDWARE( rmesa );   
 }
 
 
@@ -661,7 +668,12 @@
}
 
/* projectivetextur es are not supported by the hardware */
-   FALLBACK( rmesa, R128_FALLBACK_PROJTEX, fallback_projtex );
+   // FALLBACK( rmesa, R128_FALLBACK_PROJTEX, fallback_projtex );
+   //
+   // if (fallback_projtex) {
+   // tnl->Driver.Render.Start(ctx);
+   // return;
+   // }
 
/* Only need to change the vertex emit code if there has been a
 * statechange to a TNL index.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev