[Intel-gfx] Which Intel hardware can display/decode H.264?
Grigory Trakhman
gary.trakhman at gmail.com
Fri Jul 10 21:14:23 CEST 2009
x4500hd and x4500mhd are the first intel chips that can provide
hardware assisted h264 decoding. This is supported on Windows with
special drivers, and I think little work has been done on it in linux.
gma950 won't help with that.
On Fri, Jul 10, 2009 at 3:00 PM,
<intel-gfx-request at lists.freedesktop.org> wrote:
> Send Intel-gfx mailing list submissions to
> intel-gfx at lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> or, via email, send a message with subject or body 'help' to
> intel-gfx-request at lists.freedesktop.org
>
> You can reach the person managing the list at
> intel-gfx-owner at lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Intel-gfx digest..."
>
>
> Today's Topics:
>
> 1. Re: Which Intel hardware can display/decode H.264? (Paul Menzel)
> 2. [PATCH 2/2] uxa: Tell the driver when we're just going to
> immediately map the pixmap. (Eric Anholt)
> 3. Re: [PATCH] Fix system lockup when a client tries to allocate
> a huge BO (Eric Anholt)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 10 Jul 2009 16:48:44 +0200
> From: Paul Menzel <paulepanter at users.sourceforge.net>
> Subject: Re: [Intel-gfx] Which Intel hardware can display/decode
> H.264?
> To: intel-gfx at lists.freedesktop.org
> Message-ID:
> <1247237325.7956.7.camel at mattotaupa.wohnung.familie-menzel.net>
> Content-Type: text/plain; charset="utf-8"
>
> Dear Tino and Marc,
>
>
> thanks for your answers.
>
> Am Donnerstag, den 09.07.2009, 11:00 +0200 schrieb Tino Keitel:
>> On Wed, Jul 08, 2009 at 22:34:15 +0200, Marc Deop i Argem? wrote:
>> > On Wednesday 08 July 2009 11:10:31 Paul Menzel wrote:
>> > > Does this also include decoding H.264 material? Does the hardware have a
>> > > decoder included and is this hardware decoder supported by the Intel
>> > > drivers? [3] claims to be playing 1080p HD material on an ASUS EeePC
>> > > 901.
>> >
>> > I can assure you I *cannot* play FullHD videos on my Toshiba
>> > U200+GMA950+Centrino Duo 1,86GHz
>>
>> In the current ffmpeg, there is limited support for multithreaded
>> decoding of H.264, so that all CPUs/CPU cores can be used. It depends
>> on the video if it has been encoded with more than once slice. In this
>> case, ffmpeg can use one CPU per slice. I tested a 1920x1200 H.264
>> video on my ThinkPad X61s with a L7500 CPU (Core2 Duo 1,6 GHz) and
>> playback was finde, with some CPU cycles left on both cores.
>>
>> However, the Intel graphics GMA950 still don't help for H.264 decoding.
>
> Sorry, I am not so familiar with this stuff, so it would be nice if you
> could clarify this.
>
> The word ?still? is a bit confusing for me. Does this mean (a) Intel
> graphics GMA950 could help with H.264 decoding and the drivers do not
> support it yet or (b) the Intel graphics GMA950 is not capable of
> helping with H.264 decoding?
>
>
> Thanks,
>
> Paul
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: Dies ist ein digital signierter Nachrichtenteil
> Url : http://lists.freedesktop.org/archives/intel-gfx/attachments/20090710/0ba6300c/attachment-0001.pgp
>
> ------------------------------
>
> Message: 2
> Date: Fri, 10 Jul 2009 00:07:48 -0700
> From: Eric Anholt <eric at anholt.net>
> Subject: [Intel-gfx] [PATCH 2/2] uxa: Tell the driver when we're just
> going to immediately map the pixmap.
> To: intel-gfx at lists.freedesktop.org
> Message-ID: <1247209668-28969-2-git-send-email-eric at anholt.net>
>
> This lets the driver allocate a nice idle buffer object instead of a
> busy one, reducing runtime of firefox-20090601 on my G45 from 50.7 (+/- .41%)
> to 48.4 (+/- 1.1%).
> ---
> src/i830_uxa.c | 5 ++++-
> uxa/uxa-render.c | 3 ++-
> uxa/uxa.h | 10 ++++++++++
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/src/i830_uxa.c b/src/i830_uxa.c
> index f423805..7ec8333 100644
> --- a/src/i830_uxa.c
> +++ b/src/i830_uxa.c
> @@ -645,7 +645,10 @@ i830_uxa_create_pixmap (ScreenPtr screen, int w, int h, int depth, unsigned usag
> return NullPixmap;
> }
>
> - bo = drm_intel_bo_alloc_for_render(i830->bufmgr, "pixmap", size, 0);
> + if (usage == UXA_CREATE_PIXMAP_FOR_MAP)
> + bo = drm_intel_bo_alloc(i830->bufmgr, "pixmap", size, 0);
> + else
> + bo = drm_intel_bo_alloc_for_render(i830->bufmgr, "pixmap", size, 0);
> if (!bo) {
> fbDestroyPixmap (pixmap);
> return NullPixmap;
> diff --git a/uxa/uxa-render.c b/uxa/uxa-render.c
> index 02373b0..13128ed 100644
> --- a/uxa/uxa-render.c
> +++ b/uxa/uxa-render.c
> @@ -822,7 +822,8 @@ uxa_create_alpha_picture (ScreenPtr pScreen,
> }
>
> pPixmap = (*pScreen->CreatePixmap) (pScreen, width, height,
> - pPictFormat->depth, 0);
> + pPictFormat->depth,
> + UXA_CREATE_PIXMAP_FOR_MAP);
> if (!pPixmap)
> return 0;
> pPicture = CreatePicture (0, &pPixmap->drawable, pPictFormat,
> diff --git a/uxa/uxa.h b/uxa/uxa.h
> index 8f6f896..d5f5b9c 100644
> --- a/uxa/uxa.h
> +++ b/uxa/uxa.h
> @@ -505,6 +505,16 @@ typedef struct _UxaDriver {
>
> /** @} */
>
> +/** @name UXA CreatePixmap hint flags
> + * @{
> + */
> +/**
> + * Flag to hint that the first operation on the pixmap will be a
> + * prepare_access.
> + */
> +#define UXA_CREATE_PIXMAP_FOR_MAP 0x20000000
> +/** @} */
> +
> uxa_driver_t *
> uxa_driver_alloc(void);
>
> --
> 1.6.3.3
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 09 Jul 2009 15:59:32 -0700
> From: Eric Anholt <eric at anholt.net>
> Subject: Re: [Intel-gfx] [PATCH] Fix system lockup when a client tries
> to allocate a huge BO
> To: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: intel-gfx at lists.freedesktop.org
> Message-ID: <1247180372.19542.2.camel at gaiman.anholt.net>
> Content-Type: text/plain; charset="us-ascii"
>
> On Mon, 2009-07-06 at 10:23 +0100, Chris Wilson wrote:
>> On Mon, 2009-07-06 at 10:10 +0100, Simon Farnsworth wrote:
>> > Eric Anholt wrote:
>> > > Anyway, we could just cap allocations at aperture size and avoid any
>> > > trickiness. There's no reason to allow a BO to be allocated that won't
>> > > fit in the GPU, right?
>> > >
>> > Sounds very reasonable; how do I code that?
>>
>> I think adding a defensive guard to bo_alloc of
>> if(size > bufmgr->gtt_size) return NULL;
>> would be the first step -- which for now also ensures that size will be
>> less than ULONG_MAX/2.
>>
>> However the fix I think Eric is alluding to is this:
>> >From aae30a03aba0fbe33ca51f052aaa8d57ebcb9eaf Mon Sep 17 00:00:00 2001
>> From: Chris Wilson <chris at chris-wilson.co.uk>
>> Date: Thu, 2 Jul 2009 14:31:49 +0100
>> Subject: [PATCH] Limit bo pixmap to hw constraints
>
> 2D acceleration sizes are much bigger than this -- in fact,
> approximately equivalent to the server's limits.
>
> --
> Eric Anholt
> eric at anholt.net eric.anholt at intel.com
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 197 bytes
> Desc: This is a digitally signed message part
> Url : http://lists.freedesktop.org/archives/intel-gfx/attachments/20090709/2e2c6be3/attachment-0001.pgp
>
> ------------------------------
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
> End of Intel-gfx Digest, Vol 18, Issue 41
> *****************************************
>
More information about the Intel-gfx
mailing list