mesa3d-dev

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

[Chia-I Wu <ol...@gm...>]

Hi all,

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.

Feature-wise, st_api provides a more robust multiple client APIs
(OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
various EGLImage extensions.  As st_api interface can coexist with
st_public interface, co state trackers should work as before unless they
are switched to use st_api.

The original plan to merge the work to master after the interface is
implemented by st/mesa and st/vega, and st/egl is converted to use it.
Further development and conversions of st/glx and st/dri will happen in
master.  While this is still the plan, the recent merge of
gallium-sw-api-2 motivates me to submit this WIP patch series for public
review.  I will cover only pipe_screen::update_buffer,
pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
here as the other parts were discussed a while ago.  But any feedback to
the design is appreciated.

To summarize, there is *no* change to pipe_screen::update_buffer and
pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
trackers are not affected, and the st_public path of st/mesa and st/vega
still work.  But when the st_api path is taken,
pipe_screen::update_buffer is no longer got called.  And the caller of
pipe_screen::flush_frontbuffer becomes co state trackers instead of
state trackers.

In st_api, the co state trackers are responsible for representing
windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
depth/stencil, ...) to the state trackers.  In DRI2, this is done
through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
DRI1?), this is done by having co state trackers allocate a set of
private pipe_textures.  In both cases, the pipe_textures are created as
needed.  That is, if the state trackers draw only to the back buffer,
the front buffer will not be creatd.

At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
st_framebuffer_iface.  The state trackers retrieve the pipe_textures of
a window/pixmap/pbuffer mentioned above through this interface.  Other
than retrieving the pipe_textures, to support front buffer rendering,
the state trackers should call st_framebuffer_iface::flush_front when it
has something to display.

The implementation of st_framebuffer_iface::flush_front again depends on
the window systems.  In X11 with DRI2, it is no-op if the front buffer
passed to the state trackers is real;  Otherwise, it calls
DRI2CopyRegion to copy the contents from the fake front buffer to the
real front one.

In X11 with software rasterizer, the co state tracker is responsible to
display its private pipe_texture to a X drawable.  With the merge of
gallium-sw-api-2, this is made really easy by calling
pipe_screen::flush_frontbuffer.

The last patch of the series converts st/glx to use st_api.  The diff is
cleaner than the diff to st/egl.  It is a quick conversion to help see
the design of st_api in work.  There should be bugs, but the simple
demos I tested all work.  The other patches are constrained to EGL and
any regression outside EGL is considered a bug.

If you read this long because of the mention of EGLImage in the subject,
you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
thank-you gift :)

-- 
ol...@Lu...

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

[Keith W. <ke...@vm...>]

On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
> Hi all,
> 
> 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.
> 
> Feature-wise, st_api provides a more robust multiple client APIs
> (OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
> various EGLImage extensions.  As st_api interface can coexist with
> st_public interface, co state trackers should work as before unless they
> are switched to use st_api.
> 
> The original plan to merge the work to master after the interface is
> implemented by st/mesa and st/vega, and st/egl is converted to use it.
> Further development and conversions of st/glx and st/dri will happen in
> master.  While this is still the plan, the recent merge of
> gallium-sw-api-2 motivates me to submit this WIP patch series for public
> review.  I will cover only pipe_screen::update_buffer,
> pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
> here as the other parts were discussed a while ago.  But any feedback to
> the design is appreciated.
> 
> To summarize, there is *no* change to pipe_screen::update_buffer and
> pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
> trackers are not affected, and the st_public path of st/mesa and st/vega
> still work.  But when the st_api path is taken,
> pipe_screen::update_buffer is no longer got called.  And the caller of
> pipe_screen::flush_frontbuffer becomes co state trackers instead of
> state trackers.
> 
> In st_api, the co state trackers are responsible for representing
> windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
> depth/stencil, ...) to the state trackers.  In DRI2, this is done
> through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
> DRI1?), this is done by having co state trackers allocate a set of
> private pipe_textures.  In both cases, the pipe_textures are created as
> needed.  That is, if the state trackers draw only to the back buffer,
> the front buffer will not be creatd.
> 
> At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
> st_framebuffer_iface.  The state trackers retrieve the pipe_textures of
> a window/pixmap/pbuffer mentioned above through this interface.  Other
> than retrieving the pipe_textures, to support front buffer rendering,
> the state trackers should call st_framebuffer_iface::flush_front when it
> has something to display.
> 
> The implementation of st_framebuffer_iface::flush_front again depends on
> the window systems.  In X11 with DRI2, it is no-op if the front buffer
> passed to the state trackers is real;  Otherwise, it calls
> DRI2CopyRegion to copy the contents from the fake front buffer to the
> real front one.
> 
> In X11 with software rasterizer, the co state tracker is responsible to
> display its private pipe_texture to a X drawable.  With the merge of
> gallium-sw-api-2, this is made really easy by calling
> pipe_screen::flush_frontbuffer.
> 
> The last patch of the series converts st/glx to use st_api.  The diff is
> cleaner than the diff to st/egl.  It is a quick conversion to help see
> the design of st_api in work.  There should be bugs, but the simple
> demos I tested all work.  The other patches are constrained to EGL and
> any regression outside EGL is considered a bug.
> 
> If you read this long because of the mention of EGLImage in the subject,
> you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
> thank-you gift :)
> 

