similar to: [PATCH xf86-video-nouveau] xv: fix build warning regarding const qualifier

On Sat, 19 Jan 2019 at 18:32, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Is vlCreateAdaptorXvMC just silly, or does it really want to take > ownership of the name pointer? > vlCreateAdaptorXvMC( ) doesn't need to take over ownership of the name pointer, so yes - I guess it's being silly in one respect by not being specific about const. > > On Sat, Jan 19, 2019

Is vlCreateAdaptorXvMC just silly, or does it really want to take ownership of the name pointer? On Sat, Jan 19, 2019 at 6:30 PM Rhys Kidd <rhyskidd at gmail.com> wrote: > > Fixes warning with gcc 8.2: > > nouveau_xv.c: In function ‘NVInitVideo’: > nouveau_xv.c:2247:68: warning: passing argument 2 of ‘vlCreateAdaptorXvMC’ discards ‘const’ qualifier from pointer target type

Silences warning with gcc 8.2: nouveau_xv.c: In function ‘NVInitVideo’: nouveau_xv.c:2247:68: warning: passing argument 2 of ‘vlCreateAdaptorXvMC’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] adaptorsXvMC[0] = vlCreateAdaptorXvMC(pScreen, textureAdaptor[0]->name); ~~~~~~~~~~~~~~~~~^~~~~~ In file included

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for

A short series of compiler visibility warning fixes that I prepared whilst trialing improvements to xf86-video-nouveau's use of the core xorg-server utility macros. Rhys Kidd (4): wfb: Remove declaration for undefined function nouveau_wfb_init() dri2: Mark local create/destroy buffer and copy region functions as static xv: Mark local NVSetupTexturedVideo function as static

int i is accessed outside immediate scope so leave declaration at the highest common scope level: 1073: int ret, i; ... // Highest common scope ... 1193: if (newTTSize <= destination_buffer->size) { ... // Used in this scope ... 1248: } else { ... // Used in this scope ... 1316: }

rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to work. Very lightly tested. Instead of sticking coordinates into pushbufs, the vertex shader is modified to read them from a constbuf, indexed by vertex id. This approach could be used for all nvc0 generations, but I didn't want to rock the boat. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Note: this

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

Hi! With current git version of xorg-server when I try to compile xf86-video-nouveau I got these errors: nouveau_exa.lo nouveau_exa.c: In function 'nouveau_exa_create_pixmap': nouveau_exa.c:325:3: warning: 'Xcalloc' is deprecated (declared at /usr/include/xorg/os.h:225) nouveau_exa.c:331:2: warning: 'Xcalloc' is deprecated (declared at /usr/include/xorg/os.h:225)

The control flow was: if (!y) { ppix = ... } if (y) { ... } else if (x) { use ppix for something } else { use ppix for something } Merge the if(!y) block with the two else branches. This avoids a false-positive in the clang static analyzer, it can't know that !y and x are mutually exclusive. The result looks something like this: if (y) { ... } else { ppix = ... if (x) {

xorg-server can be built without glamor, which leads to: CC nouveau_xv.lo In file included from nouveau_xv.c:41:0: nouveau_glamor.h:12:20: fatal error: glamor.h: No such file or directory compilation terminated. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- configure.ac | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/configure.ac

https://bugs.freedesktop.org/show_bug.cgi?id=63263 Priority: medium Bug ID: 63263 Assignee: nouveau at lists.freedesktop.org Summary: X server crash in nouveau_xv.c:NVPutImage (NVCopyNV12ColorPlanes) QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All)

I believe I've addressed all the feedback from the first time around, and also made fixes necessary for GM20x based on testing results. I believe now it should actually work for all GM10x and GM20x. Further, GP10x should be very easy to add, but without someone to actually test I didn't want to claim support for it. Ilia Mirkin (7): exa: add GM10x acceleration support hwdefs: update

rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to work. Very lightly tested. Instead of sticking coordinates into pushbufs, the vertex shader is modified to read them from a constbuf, indexed by vertex id. This approach could be used for all nvc0 generations, but I didn't want to rock the boat. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> ---

Looks reasonable, some minor comments below. On 10/16/2016 02:06 AM, Ilia Mirkin wrote: > rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to > work. Very lightly tested. > > Instead of sticking coordinates into pushbufs, the vertex shader is > modified to read them from a constbuf, indexed by vertex id. This > approach could be used for all nvc0 generations,

Warning reported by gcc 8.2: nouveau_xv.c: In function ‘NVPutImage’: nouveau_xv.c:1369:7: warning: declaration of ‘ret’ shadows a previous local [-Wshadow] int ret = BadImplementation; ^~~ nouveau_xv.c:1073:6: note: shadowed declaration is here int ret, i; ^~~ Fixes: a50bba6 ("xv: misc cleanups") Cc: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Rhys Kidd

The 'w' argument to NVCopyNV12ColorPlanes is used to index into the source image. line_len is rounded up to 8 on NV50+, so if the source image (+ left offset) is not rounded to 8, NVCopyNV12ColorPlanes could read past the end of the array and crash X. This change can cause the last few horizontal pixels of dst to not be initialized, but they should be truncated by the renderer anyways.

Not clear what the depth % 8 was trying to protect against, but it was breaking 30bpp visuals with DRI3. Add it in to ensure that bitsPerPixel % 8 is 0, since there is plenty of bpp/8 math in the driver. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_dri2.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c

in nv10_exa.c : check_texture does : if (w > 2046 || h > 2046) NOUVEAU_FALLBACK("picture too large, %dx%d\n", w, h); check_render_target does : if (w > 4096 || h > 4096) return FALSE; So we have different size limits for the source and the destination ? Another thing is that nv20 uses nv10_exa.c code, and the limit in

memcpy() goes from taking 45% to 66% of total function time, which translates to a 30% decrease in NVPutImage runtime. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/nouveau_xv.c | 33 ++++++++++++++++++++++++++------- 1 file changed, 26 insertions(+), 7 deletions(-) diff --git a/src/nouveau_xv.c b/src/nouveau_xv.c index 567e30c..5569b7c 100644 --- a/src/nouveau_xv.c +++