Michael wrote: > > On Tue, Apr 09, 2002 at 02:02:59PM -0700, Ian Romanick wrote: > > After doing some cursory Maya testing, I decided to put the TCL branch up > > against glean, and glean won. It consistently explodes in one of the > > blendFunc tests. This is with the latest glean CVS trunk and DRI TCL branch > > as of the morning of 4/9. > > > > Again, I will try to provide any other helpful information that I can. > > > > blendFunc: FAIL rgba8, db, z24, win+pmap, id 35 > > source factor = GL_SRC_ALPHA_SATURATE, dest factor = GL_ONE_MINUS_DST_ALPHA > > Readback had 7.98864 bits in error; blending had 6.93146 bits in error. > > glean: t_imm_api.c:197: _tnl_Begin: Assertion `IM->BeginState == 0' failed. > > This is when glean is using a new ctx to render with and > _tnl_CreateContext using _mesa_install_exec_vtxfmt but vb.installed > state is still true. > > _tnl_Begin gets true from radeonNotifyBegin, but the vtxfmt in place is > still the tnl one, hence _tnl_End blows up. > > Might be as easy as vb.installed = 0 in radeonCreateContext, but a > similar problem seems to happen with things like glut's walker demo > using 2 contexts at the same time...
Michael - I tracked down the problem to the same cause a couple of days ago -- apologies for not posting some info to avoid duplicating the debugging. I've always known we needed to do something more with that code to handle multithreaded cases (which really can't be supported efficiently without changes to libGL.so or similar). Multithreading can be detected in MakeCurrent. But we do also need to make sure the data in 'vb' reflects the current bound context. For some reason putting off the above caused me to ignore MakeCurrent entirely... Anyway, I've got a half-finished change to fix this that I'll be working on today. Keith _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
