search for: gf104

...ngine for performing LZO decompression as >> > part of performing the copy. It has a variety of limitations (e.g., >> > cannot handle blocklinear format), and was only in a few Fermi chips, >> > as I understand it. >> >> According to our driver source, GF100, GF104, GF110, GF114, and GF116 >> all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only >> had problems reported against GF116... and only for some people. > > Hmm, some of our internal documentation is inconsistent about whether it > applies to GF100, but ot...

Due to popular demand, I have finally found time to write this up. I had to rush it a little, but hopefully you get the gist. http://www.altechnative.net/2013/11/25/virtualized-gaming-nvidia-cards-part-3-how-to-modify-a-fermi-based-geforce-into-a-quadro-geforce-gts450gtx470gtx480-to-quadro-200050006000/ Any questions, please ask away, and I''ll update the article to expand on those

...point after that, before Fermi (G96/GT200, for example). > It seems that this was done to > avoid a hardware bug that may cause the EOI write to be dropped, blocking > all further interrupts from being serviced. That was our theory also. Thanks for clarifying. > - For GF100 and GF104, an alternate MSI EOI/rearm mechanism is used: instead > of writing to the MSI rearm register at offset 0x68 in the pcicfg window, > we write to offset 0x704. Thanks for this. Maarten discovered this for GF100, I'll modify our patch to cover GF104 also. > > > I hope this in...

...n as >>>>> part of performing the copy. It has a variety of limitations (e.g., >>>>> cannot handle blocklinear format), and was only in a few Fermi chips, >>>>> as I understand it. >>>> >>>> According to our driver source, GF100, GF104, GF110, GF114, and GF116 >>>> all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only >>>> had problems reported against GF116... and only for some people. >>> >>> Hmm, some of our internal documentation is inconsistent about whether...

...is constantly indicating that there is data to read so X will never sleep. The FD 12 is a r/w socket connected via netlink to kernel's UEVENT. Restarting X resets the problem to wait again for the sleep state. A new sleep will make the problem arice again. Hardware: I have Fermi nVidia gpu GF104 NVC4 (GeForce GTX 460) and i5 quad core amd64 processor Software: System is running gentoo with stable 'default/linux/amd64/13.0/desktop/kde'-profile Kernel: sys-kernel/gentoo-sources-3.18.7 Nouveau driver: x11-drivers/xf86-video-nouveau-1.0.11 Xorg-server: x11-base/xorg-server-1.16.4...

Hi, recently we tried to enable MSI interrupts with nouveau. Unfortunately there have been some reports of things failing with certain cards, where it isn't entirely clear if this is a GPU errata or some other component in the PCIe chain failing. Could you perhaps investigate if there are any known Nvidia GPU erratas with regard to MSI interrupts, or maybe tell us the generations of cards

...ry familiar > with it, but 0x90b8 is an engine for performing LZO decompression as > part of performing the copy. It has a variety of limitations (e.g., > cannot handle blocklinear format), and was only in a few Fermi chips, > as I understand it. According to our driver source, GF100, GF104, GF110, GF114, and GF116 all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only had problems reported against GF116... and only for some people. > > It is probably easiest to just ignore it. You can distinguish this > decompress engine from normal copy engine by l...

--- man/nouveau.man | 9 ++++++++- src/nv_driver.c | 8 ++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/man/nouveau.man b/man/nouveau.man index 07d53c8..4878f24 100644 --- a/man/nouveau.man +++ b/man/nouveau.man @@ -63,7 +63,14 @@ GF100, GF104, GF106, GF108, GF110, GF114, GF116, GF117, GF119 GK104, GK106, GK107, GK110, GK208 .TP 22 .B GeForce GTX 750 -GM107 +GM107, GM108 +.TP 22 +.B GeForce GTX 9XX +GM200, GM204, GM206 +.TP 22 +.B GeForce GTX 10XX +GP102, GP104, GP106, GP107, GP108 + .SH CONFIGURATION DETAILS Please refer to __xco...

...0-/gr: split ppc state into its subunits git bisect bad 88e98d49a1b3e0f8103cdd4fd80d576ec33133ab # bad: [e21bfd171a192dfba4a8907f2fcc41acac0f685f] drm/gf110/gr: fixup gpc/tpc initvals lists git bisect bad e21bfd171a192dfba4a8907f2fcc41acac0f685f # bad: [eeb0558e074215656ae11a170059a5f2ce29963f] drm/gf104/gr: rename gf104 (nvc4), it came before gf106 (nvc3) git bisect bad eeb0558e074215656ae11a170059a5f2ce29963f # bad: [6acc09b99d5d8f276a4f9bffc32f0bb0f939c7ca] drm/nvc0-/graph: fix gpccs fuc stack setup git bisect bad 6acc09b99d5d8f276a4f9bffc32f0bb0f939c7ca # bad: [457e77b26428ab4a24998eecfb99f27fa...

