On Mon, 2010-02-15 at 01:46 -0800, Keith Whitwell wrote: > On Mon, Feb 15, 2010 at 2:11 AM, Jakob Bornecrantz > <wallbra...@kemper.freedesktop.org> wrote: > > Module: Mesa > > Branch: gallium-sw-api > > Commit: 6ad834b39d6c2ae9ead2e2b00908ad2fa6914897 > > URL: > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=6ad834b39d6c2ae9ead2e2b00908ad2fa6914897 > > > > Author: Jakob Bornecrantz <wallbra...@gmail.com> > > Date: Mon Feb 15 01:52:29 2010 +0000 > > > > drm/sw: Wip drm winsys > > > > This winsys wraps a drm_api in order abstract away the different > > memory manager. It also needs help from a pipe screen wrapper. > > That wrapper is included in the same file but could be moved out > > into a generic file. > > > > --- > > > > src/gallium/include/state_tracker/xm_winsys.h | 8 + > > src/gallium/winsys/drm/sw/Makefile | 13 ++ > > src/gallium/winsys/drm/sw/sw_drm_api.c | 287 > > +++++++++++++++++++++++++ > > 3 files changed, 308 insertions(+), 0 deletions(-) > > > > diff --git a/src/gallium/include/state_tracker/xm_winsys.h > > b/src/gallium/include/state_tracker/xm_winsys.h > > index c928be0..5e2b5ee 100644 > > --- a/src/gallium/include/state_tracker/xm_winsys.h > > +++ b/src/gallium/include/state_tracker/xm_winsys.h > > @@ -131,6 +131,14 @@ struct sw_driver { > > struct pipe_screen *(*create_screen)( struct sw_driver *driver, > > struct sw_callbacks *callbacks ); > > > > + struct pipe_texture *(*wrap_displaytarget)( struct sw_driver *driver, > > + struct pipe_screen *screen, > > + struct pipe_texture *templ, > > + struct sw_displaytarget *dt > > ); > > + > > + struct sw_displaytarget *(*get_displaytarget)( struct sw_driver *driver, > > + struct pipe_texture *tex > > ); > > + > > /* No call to wrap a display target and create a texture. Hope > > * that the callback mechanism is sufficient for now. > > */ > > Hmm, so much for the comment... > > I'd prefer *not* to have this interface express both techniques for > associating a displaytarget and a texture in this interface. I know > that the dri2 state tracker takes this backdoor "wrapping" approach, > but I'm not at all convinced it's the right way to do things. > > The fact that xorg and dri2 are using different approaches to achieve > similar goals is also pretty concerning. I'd rather see that cleaned > up and unified than push the same choices into software drivers. > Whether it's the backdoor approach or screen::create_texture() (or > similar), there should be a single flow of control and a clear > layering that is the same everywhere. > > Thinking about it now, my preference would be to add something to the > screen like: > > struct pipe_texture *open_shared_texture( struct pipe_screen > *screen, struct pipe_texture *template, void *winsys_handle ) > > and hide the local vs shared handle business inside the void * somehow > so that bit of dri2/gem/kms mismatch doesn't contaminate the 3d stack.
I entirely agree with Keith. Inter-process resource sharing is a problem common to all modern graphics APIs, therefore it should be suitably abstracted so that differences become mere implementation details, instead of having all these ad-hoc interfaces. Jose ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
