On 03/07/2011 03:38 AM, Keith Whitwell wrote:
On Sun, 2011-03-06 at 18:42 +0100, Marek Olšák wrote:
7) Stippling and smoothing
Would anyone be against removing these two from the Gallium interface
and
fully implementing them in st/mesa? It's not like any of the radeon
people
wants to implement them in the hardware drivers, and the Draw module
is not
an option, because we still would like to have hardware-accelerated
vertex
shaders even with stippling and smoothing.
I don't think this is such a good idea. There is hardware out there
that can do this natively& would benefit from continuing to have it
passed through.
What I think we need is an alternative to the draw module which does
what you're looking with geometry shaders rather than software vertex
transformation.
All these emulated rasterization paths really need the window-space
vertex positions and the assembled primitive (ie all three vertices) to
do their stuff, and the only ways to do that are in software after
vertex transformation or with geometry shaders.
It's an open question how much work it is to do this in the GS (eg. do
you have to emulate clipping first?), but it would be interesting to see
someone take it on.
I'm interested in doing this but haven't had much time for it. I want
to prototype doing some of these things as glut demos first. I
started doing this for point sprites one day but didn't finish.
BTW, the polygon stipple draw stage doesn't need to be in the draw
module (it doesn't need vertices in window coords like the other
stages). It can be implemented as a set of utility functions usable
by any driver. I've refactored the draw_pipe_pstipple.c code into a
new u_pstipple.c module but haven't plugged it into any driver for
testing yet. This would let us avoid the draw/vertex fallback when
polygon stipple happens to be enabled.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
