Tangent Space Mayhem

Graphics and GPU Programming Programming

Started by RPTD October 11, 2005 10:38 AM

29 comments, last by RPTD 18 years, 6 months ago

11,263

October 20, 2005 11:01 AM

Quote:Original post by FReY
Most people use a normalization cube map to sort this out. Treat your light-direction vector as a 3d texcoord and lookup it's length in a cubemap that effectively normalizes the direction vector. This is done in the pixel shader so that it normalizes the interpolated light direction vector before dotting it with normal obtained from your normal-map.

I'd like to point out this is becoming less and less common, instead the normal way of doing it now is to use normal instructions as on newer cards (any recent ATI and probably NV40 and up from NV) this will be faster and doesnt use up any memory bandwidth, which is alot more presious to concerve (see GDC05 presentations linked to in the Forum FAQ, I'm pretty sure its mentioned in the GLSL one)

zedzeek

529

October 20, 2005 01:13 PM

Quote:I'd like to point out this is becoming less and less common, instead the normal way of doing it now is to use normal instructions as on newer cards (any recent ATI and probably NV40 and up from NV) this will be faster and doesnt use up any memory bandwidth

not to metnion its higher quality than textures as well

Captain Courgette, eat more veg

RPTD

359

Author

October 21, 2005 05:51 AM

as far as i can remeber there is no 'normalize' command in shader-assembler. at last i did not stumble across one. hence i still stick to DP3-RSQ-MUL as this works out.

Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

Eric Lengyel

3,463

October 21, 2005 03:51 PM

NV_fragment_program2 has the NRM instruction, and NV4x has special hardware for normalizations that runs in parallel with everything else so that normalizations are basically free. In order for the compiler to natively use NRM instead of changing it to DP3/RSQ/MUL, you need to specify half-precision (by using the NRMH instruction) and you can't write to the w component of the result. So all normalizations should look like this:

NRMH    vec2.xyz, vec1;

The compiler will also recognize DP3/RSQ/MUL sequences and change them to NRMH when possible. Be sure to declare

OPTION ARB_precision_hint_fastest;

at the top of your fragment programs, and always use write masks to limit writing only to components that you'll use later.

I work on this stuff: Slug Library | C4 Engine | The 31st | Foundations of Game Engine Development | OpenGEX

_the_phantom_

11,263

October 21, 2005 04:24 PM

Quote:Original post by RPTD
as far as i can remeber there is no 'normalize' command in shader-assembler. at last i did not stumble across one. hence i still stick to DP3-RSQ-MUL as this works out.

Well, i did say 'normal' instructions, but if you used a HLSL then you'll get a normlise instruction, which the compiler can then reduce down to the code of its choice (be it DP3-RSQ-MUL or NRMH)

RPTD

359

Author

October 21, 2005 06:50 PM

i had so far bad experiences with 'high level' compilers for shaders. that's why i do all with shader assembly and with low version requirements. especially speed disappointed me badly. i managed to outperform a compiled script by nearly factor 1.5 and more simply doing assembler by hand *pfft*.

the normalize assembler instruction though would be handy as it replaces three instructions with one. it does not exist below 2.0 version not?

Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

Eric Lengyel

3,463

October 22, 2005 06:27 AM

The NRMH instruction is only available on NV40 and higher -- GeForce 6x00 series and 7x00 series.

I also still do all my shader coding in assembly. The high-level compilers generate horrible code in a lot of cases.

I work on this stuff: Slug Library | C4 Engine | The 31st | Foundations of Game Engine Development | OpenGEX

_the_phantom_

11,263

October 22, 2005 06:47 AM

well, thats your choice and if you are both willing to live with the restrictions then thats up to you, but i'm wondering when was the last time you both tried the compilers and on what hardware?

RPTD

359

Author

October 22, 2005 07:26 AM

last time around 2 month ago, nvidia Cg compiler on both ATI and NVidia based cards. my simple lighting shader compiled was double as slow as my hand written assembler shader. furthermore the compiled shader was two times bigger fitting less into the restrictions of low version shaders.

the old rule is still valid:

what are the three reasons for using assembler?
speed, speed and speed [wink]

site question. i poked around the glxinfo of my ati card finding GL_ARB_shading_language_100. this means i can do GLSL on this one. now i poked a bit at the language reference but missing some key informations. maybe somebody with GLSL knowledge can fill in the gaps.

1) are real loops supported, hence not unrolled ones?
2) are there size restrictions on the used code?
3) are the restrictions on the number of attributes you can use?
4) can you use arrays of variable sizes as attributes?
5) who does compile the code? opengl or the graphic card driver?

EDIT: btw... assembler does not have restrictions compared to the compiled version, unless you define restrictions in a different way.

Life's like a Hydra... cut off one problem just to have two more popping out.
Leader and Coder: Project Epsylon | Drag[en]gine Game Engine

_the_phantom_

11,263

October 22, 2005 08:15 AM

by 'restrictions' I mean that what you've got is what you've got. The ARB fp/vp interface isnt going to be updated again with GLSL being the only focus. NV will probably continue to support their own extensions ofcourse but when it comes to ATI or anyone else GLSL is the way forward.

anyways, GLSL questions;

1. Depends on the hardware. If the hardware can support true loops then the compiler should be able to compile the code down to represent them. If the hardware cant then loop unrolling will kick in. Loops could be unrolled if the compiler decides its faster todo so (short loops for example).

2. Your GLSL code could be huge, however the final restrictions come down again what the hardware can do instruction wise.

3. The attributes are again are hardware restriction. You can query for it to see how many you can supply.

4. I think this is a no. You can define an array attribute as having no size (vec3 foo[]) however you must either redefine it to the correct size of staticaly access the highest element required later in the code. This is because the compiler needs to be able to work out how much space to allocate. This could be changed in the future, but as current hardware has restrictions having a truely dynamic array just wouldnt work when it comes to allocation resources.

5. The graphics card driver compiles the code. OpenGL is just a spec so isnt compiling anything [wink]

Tangent Space Mayhem

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Tangent Space Mayhem

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines