[Nouveau] [Bug 91037] desktop freezes shortly after boot with NV11 [GeForce2 MX/MX 400]

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91037

--- Comment #8 from anonymissi...@arcor.de ---
It's clear to me that this machine wouldn't run with kde or gnome.

As I need to keep this hardware/OS combination available in an unusable state
to be able to generate the data you need to fix this I'd like to do that
quickly so that I can plug out the card again in favor of a better working one,
assuming there won't be a quick fix or workaround.
If it helps, I have the impression the hang happens when maximizing some window
onto the whole desktop.
I have run applications under gdb on command line in the past, if that's what I
might have to do.

-- 
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 91056] The Bard's Tale (2005, native) has rendering issues

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91056

--- Comment #3 from Ilia Mirkin imir...@alum.mit.edu ---
(In reply to Béla Gyebrószki from comment #2)
 The game shows the rendering issues with NV50_PROG_OPTIMIZE=1 as well.
 
 I found that it's sufficient to change either
 RUN_PASS(1, CopyPropagation, run);
 
 or
 
 RUN_PASS(1, LoadPropagation, run);
 
 to '2' and the game renders properly with NV50_PROG_OPTIMIZE=1 (those black
 bars remained whatever I changed though).

Interesting that it's *either*. I guess some instruction claims that it can
accept things (in the code) that it, in actuality, can't. I assume you don't
see any INVALID_OPCODE messages in dmesg?

The simplest next step is to find a draw call (using qapitrace) that renders
properly without the optimizations but improperly with. Once you've identified
the call number, the simplest thing would be to then run 'glretrace -D $call'
through valgrind-mmt both ways, which, via 'demmt', should allow you to easily
see what shaders were used in that last call.

-- 
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 91056] The Bard's Tale (2005, native) has rendering issues

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91056

--- Comment #2 from Béla Gyebrószki gyebr...@gmail.com ---
The game shows the rendering issues with NV50_PROG_OPTIMIZE=1 as well.

I found that it's sufficient to change either
RUN_PASS(1, CopyPropagation, run);

or

RUN_PASS(1, LoadPropagation, run);

to '2' and the game renders properly with NV50_PROG_OPTIMIZE=1 (those black
bars remained whatever I changed though).

-- 
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 5/8] nv50: prevent NULL pointer dereference with pipe_query functions

2015-06-22 Thread Ilia Mirkin
If query_create fails, why would any of these functions get called?

