On Mon, Jan 4, 2010 at 2:24 AM, Luca Barbieri <l...@luca-barbieri.com> wrote: > Yes, that's a possible way to implement this. > However, it would artificially introduce the notion of a current context in > Gallium. > Also, if you mean implementing this as an egl_g3d API, it seems to me you > would have to implement the whole st_public_tmp.h for Gallium. > This would introduce more artificial notions like framebuffers with front > and back attachments, draw and read buffers, texture image binding, and so > on. I was talking about a way to support Gallium in EGL that I think fit the existing model, by treating it as a client API.
Depending on how you define the client API, it may not be too much effort to implement and not be too much different to use than EGL_MESA_gallium. You may also avoid all the artifacts. For example, if the following changes are made * eglCreateGalliumContextMESA may be replaced by eglBindAPI(EGL_GALLIUM_API_MESA) and eglCreateContext(...) * eglGetGalliumScreenMESA is replaced by g3dGetScreen(G3DeglDisplay), where G3DeglDisplay is casted from EGLDisplay * eglGetGalliumSurfacesMESA is replaced by g3dGetSurfaces(G3DeglDisplay, * G3DeglSurface, ...), where G3DeglSurface is casted from EGLSurface. You get exactly what you can do with EGL_MESA_gallium, and a perfect EGL extension. The latter two functions belong to GALLIUM API and you are free to define them whatever you want. Incidentally, about the casting, I know this may look silly but it is how EGL resources are passed to client APIs http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image.txt http://www.khronos.org/registry/vg/extensions/KHR/VG_KHR_EGL_image.txt > Instead, the point of accessing a Gallium context is to be able to use > *only* pipe_context functions after doing initial setup with EGL (except > possibly for presenting the drawn pipe_surface to the user with > eglSwapBuffers). > So, for instance, setting a framebuffer has to happen via the user calling > pipe->set_framebuffer_state, not EGL. > EGL only needs to provide a struct pipe_context* (and if pipe_screen had a > create_context function like it should, then EGL would only need to provide > a pipe_screen*) > It also needs to either provide a struct pipe_surface* for the screen or > provide an interface to show an user created struct pipe_surface* on the > screen. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
