Intel Releases 2.3 RC Driver w/ XvMC

[phoronix]

Phoronix: Intel Releases 2.3 RC Driver w/ XvMC

In Linux graphics news unrelated to the recent ATI/AMD excitements, Intel has just released the xf86-video-intel 2.2.99.901 driver. This driver is meant to serve as the first release candidate for what will become xf86-video-intel 2.3.0...

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

[Pickup]

Something I don't get: are u free to contribute to Intel driver making or is it an open but strictly fore inteleers project?

[Michael]

Originally Posted by Pickup

Something I don't get: are u free to contribute to Intel driver making or is it an open but strictly fore inteleers project?

If you write a valid patch or anything, there should be no trouble getting it pushed into their master branch. They don't check you for an Intel employee ID card before looking at your work

[Svartalf]

Originally Posted by Pickup

Something I don't get: are u free to contribute to Intel driver making or is it an open but strictly fore inteleers project?

Heh... As Michael has indicated, it's Open- but like at least a few FOSS projects one can care to mention (OpenOffice, for example), a major industry player is bankrolling several of the developers on the project. Intel sees the value of having GOOD drivers on Linux and they're providing them- largely the way they're supposed to. AMD's in the process of doing the very same thing. One would hope NVidia would follow suit, but it may be a little bit before that happens- specifically, it may take a high-performer from AMD or Intel that has it's drivers in a FOSS manner on Linux to spur them to change their position on technical specs or driver code itself.

[Extreme Coder]

Originally Posted by Svartalf

Heh... As Michael has indicated, it's Open- but like at least a few FOSS projects one can care to mention (OpenOffice, for example), a major industry player is bankrolling several of the developers on the project. Intel sees the value of having GOOD drivers on Linux and they're providing them- largely the way they're supposed to. AMD's in the process of doing the very same thing. One would hope NVidia would follow suit, but it may be a little bit before that happens- specifically, it may take a high-performer from AMD or Intel that has it's drivers in a FOSS manner on Linux to spur them to change their position on technical specs or driver code itself.

Intel may have made good drivers for most of their cards, but their drivers for the 965-3000 Series are not that good at all.. After all, they just recently released the documents for them, and it will take some time before the drivers are as good as their older ones.

[Svartalf]

Originally Posted by Extreme Coder

Intel may have made good drivers for most of their cards, but their drivers for the 965-3000 Series are not that good at all.. After all, they just recently released the documents for them, and it will take some time before the drivers are as good as their older ones.

Considering that they were written using those selfsame documents- BY Intel and Tungsten Graphics...

From the Intel OpenSource Drivers site on the eve of the new drivers we're now using:

"As with any free software project, this release represents only the beginning of an ongoing commitment by Intel to work with the X.org and Mesa communities to continuously improve and enhance the drivers. While these drivers represent significant work at both Tungsten Graphics and Intel—as our first release of this code—they're still in need of significant testing, tuning, and bug fixing before they will be ready for production use. We're releasing them now to demonstrate our ongoing commitment to providing free software drivers for Intel hardware."

It's not that we didn't have the help from them in the form of the documentation- there's a disconnect between what we're doing in Mesa/DRI and what we need to be doing to get peak performance. We do not have an optimizing shader compiler, which, actually, is critical to peak speed on the GMA X3000/X3100/X3500 parts. The same goes for a goodly portion of that gap between what we'd accomplished from the R300 RE efforts and the performance levels of the fglrx, such as it is. In the case of fglrx drivers being "slow" compared to the Windows ones, they've likely got a problem reconciling interrupt handling differences between Windows and Linux (i.e. You can't just take that which works well with Windows and just shove it into Linux in many cases- the schedulers are different and cute userspace stunts that work well or adequate in Windows just simply WON'T work in Linux...) and they're introducing a pipeline stall in there somewhere. Now, I could be wrong, it may be something else- but having seen that one play out several times over the years (and having to help the client sort it out...) it's a likely culprit.

[Extreme Coder]

If it was only a case of not-so-high performance, I'd be OK with that, but as I made another thread with a list of games that don't work with it(and nobody replied to ), I was hoping they would fix that.

[Svartalf]

Originally Posted by Extreme Coder

If it was only a case of not-so-high performance, I'd be OK with that, but as I made another thread with a list of games that don't work with it(and nobody replied to ), I was hoping they would fix that.

Which games would they be?

[Huenengrab]

I tried ioquake3 on my Laptop and it's running fine on a X3100. Not a 100%-esque 60fps on 1280x800, but Quake is playable. I also tried UT2004 but even with the worst detail-configuration I can't reach more than stable 20fps throughout the game. Open Arena runs mostly fine, Nexuiz is unplayable and Alien Arena is on par with Open Arena.

It's a great chipset for Compiz. It seems more fluid than Compiz with Nvidia (and AIGLX on).

[Svartalf]

Sounds like the shader based titles might be the cause of the issue- which wouldn't be surprising.