On Fri, Mar 12, 2010 at 12:20 PM, Jakob Bornecrantz
<wallbra...@gmail.com> wrote:
> On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu <olva...@gmail.com> wrote:
>> On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu <olva...@gmail.com> 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.
This solves the problem with glXCopySubBufferMESA and eglCopyBuffers. What
remain to be done for the DRI1 case is to define the DRI1 displaytarget and
switch st/dri to use it.
Down to the lowest level, DRI1 displaytarget still faces the problem of
displaying a pipe_texture, given struct dri1_api. In the case
dri1_api::front_srf_locked is supported, it still needs to copy the texture.
Therefore, a mixed approach seems be the best. With the change to
pipe_screen::flush_frontbuffer, glXCopySubBufferMESA and eglCopyBuffers do not
need a pipe_context. And a pipe_context will be created by st/dri when DRI1 is
used. This mixed approach requires less work. As DRI1 is phasing out, I think
it is a sensible approach.
This is just some ideas. The switch of st/dri can be delayed until
gallium-st-api is merged. But if you are interested, I also have a local
branch that switches st/dri to use st_api, but only the DRI2 part. It is
functioning, but the patch is a little bit dirty..
--
o...@lunarg.com
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
