[Mesa-dev] 7 questions and proposals about changes in the Gallium interface
brianp at vmware.com
Mon Mar 7 07:24:49 PST 2011
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
>> fully implementing them in st/mesa? It's not like any of the radeon
>> 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
>> 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
> 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.
More information about the mesa-dev