> 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.
You are right, the routing table CSO needs to contain the fragment and vertex shader handles, and ideally light_twoside should be moved to the vertex->fragment routing table since it is really an attribute of that and not polygon rasterization/setup. You can then just look at your internal data structure and construct a scalar routing table from the vec4 one provided by Gallium. We could also, as a further extension, support scalar routing tables directly in Gallium. Note however that radeon hardware presumably only supports vector ones, so we would need all 3 options with caps. A further intermediate step could be vector routing tables with swizzling. ------------------------------------------------------------------------------ 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
