[Intel-gfx] [PATCH] uxa/glamor: Refine CloseScreen and InitScreen process.

2012-02-01 Thread zhigang . gong 
From: Zhigang Gong 

The previous version calls glamor_egl_close_screen and
glamor_egl_free_screen manually which is not align with
standard process. Now glamor change the way to follow
standard method:

glamor layer and glamor egl layer both have their internal
CloseScreens. The correct sequence is after the I830CloseScreen
is registered, then register glamor_egl_close_screen and
the last one is glamor_close_screen. So we move out the
intel_glamor_init from the intel_uxa_init to I830ScreenInit
and just after the registration of I830CloseScreen.

As the glamor interfaces changed, we need to check the
glamor version when load the glamor egl module to make
sure we are loading the right glamor module. If
failed, it will switch back to UXA path.

Signed-off-by: Zhigang Gong 
---
 src/intel_driver.c |3 +-
 src/intel_glamor.c |   66 +++
 src/intel_uxa.c|2 -
 uxa/uxa.h  |   10 ++-
 4 files changed, 44 insertions(+), 37 deletions(-)

diff --git a/src/intel_driver.c b/src/intel_driver.c
index 9d1c4e8..d66a8fd 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -1051,6 +1051,7 @@ I830ScreenInit(int scrnIndex, ScreenPtr screen, int argc, 
char **argv)
intel->CreateScreenResources = screen->CreateScreenResources;
screen->CreateScreenResources = i830CreateScreenResources;
 
+   intel_glamor_init(screen);
if (!xf86CrtcScreenInit(screen))
return FALSE;
 
@@ -1124,8 +1125,6 @@ static void I830FreeScreen(int scrnIndex, int flags)
ScrnInfoPtr scrn = xf86Screens[scrnIndex];
intel_screen_private *intel = intel_get_screen_private(scrn);
 
-   intel_glamor_free_screen(scrnIndex, flags);
-
if (intel) {
intel_mode_fini(intel);
intel_close_drm_master(intel);
diff --git a/src/intel_glamor.c b/src/intel_glamor.c
index e96daa6..446dd3d 100644
--- a/src/intel_glamor.c
+++ b/src/intel_glamor.c
@@ -61,20 +61,31 @@ intel_glamor_create_screen_resources(ScreenPtr screen)
 Bool
 intel_glamor_pre_init(ScrnInfoPtr scrn)
 {
+   pointer glamor_module;
intel_screen_private *intel;
+   CARD32 version;
intel = intel_get_screen_private(scrn);
 
/* Load glamor module */
-   if (xf86LoadSubModule(scrn, "glamor_egl") &&
-   glamor_egl_init(scrn, intel->drmSubFD)) {
-   xf86DrvMsg(scrn->scrnIndex, X_INFO,
-  "glamor detected, initialising\n");
-   intel->uxa_flags |= UXA_USE_GLAMOR;
-   } else {
+   if ((glamor_module = xf86LoadSubModule(scrn, "glamor_egl"))) {
+   version = xf86GetModuleVersion(glamor_module);
+   if (version < MODULE_VERSION_NUMERIC(0,3,0)) {
+   xf86DrvMsg(scrn->scrnIndex, X_ERROR,
+   "Incompatible glamor version, required >= 0.3.0.\n");
+   }
+   else {
+   if (glamor_egl_init(scrn, intel->drmSubFD)) {
+   xf86DrvMsg(scrn->scrnIndex, X_INFO,
+  "glamor detected, initialising egl 
layer.\n");
+   intel->uxa_flags = UXA_GLAMOR_EGL_INITIALIZED;
+   }
+   else
+   xf86DrvMsg(scrn->scrnIndex, X_WARNING,
+  "glamor detected, failed to 
initialize egl.\n");
+   }
+   } else
xf86DrvMsg(scrn->scrnIndex, X_WARNING,
   "glamor not available\n");
-   intel->uxa_flags &= ~UXA_USE_GLAMOR;
-   }
 
return TRUE;
 }
@@ -83,7 +94,13 @@ PixmapPtr
 intel_glamor_create_pixmap(ScreenPtr screen, int w, int h,
   int depth, unsigned int usage)
 {
-   return glamor_create_pixmap(screen, w, h, depth, usage);
+   ScrnInfoPtr scrn = xf86Screens[screen->myNum];
+   intel_screen_private *intel = intel_get_screen_private(scrn);
+
+   if (intel->uxa_flags & UXA_USE_GLAMOR)
+   return glamor_create_pixmap(screen, w, h, depth, usage);
+   else
+   return NULL;
 }
 
 Bool
@@ -145,17 +162,16 @@ intel_glamor_finish_access(PixmapPtr pixmap, uxa_access_t 
access)
return;
 }
 
-
 Bool
 intel_glamor_init(ScreenPtr screen)
 {
ScrnInfoPtr scrn = xf86Screens[screen->myNum];
intel_screen_private *intel = intel_get_screen_private(scrn);
 
-   if ((intel->uxa_flags & UXA_USE_GLAMOR) == 0)
-   return TRUE;
+   if ((intel->uxa_flags & UXA_GLAMOR_EGL_INITIALIZED) == 0)
+   goto fail;
 
-   if (!glamor_init(screen, GLAMOR_INVERTED_Y_AXIS)) {
+   if (!glamor_init(screen, GLAMOR_INVERTED_Y_AXIS | 
GLAMOR_USE_EGL_SCREEN)) {
xf86DrvMsg(scrn->scrnIndex, X_ERROR,
   "Failed to initialize glamor\n");
goto fail;
@@ -168,7 +184,7 @@ intel_glam

Re: [Intel-gfx] VAAPI (master or ext) no deinterlacing with Clarkdale GPU

2012-02-01 Thread alanwww1 
Hi  Christoph !

For the stuttering problem it is cause by lack of shader horse power to use
HQ upsacling AND deinterlacing together.
Please try to set the upscaler from auto to "bilinear" or even "nearest" at
the worst case.
Also if you are using xbmc in a composited environment please turn off all
compositing or even try to run xbmc in a separate Xsession.

If that does not help, you probably will never have it working stutter-free
with Clarkdale.

Cheers,

Attila (Team XBMC)

2012/2/1 Xiang, Haihao 

> Hi,
>
>   I know what is the problem. For some reason, the native pixel format
> for MPEG-2 decoding on Clarkdale is I420, however the input pixel format
> of deinterlacing is NV12 in the driver, so the driver doesn't support
> deinterlacing for MPEG-2 on Clardale. We will try to fix this issue but
> don't expect it too soon.
>
> BTW you can send all VAAPI related mail to li...@lists.freedesktop.org
> as well.
>
> Thanks
> Haihao
>
> > Atechsystem  freenet.de> writes:
> >
> > >
> > >
> > > Hello,
> > >
> > > I’ve written an email to Haihao Xiang regarding the “no deinterlacing”
> bug on
> > Clarkdale a week ago and he answered today. He will check this issue.
> I’ll hope
> > he can fix it. Will the extended vaapi-ext deinterlacers (temporal or
> spatial I
> > guess) also be available on Clarkdale platform? I tried the extended DXVA
> > hardware deinterlacing on Windows today and it worked fine on my CoreI3
> > Clarkdale Laptop CPU J
> > >
> > > Best regards
> > > Atech
> >
> >
> > Hi Atech,
> >
> > same problem over here. I am on vaapi-ext and latest xbmc. I can select
> Bob and
> > Bob (inverted) as deinterlacers in xbmc. With MPEG2 material
> deinterlacing
> > doesn't work at all. With H.264 video it seems to deinterlace, but video
> is
> > stuttering and I have lots of frame drops.
> >
> > Hardware: Core i3 530
> > Software: Ubuntu 11.11 x86 minimal with latest xorg stuff (edgers:ppa)
> and
> > vaapi-ext branch for libva and intel-vaapi
> >
> > Regards,
> > Christoph / Flachzange
> >
> >
> >
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] VAAPI (master or ext) no deinterlacing with Clarkdale GPU

2012-02-01 Thread Christoph Evers 

Hi Attila!

Am 01.02.2012 13:16, schrieb alanwww1:

Hi  Christoph !

For the stuttering problem it is cause by lack of shader horse power 
to use HQ upsacling AND deinterlacing together.


Yes, I noticed this in the meanwhile. GPU top showed me 100% usage :-)

Please try to set the upscaler from auto to "bilinear" or even 
"nearest" at the worst case.


It already was bilinear, but even nearest does not help

Also if you are using xbmc in a composited environment please turn off 
all compositing or even try to run xbmc in a separate Xsession.


No composite environment, but openbox window manager


If that does not help, you probably will never have it working 
stutter-free with Clarkdale.




Yes probably, even with mplayer no chance (68% framedrops)

Thanks!
Christoph

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Ironlake eDP training broken in 3.2.2

2012-02-01 Thread Ben Guthro 
I'm moving my company's distro from 2.6.38 to 3.2.X  (currently 3.2.2)
- and have found a regression in i915 that I'm hoping someone here
might have a fix for, already.

On some older platforms, I'm seeing the stack below that results in
the screen never showing anything.

Any thoughts, patches, suggestions are appreciated.

- Ben Guthro


[   28.064432] [ cut here ]
[   28.064468] WARNING: at
/builds/orc-precise/linux-3.2/drivers/gpu/drm/i915/intel_dp.c:1071
ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]()
[   28.064472] Hardware name: Latitude E5510
[   28.064474] eDP VDD not forced on
[   28.064475] Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4
nf_conntrack scst_vdisk(O) nf_defrag_ipv4 crc32c ip_tables libcrc32c
x_tables scst_cdrom(O) scst(O) bridge stp llc microcode iscsi_tcp
libiscsi_tcp libiscsi scsi_transport_iscsi nfsd arc4 exportfs nfs
snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec lockd
iwlwifi(O) fscache auth_rpcgss psmouse snd_hwdep nfs_acl snd_pcm
dell_laptop dell_wmi serio_raw snd_timer sparse_keymap dcdbas snd
mac80211(O) sunrpc soundcore snd_page_alloc intel_ips ppdev
cfg80211(O) parport_pc parport tpm_tis tpm tpm_bios usbhid hid zram(C)
i915 tg3 ehci_hcd sdhci_pci sdhci drm_kms_helper drm intel_agp
i2c_algo_bit intel_gtt video
[   28.064546] Pid: 309, comm: plymouthd Tainted: GWC O 3.2.2-orc #1
[   28.064548] Call Trace:
[   28.064557]  [] warn_slowpath_common+0x7f/0xc0
[   28.064561]  [] warn_slowpath_fmt+0x46/0x50
[   28.064573]  [] ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]
[   28.064584]  [] intel_dp_commit+0x4f/0xb0 [i915]
[   28.064590]  []
drm_crtc_helper_set_mode+0x4eb/0x520 [drm_kms_helper]
[   28.064597]  []
drm_crtc_helper_set_config+0x83f/0xaf0 [drm_kms_helper]
[   28.064603]  []
drm_fb_helper_restore_fbdev_mode+0x40/0x60 [drm_kms_helper]
[   28.064614]  [] intel_fb_restore_mode+0x1c/0x50 [i915]
[   28.064623]  [] i915_driver_lastclose+0x39/0x80 [i915]
[   28.064635]  [] drm_lastclose+0x49/0x300 [drm]
[   28.064643]  [] drm_release+0x4fd/0x6c0 [drm]
[   28.064648]  [] fput+0xea/0x220
[   28.064651]  [] filp_close+0x66/0x90
[   28.064654]  [] sys_close+0xb2/0x120
[   28.064660]  [] system_call_fastpath+0x16/0x1b
[   28.064662] ---[ end trace 4d53f99c84fca531 ]---
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Ironlake eDP training broken in 3.2.2

2012-02-01 Thread Ben Guthro 
FWIW, I found the following patch that seems to solve the issue, on
this platform:

https://bugs.freedesktop.org/attachment.cgi?id=56178

linked from:
https://bugs.freedesktop.org/show_bug.cgi?id=42263

I was unable to find this committed in any of the dev trees, however.

Does this have any known issues on other platforms?



On Wed, Feb 1, 2012 at 10:17 AM, Ben Guthro  wrote:
> I'm moving my company's distro from 2.6.38 to 3.2.X  (currently 3.2.2)
> - and have found a regression in i915 that I'm hoping someone here
> might have a fix for, already.
>
> On some older platforms, I'm seeing the stack below that results in
> the screen never showing anything.
>
> Any thoughts, patches, suggestions are appreciated.
>
> - Ben Guthro
>
>
> [   28.064432] [ cut here ]
> [   28.064468] WARNING: at
> /builds/orc-precise/linux-3.2/drivers/gpu/drm/i915/intel_dp.c:1071
> ironlake_edp_panel_vdd_off+0xbf/0xd0 [i915]()
> [   28.064472] Hardware name: Latitude E5510
> [   28.064474] eDP VDD not forced on
> [   28.064475] Modules linked in: iptable_nat nf_nat nf_conntrack_ipv4
> nf_conntrack scst_vdisk(O) nf_defrag_ipv4 crc32c ip_tables libcrc32c
> x_tables scst_cdrom(O) scst(O) bridge stp llc microcode iscsi_tcp
> libiscsi_tcp libiscsi scsi_transport_iscsi nfsd arc4 exportfs nfs
> snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_intel snd_hda_codec lockd
> iwlwifi(O) fscache auth_rpcgss psmouse snd_hwdep nfs_acl snd_pcm
> dell_laptop dell_wmi serio_raw snd_timer sparse_keymap dcdbas snd
> mac80211(O) sunrpc soundcore snd_page_alloc intel_ips ppdev
> cfg80211(O) parport_pc parport tpm_tis tpm tpm_bios usbhid hid zram(C)
> i915 tg3 ehci_hcd sdhci_pci sdhci drm_kms_helper drm intel_agp
> i2c_algo_bit intel_gtt video
> [   28.064546] Pid: 309, comm: plymouthd Tainted: G        WC O 3.2.2-orc #1
> [   28.064548] Call Trace:
> [   28.064557]  [] warn_slowpath_common+0x7f/0xc0
> [   28.064561]  [] warn_slowpath_fmt+0x46/0x50
> [   28.064573]  [] ironlake_edp_panel_vdd_off+0xbf/0xd0 
> [i915]
> [   28.064584]  [] intel_dp_commit+0x4f/0xb0 [i915]
> [   28.064590]  []
> drm_crtc_helper_set_mode+0x4eb/0x520 [drm_kms_helper]
> [   28.064597]  []
> drm_crtc_helper_set_config+0x83f/0xaf0 [drm_kms_helper]
> [   28.064603]  []
> drm_fb_helper_restore_fbdev_mode+0x40/0x60 [drm_kms_helper]
> [   28.064614]  [] intel_fb_restore_mode+0x1c/0x50 [i915]
> [   28.064623]  [] i915_driver_lastclose+0x39/0x80 [i915]
> [   28.064635]  [] drm_lastclose+0x49/0x300 [drm]
> [   28.064643]  [] drm_release+0x4fd/0x6c0 [drm]
> [   28.064648]  [] fput+0xea/0x220
> [   28.064651]  [] filp_close+0x66/0x90
> [   28.064654]  [] sys_close+0xb2/0x120
> [   28.064660]  [] system_call_fastpath+0x16/0x1b
> [   28.064662] ---[ end trace 4d53f99c84fca531 ]---
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Ironlake eDP training broken in 3.2.2

2012-02-01 Thread Daniel Vetter 
On Wed, Feb 01, 2012 at 11:48:07AM -0500, Ben Guthro wrote:
> FWIW, I found the following patch that seems to solve the issue, on
> this platform:
> 
> https://bugs.freedesktop.org/attachment.cgi?id=56178
> 
> linked from:
> https://bugs.freedesktop.org/show_bug.cgi?id=42263
> 
> I was unable to find this committed in any of the dev trees, however.
> 
> Does this have any known issues on other platforms?

This patch is simply still under review and testing, so if you can, please
test it. You need the latest drm-intel-fixes branch from:

https://git.kernel.org/?p=linux/kernel/git/keithp/linux.git;a=summary

Then apply the patch you've linked to manually. If that does not help,
please file a new bug report on bugs.freedesktop.org against drm/intel.
Atm many people are already travelling to fosdem, so it could get lost.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Libva] FW: vaapi intel-driver (vaapi-ext): assertion failed

2012-02-01 Thread atechsystem 
Hello,

i can reproduce this issue as he described. If I follow his instructions i get 
interlaced mpeg2 output with wrong colors (also with mplayer-vaapi). But i 
cannnot reproduce the "xine: i965_drv_video.c:2075:> 
i965_check_alloc_surface_bo: assertion" error with non changed vaapi-ext 
suorces. I don't get this error displayed.

Meanwhile i checked vaap-ext deinterlacing output with h264 i file Slices from 
here:

http://www.avsforum.com/avs-vb/showthread.php?p=16900173#post16900173

XBMC and mplayer-vaapi show deinterlaced output with many framedrops (Christoph 
Evers allready reported). I checked it on my I3 540 and I5 661 CPU's but even 
the faster CPU with 900MHZ videoclock is too slow. 

Regards
Atech 



> -Ursprüngliche Nachricht-
> Von: Xiang Haihao 
> Gesendet: Wed. 01.02.2012 03:34
> An: atechsys...@freenet.de
> Kopie: li...@lists.freedesktop.org
> Betreff: Re: [Libva] FW: [Intel-gfx] vaapi intel-driver (vaapi-ext): 
> assertion failed
>
> On Wed, 2012-02-01 at 10:32 +0800, Xiang, Haihao wrote: 
> > On Tue, 2012-01-31 at 22:48 +0100, atechsys...@freenet.de wrote: 
> > > Hello,
> > >
> > > I forward it to the vaapi mailinglist to get sure. 
> > >
> > > I will try to reproduce this attitude to check if I get also
> deinterlaced output with or without the wrong color space. Till now
> I've not seen the "xine: i965_drv_video.c:2075:
> i965_check_alloc_surface_bo: assertion" error message,
> >
> > Do you mean you can reproduce this issue any more? I can't
> reproduce
>  ^ 
>typo :(, can not
>
>
> > this issue with other players, such as VLC, mplayer.
> >
> > > only non interlaced output. 
> >
> > Yes for MPEG-2 video.
> >
> >
> > >
> > > Best regards
> > > Atech 
> > >
> > > > > -weitergeleitete Nachricht-
> > > > > Von: Christoph Evers 
> > > > > Gesendet: Tue. 31.01.2012 17:32
> > > > > An: intel-gfx@lists.freedesktop.org
> > > > > Betreff: [Intel-gfx] vaapi intel-driver (vaapi-ext):
> assertion
> > > > failed
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > i am not sure whether this issue belongs to the libva
> mailinglist
> > > > or
> > > > > this one. I'll give it a try :-)
> > > > >
> > > > > For testing purpose I switched to vaapi-ext branch of
> intel-driver
> > > > > and
> > > > > libva (master is working fine).
> > > > >
> > > > > I am using xine-lib-vaapi for playback with xine which uses a
> > > > vaapi
> > > > > accelerated ffmpeg: https://github.com/huceke/xine-lib-vaapi
> > > > >
> > > > > H.264 (non interlaced) files are played fine, but with MPEG2
> > > > > (interlaced/non-interlaced) the vaapi intel driver throws an
> > > > > exception:
> > > > >
> > > > > > xine: i965_drv_video.c:2075: i965_check_alloc_surface_bo:
> > > > assertion
> > > > > > obj_surface->fourcc == fourcc failed.
> > > > >
> > > > > Obviously, the obj_surface fourcc (NV12) does not fit to the
> > > > fourcc
> > > > > of
> > > > > the media (I420).
> > > > >
> > > > > If I force NV12 in i965_media_mpeg2.c:517 playback is working
> > > > (even
> > > > > deinterlaced on Clarkdale) but naturally with the wrong color
> > > > space.
> > > > >
> > > > > Do you guys have any idea?
> > > > >
> > > > > Christoph
> > > > >
> > > > > Hardware: Core i3 530
> > > > > Software: Ubuntu 11.11 x86 minimal with latest xorg stuff
> > > > > (edgers:ppa) and
> > > > > vaapi-ext branch for libva and intel-vaapi (git 30012012)
> > > > >
> > > > >
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > >
> > > > >
> > > > > -weitergeleitete Nachricht Ende-
> > > >
> > > >
> > > >
> > > >
> > > > ---
> > > > Nutzen Sie freenet Mail optimal angepasst für Ihr iPhone,
> Android
> > > > oder Nokia Handy auch von unterwegs.
> > > > Alle Infos und Download unter
> > > > http://mail.freenet.de/mobile-email/index.html
> > > >
> > > >
> > > > -weitergeleitete Nachricht Ende-
> > >
> > >
> > >
> > >
> > > ---
> > > E-Mail ist da wo du bist! Jetzt mit freenetMail ganz bequem auch
> unterwegs E-Mails verschicken.
> > > Am besten gleich informieren unter
> http://mail.freenet.de/mobile-email/index.html
> > > ___
> > > Libva mailing list
> > > li...@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/libva
> >
> >
> > ___
> > Libva mailing list
> > li...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libva
>
>
> ___
> Libva mailing list
> li...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libva>
>
> -Ursprüngliche Nachricht Ende-




---
Nutzen Sie freenet Mail optimal angepasst für Ihr iPhone, Android oder Nokia 
Handy auch von unterwegs.
Alle Infos und Download unter http://mail.freenet.de/mobile-email/index.html

[Intel-gfx] FW: RE: Re: VAAPI (master or ext) no deinterlacing with Clarkdale GPU

2012-02-01 Thread atechsystem 
Hello,

I tried the same (Slicies H.264 PAL 1080i-25.ts):

Unsupported PixelFormat 61
[VD_FFMPEG] Trying pixfmt=1.
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vaapi] 1920x1080 => 1920x1080 H.264 
VA-API Acceleration 
[VD_FFMPEG] XVMC-accelerated MPEG-2.> A: 622.5 V: 633.8 A-V:-11.267 ct: -2.039 
844/844 21% 78% 0.1% 417 0 
TS_PARSE: COULDN'T SYNC
A: 633.5 V: 633.8 A-V: -0.320 ct:-13.047 844/844 21% 78% 0.2% 417 0 


