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 <haihao.xi...@intel.com>
>
> 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, _value))
> intel->has_bsd2 = !!ret_value;
>
> +intel->has_huc = 0;
> +ret_value = 0;
> +
> +if (intel_driver_get_param(intel, LOCAL_I915_PARAM_HAS_HUC, _value))
> +intel->has_huc = !!ret_value;
> +
> intel_driver_get_revid(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 <dan...@ffwll.ch> 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 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] VA-API does no v-sync with H264 interlaced videos
On Thu, Mar 7, 2013 at 9:38 AM, Lutz Sammer john...@gmx.net 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] [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 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 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
