Menu
▾
▴
mesa3d-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(10) |
Apr
(28) |
May
(41) |
Jun
(91) |
Jul
(63) |
Aug
(45) |
Sep
(37) |
Oct
(80) |
Nov
(91) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(48) |
Feb
(121) |
Mar
(126) |
Apr
(16) |
May
(85) |
Jun
(84) |
Jul
(115) |
Aug
(71) |
Sep
(27) |
Oct
(33) |
Nov
(15) |
Dec
(71) |
| 2002 |
Jan
(73) |
Feb
(34) |
Mar
(39) |
Apr
(135) |
May
(59) |
Jun
(116) |
Jul
(93) |
Aug
(40) |
Sep
(50) |
Oct
(87) |
Nov
(90) |
Dec
(32) |
| 2003 |
Jan
(181) |
Feb
(101) |
Mar
(231) |
Apr
(240) |
May
(148) |
Jun
(228) |
Jul
(156) |
Aug
(49) |
Sep
(173) |
Oct
(169) |
Nov
(137) |
Dec
(163) |
| 2004 |
Jan
(243) |
Feb
(141) |
Mar
(183) |
Apr
(364) |
May
(369) |
Jun
(251) |
Jul
(194) |
Aug
(140) |
Sep
(154) |
Oct
(167) |
Nov
(86) |
Dec
(109) |
| 2005 |
Jan
(176) |
Feb
(140) |
Mar
(112) |
Apr
(158) |
May
(140) |
Jun
(201) |
Jul
(123) |
Aug
(196) |
Sep
(143) |
Oct
(165) |
Nov
(158) |
Dec
(79) |
| 2006 |
Jan
(90) |
Feb
(156) |
Mar
(125) |
Apr
(146) |
May
(169) |
Jun
(146) |
Jul
(150) |
Aug
(176) |
Sep
(156) |
Oct
(237) |
Nov
(179) |
Dec
(140) |
| 2007 |
Jan
(144) |
Feb
(116) |
Mar
(261) |
Apr
(279) |
May
(222) |
Jun
(103) |
Jul
(237) |
Aug
(191) |
Sep
(113) |
Oct
(129) |
Nov
(141) |
Dec
(165) |
| 2008 |
Jan
(152) |
Feb
(195) |
Mar
(242) |
Apr
(146) |
May
(151) |
Jun
(172) |
Jul
(123) |
Aug
(195) |
Sep
(195) |
Oct
(138) |
Nov
(183) |
Dec
(125) |
| 2009 |
Jan
(268) |
Feb
(281) |
Mar
(295) |
Apr
(293) |
May
(273) |
Jun
(265) |
Jul
(406) |
Aug
(679) |
Sep
(434) |
Oct
(357) |
Nov
(306) |
Dec
(478) |
| 2010 |
Jan
(856) |
Feb
(668) |
Mar
(927) |
Apr
(269) |
May
(12) |
Jun
(13) |
Jul
(6) |
Aug
(8) |
Sep
(23) |
Oct
(4) |
Nov
(8) |
Dec
(11) |
| 2011 |
Jan
(4) |
Feb
(2) |
Mar
(3) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(1) |
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Daryll S. <da...@va...> - 2000-10-05 23:37:21
|
On Thu, Oct 05, 2000 at 03:41:42PM -0700, Allen Akin wrote: > Since 1994 I've been using the visinfo package that I wrote while at > SGI. Among other things, it's used in isfast and glean, and it had > some influence on Mark Kilgard's design for the display initialization > string in GLUT. Maybe this is something we should package up and include in GLU or something. It sounds like it would be generally useful and might discourage the use of glXChooseVisual. - |Daryll |
|
From: Allen A. <ak...@po...> - 2000-10-05 22:41:43
|
On Thu, Oct 05, 2000 at 02:36:30PM -0700, Michael Vance wrote: | On Thu, Oct 05, 2000 at 11:43:10AM -0600, Brian Paul wrote: | | > glXChooseVisual() really is poorly designed. Serious apps should | > avoid it and use a better visual selection method. | | Such as? Since 1994 I've been using the visinfo package that I wrote while at SGI. Among other things, it's used in isfast and glean, and it had some influence on Mark Kilgard's design for the display initialization string in GLUT. With visinfo, you write short Boolean expressions involving attribute variables and C operators that say exactly what visual attributes you want, plus sort keys that determine which visual is returned first if more than one meets the selection criteria. That way you don't run into the ambiguities that cause problems for glXChooseVisual(). Examples: "max rgb, max z" Deepest color buffer, deepest depth buffer -- roughly what glXChooseVisual is supposed to return if you specify nonzero color and depth attributes. "max rgb, z == 16, db" Deepest color buffer; depth buffer must be exactly 16 bits; double-buffered. "max rgb, min z" Deepest color buffer; shallowest available nonzero depth buffer. "max rgba, fast, conformant, accumrgba >= 2*rgba" Deepest RGBA that's hardware accelerated, passes the OpenGL conformance tests, and has an accumulation buffer at least twice as deep as the color buffer. "r%2 || g%2 || b%2, !s" Color buffer in which at least one channel has an odd number of bits; no stencil planes. And so on. This has enough expressive power that I've never felt the need for anything else, and it's been ported to most systems running OpenGL so it has relatively good availability. However, you can always roll your own using glXGetConfig() or other window-system-dependent query function.. Allen |
|
From: Brian P. <br...@va...> - 2000-10-05 22:17:33
|
Michael Vance wrote: > > On Thu, Oct 05, 2000 at 11:43:10AM -0600, Brian Paul wrote: > > > glXChooseVisual() really is poorly designed. Serious apps should > > avoid it and use a better visual selection method. > > Such as? For each visual on the display, interogate the GLX attributes with glXGetConfig(). Then rank the visuals according to your app's needs and use the top one. This probably isn't a big deal on PC systems since all the visuals typically have the same color depth, Z size, accum buffer size, etc. But when I was developing for SGI systems I learned that visual selection can be tricky when there's an assortment of color depths, Z sizes, accum sizes, etc. For example, on an Indigo2 with High IMPACT graphics, there's an R-4, G-4, B-4, A-4, double-buffered visual and an R-5, G-5, B-5, A-1, double-buffered visual. If your GLX choose visual attribute list has GLX_RED/GREEN/BLUE/ALPHA_SIZE=1 then it's not clear which of those two visuals you'll get, and it might be really important to the app to get the right one. This was especially complicated on Infinite Reality systems because it offered more than 120 visuals with all kinds of trade-offs between the depths of the color and ancillary buffers. -Brian |
|
From: Michael V. <bri...@lo...> - 2000-10-05 21:36:35
|
On Thu, Oct 05, 2000 at 11:43:10AM -0600, Brian Paul wrote: > glXChooseVisual() really is poorly designed. Serious apps should > avoid it and use a better visual selection method. Such as? m. -- Programmer "Ha ha." "Ha ha." "What are you laughing at?" Loki Software "Just the horror of being alive." http://lokigames.com/~briareos/ - Tony Millionaire |
|
From: Brian P. <br...@va...> - 2000-10-05 17:43:39
|
Allen Akin wrote: > > On Thu, Oct 05, 2000 at 08:16:30AM -0600, Brian Paul wrote: > | > | There's two possible solutions: > | > | 1. Modify Crystal Space to specify GLX_DEPTH_SIZE=1 or GLX_DEPTH_SIZE=16. > | > | 2. Modify Mesa so that a 16-bit (the default) depth buffer is chosen if > | GLX_DEPTH_SIZE is between 1 and 16. > | > | Any comments? > > I'd go for the second one. I've never been a great fan of the > glXChooseVisual semantics, but I think that option is a reasonable way > to patch them up. Done. glXChooseVisual() really is poorly designed. Serious apps should avoid it and use a better visual selection method. -Brian |
|
From: Allen A. <ak...@va...> - 2000-10-05 17:02:47
|
On Thu, Oct 05, 2000 at 08:16:30AM -0600, Brian Paul wrote: | | There's two possible solutions: | | 1. Modify Crystal Space to specify GLX_DEPTH_SIZE=1 or GLX_DEPTH_SIZE=16. | | 2. Modify Mesa so that a 16-bit (the default) depth buffer is chosen if | GLX_DEPTH_SIZE is between 1 and 16. | | Any comments? I'd go for the second one. I've never been a great fan of the glXChooseVisual semantics, but I think that option is a reasonable way to patch them up. Allen |
|
From: Brian P. <br...@va...> - 2000-10-05 14:41:00
|
Klaus Niederkrueger wrote: > > > > > This looks like pretty typical Z buffer precision > > issues. > > > > Read this: > > > > http://web2.airmail.net/sjbaker1/love_your_z_buffer.html > > > > ...then tell us if you still think it's a Mesa bug. > > > > Well, I send in another email saying that the Depthbuffer has only 8 bits, but this email does not seem to appear on the list (stupid elm). > > The thing I think is strange is that the same binaries of CS use 8 bits when they are running with Mesa-3.3 or 3.5 and 16 bits with Mesa 3.2, but maybe it is a bug of Crystal-space... > > No idea. I forgot to mention in my previous message that the support for N-bit depth buffers was new in Mesa 3.3. In 3.2 and earlier you always got a 16-bit depth buffer, unless you specially compiled Mesa otherwise. -Brian |
|
From: Klaus N. <kl...@ma...> - 2000-10-05 14:20:13
|
> > This looks like pretty typical Z buffer precision > issues. > > Read this: > > http://web2.airmail.net/sjbaker1/love_your_z_buffer.html > > ...then tell us if you still think it's a Mesa bug. > Well, I send in another email saying that the Depthbuffer has only 8 bits, but this email does not seem to appear on the list (stupid elm). The thing I think is strange is that the same binaries of CS use 8 bits when they are running with Mesa-3.3 or 3.5 and 16 bits with Mesa 3.2, but maybe it is a bug of Crystal-space... No idea. Klaus |
|
From: Brian P. <br...@va...> - 2000-10-05 14:17:04
|
Klaus Niederkrueger wrote:
>
> bash$ LD_PRELOAD=~/Mesa/src/.libs/libGL.so.1.2.030500 ./walktest funky -video=opengl
> Using alternative 3D driver: crystalspace.graphics3d.opengl
> Crystal Space version 0.17 r001 [Linux-Intel-GCC] (Wed, 1-Sep-2000).
> Created by Jorrit Tyberghein and others...
>
> Video driver GL/X version (direct renderer)
> Visual ID: 20, 16bit TrueColor
> Frame buffer: 16bit R5:G6:B5:A0, level 0, double buffered,
> Depth buffer: 8bit <<<------
> OpenGL renderer: Mesa X11 version 1.2 Mesa 3.5 beta
> Using windowed mode at resolution 640x480.
> Loading world '/lev/funky'...
>
> It's 8bit, while with Mesa-3.2 it is 16bit.
I grabbed the Crystal Space sources and grep'd for glXChooseVisual.
In plugins/video/canvas/openglx/glx2d.cpp in the csGraphics2DGLX::Open()
function I see this:
int desired_attributes[] =
{
GLX_RGBA,
GLX_DEPTH_SIZE, 8,
GLX_RED_SIZE, 4,
GLX_BLUE_SIZE, 4,
GLX_GREEN_SIZE, 4,
None,
None
};
The GLX spec says that this should choose a visual with the deepest depth
buffer of at least 8 bits. While this is perfectly legal, Mesa has a
problem with this. Mesa's GLX, as we all know, is not real a GLX but an
emulation and it can't do everything right.
When Mesa sees GLX_DEPTH_SIZE=0, it doesn't allocate a depth buffer.
If GLX_DEPTH_SIZE=1, it allocates a 16-bit depth buffer (the default
depth buffer size).
Otherwise, if GLX_DEPTH_SIZE=N and N>1, then Mesa allocates an N-bit
depth buffer. This allows one to get a deeper depth buffer (such as
24-bits) if needed. I didn't think anyone would ever request a depth
of 1 to 15 bits so the code is kind of dumb when that happens.
There's two possible solutions:
1. Modify Crystal Space to specify GLX_DEPTH_SIZE=1 or GLX_DEPTH_SIZE=16.
2. Modify Mesa so that a 16-bit (the default) depth buffer is chosen if
GLX_DEPTH_SIZE is between 1 and 16.
Any comments?
Is anyone on this list also involved in the Crystal Space project?
-Brian
|
|
From: Brian P. <br...@va...> - 2000-10-05 13:51:45
|
"Jacob (=Jouk) Jansen" wrote: > > Hi all, > > My compiler give me the following informationals. Although all tests run fine > I think one has to look into this. I'll fix this. I'm in the process of adding support for N texture units, where N > 2. Most of this code should be #ifdef'd out for now. -Brian |
|
From: Stephen J B. <sj...@li...> - 2000-10-05 12:45:06
|
On Wed, 4 Oct 2000, Klaus Niederkrueger wrote: > Hi, > > There seems to be a bug in the depth-buffer code. That looks very strong like an rounding-error or something. On > http://www.math.leidenuniv.nl/~klaus/bug.jpg > you can see a screenshot I made. With Mesa-3.2 it looks o.k. > > The error was produced by using Crystal-space. I believe it works like this (but I'm not sure): The walls are drawn with activated z-Buffer (but without z-Buffer testing) and afterwards objects are drawn with z-Buffer-test activated. This looks like pretty typical Z buffer precision issues. Read this: http://web2.airmail.net/sjbaker1/love_your_z_buffer.html ...then tell us if you still think it's a Mesa bug. ---- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://web2.airmail.net/sjbaker1 |
|
From: Klaus N. <kl...@ma...> - 2000-10-05 10:02:53
|
bash$ LD_PRELOAD=~/Mesa/src/.libs/libGL.so.1.2.030500 ./walktest funky -video=opengl Using alternative 3D driver: crystalspace.graphics3d.opengl Crystal Space version 0.17 r001 [Linux-Intel-GCC] (Wed, 1-Sep-2000). Created by Jorrit Tyberghein and others... Video driver GL/X version (direct renderer) Visual ID: 20, 16bit TrueColor Frame buffer: 16bit R5:G6:B5:A0, level 0, double buffered, Depth buffer: 8bit <<<------ OpenGL renderer: Mesa X11 version 1.2 Mesa 3.5 beta Using windowed mode at resolution 640x480. Loading world '/lev/funky'... It's 8bit, while with Mesa-3.2 it is 16bit. Klaus |
|
From: Li M. <mi...@mp...> - 2000-10-05 08:20:03
|
Hi, I think it's just because now Brian Paul is working on supporting 4 texture units. He modified a lot but hasn't yet change the MAX_TEXTURE_UNITS(in config.h) to 4. So u'v got such warnings. Li Ming Jacob =Jouk Jansen wrote: > Hi all, > > My compiler give me the following informationals. Although all tests run fine > I think one has to look into this. > > Jouk > > cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) STAGES.C > > VB->TexCoordPtr[2] = Transform( VB->store.TexCoord[2], > ......................^ > %CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo > unds specified for the array type. > at line number 519 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST > AGES.C;1 > > VB->TexCoordPtr[2] = Transform( VB->store.TexCoord[2], > ...........................^ |
|
From: <jo...@hr...> - 2000-10-05 07:16:47
|
Hi all,
My compiler give me the following informationals. Although all tests run fine
I think one has to look into this.
Jouk
cc /include=([-.include],[])/define=(FBIND=1)/name=(as_is,short) STAGES.C
VB->TexCoordPtr[2] = Transform( VB->store.TexCoord[2],
......................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 519 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[2] = Transform( VB->store.TexCoord[2],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 519 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[2] = Transform( VB->store.TexCoord[2],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 519 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[2] = Transform( VB->store.TexCoord[2],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 519 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[2] = Transform( VB->store.TexCoord[2],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 519 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
(ctx->Texture.Unit[3].func[VB->CullMode & 0x3])( VB, 3 );
.........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 532 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[3] = Transform( VB->store.TexCoord[3],
......................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 535 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[3] = Transform( VB->store.TexCoord[3],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 535 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[3] = Transform( VB->store.TexCoord[3],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 535 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[3] = Transform( VB->store.TexCoord[3],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 535 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[3] = Transform( VB->store.TexCoord[3],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 535 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[3] = Transform( VB->store.TexCoord[3],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 535 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
VB->TexCoordPtr[3] = Transform( VB->store.TexCoord[3],
...........................^
%CC-I-SUBSCRBOUNDS, In this statement, an array is being accessed outside the bo
unds specified for the array type.
at line number 535 in file $DISK2:[JOUKJ.PUBLIC.MESAGL.MESA_20001005.MESA.SRC]ST
AGES.C;1
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>------------------------------------------------------------------------------<
Jouk Jansen
jo...@hr...
Technische Universiteit Delft tttttttttt uu uu ddddddd
Nationaal centrum voor HREM tttttttttt uu uu dd dd
Rotterdamseweg 137 tt uu uu dd dd
2628 AL Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2781536 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: <jo...@hr...> - 2000-10-05 07:15:32
|
Hi All, >Update of /cvsroot/mesa3d/Mesa/src >In directory slayer.i.sourceforge.net:/tmp/cvs-serv15238 > >Modified Files: > triangle.c >Log Message: >fixed for divide-by-zero problem in optimized triangle functions (Klaus Niederkrueger) Tested -> it solves my problem -> thanks Jouk Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse >------------------------------------------------------------------------------< Jouk Jansen jo...@hr... Technische Universiteit Delft tttttttttt uu uu ddddddd Nationaal centrum voor HREM tttttttttt uu uu dd dd Rotterdamseweg 137 tt uu uu dd dd 2628 AL Delft tt uu uu dd dd Nederland tt uu uu dd dd tel. 31-15-2781536 tt uuuuuuu ddddddd >------------------------------------------------------------------------------< |
|
From: Brian P. <br...@va...> - 2000-10-04 16:50:58
|
Klaus Niederkrueger wrote: > > >I`m assuming that you`re using software rendering (Xlib driver). > > This is true...If I use Utah-GLX (Mach 64), the error does not appear. > If I use Mesa-3.2 in Software-mode it also does not appear. (With Mesa-3.3 it does, with 3.5 also). > > >When I`ve seen this sort of thing before it usually caused by using "bad" > >near/far clip plane positions. What are your arguments to glFrustum? > >If the ratio of far:near is greater than 1000 you should adjust the > >values. > > I don't know exactly: I could check it, but I don't have much time. I just took the normal crystal-space-code (compiled it) and used the demo 'walktest'. I had made some changes in the depth buffer GLX code to support arbitrary bits/Z at runtime. There might be something funny going on in Crystal Space's use of GLX. Please do the glGetIntergerv(GL_DEPTH_BITS, &bits) experiment. -Brian |
|
From: Klaus N. <kl...@ma...> - 2000-10-04 16:08:51
|
>I`m assuming that you`re using software rendering (Xlib driver). This is true...If I use Utah-GLX (Mach 64), the error does not appear. If I use Mesa-3.2 in Software-mode it also does not appear. (With Mesa-3.3 it does, with 3.5 also). >When I`ve seen this sort of thing before it usually caused by using "bad" >near/far clip plane positions. What are your arguments to glFrustum? >If the ratio of far:near is greater than 1000 you should adjust the >values. I don't know exactly: I could check it, but I don't have much time. I just took the normal crystal-space-code (compiled it) and used the demo 'walktest'. Klaus |
|
From: Brian P. <br...@va...> - 2000-10-04 14:54:26
|
Klaus Niederkrueger wrote: > > Hi, > > There seems to be a bug in the depth-buffer code. That looks very strong like an rounding-error or something. On > http://www.math.leidenuniv.nl/~klaus/bug.jpg > you can see a screenshot I made. With Mesa-3.2 it looks o.k. > > The error was produced by using Crystal-space. I believe it works like this (but I'm not sure): The walls are drawn with activated z-Buffer (but without z-Buffer testing) and afterwards objects are drawn with z-Buffer-test activated. I'm assuming that you're using software rendering (Xlib driver). When I've seen this sort of thing before it usually caused by using "bad" near/far clip plane positions. What are your arguments to glFrustum? If the ratio of far:near is greater than 1000 you should adjust the values. Also, you could check the depth of your Z buffer with glGetIntegerv(GL_DEPTH_BITS, &bits). I'd expect it to be 16 bits, but maybe it's not. -Brian |
|
From: Klaus N. <kl...@ma...> - 2000-10-04 13:14:09
|
Hi, There seems to be a bug in the depth-buffer code. That looks very strong like an rounding-error or something. On http://www.math.leidenuniv.nl/~klaus/bug.jpg you can see a screenshot I made. With Mesa-3.2 it looks o.k. The error was produced by using Crystal-space. I believe it works like this (but I'm not sure): The walls are drawn with activated z-Buffer (but without z-Buffer testing) and afterwards objects are drawn with z-Buffer-test activated. Greetings Klaus |
|
From: <jo...@hr...> - 2000-09-29 07:06:29
|
Hi,
>On monday and tuesday I have two free days, so I will fix the error then (at least I hope).
>The fix should be pretty easy, if dx_tex == dy_tex == 0.0f, then the program does not move over the texture, so one can fill the whole array rgba[n] with the corresponding (constant) texel, indeed if only dy_tex == 0.0f one can simplify the fill-code a
>lot, but I don't know if this case is generic enough to be worked into the code.
OK thanks
>By the way: Three questions.
>
>1. When this bug happens, what is the value of dTdx, dvdx?
At the moment of the crash (so just ofter printing "test4" in my code of my
previous mail) I find
dTdx = -0.4115263E-02
dvdx = -0.1286020E-03
>2. I usually test my code-changes by typing "LD_PRELOAD=~/Mesa/src/.libs/libGL.so demoprog". How can I tell "gdb" that I want to use this library when debugging?
Yeah, but I'm using OpenVMS and not a Unix-flavour. So for me it is
completely different. I just created a non-sharable object library to perform
the debugging. This should also be possible on Unix.
>3. This is a suggestions. I believe that the MIPMAPPING-code calculates which
>texture-level to use for every pixel it draws.
>Since the level of detail should be a monotone function over the
>array rgba[n], wouldn't it be possible (in the case GL_NEAREST_MI
>PMAP_NEAREST and GL_LINEAR_MIPMAP_NEAREST) to calculate the lod at the
>beginning of the array and at the end of the array and if lod is equal at
>these points, to just fill the whole array with a constant level of detail?
Sounds good, but I'm not an expert.
Jouk
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>------------------------------------------------------------------------------<
Jouk Jansen
jo...@hr...
Technische Universiteit Delft tttttttttt uu uu ddddddd
Nationaal centrum voor HREM tttttttttt uu uu dd dd
Rotterdamseweg 137 tt uu uu dd dd
2628 AL Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2781536 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: Brian P. <br...@va...> - 2000-09-28 17:18:49
|
Klaus Niederkrueger wrote: > > Hi, > > On monday and tuesday I have two free days, so I will fix the error then (at least I hope). > The fix should be pretty easy, if dx_tex == dy_tex == 0.0f, then the program does not move over the texture, so one can fill the whole array rgba[n] with the corresponding (constant) texel, indeed if only dy_tex == 0.0f one can simplify the fill-code a lot, but I don't know if this case is generic enough to be worked into the code. > > By the way: Three questions. > > 1. When this bug happens, what is the value of dTdx, dvdx? > > 2. I usually test my code-changes by typing "LD_PRELOAD=~/Mesa/src/.libs/libGL.so demoprog". How can I tell "gdb" that I want to use this library when debugging? I use LD_LIBRARY_PATH to point to my libGL.so and gdb (version=19991004) seems to find it just fine. I can't set breakpoints in Mesa code until the library has actually been loaded so I'll first break in main() and then set my Mesa breakpoints when I've stopped in main(). Hope this helps. > 3. This is a suggestions. I believe that the MIPMAPPING-code calculates which texture-level to use for every pixel it draws. Since the level of detail should be a monotone function over the array rgba[n], wouldn't it be possible (in the case GL_NEAREST_MIPMAP_NEAREST and GL_LINEAR_MIPMAP_NEAREST) to calculate the lod at the beginning of the array and at the end of the array and if lod is equal at these points, to just fill the whole array with a constant level of detail? Yes, I believe that's true. -Brian |
|
From: Klaus N. <kl...@ma...> - 2000-09-28 16:13:13
|
Hi, On monday and tuesday I have two free days, so I will fix the error then (at least I hope). The fix should be pretty easy, if dx_tex == dy_tex == 0.0f, then the program does not move over the texture, so one can fill the whole array rgba[n] with the corresponding (constant) texel, indeed if only dy_tex == 0.0f one can simplify the fill-code a lot, but I don't know if this case is generic enough to be worked into the code. By the way: Three questions. 1. When this bug happens, what is the value of dTdx, dvdx? 2. I usually test my code-changes by typing "LD_PRELOAD=~/Mesa/src/.libs/libGL.so demoprog". How can I tell "gdb" that I want to use this library when debugging? 3. This is a suggestions. I believe that the MIPMAPPING-code calculates which texture-level to use for every pixel it draws. Since the level of detail should be a monotone function over the array rgba[n], wouldn't it be possible (in the case GL_NEAREST_MIPMAP_NEAREST and GL_LINEAR_MIPMAP_NEAREST) to calculate the lod at the beginning of the array and at the end of the array and if lod is equal at these points, to just fill the whole array with a constant level of detail? O.k. I will have to go back to work now... Bye Klaus |
|
From: Brian P. <br...@va...> - 2000-09-28 15:15:35
|
"Jacob (=Jouk) Jansen" wrote: > > Hi All, > > I detected a problem in near_persp_textured_triangle defined in triangle.c. > Below I reprinted the INNER_LOOP to show what goes wrong: > The INNER_LOOP is started for one case with > ss=dsdx=0 > tt=vv > and thus dx_tex=dy_tex=0.0. > For these values the path leads to the point where I inserted the print > of "test4". Than it crashes while it tries to divide by dx_tex which is > zero. > > What is intended here for this special case? > > Jouk I'm forwarding this report to Klaus Niederkrueger <kl...@ma...> since he wrote the function and I'm not sure that he's on this mailing list. If the bug can't be fixed this optimized triangle function will have to be disabled. -Brian |
|
From: <jo...@hr...> - 2000-09-28 10:40:23
|
Hi All,
I detected a problem in near_persp_textured_triangle defined in triangle.c.
Below I reprinted the INNER_LOOP to show what goes wrong:
The INNER_LOOP is started for one case with
ss=dsdx=0
tt=vv
and thus dx_tex=dy_tex=0.0.
For these values the path leads to the point where I inserted the print
of "test4". Than it crashes while it tries to divide by dx_tex which is
zero.
What is intended here for this special case?
Jouk
excerpt from triangle.c (procedure near_persp_textured_triangle):
#define INNER_LOOP( LEFT, RIGHT, Y ) \
{ \
GLint i = 0; \
const GLint n = RIGHT-LEFT; \
GLdepth zspan[MAX_WIDTH]; \
GLubyte rgba[MAX_WIDTH][4]; \
(void)uu; /* please GCC */ \
if (n > 0) { /* called with ss=dsdx=0 , tt=vv */ \
GLfloat SS = ss * sscale; \
GLfloat TT = tt * tscale; \
GLfloat dSdx = dsdx * sscale; \
GLfloat dTdx = dtdx * tscale; \
GLfloat x_tex = SS / vv; \
GLfloat y_tex = TT / vv; \
GLfloat dx_tex = (SS + n * dSdx) / (vv + n * dvdx) - x_tex; \
GLfloat dy_tex = (TT + n * dTdx) / (vv + n * dvdx) - y_tex; \
GLubyte *dest = rgba[0]; \
x_tex += BIAS; \
y_tex += BIAS; \
printf( "dx_tex , dy_tex , n : %f %f %d\n" , dx_tex , dy_tex , n );\
if (FABSF(dx_tex) < n && FABSF(dy_tex) < n) { \
if (FABSF(dx_tex) > FABSF(dy_tex)) { \
GLfloat nominator = - SS - vv * BIAS; \
GLfloat denominator = dvdx * BIAS + dSdx; \
GLfloat dy_dx = dy_tex / dx_tex; \
GLfloat dx_dy; \
printf( "test1\n" );\
if (dy_dx != 0.0f) \
dx_dy= 1.0f/dy_dx; \
if (dx_tex > 0.0f) { \
if (dy_tex > 0.0f) { \
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN1(NEAREST_RGB;MODULATE,3, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN1(NEAREST_RGB_REPLACE,3, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN1(NEAREST_RGB;BLEND,3, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN1(NEAREST_RGB;ADD,3, Y_X_TEX_COORD); \
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN1(NEAREST_RGBA;MODULATE,4, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN1(NEAREST_RGBA;DECAL,4, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN1(NEAREST_RGBA;BLEND,4, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN1(NEAREST_RGBA;ADD,4, Y_X_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN1(NEAREST_RGBA_REPLACE,4, Y_X_TEX_COORD);\
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
} \
} \
else { /* dy_tex <= 0.0f */ \
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN2(NEAREST_RGB;MODULATE,3, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN2(NEAREST_RGB_REPLACE,3, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN2(NEAREST_RGB;BLEND,3, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN2(NEAREST_RGB;ADD,3, Y_X_TEX_COORD); \
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN2(NEAREST_RGBA;MODULATE,4, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN2(NEAREST_RGBA;DECAL,4, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN2(NEAREST_RGBA;BLEND,4, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN2(NEAREST_RGBA;ADD,4, Y_X_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN2(NEAREST_RGBA_REPLACE,4, Y_X_TEX_COORD);\
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
} \
} \
} \
else { /* dx_tex < 0.0f */ \
printf( "test2\n" );\
if (dy_tex > 0.0f) { \
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN3(NEAREST_RGB;MODULATE,3, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN3(NEAREST_RGB_REPLACE,3, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN3(NEAREST_RGB;BLEND,3, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN3(NEAREST_RGB;ADD,3, Y_X_TEX_COORD); \
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN3(NEAREST_RGBA;MODULATE,4, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN3(NEAREST_RGBA;DECAL,4, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN3(NEAREST_RGBA;BLEND,4, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN3(NEAREST_RGBA;ADD,4, Y_X_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN3(NEAREST_RGBA_REPLACE,4, Y_X_TEX_COORD);\
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
} \
} \
else { /* dy_tex <= 0.0f */ \
printf( "test3\n" );\
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN4(NEAREST_RGB;MODULATE,3, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN4(NEAREST_RGB_REPLACE,3, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN4(NEAREST_RGB;BLEND,3, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN4(NEAREST_RGB;ADD,3, Y_X_TEX_COORD); \
break; \
default: \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN4(NEAREST_RGBA;MODULATE,4, Y_X_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN4(NEAREST_RGBA;DECAL,4, Y_X_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN4(NEAREST_RGBA;BLEND,4, Y_X_TEX_COORD); \
break; \
case GL_ADD: \
SPAN4(NEAREST_RGBA;ADD,4, Y_X_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN4(NEAREST_RGBA_REPLACE,4, Y_X_TEX_COORD);\
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
} \
} \
} \
} \
else { \
GLfloat swap; \
GLfloat dy_dx; \
GLfloat dx_dy; \
GLfloat nominator, denominator; \
/* swap some x-values and y-values */ \
SS = TT; \
dSdx = dTdx; \
swap = x_tex, x_tex = y_tex, y_tex = swap; \
swap = dx_tex, dx_tex = dy_tex, dy_tex = swap; \
printf( "test4\n" ); /*and BANG on the next statement */ \
dy_dx = dy_tex / dx_tex; \
nominator = - SS - vv * BIAS; \
denominator = dvdx * BIAS + dSdx; \
if (dy_dx != 0.0f) \
dx_dy= 1.0f/dy_dx; \
if (dx_tex > 0.0f) { \
if (dy_tex > 0.0f) { \
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN1(NEAREST_RGB;MODULATE,3, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN1(NEAREST_RGB_REPLACE,3, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN1(NEAREST_RGB;BLEND,3, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN1(NEAREST_RGB;ADD,3, X_Y_TEX_COORD); \
break; \
default: /* unexpected env mode */ \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN1(NEAREST_RGBA;MODULATE,4, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN1(NEAREST_RGBA;DECAL,4, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN1(NEAREST_RGBA;BLEND,4, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN1(NEAREST_RGBA;ADD,4, X_Y_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN1(NEAREST_RGBA_REPLACE,4, X_Y_TEX_COORD);\
break; \
default: \
abort(); \
} \
break; \
} \
} \
else { /* dy_tex <= 0.0f */ \
printf( "test5\n" );\
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN2(NEAREST_RGB;MODULATE,3, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN2(NEAREST_RGB_REPLACE,3, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN2(NEAREST_RGB;BLEND,3, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN2(NEAREST_RGB;ADD,3, X_Y_TEX_COORD); \
break; \
default: \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN2(NEAREST_RGBA;MODULATE,4, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN2(NEAREST_RGBA;DECAL,4, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN2(NEAREST_RGBA;BLEND,4, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN2(NEAREST_RGBA;ADD,4, X_Y_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN2(NEAREST_RGBA_REPLACE,4, X_Y_TEX_COORD);\
break; \
default: \
abort(); \
} \
break; \
} \
} \
} \
else { /* dx_tex < 0.0f */ \
printf( "test6\n" );\
if (dy_tex > 0.0f) { \
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN3(NEAREST_RGB;MODULATE,3, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN3(NEAREST_RGB_REPLACE,3, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN3(NEAREST_RGB;BLEND,3, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN3(NEAREST_RGB;ADD,3, X_Y_TEX_COORD); \
break; \
default: \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN3(NEAREST_RGBA;MODULATE,4, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN3(NEAREST_RGBA;DECAL,4, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN3(NEAREST_RGBA;BLEND,4, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN3(NEAREST_RGBA;ADD,4, X_Y_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN3(NEAREST_RGBA_REPLACE,4, X_Y_TEX_COORD);\
break; \
default: \
abort(); \
} \
break; \
} \
} \
else { /* dy_tex <= 0.0f */ \
printf( "test7\n" );\
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
SPAN4(NEAREST_RGB;MODULATE,3, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
case GL_REPLACE: \
SPAN4(NEAREST_RGB_REPLACE,3, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN4(NEAREST_RGB;BLEND,3, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN4(NEAREST_RGB;ADD,3, X_Y_TEX_COORD); \
break; \
default: \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
SPAN4(NEAREST_RGBA;MODULATE,4, X_Y_TEX_COORD);\
break; \
case GL_DECAL: \
SPAN4(NEAREST_RGBA;DECAL,4, X_Y_TEX_COORD); \
break; \
case GL_BLEND: \
SPAN4(NEAREST_RGBA;BLEND,4, X_Y_TEX_COORD); \
break; \
case GL_ADD: \
SPAN4(NEAREST_RGBA;ADD,4, X_Y_TEX_COORD); \
break; \
case GL_REPLACE: \
SPAN4(NEAREST_RGBA_REPLACE,4, X_Y_TEX_COORD);\
break; \
default: \
abort(); \
} \
break; \
} \
} \
} \
} \
} \
else { \
printf( "test8\n" );\
switch (format) { \
case GL_RGB: \
switch (envmode) { \
case GL_MODULATE: \
OLD_SPAN(NEAREST_RGB;MODULATE,3); \
break; \
case GL_DECAL: \
case GL_REPLACE: \
OLD_SPAN(NEAREST_RGB_REPLACE,3); \
break; \
case GL_BLEND: \
OLD_SPAN(NEAREST_RGB;BLEND,3); \
break; \
case GL_ADD: \
OLD_SPAN(NEAREST_RGB;ADD,3); \
break; \
default: \
abort(); \
} \
break; \
case GL_RGBA: \
switch(envmode) { \
case GL_MODULATE: \
OLD_SPAN(NEAREST_RGBA;MODULATE,4); \
break; \
case GL_DECAL: \
OLD_SPAN(NEAREST_RGBA;DECAL,4); \
break; \
case GL_BLEND: \
OLD_SPAN(NEAREST_RGBA;BLEND,4); \
break; \
case GL_ADD: \
OLD_SPAN(NEAREST_RGBA;ADD,4); \
break; \
case GL_REPLACE: \
OLD_SPAN(NEAREST_RGBA_REPLACE,4); \
break; \
default: \
abort(); \
} \
break; \
} \
} \
gl_write_rgba_span( ctx, n, LEFT, Y, zspan, rgba, GL_POLYGON );\
ffr = ffg = ffb = ffa = 0; \
} \
} \
#include "tritemp.h"
#undef OLD_SPAN
#undef SPAN1
#undef SPAN2
#undef SPAN3
#undef SPAN4
#undef X_Y_TEX_COORD
#undef Y_X_TEX_COORD
#undef DRAW_LINE
#undef BIAS
}
Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse
>------------------------------------------------------------------------------<
Jouk Jansen
jo...@hr...
Technische Universiteit Delft tttttttttt uu uu ddddddd
Nationaal centrum voor HREM tttttttttt uu uu dd dd
Rotterdamseweg 137 tt uu uu dd dd
2628 AL Delft tt uu uu dd dd
Nederland tt uu uu dd dd
tel. 31-15-2781536 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: T. <th...@ec...> - 2000-09-28 09:09:36
|
I have compiled and installed Mesa 3.1 without problems or errors
but the demos don't work and gives a segmentation fault
My system is: Linux distribution (based on Mandrake 6.0).
ATI Rage 128 GL
I have test compil with "make linux", and i have no problems.
Which parameters could i try to success
thanks
R. thibaud
--
|
102 messages has been excluded from this view by a project administrator.
