Re: [Mesa-dev] [PATCH] glcpp: Rewrite line-continuation support to act globally.

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 03:20 PM, Carl Worth wrote:

Kenneth Graunke  writes:

Other than than, looks good to me...thanks Carl!

Reviewed-by: Kenneth Graunke 


Thanks, Ken. Pushed now.


Someday we may want to use ralloc's rewrite_tail functions to avoid the
extra strlen() overhead.  But that can be done separately.


I took a look at this now. It looks like there are only rewrite_tail
variants of ralloc_asprintf, which feel heavy here. I'd prefer a variant
of ralloc_strcat that would give the better efficiency, (and the
documentation of ralloc_strcat could then point to the alternate
function).

Perhaps the new function could be named ralloc_rewrite_tail? Compared to
something like ralloc_strcat_rewrite_tail that would be a less awkward
name, and would also avoid suggesting that the new string is always
appended to the end, (in the case where the passed length is shorter
than the current string's length).


Yeah, I'm definitely in favor of creating a ralloc_rewrite_tail function.

I almost added them when I reworked the preprocessor, but a bunch of the 
calls needed printf-like functionality anyway, so I decided just to use 
it everywhere and put off making a new function.



The only naming question left after that would be what to name the
tail-rewriting variant of ralloc_strncat?

-Carl


Sadly, that is the trickiest part :)  I do like "ralloc_rewrite_tail", 
as it's simple and feels natural.  It doesn't mention strings, but I 
don't think it needs to.


Going with that, perhaps ralloc_rewrite_tail_n()?

Another alternative would be ralloc_strn_rewrite_tail(). That seems 
fairly clear (the "strn" concept is familiar, and can be pronounced 
"stern"...), but it almost begs for ralloc_str_rewrite_tail() for 
consistency.  And that doesn't roll off the tongue as well.


I'm pretty tempted by ralloc_rewrite_tail & ralloc_strn_rewrite_tail.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 17/26] glsl: Record in gl_shader_program whether the program uses GLSL ES.

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 03:20 PM, Eric Anholt wrote:

Ian Romanick  writes:


From: Paul Berry 

Previously we recorded just the GLSL version (or the max version, if
GLSL 1.10 and GLSL 1.20 programs were linked together).

Reviewed-by: Ian Romanick 
---
  src/glsl/linker.cpp| 1 +
  src/mesa/main/mtypes.h | 1 +
  2 files changed, 2 insertions(+)



diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index f364ae1..4e5be1f 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2387,6 +2387,7 @@ struct gl_shader_program
 GLchar *InfoLog;

 unsigned Version;   /**< GLSL version used for linking */
+   GLboolean IsEsProg; /**< True if this program uses GLSL ES */


I don't think I would ever type "Es" with a lowercase 's' on the first
try.  Am I alone?


That definitely is hard to type.  (And oh, wow, is it especially awkward 
in QWERTY...not nearly as bad in Dvorak.)


I still think "IsESProg" is hard to type...I usually end up with 
"IsESPRog" or "IsESPROg".


Other suggestions:
- "ES"
  (nice and short, super easy to type, maybe not the most clear)
- "IsES" or "IsEs"
  (the "Prog" part doesn't really add/clarify anything; we're already
   working with a gl_shader_program.  Capitalization is still hard.)
