On Mon, 2010-03-01 at 03:55 -0800, Jerome Glisse wrote: > On Mon, Mar 01, 2010 at 11:46:08AM +0000, Keith Whitwell wrote: > > 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 > > > > So you don't like the pipe_context::validate() of Jose ? My > taste goes to the pipe_context::validate() and having state > tracker setting the proper flag according to the API they > support (GL_OUT_OF_MEMORY for GL), this means just drop > rendering command that we can't do.
I think it's useful as a method for implementing GL_OUT_OF_MEMORY, but the pipe driver should: a) not rely on validate() being called - ie it is just a query, not a mandatory prepare-to-render notification. b) make a best effort to render in subsequent draw() calls, even if validate has been called - ie. it is just a query, does not modify pipe driver behaviour. > I am not really interested in doing software fallback. What > would be nice is someone testing with closed source driver > what happen when you try to draw somethings the GPU can't > handle. Maybe even people from closed source world can give > us a clue on what they are doing in front of such situation :) I've seen various things, but usually they try to render something even if its incorrect. 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
