[Mesa-dev] 7 questions and proposals about changes in the Gallium interface

[Brian Paul]

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