[Mesa-dev] Mesa (shader-work): glsl: introduce ir_binop_all_equal and ir_binop_any_equal, allow vector cmps

[Marek Olšák]

On Thu, Sep 9, 2010 at 2:35 AM, Eric Anholt <eric at anholt.net> wrote:

> However, the fact that when I ask about performance nobody says "OMG the
> texture upload/download/copy/etc. support in gallium is so great and is
> way faster than anybody managed in classic because it catches all the
> corner cases" makes me really scared about it.
>

OK so there you have it: The texture upload/download/copy is way faster in
r300g than anyone managed in r300c. For example, the ETQW main menu uses
some texture streaming and I get 1 fps in r300c and about 30 fps in r300g.
That's not something one can ignore.

The transfers in r300g were really simple to implement, it's just transfer,
map, unmap, transfer (transfer=blit). The code is clean and isolated (about
250 LoC). This is just the driver code. There is also some additional
transfer code in st/mesa, but I didn't have to care about that.

The overall speed of r300g is either at the same level as r300c or higher,
based on what application you look at. Various users have reported that,
unlike r300c, all compiz effects just work, kwin works, a lot more games
work, and the driver is faster in some apps. We used to have some
performance issues in Tremulous not so long ago, but that's been fixed since
then. Of course, one can find synthetic tests where one driver is always
faster than another. I am talking about real world applications here. For
example, I no longer have to kill Strogg in ETQW with the lowest details on
my R580 for it to be smooth.

r300g is quite optimized (I say "quite", because you're never sure), so the
overhead of other mesa components is larger than other Gallium drivers might
be able to see. In Tremulous, the overhead of r300g+libdrm is under 50% of
the whole time spent in Mesa, and that's without using Draw, so we should
start caring about the speed of st/mesa and mesa/main. The only obvious way
to get some speed there seems to be merging Mesa core with st/mesa, dropping
the classic driver inteface, and simplifying the whole thing. I guess this
won't happen until everybody moves to Gallium.

It's a sure thing Gallium is the future, and it doesn't seem to be a good
idea to implement e.g. LLVM-powered vertex shaders for classic, considering
the same thing has already been implemented and now stable in Gallium.

The only disadvantage of Gallium seems to be TGSI. It's not better than Mesa
IR, because all shaders must pass through Mesa IR anyway. I suppose using
GLSL IR or something similar would help some drivers produce more optimized
shaders (I am getting at temporary arrays here, which r300 hardware
partially supports).

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100909/656bf3a3/attachment.html>