...decompression as > >> > part of performing the copy. It has a variety of limitations (e.g., > >> > cannot handle blocklinear format), and was only in a few Fermi chips, > >> > as I understand it. > >> > >> According to our driver source, GF100, GF104, GF110, GF114, and GF116 > >> all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only > >> had problems reported against GF116... and only for some people. > > > > Hmm, some of our internal documentation is inconsistent about whether it > >...

It is not advisable to perform devinit if it has already been done. VBIOS will very likely have invoked devinit if the GPU is the primary graphics device, but there is no accurate way to detect this fact yet. This patch adds such a method for gf100 and later chips, by means of the NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit, and reset to 0 when the GPU is powered.

...t offset 0x88000. (This was actually originally implemented for NV4x, so you'll probably want to do that there as well.) It seems that this was done to avoid a hardware bug that may cause the EOI write to be dropped, blocking all further interrupts from being serviced. - For GF100 and GF104, an alternate MSI EOI/rearm mechanism is used: instead of writing to the MSI rearm register at offset 0x68 in the pcicfg window, we write to offset 0x704. I hope this information helps. - Robert

...rata myself, > but it seems you guys only do it on G80/G84/G86, and use 0x88068 at > some point after that, before Fermi (G96/GT200, for example). Yes, you're right; I was reading this wrong. The config space path described above is used on G8x and G92. Newer GPUs (other than GF100 and GF104 as mentioned previously) use the "normal" path. - Robert

...NV45, C51 +NV40, NV41, NV43, NV44, NV45, C51, MCP61 .TP 22 .B GeForce 7XXX -G70, G71, G72, G73 +G70, G71, G72, G73, MCP67, MCP68, MCP73 +.TP 22 +.B GeForce 8XXX, 9XXX, 2XX, 3XX +G80, G84, G86, G92, G94, G96, G98, G200, GT215, GT216, GT218, MCP77, +MCP79, MCP89 +.TP 22 +.B GeForce 4XX, 5XX +GF100, GF104, GF106, GF108, GF110, GF114, GF116, GF117, GF119 +.TP 22 +.B GeForce 6XX, 7XX +GK104, GK106, GK107, GK110, GK208 +.TP 22 +.B GeForce GTX 750 +GM107 .SH CONFIGURATION DETAILS Please refer to __xconfigfile__(__filemansuffix__) for general configuration @@ -67,6 +80,10 @@ are supported: .BI &quot...

...but 0x90b8 is an engine for performing LZO decompression as > > part of performing the copy. It has a variety of limitations (e.g., > > cannot handle blocklinear format), and was only in a few Fermi chips, > > as I understand it. > > According to our driver source, GF100, GF104, GF110, GF114, and GF116 > all have it. [So GF106, GF108, GF117, GF119 don't have it.] We've only > had problems reported against GF116... and only for some people. Hmm, some of our internal documentation is inconsistent about whether it applies to GF100, but otherwise what I see mat...

https://bugs.freedesktop.org/show_bug.cgi?id=110797 Bug ID: 110797 Summary: No video if nomodeset is not set with GTX 460 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau

Hello, There's a long-standing bug on nouveau (this is a sample bug, but the issue has been around for a while: https://bugs.freedesktop.org/show_bug.cgi?id=85465) whereby we attempt to use the second PCOPY engine on GF116, and it is sometimes does nothing, despite mmio register 22500 saying that it's not disabled (0x22500 == 0 for this user). In the bug you can see a dump from

https://bugs.freedesktop.org/show_bug.cgi?id=97620 Bug ID: 97620 Summary: [REGRESSION] KMS having issues after kernel upgrade (4.5.1-1 to 4.6.4-1) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium

Hello, A user on an NVC3 card (GF106) is running into data errors on m2mf (class 0x9039) that we haven't seen before: http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/glean/fbo.html http://people.freedesktop.org/~imirkin/nvc0-comparison/nvc3-2014-03-17-agashlin/spec/!OpenGL%201.1/copyteximage%201D.html Specifically the data errors 0x51 and 0x53, when running

...vice->oclass[NVDEV_SUBDEV_I2C ] = nv94_i2c_oclass; device->oclass[NVDEV_SUBDEV_FUSE ] = &gf100_fuse_oclass; device->oclass[NVDEV_SUBDEV_CLOCK ] = &nvc0_clock_oclass; @@ -94,7 +94,7 @@ nvc0_identify(struct nouveau_device *device) case 0xc4: device->cname = "GF104"; device->oclass[NVDEV_SUBDEV_VBIOS ] = &nouveau_bios_oclass; - device->oclass[NVDEV_SUBDEV_GPIO ] = nv92_gpio_oclass; + device->oclass[NVDEV_SUBDEV_GPIO ] = nv94_gpio_oclass; device->oclass[NVDEV_SUBDEV_I2C ] = nv94_i2c_oclass; device->oclass[NVDEV_SUB...