[Intel-gfx] intel_prepare_render(intel); unhelpful?

[Eric Anholt]

On Sun, 31 Oct 2010 01:15:34 +0000, Peter Clifton <pcjc2 at cam.ac.uk> wrote:
> Hi guys,
> 
> I was just poking around looking for somewhere quick and dirty to shove
> my new experimental DRM IOCTL for retrieving IDLE data from the GPU. I
> was looking at the various breakpoints in the debugger, and found
> intel_prepare_render() being called more often than I'd like.
> 
> For instance, in intelClear() we call it - AIUI, flushing rendering
> before code execution continues. Nasty ;(

I don't see flushing in intel_prepare_render() unless you're using
frontbuffer rendering, which you shouldn't be.

> I use glClear many times per frame on the stencil buffer, which always
> ends up hitting the 3D engine for the clear (even normal colour buffer
> clear seems to hit that path too, as BLIT can't do the correct kind of
> tiling IIRC?)
> 
> If we can pre-determine we will use the 3D engine, presumably all the
> state-changes in _mesa_meta_clear() will end up pipelined?
> 
> In a non-statistically correct sample test run of one benchmark
> iteration each.. blindly commenting the intel_prepare_render() call gave
> me 27.7fps -> 29.8fps.
> 
> 
> 
> I also noted that I'm hitting a path in intel_prepare_render which
> throttles, even with vblank_mode=0. Why does it have to do this?

Because otherwise, many apps out there will dump frames out to the GPU
as fast as possible, which will bottleneck, and interactivity of the
application (input reactions happen N frames later) and the X Server (it
can't get any rendering out, because the app has hogged the GPU for the
next few seconds) is ruined.

Now, this version of the code has bothered me, since apps that execute
in one batchbuffer should end up getting overly penalized.  See
intel-throttle-hack of my mesa tree for a possible fix.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20101031/3154de9e/attachment.sig>