search for: sifm

...2015 at 7:25 AM, Hans de Goede <hdegoede at redhat.com> wrote: > On nv3x we will likely end up using the cpu to do color resolving for msaa > blits. Disable msaa on these cards so that we do not end up using the cpu. Actually the CPU fallback won't do scaled, so it's stuck with SIFM or assert(false). Which isn't great, but... it's what the HW does. I don't see a reason to shut that off. I'd rather disallow allocating MS surfaces that SIFM won't later be able to resolve on nv3x. > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- >...

The sifm object has a limit of 1024x1024 for its input size and 2048x2048 for its output. The code checking this was trying to be clever resulting in it seeing a surface of e.g 1024x256 being outside of the input size limit. This commit fixes this. Signed-off-by: Hans de Goede <hdegoede at redhat.com&g...

...arately, why not use this approach on nv40 as well? I can't imagine the blitter would be faster... does this result in lower quality? On Mon, Sep 7, 2015 at 3:50 PM, Hans de Goede <hdegoede at redhat.com> wrote: > We do not have a generic blitter on nv3x cards, so we must use the > sifm object for color resolving. > > This commit divides the sources and dest surfaces in to tiles which > match the constraints of the sifm object, so that color resolving > will work properly on nv3x cards. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- >...

We do not have a generic blitter on nv3x cards, so we must use the sifm object for color resolving. This commit divides the sources and dest surfaces in to tiles which match the constraints of the sifm object, so that color resolving will work properly on nv3x cards. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- Changes in v2: -Use 1024x1024 blocks...

This fixes a somewhat indeterministic corruption problem on nv17 when there is stuff going on the other fifos (e.g. gallium but I've also reproduced it with an app just SIFM-ing memory around): in some cases it made the blits the X server had scheduled use the wrong pitch. Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- src/nv04_exa.c | 22 ++++++++++++---------- 1 files changed, 12 insertions(+), 10 deletions(-) diff --git a/src/nv04_exa.c b/s...

...> I've done some digging through the code and this translates to the > "sfim" object in the gallium nv30 code. I was wondering if I cannot > just simple call nv30_transfer_rect with the right parameters and > let it sort the blit out ? That seems fine to me. BTW, it's sifm == scaled image from memory, not sfim. You'll either have to fudge the width/height, or teach the transfer methods to look at mt->ms_x/y (and make sure to treat it as a scaled xfer if the nr_samples don't line up). -ilia

...4_patt }, + { 0x018c, nv04_graph_mthd_bind_rop }, + { 0x0190, nv04_graph_mthd_bind_beta1 }, + { 0x0194, nv04_graph_mthd_bind_beta4 }, + { 0x0198, nv04_graph_mthd_bind_surf2d }, { 0x02fc, nv04_graph_mthd_set_operation }, {}, }; +static struct nouveau_pgraph_object_method nv04_graph_mthds_nv03_sifm[] = { + { 0x0188, nv04_graph_mthd_bind_nv01_patt }, + { 0x018c, nv04_graph_mthd_bind_rop }, + { 0x0190, nv04_graph_mthd_bind_beta1 }, + { 0x0194, nv04_graph_mthd_bind_surf_dst }, + { 0x0304, nv04_graph_mthd_set_operation }, + {}, +}; + +static struct nouveau_pgraph_object_method nv04_graph_mthds_nv...

...gallium/drivers/nv04/nv04_surface_2d.c +++ b/src/gallium/drivers/nv04/nv04_surface_2d.c @@ -125,8 +125,8 @@ nv04_surface_copy_swizzle(struct nv04_surface_2d *ctx, struct nouveau_channel *chan = ctx->swzsurf->channel; struct nouveau_grobj *swzsurf = ctx->swzsurf; struct nouveau_grobj *sifm = ctx->sifm; - struct nouveau_bo *src_bo = nouveau_bo(ctx->buf(src)); - struct nouveau_bo *dst_bo = nouveau_bo(ctx->buf(dst)); + struct nouveau_bo *src_bo = ((struct nv04_miptree*)src->texture)->bo; + struct nouveau_bo *dst_bo = ((struct nv04_miptree*)dst->texture)->bo; const...

...gallium/drivers/nv04/nv04_surface_2d.c +++ b/src/gallium/drivers/nv04/nv04_surface_2d.c @@ -125,8 +125,8 @@ nv04_surface_copy_swizzle(struct nv04_surface_2d *ctx, struct nouveau_channel *chan = ctx->swzsurf->channel; struct nouveau_grobj *swzsurf = ctx->swzsurf; struct nouveau_grobj *sifm = ctx->sifm; - struct nouveau_bo *src_bo = nouveau_bo(ctx->buf(src)); - struct nouveau_bo *dst_bo = nouveau_bo(ctx->buf(dst)); + struct nouveau_bo *src_bo = ((struct nv04_miptree*)src->texture)->bo; + struct nouveau_bo *dst_bo = ((struct nv04_miptree*)dst->texture)->bo; const...

Hi All, Here is a bunch of fixes for nv30 cards, the first patch is a resend of a patch I send a while back. AFAICT that one is ready for merging, but it is not entirely clear to me what the process is for getting (nouveau) mesa patches merged. Should I request commit rights, and push my own patches once they have been reviewed ? Regards, Hans

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv04_fbcon.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv04_fbcon.c b/drivers/gpu/drm/nouveau/nv04_fbcon.c index 813b25c..7cf9287 100644 --- a/drivers/gpu/drm/nouveau/nv04_fbcon.c +++ b/drivers/gpu/drm/nouveau/nv04_fbcon.c @@ -236,7 +236,7 @@

.../* kelvin */ {} } }; diff --git a/drm/nouveau/nvkm/engine/gr/nv34.c b/drm/nouveau/nvkm/engine/gr/nv34.c index 300f5ed..e7ed04b 100644 --- a/drm/nouveau/nvkm/engine/gr/nv34.c +++ b/drm/nouveau/nvkm/engine/gr/nv34.c @@ -123,6 +123,7 @@ nv34_gr = { { -1, -1, 0x0389, &nv04_gr_object }, /* sifm (nv30) */ { -1, -1, 0x038a, &nv04_gr_object }, /* ifc (nv30) */ { -1, -1, 0x039e, &nv04_gr_object }, /* swzsurf (nv30) */ + { -1, -1, 0x0597, &nv04_gr_object }, /* kelvin */ { -1, -1, 0x0697, &nv04_gr_object }, /* rankine */ {} } diff --git a/drm/nouveau/nvkm/engine/g...

...nouveau_fence_ref(NULL, &current); - nouveau_fence_ref(NULL, &screen->base.fence.current); - } - - nouveau_object_del(&screen->query); - nouveau_object_del(&screen->fence); nouveau_object_del(&screen->ntfy); nouveau_object_del(&screen->sifm); @@ -361,10 +319,9 @@ nv30_screen_create(struct nouveau_device *dev) { struct nv30_screen *screen = CALLOC_STRUCT(nv30_screen); struct pipe_screen *pscreen; - struct nouveau_pushbuf *push; struct nv04_fifo *fifo; unsigned oclass = 0; - int ret, i; + int ret; if (!scree...

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4 +-

On Mon, Aug 31, 2015 at 8:58 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Hi, > > > On 28-08-15 11:02, Ilia Mirkin wrote: >> >> On Fri, Aug 28, 2015 at 4:54 AM, Hans de Goede <hdegoede at redhat.com> >> wrote: >>> >>> Hi, >>> >>> On 27-08-15 20:19, Ilia Mirkin wrote: >>>> >>>>

...nt); > - nouveau_fence_ref(NULL, &screen->base.fence.current); > - } > - > - nouveau_object_del(&screen->query); > - nouveau_object_del(&screen->fence); > nouveau_object_del(&screen->ntfy); > > nouveau_object_del(&screen->sifm); > @@ -361,10 +319,9 @@ nv30_screen_create(struct nouveau_device *dev) > { > struct nv30_screen *screen = CALLOC_STRUCT(nv30_screen); > struct pipe_screen *pscreen; > - struct nouveau_pushbuf *push; > struct nv04_fifo *fifo; > unsigned oclass = 0; > - i...

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_fence.c | 76 ++++++++++++------------- src/gallium/drivers/nouveau/nouveau_fence.h | 22 +++++-- src/gallium/drivers/nouveau/nouveau_screen.c | 9 +++ src/gallium/drivers/nouveau/nouveau_screen.h | 14 ++--- src/gallium/drivers/nouveau/nv30/nv30_context.c | 4