search for: nv12

...t;>> But userspace must be able to continue allocating YUV buffers through >>>> CREATE_DUMB. >>> >>> I think, allocating YUV buffers through CREATE_DUMB interface is just >>> an *abuse* and *misuse* of this API for now. >>> >>> Take the NV12 format as an example, NV12 is YUV420 planar format, have >>> two planar: the Y-planar and the UV-planar. The Y-planar appear first >>> in memory as an array of unsigned char values. The Y-planar is followed >>> immediately by the UV-planar, which is also an array of unsig...

...must be able to continue allocating YUV buffers through >>>>> CREATE_DUMB. >>>> >>>> I think, allocating YUV buffers through CREATE_DUMB interface is just >>>> an *abuse* and *misuse* of this API for now. >>>> >>>> Take the NV12 format as an example, NV12 is YUV420 planar format, have >>>> two planar: the Y-planar and the UV-planar. The Y-planar appear first >>>> in memory as an array of unsigned char values. The Y-planar is >>>> followed >>>> immediately by the UV-planar, w...

...cating YUV buffers through > >>>>> CREATE_DUMB. > >>>> > >>>> I think, allocating YUV buffers through CREATE_DUMB interface is just > >>>> an *abuse* and *misuse* of this API for now. > >>>> > >>>> Take the NV12 format as an example, NV12 is YUV420 planar format, have > >>>> two planar: the Y-planar and the UV-planar. The Y-planar appear first > >>>> in memory as an array of unsigned char values. The Y-planar is followed > >>>> immediately by the UV-planar, whic...

...t;> [...] >> >>> But userspace must be able to continue allocating YUV buffers through >>> CREATE_DUMB. >> >> I think, allocating YUV buffers through CREATE_DUMB interface is just >> an *abuse* and *misuse* of this API for now. >> >> Take the NV12 format as an example, NV12 is YUV420 planar format, have >> two planar: the Y-planar and the UV-planar. The Y-planar appear first >> in memory as an array of unsigned char values. The Y-planar is followed >> immediately by the UV-planar, which is also an array of unsigned char &gt...

...an IOCTL for YUV / etc. > > [...] > >> But userspace must be able to continue allocating YUV buffers through >> CREATE_DUMB. > > I think, allocating YUV buffers through CREATE_DUMB interface is just > an *abuse* and *misuse* of this API for now. > > Take the NV12 format as an example, NV12 is YUV420 planar format, have > two planar: the Y-planar and the UV-planar. The Y-planar appear first > in memory as an array of unsigned char values. The Y-planar is followed > immediately by the UV-planar, which is also an array of unsigned char > values tha...

...value? > Backwards compatibility. We can add an IOCTL for YUV / etc. [...] > But userspace must be able to continue allocating YUV buffers through > CREATE_DUMB. I think, allocating YUV buffers through CREATE_DUMB interface is just an *abuse* and *misuse* of this API for now. Take the NV12 format as an example, NV12 is YUV420 planar format, have two planar: the Y-planar and the UV-planar. The Y-planar appear first in memory as an array of unsigned char values. The Y-planar is followed immediately by the UV-planar, which is also an array of unsigned char values that contains packed U...

...au_xv.c index 567e30c..5569b7c 100644 --- a/src/nouveau_xv.c +++ b/src/nouveau_xv.c @@ -25,6 +25,8 @@ #include "config.h" #endif +#include <immintrin.h> + #include "xf86xv.h" #include <X11/extensions/Xv.h> #include "exa.h" @@ -532,30 +534,47 @@ NVCopyNV12ColorPlanes(unsigned char *src1, unsigned char *src2, w >>= 1; h >>= 1; +#ifdef __SSE2__ + l = w >> 3; + e = w & 7; +#else l = w >> 1; e = w & 1; +#endif for (j = 0; j < h; j++) { unsigned char *us = src1; unsigned char *vs = src2; unsigned i...

On 2013-07-31 19:18 +0200, Ilia Mirkin wrote: > On Wed, Jul 31, 2013 at 1:16 PM, Sven Joachim <svenjoac at gmx.de> wrote: >> >> Unfortunately, immintrin.h is not available on most architectures, >> leading to build failures as can be seen on >> https://buildd.debian.org/status/package.php?p=xserver-xorg-video-nouveau. > > Sorry :( I thought that immintrin.h

