Re: [Intel-gfx] [PATCH 2/4] drm/i915: Enable panel fitting for eDP
On Thu, 29 Jul 2010 10:58:53 +1000, Dave Airlie airl...@gmail.com wrote: did this patch go anywhere? We haven't forgotten it. It has been successfully tested by the bug reporter to have fixed the issue on his machine. When Eric did his last sweep of patches for Linus, we realised that it was based on drm-intel-next and so not ready to be pushed. -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3d performance very low
On Wed, Jul 28, 2010 at 23:29:02 +0200, Hanno Böck wrote: Am Mittwoch 28 Juli 2010 schrieb Matt Turner: On Wed, Jul 28, 2010 at 5:17 PM, Hanno Böck ha...@hboeck.de wrote: Hi, it seems I'm currently getting insanely slow 3d performance on my system. q3demo benchmark (run with ` to start console, timedemo 1, demo demo001) gives me 57 fps. I think even my old r200 got more than 100 there. From the logs everything seems to be fine. Any ideas what I could look for what's wrong here? kernel 2.6.34-rc6, xorg-server-1.8.2, xf86-video-intel-2.12.0,T61 laptop, card The most important piece of software here is Mesa. What version of Mesa? Sorry, I forgot, latest 7.8.2. When I tried Mesa 7.8 from Debian experimental I got stuttering 3D output, at least in neverball and glxgears. I tried libdrm2 2.4.18, 2.4.21, kernel 2.6.34, 2.6.35-rc5, and the Intel driver 2.11 and 2.12, without a change to the stuttering. The Xserver is 1.7.7. the FPS output in glxgears was even higher than with Mesa 7.7, but it looked ugly because of the stuttering. Do you have a chance to downgrade to Mesa 7.7? Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3d performance very low
Am Donnerstag 29 Juli 2010 schrieb Tino Keitel: When I tried Mesa 7.8 from Debian experimental I got stuttering 3D output, at least in neverball and glxgears. I tried libdrm2 2.4.18, 2.4.21, kernel 2.6.34, 2.6.35-rc5, and the Intel driver 2.11 and 2.12, without a change to the stuttering. The Xserver is 1.7.7. the FPS output in glxgears was even higher than with Mesa 7.7, but it looked ugly because of the stuttering. Do you have a chance to downgrade to Mesa 7.7? Tried 7.7.1, no change in performance. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de http://schokokeks.org - professional webhosting signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3d performance very low
On Thu, Jul 29, 2010 at 11:15 AM, Hanno Böck ha...@hboeck.de wrote: Am Donnerstag 29 Juli 2010 schrieb Tino Keitel: When I tried Mesa 7.8 from Debian experimental I got stuttering 3D output, at least in neverball and glxgears. I tried libdrm2 2.4.18, 2.4.21, kernel 2.6.34, 2.6.35-rc5, and the Intel driver 2.11 and 2.12, without a change to the stuttering. The Xserver is 1.7.7. the FPS output in glxgears was even higher than with Mesa 7.7, but it looked ugly because of the stuttering. Do you have a chance to downgrade to Mesa 7.7? Tried 7.7.1, no change in performance. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail: ha...@hboeck.de http://schokokeks.org - professional webhosting You're saying it's slow, but in relation to what? Were previous versions faster, or is the comparison being made between hardware? Matt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3d performance very low
Am Donnerstag, den 29.07.2010, 12:24 -0400 schrieb Matt Turner: On Thu, Jul 29, 2010 at 11:15 AM, Hanno Böck ha...@hboeck.de wrote: Am Donnerstag 29 Juli 2010 schrieb Tino Keitel: When I tried Mesa 7.8 from Debian experimental I got stuttering 3D output, at least in neverball and glxgears. I tried libdrm2 2.4.18, 2.4.21, kernel 2.6.34, 2.6.35-rc5, and the Intel driver 2.11 and 2.12, without a change to the stuttering. The Xserver is 1.7.7. the FPS output in glxgears was even higher than with Mesa 7.7, but it looked ugly because of the stuttering. Do you have a chance to downgrade to Mesa 7.7? Tried 7.7.1, no change in performance. You're saying it's slow, but in relation to what? Were previous versions faster, or is the comparison being made between hardware? In his original post he wrote that his old r200 card was faster in the q3demo benchmark [1]. Thanks, Paul [1] http://lists.freedesktop.org/archives/intel-gfx/2010-July/007538.html signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3d performance very low
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 29.07.2010 18:24, schrieb Matt Turner: You're saying it's slow, but in relation to what? Were previous versions faster, or is the comparison being made between hardware? Well I see the same problem here, using OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20100328 2010Q1 OpenGL version string: 2.1 Mesa 7.8.2 I get stuttering when scrolling in warzone2100. I've been using the same hardware for years, and the problem appeared some time this month, AFAIR around the time I upgraded Mesa from 7.7 to 7.8, but it could have some other cause. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxRvPUACgkQbtUV+xsoLpq+QACg7HqYAaBoVVjF/+dDcmfHeBD5 puYAoKab5N4Q2uFpjDKl5CRyQGiZstFq =CMrQ -END PGP SIGNATURE- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3d performance very low
Le 28/07/2010 23:17, Hanno Böck a écrit : Hi, it seems I'm currently getting insanely slow 3d performance on my system. q3demo benchmark (run with ` to start console, timedemo 1, demo demo001) gives me 57 fps. I think even my old r200 got more than 100 there. From the logs everything seems to be fine. Any ideas what I could look for what's wrong here? Sounds like you're hitting the vsync limit. I wouldn't know on my old 855 since no game/3D app ever gets close to 60fps anyway. Try comparing with glxgears: if it yields 60fps, then it's the vsync. If it's some other frame rate, then never mind. Cheers, Rémi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Submit batch buffers from flush callback chain
There are a few cases where the server will flush client output buffers
but our block handler only catches the most common (before going into select).
If the server flushes client buffers before we submit our batch buffer,
the client may receive a damage event for rendering that hasn't happened yet.
Instead, we can hook into the flush callback chain, which the server will
invoke just before flushing output. This lets us submit batch buffers
before sending out events, preserving ordering.
Fixes 28438: [bisected] incorrect character in gnome-terminal under compiz
https://bugs.freedesktop.org/show_bug.cgi?id=28438
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/intel_driver.c | 33 -
1 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/src/intel_driver.c b/src/intel_driver.c
index 7761ccf..d09c432 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -678,16 +678,8 @@ I830BlockHandler(int i, pointer blockData, pointer
pTimeout, pointer pReadmask)
intel-BlockHandler = screen-BlockHandler;
screen-BlockHandler = I830BlockHandler;
- if (scrn-vtSema) {
- /* Emit a flush of the rendering cache, or on the 965 and beyond
-* rendering results may not hit the framebuffer until
significantly
-* later.
-*/
- intel_batch_submit(scrn,
- intel-need_mi_flush ||
- !list_is_empty(intel-flush_pixmaps));
+ if (scrn-vtSema == TRUE)
drmCommandNone(intel-drmSubFD, DRM_I915_GEM_THROTTLE);
- }
intel_uxa_block_handler(intel);
intel_video_block_handler(intel);
@@ -787,6 +779,24 @@ int intel_crtc_to_pipe(xf86CrtcPtr crtc)
return drmmode_get_pipe_from_crtc_id(intel-bufmgr, crtc);
}
+static void
+intel_flush_callback(CallbackListPtr *list,
+pointer user_data, pointer call_data)
+{
+ ScrnInfoPtr scrn = user_data;
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+
+ if (scrn-vtSema) {
+ /* Emit a flush of the rendering cache, or on the 965
+* and beyond rendering results may not hit the
+* framebuffer until significantly later.
+*/
+ intel_batch_submit(scrn,
+ intel-need_mi_flush ||
+ !list_is_empty(intel-flush_pixmaps));
+ }
+}
+
static Bool
I830ScreenInit(int scrnIndex, ScreenPtr screen, int argc, char **argv)
{
@@ -955,6 +965,9 @@ I830ScreenInit(int scrnIndex, ScreenPtr screen, int argc,
char **argv)
intel-BlockHandler = screen-BlockHandler;
screen-BlockHandler = I830BlockHandler;
+ if (!AddCallback(FlushCallback, intel_flush_callback, scrn))
+ return FALSE;
+
screen-SaveScreen = xf86SaveScreen;
intel-CloseScreen = screen-CloseScreen;
screen-CloseScreen = I830CloseScreen;
@@ -1114,6 +1127,8 @@ static Bool I830CloseScreen(int scrnIndex, ScreenPtr
screen)
intel-front_buffer = NULL;
}
+ DeleteCallback(FlushCallback, intel_flush_callback, scrn);
+
intel_batch_teardown(scrn);
if (IS_I965G(intel))
--
1.7.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
