On Wed, Oct 23, 2002 at 07:56:28AM +0100, Keith Whitwell wrote: > Ian Romanick wrote: > >On Wed, Oct 23, 2002 at 12:27:57AM +0200, Charl P. Botha wrote: > > > >>On Tue, Oct 22, 2002 at 03:12:52PM -0700, Ian Romanick wrote: > >> > >>>On Tue, Oct 22, 2002 at 12:46:27AM +0200, Charl P. Botha wrote: > >>> > >>> > >>>>Run glthreads with something like: glthreads -n 5 > >>>> > >>>Here's an additional data point. If you move the call to > >>>glXDestroyContext > >>>to the end of draw_loop (and delete the other two calls), the program > >>>works > >>>as expected on the Radeon. The event_loop won't terminate, but I leave > >>>fixing that trivial bug as an exercise for the reader. :) > >>> > >>Hrmmm, interesting. The reason I made this is to reproduce a bug in a > >>much > >>larger application where that kind of control (taking glxDestroyContext() > >>INto the thread) is quite difficult. > >> > >>Ian, do you consider this to be a bug? > >> > > > >It's a bug somewhere. :) I'm going to have to dig more before I can > >determine if the bug is in the app, the driver, or both. > > > >Brian or Keith: Do either of you have an opinion about this? > > Certainly a bug. First thing of concern is whether it's the vtxfmt/codegen > stuff which isn't threadsafe, but should get turned off at the first sign > of multithreading.
I just tried this with RADEON_TCL_FORCE_DISABLE=1, RADEON_NO_VTXFMT=1 and RADEON_NO_CODEGEN=1 and I can still reproduce the bug. Are any other bells ringing? This is with a DRI CVS checkout just before Alan Hourihane's great merge work. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
