Module: Mesa Branch: gallium-sw-api Commit: 453dbedd61d143dd81b02479fb3e9778e1bace4d URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=453dbedd61d143dd81b02479fb3e9778e1bace4d
Author: Jakob Bornecrantz <wallbra...@gmail.com> Date: Mon Feb 15 02:09:35 2010 +0000 gallium: More comments about the drm api vs software rasterizers --- src/gallium/include/state_tracker/xm_winsys.h | 24 ++++++++++++++++++------ 1 files changed, 18 insertions(+), 6 deletions(-) diff --git a/src/gallium/include/state_tracker/xm_winsys.h b/src/gallium/include/state_tracker/xm_winsys.h index 5e2b5ee..07e0447 100644 --- a/src/gallium/include/state_tracker/xm_winsys.h +++ b/src/gallium/include/state_tracker/xm_winsys.h @@ -34,19 +34,31 @@ struct pipe_screen; struct pipe_surface; -/* One unusual thing about the way the dri2 driver api works is that - * textures for scanout are not created through the normal - * pipe_screen::create_texture() method, but rather by converting - * existing DRM buffer handles into pipe_textures by a backdoor in the - * driver, exposed through the winsys and drm_api callbacks. +/* The drm driver stack have two different users st/dri and st/xorg. * + * st/xorg produces both scanouts (primary) and shared (displaytarget) + * textures via the normal pipe_screen::create_texture() callback, + * this follows how the lp_winsys works. However the lp_winsys + * does not deal with the difference between scanouts and displaytargets + * something that needs to be added. st/xorg then uses the drm_api to + * access the handles to textures. + * + * st/dri creates texture via the drm api. + * + * + * With all of the above requirements the drm API needs to be aware that + * a software rasterizer has been layered ontop of it. However this code + * can be completely generic and reused for all drm winsys. + */ + +/* * In the software drivers, we would also like the co-state tracker to * be involved in creating the backing for scanout textures. This * allows the knowledge of eg. XShm to be collapsed down to a single * location, and permits a null or at least tiny software rasterizer * winsys. * - * The main question is whether to follow the approach of the DRI2 + * The main question is whether to follow the approach of the st/dri * state tracker and ask the driver to turn some pre-existing storage * into a texture, or to stay closer to the lp_winsys approach and * have the provide the driver with a set of callbacks allowing it to _______________________________________________ mesa-commit mailing list mesa-commit@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-commit
