On Mon, Aug 16, 2010 at 6: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. > In r300g, we currently set the index clamping range to [0,1] if there is a vertex buffer with stride == 0, which is wrong but it silences the in-kernel CS checker. I haven't looked into this yet and have no info about it for r300. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