BENCHMARKs: VC: 4.482s VO: 16.106s A: 0.042s Sys: 12.851s = 33.481s
BENCHMARK%: VC: 13.3871% VO: 48.1047% A: 0.1253% Sys: 38.3829% =
100.%
BENCHMARKn: disp: 427 (12.75 fps) drop: 417 (49%) total: 844 (25.21
fps)

Exiting... (End of file)

 49% framedrops on my I5 661. 

I tested this file also on my Arrandale i3 350 and it worked pretty
well with windows 7 xbmc and dxva deinterlacing only 7 framedrops at beginning.

Best regards
Atech
 
> > -Ursprüngliche Nachricht-
> > Von: Christoph Evers 
> > Gesendet: Wed. 01.02.2012 14:01
> > An: alanwww1 
> > Kopie: intel-gfx@lists.freedesktop.org
> > Betreff: Re: [Intel-gfx] VAAPI (master or ext) no deinterlacing
> with Clarkdale GPU
> >
> > Hi Attila!
> >
> > Am 01.02.2012 13:16, schrieb alanwww1:
> > > Hi  Christoph !
> > >
> > > For the stuttering problem it is cause by lack of shader horse
> > power
> > > to use HQ upsacling AND deinterlacing together.
> >
> > Yes, I noticed this in the meanwhile. GPU top showed me 100% usage
> > :-)
> >
> > > Please try to set the upscaler from auto to "bilinear" or even
> > > "nearest" at the worst case.
> >
> > It already was bilinear, but even nearest does not help
> >
> > > Also if you are using xbmc in a composited environment please
> turn
> > off
> > > all compositing or even try to run xbmc in a separate Xsession.
> >
> > No composite environment, but openbox window manager
> > >
> > > If that does not help, you probably will never have it working
> > > stutter-free with Clarkdale.
> > >
> >
> > Yes probably, even with mplayer no chance (68% framedrops)
> >
> > Thanks!
> > Christoph
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> > -Ursprüngliche Nachricht Ende-
>
>
>
>
> ---
> Nutzen Sie freenet Mail optimal angepasst für Ihr iPhone, Android
> oder Nokia Handy auch von unterwegs.
> Alle Infos und Download unter
> http://mail.freenet.de/mobile-email/index.html
>
>
> -weitergeleitete Nachricht Ende-




---
Nutzen Sie freenet Mail optimal angepasst für Ihr iPhone, Android oder Nokia 
Handy auch von unterwegs.
Alle Infos und Download unter http://mail.freenet.de/mobile-email/index.html

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: dump even more into the error_state

2012-02-01 Thread Daniel Vetter 
Chris Wilson and me have again stared at funny error states and it's
been pretty clear from the start that something was seriously amiss.
The seqnos last seen by the cpu were a few hundred behind those that
the gpu could have possibly emitted last before it died ...

