similar to: 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: 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 =

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

So, with all the nouveau_class.h changes lately it's become rather difficult to keep libdrm synced up with a particular mesa version. This is much like what happens when we break our kernel ABI, but on a far more regular basis so it has a larger impact. I'm proposing we drop nouveau_class.h from libdrm again, and move it back to the ddx and mesa trees where it can be updated at the same

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

On Sun, May 24, 2015 at 10:56 AM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 24.05.2015 16:15, Pierre Moreau wrote: >>> >>> On 24 May 2015, at 16:03, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>> >>> >>> >>> On 24.05.2015 10:38, Samuel Pitoiset wrote:

The attached patch does the cosmetic renouveau.xml changes I proposed. I'm about to reply myself with some other patches to update libdrm and then fix the API break up. -------------- next part -------------- A non-text attachment was scrubbed... Name: rename_some_nv10tcl_methods.patch Type: text/x-diff Size: 2507 bytes Desc: not available Url :

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 { + /*

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

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: Francisco Jerez <currojerez at riseup.net> --- I haven't pushed these changes to renouveau.xml yet, I'll do it soon if you guys are OK with this. nouveau/nouveau_class.h | 1036 +++++++++++++++++++++++----------------------- 1 files changed, 518 insertions(+), 518 deletions(-) diff --git a/nouveau/nouveau_class.h b/nouveau/nouveau_class.h index c5fe5d7..87e167b

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 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 or do nothing. > > Marek > My thinking was gallium should have a single semantic and a mask in the shader definition maybe. though it doesn't solve the does nvidia do the right thing with

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

Hi, On 03-08-15 20:09, Ilia Mirkin wrote: > On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede <hdegoede at redhat.com> wrote: >> Hi, >> >> >> On 03-08-15 17:36, Ilia Mirkin wrote: >>> >>> On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede <hdegoede at redhat.com> wrote: >>>> >>>> Hi, >>>> >>>> On