Re: [Mesa3d-dev] Importing real strtod code

2009-10-09 Thread Chris Rankin
--- On Thu, 8/10/09, Brian Paul bri...@vmware.com wrote:
 I think that we could just bracket the call to
 _slang_compile() with the set/restore-locale calls.

I'd hate to make an obvious suggestion, but... can't you just copy strtod() 
code (without the locale support) from GLIBC? My basic research suggests that 
the MIT license is compatible with the GPL...

Core Mesa *is* licensed under the MIT license, isn't it?

Cheers,
Chris


  

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] Importing real strtod code

2009-10-09 Thread Robert Noland
On Fri, 2009-10-09 at 01:03 -0700, Chris Rankin wrote:
 --- On Thu, 8/10/09, Brian Paul bri...@vmware.com wrote:
  I think that we could just bracket the call to
  _slang_compile() with the set/restore-locale calls.
 
 I'd hate to make an obvious suggestion, but... can't you just copy strtod() 
 code (without the locale support) from GLIBC? My basic research suggests that 
 the MIT license is compatible with the GPL...
 
 Core Mesa *is* licensed under the MIT license, isn't it?

You can include MIT code in a GPL project without impact to the license.
You can't include GPL code into an MIT project without poluting the
license.

robert.

 Cheers,
 Chris
 
 
   
 
 --
 Come build with us! The BlackBerry(R) Developer Conference in SF, CA
 is the only developer event you need to attend this year. Jumpstart your
 developing skills, take BlackBerry mobile applications to market and stay 
 ahead of the curve. Join us from November 9 - 12, 2009. Register now!
 http://p.sf.net/sfu/devconference
 ___
 Mesa3d-dev mailing list
 Mesa3d-dev@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
-- 
Robert Noland rnol...@2hip.net
2Hip Networks


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] Importing real strtod code

2009-10-09 Thread Chris Rankin
--- On Fri, 9/10/09, Robert Noland rnol...@2hip.net wrote:
 You can't include GPL code into an MIT project without
 poluting the license.

Ah. So that means Mesa would need the GLIBC copyright holder's explicit 
permission ... That would be Uli Drepper, presumably.

Cheers,
Chris



  

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


[Mesa3d-dev] drawing with elements out of range

2009-10-09 Thread michal
I've been able to crash my app that uses a gallium driver by feeding the 
draw module an index buffer with garbage contents.

Is there a desire to add out-of-bounds checking of every index element, 
or is it being ignored on purpose for performance reasons?

Thanks.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] drawing with elements out of range

2009-10-09 Thread Keith Whitwell
On Fri, 2009-10-09 at 04:10 -0700, michal wrote:
 I've been able to crash my app that uses a gallium driver by feeding the 
 draw module an index buffer with garbage contents.
 
 Is there a desire to add out-of-bounds checking of every index element, 
 or is it being ignored on purpose for performance reasons?

Michal,

There is code that should prevent this, but it probably doesn't get
heaps of testing.

Probably the best thing to do is provide a trivial/ example that
exercises the problem you're seeing.

Keith




--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] drawing with elements out of range

2009-10-09 Thread michal
Keith Whitwell pisze:
 On Fri, 2009-10-09 at 04:10 -0700, michal wrote:
   
 I've been able to crash my app that uses a gallium driver by feeding the 
 draw module an index buffer with garbage contents.

 Is there a desire to add out-of-bounds checking of every index element, 
 or is it being ignored on purpose for performance reasons?
 

 Michal,

 There is code that should prevent this, but it probably doesn't get
 heaps of testing.

 Probably the best thing to do is provide a trivial/ example that
 exercises the problem you're seeing.


   
While I would agree otherwise, there is a high chance the test app won't 
trigger a segfault.

I am happy the intent is to check element indirections and should be 
able to provide a patch for it for a review instead.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


[Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread michal
 From 5ebc14fc47a5e31b3c6be54142550bdf2ac093df Mon Sep 17 00:00:00 2001
From: Michal Krol mic...@vmware.com
Date: Fri, 9 Oct 2009 13:30:52 +0100
Subject: [PATCH] draw: Do an out-of-bounds check on array elements.

Do not draw a reduced primitive if any of its vertices
reaches outside of the vertex array.
---
 src/gallium/auxiliary/draw/draw_pipe.c |   68 
++-
 1 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/src/gallium/auxiliary/draw/draw_pipe.c 
b/src/gallium/auxiliary/draw/draw_pipe.c
index 1c6d657..5b88f00 100644
--- a/src/gallium/auxiliary/draw/draw_pipe.c
+++ b/src/gallium/auxiliary/draw/draw_pipe.c
@@ -158,37 +158,64 @@ static void do_triangle( struct draw_context *draw,
 
 
 
-#define QUAD(i0,i1,i2,i3)   \
+#define QUAD(i0,i1,i2,i3) do 
{\
+   uint e0 = 
(uint)elts[i0];  \
+   uint e1 = 
(uint)elts[i1];  \
+   uint e2 = 
(uint)elts[i2];  \
+   uint e3 = 
(uint)elts[i3];  \
+   if (e0 = vertex_count || e1 = vertex_count || e2 = vertex_count 
||  \
+   e3 = vertex_count) 
{  \
+  
break;  \
+   
}  \
do_triangle( draw,   \
 ( DRAW_PIPE_RESET_STIPPLE | \
   DRAW_PIPE_EDGE_FLAG_0 |   \
   DRAW_PIPE_EDGE_FLAG_2 ),  \
-verts + stride * elts[i0],  \
-verts + stride * elts[i1],  \
-verts + stride * elts[i3]); \
+   verts + stride * 
e0,   \
+   verts + stride * 
e1,   \
+   verts + stride * 
e3);  \
do_triangle( draw,   \
 ( DRAW_PIPE_EDGE_FLAG_0 |   \
   DRAW_PIPE_EDGE_FLAG_1 ),  \
-verts + stride * elts[i1],  \
-verts + stride * elts[i2],  \
-verts + stride * elts[i3])
-
-#define TRIANGLE(flags,i0,i1,i2)\
+   verts + stride * 
e1,   \
+   verts + stride * 
e2,   \
+   verts + stride * 
e3);  \
+} while (0)
+
+#define TRIANGLE(flags,i0,i1,i2) do 
{ \
+   uint e0 = (uint)elts[i0]  
~DRAW_PIPE_FLAG_MASK;   \
+   uint e1 = 
(uint)elts[i1];  \
+   uint e2 = 
(uint)elts[i2];  \
+   if (e0 = vertex_count || e1 = vertex_count || e2 = vertex_count) 
{  \
+  
break;  \
+   
}  \
do_triangle( draw,   \
 elts[i0],  /* flags */  \
-verts + stride * (elts[i0]  ~DRAW_PIPE_FLAG_MASK), \
-verts + stride * elts[i1],  \
-verts + stride * elts[i2])
-
-#define LINE(flags,i0,i1)   \
+   verts + stride * 
e0,   \
+   verts + stride * 
e1,   \
+   verts + stride * 
e2);  \
+} while (0)
+
+#define LINE(flags,i0,i1) do 
{\
+   uint e0 = (uint)elts[i0]  
~DRAW_PIPE_FLAG_MASK;   \
+   uint e1 = 
(uint)elts[i1];  \
+   if (e0 = vertex_count || e1 = vertex_count) 
{\
+  
break;  \
+   
}  \
do_line( draw,   \
 elts[i0],   \
-verts + stride * (elts[i0]  ~DRAW_PIPE_FLAG_MASK), \
-verts + stride * elts[i1])
-
-#define POINT(i0)   \
+   verts + stride * 
e0,   \
+   verts + stride * 
e1);  \
+} while (0)
+
+#define POINT(i0) do 
{ 

Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread Keith Whitwell
Michal,

Sorry, this isn't a great way to do this.  This can usually be caught
much earlier in the pipeline and with much less overhead by validating
the incoming index list.

We normally do that in Mesa or the state tracker, if that helps.

Keith

On Fri, 2009-10-09 at 06:01 -0700, michal wrote:
 From 5ebc14fc47a5e31b3c6be54142550bdf2ac093df Mon Sep 17 00:00:00 2001
 From: Michal Krol mic...@vmware.com
 Date: Fri, 9 Oct 2009 13:30:52 +0100
 Subject: [PATCH] draw: Do an out-of-bounds check on array elements.
 
 Do not draw a reduced primitive if any of its vertices
 reaches outside of the vertex array.
 ---
  src/gallium/auxiliary/draw/draw_pipe.c |   68 
 ++-
  1 files changed, 48 insertions(+), 20 deletions(-)
 
 diff --git a/src/gallium/auxiliary/draw/draw_pipe.c 
 b/src/gallium/auxiliary/draw/draw_pipe.c
 index 1c6d657..5b88f00 100644
 --- a/src/gallium/auxiliary/draw/draw_pipe.c
 +++ b/src/gallium/auxiliary/draw/draw_pipe.c
 @@ -158,37 +158,64 @@ static void do_triangle( struct draw_context *draw,
  
 
 
 -#define QUAD(i0,i1,i2,i3)   \
 +#define QUAD(i0,i1,i2,i3) do 
 {\
 +   uint e0 = 
 (uint)elts[i0];  \
 +   uint e1 = 
 (uint)elts[i1];  \
 +   uint e2 = 
 (uint)elts[i2];  \
 +   uint e3 = 
 (uint)elts[i3];  \
 +   if (e0 = vertex_count || e1 = vertex_count || e2 = vertex_count 
 ||  \
 +   e3 = vertex_count) 
 {  \
 +  
 break;  \
 +   
 }  \
 do_triangle( draw,   \
  ( DRAW_PIPE_RESET_STIPPLE | \
DRAW_PIPE_EDGE_FLAG_0 |   \
DRAW_PIPE_EDGE_FLAG_2 ),  \
 -verts + stride * elts[i0],  \
 -verts + stride * elts[i1],  \
 -verts + stride * elts[i3]); \
 +   verts + stride * 
 e0,   \
 +   verts + stride * 
 e1,   \
 +   verts + stride * 
 e3);  \
 do_triangle( draw,   \
  ( DRAW_PIPE_EDGE_FLAG_0 |   \
DRAW_PIPE_EDGE_FLAG_1 ),  \
 -verts + stride * elts[i1],  \
 -verts + stride * elts[i2],  \
 -verts + stride * elts[i3])
 -
 -#define TRIANGLE(flags,i0,i1,i2)\
 +   verts + stride * 
 e1,   \
 +   verts + stride * 
 e2,   \
 +   verts + stride * 
 e3);  \
 +} while (0)
 +
 +#define TRIANGLE(flags,i0,i1,i2) do 
 { \
 +   uint e0 = (uint)elts[i0]  
 ~DRAW_PIPE_FLAG_MASK;   \
 +   uint e1 = 
 (uint)elts[i1];  \
 +   uint e2 = 
 (uint)elts[i2];  \
 +   if (e0 = vertex_count || e1 = vertex_count || e2 = vertex_count) 
 {  \
 +  
 break;  \
 +   
 }  \
 do_triangle( draw,   \
  elts[i0],  /* flags */  \
 -verts + stride * (elts[i0]  ~DRAW_PIPE_FLAG_MASK), \
 -verts + stride * elts[i1],  \
 -verts + stride * elts[i2])
 -
 -#define LINE(flags,i0,i1)   \
 +   verts + stride * 
 e0,   \
 +   verts + stride * 
 e1,   \
 +   verts + stride * 
 e2);  \
 +} while (0)
 +
 +#define LINE(flags,i0,i1) do 
 {\
 +   uint e0 = (uint)elts[i0]  
 ~DRAW_PIPE_FLAG_MASK;   \
 +   uint e1 = 
 (uint)elts[i1];  \
 +   if (e0 = vertex_count || e1 = vertex_count) 
 {\
 +  
 break;  \
 +   
 }  \
 do_line( draw,   \
  elts[i0], 

Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread michal
Keith Whitwell pisze:
 Michal,

 Sorry, this isn't a great way to do this.  This can usually be caught
 much earlier in the pipeline and with much less overhead by validating
 the incoming index list.

   
OK, so we scan the whole element array beforehand, and if any element is 
out of range, we kill the while primitive, right?

 We normally do that in Mesa or the state tracker, if that helps.

   
Does this mean we actually don't want to check that in the draw module 
and we should deal with it on the state tracker level?

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread Keith Whitwell
On Fri, 2009-10-09 at 06:19 -0700, michal wrote:
 Keith Whitwell pisze:
  Michal,
 
  Sorry, this isn't a great way to do this.  This can usually be caught
  much earlier in the pipeline and with much less overhead by validating
  the incoming index list.
 

 OK, so we scan the whole element array beforehand, and if any element is 
 out of range, we kill the while primitive, right?
 
  We normally do that in Mesa or the state tracker, if that helps.
 

 Does this mean we actually don't want to check that in the draw module 
 and we should deal with it on the state tracker level?

The argument *against* doing it at the state-tracker level is that if
the vertices are in VBOs, then a lot of hardware doesn't need any
assistance from the CPU to cope with out-of-bounds indices.

So maybe what that means is that the draw module should do the scan, or
perhaps that the code-generated vertex shader within the draw module
should validate each index as it's being processed.

One trouble is that the draw module has become quite complex with a lot
of similar but different paths, eg. the tgsi_aos vs. tsgi_sse shaders.

Keith



--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread Keith Whitwell
On Fri, 2009-10-09 at 06:19 -0700, michal wrote:
 Keith Whitwell pisze:
  Michal,
 
  Sorry, this isn't a great way to do this.  This can usually be caught
  much earlier in the pipeline and with much less overhead by validating
  the incoming index list.
 

 OK, so we scan the whole element array beforehand, and if any element is 
 out of range, we kill the while primitive, right?
 
  We normally do that in Mesa or the state tracker, if that helps.
 

 Does this mean we actually don't want to check that in the draw module 
 and we should deal with it on the state tracker level?

At a guess, yes.  It would be helpful to have some tests to flush out
the real issues, as you've gathered this has been a bit ignored to date.

Keith


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread Brian Paul
Keith Whitwell wrote:
 On Fri, 2009-10-09 at 06:19 -0700, michal wrote:
 Keith Whitwell pisze:
 Michal,

 Sorry, this isn't a great way to do this.  This can usually be caught
 much earlier in the pipeline and with much less overhead by validating
 the incoming index list.

   
 OK, so we scan the whole element array beforehand, and if any element is 
 out of range, we kill the while primitive, right?

 We normally do that in Mesa or the state tracker, if that helps.

   
 Does this mean we actually don't want to check that in the draw module 
 and we should deal with it on the state tracker level?
 
 At a guess, yes.  It would be helpful to have some tests to flush out
 the real issues, as you've gathered this has been a bit ignored to date.

It seems to me there should probably be a pipe query to ask the driver 
if it can do index bounds checking.  If it can't, either the draw 
module or state tracker will have to do it.

-Brian



--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread Keith Whitwell
On Fri, 2009-10-09 at 07:10 -0700, Brian Paul wrote:
 Keith Whitwell wrote:
  On Fri, 2009-10-09 at 06:19 -0700, michal wrote:
  Keith Whitwell pisze:
  Michal,
 
  Sorry, this isn't a great way to do this.  This can usually be caught
  much earlier in the pipeline and with much less overhead by validating
  the incoming index list.
 

  OK, so we scan the whole element array beforehand, and if any element is 
  out of range, we kill the while primitive, right?
 
  We normally do that in Mesa or the state tracker, if that helps.
 

  Does this mean we actually don't want to check that in the draw module 
  and we should deal with it on the state tracker level?
  
  At a guess, yes.  It would be helpful to have some tests to flush out
  the real issues, as you've gathered this has been a bit ignored to date.
 
 It seems to me there should probably be a pipe query to ask the driver 
 if it can do index bounds checking.  If it can't, either the draw 
 module or state tracker will have to do it.

I don't think it needs to be a pipe-level interface -- it will change
from time to time depending on swtnl fallback or not, for instance.  I'd
suggest making the draw module robust against failures and then
providing an auxiliary library for drivers that need to validate before
sending to hardware.

In fact, if hardware is fragile like that, it's not even the driver that
should be validating, but really the kernel module...

Keith


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread michal
Keith Whitwell pisze:
 On Fri, 2009-10-09 at 06:19 -0700, michal wrote:
   
 Keith Whitwell pisze:
 
 Michal,

 Sorry, this isn't a great way to do this.  This can usually be caught
 much earlier in the pipeline and with much less overhead by validating
 the incoming index list.

   
   
 OK, so we scan the whole element array beforehand, and if any element is 
 out of range, we kill the while primitive, right?

 
 We normally do that in Mesa or the state tracker, if that helps.

   
   
 Does this mean we actually don't want to check that in the draw module 
 and we should deal with it on the state tracker level?
 

 The argument *against* doing it at the state-tracker level is that if
 the vertices are in VBOs, then a lot of hardware doesn't need any
 assistance from the CPU to cope with out-of-bounds indices.

 So maybe what that means is that the draw module should do the scan, or
 perhaps that the code-generated vertex shader within the draw module
 should validate each index as it's being processed.

   
I am having problems trying to imagine that, unless we do clipping 
inside vertex shaders. I would think once the vertex shader is hit, the 
vertex data has already been fetched, and if the element had been out of 
range, we are dead.


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.

2009-10-09 Thread Keith Whitwell
On Fri, 2009-10-09 at 08:01 -0700, michal wrote:
 Keith Whitwell pisze:
  On Fri, 2009-10-09 at 06:19 -0700, michal wrote:

  Keith Whitwell pisze:
  
  Michal,
 
  Sorry, this isn't a great way to do this.  This can usually be caught
  much earlier in the pipeline and with much less overhead by validating
  the incoming index list.
 


  OK, so we scan the whole element array beforehand, and if any element is 
  out of range, we kill the while primitive, right?
 
  
  We normally do that in Mesa or the state tracker, if that helps.
 


  Does this mean we actually don't want to check that in the draw module 
  and we should deal with it on the state tracker level?
  
 
  The argument *against* doing it at the state-tracker level is that if
  the vertices are in VBOs, then a lot of hardware doesn't need any
  assistance from the CPU to cope with out-of-bounds indices.
 
  So maybe what that means is that the draw module should do the scan, or
  perhaps that the code-generated vertex shader within the draw module
  should validate each index as it's being processed.
 

 I am having problems trying to imagine that, unless we do clipping 
 inside vertex shaders. I would think once the vertex shader is hit, the 
 vertex data has already been fetched, and if the element had been out of 
 range, we are dead.

No, we can just load all vertex elements as {0,0,0,1} in that case.
There's no wrong way to rasterize this -- as long as we don't crash,
everybody's happy.

Keith


--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


[Mesa3d-dev] [Bug 24425] New: rv770 hangs when trying to play mesa (bisected)

2009-10-09 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=24425

   Summary: rv770 hangs when trying to play mesa (bisected)
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa3d-dev@lists.sourceforge.net
ReportedBy: a...@sannes.org


I am using DRI2/KMS with the latest drm-next from airlied .. 
and mesa from git aswell..

ATI Technologies Inc RV770 [Radeon HD 4870]

To reproduce: When loading a level in nexuiz it hangs completely while X is
using 100% cpu.. I can kill X, but it will not be able to start again I think,
or rather it just shows garbage after this.


From bisecting I found that:

commit 44c6c20b69839ea130a255496f5f692186b68793
Author: Andre Maasikas amaasi...@gmail.com
Date:   Fri Oct 9 10:46:12 2009 +0300

r600: fixup KIL instruction a bit

- KILLGT takes 2 arguments
- arb KIL has no dst register
- add TODO about clause ending but currently piglit fp-kil passes and
  does not hang the card

was the culprit.. reverting it makes it work for me..

Any more information needed?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] Importing real strtod code

2009-10-09 Thread Kristian Høgsberg
On Thu, Oct 8, 2009 at 5:47 PM, Ian Romanick i...@freedesktop.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 The root cause of bug #23308 has been determined to be the use of strtod
 in our assembly and GLSL parsers.  When LANG is set to a locale that
 changes the radix from . to, say, ,, floating point numbers are not
 parsed correctly.

 It seems that the correct fix is to have _mesa_strtod actually implement
 strtod and ignore the locale setting.  I considered writing my own, but
 low-level floating point processing is one of those tricks best left to
 experts.  I've searched the net, and found an implementation.  It is
 extremely complex, and the code is quite archaic.

 What I found is David Gay's dtoa.c (http://www.netlib.org/fp/dtoa.c).
 Should I use this, or does anyone know of a better implementation?

GNU libc has strtod_l, which takes a locale_t as its last argument.
Use newlocale() to create a locale_t to pass to strtod_l and
freelocale() to free it.  We could create the locale up front and
store it in the context or probably even just as a global variable.
That doesn't solve the problem for non-glibc platforms, of course, but
pulling in a appropriately licensed strtod in that case is not a big
problem.

cheers,
Kristian

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


[Mesa3d-dev] [Bug 24425] rv770 hangs when trying to play nexuiz (mesa bisected)

2009-10-09 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=24425


Asbjørn Sannes a...@sannes.org changed:

   What|Removed |Added

Summary|rv770 hangs when trying to  |rv770 hangs when trying to
   |play mesa (bisected)|play nexuiz (mesa bisected)




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] Importing real strtod code

