Re: [Mesa3d-dev] drawing with elements out of range
-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
Re: [Mesa3d-dev] Importing "real" strtod code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Rankin wrote: > --- On Thu, 8/10/09, Brian Paul 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
[Mesa3d-dev] [Bug 24425] rv770 hangs when trying to play nexuiz (mesa bisected)
http://bugs.freedesktop.org/show_bug.cgi?id=24425 Asbjørn Sannes 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
On Thu, Oct 8, 2009 at 5:47 PM, Ian Romanick 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] New: rv770 hangs when trying to play mesa (bisected)
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 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] [PATCH] draw: Do an out-of-bounds check on array elements.
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
Re: [Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.
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.
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.
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.
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.
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.
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.
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 > 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; \ > + > } \ >
[Mesa3d-dev] [PATCH] draw: Do an out-of-bounds check on array elements.
From 5ebc14fc47a5e31b3c6be54142550bdf2ac093df Mon Sep 17 00:00:00 2001 From: Michal Krol 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] Importing "real" strtod code
On Fri, 2009-10-09 at 13:06 +0100, José Fonseca wrote: > On Fri, 2009-10-09 at 03:32 -0700, Chris Rankin wrote: > > --- On Fri, 9/10/09, Robert Noland 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 > > AFAIK all FSF sanctioned projects are copyright FSF. It's one of the > condition to submit patches to those projects that you have to sign and > mail a statement assigning copyright to FSF, so that they can legally > defend the project and other stuff. > > There's also http://sourceware.org/newlib/ which appears to be a BSD > like license. For that matter, there is always the version from FreeBSD, which is of course BSD licensed. robert. > Jose > -- Robert Noland 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
On Fri, 2009-10-09 at 03:32 -0700, Chris Rankin wrote: > --- On Fri, 9/10/09, Robert Noland 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 AFAIK all FSF sanctioned projects are copyright FSF. It's one of the condition to submit patches to those projects that you have to sign and mail a statement assigning copyright to FSF, so that they can legally defend the project and other stuff. There's also http://sourceware.org/newlib/ which appears to be a BSD like license. Jose -- 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
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
Re: [Mesa3d-dev] drawing with elements out of range
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
[Mesa3d-dev] drawing with elements out of range
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] Importing "real" strtod code
--- On Fri, 9/10/09, Robert Noland 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
Re: [Mesa3d-dev] Importing "real" strtod code
On Fri, 2009-10-09 at 01:03 -0700, Chris Rankin wrote: > --- On Thu, 8/10/09, Brian Paul 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 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
--- On Thu, 8/10/09, Brian Paul 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
[Mesa3d-dev] [Bug 24334] mesa git fails to build with xf86vidmodeproto 2.3
http://bugs.freedesktop.org/show_bug.cgi?id=24334 --- Comment #2 from Aidan Marks 2009-10-09 00:55:26 PST --- Perhaps just demand a newer libXxf86vm. On gentoo I emerged libXxf86vm-1.1.0 and it's all working again. -- 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