On Mon, 2010-03-01 at 03:21 -0800, José Fonseca wrote: > On Sun, 2010-02-28 at 11:25 -0800, Jerome Glisse wrote: > > Hi, > > > > I am a bit puzzled, how a pipe driver should handle > > draw callback failure ? On radeon (pretty sure nouveau > > or intel hit the same issue) we can only know when one > > of the draw_* context callback is call if we can do > > the rendering or not. > > > > The failure here is dictated by memory constraint, ie > > if user bind big texture, big vbo ... we might not have > > enough GPU address space to bind all the desired object > > (even for drawing a single triangle) ? > > > > What should we do ? None of the draw callback can return > > a value ? Maybe for a GL stack tracker we should report > > GL_OUT_OF_MEMORY all way up to app ? Anyway bottom line > > is i think pipe driver are missing something here. Any > > idea ? Thought ? Is there already a plan to address that ? :) > > Gallium draw calls had return codes before. They were used for the > fallover driver IIRC and were recently deleted. > > Either we put the return codes back, or we add a new > pipe_context::validate() that would ensure that all necessary conditions > to draw successfully are met. > > Putting return codes on bind time won't work, because one can't set all > atoms simultaneously -- atoms are set one by one, so when one's setting > the state there are state combinations which may exceed the available > resources but that are never drawn with. E.g. you have a huge VB you > finished drawing, and then you switch to drawing with a small VB with a > huge texture, but in between it may happen that you have both bound > simultaneously. > > If ignoring is not an alternative, then I'd prefer a validate call. > > Whether to fallback to software or not -- it seems to me it's really a > problem that must be decided case by case. Drivers are supposed to be > useful -- if hardware is so limited that it can't do anything useful > then falling back to software is sensible. I don't think that a driver > should support every imaginable thing -- apps should check errors, and > users should ensure they have enough hardware resources for the > workloads they want. > > Personally I think state trackers shouldn't emulate anything with CPU > beyond unsupported pixel formats. If a hardware is so limited that in > need CPU assistence this should taken care transparently by the pipe > driver. Nevertheless we can and should provide auxiliary libraries like > draw to simplify the pipe driver implementation.
My opinion on this is similar: the pipe driver is responsible for getting the rendering done. If it needs to pull in a fallback module to achieve that, it is the pipe driver's responsibility to do so. Understanding the limitations of hardware and the best ways to work around those limitations is really something that the driver itself is best positioned to handle. The slight quirk of OpenGL is that there are some conditions where theoretically the driver is allowed to throw an OUT_OF_MEMORY error (or similar) and not render. This option isn't really available to gallium drivers, mainly because we don't know inside gallium whether the API permits this. Unfortunately, even in OpenGL, very few applications actually check the error conditions, or do anything sensible when they fail. I don't really like the idea of pipe drivers being able to fail render calls, as it means that every state tracker and every bit of utility code that issues a pipe->draw() call will have to check the return code and hook in fallback code on failure. One interesting thing would be to consider creating a layer that exposes a pipe_context interface to the state tracker, but revives some of the failover ideas internally - maybe as a first step just lifting the draw module usage up to a layer above the actual hardware driver. 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
