Here are some preliminary performance data I got by using cairo performance
trace and x11perf on three different machines. We can see on SNB GT1 glamor
can get identical performance with UXA, and on Ironlake machine, glamor get
identical performance with SNA.
But on SNB GT2 machine, glamor's performance is much slower than UXA and
SNA. Need further effort to understand and further tune glamor on SNB platform.
rgb10text(max/min) aa10text(max/min)
firefox-planet(xcb) - cairo-trace
(higher is better) (higher is better)
(lower is better)
CPU : i5-2500K @ 3.30GHz
GPU: ( SNB GT2)
glamor 1.16M1.37M10s
sna 2.19M/1.95M2.88M/2.41M4.2s
uxa 2.49M 3.11M5.1s
cairo-image N/A N/A 9.5s
CPU: i7-2600 @3.4GHz
GPU: (SNB GT1)
glamor 1.21M 1.42M 10.1s
sna 2.12M/1.74M2.58M/2.26M 10.3s
uxa 1.2M 1.39M11.3s
cairo-image N/AN/A 7.5s
CPU: i5-480 @2.2GHz
GPU: (Ironlake)
glamor 772K 913K18.7s
sna 780K/1.02M1.19M/1.34M 18.7s
uxa 693K 935K 32.9s
cairo-image N/AN/A 15.3s
On Wed, Aug 17, 2011 at 8:18 PM, zhigang gong zhigang.g...@gmail.com wrote:
Hi folks,
Glamor project was initiated by Eric at last year which is to implement a new
rendering acceleration engine by using OpenGL to handle all the 2D operations.
It is somehow very similar with UXA. The major difference is that we use
texture
to hold pixmap if possible, and then use shaders to fill/composite
those pixmaps,
but UXA is calling libdrm to do buffer allocation and prepare/submit batch
buffer to GPU to start the rendering.
Now I'm working on this project, and add one ddx driver based on MESA/EGL
for the Xorg server. We have two experimental xservers currently, one is Xorg
with glamor ddx driver and the other is Xephyr. KRH suggested me to add GLES2
support, now it's almost done. Glamor xserver could run with GLES2 with major
color format support. Now it’s ready to move to wayland.
After some performance tuning, we now can avoid most of the fallback path
for common desktop applications. On some old platforms we can get identical
or even better performance with UXA/SNA, for example on a i5-480M machine
with GMA graphic chip. But on the latest SNB platform, there is still a big
performance gap. On latest SNB machine,glamor can only get about 1/2 –
1/3 performance compare to UXA/SNA. The glyph rendering is the bottle-neck
will further tune this part’s performance.
I want to get some comments here from who may be interested in glamor
before I move forward. From my point of view, if we can continue to improve
glamor's performance, and to achieve identical or even better :) performance
with uxa/sna then glamor could be a good candidate of new device’s ddx driver
and can save many effort of writing new 2D drivers for each new hardware.
Key point here is the performance. I discussed with Eric and we just saw one
big limitation is the texture size limitation. Is there any other
serious resctriction
here?
Here is a draft TODO list for glamor. Ask for comments here too.
Actually, Eric already told me some things I need to do. adjust the
priority according
to his suggestion. Thanks Eric.
0. Ongoing effort:
Enable glx/dri2 support. Need to handle the communication between dri2
buffer and textures. One possible solution is to create a EGLImage from
the dri2 buffer object's handle. And then bind the image to a texture.
1. Testing
Verify with X test suite and rendercheck and make sure no regression.
2. Submit patchset to Xorg.
Not sure how to do this, who should I contact first? The patchset has
three
parts logically, one is a glamor directory holds the hardware independent
rendering code. The second part is a patch to Xephyr which is to enable
the
xephyr to use glamor. The third part is a simple ddx driver for xorg.
3. Further performance tuning.
Optimize glyphs rendering.
Current glyphs rendering code is based on a very old uxa
implementation,
we should have some chance to optimize this part.
Large pixmap support.
Mesa only support rendering 4096x4096 texture and some OpenGL/ES2
even only support 2048x2048. This will enforce us fallback to use CPU
memory which is very slow. I'm planning to use multiple texture to
represent one single large pixmap.
Fully optimize the gradient filling by using shader.
Support all compositing OPs.
Move 1bpp to texture (currently fallback to cpu
