On Mon, Jan 18, 2010 at 3:22 PM, Luca Barbieri <l...@luca-barbieri.com>wrote:
> > I think this is not necessary and fixing the rasterizer setup in the
> driver
> > would by better than fixing the state tracker.
> >
> > In r300g, we dynamically allocate rasterizer units based on vertex shader
> > outputs. If the vertex shader uses slots 1, 5, 20, 1000000, the driver
> maps
> > them to units 1,2,3,4.
>
> But what if the fragment shader has inputs 1, 2, 5, 20, 1000000?
> If you remap the fragment shader to 1, 2, 3, 4, 5, then they will mismatch.
>
> You would need to either:
> 1. Generate shaders in the driver for the fragment/vertex combination
> instead of each one separately
> 2. Require that vertex shader outputs match fragment shader inputs exactly
>
> (1) makes the driver much more complex and slow. I think we should try
> to make it possible to avoid this, unless the hardware absolutely
> requires it.
> (2) will probably break the existing fixed pipeline and ARB_fp/vp
> support, and also make the driver more complex than necessary.
>
> Does r300g compile both fragment and vertex shader together?
>
> Also note that all Gallium-capable hardware should support 8 varying
> slots, so anything that uses only "texture coordinates" should not
> need any remapping.
>
I was talking about the rasterizer (interpolator) units, which, on r300, are
quite flexible and can read an arbitrary vertex shader output and write it
to an arbitrary fragment shader input (= register address). Given this
flexibility, fragment and vertex shaders are compiled separately in r300g
and semantic indices don't matter, just the total number of varyings.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
