> 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. ------------------------------------------------------------------------------ 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
