On Mon, 2010-03-01 at 07:33 -0800, Olivier Galibert wrote: > On Mon, Mar 01, 2010 at 04:08:32PM +0100, Jerome Glisse wrote: > > Do you have solution/proposal/idea on how to handle the situation > > i am describing ? > > I've been looking at gallium from far away, but it seems to me you > have two independant issues: > - informing the caller of errors in atomic draw() calls > - deciding what to do when the error is due to resource exhaustion > > For the first issue, if the api doesn't allow for returning errors, > then the api is crap and has to be fixed. No two ways about it.
Thanks for your comments. To reiterate what has already been said, the approach we're taking is: a) the driver makes a best effort to render under all circumstances b) we'll add an error notification path to generate GL_OUT_OF_MEMORY, but the state tracker will not be doing any fallbacks based on this. Keith ------------------------------------------------------------------------------ Download Intel® 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
