[Mesa-dev] [RFC] [PATCH 0/4] Add frequency declaration for vertex elements

Marek Olšák maraeo at gmail.com
Mon Aug 16 13:40:32 PDT 2010


On Mon, Aug 16, 2010 at 6:01 PM, Luca Barbieri <luca at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100816/59a87f51/attachment.htm>


More information about the mesa-dev mailing list