On Mon, Aug 16, 2010 at 12:01 PM, Luca Barbieri <l...@luca-barbieri.com> wrote: >> It seems like there is an alternate fix possible -- modify the mesa >> fixed-function vertex program generator to put these constant values in >> the constant buffer, rather than passing them as vertex data. That >> would remove the need for us to have this unique capability at the >> gallium level that none of the other graphics abstractions seem to >> consider necessary. >> >> I think we're putting more effort into accommodating the behaviour of >> that code than really makes sense... > > I'm not totally sure about this. > Right now drivers are supposed to support stride == 0, so this already > works, but is not optimal for hardware where this causes repeated > memory access. > > The change I'm proposing makes it easier to implement this optimally > on hardware that has some "set constant vertex attribute" command > (e.g. all nVidia cards), since the path taken by each element becomes > known at CSO creation time. > > A shader/constant-based solution would be necessary for optimal > performance on hardware that does repeated fetches on stride == 0 and > has no such command, but might be detrimental on hardware that either > has a "set constant" command, or internally optimizes for stride == 0. > > Note that it is possible to have both solutions: if a cap bit is set, > then constant elements would be used, and otherwise the state tracker > will modify the shader. > > It would be interesting to know what would be optimal for r300 and r600.
IIRC, the vertex fetch constants for r6xx+ accept 0 stride. Alex _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
