We do have hardware antialised lines. If we care, we should actually fix them to be conformant (or as close as possible) instead of using this knob to fool testcases using swrast.
For some interesting reading on the state of GL_*_SMOOTH across several drivers, see: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html --- src/mesa/drivers/dri/i965/brw_draw.c | 9 --------- 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_draw.c b/src/mesa/drivers/dri/i965/brw_draw.c index 44d3e1b..b2e89ba 100644 --- a/src/mesa/drivers/dri/i965/brw_draw.c +++ b/src/mesa/drivers/dri/i965/brw_draw.c @@ -283,15 +283,6 @@ static GLboolean check_fallbacks( struct brw_context *brw, if (brw->intel.conformance_mode == 0) return GL_FALSE; - /* BRW hardware will do AA lines, but they are non-conformant it - * seems. TBD whether we keep this fallback: - */ - if (ctx->Line.SmoothFlag) { - for (i = 0; i < nr_prims; i++) - if (reduced_prim[prim[i].mode] == GL_LINES) - return GL_TRUE; - } - /* Stipple -- these fallbacks could be resolved with a little * bit of work? */ -- 1.7.5.1 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
