<div class="gmail_quote">On Mon, Aug 16, 2010 at 6:01 PM, Luca Barbieri <<a href="mailto:luca@luca-barbieri.com">luca@luca-barbieri.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">> 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... </div>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. </blockquote></div> 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