New Intel GLAMOR Code Is Taking Shape & Running Fast

[phoronix]

Phoronix: New Intel GLAMOR Code Is Taking Shape & Running Fast

Aside from upstream work to the GLAMOR acceleration code itself that's now part of the X.Org Server, Keith Packard has been working on the GLAMOR hook-up for the xf86-video-intel DDX driver...

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

[ChrisXY]

Hm. Compiled with

 --enable-dri --disable-xvmc --enable-rendernode --enable-tear-free --enable-glamor --with-default-accel=glamor

Result:

[ 11241.031] (II) AIGLX: Screen 0 is not DRI2 capable
[ 11241.031] (EE) AIGLX: reverting to software rendering
[ 11241.045] (II) AIGLX: Loaded and initialized swrast
[ 11241.045] (II) GLX: Initialized DRISWRAST GL provider for screen 0

[sdack]

An understatement

He writes: "Of course, this is all just x11perf, which doesn’t represent real applications at all well. However, there are applications which end up doing more GetImage than would seem reasonable, and it’s nice to have this kind of speed up."

This is an understatement. He seems to have forgotten the importance of GetImage/GetShmImage for screen grabbing. Live streaming from the desktop will welcome the performance increase. The apps grab the screen as often as 25-60 times per second and even when the video stream encoding makes the lion part of the CPU usage will an improvement of 30x-40x for GetImage/GetShmImage certainly be felt.

For gaming does it mean one can send a live stream onto the Internet while playing with increased frame rates at the same time. Anyone who has ever tried live streaming knows how much CPU it requires.

[dh04000]

Would someone mind explaining in the simpliest terms why using Glamor to do 2D on the gpu is better/diffferent than our current methods? Thank you.

[przemoli]

Would someone mind explaining in the simpliest terms why using Glamor to do 2D on the gpu is better/diffferent than our current methods? Thank you.

1) Glamour translate 2D operations into 3D and use OpenGL to execute them.
2) 2D methods require either emulation on CPU, or dedicated 2D part on GPU.
3) Current trend it to skip that 2D part completely.

So for AMD GPUs from SI up, Glamour is currently only option.

For Intel there are various options. UXA which is old Intel method (reliable, and faster then "default" X.org EXA). There is SNA which still use 2D part, but its quite complex, bigger then 3D Mesa code (or so I heard), and it live in never ending beta. Intel DDX (driver for X.org) 3.0 will have it enabled.

So SNA is best if You can enable it. UXA is what You get by default (and its OK).

Glamour is currently pushed for 2 reasons though:
1) AMD needs it (but they mainly focus on 3D work, and other enablements)
2) Intel needs it for Wayland, which will also benefit from 2D acceleration but adopting UXA would not be good (SNA is plain better), while SNA is just too big (and maybe - that is my speculation - some future gen Intel hw wont have that 2D part at all. So Intel is preparing right now for it)

So:
EXA - old, "default" for X.org, not supported on Intel as two following are always better
UXA - old, battle tested "default" for Intel X.org driver
SNA - getting old, almost battle tested must be enabled by You

All above (would) use 2D engine on the iGPU to accelerate work.

Glamour - getting old (only just recently got wind in the wings), "default" for XWayland (and maybe XMir if Canonical follow the suite)
use 3D engine, as its translate 2D operations into OpenGL.

(Also UXA, SNA, EXA need to be rewritten each time new, hw comes out, while Glamour just need OpenGL support, so You get 2 things for smaller effort and faster)

[Guest]

Would someone mind explaining in the simpliest terms why using Glamor to do 2D on the gpu is better/diffferent than our current methods? Thank you.

Most modern GPUs don't have 2D engine. 2D acceleration if any is provided by using 3D engine. For each GPU card generation/series, you will need to write code to implement 2D acceration using 3D engine. This involves necessary duplicate work. Instead, 2D acceleration can be implemented on top of OpenGL, which can be done once (for all GPUs - common implementation). Saves unnecessary work. Any bugs need to be fixed only once and are fixed for all GPUs. Performance improvements benefit everyone (well, depends on 3D driver as well).

Apparently also important for nested X server and X on Wayland.

[Rexilion]

Looks nice, but for (SHM)GetImage XY 10x10 Square has a huge regression. That cannot be good. Looks promising though.

[dh04000]

Thank you przemoli & sandy8925 for the explainations. I think I understand now

[agd5f]

1) Glamour translate 2D operations into 3D and use OpenGL to execute them.
2) 2D methods require either emulation on CPU, or dedicated 2D part on GPU.
3) Current trend it to skip that 2D part completely.

So:
EXA - old, "default" for X.org, not supported on Intel as two following are always better
UXA - old, battle tested "default" for Intel X.org driver
SNA - getting old, almost battle tested must be enabled by You

All above (would) use 2D engine on the iGPU to accelerate work.

EXA, UXA, and SNA all use the 3D engine (the same hardware OpenGL uses). In fact very few GPUs even have an 2D engine anymore. The main difference between glamor and everything else is that glamor accelerates X core and render APIs using OpenGL so it's vendor independant and doesn't require any asic specific driver code. All of the other methods translate X core and render APIs into asic specific rendering commands which means you end up needing two drivers; one to accelerate X core and render APIs and one to translate OpenGL to asic specific commands.

[sdack]

Thank you przemoli & sandy8925 for the explainations. I think I understand now

Also, try to imagine how you draw a filled circle onto the screen. Basically what you to do is to test if a pixel falls within the circle and then draw it.

With Pythagoras' a^2 + b^2 = c^2 can one create such a test: sqrt(x^2 + y^2) <= r, and to avoid having to use the sqrt()-function can one simplify the test by leaving it out and only test with:

x*x + y*y <= r*r (x and y being the coordinates of a pixel and r the desired radius)

The multiplication, addition and comparison operation are simple operations for today's GPUs and one can implement this test as a shader program and thereby draw a filled circle pretty fast. Previous hardware implemented it in silicon to provide the hardware acceleration for such 2D operations, but now with GPUs having thousands of shader units (i.e. GeForce GTX Titan has got 2880 units) has this become more than obsolete.

Implementing 2D acceleration with OpenGL may seem like overhead, but it provides a direct access to the shaders and it is what one wants.