search for: nv01_subchan_object

NACK. This patches breaks MP performance counters on Fermi/Kepler because they actually use software methods to configure multiplexers. Global perf counters will also use software methods to init, sample and read hardware counters, so this SW object is definitely needed. Instead of removing it, we need to do something like that: http://paste.awesom.eu/EQeX Thanks. On 11/27/2015 02:05 AM,

...return ret; + return ret; +} + +void +nvc0_context_compute_setup(struct nvc0_context *nvc0) +{ + struct nouveau_pushbuf *push = nvc0->base.pushbuf; + struct nvc0_screen *screen = nvc0->screen; + int i; + + if (!screen->parm) + return; BEGIN_NVC0(push, SUBC_COMPUTE(NV01_SUBCHAN_OBJECT), 1); PUSH_DATA (push, screen->compute->oclass); @@ -117,8 +125,6 @@ nvc0_screen_compute_setup(struct nvc0_screen *screen, PUSH_DATA (push, (0 << 8) | 1); /* TODO: textures & samplers */ - - return 0; } boolean diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_c...

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

...reen->nvsw); + ret = nouveau_object_new(chan, (dev->chipset < 0xe0) ? 0x1f906e : 0x906e, + NVIF_CLASS_SW_GF100, NULL, 0, &screen->nvsw); if (ret) FAIL_SCREEN_INIT("Error creating SW object: %d\n", ret); + BEGIN_NVC0(push, SUBC_SW(NV01_SUBCHAN_OBJECT), 1); + PUSH_DATA (push, screen->nvsw->handle); switch (dev->chipset & ~0xf) { case 0x110: -- 2.6.4

...+nvc0_context_compute_setup(struct nvc0_context *nvc0) > +{ > + struct nouveau_pushbuf *push = nvc0->base.pushbuf; > + struct nvc0_screen *screen = nvc0->screen; > + int i; > + > + if (!screen->parm) > + return; > > BEGIN_NVC0(push, SUBC_COMPUTE(NV01_SUBCHAN_OBJECT), 1); > PUSH_DATA (push, screen->compute->oclass); > @@ -117,8 +125,6 @@ nvc0_screen_compute_setup(struct nvc0_screen *screen, > PUSH_DATA (push, (0 << 8) | 1); > > /* TODO: textures & samplers */ > - > - return 0; > } > > boolean > d...

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

Hello there, This series exposes NVIDIA's global performance counters for Tesla through the Gallium's HUD and the GL_AMD_performance_monitor extension. This adds support for 24 hardware events which have been reverse engineered with PerfKit (Windows) and CUPTI (Linux). These hardware events will allow developers to profile OpenGL applications. To reduce latency and to improve accuracy,

...screen->pushbuf, dec->fence->offset); > + PUSH_DATA (screen->pushbuf, 1); > + PUSH_DATA (screen->pushbuf, 0xf010); > + PUSH_KICK (screen->pushbuf); > + > + PUSH_SPACE(bsp_push, 2 + 12 + 2 + 4 + 3); > + > + BEGIN_NV04(bsp_push, SUBC_BSP(NV01_SUBCHAN_OBJECT), 1); > + PUSH_DATA (bsp_push, dec->bsp->handle); > + > + BEGIN_NV04(bsp_push, SUBC_BSP(0x180), 11); > + for (i = 0; i < 11; i++) Any idea where 11 comes from ? Is it related to some other parameter ? > + PUSH_DATA(bsp_push, nv04_data.vram); > +...

...nce->offset); + PUSH_DATA (screen->pushbuf, dec->fence->offset); + PUSH_DATA (screen->pushbuf, 1); + PUSH_DATA (screen->pushbuf, 0xf010); + PUSH_KICK (screen->pushbuf); + + PUSH_SPACE(bsp_push, 2 + 12 + 2 + 4 + 3); + + BEGIN_NV04(bsp_push, SUBC_BSP(NV01_SUBCHAN_OBJECT), 1); + PUSH_DATA (bsp_push, dec->bsp->handle); + + BEGIN_NV04(bsp_push, SUBC_BSP(0x180), 11); + for (i = 0; i < 11; i++) + PUSH_DATA(bsp_push, nv04_data.vram); + BEGIN_NV04(bsp_push, SUBC_BSP(0x1b8), 1); + PUSH_DATA (bsp_push, nv04_data.vram); + + BEG...

