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.
> +
> +static struct sw_displaytarget *
> +swpc_dt_create(struct sw_callbacks *swc,
> + enum pipe_format format,
> + unsigned width, unsigned height,
> + unsigned alignment,
> + unsigned *stride)
> +{
> + struct sw_pipe_callbacks *swpc = sw_pipe_callbacks(swc);
> + struct pipe_texture templ;
> + struct pipe_texture *tex;
> + memset(&templ, 0, sizeof(templ));
> +
> + templ->width0 = width;
> + templ->height0 = height;
> + templ->format = format;
> + /*
> + * XXX How do we tell the difference between displaytargets and primary
> (scanout)?
> + * Aslo should all be rendertargets?
> + * What about depthstencil?
> + * XXX we pretty much need get usage passed down, maybe even the template.
> + */
> + templ->usage = 0;
> + /* XXX alignment isn't needed for DRM platform */
> + /* XXX stride isn't needed for DRM platform */
> +
> + tex = swpc->screen->texture_create(swpc->screen, &templ);
> +
> + return sw_pipe_dt_wrap_texture(tex);
> +}
> +
This looks wrong. The software drivers will call this function from
inside texture_create, so you're setting up a recursive loop here.
The intent is that textures are implemented on top of displaytargets,
not the other way around. Look at llvmpipe for an example of this
already in use.
It really seems like there is confusion about how layering is supposed
to work here, and that the requirement in the dri2 state tracker to be
able to turn existing drm handles into textures is contributing to
this.
Keith
------------------------------------------------------------------------------
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
