If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Intel Ivy Bridge Acceleration Of UXA vs. SNA

Phoronix: Intel Ivy Bridge Acceleration Of UXA vs. SNA

It's been a few months since last delivering any Intel SNA acceleration architecture benchmarks but with all of the many recent xf86-video-intel 2.20.x driver releases, here's some new benchmarks comparing the UXA and SNA acceleration back-ends for Intel's Ivy Bridge hardware.

You could also compile xf86-video-intel with --with-default-accel=sna so you won't have to do anything.

To change graphics options, a person should not have to fart around with text based entries, period. Old sax2 in suse used to provide a simple manageable gui that would create the entries in xorg.conf, all you had to do is fire up the gui, select the option you wanted and restart x. Bang, done.

driconf, obviously. Though, I don't know if it was patched to support SNA Accelmethod.

A good configuration system should detect the new options and offer the available and applicable Boolean options. SaX2 did this and didn't require patching every time a new option was put into a driver.

A good configuration system should detect the new options and offer the available and applicable Boolean options. SaX2 did this and didn't require patching every time a new option was put into a driver.

This is an extension, the primary cfg is set in text files with is the right way. "Detect" thing will fail in several cases, although its a good one. It still needs maintenance.
Everything you wrote is non-exclusively correct, lets find a guy who implements it. :P

This is an extension, the primary cfg is set in text files with is the right way. "Detect" thing will fail in several cases, although its a good one. It still needs maintenance.

Well I've been "maintaining" old SaX2 for my own usage and it still works extremely well for detecting the driver options without having to do anything to the detection code. The point is that in a modern operating system, a person should not have to be forced to hand editing files to enable features on a primary subsystem. I'm not saying to eliminate the option of hand editing but a gui should accommodate enabling of the features in a end user friendly way. It's just minor things like having to hand edit the config files that keep people away from linux.