- "ESProgram"
  (decent to capitalize & type as there's no back-and-forth...)

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

Re: [Mesa-dev] Proposal: allow hidden security bugs on Mesa's Bugzilla

2012-12-01 Thread Benoit Jacob 
On 12-11-30 06:46 PM, Brian Paul wrote:
> On 11/30/2012 01:16 PM, Benoit Jacob wrote:
>> On 12-11-30 12:13 PM, Jerome Glisse wrote:
>>> On Fri, Nov 30, 2012 at 7:43 AM, Benoit Jacob 
>>> wrote:
 On 12-11-23 02:21 PM, Benoit Jacob wrote:
> On 12-11-21 12:48 PM, Chad Versace wrote:
>> On 11/20/2012 09:29 AM, Benoit Jacob wrote:
>>
>>> Any questions?
>>> Do you support or oppose me asking FD.o admins to allow hidden
>>> bugs on
>>> Mesa's bugzilla?
>>>
>>> Benoit
>> I support this. It seems a sensible proposal for addressing
>> security bugs.
>>
> Thanks. I have just sent the request to FD.o admins.
>
> Benoit
 This option is now turned on on Bugzilla.

 See the new checkbox: "Mesa Security Group"

 Thanks!
 Benoit

>>> How does one get into the security group ?
>>
>> Don't ask me --- obviously I amn't part of it. I suppose you should have
>> that conversation among core Mesa developers and FD.o admins.
>
> It sounds like we want to have a mesa-security mailing list to receive
> the bugzilla messages for the hidden/security bugs.  Whoever's on that
> list should have access to the bugs.  I'm not sure what the fd.o
> admins need to set that up.
>
> Benoit, did you create a bugzilla request for a mesa-security list? If
> not, would you mind doing that?

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

Benoit
>
> -Brian

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

Re: [Mesa-dev] [PATCH] gallivm: drop border wrap clamping code

2012-12-01 Thread Brian Paul 

On 11/30/2012 12:49 PM, srol...@vmware.com wrote:

From: Roland Scheidegger

The border clamping code is unnecessary, since we don't care if a wrapped
coord value is -1 or<-1 (same for length vs.>length), in either case the
border handling code will mask out the offset and replace the texel value with
the border color.
Note that technically this is not entirely correct. Omitting clamping on the
float coords means that flt->int conversion may result in undefined values for
values of very large magnitude.
However there's no reason we should honor this here since:
a) we don't care for that for ordinary wrap modes in the aos code when
converting coords and the problem is worse there (as we've got only
effectively 24 instead of 32bits)
b) at least in some cases the clamping was done already in int space hence
doing nothing to fix that problem.
c) with sse2 flt->int conversion with such values results in 0x8000 which
is just perfect (for clamp to border - not so much for the ordinary clamp to
edge).
---
  src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c |   49 +++--
  1 file changed, 16 insertions(+), 33 deletions(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c 
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index 659de9b..ba265b2 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -351,20 +351,16 @@ lp_build_sample_wrap_linear(struct 
lp_build_sample_context *bld,
}

 case PIPE_TEX_WRAP_CLAMP_TO_BORDER:
-  {
- LLVMValueRef min;
- if (bld->static_state->normalized_coords) {
-/* scale coord to length */
-coord = lp_build_mul(coord_bld, coord, length_f);
- }
- /* was: clamp to [-0.5, length + 0.5], then sub 0.5 */
- coord = lp_build_sub(coord_bld, coord, half);
- min = lp_build_const_vec(bld->gallivm, coord_bld->type, -1.0F);
- coord = lp_build_clamp(coord_bld, coord, min, length_f);
- /* convert to int, compute lerp weight */
- lp_build_ifloor_fract(coord_bld, coord,&coord0,&weight);
- coord1 = lp_build_add(int_coord_bld, coord0, int_coord_bld->one);
+  if (bld->static_state->normalized_coords) {
+ /* scale coord to length */
+ coord = lp_build_mul(coord_bld, coord, length_f);
}
+  /* was: clamp to [-0.5, length + 0.5], then sub 0.5 */
+  /* can skip clamp (though might not work for very large coord values */
+  coord = lp_build_sub(coord_bld, coord, half);
+  /* convert to int, compute lerp weight */
+  lp_build_ifloor_fract(coord_bld, coord,&coord0,&weight);
+  coord1 = lp_build_add(int_coord_bld, coord0, int_coord_bld->one);
break;

 case PIPE_TEX_WRAP_MIRROR_REPEAT:
@@ -438,9 +434,9 @@ lp_build_sample_wrap_linear(struct lp_build_sample_context 
*bld,
   }

   /* was: clamp to [-0.5, length + 0.5] then sub 0.5 */
- /* skip -0.5 clamp (always positive), do sub first */
+ /* skip clamp - always positive, and other side
+only potentially matters for very large coords */
   coord = lp_build_sub(coord_bld, coord, half);
- coord = lp_build_min(coord_bld, coord, length_f);

   /* convert to int, compute lerp weight */
   lp_build_ifloor_fract(coord_bld, coord,&coord0,&weight);
@@ -514,22 +510,12 @@ lp_build_sample_wrap_nearest(struct 
lp_build_sample_context *bld,
break;

 case PIPE_TEX_WRAP_CLAMP_TO_BORDER:
-  /* Note: this is the same as CLAMP_TO_EDGE, except min = -1 */
-  {
- LLVMValueRef min, max;
-
- if (bld->static_state->normalized_coords) {
-/* scale coord to length */
-coord = lp_build_mul(coord_bld, coord, length_f);
- }
-
- icoord = lp_build_ifloor(coord_bld, coord);
-
- /* clamp to [-1, length] */
- min = lp_build_negate(int_coord_bld, int_coord_bld->one);
- max = length;
- icoord = lp_build_clamp(int_coord_bld, icoord, min, max);
+  if (bld->static_state->normalized_coords) {
+ /* scale coord to length */
+ coord = lp_build_mul(coord_bld, coord, length_f);
}
+  /* no clamp necessary, border masking will handle this */
+  icoord = lp_build_ifloor(coord_bld, coord);
break;

 case PIPE_TEX_WRAP_MIRROR_REPEAT:
@@ -573,9 +559,6 @@ lp_build_sample_wrap_nearest(struct lp_build_sample_context 
*bld,

/* itrunc == ifloor here */
icoord = lp_build_itrunc(coord_bld, coord);
-
-  /* clamp to [0, length] */
-  icoord = lp_build_min(int_coord_bld, icoord, length);
break;

 default:


Nice!

Reviewed-by: Brian Paul 

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

[Mesa-dev] [Bug 57746] build test failure: nouveau_fbo.c:198:3: error: too few arguments to function 'nouveau_renderbuffer_del'

2012-12-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=57746

Vinson Lee  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Vinson Lee  ---
commit a17750b6884939a36947c76a30d3077f1488f943
Author: Brian Paul 
Date:   Fri Nov 30 19:11:21 2012 -0800

nouveau: Fix build.

Fixes nouveau build failure introduced at
c73245882c7ff1277b190b97f093f7b423a22f10.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57746
Signed-off-by: Vinson Lee 

-- 
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] Proposal: allow hidden security bugs on Mesa's Bugzilla

2012-12-01 Thread Brian Paul 

On 11/30/2012 01:16 PM, Benoit Jacob wrote:

On 12-11-30 12:13 PM, Jerome Glisse wrote:

On Fri, Nov 30, 2012 at 7:43 AM, Benoit Jacob  wrote:

On 12-11-23 02:21 PM, Benoit Jacob wrote:

On 12-11-21 12:48 PM, Chad Versace wrote:

On 11/20/2012 09:29 AM, Benoit Jacob wrote:


Any questions?
Do you support or oppose me asking FD.o admins to allow hidden bugs on
Mesa's bugzilla?

Benoit

I support this. It seems a sensible proposal for addressing security bugs.


Thanks. I have just sent the request to FD.o admins.

Benoit

This option is now turned on on Bugzilla.

See the new checkbox: "Mesa Security Group"

Thanks!
Benoit


How does one get into the security group ?


Don't ask me --- obviously I amn't part of it. I suppose you should have
that conversation among core Mesa developers and FD.o admins.


It sounds like we want to have a mesa-security mailing list to receive 
the bugzilla messages for the hidden/security bugs.  Whoever's on that 
list should have access to the bugs.  I'm not sure what the fd.o 
admins need to set that up.


Benoit, did you create a bugzilla request for a mesa-security list? 
If not, would you mind doing that?


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

Re: [Mesa-dev] [PATCH 2/4] glx/dri2: add and use new driver hook flush_with_flags

2012-12-01 Thread Marek Olšák 
On Fri, Nov 30, 2012 at 11:40 PM, Eric Anholt  wrote:
> The mixing of the factoring out of the protocol bits with the flush
> change in this commit is irritating, but I'm fine with the overall flush

Ah, sorry, I based it on my previous series and didn't notice it was
superfluous.

> interface of this series for the current loader implementation.
>
> Long term, I think for what you're working towards you'll want the
> dispatch threading that Paul has been working on, and dri.next for
> communicating swaps to the server, then push the whole swapbuffers
> request out of the loader and into that thread.  At that point, all this
> flush interface would be replaced with the swap request to the driver.

I would prefer if the driver didn't have to implement the swap. My
previous series had a more generic interface:

void flush_with_flags(, void (*finish)(void *data), void *data);

The driver would then call the "finish" callback in the driver thread
once the flushing is done. In this case, finish would be
dri2XcbSwapBuffers and data would be its parameters. There was also
the function void sync(__DRIcontext*) in case we wanted to wait until
the finish callback is done, so that we can e.g. safely destroy the
drawable or read the swap reply.

Marek


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

[Mesa-dev] [Bug 57756] New: [llvmpipe] piglit arb_sampler_objects-srgb-decode regression

2012-12-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=57756

  Priority: medium
Bug ID: 57756
CC: jfons...@vmware.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [llvmpipe] piglit arb_sampler_objects-srgb-decode
regression
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: da7029dcb498f80d1837323038617b49cc28431f (master)

Run piglit arb_sampler_objects-srgb-decode on llvmpipe.

$ ./bin/arb_sampler_objects-srgb-decode -auto
Probe at (0,0)
  Expected: 0.033105 0.132868 0.318547 0.80
  Observed: 0.20 0.40 0.60 0.80
Probe at (0,8)
  Expected: 0.033105 0.132868 0.318547 0.80
  Observed: 0.20 0.40 0.60 0.80
PIGLIT: {'result': 'fail' }

9f06061d50f90bf425a5337cea1b0adb94a46d25 is the first bad commit
commit 9f06061d50f90bf425a5337cea1b0adb94a46d25
Author: José Fonseca 
Date:   Wed Nov 28 19:20:18 2012 +

util/u_format: Kill util_format_is_array().

It is buggy (it was giving wrong results for some of the formats with
padding), and util_format_description::is_array already does precisely
what's intended.

Reviewed-by: Roland Scheidegger 

:04 04 acbb7501279a631c0f3e26c21f98e493fc23d551
23f59be31e2e9bdcc534e2745f050593bce2 M  src
bisect run success

-- 
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 16/26] glsl: Clean up shading language mixing check for GLSL 3.00 ES.

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 10:07 AM, Ian Romanick wrote:

From: Paul Berry 

Previously, we prohibited mixing of shading language versions if
min_version == 100 or max_version >= 130.  This was technically
correct (since desktop GLSL 1.30 and beyond prohibit mixing of shading
language versions, as does GLSL 1.00 ES), but it was confusing.  Also,
we asserted that all shading language versions were between 1.00 and
1.40, which was unnecessary (since the parser already checks shading
language versions) and doesn't work for GLSL 3.00 ES.

This patch changes the code to explicitly check that (a) ES shaders
aren't mixed with desktop shaders, (b) shaders aren't mixed between ES
versions, and (c) shaders aren't mixed between desktop GLSL versions
when at least one shader is GLSL 1.30 or greater.  Also, it removes
the unnecessary assertion.

Reviewed-by: Ian Romanick 
---
  src/glsl/linker.cpp | 16 +---
  1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 3b2ab96..1bae043 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2421,9 +2421,19 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)

 unsigned min_version = UINT_MAX;
 unsigned max_version = 0;
+   bool is_es_prog = false;
 for (unsigned i = 0; i < prog->NumShaders; i++) {
min_version = MIN2(min_version, prog->Shaders[i]->Version);
max_version = MAX2(max_version, prog->Shaders[i]->Version);
+  if (i == 0) {
+ is_es_prog = prog->Shaders[i]->IsEsShader;
+  } else {


I really dislike loops that contain conditional code for particular 
indices.  It almost seems like you want:


bool is_es_prog = prog->Shaders[0]->IsEsShader;

then you can just omit this code within the loop.  Nice and clean.  The 
only trouble is that doing so assumes there is at least one shader.


I *believe* that calling glLinkProgram with no attached shaders is an 
error and should be rejected (oglconform claims it's invalid).  However, 
I can't find any spec text about it and I'm fairly sure we don't verify 
that NumShaders >= 1 when linking.


But it's not a big deal...just a pet peeve I picked up after reading 
code in another project which was essentially:

for (int i = 0; i < POUND_DEFINE_THAT_HAPPENS_TO_BE_THREE; i++) {
   if (i == 0) {...} else if (i == 1) {...} else if (i == 2) {...}
   /* seriously, why the hell did you make this a loop? */
}

Your code here is sensible and gets a R-b either way.


+ if (prog->Shaders[i]->IsEsShader != is_es_prog) {
+linker_error(prog, "all shaders must use same shading "
+ "language version\n");
+goto done;
+ }
+  }

switch (prog->Shaders[i]->Type) {
case GL_VERTEX_SHADER:
@@ -2444,10 +2454,10 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
 /* Previous to GLSL version 1.30, different compilation units could mix and
  * match shading language versions.  With GLSL 1.30 and later, the versions
  * of all shaders must match.
+*
+* GLSL ES has never allowed mixing of shading language versions.
  */
-   assert(min_version >= 100);
-   assert(max_version <= 140);
-   if ((max_version >= 130 || min_version == 100)
+   if ((is_es_prog || max_version >= 130)
 && min_version != max_version) {
linker_error(prog, "all shaders must use same shading "
   "language version\n");



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

[Mesa-dev] [Bug 57746] build test failure: nouveau_fbo.c:198:3: error: too few arguments to function 'nouveau_renderbuffer_del'

2012-12-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=57746

--- Comment #1 from Brian Paul  ---
Can you try this patch:


diff --git a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
b/src/mesa/drivers/dri/no
index c47bce8..156b4a3 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
+++ b/src/mesa/drivers/dri/nouveau/nouveau_fbo.c
@@ -195,7 +195,7 @@ nouveau_renderbuffer_dri_new(GLenum format, __DRIdrawable
*dr
rb->AllocStorage = nouveau_renderbuffer_dri_storage;

if (!set_renderbuffer_format(rb, format)) {
-   nouveau_renderbuffer_del(rb);
+   nouveau_renderbuffer_del(NULL, rb);
return NULL;
}

-- 
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 18/26] glsl: Fix linker checks for GLSL ES 3.00.

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 10:07 AM, Ian Romanick wrote:

From: Paul Berry 

This patch updates the following linker checks to do the right thing
in GLSL 3.00 ES:

- Failing to write to gl_Position is allowed in GLSL 1.40+ as well as
   GLSL 3.00 ES.

- It is an error to write to both gl_ClipVertex and gl_ClipDistance in
   GLSL 1.30+.  This does not apply to GLSL 3.00 ES.

- GLSL 3.00 ES uses the same varying counting rules as GLSL 1.00 ES.

- In GLSL 1.30 and GLSL 3.00 ES, "discard" terminates the shader.

- In GLSL 1.00 ES and GLSL 3.00 ES, both a fragment and a vertex
   shader must be present.

Reviewed-by: Ian Romanick 
---
  src/glsl/linker.cpp | 22 +++---
  1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index d74911f..e2cd625 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -289,8 +289,11 @@ validate_vertex_shader_executable(struct gl_shader_program 
*prog,
  *  operations, if present, that operate on primitives after
  *  vertex processing has occurred. Its value is undefined if
  *  the vertex shader executable does not write gl_Position."
+*
+* GLSL ES 3.00 is similar to GLSL 1.40--failing to write to gl_Position is
+* not an error.
  */
-   if (prog->Version < 140) {
+   if (prog->Version < (prog->IsEsProg ? 300 : 140)) {
find_assignment_visitor find("gl_Position");
find.run(shader->ir);
if (!find.variable_found()) {
@@ -301,12 +304,15 @@ validate_vertex_shader_executable(struct 
gl_shader_program *prog,

 prog->Vert.ClipDistanceArraySize = 0;

-   if (prog->Version >= 130) {
+   if (!prog->IsEsProg && prog->Version >= 130) {
/* From section 7.1 (Vertex Shader Special Variables) of the
 * GLSL 1.30 spec:
 *
 *   "It is an error for a shader to statically write both
 *   gl_ClipVertex and gl_ClipDistance."
+   *
+   * This does not apply to GLSL ES shaders, since GLSL ES defines neither
+   * gl_ClipVertex not gl_ClipDistance.
 */


Typo here: We want "neither...nor" rather than "neither...not".

Also, hooray for crippled APIs!


find_assignment_visitor clip_vertex("gl_ClipVertex");
find_assignment_visitor clip_distance("gl_ClipDistance");
@@ -2144,7 +2150,7 @@ assign_varying_locations(struct gl_context *ctx,
}
 }

-   if (ctx->API == API_OPENGLES2 || prog->Version == 100) {
+   if (ctx->API == API_OPENGLES2 || prog->IsEsProg) {
if (varying_vectors > ctx->Const.MaxVarying) {
   if (ctx->Const.GLSLSkipStrictMaxVaryingLimitCheck) {
  linker_warning(prog, "shader uses too many varying vectors "
@@ -2539,8 +2545,10 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
 /* Implement the GLSL 1.30+ rule for discard vs infinite loops Do
  * it before optimization because we want most of the checks to get
  * dropped thanks to constant propagation.
+*
+* This rule also applies to GLSL ES 3.00.
  */
-   if (max_version >= 130) {
+   if (max_version >= (is_es_prog ? 300 : 130)) {
struct gl_shader *sh = prog->_LinkedShaders[MESA_SHADER_FRAGMENT];
if (sh) {
 lower_discard_flow(sh->ir);
@@ -2684,11 +2692,11 @@ link_shaders(struct gl_context *ctx, struct 
gl_shader_program *prog)
goto done;

 /* OpenGL ES requires that a vertex shader and a fragment shader both be
-* present in a linked program.  By checking for use of shading language
-* version 1.00, we also catch the GL_ARB_ES2_compatibility case.
+* present in a linked program.  By checking prog->IsEsProg, we also
+* catch the GL_ARB_ES2_compatibility case.


Well.  GL_ARB_ES2/ES3_compatibility :)


  */
 if (!prog->InternalSeparateShader &&
-   (ctx->API == API_OPENGLES2 || prog->Version == 100)) {
+   (ctx->API == API_OPENGLES2 || prog->IsEsProg)) {
if (prog->_LinkedShaders[MESA_SHADER_VERTEX] == NULL) {
 linker_error(prog, "program lacks a vertex shader\n");
} else if (prog->_LinkedShaders[MESA_SHADER_FRAGMENT] == NULL) {


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

[Mesa-dev] [Bug 57755] New: [llvmpipe] src/gallium/auxiliary/gallivm/lp_bld_arit.c:1051:lp_build_lerp: Assertion `!type.sign' failed.

2012-12-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=57755

  Priority: medium
Bug ID: 57755
CC: jfons...@vmware.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [llvmpipe]
src/gallium/auxiliary/gallivm/lp_bld_arit.c:1051:lp_bu
ild_lerp: Assertion `!type.sign' failed.
  Severity: critical
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: f3476ec8fa5a94d469a12318c537b13ce9cc5a45 (master)

Run piglit fbo-blending-formats GL_EXT_texture_snorm on llvmpipe.

$ ./bin/fbo-blending-formats GL_EXT_texture_snorm -auto
Using test set: GL_EXT_texture_snorm
Testing GL_RED_SNORM
src/gallium/auxiliary/gallivm/lp_bld_arit.c:1051:lp_build_lerp: Assertion
`!type.sign' failed.
Trace/breakpoint trap (core dumped)


(gdb) bt
#0  0x7fc02c824f16 in _debug_assert_fail (expr=0x7fc02d1ea678 "!type.sign", 
file=0x7fc02d1e9f20 "src/gallium/auxiliary/gallivm/lp_bld_arit.c",
line=1051, 
function=0x7fc02d1eae86 <__FUNCTION__.9093> "lp_build_lerp") at
src/gallium/auxiliary/util/u_debug.c:278
#1  0x7fc02c89a4fe in lp_build_lerp (bld=0x7fffcd3d6130, x=0x26be8b8,
v0=0x26886a8, v1=0x2793ca8)
at src/gallium/auxiliary/gallivm/lp_bld_arit.c:1051
#2  0x7fc02c4ff3d1 in lp_build_blend (bld=0x7fffcd3d6130, func=0,
factor_src=7, factor_dst=23, src=0x2793ca8, 
dst=0x26886a8, src_factor=0x26be8b8, dst_factor=0x26fd4f0,
not_alpha_dependent=1 '\001', optimise_only=0 '\000')
at src/gallium/drivers/llvmpipe/lp_bld_blend.c:149
#3  0x7fc02c4f934c in lp_build_blend_aos (gallivm=0x2688f40,
blend=0x2676e8c, cbuf_format=0x2676ebc, type=..., 
rt=0, src=0x2793ca8, src_alpha=0x27180a8, dst=0x26886a8, mask=0x2797f58,
const_=0x26be8b8, const_alpha=0x26be808, 
swizzle=0x7fffcd3d66b0 "", nr_channels=1) at
src/gallium/drivers/llvmpipe/lp_bld_blend_aos.c:343
#4  0x7fc02c4ee1c3 in generate_unswizzled_blend (gallivm=0x2688f40, rt=0,
variant=0x2676e80, 
out_format=PIPE_FORMAT_R8_SNORM, num_fs=2, fs_type=...,
fs_mask=0x7fffcd3d68b0, fs_out_color=0x7fffcd3d6ab0, 
context_ptr=0x271b5b0, color_ptr=0x2762828, stride=0x268d388,
partial_mask=1, do_branch=0 '\000')
at src/gallium/drivers/llvmpipe/lp_state_fs.c:1642
#5  0x7fc02c4ef6c5 in generate_fragment (lp=0x2303e80, shader=0x24a4de0,
variant=0x2676e80, partial_mask=1)
at src/gallium/drivers/llvmpipe/lp_state_fs.c:2009
#6  0x7fc02c4f02ce in generate_variant (lp=0x2303e80, shader=0x24a4de0,
key=0x7fffcd3d81e0)
at src/gallium/drivers/llvmpipe/lp_state_fs.c:2171
#7  0x7fc02c4f1639 in llvmpipe_update_fs (lp=0x2303e80) at
src/gallium/drivers/llvmpipe/lp_state_fs.c:2639
#8  0x7fc02c4e8ddb in llvmpipe_update_derived (llvmpipe=0x2303e80)
at src/gallium/drivers/llvmpipe/lp_state_derived.c:155
#9  0x7fc02c4cee43 in llvmpipe_draw_vbo (pipe=0x2303e80,
info=0x7fffcd3d8430)
at src/gallium/drivers/llvmpipe/lp_draw_arrays.c:64
#10 0x7fc02c7df672 in cso_draw_vbo (cso=0x23f7ef0, info=0x7fffcd3d8430)
at src/gallium/auxiliary/cso_cache/cso_context.c:1334
#11 0x7fc02c647409 in st_draw_vbo (ctx=0x2399ab0, prims=0x7fffcd3d84d0,
nr_prims=1, ib=0x0, 
index_bounds_valid=1 '\001', min_index=0, max_index=3, tfb_vertcount=0x0)
at src/mesa/state_tracker/st_draw.c:265
#12 0x7fc02c700397 in vbo_draw_arrays (ctx=0x2399ab0, mode=7, start=0,
count=4, numInstances=1, baseInstance=0)
at src/mesa/vbo/vbo_exec_array.c:619
#13 0x7fc02c700470 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
src/mesa/vbo/vbo_exec_array.c:649
#14 0x7fc02ee6b2ac in piglit_draw_rect (x=-0.66026, y=-1,
w=0.33013, h=2)
at piglit/tests/util/piglit-util-gl.c:872
#15 0x00401eae in blend (rect=0x7fffcd3d8650, src=0x7fffcd3d8660,
dst=0x7fffcd3d8670, blendcol=0x7fffcd3d8680, 
blendsrc=32769, blenddst=32770) at
piglit/tests/fbo/fbo-blending-formats.c:53
#16 0x00402fc4 in test_format (format=0x405520 )
at piglit/tests/fbo/fbo-blending-formats.c:255
#17 0x00401c20 in fbo_formats_display (test_format=0x401ebe
)
at piglit/tests/fbo/fbo-formats.h:641
#18 0x004036f0 in piglit_display () at
piglit/tests/fbo/fbo-blending-formats.c:361
#19 0x7fc02ee0a280 in display ()
at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:60
#20 0x7fc02e7c2fc4 in ?? () from /usr/lib/x86_64-linux-gnu/libglut.so.3
#21 0x7fc02e7c6719 in fgEnumWindows () from
/usr/lib/x86_64-linux-gnu/libglut.so.3
#22 0x7fc02e7c345c in glutMainLoopEvent () from
/usr/lib/x86_64-linux-gnu/libglut.so.3
#23 0x7fc02e7c3d1d in glutMainLoop () from
/usr/lib/x86_64-linux-gnu/libglut.so.3
#24 0x7fc02ee0a452 in run_test (gl_fw=0x7fc02f0d3800 , argc=2,
argv=0x7fffcd3d8c58)
at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c

[Mesa-dev] [Bug 57754] New: [swrast] Mesa 9.1-devel implementation error: Unable to delete renderbuffer, no context

2012-12-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=57754

  Priority: medium
Bug ID: 57754
CC: bri...@vmware.com
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: [swrast] Mesa 9.1-devel implementation error: Unable
to delete renderbuffer, no context
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: v...@freedesktop.org
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

mesa: f3476ec8fa5a94d469a12318c537b13ce9cc5a45 (master)

Run piglit glx-window-life on swrast.

$ ./bin/glx-window-life -auto
Mesa 9.1-devel implementation error: Unable to delete renderbuffer, no context
Please report at bugs.freedesktop.org
Mesa 9.1-devel implementation error: Unable to delete renderbuffer, no context
Please report at bugs.freedesktop.org
Mesa 9.1-devel implementation error: Unable to delete renderbuffer, no context
Please report at bugs.freedesktop.org
Mesa 9.1-devel implementation error: Unable to delete renderbuffer, no context
Please report at bugs.freedesktop.org

c73245882c7ff1277b190b97f093f7b423a22f10 is the first bad commit
commit c73245882c7ff1277b190b97f093f7b423a22f10
Author: Brian Paul 
Date:   Fri Nov 30 10:04:48 2012 -0700

mesa: pass context parameter to gl_renderbuffer::Delete()

We sometimes need a rendering context when deleting renderbuffers.
Pass it explicitly instead of trying to grab a current context
(which might be NULL).  The next patch will make use of this.

Note: this is a candidate for the stable branches.

Reviewed-by: Jose Fonseca 

:04 04 a7a4ac22bb7f5ef34753cf500c0f885d1058c7b1
3342ecc657c9b60cefbac65452cc10eb9a9336fb Msrc

-- 
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 1/2] mesa: Return INVALID_OPERATION when type is known but not allowed

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 03:13 PM, Matt Turner wrote:

INVALID_ENUM is for when the type is simply not known.

Fixes part of es3conform's packed_depth_stencil_error test.
---
  src/mesa/main/glformats.c |   12 +++-
  1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/src/mesa/main/glformats.c b/src/mesa/main/glformats.c
index cf8879b..158b686 100644
--- a/src/mesa/main/glformats.c
+++ b/src/mesa/main/glformats.c
@@ -1270,8 +1270,18 @@ _mesa_error_check_format_and_type(const struct 
gl_context *ctx,
   else if (ctx->Extensions.ARB_depth_buffer_float &&
   type == GL_FLOAT_32_UNSIGNED_INT_24_8_REV)
  return GL_NO_ERROR;
- else
+ switch (type) {
+ case GL_BYTE:
+ case GL_UNSIGNED_BYTE:
+ case GL_SHORT:
+ case GL_UNSIGNED_SHORT:
+ case GL_INT:
+ case GL_UNSIGNED_INT:
+ case GL_FLOAT:
+return GL_INVALID_OPERATION;
+ default:
  return GL_INVALID_ENUM;
+ }

case GL_DUDV_ATI:
case GL_DU8DV8_ATI:



Both are:
Reviewed-by: Kenneth Graunke 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 57746] build test failure: nouveau_fbo.c:198:3: error: too few arguments to function 'nouveau_renderbuffer_del'

2012-12-01 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=57746

Darxus  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #3 from Darxus  ---
Verified that commit builds without failure, thanks.

-- 
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 23/26] glsl: add determinant() functions.

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 10:07 AM, Ian Romanick wrote:

From: Paul Berry 

These functions are defined in GLSL 1.50 and GLES 3.00 ES.

The formulas have been extracted from the existing implementation of
inverse().

Reviewed-by: Ian Romanick 
---
  src/glsl/builtins/glsl/determinant.glsl | 70 +
  1 file changed, 70 insertions(+)
  create mode 100644 src/glsl/builtins/glsl/determinant.glsl

diff --git a/src/glsl/builtins/glsl/determinant.glsl 
b/src/glsl/builtins/glsl/determinant.glsl
new file mode 100644
index 000..32695a8
--- /dev/null
+++ b/src/glsl/builtins/glsl/determinant.glsl
@@ -0,0 +1,70 @@
+/*
+ * Copyright © 2012 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#version 120
+float determinant(mat2 m)
+{
+   return m[0][0] * m[1][1] - m[1][0] * m[0][1];
+}
+
+float determinant(mat3 m)
+{
+   return (+ m[0][0] * (m[1][1] * m[2][2] - m[1][2] * m[2][1])
+   - m[0][1] * (m[1][0] * m[2][2] - m[1][2] * m[2][0])
+   + m[0][2] * (m[1][0] * m[2][1] - m[1][1] * m[2][0]));
+}
+
+float determinant(mat4 m)
+{
+   float SubFactor00 = m[2][2] * m[3][3] - m[3][2] * m[2][3];
+   float SubFactor01 = m[2][1] * m[3][3] - m[3][1] * m[2][3];
+   float SubFactor02 = m[2][1] * m[3][2] - m[3][1] * m[2][2];
+   float SubFactor03 = m[2][0] * m[3][3] - m[3][0] * m[2][3];
+   float SubFactor04 = m[2][0] * m[3][2] - m[3][0] * m[2][2];
+   float SubFactor05 = m[2][0] * m[3][1] - m[3][0] * m[2][1];
+   float SubFactor06 = m[1][2] * m[3][3] - m[3][2] * m[1][3];
+   float SubFactor07 = m[1][1] * m[3][3] - m[3][1] * m[1][3];
+   float SubFactor08 = m[1][1] * m[3][2] - m[3][1] * m[1][2];
+   float SubFactor09 = m[1][0] * m[3][3] - m[3][0] * m[1][3];
+   float SubFactor10 = m[1][0] * m[3][2] - m[3][0] * m[1][2];
+   float SubFactor11 = m[1][1] * m[3][3] - m[3][1] * m[1][3];
+   float SubFactor12 = m[1][0] * m[3][1] - m[3][0] * m[1][1];
+   float SubFactor13 = m[1][2] * m[2][3] - m[2][2] * m[1][3];
+   float SubFactor14 = m[1][1] * m[2][3] - m[2][1] * m[1][3];
+   float SubFactor15 = m[1][1] * m[2][2] - m[2][1] * m[1][2];
+   float SubFactor16 = m[1][0] * m[2][3] - m[2][0] * m[1][3];
+   float SubFactor17 = m[1][0] * m[2][2] - m[2][0] * m[1][2];
+   float SubFactor18 = m[1][0] * m[2][1] - m[2][0] * m[1][1];
+
+   vec4 adj_0;
+
+   adj_0[0] = + (m[1][1] * SubFactor00 - m[1][2] * SubFactor01 + m[1][3] * 
SubFactor02);
+   adj_0[1] = - (m[1][0] * SubFactor00 - m[1][2] * SubFactor03 + m[1][3] * 
SubFactor04);
+   adj_0[2] = + (m[1][0] * SubFactor01 - m[1][1] * SubFactor03 + m[1][3] * 
SubFactor05);
+   adj_0[3] = - (m[1][0] * SubFactor02 - m[1][1] * SubFactor04 + m[1][2] * 
SubFactor05);
+
+   return (+ m[0][0] * adj_0[0]
+   + m[0][1] * adj_0[1]
+   + m[0][2] * adj_0[2]
+   + m[0][3] * adj_0[3]);
+}



I only reviewed the mat2 and mat3 formulas.  I trust the math for 4x4 is 
right and has been tested somehow.


Except where I've expressed objections, this entire series is now:
Reviewed-by: Kenneth Graunke ,kenn...@whitecape.org>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] leak in loop_analysis

2012-12-01 Thread Dave Airlie 
On Sat, Dec 1, 2012 at 4:18 AM, Ian Romanick  wrote:
> On 11/30/2012 02:20 AM, Dave Airlie wrote:
>>
>> Coverity pointed out
>> src/glsl/loop_analysis.cpp
>>
>> loop_analysis::loop_analysis()
>> {
>> this->loops = new loop_state;
>>
>>
>> This loops is never freed anywhere, probably need a destructor.
>
>
> Aw crap.  Could you submit a bug for that, and assign it to me?

Done.

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

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

Re: [Mesa-dev] [PATCH 09/26] glsl: parse GLSL ES 3.00 keywords correctly.

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 10:07 AM, Ian Romanick wrote:

From: Paul Berry 

GLSL ES 3.00 adds the following keywords over GLSL 1.00: uint,
uvec[2-4], matNxM, centroid, flat, smooth, various samplers, layout,
switch, default, and case.

Additionally, it reserves a large number of keywords, some of which
were already reserved in versions of desktop GL that Mesa supports,
some of which are new to Mesa.

A few of the reserved keywords in GLSL ES 3.00 are keywords that are
supported in all other versions of GLSL: attribute, varying,
sampler1D, sampler1DShador, sampler2DRect, and sampler2DRectShadow.

This patch updates the lexer to handle all of the new keywords
correctly when the language being parsed is GLSL 3.00 ES.

Reviewed-by: Ian Romanick 
---
  src/glsl/glsl_lexer.ll  | 189 
  src/glsl/glsl_parser.yy |   3 +
  2 files changed, 114 insertions(+), 78 deletions(-)

diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index ef1402b..e667e71 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -85,6 +85,21 @@ static int classify_identifier(struct _mesa_glsl_parse_state 
*, const char *);
}   
\
 } while (0)

+/**
+ * A macro for handling keywords that have been present in GLSL since
+ * its origin, but were changed into reserved words in GLSL 3.00 ES.
+ */
+#define DEPRECATED_ES_KEYWORD(token)   \
+   do {
\
+  if (yyextra->is_version(0, 300)) {\
+_mesa_glsl_error(yylloc, yyextra,  \
+ "Illegal use of reserved word `%s'", yytext);   \
+return ERROR_TOK;  \
+  } else { \
+ return token; \
+  }
\
+   } while (0)
+
  static int
  literal_integer(char *text, int len, struct _mesa_glsl_parse_state *state,
YYSTYPE *lval, YYLTYPE *lloc, int base)
@@ -223,12 +238,12 @@ HASH  ^{SPC}#{SPC}

  \n{ yylineno++; yycolumn = 0; }

-attribute  return ATTRIBUTE;
+attribute  DEPRECATED_ES_KEYWORD(ATTRIBUTE);
  const return CONST_TOK;
  bool  return BOOL_TOK;
  float return FLOAT_TOK;
  int   return INT_TOK;
-uint   KEYWORD(130, 0, 130, 0, UINT_TOK);
+uint   KEYWORD(130, 300, 130, 300, UINT_TOK);

  break return BREAK;
  continue  return CONTINUE;
@@ -246,59 +261,59 @@ bvec4 return BVEC4;
  ivec2 return IVEC2;
  ivec3 return IVEC3;
  ivec4 return IVEC4;
-uvec2  KEYWORD(130, 0, 130, 0, UVEC2);
-uvec3  KEYWORD(130, 0, 130, 0, UVEC3);
-uvec4  KEYWORD(130, 0, 130, 0, UVEC4);
+uvec2  KEYWORD(130, 300, 130, 300, UVEC2);
+uvec3  KEYWORD(130, 300, 130, 300, UVEC3);
+uvec4  KEYWORD(130, 300, 130, 300, UVEC4);
  vec2  return VEC2;
  vec3  return VEC3;
  vec4  return VEC4;
  mat2  return MAT2X2;
  mat3  return MAT3X3;
  mat4  return MAT4X4;
-mat2x2 KEYWORD(120, 0, 120, 0, MAT2X2);
-mat2x3 KEYWORD(120, 0, 120, 0, MAT2X3);
-mat2x4 KEYWORD(120, 0, 120, 0, MAT2X4);
-mat3x2 KEYWORD(120, 0, 120, 0, MAT3X2);
-mat3x3 KEYWORD(120, 0, 120, 0, MAT3X3);
-mat3x4 KEYWORD(120, 0, 120, 0, MAT3X4);
-mat4x2 KEYWORD(120, 0, 120, 0, MAT4X2);
-mat4x3 KEYWORD(120, 0, 120, 0, MAT4X3);
-mat4x4 KEYWORD(120, 0, 120, 0, MAT4X4);
+mat2x2 KEYWORD(120, 300, 120, 300, MAT2X2);
+mat2x3 KEYWORD(120, 300, 120, 300, MAT2X3);
+mat2x4 KEYWORD(120, 300, 120, 300, MAT2X4);
+mat3x2 KEYWORD(120, 300, 120, 300, MAT3X2);
+mat3x3 KEYWORD(120, 300, 120, 300, MAT3X3);
+mat3x4 KEYWORD(120, 300, 120, 300, MAT3X4);
+mat4x2 KEYWORD(120, 300, 120, 300, MAT4X2);
+mat4x3 KEYWORD(120, 300, 120, 300, MAT4X3);
+mat4x4 KEYWORD(120, 300, 120, 300, MAT4X4);

  inreturn IN_TOK;
  out   return OUT_TOK;
  inout return INOUT_TOK;
  uniform   return UNIFORM;
-varyingreturn VARYING;
-centroid   KEYWORD(120, 0, 120, 0, CENTROID);
+varyingDEPRECATED_ES_KEYWORD(VARYING);
+centroid   KEYWORD(120, 300, 120, 300, CENTROID);
  invariant KEYWORD(120, 100, 120, 100, INVARIANT);
-flat   KEYWORD(130, 100, 130, 0, FLAT);
-smooth KEYWORD(130, 0, 130, 0, SMOOTH);
-noperspective  KEYWORD(130, 0, 130, 0, NOPERSPECTIVE);
+flat   KEYWORD(130, 100, 130, 300, FLAT);
+smooth KEYWORD(130, 300, 130, 300, SMOOTH);
+noperspective  KEYWORD(130, 300, 130, 0, NOPERSP

Re: [Mesa-dev] [PATCH 01/26] mesa: Add ARB_ES3_compatibility flag.

2012-12-01 Thread Kenneth Graunke 

I've run out of time for now, so...

Patches 1-8, 10-14 are:
Reviewed-by: Kenneth Graunke 

I'll try and finish reviewing these in the next few days.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallivm: fix srgb format fetch

2012-12-01 Thread sroland 
From: Roland Scheidegger 

we need to rely on util code for fetching those, just like before
9f06061d50f90bf425a5337cea1b0adb94a46d25.
Fixes bugs 57699 and 57756.
---
 src/gallium/auxiliary/gallivm/lp_bld_format_aos.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c 
b/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c
index 0b54ba4..c7fdb6e 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c
@@ -481,7 +481,8 @@ lp_build_fetch_rgba_aos(struct gallivm_state *gallivm,
}
 
/* If all channels are of same type and we are not using half-floats */
-   if (format_desc->is_array) {
+   if (format_desc->is_array &&
+   format_desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB) {
   assert(!format_desc->is_mixed);
   return lp_build_fetch_rgba_aos_array(gallivm, format_desc, type, 
base_ptr, offset);
}
-- 
1.7.9.5

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

[Mesa-dev] [PATCH] mesa: remove warning message in _mesa_reference_renderbuffer_()

2012-12-01 Thread Brian Paul 
From: Brian Paul 

We were warning when there was no current context and we're about
to delete a renderbuffer, but that happens fairly often and isn't
really a problem.

Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754
---
 src/mesa/main/renderbuffer.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/renderbuffer.c b/src/mesa/main/renderbuffer.c
index 2f28443..b426162 100644
--- a/src/mesa/main/renderbuffer.c
+++ b/src/mesa/main/renderbuffer.c
@@ -160,10 +160,7 @@ _mesa_reference_renderbuffer_(struct gl_renderbuffer **ptr,
 
   if (deleteFlag) {
  GET_CURRENT_CONTEXT(ctx);
- if (ctx)
-oldRb->Delete(ctx, oldRb);
- else
-_mesa_problem(NULL, "Unable to delete renderbuffer, no context");
+ oldRb->Delete(ctx, oldRb);
   }
 
   *ptr = NULL;
-- 
1.7.4.1

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

[Mesa-dev] [PATCH 1/2] mesa: Only require Gen'ed name for glBindFramebuffer on desktop

2012-12-01 Thread Ian Romanick 
From: Ian Romanick 

Desktop OpenGL implementations that support either GL_ARB_framebuffer_object
or OpenGL 3.0 must require names from glGenFramebuffers for
glBindFramebuffer.  We have enforced this rule for quite some time.  However,
OpenGL ES 1.0, 2.0, and 3.0 implementations are required to allow user-defined
names (e.g., not from glGenFramebuffers{OES,}).

The Intel drivers have hacked around this by not enabling
GL_ARB_framebuffer_object in an ES context.  Instead, just pick the correct
behavior in _mesa_BindFramebuffer based on the context API.

Signed-off-by: Ian Romanick 
Cc: Chad Versace 
Cc: Matt Turner 
---
 src/mesa/main/fbobject.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index d05c1e4..f3d292d 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1743,7 +1743,9 @@ _mesa_BindFramebuffer(GLenum target, GLuint framebuffer)
  /* ID was reserved, but no real framebuffer object made yet */
  newDrawFb = NULL;
   }
-  else if (!newDrawFb && ctx->Extensions.ARB_framebuffer_object) {
+  else if (!newDrawFb
+   && _mesa_is_desktop_gl(ctx)
+   && ctx->Extensions.ARB_framebuffer_object) {
  /* All FBO IDs must be Gen'd */
  _mesa_error(ctx, GL_INVALID_OPERATION, "glBindFramebuffer(buffer)");
  return;
-- 
1.7.11.7

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

[Mesa-dev] [PATCH 2/2] intel: Always enable GL_ARB_framebuffer_object

2012-12-01 Thread Ian Romanick 
From: Ian Romanick 

Now that _mesa_BindFramebuffer does the right thing in ES contexts when the
gl_extensions::ARB_framebuffer_object bit is set, the Intel driver doesn't
need this hack.

No piglit or GLES2 conformance regressions observed on IVB.

Signed-off-by: Ian Romanick 
Cc: Chad Versace 
Cc: Matt Turner 
---
 src/mesa/drivers/dri/intel/intel_extensions.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c 
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 9578ff0..0873e11 100755
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -45,8 +45,7 @@ intelInitExtensions(struct gl_context *ctx)
 
ctx->Extensions.ARB_draw_elements_base_vertex = true;
ctx->Extensions.ARB_explicit_attrib_location = true;
-   if (_mesa_is_desktop_gl(ctx))
-  ctx->Extensions.ARB_framebuffer_object = true;
+   ctx->Extensions.ARB_framebuffer_object = true;
ctx->Extensions.ARB_half_float_pixel = true;
ctx->Extensions.ARB_internalformat_query = true;
ctx->Extensions.ARB_map_buffer_range = true;
-- 
1.7.11.7

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

Re: [Mesa-dev] [PATCH 01/26] mesa: Add ARB_ES3_compatibility flag.

2012-12-01 Thread Ian Romanick 

On 11/30/2012 01:39 PM, Paul Berry wrote:

On 30 November 2012 12:11, Ian Romanick mailto:i...@freedesktop.org>> wrote:

This represents a rebase of the gles3 branch that moves the
completed GLSL to be first.  I'd like to get these bits merged to
master sooner rather than later.  Once these bits land, I'll rebase
and send out the next logical block.

I have also pushed this branch to the gles3 branch of my personal
GIT repo on fd.o.  Could people working on the gles3 branch take a
look to make sure no work got lost?  I'd like to force-push this to
origin/gles3 today.


FYI, I've pushed a minor rebase on that branch to "gles3" on
git://github.com/stereotype441/mesa.git
.  The only change is that I
modified patches "mesa: Add new MESA_FORMATs for ETC2 compressed
textures" through "mesa: Add decoding functions for
GL_COMPRESSED_SRGB8_PUNCHTHROUGH_ALPHA1_ETC2" to avoid some transient
build failures.  There's no diff between the tips of the branches.

Ian, feel free to push my rebase to fd.o (assuming no one finds other
problems).


Done.

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

Re: [Mesa-dev] [PATCH 09/26] glsl: parse GLSL ES 3.00 keywords correctly.

2012-12-01 Thread Ian Romanick 

On 11/30/2012 03:47 PM, Kenneth Graunke wrote:

On 11/30/2012 10:07 AM, Ian Romanick wrote:

From: Paul Berry 

GLSL ES 3.00 adds the following keywords over GLSL 1.00: uint,
uvec[2-4], matNxM, centroid, flat, smooth, various samplers, layout,
switch, default, and case.

Additionally, it reserves a large number of keywords, some of which
were already reserved in versions of desktop GL that Mesa supports,
some of which are new to Mesa.

A few of the reserved keywords in GLSL ES 3.00 are keywords that are
supported in all other versions of GLSL: attribute, varying,
sampler1D, sampler1DShador, sampler2DRect, and sampler2DRectShadow.

This patch updates the lexer to handle all of the new keywords
correctly when the language being parsed is GLSL 3.00 ES.

Reviewed-by: Ian Romanick 
---
  src/glsl/glsl_lexer.ll  | 189

  src/glsl/glsl_parser.yy |   3 +
  2 files changed, 114 insertions(+), 78 deletions(-)

diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index ef1402b..e667e71 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -85,6 +85,21 @@ static int classify_identifier(struct
_mesa_glsl_parse_state *, const char *);
}\
 } while (0)

+/**
+ * A macro for handling keywords that have been present in GLSL since
+ * its origin, but were changed into reserved words in GLSL 3.00 ES.
+ */
+#define DEPRECATED_ES_KEYWORD(token)\
+   do {\
+  if (yyextra->is_version(0, 300)) {\
+ _mesa_glsl_error(yylloc, yyextra,\
+  "Illegal use of reserved word `%s'", yytext);\
+ return ERROR_TOK;\
+  } else {\
+ return token;\
+  }\
+   } while (0)
+
  static int
  literal_integer(char *text, int len, struct _mesa_glsl_parse_state
*state,
  YYSTYPE *lval, YYLTYPE *lloc, int base)
@@ -223,12 +238,12 @@ HASH^{SPC}#{SPC}

  \n{ yylineno++; yycolumn = 0; }

-attributereturn ATTRIBUTE;
+attributeDEPRECATED_ES_KEYWORD(ATTRIBUTE);
  constreturn CONST_TOK;
  boolreturn BOOL_TOK;
  floatreturn FLOAT_TOK;
  intreturn INT_TOK;
-uintKEYWORD(130, 0, 130, 0, UINT_TOK);
+uintKEYWORD(130, 300, 130, 300, UINT_TOK);

  breakreturn BREAK;
  continuereturn CONTINUE;
@@ -246,59 +261,59 @@ bvec4return BVEC4;
  ivec2return IVEC2;
  ivec3return IVEC3;
  ivec4return IVEC4;
-uvec2KEYWORD(130, 0, 130, 0, UVEC2);
-uvec3KEYWORD(130, 0, 130, 0, UVEC3);
-uvec4KEYWORD(130, 0, 130, 0, UVEC4);
+uvec2KEYWORD(130, 300, 130, 300, UVEC2);
+uvec3KEYWORD(130, 300, 130, 300, UVEC3);
+uvec4KEYWORD(130, 300, 130, 300, UVEC4);
  vec2return VEC2;
  vec3return VEC3;
  vec4return VEC4;
  mat2return MAT2X2;
  mat3return MAT3X3;
  mat4return MAT4X4;
-mat2x2KEYWORD(120, 0, 120, 0, MAT2X2);
-mat2x3KEYWORD(120, 0, 120, 0, MAT2X3);
-mat2x4KEYWORD(120, 0, 120, 0, MAT2X4);
-mat3x2KEYWORD(120, 0, 120, 0, MAT3X2);
-mat3x3KEYWORD(120, 0, 120, 0, MAT3X3);
-mat3x4KEYWORD(120, 0, 120, 0, MAT3X4);
-mat4x2KEYWORD(120, 0, 120, 0, MAT4X2);
-mat4x3KEYWORD(120, 0, 120, 0, MAT4X3);
-mat4x4KEYWORD(120, 0, 120, 0, MAT4X4);
+mat2x2KEYWORD(120, 300, 120, 300, MAT2X2);
+mat2x3KEYWORD(120, 300, 120, 300, MAT2X3);
+mat2x4KEYWORD(120, 300, 120, 300, MAT2X4);
+mat3x2KEYWORD(120, 300, 120, 300, MAT3X2);
+mat3x3KEYWORD(120, 300, 120, 300, MAT3X3);
+mat3x4KEYWORD(120, 300, 120, 300, MAT3X4);
+mat4x2KEYWORD(120, 300, 120, 300, MAT4X2);
+mat4x3KEYWORD(120, 300, 120, 300, MAT4X3);
+mat4x4KEYWORD(120, 300, 120, 300, MAT4X4);

  inreturn IN_TOK;
  outreturn OUT_TOK;
  inoutreturn INOUT_TOK;
  uniformreturn UNIFORM;
-varyingreturn VARYING;
-centroidKEYWORD(120, 0, 120, 0, CENTROID);
+varyingDEPRECATED_ES_KEYWORD(VARYING);
+centroidKEYWORD(120, 300, 120, 300, CENTROID);
  invariantKEYWORD(120, 100, 120, 100, INVARIANT);
-flatKEYWORD(130, 100, 130, 0, FLAT);
-smoothKEYWORD(130, 0, 130, 0, SMOOTH);
-noperspectiveKEYWORD(130, 0, 130, 0, NOPERSPECTIVE);
+flatKEYWORD(130, 100, 130, 300, FLAT);
+smoothKEYWORD(130, 300, 130, 300, SMOOTH);
+noperspectiveKEYWORD(130, 300, 130, 0, NOPERSPECTIVE);

-sampler1Dreturn SAMPLER1D;
+sampler1DDEPRECATED_ES_KEYWORD(SAMPLER1D);
  sampler2Dreturn SAMPLER2D;
  sampler3Dreturn SAMPLER3D;
  samplerCubereturn SAMPLERCUBE;
-sampler1DArrayKEYWORD(130, 0, 130, 0, SAMPLER1DARRAY);
-sampler2DArrayKEYWORD(130, 0, 130, 0, SAMPLER2DARRAY);
-sample

Re: [Mesa-dev] [PATCH 09/26] glsl: parse GLSL ES 3.00 keywords correctly.

2012-12-01 Thread Kenneth Graunke 

On 12/01/2012 11:40 AM, Ian Romanick wrote:

On 11/30/2012 03:47 PM, Kenneth Graunke wrote:

On 11/30/2012 10:07 AM, Ian Romanick wrote:

From: Paul Berry 

GLSL ES 3.00 adds the following keywords over GLSL 1.00: uint,
uvec[2-4], matNxM, centroid, flat, smooth, various samplers, layout,
switch, default, and case.

Additionally, it reserves a large number of keywords, some of which
were already reserved in versions of desktop GL that Mesa supports,
some of which are new to Mesa.

A few of the reserved keywords in GLSL ES 3.00 are keywords that are
supported in all other versions of GLSL: attribute, varying,
sampler1D, sampler1DShador, sampler2DRect, and sampler2DRectShadow.

This patch updates the lexer to handle all of the new keywords
correctly when the language being parsed is GLSL 3.00 ES.

Reviewed-by: Ian Romanick 
---
  src/glsl/glsl_lexer.ll  | 189

  src/glsl/glsl_parser.yy |   3 +
  2 files changed, 114 insertions(+), 78 deletions(-)

diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index ef1402b..e667e71 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -85,6 +85,21 @@ static int classify_identifier(struct
_mesa_glsl_parse_state *, const char *);
}\
 } while (0)

+/**
+ * A macro for handling keywords that have been present in GLSL since
+ * its origin, but were changed into reserved words in GLSL 3.00 ES.
+ */
+#define DEPRECATED_ES_KEYWORD(token)\
+   do {\
+  if (yyextra->is_version(0, 300)) {\
+ _mesa_glsl_error(yylloc, yyextra,\
+  "Illegal use of reserved word `%s'", yytext);\
+ return ERROR_TOK;\
+  } else {\
+ return token;\
+  }\
+   } while (0)
+
  static int
  literal_integer(char *text, int len, struct _mesa_glsl_parse_state
*state,
  YYSTYPE *lval, YYLTYPE *lloc, int base)
@@ -223,12 +238,12 @@ HASH^{SPC}#{SPC}

  \n{ yylineno++; yycolumn = 0; }

-attributereturn ATTRIBUTE;
+attributeDEPRECATED_ES_KEYWORD(ATTRIBUTE);
  constreturn CONST_TOK;
  boolreturn BOOL_TOK;
  floatreturn FLOAT_TOK;
  intreturn INT_TOK;
-uintKEYWORD(130, 0, 130, 0, UINT_TOK);
+uintKEYWORD(130, 300, 130, 300, UINT_TOK);

  breakreturn BREAK;
  continuereturn CONTINUE;
@@ -246,59 +261,59 @@ bvec4return BVEC4;
  ivec2return IVEC2;
  ivec3return IVEC3;
  ivec4return IVEC4;
-uvec2KEYWORD(130, 0, 130, 0, UVEC2);
-uvec3KEYWORD(130, 0, 130, 0, UVEC3);
-uvec4KEYWORD(130, 0, 130, 0, UVEC4);
+uvec2KEYWORD(130, 300, 130, 300, UVEC2);
+uvec3KEYWORD(130, 300, 130, 300, UVEC3);
+uvec4KEYWORD(130, 300, 130, 300, UVEC4);
  vec2return VEC2;
  vec3return VEC3;
  vec4return VEC4;
  mat2return MAT2X2;
  mat3return MAT3X3;
  mat4return MAT4X4;
-mat2x2KEYWORD(120, 0, 120, 0, MAT2X2);
-mat2x3KEYWORD(120, 0, 120, 0, MAT2X3);
-mat2x4KEYWORD(120, 0, 120, 0, MAT2X4);
-mat3x2KEYWORD(120, 0, 120, 0, MAT3X2);
-mat3x3KEYWORD(120, 0, 120, 0, MAT3X3);
-mat3x4KEYWORD(120, 0, 120, 0, MAT3X4);
-mat4x2KEYWORD(120, 0, 120, 0, MAT4X2);
-mat4x3KEYWORD(120, 0, 120, 0, MAT4X3);
-mat4x4KEYWORD(120, 0, 120, 0, MAT4X4);
+mat2x2KEYWORD(120, 300, 120, 300, MAT2X2);
+mat2x3KEYWORD(120, 300, 120, 300, MAT2X3);
+mat2x4KEYWORD(120, 300, 120, 300, MAT2X4);
+mat3x2KEYWORD(120, 300, 120, 300, MAT3X2);
+mat3x3KEYWORD(120, 300, 120, 300, MAT3X3);
+mat3x4KEYWORD(120, 300, 120, 300, MAT3X4);
+mat4x2KEYWORD(120, 300, 120, 300, MAT4X2);
+mat4x3KEYWORD(120, 300, 120, 300, MAT4X3);
+mat4x4KEYWORD(120, 300, 120, 300, MAT4X4);

  inreturn IN_TOK;
  outreturn OUT_TOK;
  inoutreturn INOUT_TOK;
  uniformreturn UNIFORM;
-varyingreturn VARYING;
-centroidKEYWORD(120, 0, 120, 0, CENTROID);
+varyingDEPRECATED_ES_KEYWORD(VARYING);
+centroidKEYWORD(120, 300, 120, 300, CENTROID);
  invariantKEYWORD(120, 100, 120, 100, INVARIANT);
-flatKEYWORD(130, 100, 130, 0, FLAT);
-smoothKEYWORD(130, 0, 130, 0, SMOOTH);
-noperspectiveKEYWORD(130, 0, 130, 0, NOPERSPECTIVE);
+flatKEYWORD(130, 100, 130, 300, FLAT);
+smoothKEYWORD(130, 300, 130, 300, SMOOTH);
+noperspectiveKEYWORD(130, 300, 130, 0, NOPERSPECTIVE);

-sampler1Dreturn SAMPLER1D;
+sampler1DDEPRECATED_ES_KEYWORD(SAMPLER1D);
  sampler2Dreturn SAMPLER2D;
  sampler3Dreturn SAMPLER3D;
  samplerCubereturn SAMPLERCUBE;
-sampler1DArrayKEYWORD(130, 0, 130, 0, SAMPLER1DARRAY);
-sampler2DArrayKEY

Re: [Mesa-dev] [PATCH 1/2] mesa: Only require Gen'ed name for glBindFramebuffer on desktop

2012-12-01 Thread Kenneth Graunke 

On 12/01/2012 11:10 AM, Ian Romanick wrote:

From: Ian Romanick 

Desktop OpenGL implementations that support either GL_ARB_framebuffer_object
or OpenGL 3.0 must require names from glGenFramebuffers for
glBindFramebuffer.  We have enforced this rule for quite some time.  However,
OpenGL ES 1.0, 2.0, and 3.0 implementations are required to allow user-defined
names (e.g., not from glGenFramebuffers{OES,}).


Ugh...seriously?  What were they thinking?  They require Gen'd names for 
just about everything else in ES 3.0...



The Intel drivers have hacked around this by not enabling
GL_ARB_framebuffer_object in an ES context.  Instead, just pick the correct
behavior in _mesa_BindFramebuffer based on the context API.


This was the whole reason for the EXT/ARB debacle we had?  Over one line 
of code? :)


Looks good to me...both patches are:
Reviewed-by: Kenneth Graunke 

(but I really want Chad's review)


Signed-off-by: Ian Romanick 
Cc: Chad Versace 
Cc: Matt Turner 
---
  src/mesa/main/fbobject.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index d05c1e4..f3d292d 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1743,7 +1743,9 @@ _mesa_BindFramebuffer(GLenum target, GLuint framebuffer)
   /* ID was reserved, but no real framebuffer object made yet */
   newDrawFb = NULL;
}
-  else if (!newDrawFb && ctx->Extensions.ARB_framebuffer_object) {
+  else if (!newDrawFb
+   && _mesa_is_desktop_gl(ctx)
+   && ctx->Extensions.ARB_framebuffer_object) {
   /* All FBO IDs must be Gen'd */
   _mesa_error(ctx, GL_INVALID_OPERATION, "glBindFramebuffer(buffer)");
   return;


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

Re: [Mesa-dev] [PATCH] mesa: remove warning message in _mesa_reference_renderbuffer_()

2012-12-01 Thread Ian Romanick 

On 12/01/2012 09:56 AM, Brian Paul wrote:

From: Brian Paul 

We were warning when there was no current context and we're about
to delete a renderbuffer, but that happens fairly often and isn't
really a problem.

Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754


I'm really confused.  A previous patch added the context pointer to 
gl_renderbuffer::Delete with the commit message


We sometimes need a rendering context when deleting renderbuffers.
Pass it explicitly instead of trying to grab a current context
(which might be NULL).  The next patch will make use of this.

But we're allowing NULL to be passed in all the same cases where it 
could have been NULL before.  Right?  What is preventing 
st_renderbuffer_delete from dereferencing a NULL pointer (instead of 
accessing freed memory)?  Does it just leak memory now?


In any case, this makes the warnings go away on i965.

Tested-by: Ian Romanick 


---
  src/mesa/main/renderbuffer.c |5 +
  1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/src/mesa/main/renderbuffer.c b/src/mesa/main/renderbuffer.c
index 2f28443..b426162 100644
--- a/src/mesa/main/renderbuffer.c
+++ b/src/mesa/main/renderbuffer.c
@@ -160,10 +160,7 @@ _mesa_reference_renderbuffer_(struct gl_renderbuffer **ptr,

if (deleteFlag) {
   GET_CURRENT_CONTEXT(ctx);
- if (ctx)
-oldRb->Delete(ctx, oldRb);
- else
-_mesa_problem(NULL, "Unable to delete renderbuffer, no context");
+ oldRb->Delete(ctx, oldRb);
}

*ptr = NULL;



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

Re: [Mesa-dev] [PATCH] mesa: Use _mesa_lookup_enum_by_nr in tex*_error_check

2012-12-01 Thread Kenneth Graunke 

On 11/30/2012 11:55 AM, Brian Paul wrote:

On 11/30/2012 12:26 PM, Matt Turner wrote:

---
  src/mesa/main/teximage.c |9 ++---
  1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 347b3e2..6401824 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1949,7 +1949,8 @@ texture_error_check( struct gl_context *ctx,
 if (err != GL_NO_ERROR) {
_mesa_error(ctx, err,
"glTexImage%dD(incompatible format 0x%x, type 0x%x)",
-  dimensions, format, type);
+  dimensions, _mesa_lookup_enum_by_nr(format),
+  _mesa_lookup_enum_by_nr(type));
return GL_TRUE;
 }

@@ -1962,7 +1963,8 @@ texture_error_check( struct gl_context *ctx,
 (_mesa_is_dudv_format(internalFormat) !=
_mesa_is_dudv_format(format))) {
_mesa_error(ctx, GL_INVALID_OPERATION,
"glTexImage%dD(incompatible internalFormat 0x%x,
format 0x%x)",
-  dimensions, internalFormat, format);
+  dimensions, _mesa_lookup_enum_by_nr(internalFormat),
+  _mesa_lookup_enum_by_nr(format));
return GL_TRUE;
 }

@@ -2265,7 +2267,8 @@ texsubimage_error_check(struct gl_context *ctx,
GLuint dimensions,
 if (err != GL_NO_ERROR) {
_mesa_error(ctx, err,
"glTexSubImage%dD(incompatible format 0x%x, type
0x%x)",
-  dimensions, format, type);
+  dimensions, _mesa_lookup_enum_by_nr(format),
+  _mesa_lookup_enum_by_nr(type));
return GL_TRUE;
 }



Reviewed-by: Brian Paul 

BTW, I think we were interested in renaming _mesa_lookup_enum_by_nr() to
something nicer a while back.


Yeah, I think we settled on _mesa_enum_string() or some such.  I'd still 
love to see that happen (maybe after these patches land?)

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

Re: [Mesa-dev] [PATCH] mesa: remove warning message in _mesa_reference_renderbuffer_()

2012-12-01 Thread Brian Paul 
On Sat, Dec 1, 2012 at 1:43 PM, Ian Romanick  wrote:
> On 12/01/2012 09:56 AM, Brian Paul wrote:
>>
>> From: Brian Paul 
>>
>> We were warning when there was no current context and we're about
>> to delete a renderbuffer, but that happens fairly often and isn't
>> really a problem.
>>
>> Fixes http://bugs.freedesktop.org/show_bug.cgi?id=57754
>
>
> I'm really confused.  A previous patch added the context pointer to
> gl_renderbuffer::Delete with the commit message
>
> We sometimes need a rendering context when deleting renderbuffers.
> Pass it explicitly instead of trying to grab a current context
> (which might be NULL).  The next patch will make use of this.
>
> But we're allowing NULL to be passed in all the same cases where it could
> have been NULL before.  Right?  What is preventing st_renderbuffer_delete
> from dereferencing a NULL pointer (instead of accessing freed memory)?  Does
> it just leak memory now?
>
> In any case, this makes the warnings go away on i965.
>
> Tested-by: Ian Romanick 

Yeah, this is kind of confusing.  When we delete user-created
renderbuffers we always have a rendering context, so that's simple.
When we delete winsys renderbuffers we may or may not have a context,
and that varies a bit between DRI drivers, gallium and xlib+swrast.
So far the only place where we really would like to always have a
context for RB deletion is in gallium where we have a per-context
pipe_surface object associated with renderbuffers.

I might need to add a null pointer check, as you suggested, in
st_renderbuffer_delete() but I don't have easy access to my system to
test right now.  Maybe tomorrow.

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

Re: [Mesa-dev] [PATCH] gallivm: fix srgb format fetch

2012-12-01 Thread Brian Paul 
On Sat, Dec 1, 2012 at 9:04 AM,   wrote:
> From: Roland Scheidegger 
>
> we need to rely on util code for fetching those, just like before
> 9f06061d50f90bf425a5337cea1b0adb94a46d25.
> Fixes bugs 57699 and 57756.
> ---
>  src/gallium/auxiliary/gallivm/lp_bld_format_aos.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c 
> b/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c
> index 0b54ba4..c7fdb6e 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_format_aos.c
> @@ -481,7 +481,8 @@ lp_build_fetch_rgba_aos(struct gallivm_state *gallivm,
> }
>
> /* If all channels are of same type and we are not using half-floats */
> -   if (format_desc->is_array) {
> +   if (format_desc->is_array &&
> +   format_desc->colorspace == UTIL_FORMAT_COLORSPACE_RGB) {
>assert(!format_desc->is_mixed);
>return lp_build_fetch_rgba_aos_array(gallivm, format_desc, type, 
> base_ptr, offset);
> }

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