> > + 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. > 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. z _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
