3dfxzone.it ~ SFFT Drivers ~ MesaFX ~ 3D-Analyze ~ 3dfx Headlines ~ 3dfx Cards ~
Home | Profile | Register | Active Topics | Members | Search | GoogleSearch | FAQ | 3dfxzone.it
Username:
Password:
Save Password
Forgot your Password?

 Index
 3dfx Hardware & Software
 General Discussions
 OpenGL Extensions Viewer (realtech VR) & Mesa
 New Topic  Reply to Topic
 Print topic

Next Page
Author Previous Topic Topic Next Topic
Page: of 5

ggab
Average

Argentina


294 Posts

Posted - 23/06/2004 :  20:44:35  Show Profile  Visit ggab's Homepage  Send ggab an ICQ Message  Click to see ggab's MSN Messenger address  Reply with Quote
<<<<<<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
Average

Romania


425 Posts

Posted - 24/06/2004 :  09:42:41  Show Profile  Visit dborca's Homepage  Send dborca a Yahoo! Message  Reply with Quote
Hi Gabriel,

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

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
Go to Top of Page

bloodworm
Average

USA


278 Posts

Posted - 24/06/2004 :  14:42:02  Show Profile  Visit bloodworm's Homepage  Reply with Quote
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
Go to Top of Page

dborca
Average

Romania


425 Posts

Posted - 25/06/2004 :  08:40:41  Show Profile  Visit dborca's Homepage  Send dborca a Yahoo! Message  Reply with Quote
quote:
Originally 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)
MesaSW is not written with multi-processor in mind. Few years back, when I got involved in Mesa, I was using a P166MMX. 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
Go to Top of Page

bloodworm
Average

USA


278 Posts

Posted - 25/06/2004 :  22:43:16  Show Profile  Visit bloodworm's Homepage  Reply with Quote
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
Go to Top of Page

dborca
Average

Romania


425 Posts

Posted - 26/06/2004 :  12:07:36  Show Profile  Visit dborca's Homepage  Send dborca a Yahoo! Message  Reply with Quote
quote:
Originally 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:
quote:
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


Regards,
Daniel Borca
Go to Top of Page

bloodworm
Average

USA


278 Posts

Posted - 30/06/2004 :  17:54:51  Show Profile  Visit bloodworm's Homepage  Reply with Quote
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
Go to Top of Page

gab
Novice

8 Posts

Posted - 01/07/2004 :  08:31:48  Show Profile  Visit gab's Homepage  Reply with Quote
and my new test with rc4 & voodoo3 :
Go to Top of Page

dborca
Average

Romania


425 Posts

Posted - 01/07/2004 :  12:49:17  Show Profile  Visit dborca's Homepage  Send dborca a Yahoo! Message  Reply with Quote
@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! Anyway, the next on my schedule is an OpenGL 1.5 extension.

Regards,
Daniel Borca
Go to Top of Page

r21vo
Average

Latvia


294 Posts

Posted - 01/07/2004 :  15:21:43  Show Profile  Visit r21vo's Homepage  Reply with Quote
quote:
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!

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
Go to Top of Page

dborca
Average

Romania


425 Posts

Posted - 01/07/2004 :  18:48:33  Show Profile  Visit dborca's Homepage  Send dborca a Yahoo! Message  Reply with Quote
quote:
Originally 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?

Regards,
Daniel Borca
Go to Top of Page

bloodworm
Average

USA


278 Posts

Posted - 01/07/2004 :  22:11:10  Show Profile  Visit bloodworm's Homepage  Reply with Quote
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
Go to Top of Page

ggab
Average

Argentina


294 Posts

Posted - 02/07/2004 :  10:12:01  Show Profile  Visit ggab's Homepage  Send ggab an ICQ Message  Click to see ggab's MSN Messenger address  Reply with Quote
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):

quote:
Originally posted by dborca

quote:
Originally 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:
quote:
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




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?
Go to Top of Page

r21vo
Average

Latvia


294 Posts

Posted - 02/07/2004 :  11:25:28  Show Profile  Visit r21vo's Homepage  Reply with Quote
quote:
Originally 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
Go to Top of Page

dborca
Average

Romania


425 Posts

Posted - 02/07/2004 :  13:35:57  Show Profile  Visit dborca's Homepage  Send dborca a Yahoo! Message  Reply with Quote
quote:
Originally posted by r21vo

quote:
Originally 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
Go to Top of Page

r21vo
Average

Latvia


294 Posts

Posted - 03/07/2004 :  00:38:54  Show Profile  Visit r21vo's Homepage  Reply with Quote
dborca,
now I understand why you said "evil" :) Does this problem occur for all VooDoo cards? And how do you think - it's because of bad card architecture or just bios problem?
So if LFB is unusable, is there any alternatives?


3dfx tricks, tests and wallpapers

3dfx.rule.lv
Go to Top of Page
Page: of 5 Previous Topic Topic Next Topic  
Next Page

 New Topic  Reply to Topic
 Print topic
Jump To:

 

Forum Rules

Legal Info

Privacy

Contact Us

3dfxzone.it

HWSetup.it

ForumZone.it

 

All trademarks used are properties of their respective owners - Forum Graphics and Contents © 2001 - 2014 3dfxzone.it - Forum Engine © Snitz Forums