RingWraith
Newcomer
Is this just a fancy named Math Co-processor? (like the ones back in the day for CPU's)
Question about PPP
- Thread starter RingWraith
- Start date
I asked this exact same question a little earlier, maybe this thread can help a little. The way I see it is PPP gives the GPU total control over vertices and can create and destroy and add effects to its own vertices so in a way yes it is a maths co-processor but with added abilities compared to Vertex Shaders.
http://www.beyond3d.com/forum/viewtopic.php?t=8666
More information.
PS if anyone disagrees with my analysis I apologise because I don't have the knowledge to really understand it, not yet anyway.
http://www.beyond3d.com/forum/viewtopic.php?t=8666
More information.
PS if anyone disagrees with my analysis I apologise because I don't have the knowledge to really understand it, not yet anyway.
One thing about PPP still bugs me though. When you write a vertex shader you have a pre-determined set of outputs, texcoord, position, color, fog, etc. Same for a fragment shader, you have color for each render target and a depth value. But on a PPP it would seem as if, dependent on your input values (level of detail which would control the tesselation density), that you could end up with a wildly different quantity of outputs (tesselated triangles). How this fits into the "stream" nature of the GPU for me is unclear.
Mind you I'm not an expert mulitmedia programmer (yet
) so I could be wildly off the reservation here.
Mind you I'm not an expert mulitmedia programmer (yet
) so I could be wildly off the reservation here.3dcgi:
I realize with a PPP that the core structure of the VS won't really change. My confusion lies with the input->output model of the PPP itself rather than the VS. Both the VS and the PS work on a strictly functional model with a finite, predetermined collection of outputs. But it seems as if the PPP could theoretically output, per tessellated surface, either (for example) 4 vertices or 400 vertices depending upon the level of detail it determines neccessary.
Input a pre-transformed vertex into a VS and you will return a data structure defining the properties of one transformed vertex.
Input the pre-rastered properties (interp'd color, tex coords, constants) of one pixel into a PS and you will return a data structure holding the color value(s for MRT) and a depth value for one pixel.
Input a surface into a PPP to be tessellated and retrieve God knows how many verts.
I realize with a PPP that the core structure of the VS won't really change. My confusion lies with the input->output model of the PPP itself rather than the VS. Both the VS and the PS work on a strictly functional model with a finite, predetermined collection of outputs. But it seems as if the PPP could theoretically output, per tessellated surface, either (for example) 4 vertices or 400 vertices depending upon the level of detail it determines neccessary.
Input a pre-transformed vertex into a VS and you will return a data structure defining the properties of one transformed vertex.
Input the pre-rastered properties (interp'd color, tex coords, constants) of one pixel into a PS and you will return a data structure holding the color value(s for MRT) and a depth value for one pixel.
Input a surface into a PPP to be tessellated and retrieve God knows how many verts.
akira888 said:
Yes, I think all the vertex and their parameters are generated(deleted) automatically according to the LOD and stored into a cache just like today's vertex buffer,waiting to be fed into the VS later.
another question: is HOS the thing which I call parametric representation of a surface, such as a Bezier or a NURBS surface by which you only need to manipulate a few control points to reshape the surface?
My opinion on programming for a PPP.
A 'static' PPP (number of output triangles is constant) would be fairly simple to write shaders for. You'd just end up filling up an array that is the output. This design of course would likely have a 'caps' value that would specify maximum number of triangles that can be output.
A 'dynamic' PPP (number of output triangles can vary for each input triangle) would likely require special functions/instructions that would output a single triangle/vertex at a time, but can be called multiple times, in a loop for example. This of course is so it would stall if the buffer between the PPP and VS has become full. I'm thinking here something along the lines of the OpenGL immediate mode glBegin(...); glEnd();
A 'static' PPP (number of output triangles is constant) would be fairly simple to write shaders for. You'd just end up filling up an array that is the output. This design of course would likely have a 'caps' value that would specify maximum number of triangles that can be output.
A 'dynamic' PPP (number of output triangles can vary for each input triangle) would likely require special functions/instructions that would output a single triangle/vertex at a time, but can be called multiple times, in a loop for example. This of course is so it would stall if the buffer between the PPP and VS has become full. I'm thinking here something along the lines of the OpenGL immediate mode glBegin(...); glEnd();
