On Sun, 21 Dec 2003 09:52:32 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote:
Keith Whitwell wrote:
Felix Kühling wrote:
On Sat, 20 Dec 2003 08:01:07 -0500 Keith Whitwell <[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
Hi,
while working on the savage driver I found two problems. One with
tnl/t_vb_render.c, the other one with tnl_dd/t_dd_tritmp.h. Both started
since I use different hardware primitives for quads and
triangles/polygons.
TAG(quad) in t_dd_tritmp.h calls RASTERIZE( GL_TRIANGLES ) directly before QUAD( (v[0]), (v[1]), (v[2]), (v[3]) ). RASTERIZE should be called with GL_QUADS so that the driver selects the correct hardware primitive. Also I believe that we could use the same condition as in TAG(triangle), namely
if (DO_UNFILLED) RASTERIZE( GL_QUADS );
This looks ok.
I wonder when this condition will be true anyway. But without this RASTERIZE is called for every single quad!
The second problem is in t_vb_render.c with clipped primitives. When a clipped primitive is rendered the PrimitiveNotify callback gets called with GL_POLYGON. When the next unclipped primitive is drawn we have to call PrimitiveNotify again with the original primitive type.
I think this is a misunderstanding. Although at a hardware level, you may be rendering with who knows what primitive, at a GL level, you are still attempting to render a TRIANGLE, QUAD, whatever.
The only time a difference between TRIANGLES, QUADS and POLYGONS emerges is if flat shading is active, in which case a different vertex is choosen to provide the color for the whole primitive. Is this the problem you're seeing, or is it something less subtle?
I am aware of the flat shading issue, but this is not the problem here.
Polygons are rendered using triangles. I use a different hardware primitive for Quads. So after rendering a clipped quad as a polygon (using triangles as hardware primitve) I have to tell the driver that the next primitive is going to be a quad again and that it has to select the right hardware primitive. Without this some quads got rendered as triangles with half the quad missing after a clipped quad was rendered as a polygon.
Hmm. Sounds like we need to explictly restore the old primitive type after clipping, or to always try and set the primitive type but shortcircuit the operation if there is no change.
Your patch looks like it's doing this, but isn't the cleanest code. I'd rather see a 'current' primitive in the tnl context maybe, and only call Driver.PrimitiveNotify() when that primitive changes.
Hmm. This would have to be done in conjunction with restoring the old primitive after rendering each clipped primitive.
I still think this would work out cleaner than the 'last_clipped' variable, etc that you're using at the moment.
My first approach was to restore the old primitive after each clipped one. But that would result in reduntant primitive switching if several primitives are clipped in a row. Therefore I came up with the last_clipped variable.
I see where you're going. I agree that probably some further mechanism would be required to make my scheme efficient.
If primitive switching is a significant cost, is it worthwhile using hardware quads when clipping is known to be likely?
This problem doesn't show up in the other drivers because when clipping is known likely, they all decompose all 'higher' primitives to triangles. This means more vertices are sent to the card, but at the benefit of sending fewer primitives.
For vertex-buffers where VB->ClipOrMask == 0, and it is known that clipping will not occur, there is the code in eg. i830_render.c which will endeavour to send whole primitives down to the card. Note that even in this case it is not always advantageous to do so - large numbers of small triangle-strips or fans are handled faster on the i830 by sending a single large list of triangles due to the overheads of starting a new primitive.
Keith
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
