Bug 17355 - [patch] 2D EXA acceleration on G33-class hardware, large framebuffer
Summary: [patch] 2D EXA acceleration on G33-class hardware, large framebuffer
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Carl Worth
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2008-08-29 12:32 UTC by Owen Taylor
Modified: 2009-06-04 08:37 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Enable EXA 2D acceleration for large framebuffers on G33 (against 2.4 branch) (1.02 KB, patch)
2008-08-29 12:32 UTC, Owen Taylor
no flags Details | Splinter Review

Description Owen Taylor 2008-08-29 12:32:53 UTC
Created attachment 18572 [details] [review]
Enable EXA 2D acceleration for large framebuffers on G33 (against 2.4 branch)

The attached patch is somewhat experimental ... it might be right, partially right, or plain wrong. But it works for me.

On a desktop Q35 board (GMA 3100), I found that moving windows around (uncomposited) was dead-slow if I made the framebuffer size > 2048 wide.

Looking through the driver, it appears that the limits to 2k for rendering might apply to the 3D engine, but not to the 2D engine, so I tried upping maxX and maxY and the result worked and windows moved much more smoothly.

Note that i915_check_render() and i915_prepare_render() already have checks on the sizes of the source and destination texture so fallbacks will be used for render acceleration. (I tried removing those checks too, that did not work!)

It's conceivable to me that the same change would work on older i9xx as well.
Comment 1 Gordon Jin 2008-08-30 00:57:05 UTC
anyone would like to review this patch?
Comment 2 Eric Anholt 2008-09-02 07:50:37 UTC
The assumption had been that if you can't do Render to the thing, you don't want to ever accelerate to it, since that means migration thrashing.  The front buffer would be a special case, though.

The whole mess is gone with UXA, though.
Comment 3 Carl Worth 2008-10-14 09:43:26 UTC
(In reply to comment #2)
> The assumption had been that if you can't do Render to the thing, you don't
> want to ever accelerate to it, since that means migration thrashing.  The front
> buffer would be a special case, though.
> 
> The whole mess is gone with UXA, though.

Eric,

Can you provide a bit more guidance on what you think should be done here?

It seems clear that Owen has found a nice performance improvement for his system. Should we accept his patch? Do we have some evidence that the patch would cause some other, larger problem? Or is there some better way to provide a similar improvement?

Thanks for any clarification you can provide,

-Carl
Comment 4 Eric Anholt 2009-06-04 08:37:29 UTC
So, while we failed to apply this for a long time, EXA is now gone and so this issue is as well.


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.