On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset
samuel.pitoi...@gmail.com wrote:
 This may happen when nv50_query_create() fails to create a new query.

 Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
 ---
  src/gallium/drivers/nouveau/nv50/nv50_query.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_query.c
 index 55fcac8..1162110 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_query.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_query.c
 @@ -96,6 +96,9 @@ 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)
  {
 +   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));
 @@ -152,6 +155,9 @@ nv50_query_begin(struct pipe_context *pipe, struct 
 pipe_query *pq)
 struct nouveau_pushbuf *push = nv50-base.pushbuf;
 struct nv50_query *q = nv50_query(pq);

 +   if (!pq)
 +  return FALSE;
 +
 /* For occlusion queries we have to change the storage, because a previous
  * query might set the initial render conition to FALSE even *after* we 
 re-
  * initialized it to TRUE.
 @@ -218,6 +224,9 @@ nv50_query_end(struct pipe_context *pipe, struct 
 pipe_query *pq)
 struct nouveau_pushbuf *push = nv50-base.pushbuf;
 struct nv50_query *q = nv50_query(pq);

 +   if (!pq)
 +  return;
 +
 q-state = NV50_QUERY_STATE_ENDED;

 switch (q-type) {
 @@ -294,9 +303,12 @@ nv50_query_result(struct pipe_context *pipe, struct 
 pipe_query *pq,
 uint64_t *res64 = (uint64_t *)result;
 uint32_t *res32 = (uint32_t *)result;
 boolean *res8 = (boolean *)result;
 -   uint64_t *data64 = (uint64_t *)q-data;
 +   uint64_t *data64;
 int i;

 +   if (!pq)
 +  return FALSE;
 +
 if (q-state != NV50_QUERY_STATE_READY)
nv50_query_update(q);

 @@ -314,6 +326,7 @@ nv50_query_result(struct pipe_context *pipe, struct 
 pipe_query *pq,
 }
 q-state = NV50_QUERY_STATE_READY;

 +   data64 = (uint64_t *)q-data;
 switch (q-type) {
 case PIPE_QUERY_GPU_FINISHED:
res8[0] = TRUE;
 --
 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] [RFC PATCH 6/8] nv50: add support for compute/graphics global performance counters

2015-06-22 Thread Samuel Pitoiset
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 nv50_hw_pm_signal_cfg sig[4];
+};
+
+enum nv50_hw_pm_query_display
+{
+   NV50_HW_PM_EVENT_DISPLAY_RAW,
+   NV50_HW_PM_EVENT_DISPLAY_RATIO,
+};
+
+enum nv50_hw_pm_query_count
+{
+   NV50_HW_PM_EVENT_COUNT_SIMPLE,
+   NV50_HW_PM_EVENT_COUNT_B4,

[Nouveau] [RFC PATCH 3/8] nv50: allocate and map a notifier buffer object for PM

2015-06-22 Thread Samuel Pitoiset
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;
+
+   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);
+   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 mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [RFC PATCH 7/8] nv50: expose global performance counters to the HUD

2015-06-22 Thread Samuel Pitoiset
Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
 src/gallium/drivers/nouveau/nv50/nv50_query.c  | 41 ++
 src/gallium/drivers/nouveau/nv50/nv50_screen.c |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.h |  3 ++
 3 files changed, 45 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c 
b/src/gallium/drivers/nouveau/nv50/nv50_query.c
index b9d2914..062d427 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query.c
@@ -1535,6 +1535,47 @@ nv50_hw_pm_query_result(struct nv50_context *nv50, 
struct nv50_query *q,
return TRUE;
 }
 
+int
+nv50_screen_get_driver_query_info(struct pipe_screen *pscreen,
+  unsigned id,
+  struct pipe_driver_query_info *info)
+{
+   struct nv50_screen *screen = nv50_screen(pscreen);
+   int count = 0;
+
+   // TODO: Check DRM version when nvif will be merged in libdrm!
+   if (screen-base.perfmon) {
+  nv50_identify_events(screen);
+  count += NV50_HW_PM_QUERY_COUNT;
+   }
+
+   if (!info)
+  return count;
+
+   /* Init default values. */
+   info-name = this_is_not_the_query_you_are_looking_for;
+   info-query_type = 0xdeadd01d;
+   info-type = PIPE_DRIVER_QUERY_TYPE_UINT64;
+   info-max_value.u64 = 0;
+   info-group_id = -1;
+
+   if (id  count) {
+  if (screen-base.perfmon) {
+ const struct nv50_hw_pm_query_cfg *cfg =
+nv50_hw_pm_query_get_cfg(screen, NV50_HW_PM_QUERY(id));
+
+ info-name = cfg-event-name;
+ info-query_type = NV50_HW_PM_QUERY(id);
+ info-max_value.u64 =
+(cfg-event-display == NV50_HW_PM_EVENT_DISPLAY_RATIO) ? 100 : 0;
+ return 1;
+  }
+   }
+
+   /* User asked for info about non-existing query. */
+   return 0;
+}
+
 void
 nv50_init_query_functions(struct nv50_context *nv50)
 {
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 53817c0..f07798e 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -745,6 +745,7 @@ nv50_screen_create(struct nouveau_device *dev)
pscreen-get_param = nv50_screen_get_param;
pscreen-get_shader_param = nv50_screen_get_shader_param;
pscreen-get_paramf = nv50_screen_get_paramf;
+   pscreen-get_driver_query_info = nv50_screen_get_driver_query_info;
 
nv50_screen_init_resource_functions(pscreen);
 
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.h 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
index 0449659..69127c0 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
@@ -143,6 +143,9 @@ nv50_screen(struct pipe_screen *screen)
 #define NV50_HW_PM_QUERY_TEX_CACHE_HIT  22
 #define NV50_HW_PM_QUERY_TEX_WAITS_FOR_FB   23
 
+int nv50_screen_get_driver_query_info(struct pipe_screen *, unsigned,
+  struct pipe_driver_query_info *);
+
 boolean nv50_blitter_create(struct nv50_screen *);
 void nv50_blitter_destroy(struct nv50_screen *);
 
-- 
2.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [RFC PATCH 0/8] nv50: expose global performance counters

2015-06-22 Thread Samuel Pitoiset
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, these global performance counters
are tied to the command stream of the GPU using a set of software methods
instead of ioctls. Results are then written by the kernel to a mapped notifier
buffer object that allows the userspace to read back them.

However, the libdrm branch which implements the new nvif interface exposed by
Nouveau and the software methods interface are not upstream yet. I hope this
should done in the next days.

The code of this series can be found here:
http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nouveau_perfmon

The libdrm branch can be found here:
http://cgit.freedesktop.org/~hakzsam/drm/log/?h=nouveau_perfmon

The code of the software methods interface can be found here (two last commits):
http://cgit.freedesktop.org/~hakzsam/nouveau/log/?h=nouveau_perfmon

An other series which exposes global performance counters for Fermi and Kepler
will be submitted once I have got enough reviews for this one.

Feel free to make a review.

Thanks,
Samuel.

Samuel Pitoiset (8):
  nouveau: implement the nvif hardware performance counters interface
  nv50: allocate a software object class
  nv50: allocate and map a notifier buffer object for PM
  nv50: configure the ring buffer for reading back PM counters
  nv50: prevent NULL pointer dereference with pipe_query functions
  nv50: add support for compute/graphics global performance counters
  nv50: expose global performance counters to the HUD
  nv50: enable GL_AMD_performance_monitor

 src/gallium/drivers/nouveau/Makefile.sources   |2 +
 src/gallium/drivers/nouveau/nouveau_perfmon.c  |  302 +++
 src/gallium/drivers/nouveau/nouveau_perfmon.h  |   59 ++
 src/gallium/drivers/nouveau/nouveau_screen.c   |5 +
 src/gallium/drivers/nouveau/nouveau_screen.h   |1 +
 src/gallium/drivers/nouveau/nv50/nv50_query.c  | 1148 +++-
 src/gallium/drivers/nouveau/nv50/nv50_screen.c |   49 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.h |   51 ++
 src/gallium/drivers/nouveau/nv50/nv50_winsys.h |1 +
 9 files changed, 1612 insertions(+), 6 deletions(-)
 create mode 100644 src/gallium/drivers/nouveau/nouveau_perfmon.c
 create mode 100644 src/gallium/drivers/nouveau/nouveau_perfmon.h

-- 
2.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [RFC PATCH 8/8] nv50: enable GL_AMD_performance_monitor

2015-06-22 Thread Samuel Pitoiset
This exposes a group of global performance counters that enables
GL_AMD_performance_monitor. All piglit tests are okay.

Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
 src/gallium/drivers/nouveau/nv50/nv50_query.c  | 35 ++
 src/gallium/drivers/nouveau/nv50/nv50_screen.c |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_screen.h |  6 +
 3 files changed, 42 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c 
b/src/gallium/drivers/nouveau/nv50/nv50_query.c
index 062d427..6638e82 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query.c
@@ -1566,6 +1566,7 @@ nv50_screen_get_driver_query_info(struct pipe_screen 
*pscreen,
 
  info-name = cfg-event-name;
  info-query_type = NV50_HW_PM_QUERY(id);
+ info-group_id = NV50_HW_PM_QUERY_GROUP;
  info-max_value.u64 =
 (cfg-event-display == NV50_HW_PM_EVENT_DISPLAY_RATIO) ? 100 : 0;
  return 1;
@@ -1576,6 +1577,40 @@ nv50_screen_get_driver_query_info(struct pipe_screen 
*pscreen,
return 0;
 }
 
+int
+nv50_screen_get_driver_query_group_info(struct pipe_screen *pscreen,
+unsigned id,
+struct pipe_driver_query_group_info 
*info)
+{
+   struct nv50_screen *screen = nv50_screen(pscreen);
+   int count = 0;
+
+   // TODO: Check DRM version when nvif will be merged in libdrm!
+   if (screen-base.perfmon) {
+  count++; /* NV50_HW_PM_QUERY_GROUP */
+   }
+
+   if (!info)
+  return count;
+
+   if (id == NV50_HW_PM_QUERY_GROUP) {
+  if (screen-base.perfmon) {
+ info-name = Global performance counters;
+ info-type = PIPE_DRIVER_QUERY_GROUP_TYPE_GPU;
+ info-num_queries = NV50_HW_PM_QUERY_COUNT;
+ info-max_active_queries = 1; /* TODO: get rid of this limitation! */
+ return 1;
+  }
+   }
+
+   /* user asked for info about non-existing query group */
+   info-name = this_is_not_the_query_group_you_are_looking_for;
+   info-max_active_queries = 0;
+   info-num_queries = 0;
+   info-type = 0;
+   return 0;
+}
+
 void
 nv50_init_query_functions(struct nv50_context *nv50)
 {
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index f07798e..dfe20c9 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -746,6 +746,7 @@ nv50_screen_create(struct nouveau_device *dev)
pscreen-get_shader_param = nv50_screen_get_shader_param;
pscreen-get_paramf = nv50_screen_get_paramf;
pscreen-get_driver_query_info = nv50_screen_get_driver_query_info;
+   pscreen-get_driver_query_group_info = 
nv50_screen_get_driver_query_group_info;
 
nv50_screen_init_resource_functions(pscreen);
 
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.h 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
index 69127c0..807ae0e 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
@@ -114,6 +114,9 @@ nv50_screen(struct pipe_screen *screen)
return (struct nv50_screen *)screen;
 }
 
+/* Hardware global performance counters groups. */
+#define NV50_HW_PM_QUERY_GROUP 0
+
 /* Hardware global performance counters. */
 #define NV50_HW_PM_QUERY_COUNT  24
 #define NV50_HW_PM_QUERY(i)(PIPE_QUERY_DRIVER_SPECIFIC + (i))
@@ -146,6 +149,9 @@ nv50_screen(struct pipe_screen *screen)
 int nv50_screen_get_driver_query_info(struct pipe_screen *, unsigned,
   struct pipe_driver_query_info *);
 
+int nv50_screen_get_driver_query_group_info(struct pipe_screen *, unsigned,
+struct 
pipe_driver_query_group_info *);
+
 boolean nv50_blitter_create(struct nv50_screen *);
 void nv50_blitter_destroy(struct nv50_screen *);
 
-- 
2.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [RFC PATCH 5/8] nv50: prevent NULL pointer dereference with pipe_query functions

2015-06-22 Thread Samuel Pitoiset
This may happen when nv50_query_create() fails to create a new query.

Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
 src/gallium/drivers/nouveau/nv50/nv50_query.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c 
b/src/gallium/drivers/nouveau/nv50/nv50_query.c
index 55fcac8..1162110 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query.c
@@ -96,6 +96,9 @@ 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)
 {
+   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));
@@ -152,6 +155,9 @@ nv50_query_begin(struct pipe_context *pipe, struct 
pipe_query *pq)
struct nouveau_pushbuf *push = nv50-base.pushbuf;
struct nv50_query *q = nv50_query(pq);
 
