search for: ctxprog

...ivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c +++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c @@ -669,21 +669,27 @@ nv40_grctx_fill(struct nouveau_device *device, struct nouveau_gpuobj *mem) }); } -void +int nv40_grctx_init(struct nouveau_device *device, u32 *size) { - u32 ctxprog[256], i; + u32 *ctxprog = kmalloc(256 * 4, GFP_KERNEL), i; struct nouveau_grctx ctx = { .device = device, .mode = NOUVEAU_GRCTX_PROG, .data = ctxprog, - .ctxprog_max = ARRAY_SIZE(ctxprog) + .ctxprog_max = 256, }; + if (!ctxprog) + return -ENOMEM; + nv40_grctx_generate(&ctx);...

So, I wrote a generator for ctxprogs on NV50, NV84, NV86, NV92, NV94, NV96, NV98. Atm it's only tested with NV86 and I'd like to see if it works for all the other cards, especially NV50. NVAx support is still missing due to some differences, but should be coming soon. Address is http://0x04.net/~mwk/gen.diff , please test...

Firmware files in firmware/ directory are not expected to be in binary format. The nouveau files are in binary format, and are therefore removed when running e.g. make clean. Fix that by converting them to ihex format instead. The patch is really big as it contains the ctxprogs stuff, so I'll provide a link instead: http://stuff.onse.fi/0001-drm-nouveau-provide-ctxprog-ctxvals-in-ihex-format.patch -- Anssi Hannula

...ut script 0 [TTM] Zone kernel: Available graphics memory: 2028336 kiB. [drm] nouveau 0000:01:00.0: 512 MiB VRAM [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture) mtrr: type mismatch for c0000000,20000000 old: write-back new: write-combining nouveau 0000:01:00.0: firmware: requesting nouveau/nv92.ctxprog [drm] nouveau 0000:01:00.0: No ctxprog for NV92 [drm] nouveau 0000:01:00.0: Detected a DAC output [drm] nouveau 0000:01:00.0: Detected a TMDS output [drm] nouveau 0000:01:00.0: Detected a DAC output [drm] nouveau 0000:01:00.0: Detected a TMDS output [drm] nouveau 0000:01:00.0: DCB encoder 1 unknown...

On Thu, 10 Dec 2009 15:33:13 -0500 "C. Bergstr?m" <cbergstrom at pathscale.com> wrote: > Pekka Paalanen > > > The big question is what we call ctxprogs: binary blobs that are > > clearly executable, running somewhere in the GPU. No-one seems > > to know, if those are copyrightable, or if they can be > > redistributed. In their current form, they have been recorded > > from the nvidia proprietary driver using mmiotrace, and...

...pretty big performance regression (nv92): $ git bisect good b2737681d5442f05ab6419e05468c3d2511a5ced is the first bad commit commit b2737681d5442f05ab6419e05468c3d2511a5ced Author: Martin Peres <martin.peres at ensi-bourges.fr> Date: Sat Jul 30 23:08:45 2011 +0200 drm/nv50/gr: enable ctxprog xfer only when we need it to save power This patch adds instructions to ctxprog and by doing, impacts context switching performance. My testcase showed a 1% performance cost using glxgears that is a context-switch bound application. Please test and report bugs/performance/power/o...

This removes dependence on external firmware for NV50 generation cards. If the generated ctxprogs don't work for you for some reason, please report it. Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/Makefile | 2 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 1 + drivers/gpu/drm/nouveau/nv50_graph.c | 74 +- drivers/gpu/drm/nouveau/...

http://0x04.net/~mwk/0001-drm-nv50-Implement-ctxprog-state-generation.patch This patch makes nouveau generate its own ctxprogs out of thin air on NV50 family cards and allows us to get rid of nvidia's firmware. It differs quite a bit from nvidia progs and needs thorough testing on as many chipsets and applications as possible, including galli...

Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv50_grctx.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_grctx.c b/drivers/gpu/drm/nouveau/nv50_grctx.c index 3c3cc46..42a8fb2 100644 --- a/drivers/gpu/drm/nouveau/nv50_grctx.c +++ b/drivers/gpu/drm/nouveau/nv50_grctx.c @@ -177,6 +177,7

Hi guys, With a GeForce 320M GPU running linux 3.13.2 and Xorg 1.15.0, I'm seeing significant graphical corruption and later unrecoverable GPU lockup, accompanied by thousands of ILLEGAL_MTHD or related kernel messages [1]. I see similar issues on 3.12 also. Is there any debugging or testing I can do to help diagnose this? Many thanks, Daniel --- [1] http://quora.org/nouveau-dmesg.txt

This will fix races between generated ctxprogs and interrupt handler. Signed-off-by: Marcin Ko?cielnicki <koriakin at 0x04.net> --- drivers/gpu/drm/nouveau/nv50_grctx.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_grctx.c b/drivers/gpu/drm/nouveau/nv50_grctx.c index d105fcd.....

On Tue, Jan 12, 2010 at 02:43:35PM +0100, Pavel Machek wrote: > Hi! > > I tried enabling staging nvidia driver on GT220, but apparently driver > does not know about it. Unfortunately, I have one of those cards here. > > (I wonder... is there better mailing list? MAINTAINERS only lists > linux-fbdev....) CC'ing proper mailing list

...el 0xcccc0000 [Xorg[29026]] 2013-06-14T04:23:14.912466+02:00 linux-zxd7 kernel: [305134.597340] nouveau E[ PGRAPH][0000:04:00.0] PGRAPH TLB flush idle timeout fail 2013-06-14T04:23:14.912468+02:00 linux-zxd7 kernel: [305134.597343] nouveau E[ PGRAPH][0000:04:00.0] PGRAPH_STATUS : 0x00000501 BUSY CTXPROG CCACHE_UNK4 2013-06-14T04:23:14.912470+02:00 linux-zxd7 kernel: [305134.597349] nouveau E[ PGRAPH][0000:04:00.0] PGRAPH_VSTATUS0: 0x00000008 CCACHE 2013-06-14T04:23:14.912472+02:00 linux-zxd7 kernel: [305134.597353] nouveau E[ PGRAPH][0000:04:00.0] PGRAPH_VSTATUS1: 0x00000000 2013-06-14T04:23:14....

...f, and chances are nvaf wasn't well-represented when all those were made. Assuming there isn't an earlier working version of nouveau, one avenue is to do a mmiotrace (https://wiki.ubuntu.com/X/MMIOTracing) of the blob starting X and running e.g. glxgears. Then one would have to look at what ctxprog it uploads and reconcile that with nouveau's somehow. (But perhaps this is entirely wrong and nouveau's ctxprogs are fine.) -ilia

https://bugs.freedesktop.org/show_bug.cgi?id=33222 Summary: random hang-up with nouveau when browsing with Google chrome Product: xorg Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

...hen any bit is set */ + { 0x00000002, "DISPATCH" }, + { 0x00000004, "UNK2" }, + { 0x00000008, "UNK3" }, + { 0x00000010, "UNK4" }, + { 0x00000020, "UNK5" }, + { 0x00000040, "M2MF" }, + { 0x00000080, "UNK7" }, + { 0x00000100, "CTXPROG" }, + { 0x00000200, "VFETCH" }, + { 0x00000400, "CCACHE_UNK4" }, + { 0x00000800, "STRMOUT_GSCHED_UNK5" }, + { 0x00001000, "UNK14XX" }, + { 0x00002000, "UNK24XX_CSCHED" }, + { 0x00004000, "UNK1CXX" }, + { 0x00008000, "CLIPID"...

- In the current situation the padding that is added is dangerous to write to, userspace could potentially overwrite parts of another bo. - Depth and stencil buffers are supposed to be large enough in general so the waste of memory should be acceptable. - Alternatives are hiding the padding from users or splitting vram into 2 zones. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com>

...ignores this specific chip. Anyway, I was porting the hard disk from my previous laptop, which had an older Nvidia card that works quite OK with both Nouveau and Gallium. On this machine, the card is recognized, but I get this message: [drm] nouveau 0000:01:00.0: I don't know how to make a ctxprog for your NVa3 card. [drm] nouveau 0000:01:00.0: Disabling acceleration. Please contact the devs. I tracked the point in the driver where this message is generated, in drivers/gpu/drm/nouveau/nv50_grctx.c and I tried, for the sake of it, just to add the relative case 0xa3: line in init, wher...

...vaf wasn't well-represented when all those were made. Assuming there > isn't an earlier working version of nouveau, one avenue is to do a > mmiotrace (https://wiki.ubuntu.com/X/MMIOTracing) of the blob starting > X and running e.g. glxgears. Then one would have to look at what > ctxprog it uploads and reconcile that with nouveau's somehow. (But > perhaps this is entirely wrong and nouveau's ctxprogs are fine.) Superb writeup! Indeed, booting with nouveau.config=PCI0=1 didn't help as you deduced, nor did nouveau.config=NvMSI=0. Interestingly, there was graphical fa...

...hen any bit is set */ + { 1<<1, "DISPATCH" }, + { 1<<2, "UNK2" }, + { 1<<3, "UNK3" }, + { 1<<4, "UNK4" }, + { 1<<5, "UNK5" }, + { 1<<6, "M2MF" }, + { 1<<7, "UNK7" }, + { 1<<8, "CTXPROG" }, + { 1<<9, "VFETCH" }, + { 1<<10, "CCACHE_UNK4" }, + { 1<<11, "STRMOUT_GSCHED_UNK5" }, + { 1<<12, "UNK14XX" }, + { 1<<13, "UNK24XX_CSCHED" }, + { 1<<14, "UNK1CXX" }, + { 1<<15, "CLIPID...