i’ve never done any vp because i can’t due to my graphic card (gc).
However, i’d like to know some about them, in the case i understood well, i may buy some vp gc. I know there are docs about it, but I prefer know what you feel about them as you’re using them for a while now…
What change regarding normal va ? It seems you could do some computation (so the name vp) as transforming these vertex into others: as rotating, translating…
Do you do some things like that ?
Vertex *my_vert= ‘something’;
Matrix& my_matrix= ‘some_transform’;
my_vert= glComputeVP( my_matrix);
(glComputeVP certainly does not exist.). it’s a way i’d done them if…
Or do you need to compute for each vertex ?? and are they compatible with all VA technics (as CVA,VAR ?).
Vertex programs simply replace what’s done in the pipeline in vanilla OpenGL. They operate on streamed vertex data.
You have the input information like object space coordinate, color, normals, texture coordinates as registers or from a structure depending on your language, and you have access to matrices. Then you go to town with your program.
Your output is in the form of data to interpolators that will ultimately be sent to the fragment program, you simply write the results to a predetermined set of registers or structure members.
VP output gets sent either to the default OpenGL fixed function pipeline fragment processor or to a fragment program you’ve written. Fragment programs are essentially the same concept except they take in the fragment data that has been interpolated across the primitive since the vertex program wrote it, they don’t have matrix operations like VPs, they can fetch filtered texture data using coordinates generated internally or sent by the vertex program (or through from the application) and they output to the framebuffer (registers/structure) and that’s what is used by the standard fixed function back end for fragment processing like zbuffer and framebuffer blending.
It’s tricky to use an approach like this for most general purpose computing for reasons that should now be obvious. It has been attempted and published though.
[This message has been edited by dorbie (edited 06-04-2003).]
well, so vp pass threw some stages:
interpolators (i think for calculating what you want to transform)
fragment program that do textures… so, this may be a good solution for moving multitexrures here…
I may read about them in order to get a more effective understand.
You can still use Vertex Programs even if you don’t have a card that supports them in hardware. They will just run in software, and actually they are still quite fast. Not as much as a GPU could do them of course but still not bad. As far as buying a gc that supports them in hardware, you can find one of these for real cheap now. Just be carefull on which card you buy. Make absolutly sure it supports vp in hardware. For example the nvidia MX line of cards do not. Even if they have the GeForce 4 name on them.
You tell that vp is always supported at software if not in hardware, but I’m not sure. I may be confuses, so i need to know:
Every one knows 3dmark now… test for vertex shaders are not supported on geforce mx cards (i’ve got 2mx). But this may not be as vp the shaders, isn’t it ? I think shaders are computed at a fragment of a vp.
If i’m completly wrong, just forgive me, i need some lecture…
Shaders is the same as Programs, just that shaders is DX naming and Program is Opengls name on them
then you have 2 different kinds of programs right now
VertexPrograms - that handles vertexdata, and
FragmentPrograms - that computes per fragment.
Vertexprograms can be easily runned in the CPU without too much speed loss, but emulated FragmentPrograms are very, very slow…
So for Vertexprogram you can get almost any nvidia card you like, they emulate the VP on cards that cant handle it natively. Dont know about ATI in that department.
But Fragmentprograms works only in the GfFX serie and Radeon 9500 or better, for now atleast… ( or have you seen any other vendor supporting that yet?)
nVidia supports simpler fragmentprograms in theire other cards, but you have a nvidia only API to use there, and its not as easy and flexible as arb_fragment_program
Originally posted by Mazy:
[b]Shaders is the same as Programs, just that shaders is DX naming and Program is Opengls name on them
as vertex for OpenGL and pixel for M$ ?? so we call it VP but M$ calls it PS ? ****
then you have 2 different kinds of programs right now
VertexPrograms - that handles vertexdata, and
FragmentPrograms - that computes per fragment.
Vertexprograms can be easily runned in the CPU without too much speed loss, but emulated FragmentPrograms are very, very slow…
That’s why it’s disabled by default…
So for Vertexprogram you can get almost any nvidia card you like, they emulate the VP on cards that cant handle it natively. Dont know about ATI in that department.
But Fragmentprograms works only in the GfFX serie and Radeon 9500 or better, for now atleast… ( or have you seen any other vendor supporting that yet?)
i’m not really uptodate to that sort of news…
nVidia supports simpler fragmentprograms in theire other cards, but you have a nvidia only API to use there, and its not as easy and flexible as arb_fragment_program
as vertex for OpenGL and pixel for M$ ?? so we call it VP but M$ calls it PS ?
No. Where’d you get that idea? ARB_vertex_program has the analgous functionality of D3D’s Vertex_shader 1.1 spec.
D3D’s Pixel shader 2.0 is approximately equivalent to ARB_fragment_program. D3D doesn’t refer to the concept of a fragment; it perfers to use the less-accurate term, pixel.
