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>
If a pixmap is a pure in-memory pixmap, we do not need to
check its format. Format checking has more overhead than
checking FBO, so we change to check fbo firtly.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Even if a picture's pixmap is a pure in memory pixmap, we still need
to track its format. The reason is we may need to upload this drawable
to texture thus we need to know its real picture format.
As to the MACRO to check whether a pixmap is a picture, we should
check whether the priv is non-NULL before we touch its field.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As now the pixmap may be allocated by DDX and doesn't have a
valid pixmap private field. We must check pixmap private
pointer before touch its field value. If a pixmap doesn't
have a non-NULL private pointer, it doesn't have a valid
FBO.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As we want to take over all the possible GC ops from the DDX
layer, we need to add all the missed functions.
This commit also fixed one bug at polylines.
We simply drop the bugy optimized code now, as it did not
consider of clip info.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We should not change the points coords when loop for the clip
rects. Change to use another variable to store the clipped
coords and keep the original coords. This bug cause some
XTS failures. Now fix it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
fbPutImage wants the input drawable is the target drawable rather
than the backing pixmap. This bug cause some XTS failures, now
fix it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
The original version assumes that each drawable pixmap should
have a valid private pixmap pointer. But this is not true after
we create this libglamor. As the DDX layer may create a pure
software drawable pixmap which doesn't have a private pixmap
pointer.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This is also a function which may direct access pixmaps which
may be a glamor only pixmap and DDX doesn't know how to access
it. We have to export this API to DDX driver and let the DDX
driver use it to do the validation.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Before destroy an image which was attached to a texture.
we must call glFlush to make sure the operation on that
texture has been done.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As at ValidateGC stage, it may need to touch the pixmap directly, for
example the tile pixmap. We must export this interface to DDX driver
and let the DDX driver to route the processing to us. As this pixmap
may be a texture only pixmap, and DDX don't know how to handle it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We only need to create image fron external name rather
than use drm_image_mesa to create drm image, so remove
them.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Just in case when wrongly fallback to DDX layer and cause
random memory corruption. Pointed out by Chris.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
If DDX failed to create textured pixmap from its BO's handle,
it can turn to call this API to create a brand new glamor
rather than fallback to pure in memory pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Discussed with Chris and found the previous logic is not
good. Now change it in this commit, this API will just
try to create a textured pixmap from the handle provided
by DDX driver, if failed simply return FALSE without touch
the pixmap. And the DDX driver can choose how to do next
step.
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>
As we may need to fallback to DDX's rendering path
during the glyphs, we have to call screen's create pixmap
method to create pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
During the integration with intel driver, we introduce two
new type of pixmap, one is TEXTURE_DRM, the other is DRM_ONLY.
TEXTURE_DRM means we create a texture bind to the DRM buffer
successfully. And then the texture and the external BO is
consistent. DRM_ONLY means that we failed to create a texture
from the external DRM BO. We need to handle those different
types carefully, so we have to track them in the data structure.
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>
Currently, KHR image only support one color format ARGB32.
For all other format, we have to fail to create corresponding
image and texture here.
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>
When create a piccture, we need to attach a pixmap to it.
A pixmap only has a depth, which is not sufficant for glamor.
As in openGL texture only has a few internal formats which
is not sufficant to represent all the possible picture
format. So we always transform the picture format to GL_RGBA.
And when we need to read back the picture, we must know the
original picture format. So we have to override create
and destroy picture to track a pixmap's real picture format
if it is attached to a picture.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Pointed by Chris, we must add xorg-server.h at the top
of each file before we include any other xorg header files.
Otherwise, it may cause incorrect XID length.
This commit also fixes one compilation warning in X86_64
platform.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
If need fallback, this new version just returns FALSE without
doing anything. It's the caller's responsibility to implement
fallback method.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
For the purpose of incrementally intergration of existing intel
driver, for the GC operations we may don't want to use glamor's
internal fallback which is in general much slower than the
implementation in intel driver. If the parameter "fallback" is
false when call the glamor_fillspans, then if glamor found it
can't accelerate it then it will just return a FALSE rather than
fallback to a slow path.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
The previous implementation is to override the CreatePixmap
firstly and assume the first call to CreatePixmap must be
screen pixmap. This is not clean. Now Refine it to normal
way. Let the Xephyr to set texture 0 to screen pixmap
during creating screen resources.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Latest mesa EGL implementation move to use gbm to manage/allocate buffers.
To keep backward compatibility, we still try to use eglGetDRMDisplayMESA
firstly, and if failed, then turn to use eglGetDisplay(gbm).
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This function is used to support dri2. In the underlying
driver, it will create a buffer object for a given pixmap.
And then call this api to create a egl image from that
buffer object, and then bind that image to a texture, and
then bind that texture to the pixmap.
Normally, this pixmap's content is shared between a dri2
client and the x server.
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 in glamor_glyphs_init, we may need to create pixmap. Thus it must
be called after the pixmap resources allocation. Just move it to
screen resource creation stage is good enough for mow.
Also introduce a macro GLAMOR_FOR_XORG to glamor.h. As glamor may
be used by Xephyr which doesn't don't have those xorg header files
and also don't need the egl extension.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Slightly change the API glamor_egl_init,
as this initialization is to initialize the display not
the screen, we should call it in xxx_preinit rather
than xxxScreenInit(). we change the input parameter as
below, as in preInit, the screen may not be allocated
at all. And in glamor_egl_init, it will not call
glamor_init. Driver should call glamor_init at
screen_init stage.
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>
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>
It will return when the destination pixmap has a fbo but will continue
when it doesn't have a fbo.
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>
glamor_fill is only called from internal functions
glamor_fillspancs and glamor_polyfillrect. And both functions
already add the offset to the coords, so the coords are already
relative value, we can't add the offset once again.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
If the dest pixmap is in texture memory, but source pixmap is not.
Then we need to upload the source pixmap to texture memory. Previous
version will upload the whole source pixmap. This commit preprocess
the source pixmap, and reduce it to a smaller tempory pixmap only
contains the required region.
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>
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>
If the pixmap is write-only, then use a pbo mapping will not
get too much benefit. And even worse, when the software
rendering is access this mapped data range, it's much slower
than just using a system memory. From the glamor_prepare_access
glamor_finish_access view, we have two options here:
option 1:
1.0 create a pbo
1.1 copy texture to the pbo
1.2 map the pbo to va
1.3 access the va directly in software rendering.
1.4 bind the pbo as unpack buffer & draw it back to texture.
option 2:
2.0 allocate a block memory in system memory space.
2.1 read the texture memory to the system memory.
2.2 access the system memory and do rendering.
2.3 draw the system memory back to texture.
In general, 1.1 plush 1.2 is much faster than 2.1.
And 1.3 is slower than 2.2. 1.4 is faster than 2.3.
If the access mode is read only or read write, option 1
may be fater, but if the access mode is write only. Then
most of the time option 1 is much faster.
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>
When try to upload a pixmap without yInverted set, we must
set up a fbo for it to do the y flip. Previous implementation
only consider the ax bit. After fix this problem, we can
enable the dynamic uploading feature in copyarea function when
the yInverted is not set (from Xephyr).
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
When calling from ephyr, we forgot to initialize it to the correct
value. Will cause segfault when run Xephyr.
Signed-off-by: Zhigang Gong <zhigang.gong@gmail.com>
Zhigang Gong
Zhigang Gong
Zhenyu Wang