...fence->offset); >> + PUSH_DATA (screen->pushbuf, 1); >> + PUSH_DATA (screen->pushbuf, 0xf010); >> + PUSH_KICK (screen->pushbuf); >> + >> + PUSH_SPACE(bsp_push, 2 + 12 + 2 + 4 + 3); >> + >> + BEGIN_NV04(bsp_push, SUBC_BSP(NV01_SUBCHAN_OBJECT), 1); >> + PUSH_DATA (bsp_push, dec->bsp->handle); >> + >> + BEGIN_NV04(bsp_push, SUBC_BSP(0x180), 11); >> + for (i = 0; i < 11; i++) > Any idea where 11 comes from ? Is it related to some other parameter ? These are the dma indices (e.g. when i u...

...nce->offset); + PUSH_DATA (screen->pushbuf, dec->fence->offset); + PUSH_DATA (screen->pushbuf, 1); + PUSH_DATA (screen->pushbuf, 0xf010); + PUSH_KICK (screen->pushbuf); + + PUSH_SPACE(bsp_push, 2 + 12 + 2 + 4 + 3); + + BEGIN_NV04(bsp_push, SUBC_BSP(NV01_SUBCHAN_OBJECT), 1); + PUSH_DATA (bsp_push, dec->bsp->handle); + + BEGIN_NV04(bsp_push, SUBC_BSP(0x180), 11); + for (i = 0; i < 11; i++) + PUSH_DATA(bsp_push, nv04_data.vram); + BEGIN_NV04(bsp_push, SUBC_BSP(0x1b8), 1); + PUSH_DATA (bsp_push, nv04_data.vram); + + BEG...

...gt; + PUSH_DATA (screen->pushbuf, 1); >>> + PUSH_DATA (screen->pushbuf, 0xf010); >>> + PUSH_KICK (screen->pushbuf); >>> + >>> + PUSH_SPACE(bsp_push, 2 + 12 + 2 + 4 + 3); >>> + >>> + BEGIN_NV04(bsp_push, SUBC_BSP(NV01_SUBCHAN_OBJECT), 1); >>> + PUSH_DATA (bsp_push, dec->bsp->handle); >>> + >>> + BEGIN_NV04(bsp_push, SUBC_BSP(0x180), 11); >>> + for (i = 0; i < 11; i++) >> Any idea where 11 comes from ? Is it related to some other parameter ? > > These are...

From: Ben Skeggs <bskeggs at redhat.com> v2. forgot bump for non-gallium driver Signed-off-by: Ben Skeggs <bskeggs at redhat.com> --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b6680d0..965c6f7 100644 --- a/configure.ac +++ b/configure.ac @@ -72,8 +72,8 @@ LIBDRM_REQUIRED=2.4.60

As it turns out, with the proprietary firmware, the VP3 and VP4 interfaces are identical. Furthermore, this is all already implemented for nvc0. So these patches (a) move the easily sharable bits of the nvc0 implementation into the nouveau directory, and then (b) implement the other parts in nv50. The non-shared parts are still largely copies, but there are some differences, not the least of which

.../nvc0_screen.c b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c index 5032c7f..5069e5a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -696,10 +696,10 @@ nvc0_screen_create(struct nouveau_device *dev) BEGIN_NVC0(push, SUBC_2D(NV01_SUBCHAN_OBJECT), 1); PUSH_DATA (push, screen->eng2d->oclass); - BEGIN_NVC0(push, NVC0_2D(SINGLE_GPC), 1); + BEGIN_NVC0(push, SUBC_2D(NVC0_2D_SINGLE_GPC), 1); PUSH_DATA (push, 0); BEGIN_NVC0(push, NVC0_2D(OPERATION), 1); - PUSH_DATA (push, NVC0_2D_OPERATION_SRCCOPY); + PUSH_DATA (push, NV...

The headers hadn't been regenerated in a long time, and there were a few minor divergences. Among other things, rnndb has changed naming to G80/etc, for now I've not tackled switching that over and manually replaced the nvidia codenames back to the chip ids. However no other modifications of the headergen'd headers was done. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>