GitLab

As glVertexPointer is not supported by GLES2, I totally
replaced it by VertexAttribArray. This commit remove those
old code.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>

The original code use different name and the name is vague.
Now change it to no_alpha.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>

Glamor doesn't need to use GLEW. We can parse the extension by
ourself. This patch also fix the fbo size checking from a hard
coded style to a dynamic checking style.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>

And add status checking for it.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>

Now, to build a gles2 version of glamor server, we could
use ./autogen.sh --enable-glamor-ddx --enable-glamor-gles2
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>

As GLES2 doesn't support glVertexPointer.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

ES2.0 doesn't support QUADS and also doesn't support
some EXT APIs. Fix some of them in this commit.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

First commit to enable gles2 support. --enable-glamor-ddx
--enable-glamor-gles2 will set thwo MACROs GLAMOR_DDX and
GLAMOR_GLES2.

Currently, the gles2 support is still incomplete.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

When we need to solid fill an entire pixmap with a specific color,
we do not need to draw it immediately. We can defer it to the
following occasions:

1. The pixmap will be used as source, then we can just use a shader
   to instead of one copyarea.
2. The pixmap will be used as target, then we can do the filling
   just before drawing new pixel onto it. The filling and drawing
   will have the same target texture, we can save one time of
   fbo context switching.

Actually, for the 2nd case, we have opportunity to further optimize
it. We can just fill the untouched region.

By applying this patch, the cairo-trace for the firefox-planet-gnome's
rendering time decrease to 14seconds from 16 seconds.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

Some special case we want to get a cpu memory pixmap. For example
to gather a large cpu memory pixmap's block to a small pixmap.

Add pixmap's priviate data's deallocation when destroy a pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

Concentrate the verties and texture coords processing code to a new
file glamor_utils.h. Change most of the code to macro. Will have some
performance benefit on slow machine. And reduce most of the duplicate
code when calculate the normalized coords.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

Major refactoring.
1. Rewrite the pixmap texture uploading and downloading functions.
   Add some new functions for both the prepare/finish access and
   the new performance feature dynamic texture uploading, which
   could download and upload the current image to/from a private
   texture/fbo. In the uploading or downloading phase, we need to
   handle two things:
   The first is the yInverted option, If it set, then we don't need
   to flip y. If not set, if it is from a dynamic texture uploading
   then we don't need to flip either if the current drawing process
   will flip it latter. If it is from finish_access, then we must
   flip the y axis.

   The second thing is the alpha channel hanlding, if the pixmap's
   format is something like x8a8r8g8, x1r5g5b5 which means it doesn't
   has alpha channel, but it do has those extra bits. Then we need to
   wire those bits to 1.

2. Add almost all the required picture format support.
   This is not as trivial as it looks like. The previous implementation
   only support GL_a8,GL_a8r8g8b8,GL_x8r8g8b8. All the other format,
   we have to fallback to cpu. The reason why we can't simply add those
   other color format is because the exists of picture. one drawable
   pixmap may has one or even more container pictures. The drawable pixmap's
   depth can't map to a specified color format, for example depth 16 can
   mapped to r5g6b5, x1r5g5b5, a1r5g5b5, or even b5g6r5. So we can't get
   get the color format just from the depth value. But the pixmap do not
   has a pict_format element. We have to make a new one in the pixmap
   private data structure. Reroute the CreatePicture to glamor_create_picture
   and then store the picture's format to the pixmap's private structure.

   This is not an ideal solution, as there may be more than one pictures
   refer to the same pixmap. Then we will have trouble. There is an example
   in glamor_composite_with_shader. The source and mask often share the
   same pixmap, but use different picture format. Our current solution is to
   combine those two different picture formats to one which will not lose any
   data. Then change the source's format to this new format and then upload
   the pixmap to texture once. It works. If we fail to find a matched new
   format then we fallback.

   There still is a potential problem, if two pictures refer to the same
   pixmap, and one of them destroy the picture, but the other still remained
   to be used latter. We don't handle that situation currently. To be fixed.

3. Dynamic texture uploading.
   This is a performance feature. Although we don't like the client to hold
   a pixmap data to shared memory and we can't accelerate it. And even worse,
   we may need to fallback all the required pixmaps to cpu memory and then
   process them on CPU. This feature is to mitigate this penalty. When the
   target pixmap has a valid gl fbo attached to it. But the other pixmaps are
   not. Then it will be more efficient to upload the other pixmaps to GPU and
   then do the blitting or rendering on GPU than fallback all the pixmaps to CPU.
   To enable this feature, I experienced a significant performance improvement
   in the Game "Mines" :).

4. Debug facility.
   Modify the debug output mechanism. Now add a new macro:
   glamor_debug_output(_level_, _format_,...) to conditional output some messages
   according to the environment variable GLAMOR_DEBUG. We have the following
   levels currently.
    exports GLAMOR_DEBUG to 3 will enable all the above messages.

5. Changes in pixmap private data structure.
   Add some for the full color format supports and relate it to the pictures which
   already described. Also Add the following new elements:
   gl_fbo - to indicates whether this pixmap is on gpu only.
   gl_tex - to indicates whether the tex is valid and is containing the pixmap's
            image originally.
   As we bring the dynamic pixmap uploading feature, so a cpu memory pixmap may
   also has a valid fbo or tex attached to it. So we will have to use the above
   new element to check it true type.

After this commit, we can pass the rendercheck testing for all the picture formats.
And is much much fater than fallback to cpu when doing rendercheck testing.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

The previous implementation will just skip the rendering
which is not good.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

By default, fallback to frame buffer currently. This commit
makes us pass the rendercheck's triangles testing.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

Added a new shader aswizlle_prog to wired the alpha to 1 when
the image color depth is 24 (xrgb). Then we don't need to fallback
the xrgb source/mask to software composite in render phase. Also
don't wire the alpha bit to 1 in the render phase. This can get
about 2x performance gain with the cairo performance trace's
firefox-planet case.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>

For those pixmap which has valid fbo and opened as GLAMOR_ACCESS_RO
mode, we don't need to upload the texture back when calling the
glamor_finish_access(). This will get about 10% performance gain.

If pixmap's size exceeds the limitation of the MESA library, the
rendering will fail. So we switch to software fb if it is the case.
Add one new element for pixmap private structure to indicate whehter
we are a software fb type or a opengl type.

those xcalloc/xfree/xalloc/XNFprintf/... are deprecated. Replace
then with the new one. And fix some other minor problems.

Due to the coordinate system on EGL is different from FBO
object. To support EGL surface well, we add this new feature.
When calling glamor_init from EGL ddx driver, it should use
the new flag GLAMOR_INVERTED_Y_AXIS.

move the original glamor_fini to glamor_close_screen. And wrap the CloseScreen
with glamor_close_screen, Then we can do some thing before call the underlying
CloseScreen().
The root cause is that glamor_fini will be called after the ->CloseScreen().
This may trigger a segmentation fault at
glamor_unrealize_glyph_caches() at calling into FreePicture().

We should include the dix-config.h for all the glamor files. Otherwise
the XID type maybe inconsisitent in different files in 64bit machine.
The root cause is this macro "#define _XSERVER64 1" should be included
in all files refer to the data type "XID" which is originally defined
in X.h. If _XSERVER64 is defined as 1, then XID is defined as CARD32
which is a 32bit integer. If _XSERVER64 is not defined as 1 then XID
is "unsigned long". In a 32bit machine, "unsigned long" should be
identical to CARD32. But in a 64bit machine, they are different.

This increases us from 23000 to 27000/sec on rgb24text.

Brings x11perf -rgb24text from 230/sec to 18400/sec

Sometimes we want to try a couple of different methods for
accelerating.  If one of them says "no" and the other says "yes",
don't spam the log about the "no."

It's not an offset from pixmap coords to composited pixmap coords,
it's an offset from screen-relative window drawable coords to
composited pixmap coords.

There's a limitation still for RepeatNone, but this fixes a bunch of
fallbacks for gnome-terminal.

This doesn't yet have an optimized glamor_composite_rects()
implementation, but it does triple the speed of x11perf -aa10text.

Root weave displays. \o/