I propose that the following language be added to the spec: """ Gallium has no explicit mechanism for linking shaders. Shaders are implicitly linked in a pipeline at render time. Thus, linking must not fail and the pipe driver is permitted to change shader semantics to preserve linking.
If a shader uses non-consecutive semantics, the pipe driver may remap them to be consecutive, within the bounds of other currently bound state. For example, if a shader samples from samplers 3 and 5, but the only samplers bound are 0 and 1, the driver may adjust the shader to sample from samplers 0 and 1 instead. If the bound shader pipeline does not have consistent outputs and inputs, the driver is permitted to remap them to be consistent through a driver-specific mechanism. For example, if a vertex shader writes generic 1, a fragment shader references generic 0, and there is no geometry shader bound, the pipe driver may change the vertex shader to write generic 0, or it may use a driver-specific internal routing table to route generic 1 to generic 0. If the total count of each semantic attribute written by the vertex shader does not match the counts read by the fragment shader, the driver may discard extraneous attributes and the values of missing attributes are undefined. If a geometry shader is present, this adjustment may happen on the vertex to geometry linking and geometry to fragment linking. """ I think this about covers it. This language seems *very* reasonable to me, while not totally ignoring the problems faced by nv50. ~ C. On Mon, Feb 1, 2010 at 7:29 AM, Luca Barbieri <l...@luca-barbieri.com> wrote: >> 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 > -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson <mostawesomed...@gmail.com> ------------------------------------------------------------------------------ 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
