One case we need force clip when download/upload a drm_texture
pixmap. Actually, this is only meaningful for testing purpose.
As we may set the max_fbo_size to a very small value, but the
drm texture may exceed this value but the drm texture pixmap
is not largepixmap. This is not a problem with OpenGL. But for
GLES2, we may need to call glamor_es2_pixmap_read_prepare to
create a temporary fbo to do the color conversion. Then we have
to force clip the drm pixmap here to avoid large pixmap handling
at glamor_es2_pixmap_read_prepare.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We change some macros to put the vert to the vertex buffer
directly when we cacluating it. This way, we can get about
4% performance gain.
This commit also fixed one RepeatPad bug, when we RepeatPad
a not eaxct size fbo. We need to calculate the edge. The edge
should be 1.0 - half point, not 1.0.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We seperate the composite to two phases, firstly to
select the shader according to source type and logic
op, setting the right parameters. Then we emit the
vertex array to generate the dest result.
The reason why we do this is that the shader may be
used to composite no only rect, trapezoid and triangle
render function can also use it to render triangles and
polygens. The old function glamor_composite_with_shader
do the whole two phases work and can not match the
new request.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Create the file glamor_trapezoid.c, extract the logic
relating to trapezoid from glamor_render.c to this file.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
The simplest way to support large pixmap's self compositing
is to just clone a pixmap private data structure, and change
the fbo and box to point to the correct postions. Don't need
to copy a new box.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This commit implement almost all the needed functions for
the large pixmap support. It's almost complete.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Now we start to enable glamor_composite on large pixmap.
We need to do a three layer clipping to split the dest/source/mask
to small pieces. This commit only support non-transformation and
repeat normal case.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Added infrastructure for largepixmap, this commit implemented:
1. Create/Destroy large pixmap.
2. Upload/Download large pixmap.
3. Implement basic repeat normal support.
3. tile/fill/copyarea large pixmap get supported.
The most complicated part glamor_composite still not implemented.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This is the first commit to add support for large pixmap.
The large here means a pixmap is larger than the texutre's
size limitation thus can't fit into one single texutre.
The previous implementation will simply fallback to use a
in memory pixmap to contain the large pixmap which is
very slow in practice.
The basic idea here is to use an array of texture to hold
the large pixmap. And when we need to get a specific area
of the pixmap, we just need to compute/clip the correct
region and find the corresponding fbo.
We need to implement some auxiliary routines to clip every
rendering operations into small pieces which can fit into
one texture.
The complex part is the transformation/repeat/repeatReflect
and repeat pad and their comination. We will support all of
them step by step.
This commit just add some necessary data structure to represent
the large pixmap, and doesn't change any rendering process.
This commit doesn't add real large pixmap support.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
1. Extract the logic of gradient from the glamor_render.c
to the file glamor_gradient.c.
2. Modify the logic of gradient pixmap gl draw. Use the
logic like composite before, but the gradient always just
have one rect to render, so no need to set the VB and EB,
replace it with just call glDrawArrays. 3.Kill all the
warning in glamor_render.c
Reviewed-by: Zhigang Gong<zhigang.gong@linux.intel.com>
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Previous implementation set the whole fbo's width and height as the
viewpoint. This may increase the numerical error as we may only has
a partial region as the valid pixmap. So add a new marco
pixmap_priv_get_dest_scale to get proper scale factor for the
destination pixmap. For the source/mask pixmap, we still need to
consider the whole fbo's size.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We miss the strict warning flags for a long time, now add it back.
This commit also fixed most of the warnings after enable the strict
flags.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As GLES2 doesn't support clamp to the border, we have to
handle it seprately from the normal case.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Use partial texture as the pixmap for the transformation
source/mask may introduce extra errors. have to use
eaxct size.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We should use difference calculation for these two repeat mode
when we are a sub region within one texture.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fix the bug caused by gradient picture set the stops at
the same percentage. The (stops[i] - stops[i-1]) will
be used as divisor in the shader, which will cause
problem. We just keep the later one if stops[i] ==
stops[i-1].
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fix the problem of memory leak in gradient pixmap
generating. The problem caused by we do not call
glDeleteShader when destroy a shader program. This patch
will split the gradient pixmap generating to three
category. If nstops < 6, we will use the no array version
of the shader, which has the best performance. Else if
nstops < 16, we use array version of the shader, which is
compiled and linked at screen init stage. Else if nstops >
16, we dynamically create a new shader program, and this
program will be cached until bigger nstops.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We have disabled this feature for a long time, and previous
testing shows that this(pending fill) will not bring observed
performance gain. Now remove it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Actually only PictOpAtop,PictOpAtopReverse and PictOpXor
can't be implemented by using single source blending.
All the other can be easily support. Slightly change
the code to support them. Consider those three Ops
are not frequenly used in real application. We simply
fallback them currently.
PictOpAtop: s*mask*dst.a + (1 - s.a*mask)*dst
PictOpAtopReverse: s*mask*(1 - dst.a) + dst *s.a*mask
PictOpXor: s*mask*(1 - dst.a) + dst * (1 - s.a*mask)
The two oprands in the above three ops are all reated to dst and
the blend factors are not constant (0 or 1), it's hardly to
convert it to single source blend.
Now, the rendercheck is runing more smoothly.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
I found when enable the gradient shader, the firefox's tab's
background has incorrect rendering result.
Need furthr investigation, for now, just disable it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Add the feature for radial gradient using shader. The
transform matrix and the 4 type of repeat mode are
supported. Less than 2/255 difference for every color
component comparing to pixman's result. Extract the
common logic of linear and radial's to another shader.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Add the feature of generating linear gradient picture
by using shader. This logic will replace the original
linear gradient picture generating manner in glamor
which firstly use pixman and then upload it to GPU.
Compare it to the result generated by pixman, the
difference of each color component of each pixel is
normally 0, sometimes 1/255, and 2/255 at most. The
pixman use fixed-point but shader use float-point, so may have
difference. The feature of transform matrix and 4 types
of repeat modes have been supported. The array usage in
shader seems slow, so use 8 uniform variables to avoid
using array when stops number is not very big. This
make code look verbose but the performance improved a
lot.
We still have slightly performance regression compare to
original pixman version. There are one further optimization
opportunity which is to merge the gradient pixmap generation
and the latter compositing into one shader, then we don't need
to generate the extra texture, we can use the gradient value
directly at the compositing shader. Hope that can beat pixman
version. Will do that latter.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Prepare for modification of gradient using shader. The
gradient pixmaps now is generated by pixman and we will
replace them with shader. Add structure fields and
dispatch functions which will be needed. Some auxiliary
macro for vertex convert.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Slightly optimize the fragment shader, as if we are not
repeat case and not exceed the valid texture range, then
we don't need to recalculate the coords.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Then we don't need to fixup the larger pixmap to the exact
size, just need to let the shader to re-calculate the correct
texture coords.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Renaming glamor_priv->dispatch and wrapping the access to
the dispatch table with a function that also ensured the
context was bound.
dispatch = glamor_get_dispatch(glamor_priv);
...
glamor_put_dispatch(glamor_priv);
So that we catch all places where we attempt to call into GL withouta
context. As an optimisation we can then do glamor_get_context();
glamor_put_context() around the rendering entry points to reduce the
frequency of having to restore the old context. (Along with allowing
the context to be recursively acquired and making the old context part of
the glamor_egl state.)
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
If we are using MESA as our GL library, then both xserver's
GLX and glamor are link to the same library. As xserver's
GLX has its own _glapi_get/set_context/dispatch etc, and it
is a simplified version derived from mesa thus is not
sufficient for mesa/egl's dri loader which is used by glamor.
Then if glx module is loaded before glamoregl module, the
initialization of mesa/egl/opengl will not be correct, and
will fail at a very early stage, most likely fail to map
the element buffer.
Two methodis to fix this problem, first is to modify the xserver's
glx's glapi.c to fit mesa's requirement. The second is to put
a glamor.conf as below, to the system's xorg.conf path.
Section "Module"
Load "glamoregl"
EndSection
Then glamor will be loaded firstly, and the mesa's libglapi.so
will be used. As current xserver's dispatch table is the same
as mesa's, then the glx's dri loader can work without problem.
We took the second method as it don't need any change to xorg.:)
Although this is not a graceful implementation as it depends
on the xserver's dispatch table and the mesa's dispatch table
is the same and the context set and get is using the same method.
Anyway it works.
As by default, xserver will enable GLX_USE_TLS. But mesa will not
enable it, you may need to enable that when build mesa.
Three pre-requirements to make this glamor version work:
0. Make sure xserver has commit 66e603, if not please pull the latest
master branch.
1. Rebuild mesa by enable GLX_USE_TLS.
2. Put the glamor.conf to your system's xorg.conf path and make sure
it loaded prior to glx module.
Preliminary testing shows indirect glxgears works fine.
If user want to use GLES2 for glamor by using MESA, GLX will not
work correctly.
If you are not using normal MESA, for example PVR's private GLES
implementation, then it should be ok to use GLES2 glamor and the
GLX should work as expected. In this commit, I use gbm to check
whether we are using MESA or non-mesa. Maybe not the best way.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
In order to reduce a composite operation to a source, we need to provide
Render semantics for the pixel values of samples outside of the source
pixmap, i.e. they need to be rgba(0, 0, 0, 0). This is provided by using
the CLAMP_TO_BORDER repeat mode, but only if the texture has an alpha
channel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
In order to maintain Render semantics, samples outside of the source
should return CLEAR. The copy routines instead are based on the core
protocol and expects the source rectangle to be wholly contained within
the drawable and so does no fixup.
Fixes the rendering of GTK icons.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As some GLES implementations' glMapOES /glUnmapOES is
not so efficient, we implement the in memory vertex array
for them.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fixup three special cases, one is in tile and the other is in
composite. Both cases are due to repeat texture issue. Maybe
we can refine the shader to recalculate texture coords to
support partial texture's repeating.
The third is when upload a memory pixmap to texture, as now
the texture may not have the exact size as the pixmap, we
should not use the full rect coords.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We classify the cache according to the texture's format/width/height.
As openGL doesn't allow us to change a texture's format/width/height
after the internal texture object is already allocated, we can't
just calculate the size and then according ths size to put the
fbo to an bucket which is just like SNA does. We can only put
the fbo to the corresponding format/width/height bucket.
This commit only support the exact size match. The following patch
will remove this restriction, just need to handle the repeat/tile
case when the size is not exactly match.
Should use fls instead of ffs when decide the width/height bucket,
thanks for Chris to point this out.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This is the first patch to implement a fbo/tex pool mechanism which
is like the sna's BO cache list. We firstly need to decopule the
fbo/tex from each pixmap. The new glamor_pixmap_fbo data
structure is for that purpose. It's somehow independent to each
pixmap and can be reused latter by other pixmaps once it's detached
from the current pixmap.
And this commit also slightly change the way to create a
memory pixmap. We will not create a pixmap private data structure
by default, instead we will crete that structure when a memory
pixmap is attaching a fbo to it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Use a fixed VBO is not efficient. Some times we may only has less than
100 verts, and some times we may have larger than 4K verts. We change
it to allocate VBO buffer dynamically, and this can bring about 10%
performance gain for both aa10text/rgb10text and some cairo benchmarks.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
To split a rectangle (0,1,2,3) to two separated triangles need to feed
6 vertices, (0,1,2) and (0,2,3). use glDrawElements can reuse the shared
vertices.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Computing the composite region at the composite_with_shader is very
inefficient. As when we call to here from the glamor_glyph's temproary
picture, we don't need to compute this region at all. So we move this
computing out from this function and do that at the glamor_composite
function. This can get about 5% performance gain for aa10text/rgb10text.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As we now add the checking to the Macro, we don't need to check
the pointer outside the Macro.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This commit exports all the rest rendering/drawing functions
to the DDX drivers. And introduce some new pixmap type. For
a pixmap which has a separated texture, we never fallback
it to the DDX layer.
This commit also adds the following new functions:
glamor_composite_rects, glamor_get_image_nf which are needed
by UXA framework. Just a simple wrapper function of miXXX.
Will consider to optimize them next few weeks.
This commit also Fixed a glyphs rendering bug pointed by Chris.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
When glamor is rendering pixmaps, and needs to create some
temporary pixmap, it's better to use glamor version create
pixmap directly. As if goes to external DDX's create pixmap,
it may create a external DRM buffer which is not necessary.
All the case within glamor scope is to create a texture only
pixmap or a in memory pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Change the finish_access to pass in the access mode, and remove
the access mode from the pixmap structure. This element should
not be a pixmap's property.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Exports all necessary rendering functions to DDx drivers, including
CopyArea, Glyphs, Composite, Triangles, ....
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Create a new structure glamor_gl_dispatch to hold all the
gl function's pointer and initialize them at run time ,
rather than use them directly. To do this is to avoid
symbol conflicts.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This commit applying the latest uxa's glyphs cache mechanism
and give up the old hash based cache algorithm. And the cache
picture now is much larger than the previous one also.
This new algorithm can avoid the hash insert/remove and also
the expensive sha1 checking. It could obtain about 10%
performance gain when rendering glyphs.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
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>
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>
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>
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>
Xephyr doesn't has a bounded valid texture. It seems that we can't
load texture 0 directly sometimes. Especially in the copyarea, function
if that is the case, we prefer to use fbo blit to read the screen pixmap
rather than load the bound texture.
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>
We already handle all format checking in pixmap uploading and
converting, don't need to do that again.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This reverts commit eb16fe0b7c8ea27b5cf9122d02e48bf585495228.
As currently glamor_prepare_access/finish_access will touch
the whole pixmap, not just the request region, then write only
mode will not work correctly. We may need to revisit all fallback
case, and convert the image to the right size before do the
prepare/finish processing.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
Some strange web page has 20000*1 png picture, and actually only use
partial of it. We force to convert it to a actuall size rather than
its original size,if it is the case. Then to avoid latter's failure
uploading.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
If we only need a short part of the source or mask's drawable
pixmap, we can convert it to a new small picture before
call to the low level compositing function. Then it will only
upload the smaller picture latter.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Access mapped vbo address is too slow. And by use system memory
directly, rgb10text/aa10text increases from 980K/1160K to 117K/140K.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This reduce the time when running cairo-performance-trace with
the firefox-planet-gnome.trace from 23.5 seconds to 21.5 seconds.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This is a bug, as if we do blend set up before do the pixmap
dynamic uploading. We will have a incorrect blend env when
doing the uploading.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
Change the glamor_change_window_attributes's handling. We don't need
to fallback every thing to cpu at the beginning. Only when there
is a real need to change the pixmap's format, we need to do something.
Otherwise, we need do nothing here.
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>
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>
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.
They're stored just like a8, but the values are set to either 0.0 or
1.0. Because they're a8 with only two legal values, we can't use them
as destinations, but nobody's rendering to a1 dests anyway (we hope).
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.
