On 01.02.2010 15:32, Luca Barbieri wrote: > An overview of the possible options. > Let's call vertex shader outputs "v" and fragment shader inputs "f" > Let v -> f mean that v connects to f. > NUM_INTERPOLATORS is the number of available interpolators. It is > usually between 8 and 32. > > 1. Current Gallium > v -> f if and only if v == f > Any values of v and f are legal > > 2. My proposal, basic version > v -> f if and only if v == f > v >= NUM_INTERPOLATORS and f >= NUM_INTERPOLATORS are illegal > > 3. My proposal plus with routing tables (Corbin Simpson's idea) > v -> f if and only if (v, f) is an entry in the routing table > v >= NUM_INTERPOLATORS and f >= NUM_INTERPOLATORS are illegal > If no routing table is set, (2) is used instead > The routing table is set via a new ->set_routing_table() entry point, > taking the processor linkage affected, and an array of pairs of > registers to link. > This may be made a CSO (it is constant for each pair of state tracker > shaders). > >
I can't really use a routing table state to produce a cso, because the hw routing table I generate depends on rasterizer state, e.g. I must not put in back face colour (we have a 2 to 1 mapping here) if twoside is disabled. Also, I'm routing based on the scalar *components* the FP reads, not whole TGSI pseudo vec4 registers (NUM_INTERPOLATORS will thus be inaccurate) - set_routing_table will have to pass me the respective programs too. Well, I can still use the cso and insert it into the rest of the routing table that still need to be assembled on the fly, I did that before the 1:1 mapping between FP and VP regs was removed. On a sidenote, if a VP output is not written, I map it to 0 or 1 (4th component); FOG has all 4 components written in VP thus yzw don't become 0 or 1 in FP as is expected; I can adjust the write mask myself though ... Christoph > The problem with (1) is that if the hardware has no routing support, > there is no way to implement it except by recompiling either the > vertex or fragment shader when the other changes. > > Furthermore, no known user of Gallium actually needs (1) except the > current GLSL linker, but only due to the particular implementation and > not due to the OpenGL/GLSL API itself. > > Only (2) is actually needed by the APIs, and it is also supported > trivially by all hardware. > > > Additionally there is no way to implement "bind by name" (i.e. having > GLSL varyings with the same name be linked) with either (1) or (2) > without recompiling one shader in response to changing the other. > > With (3) instead, the state tracker can look at the symbol tables of > both programs, build a routing table, and set it independently of the > shaders. Functionality provided by (1) can also be emulated in this > way. > > > Thus, I propose replacing (1) with (2) and later expand to (3) if we > desire to do so. > > I think that in particular, the "bind by name" argument is decisive, > since binding by name is what GLSL and high level languages really > want, and the added flexibility of (1) is useless for that, while > coming at significant driver complexity and performance cost. > > What do you think? > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
