Intel Glamor Acceleration Compared To SNA, UXA

[hwertz]

Took to long to edit my last post... anyway, with the way things are going perhaps Glamor will be the way to go on GMA500.

[ickle]

I'd love if the SNA work was applicable to the GMA500. I have video acceleration (VA-API) and all that working and it's pretty nice, certain 2D operations are quite a bit slower than it seems like they should be so if SNA has different caching and memory management strategies I expect it could radically affect performance on it too. I don't know where the "binary blob"/"open source" line is on this driver though, if the blob insists on managing memory itself than nothing can be done with it.

I too would love to get my hands on the specs for the GMA500... At the moment, the only open source components for it are the KMS portions which is loosely based on the already open i915 display engine and we do not have enough information to write a Graphics Execution Manager for doing mixed core and Render acceleration. (Render acceleration would require access to the 3D pipeline.) The existing binary driver is a mockery and delivers performance that is more than a order of magnitude slower than the Atom CPU to which it is attached could manage. That driver is so inexcusably slow that even glamor is faster there, but it still falls far below my expectations. However, I still maintain that if a team is not able to accelerate the simple X drawing protocols then I have no confidence in their ability to accelerate the entirety of OpenGL! Even before considering that 2D rendering stresses the buffer allocation and command execution paths far greater than the typical game and as a result the drivers need a large amount of optimisation for this new workload. A typical example is the simple blit performance, where glamor on mesa is 50x slower than the dedicated 2D driver due to the CPU overhead of GL command processing. An only slightly more complex example is that at 7Mglyph/s SNA is GPU bound (cpu utilisation is around 60%), whereas at only 1.8Mglyphs/s glamor is CPU bound.

Back to the original discussion, SNA actually has broadly similar ideas of pixmap migration to EXA upon which the proprietary Poulsbo driver is based; so in reality the only limiting factor for that driver is its quality of implementation. That it is not open source speaks volumes for the level of confidence and commitment Intel have made for that GPU and driver.