----- Original Message ----- > Second attempt, 2 years ago no one replied or cared ... > > We really need to know about these on nvc0 because there are only 8 > fixed hardware locations that can be overwritten by sprite coordinates, > and one location that represents gl_PointCoord and unconditionally > returns sprite coordinates. > > So far this was solved via a hack, which works since the locations the > state tracker picks aren't dynamic (and likely will never be, to facilitate > ARB_separate_shader_objects), but it still isn't nice to do it this way. > > It looks like nv30 was using a hack, too, since it had a check for > Semantic.Index == 9, which is what mesa uses for PointCoord. > > Implementing a safe, non-mesa-dependent way without these SEMANTICs would > be jumping through hoops and doing expensive shader recompilations just > because we like to destroy information at the gallium threshold, and that's > unacceptable. > > I started to (try) fix up the other drivers, but maybe we just want a CAP > for this instead, since the default solution - if this is TEXCOORD then > treat it as GENERIC with semantic index += MAX_TEXCOORDS - doesn't really > look that nicer either. > E.g. if PIPE_CAP_RESTRICTED_SPRITE_COORDS is advertised, the state tracker > should use the TEXCOORD and PCOORD semantics, otherwise it should just use > GENERICs as before.
Personally I have no objection with this FWIW. But please append the new TGSI_SEMANTIC_xxx without renumbering the existing ones. Jose _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
