On Sun, 2010-03-28 at 23:56 -0700, Chia-I Wu wrote: > On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell > <keith.whitw...@googlemail.com> wrote: > > I've just pushed a variation on a theme a couple of people have > > explored in the past, ie. an interface to gallium without an > > intervening state-tracker. > > The purpose of this is for writing minimal test programs to exercise > > new gallium drivers in isolation from the rest of the codebase. > > In fact it doesn't really make sense to say "without a state tracker", > > unless you don't mind creating test programs which are specific to the > > windowing system you're currently working with. Some similar work has > > avoided window-system issues altogether by dumping bitmaps to files, > > or using eg. python to abstract over window systems. > > This approach is a little different - I've defined a super-minimal api > > for creating/destroying windows, currently calling this "graw", and we > > have a tiny little co-state-tracker that each implementation provides. > > This is similar to the glut approach of abstracting over window > > systems, though much less complete. > > It currently consists of three calls: > > struct pipe_screen *graw_init( void ); > > void *graw_create_window(...); > > void graw_destroy_window( void *handle ); > > which are sufficient to build simple demos on top of. A future > > enhancement would be to add a glut-style input handling facility. > > Right now there's a single demo, "clear.c" which displays an ugly > > purple box. Builds so far only with scons, using winsys=graw-xlib. > 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. Keith ------------------------------------------------------------------------------ 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