2009-10-09 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Rankin wrote:
 --- On Thu, 8/10/09, Brian Paul bri...@vmware.com wrote:
 I think that we could just bracket the call to
 _slang_compile() with the set/restore-locale calls.
 
 I'd hate to make an obvious suggestion, but... can't you just copy strtod() 
 code (without the locale support) from GLIBC? My basic research suggests that 
 the MIT license is compatible with the GPL...
 
 Core Mesa *is* licensed under the MIT license, isn't it?

This is sort of where I came up with the other proposal.  GLIBC is LGPL,
so copying code from there is not okay.  However, the code that I
mentioned earlier is the basis of the strtod implementation in the
FreeBSD libc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrPjBUACgkQX1gOwKyEAw+fjgCfVrIplzmIGr8yA6TEUjMNouc7
jo0An17wLOcJjBrAqCLiAr3UBOdXxc7g
=CLmL
-END PGP SIGNATURE-

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev


Re: [Mesa3d-dev] drawing with elements out of range

2009-10-09 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

michal wrote:

 Is there a desire to add out-of-bounds checking of every index element, 
 or is it being ignored on purpose for performance reasons?

The later.  The OpenGL spec allows implementations to crash buggy
applications anytime that preventing such a crash would impact the
performance of correct applications.  The only caveat is that the
implementation is not supposed to crash the system.  This means that we
have to add extra checks in versions of the driver that are loaded into
the X server, for example.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrPjQQACgkQX1gOwKyEAw/22ACfRH6QLk7ulJFPCHo1Kbls/K/h
PTAAnA0HK2D1tgEyIljrIE1NTHZbZwwJ
=eBXz
-END PGP SIGNATURE-

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev