Re: [Libva] [Libva-intel-driver][PATCH 1/2] Check whether there is a fully loaded HuC firmware
On Wed, Sep 28, 2016 at 01:45:54PM -0700, Sean V Kelley wrote:
> On Wed, 2016-09-28 at 08:42 +0800, Xiang, Haihao wrote:
> > > Signed-off-by: Xiang, Haihao
>
> lgtm, applied.
>
> Now we just need the kernel patches merged and we should be good.
Those just landed, you're good to go.
Cheers, Daniel
>
> Thanks,
>
> Sean
>
>
> > ---
> src/intel_driver.c | 12
> src/intel_driver.h | 1 +
> 2 files changed, 13 insertions(+)
>
> diff --git a/src/intel_driver.c b/src/intel_driver.c
> index 96c1994..bb19401 100644
> --- a/src/intel_driver.c
> +++ b/src/intel_driver.c
> @@ -44,6 +44,12 @@ uint32_t g_intel_debug_option_flags = 0;
> #define LOCAL_I915_PARAM_HAS_BSD230
> #endif
>
> +#ifdef I915_PARAM_HAS_HUC
> +#define LOCAL_I915_PARAM_HAS_HUC I915_PARAM_HAS_HUC
> +#else
> +#define LOCAL_I915_PARAM_HAS_HUC 42
> +#endif
> +
> static Bool
> intel_driver_get_param(struct intel_driver_data *intel, int param, int
> *value)
> {
> @@ -130,6 +136,12 @@ intel_driver_init(VADriverContextP ctx)
> if (intel_driver_get_param(intel, LOCAL_I915_PARAM_HAS_BSD2, &ret_value))
> intel->has_bsd2 = !!ret_value;
>
> +intel->has_huc = 0;
> +ret_value = 0;
> +
> +if (intel_driver_get_param(intel, LOCAL_I915_PARAM_HAS_HUC, &ret_value))
> +intel->has_huc = !!ret_value;
> +
> intel_driver_get_revid(intel, &intel->revision);
> return true;
> }
> diff --git a/src/intel_driver.h b/src/intel_driver.h
> index c9a80c8..dcdc03b 100644
> --- a/src/intel_driver.h
> +++ b/src/intel_driver.h
> @@ -181,6 +181,7 @@ struct intel_driver_data
> unsigned int has_blt: 1; /* Flag: has BLT unit? */
> unsigned int has_vebox : 1; /* Flag: has VEBOX unit */
> unsigned int has_bsd2 : 1; /* Flag: has the second BSD video ring unit
> */
> +unsigned int has_huc: 1; /* Flag: has a fully loaded HuC firmware? */
>
> const struct intel_device_info *device_info;
> };
>
> ___
> Libva mailing list
> Libva@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libva
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [PATCH v2 0/7] Host1x IOMMU support + VIC support
On Wed, Dec 14, 2016 at 3:11 PM, Daniel Vetter wrote: > On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote: >> On 14.12.2016 15:05, Daniel Vetter wrote: >> > On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: >> > > On 14.12.2016 14:30, Daniel Vetter wrote: >> > > > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: >> > > > > This series adds IOMMU support to Host1x and TegraDRM >> > > > > and adds support for the VIC (Video Image Compositor) >> > > > > host1x client. The series is available as a git repository at >> > > > > git://github.com/cyndis/linux.git; branch vic-2. >> > > > > >> > > > > A userspace test case for VIC can be found at >> > > > > https://github.com/cyndis/drm/tree/work/tegra. >> > > > > The testcase is in tests/tegra and is called submit_vic. >> > > > > The testcase/TRM include full headers and documentation >> > > > > to program the unit. The unit by itself, however, does not >> > > > > readily map to existing userspace library interfaces, so >> > > > > implementations for those are not provided. >> > > > >> > > > Afaik libva has an entire pile of post-processing support. Pretty sure >> > > > other video transcode libraries have similar interfaces, so should all >> > > > be >> > > > possible to implement this. >> > > >> > > We don't have any actual video transcoding support though, so unless it's >> > > possible to just implement a part of libva and defer the rest to some CPU >> > > implementation, I don't see how this is useful. I suppose I could >> > > implement >> > > a GStreamer plugin for colorspace conversion or resizing, since those are >> > > very modular. >> > >> > Hm, I guess the question then is, how did that get enabled? >> >> What is "that"? I'm not exactly sure. >> >> Our architecture is such that there's the VIC that handles colorspace >> conversion, rescaling, blitting and can do some 2d postprocessing effects as >> well. >> >> Then there's the separate NVDEC that is a video bitstream decoder. There's >> no support for that at the moment. I am working on the IP side of that. >> >> The video processing pipeline is then such that NVDEC is fed the bitstream; >> NVDEC outputs a YUV picture in a specific format; VIC takes that YUV picture >> and converts/rescales it into the desired format. Or if we are encoding >> video, VIC takes your RGB image, converts it into a format that NVENC >> understands, and so on. >> >> So with just VIC support, I could implement some simple 2D things. I don't >> know if anyone would want to specifically use the VIC for those since >> applications already have fast CPU algorithms. For the video pipeline using >> VIC is nice since these units can synchronize work without CPU involvement >> and when you're already using NVDEC or NVENC it's barely any extra effort to >> involve VIC as well. It can also be useful in power usage sensitive >> situations, but we aren't really fit for those situations with the upstream >> kernel anyway :) > > Ah I thought the nvdec was already enabled, since for i915 that's how we > went about things (we have a pretty much exactly matching split in the > various video related engines). But if that's not there yet then no > worries, all fine. > > Since you do seem to plan to enable everything anyway, might be worth it > to go directly with something like libva or libvdpau or whatever the cool > thing is. libva is my recommendation since it works on non-X11 too afaik, > but I have 0 clue. And might be worth it to check out whether you can't do > a super-basic libva driver that only does the post processing stuff. With > libva you can import/export images, so it might be possible even ... And > directly doing the full video engine support instead of a one-off in > gstreamer sounds more sensible to me. Silly me forgot to add the experts, i.e. Sean (current libva maintainer) and libva mailing lists. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] [PATCH] drm/i915: Make sample_c messages go faster on Haswell.
On Tue, Jan 06, 2015 at 03:15:39PM +0800, Xiang, Haihao wrote: > On Mon, 2015-01-05 at 23:03 -0800, Kenneth Graunke wrote: > > On Tuesday, January 06, 2015 02:39:36 PM Xiang, Haihao wrote: > > > On Mon, 2015-01-05 at 21:54 -0800, Kenneth Graunke wrote: > > > > On Tuesday, January 06, 2015 01:11:53 PM Xiang, Haihao wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > How did you test OSD ? I can't reproduce the issue you mentioned, OSD > > > > > works well for me when using mplayer-vaapi with the latest > > > > > libva/libva-intel-driver master branch. > > > > > > > > > > I tried your patch, what surprised me is OSD still works well after > > > > > applying your patch. It seems your patch didn't disable the palette. > > > > > > > > > > Thanks > > > > > Haihao > > > > > > > > I ran: > > > > > > > > mplayer -osdlevel 3 -vo vaapi big_buck_bunny_720p_stereo.ogg > > > > > > > > For me, the OSD text is solid green, with hard edges. > > > > > > The OSD text is white for me when using mplayer -osdlevel 3 -vo vaapi > > > xxx. If possible, could you update your mplayer ? > > > > Huh. I'm using the Arch Linux package of mplayer-vaapi 36265-13, > > which seems to be the most recent subversion commit ID. I've never seen > > white text on my Haswell system - it seems to be consistently dark green. > > > > > If you use "-vo gl" or "-vo xv", the OSD is solid white text with a > > > > black > > > > border around it. I presume that it's supposed to be white with vaapi > > > > as > > > > well, but I guess I'm not entirely sure. > > > > > > > > It's possible that the optimization doesn't affect the palette as long > > > > as > > > > you never use sample_c with the paletted textures. > > > > > > I verified the palette takes effect in the following way: > > > > > > 1. Only support P8A8 format in the driver > > > > > > 2. ran the above command and I saw white OSD text > > > > > > 3. Only support P4A4 format in the driver and don't use > > > 3DSTATE_SAMPLER_PALETTE_LOAD0 to load the value to the texture palette, > > > so the palette keeps unchanged. > > > > > > 4. ran the above command and I saw black OSD text. > > > > > > 5. Load the right value to the texture palette and ran the above command > > > again, I saw white OSD text. > > > > > > Hence I think sample_c with the paletted textures is used in the driver. > > > > That sounds like the palette is actually working, then. Great :) > > > > I doubt that libva would use sample_c - sampling with a shadow comparison? > > It looks like it just uses sample and sample+killpix. > > You are right, libva driver doesn't use sample_c message. > > > I'm pretty sure the sample_c optimization just uses the palette memory as > > storage for some stuff, so it's quite possible it just works if you're > > only using sample and sample+killpix. > > Thanks for the explanation, it makes sense to me. Thanks for digging into this some more, I've added the above discussion in a quote to the commit message. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] [PATCH] drm/i915: Make sample_c messages go faster on Haswell.
On Wed, Dec 31, 2014 at 04:23:00PM -0800, Kenneth Graunke wrote:
> Haswell significantly improved the performance of sampler_c messages,
> but the optimization appears to be off by default. Later platforms
> remove this bit, and apparently always enable the optimization.
>
> Improves performance in "Counter Strike: Global Offensive" by 18%
> at default settings on Iris Pro.
>
> This may break sampling of paletted formats (P8/A8P8/P8A8). It's
> unclear whether it affects sampling of paletted formats in general,
> or just the sample_c message (which is never used).
>
> While libva does have support for using paletted formats (primarily
> for OSDs), that support appears to have been broken for at least a
> year, so I couldn't observe a regression from this.
>
> Signed-off-by: Kenneth Graunke
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 4
> 2 files changed, 5 insertions(+)
>
> Resubmitting the patch to unconditionally enable this. I tried to get
> libva-intel to use paletted formats, and observe a regression...but the
> only thing I found that used it was mplayer's OSD (on screen display).
> Even without my patch, the colors were totally wrong with that, and it's
> according to a few distro wikis, that's been the case for over a year.
>
> If libva's code for paletted formats /is/ broken, they could always add
> code to disable this bit using the command validator when fixing it.
>
> Could we try merging this, and back it out if someone reports a
> regression? I haven't observed any problems. It's also been quite
> stable.
Yeah makes sense. When resending please incorporated review feedback
(Ville dug out the wa name), I've done that. And I've pasted the
additional detail about the libva saga, just for reference (since no one
will remember that it's mplayer's OSD which uses this 2 months down the
road).
Also please cc libva mailing lists next time around as an fyi. Done that
too.
Queued for -next, thanks for the patch.
-Daniel
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 40ca873..0f32fd1a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6167,6 +6167,7 @@ enum punit_power_well {
> #define HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE(1 << 6)
>
> #define HALF_SLICE_CHICKEN3 0xe184
> +#define HSW_SAMPLE_C_PERFORMANCE (1<<9)
> #define GEN8_CENTROID_PIXEL_OPT_DIS(1<<8)
> #define GEN8_SAMPLER_POWER_BYPASS_DIS (1<<1)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7d99a9c..17e84dc 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5974,6 +5974,10 @@ static void haswell_init_clock_gating(struct
> drm_device *dev)
> I915_WRITE(GEN7_GT_MODE,
> _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
>
> + /* Make sample_c messages faster. */
> + I915_WRITE(HALF_SLICE_CHICKEN3,
> +_MASKED_BIT_ENABLE(HSW_SAMPLE_C_PERFORMANCE));
> +
> /* WaSwitchSolVfFArbitrationPriority:hsw */
> I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
>
> --
> 2.2.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Libva mailing list
Libva@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] [PATCH] drm/i915: Make sample_c messages go faster on Haswell.
On Fri, Oct 31, 2014 at 11:27:33AM +0200, Ville Syrjälä wrote: > On Thu, Oct 30, 2014 at 12:57:04PM -0700, Kenneth Graunke wrote: > > Before we get too much further...we should check if libva is actually > > broken. > > I don't know if this means the sampler palette completely doesn't work, or > > if > > it just means sample_c doesn't work with the palette. If it's the latter, > > we're probably fine, because I doubt libva uses sample_c. > > Yeah if we wouldn't break any existing userspace I guess we could just > flip the switch in the kernel. If anyone later wants to start doing > something that no longer works they'd have to deal with disabling the > bit using an LRI. It very much looks like libva uses palettes, since it supports C8 and C4 image formats (well some crazy fourcc nonsense, but meh). And it does so on all generations support by the libva driver, i.e. including hsw afaict Cc'ing people and lists with more clue who should be able to tell whether its not just there but actually works ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] Parse and render in different threads?
On Wed, Mar 20, 2013 at 9:02 AM, Andreas Larsson wrote: > Yep ok, that's nice! > > Followup question(s): > > I'm currently filling in my buffers by calling vaCreateBuffer with NULL as > pointer argument to let the server allocate the memory for me, then I use > vaMapBuffer when I fill it in. This works very nice and performance is good. > > However I see that when I over-allocate my slice buffers the performance > drops a bit. Currently I allocate 8kb for each slice and fill it in and then > specify in the slice parameters exactly how much of the buffer I actually > use. As I understand it the over-allocation shouldn't affect performance, but > it does. Are the buffers copied even though I allocate them in the server? If you are on ironlake or on sandybridge with an old kernel it might be that you're hitting the clflush overhead of cpu mmaps, which is proportional to the size of the buffer, not the data actually used. I'm not sure of the internals and whether libva has an interface to upload with copies. But if that exists we could use the kernel's pwrite interface, which has generally higher throughput in this case and only overhead proportional to the actually written data. > More over, the documentation says the buffers are automatically de-allocated > once they've been sent to vaRenderPicture. Is there any way to re-use the > buffers and avoid automatic de-allocation? I really don't see why I should > create/destroy all buffers each frame, seems like a complete waste of > resources. Buffers, including any cpu mappings already set up are _very_ aggressively cached internally in libva (actually libdrm) arleady. So there should be no need for you to do any caching on top. -Daniel > > Kind regards, Andreas Larsson > > > 20 mar 2013 kl. 01:50 skrev "Xiang, Haihao" > : > >> On Tue, 2013-03-19 at 08:02 +, Andreas Larsson wrote: >>> Hi! >>> >>> Do I have to perform bitstream parsing and vaRenderPicture in separate >>> threads to maintain best performance. I.e. do vaRenderPicture block or are >>> those calls buffered and handled asynchronously by the driver/chip, like >>> OpenGL? >> >> VA runs in asynchronous mode. >> >>> >>> As it is, I generate MPEG2 data and for each slice I call vaRenderPicture >>> before I generate the next slice, so if vaRenderPicture blocks this would >>> drain my performance completly. >>> >>> Kind regards, Andreas Larsson >>> >>> ___ >>> Libva mailing list >>> Libva@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/libva >> >> > > ___ > Libva mailing list > Libva@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libva -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] VA-API does no v-sync with H264 interlaced videos
On Thu, Mar 7, 2013 at 9:38 AM, Lutz Sammer wrote: > vaPutSurface (X11) waits on v-sync? With the minor nit that for a long time the intel X driver didn't implement this on snb/ivb, resulting in tearing. But with kernel 3.8 and latest xfree86-video-intel when using the SNA backed it should work. Note that it always worked when using a gl fullscreen compositor. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] GPU Hangcheck
On Sun, Dec 18, 2011 at 08:29:37PM +0100, gimli wrote: > Is there a chance that the "GPU Hangcheck" issues with vaapi will ever be > fixed ? > I saw on the ML that Daniel Vetter started to sort it out, but then > suddenly stopped. > > At the moment i use a G440 Intel CPU. Using libva and the intel git video > drivers crashing the X server imediatley. > > When using glx and deinterlacing the "GPU Hangcheck" is there. The issuse > is long know but no one seems to adress it serious. > > With those bugs the intel platform seems more a theoretical concept for > VAAPI than realy usable for production. Well, I've stopped working on it because the bug reporter somehow disappeared. Can you please point me to your bug number or file a new one with all the usual details (i915_error_state is the most important one). I usually don't work on libva, so I don't check the outstanding bug reports for issues. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Tue, Oct 18, 2011 at 08:47:04PM +0200, Daniel Vetter wrote: > On Tue, Oct 18, 2011 at 09:52:32AM +0200, Dieter Mummenschanz wrote: > > In this special case the gpu was successfully reset and continued normally. > > > > Any other ideas? > > Not at the moment, unfortunately. Can you please report a bug against > libva with a small summary of all the things we've already discussed here? > Also please add a error_state with my patches applied. And don't forget to > put me on cc and post the bug # here in this thread. Any update on this? I've got other reports of libva related gpu hangs, but you seem to be the only one who can grab the error_state ... Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Tue, Oct 18, 2011 at 09:52:32AM +0200, Dieter Mummenschanz wrote: > I've installed your libva patch: > > libva: libva version 0.32.0 > libva: va_getDriverName() returns 0 > libva: Trying to open /usr/local/lib/dri/i965_drv_video.so > libva: va_openDriver() returns 0 > vainfo: VA API version: 0.32 > vainfo: Driver version: Intel i965 driver - 1.0.15.pre1 > > No Changes. With iommu switched off there are less frequent hangs but there > still are :-(. dmesg shows: > > WARNING: at drivers/gpu/drm/i915/i915_drv.c:354 > gen6_gt_force_wake_get+0x1f/0x3c [i915]() > Hardware name: 4236NGG > Modules linked in: snd_hda_codec_conexant fbcon font bitblit softcursor i915 > thinkpad_acpi nvram drm_kms_helper drm fb fbdev cfbcopyarea video iwlagn > backlight cfbimgblt cfbfillrect e1000e snd_hda_intel snd_hda_codec intel_agp > intel_gtt agpgart > Pid: 0, comm: swapper Not tainted 3.1.0-rc4+ #1 > Call Trace: >[] ? warn_slowpath_common+0x78/0x8c > [] ? i915_vblank_swap+0x6/0x6 [i915] > [] ? gen6_gt_force_wake_get+0x1f/0x3c [i915] > [] ? i915_hangcheck_elapsed+0x109/0x29a [i915] > [] ? i915_vblank_swap+0x6/0x6 [i915] > [] ? run_timer_softirq+0x195/0x222 > [] ? __do_softirq+0x7f/0x106 > [] ? call_softirq+0x1c/0x30 > [] ? do_softirq+0x31/0x67 > [] ? irq_exit+0x44/0xa5 > [] ? smp_apic_timer_interrupt+0x85/0x95 > [] ? apic_timer_interrupt+0x6b/0x70 >[] ? intel_idle+0xcd/0xe9 > [] ? intel_idle+0xa9/0xe9 > [] ? cpuidle_idle_call+0xa0/0xdb > [] ? cpu_idle+0x52/0x75 > [] ? start_kernel+0x401/0x40c We already know about this backtrace. It's a possible sideffect of a overloaded/dying gpu, but unrelated to the bug at hand. > In this special case the gpu was successfully reset and continued normally. > > Any other ideas? Not at the moment, unfortunately. Can you please report a bug against libva with a small summary of all the things we've already discussed here? Also please add a error_state with my patches applied. And don't forget to put me on cc and post the bug # here in this thread. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Mon, Oct 17, 2011 at 10:20:09PM +0200, Dieter Mummenschanz wrote: > ok now I got your patch from git and will give it a try asap. Meanwhile > the intel_iommu=off (with rc6 enabled) switch seems to make the system > somehow more stable. the gpu hangs don't appear that often but they > still occur! strangely after the hang/resume, the OpenGL game crashes > immediately with: > > intel_do_flush_locked failed: Input/output error > and raises the same error when I try to start it up again. > > mplayer also bails out with: > mplayer: dri2_util.c:109: dri2GetRenderingBuffer: Assertion `buffers' failed. > MPlayer interrupted by signal 6 in module: flip_page > > I have to reboot in order to get mplayer / the game running. > > I've never experienced that before. i915 error state attached. Well, that usually means that the kernel couldn't reset the gpu after a hang. You should see a message to that effect in dmesg. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Mon, Oct 17, 2011 at 06:01:56PM +0200, Dieter Mummenschanz wrote: > Hi Daniel, > > ok I did a git clone git://anongit.freedesktop.org/libva (hope this is the > right one?) and in the libva checkout I issued: > > git pull git://freedesktop.org/~danvet/libva-intel for-dieter > warning: no common commits > remote: Counting objects: 1632, done. > remote: Compressing objects: 100% (447/447), done. > remote: Total 1632 (delta 1174), reused 1632 (delta 1174) > Receiving objects: 100% (1632/1632), 617.29 KiB | 230 KiB/s, done. > Resolving deltas: 100% (1174/1174), done. > From git://freedesktop.org/~danvet/libva-intel > * branchfor-dieter -> FETCH_HEAD > Auto-merging configure.ac > CONFLICT (add/add): Merge conflict in configure.ac > Auto-merging Makefile.am > CONFLICT (add/add): Merge conflict in Makefile.am > Auto-merging .gitignore > CONFLICT (add/add): Merge conflict in .gitignore > Automatic merge failed; fix conflicts and then commit the result. > > help! :-( Ok, I've given that git repo a head, so your usual git clone should work. Btw, you're sure you have the latest libva? It moved to http://cgit.freedesktop.org/vaapi/intel-driver/ Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Mon, Oct 17, 2011 at 05:13:02PM +0200, Dieter Mummenschanz wrote: > Hi Daniel, > > something is odd with your git branch - or my git command: It's a headless git repo with just branches. Go into your existing intel libva driver checkout, create a new branch and merge in my stuff with git pull git://freedesktop.org/~danvet/libva-intel for-dieter Cheers, Daniel > git clone git://freedesktop.org/~danvet/libva-intel for-dieter > Cloning into for-dieter... > remote: Counting objects: 1632, done. > remote: Compressing objects: 100% (447/447), done. > remote: Total 1632 (delta 1174), reused 1632 (delta 1174) > Receiving objects: 100% (1632/1632), 617.29 KiB | 266 KiB/s, done. > Resolving deltas: 100% (1174/1174), done. > warning: remote HEAD refers to nonexistent ref, unable to checkout ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Mon, Oct 17, 2011 at 03:54:03PM +0200, Dieter Mummenschanz wrote: > Hi Daniel, > > I believe I tried that already but I'll give it another shot. To avoid > another screw up: Can I check in proc or sysfs to see, if iommu is > really disabled? I also have pcie_aspm=force set as kernel parameter to > save some watts but it does not seem to contribute to the gpu hangs. If you disable it in the bios, there should be no IOMMU message left in dmesg. Disabling it on the kernel cmdline leaves a few behind (they announce that the bios supports dmar). Meanwhile I've stitched together the patches for libva, can you try the for-dieter branch at: http://cgit.freedesktop.org/~danvet/libva-intel/ Also please ensure that you have the latest xf86-video-intel from git master installed. Thanks, Daniel PS: Please don't cut out libva from the cc: list. -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Mon, Oct 17, 2011 at 02:37:21PM +0200, Dieter Mummenschanz wrote: > Hi Daniel, > > no problem. dmesg.log attached. > To reproduce the hang: try to play two or more bluray streams at once > and probably a hires wmv stream as well using mplayer-vaapi. also run a > opengl game like Quake3 or prboom-plus > (http://prboom-plus.sourceforge.net). You'll need an additional "pwad" > file for prboom. PM me for that. With everything up and running, open a > browser and do normal desktop work. That'll do it. Sometimes after a > minute - sometimes after an hour. One more thing: I have a mobile > i7-2620M chip, no additional gpu, running with cpufreq-tools on demand. > The Notebook runs on AC Power all the time. > > If I can help in any way (testing patches, etc), please let me know :-) As I kinda expected, you're running with VT-d/DMAR switched on. That's implicated in quite a few rc6/strange hang reports already. Can you check what happens when you turn that off, either in the bios or with intel_iommu=off on the kernel cmdline? Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Mon, Oct 17, 2011 at 01:58:03PM +0200, Daniel Vetter wrote: > On Mon, Oct 17, 2011 at 01:45:28PM +0200, Dieter Mummenschanz wrote: > > Hi Daniel, > > > > first of all I've seemed to screwed up my rc6 kernel parameters causing > > rc6 to be enabled in all my previous tests even though I thought it was > > disbaled. Sorry for that! Some new tests with i915_enable_rc6 definately > > being disabled didn't raise any gpu hangs no matter what I did! So rc6 > > related clock changes might have something to do with the hangs/stalls. > > With rc6 being disabled, some opengl games, like prboom-plus however > > show random pixel depthbuffer errors. Is this a known issue? Regarding > > the video streams causing the gpu hang, those are unfortunately > > copyrighted material (i.e. Star Wars Bluray for example). The best way > > is to play multiple hi bitrate-streams with different formats > > simultaneously and run a free OpenGL game like prboom-plus. I'll do some > > seaching on the web for free test streams to reproduce the hang. > > Oh, I don't want you to publish them, just check whether it's a specific > one or more random. And maybe it helps in reproducing. > > > vainfo (latest git) shows: > > libva: libva version 0.32.0 > > libva: va_getDriverName() returns 0 > > libva: Trying to open /usr/local/lib/dri/i965_drv_video.so > > libva: va_openDriver() returns 0 > > vainfo: VA API version: 0.32 > > vainfo: Driver version: i965 Driver 0.1 > > > > the player is the latest mplayer hwaccel-vaapi branch (latest git) > > http://gitorious.org/vaapi/mplayer/commits/hwaccel-vaapi > > console command is mplayer -vo vaapi -va vaapi stream.mkv > > > > Is there any way to monitor rc6 state change, i.e. gpu/ring clock speed? > > Maybe this helps to track down issues caused by rc6 state changes? > > Ok, with have a new rc6 bug :( I think we'll attack the libva hang first, > I have an idea for a patch. > > > Anyway sorry again for the rc6 confusion. Meh, hit send too early. No problem about the confusion, now that it's cleared up. Can you also attach the full dmesg while I hack together a patch for libva? Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Mon, Oct 17, 2011 at 01:45:28PM +0200, Dieter Mummenschanz wrote: > Hi Daniel, > > first of all I've seemed to screwed up my rc6 kernel parameters causing > rc6 to be enabled in all my previous tests even though I thought it was > disbaled. Sorry for that! Some new tests with i915_enable_rc6 definately > being disabled didn't raise any gpu hangs no matter what I did! So rc6 > related clock changes might have something to do with the hangs/stalls. > With rc6 being disabled, some opengl games, like prboom-plus however > show random pixel depthbuffer errors. Is this a known issue? Regarding > the video streams causing the gpu hang, those are unfortunately > copyrighted material (i.e. Star Wars Bluray for example). The best way > is to play multiple hi bitrate-streams with different formats > simultaneously and run a free OpenGL game like prboom-plus. I'll do some > seaching on the web for free test streams to reproduce the hang. Oh, I don't want you to publish them, just check whether it's a specific one or more random. And maybe it helps in reproducing. > vainfo (latest git) shows: > libva: libva version 0.32.0 > libva: va_getDriverName() returns 0 > libva: Trying to open /usr/local/lib/dri/i965_drv_video.so > libva: va_openDriver() returns 0 > vainfo: VA API version: 0.32 > vainfo: Driver version: i965 Driver 0.1 > > the player is the latest mplayer hwaccel-vaapi branch (latest git) > http://gitorious.org/vaapi/mplayer/commits/hwaccel-vaapi > console command is mplayer -vo vaapi -va vaapi stream.mkv > > Is there any way to monitor rc6 state change, i.e. gpu/ring clock speed? > Maybe this helps to track down issues caused by rc6 state changes? Ok, with have a new rc6 bug :( I think we'll attack the libva hang first, I have an idea for a patch. > Anyway sorry again for the rc6 confusion. > > Regards, > Dieter -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
Re: [Libva] [Intel-gfx] frequent x crashes with gen6/sna
On Sun, Oct 16, 2011 at 06:18:17PM +0200, Daniel Vetter wrote: > Hi Dieter > > [Adding libva to cc] > > In all the error_state you've reported till now there's activity on the > video ring. Can you check whether watching (maybe even a specific) video > with libva causes these hangs? Also please try the latest libva from git > sources. > > Thanks, Daniel Forward because libva has a nutty msg limit of 40 kb. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva
