search for: nvc0_video

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nvc0/nvc0_video.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c index 5871f59..c9ab13a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c @@ -77,6 +77,9...

On Mon, May 19, 2014 at 12:16 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > src/gallium/drivers/nouveau/nvc0/nvc0_video.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c b/src/gallium/drivers/nouveau/nvc0/nvc0_video.c > index 5871f59..c9ab13a 100644 > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_video.c > +++ b/src/gallium/drivers/nouveau/nvc...

...ent the other parts in nv50. The non-shared parts are still largely copies, but there are some differences, not the least of which is the BEGIN_NV04 vs BEGIN_NVC0 stuff. Probably more refactoring is possible, but right now there is ~1k lines of code in nouveau, and ~1k lines of code in each of nvc0/nvc0_video* and nv50/nv98_video*. For whatever reason, h264 and mpeg4 don't work "out of the box". With h264, the decoder hangs after decoding a few frames, and I think reports are that mpeg4 just doesn't work at all. (I also seem to remember hearing that mpeg4 didn't work on nvc0+ eith...

...nt_new(screen->device, &dec->client); >> + if (ret) >> + goto fail; > Is there any particular reason for using a variable to store the return > value through this functions? Me thinks it can be safely purged, making > the code a bit cleaner It was like that in nvc0_video and a lot of other code. I think the code looks a little odd when you have if (super-long multi-line statement) goto fail > >> + >> + if (is_h264) { >> + ret = nouveau_object_new(&screen->device->object, 0, >> + NOUVEAU_F...

...;dec->client); >>> + if (ret) >>> + goto fail; >> Is there any particular reason for using a variable to store the return >> value through this functions? Me thinks it can be safely purged, making >> the code a bit cleaner > > It was like that in nvc0_video and a lot of other code. I think the > code looks a little odd when you have > > if (super-long multi-line statement) > goto fail There are cases where you've left the "super-long multi-line statement" in the conditional and others where you did not. I suggested changin...

https://bugs.freedesktop.org/show_bug.cgi?id=89969 Bug ID: 89969 Summary: vaDriverInit fails with gallium/nouveau driver Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=111213 Bug ID: 111213 Summary: VA-API nouveau SIGSEGV and asserts Product: Mesa Version: 19.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

...; +static INLINE uint32_t mb(uint32_t coord) > +{ > + return (coord + 0xf)>>4; > +} > + > +static INLINE uint32_t mb_half(uint32_t coord) > +{ > + return (coord + 0x1f)>>5; > +} How about moving these in nouveau_video.h ? (and removing the duplicate copy from nvc0_video.h) Might be better as a follow on patch ... > diff --git a/src/gallium/drivers/nv50/nv84_video_vp.c b/src/gallium/drivers/nv50/nv84_video_vp.c > new file mode 100644 > index 0000000..60c0848 > --- /dev/null > +++ b/src/gallium/drivers/nv50/nv84_video_vp.c > @@ -0,0 +1,521 @@ &gt...

Adds H.264 and MPEG2 codec support via VP2, using firmware from the blob. Acceleration is supported at the bitstream level for H.264 and IDCT level for MPEG2. Known issues: - H.264 interlaced doesn't render properly - H.264 shows very occasional artifacts on a small fraction of videos - MPEG2 + VDPAU shows frequent but small artifacts, which aren't there when using XvMC on the same