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>
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>
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>
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>
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>
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>
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>
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>
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>
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)
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
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>
This patch fixed two major problems when we do the color convesion with
GLES2.
1. lack of necessary formats in FBO pool.
GLES2 has three different possible texture formats, GL_RGBA,
GL_BGRA and GL_ALPHA. Previous implementation only has one bucket
for all the three formats which may reuse a incorrect texture format
when do the cache lookup. After this fix, we can enable fbo safely
when running with GLES2.
2. Refine the format matching method in
glamor_get_tex_format_type_from_pictformat.
If both revertion and swap_rb are needed, for example use GL_RGBA
to represent PICT_b8g8r8a8. Then the downloading and uploading should
be handled differently.
The picture's format is PICT_b8g8r8a8,
Then the expecting color layout is as below (little endian):
0 1 2 3 : address
a r g b
Now the in GLES2 the supported color format is GL_RGBA, type is
GL_UNSIGNED_TYPE, then we need to shuffle the fragment
color as :
frag_color = sample(texture).argb;
before we use glReadPixel to get it back.
For the uploading process, the shuffle is a revert shuffle.
We still use GL_RGBA, GL_UNSIGNED_BYTE to upload the color
to a texture, then let's see
0 1 2 3 : address
a r g b : correct colors
R G B A : GL_RGBA with GL_UNSIGNED_BYTE
Now we need to shuffle again, the mapping rule is
r = G, g = B, b = A, a = R. Then the uploading shuffle is as
below:
frag_color = sample(texture).gbar;
After this commit, gles2 version can pass render check with all
the formats except those 1555/2101010.
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Prepare for modification of gradient using shader. The
gradient pixmaps now is generated by pixman and we will
replace them with shader. Add structure fields and
dispatch functions which will be needed. Some auxiliary
macro for vertex convert.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
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>
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>
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>
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>