search for: m2mf

Hi all, I am trying to use the 0x110 SERIALIZE (or 0x108 WAIT_FOR_IDLE?) command to barrier the PGRAPH commands. Unfortunately, I do not find any examples either in nouveau or gallium. If it plays just a barrier, I guess it should work by something like (in case of m2mf): BEGIN_RING(chan, m2mf, 0x110, 1); OUT_RING(chan, 1); Otherwise, it may actually play to serialize some commands, then I would rather use as follows: BEGIN_RING(chan, m2mf, 0x110, 1); OUT_RING(chan, NUMBER_OF_FOLLOWING_COMMANDS); I have tried both approaches, and the application runs without any...

...seems really very 'simple': "use crypto engine for async buffer copies" @@ -821,6 +839,7 @@ nouveau_bo_move_init(struct nouveau_channel *chan) } _methods[] = { { "COPY", 0xa0b5, nve0_bo_move_copy, nvc0_bo_move_init }, { "M2MF", 0x9039, nvc0_bo_move_m2mf, nvc0_bo_move_init }, + { "CRYPT", 0x74c1, nv84_bo_move_exec, nv50_bo_move_init }, { "M2MF", 0x5039, nv50_bo_move_m2mf, nv50_bo_move_init }, { "M2MF", 0x0039, nv04_bo_move_m2mf, nv04_bo_mo...

....c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 11ca821..7ff1071 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -801,7 +801,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct ttm_buffer_object *bo, stride = 16 * 4; height = amount / stride; - if (new_mem->mem_type == TTM_PL_VRAM && + if (old_mem->mem_type == TTM_PL_VRAM && nouveau_bo_tile_layout(nvbo)) { ret = RING_SPACE(chan, 8); if (...

..._screen.c @@ -407,8 +407,6 @@ nvc0_screen_destroy(struct pipe_screen *pscreen) FREE(screen->tic.entries); - nouveau_mm_destroy(screen->mm_VRAM_fe0); - nouveau_object_del(&screen->eng3d); nouveau_object_del(&screen->eng2d); nouveau_object_del(&screen->m2mf); @@ -1027,7 +1025,6 @@ nvc0_screen_create(struct nouveau_device *dev) mm_config.nvc0.tile_mode = 0; mm_config.nvc0.memtype = 0xfe0; - screen->mm_VRAM_fe0 = nouveau_mm_create(dev, NOUVEAU_BO_VRAM, &mm_config); if (!nvc0_blitter_create(screen)) goto fail; diff --git a...

...newdataMaker(m1, fl = list(x2 = c(50, 60), xcat2 = c("M","D"))) pr <- predictOMatic(m1, fl = list(x2 = c(50, 60), xcat2 = c("M","D")), interval="conf") ## m2 <- glm(xcat2 ~ x1 + x2 + x3 + xcat1, data=dat, family=binomial(logit)) summary(m2) m2mf <- model.frame(m2) summarize(m2mf) predict(m2, newdata=data.frame(xcat1=c("M","F"), x1=c(1), x2=mean(m2mf$x2), x3=mean(m2mf$x3)), se.fit=TRUE) predictOMatic(m2, fl = list(x2 = c(-1, 1), xcat1 = c("M","F")), interval="conf", type="response&...

...a (so, fui(nv50->viewport.scale[2])); diff --git a/src/gallium/drivers/nv50/nv50_transfer.c b/src/gallium/drivers/nv50/nv50_transfer.c index 4d9afa6..53e34a4 100644 --- a/src/gallium/drivers/nv50/nv50_transfer.c +++ b/src/gallium/drivers/nv50/nv50_transfer.c @@ -47,7 +47,7 @@ nv50_transfer_rect_m2mf(struct pipe_screen *pscreen, NV50_MEMORY_TO_MEMORY_FORMAT_LINEAR_IN, 1); OUT_RING (chan, 1); BEGIN_RING(chan, m2mf, - NV50_MEMORY_TO_MEMORY_FORMAT_PITCH_IN, 1); + NV04_MEMORY_TO_MEMORY_FORMAT_PITCH_IN, 1); OUT_RING (chan, src_pitch); src_offset += (sy * src_pitch) + (sx * cpp)...

...b74a 100644 > --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c > +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c > @@ -447,7 +447,6 @@ nvc0_screen_destroy(struct pipe_screen *pscreen) > nouveau_object_del(&screen->eng2d); > nouveau_object_del(&screen->m2mf); > nouveau_object_del(&screen->compute); > - nouveau_object_del(&screen->nvsw); > > nouveau_screen_fini(&screen->base); > > @@ -698,13 +697,6 @@ nvc0_screen_create(struct nouveau_device *dev) > screen->base.fence.update = nvc0_screen_fe...

...screen.c index 4897ebe..11cb74a 100644 --- a/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_screen.c @@ -447,7 +447,6 @@ nvc0_screen_destroy(struct pipe_screen *pscreen) nouveau_object_del(&screen->eng2d); nouveau_object_del(&screen->m2mf); nouveau_object_del(&screen->compute); - nouveau_object_del(&screen->nvsw); nouveau_screen_fini(&screen->base); @@ -698,13 +697,6 @@ nvc0_screen_create(struct nouveau_device *dev) screen->base.fence.update = nvc0_screen_fence_update; - ret = nouveau_...

...close together on the same piece of memory (no hard proof to back this up, just something i noticed). I'm using the dma engine quite heavily and i've pretty much narrowed it down to that. I'm wondering if anyone has ever had such problems or knows of some special sync that is needed for m2mf. I'm doing copy, map, unmap, copy back for pretty much everything. About 10 secs of gtkperf is enough to trigger it. I've gone as far as placing an NVSync after every dma transfer. I'd appreciate any kind of hint. Maarten.

...+++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/rnndb/nv50_pgraph.xml b/rnndb/nv50_pgraph.xml index 92d69ea..6499631 100644 --- a/rnndb/nv50_pgraph.xml +++ b/rnndb/nv50_pgraph.xml @@ -93,6 +93,9 @@ <value value="0x23" name="XY_OUT_OF_BOUNDS"> <!-- m2mf at least. 2d too? --> <brief>Your x/y coords exceed the size of your surface.</brief> </value> + <value value="0x24" name="VP_NO_INPUT_MASK"> + <brief>You tried to submit vertices without setting input mask (VP_ATTR_EN).</brief> + &lt...

The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. Signed-off-by: Henrik Rydberg <rydberg at euromail.se> --- Hi Ben, this patch is still needed in 3.6-rc1, so perhaps we should apply it after all. I have been running it without problems for a long time now. Thanks, Henrik drivers/gpu/drm/nouveau/nouveau_state....

...e prints, which feel like they're accompanied by bad frames: 0x7f7fcb29ab70 is not a real ref: -0.011 72712/72709 0% 35% 1.0% 0 0 This comes from if (dec->refs[idx].vidbuf != refs[i]) { debug_printf("%p is not a real ref\n", refs[i]); // FIXME: Maybe do m2mf copy here if a application really depends on it? continue; } Can you explain what this means, and what the fixme is referring to? -ilia

...creen_destroy(struct pipe_screen *pscreen) > > FREE(screen->tic.entries); > > - nouveau_mm_destroy(screen->mm_VRAM_fe0); > - > nouveau_object_del(&screen->eng3d); > nouveau_object_del(&screen->eng2d); > nouveau_object_del(&screen->m2mf); > @@ -1027,7 +1025,6 @@ nvc0_screen_create(struct nouveau_device *dev) > > mm_config.nvc0.tile_mode = 0; > mm_config.nvc0.memtype = 0xfe0; > - screen->mm_VRAM_fe0 = nouveau_mm_create(dev, NOUVEAU_BO_VRAM, &mm_config); > > if (!nvc0_blitter_create(screen))...

...n) > > > > FREE(screen->tic.entries); > > > > - nouveau_mm_destroy(screen->mm_VRAM_fe0); > > - > > nouveau_object_del(&screen->eng3d); > > nouveau_object_del(&screen->eng2d); > > nouveau_object_del(&screen->m2mf); > > @@ -1027,7 +1025,6 @@ nvc0_screen_create(struct nouveau_device *dev) > > > > mm_config.nvc0.tile_mode = 0; > > mm_config.nvc0.memtype = 0xfe0; > > - screen->mm_VRAM_fe0 = nouveau_mm_create(dev, NOUVEAU_BO_VRAM, > &mm_config); > > > &g...

Hi ! I think src and dst starting positions got mixed up in nv50_transfer_rect_m2mf, there's a diff at the bottom of this message. This came up when trying to make the gearbox demo run correctly, but this change alone doesn't fix it. The mesa state tracker in st_cb_clear.c assumes Y_0_TOP when clearing the color buffer, but that seems to be wrong for NV50. When bypassing t...

...allocated. According to the wiki docs, I need to set NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN into the 'notify' field of an object in a channel. Hence, I tried seting a flag to a DMA notifier in nouveau_dma_init(): // seems entry[1] is related to a DMA notifier? nv_wo32(dev, m2mf, 1, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); I also tried sending some command: // guess this is a very wrong way ;-) BEGIN_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY, 1); OUT_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); But they both did not work... Ho...

Hello, A user on an NVC3 card (GF106) is running into data errors on m2mf (class 0x9039) that we haven't seen before: http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/glean/fbo.html http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/spec/!OpenGL%201.1/copyteximage%201D.html Specifically the data errors 0x5...

...{ + if ((nv_rd32(priv, 0x100c14) & 0x00000002) == 0x00000000) { + nv_wr32(priv, 0x100c1c, priv->r100c08 >> 8); + nv_mask(priv, 0x100c14, 0x00000000, 0x00000002); + } + } + /* Not a clue what this is exactly. Without pointing it at a * scratch page, VRAM->GART blits with M2MF (as in DDX DFS) * cause IOMMU "read from address 0" errors (rh#561267) -- 2.1.2

...hed some light on the true problem, such that a fix can be found for 3.5. Thanks, Henrik The nva3 copy engine exhibits random memory corruption in at least one case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch omits creating the engine for the specific chipset, falling back to M2MF, which kills the symptoms. --- drivers/gpu/drm/nouveau/nouveau_state.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c b/drivers/gpu/drm/nouveau/nouveau_state.c index 19706f0..b466937 100644 --- a/drivers/gpu/drm/nouveau/nouveau_state.c +++ b/drivers/gpu/...

Before this patch they were being reset to zero on every context switch instead of leaving the saved value, causing some context switching weirdness (the most serious symptom was the memory manager corrupting the BOs it migrated because of a malfunctioning M2MF). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nv10_graph.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv10_graph.c b/drivers/gpu/drm/nouveau/nv10_graph.c index cf5c9c4..6bf6804 100644 --- a/dri...