+   if (!pq)
+  return FALSE;
+
/* For occlusion queries we have to change the storage, because a previous
 * query might set the initial render conition to FALSE even *after* we re-
 * initialized it to TRUE.
@@ -218,6 +224,9 @@ nv50_query_end(struct pipe_context *pipe, struct pipe_query 
*pq)
struct nouveau_pushbuf *push = nv50-base.pushbuf;
struct nv50_query *q = nv50_query(pq);
 
+   if (!pq)
+  return;
+
q-state = NV50_QUERY_STATE_ENDED;
 
switch (q-type) {
@@ -294,9 +303,12 @@ nv50_query_result(struct pipe_context *pipe, struct 
pipe_query *pq,
uint64_t *res64 = (uint64_t *)result;
uint32_t *res32 = (uint32_t *)result;
boolean *res8 = (boolean *)result;
-   uint64_t *data64 = (uint64_t *)q-data;
+   uint64_t *data64;
int i;
 
+   if (!pq)
+  return FALSE;
+
if (q-state != NV50_QUERY_STATE_READY)
   nv50_query_update(q);
 
@@ -314,6 +326,7 @@ nv50_query_result(struct pipe_context *pipe, struct 
pipe_query *pq,
}
q-state = NV50_QUERY_STATE_READY;
 
+   data64 = (uint64_t *)q-data;
switch (q-type) {
case PIPE_QUERY_GPU_FINISHED:
   res8[0] = TRUE;
-- 
2.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [RFC PATCH 4/8] nv50: configure the ring buffer for reading back PM counters

2015-06-22 Thread Samuel Pitoiset
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);
 
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] [RFC PATCH 2/8] nv50: allocate a software object class

2015-06-22 Thread Samuel Pitoiset
This will allow to monitor global performance counters through the
command stream of the GPU instead of using ioctls.

Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
 src/gallium/drivers/nouveau/nv50/nv50_screen.c | 11 +++
 src/gallium/drivers/nouveau/nv50/nv50_screen.h |  1 +
 src/gallium/drivers/nouveau/nv50/nv50_winsys.h |  1 +
 3 files changed, 13 insertions(+)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 6583a35..c985344 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -367,6 +367,7 @@ nv50_screen_destroy(struct pipe_screen *pscreen)
nouveau_object_del(screen-eng2d);
nouveau_object_del(screen-m2mf);
nouveau_object_del(screen-sync);
+   nouveau_object_del(screen-sw);
 
nouveau_screen_fini(screen-base);
 
@@ -437,6 +438,9 @@ nv50_screen_init_hwctx(struct nv50_screen *screen)
BEGIN_NV04(push, SUBC_3D(NV01_SUBCHAN_OBJECT), 1);
PUSH_DATA (push, screen-tesla-handle);
 
+   BEGIN_NV04(push, SUBC_SW(NV01_SUBCHAN_OBJECT), 1);
+   PUSH_DATA (push, screen-sw-handle);
+
BEGIN_NV04(push, NV50_3D(COND_MODE), 1);
PUSH_DATA (push, NV50_3D_COND_MODE_ALWAYS);
 
@@ -768,6 +772,13 @@ nv50_screen_create(struct nouveau_device *dev)
   goto fail;
}
 
+   ret = nouveau_object_new(chan, 0xbeef506e, 0x506e,
+NULL, 0, screen-sw);
+   if (ret) {
+  NOUVEAU_ERR(Failed to allocate SW object: %d\n, ret);
+  goto fail;
+   }
+
ret = nouveau_object_new(chan, 0xbeef5039, NV50_M2MF_CLASS,
 NULL, 0, screen-m2mf);
if (ret) {
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.h 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
index 881051b..69fdfdb 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.h
@@ -93,6 +93,7 @@ struct nv50_screen {
struct nouveau_object *tesla;
struct nouveau_object *eng2d;
struct nouveau_object *m2mf;
+   struct nouveau_object *sw;
 };
 
 static INLINE struct nv50_screen *
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_winsys.h 
b/src/gallium/drivers/nouveau/nv50/nv50_winsys.h
index e8578c8..5cb33ef 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_winsys.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_winsys.h
@@ -60,6 +60,7 @@ PUSH_REFN(struct nouveau_pushbuf *push, struct nouveau_bo 
*bo, uint32_t flags)
 #define SUBC_COMPUTE(m) 6, (m)
 #define NV50_COMPUTE(n) SUBC_COMPUTE(NV50_COMPUTE_##n)
 
+#define SUBC_SW(m) 7, (m)
 
 static INLINE uint32_t
 NV50_FIFO_PKHDR(int subc, int mthd, unsigned size)
-- 
2.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [RFC PATCH 5/8] nv50: prevent NULL pointer dereference with pipe_query functions

2015-06-22 Thread Samuel Pitoiset



On 06/22/2015 10:52 PM, Ilia Mirkin wrote:

If query_create fails, why would any of these functions get called?


Because the HUD doesn't check if query_create() fails and it calls other 
pipe_query functions with NULL pointer instead of a valid query object.




On Mon, Jun 22, 2015 at 4:53 PM, Samuel Pitoiset
samuel.pitoi...@gmail.com wrote:

This may happen when nv50_query_create() fails to create a new query.

Signed-off-by: Samuel Pitoiset samuel.pitoi...@gmail.com
---
  src/gallium/drivers/nouveau/nv50/nv50_query.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/nouveau/nv50/nv50_query.c 
b/src/gallium/drivers/nouveau/nv50/nv50_query.c
index 55fcac8..1162110 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_query.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_query.c
@@ -96,6 +96,9 @@ 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)
  {
+   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));
@@ -152,6 +155,9 @@ nv50_query_begin(struct pipe_context *pipe, struct 
pipe_query *pq)
 struct nouveau_pushbuf *push = nv50-base.pushbuf;
 struct nv50_query *q = nv50_query(pq);

+   if (!pq)
+  return FALSE;
+
 /* For occlusion queries we have to change the storage, because a previous
  * query might set the initial render conition to FALSE even *after* we re-
  * initialized it to TRUE.
@@ -218,6 +224,9 @@ nv50_query_end(struct pipe_context *pipe, struct pipe_query 
*pq)
 struct nouveau_pushbuf *push = nv50-base.pushbuf;
 struct nv50_query *q = nv50_query(pq);

+   if (!pq)
+  return;
+
 q-state = NV50_QUERY_STATE_ENDED;

 switch (q-type) {
@@ -294,9 +303,12 @@ nv50_query_result(struct pipe_context *pipe, struct 
pipe_query *pq,
 uint64_t *res64 = (uint64_t *)result;
 uint32_t *res32 = (uint32_t *)result;
 boolean *res8 = (boolean *)result;
-   uint64_t *data64 = (uint64_t *)q-data;
+   uint64_t *data64;
 int i;

+   if (!pq)
+  return FALSE;
+
 if (q-state != NV50_QUERY_STATE_READY)
nv50_query_update(q);

@@ -314,6 +326,7 @@ nv50_query_result(struct pipe_context *pipe, struct 
pipe_query *pq,
 }
 q-state = NV50_QUERY_STATE_READY;

+   data64 = (uint64_t *)q-data;
 switch (q-type) {
 case PIPE_QUERY_GPU_FINISHED:
res8[0] = TRUE;
--
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


Re: [Nouveau] Fermi+ shader header docs

2015-06-22 Thread Ilia Mirkin
And an additional question: I have a trace here where a reserved bit
from CommonWord0 is set. Is that just random values that aren't
cleared by the driver, or does it have some significance? Here is the
full shader:

HEADER:
0x06040461   0 = { SPH = VTG | VERSION = 3 | KIND = VP_B |
SASS_VERSION = 2 | LDST_ENABLE | SO_MASK = 0 | 0x200 }
0x   1 = { LMEM_POS_ALLOC = 0 | PATCH_ATTRIBUTES = 0 }
0x   2 = { LMEM_NEG_ALLOC = 0 | THREADS_PER_PRIM = 0 }
0x   3 = { WARP_CSTACK_SIZE = 0 | OUTPUT_PRIM = 0 }
0x   4 = { MAX_OUTPUT_VERTS = 0 | MIN_OUT_READ_SLOT = 0 |
MAX_OUT_READ_SLOT = 0 }
0x   ATTR_EN_0 = 0
0x   ATTR_EN_1 = 0
0x   ATTR_EN_2 = 0
0x   ATTR_EN_3 = 0
0x   ATTR_EN_4 = 0
0x   ATTR_EN_5 = { 0 }
0x   11 = 0
0x   12 = 0
0x0001f000   EXPORT_EN_0 = { HPOS = 0xf | 0x1 }
0x   EXPORT_EN_1 = 0
0x   EXPORT_EN_2 = 0
0x   EXPORT_EN_3 = 0
0x   EXPORT_EN_4 = 0
0x   EXPORT_EN_5 = { CLIP_DISTANCE = 0 | UNK12 = 0 }
0x   19 = 0
CODE:
: a01088b0 08bcb810 sched 0x2c 0x22 0x4 0x28 0x4 0x2e 0x2f
0008: 0b1ffc1e 5b601c07 set $p0 0x1 ge u32 0x0 c0[0x3858]
0010: 103c 1200 $p0 bra 0x38
0018: 0a1c0002 64c03c07 mov b32 $r0 c0[0x3850]
0020: 0a9c0006 64c03c07 mov b32 $r1 c0[0x3854]
0028: 001c cc80 ld b32 $r0 cg g[$r0d]
0030: 041c003c 1200 bra 0x40

0038: 7f9c0002 e4c03c00  C  mov b32 $r0 0x0

0040: 9c108010 090c8c10  C  sched 0x4 0x20 0x4 0x27 0x4 0x23 0x43
0048: 001c2802 e5c0 cvt rn f32 $r0 u32 $r0
0050: 341c0006 64c03c00 mov b32 $r1 c0[0x1a0]
0058: 349c000a 64c03c00 mov b32 $r2 c0[0x1a4]
0060: 351c000e 64c03c00 mov b32 $r3 c0[0x1a8]
0068: 359c0012 64c03c00 mov b32 $r4 c0[0x1ac]
0070: 381ffc06 7f03fc00 st b32 a[0x70] $r1 0x0 0x0
0078: 3a1ffc0a 7f03fc00 st b32 a[0x74] $r2 0x0 0x0
0080: 3c110d0c 0801 sched 0x43 0x43 0x4 0x4f 0x0 0x0 0x0
0088: 3c1ffc0e 7f03fc00 st b32 a[0x78] $r3 0x0 0x0
0090: 3e1ffc12 7f03fc00 st b32 a[0x7c] $r4 0x0 0x0
0098: 401ffc02 7f03fc00 st b32 a[0x80] $r0 0x0 0x0
00a0: 001c003c 1800 exit

00a8: fc1c003c 12007fff  C  bra 0xa8
00b0: 001c3c02 8580 nop
00b8: 001c3c02 8580 nop

On Sat, May 23, 2015 at 5:35 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
 On Thu, May 21, 2015 at 11:32 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
 On Thu, May 21, 2015 at 10:05 AM, Robert Morell rmor...@nvidia.com wrote:
 Hi Ilia,

 On Sat, May 02, 2015 at 12:34:21PM -0400, Ilia Mirkin wrote:
 Hi,

 As I'm looking to add some support to nouveau for features like atomic
 counters and images, I'm running into some confusion about what the
 first word of the shader header means. Here is the definition as we
 have it today:

 [...]

 However I know that these are somewhat wrong. I've seen shaders that
 use gmem accesses (i.e. mov r0, [r0]) that just have the LMEM enable
 bit set (and they use no lmem). And I've seen additional bits set, esp
 relating to images, but I haven't spent enough time looking at all the
 variations to make sense of it yet. For example, I think that Fermi
 and Kepler+ have different meanings for some of the bits.

 Those look pretty close :)

 I was hoping you could just release the docs for the shader headers,
 or at least the first word of the shader header.

 We've posted the specification for the full Shader Program Header to our
 GPU documentation site here:

 ftp://download.nvidia.com/open-gpu-doc/Shader-Program-Header/1/Shader-Program-Header.html

 I hope it helps clear things up.

 Yep, just a few follow-up questions:

 - SPH Type 1 and type 2 appear to be flipped wrt the tables -- When
 PS is used, field SphType in CommonWord0 must be set to 1; similarly,
 when VTG is used, SphType in CommonWord0 must be set to 2. But the
 Table 1. SPH Type 1 Definition is clearly meant for VTG and table 2
 is clearly meant for PS...
 - You skip over SassVersion -- what is that?
 - You have a funny note in there -- Triangles generated by the
 geometry shader always have all their edge flags set to TRUE -- that
 is the *only* reference to edge flags in the whole document. Right now
 we do some crazy thing to get edge flags right on fermi+ (and I think
 we just get them wrong on tesla). Is there a way to emit edge flags
 from vertex shader?
 - To be clear: DoesLoadOrStore -- *any* load/store? Even LDC? ALD?

 Oh, and one more little correction:

 
 The SPH field OutputTopology sets the primitive topology of the
 vertices that are output from the pipe stage. This field is only used
 with geometry shaders, where the value must be greater than zero and
 has a maximum of 1024. The allowed values are: ... [the correct values
 for OutputTopology]
 

 The 1024 thing seems like it probably applies to MaxOutputVertexCount
 in CommonWord4.

   -ilia

[Nouveau] [Bug 91056] New: The Bard's Tale (2005, native) has rendering issues

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91056

Bug ID: 91056
   Summary: The Bard's Tale (2005, native)  has rendering issues
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: gyebr...@gmail.com
QA Contact: nouveau@lists.freedesktop.org

The native Linux version of the game has serious rendering issues while in the
menus or during conversations in the game.
When the menu appears the book containing the menu options is invisible (or
transparent) and there are strange polygons flashing across the screen; this
makes navigation in the menus difficult.
Pre-rendered videos like the intro video are rendered properly, but the screen
is filled with flashing, brownish polygons whenever the player starts a
conversation with one of the NPCs.

Note: additionally, a thick black polygon is always present, originating from
the player's head, this however is present with the binary driver too, and
could be a different issue.

The graphical issues in the menus and during the conversation screens are not
present when
- using the binary drivers 340.76
- using the software renderer (LIBGL_ALWAYS_SOFTWARE=1)
- when starting the game with NV50_PROG_OPTIMIZE=0

I have Mesa3D built from git with debugging enabled, but nothing is shown in
the terminal or in dmesg.

Example video showing the issue:
https://drive.google.com/open?id=0B-tTbLKBl-tOVG9jUE5fOS1udXM
Trace file generated by Apitrace (uncompressed size 232 MB):
https://drive.google.com/open?id=0B-tTbLKBl-tOWmZSVkVOeEtQNlE

Replaying the trace file with nouveau the problem is present, the binary driver
plays the trace properly (except the black polygon issue which is present with
the 340.76 driver too)
Please let me know if you need additional info or logs.

OS: Fedora 22 i686
Kernel: 4.0.5-300.fc22.i686+PAE
Mesa: compiled from git (10.6-branchpoint-541-g104bff0)
VGA compatible controller: NVIDIA Corporation G92 [GeForce GTS 250] (rev a2)
(prog-if 00 [VGA controller])
xorg-x11-server-Xorg-1.17.1-14.fc22.i686

-- 
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 90932] gm107 font glitches with kernel 4.1rc

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=90932

Marcus Moeller marcus.moel...@gmx.ch changed:

   What|Removed |Added

Summary|gm105 font glitches with|gm107 font glitches with
   |kernel 4.1rc|kernel 4.1rc

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

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=90932

Marcus Moeller marcus.moel...@gmx.ch changed:

   What|Removed |Added

 Attachment #116429|font glitches with gm105|font glitches with gm107
description||

-- 
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 91051] New: GT650M and Nouveau - NOUVEAU(0): [drm] failed to set drm interface version.

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91051

Bug ID: 91051
   Summary: GT650M and Nouveau - NOUVEAU(0): [drm] failed to set
drm interface version.
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: stu.a...@gmail.com
QA Contact: nouveau@lists.freedesktop.org

Not sure if this is the right place...

OS:  
Ubuntu 15.04,  Using oibaf PPA.  Laptop: Asus N56VZ


I have GT650M with Intel.The nouveau driver doesn't seem to load with this
error in /var/log/Xorg.8.log:

NOUVEAU(0): [drm] failed to set drm interface version.

Googling, I've found people with the same issue, but no solution that is not
use the proprietary drivers which is I prefer not to do as they are quite
fragile during upgrades.

With earlier kernels (about 3 releases of Ubuntu back?) - Nouveau worked fine
with bumblebee, it hasn't for quite a long time, I've got a suspicion that
Nouveau and Bumblebee hasn't been working for anybody else during that time too
(since searching for a fix on and off the last few years).


/var/log/Xorg.8.log
[  8990.687] 
X.Org X Server 1.17.1
Release Date: 2015-02-10
[  8990.687] X Protocol Version 11, Revision 0
[  8990.687] Build Operating System: Linux 3.2.0-61-generic x86_64 Ubuntu
[  8990.687] Current Operating System: Linux beezlebub 3.19.0-20-generic
#20-Ubuntu SMP Fri May 29 10:10:47 UTC 2015 x86_64
[  8990.687] Kernel command line:
BOOT_IMAGE=/vmlinuz-3.19.0-20-generic.efi.signed
root=UUID=14ac372e-6980-4fe8-b247-fae92d54b0c5 ro quiet splash
acpi_enforce_resources=lax intel_pstate=enable rcutree.rcu_idle_gp_delay=1
vt.handoff=7
[  8990.687] Build Date: 19 March 2015  09:26:59AM
[  8990.687] xorg-server 2:1.17.1-0ubuntu3 (For technical support please see
http://www.ubuntu.com/support) 
[  8990.687] Current version of pixman: 0.32.6
[  8990.687] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  8990.687] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  8990.687] (==) Log file: /var/log/Xorg.8.log, Time: Mon Jun 22 16:05:14
2015
[  8990.687] (++) Using config file: /etc/bumblebee/xorg.conf.nouveau
[  8990.687] (++) Using config directory: /etc/bumblebee/xorg.conf.d
[  8990.687] (==) Using system config directory /usr/share/X11/xorg.conf.d
[  8990.687] (==) ServerLayout Layout0
[  8990.687] (==) No screen section available. Using defaults.
[  8990.687] (**) |--Screen Default Screen Section (0)
[  8990.687] (**) |   |--Monitor default monitor
[  8990.688] (==) No device specified for screen Default Screen Section.
Using the first device section listed.
[  8990.688] (**) |   |--Device DiscreteNvidia
[  8990.688] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[  8990.688] (**) Option AutoAddDevices false
[  8990.688] (**) Option AutoAddGPU false
[  8990.688] (**) Not automatically adding devices
[  8990.688] (==) Automatically enabling devices
[  8990.688] (**) Not automatically adding GPU devices
[  8990.688] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[  8990.688] Entry deleted from font path.
[  8990.688] (WW) The directory /usr/share/fonts/X11/75dpi/ does not exist.
[  8990.688] Entry deleted from font path.
[  8990.688] (WW) The directory /usr/share/fonts/X11/75dpi does not exist.
[  8990.688] Entry deleted from font path.
[  8990.688] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
built-ins
[  8990.688] (==) ModulePath set to
/usr/lib/x86_64-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules
[  8990.688] (==) |--Input Device default pointer
[  8990.688] (==) |--Input Device default keyboard
[  8990.688] (==) The core pointer device wasn't specified explicitly in the
layout.
Using the default mouse configuration.
[  8990.688] (==) The core keyboard device wasn't specified explicitly in the
layout.
Using the default keyboard configuration.
[  8990.688] (II) Loader magic: 0x7f66b0169d80
[  8990.688] (II) Module ABI versions:
[  8990.688] X.Org ANSI C Emulation: 0.4
[  8990.688] X.Org Video Driver: 19.0
[  8990.688] X.Org XInput driver : 21.0
[  8990.688] X.Org Server Extension : 9.0
[  8990.688] (II) xfree86: Adding drm device (/dev/dri/card1)
[  8990.688] (II) xfree86: Adding drm device (/dev/dri/card0)
[  8990.689] (--) PCI: (0:1:0:0) 10de:0fd1:1043:2103 rev 161, Mem @
0xf600/16777216, 0xe000/268435456, 0xf000/33554432, 

[Nouveau] [Bug 80865] [NVE7] Hard hang (GPC0/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS)

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=80865

--- Comment #7 from Mario Barrera mbarr...@gmx.com ---
This has been happening to me for a while, now it is more frequent, it happens
even twice a day.

Relevant parts of the log from my latest crash.

Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0] TRAP ch 6
[0x00bf556000 chromium[6894]]
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC0/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC0/TPC1/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC1/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC2/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC3/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0] TRAP ch 6
[0x00bf556000 chromium[6894]]
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC0/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC0/TPC1/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC1/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:40 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC2/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:44 localhost kernel: nouveau E[   PFIFO][:01:00.0] SCHED_ERROR
[ CTXSW_TIMEOUT ]
Jun 22 15:12:44 localhost kernel: nouveau E[   PFIFO][:01:00.0] PGR engine
fault on channel 5, recovering...
Jun 22 15:12:44 localhost kernel: nouveau E[ PGR][:01:00.0] TRAP ch 6
[0x00bf556000 chromium[6894]]
Jun 22 15:12:44 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC0/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:44 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC0/TPC1/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:44 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC1/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:44 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC2/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:12:44 localhost kernel: nouveau E[ PGR][:01:00.0]
GPC3/TPC0/MP trap: MULTIPLE_WARP_ERRORS MEM_OUT_OF_BOUNDS
Jun 22 15:13:19 localhost libvirtd[583]: No response from client 0x7faa4465af70
after 5 keepalive messages in 30 seconds
Jun 22 15:13:19 localhost libvirtd[1206]: No response from client
0x7f37e7faea50 after 5 keepalive messages in 30 seconds
-- Reboot --

-- 
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 91056] The Bard's Tale (2005, native) has rendering issues

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=91056

--- Comment #1 from Ilia Mirkin imir...@alum.mit.edu ---
Couldn't reproduce on a GF108 (nvc1), which means this is nv50-specific. I did
see some small render fail with the GF108 (the black polygon you mention
happens in the blob too), and it didn't go away with NV50_PROG_OPTIMIZE=0.

So... you need to isolate the pass that's making things worse. This can be
tricky as sometimes one pass will affect another. Start with

NV50_PROG_OPTIMIZE=1

If that fails identically, then go into nv50_ir_peephole.cpp, and look at

bool
Program::optimizeSSA(int level)
{
   RUN_PASS(1, DeadCodeElim, buryAll);
   RUN_PASS(1, CopyPropagation, run);
   RUN_PASS(1, MergeSplits, run);
   RUN_PASS(2, GlobalCSE, run);
   RUN_PASS(1, LocalCSE, run);
   RUN_PASS(2, AlgebraicOpt, run);
   RUN_PASS(2, ModifierFolding, run); // before load propagation - less checks
   RUN_PASS(1, ConstantFolding, foldAll);
   RUN_PASS(1, LoadPropagation, run);
   RUN_PASS(2, MemoryOpt, run);
   RUN_PASS(2, LocalCSE, run);
   RUN_PASS(0, DeadCodeElim, buryAll);

   return true;
}

Try to find the smallest set of 1's you have to change into 2's, until
NV50_PROG_OPTIMIZE=1 works. [By the way, since you commented on bug 90887, I
assume you have the relevant patch from that too.]

If NV50_PROG_OPTIMIZE=1 already works, try flipping some 2's into 1's until it
no longer works.

-- 
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 90887] PhiMovesPass in register allocator broken

2015-06-22 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=90887

--- Comment #13 from Béla Gyebrószki gyebr...@gmail.com ---
I tried the patch from comment #9 and it indeed fixed the rendering issues in
the games like Two Worlds 2, Trine: Enchanted Edition, Trine 2, XCOM:Enemy
Unknown, Stacking (running in Wine).
The patch greatly improves image quality but doesn't fix the rendering issues
completely in Sonic Generations or in The Raven: Legacy of a Master Thief, see
the screenshot for comparison between unmodified and patched nouveau:
https://drive.google.com/open?id=0B-tTbLKBl-tOdldDb1pRNENnYUk

VGA compatible controller: NVIDIA Corporation G92 [GeForce GTS 250] (rev a2)
Mesa 3D 10.6-branchpoint-541-g104bff0

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