[Nouveau] [Bug 27036] New: kernel panic on resume on 9400M (NVAC)
http://bugs.freedesktop.org/show_bug.cgi?id=27036 Summary: kernel panic on resume on 9400M (NVAC) Product: xorg Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau@lists.freedesktop.org ReportedBy: bj...@cornell.edu QAContact: xorg-t...@lists.x.org Got a kernel panic on resuming from suspend. Running nouveau drm kernel module 4b52473c354f7238afe0c78f50a6c84c40aa3478 and xf86-video-nouveau 6b8b15731b7610c9d8fb3625861797a0c9fd9546. See attached photo of kernel dump. The kernel taint is due to the binary Broadcom WLAN driver... hopefully that isn't affecting things. If there's any more info I can provide, please let me know. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 RFC] ttm: nouveau accelerated on Xen pv-ops kernel
On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen p...@iki.fi wrote: I'm adding dri-devel@ to CC, since this suggested patch touches TTM code, and none of the Nouveau code. TTM patches go via dri-de...@. Thanks. On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R arvin...@gmail.com wrote: Hi, Following is a simple patch that is needed in nouveau to get accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is almost the mainline merge), was substituted into the kernel-tree. All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) used of the same day. Patch: diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 10:19:28.0 +0530 +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 17:28:59.0 +0530 @@ -271,7 +271,10 @@ */ vma-vm_private_data = bo; - vma-vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | VM_DONTEXPAND; + vma-vm_flags |= VM_RESERVED | VM_MIXEDMAP | VM_DONTEXPAND; + if (!((bo-mem.placement TTM_PL_MASK_MEM) TTM_PL_FLAG_TT)) + vma-vm_flags |= VM_IO; + vma-vm_page_prot = vma_get_vm_prot(vma-vm_flags); return 0; out_unref: ttm_bo_unref(bo); sorry for the typo and other procedural errors. the last added line should be +vma-vm_page_prot = vm_get_page_prot(vma-vm_flags) This patch is necessary because, in Xen, PFN of a page is virtualised. So physical addresses for DMA programming needs to use the MFN. Xen transparently does the correct translation using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, then Xen assumes that the backing memory is in the IOMEM space, and PFN equals MFN. If not set, page_to_pfn() returns MFN. The patch enables the ttm_bo_vm_fault() handler to behave correctly under Xen, and has no side-effects on normal (not under Xen) operations. The use of TTM_PL_FLAG_TT in the check assumes that all other placements are backed by device memory or IO. If there are any other placements that use system memory, that flag has to be OR'ed into the check. The above patch has no implications on a normal kernel or a Xen pv_ops kernel booted without the Xen hypervisor. My testing is on a debian-lenny environment on a Core2 processor with nVidia GeForce 9400 GT. Efficacy of patch: successful flightgear run on dom0 AND bareboot! Arvind R. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3/3] libdrm: Move all noninstalled headers to noinst_HEADERS.
Cleanup make system so that all noninstalled headers are put
to noinst_HEADERS. This quarentees that header will be present
in tar ball but not installed with make install.
CC: nouveau@lists.freedesktop.org
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
Makefile.am |6 +++---
intel/Makefile.am | 10 ++
nouveau/Makefile.am |4 +++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index e434e1d..61da186 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -55,13 +55,13 @@ libdrm_la_SOURCES = \
xf86drmHash.c \
xf86drmRandom.c \
xf86drmSL.c \
- xf86drmMode.c \
- libdrm_lists.h
+ xf86drmMode.c
libdrmincludedir = ${includedir}
libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
-noinst_HEADERS = xf86atomic.h
+noinst_HEADERS = xf86atomic.h \
+ libdrm_lists.h
EXTRA_DIST = libdrm.pc.in include/drm/*
diff --git a/intel/Makefile.am b/intel/Makefile.am
index 9add505..d56b03a 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -36,14 +36,16 @@ libdrm_intel_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
@CLOCK_LIB@
libdrm_intel_la_SOURCES = \
intel_bufmgr.c \
- intel_bufmgr_priv.h \
intel_bufmgr_fake.c \
intel_bufmgr_gem.c \
- intel_chipset.h \
- mm.c \
- mm.h
+ mm.c
libdrm_intelincludedir = ${includedir}
libdrm_intelinclude_HEADERS = intel_bufmgr.h
+noinst_HEADERS = \
+ intel_bufmgr_priv.h \
+ intel_chipset.h \
+ mm.h
+
pkgconfig_DATA = libdrm_intel.pc
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index 5d759c5..53099eb 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -18,7 +18,6 @@ libdrm_nouveau_la_SOURCES = \
nouveau_notifier.c \
nouveau_bo.c \
nouveau_resource.c \
- nouveau_private.h \
nouveau_reloc.c
libdrm_nouveaucommonincludedir = ${includedir}/nouveau
@@ -38,5 +37,8 @@ libdrm_nouveauincludedir = ${includedir}/drm
libdrm_nouveauinclude_HEADERS = \
nouveau_drmif.h
+noinst_HEADERS = \
+ nouveau_private.h
+
pkgconfigdir = @pkgconfigdir@
pkgconfig_DATA = libdrm_nouveau.pc
--
1.6.3.3
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] GtkPerf: Non linear Add text execution time
Hello everyone, I am a daily tester of the nouveau driver on my (nVidia Corporation Quadro NVS 140M (rev a1)). Today, when trying to make compiz crash, I have tried to execute a lot of tests at the same time with both 2D and 3D. Well, I didn't bump into any crashes but I have discovered a really annoying performance issue. Indeed, the gtkTextView - Add Text of gtkperf has non-linear execution times: GtkPerf 0.40 - Starting testing: Fri Mar 12 13:57:19 2010 GtkTextView - Add text - time: 0,03 -- 10 executions --- Total time: 0,04 GtkPerf 0.40 - Starting testing: Fri Mar 12 13:57:28 2010 GtkTextView - Add text - time: 0,99 -- 100 executions --- Total time: 0,99 GtkPerf 0.40 - Starting testing: Fri Mar 12 13:57:34 2010 GtkTextView - Add text - time: 88,19 -- 1000 executions --- Total time: 88,19 So, if results were linear, we would have had a 3 seconds execution time with 1000 executions while we got 88.19s. Just to give you an idea. I was testing with even more iterations and adding just one single text can take more than one second. I don't know if it is a performance regression or if it has always been here but this could explain some slow code-path I sometime encounter using nouveau on lengthy webpages. What do you think about it ? Also, one last question, do you have any idea why KWin doesn't let me activate the composite. Do you think the problem is from KWin or does Nouveau misses a few features to get it working ? Anyway, I am an happy tester of the nouveau stack and I would be glad to help you in running tests/applying patches on my card. Martin ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium driver and compatibility issues
Am Freitag, den 12.03.2010, 12:52 +0200 schrieb Pekka Paalanen: On Thu, 11 Mar 2010 20:40:34 +0100 Uwe Bugla uwe.bu...@gmx.de wrote: Am Donnerstag, den 11.03.2010, 13:23 -0500 schrieb Younes Manton: On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla uwe.bu...@gmx.de wrote: Hi, I use two nv34 cards and I would like to test / try out / use the Gallium driver without drawbacks. A multicard setup? According to http://nouveau.freedesktop.org/wiki/FeatureMatrix that is not supported yet. What do you mean without drawbacks? Have only the apps you select to use the experimental driver and all other apps to use the stable software renderer? Do not install nouveau_dri.so system-wide, then. Note, that the Nvidia proprietary driver simply cannot live together with Nouveau like this. Unfortunately this has not been working since I decided to install / compile nouveau drivers. Problems are expected on the OpenGL front, if you install any of the experimental, unreleased 3D drivers. My system is Debian Squeeze, my kernel is 2.6.34-rc1. The problem is: Every time I load nouveau_dri.so into RAM existing applications are broken / unusable (Example: gnome-games). Without logs we cannot help at all. It does not matter if I overwrite existing versions of libglut*, libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any difference. Did you forget libglx? The X log would tell. The center of the problem is nouveau_dri.so and nothing else. Could it please be possible to modify this driver file so that it does NOT continue to break existing applications?? Yes. That is called development. It is what people are doing all the time. You whining about it does not make it happen faster. Quite the contrary. Don't install nouveau_dri.so globally. When you want to try it with a specific application set LIBGL_DRIVERS_PATH=/path/to/nouveau_dri.so in your env. Thanks. Sounds plausible. But: 1. Udev decides which driver is being loaded into memory at boot time. 2. I was asking for a _long term_ solution, not for a quick short term workaround without changing the driver itself. udev has nothing to do with this. Udev only loads the kernel modules. The 3D driver is not a kernel module, though it depends on Nouveau DRM. The long term solution is *long term*. Nouveau still does not officially support 3D, although some reports of some 3D apps working exist. The current advice is to *never* install nouveau_dri.so system-wide. Also, you have failed to provide any logs nor descriptions about what is broken and how. Therefore we cannot help. My best guess is that you have parts of the prorietary Nvidia driver still in your system (e.g. libglx). If you want to try things, do follow http://nouveau.freedesktop.org/wiki/GalliumHowto and do not install the Gallium3D driver system-wide. Pekka, although your answering style and niveau are a catastrophe I still try to extract the positive parts of the traffic: Lapse No. 1: If I mention owing 2 nv34 cards this does not automatically mean that I use a multicard setup. What do you mean without drawbacks? Lapse No. 2: If you first read a message as a whole to try and understand the issue as a whole you very simply can avoid questions like that one. So FIRST try to understand the message as a whole, THEN start answering. Note, that the Nvidia proprietary driver. Lapse No. 3: Misleading usage of expressions. Everybody talking about the Nvidia proprietary driver in the graphic card context of Nvidia cards normallly means the blob driver shipped by Nvidia (closed source driver!) which does not have any problems with stuff like Compiz or other 3D applications. I do not like blob drivers for a whole bunch of reasons. As you are definitely using the wrong expression it remains your personal secret what you are trying to express or say. Problems are expected on the OpenGL front. Lapse No. 4: I did not mention nearly all driver parts of the Gallium drivers carrying the GL in their names just by chance. I reflect while I am typing messages. I explicitly mentioned that the versions of the driver parts carrying the GL in their names are NOT responsible for the breakage that I reported. Thus it still remains your personal secret what you mean by OpenGL front. Yes. That is called development. It is what people are doing all the time. You whining about it does not make it happen faster. Quite the contrary. Lapse No. 5: If you want to be addressed like something utmost primitive that noone appreciates or needs or wants then go on expressing yourself like that. If you want to be addressed like a human being, either immediately change your style or simply shut up! Lapse No. 6: Instead of repeating the core message of my request for 4 times in this mail (how insane!) I propose to change this page
[Nouveau] [Bug 23092] Syslog flooded with nouveau 0000:01:00.0: Unhandled PFIFO_INTR - 0x00000010
http://bugs.freedesktop.org/show_bug.cgi?id=23092 Michal Suchanek hramr...@centrum.cz changed: What|Removed |Added CC||hramr...@centrum.cz --- Comment #7 from Michal Suchanek hramr...@centrum.cz 2010-03-12 06:24:01 PST --- I had similar messages when vesafb was activated before loading the nouveau module. Setting vga=normal on the kernel command line resolved the issue for me. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 27049] New: fails to start - drm open issue?
http://bugs.freedesktop.org/show_bug.cgi?id=27049 Summary: fails to start - drm open issue? Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau@lists.freedesktop.org ReportedBy: hramr...@centrum.cz QAContact: xorg-t...@lists.x.org Created an attachment (id=33996) -- (http://bugs.freedesktop.org/attachment.cgi?id=33996) X log X does not start. I am running linux 2.6.33, libdrm 2.4.18 nouveau git X 1.7.5 Mesa 7.7 It opens the drm device and then says it failed to open it. I suspect I have kernel module 0.0.15 and libdrm module 0.0.16 but it is not mentioned anywhere in the log that the versions do not match. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 27049] fails to start - drm open issue?
http://bugs.freedesktop.org/show_bug.cgi?id=27049 --- Comment #1 from Michal Suchanek hramr...@centrum.cz 2010-03-12 06:34:45 PST --- Created an attachment (id=33997) -- (http://bugs.freedesktop.org/attachment.cgi?id=33997) dmesg excerpt -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] nv50 mouse cursor disappears hourly
On Thursday 11 March 2010 15:30:01 Brian DeRocher wrote: Next time it happens, i'll check /var/log/ /var/log/syslog Mar 11 15:26:38 bregalad kernel: [ 4011.159249] [drm] nouveau :01:00.0: Allocating FIFO number 4 Mar 11 15:26:38 bregalad kernel: [ 4011.172345] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 4 Mar 11 15:26:56 bregalad kernel: [ 4029.528631] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 4 Mar 11 15:30:01 bregalad /USR/SBIN/CRON[4460]: (www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache/access.log ] /usr/lib/cgi-bin/awstats.pl -config=awstats -update /dev/null) Mar 11 15:40:01 bregalad /USR/SBIN/CRON[4703]: (www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache/access.log ] /usr/lib/cgi-bin/awstats.pl -config=awstats -update /dev/null) Mar 11 15:50:01 bregalad /USR/SBIN/CRON[5128]: (www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache/access.log ] /usr/lib/cgi-bin/awstats.pl -config=awstats -update /dev/null) Mar 11 15:59:05 bregalad kernel: [ 5958.643154] [drm] nouveau :01:00.0: EvoCh 0 Mthd 0x Data 0x0400 (0x0002 0x01) Mar 11 16:00:01 bregalad /USR/SBIN/CRON[5371]: (www-data) CMD ([ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache/access.log ] /usr/lib/cgi-bin/awstats.pl -config=awstats -update /dev/null) /var/log/dmesg Mar 11 15:59:05 bregalad kernel: [ 5958.643154] [drm] nouveau :01:00.0: EvoCh 0 Mthd 0x Data 0x0400 (0x0002 0x01) Mar 11 14:20:53 bregalad kernel: [ 65.957641] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 3 Mar 11 14:29:08 bregalad kernel: [ 561.104849] [drm] LVDS-7: set mode 1920x1200 3e Mar 11 14:29:23 bregalad kernel: [ 576.013970] [drm] LVDS-7: set mode 1920x1200_60.00 3d Mar 11 14:29:45 bregalad kernel: [ 598.589129] CPUFREQ: Per core ondemand sysfs interface is deprecated - up_threshold Mar 11 14:47:32 bregalad kernel: [ 1665.713034] CE: hpet increasing min_delta_ns to 15000 nsec Mar 11 14:50:34 bregalad kernel: [ 1847.552047] CE: hpet increasing min_delta_ns to 22500 nsec Mar 11 15:26:38 bregalad kernel: [ 4011.159249] [drm] nouveau :01:00.0: Allocating FIFO number 4 Mar 11 15:26:38 bregalad kernel: [ 4011.172345] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 4 Mar 11 15:26:56 bregalad kernel: [ 4029.528631] [drm] nouveau :01:00.0: nouveau_channel_free: freeing fifo 4 Mar 11 15:59:05 bregalad kernel: [ 5958.643154] [drm] nouveau :01:00.0: EvoCh 0 Mthd 0x Data 0x0400 (0x0002 0x01) Brian -- http://brian.derocher.org ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Intel-gfx] [PATCH 3/3] libdrm: Move all noninstalled headers to noinst_HEADERS.
On Fri, Mar 12, 2010 at 4:50 AM, Pauli Nieminen suok...@gmail.com wrote:
Cleanup make system so that all noninstalled headers are put
to noinst_HEADERS. This quarentees that header will be present
in tar ball but not installed with make install.
CC: nouveau@lists.freedesktop.org
Signed-off-by: Pauli Nieminen suok...@gmail.com
---
Makefile.am | 6 +++---
intel/Makefile.am | 10 ++
nouveau/Makefile.am | 4 +++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index e434e1d..61da186 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -55,13 +55,13 @@ libdrm_la_SOURCES = \
xf86drmHash.c \
xf86drmRandom.c \
xf86drmSL.c \
- xf86drmMode.c \
- libdrm_lists.h
+ xf86drmMode.c
libdrmincludedir = ${includedir}
libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
-noinst_HEADERS = xf86atomic.h
+noinst_HEADERS = xf86atomic.h \
+ libdrm_lists.h
EXTRA_DIST = libdrm.pc.in include/drm/*
diff --git a/intel/Makefile.am b/intel/Makefile.am
index 9add505..d56b03a 100644
--- a/intel/Makefile.am
+++ b/intel/Makefile.am
@@ -36,14 +36,16 @@ libdrm_intel_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
@CLOCK_LIB@
libdrm_intel_la_SOURCES = \
intel_bufmgr.c \
- intel_bufmgr_priv.h \
intel_bufmgr_fake.c \
intel_bufmgr_gem.c \
- intel_chipset.h \
- mm.c \
- mm.h
+ mm.c
libdrm_intelincludedir = ${includedir}
libdrm_intelinclude_HEADERS = intel_bufmgr.h
+noinst_HEADERS = \
+ intel_bufmgr_priv.h \
+ intel_chipset.h \
+ mm.h
+
pkgconfig_DATA = libdrm_intel.pc
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index 5d759c5..53099eb 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -18,7 +18,6 @@ libdrm_nouveau_la_SOURCES = \
nouveau_notifier.c \
nouveau_bo.c \
nouveau_resource.c \
- nouveau_private.h \
nouveau_reloc.c
libdrm_nouveaucommonincludedir = ${includedir}/nouveau
@@ -38,5 +37,8 @@ libdrm_nouveauincludedir = ${includedir}/drm
libdrm_nouveauinclude_HEADERS = \
nouveau_drmif.h
+noinst_HEADERS = \
+ nouveau_private.h
+
pkgconfigdir = @pkgconfigdir@
pkgconfig_DATA = libdrm_nouveau.pc
I don't think this is the best strategy. Having the headers under
_SOURCES already means they'll get distributed. The only reason for
the separate _HEADERS declarations is if you need to install them.
http://www.gnu.org/software/automake/manual/automake.html#Headers
--
Dan
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium driver and compatibility issues
On 11.03.2010 18:42, Uwe Bugla wrote: Hi, I use two nv34 cards and I would like to test / try out / use the Gallium driver without drawbacks. Note that you said use, and not own, which is a little biased towards they're plugged into the same MB. Unfortunately this has not been working since I decided to install / compile nouveau drivers. This is kind of a pre-requisite to be able to try the gallium drivers ... well, you can run a simulation in your head, but, that would be rather tedious. My system is Debian Squeeze, my kernel is 2.6.34-rc1. The problem is: Every time I load nouveau_dri.so into RAM existing applications are broken / unusable (Example: gnome-games). Loading stuff into RAM by itself shouldn't cause any problems if that RAM isn't used by something else, but, I'll just interpret this as best I can: AIGLX is loading it from .../lib/dri/, i.e. you installed it globally - not the safest way to try, because now any app using OpenGL may use the hw through indirect rendering. (indirect meaning app - libGL - Xorg - nouveau_dri, instead of app - libGL - nouveau_dri) It does not matter if I overwrite existing versions of libglut*, libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any difference. The center of the problem is nouveau_dri.so and nothing else. Sure, libGL etc. don't directly control the hardware, they hook into the dri driver (nouveau_dri.so) to do that. Could it please be possible to modify this driver file so that it does NOT continue to break existing applications?? It will break existing applications if existing applications make use of it and it is itself broken. So, either don't let them use it, or fix it. We're working on that. Consider yourself lucky that you got an answer at all. Normally, at this time, we don't care about the process of people trying the gallium driver without knowing exactly (well, to a certain degree at least) what they're doing. Half-expecting to have my message dissected now, Christoph Would be a pleasure! Cheers Uwe ___ 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] Gallium driver and compatibility issues
Am Freitag, den 12.03.2010, 16:19 +0100 schrieb Christoph Bumiller: On 11.03.2010 18:42, Uwe Bugla wrote: Hi, I use two nv34 cards and I would like to test / try out / use the Gallium driver without drawbacks. Note that you said use, and not own, which is a little biased towards they're plugged into the same MB. Unfortunately this has not been working since I decided to install / compile nouveau drivers. This is kind of a pre-requisite to be able to try the gallium drivers ... well, you can run a simulation in your head, but, that would be rather tedious. My system is Debian Squeeze, my kernel is 2.6.34-rc1. The problem is: Every time I load nouveau_dri.so into RAM existing applications are broken / unusable (Example: gnome-games). Loading stuff into RAM by itself shouldn't cause any problems if that RAM isn't used by something else, but, I'll just interpret this as best I can: AIGLX is loading it from .../lib/dri/, i.e. you installed it globally - not the safest way to try, because now any app using OpenGL may use the hw through indirect rendering. (indirect meaning app - libGL - Xorg - nouveau_dri, instead of app - libGL - nouveau_dri) It does not matter if I overwrite existing versions of libglut*, libGLw*, libGLU*, libGL*, libEGL* or not - that does not make any difference. The center of the problem is nouveau_dri.so and nothing else. Sure, libGL etc. don't directly control the hardware, they hook into the dri driver (nouveau_dri.so) to do that. Could it please be possible to modify this driver file so that it does NOT continue to break existing applications?? It will break existing applications if existing applications make use of it and it is itself broken. So, either don't let them use it, or fix it. We're working on that. Consider yourself lucky that you got an answer at all. Normally, at this time, we don't care about the process of people trying the gallium driver without knowing exactly (well, to a certain degree at least) what they're doing. Half-expecting to have my message dissected now, Christoph Would be a pleasure! Cheers Uwe Christoph, Thanks for the explanation of indirect rendering. Consider yourself lucky that you got an answer at all. Please avoid sentences like that one, as this bum style really sucks! In addition to my proposal of changing the intro of the Gallium HOWTO I would propose to establish an (incomplete) list of apps known to work with the Gallium driver. So one can easily find out the gaps and at least try to fill them by testing. Reason / Conclusion: Developers of whatever kind of software aren't omnicient gods. They need feedback, cause without that feedback they are lost. Whenever Gallium and nouveau will be stable or finished they will not be the result of Stay-away-from-it slogans by some profile-neurotic stupid, arrogant and asocial would-like-to's. They will be instead products of a social community work of many many different people. Cheers Uwe ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 27036] kernel panic on resume on 9400M (NVAC)
http://bugs.freedesktop.org/show_bug.cgi?id=27036 --- Comment #2 from Marcin Slusarz marcin.slus...@gmail.com 2010-03-12 09:35:22 PST --- it's probably a duplicate of (still unresolved) bug 26521 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 27049] fails to start - drm open issue?
http://bugs.freedesktop.org/show_bug.cgi?id=27049 Michal Suchanek hramr...@centrum.cz changed: What|Removed |Added Attachment #33997|0 |1 is obsolete|| --- Comment #3 from Michal Suchanek hramr...@centrum.cz 2010-03-12 09:59:59 PST --- Created an attachment (id=34004) -- (http://bugs.freedesktop.org/attachment.cgi?id=34004) drm dmesg excerpt Installing the firmware changes dmesg output slightly but the X server fails in the same way producing the same log. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 27049] fails to start - drm open issue?
http://bugs.freedesktop.org/show_bug.cgi?id=27049 --- Comment #4 from okias d.ok...@gmail.com 2010-03-12 10:05:29 PST --- Update to lastest git, there is no need to install firmware (nouveau tree or kernel 2.6.34-rc1+). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 26800] Nouveau TV-out incorrectly detecting load
http://bugs.freedesktop.org/show_bug.cgi?id=26800 --- Comment #12 from Francisco Jerez curroje...@riseup.net 2010-03-12 10:21:48 PST --- Created an attachment (id=34006) -- (http://bugs.freedesktop.org/attachment.cgi?id=34006) nv67_tvdac_load_2.patch (In reply to comment #11) (In reply to comment #10) Is the TV detected properly when it's plugged in? In particular 'xrandr --prop |grep subconnector' should tell you the right connector type after you've plugged it in (Composite I guess). It looks like it. Booting with the TV hooked in, it chooses the lower default resolution it was using before your patch. The output from 'xrandr --prop | grep subconnector' was: subconnector: SCART select subconnector:Automatic Does the attached patch have the same effect? [...] The TV-out doesn't actually show anything, but I imagine that is to be expected according to the status matrix. Actually it's a bit unexpected, TV-out is supposed to work on all the nv40-like cards, but I think you're the first one to try it on an nv6x. Sadly the mmiotrace you sent seems to be incomplete: Are you sure you waited long enough before giving up? X often takes quite a while to start up when you're mmiotracing, up to several minutes. -Andy -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] Gallium driver and compatibility issues
On Fri, 12 Mar 2010 17:09:38 +0100 Uwe Bugla uwe.bu...@gmx.de wrote: Reason / Conclusion: Developers of whatever kind of software aren't omnicient gods. They need feedback, cause without that feedback they are lost. The point is, the developers do NOT need feedback TODAY. They have enough broken applications to debug on their own. When this situation changes, it will certainly be announced to the world. But not yet. That is the reason why end users should not be trying the 3D part of the driver set. This is also why developers are so hostile to 3D issues. -- Pekka Paalanen http://www.iki.fi/pq/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium driver and compatibility issues
On Fri, 12 Mar 2010 14:51:34 +0100 Uwe Bugla uwe.bu...@gmx.de wrote: Note, that the Nvidia proprietary driver. Lapse No. 3: Misleading usage of expressions. Everybody talking about the Nvidia proprietary driver in the graphic card context of Nvidia cards normallly means the blob driver shipped by Nvidia (closed source driver!) which does not have any problems with stuff like Compiz or other 3D applications. I do not like blob drivers for a whole bunch of reasons. As you are definitely using the wrong expression it remains your personal secret what you are trying to express or say. One of the most common reasons for problems with Nouveau are the remnants of the proprietary driver. Since you did not provide kernel log, X log, nor glxinfo output, I of course assumed the most probable case. A stale libglx from the blob kills OpenGL, for instance. Furthermore, you cannot have the Nvidia proprietary 3D driver running by default, and then use the Nouveau 3D driver on selected apps. If you use *any* part of Nouveau, you cannot have *any* part of the proprietary driver, and vice versa. They cannot live together at all. I'm sorry I guessed your problem wrong. There was no real information to begin the diagnosis with. Problems are expected on the OpenGL front. Lapse No. 4: I did not mention nearly all driver parts of the Gallium drivers carrying the GL in their names just by chance. I reflect while I am typing messages. I explicitly mentioned that the versions of the driver parts carrying the GL in their names are NOT responsible for the breakage that I reported. Thus it still remains your personal secret what you mean by OpenGL front. Actually, they are. Mesa libGL will try to load nouveau_dri.so to provide hardware accelerated 3D rendering. At this time OpenGL (via Mesa) is the only real user of nouveau_dri.so. nouveau_dri.so may be loaded by the X server (AIGLX) or the application (direct rendering) when they load libGL. In short, having nouveau_dri.so will break OpenGL and perhaps kill the X server in the AIGLX case. Lapse No. 6: Instead of repeating the core message of my request for 4 times in this mail (how insane!) I propose to change this page http://nouveau.freedesktop.org/wiki/GalliumHowto in the following way: 1. Wipe off the following stupid idiotic crap: Warning : Nouveau's developers don't want people to build gallium drivers now, and do not support it at all. They also don't want bug reports on gallium ATM. This is code in rapid development. Bug reports for this are useless, as it's known to be broken. That is rude on purpose. It is supposed to be crystal clear to everyone, that this is not yet for end users, but apparently it is not that clear. The time for end users will come, later. At that time the page will be rewritten to be polite. Right now it is just a cheatsheet for new developers. And once again: The error is not hidden in some library file containing the GL in its name, and the versioning of those GL files is also NOT the problem. It's the sources of the nouveau_dri.so file that do contain the bug. True. nouveau_dri.so misses complete features and contains bugs. I read your two first posts as nothing more than an elaborate Fix everything, please. That really is what people are actually doing on their free time. Trying to kick their butt can only make them ignorant or angry. -- Pekka Paalanen http://www.iki.fi/pq/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Interrupt setting
Hi, I am responding to myself... Interrupts now work; I should have set the NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN flag every time a command is sent. In fact, I thought this flag tells GPU to notify us of when DMA transfers are done, but I got PGRAPH_NOTIFY interrupts by this. It sounds to me that they notify of when GPU operations are done rather than DMA transfers. # PGRAPH_BUFFER_NOTIFY sounds more related to DMA transfers. Is my understanding wrong? I appreciate any comments or information about this. Best regards, - Shinpei -Original Message- From: nouveau-boun...@lists.freedesktop.org [mailto:nouveau-boun...@lists.freedesktop.org] On Behalf Of Shinpei KATO Sent: Friday, March 12, 2010 7:21 AM To: nouveau@lists.freedesktop.org Subject: [Nouveau] Interrupt setting Hi all, I am a Nouveau user on FC12 with GeForce 9500GT. I have read the Nouveau wiki documents, and they imply that there are ways to set GPU to send interrupts to CPU, when we want to be notified for something, e.g., when DMA transfer or GPU operation is completed. By default, when I run an OpenGL demo application from Gallium3D, the driver gets no interrupts from GPU in nouveau_irq_handler(), except that it gets one NV_PFIFO_INTR_CACHE_ERROR interrupt right after the FIFO is allocated. According to the wiki docs, I need to set NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN into the 'notify' field of an object in a channel. Hence, I tried seting a flag to a DMA notifier in nouveau_dma_init(): // seems entry[1] is related to a DMA notifier? nv_wo32(dev, m2mf, 1, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); I also tried sending some command: // guess this is a very wrong way ;-) BEGIN_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY, 1); OUT_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); But they both did not work... How can we set GPU to send interrupts to CPU? I would appreciate your comments. Thanks, - Shinpei ___ 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] Gallium driver and compatibility issues
Am Freitag, den 12.03.2010, 22:25 +0200 schrieb Pekka Paalanen: On Fri, 12 Mar 2010 14:51:34 +0100 Uwe Bugla uwe.bu...@gmx.de wrote: Note, that the Nvidia proprietary driver. Lapse No. 3: Misleading usage of expressions. Everybody talking about the Nvidia proprietary driver in the graphic card context of Nvidia cards normallly means the blob driver shipped by Nvidia (closed source driver!) which does not have any problems with stuff like Compiz or other 3D applications. I do not like blob drivers for a whole bunch of reasons. As you are definitely using the wrong expression it remains your personal secret what you are trying to express or say. One of the most common reasons for problems with Nouveau are the remnants of the proprietary driver. Since you did not provide kernel log, X log, nor glxinfo output, I of course assumed the most probable case. A stale libglx from the blob kills OpenGL, for instance. Furthermore, you cannot have the Nvidia proprietary 3D driver running by default, and then use the Nouveau 3D driver on selected apps. If you use *any* part of Nouveau, you cannot have *any* part of the proprietary driver, and vice versa. They cannot live together at all. I'm sorry I guessed your problem wrong. There was no real information to begin the diagnosis with. Problems are expected on the OpenGL front. Lapse No. 4: I did not mention nearly all driver parts of the Gallium drivers carrying the GL in their names just by chance. I reflect while I am typing messages. I explicitly mentioned that the versions of the driver parts carrying the GL in their names are NOT responsible for the breakage that I reported. Thus it still remains your personal secret what you mean by OpenGL front. Actually, they are. Mesa libGL will try to load nouveau_dri.so to provide hardware accelerated 3D rendering. At this time OpenGL (via Mesa) is the only real user of nouveau_dri.so. nouveau_dri.so may be loaded by the X server (AIGLX) or the application (direct rendering) when they load libGL. In short, having nouveau_dri.so will break OpenGL and perhaps kill the X server in the AIGLX case. Lapse No. 6: Instead of repeating the core message of my request for 4 times in this mail (how insane!) I propose to change this page http://nouveau.freedesktop.org/wiki/GalliumHowto in the following way: 1. Wipe off the following stupid idiotic crap: Warning : Nouveau's developers don't want people to build gallium drivers now, and do not support it at all. They also don't want bug reports on gallium ATM. This is code in rapid development. Bug reports for this are useless, as it's known to be broken. That is rude on purpose. It is supposed to be crystal clear to everyone, that this is not yet for end users, but apparently it is not that clear. The time for end users will come, later. At that time the page will be rewritten to be polite. Right now it is just a cheatsheet for new developers. And once again: The error is not hidden in some library file containing the GL in its name, and the versioning of those GL files is also NOT the problem. It's the sources of the nouveau_dri.so file that do contain the bug. True. nouveau_dri.so misses complete features and contains bugs. I read your two first posts as nothing more than an elaborate Fix everything, please. That really is what people are actually doing on their free time. Trying to kick their butt can only make them ignorant or angry. Yup! Good vibes! a. I do not use parts of the Nvidia blob driver or the blob as whole. b. Up to now I always loaded nouveau_dri.so via AIGLX plus minimal xorg.conf plus nouveau kernel staging driver. c. I can send you some xorg.0.log if you may wish. What other log files could be useful please? d. In fact the xorg server did not crash even once. The only thing that is broken is the specific application (solitaire). There do exist apps that are not broken. That's it for now. If you need further info please tell me. Otherwise I will stay away from Gallium from now on. Cheers Uwe ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 26800] Nouveau TV-out incorrectly detecting load
http://bugs.freedesktop.org/show_bug.cgi?id=26800 --- Comment #13 from Andy Rink personman_...@hotmail.com 2010-03-12 13:28:35 PST --- (In reply to comment #12) Created an attachment (id=34006) -- (http://bugs.freedesktop.org/attachment.cgi?id=34006) [details] nv67_tvdac_load_2.patch Does the attached patch have the same effect? Do I need to revert the previous patch to apply this one? Actually it's a bit unexpected, TV-out is supposed to work on all the nv40-like cards, but I think you're the first one to try it on an nv6x. Hmmm ok. According to the status matrix, it is showing that it's the nv30 that is supposed to have functional TV-out, with NV40 cards marked as mostly. This is interesting, because I have a 6600 chip in my media machine, and I was unable to get TV out from that as well, which I think is an NV40 card. I didn't spend much time on that, so I'll do more testing. Sadly the mmiotrace you sent seems to be incomplete: Are you sure you waited long enough before giving up? X often takes quite a while to start up when you're mmiotracing, up to several minutes. I did give it a few minutes, but perhaps not enough. I'll try it again and wait longer. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 26800] Nouveau TV-out incorrectly detecting load
http://bugs.freedesktop.org/show_bug.cgi?id=26800 --- Comment #14 from Francisco Jerez curroje...@riseup.net 2010-03-12 13:46:05 PST --- (In reply to comment #13) (In reply to comment #12) Created an attachment (id=34006) -- (http://bugs.freedesktop.org/attachment.cgi?id=34006) [details] [details] nv67_tvdac_load_2.patch Does the attached patch have the same effect? Do I need to revert the previous patch to apply this one? Yes. Actually it's a bit unexpected, TV-out is supposed to work on all the nv40-like cards, but I think you're the first one to try it on an nv6x. Hmmm ok. According to the status matrix, it is showing that it's the nv30 that is supposed to have functional TV-out, with NV40 cards marked as mostly. This is interesting, because I have a 6600 chip in my media machine, and I was unable to get TV out from that as well, which I think is an NV40 card. I didn't spend much time on that, so I'll do more testing. That one was reported to work IIRC. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] Gallium driver and compatibility issues
It is not surprising that some (or most) 3D applications don't actually work correctly with nouveau on nv3x right now. The driver will probably improve in the future. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 26800] Nouveau TV-out incorrectly detecting load
http://bugs.freedesktop.org/show_bug.cgi?id=26800 --- Comment #15 from Andy Rink personman_...@hotmail.com 2010-03-12 14:35:43 PST --- I tried to get a full mmiotrace with the blob again, and no luck. I let it attempt to boot X for about 20 minutes. The LVDS blinked once or twice, but that was it, nothing on the TV. The hard drive light wasn't blinking or anything. :/ I'll try out that other patch and post back. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 26800] Nouveau TV-out incorrectly detecting load
http://bugs.freedesktop.org/show_bug.cgi?id=26800 --- Comment #16 from Andy Rink personman_...@hotmail.com 2010-03-12 15:27:59 PST --- With patch 2 I get: subconnector: Composite select subconnector:Automatic Other than that, seems to work the same as patch 1. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] Interrupt setting
On Fri, Mar 12, 2010 at 4:14 PM, Shinpei KATO shin...@il.is.s.u-tokyo.ac.jp wrote: Hi, I am responding to myself... Interrupts now work; I should have set the NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN flag every time a command is sent. In fact, I thought this flag tells GPU to notify us of when DMA transfers are done, but I got PGRAPH_NOTIFY interrupts by this. It sounds to me that they notify of when GPU operations are done rather than DMA transfers. # PGRAPH_BUFFER_NOTIFY sounds more related to DMA transfers. Is my understanding wrong? I appreciate any comments or information about this. Best regards, - Shinpei -Original Message- From: nouveau-boun...@lists.freedesktop.org [mailto:nouveau-boun...@lists.freedesktop.org] On Behalf Of Shinpei KATO Sent: Friday, March 12, 2010 7:21 AM To: nouveau@lists.freedesktop.org Subject: [Nouveau] Interrupt setting Hi all, I am a Nouveau user on FC12 with GeForce 9500GT. I have read the Nouveau wiki documents, and they imply that there are ways to set GPU to send interrupts to CPU, when we want to be notified for something, e.g., when DMA transfer or GPU operation is completed. By default, when I run an OpenGL demo application from Gallium3D, the driver gets no interrupts from GPU in nouveau_irq_handler(), except that it gets one NV_PFIFO_INTR_CACHE_ERROR interrupt right after the FIFO is allocated. According to the wiki docs, I need to set NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN into the 'notify' field of an object in a channel. Hence, I tried seting a flag to a DMA notifier in nouveau_dma_init(): // seems entry[1] is related to a DMA notifier? nv_wo32(dev, m2mf, 1, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); I also tried sending some command: // guess this is a very wrong way ;-) BEGIN_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY, 1); OUT_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); But they both did not work... How can we set GPU to send interrupts to CPU? I would appreciate your comments. Thanks, - Shinpei Nouveau doesn't really make use of interrupts so you wont see them while running OpenGL. In general we make use of fences to signal when things of interest have occured. Is there something particular you're trying to accomplish or is this just a learning exercise? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Interrupt setting
Dear Younes, Thank you for your reply. Nouveau doesn't really make use of interrupts so you wont see them while running OpenGL. In general we make use of fences to signal when things of interest have occured. Is there something particular you're trying to accomplish or is this just a learning exercise? I have been using Nouveau for a research purpose, though it has been just a month. So I can say both something particular and a learning exercise. I have tried understanding the behavir of fences, but a bit hard to catch up the execution flow. To my understanding, for instance every time pushbuf ioctl is called, you create a fence object. Does this make a caller process to wait for a completion of a GPU command? I inserted printk()s in nouveau_fence_wait(), but the process does not seem sleeping. I am also wondering if current GPUs can be set up to generate interrupts when GPU commands are done. My guess is that NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY is to generate interrupts when DMA transfers are done. Am I misunderstanding? Best, - Shinpei -Original Message- From: Younes Manton [mailto:youne...@gmail.com] Sent: Saturday, March 13, 2010 10:31 AM To: Shinpei KATO Cc: nouveau@lists.freedesktop.org Subject: Re: [Nouveau] Interrupt setting On Fri, Mar 12, 2010 at 4:14 PM, Shinpei KATO shin...@il.is.s.u-tokyo.ac.jp wrote: Hi, I am responding to myself... Interrupts now work; I should have set the NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN flag every time a command is sent. In fact, I thought this flag tells GPU to notify us of when DMA transfers are done, but I got PGRAPH_NOTIFY interrupts by this. It sounds to me that they notify of when GPU operations are done rather than DMA transfers. # PGRAPH_BUFFER_NOTIFY sounds more related to DMA transfers. Is my understanding wrong? I appreciate any comments or information about this. Best regards, - Shinpei -Original Message- From: nouveau-boun...@lists.freedesktop.org [mailto:nouveau-boun...@lists.freedesktop.org] On Behalf Of Shinpei KATO Sent: Friday, March 12, 2010 7:21 AM To: nouveau@lists.freedesktop.org Subject: [Nouveau] Interrupt setting Hi all, I am a Nouveau user on FC12 with GeForce 9500GT. I have read the Nouveau wiki documents, and they imply that there are ways to set GPU to send interrupts to CPU, when we want to be notified for something, e.g., when DMA transfer or GPU operation is completed. By default, when I run an OpenGL demo application from Gallium3D, the driver gets no interrupts from GPU in nouveau_irq_handler(), except that it gets one NV_PFIFO_INTR_CACHE_ERROR interrupt right after the FIFO is allocated. According to the wiki docs, I need to set NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN into the 'notify' field of an object in a channel. Hence, I tried seting a flag to a DMA notifier in nouveau_dma_init(): // seems entry[1] is related to a DMA notifier? nv_wo32(dev, m2mf, 1, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); I also tried sending some command: // guess this is a very wrong way ;-) BEGIN_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY, 1); OUT_RING(chan, NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY_STYLE_WRITE_LE_AWAKEN); But they both did not work... How can we set GPU to send interrupts to CPU? I would appreciate your comments. Thanks, - Shinpei Nouveau doesn't really make use of interrupts so you wont see them while running OpenGL. In general we make use of fences to signal when things of interest have occured. Is there something particular you're trying to accomplish or is this just a learning exercise? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium driver and compatibility issues
Am Freitag, den 12.03.2010, 22:25 +0200 schrieb Pekka Paalanen: On Fri, 12 Mar 2010 14:51:34 +0100 Uwe Bugla uwe.bu...@gmx.de wrote: Note, that the Nvidia proprietary driver. Lapse No. 3: Misleading usage of expressions. Everybody talking about the Nvidia proprietary driver in the graphic card context of Nvidia cards normallly means the blob driver shipped by Nvidia (closed source driver!) which does not have any problems with stuff like Compiz or other 3D applications. I do not like blob drivers for a whole bunch of reasons. As you are definitely using the wrong expression it remains your personal secret what you are trying to express or say. One of the most common reasons for problems with Nouveau are the remnants of the proprietary driver. Since you did not provide kernel log, X log, nor glxinfo output, I of course assumed the most probable case. A stale libglx from the blob kills OpenGL, for instance. Furthermore, you cannot have the Nvidia proprietary 3D driver running by default, and then use the Nouveau 3D driver on selected apps. If you use *any* part of Nouveau, you cannot have *any* part of the proprietary driver, and vice versa. They cannot live together at all. I'm sorry I guessed your problem wrong. There was no real information to begin the diagnosis with. Problems are expected on the OpenGL front. Lapse No. 4: I did not mention nearly all driver parts of the Gallium drivers carrying the GL in their names just by chance. I reflect while I am typing messages. I explicitly mentioned that the versions of the driver parts carrying the GL in their names are NOT responsible for the breakage that I reported. Thus it still remains your personal secret what you mean by OpenGL front. Actually, they are. Mesa libGL will try to load nouveau_dri.so to provide hardware accelerated 3D rendering. At this time OpenGL (via Mesa) is the only real user of nouveau_dri.so. nouveau_dri.so may be loaded by the X server (AIGLX) or the application (direct rendering) when they load libGL. In short, having nouveau_dri.so will break OpenGL and perhaps kill the X server in the AIGLX case. Lapse No. 6: Instead of repeating the core message of my request for 4 times in this mail (how insane!) I propose to change this page http://nouveau.freedesktop.org/wiki/GalliumHowto in the following way: 1. Wipe off the following stupid idiotic crap: Warning : Nouveau's developers don't want people to build gallium drivers now, and do not support it at all. They also don't want bug reports on gallium ATM. This is code in rapid development. Bug reports for this are useless, as it's known to be broken. That is rude on purpose. It is supposed to be crystal clear to everyone, that this is not yet for end users, but apparently it is not that clear. The time for end users will come, later. At that time the page will be rewritten to be polite. Right now it is just a cheatsheet for new developers. And once again: The error is not hidden in some library file containing the GL in its name, and the versioning of those GL files is also NOT the problem. It's the sources of the nouveau_dri.so file that do contain the bug. True. nouveau_dri.so misses complete features and contains bugs. I read your two first posts as nothing more than an elaborate Fix everything, please. That really is what people are actually doing on their free time. Trying to kick their butt can only make them ignorant or angry. Yup! Good vibes! a. I do not use parts of the Nvidia blob driver or the blob as whole. b. Up to now I always loaded nouveau_dri.so via AIGLX plus minimal xorg.conf plus nouveau kernel staging driver. c. I can send you some xorg.0.log if you may wish. What other log files could be useful please? d. In fact the xorg server did not crash even once. The only thing that is broken is the specific application (solitaire). There do exist apps that are not broken. That's it for now. If you need further info please tell me. Otherwise I will stay away from Gallium from now on. Cheers Uwe ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
xen-devel-boun...@lists.xensource.com wrote on 03/12/2010 07:45:57 AM: On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen p...@iki.fi wrote: *snip* Efficacy of patch: successful flightgear run on dom0 AND bareboot! Arvind R. If you boot your system up w/out a monitor plugged in, then plug one in, do you ever get signal? I've been playing with nouveau (just bare-metal up until now!) for a few weeks as well, and my biggest problem with it is that if you have a bunch of PCs on a cheap KVM, they all have to have the monitor/keyboard/mouse at boot or you never get any TTY or X logins... Maybe I'm just doing something wrong? -Mike --- Michael D Labriola Electric Boat mlabr...@gdeb.com 401-848-8871 (desk) 401-848-8513 (lab) 401-316-9844 (cell) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Interrupt setting
On Fri, Mar 12, 2010 at 8:45 PM, Shinpei KATO shin...@il.is.s.u-tokyo.ac.jp wrote: Dear Younes, Thank you for your reply. Nouveau doesn't really make use of interrupts so you wont see them while running OpenGL. In general we make use of fences to signal when things of interest have occured. Is there something particular you're trying to accomplish or is this just a learning exercise? I have been using Nouveau for a research purpose, though it has been just a month. So I can say both something particular and a learning exercise. I have tried understanding the behavir of fences, but a bit hard to catch up the execution flow. To my understanding, for instance every time pushbuf ioctl is called, you create a fence object. Does this make a caller process to wait for a completion of a GPU command? I inserted printk()s in nouveau_fence_wait(), but the process does not seem sleeping. I'm not the expert on these things so some of this may be incorrect. If so I hope someone will correct me... We create a fence for every pushbuf, so when that fence is signalled we know that every command in the pushbuf has completed. Each fence has a sequence number which is simply an integer. So after the first pushbuf we will emit a fence with sequence #0, then 1, and so on. As the GPU is processing pushbufs it will write the sequence # of each fence it encounters in a register. By reading this register we know which commands are completed. We use this mechanism when synchronization is required instead of interrupts. For example in the OpenGL driver if you issue a draw command referring to texture A that draw command will be in some pushbuf B. If you then attempt to write to texture A with the CPU immediately after, the OpenGL driver will check if texture A is referenced in a pending draw command and if so will flush the associated pushbuf, which results in a fence being emitted. The OpenGL driver will then attempt to map the texture. The kernel module will wait until that fence is signalled before allowing the OpenGL driver to map it so that synchronization is maintained, otherwise the CPU might alter the contents of the texture before the previous draw command was even seen by the GPU. I am also wondering if current GPUs can be set up to generate interrupts when GPU commands are done. My guess is that NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY is to generate interrupts when DMA transfers are done. Am I misunderstanding? There's another similar mechanism that the GPU supports, which is a notifier/semaphore. With this you can specify a memory location and a value and attach it to a specific command. The GPU will write the value to the memory location after that command completes and you can use the CPU to check it. You can also request that an interrupt be generated. This is independent of the pushbuf sequence numbering and is intended for more precise control. I don't know if we have any example code using a notifier that you can look at unfortunately, but it should be possible to generate an interrupt or write to a notifier after using M2MF to copy some memory like you said. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Interrupt setting
Dear Younes, I appreciate your VERY helpful explanation! Things are now more clear to me. Nouveau doesn't really make use of interrupts so you wont see them while running OpenGL. In general we make use of fences to signal when things of interest have occured. Is there something particular you're trying to accomplish or is this just a learning exercise? I have been using Nouveau for a research purpose, though it has been just a month. So I can say both something particular and a learning exercise. I have tried understanding the behavir of fences, but a bit hard to catch up the execution flow. To my understanding, for instance every time pushbuf ioctl is called, you create a fence object. Does this make a caller process to wait for a completion of a GPU command? I inserted printk()s in nouveau_fence_wait(), but the process does not seem sleeping. I'm not the expert on these things so some of this may be incorrect. If so I hope someone will correct me... We create a fence for every pushbuf, so when that fence is signalled we know that every command in the pushbuf has completed. Each fence has a sequence number which is simply an integer. So after the first pushbuf we will emit a fence with sequence #0, then 1, and so on. As the GPU is processing pushbufs it will write the sequence # of each fence it encounters in a register. By reading this register we know which commands are completed. So a GPU itself updates the sequence # of each fence in a specific register, and we can let the Nouveau driver wait for a target value to be written. Do you know when the value is actually written? If it is written when a DMA transfer is done, we dont know exactly when the corresponding GPU operation is finished. Do you think it is possible to wait for a completion of a GPU operation? We use this mechanism when synchronization is required instead of interrupts. For example in the OpenGL driver if you issue a draw command referring to texture A that draw command will be in some pushbuf B. If you then attempt to write to texture A with the CPU immediately after, the OpenGL driver will check if texture A is referenced in a pending draw command and if so will flush the associated pushbuf, which results in a fence being emitted. The OpenGL driver will then attempt to map the texture. The kernel module will wait until that fence is signalled before allowing the OpenGL driver to map it so that synchronization is maintained, otherwise the CPU might alter the contents of the texture before the previous draw command was even seen by the GPU. I see, so we need to explicitly call a synchronization function, something like nouveau_fence_wait(), to wait for a completion of a GPU command. I have been just checking default procedures with a single instance of an OpenGL app..., that is why I haven't seen a effect, but now I understand the way! I am also wondering if current GPUs can be set up to generate interrupts when GPU commands are done. My guess is that NV_MEMORY_TO_MEMORY_FORMAT_NOTIFY is to generate interrupts when DMA transfers are done. Am I misunderstanding? There's another similar mechanism that the GPU supports, which is a notifier/semaphore. With this you can specify a memory location and a value and attach it to a specific command. The GPU will write the value to the memory location after that command completes and you can use the CPU to check it. You can also request that an interrupt be generated. This is independent of the pushbuf sequence numbering and is intended for more precise control. I don't know if we have any example code using a notifier that you can look at unfortunately, but it should be possible to generate an interrupt or write to a notifier after using M2MF to copy some memory like you said. Fortunately, in an old version of Nouveau, I found a code in nouveau_fence_emit() that generates an interrupt with a notifier. I copied and tried it, and it worked! But, I am not sure if this is a notification for a completion of a GPU operation or a DMA transfer... Best, - Shinpei ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
