On 01.02.2010 17:31, Keith Whitwell wrote: > Christoph, Luca, > > Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware > we end up implementing it by passing both front and back colors to the > fragment shader and selecting between them using the FACE variable. If we > removed the implicit fixed-function support for two-side lighting in the > rasterizer, it would solve the issue of how this is represented in any > routing table. > > How does that sit with your drivers? > > Keith > > > It would work, if the COLOR semantic is completely ignored, i.e. I would appreciate the insertion of clamping instructions on the st side (I suspect earlier cards will not have 4 front color registers so clamping will go away for their back colors too ...).
I can only select 2 x 8 consecutive scalar values in the routing table to be clamped, and only 1 x 8 will get through to the fragment shader. I'll not be happy to insert clamping manually, but I can do if it turns out to be the best solution to not have the st do it. It's a bit of a waste not to use that hw cap though ... otoh not many apps will use two sided lighting nowadays I suppose. > ________________________________________ > From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca > Barbieri [l...@luca-barbieri.com] > Sent: Monday, February 01, 2010 7:29 AM > To: Christoph Bumiller > Cc: Keith Whitwell; mesa3d-dev@lists.sourceforge.net > Subject: Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots > > >> 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