...g12 nv84_vp-vc1-1 nv84_vp-vc1-2 nv84_vp-vc1-3 nv84_xuc00f nv84_xuc103 $ vdpauinfo display: :0 screen: 0 API version: 1 Information string: G3DVL VDPAU Driver Shared Library version 1.0 Video surface: name width height types ------------------------------------------- 420 8192 8192 NV12 YV12 422 8192 8192 UYVY YUYV 444 8192 8192 Y8U8V8A8 V8U8Y8A8 Decoder capabilities: name level macbs width height ------------------------------------------- MPEG1 0 16384 2048 2048 MPEG2_SIMPLE 3 16384 2048 2048 MPEG2_MAIN 3 163...

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_xv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/nouveau_xv.c b/src/nouveau_xv.c index 8eafcf0..567e30c 100644 --- a/src/nouveau_xv.c +++ b/src/nouveau_xv.c @@ -552,8 +552,11 @@ NVCopyNV12ColorPlanes(unsigned char *src1, unsigned char *src2, if (e) { unsigned short *vud = (unsigned short *) vuvud; - +#if X_BYTE_ORDER == X_BIG_ENDIAN + *vud = us[0] | (vs[0]<<8); +#else *vud = vs[0] | (us[0]<<8); +#endif } dst += dstPitch; -- 1.8.1.5

...: VAEntrypointVideoProc First, I think EncSlice lines are invalid (or mesa can magically (shaders?) _encode_ mpeg2 videos?) Second .. ffmpeg command failed for me :/ ffmpeg -vaapi_device /dev/dri/renderD128 -benchmark -c:v libdav1d -i /mnt/sdb1/Stream2_AV1_720p_3.2mbps.webm -vf format=nv12,hwupload,scale_vaapi=w=240:h=120 -map 0:v:0 -v trace -f null - ffmpeg version N-93862-gf49cec2ba8 Copyright (c) 2000-2019 the FFmpeg developers built with gcc 5.5.0 (GCC) [skip] Applying option vaapi_device (set VAAPI hardware device (DRM path or X11 display name)) with argument /dev/dri/render...

On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote: > On Thu, Jan 16, 2025 at 11:03?AM Tomi Valkeinen > <tomi.valkeinen at ideasonboard.com> wrote: > > On 16/01/2025 10:09, Thomas Zimmermann wrote: > > > Am 15.01.25 um 15:20 schrieb Tomi Valkeinen: > > > [...] > > >> > > >> My point is that we have the current UAPI, and we

...e if we just define how the >>> userspace should use it for multiplanar, subsampled formats? >> >> That would duplicate format and hardware information in user-space. Some > > But we already have that, don't we? We have drivers and userspace that > support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we > don't document how CREATE_DUMB has to be used to allocate multiplanar > subsampled buffers, so the userspace devs have to "guess". Yeah, there are constrains in the scanline and buffer alignments and orientation. And i...

https://bugs.freedesktop.org/show_bug.cgi?id=86006 Bug ID: 86006 Summary: [NV84] Nvidia GeForce 8600 GT VDPAU h264 hardware acceleration Product: xorg Version: 7.6 (2010.12) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

...the >>>> userspace should use it for multiplanar, subsampled formats? >>> >>> That would duplicate format and hardware information in user-space. Some >> >> But we already have that, don't we? We have drivers and userspace that >> support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we >> don't document how CREATE_DUMB has to be used to allocate multiplanar >> subsampled buffers, so the userspace devs have to "guess". > > Yeah, there are constrains in the scanline and buffer alignments and...

...ent EXA and XVideo acceleration Dave Airlie (4): drmmode: add support for multi-screen reverse optimus fix make distcheck. nouveau: fix crash when xinerama is enabled. bump to 1.0.9 for release Ilia Mirkin (3): xv: fix last pixel for big-endian machines in YV12 -> NV12 conversion xv: speed up YV12 -> NV12 conversion using SSE2 if available nouveau: use uppercase for chipset name Maarten Lankhorst (1): fixup the dri2 check Sven Joachim (1): Link against libdrm git tag: xf86-video-nouveau-1.0.9 http://xorg.freedesktop.org/archive/indi...

...ent EXA and XVideo acceleration Dave Airlie (4): drmmode: add support for multi-screen reverse optimus fix make distcheck. nouveau: fix crash when xinerama is enabled. bump to 1.0.9 for release Ilia Mirkin (3): xv: fix last pixel for big-endian machines in YV12 -> NV12 conversion xv: speed up YV12 -> NV12 conversion using SSE2 if available nouveau: use uppercase for chipset name Maarten Lankhorst (1): fixup the dri2 check Sven Joachim (1): Link against libdrm git tag: xf86-video-nouveau-1.0.9 http://xorg.freedesktop.org/archive/indi...

...ats, or can it be suitable if we just define how the userspace >> should use it for multiplanar, subsampled formats? > > That would duplicate format and hardware information in user-space. Some But we already have that, don't we? We have drivers and userspace that support, say, NV12 via dumb buffers. But (correct me if I'm wrong) we don't document how CREATE_DUMB has to be used to allocate multiplanar subsampled buffers, so the userspace devs have to "guess". > hardware might have odd per-plane limitations that only the driver knows > about. For exa...

...rtant part of this is our screen capture tool, which works by querying drm for crtcs, planes, and fbs. Unfortunately, there is only limited information available via drmModeGetFB(), which often wrong information when drmModeAddFB2() was used to create the fbs. For example, if the pixel format is NV12 or YUV420, the fb returned knows nothing about the additional buffer planes required by these formats. Ideally, we would like a function (e.g. drmModeGetFB2) to return information symmetric with drmModeAddFB2 including the pixel format id, buffer plane information etc. </snip> ChromeOS has...

Hi Am 15.01.25 um 14:33 schrieb Tomi Valkeinen: [...] >> Yeah, there are constrains in the scanline and buffer alignments and >> orientation. And if we say that bpp==12 means NV12, it will be a >> problem for all other cases where bpp==12 makes sense. > > I feel I still don't quite understand. Can't we define and document > CREATE_DUMB like this: > > If (bpp < 8 || is_power_of_two(bpp)) > ????bpp means bitsperpixel > ????pitch is args-...