On Mon, Mar 1, 2010 at 3:02 PM, Jerome Glisse <gli...@freedesktop.org>wrote:
> On Mon, Mar 01, 2010 at 12:24:19PM +0000, Keith Whitwell wrote:
> > On Mon, 2010-03-01 at 04:07 -0800, Keith Whitwell wrote:
> > > 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.
> >
> > It's always interesting to think about the OpenGL mechanisms and
> > understand why they do things a particular way.
> >
> > In this case we bump into a fairly interesting bit of OpenGL -- the
> > asynchronous error mechanism. Why doesn't OpenGL just return
> > OUT_OF_MEMORY from glBegin() or glDrawElemenets()? Basically GL is
> > preserving asynchronous operations between the application and the GL
> > implementation - eg for indirect contexts, but also for cases where the
> > errors are generated by the memory manager or even the hardware long
> > after the actual draw() call itself.
> >
> > I think we probably will face the same issues in gallium. Nobody has
> > tried to do a "remote gallium" yet, but any sort of synchronous
> > round-trip query (like validate, or return codes from draw calls) will
> > be a pain to accommodate in that environment. Likewise errors that are
> > raised by TTM at command-buffer submission would be better handled by an
> > asynchronous error mechanism.
> >
> > For now, validate() sounds fine, but at some point in the future a
> > less-synchronous version may be appealing.
> >
> > Keith
> >
>
> Note that i likely didn't described well my error case, in my pipe
> driver i can very easily split rendering operation so vbo size is
> virtualy not a problem. The error case i was thinking about is
> for instance binding 16 3d 8096x8096x8096 textures ie something
> the hw doesn't have enough memory to achieve no matter in how
> small piece we break draw command.
>
>
Wouldn't it be better and easier to just fail to allocate such large
textures? I think the memory manager should made more humble when exceeding
the VRAM size.
I guess i should first fine tune the texture size limit i am
> reporting, but i don't want to cripple app that use 1 4096x4096
> texture in order to forbid app which use 16 of those.
>
> Cheers,
> Jerome
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
