[ShivanSpS]

I was reading about VTF today on internet and i found something.

http://www.opengl.org/wiki/Vertex_Texture_Fetch

Specialy this part call me the atention.

ATI/AMD :
ATI/AMD chose not to have VTF in their SM 3.0 GPUs.
X300 up to X1950. All of their standard X series.
They said it would be too slow. It would be better to do Render_To_VertexBuffer (R2VB).
In OpenGL, to do R2VB you would need PBO support.

PBO became core in GL 2.1 and ATI's driver do support GL 2.1.
ATI's DX10 parts, in other words all their GPUs with the HD in the name, support VTF.
ATI's driver does report 16 for GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS but users are saying that their shaders don't work.

[Zacam]

I believe that was touched on during the initial release of the MediaVP's and the related thread for ATI card users that I started.

Nice to know however that the information is widespread enough that pretty much anybody can find it however.

[chief1983]

I thought that sounded familiar...

[ShivanSpS]

I believe that was touched on during the initial release of the MediaVP's and the related thread for ATI card users that I started.

Nice to know however that the information is widespread enough that pretty much anybody can find it however.

Actually what i was thinking if wasnt possible to use R2VB instead of VTF for Radeon X1K

[taylor]

Unless I'm just completely missing something, we aren't making use of VTF.

[ARSPR]

Unless I'm just completely missing something, we aren't making use of VTF.

Taylor, you should talk with Zacam. He was who "discovered" the possible x1Kxx series issue as posted here: http://www.hard-light.net/forums/index.php/topic,58371.msg1178750.html#msg1178750

I suppose he will welcome expert advice.

[taylor]

I had skimmed over that topic when it was started and kept up with it for a little bit, but I didn't think that the VTF thing was seriously considered as the problem.  It seemed like it was mentioned mostly just as one point of difference.  I admit to not reading the entire thread though, so maybe it was brought up more than I realized.

I'm pretty sure that the issue is with the way that lighting had to be handled.  Without a much larger code rewrite, what I could do with it all was pretty limited.  That part of the shaders has caused the most trouble for everyone.  Cutting it down to 4 lights instead of 8 tends to make a big difference but then it doesn't look as good.  Unfortunately the old HTL upgrade didn't include still allowing software lights to be used (color vertex), otherwise it wouldn't be that much of an issue.  Or if the rendering efficiency of the engine wasn't so bad then multipass lighting could be used without incurring an average 70% performance hit.


But if you want to run a few tests to try and narrow down the problem Zacam then PM me and I'll help out.

[Zacam]

Well, the thing that confuses me, is that if it is simply an issue of lights, and the rads in question were made by ATi to support SM3, that should also include support for the hardware lights as well, yes? So, I think the VTF is utilized by a proper SM3 system by utilizing the VTF natively (eg: without an exension call, just an enumeration to pass lights) that fails on those cards because of the lack of a supporting feature that would make it necessary to perform.

But then, one of the reasons why ATi stated that they chose RTVB instead of VTF was it supposedly wasn't fast enough (VTF), so maybe the hardware die does _not_ in fact have the necessary horsepower (inspite of it's SM3 capable rated spec) to handle the lights after all.

I'll do some light pass based tests and see what I get.

[taylor]

I don't know that it actually is the lights, I just know that the lights are the most iffy part of the shaders.

It's simple enough to test out the theory though.  You just need to start the game with -no_vsync and -no_fps_capping and then run some tests the ships lab.  Turn off all maps and lighting, then turn on fixed rendering and check the FPS counter at the bottom.  Turn off fixed rendering and check for a change in the FPS counter.  If it is the same, or nearly the same, then basic shader support is good.  Next turn on the base/diffuse map to see if basic texture support makes a difference.  If things still look good then turn lighting back on and see if there is any change.  If not then it isn't the lighting code that's the problem.  And in that case you can just do the same thing map by map until the find the combination that has the biggest performance hit.

[Zacam]

By default settings, FPS flickers around 290-310. Really hard to read, it flickers a lot. Thank FRAP's.
It maintains this through Fixed, No Normal, No Glow, No Diffuse or any combination of those.
320-340: No Lighting
320-350: No Spec
360-380: Fixed, No Spec/No Lighting
350-410: Fixed, No Spec, No Lighting

I also had Enable Subsystem Rotation, Show Thrusters, No Culling.

Code: [Select]

C:\Games\FreeSpace2\fs2_open_3_6_10d.exe -mod FSU -spec -glow -env -nomotiondebris -missile_lighting -normal -3dshockwave -no_vsync -cache_bitmaps -dualscanlines -targetinfo -orbradar -rearm_timer -ship_choice_3d -weapon_choice_3d -3dwarp -snd_preload -loadallweps  -ambient_factor 10 -no_emissive_light -spec_exp 11.0 -spec_point 0.6 -spec_static 0.8 -spec_tube 0.4 -ogl_spec 30 -clipdist 0.1 -fov 0.55 -no_fps_capping

No AA or AF on in Launcher or CCC. x1800 GTO.
Compared to the 8800 640 GTS, not too bad.
390-410: Standard
470-520: No Lighting
470-520: No Spec
480-550: Fixed, No Spec/No Lighting
490-580: Fixed, No Spec, No Lighting.

Both cards tested in the same system.

Edit: I can't test on my x1650 XT at the moment as I need to replace the heatsink and/or fan on it.