From: Keith W. <kei...@go...> - 2010-03-14 08:53:18
|
Chia-I, This looks like it introduces an extra full-window copying operation at every swapbuffers... is that correct? If so, I think we should try to figure out an alternative approach without the copying... would actually flipping between two textures (thus preserving the old back/new front) contents be workable? Keith On Sun, Mar 14, 2010 at 5:17 AM, Chia-I Wu <ol...@ke...> wrote: > Module: Mesa > Branch: gallium-st-api > Commit: d6262bdcfb64e1f88f6a890829f5c30c26bc372b > URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d6262bdcfb64e1f88f6a890829f5c30c26bc372b > > Author: Chia-I Wu <ol...@lu...> > Date: Sun Mar 14 12:01:27 2010 +0800 > > st/glx: Sync the back buffer to the front buffer. > > Consider this rendering sequence > > * render to the back buffer > * swap buffers > * read from the front buffer > > The front buffer is expected to have the contents of the back buffer. > > --- > > src/gallium/state_trackers/glx/xlib/xm_st.c | 26 ++++++++++++++++++++++---- > 1 files changed, 22 insertions(+), 4 deletions(-) > > diff --git a/src/gallium/state_trackers/glx/xlib/xm_st.c b/src/gallium/state_trackers/glx/xlib/xm_st.c > index de5a35e..bcb8285 100644 > --- a/src/gallium/state_trackers/glx/xlib/xm_st.c > +++ b/src/gallium/state_trackers/glx/xlib/xm_st.c > @@ -197,18 +197,36 @@ xmesa_st_framebuffer_validate(struct st_framebuffer_iface *stfbi, > struct pipe_texture **out) > { > struct xmesa_st_framebuffer *xstfb = xmesa_st_framebuffer(stfbi); > - unsigned statt_mask, i; > + unsigned statt_mask, new_mask, i; > + boolean resized; > > statt_mask = 0x0; > for (i = 0; i < count; i++) > statt_mask |= 1 << statts[i]; > + /* record newly allocated textures */ > + new_mask = statt_mask & ~xstfb->texture_mask; > + > + resized = (xstfb->buffer->width != xstfb->texture_width || > + xstfb->buffer->height != xstfb->texture_height); > > /* revalidate textures */ > - if (xstfb->buffer->width != xstfb->texture_width || > - xstfb->buffer->height != xstfb->texture_height || > - (xstfb->texture_mask & statt_mask) != statt_mask) { > + if (resized || new_mask) { > xmesa_st_framebuffer_validate_textures(stfbi, > xstfb->buffer->width, xstfb->buffer->height, statt_mask); > + > + if (!resized) { > + enum st_attachment_type back, front; > + > + back = ST_ATTACHMENT_BACK_LEFT; > + front = ST_ATTACHMENT_FRONT_LEFT; > + /* copy the contents if front is newly allocated and back is not */ > + if ((statt_mask & (1 << back)) && > + (new_mask & (1 << front)) && > + !(new_mask & (1 << back))) { > + xmesa_st_framebuffer_copy_textures(stfbi, back, front, > + 0, 0, xstfb->texture_width, xstfb->texture_height); > + } > + } > } > > for (i = 0; i < count; i++) { > > _______________________________________________ > mesa-commit mailing list > mes...@li... > http://lists.freedesktop.org/mailman/listinfo/mesa-commit > |
From: Chia-I Wu <ol...@gm...> - 2010-03-14 10:28:27
|
On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell <kei...@go...> wrote: > This looks like it introduces an extra full-window copying operation > at every swapbuffers... is that correct? > If so, I think we should try to figure out an alternative approach > without the copying... would actually flipping between two textures > (thus preserving the old back/new front) contents be workable? Buffers swapping is handled in xmesa_swap_st_framebuffer. It is a zero-copy operation. This commit is to fix a bug when this code path is hit /* draw something and ... */ glXSwapBuffers(); glReadBuffer(GL_FRONT); glReadPixels(); In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be added on demand as can be seen in st_ReadBuffer. The validation list would become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }. When glReadPixels is called, st/mesa will validate with the list and read from the front buffer. On the st/glx side, this use pattern is catched. When the front buffer is allocated, the contents of the back buffer will be copied to the front buffer. This happens only once. When the same code is run again, glXSwapBuffers will swap the buffers. The copying is required because xmesa_swap_st_framebuffer does not always swap the buffers. It is so that only the back buffer is allocated when the application never draws/reads the front buffer. -- ol...@Lu... |
From: Keith W. <kei...@go...> - 2010-03-14 11:27:25
|
On Sun, Mar 14, 2010 at 10:28 AM, Chia-I Wu <ol...@gm...> wrote: > On Sun, Mar 14, 2010 at 4:53 PM, Keith Whitwell > <kei...@go...> wrote: >> This looks like it introduces an extra full-window copying operation >> at every swapbuffers... is that correct? >> If so, I think we should try to figure out an alternative approach >> without the copying... would actually flipping between two textures >> (thus preserving the old back/new front) contents be workable? > Buffers swapping is handled in xmesa_swap_st_framebuffer. It is a zero-copy > operation. > > This commit is to fix a bug when this code path is hit > > /* draw something and ... */ > glXSwapBuffers(); > glReadBuffer(GL_FRONT); > glReadPixels(); > > In the above, glReadBuffer will cause BUFFER_FRONT_LEFT renderbuffer to be > added on demand as can be seen in st_ReadBuffer. The validation list would > become { ST_ATTACHMENT_FRONT_LEFT, ST_ATTACHMENT_BACK_LEFT }. When > glReadPixels is called, st/mesa will validate with the list and read from the > front buffer. > > On the st/glx side, this use pattern is catched. When the front buffer is > allocated, the contents of the back buffer will be copied to the front buffer. > This happens only once. When the same code is run again, glXSwapBuffers will > swap the buffers. > > The copying is required because xmesa_swap_st_framebuffer does not always swap > the buffers. It is so that only the back buffer is allocated when the > application never draws/reads the front buffer. > > -- > ol...@Lu... > OK, sorry for being slow & thanks for explaining... Keith |