[PATCH] Make DRI/DRM state tracker interface less context-dependent

[Younes Manton]

Hi Thomas,

I'd like to make these changes to make it possible to use the DRM
state tracker interface with contexts other than pipe_context. Nouveau
is the only public driver that does DRI1 from what I can see, but I've
been told that there are some closed drivers that also depend on these
interfaces and that you look after them.

Added drm_api::create_video_context() to get a pipe_video_context, you
can ignore it. Changes to the st_* lock functions are trivial and
obvious, Nouveau doesn't use them but presumably anyone who does can
return pipe_context->priv just as easily. Changes to
dri1_api::front_srf_locked() are too, hopefully your front buffer can
be accessed via pipe_screen as well. I didn't change
dri1_api::present_locked() because we don't do page flipping yet, but
I think that could be done with just a screen as well in Nouveau.
Thoughts?

---

diff --git a/src/gallium/drivers/nouveau/nouveau_winsys.h
b/src/gallium/drivers/nouveau/nouveau_winsys.h
index 42c77e5..600a86c 100644
--- a/src/gallium/drivers/nouveau/nouveau_winsys.h
+++ b/src/gallium/drivers/nouveau/nouveau_winsys.h
@@ -53,6 +53,12 @@ nv40_screen_create(struct pipe_winsys *ws, struct
nouveau_device *);
 extern struct pipe_context *
 nv40_create(struct pipe_screen *, unsigned pctx_id);

+extern struct pipe_video_context *
+nv40_video_create(struct pipe_context *pipe, enum pipe_video_profile profile,
+                  enum pipe_video_chroma_format chroma_format,
+                  unsigned width, unsigned height,
+                  unsigned pvctx_id);
+
 extern struct pipe_screen *
 nv50_screen_create(struct pipe_winsys *ws, struct nouveau_device *);

diff --git a/src/gallium/include/state_tracker/dri1_api.h
b/src/gallium/include/state_tracker/dri1_api.h
index b173ba3..603f5d8 100644
--- a/src/gallium/include/state_tracker/dri1_api.h
+++ b/src/gallium/include/state_tracker/dri1_api.h
@@ -29,11 +29,11 @@ struct dri1_api_version

 struct dri1_api_lock_funcs
 {
-   void (*lock) (struct pipe_context * pipe);
-   void (*unlock) (struct pipe_context * locked_pipe);
-      boolean(*is_locked) (struct pipe_context * locked_pipe);
-      boolean(*is_lock_lost) (struct pipe_context * locked_pipe);
-   void (*clear_lost_lock) (struct pipe_context * locked_pipe);
+   void (*lock) (void *pipe_priv);
+   void (*unlock) (void *locked_pipe_priv);
+      boolean(*is_locked) (void *locked_pipe_priv);
+      boolean(*is_lock_lost) (void *locked_pipe_priv);
+   void (*clear_lost_lock) (void *locked_pipe_priv);
 };

 struct dri1_api
@@ -46,7 +46,7 @@ struct dri1_api

    /*@{ */

