Re: 945GM(E) screen rotation and slow GL.

2009-01-14 Thread Vedran Rodic
I've done tests in Second Life where the framerate in Linux is about
2x worse than in Windows.

On Wed, Jan 14, 2009 at 11:30 AM, Mateusz Kaduk  wrote:
> 2009/1/14 Vedran Rodic 
>>
>> Probably unrelated, but the old 915tex driver had about 50% better
>> framerate in glxgears than either the old Mesa driver, or the current.
>> Of course, this driver is now obsolete. Do you have any idea why was
>> that driver so much faster? If I remember correctly, the performance
>> improvement was also visible in quake3.
>
> afaik glxgears now is vblank synced by default and someone even wrote its
> not a benchmarking tool. You can disable vblank syncing with dri-conf. When
> it comes to openarena, regnum-online, nexuiz without GLSL it preformes fine
> and is pretty playable on GM965. Windows does not preform that much faster
> and no tests were done to show real difference.
>
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: 945GM(E) screen rotation and slow GL.

2009-01-14 Thread Mateusz Kaduk
2009/1/14 Vedran Rodic 

> Probably unrelated, but the old 915tex driver had about 50% better
> framerate in glxgears than either the old Mesa driver, or the current.
> Of course, this driver is now obsolete. Do you have any idea why was
> that driver so much faster? If I remember correctly, the performance
> improvement was also visible in quake3.
>

afaik glxgears now is vblank synced by default and someone even wrote its
not a benchmarking tool. You can disable vblank syncing with dri-conf. When
it comes to openarena, regnum-online, nexuiz without GLSL it preformes fine
and is pretty playable on GM965. Windows does not preform that much faster
and no tests were done to show real difference.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: 945GM(E) screen rotation and slow GL.

2009-01-14 Thread Vedran Rodic
On Wed, Jan 14, 2009 at 6:27 AM, Keith Packard  wrote:

> You're fairly seriously memory bandwidth limited with that chipset, and
> at that resolution.


Probably unrelated, but the old 915tex driver had about 50% better
framerate in glxgears than either the old Mesa driver, or the current.
Of course, this driver is now obsolete. Do you have any idea why was
that driver so much faster? If I remember correctly, the performance
improvement was also visible in quake3.

Vedran
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: 945GM(E) screen rotation and slow GL.

2009-01-13 Thread Rob Kramer
Keith Packard wrote:
>> Do you think the 945 chipset is just too slow to rotate a 1920x1200
>> screen?
> 
> One thing that may improve performance a bit is when we get tiling
> support for the displayed buffer. That work requires some additional
> kernel infrastructure to manage the 'fence' registers which are
> responsible for linearizing tiled regions for software rendering code.
>
> You might try 16bpp instead of 32bpp; it won't look as good, but it
> should go faster.

Tried that: 85 fps in normal mode, 27 fps for left-rotation.

Would a board with a 965GM chipset fare much better, you think? I haven't
seen many small form-factor embedded boards with that chipset yet,
unfortunately.

Cheers,

   Rob


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: 945GM(E) screen rotation and slow GL.

2009-01-13 Thread Keith Packard
On Wed, 2009-01-14 at 13:18 +0800, Rob Kramer wrote:

> Cool, thanks. That's a lot better at 18 fps, but still a lot worse than
> normal landscape operation. Is that expected? I thought with modern GL
> setups, rotation basically came for free -- but I'm a GL newbie :)

The rotation is done by drawing to an upright frame buffer and then
copying that to the rotated frame buffer for presentation. That's a lot
of pixels to copy around each frame.

> Do you think the 945 chipset is just too slow to rotate a 1920x1200
> screen?

You're fairly seriously memory bandwidth limited with that chipset, and
at that resolution.

One thing that may improve performance a bit is when we get tiling
support for the displayed buffer. That work requires some additional
kernel infrastructure to manage the 'fence' registers which are
responsible for linearizing tiled regions for software rendering code.

You might try 16bpp instead of 32bpp; it won't look as good, but it
should go faster.

-- 
keith.pack...@intel.com


signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: 945GM(E) screen rotation and slow GL.

2009-01-13 Thread Rob Kramer
Keith Packard wrote:
> On Wed, 2009-01-14 at 09:51 +0800, Rob Kramer wrote:
> 
>> When testing screen rotation to portrait mode, the glxgears framerate
>> drops from 51 fps (not too great to start with) to 1 fps.
> 
> Thanks! We lost our rotation acceleration when we switched to dri_bo's
> for pixmaps.

Cool, thanks. That's a lot better at 18 fps, but still a lot worse than
normal landscape operation. Is that expected? I thought with modern GL
setups, rotation basically came for free -- but I'm a GL newbie :)

Do you think the 945 chipset is just too slow to rotate a 1920x1200 screen?

Cheers!

   Rob

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg


Re: 945GM(E) screen rotation and slow GL.

2009-01-13 Thread Keith Packard
On Wed, 2009-01-14 at 09:51 +0800, Rob Kramer wrote:

> When testing screen rotation to portrait mode, the glxgears framerate drops
> from 51 fps (not too great to start with) to 1 fps. 

Thanks! We lost our rotation acceleration when we switched to dri_bo's
for pixmaps.

Try this patch:

diff --git a/src/i830_display.c b/src/i830_display.c
index 50fbc4d..4fba1fb 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -1601,6 +1601,7 @@ static PixmapPtr
 i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, int width, int height)
 {
 ScrnInfoPtr pScrn = crtc->scrn;
+I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
 I830Ptr pI830 = I830PTR(pScrn);
 int rotate_pitch;
 PixmapPtr rotate_pixmap;
@@ -1621,6 +1622,8 @@ i830_crtc_shadow_create(xf86CrtcPtr crtc, void *data, int 
width, int height)
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
   "Couldn't allocate shadow pixmap for rotated CRTC\n");
 }
+if (intel_crtc->rotate_mem && intel_crtc->rotate_mem->bo)
+   i830_set_pixmap_bo(rotate_pixmap, intel_crtc->rotate_mem->bo);
 return rotate_pixmap;
 }
 

-- 
keith.pack...@intel.com


signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

945GM(E) screen rotation and slow GL.

2009-01-13 Thread Rob Kramer
Hi,

I have an embedded board with 945GM chipset (1.8GHz Celeron M) connected via
DVI to a 1920x1200 screen. I'm trying to benchmark GL performance a bit
with glxgears, which should be good enough to give a rough estimate of the
device's capabilities. (Is there a better generic GL benchmark tool?)

When testing screen rotation to portrait mode, the glxgears framerate drops
from 51 fps (not too great to start with) to 1 fps. 

I remember in the past there were always dire performance warnings regarding
XAA and rotation; impact of shadow FBs and all that. Is that still a valid
concern for a modern setup, i.e. is GL expected to be sluggish/unusable in
rotated mode? Should I not use the 'rotate' feature at all, but rotate GL
geometries/textures myself, in my application? (that would be painful, I
guess).

Using kernel 2.6.28.3. Xorg, drm, mesa are from Fedora rawhide. The intel
driver is git HEAD. For the driver, it doesn't seem to make a difference
whether I specify UXA or not.

Cheers,

Rob

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg