3dfx troubles with u3d & gl tut

michele · December 17, 2000, 11:14pm

I’ve got a voodoo2 on a linux system. It works with may apps and games
but when i run the u3d demo or the gl demo #11 I receive:

fxmesa: Received a not handled signal 11

(other demos work fine)

what happen?

michele

Vasileiou_Nikolaos · December 18, 2000, 8:39am

signal 11 is not generally good cause it may indicate hardware errors.

Can you tell me if U3D gives you any other message on the console so I
can spot the problem?
Normally you should get some info like what version of opengl you use and
other stuff. If not please tell me.On Mon, 18 Dec 2000, michele wrote:

I’ve got a voodoo2 on a linux system. It works with may apps and games
but when i run the u3d demo or the gl demo #11 I receive:

fxmesa: Received a not handled signal 11

(other demos work fine)

what happen?

michele

michele · December 19, 2000, 5:50pm

I had to remove the lines in the gl-intro demo #11:

glPolygonMode( GL_BACK, GL_FILL );
glPolygonMode( GL_FRONT, GL_LINE );

and now it works:
does u3d use glPolygonMode? and how?
what is glPolygonMode used for?
is there a best solution than erasing lines in sources?

I’ll look at the config file for my mesa libs.

michele

Vasileiou Nikolaos wrote:>

signal 11 is not generally good cause it may indicate hardware errors.

Can you tell me if U3D gives you any other message on the console so I
can spot the problem?
Normally you should get some info like what version of opengl you use and
other stuff. If not please tell me.

michele · December 19, 2000, 5:43pm

This is ALL U3D tells me on the console
the test progs for Glide3x ,2x and 3dfx work good as quake3 and quake2.
I think that the prog makes a call to a feature not present in the Mesa
driver I’m using (or excluded by a compiling mistake).

thanks, michele

USING: libGL.so
---- Loading OpenGL Symbols ----
GL_RED_SIZE: 5
GL_GREEN_SIZE: 6
GL_BLUE_SIZE: 5
GL_DEPTH_SIZE: 16
GL_DOUBLEBUFFER: 1

Vendor : Brian Paul
Renderer : Mesa Glide v0.30 Voodoo_Graphics 0 CARD/4 FB/8 TM/2
TMU/NOSLI
Version : 1.2 Mesa 3.3

fxmesa: Received a not handled signal 11

Vasileiou Nikolaos wrote:>

signal 11 is not generally good cause it may indicate hardware errors.

Can you tell me if U3D gives you any other message on the console so I
can spot the problem?
Normally you should get some info like what version of opengl you use and
other stuff. If not please tell me.

Vasileiou_Nikolaos · December 20, 2000, 12:04pm

About the glPolygon mode call, it is not normal to crash because of that
since it is a standart opengl call and not an unsupported extension or
something like that. quite weird!! Maybe a Mesa bug? who knows!

On U3D the problem is on extension loading. I am working on it. Maybe it
occurs because I load opengl on the fly.On Tue, 19 Dec 2000, michele wrote:

This is ALL U3D tells me on the console
the test progs for Glide3x ,2x and 3dfx work good as quake3 and quake2.
I think that the prog makes a call to a feature not present in the Mesa
driver I’m using (or excluded by a compiling mistake).

thanks, michele

USING: libGL.so
---- Loading OpenGL Symbols ----
GL_RED_SIZE: 5
GL_GREEN_SIZE: 6
GL_BLUE_SIZE: 5
GL_DEPTH_SIZE: 16
GL_DOUBLEBUFFER: 1

Vendor : Brian Paul
Renderer : Mesa Glide v0.30 Voodoo_Graphics 0 CARD/4 FB/8 TM/2
TMU/NOSLI
Version : 1.2 Mesa 3.3

fxmesa: Received a not handled signal 11

David_Olofson · December 20, 2000, 3:37pm

Wed, 20 Dec 2000 Vasileiou Nikolaos wrote:

About the glPolygon mode call, it is not normal to crash because of that
since it is a standart opengl call and not an unsupported extension or
something like that. quite weird!! Maybe a Mesa bug? who knows!

There seems to be another, perhaps less surprizing problem though, at least
with the Mach64 Rage Pro and G400 drivers; using the lines mode slows down the
rendering by an incomprehensible factor; the frame rate on my G400 drops from
some 150 fps to several seconds per frame! The drop on the Rage Pro is not that
great, but very obvious; similar to dropping back to 100% software rendering.

