On Sun, 31 Oct 2010 01:15:34 +0000, Peter Clifton <pc...@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.
pgplGpK7H3irD.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
