similar to: [PATCH 1/2] xv: fix last pixel for big-endian machines in YV12 -> NV12 conversion

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 +++

http://bugs.freedesktop.org/show_bug.cgi?id=14168 Summary: endian bug on powerpc Product: xorg Version: unspecified Platform: PowerPC OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy: obiwan at

http://bugs.freedesktop.org/show_bug.cgi?id=10957 Summary: Garbled console text with XAA enabled Product: xorg Version: 7.1 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org ReportedBy:

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

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: }

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 [-Wdiscarded-qualifiers] adaptorsXvMC[0] = vlCreateAdaptorXvMC(pScreen, textureAdaptor[0]->name); ~~~~~~~~~~~~~~~~~^~~~~~ In file included from

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

--- src/drmmode_display.c | 29 +++++++++++++++++-- src/nouveau_hw.h | 17 +++++++++++ src/nv_cursor.c | 74 ++++++++++++++++++++++++------------------------ src/nv_proto.h | 2 + 4 files changed, 82 insertions(+), 40 deletions(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index f2fe0e8..7acddf1 100644 --- a/src/drmmode_display.c +++

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)

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

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

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

I did a very quick pass at removing all the non-KMS support from the DDX. It's tested on G80 but nowhere else currently, I thought some discussion would be a good idea rather than just ripping it out :) The non-KMS paths are messy, and lets face it, rotting badly. IMO the KMS code is stable enough now that we can continue without the UMS crutch, and indeed, the KMS code supports a lot more

I''m playing around with snv_128 on one of my systems, and trying to see what kinda of benefits enabling dedup will give me. The standard practice for reprocessing data that''s already stored to add compression and now dedup seems to be a send / receive pipe similar to: zfs send -R <old fs>@snap | zfs recv -d <new fs> However, according to the man page,

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

- added lots of comments, discussed comments with ahuillet and refined comments - replaced two constants with MACROs - no changes to actual code diff --git a/src/nv_video.c b/src/nv_video.c index cf4f88d..d9ee700 100644 --- a/src/nv_video.c +++ b/src/nv_video.c @@ -25,6 +25,15 @@ #include "nv_include.h" #include "nv_dma.h" +/* +2046 is the maximum image size in one

http://bugs.freedesktop.org/show_bug.cgi?id=15792 Summary: nv04 (TNT2) video blitter problem. Product: xorg Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org