search for: ctxprogs

Some archs defconfigs have CONFIG_FRAME_WARN set to 1024, which lead to this warning: drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c: warning: the frame size of 1184 bytes is larger than 1024 bytes Reported-by: Geert Uytterhoeven <geert at linux-m68k.org> Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c | 12

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

http://bugs.freedesktop.org/show_bug.cgi?id=25952 Summary: GeForce 9800 GTX - nouveau_init takes ~ 1 minute to complete Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: major Priority: high Component: Driver/nouveau AssignedTo: nouveau at

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

Hi I've bisected 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

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/n...

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 gallium3d. Anything that works with nvidia firmware, but not with this generato...

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

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

Hi, Using kernel 3.9.4, with openSUSE 12.1 (KDE 4.7.4 I think), I was running fine for a long time with no problems. Today with openSUSE 12.3 (KDE 4.10.3, Xorg 1.13.2, upgraded on Jun. 10), my machine hung completely. I believe the nouveau driver is at fault rather than KDE or X, so chose this list. I think it might have been triggered by the "Clock" ScreenLocker (screen saver). It

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

Now it outputs: nouveau E[ PGRAPH][0000:02:00.0] PGRAPH TLB flush idle timeout fail nouveau E[ PGRAPH][0000:02:00.0] PGRAPH_STATUS: BUSY DISPATCH VFETCH CCACHE_UNK4 STRMOUT_GSCHED_UNK5 UNK14XX UNK1CXX CLIPID ZCULL ENG2D UNK34XX TPRAST TPROP ROP (0x011fde03) nouveau E[ PGRAPH][0000:02:00.0] PGRAPH_VSTATUS: CCACHE (0x00145b4d) (0x0000002d) ENG2D ROP (0x0034db40) instead of: [drm] nouveau

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

Good day. I am Carlo - living in the Netherlands. Today I came in possession of a MSI-produced barebone laptop - a MS-1656-ID1 (which is equivalent in hardware to the GT640 "gaming" laptop). This laptop comes wih a video card that is identified as follows: 01:00.0 VGA compatible controller: nVidia Corporation GT215 [GeForce GTS 250M] (rev a2) (pci ID 10de:0ca9). For your info, the

..., 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 failure booting 3.6.11, even nvidia-current fails to initialise, but these two issues could be due to running the Xorg stack in...

Now it outputs: nouveau E[ PGRAPH][0000:02:00.0] PGRAPH TLB flush idle timeout fail nouveau E[ PGRAPH][0000:02:00.0] PGRAPH_STATUS: BUSY DISPATCH VFETCH CCACHE_UNK4 STRMOUT_GSCHED_UNK5 UNK14XX UNK1CXX CLIPID ZCULL ENG2D UNK34XX TPRAST TPROP ROP (0x011fde03) nouveau E[ PGRAPH][0000:02:00.0] PGRAPH_VSTATUS_0: CCACHE (0x00145b4d) nouveau E[ PGRAPH][0000:02:00.0] PGRAPH_VSTATUS_1: (0x0000002d)