These use the upload_boxes and download_boxes helpers to provide
reasonably efficient image transfer.
Fixes segfaults in Xephyr with x11perf -reps 1.
Performance improvements:
Improves -putimage10 by 548.218% +/- 88.601% (n=10).
Improves -putimage500 by 3.71014% +/- 1.5049% (n=10).
Improves -getimage10 by 8.37004% +/- 4.58274% (n=10).
No statistically significant difference on -getimage500 (n=10).
v2: Fix rebase failures, don't forget to check/prepare the gc in
putimage fallbacks (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
When sourcing a picture that has no alpha values, make sure any
texture fetches wire the alpha value to one. This ensures that bits
beyond the depth of the pixmap, or bits other than the RGB values
aren't used.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Fixes a usage of the wrong context with swrast GLX's GetImage entrypoint.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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 matches the Xephyr behavior. Now that we know when to reset the
context in the presence of GLX, we don't need to try to keep our stuff
from being smashed by GLX.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There is some complicated code to support tweaking the format as we
upload from a SHM pixmap (aka the GTK icon cache), but if we weren't
sourcing from a SHM pixmap we just forgot to check that the formats
matched at all.
We could potentially be a little more discerning here (xRGB source and
ARGB mask would be fine, for example), but this will all change with
texture views anyway, so just get the rendering working for 1.16
release.
Fixes the new rendercheck gtk_argb_xbgr test.
v2: Squash in keithp's fix for checking that we have a non-NULL
pixmap, and reword the comment even more.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Bad anholt, no biscuit. Broken in commit
4c9a200725.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
It wasn't possible to build glamor from tarballs.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64297#c9
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Using a pixmap as a tile or stipple means that we must have the
underlying FBO match the pixmap geometry exactly. We may want to add
some complexity here to migrate pixmaps into exact sized objects as
necessary, but for now, make the server work correctly by skipping
this optimization.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Xwayland will eventually need the current client in dri3_open. Simply
changing that API is not an option though as other drivers that
implement DRI3 will not have a matching function signature and will
crash when called.
Add a new dri3_open_client function pointer and bump
DRI3_SCREEN_INFO_VERSION so that drivers can be aware of the new
function which will be used in preference to the old function when
available.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anhole <eric@anholt.net>
Accelerates text painting with GPU-based geometry computation and stippling
v2: Simplify get_glyphs, expand single character variable names to
more descriptive ones. (Markus Wick)
v3: Rebase against the glamor_prepare_* un-renaming (changes by anholt).
Improves x11perf -f8text by 417.908% +/- 11.0144% (n=10)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This constructs suitable shaders using the glamor_program
infrastructure for poly glyph blt, and then gets rid of the no-op
wrapper of miImageGlyphBlt.
Improves x11perf -f8text by 11.6221% +/- 1.04585% (n=10)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This accelerates poly_fill_rect using GPU-based geometry computation
Improves x11perf -rect100 by 41.5127% +/- 7.63888% (n=10)
Improves x11perf -rect10 by 3745.72% +/- 94.7503% (n=6)
v2: Rebase on skipping the prepare rewrite for now, and fix the GLSL
1.20 and GLES2 cases (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This accelerates spans operations using GPU-based geometry computation
-wellipse500 goes from about 4k/sec before the patch, to ~8k/sec in
the GLES2 fallback loop, to ~100k/sec in desktop mode.
v2: Rebase on skipping the prepare rewrite for now, and fix the GLSL
1.20 and GLES2 cases (changes by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
These use glTexSubimage2D for upload and glReadPixels for
download. There are a variety of interfaces to the basic function as
needed by the callers.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
This prevents performance regressions from losing acceleration support
on older hardware as we transition to using glamor_program.c for
acceleration.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This currently computes the GLSL version in a fairly naïve fashion,
and leaves that in the screen private for other users. This will let
us update the version computation in one place later on.
v2: Drop an accidental rebase-squashed hunk (change by anholt).
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
I think the sense of the return value was just flipped here; if you
return TRUE, then the calling code assumes that the pixmap *has* been
uploaded and that an FBO is available. When it tries to use it, it
crashes though. Returning false makes the caller bail back to software.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This happens when you have 4bpp pixmaps; it's not an error, so stop
flooding the log file when it happens.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
There was a spurious declaratoin in glamor.h for glamor_poly_line_nf
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
The glamor_init calls to glamor_init_xv_shader were never getting run
because GLAMOR_XV was never defined. Instead of trying to make that
work, fix glamor_xv_init to make the call instead.
Further, just get rid of the glamor_fini_xv_shader function entirely
as the shader program will be destroyed when the context is destroyed
at server reset time.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Move the configuration of screen->SetWindowPixmap out from under it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
All of the glamor _nf functions must check to see if the DDX can
access the pixmap directly before returning failure back to the
driver; this restructures the point code to split out the _nf checking
from the _gl code.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
When we create a glamor pixmap by calling glamor_create_pixmap()
directly, we need to call glamor_destroy_pixmap() to destroy it.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This flag lets a DDX allocate a glamor pixmap without allocating the
texture that backs it. The DDX can then allocate the texture itself
and then set it later.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
A DDX that implements the glamor EGL functions need to pull in this
prototype but shouldn't need to pull in glamor_priv.h
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
By passing the client pointer to the dri3_open implementation, we allow
the clients to implement the open callback asynchronously. If the
client ignore count is positive after returning from dri3_open, we
assume that authentication is in progress and doesn't send the reply.
The code to send the reply is moved into a helper function, which the
implementation can call upon receiving its authenticaion reply.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This accelerates poly point when possible by off-loading all geometry
computation to the GPU.
Improves x11perf -dot performance by 28109.5% +/- 1022.01% (n=3)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
There's no reason to mix PolyPoint and PolySegment in the same file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-off-by: Eric Anholt <eric@anholt.net>
This just adds a bunch of support code to construct shaders from
'facets', which bundle attributes needed for each layer of the
rendering system. At this point, that includes only the primitive and
the fill stuff.
v2: Correct comment in glamor transform about 1/2 pixel correction needed
for GL_POINT. (Eric Anholt)
v3: Rebase on Markus's cleanups (change by anholt)
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This adds a few helper functions to make pixmap fbo access symmetrical
between the single fbo and tiled cases.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
This lets code treat the one-fbo pixmaps more symmetrically with the
tiled pixmaps.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
Glamor has a mode where pixmaps will be constructed from numerous
small FBOs. This allows testing of the tiled pixmap code without
needing to create huge pixmaps.
However, the render glyph code assumed that it could create a pixmap
large enough for the glyph atlas. Instead of attempting to fix that
(which would be disruptive and not helpful), I've added a new pixmap
creation usage, GLAMOR_CREATE_NO_LARGE which forces allocation of a
single large FBO.
Now that we have pixmaps with varying FBO sizes, I then went around
and fixed the few places using the global FBO max size and replaced
that with the per-pixmap FBO tiling sizes, which were already present
in each large pixmap.
Xephyr has been changed to pass GLAMOR_CREATE_NO_LARGE when it creates
the screen pixmap as it doesn't want to deal with tiling either.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We don't care that much about startup time to write different code paths...
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The mbr path was hard coded enabled for desktop gl and disabled for
gles. But there are both desktop without mbr and GLES with mbr.
v2: Don't forget to update the fini path, too (change by anholt)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We will never ever run on OpenGL 1.2 as we use shaders everywhere.
2.0 may be enough, but we also often use PBOs and our big shaders
won't fit into the first GLSL limits.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
It wasn't assigned yet when it was tested for GLAMOR_NO_DRI3.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
We don't use fixed function rendering, so there is no need to reset
the program at all. This lets the driver avoid checking for state
changes between draw calls when we rebind the same program.
Improves xephyr x11perf -f8text performance by 6.03062% +/- 1.64928%
(n=20)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
This block was disabled since 2011, so there is likely no need to keep it any more.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
Flagged by cppcheck 1.64:
[glamor/glamor_gradient.c:987] -> [glamor/glamor_gradient.c:991]:
(performance) Variable 'repeat_type_uniform_location' is
reassigned a value before the old one has been used.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
This will help tools like fips, apitrace, or INTEL_DEBUG=shader_time
provide useful information about the shaders in use.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
From the GL_ARB_vertex_buffer_object spec:
After the client has specified the contents of a mapped data store,
and before the data in that store are dereferenced by any GL commands,
the mapping must be relinquished by calling
boolean UnmapBufferARB(enum target);
Our mappings were only getting reaped at PBO destroy time, after the
upload. If the GL implementation wasn't coherent, it would have used
stale data to do the texture upload.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
If the lines aren't solid-filled vert/horiz solid-filled rectangles,
we fall back. libreoffice has some diagonal lines, and the
performance of the fallback path was atrocious. Just fall back to
mi's spans instead, so that we don't do an upload/download.
Improves x11perf -seg100 by 863.652% +/- 9.8968% (n=5)
Signed-off-by: Eric Anholt <eric@anholt.net>
Using the same idea as the previous PushPixels code, just make points
for each point in the glyph. This is an advantage over the pushpixels
fallback because we can batch the BO mappings and draw calls across
glyphs.
Improves performance of x11perf -f8text by 773.389% +/- 3.50754% (n=10).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Otherwise, mi will fall back to GetSpans()ing the bitmap, walking the
bitmap, computing spans to be filled, and calling FillSpans().
Improves x11perf -f8text by 759.373% +/- 3.33096% (n=166)
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
We had regressions in CopyPlane reported by xts5, because we were
(successfully!) dereferencing the null pixmap->devPrivate.ptr for a
tile or stipple without having done a prepare.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
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>
The common pattern is to do nested if statements making calls to
prepare_access() and then pop those mappings back off in each set of
braces. Some cases checked for src == dst to avoid leaking mappings,
but others didn't. Others didn't even do the nested mappings, so a
failure in the outer map would result in trying to umap the inner and
failing.
By allowing nested mappings, we can fix both problems by not requiring
the care from the caller, plus we can allow a simpler nesting of all
the prepares in one if statement.
v2: Add a comment about nested unmap behavior, and just reuse the
glamor_access_t enum.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Nothing was using it, and it was going to complicate the
glamor_prepare_access bugfixing I'm going to do next.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The old Xephyr codebase was using the GL window system framebuffer for
the screen pixmap, but that meant you couldn't texture from it to do
operations sourcing from the screen, so in the version that landed I
instead had the screen just be a plain texture.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This unpacks the bitfield into an int size, but my experience has been
that packing bitfields doesn't matter for performance.
v2: Convert more comparisons against numbers or implicit bool
comparisons to comparisons against the enum names, and fix up some
comments.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Now the error path of allocation is more obvious: We leave things in
the a-few-boxes-at-a-time stack memory state.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The "valid_" prefix was used above to describe our allocation that
gets reused multiple times, which is totally unrelated.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Imagine a nbox that was (UINT_MAX + small number) / (4 * 2 *
sizeof(float)). We'd malloc a few bytes after the integer overflow,
but glamor_set_normalize_vcoords would write over gigabytes of heap.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
ARRAY_SIZE(vertices) is 32 (floating point values), so we need to
divide by the number of floats in a box like we do in the overflow
case below.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
No change in generated code size -- apparently the compiler figured it
out.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
Just like for a caller of glamor_dri3_fd_from_pixmap(), otherwise the
consumer of that named buffer has no idea what GL chose for the
stride.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The flag is already being set at glamor_egl_screen_init() time, so no
need for the driver to separately call this. That said, leave the
function around to keep the ABI compatibility.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
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>
There's no reason to hide EGL from the rest of glamor, now that we
have epoxy.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus@selfnet.de>
The theory here was that it (which I copied from EGL) existed to fix
up context switching with indirect GLX. But indirect GLX won't even
try to set the context again unless its lastContext field is cleared,
so we need to solve this a different way.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
v2:
- Make the default buffer size a #define. (by Markus Wick)
- Fix the return offset for mapping with buffer_storage. (oops!)
v3:
- Avoid GL error at first rendering from unmapping no buffer.
- Rebase on the glBindBuffer(GL_ARRAY_BUFFER, 0) change.
v4: Rebase on Markus's vbo init changes.
v5: Fix missing put_context() in the buffer_storage fallback path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
The argument to setup_composte_vbo is the number of verts.
v2: Drop the now-unused vert_stride value.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
We should be uploading any vertex data using this kind of upload
style, since it saves a bunch of extra copies of our vertex data.
v2:
- Add a simple comment about what the function does.
- Use get_vbo_space()'s return in trapezoids, instead of dereffing
glamor_priv->vb (by Markus Wick).
- Fix the double-unmapping by moving put_vbo_space() outside of
flush_composite_rects().
- Remove the rest of the composite_vbo_offset usage, and just always
use get_vbo_space()'s return value.
v3:
- Fix failure to put_vbo_space in traps when no prims were
generated.
- Unbind the VBO from put_vbo_space(). Keeps callers from
forgetting to do so.
v4:
- Split out some changes into the previous 3 commits while trying to
track down a regression.
- Fix regression due to rebase fail where glamor_priv->vbo_offset
wasn't incremented.
v5:
- Fix GLES2 VBO sizing.
- Add a comment about resize behavior.
- Move glamor_vbo.c init code to glamor_vbo.c from
glamor_render.c. (Derived from Markus's changes, but the GLES2 fix
dropped almost all of the code in the functions).
v6:
- Drop the initial BufferData on GLES2 (it happens at put() time).
- Don't forget to set vbo_offset to the size on GLES2.
- Use char * instead of void * in the cast to return the vbo_offset.
- Resize the default FBO to 512kb, to be similar to previous
behavior. +1.66124% +/- 0.284223% (n=679) on aa10text.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
I want to extract the VBO mapping code, and as part of that I need to
get the global vbo_offset munging to stop.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
It's only used in the nonantialiased, triangle-based trapezoids path.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
We don't need any current contents of the buffer, and this allows an
implementation to make a temporary BO for a streamed upload if it
wants to.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
We don't call GL in this function any more, so we can just drop the
get.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
GLES2 Xephyr is failing due to lack of glMapBuffer() with the read
bits set, and I decided to see if we can just switch everything to
glMapBufferRange(). I'm undecided, and it largely depends on whether
we find people are interested in using glamor for the windows X server.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Markus Wick <markus at selfnet.de>
The render-nodes case is untested.
v2: Add a flag for wayland to suppress the native DRI3 support.
Wayland isn't running as a master itself, so it can't do the auth
on its own and has to ask the compositor to do it for us. Dropped
XXX about randr provider -- the conclusion from discussion with
keithp was that if the driver's dri3_open for a provider on a
different screen, that's a core dri3 bug.
v3: Don't put quite so much under GLAMOR_NO_DRI3, and add a comment
explaining what this is about.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
There was confusion over whether they should have egl in the name, and
they had DRI3 in the name even though they're useful to have without
DRI3.
v2: Just rename glamor_name_from_pixmap for now -- I'd accidentally
conflict-resolved in adding new parameters from a later commit.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Porting this code to be non-xorg-dependent is going to take
significant hacking, so just dump it in the glamoregl module for the
moment, so I can hack on it while regression testing.
v2: Fix compiler warnings by adding #include dix-config.h at the top,
don't try to auto-init (I'll try to fix the xv ABI later).
v3: Fix last minute breakage of having reintroduced xf86ScrnToScreen
(one of the compat macros). Just use the drawable's pScreen instead.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is not exposing the API we want long term, but it should get
existing DDX drivers up and running while we massage the API into
shape.
v2: Use LIBADD instead of LDFLAGS to fix deps on libglamor.la, and use
version 0.5.1 (the point it was forked from the external repo).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
v2: Avoid making the Ximage for the screen that we'll never use, and
drive the screen pixmap creation for glamor ourselves.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com>
There's nothing dependent on the presence of DRI3 code in the server
for this, but it does rely on GBM.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
GLES2 sensibly doesn't allow you to attach multiple shaders for the
same stage to a single program. This means we have to attach the
whole thing in one glShaderSource call.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
They never get reattached to any other program, so saving them to
unreference later is a waste of code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Assuming it was the first attribute assigned by the GL, it would have
ended up with location 0 anyway.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This is the last desktop-versus-ES2 build ifdef in core glamor.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
Now that we're using epoxy, we can write code using both desktop and
ES symbols and decide what to use at runtime.
v2: Fix a spelling mistake (latter), since the lines were moved
anyway (noticed by Rémi Cardona). Fix condition invert in
glamor_set_composite_texture (caught by Michel Dänzer).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com> (v1)
Reviewed-by: Adam Jackson <ajax@redhat.com> (v1)
gl_ModelViewProjection and friends aren't used in our shaders, so this
setup didn't do anything.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Those calls are only for enabling texture handling in the fixed
function pipeline, while everything we do is with shaders.
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>
For now we're just building an uninstalled library. The extra EGL
stubs are required so that we can get the DIX building and usable
without pulling in the xf86 DDX code in glamor_egl.c.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
We're not using the extension prototypes, since you have to dlsym them
anyway. Disabling their definitions prevents them from being defined
twice (once by gl.h, once by glext.h).
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We're going to want to make this DIX code instead of XF86 if at all
possible, but for now just disable it so we can work on the rest of
the build.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
v2: Also edit the one in glamor_egl.c (by anholt)
v3: Also edit the one in glamor_eglmodule.c (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>
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>
Automake always provide -I. It is at the beginning of the list of compiler
options.
Not needed either to find glamor_egl.c source.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
In toplevel makefile:
nostdinc: only xserver, no other X modules
aclocaldir: no local macros to install
xkb_path: xserver only
"Gross hack": xserver only
In src/makefile:
SOLARIS_ASM_CFLAGS; server only
XORG_INCS: undefined variable
DIX_CFLAGS: undefined variable
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This loop needed to go one higher, not sure if this fixes the leak
MrCooper was seeing on irc, but it fixes a leak.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This is a warning, but a real problem can occur on some system.
Reported-by: Fabio Pedretti <fabio.ped@libero.it>
Reviewed-by: Axel Davy <davyaxel@free.fr>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This implements some DRI3 helpers to help the DDXs using
glamor to support DRI3.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
There is one compilation error ,cast int to pointer, when built without
libgbm, reported by Gaetan Nadon.
And some error checking after memory allocation, reported by Seth Arnold.
There are still some similar issues in the largepixmap implementation.
They are relatively more complicate due to the heavy usage of RegionXXX
APIs which may allocate implicitly. Will fix them in the future.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Tested-by: Gaetan Nadon <memsize@videotron.ca>
This implements glamor_egl_create_textured_pixmap_from_gbm_bo,
which is similar to glamor_egl_create_textured_pixmap, except
it takes a gbm_bo as argument.
Signed-off-by: Axel Davy <axel.davy@ens.fr>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
When creating a window with recordmydesktop running, the following may happen:
create picture 0x1cd457e0, with drawable 0x1327d1f0
(SetWindowPixmap is called)
destroy picture 0x1cd457e0, with drawable 0x1cd65820
Obtaining format for pixmap 0x1327d1f0 and picture 0x1cd457e0
==7989== Invalid read of size 4
==7989== at 0x8CAA0CA: glamor_get_tex_format_type_from_pixmap (glamor_utils.h:1252)
==7989== by 0x8CAD1B7: glamor_download_sub_pixmap_to_cpu (glamor_pixmap.c:1074)
==7989== by 0x8CA8BB7: _glamor_get_image (glamor_getimage.c:66)
==7989== by 0x8CA8D2F: glamor_get_image (glamor_getimage.c:92)
==7989== by 0x29AEF2: miSpriteGetImage (misprite.c:413)
==7989== by 0x1E7674: compGetImage (compinit.c:148)
==7989== by 0x1F5E5B: ProcShmGetImage (shm.c:684)
==7989== by 0x1F686F: ProcShmDispatch (shm.c:1121)
==7989== by 0x15D00D: Dispatch (dispatch.c:432)
==7989== by 0x14C569: main (main.c:298)
==7989== Address 0x1cd457f0 is 16 bytes inside a block of size 120 free'd
==7989== at 0x4C2B60C: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7989== by 0x228897: FreePicture (picture.c:1477)
==7989== by 0x228B23: PictureDestroyWindow (picture.c:73)
==7989== by 0x234C19: damageDestroyWindow (damage.c:1646)
==7989== by 0x1E92C0: compDestroyWindow (compwindow.c:590)
==7989== by 0x20FF85: DbeDestroyWindow (dbe.c:1389)
==7989== by 0x185D46: FreeWindowResources (window.c:907)
==7989== by 0x1889A7: DeleteWindow (window.c:975)
==7989== by 0x17EBF1: doFreeResource (resource.c:873)
==7989== by 0x17FC1B: FreeClientResources (resource.c:1139)
==7989== by 0x15C4DE: CloseDownClient (dispatch.c:3402)
==7989== by 0x2AB843: CheckConnections (connection.c:1008)
==7989==
(II) fail to get matched format for dfdfdfdf
The fix is to update the picture pointer when the window pixmap is changed,
so it moves the picture around with the window rather than the pixmap.
This makes FreePicture work correctly.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71088
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
n was used as a function parameter. But inside the for (i=1..n) loop,
n got reassigned as REGION_NUM_RECTS() and then decremented to zero by
the while loop. This caused the for loop to only iterate once instead
of 'n' times.
This patch renames the n parameter to numPoints.
Found by code inspection. Untested.
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Add Fast/Good/Best and appropriately map to Nearest and
Bilinear. Additionally, add a fallback path for unsupported filters.
Notably, this fixes window shadow rendering with Compiz, which uses
PictFilterConvolution for some odd reason.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This lets us explicitly specify the range of vertices that are used,
which the OpenGL driver can use for optimization. Particularly,
it results in lower CPU overhead with Mesa-based drivers.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This does YV12 and I420 for now, not sure if we can do packed without
a GL extension.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64912
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: He Junyan <junyan.he@inbox.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
The return value of RegionContainsRect() is not a boolean but an enum
indicating that the region contains the rectangle completely, partially
or not at all. We can only take the PutImage fastpath when the region
contatins the rectangle completely.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65964
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fixes crashes when glamor is used for a GPU screen with xserver 1.13 or
newer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57200#c17
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This just adds the headers, then it falls over on the sdk_HEADERS
as it overrides proper install paths by the looks of it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
As we need to call DamageRegionAppend even for fallback path,
we must initialize the region before do that. Pointed by
Igor Vagulin.
https://bugs.freedesktop.org/show_bug.cgi?id=56940
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
According to the GL_EXT_framebuffer_blit spec, the result of doing so is
undefined. But we need well-defined results. :)
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
This commit will benefit vertex stressing cases such as
aa10text/rgb10text, and can get about 15% performance gain.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Acked-by: Junyan <junyan.he@linux.intel.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>
If the repeat direction only has one block, then we need to set the
dx/dy to cover all the extent. This commit also silence some compilation
warnings.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Current Mesa Git only advertises the former instead of the latter.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
The trapezoid generating speed of the shader is relatively
slower when the trapezoid area is big. We fallback when
the trapezoid's width and height is bigger enough.
The big traps number will also slow down the render because
of the VBO size. We fallback if ntrap > 256
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Reviewed-By: Zhigang Gong <zhigang.gong@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>
It seems that the following statement cann't run as expected on SNB.
bool trap_left_vertical = (abs(trap_left_vertical_f - 1.0) <= 0.0001);
Have to rewrite it to another style to let the vertical edge trapezoid
to be rendered correctly.
Reviewed-by: Junyan He <junyan.he@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
In some cases we allocate the VBO but have no vertex to
emit, which cause the VBO fail to be released. Fix it.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
The precise mode of trapezoid rendering need to sample the trapezoid on
the centre points of an (2*n+1)x(2*n-1) subpixel grid. It is computationally
expensive in shader, and we use inside area ratio to replace it.
The result has some difference, and we just use it if the polymode == Imprecise.
Signed-off-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>
Previous patch doesn't set the offset to zero for GLESv2
path. Now fix it.
This patch also fix a minor problem in pixmap uploading
preparation. If the revert is not REVERT_NORMAL, then we
don't need to prepare a fbo for it. As current mesa i965
gles2 driver doesn't support to set a A8 texture as a fbo
target, we must fix this problem. As some A1/A8 picture
need to be uploaded, this is the only place a A8 texture
may be attached to a fbo.
This patch also enable the shader gradient for GLESv2.
The reason we disable it before is that some glsl linker
doesn't support link different objects which have cross
reference. Now we don't have that problem.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fixes incorrectly clipped rendering. E.g. the cursor in Evolution
composer windows became invisible.
Signed-off-by: Michel Daenzer <michel.daenzer@amd.com>
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>
Practically, for pure 2D blit, the blit copy is much faster
than textured copy. For the x11perf copywinwin100, it's about
3x faster. But if we have heavy rendering/compositing, then use
textured copy will get much better (>30%)performance for most
of the cases.
So we simply add a data element to track current state. For
rendering state we use textured copy, otherwise, we use blit
copy.
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>
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>
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>
We can reuse the last one if the last one is big enough
to contain current vertext data. In the meantime, Use
MapBufferRange instead of MapBuffer.
Testing shows, this patch brings some benefit for
aa10text/rgb10text. Not too much, but indeed faster.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
I met a problem with large texture (larger than 7000x7000)'s
uploading on SNB platform. The map_gtt get back a mapped VA
without error, but write to that virtual address triggers
BUS error. This work around is to avoid that direct uploading.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
For the componentAlpha with PictOpOver, we use two pass
rendering to implement it. Previous implementation call
two times the glamor_composite_... independently which is
very inefficient. Now we change the control flow, and do
the two pass internally and avoid duplicate works.
For the x11perf -rgb10text, this optimization can get about
30% improvement.
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>
As we have glyphs atlas cache, we don't need to hold each
glyphs on GPU. And for the subsequent optimization, we need
to store the original glyphs pixmap on system memory.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We find in some cases the trapezoid will be render as a triangle and
the left edge and right edge will cross with each other just bellow
the top or over the bottom. The distance between the cross poind and
the top or bottom is less than pixman_fixed_1_minus_e, so after the
fixed converted to int, the cross point has the same value with the
top or botton and the triangle should not be affected. But in our
clip logic, the cross point will be clipped out. So add a logic
to fix this problem.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
One case we need force clip when download/upload a drm_texture
pixmap. Actually, this is only meaningful for testing purpose.
As we may set the max_fbo_size to a very small value, but the
drm texture may exceed this value but the drm texture pixmap
is not largepixmap. This is not a problem with OpenGL. But for
GLES2, we may need to call glamor_es2_pixmap_read_prepare to
create a temporary fbo to do the color conversion. Then we have
to force clip the drm pixmap here to avoid large pixmap handling
at glamor_es2_pixmap_read_prepare.
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>
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>
Because when mask depth is 1, there is no Anti-Alias at all,
in this case, the directly render can work well and it is faseter.
Signed-off-by: Junyan He <junyan.he@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>
We seperate the composite to two phases, firstly to
select the shader according to source type and logic
op, setting the right parameters. Then we emit the
vertex array to generate the dest result.
The reason why we do this is that the shader may be
used to composite no only rect, trapezoid and triangle
render function can also use it to render triangles and
polygens. The old function glamor_composite_with_shader
do the whole two phases work and can not match the
new request.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
The old manner of trapezoid render uses pixman to
generate a mask pixmap and upload it to the GPU.
This effect the performance. We now use shader to
generate the temp trapezoid mask to avoid the
uploading of this pixmap.
We implement a anti-alias manner in the shader
according to pixman, which will caculate the area
inside the trapezoid dividing total area for every
pixel and assign it to the alpha value of that pixel.
The pixman use a int-to-fix manner to approximate but
the shader use float, so the result may have some
difference.
Because the array in the shader has optimization problem,
we need to emit the vertex of every trapezoid every
time, which will effect the performance a lot. Need to
improve it.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Create the file glamor_trapezoid.c, extract the logic
relating to trapezoid from glamor_render.c to this file.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
If the source and destination are the same pixmap/fbo, and we
need to split the copy to small pieces. Then we do need to
consider the sequence of the small pieces when the copy area
has overlaps. This commit take the reverse/upsidedown into
the clipping function, thus it can generate correct sequence
and avoid corruption self copying.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
The simplest way to support large pixmap's self compositing
is to just clone a pixmap private data structure, and change
the fbo and box to point to the correct postions. Don't need
to copy a new box.
Signed-off-by: Zhigang Gong <zhigang.gong@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>
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>
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>
1. The vertical and horizontal judgement in linear
gradient have problem when p1 point and p2 point
distance is very small but the gradient pict have a
transform matrix which will convert the X Y coordinates
to small values. So the judgement is not suitable.
Because this judgement's purpose is to assure the
divisor not to be zero, so we simply it to enter
horizontal judgement when p1 and p2's Y is same.
Vertical case is deleted. 2. Delete the unused p1 p2
uniform variable.
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>
Some gradient set the stops at the same position, for
example: firstly 0.5 to red color and then set 0.5 to
blue. This kind of setting will cause the shader work
not correctly because the percentage caculating need to
use the stop[i] - stop[i-1] as dividend. The previous
patch we just kill some stop if the distance between
them is 0. But this cause the problem that the color
for next stop is wrong. We now modify to handle it in
the shader to avoid the 0 as dividend.
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>
The macro like "#define LINEAR_SMALL_STOPS 6 + 2" causes
the problem. When use it to define like "GLfloat
stop_colors_st[LINEAR_SMALL_STOPS*4];" The array is
small than what we supposed it to be. Cause memory
corruption problem and cause the bug of render wrong
result. Fix it.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
1. Extract the logic of gradient from the glamor_render.c
to the file glamor_gradient.c.
2. Modify the logic of gradient pixmap gl draw. Use the
logic like composite before, but the gradient always just
have one rect to render, so no need to set the VB and EB,
replace it with just call glDrawArrays. 3.Kill all the
warning in glamor_render.c
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>
Caching texture objects is not necessary based on previous testing.
To keep the code simple, we remove it.
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>
Almost all callers will check whether the regions is empty
before call to this internal API, but it seems the
glamor_composite_with_copy may call into here with a zero
nbox. A little weird, as the miComputeCompositeRegion return
a Non-NULL, but the region is empty.
Also remove a unecessary glflush.
So let's check it here.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Use partial texture as the pixmap for the transformation
source/mask may introduce extra errors. have to use
eaxct size.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Currently set it to 256MB. If cache pool watermark increases
to this value, then don't push any fbo to this pool, will purge
the fbo directly.
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>
We should use difference calculation for these two repeat mode
when we are a sub region within one texture.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As EGL image/gbm only support ARGB8888 image, we don't support
other format. We may change the way to use gbm directly latter.
But now, we have to face this limitation, and thus if a client
create a 16bpp drawable, and call get texture from pixmap then
a copy to here may occur and thus we have to force retur a TRUE
without do nothing.
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>
As PVR glsl compiler seems doesn't support external fragment
function, and fails at compile gradient shader. Disable it
for now. We may need to modify gradient shader to don't use
external function.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fix the bug caused by gradient picture set the stops at
the same percentage. The (stops[i] - stops[i-1]) will
be used as divisor in the shader, which will cause
problem. We just keep the later one if stops[i] ==
stops[i-1].
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Fix the problem of memory leak in gradient pixmap
generating. The problem caused by we do not call
glDeleteShader when destroy a shader program. This patch
will split the gradient pixmap generating to three
category. If nstops < 6, we will use the no array version
of the shader, which has the best performance. Else if
nstops < 16, we use array version of the shader, which is
compiled and linked at screen init stage. Else if nstops >
16, we dynamically create a new shader program, and this
program will be cached until bigger nstops.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This commit optimize two cases:
1. When the clip contains the whole area, we can directly upload
the texel data to the pixmap, and don't need to do one extra
clipped copy.
2. At fallback path, we don't read back the whole pixmap, just
need a sub region.
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>
As miGetImage is very inefficient, we don't fallback to it.
If the format is not ZPixmap, we download the required sub-
region, and then call fbGetImage to do the conversion.
This way is much faster than previous.
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>
If no clip set, we load the bits to the pixmap directly.
Otherwise, load the bits to a temporary pixmap and call
glamor_copy_area to do the clipped copy.
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>
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>
We should advance the prect after we successfully excuted the
glamor_fill. And if failed, we need to add the failed 1 box
back to nbox.
Although, this bug will never happen currently, as glamor_fill
will never fallback.
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>
Calling to miFunctions give some opportunities to jump to
accelerated path, so we switch to call miFunctions rather
than fallback to fbFunctions directly.
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>
Fixed one bug when calculate the coords, should consider the
drawable's x and y. Now enable it by default. Most of the time,
it should be more efficient than miGetImage.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Actually only PictOpAtop,PictOpAtopReverse and PictOpXor
can't be implemented by using single source blending.
All the other can be easily support. Slightly change
the code to support them. Consider those three Ops
are not frequenly used in real application. We simply
fallback them currently.
PictOpAtop: s*mask*dst.a + (1 - s.a*mask)*dst
PictOpAtopReverse: s*mask*(1 - dst.a) + dst *s.a*mask
PictOpXor: s*mask*(1 - dst.a) + dst * (1 - s.a*mask)
The two oprands in the above three ops are all reated to dst and
the blend factors are not constant (0 or 1), it's hardly to
convert it to single source blend.
Now, the rendercheck is runing more smoothly.
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>
We reuse glamor_upload_bits_to_pixmap_texture to do the
data uploading to texture in putimage. Besides to avoid
duplicate code, this also fixed the potential problem
when the data format need extra reversion which is not
supported by the finish shader, as
glamor_upload_bits_to_pixmap_texture will handle all
conditions.
Tested-by: Junyan He <junyan.he@linux.intel.com>
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>
I found when enable the gradient shader, the firefox's tab's
background has incorrect rendering result.
Need furthr investigation, for now, just disable it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Add the feature for radial gradient using shader. The
transform matrix and the 4 type of repeat mode are
supported. Less than 2/255 difference for every color
component comparing to pixman's result. Extract the
common logic of linear and radial's to another shader.
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>
Add the feature of generating linear gradient picture
by using shader. This logic will replace the original
linear gradient picture generating manner in glamor
which firstly use pixman and then upload it to GPU.
Compare it to the result generated by pixman, the
difference of each color component of each pixel is
normally 0, sometimes 1/255, and 2/255 at most. The
pixman use fixed-point but shader use float-point, so may have
difference. The feature of transform matrix and 4 types
of repeat modes have been supported. The array usage in
shader seems slow, so use 8 uniform variables to avoid
using array when stops number is not very big. This
make code look verbose but the performance improved a
lot.
We still have slightly performance regression compare to
original pixman version. There are one further optimization
opportunity which is to merge the gradient pixmap generation
and the latter compositing into one shader, then we don't need
to generate the extra texture, we can use the gradient value
directly at the compositing shader. Hope that can beat pixman
version. Will do that latter.
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>
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>
Because the file list.h in xorg/include has changed the
functions and struct names, adding xorg_ prefix before
the original name. So Modify glamor_screen_private
struct and the code which use list's functions in
glamor_fbo.c. We hack at glamor_priv.h avoid the
compile error when using old version xserver header
file.
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
This commit added two APIs to support the DRI swap buffer.
one is glamor_egl_exchange_buffers() which can swap two
pixmaps' underlying KHRimages/fbos/texs. The DDX layer should
exchange the DRM bos to make them consistent to each other.
Another API is glamor_egl_create_textured_screen_ext(), which
extent one more parameters to track the DDX layer's back pixmap
pointer. This is for the triple buffer support. When using triple
buffer, the DDX layer will keep a back pixmap rather then the
front pixmap and the pixmap used by the DRI2 client. And during
the closing screen stage, we have to dereference all the back
pixmap's glamor resources. Thus we have to extent this API to
register it when create new screen.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We may need to modify all the shader to handle GL_CLAMP_TO_BORDER
when using GLES2. XXX, for now, we just ignore them.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Slightly optimize the fragment shader, as if we are not
repeat case and not exceed the valid texture range, then
we don't need to recalculate the coords.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Then we don't need to fixup the larger pixmap to the exact
size, just need to let the shader to re-calculate the correct
texture coords.
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>
The previous's calculation is incorrect, now fix it and then
we don't need to fallback at glamor_tile.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Tested-by: Peng Li <peng.li@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>
As Xorg module loader will normalize module name which will
remove '_' when we put "glamor_egl" to the configure file,
then it will fail to find us.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We may change the way to set/get those private data latter.
consolidate to glamor_set_pixmap/screen_private is better
than call those dixSetPrivate directly.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This commit move the calling to glamor_close_screen from
glamor_egl_free_screen to glamor_egl_close_screen, as this
is the right place to do this.
We should detach screen fbo and destroy the corresponding
KHR image at glamor_egl_close_screen stage. As latter
DDX driver will call DestroyPixmap to destroy screen pixmap,
if the fbo and image are still there but glamor screen private
data pointer has been freed, then it causes segfault.
This commit also introduces a new flag GLAMOR_USE_EGL_SCREEN.
if DDX driver is using EGL layer then should set this bit
when call to glamor_init and then both glamor_close_screen
and glamor_egl_close_screen will be registered correctly,
DDX layer will not need to call these two functions manually.
This way is also the preferred method within Xorg domain.
As interfaces changed, bump the version to 0.3.0.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Tested-by: Peng Li <peng.li@intel.com>
In order to reduce a composite operation to a source, we need to provide
Render semantics for the pixel values of samples outside of the source
pixmap, i.e. they need to be rgba(0, 0, 0, 0). This is provided by using
the CLAMP_TO_BORDER repeat mode, but only if the texture has an alpha
channel.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
In order to maintain Render semantics, samples outside of the source
should return CLEAR. The copy routines instead are based on the core
protocol and expects the source rectangle to be wholly contained within
the drawable and so does no fixup.
Fixes the rendering of GTK icons.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
And also reduce the expire count to 100 which should be
good enough on x11perf and cairo-trace testing.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.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>
glamor calls DRM_IOCTL_GEM_FLINK to get a name for a buffer object.
It only works for driver that support GEM, such as intel i915 driver.
But for pvr driver who doesn't has GEM, we can't do it this way.
According to Chris's comments, we check the has_gem as the following
method:
Here we just try to flink handle 0. If that fails with ENODEV or
ENOTTY instead of ENOENT (or EINVAL on older kernels), set has_gem=0.
Signed-off-by: Li Peng <peng.li@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Maybe we should use eglGetDisplayDRM to get display, but current
PVR's driver is using eglGetDisplay.
Signed-off-by: Peng Li <peng.li@intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Some gles2 implementation doesn's support get_proc_address.
And we also need to avoid get those missing functions pointers
when we are GLES2.
Signed-off-by: Peng Li <peng.li@intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As some GLES implementations' glMapOES /glUnmapOES is
not so efficient, we implement the in memory vertex array
for them.
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 after we got a texture, no matter the texture is created
on the glamor_create_pixmap or on the egl layer, we all already
know the texture's width and height there. We don't need
to pass them in.
This commit also simply the glamor_egl_create_textured_screen to
reuse the egl_create_textured_pixmap. And also remove the useless
root image from the egl private structure. As now the root image
is bound to the screen image, we don't take care it separately
here. It will be freed at the screen closing.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
We should not simply set a TEXTURE_DRM pixmap to a separated
texture pixmap. If the format is compatible with current fbo
then it is just fine to keep it as TEXTURE_DRM type and we
can safely fallback to DDX layer on it.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
As we want to support DRI2 drawable which may create a new textured_drm
to a pre-existing texture_only pixmap, we have to add this logical.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Tested-by: He Junyan<junyan.he@linux.intel.com>
Use a fixed VBO is not efficient. Some times we may only has less than
100 verts, and some times we may have larger than 4K verts. We change
it to allocate VBO buffer dynamically, and this can bring about 10%
performance gain for both aa10text/rgb10text and some cairo benchmarks.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
This optimization will only call glReadPixels once. It should get
some performance gain. But it seems it even get worse performance
at SNB, disable it by default.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
To split a rectangle (0,1,2,3) to two separated triangles need to feed
6 vertices, (0,1,2) and (0,2,3). use glDrawElements can reuse the shared
vertices.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Computing the composite region at the composite_with_shader is very
inefficient. As when we call to here from the glamor_glyph's temproary
picture, we don't need to compute this region at all. So we move this
computing out from this function and do that at the glamor_composite
function. This can get about 5% performance gain for aa10text/rgb10text.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Should check the enable-glamor-gles2 before use the variable.
And should include the config.h as the GLAMOR_GLES2 macro is
defined there.
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>
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>
Change the glamor_change_window_attributes's handling. We don't need
to fallback every thing to cpu at the beginning. Only when there
is a real need to change the pixmap's format, we need to do something.
Otherwise, we need do nothing here.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Concentrate the verties and texture coords processing code to a new
file glamor_utils.h. Change most of the code to macro. Will have some
performance benefit on slow machine. And reduce most of the duplicate
code when calculate the normalized coords.
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>
This commit was borrowed from uxa driver contributed by Eric.
commit number is e0066e77e026b0dd0daa0c3765473c7d63aa6753. commit log paste as
below:
We were clipping each span against the bounds of the clip, throwing
out the span early if it was all clipped, and then walked the clip box
clipping against each of the cliprects. We would expect spans to
typically be clipped against one box, and not thrown out, so we were
not saving any work there. For multiple cliprects, we were adding
work. Only for many spans clipped entirely out of a complicated clip
region would it have saved work, and it clearly didn't save bugs as
evidenced by the many fix attempts here.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
By default, fallback to frame buffer currently. This commit
makes us pass the rendercheck's triangles testing.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
For 1bpp pixmap, software fb get better performance than
GL surface. The main reason is that fbo doesn't support
1bpp texture as internal format, so we have to translate
a 1bpp bitmap to a 8bit alpha format each time which is
very inefficient. And the previous implementation is
not supported by the latest OpenGL 4.0, the GL_BITMAP
was deprecated.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Added a new shader aswizlle_prog to wired the alpha to 1 when
the image color depth is 24 (xrgb). Then we don't need to fallback
the xrgb source/mask to software composite in render phase. Also
don't wire the alpha bit to 1 in the render phase. This can get
about 2x performance gain with the cairo performance trace's
firefox-planet case.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
use pbo if possible when we load texture to a temporary tex.
And for the previous direct texture load function, it's not
correct and get removed in this commit.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Added comments to glamor_pixmap_create. To be refined in the future.
We need to identify whether a pixmap is a CPU memory pixmap or a
GPU pixmap. Current implementation is not correct. There are three
cases:
1. Too large pixmap, we direct it to CPU memory pixmap.
2. w ==0 || h == 0 pixmap, this case has two possibilities:
2.1 It will become a screen pixmap latter, then it should be
GPU type.
2.2 It's a scratch pixmap or created from a share memory, then
it should belong to CPU memory.
XXX, need to be refined latter.
For those pixmap which has valid fbo and opened as GLAMOR_ACCESS_RO
mode, we don't need to upload the texture back when calling the
glamor_finish_access(). This will get about 10% performance gain.
Change the row length of 1bit color depth pixmap to the actual stride.
The previous implementation use the width as its stride which is not
good. As it will waste 8 times of space and also bring some non-unify
code path. With this commit, we can merge those 1bit or other color
depth to almost one code path. And we will use pixel buffer object
as much as possible due to performance issue. By default, some mesa
hardware driver will fallback to software rasterization when use
glReadPixels on a non-buffer-object frame buffer. This change will
get about 4x times performance improvemention when we use y-inverted
glamor or the driver support hardware y-flipped blitting.
If pixmap's size exceeds the limitation of the MESA library, the
rendering will fail. So we switch to software fb if it is the case.
Add one new element for pixmap private structure to indicate whehter
we are a software fb type or a opengl type.
Due to the coordinate system on EGL is different from FBO
object. To support EGL surface well, we add this new feature.
When calling glamor_init from EGL ddx driver, it should use
the new flag GLAMOR_INVERTED_Y_AXIS.
