On Mon, Mar 1, 2010 at 12:43 PM, Joakim Sindholt <b...@zhasha.com> wrote: > On Sun, 2010-02-28 at 20:25 +0100, 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 ? :) >> >> Cheers, >> Jerome > > I think a vital point you're missing is: do we even care? If rendering > fails because we simply can't render any more, do we even want to fall > back? I can see a point in having a cap on how large a buffer can be > rendered but apart from that, I'm not sure there even is a problem. >
Welcome to GL. If I have a 32MB graphics card, and I advertise a maximum texture size of 4096x4096 + cubemapping + 3D textures, there is no nice way for the app to get a clue about what it can legally ask me to do. Old DRI drivers used to either use texmem which would try and scale the limits etc to what it could legally fit in the memory available, or with bufmgr drivers they would check against a limit from the kernel, and in both cases sw fallback if necessary. Gallium seemingly can't do this, maybe its okay to ignore it but it wasn't an option when we did the old DRI drivers. Dave. ------------------------------------------------------------------------------ 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