-   struct pipe_surface *(*front_srf_locked) (struct pipe_context *
+   struct pipe_surface *(*front_srf_locked) (struct pipe_screen *
      locked_pipe);

    void (*present_locked) (struct pipe_context * locked_pipe,
diff --git a/src/gallium/include/state_tracker/drm_api.h
b/src/gallium/include/state_tracker/drm_api.h
index 4d1259e..ea0b91c 100644
--- a/src/gallium/include/state_tracker/drm_api.h
+++ b/src/gallium/include/state_tracker/drm_api.h
@@ -8,6 +8,7 @@ struct pipe_screen;
 struct pipe_winsys;
 struct pipe_buffer;
 struct pipe_context;
+struct pipe_video_context;
 struct pipe_texture;

 enum drm_create_screen_mode {
@@ -36,6 +37,11 @@ struct drm_api
                                       struct drm_create_screen_arg *arg);
  struct pipe_context* (*create_context)(struct drm_api *api,
                                        struct pipe_screen *screen);
+        struct pipe_video_context* (*create_video_context)(struct drm_api *api,
+                                                           struct
pipe_screen *screen,
+                                                           enum
pipe_video_profile profile,
+                                                           enum
pipe_video_chroma_format chroma_format,
+                                                           unsigned
width, unsigned height);
  /*@}*/

  /**
diff --git a/src/gallium/state_trackers/dri/dri_context.c
b/src/gallium/state_trackers/dri/dri_context.c
index 8819936..3ddff30 100644
--- a/src/gallium/state_trackers/dri/dri_context.c
+++ b/src/gallium/state_trackers/dri/dri_context.c
@@ -175,33 +175,33 @@ dri_make_current(__DRIcontextPrivate * cPriv,
 }

 static void
-st_dri_lock(struct pipe_context *pipe)
+st_dri_lock(void *pipe_priv)
 {
-   dri_lock((struct dri_context *)pipe->priv);
+   dri_lock((struct dri_context *)pipe_priv);
 }

 static void
-st_dri_unlock(struct pipe_context *pipe)
+st_dri_unlock(void *pipe_priv)
 {
-   dri_unlock((struct dri_context *)pipe->priv);
+   dri_unlock((struct dri_context *)pipe_priv);
 }

 static boolean
-st_dri_is_locked(struct pipe_context *pipe)
+st_dri_is_locked(void *pipe_priv)
 {
-   return ((struct dri_context *)pipe->priv)->isLocked;
+   return ((struct dri_context *)pipe_priv)->isLocked;
 }

 static boolean
-st_dri_lost_lock(struct pipe_context *pipe)
+st_dri_lost_lock(void *pipe_priv)
 {
-   return ((struct dri_context *)pipe->priv)->wsLostLock;
+   return ((struct dri_context *)pipe_priv)->wsLostLock;
 }

 static void
-st_dri_clear_lost_lock(struct pipe_context *pipe)
+st_dri_clear_lost_lock(void *pipe_priv)
 {
-   ((struct dri_context *)pipe->priv)->wsLostLock = FALSE;
+   ((struct dri_context *)pipe_priv)->wsLostLock = FALSE;
 }

 struct dri1_api_lock_funcs dri1_lf = {
diff --git a/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
b/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
index f512c0e..97e7426 100644
--- a/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
+++ b/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.c
@@ -46,9 +46,9 @@ dri_surface_from_handle(struct drm_api *api, struct
pipe_screen *pscreen,
 }

 static struct pipe_surface *
-nouveau_dri1_front_surface(struct pipe_context *pipe)
+nouveau_dri1_front_surface(struct pipe_screen *screen)
 {
- return nouveau_winsys_screen(pipe->screen)->front;
+ return nouveau_winsys_screen(screen)->front;
 }

 static struct dri1_api nouveau_dri1_api = {
@@ -191,6 +191,54 @@ nouveau_drm_create_context(struct drm_api *api,
struct pipe_screen *pscreen)
  return nvws->pctx[i];
 }

+typedef struct pipe_video_context* (*nouveau_video_create)(struct
pipe_context *pipe,
+                                                           enum
pipe_video_profile profile,
+                                                           enum
pipe_video_chroma_format chroma_format,
+                                                           unsigned
width, unsigned height,
+                                                           unsigned pvctx);
+
+static struct pipe_video_context *
+nouveau_drm_create_video_context(struct drm_api *api, struct
pipe_screen *pscreen,
+                                 enum pipe_video_profile profile,
+                                 enum pipe_video_chroma_format chroma_format,
+                                 unsigned width, unsigned height)
+{
+ struct nouveau_winsys *nvws = nouveau_winsys_screen(pscreen);
+        nouveau_video_create init;
+ unsigned chipset = nouveau_screen(pscreen)->device->chipset;
+        struct pipe_context *pipe;
+ int i;
+
+ switch (chipset & 0xf0) {
+ case 0x40:
+ case 0x60:
+ init = nv40_video_create;
+ break;
+ default:
+ debug_printf("%s: unknown chipset nv%02x\n", __func__, chipset);
+ return NULL;
+ }
+
+ /* Find a free slot for a pipe video context, allocate a new one if needed */
+ for (i = 0; i < nvws->nr_pvctx; i++) {
+ if (nvws->pvctx[i] == NULL)
+ break;
+ }
+
+ if (i == nvws->nr_pvctx) {
+ nvws->nr_pvctx++;
+ nvws->pvctx = realloc(nvws->pvctx,
+      sizeof(*nvws->pvctx) * nvws->nr_pvctx);
+ }
+
+        pipe = nouveau_drm_create_context(api, pscreen);
+        if (!pipe)
+           return NULL;
+
+ nvws->pvctx[i] = init(pipe, profile, chroma_format, width, height, i);
+ return nvws->pvctx[i];
+}
+
 static struct pipe_texture *
 nouveau_drm_pt_from_name(struct drm_api *api, struct pipe_screen *pscreen,
  struct pipe_texture *templ, const char *name,
@@ -255,6 +303,7 @@ nouveau_drm_handle_from_pt(struct drm_api *api,
struct pipe_screen *pscreen,
 struct drm_api drm_api_hooks = {
  .create_screen = nouveau_drm_create_screen,
  .create_context = nouveau_drm_create_context,
+        .create_video_context = nouveau_drm_create_video_context,
  .texture_from_shared_handle = nouveau_drm_pt_from_name,
  .shared_handle_from_texture = nouveau_drm_name_from_pt,
  .local_handle_from_texture = nouveau_drm_handle_from_pt,
diff --git a/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.h
b/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.h
index e61e0e0..fa4e821 100644
--- a/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.h
+++ b/src/gallium/winsys/drm/nouveau/drm/nouveau_drm_api.h
@@ -15,6 +15,8 @@ struct nouveau_winsys {

  unsigned nr_pctx;
  struct pipe_context **pctx;
+        unsigned nr_pvctx;
+        struct pipe_video_context **pvctx;

  struct pipe_surface *front;
 };

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Zack Rusin-2]

On Saturday 24 October 2009 19:02:51 Younes Manton wrote:

> Hi Thomas,
>
> I'd like to make these changes to make it possible to use the DRM
> state tracker interface with contexts other than pipe_context. Nouveau
> is the only public driver that does DRI1 from what I can see, but I've
> been told that there are some closed drivers that also depend on these
> interfaces and that you look after them.
>
> Added drm_api::create_video_context() to get a pipe_video_context, you
> can ignore it. Changes to the st_* lock functions are trivial and
> obvious, Nouveau doesn't use them but presumably anyone who does can
> return pipe_context->priv just as easily. Changes to
> dri1_api::front_srf_locked() are too, hopefully your front buffer can
> be accessed via pipe_screen as well. I didn't change
> dri1_api::present_locked() because we don't do page flipping yet, but
> I think that could be done with just a screen as well in Nouveau.
> Thoughts?

Younes,

sorry for the slow response, we've been a bit busy lately.
I can't say that I'm a huge fan of this patch. I've been thinking about it
lately and essentially I'd like to reiterate what I said initially about the
pipe_video_context. While I think it's a great idea, I'm not too excited about
the way it looks right now. It boils down to three problems for me:

1) The interface itself. In particular:

void (*clear_surface)(struct pipe_video_context *vpipe,
                         unsigned x, unsigned y,
                         unsigned width, unsigned height,
                         unsigned value,
                         struct pipe_surface *surface);
is problematic for two reasons: a) because it's something that looks more like
a pipe_context method in itself, b) because it's a combination of a
surface_fill and clear interface which we moved away from in master

