Simon Pogarcic wrote:
>
> Hi,
>
> I'm trying to figure out the list of all possible primitives which one
> would implement in full OpenGL driver, derived after flavour and overhead
> of hardware setup for particular primitive. But maybe I'm missing
> something or putting something too much...
>
> 4 Point primitives:
> -------------------
> 1. Point
> 2. Point_Textured
> 3. Point_Wide
> 4. Point_Textured_Wide
>
> 16 Line primitives:
> -------------------
> 1/2. Line_Flat/Smooth
> 3/4. Line_Flat/Smooth_Textured
> 5/6. Line_Flat/Smooth_Stippled
> 7/8. Line_Flat/Smooth_Stippled_Textured
> 9/10. Line_Flat/Smooth_Wide
> 11/12. Line_Flat/Smooth_Wide_Textured
> 13/14. Line_Flat/Smooth_Wide_Stippled
> 15/16. Line_Flat/Smooth_Wide_Stippled_Textured
>
> 8 Triangle/Quad/Rect primitives:
> --------------------------------
> 1/2. Flat/Smooth
> 3/4. Flat/Smooth_Textured
> 5/6. Flat/Smooth_Stippled
> 7/8. Flat/Smooth_Stippled_Textured
>
> "Wide" by points and lines means that they are thicker than 1 point.
> Moreover, I haven't included antialiasing, because it doesn't require
> additional overhead within primitive functions.
>
Polygon offset is best performed at triangle setup.
Backface culling is often best performed at triangle setup.
Twosided lighting depends on the same information as culling - and
certainly requires some code at setup.
There is the issue of single texture vs. multi texture.
There is seperate-specular-color, which requires code at setup.
There are probably others that aren't at the top of my head.
To help avoid combinatoric explosion, note that you can probably do all
of the culling (+ve area, -ve area, no cull) cases together.
I think that what functions you implement will depend on the hardware to
such an extent that you are unlikely to be able to come up with a
'definitive' answer to your search. Triangle setup in software is fast
becoming a thing of the past. The first impact this will have on what
I've said above is that polygon offset and backface culling are no
longer things you want to do in the draw_triangle() routine - you would
almost certainly expect the card to do it for you.
I think that we have to move fairly quickly away from implementations
which call a triangle() function for every triangle - the overhead will
be quite high once all we are doing is filling a buffer with clip-space
vertices (or even projected ones). This will essentially be the same
trap as the glVertex() interface - eventually vertices were so cheap
that that the call itself became a major step in the processing.
It's a funny thing to say, but perhaps for the only time in history, the
corporate computing world could have taught the graphics people a thing
or two about performance.
Keith
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
