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

[Ian Romanick]

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.

> -Daniel