Platform design with the following details. Hardware
Processor Intel i7-2720QM Intel i7-2710QE Chipset QM67 Memory 2GB Software Hyper-Threading OFF Operating System Linux 3.2.14-rt24 BIOS (AMI) 2.10.1208 Graphics Standard DRM Kernel Driver provided with Linux version 3D MESA 8.1.0 2D NONE - All rendering done w/OpenGLES2 Libdrm 2.4.0 Libva NONE - no requirement for rendering motion video Vaapi-driver-intel NONE - no requirement for rendering motion video Application Framework Qt v.5.0 The issue surrounds delay in response times when the Intel GPU is utilized verse when a discrete GPU is utilized. The expected response times should be below 330us. We are seeing in spikes in response time up to 500us when using the Intel GPU. Application: - OpenGLES2 painter for all rendering - All windows are composed on offscreen buffers and then composited onto a full-screen GL surface as a texture. - All buffer management is done with Mesa's libgbm - Delay times are still seen when simplifying the test to -- run a bare-bones application that has no windows or rendering going on whatsoever (other than just clearing the on screen window), we still see the processing time interference. In this scenario, on every vsync, the on-screen color buffer (1920x1080@32<mailto:1920x1080@32> bitsPerPixel) is just being cleared (via glClear(GL_COLOR_BUFFER_BIT)) and then a page flip is performed via the kms/drm interface. There is a question about L3 cache impact and that being the source of the additional processing time. This is a Non-XServer usage model. Questions: * Is there a less impactful way to compose the display image than composing it all in off-screen buffers and then composited on a full-screen GL surface as a texture. * Any recommendations on reducing the processing time? Best Regards Shane Bower Application Design Center(ADC) Platform Software TME
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
