[Mesa-dev] [PATCH] i965: Throttle rendering to an fbo

[Daniel Vetter]

On Wed, Mar 11, 2015 at 09:10:01AM -0700, Ian Romanick wrote:
> On 03/06/2015 06:30 AM, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:38:44PM -0800, Ian Romanick wrote:
> >> On 03/04/2015 10:28 AM, Chad Versace wrote:
> >>> That text does not appear in the GL spec. When I read the manpage alongside
> >>> the GL spec, to get a more complete context, I think the manpage contains
> >>> that phrase simply to contrast with glFinish. In my reading, it does not imply that
> >>> glFlush may wait for *some* previously issued GL commands to complete.
> >>
> >> glFlush was invented to support indirect rendering (especially to the
> >> front buffer):  it flushes the buffer in libGL to the xserver.  If
> >> you're making any other assumptions about what it does or does not do...
> >> continue at your own peril.
> > 
> > Well plan B is the kernel throttles for you. But that's going to cause a
> > fuzz since at least for benchmarking the kernel kinda lacks the necessary
> > information to make informed calls about when to throttle and how.
> 
> Based on my (possibly flawed) understanding of the kernel commit message
> the Chris previously cited, we only need to throttle when not throttling
> would cause a problem.  Is that correct?  Based on the rest of my
> understanding, Mesa doesn't have the right information either.
> 
> > So is there no gl entry point in mesa we can abuse and make this happen?
> > Citing the spec doesn't make the real world issue go away.
> 
> I think we're at a place where real worlds collide.
> 
> There are a lot of poorly written apps out there.  Much of it is the
> "beat on it until it works" syndrome.  This results in a lot of glFlush
> abuse.  This is part of the reason that drivers for deferred rendering
> GPUs generally just ignore glFlush.  Unnecessary flushes REALLY hurt
> performance on tilers, but they don't matter so much on immediate mode
> renderers.
> 
> Applications do FBO rendering for a lot of things that don't end up on
> the screen.  For example, some applications will load images from disk
> and use FBO rendering to generate the mipmaps.  Applications also do
> varying amounts of FBO rendering for pre-passes, shadow map generation,
> etc.  A few applications also do FBO rendering as a sort of poor man's
> compute shader.
> 
> Now we have the collision.  You have an game that is going to do a few
> thousand draws to FBOs to generate mipmaps at start-up with a bunch of
> (probably unnecessary) glFlush calls sprinkled around.  Now somebody
> gets a bug report that the game takes too long to load because it's
> getting throttled.
> 
> I think throttling submission in Mesa is the right place, but I think we
> need additional information to know when it is necessary.

Ok makes sense then that anything in glflush wouldn't be a good idea. The
current iteration of stalling before we submit more work at least has the
benefit of some relation with the workloads generated. I guess in the end
we do indeed need more clueful throttling in the kernel (to prevent bad
things from happening), with some additional throttlin on frame boundaries
in mesa to etch out the last bit of interactive responsiveness.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch