[Mesa-dev] [PATCH 2/2] draw: inject frontface info into wireframe outputs

[Roland Scheidegger]

Am 01.08.2013 06:21, schrieb Zack Rusin:
>>> +   if (draw_will_inject_frontface(lp_context->draw) &&
>> I think it's annoying you have to do these calls to determine if there's
>> a valid frontface here for each line instead of just per draw call but
>> it doesn't seem easy to avoid it.
> 
> Yea, there's no trivial way of avoiding it.
> 
>> Also, no love for llvmpipe point face? I realize d3d10 doesn't require
>> it but OpenGL (and IIRC d3d9) do.
> 
> I didn't know of any tests for the points and we care only about lines right now. It's just four extra lines of code or so, so I can trivially add it but I don't have anything to test it with.
Yeah looks like there's no piglit test for this.

>> Looks like quite a heavy interface (and sort of silly to allocate 128
>> bits in the vertex data (so actually twice that for one line) for 1 bit
>> of information but given all our data passed on to the line/point funcs
>> are float4 I don't really see any other easy way neither), but seems all
>> necessary unfortunately. I guess another option would be to pass the
>> face info always along the vertex data no matter what (which would mean
>> all those additional calls for setting up outputs, determining if
>> there's a valid frontface etc. could go along with the storage needed)
>> for all primitives to the point/line/tri funcs but I'm not really
>> thrilled about that idea neither (passing it for tris so it doesn't have
>> to be recalculated may or may not be a good idea neither).
> 
> Yes, plus then we'd need a brand new pipeline stage that is always run and that is largely useless for vast majority of rendering. It's sort of a lose lose scenario. The only thing that is clear is that we have to pass the data along the shader outputs, everything else is a messy glue to make it possible.
Well it wouldn't really be a new pipeline stage, facing is calculated
most of the time anyway (in the cull stage), plus as said for tris we
recalculate it in the driver always (at least for llvmpipe) so no loss
there.
There's actually yet another issue with recalculating face in drivers,
it is possible draw turns tris into points/lines and back into tris
again (first step with poly fill mode, second with wide points / wide
lines). Again this means that face calculation done for tris after draw
is just going to screw things up. I think draw itself again does the
right thing here inside draw (keep the facing information from the
original polygon) but this information doesn't make it out of draw.
So just always calculating face first in draw and pass that information
along would also help there. (There is actually a difference to how we
calculate facing in llvmpipe, as we do it with fixed point coordinates
which I think may not guarantee the outcome is the same, not sure though
if that matters).
I am not convinced this really would slow things down in general for
ordinary tris, as it would allow us to skip recalculating facing (area)
which we always do anyway in llvmpipe for tris no matter what. But we
could always change that later with some draw cleanup.

Roland