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>
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>
