On Sun, 2009-05-03 at 03:05 -0700, Thomas Hellström wrote: > Jose Fonseca wrote: > > > > gallium-screen-context adds a new callback to create a context with a > > screen. This is very useful when one stacks pipe drivers on top of another > > (like the trace pipe driver, or perhaps one day the draw module). The > > problem is the pipe_context::priv and the context_private argument of > > pipe_screen::flush_frontbuffer. Putting private in pipe_context doesn't > > work if there are many pipe contexts. Basically, pipe_context::priv must > > disappear, and context_private argument must be replaced by something > > sensible (perhaps an abstract drawable pointer). However these are used by > > GLX/DRI code which I don't understand enough to fix on my own. > > > > > José, > > the drm_api <gallium/include/state-tracker/drm_api.h> has an equivalent > callback usually exported by a particular winsys wanting to implement > the drm_api, and that winsys typically call into the pipe driver to > implement this, so having it exported by the pipe_screen is probably a > good idea. > > The problem with pipe_context::priv is that the state-tracker may export > a set off callbacks to be used by the winsys, and these callbacks > typically take an opaque pointer to a per-context structure used by the > state tracker. For DRI these are flush_frontbuffer and the DRI locking > functions. > > One possible solution to this would be to have a > > pipe_screen::context_create(struct pipe_screen *screen, struct > context_private *priv); > > @priv could either be a void * or perhaps a pointer to a structure that > can be derived from: > > A pipe driver wrapping this function would just pass the priv parameter > on to the next level.
Yes, passing priv as an argument is a simple solution that allows to move this change forward. I guess that I abhor these magic priv pointers so much that I didn't even thought about it. The flush_frontbuffer interface will have to be rethought soon though, because it is not versatile enough for the WGL state tracker. Basically the WGL co-statetracker needs to intercept these calls so that the gl_framebuffer gets resized at the right timings. This means that the WGL needs to provide a callback whenever that flush_frontbuffer needs to happen, instead of having the Mesa state tracker calling pipe_screen::flush_frontbuffer directly. I hope to workout the details and provide a patch for this for review one of these days. Jose ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
