On Mon, Jan 18, 2010 at 10:52 AM, Marek Olšák <mar...@gmail.com> wrote: > 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.
I think DX9 required this flexibility when mapping VS to PS, so it's likely most DX9 hw supports this. Alex ------------------------------------------------------------------------------ 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
