OpenGL Extensions Viewer (realtech VR) & Mesa

Started by ggab, 23 June 2004, 20:44:35

Previous topic - Next topic

ggab

<<<<<<my tests:>>>>>>   with lastest v2.0.9.171 & a voodoo3

### mesaFX 6.1.0.8 (hardware)





Report:
{*} Compiled vertex array support.*This extension improve OpenGL performances by used video memory for vertex transformation.
{*} Multitexture support.*This features speed up rendering complex rendering like lightmaps or environment mapping.
{*} No 8bit palette texture support.*This may leads performance loss on some old applications.
{*} No Fragment program extension found. *This feature enables per pixel programming (DX8 Pixel Shader) Some for actual or future OpenGL programs may requires this extension to run.
{*} No ICD Registry Entry. *The current OpenGL driver doesn't expose the SOFTWARE/Microsoft/Windows (NT)/CurrentVersion/OpenGLDrivers registry entry. Unable to detects driver version, driver revision name and filename.
{*} No S3TC compression support.*This may leads performances loss on some applications.
{*} No Stencil support *Your current desktop configuration DOES NOT support stencil buffering. Some applications may not run.
{*} No vertex program extension found*This feature enables vertex programming (DX8 Vertex Shader) Some for actual or future OpenGL programs may requires this extension to run.
{*} Texture Edge Clamp extension found. *This feature enables an important DX6 feature for texture mapping.
{*} Secondary color support.*This feature enables specular lighting on polygons.

{*} @ both mesa´s.

{only} Few texture units found.*This would slow down some applications using Fragment Program or extensive texture mapping.
{only} Small texture size support. *Some programs may not display large textures correctly.


### mesa 5.0.1 (software)





Report:
//remember {*} @ both mesa´s, so here too.
and...
{only} No Hardware support *You current desktop configuration DOES NOT support OpenGL Hardware Accelerated.
{only} No ZBuffer support *You current desktop configuration DOES NOT support Z-buffering.
{only} Occlusion test support *This extension provides an hardware accelerated culling for objects.

this mesa 5 software compiling is available here:

http://www.iespana.es/serchmx/Mesa501.zip

----------------------------------------------------------------
2 questions=

-> with glView, in v1.2:  GL_EXT_blend_subtract
this extension is not supported by voodoo3? why?

because in a voodoo5 IT IS supported.
and the % are better: (1 extension more in each Ogl versions)
1.1 --- 100%
1.2 -- 81%
1.3 -- 55%
1.4 -- 53%
1.5 -- 16%


-> this v1.2 SGI extensions:
GL_EXT_blend_color
GL_EXT_blend_minmax

that, aren´t supported by mesaFX right now... (well, there is one more: GL_EXT_blend_subtract  but it seems that with v5 are supported....)

can be or is possible to implement them, in future versions? (i wish... :) )

because some applications/games with OGL v1.2 that i tried with the mesa 5.0.1 by software runs OK (slow... but works), so if the 2 extensions left in mesaFX can be done via hardware or even with a software implemention, it will be so cool!! and has the same v1.2 at 100% as the mesa 5.0.1 (software) one.
 

dborca

Hi Gabriel,

your posting is a real mess, so I couldn't spot much out of it. :D

Anyway, here are some answers:
  • the Voodoos always had a maximum of 2 TMUs. Hence the "few texture units found". MesaSW uses 8 TMUs.
  • you could avoid the "small texture size support" by using MESA_FX_MAXLOD.
  • GL_EXT_blend_subtract is not supported by pre-Napalm core, because the fog unit does only addition.
  • GL_EXT_blend_color / GL_EXT_blend_minmax cannot be done due to HW limitations.
The truth is, we could implement all of them in SW, but it will be slow. And I mean even slower than regular MesaSW, because we're dealing with LFB memory when we hit the total rasterization fallbacks, but the HW has to sync with the 3D engine. The other negative aspect is that sometimes there are minor differences between HW and SW which will result in minor glitches.
Regards,
Daniel Borca

bloodworm

How much of this is done in Mesasw now? that is not done in the HW?  does the mesasw utilize more than one processor if it were available?
Bloody Mess

dborca

QuoteOriginally posted by bloodworm

How much of this is done in Mesasw now? that is not done in the HW?  does the mesasw utilize more than one processor if it were available?
Theoretically, MesaSW should have 100% compliance (minus the bugs) :D
MesaSW is not written with multi-processor in mind. Few years back, when I got involved in Mesa, I was using a P166MMX. [:p] Mesa does support multi-threading. However, many (and I mean _many_ applications) are not aware of how many processors are running on. Most of the time, this is irrelevant.
Regards,
Daniel Borca

bloodworm

is there a way that we could be suplementing our (your) mesafx hardware driver with the mesasw driver so that we get all the benefits of the hardware acceleration and then we also can be running what is left over with mesasw via the CPU?
Bloody Mess

dborca

QuoteOriginally posted by bloodworm

