These offer a simpler and more efficient means for temporarily
transitioning to CPU-accessible memory for fallback implementations.
v2: Do not attempt fallbacks with GLAMOR_DRM_ONLY pixmaps
glamor cannot transfer pixels for GLAMOR_DRM_ONLY pixmaps using
glReadPixels and glTexSubImage2D, and so there's no way to perform
fallback operations with these pixmaps.
v3: Clear ->pbo field when deleting the PBO. Otherwise, we'd reuse
the old name next time we fall back on the pixmap, which would
potentially conflict with some other pixmap that genned a new
name, or just do a lazy allocation of the name (compat GL context,
like we currently use) or error out (core GL context, like we hope
to use some day). Also, style fixes. Changes by anholt, acked by
keithp.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Now that we have the DIX global state for the current context, we
don't need to track nesting to try to reduce MakeCurrent overhead.
v2: Fix a mistaken replacement of a put_context with make_current in
glamor_fill_spans_gl() (caught by keithp).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
This gets us some more context changes that are needed to make sure
the two sides render to the right drawables and manipulate the right
objects.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Now that the core deals with that for us, we can avoid all this extra
carefulness.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
A pair of 150 lines of inlined switch statements in a header file is
crazy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
We only ask for GL_RGB on desktop GL as far as I can see, but now if
GLES2 did happen to ask for GL_RGB it would return a cache index
instead of -1.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
v2: Just pass in the PicturePtr to glamor_pict_format_is_compatible()
(suggestion by keithp)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The GLX side just gets the context from the current state. That's
also something I want to do for EGL, so that the making a context is
separate from initializing glamor, but I think I need the modesetting
driver in the server before I think about hacking on that more.
The previous code was rather incestuous, along with pulling in xf86
dependencies to our dix code. The new code just initializes itself
from the current state.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
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>
We only needed this because glx was directly bashing glapi tables.
Since that's not the case anymore, we should just MakeCurrent like a
real GL app.
v2: Hand-resolve against rebase onto newer server (by 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>
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>
Because some uniform variables need to be set for every
trapezoid rendering, we can not use vbo to render multi
trapezoids one time, which have performance big loss.
We now add attributes which contain the same value to bypass
the uniform variable problem. The uniform value for one
trapezoid will be set to the same value to all the vertex
of that trapezoid as an attribute, then in FS, it is still
a constant.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
As xorg 1.13 change the scrn interaces and remove those
global arrays. Some API change cause we can't build. Now
fix it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Don't call miCompositeRects. Use glamor_composite_clipped_region
to render those boxes at once.
Also add a new function glamor_solid_boxes to fill boxes at once.
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>
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 firstly get the render area by clipping the trapezoid
with the clip rect, then split the clipped area into small
triangles and use the composite logic to generate the result
directly. This manner is fast but have the problem that
some implementation of GL do not implement the Anti-Alias
of triangles fill, so the edge sometimes has sawtooth. It is
not acceptable when use trapezoid to approximate circles and
wide lines.
Signed-off-by: Junyan He <junyan.he@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>
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>
The x_source and y_source cause some problem in
gradient. The old way to handle it by recaulate P1 P2
to minus the x_source and y_source, but this causes
problem in radial shader. Now we modify the manner to
set the texture coordinates: (x_source, y_source) -->
(x_source + width, y_source + height) to handle all the
cases.
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>
It seems that mesa has bugs when uploading bitmap to texture.
We switch to convert bitmap to a8 format and then upload the
a8 texture.
Also added a helper routine to dump 1bpp pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As PVR's GLES2 implementation doesn't support A8 texture as
rendering target, we disable it for now.
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>
If a pixmap doesn't have a private, then set its type to
GLAMOR_MEMORY, and thus it will get a valid private.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Added color conversion code to support 1555/2101010
formats,now gles2 can pass the render check with all
formats.
We use 5551 to represent 1555, and do the revertion
if downloading/uploading is needed.
For 2101010, as gles2 doesn't support reading the
identical formats. We have to use 8888 to represent,
thus we may introduce some accurate problem. But anyway,
we can pass the error checking in render check, so that
may not be a big problem.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This patch fixed two major problems when we do the color convesion with
GLES2.
1. lack of necessary formats in FBO pool.
GLES2 has three different possible texture formats, GL_RGBA,
GL_BGRA and GL_ALPHA. Previous implementation only has one bucket
for all the three formats which may reuse a incorrect texture format
when do the cache lookup. After this fix, we can enable fbo safely
when running with GLES2.
2. Refine the format matching method in
glamor_get_tex_format_type_from_pictformat.
If both revertion and swap_rb are needed, for example use GL_RGBA
to represent PICT_b8g8r8a8. Then the downloading and uploading should
be handled differently.
The picture's format is PICT_b8g8r8a8,
Then the expecting color layout is as below (little endian):
0 1 2 3 : address
a r g b
Now the in GLES2 the supported color format is GL_RGBA, type is
GL_UNSIGNED_TYPE, then we need to shuffle the fragment
color as :
frag_color = sample(texture).argb;
before we use glReadPixel to get it back.
For the uploading process, the shuffle is a revert shuffle.
We still use GL_RGBA, GL_UNSIGNED_BYTE to upload the color
to a texture, then let's see
0 1 2 3 : address
a r g b : correct colors
R G B A : GL_RGBA with GL_UNSIGNED_BYTE
Now we need to shuffle again, the mapping rule is
r = G, g = B, b = A, a = R. Then the uploading shuffle is as
below:
frag_color = sample(texture).gbar;
After this commit, gles2 version can pass render check with all
the formats except those 1555/2101010.
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>
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>
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>
For debug purpose only to dump the pixmap's content.
As this function will call glamor_prepare_access/glamor_finish_access
internally. Please use it carefully.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We add a new gl_fbo status GLAMOR_FBO_DOWNLOADED to indicate
the fbo was already downloaded to CPU. Then latter the access
to this pixmap will be treated as pure CPU access. In glamor,
if we fallback to DDX/fbXXX, then we fallback everything
currently. We don't support to jump into glamor acceleration
layer between a prepare_access/finish_access. Actually, fbCopyPlane
is such a function which may call to acceleration function within
it. Then we must mark the downloaded pixmap to another state
rather than a normal fbo textured pixmap, and then stick to use
it as a in-memory pixmap.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Tested-by: Peng Li <peng.li@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>
