[Mesa-dev] decoupling XCB from Mesa

Srini srini_rajini at yahoo.com
Wed Mar 30 23:38:49 PDT 2011


Hi Jerome,
i understand your point,i agree i have registered the pointer for function 
"dri2_get_buffers_flip" during initialization, and it is called from 
eglMakeCurrent( ) just after the eglCreateWindowSurface(), as you said. the 
implementation of get_buffers is as below.

static __DRIbuffer *
dri2_get_buffers_flip(__DRIdrawable * driDrawable,int *width, int 
*height,unsigned int *attachments, int count,
int *out_count, void *loaderPrivate)
{
struct dri2_egl_surface *dri2_surf = loaderPrivate;
struct dri2_egl_display *dri2_dpy =
dri2_egl_display(dri2_surf->base.Resource.Display);
/*T_DispMan_Surface*/T_LP_DispMan_Surface *flipSurf = NULL; // private windowing 
system.
int cdi_surface_width, cdi_surface_height,i,ret,fd = -1;
struct drm_i915_gem_create create;
struct drm_gem_flink flink;
struct drm_gem_open open;

_eglLog(_EGL_INFO, "This is not the right way of implementing, hack is done by 
looking out X11 values.\n");

flipSurf = DispMan_Surface_FromId(2);
if (NULL == flipSurf){
printf("~~~~~~~~~~~~ Getting Surface from Dispman Error ~~~~~~~~~~~~\n");
return NULL;
}
DispMan_Surface_GetDimension(dri2_dpy->flip_info.flipSurf, &cdi_surface_width, 
&cdi_surface_height); // Private API
dri2_surf->base.Width = *width = cdi_surface_width;
dri2_surf->base.Height = *height = cdi_surface_height;
dri2_surf->buffer_count = 1;
dri2_surf->have_fake_front = 1;

memset(&create , 0 , sizeof(create));
create.size = 2*1024 *1024;  // this values are hard coded aftre looking out the 
X11 Flow.
ret = ioctl(dri2_dpy->fd,DRM_IOCTL_I915_GEM_CREATE,&create);
assert(ret == 0);

flink.handle = create.handle;
ret = ioctl(dri2_dpy->fd, DRM_IOCTL_GEM_FLINK,&flink);
assert(ret == 0);

open.name = flink.name;
ret = ioctl(dri2_dpy->fd,DRM_IOCTL_GEM_OPEN,&open);
assert(ret == 0);
assert(open.handle != 0);

dri2_surf->buffers[0].attachment = 7;  // this values are hard coded aftre 
looking out the X11 Flow.
dri2_surf->buffers[0].name = open.name;
dri2_surf->buffers[0].pitch = 3072; // this values are hard coded aftre looking 
out the X11 Flow.
dri2_surf->buffers[0].cpp = 4; // this values are hard coded aftre looking out 
the X11 Flow.
dri2_surf->buffers[0].flags = 0; // this values are hard coded aftre looking out 
the X11 Flow.
*out_count = 1;
return dri2_surf->buffers;
}
here i am not getting what is the handle to drm buffer you are recommending. may 
be you mean after this call, the call  to "intel_bo_gem_create_from_name" from 
the function "intel_region_alloc_for_handle" in the file intel_region.c returns 
the buffer of type "struct _drm_intel_bo". i compared this structure with X11 
there is no discrepancy between both.

Another thing is, I can query pointer to onscreen window. To my windowing system 
using the call "DispMan_Surface_GetPixmapAdr( )" My idea is to do memcpy to 
this retrieved pointer from the pointer to FAKE_FRONT_LEFT
like this 
memcpy( *DispMan_Surface_GetPixmapAdr(), * FAKE_FRONT_LEFT, size) ;

for this obviously i need to derive some how  the pointer, from the drm handle 
as you suggested.

i am not clear that i conveyed you properly, please write me for more details.

Thank you very much.

Regards,
Srini.


________________________________
From: Jerome Glisse <j.glisse at gmail.com>
To: Srini <srini_rajini at yahoo.com>
Cc: mesa-dev at lists.freedesktop.org
Sent: Wed, 30 March, 2011 7:18:28 PM
Subject: Re: [Mesa-dev] decoupling XCB from Mesa

On Wed, Mar 30, 2011 at 2:30 AM, Srini <srini_rajini at yahoo.com> wrote:
> Hi Jerome,
>
>     Thanks for Reply, what you said is right for my attempt on software
> acceleration. I added a folder called "flip" in
> mesa/src/gallium/state_tracker/egl/ and created the egl software driver
> called "egl_flip_swrast.so" its working fine.
>
> My current attempt is to enable the hardware acceleration, I choose
> Mesa-7.9,and the configuration i used is
>
> "./configure --enable-gles2 --enable-egl --with-egl-platforms=x11
> --with-dri-drivers=i965 --with-state-trackers=egl,dri --disable-gallium
> --disable-glw"
>
> This configuration totally disable the gallium driver this means I am using
> Classic mesa driver, I used the small GLES application to read the flow of
> the Hardware rendering path, accordingly I mocked the entire flow for my
> windowing system by faking the egl_dri2.c file, where actually the
> initialization for x11 and drm are happening, I added the new API
> "dri2_initialize_flip".
>
> The difference between dri2_initialize_flip and dri2_initialize_x11 is, all
> the calls to XCB are removed, and rather I am using my local library by this
> way, whole initialization is successful, I have touch few thing in
> libdrm_intel.so to fake the xcb connection.
>
> How I am telling the initialization is successful is because, my gles
> application returns success in creating shader and vertex program.the final
> call to glDrawaArray is also success. after glDrawaArray application calls
> eglSwapBuffers. If I see the eglSwapBuffers implementation it boils to
> "dri2_copy_region" where they directly delegates to libXCb.
>
> From dri2_copy_region the call to "xcb_dri2_copy_region_unchecked" has the
> source and destination as XCB_DRI2_ATTACHMENT_BUFFER_FAKE_FRONT_LEFT and
> XCB_DRI2_ATTACHMENT_BUFFER_FRONT_LEFT respectively.
>
> What I believe is, final GLES created scene is available in
> "FAKE_FRONT_LEFT" if by any chance I happen to get the pointer to
> FAKE_FRONT_LEFT, I can copy the content  to my window surface and validate
> the scene.
>
> Sorry for the big mail, i want to put in detail.
>
> Happy to hear back.
>
> Regards,
>
> Srini.
>

Easiest solution is to record in egl the drm handle of the buffer when
GetBuffer is call (after egl surface creation) and in the elg swap
buffer call back you call your window system to blit from this handle
to your front buffer and do nothing else. That means that the dri
driver will keep rendering to the same buffer.

Cheers,
Jerome
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110331/960863fa/attachment.html>


More information about the mesa-dev mailing list