On Sat, Apr 3, 2010 at 3:11 PM, Dave Airlie <airl...@gmail.com> wrote:
> The piglit read-front.c test is failing and the rabbits warren that is
> front buffer rendering in mesa st + dri st isn't helping me solve it.
> One thing I noticed was check_create_front_buffers is called in a
> number of places in the st, however it seems to never be used, as we
> call st_manager_add_color_renderbuffer moments before and that sets up
> the buffer.
> so
>  if (fb->Attachment[frontIndex].Renderbuffer == NULL) {
> this always fails and we never do any of that stuff.
> Maybe someone has a clue on how this is meant to work and I can implement 
> that.
DRI drivers use st_manager_add_color_renderbuffer path.
check_create_front_buffers is no-op for them.  The latter is used by st/wgl,
which still uses st_public.h.

i915g passes the read-front test on my 945GM laptop.  The failure could be that
some states are not correctly invalidated in st_manager_add_color_renderbuffer
and r300g (I assume this is your platform) could not reflect the change.

-- 
o...@lunarg.com

------------------------------------------------------------------------------
Download Intel&#174; 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

Reply via email to