[Mesa-dev] [Bug 33934] glBlitFramebuffer could have a fast path if there's no scaling

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Feb 8 05:08:06 PST 2011


https://bugs.freedesktop.org/show_bug.cgi?id=33934

--- Comment #3 from Neil Roberts <neil at linux.intel.com> 2011-02-08 05:08:06 PST ---
Created an attachment (id=43096)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=43096)
Test case showing the performance difference

Well at least on the Intel driver there is a faster path for blitting that
glCopyTexSubImage2D uses. If it's not also beneficial for Radeon then maybe we
should move the patch to be specific to the Intel drivers.

Attached is a test case to get some timing for the two functions.

Without patch:

time for glBlitFramebuffer = 122285
time for glCopyTexSubImage2D = 6097

So glCopyTexSubImage2D is 1906% faster than glBlitFramebuffer.

With the patch I get:

time for glBlitFramebuffer = 25740
time for glCopyTexSubImage2D = 6900

The patch improves the speed of glBlitFramebuffer by 375% but it's still pretty
slow compared to glCopyTexSubImage2D. Maybe the cost of glBlitFramebuffer is
mostly in preserving the GL state across the Mesa meta calls and the patch
still does a bit of this. Maybe we should make a proper Intel-specific fast
path for glBlitFramebuffer that directly calls intelEmitCopyBlit like
do_copy_texsubimage does so that it can avoid affecting the GL state.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the mesa-dev mailing list