As PVR's gles2 has different version number from mesa's,
just simply remove the version check here to let both
platform could build it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Need to be fixed latter. We should not need any fallback here.
But currently, the implementation for repeating tiling is
broken.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As glamor_fill may fallback to software rasterization, we'd
better to use the original drawable as input paramter.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Originaly, we use fbo blit to handle overlaped region copy.
But GLES2 doesn't support that, just simply copy the needed
region to another texture can fix this problem.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
There are two places we need to do color conversion.
1. When upload a image data to a texture.
2. When download a texture to a memory buffer.
As the color format may not be supported in GLES2. We may
need to do the following two operations to convert dat.
a. revert argb to bgra / abgr to rgba.
b. swap argb to abgr / bgra to rgba.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.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>
As some platform doesn't support to use ALPHA8 texture as
draw target, we have to disable it. It seems there is no
easy way to check that.
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>
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>
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>
It turns out that the use of fbo blit is one of the root cause
which lead to slow drawing, especially slow filling rects.
We guess there should be a performance bug in the mesa driver
or even in the kernel drm driver. Currently, the only thing
glamor can do is to avoid calling those functions.
We check whether the copy source and destination has overlapped
region, if it has, we have to call fbo blit function. If it has
not, we can load the source texture directly and draw it to the
target texture. We totally don't need the glCopyPixels here, so
remove it.
By apply this patch, the rendering time of firefox-planet-gnome
decrease to 10.4 seconds. At the same platform, uxa driver get 13
seconds. This is the first time we get better performance than
uxa driver.
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>
When fallback to cpu for the polylines procedure, we can just download
required region to CPU rather than to download the whole pixmap. This
significant improve the performance if we have to fallback, for example
do non-solid filling in the game Mines.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.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>