On Sat, Apr 3, 2010 at 3:11 PM, Dave Airlie <ai...@gm...> 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.
--
ol...@Lu...
|
