Displaying 20 results from an estimated 1000 matches similar to: "[Bug 96390] New: [GK208] DISP failure while using PRIME offloading"
2016 Feb 26
0
[PATCH 3/4] pmu/fuc: call# seems to be broken on gk208
for some reasons these calls don't really go there where they should go
leading to various corruptions of the PMU state
Signed-off-by: Karol Herbst <nouveau at karolherbst.de>
---
drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 12 ++++++------
drm/nouveau/nvkm/subdev/pmu/fuc/kernel.fuc | 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git
2017 Nov 06
0
[PATCH v3] pmu/fuc: don't use movw directly anymore
Fixes failure to compile with recent envyas as a result of the 'movw'
alias being removed for v5.
A bit of history:
v3 only has a 16-bit sign-extended immediate mov op. In order to set
the high bits, there's a separate 'sethi' op. envyas validates that
the value passed to mov(imm) is between -0x8000 and 0x7fff. In order
to simplify macros that load both the low and high word,
2017 Nov 01
2
[PATCH] pmu/fuc: don't use movw directly anymore
fixes compilation issues with recent envytools, because movw was removed
from fuc5, because it doesn't exist there anymore. The current code is
most likely broken for fuc5 hardware as well and might have triggered all
kinds of random memory reclocking fails.
Changes in fuc3 binaries are tue do opcode optimizations using shorter
opcodes when possible.
Signed-off-by: Karol Herbst <kherbst
2017 Nov 06
0
[PATCH v2] pmu/fuc: don't use movw directly anymore
Fixes failure to compile with recent envyas as a result of the 'movw'
alias being removed for v5.
A bit of history:
v3 only has a 16-bit sign-extended immediate mov op. In order to set
the high bits, there's a separate 'sethi' op. envyas validates that
the value passed to mov(imm) is between -0x8000 and 0x7fff. In order
to simplify macros that load both the low and high word,
2017 Nov 01
0
[PATCH] pmu/fuc: don't use movw directly anymore
On Wed, Nov 1, 2017 at 12:51 PM, Karol Herbst <kherbst at redhat.com> wrote:
> fixes compilation issues with recent envytools, because movw was removed
> from fuc5, because it doesn't exist there anymore. The current code is
> most likely broken for fuc5 hardware as well and might have triggered all
> kinds of random memory reclocking fails.
>
> Changes in fuc3 binaries
2023 Jun 28
2
[PATCH 1/3] drm/nouveau/disp: fix HDMI on gt215+
Cc: Ben Skeggs <bskeggs at redhat.com>
Cc: Lyude Paul <lyude at redhat.com>
Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire + infoframe methods")
Signed-off-by: Karol Herbst <kherbst at redhat.com>
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
2014 Jun 07
0
[PATCH] drm/gk208/gr: add missing registers to grctx init
This fixes hangs on GK208 which happen instantaneously on trying to use a
geometry shader.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
Cc: stable at vger.kernel.org # v3.14+
---
ctxnvf0 also writes to these registers (although slightly diff values), so I
think this is right. So I guess trap 4 is whatever this 406 subengine is...
2014 Jun 07
0
[RFC PATCH] drm/gk208/gr: adjust a couple of init values
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
MMIO32 R 0x17e91c 0x0b040a0b PMFB_BROADCAST.SUBP_BROADCAST.UNK11C => 0xb040a0b
MMIO32 R 0x17e920 0x00090c03 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 => 0x90c03
MMIO32 W 0x17e91c 0x0b030a0c PMFB_BROADCAST.SUBP_BROADCAST.UNK11C <= 0xb030a0c
MMIO32 W 0x17e920 0x00090d08 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 <= 0x90d08
And then
2015 Oct 20
1
[Bug 92560] New: [GK208] iowrite goes out of bounds on channel close
https://bugs.freedesktop.org/show_bug.cgi?id=92560
Bug ID: 92560
Summary: [GK208] iowrite goes out of bounds on channel close
Product: xorg
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
Assignee: nouveau at
2015 Oct 26
0
[PATCH 3/4] subdev/pmu/fuc: implement perf
From: Karol Herbst <git at karolherbst.de>
---
drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 788 +++++++++++++++------------
drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 740 ++++++++++++++-----------
drm/nouveau/nvkm/subdev/pmu/fuc/gk104.fuc4.h | 740 ++++++++++++++-----------
drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 710 ++++++++++++++----------
2015 Dec 01
3
[Bug 93197] New: Warsow 2.0 crashes in nouveau_fence_trigger_work
https://bugs.freedesktop.org/show_bug.cgi?id=93197
Bug ID: 93197
Summary: Warsow 2.0 crashes in nouveau_fence_trigger_work
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/DRI/nouveau
Assignee:
2017 Jan 23
8
[Bug 99505] New: Attempting to reclock GeForce GT740M (GK208) cause GPU and system to hang
https://bugs.freedesktop.org/show_bug.cgi?id=99505
Bug ID: 99505
Summary: Attempting to reclock GeForce GT740M (GK208) cause GPU
and system to hang
Product: xorg
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component:
2014 Jun 19
0
[PATCH] update man page with new chips, AccelMethod option
---
man/nouveau.man | 29 +++++++++++++++++++++++------
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/man/nouveau.man b/man/nouveau.man
index 7c72907..a8dfacd 100644
--- a/man/nouveau.man
+++ b/man/nouveau.man
@@ -13,7 +13,7 @@ nouveau \- NVIDIA video driver
.fi
.SH DESCRIPTION
.B nouveau
-is an __xservername__ driver for NVIDIA video cards. The driver supports 2D
+is an
2016 Jun 24
0
[Bug 96656] [regression, bisected] all textureGather piglits fail
https://bugs.freedesktop.org/show_bug.cgi?id=96656
Ilia Mirkin <imirkin at alum.mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|mesa-dev at lists.freedesktop. |nouveau at lists.freedesktop.o
|org |rg
QA
2014 Apr 11
13
[Bug 77333] New: Xorg segfaults trying to use nouveau GK208 as offloadsink provider
https://bugs.freedesktop.org/show_bug.cgi?id=77333
Priority: medium
Bug ID: 77333
Assignee: nouveau at lists.freedesktop.org
Summary: Xorg segfaults trying to use nouveau GK208 as
offloadsink provider
QA Contact: xorg-team at lists.x.org
Severity: normal
Classification: Unclassified
OS: All
2016 Feb 26
0
[PATCH 2/4] pmu/fuc: replace mov+sethi with imm32
on gk208+ we can simply mov 32bits, so we should have a single mov there
Signed-off-by: Karol Herbst <nouveau at karolherbst.de>
---
drm/nouveau/nvkm/subdev/pmu/fuc/gf100.fuc3.h | 1598 +++++++++++------------
drm/nouveau/nvkm/subdev/pmu/fuc/gf119.fuc4.h | 1494 +++++++++++-----------
drm/nouveau/nvkm/subdev/pmu/fuc/gk208.fuc5.h | 1424 ++++++++++-----------
2017 Jun 05
7
[PATCH v3 0/7] PMU engine counters
I think I am done reworking the series and getting to a point where I think
it is basically finished. The configuration of the slots could be improved
later on when working on dynamic reclocking, but for now it's good enough to
report the current GPU utilization to userspace.
Patches 1-4 imeplement PMU commands to setup and readout the counters.
Patches 5-6 lets Nouveau make use of 1-4.
Patch
2015 Dec 04
0
NV50 compute support questions
On 12/04/2015 09:45 AM, Hans de Goede wrote:
> Hi,
>
> On 02-12-15 19:33, Samuel Pitoiset wrote:
>>
>>
>> On 12/02/2015 04:34 PM, Hans de Goede wrote:
>>> On 01-12-15, Samuel Pitoiset wrote:
>>>
>>> >>> Ok, here is a MMT trace of vectorAdd:
>>> >>>
>>> >>>
2015 Dec 02
0
NV50 compute support questions
On 12/02/2015 04:34 PM, Hans de Goede wrote:
> On 01-12-15, Samuel Pitoiset wrote:
>
> >>> Ok, here is a MMT trace of vectorAdd:
> >>>
> >>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz
> >>
> >> Hi Hans,
> >>
> >> Thanks a lot.
> >
> > Well, I didn't know but Martin has a GK208...
>
2017 Nov 23
2
Addressing the problem of noisy GPUs under Nouveau
Hey,
Thanks for your answer, Andy!
On 22/11/17 04:06, Ilia Mirkin wrote:
> On Tue, Nov 21, 2017 at 8:29 PM, Andy Ritger <aritger at nvidia.com> wrote:
>> Hi Martin,
>
> Martin should have complete answers,
>
>>
>> I was asked to clarify a few things:
>>
>> (1) Are all the user reports of loud fans on Fermi-era GPUs?
>
> Yes. Although I