Chris now tracked it down (hopefully, definit verdict's still out),
but in hindsight we'd have found the bug by simply dumping the cpu
side tracking of the ring head and tail registers.

Fix this and prevent an identical time-waster in the future.

Because the hangs always involved semaphores in one way or another,
we've tried to dump the mbox registers, but couldn't find any
inconsistencies. Still, dump them too.

Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |6 ++
 drivers/gpu/drm/i915/i915_drv.h |4 
 drivers/gpu/drm/i915/i915_irq.c |7 +++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 681cbe4..e9eeacb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -721,8 +721,14 @@ static void i915_ring_error_state(struct seq_file *m,
if (INTEL_INFO(dev)->gen >= 6) {
seq_printf(m, "  FADDR: 0x%08x\n", error->faddr[ring]);
seq_printf(m, "  FAULT_REG: 0x%08x\n", error->fault_reg[ring]);
+   seq_printf(m, "  SYNC_0: 0x%08x\n",
+  error->semaphore_mboxes[ring][0]);
+   seq_printf(m, "  SYNC_1: 0x%08x\n",
+  error->semaphore_mboxes[ring][1]);
}
seq_printf(m, "  seqno: 0x%08x\n", error->seqno[ring]);
+   seq_printf(m, "  ring->head: 0x%08x\n", error->cpu_ring_head[ring]);
+   seq_printf(m, "  ring->tail: 0x%08x\n", error->cpu_ring_tail[ring]);
 }
 
 static int i915_error_state(struct seq_file *m, void *unused)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 865de80..1eb3b9a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -159,6 +159,10 @@ struct drm_i915_error_state {
u32 ipehr[I915_NUM_RINGS];
u32 instdone[I915_NUM_RINGS];
u32 acthd[I915_NUM_RINGS];
+   u32 semaphore_mboxes[I915_NUM_RINGS][I915_NUM_RINGS - 1];
+   /* our own tracking of ring head and tail */
+   u32 cpu_ring_head[I915_NUM_RINGS];
+   u32 cpu_ring_tail[I915_NUM_RINGS];
u32 error; /* gen6+ */
u32 instpm[I915_NUM_RINGS];
u32 instps[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8ea1ca4..cde1ce9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -903,6 +903,10 @@ static void i915_record_ring_state(struct drm_device *dev,
if (INTEL_INFO(dev)->gen >= 6) {
error->faddr[ring->id] = 
I915_READ(RING_DMA_FADD(ring->mmio_base));
error->fault_reg[ring->id] = I915_READ(RING_FAULT_REG(ring));
+   error->semaphore_mboxes[ring->id][0]
+   = I915_READ(RING_SYNC_0(ring->mmio_base));
+   error->semaphore_mboxes[ring->id][1]
+   = I915_READ(RING_SYNC_1(ring->mmio_base));
}
 
if (INTEL_INFO(dev)->gen >= 4) {
@@ -925,6 +929,9 @@ static void i915_record_ring_state(struct drm_device *dev,
error->acthd[ring->id] = intel_ring_get_active_head(ring);
error->head[ring->id] = I915_READ_HEAD(ring);
error->tail[ring->id] = I915_READ_TAIL(ring);
+
+   error->cpu_ring_head[ring->id] = ring->head;
+   error->cpu_ring_tail[ring->id] = ring->tail;
 }
 
 /**
-- 
1.7.8.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: swizzling support for snb/ivb

2012-02-01 Thread Ben Widawsky 
On 01/31/2012 07:47 AM, Daniel Vetter wrote:
> We have to do this manually. Somebody had a Great Idea.
> 
> I've measured speed-ups just a few percent above the noise level
> (below 5% for the best case), but no slowdows. Chris Wilson measured
> quite a bit more (10-20% above the usual snb variance) on a more
> recent and better tuned version of sna, but also recorded a few
> slow-downs on benchmarks know for uglier amounts of snb-induced
> variance.
> 
> v2: Incorporate Ben Widawsky's preliminary review comments and
> elaborate a bit about the performance impact in the changelog.
> 
> Acked-by: Chris Wilson 
> Signed-Off-by: Daniel Vetter 

You didn't address one questions I really cared about, how is it safe to
ignore channel 3 size? While I'm at it, I wonder what is in these
registers if you have less than 256MB. If the answer is zero, then your
check isn't safe enough below.

As an aside, this will potentially break our simulation environment, but
that's environment fail.

> ---
>  drivers/gpu/drm/i915/i915_dma.c|2 +-
>  drivers/gpu/drm/i915/i915_drv.c|4 ++-
>  drivers/gpu/drm/i915/i915_drv.h|3 +-
>  drivers/gpu/drm/i915/i915_gem.c|   23 +++-
>  drivers/gpu/drm/i915/i915_gem_tiling.c |   16 +-
>  drivers/gpu/drm/i915/i915_reg.h|   34 
> 
>  6 files changed, 75 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3f27173..dfef956 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1208,7 +1208,7 @@ static int i915_load_gem_init(struct drm_device *dev)
>   i915_gem_do_init(dev, 0, mappable_size, gtt_size - PAGE_SIZE);
>  
>   mutex_lock(&dev->struct_mutex);
> - ret = i915_gem_init_ringbuffer(dev);
> + ret = i915_gem_init_hw(dev);
>   mutex_unlock(&dev->struct_mutex);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1658cfd..12ddf47 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -495,7 +495,7 @@ static int i915_drm_thaw(struct drm_device *dev)
>   mutex_lock(&dev->struct_mutex);
>   dev_priv->mm.suspended = 0;
>  
> - error = i915_gem_init_ringbuffer(dev);
> + error = i915_gem_init_hw(dev);
>   mutex_unlock(&dev->struct_mutex);
>  
>   if (HAS_PCH_SPLIT(dev))
> @@ -686,6 +686,8 @@ int i915_reset(struct drm_device *dev, u8 flags)
>   !dev_priv->mm.suspended) {
>   dev_priv->mm.suspended = 0;
>  
> + i915_gem_init_swizzling(dev);
> +
>   dev_priv->ring[RCS].init(&dev_priv->ring[RCS]);
>   if (HAS_BSD(dev))
>   dev_priv->ring[VCS].init(&dev_priv->ring[VCS]);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 865de80..0845419 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1187,7 +1187,8 @@ int __must_check i915_gem_object_set_domain(struct 
> drm_i915_gem_object *obj,
>   uint32_t read_domains,
>   uint32_t write_domain);
>  int __must_check i915_gem_object_finish_gpu(struct drm_i915_gem_object *obj);
> -int __must_check i915_gem_init_ringbuffer(struct drm_device *dev);
> +int __must_check i915_gem_init_hw(struct drm_device *dev);
> +void i915_gem_init_swizzling(struct drm_device *dev);
>  void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
>  void i915_gem_do_init(struct drm_device *dev,
> unsigned long start,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 51a2b0c..86fffd2 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3681,12 +3681,31 @@ i915_gem_idle(struct drm_device *dev)
>   return 0;
>  }
>  
> +void i915_gem_init_swizzling(struct drm_device *dev)
> +{
> + drm_i915_private_t *dev_priv = dev->dev_private;
> +
> + if (INTEL_INFO(dev)->gen < 6 ||
> + dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
> + return;
> +
> + I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
> +  DISP_TILE_SURFACE_SWIZZLING);
> +
> + I915_WRITE(TILECTL, I915_READ(TILECTL) | TILECTL_SWZCTL);
> + if (IS_GEN6(dev))
> + I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_SNB));
> + else
> + I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_IVB));
> +}
>  int
> -i915_gem_init_ringbuffer(struct drm_device *dev)
> +i915_gem_init_hw(struct drm_device *dev)
>  {
>   drm_i915_private_t *dev_priv = dev->dev_private;
>   int ret;
>  
> + i915_gem_init_swizzling(dev);
> +
>   ret = intel_init_render_ring_buffer(dev);
>

Re: [Intel-gfx] [PATCH 2/3] drm/i915: consolidate swizzling control bit frobbing

2012-02-01 Thread Ben Widawsky 
On Tue, Jan 31, 2012 at 04:47:55PM +0100, Daniel Vetter wrote:
> On gen5 we also need to correctly set up swizzling in the display
> scanout engine, but only there. Consolidate this into the same
> function.
> 
> This has a small effect on ums setups - the kernel now also sets this
> bit in addition to userspace setting it. Given that this code only
> runs when userspace either can't (resume, gpu reset) or explicitly
> won't(gem_init) touch the hw this shouldn't have an adverse effect.
> 
> Signed-Off-by: Daniel Vetter 
> ---

Have you tested this well?
From bspec:
Note: For ILK Display Engine can(?) implement the A[6] swizzling
structure however it will not be used – corresponding bits will be set
to “00”
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: dump even more into the error_state

2012-02-01 Thread Chris Wilson 
On Wed,  1 Feb 2012 22:26:45 +0100, Daniel Vetter  
wrote:
> Chris Wilson and me have again stared at funny error states and it's
> been pretty clear from the start that something was seriously amiss.
> The seqnos last seen by the cpu were a few hundred behind those that
> the gpu could have possibly emitted last before it died ...
> 
> Chris now tracked it down (hopefully, definit verdict's still out),
> but in hindsight we'd have found the bug by simply dumping the cpu
> side tracking of the ring head and tail registers.
> 
> Fix this and prevent an identical time-waster in the future.
> 
> Because the hangs always involved semaphores in one way or another,
> we've tried to dump the mbox registers, but couldn't find any
> inconsistencies. Still, dump them too.
> 
> Signed-Off-by: Daniel Vetter 
Reviewed-and-wanted-by: Chris Wilson 
-Chris

-- 
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] [PATCH 3/3] drm/i915: add gen6+ registers to i915_swizzle_info

2012-02-01 Thread Ben Widawsky 
On Tue, Jan 31, 2012 at 04:47:56PM +0100, Daniel Vetter wrote:
> Signed-Off-by: Daniel Vetter 
Reviewed-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |   13 +
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 681cbe4..4ebca6d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1422,6 +1422,19 @@ static int i915_swizzle_info(struct seq_file *m, void 
> *data)
>  I915_READ16(C0DRB3));
>   seq_printf(m, "C1DRB3 = 0x%04x\n",
>  I915_READ16(C1DRB3));
> + } else if (IS_GEN6(dev) || IS_GEN7(dev)) {
> + seq_printf(m, "MAD_DIMM_C0 = 0x%08x\n",
> +I915_READ(MAD_DIMM_C0));
> + seq_printf(m, "MAD_DIMM_C1 = 0x%08x\n",
> +I915_READ(MAD_DIMM_C1));
> + seq_printf(m, "MAD_DIMM_C2 = 0x%08x\n",
> +I915_READ(MAD_DIMM_C2));
> + seq_printf(m, "TILECTL = 0x%08x\n",
> +I915_READ(TILECTL));
> + seq_printf(m, "ARB_MODE = 0x%08x\n",
> +I915_READ(ARB_MODE));
> + seq_printf(m, "DISP_ARB_CTL = 0x%08x\n",
> +I915_READ(DISP_ARB_CTL));
>   }
>   mutex_unlock(&dev->struct_mutex);
>  
> -- 
> 1.7.7.5
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: swizzling support for snb/ivb

2012-02-01 Thread Daniel Vetter 
On Wed, Feb 01, 2012 at 01:35:14PM -0800, Ben Widawsky wrote:
> On 01/31/2012 07:47 AM, Daniel Vetter wrote:
> > We have to do this manually. Somebody had a Great Idea.
> > 
> > I've measured speed-ups just a few percent above the noise level
> > (below 5% for the best case), but no slowdows. Chris Wilson measured
> > quite a bit more (10-20% above the usual snb variance) on a more
> > recent and better tuned version of sna, but also recorded a few
> > slow-downs on benchmarks know for uglier amounts of snb-induced
> > variance.
> > 
> > v2: Incorporate Ben Widawsky's preliminary review comments and
> > elaborate a bit about the performance impact in the changelog.
> > 
> > Acked-by: Chris Wilson 
> > Signed-Off-by: Daniel Vetter 
> 
> You didn't address one questions I really cared about, how is it safe to
> ignore channel 3 size? While I'm at it, I wonder what is in these
> registers if you have less than 256MB. If the answer is zero, then your
> check isn't safe enough below.

Hm, I've thought I've answered that in the mail to your review: 3 channel
ddr configurations only exists on i7 chips without a gpu attached.
Furthermore swizzling is only sensible when we have 2 channels anyway.

For the other issue, I suspect 256mb is simply the smallest dimm you can
buy for ddr3 - I don't have the spec for that though, but the smallest
dimm my local supplier sells is 512mb, anyway ;-)

> As an aside, this will potentially break our simulation environment, but
> that's environment fail.

I think we can quirk that by detecting has or something like that ...

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/8] interlaced support v2

2012-02-01 Thread Angela Schmid 
Hello Daniel

I also want to confirm that interlacing is working over HDMI with 
1920x1080i@50hz for Sandy Bridge 2600k. Thanks a lot.

The fixes are not part of the intel gfx driver, correct ?
When will it be pushed and to which kernel release will it presumably be 
addressed to.

Angela


> -Original Message-
> From: intel-gfx-bounces+angela.schmid=wolke7@lists.freedesktop.org 
> [mailto:intel-gfx-
> bounces+angela.schmid=wolke7@lists.freedesktop.org] On Behalf Of Alfonso 
> Fiore
> Sent: 28 January 2012 19:30
> To: Daniel Vetter
> Cc: Intel Graphics Development
> Subject: Re: [Intel-gfx] [PATCH 0/8] interlaced support v2
> 
> On Sat, Jan 28, 2012 at 2:49 PM, Daniel Vetter  wrote:
> > Hi all,
> >
> > These are the patches I'd like to queue to -next for interlaced support. 
> > Needs
> > the patch "fixup interlaced bits clearing in PIPECONF on PCH_SPLIT" and 
> > also the
> > drm core fix "drm/modes: do not enforce an odd vtotal for interlaced modes" 
> > if
> > you want to use interlaced modelines with an even vtotal.
> >
> > The entire series is available in my interlaced branch at
> >
> > http://cgit.freedesktop.org/~danvet/drm/log/?h=interlaced
> >
> > Review, comments and testing highly welcome.
> 
> Tested-by: Alfonso Fiore 
> 
> i3 2130 connected to a Philips 32pf9731d over HDMI:
> - 1920x1080i@30Hz
> - 1280x720p@60Hz
> - 1024x768p@60Hz
> 
> thanks again,
> alfonso
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: consolidate swizzling control bit frobbing

2012-02-01 Thread Daniel Vetter 
On Wed, Feb 01, 2012 at 01:37:29PM -0800, Ben Widawsky wrote:
> On Tue, Jan 31, 2012 at 04:47:55PM +0100, Daniel Vetter wrote:
> > On gen5 we also need to correctly set up swizzling in the display
> > scanout engine, but only there. Consolidate this into the same
> > function.
> > 
> > This has a small effect on ums setups - the kernel now also sets this
> > bit in addition to userspace setting it. Given that this code only
> > runs when userspace either can't (resume, gpu reset) or explicitly
> > won't(gem_init) touch the hw this shouldn't have an adverse effect.
> > 
> > Signed-Off-by: Daniel Vetter 
> > ---
> 
> Have you tested this well?
> From bspec:
> Note: For ILK Display Engine can(?) implement the A[6] swizzling
> structure however it will not be used – corresponding bits will be set
> to “00”

I've simply moved the check around and my and checked whether I haven't
broken things. But resetting that bit seriously creates swizzling havoc on
my screen, so I think it's required ;-)

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/8] interlaced support v2

2012-02-01 Thread Daniel Vetter 
On Wed, Feb 01, 2012 at 11:18:48PM +0100, Angela Schmid wrote:
> Hello Daniel
> 
> I also want to confirm that interlacing is working over HDMI with 
> 1920x1080i@50hz for Sandy Bridge 2600k. Thanks a lot.
> 
> The fixes are not part of the intel gfx driver, correct ?
> When will it be pushed and to which kernel release will it presumably be 
> addressed to.

Correct, this is all kernel work and doesn't required any changes to the X
server or driver. Because it's a new feature, it'll go through next and
should land in linux kernel v3.4, which releases in about half a year or
so.

Thanks a lot for testing.

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: swizzling support for snb/ivb

2012-02-01 Thread Chris Wilson 
On Wed, 1 Feb 2012 23:16:19 +0100, Daniel Vetter  wrote:
> On Wed, Feb 01, 2012 at 01:35:14PM -0800, Ben Widawsky wrote:
> > You didn't address one questions I really cared about, how is it safe to
> > ignore channel 3 size? While I'm at it, I wonder what is in these
> > registers if you have less than 256MB. If the answer is zero, then your
> > check isn't safe enough below.
> 
> Hm, I've thought I've answered that in the mail to your review: 3 channel
> ddr configurations only exists on i7 chips without a gpu attached.
> Furthermore swizzling is only sensible when we have 2 channels anyway.

It almost always sensible to leave a comment behind in the code to
address review questions. What may not appear immediately obvious to
another person is unlikely to occur to anyone perusing the code 18+
months later. Didn't future Daniel warn you about that when he travelled
back from December 2012? :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Don't lock panel registers when downclocking

2012-02-01 Thread Sean Paul 
This patch removes the locking from the downclock routines since we are no
longer locking the registers at all. See ed10fca9 for the original commit
changing this philosophy.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_display.c |   14 --
 1 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ebe71ed..fe4787a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6968,10 +6968,6 @@ static void intel_increase_pllclock(struct drm_crtc 
*crtc)
if (!HAS_PIPE_CXSR(dev) && (dpll & DISPLAY_RATE_SELECT_FPA1)) {
DRM_DEBUG_DRIVER("upclocking LVDS\n");
 
-   /* Unlock panel regs */
-   I915_WRITE(PP_CONTROL,
-  I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
-
dpll &= ~DISPLAY_RATE_SELECT_FPA1;
I915_WRITE(dpll_reg, dpll);
intel_wait_for_vblank(dev, pipe);
@@ -6979,9 +6975,6 @@ static void intel_increase_pllclock(struct drm_crtc *crtc)
dpll = I915_READ(dpll_reg);
if (dpll & DISPLAY_RATE_SELECT_FPA1)
DRM_DEBUG_DRIVER("failed to upclock LVDS!\n");
-
-   /* ...and lock them again */
-   I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) & 0x3);
}
 
/* Schedule downclock */
@@ -7011,19 +7004,12 @@ static void intel_decrease_pllclock(struct drm_crtc 
*crtc)
if (!HAS_PIPE_CXSR(dev) && intel_crtc->lowfreq_avail) {
DRM_DEBUG_DRIVER("downclocking LVDS\n");
 
-   /* Unlock panel regs */
-   I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) |
-  PANEL_UNLOCK_REGS);
-
dpll |= DISPLAY_RATE_SELECT_FPA1;
I915_WRITE(dpll_reg, dpll);
intel_wait_for_vblank(dev, pipe);
dpll = I915_READ(dpll_reg);
if (!(dpll & DISPLAY_RATE_SELECT_FPA1))
DRM_DEBUG_DRIVER("failed to downclock LVDS!\n");
-
-   /* ...and lock them again */
-   I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) & 0x3);
}
 
 }
