[Nouveau] [Bug 91037] desktop freezes shortly after boot with NV11 [GeForce2 MX/MX 400]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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)
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
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
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