On Wed, Mar 31, 2010 at 12:52 AM, Keith Whitwell <kei...@vmware.com> wrote: > On Sun, 2010-03-28 at 23:56 -0700, Chia-I Wu wrote: >> I happened to be playing with the idea yesterday. My take is to define an >> EGL >> extension, EGL_MESA_gallium. The extension defines Gallium as a rendering >> API >> of EGL. The downside of this approach is that it depends on st/egl. The >> upside is that, it will work on whatever platform st/egl supports. >> >> I've cleaned up my work a little bit. You can find it in the attachments. >> There is a port of "clear" raw demo to use EGL_MESA_gallium. The demo >> supports >> window resizing, and is accelerated if a hardware EGL driver is used. >> >> The demo renders into a X11 window. It is worth noting that, when there is >> no >> need to render into an EGLSurface, eglCreateWindowSurface or eglMakeCurrent >> is >> not required. To interface with X11, I've also borrowed some code from >> OpenVG >> demos and renamed it to EGLUT. > I'm not sure how far to take any of these "naked" gallium approaches. > My motivation was to build something to provide a very controlled > environment for bringup of new drivers - basically getting to the first > triangle and not much further. After that, existing state trackers with > stable ABIs are probably preferable. Ok. The benefit of using st/egl is that you get to see the results on the screen. pipe_screen::flush_frontbffer is usually not implemented by hw pipe drivers. But I guess that is minor for bring-up of new drivers.
-- o...@lunarg.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