-- 
1.7.7.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: swizzling support for snb/ivb

2012-02-01 Thread Daniel Vetter 
We have to do this manually. Somebody had a Great Idea.

I've measured speed-ups just a few percent above the noise level
(below 5% for the best case), but no slowdows. Chris Wilson measured
quite a bit more (10-20% above the usual snb variance) on a more
recent and better tuned version of sna, but also recorded a few
slow-downs on benchmarks know for uglier amounts of snb-induced
variance.

v2: Incorporate Ben Widawsky's preliminary review comments and
elaborate a bit about the performance impact in the changelog.

v3: Add a comment as to why we don't need to check the 3rd memory
channel.

Acked-by: Chris Wilson 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_dma.c|2 +-
 drivers/gpu/drm/i915/i915_drv.c|4 ++-
 drivers/gpu/drm/i915/i915_drv.h|3 +-
 drivers/gpu/drm/i915/i915_gem.c|   23 +++-
 drivers/gpu/drm/i915/i915_gem_tiling.c |   19 -
 drivers/gpu/drm/i915/i915_reg.h|   34 
 6 files changed, 78 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3f27173..dfef956 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1208,7 +1208,7 @@ static int i915_load_gem_init(struct drm_device *dev)
i915_gem_do_init(dev, 0, mappable_size, gtt_size - PAGE_SIZE);
 
