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: Grzegorz J. <gr...@po...> - 2001-08-01 17:49:57
|
Sorry , i didn't look at it exacly and don't say exacly what do i do: So.: i just take file MesaDemos-3.4.2.tar.gz and ungzip, and untar it. go into Mesa-3.4.2/demos dir type in make and recive make: *** No rule to make target `../configure.in', needed `Makefile.in'. Stop. Maybe i en doing something wrong, i don't know. But for me every thing is ok. Oh, and of course i have got Mesa-3.4.2 glut, glu installed and libGlide (becouse i em using voodoo II). Thx. -- Jest niezly ... i liscik napisze OnetKomunikator [ http://ok.onet.pl/instaluj.html ] |
|
From: Sven M. H. <pe...@gm...> - 2001-08-01 15:44:47
|
On Wed, Aug 01, 2001 at 01:20:48PM +0100, Grzegorz Jaskiewicz wrote: > On Wed, 1 Aug 2001 14:06:17 +0200, Sven M. Hallberg wrote: > >On Wed, Aug 01, 2001 at 10:52:04AM +0100, Grzegorz Jaskiewicz wrote: > >> Can You describe me , how should i make examples ? becouse each > >>time i do make somefile it tolds me that makefile.in is missing? > > > >Did you get from CVS and forget to run bootstrap? > > no just tar.gz file (every from 3.0 to 3.4). Weird, if the file is really missing, that's a packaging error. Brian, can you verify this? -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |
|
From: Grzegorz J. <gr...@po...> - 2001-08-01 12:11:00
|
On Wed, 1 Aug 2001 14:06:17 +0200, Sven M. Hallberg wrote: >On Wed, Aug 01, 2001 at 10:52:04AM +0100, Grzegorz Jaskiewicz= wrote: >> Can You describe me , how should i make examples ? becouse= each >>time i do make somefile it tolds me that makefile.in is= missing? > >Did you get from CVS and forget to run bootstrap? > >-Sven > no just tar.gz file (every from 3.0 to 3.4). >-- >"Would the All-Seeing Eye please look in my direction?" > [ KeyID........: 0xC297FEAB ] > [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297= FEAB >] > >_______________________________________________ >Mesa3d-dev mailing list >Mes...@li... >http://lists.sourceforge.net/lists/listinfo/mesa3d-dev "Cogito ergo sum", he said, and than disappeared.......... -- Grzegorz Jaskiewicz, gr...@po... on 08-01-2001 You can write also to: gja...@at... , gj...@wp... ,= gr...@po... Tel.:+48 608 892 083 Gadu Gadu : 915051 -- Jest niezly ... i liscik napisze OnetKomunikator [ http://ok.onet.pl/instaluj.html ] |
|
From: Sven M. H. <pe...@gm...> - 2001-08-01 12:03:43
|
On Wed, Aug 01, 2001 at 10:52:04AM +0100, Grzegorz Jaskiewicz wrote: > Can You describe me , how should i make examples ? becouse each time i do make somefile it tolds me that makefile.in is missing? Did you get from CVS and forget to run bootstrap? -Sven -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |
|
From: Grzegorz J. <gr...@po...> - 2001-08-01 09:42:13
|
Can You describe me , how should i make examples ? becouse each= time i do make somefile it tolds me that makefile.in is= missing? Other thing, to windows Mesa users - how much faster is Mesa in= generic mode in comparation to SGI opengl 1.2 ? "Cogito ergo sum", he said, and than disappeared.......... -- Grzegorz Jaskiewicz, gr...@po... on 08-01-2001 You can write also to: gja...@at... , gj...@wp... ,= gr...@po... Tel.:+48 608 892 083 Gadu Gadu : 915051 -- Jest niezly ... i liscik napisze OnetKomunikator [ http://ok.onet.pl/instaluj.html ] |
|
From: <no...@so...> - 2001-08-01 05:18:32
|
Bugs item #442527, was opened at 2001-07-18 11:46 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=442527&group_id=3 Category: mesa-core Group: Rendering Error Status: Open Resolution: None Priority: 5 Submitted By: Michael Saunders (rms7326) Assigned to: Nobody/Anonymous (nobody) Summary: glMaterial and quad strips with lighting Initial Comment: We are using the Mesa 3.5 build on Linux and due to bug #441859 we are forced to use glMaterial instead of glColorMaterial. We have two sided lighting and a single color surface with quad strips in use. When the plot is translated across the left or bottom edge of the viewport one quad in a strip occasionally changes it's lighting to that of a previously drawn strip. If the strips are entirely within the viewport then no problems occur. Also if we turn off quad strips the problem goes away as well. We tried triangle strips and have not yet noticed the problem. This should similar to the problems that we were experiencing in version Mesa 3.4.2 where pixel buffers were being overwritten with wide lines. One particular point of interest is that our Solaris 5 and 7 builds with Mesa 3.5 do not exhibit this bad lighting behavior. Also note that on these two platforms we compile Mesa with the --disable-sparc option. Another point of interest that if we add or remove lines to our plot the quad that was previously exhibiting the problem is drawn correctly and another quad has problems. ---------------------------------------------------------------------- >Comment By: Keith Whitwell (keithw) Date: 2001-07-31 22:18 Message: Logged In: YES user_id=979 Please retry with current cvs, if possible submit a demo to excersize the problem. Keith ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=442527&group_id=3 |
|
From: <no...@so...> - 2001-08-01 05:17:47
|
Bugs item #441859, was opened at 2001-07-16 17:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=441859&group_id=3 Category: mesa-core Group: Rendering Error Status: Open Resolution: None Priority: 5 Submitted By: Michael Saunders (rms7326) Assigned to: Nobody/Anonymous (nobody) Summary: glColorMaterial fails with strips Initial Comment: Using glColorMaterial(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE) in conjunction with GL_QUAD_STRIP blocks does not always color/light the surface correctly. The first few strips shade well and then suddenly the strip turns black. This occurs only when lighting is used. If we turn lighting off the strips are colored correctly. We noticed that if we deliver a color at each vertex then glColorMaterial seems to track lighting correctly. I should note that this problem occurs on Intel Linux 2.2 machine but not on our Solaris 7 machine. One difference between the two builds is that I compiled the Solaris 7 platform so that it did not use the Sparc ASM code (i.e. USE_SPARC_ASM is commented out in conf.h because it won't compile otherwise). So I suppose it is possible that the problem is in that or other platform specific code (including the graphics card I suppose). Our linux machine has a GForce 2 Ulta. ---------------------------------------------------------------------- >Comment By: Keith Whitwell (keithw) Date: 2001-07-31 22:17 Message: Logged In: YES user_id=979 Please retry with latest cvs, if problem persists, can you submit a demo program which excercises it? Keith ---------------------------------------------------------------------- Comment By: Michael Saunders (rms7326) Date: 2001-07-17 10:39 Message: Logged In: YES user_id=217333 After further investigation I discovered that I mistated when I said that Solaris 7 did not exhibit the problem. This is not true and I was able to get Solaris 5 and 7 to fail as well. I tried to reduce the problem to as small as possible. While I was doing this I notied some interesting points. 1) If we turned off drawing of the lines strips that are also in this plot the shading problems went away. Next I ran a larger problem and discoverd that with larger problems it didn't matter if I turned the line strips on or not. 2) When I linked the debug build of our application to the release build of the Mesa 3.5 library the problem did not exhibit itself. However when I linked the release build of our application to the release build of the Mesa 3.5 library the problem did exhibit itself. Initially I had assumed that we must be sending different instructions to Mesa with our debug and release builds. So I turned on our logging feature which outputs the OpenGL statements delivered to Mesa and compared the two. The diffs were identical. This leads me to believe that the problem is an uninitialized variable inside the code that processes strips and tracks the color and lighting (glColorMaterial). I have included the log output as an attachment. The instructions are all executable so if you need to paste it into a c program it should work fine. The log contains all the instructions send to Mesa with their respective arguments. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=441859&group_id=3 |
|
From: Mike A. H. <mh...@re...> - 2001-08-01 02:54:19
|
Is the libGLw stuff that comes with the Mesa sources, and X considered stable? Is it currently developer supported and actively maintained? A perusal of the sources, Changelogs, etc it appears to be idle and only untested beta quality. I've recieved a few requests to add this library to our Mesa releases but want to ensure that it is something that is stable and maintained beforehand. TIA ---------------------------------------------------------------------- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris ---------------------------------------------------------------------- |
|
From: Eric P. <eri...@di...> - 2001-07-31 21:23:10
|
Ha, found it, I need to link with the libglide dso... Sorry about the bandwidth. (I suppose there's a configure option to avoid this...) -- eric plante, software developer, effects, discreet |
|
From: Eric P. <eri...@di...> - 2001-07-31 21:04:24
|
A few useless precisions.. 1. Ignore the comments at the beginning of the .c, I just used the file the comment is from to get the glut calls right rather than looking them up. 2. On netscsape mail with attachments set to inline I see my gzipped text file as garbage (the mime type is wrong). Just turn off Attachments inline in the view menu and shift-click. Name the file by adding a .gz extension because netscape removes it (bug) and gunzip will refuse to uncompress it (bug also). You know the drill. Thanks, (and oh no I'll get that guy's autoreply again), -- eric plante, software developer, effects, discreet |
|
From: Eric P. <eri...@di...> - 2001-07-31 20:50:08
|
On Linux. And lots of them. Am I missing something? This is a straight build with configure --enable-static --disable-shared. Compiling a simple glut program (included) yields what you will find in undefs.txt.gz . The compile line is included in the beginning of that file. Switching to shared libs (although I must admit those are from the FireGL drivers) will make it compile fine. I _suppose_ it's just a case of configuration mistake for autoconf (why does that sound wierd ;) )... -- eric plante, software developer, effects, discreet |
|
From: Igor P. <igo...@ma...> - 2001-07-31 10:50:56
|
Hello. I'm using XFree86 4.1.0 on FreeBSD 4.3 machine (motherboard on i815EP chip). Kernel supports AGP module (arg.ko), and I load it at startup (but one detail: as I looked through AGP kernel module sources, I have not found my i815EP chip in supported chips, may be this is cause?). After configuring configuration X configuration file, how it was said in documentation for my ATI RADEON AGP card, when running "startx", I am getting an error message "[drmOpen]: Failed". All messages before, said, that RADEON card have been detected, and all needed libraries are loaded. After this message X server told, that DRI is disabled. May be somebody could tell me, where I was wrong? P.S. I know that this is not XFree mailing list, but I've sent emails there, but got no answer. Best regards I. Pokrovsky |
|
From: <no...@so...> - 2001-07-30 16:28:22
|
Bugs item #212069, was opened at 2000-08-16 07:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=212069&group_id=3 Category: mesa-core Group: Rendering Error Status: Open Resolution: Fixed Priority: 5 Submitted By: Diego Santa Cruz (dsanta) Assigned to: Brian Paul (brianp) Summary: Incorrect lighting for revolution NURBS surface Initial Comment: Rendering revolution NURBS surfaces with the GLU NURBS renderer in MESA 3.2.1 (possibly others) and GL_AUTO_NORMAL enabled is incorrect. The shading does not correspond to a revolution surface, it has sharp shade transitions between the circular segments. This is probably in connection with the double knots in an order 3 NURB. The problem also appears when using remote display from an IRIX 6.5 machine with SGI's GL, so the problem probably lies in the evaluators of the Mesa GL library, not in Mesa's GLU. Display with SGI's GL and GLU on an IRIX 6.5 machine is OK, so the problem is not in the model or application code. I can provide application code if needed. An example NURBS where this happens: NurbsSurface { pType P3 uOrder 4 vOrder 3 uKnot [.58528, .61804, .68416, .80452, 1, 1, 1, 1] vKnot [0, 0, 0, .5, .5, 1, 1, 1] controlPoint [.70224 -.253141 0 1 .82956 -.263243 0 1 .93484 -.251769 0 1 1 -.24 0 1 .496559 -.178998 .178998 .707107 .586588 -.186141 .186141 .707107 .661032 -.178028 .178028 .707107 .707107 -.169706 .169706 .707107 .70224 0 .253141 1 .82956 0 .263243 1 .93484 0 .251769 1 1 0 .24 1 .496559 .178998 .178998 .707107 .586588 .186141 .186141 .707107 .661032 .178028 .178028 .707107 .707107 .169706 .169706 .707107 .70224 .253141 0 1 .82956 .263243 0 1 .93484 .251769 0 1 1 .24 0 1] } MESA_INFO gives: X/Mesa visual = 0x8052bd0 X/Mesa dithered pf = 5 X/Mesa undithered pf = 5 X/Mesa level = 0 X/Mesa depth = 24 X/Mesa bits per pixel = 32 X/Mesa visual = 0x8052bd0 X/Mesa dithered pf = 5 X/Mesa undithered pf = 5 X/Mesa level = 0 X/Mesa depth = 24 X/Mesa bits per pixel = 32 Mesa GL_VERSION = 1.2 Mesa 3.2.1 Mesa GL_RENDERER = Mesa X11 Mesa GL_VENDOR = Brian Paul Mesa GL_EXTENSIONS = GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_logic_op GL_EXT_blend_subtract GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_vertex_array GL_EXT_texture_object GL_EXT_texture3D GL_MESA_window_pos GL_MESA_resize_buffers GL_EXT_shared_texture_palette GL_EXT_rescale_normal GL_EXT_abgr GL_SGIS_texture_edge_clamp GL_EXT_stencil_wrap GL_INGR_blend_func_separate GL_ARB_multitexture GL_NV_texgen_reflection GL_PGI_misc_hints GL_EXT_compiled_vertex_array GL_EXT_clip_volume_hint ---------------------------------------------------------------------- >Comment By: Diego Santa Cruz (dsanta) Date: 2001-07-30 09:28 Message: Logged In: YES user_id=64464 Tested with Mesa 3.5 and the bug is not fixed. The test program nurbs_revol.c still produces the problem. ---------------------------------------------------------------------- Comment By: Diego Santa Cruz (dsanta) Date: 2001-05-10 08:31 Message: Logged In: YES user_id=64464 Putting back in open since not fixed. ---------------------------------------------------------------------- Comment By: Diego Santa Cruz (dsanta) Date: 2001-05-10 08:05 Message: Logged In: YES user_id=64464 Tested with Mesa 3.5 from CVS (checkout time Thu May 10 17:00:20 CEST 2001) and it is not fixed. Please reopen the bug! I attache a test program. I've built Mesa with make -f Makefile.X11 linux-debug ---------------------------------------------------------------------- Comment By: Brian Paul (brianp) Date: 2001-05-10 07:07 Message: Logged In: YES user_id=983 This should be fixed in Mesa 3.5 since we've switched to the SGI SI GLU and have fixed some problems in GL evaluators. Closing this report now. ---------------------------------------------------------------------- Comment By: Diego Santa Cruz (dsanta) Date: 2001-02-12 05:30 Message: Sure, let me know the e-mail address where I can send it to you. I suppose you would like sources. Are Linux (glibc2) binaries wanted too? I need a bit of time to "package" the source, but I should have them ready quite soon. ---------------------------------------------------------------------- Comment By: Brian Paul (brianp) Date: 2001-02-09 09:20 Message: Do you have a test program that I can try out? ---------------------------------------------------------------------- Comment By: Diego Santa Cruz (dsanta) Date: 2001-02-08 08:40 Message: I'm now using GL 1.2 Mesa 3.4 with the GLU of the sample implementation (the RPM on the Mesa3D website, oss-opengl-glu-20000925). The problem still persists so I think it is a problem of the Mesa GL. The workaround I'm currently using is to use the GLU's tesellator callbacks instead of GL evaluators which are used by default. But this is far from being optimal. BTW, the SI-GLU tesellator has some problems rendering NURBS curves, which the Mesa GL evaluators don't have. ---------------------------------------------------------------------- Comment By: Brian Paul (brianp) Date: 2001-02-08 08:22 Message: This could be a problem with Mesa's GLU NURBS code. Have you tried the SGI SI GLU library? You can download precompiled Linux binaries from the Mesa website. I plan to replace Mesa's GLU library with the SI GLU library in the future. Sorry for the late response on this. Someone else just reported a similar problem to me. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=212069&group_id=3 |
|
From: Paul A. T. <pa...@Ch...> - 2001-07-29 15:18:59
|
Hi. I'm noticing some really odd behaviour using Mesa releases starting from 3.2.1. I'm on RedHat Linux 7.1, with a PIII/850 and a Voodoo 4500AGP video card. I'm using gcc and the 'configure' make system, with the flag --without-glide. My problem is a bit hard to describe. I'm writing a protein visualization program (Cn3D), which creates graphically complex protein shapes, composed mainly of spheres, cylinders, and customized polygon objects. In my program, the problem seems to manifest itself whenever I use gluDisk(), but I can't say for sure that it's a problem with the gluDisk() function code itself. What happens is that when gluDisk() is used in a display list, it seems to screw up the disk and other objects - unrelated objects are out of place, shading is messed up (in gluCylinder() objects and elsewhere), text is out of place, and sometimes when I rotate the whole protein with the mouse (e.g., varying the top-level matrix), some objects move and some stay fixed (they're all supposed to move together). Again, this happens in versions 3.2.1 and higher. The details of exactly what's screwed up seems to change with each version, but they all mess up in similar ways. I've tried all the "release" versions available on SourceForge, and the only ones that work properly (not changing my own code at all, just replacing the Mesa libs/headers) are 3.1 and 3.2. And I run the exact same program (which is in C++ and uses wxWindows for the GUI) on Windows, SGI, and Solaris, which all have their own "native" OpenGL libraries, and all is fine on these platforms. I notice that between 3.2 and 3.2.1 there were massive changes to src-glu/quadric.c, although the gluDisk() function itself was pretty much unchanged. But I don't know this code at all (just looked at it for the first time yesterday), so I can't even begin to say what's going wrong. I apologize for being so vague, but this is the best I can describe it. The most odd thing is that a call to gluDisk() could affect other objects. Maybe there's a memory leak somewhere that's overwriting and corrupting other parts of the display list or something, but that's just a guess. In my program, I can turn on and off the objects that use gluDisk() interactively (e.g. while the program is running), and when these objects are not drawn all is well, and when I turn them back on, things get messed up again. And of course, if I comment out the calls to gluDisk() in the code, all is well regardless of runtime settings. Has anyone seen anything like this before? Any clues at all as to what might be happening? Thanks, - Paul =-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= Paul A. | pa...@Ch... Thiessen | http://www.ChemicalGraphics.com =-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= |
|
From: <no...@so...> - 2001-07-28 00:43:33
|
Support Requests item #445382, was opened at 2001-07-27 17:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200003&aid=445382&group_id=3 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Jacobberger (mahonri) Assigned to: Nobody/Anonymous (nobody) Summary: libGL.so?? Mesa 3.5 Initial Comment: brianp told me : This is not a bug. [ Bugs item #445126, was opened at 2001-07-27 05:17 ] brianp also stated: The fact that OpenGL renderer string reports 'Mesa X11' indicates that you're not using a DRI-aware libGL. You need to replace your libGL.so (wherever it is) with the libGL that comes with XFree86. I'm closing this report. So I reply: I nuked the links to the Mesa 3.5 libGL.so.350 so that I could create the symbolic links to libGL.so.1 located in the /usr/X11R6/lib for /usr/local/lib/libGL.so and /usr/lib/libGL.so... I still am confused as to how to install Mesa 3.5?? It apparently has it's OWN libGL.so?? Doing a make install put it there... SO how does that come full circle to this being a XFree86 issue... Are we not to do make install of Mesa 3.5 with it's own libGL?? Please advise.... I'm using XFree86 4.1.0-0.9.1 here. Thanks, Frank ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200003&aid=445382&group_id=3 |
|
From: Stephane R. <ste...@wi...> - 2001-07-27 15:16:23
|
Hi all,
As Allen Barnet, I have encoutered a bug with a couple of display
lists, my example is an extract from stencil.c.
The crash occurs in the 2nd call, too.
void initGL (GLsizei w, GLsizei h)
{
GLfloat yellow_diffuse[] = { 0.7, 0.7, 0.0, 1.0 };
GLfloat yellow_specular[] = { 1.0, 1.0, 1.0, 1.0 };
GLfloat blue_diffuse[] = { 0.1, 0.1, 0.7, 1.0 };
GLfloat blue_specular[] = { 0.1, 1.0, 1.0, 1.0 };
GLfloat position_one[] = { 1.0, 1.0, 1.0, 0.0 };
glNewList(YELLOWMAT, GL_COMPILE);
glMaterialfv(GL_FRONT, GL_DIFFUSE, yellow_diffuse);
glMaterialfv(GL_FRONT, GL_SPECULAR, yellow_specular);
glMaterialf(GL_FRONT, GL_SHININESS, 64.0);
glEndList();
glNewList(BLUEMAT, GL_COMPILE);
glMaterialfv(GL_FRONT, GL_DIFFUSE, blue_diffuse);
glMaterialfv(GL_FRONT, GL_SPECULAR, blue_specular);
glMaterialf(GL_FRONT, GL_SHININESS, 45.0);
glEndList();
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0, (GLfloat) w/(GLfloat) h, 3.0, 7.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glTranslatef(0.0, 0.0, -5.0);
}
/* Draw a sphere in a diamond-shaped section in the
* middle of a window with 2 tori.
*/
void drawGL(void)
{
glClear(GL_COLOR_BUFFER_BIT);
glCallList (BLUEMAT);
glutSolidSphere (0.5, 15, 15);
glCallList (YELLOWMAT);
glutSolidTorus (0.275, 0.85, 15, 15);
glFlush();
}
|
|
From: Brian P. <br...@va...> - 2001-07-27 14:25:52
|
Eric Plante wrote: > > I don't know if this is a bug or not... > > glxext.h says: > #ifndef GLX_VERSION_1_3 > (...) > #define GLX_RGBA_BIT 0x00000001 > (...) > #endif > > and then later on, and I assume that this is not nested in other > #ifdefs, it goes: > #ifndef GLX_VERSION_1_3 > #define GLX_VERSION_1_3 1 > > So I suppose this amounts to: "If GLX version is less than 1.3, then > define a bunch of stuff, and then later on pretend that it's 1.3". Right. > However, glx.h (which must appear before glxext.h from what I gather) > has the following: > #define GLX_VERSION_1_3 1 > > _BUT_, it doesn't have GLX_RGBA_BIT defined anywhere! The only way I can > see that this would be correct is if that define used to exist in older > versions of GLX but has been deprecated since 1.3. Otherwise, aren't > there define's missing? Yes, GLX_RGBA_BIT (and a few others) were missing in glx.h. I think I've got them all now. Thanks for spotting this. -Brian |
|
From: <no...@so...> - 2001-07-27 14:19:13
|
Bugs item #429312, was opened at 2001-06-01 07:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=429312&group_id=3 Category: mesa-core Group: Rendering Error >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Saunders (rms7326) >Assigned to: Brian Paul (brianp) Summary: glMaterialfv broken with Translucency Initial Comment: The glMaterialfv function does not seem to recognize changes to translucency correctly. We are pulling "panels" off of a depth sorted panel heap and then then setting the appropriate translucency for each. The order of our OpenGL calls looks something like this: glNewList(dataList, GL_COMPILE) glDepthMask(FALSE) glEnable(GL_BLEND) glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) glPolygonMode(GL_FRONT_AND_BACK, 6914) glEnable(GL_LIGHTING) glShadeModel(GL_FLAT) glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, RGBA_array) where RGBA_array[0..3]=[0.823529,0,0,0.9] glBegin(GL_POLYGON) glNormal3d(0 1 0) glVertex3d(1.1,0,0) glVertex3d(1.1,0,1) glVertex3d(2.1,0,1) glVertex3d(2.1,0,0) glEnd() glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, RGBA_array) where RGBA_array[0..3]=[0.823529,0,0,0.5] glBegin(GL_POLYGON) glNormal3d(0 1 0) glVertex3d(0,0,0) glVertex3d(0,0,1) glVertex3d(1,0,1) glVertex3d(1,0,0) glEnd() glDepthMask(TRUE) glDisable(GL_BLEND) glEndList() glCallList(dataList) glFlush() What we discover is that the two polygons have the same instead of different translucency. This is a small example of a larger problem. When we draw tens of thousands of polygons in this way we discover that on occasion the correct translucency value is pushed through, almost as if there is a cache problem. I know it is not graphics card related cache problem because we have run the Mesa version of our product on various platforms all exhibiting the same behavior. Additionally, we are using Mesa 3.4.1. I can provide more info about what we are doing before and after the above calls if needed. Thanks, Michael ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:19 Message: Logged In: YES user_id=983 I'm closing this bug report now. ---------------------------------------------------------------------- Comment By: Michael Saunders (rms7326) Date: 2001-07-16 17:42 Message: Logged In: YES user_id=217333 Brian, I got a chance to check out the 3.5 release and the problem with glMateral is now fixed so you can close this bug report. I did however discover another bug with glColorMaterial and strips which I will report separately. Michael ---------------------------------------------------------------------- Comment By: Brian Paul (brianp) Date: 2001-06-04 09:01 Message: Logged In: YES user_id=983 I think this should be fixed in Mesa 3.5 (the CVS trunk). Can you give that a try? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=429312&group_id=3 |
|
From: <no...@so...> - 2001-07-27 14:18:25
|
Bugs item #430284, was opened at 2001-06-05 04:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=430284&group_id=3 Category: GLU Group: Compile/Install Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Brian Paul (brianp) Summary: Incompatibility Mesa-3.4.2/SGI glu.h Initial Comment: I attempted to install the libGLU and header from the SGI sample implementation (ogl-sample.20000807.tgz), as suggested on the Mesa web site and found that the new glu.h produced compile-time errors. After some investigation it appears that this is because the new glu.h expects the following typedef to occur in gl.h : typedef void (*_GLfuncptr)(); but this type is not defined in the Mesa gl.h header. ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:18 Message: Logged In: YES user_id=983 I'm looking at the Mesa-3.5/include/GL/glu.h header. Instead of _GLfuncptr I see _GLUfuncptr. I don't rember if this was changed by SGI or myself (many months ago). Please try the glu.h header from Mesa. ---------------------------------------------------------------------- Comment By: Gerard Flynn (gerardflynn) Date: 2001-06-19 00:21 Message: Logged In: YES user_id=80449 Are you sure you're looking at the SGI glu.h ? It's true that the Mesa version doesn't have any such references. In the SGI glu.h I see the following : line 290 : extern void gluNurbsCallback (GLUnurbs* nurb, GLenum which, _GLfuncptr CallBackFunc); line 302: extern void gluQuadricCallback (GLUquadric* quad, GLenum which, _GLfuncptr CallBackFunc); line 311: extern void gluTessCallback (GLUtesselator* tess, GLenum which, _GLfuncptr CallBackFunc); ---------------------------------------------------------------------- Comment By: Brian Paul (brianp) Date: 2001-06-11 12:51 Message: Logged In: YES user_id=983 I see no reference to '_GLfuncptr' in glu.h. There is a '_GLUfuncptr' type but it is defined in glu.h so I don't see what the problem is. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=430284&group_id=3 |
|
From: <no...@so...> - 2001-07-27 14:16:17
|
Bugs item #435682, was opened at 2001-06-23 07:13 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=435682&group_id=3 Category: None Group: Compile/Install >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Brian Paul (brianp) Summary: Can't compile Mesa 3.5 with VC++ 6.0 Initial Comment: When trying to compile Mesa 3D version 3.5 with: nmake /f Makefile.win I get following error messages: tnl\t_imm_dlist.c(502) : error C2152: '=' : pointers to functions with different attributes tnl\t_imm_dlist.c(504) : error C2152: '=' : pointers to functions with different attributes tnl\t_imm_dlist.c(510) : warning C4018: '==' : signed/unsigned mismatch tnl\t_imm_dlist.c(511) : error C2152: '=' : pointers to functions with different attributes tnl\t_imm_dlist.c(513) : error C2152: '=' : pointers to functions with different attributes tnl\t_imm_dlist.c(515) : error C2152: '=' : pointers to functions with different attributes My compiler (VC++ 6.0) should be correctly installed so that isn't the problem, I think. Is there some compiler option that should be enabled? If not, what is the problem? ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:16 Message: Logged In: YES user_id=983 If you grab the latest sources from CVS this should work now. Somebody else contributed a patch. I'm closing this report now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=435682&group_id=3 |
|
From: <no...@so...> - 2001-07-27 14:13:32
|
Bugs item #438798, was opened at 2001-07-05 08:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=438798&group_id=3 Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Brian Paul (brianp) Summary: No install directions Initial Comment: Perhaps I'm blind, but I can't find any information on how to install mesa3d. ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:13 Message: Logged In: YES user_id=983 See Mesa/docs/INSTALL ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=438798&group_id=3 |
|
From: <no...@so...> - 2001-07-27 14:12:53
|
Bugs item #441141, was opened at 2001-07-13 11:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=441141&group_id=3 Category: mesa-core Group: Compile/Install Status: Open Resolution: None Priority: 5 Submitted By: Michael Saunders (rms7326) >Assigned to: Brian Paul (brianp) Summary: Various compile errors for Solaris 7 Initial Comment: 1) Several files in the 3.5 distribution are reported by the Solaris 7 compiler (Workshop 6.0) as having a null character at the end of the files. The compiler reports this as an error and stops. I solved the problem by editing the file with vi and adding a newline to the end of the file and then deleting it again. I have discovered from working in a mixed environment that when Windows machines write out text files they leave off whatever character the Solaris machine is expecting at the end of the file. I have never had this problem when editing files with a Unix machine. 2) With the USE_SPARC_ASM define set to 1 the Solaris 7 Workshop 6.0 cc compiler has trouble compiling the assembly language files. It passes off the cpp'ed file to a utility called /opt/SUNWspro/bin/../WS6/bin/fbe to convert the asm to machine code but it reports all kinds of errors (a few follow below): cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src -DUSE_SPARC_ASM -I./src/X86 -g -D_REENTRANT -DPTHREADS -c glapi_sparc.S -KPIC -DPIC -o glapi_sparc.o /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 611: error: invalid character (0x40) /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: invalid character (0x23) /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: invalid character (0x3b) /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: statement syntax /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: invalid character (0x23) /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: invalid number of operands /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: invalid character (0x2c) /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: invalid character (0x40) /opt/SUNWspro/bin/../WS6/bin/fbe: "/tmp/cpp0AAADRaq8M", line 614: error: statement syntax Here is what the preprossed file looks like (note I added the line numbers to help you see the association with the errors above: 599 .text 600 .align 32 601 .globl __glapi_sparc_icache_flush 602 __glapi_sparc_icache_flush: 603 flush %o0 604 retl 605 nop 606 607 .data 608 .align 64 609 610 .globl _mesa_sparc_glapi_begin 611 .type _mesa_sparc_glapi_begin,@function 612 _mesa_sparc_glapi_begin: 613 614 .globl gl##NewList ; .type gl##NewList,@function 615 gl##NewList: 616 # 39 "glapi_sparc.S" 617 618 sethi %hi(0x00000000), %g1 619 ld [%g1 + %lo(0x00000000)], %g1 620 ld [%g1 + (4 * 0)], %g3 621 622 jmpl %g3, %g0 623 624 .globl gl##EndList ; .type gl##EndList,@function 625 gl##EndList: 626 # 58 "glapi_sparc.S" 627 628 sethi %hi(0x00000000), %g1 629 ld [%g1 + %lo(0x00000000)], %g1 630 ld [%g1 + (4 * 1)], %g3 631 632 jmpl %g3, %g0 633 634 .globl gl##CallList ; .type gl##CallList,@function 635 gl##CallList: It looks like fbe is complaining about the @ and ; and ; and , signs. Michael ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:12 Message: Logged In: YES user_id=983 Does replacing the @ characters with # or ## as in your later report fix this? Otherwise, please send me a new glapi_sparc.S file which works for you. -Brian ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=441141&group_id=3 |
|
From: <no...@so...> - 2001-07-27 14:10:24
|
Bugs item #441817, was opened at 2001-07-16 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=441817&group_id=3 Category: GLU Group: Compile/Install Status: Open Resolution: None Priority: 5 Submitted By: Michael Saunders (rms7326) >Assigned to: Brian Paul (brianp) Summary: Solaris 5 and 7 can't compile glu Initial Comment: Both my Solaris 5 and Solaris 7 platforms can't compile some files (at least "curve.cc", but there may be more) in the "si-glu/libnurbs/internals" directory. The file, "curve.cc" uses "::sqrtf" which when LIBRARYBUILD is defined (and not GLBUILD or STANDALONE) it is undefined (see "mymath.h"). For some reason the linux build using g++ does not have this problem so I assume it must define ::sqrtf but the Sun Workshop 6 compilers do not. Michael ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:10 Message: Logged In: YES user_id=983 I don't have access to a Solaris system to test/fix this. Do you have a suggested fix? -Brian ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=441817&group_id=3 |
|
From: <no...@so...> - 2001-07-27 14:07:10
|
Bugs item #442742, was opened at 2001-07-19 06:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=442742&group_id=3 Category: mesa-core Group: Compile/Install >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Brian Paul (brianp) Summary: SUN assembly invalid character @ Initial Comment: While compiling on SunOS 5.6 Ultra-1 an error occurred at src/SPARC/glapi_sparc.S. The message was invalid character 0x40. I changed the following lines to read: #define GLOBL_FN(x) .globl x ; .type x,##function ... .type _mesa_sparc_glapi_begin,#function ... .type _mesa_sparc_glapi_end,#function It then compiles ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:06 Message: Logged In: YES user_id=983 Thanks for the patch. I've applied it to the 3.5 sources. I'm closing this report now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=442742&group_id=3 |
|
From: <no...@so...> - 2001-07-27 14:04:20
|
Bugs item #444562, was opened at 2001-07-25 12:04 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=444562&group_id=3 Category: other Group: Rendering Error >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Frank Warmerdam (warmerda) >Assigned to: Brian Paul (brianp) Summary: wglUseFontBitmap support for bitmap font Initial Comment: Brian, I have a new update for the src/Windows/wgl.c code. I was able to crib a bunch of code from the FX driver to that appears to correctly implement bitmap font support (as well as the existing outline font support). Please replace the entire existing wglUseFontBitmapsA() function with the code in the attachment. While I am working against a slightly older version of wgl.c, I skimmed over the 3.5 src/Windows/wgl.c and I believe that my code should fit in their fine. Let me know if there are problems. Note that with the old code, trying to render a bitmap font can result in an unterminated glNewList() which can be very damaging! This code fixes that problem as well. ---------------------------------------------------------------------- >Comment By: Brian Paul (brianp) Date: 2001-07-27 07:04 Message: Logged In: YES user_id=983 Thanks. I've applied the change to the 3.5 code. I'm closing this report now. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=444562&group_id=3 |
102 messages has been excluded from this view by a project administrator.
