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