[Mesa-dev] decoupling XCB from Mesa

[Srini]

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.





________________________________
From: Jerome Glisse <j.glisse at gmail.com>
To: Srini <srini_rajini at yahoo.com>
Cc: mesa-dev at lists.freedesktop.org
Sent: Tue, 29 March, 2011 8:38:07 PM
Subject: Re: [Mesa-dev] decoupling XCB from Mesa

On Tue, Mar 29, 2011 at 2:28 AM, Srini <srini_rajini at yahoo.com> wrote:
> So, can you please suggest me which is the exact API or place to do this
> change.
> is there any such pointer for FAKE_FRONT_LEFT been maintained in kernel DRM
> module? or some where in x server kernel module? if it is so i can get some
> reference from there.
>
> please suggest me.
>
> Regards,
> Srini.
>

Question is what do you want to do exactly ? If you want to use mesa
software renderer i suggest you use the llvmpipe one and add proper
hook for your window system into mesa/src/gallium/state_tracker/egl/
(create a subdir their for your window system and look at the drm
folder for the simpler example).

If you also want to use the classic mesa driver than you need either
to add a new API to all of them (mesa/src/mesa/drivers/dri/) or fake
the dri interface (likely easier thought i can't remember if the dri
stuff in driver do any X/DRI2 protocol directly or just use the
callback stuff in mesa/include/GL/internal/dri_interface.h) in this
case the egl implementation need to call flush callback of
__DRI2flushExtensionRec also the invalidate callback will be call
through glx_dri2 code.

I think the biggest issue in faking dri api is that a lot of code is
in the src/glx stuff and this code callback into the driver for things
to happen. Basicly you will have to make sure that all call to
appropriate dri_interface.h callback are made corresponding to each
event (swapbuffer, new surface ...).

Gallium driver are more easier to work with, basicly just add you
window specific code into the  mesa/src/gallium/state_tracker/egl/

Cheers,
Jerome


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110330/89c5f721/attachment.html>