Chia-I,

This is all looking good to me.  The code doesn't seem to introduce any
new layering issues or introduce dependencies on existing ones, which
helps with ongoing cleanups.

I did some quick testing with the "linux-debug" target.  Gears works,
with and without GALLIUM_WRAP=t.  However, demos/singlebuffer seems to
get caught in infinite recursion and segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
185     {
(gdb) bt
#0  0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
#1  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#2  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#3  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#4  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#5  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#6  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#7  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#8  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189


Keith

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

[Keith W. <ke...@vm...>]

On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
> On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
> > Hi all,
> > 
> > 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.
> > 
> > Feature-wise, st_api provides a more robust multiple client APIs
> > (OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
> > various EGLImage extensions.  As st_api interface can coexist with
> > st_public interface, co state trackers should work as before unless they
> > are switched to use st_api.
> > 
> > The original plan to merge the work to master after the interface is
> > implemented by st/mesa and st/vega, and st/egl is converted to use it.
> > Further development and conversions of st/glx and st/dri will happen in
> > master.  While this is still the plan, the recent merge of
> > gallium-sw-api-2 motivates me to submit this WIP patch series for public
> > review.  I will cover only pipe_screen::update_buffer,
> > pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
> > here as the other parts were discussed a while ago.  But any feedback to
> > the design is appreciated.
> > 
> > To summarize, there is *no* change to pipe_screen::update_buffer and
> > pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
> > trackers are not affected, and the st_public path of st/mesa and st/vega
> > still work.  But when the st_api path is taken,
> > pipe_screen::update_buffer is no longer got called.  And the caller of
> > pipe_screen::flush_frontbuffer becomes co state trackers instead of
> > state trackers.
> > 
> > In st_api, the co state trackers are responsible for representing
> > windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
> > depth/stencil, ...) to the state trackers.  In DRI2, this is done
> > through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
> > DRI1?), this is done by having co state trackers allocate a set of
> > private pipe_textures.  In both cases, the pipe_textures are created as
> > needed.  That is, if the state trackers draw only to the back buffer,
> > the front buffer will not be creatd.
> > 
> > At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
> > st_framebuffer_iface.  The state trackers retrieve the pipe_textures of
> > a window/pixmap/pbuffer mentioned above through this interface.  Other
> > than retrieving the pipe_textures, to support front buffer rendering,
> > the state trackers should call st_framebuffer_iface::flush_front when it
> > has something to display.
> > 
> > The implementation of st_framebuffer_iface::flush_front again depends on
> > the window systems.  In X11 with DRI2, it is no-op if the front buffer
> > passed to the state trackers is real;  Otherwise, it calls
> > DRI2CopyRegion to copy the contents from the fake front buffer to the
> > real front one.
> > 
> > In X11 with software rasterizer, the co state tracker is responsible to
> > display its private pipe_texture to a X drawable.  With the merge of
> > gallium-sw-api-2, this is made really easy by calling
> > pipe_screen::flush_frontbuffer.
> > 
> > The last patch of the series converts st/glx to use st_api.  The diff is
> > cleaner than the diff to st/egl.  It is a quick conversion to help see
> > the design of st_api in work.  There should be bugs, but the simple
> > demos I tested all work.  The other patches are constrained to EGL and
> > any regression outside EGL is considered a bug.
> > 
> > If you read this long because of the mention of EGLImage in the subject,
> > you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
> > thank-you gift :)
> > 
> 
> Chia-I,
> 
> This is all looking good to me.  The code doesn't seem to introduce any
> new layering issues or introduce dependencies on existing ones, which
> helps with ongoing cleanups.
> 
> I did some quick testing with the "linux-debug" target.  Gears works,
> with and without GALLIUM_WRAP=t.  However, demos/singlebuffer seems to
> get caught in infinite recursion and segfaults:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
> 185     {
> (gdb) bt
> #0  0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
> #1  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #2  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #3  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #4  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #5  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #6  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #7  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #8  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189

Also, libgl-xlib / llvmpipe is getting some rendering errors with these
patches - seems like culling is messed up maybe.  This is with a scons
build after adding the missing xm_st.c file.

Does it make sense to push these patches to a public Mesa branch so some
bugfixing can get done?

Keith

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

[Chia-I Wu <ol...@gm...>]

On Thu, Mar 11, 2010 at 7:54 PM, Keith Whitwell <ke...@vm...> wrote:
> On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
>> This is all looking good to me.  The code doesn't seem to introduce any
>> new layering issues or introduce dependencies on existing ones, which
>> helps with ongoing cleanups.
>> I did some quick testing with the "linux-debug" target.  Gears works,
>> with and without GALLIUM_WRAP=t.  However, demos/singlebuffer seems to
>> get caught in infinite recursion and segfaults:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
>> 185     {
>> (gdb) bt
>> #0  0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
>> #1  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
>> #2  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
>> #3  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
>> #4  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
>> #5  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
>> #6  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
>> #7  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
>> #8  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
>>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> Also, libgl-xlib / llvmpipe is getting some rendering errors with these
> patches - seems like culling is messed up maybe.  This is with a scons
> build after adding the missing xm_st.c file.
> Does it make sense to push these patches to a public Mesa branch so some
> bugfixing can get done?
Thanks for testing the patches.  I will have a look at the segfault tomorrow.
I haven't tried llvmpipe.  Does softpipe also get the rendering error?

I will create a topic branch, gallium-st-api, tomorrow and continue the
development/bugfixing there, unless there are major design defects that should
be resolved first.

-- 
ol...@Lu...

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

[Keith W. <ke...@vm...>]

On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
> On Thu, Mar 11, 2010 at 7:54 PM, Keith Whitwell <ke...@vm...> wrote:
> > On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
> >> This is all looking good to me.  The code doesn't seem to introduce any
> >> new layering issues or introduce dependencies on existing ones, which
> >> helps with ongoing cleanups.
> >> I did some quick testing with the "linux-debug" target.  Gears works,
> >> with and without GALLIUM_WRAP=t.  However, demos/singlebuffer seems to
> >> get caught in infinite recursion and segfaults:
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
> >> 185     {
> >> (gdb) bt
> >> #0  0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
> >> #1  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> >> #2  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> >> #3  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> >> #4  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> >> #5  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> >> #6  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> >> #7  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> >> #8  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08,
> >>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> > Also, libgl-xlib / llvmpipe is getting some rendering errors with these
> > patches - seems like culling is messed up maybe.  This is with a scons
> > build after adding the missing xm_st.c file.
> > Does it make sense to push these patches to a public Mesa branch so some
> > bugfixing can get done?
> Thanks for testing the patches.  I will have a look at the segfault tomorrow.
> I haven't tried llvmpipe.  Does softpipe also get the rendering error?

No, purely llvmpipe.

> I will create a topic branch, gallium-st-api, tomorrow and continue the
> development/bugfixing there, unless there are major design defects that should
> be resolved first.

I don't see any major defects - it all looks pretty sensible to me.

Keith

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

[Jakob B. <ja...@vm...>]

On 11 mar 2010, at 04.15, Chia-I Wu wrote:
> Hi all,
>
> 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.
>
> Feature-wise, st_api provides a more robust multiple client APIs
> (OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
> various EGLImage extensions.  As st_api interface can coexist with
> st_public interface, co state trackers should work as before unless  
> they
> are switched to use st_api.
>
> The original plan to merge the work to master after the interface is
> implemented by st/mesa and st/vega, and st/egl is converted to use it.
> Further development and conversions of st/glx and st/dri will happen  
> in
> master.  While this is still the plan, the recent merge of
> gallium-sw-api-2 motivates me to submit this WIP patch series for  
> public
> review.  I will cover only pipe_screen::update_buffer,
> pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
> here as the other parts were discussed a while ago.  But any  
> feedback to
> the design is appreciated.
>
> To summarize, there is *no* change to pipe_screen::update_buffer and
> pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
> trackers are not affected, and the st_public path of st/mesa and st/ 
> vega
> still work.  But when the st_api path is taken,
> pipe_screen::update_buffer is no longer got called.  And the caller of
> pipe_screen::flush_frontbuffer becomes co state trackers instead of
> state trackers.
>
> In st_api, the co state trackers are responsible for representing
> windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
> depth/stencil, ...) to the state trackers.  In DRI2, this is done
> through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
> DRI1?), this is done by having co state trackers allocate a set of
> private pipe_textures.  In both cases, the pipe_textures are created  
> as
> needed.  That is, if the state trackers draw only to the back buffer,
> the front buffer will not be creatd.
>
> At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
> st_framebuffer_iface.  The state trackers retrieve the pipe_textures  
> of
> a window/pixmap/pbuffer mentioned above through this interface.  Other
> than retrieving the pipe_textures, to support front buffer rendering,
> the state trackers should call st_framebuffer_iface::flush_front  
> when it
> has something to display.
>
> The implementation of st_framebuffer_iface::flush_front again  
> depends on
> the window systems.  In X11 with DRI2, it is no-op if the front buffer
> passed to the state trackers is real;  Otherwise, it calls
> DRI2CopyRegion to copy the contents from the fake front buffer to the
> real front one.
>
> In X11 with software rasterizer, the co state tracker is responsible  
> to
> display its private pipe_texture to a X drawable.  With the merge of
> gallium-sw-api-2, this is made really easy by calling
> pipe_screen::flush_frontbuffer.
>
> The last patch of the series converts st/glx to use st_api.  The  
> diff is
> cleaner than the diff to st/egl.  It is a quick conversion to help see
> the design of st_api in work.  There should be bugs, but the simple
> demos I tested all work.  The other patches are constrained to EGL and
> any regression outside EGL is considered a bug.
>
> If you read this long because of the mention of EGLImage in the  
> subject,
> you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
> thank-you gift :)

Thanks for doing this Chia-I, also a very excellent summary. Last time  
we talked about st_api IIRC we both agreed that the way we implemented  
EGLImage was wrong. However I think that we have waited long enough to  
move the state trackers over to st_api.

Would it to much trouble for you if we didn't do EGLImage in the first  
gallium-st-api feature branch? My feeling is that they are two  
separate issues and I think we should be able to quickly resolve  
moving the state trackers over to st_api and then move on to EGLImage.  
Looking at the patches the only affected one is the VG state tracker  
while the rest should just be not to apply the EGLImage related  
patches. I can do this later tonight and send out a series and give  
you something to work on.

I really want to move the state trackers over to st_api and I don't  
want the EGLImage issues holding us back. I also think that that part  
of the patch series looks excellent and I don't foresee any  
difficulties getting this merged ASAP.

Again thanks for doing this I know the inter state tracker  
interactions are a mess.

Cheers Jakob.

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

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz <ja...@vm...> wrote:
> Thanks for doing this Chia-I, also a very excellent summary. Last time we
> talked about st_api IIRC we both agreed that the way we implemented EGLImage
> was wrong. However I think that we have waited long enough to move the state
> trackers over to st_api.
> Would it to much trouble for you if we didn't do EGLImage in the first
> gallium-st-api feature branch? My feeling is that they are two separate
> issues and I think we should be able to quickly resolve moving the state
> trackers over to st_api and then move on to EGLImage. Looking at the patches
> the only affected one is the VG state tracker while the rest should just be
> not to apply the EGLImage related patches. I can do this later tonight and
> send out a series and give you something to work on.
> I really want to move the state trackers over to st_api and I don't want the
> EGLImage issues holding us back. I also think that that part of the patch
> series looks excellent and I don't foresee any difficulties getting this
> merged ASAP.
> Again thanks for doing this I know the inter state tracker interactions are
> a mess.
I've pushed a new branch, gallium-st-api, for the development of st_api.  It
consists of this patch series with EGLImage bits stripped out.  I also like to
have the branch merged sooner than later.

-- 
ol...@Lu...

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

[Jakob B. <wal...@gm...>]

On Fri, Mar 12, 2010 at 2:12 AM, Chia-I Wu <ol...@gm...> wrote:
> On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz <ja...@vm...> wrote:
>> Thanks for doing this Chia-I, also a very excellent summary. Last time we
>> talked about st_api IIRC we both agreed that the way we implemented EGLImage
>> was wrong. However I think that we have waited long enough to move the state
>> trackers over to st_api.
>> Would it to much trouble for you if we didn't do EGLImage in the first
>> gallium-st-api feature branch? My feeling is that they are two separate
>> issues and I think we should be able to quickly resolve moving the state
>> trackers over to st_api and then move on to EGLImage. Looking at the patches
>> the only affected one is the VG state tracker while the rest should just be
>> not to apply the EGLImage related patches. I can do this later tonight and
>> send out a series and give you something to work on.
>> I really want to move the state trackers over to st_api and I don't want the
>> EGLImage issues holding us back. I also think that that part of the patch
>> series looks excellent and I don't foresee any difficulties getting this
>> merged ASAP.
>> Again thanks for doing this I know the inter state tracker interactions are
>> a mess.
> I've pushed a new branch, gallium-st-api, for the development of st_api.  It
> consists of this patch series with EGLImage bits stripped out.  I also like to
> have the branch merged sooner than later.

Awesome, Thanks!

The *_iface was always a eye sore in the interface but it could be
avoided since st_context and st_framebuffer was already taken by the
gl state tracker. One would have to be crazy to go over the files with
sed and change all the reference, I guess I'm crazy... I have attached
three patches does exactly this. Everything compiles between and works
between each patch but a lot of warnings are generated, but I think I
squashed them all in the last patch. They should probably be squashed
if we want to use them, I like to get somebody sensible to weigh in on
this matter before we do anything with them.

Cheers Jakob.

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

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 12:07 PM, Jakob Bornecrantz
<wal...@gm...> wrote:
> On Fri, Mar 12, 2010 at 2:12 AM, Chia-I Wu <ol...@gm...> wrote:
>> On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz <ja...@vm...> wrote:
>>> Thanks for doing this Chia-I, also a very excellent summary. Last time we
>>> talked about st_api IIRC we both agreed that the way we implemented EGLImage
>>> was wrong. However I think that we have waited long enough to move the state
>>> trackers over to st_api.
>>> Would it to much trouble for you if we didn't do EGLImage in the first
>>> gallium-st-api feature branch? My feeling is that they are two separate
>>> issues and I think we should be able to quickly resolve moving the state
>>> trackers over to st_api and then move on to EGLImage. Looking at the patches
>>> the only affected one is the VG state tracker while the rest should just be
>>> not to apply the EGLImage related patches. I can do this later tonight and
>>> send out a series and give you something to work on.
>>> I really want to move the state trackers over to st_api and I don't want the
>>> EGLImage issues holding us back. I also think that that part of the patch
>>> series looks excellent and I don't foresee any difficulties getting this
>>> merged ASAP.
>>> Again thanks for doing this I know the inter state tracker interactions are
>>> a mess.
>> I've pushed a new branch, gallium-st-api, for the development of st_api.  It
>> consists of this patch series with EGLImage bits stripped out.  I also like to
>> have the branch merged sooner than later.
> Awesome, Thanks!
> The *_iface was always a eye sore in the interface but it could be
> avoided since st_context and st_framebuffer was already taken by the
> gl state tracker. One would have to be crazy to go over the files with
> sed and change all the reference, I guess I'm crazy... I have attached
> three patches does exactly this. Everything compiles between and works
> between each patch but a lot of warnings are generated, but I think I
> squashed them all in the last patch. They should probably be squashed
> if we want to use them, I like to get somebody sensible to weigh in on
> this matter before we do anything with them.
I'd love to see the _iface suffix get dropped too.  About the patches.  st/vega
also defines st_framebuffer and it needs to be renamed.  We might want to have
a convention for data types and variable naming that st/mesa and st/vega could
both follow.

That said, one concern about the renames is that it might cause many conflicts
when the branch is merged.  We might want to delay it until the branch is
merged or about to be merged.

-- 
ol...@Lu...

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

[Chia-I Wu <ol...@gm...>]

On Thu, Mar 11, 2010 at 11:45 PM, Keith Whitwell <ke...@vm...> wrote:
> On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
>> Thanks for testing the patches.  I will have a look at the segfault tomorrow.
>> I haven't tried llvmpipe.  Does softpipe also get the rendering error?
> No, purely llvmpipe.
I've fixed the infinite loop.  It was a stupid typo.  Now I am seeing rendering
errors in singlebuffer.
>> I will create a topic branch, gallium-st-api, tomorrow and continue the
>> development/bugfixing there, unless there are major design defects that should
>> be resolved first.
> I don't see any major defects - it all looks pretty sensible to me.
I've pushed this patches series to gallium-st-api.  The only change is that it
does not have the EGLImage bits, as requested by Jakob.

-- 
ol...@Lu...

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

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 10:16 AM, Chia-I Wu <ol...@gm...> wrote:
> On Thu, Mar 11, 2010 at 11:45 PM, Keith Whitwell <ke...@vm...> wrote:
>> On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
>>> Thanks for testing the patches.  I will have a look at the segfault tomorrow.
>>> I haven't tried llvmpipe.  Does softpipe also get the rendering error?
>> No, purely llvmpipe.
> I've fixed the infinite loop.  It was a stupid typo.  Now I am seeing rendering
> errors in singlebuffer.
Yes, the rendering error I saw was due to missing stencil bits.  It should be
fixed now.

-- 
ol...@Lu...

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

[Chia-I Wu <ol...@gm...>]

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.

-- 
ol...@Lu...

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

[Jakob B. <wal...@gm...>]

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.

Cheers Jakob.

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

[Chia-I Wu <ol...@gm...>]

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.

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..

-- 
ol...@Lu...

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

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 1:12 PM, Chia-I Wu <ol...@gm...> 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've changed st/egl and st/glx to create a pipe_context as needed to copy
between pipe_textures.  Only pipe_context::surface_copy is used.  It seems to
be the easiest way to do things right now.

As a result, gallium-st-api passes as many piglit quick tests as the
master branch does!
> 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..
>
> --
> ol...@Lu...
>



-- 
ol...@Lu...

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

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

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 10:08 PM, José Fonseca <jfo...@vm...> wrote:
> 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).
On X11 with software rasterizer, flush_frontbuffer (I use flush_frontbuffer in
this mail, but it also applies to display_texture) is implemented through
X(Shm)PutImage.  When DRI2 is used, it should be implemented through
DRI2CopyRegion.  The required parameters for calling X(Shm)PutImage or
DRI2CopyRegion are provided by screen-specific winsys_drawable_handle.  The
callback should generally be implemented with window system APIs.

But, there is no efficient way to implement the callback without a pipe_context
when DRI1 is used.  DRI1 needs to copy the textures (fake front or back) to the
real front buffer.  Passing pipe_context as a member of winsys_drawable_handle
seems to solve the problem, but I am not sure if it is considered a fix or a
hack though.

flush_frontbuffer is only implemented on software pipe drivers.  What DRI1
faces might exist on other window systems (Windows?).  It seems the callback
cannot be generally implemented without a pipe_context.  It should be either
move the callback to pipe_context, or keep it in pipe_screen and pass a
pipe_context as a member of winsys_drawable_handle for window systems that need
it.  I am leaning toward the latter right now.
> Furthermore, now it is very easy for any state tracker entity to create
> a dummy context for if needed, via pipe_screen::context_create().

-- 
ol...@Lu...