similar to: [PATCH] nouveau: synchronize "scratch runout" destruction with the command stream

This logic is borrowed from the radeon code. The transfer logic will only get called for PIPE_BUFFER resources, so it shouldn't be necessary to worry about them becoming render targets. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- A user reported a ~30% FPS improvement with an earlier version of this patch in TF2, and no visual regressions in CS, all on a nv50 card. (Source

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 4 +--- src/gallium/drivers/nouveau/nouveau_context.h | 1 - 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/src/gallium/drivers/nouveau/nouveau_buffer.c b/src/gallium/drivers/nouveau/nouveau_buffer.c index e308ff4..904e2cc 100644 ---

On Wed, Nov 19, 2014 at 12:41 AM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative > VRAM domains for chips that do not use dedicated video memory. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++---- >

Different textures may be bound to each slot for each stage. So we need to be able to upload ms parameters for each one without stages overwriting each other. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.1 10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_lowering_nv50.cpp | 4 ++++

New revision of this patchset that prevents VRAM objects from being allocated on VRAM-less systems like Tegra. This is required for Mesa to work on such systems. Changes since v2: - Use vram_size to detect systems without VRAM and set the correct domain instead of expecting each chip to set its domain explicitly. Alexandre Courbot (2): nouveau: support for custom VRAM domains nvc0: use

This series is to allow NVIDIA chips with shared memory to operate more efficiently (and to operate at all once we disable VRAM from the kernel driver) by allowing nouveau_screen to specify a domain to use for objects originally allocated into VRAM. If the domain is not overridden, the default NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be used in place of

This series is to allow NVIDIA chips with shared memory to operate more efficiently (and to operate at all once we disable VRAM from the kernel driver) by allowing nouveau_screen to specify a domain to use for objects originally allocated into VRAM. If the domain is not overridden, the default NOUVEAU_BO_VRAM is used. A NV_VRAM_DOMAIN() macro is then introduced to be used in place of

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This is my shot at understanding this whole transfer business. The upshot is that after reading through it and understanding it, the transfer logic does appear correct if potentially less-than-perfectly-efficient (e.g. one could keep track of ranges being read/written, etc). src/gallium/drivers/nouveau/nouveau_buffer.c | 71

This fixes a memory leak in some situations. Also avoids emitting an extra fence if the kick handler does the call to nouveau_fence_next itself. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "9.2 10.0" <mesa-stable at lists.freedesktop.org> --- TBH I'm pretty confused by the whole fence refcounting logic and its interaction with emits, updates, etc. However

Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative VRAM domains for chips that do not use dedicated video memory. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 6 ++---- src/gallium/drivers/nouveau/nv50/nv50_miptree.c | 4 ++-- src/gallium/drivers/nouveau/nvc0/nvc0_compute.c | 2 +-

Hello Alex, Op 19-11-14 om 06:41 schreef Alexandre Courbot: > Use the newly-introduced NV_VRAM_DOMAIN() macro to support alternative > VRAM domains for chips that do not use dedicated video memory. Should we construct a similar patch for NVAA/NVAC (MCP7x) as well? > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- >

--- This is still a WIP. Just wanted to get people's opinions. It's also not bullet-proof. Unfortunately nouveau_bo_wait [which is in turn called by nouveau_bo_map] can trigger a kick, so technically we have to have a lock around any nouveau_bo_map. My strategy here was to add locks around all the user-accessible APIs while leaving all the internal stuff unlocked. When waiting for a

https://bugs.freedesktop.org/show_bug.cgi?id=59242 Priority: medium Bug ID: 59242 Assignee: nouveau at lists.freedesktop.org Summary: some mesa demos start to segfault after "nouveau: improve buffer transfers" on nv43 Severity: normal Classification: Unclassified OS: Linux (All)

I just tried to install an ancient detective-type RPG ( I am not up with the classifications.) (a) It offered to install DirectX. Since Wine has its own DirectX, I ignored that. (b) The game failed to run because (according to the message box) it couldn't find DirectDraw. This showed as a Fixme in the terminal, while the error message was to do with the display settings - there was no mode

https://bugs.freedesktop.org/show_bug.cgi?id=99354 Bug ID: 99354 Summary: [G71] "Assertion `bkref' failed" reproducible with glmark2 Product: Mesa Version: 13.0 Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium

https://bugs.freedesktop.org/show_bug.cgi?id=99396 Bug ID: 99396 Summary: Crash in nouveau_dri.so when switching apps with alt-tab in Gnome Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=105382 Bug ID: 105382 Summary: segfault in nouveau_scratch_data when using 2 nouveau cards Product: Mesa Version: 17.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau

nv30 seems to not support dma objects with offset, so simply extend the query_heap to cover the entire notifier, and use a offset in nv30_context_kick_notify. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- src/gallium/drivers/nouveau/nouveau_buffer.c | 14 +- src/gallium/drivers/nouveau/nouveau_context.h | 5 +

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

I'm not really sure what all information I should include with my question. But, I've installed both the original Diablo II and its expansion onto a virtual drive provided by Wine. When I choose to run Diablo II the emulated window is a blue color, and in the top left of the screen there is a small black box which cycles through letters and symbols. Finally after a few seconds the