similar to: Fwd: xf86-video-nouveau compile error and fix

Hello, I found xf86-video-nouveau unable to compile on my system. Failing with two errors in nv_accel_common.c about NV50_2D_CLIP_ENABLE and NV50_2D_COLOR_KEY_ENABLE not being defined. Comparing the source to xf86-video-nv, i found the missing constants to be 0x290 for CLIP_ENABLE and 0x29c for COLOR_KEY_ENABLE. This got nv_accel_common.c to compile. I'd request these two constants to be

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Would be nice if someone could glance at this... I suppose I could also compare object files. Yeah, I should probably do that. src/nv10_exa.c | 8 ++++---- src/nv30_exa.c | 20 ++++++++++---------- src/nv40_exa.c | 8 ++++---- src/nv50_accel.c | 6 +++--- src/nv50_accel.h | 1 + src/nv50_exa.c

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested. src/nouveau_copy.c | 2 ++ src/nouveau_exa.c | 1 + src/nv_accel_common.c | 1 + src/nv_driver.c | 3 +++ src/nv_type.h | 1 + src/nvc0_accel.c | 6 ++++++ 6 files changed, 14 insertions(+) diff --git a/src/nouveau_copy.c b/src/nouveau_copy.c index 7118a7a..7fbcc87 100644 --- a/src/nouveau_copy.c

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- v1 -> v2: add 0x130 as a valid chip type early on in detection src/nouveau_copy.c | 2 ++ src/nouveau_exa.c | 1 + src/nv_accel_common.c | 1 + src/nv_driver.c | 4 ++++ src/nv_type.h | 1 + src/nvc0_accel.c | 6 ++++++ 6 files changed, 15 insertions(+) diff --git a/src/nouveau_copy.c

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Highlights: - Support for server managed fd's. - Glamor support. - Maxwell support. - DRI3 and initial Present support. - vsync'ed kms pageflip performance fixes when running on Linux 3.13+ - Multi-display vsync, vblank, swap scheduling, timestamping fixes. - Multi x-screen support fixes. - ZaphodHead support on for

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Highlights: - Support for server managed fd's. - Glamor support. - Maxwell support. - DRI3 and initial Present support. - vsync'ed kms pageflip performance fixes when running on Linux 3.13+ - Multi-display vsync, vblank, swap scheduling, timestamping fixes. - Multi x-screen support fixes. - ZaphodHead support on for

Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com> --- src/nv_accel_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/nv_accel_common.c b/src/nv_accel_common.c index 4484c1c..eebb0ab 100644 --- a/src/nv_accel_common.c +++ b/src/nv_accel_common.c @@ -37,7 +37,7 @@ nouveau_allocate_surface(ScrnInfoPtr scrn, int width, int height, int bpp, Bool tiled =

From: Marcin Slusarz <marcin.slusarz at gmail.com> after this change nouveau passes all fill and blend tests of rendercheck (before: fill - 108/120, blend - 3323868/3569150) tested on NV34 Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- src/nv04_exa.c | 19 +++++++++---------- src/nv_accel_common.c | 5 ++++- 2 files changed, 13 insertions(+), 11

--- src/nouveau_dri2.c | 4 +++- src/nv_accel_common.c | 4 ++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c index d14443f..b99893f 100644 --- a/src/nouveau_dri2.c +++ b/src/nouveau_dri2.c @@ -46,6 +46,8 @@ nouveau_dri2_create_buffer(DrawablePtr pDraw, unsigned int attachment, ppix->refcnt++; } else { + /*

With this patch the DDX almost works with GK20A, the missing piece is adding COHERENT mappings to the right places. ;-) If you specify NOUVEAU_BO_APER the kernel will truncate valid_domains to the domains specified at creation time. This means that as long as we only specify the correct domain in nouveau_allocate_surface the effect is still the same. Signed-off-by: Maarten Lankhorst <dev at

Hello, after searching through the archives and not finding a thread that answers this question, I thought I'd pass it on to the list. Given a data frame and given a factor variable that assigns a class to each case in the data frame, what is the most efficient way to sample a given number of cases from each class? I've found a roundabout solution that works as follows: for each class:

Dear list, I use Sweave almost exclusively for writing papers, and I have become quite spoiled by the excellent xtable export facilities. Has anybody written an xtable method for the Anova function in CAR, or has anybody used a different set of functions to import Anova results into a table in an Sweave document? If not, any handy hints on how to write a good homebrew based on the output of Anova

Hi, first of all: I'm not only new to R, but also to S. I hope this is the right forum for asking the following very stupid questions: a) is there a straightforward way of saying for all factors f in a data frame { any old function, e.g. max(f) } b) how can you construct a new data frame d' from a given data frame d which contains only rows with [X=="A"] (x is

the original message looks like it was corrupted when it got to the list, so here's another try ... -----Original Message----- From: Tim Wolters Sent: Sun 11/10/2002 10:55 AM To: samba@lists.samba.org Cc: Subject: nmbd help please I've been working on this for about a week now and can't seem to figure out the magic configuration that will make my Samba server work.

hello when i Tried to compile xf86-video-nouveau come this message: cc1: error: unrecognized command line option "-minline-all-stringops" make[2]: *** [nv_accel_common.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail:

https://bugs.freedesktop.org/show_bug.cgi?id=80738 Priority: medium Bug ID: 80738 Assignee: nouveau at lists.freedesktop.org Summary: Possible wrong variable used in nouveau_allocate_surface QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All

I ran into the following error message : ---snipp--- Call kernel32.495: LoadLibraryA(102951c8 "ctmp3Lib.dll") ret=1025f5ad fs=008f Call kernel32.922: __wine_register_dll_16(418ff5ac) ret=418bd4f0 fs=008f Ret kernel32.922: __wine_register_dll_16() retval=418ff5ac ret=418bd4f0 fs=008f err:win32:fixup_imports No implementation for NTDLL.dll.3(IoUnregisterDeviceInterface), setting to

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,

On Mon, May 25, 2015 at 9:40 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > On 25.05.2015 07:17, Dave Airlie wrote: >> >> On 25 May 2015 at 08:11, Marek Olšák <maraeo at gmail.com> wrote: >>> >>> It's the same on Radeon. There are 2x ClipOrCullDistance output >>> vectors and a mask saying it should clip or cull