mutex_lock(&dev->struct_mutex);
-   ret = i915_gem_init_ringbuffer(dev);
+   ret = i915_gem_init_hw(dev);
mutex_unlock(&dev->struct_mutex);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1658cfd..12ddf47 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -495,7 +495,7 @@ static int i915_drm_thaw(struct drm_device *dev)
mutex_lock(&dev->struct_mutex);
dev_priv->mm.suspended = 0;
 
-   error = i915_gem_init_ringbuffer(dev);
+   error = i915_gem_init_hw(dev);
mutex_unlock(&dev->struct_mutex);
 
if (HAS_PCH_SPLIT(dev))
@@ -686,6 +686,8 @@ int i915_reset(struct drm_device *dev, u8 flags)
!dev_priv->mm.suspended) {
dev_priv->mm.suspended = 0;
 
+   i915_gem_init_swizzling(dev);
+
dev_priv->ring[RCS].init(&dev_priv->ring[RCS]);
if (HAS_BSD(dev))
dev_priv->ring[VCS].init(&dev_priv->ring[VCS]);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 865de80..0845419 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1187,7 +1187,8 @@ int __must_check i915_gem_object_set_domain(struct 
drm_i915_gem_object *obj,
uint32_t read_domains,
uint32_t write_domain);
 int __must_check i915_gem_object_finish_gpu(struct drm_i915_gem_object *obj);
-int __must_check i915_gem_init_ringbuffer(struct drm_device *dev);
+int __must_check i915_gem_init_hw(struct drm_device *dev);
+void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
 void i915_gem_do_init(struct drm_device *dev,
  unsigned long start,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 51a2b0c..86fffd2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3681,12 +3681,31 @@ i915_gem_idle(struct drm_device *dev)
return 0;
 }
 
+void i915_gem_init_swizzling(struct drm_device *dev)
+{
+   drm_i915_private_t *dev_priv = dev->dev_private;
+
+   if (INTEL_INFO(dev)->gen < 6 ||
+   dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
+   return;
+
+   I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
+DISP_TILE_SURFACE_SWIZZLING);
+
+   I915_WRITE(TILECTL, I915_READ(TILECTL) | TILECTL_SWZCTL);
+   if (IS_GEN6(dev))
+   I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_SNB));
+   else
+   I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_IVB));
+}
 int
