[Nouveau] [Bug 81363] [NV84] Black screen after UDEV is intialized
https://bugs.freedesktop.org/show_bug.cgi?id=81363 --- Comment #11 from Jeff --- This is still not working on Kernel 4.2. But during this test I had the laptop connected to a DVI output. And the DVI output worked great. So it seems this is not working for the LVDS only, which has the black light on but remains blank/black. I noticed on a Google search that there had been blank screen issues on pre-nv50 drivers: http://patchwork.ozlabs.org/patch/215168/ I wonder if this is something that exists on my card as well. I was glad to see the display working on the DVI output, but I am hoping to have this working on LVDS at some point. Thanks -- 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] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
On Fri, Dec 18, 2015 at 7:55 AM, Hans de Goede wrote:
> Hi,
>
> On 16-12-15 18:24, Ilia Mirkin wrote:
>>
>> I believe that your problem is this:
>>
>> /*01a0*/ LD R8, [R8];
>> /* 0x80821c85 */
>>
>> That needs to be LD.E (and your ST's need to be ST.E). You're using a
>> 32-bit gmem address, but you need to be using a 64-bit one. I believe
>> the 32-bit ones work on fermi, but afaik not on Kepler.
>
>
> I do not think that is the problem, src/gallium/tests/trivial/compute
> test_input_global() has:
>
> COMP
> DCL SV[0], THREAD_ID
> DCL TEMP[0], LOCAL
> DCL TEMP[1], LOCAL
> IMM[0] UINT32 {8, 0, 0, 0}
> 0: BGNSUB :0
> 1: UMUL TEMP[0], SV[0], IMM[0]
> 2: LOAD TEMP[1].xy, RES[32764], TEMP[0]
> 3: LOAD TEMP[0].x, RES[32767], TEMP[1].
> 4: UADD TEMP[1].x, TEMP[0], -TEMP[1]
> 5: STORE RES[32767].x, TEMP[1]., TEMP[1]
> 6: RET
> 7: ENDSUB
>
> Which translates to:
>
> SUB:0 ()
> BB:0 (7 instructions) - df = { }
> -> BB:1 (cross)
> 0: rdsv u32 $r0 sv[TID:0] (8)
> 1: shl u32 $r2 $r0 0x0003 (8)
> 2: ld u64 $r0d c0[$r2+0x0] (8)
> 3: ld u32 $r2 g[$r1+0x0] (8)
> 4: add u32 $r0 $r2 neg $r0 (8)
> 5: st u32 # g[$r1+0x0] $r0 (8)
> 6: ret (8)
> BB:1 (0 instructions) - idom = BB:0, df = { }
>
> MAIN:-1 ()
> BB:0 (0 instructions) - df = { }
>
> Which is also using 32 bits loads from global memory
> and that works fine on my GK107 [GeForce GT 740].
>
> I think that for now I'll just focus on translating
> the tests from rc/gallium/tests/trivial/compute.c to
> opencl and getting the entire opencl -> llvm -> tgsi ->
> nouveau_compiler -> hardware chain to work that way.
>
> Still would be good to get nbody.c to work though.
H odd. Not sure how 32-bit addresses work there. (Or on Fermi
tbh.) Probably assumes that the upper 8 bits of the 40-bit VA are 0?
Anyways, another thing I remember is that I couldn't get barriers to
work at all with tess (with iirc, invalid opcode errors). My solution
to the problem was to just discard them, since that's what the blob
seemed to do, and I assumed they knew what they were doing.
Perhaps I was just emitting it wrong. I'd take a careful look at how
the blob emits that BAR.SYNC primitive.
Cheers,
-ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [libdrm v3 01/14] nouveau: import and install a selection of nvif headers from the kernel
Hi Ben,
I don't feel comfortable enough with the libdrm nouveau code to give you
my Rb for this series, but as this seems work as expected, this series is:
Tested-by: Samuel Pitoiset
Thanks for your work!
On 12/17/2015 12:20 AM, Ben Skeggs wrote:
From: Ben Skeggs
This commit also modifies the install path of the main libdrm_nouveau
header to be under a nouveau/ subdirectory.
Signed-off-by: Ben Skeggs
---
include/drm/nouveau_drm.h| 1 +
nouveau/Makefile.am | 11 +++-
nouveau/libdrm_nouveau.pc.in | 2 +-
nouveau/nvif/cl0080.h| 45 ++
nouveau/nvif/cl9097.h| 44 ++
nouveau/nvif/class.h | 141 +++
nouveau/nvif/if0002.h| 38
nouveau/nvif/if0003.h| 33 ++
nouveau/nvif/ioctl.h | 132
nouveau/nvif/unpack.h| 28 +
10 files changed, 473 insertions(+), 2 deletions(-)
create mode 100644 nouveau/nvif/cl0080.h
create mode 100644 nouveau/nvif/cl9097.h
create mode 100644 nouveau/nvif/class.h
create mode 100644 nouveau/nvif/if0002.h
create mode 100644 nouveau/nvif/if0003.h
create mode 100644 nouveau/nvif/ioctl.h
create mode 100644 nouveau/nvif/unpack.h
diff --git a/include/drm/nouveau_drm.h b/include/drm/nouveau_drm.h
index 87aefc5..e418f9f 100644
--- a/include/drm/nouveau_drm.h
+++ b/include/drm/nouveau_drm.h
@@ -200,6 +200,7 @@ struct drm_nouveau_sarea {
#define DRM_NOUVEAU_GROBJ_ALLOC0x04
#define DRM_NOUVEAU_NOTIFIEROBJ_ALLOC 0x05
#define DRM_NOUVEAU_GPUOBJ_FREE0x06
+#define DRM_NOUVEAU_NVIF 0x07
#define DRM_NOUVEAU_GEM_NEW0x40
#define DRM_NOUVEAU_GEM_PUSHBUF0x41
#define DRM_NOUVEAU_GEM_CPU_PREP 0x42
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index 25ea6dc..76cdeca 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -14,9 +14,18 @@ libdrm_nouveau_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
libdrm_nouveau_la_SOURCES = $(LIBDRM_NOUVEAU_FILES)
-libdrm_nouveauincludedir = ${includedir}/libdrm
+libdrm_nouveauincludedir = ${includedir}/libdrm/nouveau
libdrm_nouveauinclude_HEADERS = $(LIBDRM_NOUVEAU_H_FILES)
+libdrm_nouveaunvifincludedir = ${includedir}/libdrm/nouveau/nvif
+libdrm_nouveaunvifinclude_HEADERS = nvif/class.h \
+ nvif/cl0080.h \
+ nvif/cl9097.h \
+ nvif/if0002.h \
+ nvif/if0003.h \
+ nvif/ioctl.h \
+ nvif/unpack.h
+
pkgconfigdir = @pkgconfigdir@
pkgconfig_DATA = libdrm_nouveau.pc
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 9abfd81..7d0622e 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_nouveau.pc.in
@@ -7,5 +7,5 @@ Name: libdrm_nouveau
Description: Userspace interface to nouveau kernel DRM services
Version: @PACKAGE_VERSION@
Libs: -L${libdir} -ldrm_nouveau
-Cflags: -I${includedir} -I${includedir}/libdrm
+Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/libdrm/nouveau
Requires.private: libdrm
diff --git a/nouveau/nvif/cl0080.h b/nouveau/nvif/cl0080.h
new file mode 100644
index 000..331620a
--- /dev/null
+++ b/nouveau/nvif/cl0080.h
@@ -0,0 +1,45 @@
+#ifndef __NVIF_CL0080_H__
+#define __NVIF_CL0080_H__
+
+struct nv_device_v0 {
+ __u8 version;
+ __u8 pad01[7];
+ __u64 device; /* device identifier, ~0 for client default */
+};
+
+#define NV_DEVICE_V0_INFO 0x00
+#define NV_DEVICE_V0_TIME 0x01
+
+struct nv_device_info_v0 {
+ __u8 version;
+#define NV_DEVICE_INFO_V0_IGP 0x00
+#define NV_DEVICE_INFO_V0_PCI 0x01
+#define NV_DEVICE_INFO_V0_AGP 0x02
+#define NV_DEVICE_INFO_V0_PCIE 0x03
+#define NV_DEVICE_INFO_V0_SOC 0x04
+ __u8 platform;
+ __u16 chipset; /* from NV_PMC_BOOT_0 */
+ __u8 revision; /* from NV_PMC_BOOT_0 */
+#define NV_DEVICE_INFO_V0_TNT 0x01
+#define NV_DEVICE_INFO_V0_CELSIUS 0x02
+#define NV_DEVICE_INFO_V0_KELVIN 0x03
+#define NV_DEVICE_INFO_V0_RANKINE 0x04
+#define NV_DEVICE_INFO_V0_CURIE0x05
+#define NV_DEVICE_INFO_V0_TESLA0x06
+#define NV_DEVICE_INFO_V0_FERMI0x07
+#define NV_DEVICE_INFO_V0_KEPLER
Re: [Nouveau] [mesa v3 8/9] nvc0: remove use of deprecated sw class identifier
On 18 December 2015 at 15:24, Samuel Pitoiset wrote: > On 12/18/2015 11:19 AM, Emil Velikov wrote: >> >> The commit summary "remove use of deprecated..." is no longer >> applicable. Feel free to tweak (use nvif provided class name/define ?) >> before pushing. > > > Well, the commit summary is fine by me because the old sw class identifier > is actually deprecated with that new interface and won"t work if it's not > updated accordingly. > > But, feel free to change it. :-) > Indeed you're correct. I got mesmerised with the *906e repetition. Comment/suggestion withdraw - sorry for the noise. -Emil ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [mesa v3 8/9] nvc0: remove use of deprecated sw class identifier
On 12/18/2015 11:19 AM, Emil Velikov wrote: The commit summary "remove use of deprecated..." is no longer applicable. Feel free to tweak (use nvif provided class name/define ?) before pushing. Well, the commit summary is fine by me because the old sw class identifier is actually deprecated with that new interface and won"t work if it's not updated accordingly. But, feel free to change it. :-) -Emil ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Hi,
On 16-12-15 18:34, Ilia Mirkin wrote:
BTW, you may be interested in
https://github.com/imirkin/mesa/commits/atomic3 which has working
ARB_shader_atomic_counters and ARB_shader_storage_buffer_object
support (while ripping out things like TGSI_FILE_RESOURCE).
Interesting, good to see progress on this.
Still
working on proper memory qualifier support, and obviously need to do
some cleanup before upstreaming. Should be getting into a pushable
state probably early January.
I'm looking forward to seeing this upstream, and I'll keep this in
mind during my own work.
Regards,
Hans
Cheers,
-ilia
On Wed, Dec 16, 2015 at 12:24 PM, Ilia Mirkin wrote:
I believe that your problem is this:
/*01a0*/ LD R8, [R8];
/* 0x80821c85 */
That needs to be LD.E (and your ST's need to be ST.E). You're using a
32-bit gmem address, but you need to be using a 64-bit one. I believe
the 32-bit ones work on fermi, but afaik not on Kepler.
Cheers,
-ilia
On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede wrote:
Hi,
On 15-12-15 20:04, Ilia Mirkin wrote:
Also, where's the exit op? Perhaps what's happening is that you don't
have an exit and it just goes off executing into the ether?
Sorry I only included a small bit of the program in my original mail
because I found the use of "MOV" instructions to load constants
suspicious, is that normal ?
I've put a log with NV50_PROG_DEBUG=1 output here:
https://fedorapeople.org/~jwrdegoede/nbody.log
nvdisasm -b SM30 for the generated binary code is here:
https://fedorapeople.org/~jwrdegoede/nbody.disasm
There are already .tgsi, .hex and .bin files there if
you find those easier to use then the
NV50_PROG_DEBUG=1 output.
On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin
wrote:
A few things that stand out:
0: ld u32 %r219 c0[0x+0x0] (0)
wtf is that 0x0 thing doing there? Was it a %rX which got
constant-folded into 0? That indirectness should have then been
removed... that said, the final encoding looks fine.
I don't know, maybe there is a hint in the log file?
Regards,
Hans
I believe that kepler has this launch descriptor thing too... is that
being set correctly? Please generate a mmt trace, and we can see if
anything stands out compared to a blob trace that also does compute.
Cheers,
-ilia
On Tue, Dec 15, 2015 at 9:15 AM, Hans de Goede
wrote:
Hi all,
As part of my compute work I'm trying to get some TGSI compute
code to work. The code from mesa/src/gallium/tests/trivial.c
works.
So now I'm trying to get a "native" tgsi kernel to run via
clover, I'm using Francisco's nbody.c example for this:
https://fedorapeople.org/~jwrdegoede/nbody.c
Which does not work, at first I thought there was an issue
with the setup of the input / output buffers, but that seems to
work fine, and moreover I finally got the smart idea to look
in dmesg, which says:
[ 9920.802435] nouveau :01:00.0: gr: TRAP ch 6 [007f7fa000
nbody[31881]]
[ 9920.802449] nouveau :01:00.0: gr: GPC0/TPC0/MP trap: global
[] warp 10009 [INVALID_OPCODE]
[ 9920.802456] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global
0004
[MULTIPLE_WARP_ERRORS] warp 20009 [INVALID_OPCODE]
and repeats that for every "step" in the nobody simulation, this is on a
gk107 card.
So that seems to be the real problem, since the
error says "INVALID_OPCODE", I've put the tgsi code from nbody.c
through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30"
on it, but the output looks ok. There is a 8 byte sequence which does
not get decoded every 64 bytes but AFAIK that is the scheduling info,
so that should be fine.
One thing which does stand out is that this:
0: ld u32 %r219 c0[0x+0x0] (0)
1: ld u32 %r222 c0[0x4] (0)
2: ld u64 { %r225 %r228 } c0[0x8] (0)
3: ld u32 %r234 c0[0x10] (0)
Gets translated into (nvdisasm output) :
/*0008*/ LDC R4, c[0x0][0x0];
/* 0x140003f11c86 */
/*0010*/ MOV R2, c[0x0][0x4];
/* 0x2800400010009de4 */
/*0018*/ LDC.64 R0, c[0x0][0x8];
/* 0x140023f01ca6 */
/*0020*/ MOV R3, c[0x0][0x10];
/* 0x280040004000dde4 */
Where I would expect for LDC instructions, could that be the problem ?
If that is not the problem, then hints how to debug this further would
be
greatly appreciated.
Regards,
Hans
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Debugging INVALID_OPCODE / MULTIPLE_WARP_ERRORS ?
Hi,
On 16-12-15 18:24, Ilia Mirkin wrote:
I believe that your problem is this:
/*01a0*/ LD R8, [R8];
/* 0x80821c85 */
That needs to be LD.E (and your ST's need to be ST.E). You're using a
32-bit gmem address, but you need to be using a 64-bit one. I believe
the 32-bit ones work on fermi, but afaik not on Kepler.
I do not think that is the problem, src/gallium/tests/trivial/compute
test_input_global() has:
COMP
DCL SV[0], THREAD_ID
DCL TEMP[0], LOCAL
DCL TEMP[1], LOCAL
IMM[0] UINT32 {8, 0, 0, 0}
0: BGNSUB :0
1: UMUL TEMP[0], SV[0], IMM[0]
2: LOAD TEMP[1].xy, RES[32764], TEMP[0]
3: LOAD TEMP[0].x, RES[32767], TEMP[1].
4: UADD TEMP[1].x, TEMP[0], -TEMP[1]
5: STORE RES[32767].x, TEMP[1]., TEMP[1]
6: RET
7: ENDSUB
Which translates to:
SUB:0 ()
BB:0 (7 instructions) - df = { }
-> BB:1 (cross)
0: rdsv u32 $r0 sv[TID:0] (8)
1: shl u32 $r2 $r0 0x0003 (8)
2: ld u64 $r0d c0[$r2+0x0] (8)
3: ld u32 $r2 g[$r1+0x0] (8)
4: add u32 $r0 $r2 neg $r0 (8)
5: st u32 # g[$r1+0x0] $r0 (8)
6: ret (8)
BB:1 (0 instructions) - idom = BB:0, df = { }
MAIN:-1 ()
BB:0 (0 instructions) - df = { }
Which is also using 32 bits loads from global memory
and that works fine on my GK107 [GeForce GT 740].
I think that for now I'll just focus on translating
the tests from rc/gallium/tests/trivial/compute.c to
opencl and getting the entire opencl -> llvm -> tgsi ->
nouveau_compiler -> hardware chain to work that way.
Still would be good to get nbody.c to work though.
Regards,
Hans
Cheers,
-ilia
On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede wrote:
Hi,
On 15-12-15 20:04, Ilia Mirkin wrote:
Also, where's the exit op? Perhaps what's happening is that you don't
have an exit and it just goes off executing into the ether?
Sorry I only included a small bit of the program in my original mail
because I found the use of "MOV" instructions to load constants
suspicious, is that normal ?
I've put a log with NV50_PROG_DEBUG=1 output here:
https://fedorapeople.org/~jwrdegoede/nbody.log
nvdisasm -b SM30 for the generated binary code is here:
https://fedorapeople.org/~jwrdegoede/nbody.disasm
There are already .tgsi, .hex and .bin files there if
you find those easier to use then the
NV50_PROG_DEBUG=1 output.
On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin
wrote:
A few things that stand out:
0: ld u32 %r219 c0[0x+0x0] (0)
wtf is that 0x0 thing doing there? Was it a %rX which got
constant-folded into 0? That indirectness should have then been
removed... that said, the final encoding looks fine.
I don't know, maybe there is a hint in the log file?
Regards,
Hans
I believe that kepler has this launch descriptor thing too... is that
being set correctly? Please generate a mmt trace, and we can see if
anything stands out compared to a blob trace that also does compute.
Cheers,
-ilia
On Tue, Dec 15, 2015 at 9:15 AM, Hans de Goede
wrote:
Hi all,
As part of my compute work I'm trying to get some TGSI compute
code to work. The code from mesa/src/gallium/tests/trivial.c
works.
So now I'm trying to get a "native" tgsi kernel to run via
clover, I'm using Francisco's nbody.c example for this:
https://fedorapeople.org/~jwrdegoede/nbody.c
Which does not work, at first I thought there was an issue
with the setup of the input / output buffers, but that seems to
work fine, and moreover I finally got the smart idea to look
in dmesg, which says:
[ 9920.802435] nouveau :01:00.0: gr: TRAP ch 6 [007f7fa000
nbody[31881]]
[ 9920.802449] nouveau :01:00.0: gr: GPC0/TPC0/MP trap: global
[] warp 10009 [INVALID_OPCODE]
[ 9920.802456] nouveau :01:00.0: gr: GPC0/TPC1/MP trap: global
0004
[MULTIPLE_WARP_ERRORS] warp 20009 [INVALID_OPCODE]
and repeats that for every "step" in the nobody simulation, this is on a
gk107 card.
So that seems to be the real problem, since the
error says "INVALID_OPCODE", I've put the tgsi code from nbody.c
through "nouveau_compiler -a e4" and then run "nvdisasm -b SM30"
on it, but the output looks ok. There is a 8 byte sequence which does
not get decoded every 64 bytes but AFAIK that is the scheduling info,
so that should be fine.
One thing which does stand out is that this:
0: ld u32 %r219 c0[0x+0x0] (0)
1: ld u32 %r222 c0[0x4] (0)
2: ld u64 { %r225 %r228 } c0[0x8] (0)
3: ld u32 %r234 c0[0x10] (0)
Gets translated into (nvdisasm output) :
/*0008*/ LDC R4, c[0x0][0x0];
/* 0x140003f11c86 */
/*0010*/ MOV R2, c[0x0][0x4];
/* 0x2800400010009de4 */
/*0018*/ LDC.64 R0, c[0x0][0x8];
/* 0x140023f01ca6 */
/*0020*/ MOV R3, c[0x0][0x10];
/* 0x280040004000dde4 */
Where I would expect for LDC instructions, could that be the problem ?
If that is not the problem, then hints how to debug this further woul
Re: [Nouveau] [mesa v3 1/9] nouveau: bump required libdrm version to 2.4.66
Hi Ben, When "we're feeling bored" ideas in 13/14 of the libdrm-nouveau lot. That aside with the minor comment in 8/9 both series are Reviewed-by: Emil Velikov Hats off for this series (and the crazy drm nouveau evolution) :-) -Emil ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [mesa v3 8/9] nvc0: remove use of deprecated sw class identifier
The commit summary "remove use of deprecated..." is no longer applicable. Feel free to tweak (use nvif provided class name/define ?) before pushing. -Emil ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 70354] [NVE6, NVE7] HUB_INIT timeout on graph init, blob fw doesn't help
https://bugs.freedesktop.org/show_bug.cgi?id=70354 --- Comment #93 from Bozhan Boyadzhiev --- Ilia, what about this messages: nouveau :01:00.0: DRM: Pointer to TMDS table invalid nouveau :01:00.0: DRM: Pointer to flat panel table invalid bus: MMIO write of 0002 FAULT at 4188ac [ IBUS ] -- 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
