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. For the second issue, you can have a generic way, a per-driver (call them state trackers if you want) specific way, both, or neither (also known as the "fuck it" solution). The generic way is to, when you get an "out of whatever" error, drop down to software in the caller. That requires having enough state available to be able to apply software to the specific operations in the first place. Potentially slow, but otoh all drivers would benefit from it. It would happen only on error, so outside of the fast path. The specific way is to handle all you can in the driver, for instance splitting as you proposed, and punt in error only if you really can't do anything accelerated. Both allows you in case of punting to still be able to do the requested render. Belt and suspenders :-) Neither "just" means ensuring errors go up all the way in the chain to the application. Personally I'd start by that, but that's just me. Ensure that the application has enough information, even if after-the-fact, to do its own tuning. A polygon not drawing silently is an atrocity to debug. An out of resources error is something obvious (debug-wise) you can throw money or code at. Having "neither", i.e. correctness in error handling, does not prevent you to play with the generic or specific ways afterwards. But I suspect you'll find more interesting to work on enabling access to currently unavailable hardware features and tell people that if they want 16 8192^3 textures they can go full software explicitely or buy a card capable of it. Reasonableness has limits. OG. ------------------------------------------------------------------------------ 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
