On 04/02/2012 01:14, Carl Worth wrote: > I recently had a problem with a dri driver failing to load, (it turned > out to be a case of the driver being built for 64-bit, but running a > 32-bit application). > > At the time, mesa switched over to indirect rendering without me > realizing it at all. This left me quite confused. Finally, a kind > friend pointed me to LIBGL_DEBUG=verbose and I was able to diagnose > the problem. > > I think mesa could have been that friend first. Here's a patch series > to introduce a new CriticalErrorMessageF macro which will print a > message even if LIBGL_DEBUG is unset, (but, like ErrorMessageF, will > still silence the message if LIBGL_DEBUG is set to quiet). > > Then, the error messages regarding switching to indirect and > software-direct rendering are moved from ErrorMessageF to > CriticalErrorMessageF. > > I think this makes mesa a bit kinder when things go wrong, without > spewing excessive noise in common cases. Any diagreement? Are their > other obvious candidates for CriticalErrorMessageF?
It looks like these error messages will always be emitted when software-direct and indirect are the only paths available (e.g. when ./configured with --with-dri-drivers=swrast or --disable-driglx-direct). _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