void (*render_picture)(struct pipe_video_context     *vpipe,
                          /*struct pipe_surface         *backround,
                          struct pipe_video_rect        *backround_area,*/
                          struct pipe_video_surface     *src_surface,
                          enum pipe_mpeg12_picture_type picture_type,
                          /*unsigned                    num_past_surfaces,
                          struct pipe_video_surface     *past_surfaces,
                          unsigned                      num_future_surfaces,
                          struct pipe_video_surface     *future_surfaces,*/
                          struct pipe_video_rect        *src_area,
                          struct pipe_surface           *dst_surface,
                          struct pipe_video_rect        *dst_area,
                          /*unsigned                      num_layers,
                          struct pipe_texture           *layers,
                          struct pipe_video_rect        *layer_src_areas,
                          struct pipe_video_rect        *layer_dst_areas,*/
                          struct pipe_fence_handle      **fence);

has simply way too many arguments, not to mention that over a half is
commented out. It's really a common problem for the entire interface, methods
are very complex. Gallium deals with it with settable state. Which  brings us
to another problem with the interface:

struct pipe_video_context
{
   struct pipe_screen *screen;
   enum pipe_video_profile profile;
   enum pipe_video_chroma_format chroma_format;
   unsigned width;
   unsigned height;
        ... methods follow...

which means that the interface is both an interface and a state.
All of it is very un-gallium like.

2) We really need a real world video api implemented with the interface before
making it public. So it should be proven that openmax or vdpau can actually be
implemented using the interface before making it public.

