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. Jose ------------------------------------------------------------------------------ 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
