Displaying 9 results from an estimated 9 matches for "nouveau_fence_state_emitting".
2015 Oct 10
2
[PATCH] nouveau: avoid emitting new fences unnecessarily
...index ee4e08d..18b1592 100644
--- a/src/gallium/drivers/nouveau/nouveau_fence.c
+++ b/src/gallium/drivers/nouveau/nouveau_fence.c
@@ -190,8 +190,10 @@ nouveau_fence_wait(struct nouveau_fence *fence)
/* wtf, someone is waiting on a fence in flush_notify handler? */
assert(fence->state != NOUVEAU_FENCE_STATE_EMITTING);
- if (fence->state < NOUVEAU_FENCE_STATE_EMITTED)
+ if (fence->state < NOUVEAU_FENCE_STATE_EMITTED) {
+ PUSH_SPACE(screen->pushbuf, 8);
nouveau_fence_emit(fence);
+ }
if (fence->state < NOUVEAU_FENCE_STATE_FLUSHED)
if (nouveau_pushbuf_kick(scr...
2013 Nov 30
1
[PATCH 1/2] nouveau: avoid leaking fences while waiting
...index dea146c..c686710 100644
--- a/src/gallium/drivers/nouveau/nouveau_fence.c
+++ b/src/gallium/drivers/nouveau/nouveau_fence.c
@@ -189,16 +189,15 @@ nouveau_fence_wait(struct nouveau_fence *fence)
/* wtf, someone is waiting on a fence in flush_notify handler? */
assert(fence->state != NOUVEAU_FENCE_STATE_EMITTING);
- if (fence->state < NOUVEAU_FENCE_STATE_EMITTED) {
+ if (fence->state < NOUVEAU_FENCE_STATE_EMITTED)
nouveau_fence_emit(fence);
- if (fence == screen->fence.current)
- nouveau_fence_new(screen, &screen->fence.current, FALSE);
- }
- if (fence-...
2014 Mar 06
2
[PATCH] nouveau: fix fence waiting logic in screen destroy
nouveau_fence_wait has the expectation that an external entity is
holding onto the fence being waited on, not that it is merely held onto
by the current pointer. Fixes a use-after-free in nouveau_fence_wait
when used on the screen's current fence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75279
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
Should the waiting be
2014 Jun 16
2
[PATCH 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
...else
- screen->fence.head = fence;
+ mgr->head = fence;
- screen->fence.tail = fence;
+ mgr->tail = fence;
- screen->fence.emit(&screen->base, &fence->sequence);
+ mgr->emit(mgr, &fence->sequence);
assert(fence->state == NOUVEAU_FENCE_STATE_EMITTING);
fence->state = NOUVEAU_FENCE_STATE_EMITTED;
@@ -109,19 +109,19 @@ void
nouveau_fence_del(struct nouveau_fence *fence)
{
struct nouveau_fence *it;
- struct nouveau_screen *screen = fence->screen;
+ struct nouveau_fence_mgr *mgr = fence->mgr;
if (fence->state =...
2014 Mar 07
0
[PATCH] nouveau: fix fence waiting logic in screen destroy
On 06/03/14 04:01, Ilia Mirkin wrote:
> nouveau_fence_wait has the expectation that an external entity is
> holding onto the fence being waited on, not that it is merely held onto
> by the current pointer. Fixes a use-after-free in nouveau_fence_wait
> when used on the screen's current fence.
>
IMHO one should flatten all the fence handling a bit to greatly improve
readability
2014 Jun 12
6
[Bug 79946] New: Segmentation violation at nouveau_fence.c
...mesa-20140509
Chipset C51 (NV4E)
Family NV40 Video card NVIDIA GeForce 6150 LE
Running ~/intel/ism/bin/intel64/intelremotedialog
from Intel VTune Amplifier XE 2013 command amplxe-gui on Linux Fedora 20.
Segmentation violation at nouveau_fence.c:226
"if (screen->fence.current->state < NOUVEAU_FENCE_STATE_EMITTING)"
pointer screen is nil because after nv30/nv30_context.c:44
"nv30 = container_of(push->user_priv, nv30, bufctx);"
assert(nv30->screen) fails.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment...
2014 Jul 10
3
[PATCH 0/3] nvc0: ARB_(multi_)draw_indirect support
The main patches are from Christoph. Unfortunately they're a little beyond my
understanding of all the vertex-related details, but they generally seemed
fine. I'm just going to push these unless someone steps up to review them.
Christoph Bumiller (2):
nvc0: add support for indirect drawing
nvc0: fix translate path for PRIM_RESTART_WITH_DRAW_ARRAYS
Ilia Mirkin (1):
nouveau: check if
2016 Jun 05
0
[RFC PATCH] nouveau: add locking
---
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
2014 Jun 17
2
[PATCH try 2 1/2] gallium/nouveau: decouple nouveau_fence implementation from screen
...nce;
else
- screen->fence.head = fence;
+ mgr->head = fence;
- screen->fence.tail = fence;
+ mgr->tail = fence;
- screen->fence.emit(&screen->base, &fence->sequence);
+ mgr->emit(mgr, &fence->sequence);
assert(fence->state == NOUVEAU_FENCE_STATE_EMITTING);
fence->state = NOUVEAU_FENCE_STATE_EMITTED;
@@ -109,19 +109,19 @@ void
nouveau_fence_del(struct nouveau_fence *fence)
{
struct nouveau_fence *it;
- struct nouveau_screen *screen = fence->screen;
+ struct nouveau_fence_mgr *mgr = fence->mgr;
if (fence->state == NOUV...