-i915_gem_init_ringbuffer(struct drm_device *dev)
+i915_gem_init_hw(struct drm_device *dev)
 {
drm_i915_private_t *dev_priv = dev->dev_private;
int ret;
 
+   i915_gem_init_swizzling(dev);
+
ret = intel_init_render_ring_buffer(dev);
if (ret)
return ret;
@@ -3742,7 +3761,7 @@ i915_gem_entervt_ioctl(struct drm_device *dev, void *data,
mutex_lock(&dev->struct_mutex);
dev_priv->mm.suspended = 0;
 
-   ret = i915_gem_init_ringbuffer(dev);
+   ret = i915_gem_init_hw(dev);
if (ret != 0) {
mutex_unlock(&dev->struct_mutex);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
b/drivers/gpu/drm

Re: [Intel-gfx] [PATCH] drm/i915: dump even more into the error_state

2012-02-01 Thread Eugeni Dodonov 
On Wed, Feb 1, 2012 at 19:39, Chris Wilson  wrote:

> On Wed,  1 Feb 2012 22:26:45 +0100, Daniel Vetter 
> wrote:
> > Chris Wilson and me have again stared at funny error states and it's
> > been pretty clear from the start that something was seriously amiss.
> > The seqnos last seen by the cpu were a few hundred behind those that
> > the gpu could have possibly emitted last before it died ...
> >
> > Chris now tracked it down (hopefully, definit verdict's still out),
> > but in hindsight we'd have found the bug by simply dumping the cpu
> > side tracking of the ring head and tail registers.
> >
> > Fix this and prevent an identical time-waster in the future.
> >
> > Because the hangs always involved semaphores in one way or another,
> > we've tried to dump the mbox registers, but couldn't find any
> > inconsistencies. Still, dump them too.
> >
> > Signed-Off-by: Daniel Vetter 
> Reviewed-and-wanted-by: Chris Wilson 
>

Yeah!! Thanks a lot for that.

Reviewed-by: Eugeni Dodonov 

-- 
Eugeni Dodonov

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] uxa/glamor: Use a macro to specify module name.

2012-02-01 Thread zhigang . gong 
From: Zhigang Gong 

Signed-off-by: Zhigang Gong 
---
 src/intel_glamor.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/intel_glamor.c b/src/intel_glamor.c
index 446dd3d..f908b7c 100644
--- a/src/intel_glamor.c
+++ b/src/intel_glamor.c
@@ -67,7 +67,7 @@ intel_glamor_pre_init(ScrnInfoPtr scrn)
intel = intel_get_screen_private(scrn);
 
/* Load glamor module */
-   if ((glamor_module = xf86LoadSubModule(scrn, "glamor_egl"))) {
+   if ((glamor_module = xf86LoadSubModule(scrn, GLAMOR_EGL_MODULE_NAME))) {
version = xf86GetModuleVersion(glamor_module);
if (version < MODULE_VERSION_NUMERIC(0,3,0)) {
xf86DrvMsg(scrn->scrnIndex, X_ERROR,
-- 
1.7.4.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: swizzling support for snb/ivb

2012-02-01 Thread Ben Widawsky 
On Thu, Feb 02, 2012 at 12:15:38AM +0100, Daniel Vetter wrote:
> We have to do this manually. Somebody had a Great Idea.
> 
> I've measured speed-ups just a few percent above the noise level
> (below 5% for the best case), but no slowdows. Chris Wilson measured
> quite a bit more (10-20% above the usual snb variance) on a more
> recent and better tuned version of sna, but also recorded a few
> slow-downs on benchmarks know for uglier amounts of snb-induced
> variance.
> 
> v2: Incorporate Ben Widawsky's preliminary review comments and
> elaborate a bit about the performance impact in the changelog.
> 
> v3: Add a comment as to why we don't need to check the 3rd memory
> channel.
> 
> Acked-by: Chris Wilson 
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_dma.c|2 +-
>  drivers/gpu/drm/i915/i915_drv.c|4 ++-
>  drivers/gpu/drm/i915/i915_drv.h|3 +-
>  drivers/gpu/drm/i915/i915_gem.c|   23 +++-
>  drivers/gpu/drm/i915/i915_gem_tiling.c |   19 -
>  drivers/gpu/drm/i915/i915_reg.h|   34 
> 
>  6 files changed, 78 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3f27173..dfef956 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1208,7 +1208,7 @@ static int i915_load_gem_init(struct drm_device *dev)
>   i915_gem_do_init(dev, 0, mappable_size, gtt_size - PAGE_SIZE);
>  
>   mutex_lock(&dev->struct_mutex);
> - ret = i915_gem_init_ringbuffer(dev);
> + ret = i915_gem_init_hw(dev);
>   mutex_unlock(&dev->struct_mutex);
>   if (ret)
>   return ret;
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1658cfd..12ddf47 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -495,7 +495,7 @@ static int i915_drm_thaw(struct drm_device *dev)
>   mutex_lock(&dev->struct_mutex);
>   dev_priv->mm.suspended = 0;
>  
> - error = i915_gem_init_ringbuffer(dev);
> + error = i915_gem_init_hw(dev);
>   mutex_unlock(&dev->struct_mutex);
>  
>   if (HAS_PCH_SPLIT(dev))
> @@ -686,6 +686,8 @@ int i915_reset(struct drm_device *dev, u8 flags)
>   !dev_priv->mm.suspended) {
>   dev_priv->mm.suspended = 0;
>  
> + i915_gem_init_swizzling(dev);
> +
>   dev_priv->ring[RCS].init(&dev_priv->ring[RCS]);
>   if (HAS_BSD(dev))
>   dev_priv->ring[VCS].init(&dev_priv->ring[VCS]);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 865de80..0845419 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1187,7 +1187,8 @@ int __must_check i915_gem_object_set_domain(struct 
> drm_i915_gem_object *obj,
>   uint32_t read_domains,
>   uint32_t write_domain);
>  int __must_check i915_gem_object_finish_gpu(struct drm_i915_gem_object *obj);
> -int __must_check i915_gem_init_ringbuffer(struct drm_device *dev);
> +int __must_check i915_gem_init_hw(struct drm_device *dev);
> +void i915_gem_init_swizzling(struct drm_device *dev);
>  void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
>  void i915_gem_do_init(struct drm_device *dev,
> unsigned long start,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 51a2b0c..86fffd2 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3681,12 +3681,31 @@ i915_gem_idle(struct drm_device *dev)
>   return 0;
>  }
>  
> +void i915_gem_init_swizzling(struct drm_device *dev)
> +{
> + drm_i915_private_t *dev_priv = dev->dev_private;
> +
> + if (INTEL_INFO(dev)->gen < 6 ||
> + dev_priv->mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
> + return;
> +
> + I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
> +  DISP_TILE_SURFACE_SWIZZLING);
> +
> + I915_WRITE(TILECTL, I915_READ(TILECTL) | TILECTL_SWZCTL);
> + if (IS_GEN6(dev))
> + I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_SNB));
> + else
> + I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_IVB));
> +}
>  int
> -i915_gem_init_ringbuffer(struct drm_device *dev)
> +i915_gem_init_hw(struct drm_device *dev)
>  {
>   drm_i915_private_t *dev_priv = dev->dev_private;
>   int ret;
>  
> + i915_gem_init_swizzling(dev);
> +
>   ret = intel_init_render_ring_buffer(dev);
>   if (ret)
>   return ret;
> @@ -3742,7 +3761,7 @@ i915_gem_entervt_ioctl(struct drm_device *dev, void 
> *data,
>   mutex_lock(&dev->struct_mutex);
>   dev_priv->mm.suspended = 0;
>  
> - ret = i915_gem_init_ringbuf