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

Jakob Bornecrantz wallbraker at gmail.com
Wed Sep 8 15:57:18 PDT 2010


On Wed, Sep 8, 2010 at 11:47 PM, Ian Romanick <idr at freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Eric Anholt wrote:
>> On Wed, 8 Sep 2010 06:13:16 +0200, Luca Barbieri <luca at luca-barbieri.com> wrote:
>>
>>> It would be great if Intel switched to the i915g and i965g Gallium
>>> drivers, since everyone else is concentrating their attention on
>>> Gallium, since it's much easier and better to write drivers for it.
>>
>> I keep hearing this, and a bunch of people have been trying to build the
>> equivalent gallium hardware drivers to various core drivers for a long
>> time.  So, can we get some details on a success story?  What driver is
>> now more correct/faster than it was before?  By how much?  How much of
>> that was hardware enabling you did on the gallium side only?
>
> And never mind that you can't make a conformant OpenGL driver with
> Gallium due to the impossibility of software fallbacks.

Hmm thinking more about it doing a proper software fallback for the
rasterizer and fragment shader would mostly be trivial.

What you would need to write for each driver is file that grabs all
the cso:s states and plugs that into the helper object. Doing that is
trivial since all state is in cso:s. Grabbing all the needed texture
data from the hw textures would all be handled from the helper, since
which textures to use is already given via the cso:s, but doing it
would be trivial, as we can already run the software rasterizers on
top of regular hardware driver (see src/gallium/winsys/sw/wrapper).

And it might even be worth it since now we actually have a fast
software rasterizer (for things more complex then glxgears and
tunnel).

Cheers Jakob.


More information about the mesa-dev mailing list