is there a way that we could be suplementing our (your) mesafx hardware driver with the mesasw driver so that we get all the benefits of the hardware acceleration and then we also can be running what is left over with mesasw via the CPU?
Mesa is always compiled with the SW driver. MesaFX is compiled with SW + FX drivers. But... doh... I hate quoting myself:
Quotewe could implement all of them in SW, but it will be slow. And I mean even slower than regular MesaSW, because we're dealing with LFB memory when we hit the total rasterization fallbacks, but the HW has to sync with the 3D engine
Regards,
Daniel Borca

bloodworm

dborca,
I noticed that in ggab's post above, the mesa 5.0.1 software contains
many more extensions than the mesa 6 HW above (and on mine at home and work).  under the compliance, the V1.3 contains 9 out of 9? 100%? (mesa 6.1.0.8 HW only shows 5/9 on mine) also the 1.4 has 14 out of 15? (mine shows 8/15) and the 1.5 has 4 out of 6? (mine shows 1/6)

I assume this is with a voodoo3 card,  and mine is a voodoo5 5500 agp card.

If GLview cannot see these "extra" extensions running via "software" emulation, then our games are not seeing them as well?

I am no expert on Mesa drivers to be sure (YOU are da man!), but what I am asking is why does the mesa 6.1.0.8 driver not show these extra extensions?  even if they are only run by the CPU (software) and not the card itself (hardware)?  or is this just a limitation of glview?
Bloody Mess

gab

and my new test with  rc4 & voodoo3 :
 

dborca

@bloodworm
Even though MesaFX has a built-in software rasterizer, I chose not to enable extensions not supported in HW. Because they are slow, and I mean SLOW!

Sometimes it is best to not advertise, and let the game engine to choose another path that totally avoids those, instead of advertising them and get 1 FPS.

@gab
NICE ARTWORK! :D Anyway, the next on my schedule is an OpenGL 1.5 extension. [:0]
Regards,
Daniel Borca

r21vo

QuoteEven though MesaFX has a built-in software rasterizer, I chose not to enable extensions not supported in HW. Because they are slow, and I mean SLOW!
isn't that possible to make some kind of compability mode (make some extensions combining hardware features so they would be not so slow, but at least something similar to ones in specification). and then disable these extensions by default, but leave an option to enable them. I guess it would be great for testing purposes.

3dfx tricks, tests and wallpapers

3dfx.rule.lv

dborca

QuoteOriginally posted by r21vo

isn't that possible to make some kind of compability mode (make some extensions combining hardware features so they would be not so slow, but at least something similar to ones in specification). and then disable these extensions by default, but leave an option to enable them. I guess it would be great for testing purposes.
Yes and no. Most of them would need LFB writes. Which is evil. Other extensions are already using tricks: how do you know I implemented separate_specular and secondary_color? :D
Regards,
Daniel Borca

bloodworm

ahhhhh, I wasn't thinking that it would slow down, I was thinking that it would speed things up, but of course you are correct.  NOW i understand.....  keep up the good work dborca!  what opengl 1.5 extension are you going for next?  and what other extensions are acctually possible for future development?  also, is there a way to run the software extensions via a second processor if we indeed had a motherboard capable of it?  or is this still a lose/lose proposition for FPS?
Bloody Mess

ggab

many people are asking for "an especial edition" (at least, for testing purposes), mixing the default HW extensions (mesaFX right now) with some of the SW driver.
But, dborca tell us the truth (some posts ago): :D

QuoteOriginally posted by dborca

QuoteOriginally posted by bloodworm

is there a way that we could be suplementing our (your) mesafx hardware driver with the mesasw driver so that we get all the benefits of the hardware acceleration and then we also can be running what is left over with mesasw via the CPU?
Mesa is always compiled with the SW driver. MesaFX is compiled with SW + FX drivers. But... doh... I hate quoting myself:
Quotewe could implement all of them in SW, but it will be slow. And I mean even slower than regular MesaSW, because we're dealing with LFB memory when we hit the total rasterization fallbacks, but the HW has to sync with the 3D engine

[?] Finally, are you interesting in this "special edition", to become true?
(we know, it will be slow), but only 1 or 2 FPS?, and if we have a 2Ghz CPU?
 

r21vo

QuoteOriginally posted by dborca
Most of them would need LFB writes. Which is evil.
As far as i know LFB means Linear Frame Buffer, does VooDoo cards support it? If they do, then can you tell where is the problem - in complexity or in lack of hardware support?

3dfx tricks, tests and wallpapers

3dfx.rule.lv

dborca

QuoteOriginally posted by r21vo

QuoteOriginally posted by dborca
Most of them would need LFB writes. Which is evil.
As far as i know LFB means Linear Frame Buffer, does VooDoo cards support it? If they do, then can you tell where is the problem - in complexity or in lack of hardware support?
Yes, all the Voods have it (LFB). The problem is... LFB is slower when the 3D engine is awake. That is, using a Voodoo3 as a VESA card yields faster SW rasterization than LFB when the 3D engine is active.
Regards,
Daniel Borca