3) There's no hardware implementation for the interface and as far as i can
see there's no plans for one. It's really what the interfaces are for, until
we have people actually working on a hardware implementation there's no reason
for this to be a Gallium interface at all.

That's why i think the whole code should be an auxiliary module in which case
patches like this one wouldn't be even necessary.

When it comes to interfaces it's a lot harder to remove/significantly change an
interface than to add a new one, so we should be extremely careful when adding
interfaces and at least try to make sure that for all #1, #2 and #3 are
fixable.

Also it's worth noting that Keith is the maintainer for Gallium interfaces, so
pipe_video_context and, in general, all changes to Gallium should always go
through him.

z

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[José Fonseca-2]

On Tue, 2009-10-27 at 12:11 -0700, Zack Rusin wrote:

> On Saturday 24 October 2009 19:02:51 Younes Manton wrote:
> > Hi Thomas,
> >
> > I'd like to make these changes to make it possible to use the DRM
> > state tracker interface with contexts other than pipe_context. Nouveau
> > is the only public driver that does DRI1 from what I can see, but I've
> > been told that there are some closed drivers that also depend on these
> > interfaces and that you look after them.
> >
> > Added drm_api::create_video_context() to get a pipe_video_context, you
> > can ignore it. Changes to the st_* lock functions are trivial and
> > obvious, Nouveau doesn't use them but presumably anyone who does can
> > return pipe_context->priv just as easily. Changes to
> > dri1_api::front_srf_locked() are too, hopefully your front buffer can
> > be accessed via pipe_screen as well. I didn't change
> > dri1_api::present_locked() because we don't do page flipping yet, but
> > I think that could be done with just a screen as well in Nouveau.
> > Thoughts?
>
> Younes,
>
> sorry for the slow response, we've been a bit busy lately.
> I can't say that I'm a huge fan of this patch. I've been thinking about it
> lately and essentially I'd like to reiterate what I said initially about the
> pipe_video_context. While I think it's a great idea, I'm not too excited about
> the way it looks right now. It boils down to three problems for me:
>
> 1) The interface itself. In particular:
>
> void (*clear_surface)(struct pipe_video_context *vpipe,
>                          unsigned x, unsigned y,
>                          unsigned width, unsigned height,
>                          unsigned value,
>                          struct pipe_surface *surface);
> is problematic for two reasons: a) because it's something that looks more like
> a pipe_context method in itself, b) because it's a combination of a
> surface_fill and clear interface which we moved away from in master
>
> void (*render_picture)(struct pipe_video_context     *vpipe,
>                           /*struct pipe_surface         *backround,
>                           struct pipe_video_rect        *backround_area,*/
>                           struct pipe_video_surface     *src_surface,
>                           enum pipe_mpeg12_picture_type picture_type,
>                           /*unsigned                    num_past_surfaces,
>                           struct pipe_video_surface     *past_surfaces,
>                           unsigned                      num_future_surfaces,
>                           struct pipe_video_surface     *future_surfaces,*/
>                           struct pipe_video_rect        *src_area,
>                           struct pipe_surface           *dst_surface,
>                           struct pipe_video_rect        *dst_area,
>                           /*unsigned                      num_layers,
>                           struct pipe_texture           *layers,
>                           struct pipe_video_rect        *layer_src_areas,
>                           struct pipe_video_rect        *layer_dst_areas,*/
>                           struct pipe_fence_handle      **fence);
>
> has simply way too many arguments, not to mention that over a half is
> commented out. It's really a common problem for the entire interface, methods
> are very complex. Gallium deals with it with settable state. Which  brings us
> to another problem with the interface:
>
> struct pipe_video_context
> {
>    struct pipe_screen *screen;
>    enum pipe_video_profile profile;
>    enum pipe_video_chroma_format chroma_format;
>    unsigned width;
>    unsigned height;
>         ... methods follow...
>
> which means that the interface is both an interface and a state.
> All of it is very un-gallium like.
>
> 2) We really need a real world video api implemented with the interface before
> making it public. So it should be proven that openmax or vdpau can actually be
> implemented using the interface before making it public.
>
> 3) There's no hardware implementation for the interface and as far as i can
> see there's no plans for one. It's really what the interfaces are for, until
> we have people actually working on a hardware implementation there's no reason
> for this to be a Gallium interface at all.
>
> That's why i think the whole code should be an auxiliary module in which case
> patches like this one wouldn't be even necessary.
>
> When it comes to interfaces it's a lot harder to remove/significantly change an
> interface than to add a new one, so we should be extremely careful when adding
> interfaces and at least try to make sure that for all #1, #2 and #3 are
> fixable.

