New Intel Driver Takes SNA Accel Mainstream
Phoronix: New Intel Driver Takes SNA Accel Mainstream
Chris Wilson released the xf86-video-intel 2.20 driver on Sunday, which brings SNA acceleration to the masses...
The Intel SNA is all fine and good with a minor gripe for me. AFAIK, the fglrx driver does not support SNA for the muxless hybrid radeon cards in many of the notebooks.
On that note, there has surprisingly been very little information/coverage in Phoronix about the fairly good support from the fglrx driver for the muxless hybrid graphics. All or most of the articles seem to suggest that the fglrx support for these systems is non-existent, and that there is some support for Nvidia cards in the form of Bumblebee and related projects. This is one area where I feel fglrx has trumped the Nvidia drivers. I for one have been very pleased with this for the Radeon 6630M hybrid graphics on my 2011 Sony Vaio S notebook.
I also hope that the fglrx also supports Intel SNA in near future. And/or the open source graphics drivers catch up.
PS: Recently I also verified that the fglrx driver works very well for MacBook Pro (Late 2011 model, 8.2) with Radeon hybrid graphics, without workarounds of any kind.
Yeah, fglrx has had support for this for quite a while, but you never really hear anything about it.
Originally Posted by hdas
This is seriously good news if Graphics is important to you. It might even make me consider Intel over AMD integrated GPUS.
I'm pretty much don't care about pixels count performance of my intel sandy bridge powered ultrabook. what is interesting, imho, is that if we can do more with the same processor, will that processor do the same as before but more efficiency (with less energy consumption) ?
I may take every second of battery life that work can help me to get from my laptop power cell.
vsync in kwin compositing doesn't work when i enable sna on gma945
The method they are using is not specified in the protocol to provide vsync and that "optimisation" provides worse power consumption than if they just pageflipped.
Originally Posted by kokoko3k
Could you please explain who are "they", what is the protocol you are referring to? I admit i haven't understood your post, sorry...
Originally Posted by ickle
Apologies for ranting.
The issue is that the CopySubBuffer was introduced as an optimisation to DRI2 specification for the benefit of compositor to avoid performing a full swapbuffers and only copy the regions that changed. This was introduced before pageflipping was completed upon the mistaken assumption that this was beneficial to hardware. In fact, it rather badly interferes with the power management of recent chips, to the extent that vsync enabled rendering to the scanout was defeatured temporarily. (It is stilll strongly not recommended as many power saving features of the chip require that rendering only be performed to a back buffer that is page flipped onto the scanout, and since the other OS only pageflips that is the only path that works and the hw is designed for...)
Originally Posted by kokoko3k
Internally to the XServer implmentation, CopySubBuffer calls exactly the same function in exactly the same manner as an asynchronous swap, therefore the driver has no idea if this was a client originating CopySubBuffer or a request to render as fast as possible - we have no idea whether or not vsync is desired or expressly forbidden.
https://bugs.freedesktop.org/show_bug.cgi?id=39538 and I've been trying to get a patch into the xserver to fix this confusion for a couple of years now.
Thanks, it is more clear now.