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