Yes. Younes, I really think it is better to crystallize this in a
separate branch until it reaches a point where the interfaces are
crystallized. The master branch is not always perfect, but it should
always near a state were a release can be made, and it seems that the
video interfaces need to mature a little more before that.

Jose


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Younes Manton]

On Tue, Oct 27, 2009 at 3:11 PM, Zack Rusin <zackr@...> wrote:

> Younes,
>
> sorry for the slow response, we've been a bit busy lately.
> I can't say that I'm a huge fan of this patch. I've been thinking about it
> lately and essentially I'd like to reiterate what I said initially about the
> pipe_video_context. While I think it's a great idea, I'm not too excited about
> the way it looks right now. It boils down to three problems for me:
>
> 1) The interface itself. In particular:
>
> void (*clear_surface)(struct pipe_video_context *vpipe,
>                         unsigned x, unsigned y,
>                         unsigned width, unsigned height,
>                         unsigned value,
>                         struct pipe_surface *surface);
> is problematic for two reasons: a) because it's something that looks more like
> a pipe_context method in itself, b) because it's a combination of a
> surface_fill and clear interface which we moved away from in master

Thanks for the comments. I've changed this slightly in my tree to be
::surface_fill() and ::surface_copy() just as in pipe_context. The way
I see it in a video API implementation the client won't have a
pipe_context, so pipe_video_context has to provide these methods so
you can 1) initialize video surfaces (to black, in cases where the
video doesn't actually fill the entire frame) and 2) to copy the
surfaces to the front buffer. Unlike pipe_context these must be
provided because I don't expect surfaces that can't be rendered to to
exist in this context, the only surfaces that should exist are color
buffers. If someone wants/needs to implement these with their
pipe_context then they can, but if their video HW can handle it then
there's no need to initialize a pipe_context at all.

> void (*render_picture)(struct pipe_video_context     *vpipe,
>                          /*struct pipe_surface         *backround,
>                          struct pipe_video_rect        *backround_area,*/
>                          struct pipe_video_surface     *src_surface,
>                          enum pipe_mpeg12_picture_type picture_type,
>                          /*unsigned                    num_past_surfaces,
>                          struct pipe_video_surface     *past_surfaces,
>                          unsigned                      num_future_surfaces,
>                          struct pipe_video_surface     *future_surfaces,*/
>                          struct pipe_video_rect        *src_area,
>                          struct pipe_surface           *dst_surface,
>                          struct pipe_video_rect        *dst_area,
>                          /*unsigned                      num_layers,
>                          struct pipe_texture           *layers,
>                          struct pipe_video_rect        *layer_src_areas,
>                          struct pipe_video_rect        *layer_dst_areas,*/
>                          struct pipe_fence_handle      **fence);
>
> has simply way too many arguments, not to mention that over a half is
> commented out. It's really a common problem for the entire interface, methods
> are very complex.

Well, because they're commented out we haven't really committed to
anything yet, I just had it in there as a reminder of what needs to be
supported for VDPAU (if you remove the comments this function maps
one-to-one with the VDPAU function that does the same thing). I can
implement it as settable states when the time comes if that's what
people prefer.

Gallium deals with it with settable state. Which  brings us

> to another problem with the interface:
>
> struct pipe_video_context
> {
>   struct pipe_screen *screen;
>   enum pipe_video_profile profile;
>   enum pipe_video_chroma_format chroma_format;
>   unsigned width;
>   unsigned height;
>        ... methods follow...
>
> which means that the interface is both an interface and a state.
> All of it is very un-gallium like.

However this isn't mutable state, they're effectively constants; once
you create a pipe_video_context with a set of parameters you get a
context that can only handle what you specified and everything else
fails, so they're there so it can easily be determined what this video
context handles. They could be behind getter functions if that's what
people prefer, but I'm the only one who uses this stuff so I apologize
if my personal habits sometimes sneak in...

> 2) We really need a real world video api implemented with the interface before
> making it public. So it should be proven that openmax or vdpau can actually be
> implemented using the interface before making it public.

Fair enough.

> 3) There's no hardware implementation for the interface and as far as i can
> see there's no plans for one. It's really what the interfaces are for, until
> we have people actually working on a hardware implementation there's no reason
> for this to be a Gallium interface at all.
>
> That's why i think the whole code should be an auxiliary module in which case
> patches like this one wouldn't be even necessary.

