[Nouveau] [Bug 91373] Nouveau fills kern.log with gigabytes of data when molecule screensaver is run
https://bugs.freedesktop.org/show_bug.cgi?id=91373 --- Comment #4 from Olivier Diotte vhann3000+freedesk...@gmail.com --- (In reply to Ilia Mirkin from comment #3) 4.0 received some additional fixes to ctxsw logic. Please try that or 4.1. I compiled v4.1, but actually booted into 4.2.0-rc2 (derp), yet it didn't crash or write any error to the log files over the whole weekend. I will keep using it and see if I can still reproduce, but right now, this appears to work for me. I can still test v4.1 or v4.0 if you feel it would be useful. -- 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
Re: [Nouveau] [PATCH] nv50: adjust min/max lod by base level on G80
Reviewed-by: Samuel Pitoiset samuel.pitoi...@gmail.com
On 07/20/2015 09:26 AM, Ilia Mirkin wrote:
Make the assumption that there's a 1:1 TIC - TSC connection, and
increase min/max lod by the relevant texture's base level. Also if
there's no mipfilter, we have to enable it while forcing min/max lod to
the base level.
This fixes many, but not all, tex-miplevel-selection tests on G80.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
All the textureLod tests fail. If I also adjust the lod_bias by the
first_level, then the regular tests start failing.
Not sure what the right move is here... need to trace the blob to see
what it does here.
src/gallium/drivers/nouveau/nv50/nv50_state.c | 1 +
.../drivers/nouveau/nv50/nv50_stateobj_tex.h | 1 +
src/gallium/drivers/nouveau/nv50/nv50_tex.c| 39 ++
3 files changed, 41 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_state.c
b/src/gallium/drivers/nouveau/nv50/nv50_state.c
index d4d41af..98c4c3a 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_state.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_state.c
@@ -464,6 +464,7 @@ nv50_sampler_state_create(struct pipe_context *pipe,
struct nv50_tsc_entry *so = MALLOC_STRUCT(nv50_tsc_entry);
float f[2];
+ so-pipe = *cso;
so-id = -1;
so-tsc[0] = (0x00026000 |
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_stateobj_tex.h
b/src/gallium/drivers/nouveau/nv50/nv50_stateobj_tex.h
index 99548cb..9a19166 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_stateobj_tex.h
+++ b/src/gallium/drivers/nouveau/nv50/nv50_stateobj_tex.h
@@ -5,6 +5,7 @@
#include pipe/p_state.h
struct nv50_tsc_entry {
+ struct pipe_sampler_state pipe;
int id;
uint32_t tsc[8];
};
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
index 17ae27f..d79c813 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_tex.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_tex.c
@@ -344,6 +344,45 @@ nv50_validate_tsc(struct nv50_context *nv50, int s)
PUSH_DATA (push, (i 4) | 0);
continue;
}
+ if (nv50-base.screen-class_3d == NV50_3D_CLASS) {
+ struct nv50_tic_entry *tic = nv50_tic_entry(nv50-textures[s][i]);
+
+ /* We must make sure that the MIN_LOD is at least set to the first
+ * level for the G80
+ */
+ bool need_update = false;
+ float min_lod = CLAMP(
+ tic-pipe.u.tex.first_level + tsc-pipe.min_lod, 0.0f, 15.0f);
+ float max_lod = CLAMP(
+ tic-pipe.u.tex.first_level + tsc-pipe.max_lod, 0.0f, 15.0f);
+
+ if (tsc-pipe.min_mip_filter == PIPE_TEX_MIPFILTER_NONE) {
+uint32_t old_tsc1 = tsc-tsc[1];
+tsc-tsc[1] = ~NV50_TSC_1_MIPF__MASK;
+if (tic-pipe.u.tex.first_level) {
+ tsc-tsc[1] |= NV50_TSC_1_MIPF_NEAREST;
+ max_lod = min_lod = tic-pipe.u.tex.first_level;
+}
+if (tsc-tsc[1] != old_tsc1)
+ need_update = true;
+ }
+
+ uint32_t new_tsc2 =
+(((int)(max_lod * 256.0f) 0xfff) 12) |
+((int)(min_lod * 256.0f) 0xfff);
+ if ((tsc-tsc[2] 0xff) != new_tsc2) {
+tsc-tsc[2] = ~0xffu;
+tsc-tsc[2] |= new_tsc2;
+need_update = true;
+ }
+
+ if (need_update tsc-id = 0) {
+nv50_sifc_linear_u8(nv50-base, nv50-screen-txc,
+65536 + tsc-id * 32,
+NOUVEAU_BO_VRAM, 32, tsc-tsc);
+need_flush = TRUE;
+ }
+ }
if (tsc-id 0) {
tsc-id = nv50_screen_tsc_alloc(nv50-screen, tsc);
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 89047] linux-3.19 nvd9 Invalid rom content
https://bugs.freedesktop.org/show_bug.cgi?id=89047 vdanj...@free.fr vdanjean...@free.fr changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=91402 -- 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 91402] linux-4.1 nv108 Invalid ROM contents
https://bugs.freedesktop.org/show_bug.cgi?id=91402 vdanj...@free.fr vdanjean...@free.fr changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=89047 -- 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 91402] linux-4.1 nv108 Invalid ROM contents
https://bugs.freedesktop.org/show_bug.cgi?id=91402 Vincent Lefevre vincent-...@vinc17.net changed: What|Removed |Added CC||vincent-...@vinc17.net --- Comment #1 from Vincent Lefevre vincent-...@vinc17.net --- Same problem with my HP Zbook 15 G2. My Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789266 -- 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 91402] linux-4.1 nv108 Invalid ROM contents
https://bugs.freedesktop.org/show_bug.cgi?id=91402 --- Comment #2 from vdanj...@free.fr vdanjean...@free.fr --- This bug might be a duplicate of #90626 -- 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 90626] HP ZBook 15 nouveau driver hangup for kernel = 4.1
https://bugs.freedesktop.org/show_bug.cgi?id=90626 vdanj...@free.fr vdanjean...@free.fr changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=91402 -- 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 91373] Nouveau fills kern.log with gigabytes of data when molecule screensaver is run
https://bugs.freedesktop.org/show_bug.cgi?id=91373 --- Comment #5 from Olivier Diotte vhann3000+freedesk...@gmail.com --- 4.2 is no go, it just locked up again. What is interesting is that the keyboard was unresponsive (Caps Lock light didn't turn on, RESIUB wouldn't work), neither would the ACPI power off (hitting the power button), yet the computer was still responsive to the network (apache was still serving Web pages, etc). I enabled SSH so that I can log in (or try to in any case) to the computer if it happens again. I am now testing v4.1. -- 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 91402] linux-4.1 nv108 Invalid ROM contents
https://bugs.freedesktop.org/show_bug.cgi?id=91402 vdanj...@free.fr vdanjean...@free.fr changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=90626 -- 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 91408] New: Lenovo T440s alternate way to turn off discrete GPU
https://bugs.freedesktop.org/show_bug.cgi?id=91408 Bug ID: 91408 Summary: Lenovo T440s alternate way to turn off discrete GPU Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau@lists.freedesktop.org Reporter: t...@246tnt.com QA Contact: xorg-t...@lists.x.org The lenovo T440s BIOS handles the discret NVIDIA card power managemement differently when the kernel advertise Windows 2013 (since 3.15) or Windows 2015 (since 4.2) OSI strings. Calling the HSM then setting the device to D3 doesn't cause any errors and it _does_ lower the power usage, but not as much as it should. (about 1W vs 2.5W before 3.15). This means user might not notice the issue ... Using acpi_osi=!Windows 2013 acpi_osi=!Windows 2015 in the kernel command line does allow the old method to work, however the user needs to manually do this and also new OSI strings keep being added in the kernel and so this might silently re-break in the future. The dump of the DSDT tables in the latest (as of today) BIOS of the T440s is available there : http://pastebin.com/raw.php?i=C6Q3A8aa The important changes to note when Windows 2013 is in the osi string: - OSYS is set to 0x07DD. - This in turn cause VMSH to be set to 1. - This in turn causes _SB_.PCI0.PEG_.VID_.PS3 to _NOT call GPOF when the device is set to D3. - and so the card is never really turned off completely Now if you look at how GPOF can be called, you can see it will be called as part of NVP3 power resource which is PR3 ... but on the node _SB.PCI0.PEG_ and not _SB_.PCI0.PEG_.VID_ ! So this means that the parent PCIe root port the card is connected to needs to be put in D3. I did a quick hack using bumblebee (easier to try stuff out) to test and this indeed seems to work. I was able to observe the 2.5W power drop as expected and freely able to turn the card on off. -- 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 91408] Lenovo T440s alternate way to turn off discrete GPU
https://bugs.freedesktop.org/show_bug.cgi?id=91408 --- Comment #1 from Sylvain Munaut t...@246tnt.com --- Created attachment 117267 -- https://bugs.freedesktop.org/attachment.cgi?id=117267action=edit DSDT of T440s -- 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 91319] Nouveau driver cannot extract FCODE ROM / DCB Block from OpenFirmware Device tree
https://bugs.freedesktop.org/show_bug.cgi?id=91319 --- Comment #3 from Peter Saisanas psaisa...@gmail.com --- Hi, I have managed to extract the actual Open Firmware nVidia Quadro FX4500 PCI expansion ROM which i have attached. The actual ROM itself seems to have a PCIR header located @ offset 0x20. Could it be that nouveau is actually trying to read the PCIR header directly off the XROM (which is how i assume it would be done in x86) and not via the OF device tree for ppc arch in the newer versions of nouveau by any chance? Regards, Peter -- 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 91319] Nouveau driver cannot extract FCODE ROM / DCB Block from OpenFirmware Device tree
https://bugs.freedesktop.org/show_bug.cgi?id=91319 --- Comment #4 from Peter Saisanas psaisa...@gmail.com --- Created attachment 117271 -- https://bugs.freedesktop.org/attachment.cgi?id=117271action=edit OF Powermac Quadro FX4500 ROM -- 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
