Intel's Gallium3D Driver After Google's Work

[phoronix]

Phoronix: Intel's Gallium3D Driver After Google's Work

As noted last week on Phoronix, Google has Chromium OS engineers making improvements to Intel's Gallium3D driver even though this open-source Linux driver isn't officially supported by Intel Corp. Google's interested in shipping the Intel Gallium3D driver on their Chromium OS netbooks in order to take advantage of the Low-Level Virtual Machine (LLVM) and other Gallium3D features to make up for the netbook's lack of vertex shader hardware. How does this community-maintained Intel 3D driver now compare performance-wise to Intel's official classic Mesa driver? Here is a fresh set of benchmarks from the latest Mesa Git code over the US holiday weekend.

http://www.phoronix.com/vr.php?view=16200

[curaga]

s/Nexuiz/Warsow/ in the last paragraph

[HokTar]

Considering the amount of work which goes into these drivers I'm impressed by i915g. I think it shows the power of G3D.

I think there's little doubt that intel will eventually jump ship, the question is when.

[jntesteves]

If this pace of development holds I can see the Gallium3D driver beating the hell out of the classic driver really soon.
I hope Intel starts laying their plans for the G3D transition already so they can share more infrastructure with all the other drivers and everyone wins. It's clearly the only way forward for Linux video drivers nowadays.

[ChrisXY]

This testing is using the Mesa "master" Git code from 2 July 2011

Is the reason why the code is 5 days old because the benchmark was done 5 days ago?
5 days are not much, yes, but there are hundreds of added and deleted lines of code in mesa daily...

Also, can we read anywhere with what options this mesa was compiled? I have created the mesa-full-i915g package in the Archlinux AUR just for fun and the configure options really get added and changed fast so I wonder if all important stuff was included. Llvm was mentioned, so I guess it was activated in the build

The configure options I have found out to use are

   --with-dri-drivers=i915 \
   --with-gallium-drivers=i915 \
   --with-dri-driverdir=/usr/lib/xorg/modules/dri \
   --enable-glx-tls \
   --enable-xcb \
   --enable-egl \
   --enable-gallium-egl \
   --enable-gallium-llvm \
   --enable-glu \
   --enable-gles1 \
   --enable-gles2 \
   --enable-glut \
   --enable-glw \
   --enable-openvg \
   --enable-xa \
   --enable-xorg \
   --enable-osmesa \
   --enable-texture-float

It would be interesting to see if some of those options make a performance difference.

It would also be interesting to see if it is the same on 64 bit.

And lastly it would be interesting if the i915 driver would profit from --enable-sna in xf86-video-intel.

There are also these options

--enable-gbm \
--enable-gallium-gbm \
--enable-shared-glapi \

Would also be interesting to see if the graphics buffer manager makes a difference... But it needs the --enable-shared-glapi and this is marked experimental so I didn't enable it...

[89c51]

If this pace of development holds I can see the Gallium3D driver beating the hell out of the classic driver really soon.
I hope Intel starts laying their plans for the G3D transition already so they can share more infrastructure with all the other drivers and everyone wins. It's clearly the only way forward for Linux video drivers nowadays.

since they didn't do it when they had the chance (they rewrote parts of it recently -don't know if they are finished with it) i doubt they will do it anytime soon

except if google steps in but i don't think they will put more resources into it

[crazycheese]

Intel should be punched in the ... of steel for ignoring Gallium for so long. When everyone starts writing its own libraries for the same task instead of polishing one but together, all blame how linux is inefficient.
But when microsoft punch them together, they suddenly keep quiet and do it right and then every single fps advantage or bug-less behavior is assigned as microsoft's achievement... Seriously, someone (from google?) needs to guide (hit?) intel in the right direction.

[marcheu]

That benchmark is really outdated. If you try with a recent version (not from 5 days ago - I think 500 lines of i915g driver code have changed since that article was written) they will be completely different.

Why publish something 5 days old? It doesn't make sense.

[89c51]

That benchmark is really outdated. If you try with a recent version (not from 5 days ago - I think 500 lines of i915g driver code have changed since that article was written) they will be completely different.

Why publish something 5 days old? It doesn't make sense.

probably because he was away from his home or something

anyway may i ask what are the targets (in terms of features) for this driver you are working on???

[marcheu]

probably because he was away from his home or something

anyway may i ask what are the targets (in terms of features) for this driver you are working on???

The features are the same as the classic driver except that I need good performance (for 3D, but also for texture streaming and the like). If you look at the recent i915g changes they have been performance-focused, and that's where I'm going to take this driver.