Bug 17355

Summary:

[patch] 2D EXA acceleration on G33-class hardware, large framebuffer

Product:

xorg

Reporter:

Owen Taylor <otaylor>

Component:

Driver/intel

Assignee:

Carl Worth <cworth>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

CC:

eric, keithp, zhenyu.z.wang

Version:

unspecified

Keywords:

patch

Hardware:

Other

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
Enable EXA 2D acceleration for large framebuffers on G33 (against 2.4 branch)	none

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.