On Sun, 2010-02-28 at 21:35 -0800, Corbin Simpson wrote:
> On Sun, Feb 28, 2010 at 9:15 PM, Dave Airlie <airl...@gmail.com> wrote:
> > 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.
>
> GL_ATI_meminfo is unfortunately the best bet. :C
>
> Also Gallium's API is written so that drivers must never fail on
> render calls. This is *incredibly* lame but there's nothing that can
> be done. Every single driver is currently encouraged to just drop shit
> on the floor if e.g. u_trim_pipe_prim fails, and every driver is
> encouraged to call u_trim_pipe_prim, so we have stupidity like: if
> (!u_trim_pipe_prim(mode, &count)) { return; }
>
> In EVERY SINGLE DRIVER. Most uncool. What's the point of a unified API
> if it can't do sanity checks? >:T
I don't see what sanity checking has to do with the topic of failing
draw calls.
Would
(!u_trim_pipe_prim(mode, &count)) { return FALSE; }
make you any happier?
I think we all agree sanity checking should be done by the state
trackers. You're just confusing the result of common practices of
cut'n'pasting code and working around third-party problems in their code
with the encouraged design principles. I'm sure a patch to fix this
would be most welcome.
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