What’s goin’ on…?

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Matt_Busigin · December 20, 2000, 11:55pm

First the Americans spell it bastarize, and now surprizing? What next? ;)On Wed, Dec 20, 2000 at 04:37:34PM +0100, David Olofson wrote:

There seems to be another, perhaps less surprizing problem though, at least

michele · December 21, 2000, 8:00am

Vasileiou Nikolaos wrote:

About the e call, it is not normal to crash because of that
since it is a standart opengl call and not an unsupported extension or
something like that. quite weird!! Maybe a Mesa bug? who knows!

On U3D the problem is on extension loading. I am working on it. Maybe it
occurs because I load opengl on the fly.

I upgraded to 3.4 and the demo works very slow with glPolygonMode and
really fast without it.

michele

Andreas_Umbach · December 21, 2000, 10:36am

cow at amber.org.uk schrieb am 20 Dec 2000:> On Wed, Dec 20, 2000 at 04:37:34PM +0100, David Olofson wrote:

There seems to be another, perhaps less surprizing problem though, at least

First the Americans spell it bastarize, and now surprizing? What next?

This mailing list is reall going downhill.

First it’s the C-newbies.
Then it’s the spam.
Then the OT posters.
Then the spellcheckers.
What next?

Uh-oh. Looks like the spellchecker-flamers are here too…

Andreas
–
Check out my 3D lightcycle game: http://www.gltron.org
A 0.60 preview/beta for win32/mac is available NOW!
More than 100’000 Downloads of the last version (0.59)

Vasileiou_Nikolaos · December 21, 2000, 11:40am

Seems quite normal to me since most 3d hardware accelerates textured
surfaces (even faster than solid ones) so drawing lines and other stuff
must be calculated in the CPU.On Wed, 20 Dec 2000, David Olofson wrote:

Wed, 20 Dec 2000 Vasileiou Nikolaos wrote:

About the glPolygon mode call, it is not normal to crash because of that
since it is a standart opengl call and not an unsupported extension or
something like that. quite weird!! Maybe a Mesa bug? who knows!

There seems to be another, perhaps less surprizing problem though, at least
with the Mach64 Rage Pro and G400 drivers; using the lines mode slows down the
rendering by an incomprehensible factor; the frame rate on my G400 drops from
some 150 fps to several seconds per frame! The drop on the Rage Pro is not that
great, but very obvious; similar to dropping back to 100% software rendering.

What’s goin’ on…?

//David

…- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' ..- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -’

Manny · December 21, 2000, 7:02pm

Lines are typically drawn with 3 really thin polygons, so the polygon count
in lines mode becomes 3x, causing a slowdown even if it’s all in hardware

–Manny

At 01:40 PM 12/21/2000 +0200, you wrote:>Seems quite normal to me since most 3d hardware accelerates textured

surfaces (even faster than solid ones) so drawing lines and other stuff
must be calculated in the CPU.

Daniel_Vogel · December 21, 2000, 7:26pm

Vasileiou Nikolaos wrote:

Seems quite normal to me since most 3d hardware accelerates textured
surfaces (even faster than solid ones) so drawing lines and other stuff
must be calculated in the CPU.

Untextured polygons should never be slower than textured ones - actually
they can be much faster if you are fillrate limited. One thing that
should be avoided are flat shaded polygons as those are considerably
slower than gouraud shaded ones on modern HW. I think it is mentioned in
the NVIDIA GPU Performance FAQ but I am not sure.

                        Daniel Vogel, Programmer, Loki Software Inc.

Bill_Kendrick · December 21, 2000, 7:58pm

Daniel stated:

One thing that
should be avoided are flat shaded polygons as those are considerably
slower than gouraud shaded ones on modern HW.

???

-bill!

Daniel_Vogel · December 22, 2000, 12:14am

Daniel Vogel wrote:

Untextured polygons should never be slower than textured ones - actually
they can be much faster if you are fillrate limited. One thing that
should be avoided are flat shaded polygons as those are considerably

Considerably is the wrong word. It should read “might be slower”.

slower than gouraud shaded ones on modern HW. I think it is mentioned in
the NVIDIA GPU Performance FAQ but I am not sure.

It was in some V5 tuning docs.

                        Daniel Vogel, Programmer, Loki Software Inc.