Created attachment 19166 [details] xorg.0.log System Environment: -------------------------- --Platform: q965 --Architecture(32-bit,64-bit,compatiblity): 32-bit --2D driver: xf86-video-intel-2.5-branch 8408995ffbf705aa0bc09ab72c58c2e31a4b70c3 --3D driver: intel-2008-q3 branch e636f5b76bbcfef95092d21646c844c0dfe770e0 --DRM:shipped with kernel 2.6.27-rc6 --libdrm: master 2db8e0c8ef8c7a66460fceda129533b364f6418c --Xserver: 1.5.1 --Kernel: 2.6.27-rc6 Bug detailed description: -------------------------- start X ,then run Rendercheck test .due to very low performance,it will take more than 5 hours now but just need 1 hour before. Reproduce steps: ---------------- 1. xinit & 2. ./rendercheck -t composite -o src,over,overreverse,xor -f a8r8g8b8,a8,x8r8g8b8,r8g8b8,b8g8r8,r5g5b5,b5g5r5,x1r5g5b5,x1b5g5r5,r5g6b5,b5g6r5,x8b8g8r8
In exchange for better cpu usage behavior when doing real work, we may have hurt runtime of this regression test. Very low priority.
still exists with : Mesa: (master)2a877411dbe35abdd8c15fb4821d9232619d89cc Xserver: (master)102c4dac7c521941f52652152b1660cd7f559d56 Xf86_video_intel: (master)87ea531c5dc5b39809395b277c330854aaaaf019 Kernel_gem: (drm-intel-next)43f7ccc48dd7587983cfe16de578042a7ad3a9b3
still exists against: Libdrm: (master)00d8e960ca665b7f0528438331f4d0ae77fbb4cc Mesa:(mesa_7_4_branch)b009a32bf428192fef2dc4787d25f022a472854f Xserver: (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e Xf86_video_intel: (2.7)e2465249a90b9aefe6d7a96eb56a51fde54698a0 Kernel: (for-airlied)a2e785c32b886dd7f0289d1cf15fc14e9c81bc01
still exists with the latest driver: Libdrm: (master)68103b2758029b3c1fbfcf995baa758bfd2676de Mesa: (mesa_7_5_branch)dd4c142e90a0cba5b445990bb522ce9199d7f565 Xserver: (master)1b1b20d6e3e696e4437a9ef56128cde70a485f66 Xf86_video_intel: (master)a8a771a853478e5f45f71d0eff3c4d55bf24d0ad Kernel: (for-linus)091438dd5668396328a3419abcbc6591159eb8d1
Now with the newest code on master branch, on both 945GM and G45, rendercheck/composite passes but it needs more than 7 hours to finish.
As I found myself waiting upon rendercheck, I fixed one of the TODOs and reduced the number of round-trips required for result processing. So rendercheck as a whole is significantly faster. However, we still incur considerable slow-down due to fallback ping-pong and there is very little incentive to fix that (accelerating more ops is likely to cause rendercheck to slow down even more...).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.