Well, I think the interface has to come before the implementation.
Another Nouveau contributor has some NV40 HW decoder code that's been
sitting around for a while.

Anyway, a state tracker was how it was implemented before
pipe_video_context; VDPAU and HW implementations are what prompted me
to find another way to do it because writing any more code as an
auxiliary module would just add to the pile of code that would later
have to be ported. At the time Keith even gave me some suggestions to
that end so you'll have to excuse me for going in this direction, I
didn't really hear any objections at the time.

> When it comes to interfaces it's a lot harder to remove/significantly change an
> interface than to add a new one, so we should be extremely careful when adding
> interfaces and at least try to make sure that for all #1, #2 and #3 are
> fixable.

Fair enough, I'm all ears when it comes to suggestions but aside from
Cooper on r300g there aren't many others who touch/are affected by
this so I don't get a lot of feedback except when I have to break
things.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Younes Manton]

On Tue, Oct 27, 2009 at 3:33 PM, José Fonseca <jfonseca@...> wrote:
> Yes. Younes, I really think it is better to crystallize this in a
> separate branch until it reaches a point where the interfaces are
> crystallized. The master branch is not always perfect, but it should
> always near a state were a release can be made, and it seems that the
> video interfaces need to mature a little more before that.
>
> Jose

That's probably the best solution for everybody. I'll copy a video
branch off master, remove the video stuff from master, and continue on
in the video branch. Thanks.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Younes Manton]

I'd just like to add that if other interfaces will exist in the future
(I recall pipe_2d_context being floated at one time) and state
trackers want to use them without initializing a pipe_context
needlessly and want to reuse the rest of the DRM winsys then the
relevent parts of this patch (or comparable changes) will need to be
considered sooner or later regardless of whether or not
pipe_video_context exists.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[José Fonseca-2]

On Tue, 2009-10-27 at 14:45 -0700, Younes Manton wrote:
> I'd just like to add that if other interfaces will exist in the future
> (I recall pipe_2d_context being floated at one time) and state
> trackers want to use them without initializing a pipe_context
> needlessly and want to reuse the rest of the DRM winsys then the
> relevent parts of this patch (or comparable changes) will need to be
> considered sooner or later regardless of whether or not
> pipe_video_context exists.

