Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[José F. <jfo...@vm...>]

On Thu, 2010-03-11 at 21:12 -0800, Chia-I Wu wrote:
> On Fri, Mar 12, 2010 at 12:20 PM, Jakob Bornecrantz
> <wal...@gm...> wrote:
> > On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu <ol...@gm...> wrote:
> >> On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu <ol...@gm...> wrote:
> >>> This patch series adds st_api interface to st/mesa and st/vega, and
> >>> switch st/egl and st/glx from st_public interface to the new interface.
> >> I've pushed most of the this patch series to gallium-st-api.  I'd like to have
> >> this topic branch focus on the switch of st/egl and st/glx to use st_api.
> >> Further works, such as the switch of st/dri, EGLImage extensions will happen
> >> directly in master or some other topic branches, whichever suits better.
> >>
> >> The implementations of the new interfaces (st_api, st_framebuffer_iface) are
> >> isolated in new files in each state tracker.  The isolation makes it easier to
> >> locate the changes.  But more importantly, unlike the rest of a state tracker,
> >> the interfaces might be called from different threads.  I used whatever
> >> existing mechanisms available to protect those callbacks, but when there is no
> >> such mechanism, I ignored the issue mostly.
> >>
> >> I have one open question so far.  With st_api, co state trackers no longer have
> >> access to pipe_contexts.  The pipe_contexts are usually used to implement
> >>
> >> * glXCopySubBufferMESA: copy a region of the back buffer to the front
> >> * eglCopyBuffers: copy the render buffer of a surface to a pixmap
> >> * SwapBuffers and FlushFront in DRI1
> >>
> >> The copying is a framebuffer operation and it does not make sense to steal a
> >> random API context for the copying.  Remember that the co state trackers always
> >> own the pipe_textures of a drawable in st_api.  One way to solve the problem is
> >> to let the co state trackers own pipe_contexts of their own. A co state tracker
> >> may create its pipe_context (and probably a blitter context) on demand when
> >> glXCopySubBufferMESA or eglCopyBuffers is called and do the copying directly.
> >>
> >> But as all the 3 cases need to do a pipe_screen::flush_frontbuffer after the
> >> copying, a better approach might be to rename and enhance
> >> pipe_screen::flush_frontbuffer to support them directly, or a mix of both
> >> approaches.
> > Hmm maybe flush_frontbuffer should be made into a context function, or
> > take a pipe_context. But that would probably require
> > st_framebuffer_iface::flush_front to take a st_context as well. Not
> > that I have anything against that.
> > For eglCopyBuffers the manager probably need a pipe_context for
> > itself. If you don't want to randomly steal one that is currently
> > bound, even then it is not guarantied to be any context created, so as
> > a fallback you will probably always have a context around.
> I am thinking change pipe_screen::flush_frontbuffer to
> 
>   void
>   pipe_screen::display_texture(struct pipe_screen *,
>                                struct pipe_texture *,
>                                void *winsys_drawable_handle,
>                                unsigned x, unsigned y,
>                                unsigned width, unsigned height);
> 
> The pipe_texture must be created with DISPLAY_TARGET or SCANOUT.  The type of
> the opaque drawable handle is pipe_screen specific and is known to the co state
> tracker, or whoever, created the pipe_screen.

I'd support this. This is pretty much what I'd need for WGL too.

Regarding being pipe_screen vs pipe_context I don't have a strong
opinion about this, but I believe making it a context operation is
adequate. 

Presents are translated either to a series of blits or a fullscreen
flip. Certain hardware deos not have dedicate blit engines, so having a
context for doing the blits via 3d is very handy.

On Windows XP presents don't require context. On Vista and later
presents already require a rendering context (I typically use the last
one that rendered to a surface).

Furthermore, now it is very easy for any state tracker entity to create
a dummy context for if needed, via pipe_screen::context_create().

Jose