On 13.03.2013 21:24, Jose Fonseca wrote: > ----- 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. >
Sure, ok, I just though it would fit better up there, having PSIZE and PCOORD adjacent. Binary compatibility issues ? So far so good, now I just have to fear the other driver devs' wrath (or silence) for changing something that already works for them ... > Jose > _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