Indeed.

And it is not only the problem of the pipe_*_context creation. There is
the problem of the state tracker still reaching out parts of the winsys.

I really think that a simple driver with a generic interface query as I
proposed in

http://www.mail-archive.com/mesa3d-dev@.../msg07818.html

is the best, and we sorely need it, with the recent and welcomed
increase of pipe drivers and state trackers.

I'll try to prototype this on a few state trackers and see how it goes.

Jose


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Keith Whitwell-3]

On Wed, 2009-10-28 at 05:21 -0700, José Fonseca wrote:

> On Tue, 2009-10-27 at 14:45 -0700, Younes Manton wrote:
> > I'd just like to add that if other interfaces will exist in the future
> > (I recall pipe_2d_context being floated at one time) and state
> > trackers want to use them without initializing a pipe_context
> > needlessly and want to reuse the rest of the DRM winsys then the
> > relevent parts of this patch (or comparable changes) will need to be
> > considered sooner or later regardless of whether or not
> > pipe_video_context exists.
>
> Indeed.
>
> And it is not only the problem of the pipe_*_context creation. There is
> the problem of the state tracker still reaching out parts of the winsys.
>
> I really think that a simple driver with a generic interface query as I
> proposed in
>
> http://www.mail-archive.com/mesa3d-dev@.../msg07818.html
>
> is the best, and we sorely need it, with the recent and welcomed
> increase of pipe drivers and state trackers.
>
> I'll try to prototype this on a few state trackers and see how it goes.
>
> Jose

It's an interesting topic how to broaden the set of interfaces that we
manage in Gallium, and there's a real opportunity to create a nice
solution.

My personal interest would be to see Gallium grow an ability to build a
complete driver (possibly at runtime) out of a set of registered
components, each of which implements one or more named interfaces, and
in turn depends on a set of named interfaces.

Once you do that, we end up with a lot of flexibility about how to
incorporate new interfaces over time, and add the ability to keep older
versions alive, provide compatibility shims, and so forth.  It also
provides a universal mechanism for injecting tracing shims, etc.


Keith


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Keith Whitwell-3]

On Wed, 2009-10-28 at 05:21 -0700, José Fonseca wrote:

> On Tue, 2009-10-27 at 14:45 -0700, Younes Manton wrote:
> > I'd just like to add that if other interfaces will exist in the future
> > (I recall pipe_2d_context being floated at one time) and state
> > trackers want to use them without initializing a pipe_context
> > needlessly and want to reuse the rest of the DRM winsys then the
> > relevent parts of this patch (or comparable changes) will need to be
> > considered sooner or later regardless of whether or not
> > pipe_video_context exists.
>
> Indeed.
>
> And it is not only the problem of the pipe_*_context creation. There is
> the problem of the state tracker still reaching out parts of the winsys.
>
> I really think that a simple driver with a generic interface query as I
> proposed in
>
> http://www.mail-archive.com/mesa3d-dev@.../msg07818.html
>
> is the best, and we sorely need it, with the recent and welcomed
> increase of pipe drivers and state trackers.
>
> I'll try to prototype this on a few state trackers and see how it goes.

In the meantime though, I think we're getting to a point where there's
enough riding on the interfaces in gallium/include/pipe that we want to
start being a bit more rigorous about updates to that directory.

We're already often using feature branches for larger changes and
reviews for important patches.   Let's formalize that for changes that
touch the Gallium interfaces in include/pipe.

Additionally, I'm going to play the maintainer card at this point and
ask that changes to the include/pipe directory on the master branch go
through me, after review on Mesa-dev.  

Development on the rest of the tree I'm OK with as it stands, but I
think we need a coherent process to guide the direction of interface
change and growth.

For my own part, I'll make sure that my personal changes to
gallium/include follow the same process as above, and are properly
reviewed on the list before pushing.

Keith




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev