[Nouveau] [Bug 90887] PhiMovesPass in register allocator broken
https://bugs.freedesktop.org/show_bug.cgi?id=90887
--- Comment #14 from Ilia Mirkin imir...@alum.mit.edu ---
OK, so among other changes, commit e43a3a66 had the following diff:
@@ -312,23 +337,26 @@ RegAlloc::PhiMovesPass::visit(BasicBlock *bb)
Instruction *phi, *mov;
BasicBlock *pb, *pn;
+ std::stackBasicBlock * stack;
+
for (Graph::EdgeIterator ei = bb-cfg.incident(); !ei.end(); ei.next()) {
- pb = pn = BasicBlock::get(ei.getNode());
+ pb = BasicBlock::get(ei.getNode());
assert(pb);
-
- if (needNewElseBlock(bb, pb)) {
- pn = new BasicBlock(func);
-
- // deletes an edge, iterator is invalid after this:
- pb-cfg.detach(bb-cfg);
- pb-cfg.attach(pn-cfg, Graph::Edge::TREE);
- pn-cfg.attach(bb-cfg, Graph::Edge::FORWARD); // XXX: check order !
-
- assert(pb-getExit()-op != OP_CALL);
- if (pb-getExit()-asFlow()-target.bb == bb)
-pb-getExit()-asFlow()-target.bb = pn;
- break;
- }
+ if (needNewElseBlock(bb, pb))
+ stack.push(pb);
+ }
+ while (!stack.empty()) {
+ pb = stack.top();
+ pn = new BasicBlock(func);
+ stack.pop();
+
+ pb-cfg.detach(bb-cfg);
+ pb-cfg.attach(pn-cfg, Graph::Edge::TREE);
+ pn-cfg.attach(bb-cfg, Graph::Edge::FORWARD);
+
+ assert(pb-getExit()-op != OP_CALL);
+ if (pb-getExit()-asFlow()-target.bb == bb)
+ pb-getExit()-asFlow()-target.bb = pn;
}
// insert MOVs (phi-src(j) should stem from j-th in-BB)
which the patch in attachment 116339 effectively undoes. [Why was that in
there? No idea. But presumably futzing with bb's affects needNewElseBlock's
decisions.] So I'm still tending towards my solution. But I'm not particularly
happy that it has to build up and use that hash table every time even if
nothing's changed.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH 3/8] nv50: allocate and map a notifier buffer object for PM
On 06/26/2015 01:02 AM, Ilia Mirkin wrote:
On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset
samuel.pitoi...@gmail.com wrote:
This notifier buffer object will be used to read back global performance
counters results written by the kernel.
For each domain, we will store the handle of the perfdom object, an
array of 4 counters and the number of cycles. Like the Gallium's HUD,
we keep a list of busy queries in a ring in order to prevent stalls
when reading queries.
Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
src/gallium/drivers/nouveau/nv50/nv50_screen.c | 29 ++
src/gallium/drivers/nouveau/nv50/nv50_screen.h | 6 ++
2 files changed, 35 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index c985344..3a99cc8 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -368,6 +368,7 @@ nv50_screen_destroy(struct pipe_screen *pscreen)
nouveau_object_del(screen-m2mf);
nouveau_object_del(screen-sync);
nouveau_object_del(screen-sw);
+ nouveau_object_del(screen-query);
nouveau_screen_fini(screen-base);
@@ -699,9 +700,11 @@ nv50_screen_create(struct nouveau_device *dev)
struct nv50_screen *screen;
struct pipe_screen *pscreen;
struct nouveau_object *chan;
+ struct nv04_fifo *fifo;
uint64_t value;
uint32_t tesla_class;
unsigned stack_size;
+ uint32_t length;
int ret;
screen = CALLOC_STRUCT(nv50_screen);
@@ -727,6 +730,7 @@ nv50_screen_create(struct nouveau_device *dev)
screen-base.pushbuf-rsvd_kick = 5;
chan = screen-base.channel;
+ fifo = chan-data;
pscreen-destroy = nv50_screen_destroy;
pscreen-context_create = nv50_create;
@@ -772,6 +776,23 @@ nv50_screen_create(struct nouveau_device *dev)
goto fail;
}
+ /* Compute size (in bytes) of the notifier buffer object which is used
+* in order to read back global performance counters results written
+* by the kernel. For each domain, we store the handle of the perfdom
+* object, an array of 4 counters and the number of cycles. Like for
+* the Gallium's HUD, we keep a list of busy queries in a ring in order
+* to prevent stalls when reading queries. */
+ length = (1 + (NV50_HW_PM_RING_BUFFER_NUM_DOMAINS * 6) *
+ NV50_HW_PM_RING_BUFFER_MAX_QUERIES) * 4;
This calculation may become apparent to me later, but it certainly
isn't now. What's the *6? You refer to an array of 4 counters...
should that have been 6 counters? Or should this have been a 4?
This refers to the handle of the object, the array of 4 counters and the
number of cycles.
In other words, for each domain we store: id, ctr0, ctr1, ctr2, ctr3, clk.
+
+ ret = nouveau_object_new(chan, 0xbeef0302, NOUVEAU_NOTIFIER_CLASS,
+(struct nv04_notify){ .length = length },
+sizeof(struct nv04_notify), screen-query);
+ if (ret) {
+ NOUVEAU_ERR(Failed to allocate notifier object for PM: %d\n, ret);
+ goto fail;
+ }
+
ret = nouveau_object_new(chan, 0xbeef506e, 0x506e,
NULL, 0, screen-sw);
if (ret) {
@@ -845,6 +866,14 @@ nv50_screen_create(struct nouveau_device *dev)
nouveau_heap_init(screen-gp_code_heap, 0, 1 NV50_CODE_BO_SIZE_LOG2);
nouveau_heap_init(screen-fp_code_heap, 0, 1 NV50_CODE_BO_SIZE_LOG2);
+ ret = nouveau_bo_wrap(screen-base.device, fifo-notify,
screen-notify_bo);
+ if (ret == 0)
+ nouveau_bo_map(screen-notify_bo, 0, screen-base.client);
ret = ...
Good catch, thanks.
+ if (ret) {
+ NOUVEAU_ERR(Failed to map notifier object for PM: %d\n, ret);
+ goto fail;
+ }
+
nouveau_getparam(dev, NOUVEAU_GETPARAM_GRAPH_UNITS, value);
screen-TPs = util_bitcount(value 0x);
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.h
b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
index 69fdfdb..71a5247 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
@@ -59,6 +59,7 @@ struct nv50_screen {
struct nouveau_bo *txc; /* TIC (offset 0) and TSC (65536) */
struct nouveau_bo *stack_bo;
struct nouveau_bo *tls_bo;
+ struct nouveau_bo *notify_bo;
unsigned TPs;
unsigned MPsInTP;
@@ -89,6 +90,7 @@ struct nv50_screen {
} fence;
struct nouveau_object *sync;
+ struct nouveau_object *query;
struct nouveau_object *tesla;
struct nouveau_object *eng2d;
@@ -96,6 +98,10 @@ struct nv50_screen {
struct nouveau_object *sw;
};
+/* Parameters of the ring buffer used to read back global PM counters. */
+#define NV50_HW_PM_RING_BUFFER_NUM_DOMAINS 8
+#define NV50_HW_PM_RING_BUFFER_MAX_QUERIES 9 /* HUD_NUM_QUERIES + 1 */
+
static INLINE struct nv50_screen *
nv50_screen(struct pipe_screen *screen)
{
--
2.4.4
[Nouveau] [Bug 86356] [nv50] Graphical glitches in dota2
https://bugs.freedesktop.org/show_bug.cgi?id=86356 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Ilia Mirkin imir...@alum.mit.edu --- mogorva on IRC confirms that this bug is the same as the TXL-related one. Even though it's newer, it has all the relevant info, so marking as dup. *** This bug has been marked as a duplicate of bug 90887 *** -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90887] PhiMovesPass in register allocator broken
https://bugs.freedesktop.org/show_bug.cgi?id=90887 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added CC||emil.l.veli...@gmail.com --- Comment #15 from Ilia Mirkin imir...@alum.mit.edu --- *** Bug 86356 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH 6/8] nv50: add support for compute/graphics global performance counters
On 06/26/2015 01:09 AM, Ilia Mirkin wrote:
What's with the \%'s everywhere?
Maybe percent will be better ?
On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset
samuel.pitoi...@gmail.com wrote:
This commit adds support for both compute and graphics global
performance counters which have been reverse engineered with
CUPTI (Linux) and PerfKit (Windows).
Currently, only one query type can be monitored at the same time because
the Gallium's HUD doesn't fit pretty well. This will be improved later.
Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
src/gallium/drivers/nouveau/nv50/nv50_query.c | 1057 +++-
src/gallium/drivers/nouveau/nv50/nv50_screen.h | 35 +
2 files changed, 1087 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c
b/src/gallium/drivers/nouveau/nv50/nv50_query.c
index 1162110..b9d2914 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query.c
@@ -27,6 +27,8 @@
#include nv50/nv50_context.h
#include nv_object.xml.h
+#include nouveau_perfmon.h
+
#define NV50_QUERY_STATE_READY 0
#define NV50_QUERY_STATE_ACTIVE 1
#define NV50_QUERY_STATE_ENDED 2
@@ -51,10 +53,25 @@ struct nv50_query {
boolean is64bit;
struct nouveau_mm_allocation *mm;
struct nouveau_fence *fence;
+ struct nouveau_object *perfdom;
};
#define NV50_QUERY_ALLOC_SPACE 256
+#ifdef DEBUG
+static void nv50_hw_pm_dump_perfdom(struct nvif_perfdom_v0 *args);
+#endif
+
+static boolean
+nv50_hw_pm_query_create(struct nv50_context *, struct nv50_query *);
+static void
+nv50_hw_pm_query_destroy(struct nv50_context *, struct nv50_query *);
+static boolean
+nv50_hw_pm_query_begin(struct nv50_context *, struct nv50_query *);
+static void nv50_hw_pm_query_end(struct nv50_context *, struct nv50_query *);
+static boolean nv50_hw_pm_query_result(struct nv50_context *,
+struct nv50_query *, boolean, void *);
+
static INLINE struct nv50_query *
nv50_query(struct pipe_query *pipe)
{
@@ -96,12 +113,18 @@ nv50_query_allocate(struct nv50_context *nv50, struct
nv50_query *q, int size)
static void
nv50_query_destroy(struct pipe_context *pipe, struct pipe_query *pq)
{
+ struct nv50_context *nv50 = nv50_context(pipe);
+ struct nv50_query *q = nv50_query(pq);
+
if (!pq)
return;
- nv50_query_allocate(nv50_context(pipe), nv50_query(pq), 0);
- nouveau_fence_ref(NULL, nv50_query(pq)-fence);
- FREE(nv50_query(pq));
+ if ((q-type = NV50_HW_PM_QUERY(0) q-type = NV50_HW_PM_QUERY_LAST))
+ nv50_hw_pm_query_destroy(nv50, q);
+
+ nv50_query_allocate(nv50, q, 0);
+ nouveau_fence_ref(NULL, q-fence);
+ FREE(q);
}
static struct pipe_query *
@@ -130,6 +153,11 @@ nv50_query_create(struct pipe_context *pipe, unsigned
type, unsigned index)
q-data -= 32 / sizeof(*q-data); /* we advance before query_begin ! */
}
+ if ((q-type = NV50_HW_PM_QUERY(0) q-type = NV50_HW_PM_QUERY_LAST)) {
+ if (!nv50_hw_pm_query_create(nv50, q))
+ return NULL;
+ }
+
return (struct pipe_query *)q;
}
@@ -154,6 +182,7 @@ nv50_query_begin(struct pipe_context *pipe, struct
pipe_query *pq)
struct nv50_context *nv50 = nv50_context(pipe);
struct nouveau_pushbuf *push = nv50-base.pushbuf;
struct nv50_query *q = nv50_query(pq);
+ boolean ret = TRUE;
if (!pq)
return FALSE;
@@ -211,10 +240,13 @@ nv50_query_begin(struct pipe_context *pipe, struct
pipe_query *pq)
nv50_query_get(push, q, 0x10, 0x5002);
break;
default:
+ if ((q-type = NV50_HW_PM_QUERY(0) q-type =
NV50_HW_PM_QUERY_LAST)) {
+ ret = nv50_hw_pm_query_begin(nv50, q);
+ }
break;
}
q-state = NV50_QUERY_STATE_ACTIVE;
- return true;
+ return ret;
}
static void
@@ -274,7 +306,9 @@ nv50_query_end(struct pipe_context *pipe, struct pipe_query
*pq)
q-state = NV50_QUERY_STATE_READY;
break;
default:
- assert(0);
+ if ((q-type = NV50_HW_PM_QUERY(0) q-type =
NV50_HW_PM_QUERY_LAST)) {
+ nv50_hw_pm_query_end(nv50, q);
+ }
break;
}
@@ -309,6 +343,10 @@ nv50_query_result(struct pipe_context *pipe, struct
pipe_query *pq,
if (!pq)
return FALSE;
+ if ((q-type = NV50_HW_PM_QUERY(0) q-type = NV50_HW_PM_QUERY_LAST)) {
+ return nv50_hw_pm_query_result(nv50, q, wait, result);
+ }
+
if (q-state != NV50_QUERY_STATE_READY)
nv50_query_update(q);
@@ -488,6 +526,1015 @@ nva0_so_target_save_offset(struct pipe_context *pipe,
nv50_query_end(pipe, targ-pq);
}
+/* === HARDWARE GLOBAL PERFORMANCE COUNTERS for NV50 === */
+
+struct nv50_hw_pm_source_cfg
+{
+ const char *name;
+ uint64_t value;
+};
+
+struct nv50_hw_pm_signal_cfg
+{
+ const char *name;
+ const struct nv50_hw_pm_source_cfg src[8];
+};
+
+struct nv50_hw_pm_counter_cfg
+{
+ uint16_t logic_op;
+ const struct
[Nouveau] [Bug 90887] PhiMovesPass in register allocator broken
https://bugs.freedesktop.org/show_bug.cgi?id=90887 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added CC||lub...@gmail.com --- Comment #16 from Ilia Mirkin imir...@alum.mit.edu --- *** Bug 75776 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 75776] [NV50 gallium] Hearthstone displays corrupted buffers
https://bugs.freedesktop.org/show_bug.cgi?id=75776 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #17 from Ilia Mirkin imir...@alum.mit.edu --- As per the last comment, this is the same as a newer but much more detailed bug. Combining. *** This bug has been marked as a duplicate of bug 90887 *** -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90887] PhiMovesPass in register allocator broken
https://bugs.freedesktop.org/show_bug.cgi?id=90887 --- Comment #18 from Ilia Mirkin imir...@alum.mit.edu --- (In reply to Ilia Mirkin from comment #17) Created attachment 116761 [details] [review] another attempt OK, I like this a bit better since it doesn't use any weird maps, and incurs minimal costs in the common case. It unfortunately encodes the graph's insertion strategy, but... meh. Ugh, actually this patch won't work. It needs to be phi-setSrc(j, tmp); but then I lose the old phi source. So perhaps the map approach is ~required :( -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC PATCH 4/8] nv50: configure the ring buffer for reading back PM counters
On 06/26/2015 01:04 AM, Ilia Mirkin wrote: Yeah, this whole thing has to be guarded by a drm version check, otherwise it'll end up with errors in dmesg I assume. Perhaps only allocate screen-query when the drm version matches, and gate things on that for the rest of the code? Yes, this sounds good to me. On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset samuel.pitoi...@gmail.com wrote: To write data at the right offset, the kernel has to know some parameters of this ring buffer, like the number of domains and the maximum number of queries. Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com --- src/gallium/drivers/nouveau/nv50/nv50_screen.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c b/src/gallium/drivers/nouveau/nv50/nv50_screen.c index 3a99cc8..53817c0 100644 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c @@ -441,6 +441,13 @@ nv50_screen_init_hwctx(struct nv50_screen *screen) BEGIN_NV04(push, SUBC_SW(NV01_SUBCHAN_OBJECT), 1); PUSH_DATA (push, screen-sw-handle); + BEGIN_NV04(push, SUBC_SW(0x0190), 1); + PUSH_DATA (push, screen-query-handle); + // XXX: Maybe add a check for DRM version here ? + BEGIN_NV04(push, SUBC_SW(0x0600), 1); + PUSH_DATA (push, NV50_HW_PM_RING_BUFFER_MAX_QUERIES); + BEGIN_NV04(push, SUBC_SW(0x0604), 1); + PUSH_DATA (push, NV50_HW_PM_RING_BUFFER_NUM_DOMAINS); FYI you can do BEGIN_NV04(..., 2), since they're sequential. I'm going to make the change. BEGIN_NV04(push, NV50_3D(COND_MODE), 1); PUSH_DATA (push, NV50_3D_COND_MODE_ALWAYS); -- 2.4.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90887] PhiMovesPass in register allocator broken
https://bugs.freedesktop.org/show_bug.cgi?id=90887 --- Comment #17 from Ilia Mirkin imir...@alum.mit.edu --- Created attachment 116761 -- https://bugs.freedesktop.org/attachment.cgi?id=116761action=edit another attempt OK, I like this a bit better since it doesn't use any weird maps, and incurs minimal costs in the common case. It unfortunately encodes the graph's insertion strategy, but... meh. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89842] Nvidia nouveau drivers hangs all gnome when opening the new legacy tray (and many other situations) in 3.16.0
https://bugs.freedesktop.org/show_bug.cgi?id=89842 Victor Porton por...@narod.ru changed: What|Removed |Added CC||por...@narod.ru --- Comment #18 from Victor Porton por...@narod.ru --- Created attachment 116767 -- https://bugs.freedesktop.org/attachment.cgi?id=116767action=edit when manipulating Gnome tray See the error log produced by journalctl when manipulating Gnome tray. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89842] Nvidia nouveau drivers hangs all gnome when opening the new legacy tray (and many other situations) in 3.16.0
https://bugs.freedesktop.org/show_bug.cgi?id=89842 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Ilia Mirkin imir...@alum.mit.edu --- This is fixed by not using libdrm 2.4.60 which was a buggy release on the nouveau end. libdrm 2.4.59 or libdrm 2.4.61 should work fine. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72180] [NVE6] Random GPU Lockups, works with blob PGRAPH fw
https://bugs.freedesktop.org/show_bug.cgi?id=72180 --- Comment #42 from Ilia Mirkin imir...@alum.mit.edu --- Could people who still had issues with 3.17 retest with 4.0+? There was another fix in commit 404ba3f79089a01c1ebacccafa08a5db4a4cd2af which among other things fixed an issue on GK110. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #12 from poma pomidorabelis...@gmail.com --- (In reply to Marcus Moeller from comment #11) Yes that might be the case. Is there any way to check this? # journalctl -b | grep -i 'foo\|bar' -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90932] gm107 font glitches with kernel 4.1rc
https://bugs.freedesktop.org/show_bug.cgi?id=90932 --- Comment #13 from poma pomidorabelis...@gmail.com --- Created attachment 116778 -- https://bugs.freedesktop.org/attachment.cgi?id=116778action=edit modeset - glamor NV50 For comparison. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
