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>
There are two cases which we may use a wrong texture size.
1. A pixmap is modified by the client side after it created
it. Then the pixmap's width may mismatch the original fbo/tex's
size. Thus we need to check this condition when preparing
upload the pixmap.
2. We provide two API to download/upload sub region of a
textured pixmap. The caller may pass in a larger width then
the original pixmap's size, this may happen at putimage
and setspans. We need to validate the width and height
when do the downloading/uploading.
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>
Currently, intel's mesa dri driver will not check pbo for
a TexSubImage2D. So we use glTexImage2D if we are a fully
updating.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As the pixmap may be attached to a picture, we need to use
glamor_upload_sub_pixmap to process it. glamor_copy_n_to_n
will not consider the picture case.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As a textured_drm pixmap has a drm bo attached to it, and
it's the DDX layer to set it stride value. In some case,
the stride value is not equal to PixmapBytePad(w, depth)
which is used within glamor.
Then if it is the case, we have two choice, one is to set
the GL_PACK_ROW_LENGTH/GL_UNPACK_ROW_LENGTH when we need
to download or upload the pixmap. The other option is to
change the pixmap's devKind to match the one glamor is using
when downloading the pixmap, and restore it to the drm stride
after uploading the pixmap.
We choose the 2nd option, as GLES doesn't support the first
method.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We already adjust the stride of the pixmap, and keep the alignment
as 4 should be ok to let the GL/GLES match the stride.
Previous version has a unbalanced PACK ROW length seting, and is
buggy, now fixed it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
For A1 to A8's conversion, the stride is different for the
source and destination. Previous implementation use the same
stride, and may allocate less memory than required. Thus may
crash the server when uploading a A1 pixmap. Now fix it.
Tested-by: Peng Li <peng.li@intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Just as the downloading side, we can upload an sub region data to
a pixmap's specified region. The data could be in memory or in a
pbo buffer.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Introduced two function glamor_get_sub_pixmap/glamor_put_sub_pixmap,
can easily used to get and put sub region of a big textured pixmap.
And it can use pbo if possible.
To support download a big textured pixmap's sub region to another
pixmap's pbo, we introduce a new type of pixmap GLAMOR_MEMORY_MAP.
This type of pixmap has a valid devPrivate.ptr pointer, and that
pointer points to a pbo mapped address.
Now, we are ready to refine those
glamor_prepare_access/glamor_finish_access pairs.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Prepare to optimize the fallback path. We choose the important
rendering pathes to optimzie it by using shader. For other pathes,
we have to fallback. We may continue to optimize more pathes in
the future, but now we have to face those fallbacks.
The original fallback is very slow and will download/upload the whole
pixmap. From this commit, I will refine it to just download/upload
needed part.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As we don't need to allocate new buffer when downloading pixmap
to CPU, we change the prototype of the color converting function
and let the caller to provide the buffer to hold the result.
All the color conversion function supports store the result
just at the same place of the source.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We don't need to issue the glamor_fallback at the glamor_set_alu
routine, as the caller may support GXclear or other most frequent
Ops. Leave it to the caller to determine fallback or not.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As GLES2 doesn't support LogiOps, we have to fallback
here. GLES2 programing guide's statement is as below:
"In addition, LogicOp is removed as it is very
infrequently used by applications and the OpenGL ES
working group did not get requests from independent
software vendors (ISVs) to support this feature in
OpenGL ES 2.0."
So, I think, fallback here may not a big deal ;).
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>
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>
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>
Concentrate checking the size/depth when creating fbo. Simply
the pixmap creation and the uploading fbo/texture preparing.
Also slightly change the uploading fbo's preparation. If don't
need fbo, then a fbo only has valid texture should be enough
to return.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Just an initial implementation and disabled by default.
When uploading a pixmap to a texture, we don't really want
to attach the texture to any fbo. So add one fbo type
which doesn't has a gl FBO attached to it.
This commit can increase the cairo-trace's performance by
10-20%. Now the firefox-planet-gnome is 8.3s. SNA is still
the best, only take 3.5s.
Thanks for Chris to point out the A1 pixmap uploading bug.
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>
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>
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>
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>
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>
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>
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>
