This hasn't actually been a problem, since the server hasn't allocated
any glyphs before our glyph private initialization during
CreateScreenResources. But it's generally not X Server style to do
things this way.
Now that glamor itself drives both parts of glyphs setup, DDX drivers
no longer need to tell glamor to initialize glyphs. We do retain the
old public symbol so they can keep running with no changes.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
It used to be the thing that returned your dispatch table and happeend
to set up the context, but now it just sets up the context.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Libepoxy hides all the GL versus GLES2 dispatch handling for us, with
higher performance.
v2: Squash in the later patch to drop the later of two repeated
glamor_get_dispatch()es instead (caught by keithp)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Xfuncproto.h has equivalents for these already.
v2: Adjust a couple more likelies after the rebase (anholt)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
After increase to gcc4.7, it reports more warnings, now
fix them.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Tested-by: Junyan He<junyan.he@linux.intel.com>
This is a corner case, when we render glyphs via mask cache, and
when we need to upload new glyphs cache, we need to flush both the
mask and dest buffer. But we the dest arg may point to a NULL buffer
at that time, we need to check it firstly. If the dest buffer is NULL.
Then we don't need to flush both the dest and mask buffer.
This commit fix a potential crash.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
If we merge all lists's extent together, than we may have
some fail overlap checking. Here is a simple:
A E
B F
C
D
The first list has vertical "ABCD". And the second list
has two char "EF". When detecting E, it can successfully
find it doesn't overlap with previous glyphs. But after
that, the original code will merge the previous extent with
E's extent, then the extent will cover "F", so when detecting
F, it will be treated as overlapped.
We can simply solve this issue by not merge extent from different
list. We can union different list's extent to a global region.
And then do the intersect checkint between that region and
current glyph extent, then we can avoid that fail checking.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
By default, mask picture is newly created, and each time we need to
clear the whole mask picture, and then composite glyphs to the mask
picture and then composite the mask picture to destination.
Testing results shows that the filling of the mask picture takes a
big portion of the rendering time. As we don't really need to clear
the whole region, we just need to clear the real overlapped region.
This commit is to solve this issue. We split a large glyphs list to
serval lists and each list is non-overlapped or overlapped.
we can reduce the length of overlapped glyphs to do the glyphs_via_mask
to 2 or 3 glyphs one time for most cases. Thus it give us a case to allocate a
small portion of the corresponding cache directly as the mask picture.
Then we can rendering the glyphs to this mask picture, and latter we
can accumulate the second steps, composite the mask to the dest with
the other non-overlapped glyphs's rendering process.
It also make us implement a batch mask cache blocks clearing
algorithm to avoid too frequently small region clearing.
If there is no any overlapping, this method will not get performance gain.
If there is some overlapping, then this algorithm can get about 15% performance
gain.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As glamor_glyphs never fallback, we don't need to keep the
underlying glyphs routines, just override the ps->glys
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
To split a glyph's extent region to three sub-boxes
as below.
left box 2 x h
center box (w-4) x h
right box 2 x h
Take a simple glyph A as an example:
*
__* *__
*****
* *
~~ ~~
The left box and right boxes are both 2 x 2. The center box
is 2 x 4.
The left box has two bitmaps 0001'b and 0010'b to indicate
the real inked area.
The right box also has two bitmaps 0010'b and 0001'b.
And then we can check the inked area in left and right boxes with
previous glyph. If the direction is from left to right, then we
need to check the previous right bitmap with current left bitmap.
And if we found the center box has overlapped or we overlap with
not only the previous glyph, we will treat it as real overlapped
and will render the glyphs via mask.
If we only intersect with previous glyph on the left/right edge.
Then we further compute the real overlapped bits. We set a loose
check criteria here, if it has less than two pixel overlapping, we
treat it as non-overlapping.
With this patch, The aa10text boost fom 1660000 to 320000.
Almost double the performance! And the cairo test result is the
same as without this patch.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
When we can't get a cache hit and have to evict one cache
entry to upload new picture, we need to flush the previous
buffer. Otherwise, we may get corrupt glyphs rendering result.
This is the reason why user-font-proxy may fail sometimes.
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>
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>
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>
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>
Exports all necessary rendering functions to DDx drivers, including
CopyArea, Glyphs, Composite, Triangles, ....
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>
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>
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>
