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: <no...@so...> - 2001-07-27 12:17:26
|
Bugs item #445126, was opened at 2001-07-27 05:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=445126&group_id=3 Category: mesa-core Group: Rendering Error Status: Open Resolution: None Priority: 5 Submitted By: Frank Jacobberger (mahonri) Assigned to: Nobody/Anonymous (nobody) Summary: Mesa 3.5 w/glxinfo false info Initial Comment: Executing glxinfo nets a incorrect response with regard to direct rendering: It reports "direct rendering: No" If I look at my XFree86-0.log file it reports "direct rendering enabled" See attached file: XFree86.0.log My card is a radeon 64 ddr. Running under kernel 2.4.7 on a Intel 815ep chipset, PIII - 866 Coppermine. Here is the output of glxinfo: [root@f1j Mesa-3.5]# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: Brian Paul server glx version string: 1.3 Mesa 3.5 server glx extensions: GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, GLX_ARB_get_proc_address client glx vendor string: Brian Paul client glx version string: 1.2 Mesa 3.5 client glx extensions: GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, GLX_ARB_get_proc_address GLX extensions: GLX_MESA_pixmap_colormap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_release_buffers, GLX_MESA_copy_sub_buffer, GLX_SGI_video_sync, GLX_ARB_get_proc_address OpenGL vendor string: Brian Paul OpenGL renderer string: Mesa X11 OpenGL version string: 1.2 Mesa 3.5 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_fog_coord, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_HP_occlusion_test, GL_INGR_blend_func_separate, GL_MESA_resize_buffers, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_pixel_texture, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIX_depth_texture, GL_SGIX_pixel_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x25 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x26 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x27 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x29 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None 0x2a 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 16 0 0 None ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=445126&group_id=3 |
|
From: Eric P. <eri...@di...> - 2001-07-26 21:27:22
|
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". 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? Thanks for any clues, -- eric plante, software developer, effects, discreet |
|
From: <no...@so...> - 2001-07-25 19:04:21
|
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: Open Resolution: None Priority: 5 Submitted By: Frank Warmerdam (warmerda) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=444562&group_id=3 |
|
From: Brian P. <br...@va...> - 2001-07-23 15:13:34
|
Eric Plante wrote: > > Hmm. Here's another one. It seems that in > /DLlocal/plantee/Mesa-3.5/src/context.c:1424, when called by > glXCreateContext, I get stuck on a deadlock. This might very well be > caused by particularities of our code which I have yet to discover, but > I just wanted to ask here if this rings a bell to anyone. Never heard of that one before. > As an aside, does Mesa require pthreads or can it be compiled without > it? I saw a define related to that in the generated conf.h, but haven't > investigated further. Mesa relies on one of PTHREADS, SOLARIS_THREADS, XTHREADS, or WIN32_THREADS to be defined on the command line in order to support thread safety. If none are defined, then the thread-related functions are no-ops. -Brian |
|
From: Brian P. <br...@va...> - 2001-07-23 15:10:35
|
"Jacob (=Jouk) Jansen" wrote: > > Hi All, > > the file include/GL/vms_x_fix.h seems to be missing in the released version > of Mesa3.5. This file is needed to get everything compiled on OpenVMS. I added > this file sometime ago to the CVS. Is it than not autmatically added in the > packages derived from that or do I have to do something to achieve this? It was an oversight. I've fixed the Makefile used to make the tar file. -Brian |
|
From: Brian P. <br...@va...> - 2001-07-23 15:06:51
|
Markus Kuespert wrote: > > Where can I find the data structure of __GLcontextModesRec (formerly > known as gl_visual) in 3.5.0 ??? > > In Version 3.4.2 it could be found in types.h. See Mesa/include/GL/internal/glcore.h -Brian |
|
From: Steve B. <st...@li...> - 2001-07-23 14:26:42
|
On Thu, 19 Jul 2001, [iso-8859-1] Heriberto Delgado V=E1squez wrote: > Steve Baker wrote, among others: >=20 > >Since EVERY OpenGL program is going to need X and GL, and maybe > >90% of them need GLU and perhaps 50% need GLUT, it really does > >make sense to ship them all together. >=20 > Hmm... what about us Windows developers??? =20 (like I *care* about what happens to Windoze developers) Well, OK - I was talking to the Mesa list in response to a question about how GLUT is distributed with X - and I guess there aren't too many Windoze people who care about that. To rephrase that: "Since EVERY OpenGL program that uses X (and hence is relevent to this thread) is going to need X and GL...." ---- 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: <no...@so...> - 2001-07-21 15:09:12
|
Bugs item #443347, was opened at 2001-07-21 07:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=443347&group_id=3 Category: 3dfx-driver Group: Fatal Error >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Colin Bayer (vogon_jeltz) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault on opening with MESA_GLX_FX Initial Comment: OK, here's the deal. I have a Pentium III box with a Voodoo5 5500 PCI running XFree release 4.1.0 and Glide3 hot off the CVS. Whenever I start TuxRacer (this doesn't happen with GLTron or BZFlag, BTW), it gives me the infamous "Warning: MESA_GLX_FX not defined..." message. I don't set MESA_GLX_FX for one important reason: when I set it to "fullscreen" or "windowed", TuxRacer segfaults with this (cryptic) error message: gd error (glide): gd error (glide): grSstSelect: non-existent SSTgd error (glide): grSstSelect: non-existent SSTSegmentation fault (core dumped) However, if I don't set MESA_GLX_FX to either of these, I get incredibly slow software rendering... Why does this happen, and how do I fix it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=443347&group_id=3 |
|
From: <no...@so...> - 2001-07-21 14:45:26
|
Bugs item #443347, was opened at 2001-07-21 07:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=443347&group_id=3 Category: 3dfx-driver Group: Fatal Error Status: Open Resolution: None Priority: 5 Submitted By: Colin Bayer (vogon_jeltz) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault on opening with MESA_GLX_FX Initial Comment: OK, here's the deal. I have a Pentium III box with a Voodoo5 5500 PCI running XFree release 4.1.0 and Glide3 hot off the CVS. Whenever I start TuxRacer (this doesn't happen with GLTron or BZFlag, BTW), it gives me the infamous "Warning: MESA_GLX_FX not defined..." message. I don't set MESA_GLX_FX for one important reason: when I set it to "fullscreen" or "windowed", TuxRacer segfaults with this (cryptic) error message: gd error (glide): gd error (glide): grSstSelect: non-existent SSTgd error (glide): grSstSelect: non-existent SSTSegmentation fault (core dumped) However, if I don't set MESA_GLX_FX to either of these, I get incredibly slow software rendering... Why does this happen, and how do I fix it? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=443347&group_id=3 |
|
From: Markus K. <kue...@mk...> - 2001-07-20 17:29:58
|
Where can I find the data structure of __GLcontextModesRec (formerly known as gl_visual) in 3.5.0 ??? In Version 3.4.2 it could be found in types.h. Thank you for your help Markus Kuespert |
|
From: <jo...@hr...> - 2001-07-20 10:10:45
|
Hi all,
Since 27 June ( my last stable Mesa snapshot from the CVS) I see occasional
crashes of the xlockmore programs in the GL-modes running on VMS. Up to now
I create anything reproducable. However today (with Today's Mesa-CVS) I
noticed that when running xlockmore with:
xlock -nice 0 -inwindow -modelist molecule
In around 50% of the cases it gives a mesa error before crashing or hanging
(see messages attached). The opcode seems to be more or less random (why???)
In the examples of opcode 4096 and 297 not one message was created and than
a crash, but the message was generated continuously letting the display-window
hang.
Jouk
Mesa messages (a blank line separates messages from different runs of xlock):
Mesa implementation error: Error in execute_list: opcode=41140624
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=-267557120
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=20267016
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=34339824
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=34339824
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=36176624
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=4096
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=4096
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=4096
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=4096
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=4096
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=4096
Please report to the Mesa bug database at www.mesa3d.org
etc.
Mesa implementation error: Error in execute_list: opcode=297
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=297
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=297
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=297
Please report to the Mesa bug database at www.mesa3d.org
Mesa implementation error: Error in execute_list: opcode=297
Please report to the Mesa bug database at www.mesa3d.org
etc.
Mesa implementation error: Error in execute_list: opcode=32330192
Please report to the Mesa bug database at www.mesa3d.org
Bush : All votes are equal but some votes are more equal than others.
>------------------------------------------------------------------------------<
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-2782272 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: Rasputin <rar...@vi...> - 2001-07-20 09:07:52
|
* Heriberto Delgado Vásquez <her...@ru...> [010720 03:00]:
> Steve Baker wrote, among others:
>
> >Since EVERY OpenGL program is going to need X and GL, and maybe
> >90% of them need GLU and perhaps 50% need GLUT, it really does
> >make sense to ship them all together.
>
> Hmm... what about us Windows developers???
Ah, it's worth pointing out that parts of Mesa are already being
shipped with XFree86, so it makes sense to have GLUT ship with it
too if it's considered part of OpenGL by most of the community.
I don't think anyone's suggesting making GLUT an X-only thing.
--
"unsupported alpha source blend function
Glide sucks
Glide sucks
Glide sucks"
-- /usr/X11R6/lib/libglide3.so
Rasputin :: Jack of All Trades - Master of Nuns ::
|
|
From: <jo...@hr...> - 2001-07-20 07:05:21
|
Hi All,
the file include/GL/vms_x_fix.h seems to be missing in the released version
of Mesa3.5. This file is needed to get everything compiled on OpenVMS. I added
this file sometime ago to the CVS. Is it than not autmatically added in the
packages derived from that or do I have to do something to achieve this?
Jouk
Bush : All votes are equal but some votes are more equal than others.
>------------------------------------------------------------------------------<
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-2782272 tt uuuuuuu ddddddd
>------------------------------------------------------------------------------<
|
|
From: <her...@ru...> - 2001-07-20 01:45:49
|
Steve Baker wrote, among others:
>Since EVERY OpenGL program is going to need X and GL, and maybe
>90% of them need GLU and perhaps 50% need GLUT, it really does
>make sense to ship them all together.
Hmm... what about us Windows developers???
- Heriberto Delgado
(io...@cr...,
her...@ru...)
|
|
From: Eric P. <eri...@di...> - 2001-07-19 21:36:06
|
Hmm. Here's another one. It seems that in /DLlocal/plantee/Mesa-3.5/src/context.c:1424, when called by glXCreateContext, I get stuck on a deadlock. This might very well be caused by particularities of our code which I have yet to discover, but I just wanted to ask here if this rings a bell to anyone. As an aside, does Mesa require pthreads or can it be compiled without it? I saw a define related to that in the generated conf.h, but haven't investigated further. Thanks, -- eric plante, software developer, effects, discreet |
|
From: <no...@so...> - 2001-07-19 13:27:49
|
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: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=442742&group_id=3 |
|
From: Philip W. <pg...@do...> - 2001-07-19 12:25:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today, Stephen J Baker wrote: >On Wed, 18 Jul 2001, Philip Willoughby wrote: >> I think that the best way for you to package X, GL, GLU and glut would be to >> have all four in seperate packages. > >I think this is the worst of all possible worlds. > >People have a TERRIBLE time getting all the versions of their >software lined up right and finding all the packages they need >in order to install some end product like a games or something. > >The fewer opportunities there are for error, the better. > >Since EVERY OpenGL program is going to need X and GL, and maybe >90% of them need GLU and perhaps 50% need GLUT, it really does >make sense to ship them all together. I cannot agree with this -- it means you need to upgrade all of them (or rather download a huge package with the old versions in again) when any one changes. So long as glut depends on libGLU.so, libGL.so, libX11.so etc. and GLU depends on libGL.so users will be able to mix-and-match. As you have just said, there are two sources of glut, GLU can be had from Mesa or SGIs reference implementation (I believe SGIs is the recommended as it's newer), and GL can be Mesa Xlib for software X 3.3.x, DRI/drm Mesa for 4.x.y, or nvidias version. Until there is only one version of GL, GLU, and glut that everyone agrees on, there is no sense in packaging all three in one. Regards, Philip Willoughby - -- echo bz...@nf... | tr "bizndfohces" "pwgd9ociaku" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7VtGYTEXlrOaAVckRAh4GAKDWUs7rWORG2r7EHQTQPflTKaw7PACeKZJV 4/EuFpbbTfr/PBWK2nMi7Co= =8F7e -----END PGP SIGNATURE----- |
|
From: Stephen J B. <sj...@li...> - 2001-07-19 11:57:36
|
On Wed, 18 Jul 2001, Brian Paul wrote: > > I do not use Mesa myself, so I don't understand how big a problem > > removing GLUT from the distro might be. Is there plans to > > integrate GLUT with XFree86 4.2.0 at all? If not, what is the > > reasoning, and should we support it separately do you think? > > I think GLUT should be in its own RPM, independent of Mesa, XFree86, > DRI, etc. Since GLUT can be used with any number of X and OpenGL > implementations it's wrong to create an unneeded dependency on > Mesa or XFree86. > > I only distribute GLUT with Mesa as a convenience to users so > that they can get up & running with OpenGL quickly. True - that was the *ORIGINAL* intention of GLUT - but the fact is that a HUGE number of packages use it and it's now probably almost as important as GLU. ---- 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: Stephen J B. <sj...@li...> - 2001-07-19 11:55:46
|
On Wed, 18 Jul 2001, Philip Willoughby wrote: > As I understand it it's a licensing issue. glut is released under the strict > GPL, and XFree86 is not. No!!!! GLUT is most certainly not GPL (or even LGPL) - it's not even "in the public domain" according to the file 'NOTICE' in the GLUT distro: "NOTICE: The OpenGL Utility Toolkit (GLUT) distribution contains source code published in a book titled "Programming OpenGL for the X Window System" (ISBN: 0-201-48359-9) published by Addison-Wesley. The programs and associated files contained in the distribution were developed by Mark J. Kilgard and are Copyright 1994, 1995, 1996 by Mark J. Kilgard (unless otherwise noted). The programs are not in the public domain, but they are freely distributable without licensing fees. These programs are provided without guarantee or warrantee expressed or implied." ...so it's probably incompatible with Xfree licensing. > The licenses are not entirely compatible, and since > the XFree86 guys (rightly) do not want 90% of their code under one > license, and > then some random bits in other license -- this just makes it a lot harder for > people to work out what they can and cannot do with the code. Right - so GLUT can't go into Xfree - although 'freeglut' (which is licensed under the Xfree license) could be included. > I think that the best way for you to package X, GL, GLU and glut would be to > have all four in seperate packages. I think this is the worst of all possible worlds. People have a TERRIBLE time getting all the versions of their software lined up right and finding all the packages they need in order to install some end product like a games or something. The fewer opportunities there are for error, the better. Since EVERY OpenGL program is going to need X and GL, and maybe 90% of them need GLU and perhaps 50% need GLUT, it really does make sense to ship them all together. The only problem with that is that "Not All Linux OpenGL is Mesa"... in fact from what I can tell from the people who I talk to, Mesa users are increasingly becoming the minority with nVidia's OpenGL drivers being the more commonly used. (Due to the popularity of their hardware rather than any feature or mis-feature of their driver or of Mesa) > Of course, this is just my opinion, but perhaps it would help distribution > vendors, and more so end-users if all concerned could agree on a standard way > of packaging up X, GL, GLU and glut... Yes. If just one major Linux vendor screws up, the amount of chaos for the people who support the end-user applications can be unbelievable. RedHat's screw up over GCC added probably 150 emails a week to my support load for the handful of odd games and tools that I give away. Avoiding another SNAFU like that is crucial. That the problem doesn't "belong" to the end-user application support people is irrelevent...we are the ones with our email addresses at the bottom of the home page - when the game doesn't work - we get the first call from the users. ---- 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: Stephen J B. <sj...@li...> - 2001-07-19 11:42:34
|
On Wed, 18 Jul 2001, Mike A. Harris wrote: > I've had several people asking me why GLUT is not included in > XFree86's Mesa. We ship separate Mesa which has it, but if I > understand correctly, Brian Paul has added the needed bits to the > Mesa trunk so that it works with 3.3.6 now also. When this makes > it into an official XFree86 release, we won't need external Mesa > I don't believe, and likely will just ship XFree86 Mesa. > > I've mentioned this to people, and they are worried that GLUT > won't be supported because it is not part of XFree86 Mesa. > > I do not use Mesa myself, so I don't understand how big a problem > removing GLUT from the distro might be. Is there plans to > integrate GLUT with XFree86 4.2.0 at all? If not, what is the > reasoning, and should we support it separately do you think? GLUT is quite important - a very large number of OpenGL programs rely on it and it should certainly be installed on every Linux PC that has OpenGL or Mesa. How it gets there: * as a part of the main Linux distro. * as a part of Xfree. * as a part of some vestigial Mesa. ...doesn't matter so long as the RedHat's, SuSE's, Debians and others of their ilk make sure that there is a /usr/include/GL/glut.h and a /usr/lib/libglut.so on every machine by default. Failure to do that would be a great disaster for those of us who maintain free OpenGL programs because we'll suddenly be deluged by email from people who would find that published build instructions would stop working under some future release. Note that there is also 'freeglut' at http://freeglut.sf.net which is a truly OpenSourced GLUT alternative. GLUT is free (in the sense of 'free beer') but not *completely* Free - which may concern some distributors. I'm not aware of any GLUT programs that don't work with 'freeglut'. ---- 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: Grzegorz J. <gr...@po...> - 2001-07-19 09:10:53
|
On Wed, 18 Jul 2001 14:21:58 -0600, Brian Paul wrote: >Grzegorz Jaskiewicz wrote: >> >> On Wed, 18 Jul 2001 13:27:39 -0400, Scott McMillan wrote: >> >Keith Whitwell wrote: >> >> >> >> Scott McMillan wrote: >> >> > >> >> > I am having trouble with glDrawRangeElements (again)= with >>version >> >> > 3.5. The attached test program renders three= GL_POLYGONs. By >> >> > pressing 'v' it cycles through using glVertex3f (the= initial >> >>mode), >> >> > glDrawRangeElements, and glDrawElements. There is a= problem >>with >> >> > the glDrawRangeElements. >> >> >> >> I don't see this problem at all. Can you verify it is= still >>there >> >>with >> >> current cvs? >> > >> >With the current CVS it seems to be fixed...but now I am= getting >> >core dumps on exit of other SGL test programs in= chunk_free() >> >from libc.so.6. I cannot get enough of a stack trace to= find >> >out where this is happening (just a second level:= __DTOR_END__()). >> > >> >I will try to rerun the rest of the SGL test programs to see= what >> >other problems have gone away or been created (soon I hope). >> > >> >scott >> > >> This fn, as far as i know was introduced in opengl 1.21. Mesa= 3.5 >>(it is writen on main page) is only 1.2 compilant. Thats good, >>but...... > >The OpenGL 1.2.1 spec is 1.2 + GL_ARB_multitexture, which Mesa= 3.5 >fully supports. > :-) >-Brian > >_______________________________________________ >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 07-19-2001 You can write also to: gja...@at... , gj...@wp... ,= gr...@po... Tel.:+48 608 892 083 Gadu Gadu : 915051 -- Czatuj, wyslij sms-y, sprawdz poczte Zainstaluj OnetKomunikatora [ http://ok.onet.pl/ ] |
|
From: Brian P. <br...@va...> - 2001-07-18 20:16:23
|
Grzegorz Jaskiewicz wrote: > > On Wed, 18 Jul 2001 13:27:39 -0400, Scott McMillan wrote: > >Keith Whitwell wrote: > >> > >> Scott McMillan wrote: > >> > > >> > I am having trouble with glDrawRangeElements (again) with version > >> > 3.5. The attached test program renders three GL_POLYGONs. By > >> > pressing 'v' it cycles through using glVertex3f (the initial > >>mode), > >> > glDrawRangeElements, and glDrawElements. There is a problem with > >> > the glDrawRangeElements. > >> > >> I don't see this problem at all. Can you verify it is still there > >>with > >> current cvs? > > > >With the current CVS it seems to be fixed...but now I am getting > >core dumps on exit of other SGL test programs in chunk_free() > >from libc.so.6. I cannot get enough of a stack trace to find > >out where this is happening (just a second level: __DTOR_END__()). > > > >I will try to rerun the rest of the SGL test programs to see what > >other problems have gone away or been created (soon I hope). > > > >scott > > > This fn, as far as i know was introduced in opengl 1.21. Mesa 3.5 (it is writen on main page) is only 1.2 compilant. Thats good, but...... The OpenGL 1.2.1 spec is 1.2 + GL_ARB_multitexture, which Mesa 3.5 fully supports. -Brian |
|
From: Grzegorz J. <gr...@po...> - 2001-07-18 20:05:58
|
On Wed, 18 Jul 2001 13:27:39 -0400, Scott McMillan wrote: >Keith Whitwell wrote: >> >> Scott McMillan wrote: >> > >> > I am having trouble with glDrawRangeElements (again) with= version >> > 3.5. The attached test program renders three GL_POLYGONs. = By >> > pressing 'v' it cycles through using glVertex3f (the= initial >>mode), >> > glDrawRangeElements, and glDrawElements. There is a problem= with >> > the glDrawRangeElements. >> >> I don't see this problem at all. Can you verify it is still= there >>with >> current cvs? > >With the current CVS it seems to be fixed...but now I am= getting >core dumps on exit of other SGL test programs in chunk_free() >from libc.so.6. I cannot get enough of a stack trace to find >out where this is happening (just a second level:= __DTOR_END__()). > >I will try to rerun the rest of the SGL test programs to see= what >other problems have gone away or been created (soon I hope). > >scott > This fn, as far as i know was introduced in opengl 1.21. Mesa 3.5= (it is writen on main page) is only 1.2 compilant. Thats good,= but...... >_______________________________________________ >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 07-18-2001 You can write also to: gja...@at... , gj...@wp... ,= gr...@po... Tel.:+48 608 892 083 Gadu Gadu : 915051 -- Czatuj, wyslij sms-y, sprawdz poczte Zainstaluj OnetKomunikatora [ http://ok.onet.pl/ ] |
|
From: <no...@so...> - 2001-07-18 18:46:07
|
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. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100003&aid=442527&group_id=3 |
|
From: Scott M. <mcm...@ca...> - 2001-07-18 17:29:22
|
Keith Whitwell wrote: > > Scott McMillan wrote: > > > > I am having trouble with glDrawRangeElements (again) with version > > 3.5. The attached test program renders three GL_POLYGONs. By > > pressing 'v' it cycles through using glVertex3f (the initial mode), > > glDrawRangeElements, and glDrawElements. There is a problem with > > the glDrawRangeElements. > > I don't see this problem at all. Can you verify it is still there with > current cvs? With the current CVS it seems to be fixed...but now I am getting core dumps on exit of other SGL test programs in chunk_free() from libc.so.6. I cannot get enough of a stack trace to find out where this is happening (just a second level: __DTOR_END__()). I will try to rerun the rest of the SGL test programs to see what other problems have gone away or been created (soon I hope). scott |
102 messages has been excluded from this view by a project administrator.
