Re: [Nouveau] [PATCH 0/4] nvfx: rework render temps code and fixes
On Mon, Jan 16, 2012 at 11:33 AM, Lucas Stach wrote: > I seems Marek has just accidentally pushed the whole series. So we have > a bit of a difficult situation here. I'm not sure if we should just > revert or if we can leave the patches upstream. > > I'm aware that this patches haven't received much testing by others than > me and that a review of the code is still oustanding, but I like to > stress the point that these patches are rigorously tested by me and are > relatively low risk. > > Patrice your report of this patchset not working did surprise me, so can > you please make sure those patches are really the cause for your issues? > I heard reports that nv3x is not working properly with mesa/master for > some time. I tried to reproduce the problem on my nv49 setup and I don't > see any issues besides the well known vertex corruption, which is most > likely due to some missing reloc somewhere or the like. > > Regards, > Lucas > This should not have been pushed without at least having been tried on nv30. You can test every application on earth if you want, but there are nv30 code paths/limits/behaviours both in userspace and kernel that you'll never hit running on an nv40, so rigorous testing is irrelevant in that regard. Of course the userbase for these cards is dwindling anyway so it's not a big deal as long as it can be fixed before it gets released. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau driver is not loading
On Thu, Dec 1, 2011 at 2:54 PM, Lars Callenbach wrote: > Thank you for your answer. I have restartet the computer and have not loaded > nvidiafb. This is the output for the latest git-nouveau kernel module (error > code -12): > --- > [ 6.971517] [drm] Initialized drm 1.1.0 20060810 > [ 7.037917] [drm] nouveau :06:00.0: Detected an NV40 generation card > (0x043000a4) > [ 7.073400] [drm] nouveau :06:00.0: 0 MiB GART (aperture) That's strange... > [ 7.170138] [drm] nouveau :06:00.0: ntfy -12 > [ 7.170288] [drm] nouveau :06:00.0: 0xD642: Parsing digital output > script table > [ 7.220570] [drm] nouveau :06:00.0: Restoring VGA fonts > [ 7.221181] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.221584] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.221980] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.222372] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.222760] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.223127] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.223516] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.223905] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.224310] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.224707] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.225097] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.225486] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.225875] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.226263] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.226656] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.227048] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.227445] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.227842] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.228253] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 > [ 7.228625] [drm] nouveau :06:00.0: PMC - unhandled INTR 0x0100 This is also strange... > [ 7.232989] [drm:drm_sysfs_connector_remove], removing "VGA-1" from sysfs > [ 7.233027] [drm:drm_sysfs_connector_remove], removing "DVI-I-1" from sysfs > [ 7.233054] [drm:drm_sysfs_connector_remove], removing "TV-1" from sysfs > [ 7.233099] [drm:drm_irq_uninstall], irq=16 > [ 7.233118] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. > Delaying takedown > [ 7.233260] [drm:drm_mm_takedown] *ERROR* Memory manager not clean. > Delaying takedown > [ 7.233401] [TTM] Finalizing pool allocator. > [ 7.233437] [TTM] Zone kernel: Used memory at exit: 0 kiB. > [ 7.235221] [drm:drm_put_minor], release secondary minor 0 > [ 7.235330] [drm:drm_put_minor], release secondary minor 64 > [ 7.235507] nouveau :06:00.0: PCI INT A disabled > [ 7.235529] nouveau: probe of :06:00.0 failed with error -12 Not sure what's going on with your card. Is this a regression? Did nouveau ever work for you? Does Nvidia's official driver work? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau driver is not loading
On Tue, Nov 29, 2011 at 4:04 PM, Lars Callenbach wrote: > Hello, > > I have installed git-kernel (3.2-rc3) with git-drm libs on debian. nvidiafb > on terminals works fine, but loading of nouveau for Xorg fails. Maybe someone > can help me or give me hints (what do I have to change?). The kernel produces > the attached output. > > Best regards, > Lars Callenbach You can't use nvidiafb and nouveau at the same time. Get rid of nvidiafb, nouveau can provide a framebuffer console on it's own. The wiki should have this info in the installation section. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH to drm/nouveau] nouveau: Mark nouveau subchannel unbound nouveau_grobj_free
On Thu, Nov 24, 2011 at 8:08 AM, Maarten Lankhorst wrote: > Valgrind throws warns about a user-after-free if you try to bind a > new subchannel after the old one in that slot was freed, > so remove it from the channel list. > > Signed-off-by: Maarten Lankhorst > > --- a/nouveau/nouveau_grobj.c > +++ b/nouveau/nouveau_grobj.c > @@ -100,12 +99,13 @@ nouveau_grobj_free(struct nouveau_grobj **grobj) > struct drm_nouveau_gpuobj_free f; > > FIRE_RING(&chan->base); > - > f.channel = chan->drm.channel; > f.handle = nvgrobj->base.handle; > drmCommandWrite(nvdev->fd, DRM_NOUVEAU_GPUOBJ_FREE, > &f, sizeof(f)); > } > + if (nvgrobj->base.bound != NOUVEAU_GROBJ_UNBOUND) > + chan->base.subc[nvgrobj->base.subc].gr = NULL; > free(nvgrobj); > } > > > > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau > Pushed, thanks. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau on Linux/sparc64 -- almost!
On Wed, Nov 23, 2011 at 11:23 AM, Patrick Baggett wrote: > >> Are unaligned accesses actually errors on Sparc or just trapped and >> emulated and therefore slow? > > I'm not 100% sure. Architecturally, they are errors on SPARC. Userspace > applications that do unaligned accesses are sent SIGBUS and usually killed. > For a driver, I would imagine that the kernel would catch this trap and > emulate or ignore it rather than go down in a blaze of glory. It should > generally be treated as an error, and every time I've seen the C code that > does it, it is usually straight forward to fix it. > If you want to fix it the kernel log I guess tells you roughly where to look: [ 37.891494] Kernel unaligned access at TPC[102148ac] nouveau_bios_init+0x89c/0x29c0 [nouveau] [ 37.891667] Kernel unaligned access at TPC[102148f0] nouveau_bios_init+0x8e0/0x29c0 [nouveau] [ 37.891833] Kernel unaligned access at TPC[1020a434] parse_script_table_pointers+0x4/0xec [nouveau] [ 37.891999] Kernel unaligned access at TPC[1020a458] parse_script_table_pointers+0x28/0xec [nouveau] [ 37.892187] Kernel unaligned access at TPC[1020a478] parse_script_table_pointers+0x48/0xec [nouveau] You'll have to take inlining into consideration though, since nouveau_bios_init for example doesn't actually read the BIOS but has calls to other functions that do that have been inlined. From briefly looking at this code the problem appears to be with reading 16 (and maybe 32) bit values in the BIOS image at various unaligned offsets, so you can use the get_unaligned() macro where necessary. >> >> If you can start X, does that mean fbcon >> works? > > I don't really know a whole lot about fbcon in general. I know that I > definitely get fbcon on the ATI chip (fb0), but I haven't really researched > how to get a console going on the NVidia one. I'd be happy to try it and > report results if you give me a bit of direction. > Patrick What I mean is, does KMS kick in? From your log that appears to be the case, and since you can start X I'm assuming the console renders correctly and you see what you're typing. You should look at the kernel log *after* you start X (the snippet you provided is very limited and is from before you started X). ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau on Linux/sparc64 -- almost!
On Tue, Nov 22, 2011 at 8:10 PM, Patrick Baggett wrote: > Hey all, > > First off, I'd like to say many thanks to the nouveau developers! > > I've got a Sun Ultra 10 running Debian 6 (testing branch) with an onboard > ATI card and a PCI GeForceMX 4000. So far X works fine on the ATI card, but > I noticed that the DRM driver for the GF4 has a few unaligned accesses in it > (see log). I can actually start X using that card, but all I get is a black > screen -- though the cursor works and I can move it around! It seems like it > is very close to working. Unfortunately, I can't seem kill X in a way that > preserves the graphical output of either the gfx chip. > > Any ideas where to begin hacking at this problem? Any suggestions or known > issues on RISC systems? I have an x86 box running Debian 6 with a Geforce4 > MX (AGP) as well, so hopefully I can test fixes that will work on both x86 > and sparc64. Are unaligned accesses actually errors on Sparc or just trapped and emulated and therefore slow? If you can start X, does that mean fbcon works? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau: Keep RAMIN heap within the channel.
The entire RAMIN is allocated to be 'size', but the heap is
specified as 'base' + 'size' inside RAMIN, so it will overflow
past RAMIN by 'base' bytes on NV50+ and clobber other allocatons
unless it's size is adjusted.
Signed-off-by: Younes Manton
---
drivers/gpu/drm/nouveau/nouveau_object.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_object.c
b/drivers/gpu/drm/nouveau/nouveau_object.c
index 0c5..960c0ae 100644
--- a/drivers/gpu/drm/nouveau/nouveau_object.c
+++ b/drivers/gpu/drm/nouveau/nouveau_object.c
@@ -680,7 +680,7 @@ nouveau_gpuobj_channel_init_pramin(struct nouveau_channel
*chan)
return ret;
}
- ret = drm_mm_init(&chan->ramin_heap, base, size);
+ ret = drm_mm_init(&chan->ramin_heap, base, size - base);
if (ret) {
NV_ERROR(dev, "Error creating PRAMIN heap: %d\n", ret);
nouveau_gpuobj_ref(NULL, &chan->ramin);
--
1.7.7.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] xrandr or xorg.conf... help with virtual size desktop
On Thu, Oct 13, 2011 at 9:57 AM, Harry Putnam wrote: > I've come at this a few different ways on this list and others. But not > really getting a solution. Possibly there is none until some changes > are made upstream. > > Setup: Debian Wheezy (testing) 3.0.0-1-686-pae > Video card: Nvidia XF 5700LE > Older P4 intel cpu 3.06 (single core) > (Using Nouveau driver) > > My aim is to create a large pannable desktop either with use of > xorg.conf or xrandr. > > In the past, on a Gentoo linux OS using the same hardware: > (Cpu and video card the same as now and shown above in `Setup') > > It worked to have this in xorg.conf inside a screen subsection. > > [...] > Subsection "Display" > Depth 24 > Modes "1280x1024" #"1024x768" "800x600" "640x480" > Virtual 2048 1536 > ViewPort 0 0 > EndSubsection > [...] > > Note the `Virtual' line. > > The end result was a pannable desktop at size 2048x1536 > > I haven't been able to figure out how to get that to work in a current > xorg.conf created by: `Xorg -configure' (in console mode). > > I have inlined an attempted xorg.conf, that seems to work so far as X > being usable but fails to provide the virtual size. > (the xorg.conf is inlined following Xorg.0.log) > > --- - ---=--- - > > So I turned to xrandr, hoping to set something similar. > > And I believe xrandr commands such as: > > xrandr --output DVI-I-1 --mode 1440x900 \ > --fb 1440x900 --panning 1680x105 > > or even the full previously available size: > > xrandr --output DVI-I-1 --mode 1440x900 \ > --fb 2048x1536 --panning 2048x1536 > > Do set the size. > > Either of those appears to set the larger virtual size as I see an > image I use as background grow very noticably... and a panel set at > the bottom of my screen is pushed down out of site. > > All well and good, except the mouse cannot pan into the newly created > space and is still confined to the visible borders. > > It appears to be because of this bug: > https://bugs.freedesktop.org/show_bug.cgi?id=39994 > reported 2011-08-08 > > Reading the comments, there have been a few patches submitted but > apparently no actions taken as yet. > > Can any of you help me figure out how to get a large panning desktop? > Is anyone here using or able to set a large panning desktop? > > I've inlined both a fresh Xorg.0.log and the current xorg.conf. > (NOTE: xorg.conf was NOT in use when Xorg.0.log was created) > --- - ---=--- - > --- - ---=--- - > This Xorg.0.log created following a reboot, and with no xorg.conf > The bug you're talking about is actually https://bugs.freedesktop.org/show_bug.cgi?id=39949 for those interested. I don't spend much time with the xserver or DDX code so I might be wrong, but panning is as far as I know largely handled by the server and is not something the driver has much control over. You'll have to wait until this is fixed there or perhaps you can downgrade your server to 1.10 until it's fixed. I don't think there's anything that can be done in nouveau to work around it. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Does Nouveau support for vdpau?
On Sun, Sep 25, 2011 at 5:37 AM, James Courtier-Dutton wrote: > Hi, > > Does nouveau support vdpau? > If not, how far is it away from some type of HD Video output accel ? > Use-case: Zotac mini PC with ION chipset and HDMI output running mythtv. > This setup works very nicely with the nvidia driver and vdpau. I am > just wondering about nouveau support. > > Kind Regards Simple answer is no it doesn't. It will probably be quite a while away, video decoding on that particular chip and most others requires quite a bit of microcode. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Mistake in Gallium how-to in wiki?
On Mon, Jul 18, 2011 at 4:42 PM, Andrew Green wrote: > Hi, > > I think I've found a mistake in the Gallium instructions in the Nouveau wiki > (http://nouveau.freedesktop.org/wiki/GalliumHowto). > > According to that page, one should run ./configure like this: > > ./configure --enable-debug --enable-glx-tls --disable-asm \ > --with-dri-drivers= --enable-gallium-nouveau \ > --disable-gallium-i915 --disable-gallium-i965 \ > --disable-gallium-r300 --disable-gallium-r600 --disable-gallium-svga \ > --with-state-trackers=glx,dri > > > But when I compiled using that configuration, nouveau_dri.so was not built. > Also, a few of the configuration options were not recognized. However, this > configure command did work, at least for me: > > ./configure --enable-debug --enable-glx-tls --disable-asm \ > --with-dri-drivers --enable-glx --enable-dri --enable-xorg \ > --with-state-trackers=glx,dri --with-gallium-drivers="nouveau > > > Hope this is helpful. (I'm completely "new" to "nouveau", so I guess I may > be completely off.) Thanks to the developers for their work on this, > greetings, > Andrew The config options changed not too long ago and the wiki hasn't been updated. Feel free to update it if you have an account. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] drm/nouveau: Calculate reserved VRAM for PRAMIN value before use.
'drm/nouveau: rework vram init/fini ordering a little' changed the order of instmem.init() and nouveau_mem_vram_init() which resulted in using ramin_rsvd_vram before it was calculated and failing to init any accel on pre-NV50 cards. Since it's only used on 0001-drm-nouveau-Calculate-reserved-VRAM-for-PRAMIN-value.patch Description: Binary data ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Can't "make" nouveau
On Sat, Jun 4, 2011 at 1:04 PM, Mariane wrote: > Hi everyone, > > I'm not used to beta programs and it's the first time I try to compile a > driver, so please excuse me if I ask silly questions. I have Ubuntu 10.10, > KDE desktop, and my nvidia card GeForce 9300 H GS seems impossible to > configure for 2 monitors with the current driver. xrandr commands fail. > > I was following the instructions here: > http://nouveau.freedesktop.org/wiki/InstallNouveau > > What I did was: > > sudo apt-get install xserver-xorg-video-nouveau-dbg > lsmod > check if there are nvidia drivers listed? no > sudo modprobe nouveau > lsmod > Now I can see nouveau drivers listed > git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/ > cd xf86-video-nouveau/ > ./autogen.sh > Problem and Solution (found on the wiki): > sudo apt-get install xorg-dev > ./autogen.sh > Problem: > No package 'libdrm_nouveau' found > Solution1: I see there is a package called libdrm-nouveau1 so I replace: > #PKG_CHECK_MODULES(LIBDRM_NOUVEAU, libdrm_nouveau) > by > PKG_CHECK_MODULES(LIBDRM_NOUVEAU, libdrm-nouveau1) > It does not solve the problem. > > Solution2: in configure.ac I comment out: > # Checks for pkg-config packages > #PKG_CHECK_MODULES(LIBDRM_NOUVEAU, libdrm_nouveau) > #PKG_CHECK_MODULES(LIBDRM_NOUVEAU, libdrm-nouveau1) > #AC_SUBST(LIBDRM_NOUVEAU_CFLAGS) > #AC_SUBST(LIBDRM_NOUVEAU_LIBS) > > #PKG_CHECK_MODULES(XORG, [xorg-server >= 1.8] xproto fontsproto libdrm > xf86driproto $REQUIRED_MODULES) > #PKG_CHECK_MODULES(XEXT, [xextproto >= 7.0.99.1], > # HAVE_XEXTPROTO_71="yes"; AC_DEFINE(HAVE_XEXTPROTO_71, 1, > [xextproto > 7.1 available]), > # HAVE_XEXTPROTO_71="no") > #AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test "$HAVE_XEXTPROTO_71" = "yes" ]) > #sdkdir=$(pkg-config --variable=sdkdir xorg-server) > This time autogen.sh finishes. > > make > Making all in src > make[2]: Entering directory `/home/alan/xf86-video-nouveau/src' > CC nouveau_exa.lo > gcc: @XORG_CFLAGS@: No such file or directory > gcc: @LIBDRM_NOUVEAU_CFLAGS@: No such file or directory > In file included from nv_include.h:5, > from nouveau_exa.c:23: > ../config.h:4: fatal error: xorg-server.h: No such file or directory > compilation terminated. > make[2]: *** [nouveau_exa.lo] Error 1 > make[2]: Leaving directory `/home/alan/xf86-video-nouveau/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/alan/xf86-video-nouveau' > make: *** [all] Error 2 > > Solution: > sudo apt-get install xserver-xorg-dev > xserver-xorg-dev is already the newest version. > So this solution fails > > What should I do next, please? You can't simply comment out the dependency checks if they fail, you need to actually have the correct software installed. Anyhow, if you're having trouble with mode setting I don't think installing a newer xf86-video-nouveau will help, you should likely try a newer nouveau kernel module, since that's where the mode setting mostly is done. Alternatively, you can try to figure out why xrandr fails. What was the error message? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] one desktop on four monitors ?
On Mon, Oct 25, 2010 at 9:44 PM, DJ Delorie wrote: > > Grrr. Can the nouveau driver grab two cards at a time and tell the X > server it's one card? No. It would be pretty tricky to do, especially with different chip versions and generations, but even with identical cards it's probably a fair bit of effort that would be better spent on proper X server support. X server internals aren't really my area of interest so I can't tell you much more. > Does nouveau support any cards that can drive four monitors with one > card, with at least one monitor at 2560x1600 ? Would that get me what > I want? > Current Nvidia cards that support 4 heads are actually dual-GPUs on a single card, so the problem is largely the same. Sorry to be the bearer of bad news. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] one desktop on four monitors ?
On Sun, Oct 24, 2010 at 10:11 PM, DJ Delorie wrote: > >> > While I'd prefer to use xrandr for these monitors, I've read that it's >> > just not supported yet (sigh). >> >> Most of whats needed to get this working in a RandR based driver is >> just not implemented in the server yet. > > What about *without* RandR ? I can get it to bring up all four > monitors sort-of, I'm OK with Xinerama for now, I just want something > that works... > Nouveau doesn't support anything other than RandR. Most of the server's old Xinerama code is also long gone, but clients can still use the Xinerama extension and RandR will provide the screen geometry info. However, without the proper server-side support for multiple cards driving a single desktop all Xinerama is good for on RandR based drivers is supporting multiple monitors on a *single* card for old clients that only support Xinerama for screen geometry instead of RandR. Any other configuration is likely broken. I don't think anyone is working on multiple cards driving a single desktop so unfortunately your #1 setup is the best you can do on 2 cards for the foreseeable future. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] one desktop on four monitors ?
On Sun, Oct 24, 2010 at 12:26 AM, DJ Delorie wrote: > > I've been trying for a while to get my setup to work with nouveau. > I'm currently using the nvidia blob with Fedora 12 with success, but > certain types of X operations kill performance. > > I have two Nvidia 9800 GT video cards, each driving two monitors. > > Card 0 > Monitor 0 = Dell 3008FP 2560x1600, in the middle of the cluster > Monitor 1 = Dell 2001FP 1600x1200, above the middle > Card 1 > Monitor 0 = Dell 2001FP 1600x1200, left of middle, rotated right > Monitor 1 = Dell 2001FP 1600x1200, right of middle, rotated right > > So far, with Fedora 14 beta, I can do one of two things: > > 1. Each card is a separate randr display pair (i.e. two virtual > monitors, two desktops) > > 2. Monitor 0 of each card is a xinerama pair, and each Monitor 1 is a > clone of its Monitor 0. > > While I'd prefer to use xrandr for these monitors, I've read that it's > just not supported yet (sigh). At this point, I'd be happy if > xinerama worked! Even if it only gave comparable performance to the > binary blob, it would make updating Fedora much easier. > > Has *anyone* gotten a single desktop on >1 cards and >2 monitors yet? > > DJ Most of whats needed to get this working in a RandR based driver is just not implemented in the server yet. All of the RandR drivers are basically in the same boat, not just Nouveau. Nvidia's RandR support is basically a wrapper around their NVCONTROL extension if I recall correctly, so they can still support it. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau and multiple video cards
On Sun, Sep 19, 2010 at 6:48 PM, Felix Blanke wrote: > Hi, > > I hope it is ok if I would ask one last question: > > It is possible to use a quadro NVS 450 with 3 monitors via DVI and nouveau? > > > The status matrix is kind of old (e.g. it says that dual link dvi is WIP, it > works > for me good :)) and I dont find that quado NVS 450 on it. > > > Thanks again! If the card can actually drive 3 monitors at once with the nvidia driver then it should work in nouveau now or can be implemented with some reversing. Maybe someone who knows more about mode setting can give you a definitive answer. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau and multiple video cards
On Sat, Sep 18, 2010 at 12:41 PM, Felix Blanke wrote: > Thanks for your reply! > > Do you know if that will be possible in the near future? > Do you know any other way how to do that? > > Regards, > Felix > > On Sep 18, 2010 6:36 PM, "Younes Manton" wrote: > > On Sat, Sep 18, 2010 at 12:01 PM, Felix Blanke > wrote: >> Hi, >> >> is it possib... > > Currently not possible with nouveau. This is partially a limitation of > the X server, not just nouveau. > I don't think it will be possible in the near future, there is a fair bit of work involved and no one is actively pursuing it as far as I know. Maybe nvidia's driver can do this for you now. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nouveau and multiple video cards
On Sat, Sep 18, 2010 at 12:01 PM, Felix Blanke wrote: > Hi, > > is it possible to setup one virtual screen with 2 video cards and 3 monitors? > > > My setup looks like this: > > 01:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7300 > SE/7200 GS] > (rev a1) > 02:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce 8600 GT] > (rev a1) > > > 02:00.0 is my primary video card with two monitors connected. 01:00.0 has one > monitor > connected. > > xrandr only shows me 2 outputs :/ > > scooter ~ # xrandr -q > Screen 0: minimum 320 x 200, current 3760 x 1600, maximum 8192 x 8192 > DVI-I-2 connected 2560x1600+0+0 (normal left inverted right x axis y axis) > 641mm x > 400mm > 2560x1600 59.9*+ > 1280x800 59.9 > DVI-I-3 connected 1200x1600+2560+0 right (normal left inverted right x axis y > axis) 408mm x 306mm > 1600x1200 60.0*+ > 1280x1024 85.0 75.0 60.0 > 1280x960 60.0 > 1152x864 75.0 > 1024x768 85.0 75.1 70.1 60.0 > 832x624 74.6 > 800x600 85.1 75.0 60.3 > 640x480 85.0 75.0 60.0 > 720x400 70.1 > > > Is there something special I have to do or is it not possible to use such a > setup > with nouveau? > > > Thanks for your help! Currently not possible with nouveau. This is partially a limitation of the X server, not just nouveau. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nouveau driver fails
2010/9/4 Piotr Hosowicz : > On 04.09.2010 15:34, Calvin Walton wrote: >> >> On Fri, 2010-09-03 at 13:28 +0200, Piotr Hosowicz wrote: >>> >>> Hello, >>> >>> Nouveau driver seems to fail. Please find attached Xorg.0.log, lspci and >>> kernel config. My card is 01:00.0 VGA compatible controller: nVidia >>> Corporation G96 [GeForce 9400 GT] (rev a1). Tried with today's Linux >>> Next. >> >> You might get better results asking the nouveau developers directly - >> I've added the nouveau mailing list to the CC. >> >> (http://www.spinics.net/lists/kernel/msg1079386.html has the attachments >> archived.) > > Calvin did not send dmesg output, here it is. > > Regards, > > Piotr Hosowicz How are you connected to the monitor? DVI, VGA? Something is a little off with the connectors I think. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Optimus and Nvidia
(Use reply-all if you want people on the list to see your emails, your last two were only to me.) Google "nvidia optimus linux" and you'll find some info on the matter. The Nvidia driver does not support Optimus. As far as I know this means that it will not work with the 330M in an Optimus chipset because the 330M is hooked up to the Intel chip, it doesn't matter that the Nvidia driver supports regular 330Ms, this is not a regular 330M. Nouveau doesn't support it either until someone figures out how it works. As far as the Intel chip is concerned I don't know if the Intel driver will support it and just ignore the Optimus-related stuff. Maybe you should ask that on the Intel list. What the sales guy told you about turning it off doesn't matter. On Thu, Aug 5, 2010 at 11:24 PM, Jason Long wrote: > The NVIDIA GeForce GT 330M is supported by the propriety driver, but I do > not know how is will work with the integrated Intel. > > On Thu, Aug 5, 2010 at 10:22 PM, Jason Long > wrote: >> >> It is a http://www.pctorque.com/sager-5125-gaming-computers.php >> with NVIDIA GeForce GT 330M with integrated Intel 4500 GMA. >> I am not really concerned about if Optimus works. I am mainly concerned >> about using the latest Fedora release. I do not even care if I have to use >> either the Intel of Nvidia card. I just want 1080p under Linux. >> Does anyone know what the options are? The sales guys said there was a >> switch to turn Optimus off. >> On Thu, Aug 5, 2010 at 10:08 PM, Younes Manton wrote: >>> >>> On Thu, Aug 5, 2010 at 4:38 PM, Jason Long >>> wrote: >>> > I need to buy a Sager 5125 laptop immediately and I am concerned about >>> > the >>> > Optimus setup in this model. >>> > It comes with a Nvidia 330M/Intel Hybrid. >>> > I want to use this with Fedora 13. I do not care if I can switch. I >>> > just >>> > want it to work. I can also deal with only the onboard graphics >>> > working in >>> > linux. >>> > Do you think the HDMI output will work or I will need the 330M driver >>> > for >>> > that? >>> > I see nvidia has support for the 330M in their driver? Will this work? >>> > ___ >>> > Nouveau mailing list >>> > Nouveau@lists.freedesktop.org >>> > http://lists.freedesktop.org/mailman/listinfo/nouveau >>> >>> >>> Last I heard I don't think Nvidia will support Optimus on Linux with >>> their driver. As far as Nouveau and DRM playing nice with Optimus I >>> think Dave Airlie had some interest in that but no access to hardware? >>> I don't remember the details myself, maybe someone else can tell you >>> more. >> > > ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Optimus and Nvidia
On Thu, Aug 5, 2010 at 4:38 PM, Jason Long wrote: > I need to buy a Sager 5125 laptop immediately and I am concerned about the > Optimus setup in this model. > It comes with a Nvidia 330M/Intel Hybrid. > I want to use this with Fedora 13. I do not care if I can switch. I just > want it to work. I can also deal with only the onboard graphics working in > linux. > Do you think the HDMI output will work or I will need the 330M driver for > that? > I see nvidia has support for the 330M in their driver? Will this work? > ___ > Nouveau mailing list > Nouveau@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau Last I heard I don't think Nvidia will support Optimus on Linux with their driver. As far as Nouveau and DRM playing nice with Optimus I think Dave Airlie had some interest in that but no access to hardware? I don't remember the details myself, maybe someone else can tell you more. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [Bug 29386] New: 2D performance drops drastically when enabling a 2nd monitor
On Tue, Aug 3, 2010 at 1:37 PM, wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=29386 > > Summary: 2D performance drops drastically when enabling a 2nd > monitor > Product: xorg > Version: git > Platform: x86 (IA32) > OS/Version: Linux (All) > Status: NEW > Severity: normal > Priority: medium > Component: Driver/nouveau > AssignedTo: nouveau@lists.freedesktop.org > ReportedBy: malsa...@gmail.com > QAContact: xorg-t...@lists.x.org > > > Created an attachment (id=37547) > --> (https://bugs.freedesktop.org/attachment.cgi?id=37547) > Xorg.0.log > > I have two 1280x1024 identical monitor and nv18 MX 440 older nvidia card. The > card has one VGA-1 and one DVI-I outputs. The operating system is Fedora 13 > and > xorg-x11-server-Xorg-1.8.2-2.fc13.i686 > xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.i686 > ___ > $ lspci -vnn | grep nVidia > VGA compatible controller [0300]: nVidia Corporation NV18 [GeForce4 MX 440 AGP > 8x] [10de:0181] (rev a2) (prog-if 00 [VGA controller]) > ___ > $ xrandr -q > Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096 > VGA-1 connected (normal left inverted right x axis y axis) > 1280x1024 60.0 + 75.0 > 1280x960 60.0 > 1152x864 75.0 > 1024x768 85.0 75.1 70.1 60.0 > 832x624 74.6 > 800x600 85.1 72.2 75.0 60.3 56.2 > 640x480 85.0 72.8 75.0 66.7 60.0 > 720x400 70.1 > DVI-I-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) > 376mm x 301mm > 1280x1024 60.0*+ 75.0 > 1280x960 60.0 > 1152x864 75.0 > 1024x768 85.0 75.1 70.1 60.0 > 832x624 74.6 > 800x600 85.1 72.2 75.0 60.3 56.2 > 640x480 85.0 72.8 75.0 66.7 60.0 > 720x400 70.1 > TV-1 disconnected (normal left inverted right x axis y axis) > _ > > If I enable the VGA-1 at auto resolution, the 2D performance drops so bad that > when I raise a window, I see it gets painted on the screen for a couple of > seconds. browser scrolling is so slow and all gui apps as well. Desktop > effects > are disabled. > The commands I use are: > > $ xrandr --screen 0 --output VGA-1 --auto > $ xrandr --screen 0 --output VGA-1 --left-of DVI-I-1 > > > Direct rendering is enabled according to glxinfo > ___ > $ glxinfo | grep -i render > direct rendering: Yes > OpenGL renderer string: Mesa DRI nv18 20091015 > ___ > > If I clone the monitors, however, performance is not dropped. I also tried > lowering the resolutions of the monitors until performance did not drop when I > reached the 1024x768 resolution for each screen. > > So it is probably the buffer size needed to accommodate the two outputs in one > big screen of size. > > I know this is an older card, but I also know it can handle two screens > because > I have used it with FC12 and under with nVidia drivers with no performance > problems. > > -- You're probably hitting fallbacks due to hardware limits. IIRC that card's 3D engine has a 2k*2k limit for textures and two 1280x1024 screens side by side is well over 2k width. The nvidia driver 'works' because they probably use the 2D engine instead of the 3D engine to do X rendering and maybe break up their rendering into chunks if that card's 2D engine has similar limits. Nouveau uses the 3D engine even for 2D in order to support Xrender. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Dual Head: 2nd monitor "Out of Range"
On Tue, Jun 22, 2010 at 2:45 PM, Elijah Smith wrote: > Having issues with Nouveau in Ubuntu 10.4. I posted on the forums, but the > only help I have gotten had been people telling me to install the Blob > (which is a P.O.S. in my opinion), so I have decided to ask the experts. > Prior to my HDD failing, I was running Ubuntu 9.10 with Nouveau installed > from the Edgers PPA without any issues. When I replaced the HDD, I went > ahead and did a clean install of 10.4 and was delighted to find Nouveau as > the default driver... yay! The only problem is that I seem to have an issue > with dual heads. I have a pretty new computer (as of January) with a 1GB > Nvidia card that worked nicely with my previous Nouveau installation, so I > know it should work with my setup. I can get the laptop screen running at > its native 1600x900 without issue. I can set the external monitor to its > native 1920x1200, but the monitor only displays "Out of Range" when I do > that. In the Desktop Switcher, it appears as if it recognizes the 2nd > monitor and I can move window onto it, but the monitor just does not display > an image. The highest resolutions I can set the external monitor to and > still get an image are 1440x900 or a strange 1280x1024. Not sure what's > wrong here, but I would really like to see my external monitor at its native > resolution. > Thoughts? I know my way around the GUI pretty well, but I am mostly limited > to copy and paste in command line. If you give me some command line to > input, I can reply with the output. Is there something I should try? Any > help would be greatly appreciated. > Thanks in advance. > -Eli > > -- > Eli Smith > 540-808-8268 > durableinnovati...@gmail.com Your xorg.conf, Xorg log, and kernel log are a good place to look. Can you reboot the machine and try to set the 2nd monitor to it's native res? Once you do that you can grab your kernel log by doing the following in a terminal: dmesg >kernel.log which will result in a file called kernel.log in your home dir. After that attach kernel.log, /var/log/Xorg.0.log, and /etc/X11/xorg.conf in your reply. You may not have /etc/X11/xorg.conf, which is ok. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Lots of bugs in xubuntu lucid
On Tue, Jun 15, 2010 at 4:38 PM, Alexandr Revin wrote: > Hello guys, > i've decided to test nouveau driver and installed it recently from > official repos. My videocard is GeForce 4 with additional S-video and > Composite outputs, 64 MB of memory. I installed xubuntu, and tried to > use nouveau driver instead of official nvidia's. After switching driver, > the boot splash xubuntu logo turned into poor coloured low-resolutioned > one, but X loaded normally. Xfce worked fine, but i decided to try LXDE > with SLiM login manager. > > So, here's bugs: > > 1) X server is loading normally, but when i try to switch to virtual > terminal (Ctrl-Fx) my monitor shows me "Out of range" message, keyboard > and mouse are switching off too and it makes me to reboot pc to get > back. > > 2) When i trying to boot into kernel single mode, my root console does > not show the characters i typing, but generally it works, with the need > of double-entered confirmation. > > 3) Corrupted colors! Especially black - i see a set of random sized huge > gray pixels instead of solid black area. Other colors are suffering too, > see http://imagebin.ca/view/ay3nrec.html. > > > $uname -a > Linux lynn 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 > i686 GNU/Linux > > > $glxinfo > $ glxinfo > name of display: :0.0 > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > Error: couldn't find RGB GLX visual or fbconfig > > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > Xlib: extension "GLX" missing on display ":0.0". > 2 GLXFBConfigs: > visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > -- > Segmentation fault Try without the monitor section in your xorg.conf. The driver should be able to get you to the preferred mode of your monitor without much help from your xorg.conf if the monitor has an accurate EDID. Re glxinfo, you have bits of the Nvidia driver still installed: (II) Loading /usr/lib/xorg/extra-modules/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension Re colors, I don't know about that one. Gamma or overlay related maybe? Are colors washed out everywhere or just mplayer? If it's just mplayer can you try a different output mode? (Something like -vo x11 on the command line.) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Need help getting nouveau drivers working on Fedora 13
On Fri, Jun 11, 2010 at 8:27 PM, Joe Zeff wrote: > On 06/11/2010 05:10 PM, Younes Manton wrote: >> >> Hi. When you say you reinstalled Xorg without mesa packages, I'm >> assuming you mean that you didn't install the nouveau mesa driver? If >> so it sounds like you're trying to run compiz with the software >> rasterizer. Not sure if/how that works, last I heard it didn't. Either >> way, can you try without compiz? If you still have problems please >> attach a kernel log (the output of dmesg) and an Xorg log. > > I did try installing the mesa experimental drivers, but they just gave me a > broken screen that wasn't usable. What packages should I install? Also, > how do I deactivate compiz? > That depends on your desktop environment. On Gnome it's something like System -> Preferences -> Appearance -> Visual Effects. On Fri, Jun 11, 2010 at 8:31 PM, Joe Zeff wrote: > On 06/11/2010 05:10 PM, Younes Manton wrote: >> >> Hi. When you say you reinstalled Xorg without mesa packages, I'm >> assuming you mean that you didn't install the nouveau mesa driver? > > A little update: checking, I have mesa-dri-drivers.i686 installed,but not > the experimental. > I don't use Fedora but I think that means you don't have the nouveau mesa drivers. I suggest you disable compiz first anyway. If it works at least you know the non-mesa part of the driver works. If it doesn't work it will be easier to debug if the mesa driver is out of the picture. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Need help getting nouveau drivers working on Fedora 13
On Fri, Jun 11, 2010 at 6:47 PM, Joe Zeff wrote: > My desktop computer uses a GeForce FX 5200 card and, when I was using Fedora > 11, the kmod-nvidia drivers (a Fedora-specific repackaging of the binary > blob) worked Just Fine. Now, even though I've followed all of the > instructions for them, they don't. In fact, my system won't even complete > booting if they're active. (I'm posting from a laptop, while I'm trying to > get my desktop up again.) I've removed all of the nvidia packages and > reinstalled Xorg; no mesa packages installed. When I try to log in under X, > I can see the desktop, briefly, long enough to see that my screenlets are > loading in the wrong place, then, it's the infamous White Screen Of Death. > The desktop doesn't just turn white, it's more like a curtain being drawn > down over it, that never comes back up. Going to an alternate console and > checking .xsession-errors, the last message that I can understand is from > compiz, saying that it can't find some 8 bit pixmaps. > > I'd greatly appreciate any pointers as to what I need to do, other than > replace the video card (Not a pleasant option, because I've no reason to > believe that it's gone bad.) to get my desktop back under control. If > there's any other info that you need, just ask. Hi. When you say you reinstalled Xorg without mesa packages, I'm assuming you mean that you didn't install the nouveau mesa driver? If so it sounds like you're trying to run compiz with the software rasterizer. Not sure if/how that works, last I heard it didn't. Either way, can you try without compiz? If you still have problems please attach a kernel log (the output of dmesg) and an Xorg log. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [BUG ?] Nouveau driver on 330M GT
On Fri, Jun 11, 2010 at 4:52 AM, Eric Lacombe wrote: > Hi, > > I tested Nouveau with 2.6.34, and now with 2.6.35-rc2 and It does not work > with my laptop (chip NVIDIA GeForce 330M GT). (I give more information of the > nvidia chip below). I've seen an error message related to my nvidia chip that > may also be related to my problem : > > pci :01:00.0: no compatible bridge window for [mem 0xfff8-0x > pref] > > Thanks in advance for your response. > > Best regards > > Eric > > Here more information : > > # dmesg |grep "01\:00\.0" > [ 0.933105] pci :01:00.0: reg 10: [mem 0xd000-0xd0ff] > [ 0.933122] pci :01:00.0: reg 14: [mem 0xa000-0xafff 64bit > pref] > [ 0.933139] pci :01:00.0: reg 1c: [mem 0xb000-0xb1ff 64bit > pref] > [ 0.933151] pci :01:00.0: reg 24: [io 0x6000-0x607f] > [ 0.933166] pci :01:00.0: reg 30: [mem 0xfff8-0x pref] > [ 0.95] vgaarb: device added: > PCI::01:00.0,decodes=io+mem,owns=none,locks=none > [ 0.973672] pci :01:00.0: no compatible bridge window for [mem > 0xfff8-0x pref] > [ 0.973800] pci :01:00.0: BAR 6: assigned [mem 0xd108-0xd10f > pref] > [ 13.092806] vgaarb: transferring owner from PCI::00:02.0 to > PCI::01:00.0 This is not enough information. Most of the useful information is prefixed with [drm], but generally a full log from boot to fail is best. > > # sudo lspci -v -s :01:00.0 > 01:00.0 VGA compatible controller: nVidia Corporation Device 0a2b (rev a2) > Subsystem: Sony Corporation Device 905a > Flags: fast devsel, IRQ 5 > Memory at d000 (32-bit, non-prefetchable) [disabled] [size=16M] > Memory at a000 (64-bit, prefetchable) [disabled] [size=256M] > Memory at b000 (64-bit, prefetchable) [disabled] [size=32M] > I/O ports at 6000 [disabled] [size=128] > Expansion ROM at d108 [disabled] [size=512K] > Capabilities: [60] Power Management version 3 > Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > Capabilities: [78] Express Endpoint, MSI 00 > Capabilities: [b4] Vendor Specific Information > Capabilities: [100] Virtual Channel > Capabilities: [128] Power Budgeting > Capabilities: [600] Vendor Specific Information > Kernel modules: nouveau, nvidiafb Please make sure nvidiafb is not loaded. If you still have issues after making sure that nouveau is the only kernel module running for this device please attach a full log. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] PFIFO_DMA_PUSHER + Xen + NV30 + questions.
On Fri, Jun 4, 2010 at 5:24 PM, Konrad Rzeszutek Wilk wrote: > Hello, > > I am kernel engineer working on PV-OPS kernel trying to get it work in Dom0 > with an NVidia (NV30 right now) card. > > But there are issues, such as that the > pv-ops kernel has a different understanding of memory (for details check > out: http://wiki.xensource.com/xenwiki/XenPVOPSDRM). > > I've fleshed out most of them (like GART had the wrong phys addresses, > ouch!), but the one that I am stumbling at is that I see the PFIFO_DMA_PUSHER, > which I am to understand means: "Oh, the GPU obj operation you stuck on the > RAMHT/RAMIN is busted." > > So first of, is there a register to poke to find out which DMA operation > it is talking about ? Or is it pretty fast - so I can surmise that: > > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_hash_handle:75 - ch0 > handle=0x8001 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_hash_handle:86 - > hash=0x0088 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_insert:141 - insert > ch0 0x0088: h=0x8001, c=0x80011639 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_ref_add:457 - ch0 > h=0x800e gpuobj=88000219ac00 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_hash_handle:75 - ch0 > handle=0x800e > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_hash_handle:86 - > hash=0x00f0 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_insert:141 - insert > ch0 0x00f0: h=0x800e, c=0x8004 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_dma_new:679 - ch0 > class=0x003d offset=0x4 size=0x20 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_dma_new:680 - > access=0 target=0 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_new:216 - ch0 > size=16 align=16 flags=0x0006 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_new:224 - gpuobj > 88000219ac60 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_new:241 - global > heap fallback > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_ref_add:457 - ch0 > h=0x8006 gpuobj=88000219ac60 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_hash_handle:75 - ch0 > handle=0x8006 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_hash_handle:86 - > hash=0x00b0 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_ramht_insert:141 - insert > ch0 0x00b0: h=0x8006, c=0x8000163a > [ 13.271499] [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised > FIFO 0 > [ 13.760068] [drm] nouveau :01:00.0: PFIFO_DMA_PUSHER - Ch 0 > [ 13.271499] [drm] nouveau :01:00.0: nouveau_gpuobj_dma_new:679 - ch0 > class=0x003d offset=0x0 size=0x800 > > the error is for the blobs that have been inserted via _ramht_insert? > Or should I interogate some register to find out what it thinks is > wrong? > > P.S. > 1) If you are interested in seeing the git tree and all of the hacks I've > employed so far: > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > dev.experiment.kms > 2) A serial log on baremetal: http://darnok.org/tst004.baremetal.1 > 3) And on Xen:http://darnok.org/tst004.xen.1 where the PFIFO_DMA_PUSHER > is the king. It means the card started fetching unexpected garbage from the ring buffer. Either you pointed the card at garbage instead of a sensible buffer (nv10_fifo_create_context for nv30 IIRC) or your initial pushbuf (submitted by nouveau_dma_init) contains garbage. Or maybe something else, but based on your log that would be my guess. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Nvidia says I have a 8200, but lspci says a GeForce 9200M G
On Tue, May 25, 2010 at 10:46 AM, Bryan Quigley wrote: > Hello all, > > I'm debugging a card that the Nvidia blob recognizes as an 8200 but > lspci says is a GeForce 9200M G. My original bug report is in > launchpad.(https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/557895), > but I have been trying to debug further by using the nightly builds. > It still requires the noaccel flag to be set to work. > > I was wondering if there is anyway I could force it to be detected as > a 8200 with nouveau. I am guessing that it may be using some accel > features of the 9200 and that's the reason it doesn't work. PCI ID is > 10de:086f Don't pay attention to the marketing names, Nouveau is detecting your card as an NVAC and that's all that matters. See your log: [drm] nouveau :02:00.0: Detected an NV50 generation card (0x0ac780b1) Those chips are a little different from most other NV50s and not many developers have access to them so there are probably still some issues that need to be worked out. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Kernel module fails to initialize on AMD751 based system with NV34
On Mon, May 24, 2010 at 3:02 PM, Clemens Eisserer wrote: > Hi Younes, > > Thanks a lot for taking the time to reply to me mail. > > Updating the Bios (latest version for that board was Dec. 2000) didn't help. > I also tried nouveau with an old TNT2M64 card, but that didn't succeed either: > > 01:05.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA > TNT2 Model 64/Model 64 Pro] (rev 11) > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Interrupt: pin A routed to IRQ 11 > Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] > Region 1: Memory at e200 (32-bit, prefetchable) [size=32M] > Expansion ROM at efef [disabled] [size=64K] > Capabilities: > Kernel modules: nvidiafb, rivafb, nouveau > > > 01:05.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX > 5200] (rev a1) > Subsystem: XFX Pine Group Inc. Device 1351 > Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Interrupt: pin A routed to IRQ 11 > Region 0: Memory at ee00 (32-bit, non-prefetchable) [size=16M] > Region 1: Memory at d800 (32-bit, prefetchable) [size=128M] > Expansion ROM at efee [disabled] [size=128K] > Capabilities: > Kernel modules: nvidiafb, nouveau > > > 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate] > AGP Bridge (rev 01) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- DisINTx- > Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 120 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 > I/O behind bridge: c000-cfff > Memory behind bridge: ede0-efef > Prefetchable memory behind bridge: d5c0-e5cf > Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- > BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B- > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- > Kernel modules: shpchp > > > Should I file a bug directly against nouveau instead Ubuntu/Fedora? > > > Thanks again, Clemens > Both cards show BusMaster- when it should be BusMaster+. Also both cards have 2 BARs instead of 3. Check your BIOS settings to see if there's a switch to enable bus mastering. This is an AGP card right? If it was a PCI card I'd say plug it into another slot since some slots on some mobos can't do bus mastering, but if it's AGP the only thing left is a BIOS switch. Just guessing at this point. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Kernel module fails to initialize on AMD751 based system with NV34
On Wed, May 19, 2010 at 6:17 PM, Clemens Eisserer wrote: > Is there anything I can do in order to debug this? > > Thank you in advance, Clemens > > 2010/5/14 Clemens Eisserer : >> Today I tried Ubuntu-10.04 on a system with an NV34 (Geforce-5200) >> AMD-751 (Ironlake) Northbridge, >> however the kernel-module fails to initialize. >> >> Any idea what could be going wrong? >> >> Thank you in advance, Clemens >> >> PS: I filed a bug at ubuntu's launchpad: >> https://bugs.launchpad.net/ubuntu/+bug/580656 Seems to be failing on trying to read from the user area (despite the ioremap of that area succeeding), but before that there is another failure that forces it to take the channel down before it's fully initialized. Can you paste the output of lspci -vv for the video card just out of curiousity? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] SERIALIZE command
2010/4/9 Shinpei KATO : > Hi, > > Thanks again for your reply! > >> > I tried inserting the 0x110 commands with NvSubM2MF (subc=0), MvSubSw >> > (subc=1), NvSub2D (subc=2), NvSubGdiRect (subc=3), NvSubImageBlit >> (subc=4). >> > As a result, I got the PFIFO_CACHE_ERROR interrupts, with respect to those >> > with NvSubSw and NvSubImageBlit. I am really not certain what >> > PFIFO_CACHE_ERROR indicates, but seems they do not work correctly? Well, >> > those with NvSubM2MF, NvSub2D and NvSubGdiRect are still very helpful >> > though. >> >> This is not how it works. >> >> The command channels on nvidia hardware are split into 8 identical so-called >> subchannels. The consts you're refering to are subchannel numbers. >> >> However, these subchannels aren't constantly bound to the same objects - >> you >> bind an object to a subchannel by executing command 0 with data being the >> RAMHT handle of an object. >> >> The Nv* consts you're referring to are only valid in kernel, and represent >> the >> bindings it sets up at start. Most of them don't even apply to NV50. Also, >> NvSubSw is bound to a software object. > > Oops... I thought that each subchannel is always bound to the same object, > and I was actually looking at only the kernel driver ;-) > I have been trying to understand the behavior of GPU operations, using > Gallium demo applications. > To do so, I was dumping the commands sent from the user space > (Nouveau/Gallium libdrm), by mapping the pushbuf to the kernel virtual > address in the kernel driver, to see what is going on. > I was also inserting another command in the kernel driver, like in > nouveau_gem_ioctl_pushbuf(), to see what happens. > Since several Gallium demo applications seem to use the subchannels in the > same manner, I misunderstood that they are constantly bound to the same > objects... > I should have looked into the libdrm code in detail. Now I see them, thanks. > By the way, when I was dumping the commands, I sometimes saw 0x > without any data. > Do you have any idea what this value means? (just a NOP?) That's probably the null object (handle=0, class=0x30). It's created for every channel, see libdrm/nouveau_channel.c:86. >> PFIFO_CACHE_ERROR is an error that happens when the PFIFO puller encounters >> some problems. One of the causes is submitting a command on a subchannel >> which >> isn't actually bound to anything, which is what happens here. >> >> Software objects are fake objects where you don't actually bind any object >> to >> a subchannel, and instead trap the PFIFO_CACHE_ERROR this causes on command >> submission and do something on the host side. We use this for syncing with >> vblank on nv50. These don't support the SERIALIZE command because they're >> not >> real objects. > > So I was sending those commands with unbounded subchannels, that is why I got > the PFIFO_CACHE_ERROR interrupts. > >> Basically, there exist only 4 types of real objects you can submit commands >> on >> and bind to subchans: >> >> - m2mf [5039]: memory copies >> - eng2d [502d]: 2d engine >> - tesla [5097, 8297, 8397, 8597]: 3d engine >> - turing [50c0, 85c0]: computation engine: CUDA and the like >> >> Very likely there are more types, using different engine than PGRAPH, but >> we >> don't know anything about them yet. At the very least there should be the >> video decoding engine. > > Got it. > Regarding turing, you mean that Nouveau now supports CUDA? I think the kernel allows that object to be created, but that's all. We don't have any userspace GPGPU library yet. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nv40: remove leftover nv40_transfer.c from unification into nvfx
On Mon, Mar 15, 2010 at 9:35 AM, Luca Barbieri wrote:
> ---
> src/gallium/drivers/nv40/nv40_transfer.c | 181
> --
> 1 files changed, 0 insertions(+), 181 deletions(-)
> delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c
>
> diff --git a/src/gallium/drivers/nv40/nv40_transfer.c
> b/src/gallium/drivers/nv40/nv40_transfer.c
> deleted file mode 100644
> index 3d8c8e8..000
> --- a/src/gallium/drivers/nv40/nv40_transfer.c
> +++ /dev/null
> @@ -1,181 +0,0 @@
> -#include "pipe/p_state.h"
> -#include "pipe/p_defines.h"
> -#include "util/u_inlines.h"
> -#include "util/u_format.h"
> -#include "util/u_memory.h"
> -#include "util/u_math.h"
> -#include "nouveau/nouveau_winsys.h"
> -#include "nv40_context.h"
> -#include "nvfx_screen.h"
> -#include "nvfx_state.h"
> -
> -struct nv40_transfer {
> - struct pipe_transfer base;
> - struct pipe_surface *surface;
> - boolean direct;
> -};
> -
> -static void
> -nv40_compatible_transfer_tex(struct pipe_texture *pt, unsigned width,
> unsigned height,
> - struct pipe_texture *template)
> -{
> - memset(template, 0, sizeof(struct pipe_texture));
> - template->target = pt->target;
> - template->format = pt->format;
> - template->width0 = width;
> - template->height0 = height;
> - template->depth0 = 1;
> - template->last_level = 0;
> - template->nr_samples = pt->nr_samples;
> -
> - template->tex_usage = PIPE_TEXTURE_USAGE_DYNAMIC |
> - NOUVEAU_TEXTURE_USAGE_LINEAR;
> -}
> -
> -static struct pipe_transfer *
> -nv40_transfer_new(struct pipe_context *pcontext, struct pipe_texture *pt,
> - unsigned face, unsigned level, unsigned zslice,
> - enum pipe_transfer_usage usage,
> - unsigned x, unsigned y, unsigned w, unsigned h)
> -{
> - struct pipe_screen *pscreen = pcontext->screen;
> - struct nvfx_miptree *mt = (struct nvfx_miptree *)pt;
> - struct nv40_transfer *tx;
> - struct pipe_texture tx_tex_template, *tx_tex;
> -
> - tx = CALLOC_STRUCT(nv40_transfer);
> - if (!tx)
> - return NULL;
> -
> - pipe_texture_reference(&tx->base.texture, pt);
> - tx->base.x = x;
> - tx->base.y = y;
> - tx->base.width = w;
> - tx->base.height = h;
> - tx->base.stride = mt->level[level].pitch;
> - tx->base.usage = usage;
> - tx->base.face = face;
> - tx->base.level = level;
> - tx->base.zslice = zslice;
> -
> - /* Direct access to texture */
> - if ((pt->tex_usage & PIPE_TEXTURE_USAGE_DYNAMIC ||
> - debug_get_bool_option("NOUVEAU_NO_TRANSFER", TRUE/*XXX:FALSE*/))
> &&
> - pt->tex_usage & NOUVEAU_TEXTURE_USAGE_LINEAR)
> - {
> - tx->direct = true;
> - tx->surface = pscreen->get_tex_surface(pscreen, pt,
> - face, level, zslice,
> -
> pipe_transfer_buffer_flags(&tx->base));
> - return &tx->base;
> - }
> -
> - tx->direct = false;
> -
> - nv40_compatible_transfer_tex(pt, w, h, &tx_tex_template);
> -
> - tx_tex = pscreen->texture_create(pscreen, &tx_tex_template);
> - if (!tx_tex)
> - {
> - FREE(tx);
> - return NULL;
> - }
> -
> - tx->base.stride = ((struct nvfx_miptree*)tx_tex)->level[0].pitch;
> -
> - tx->surface = pscreen->get_tex_surface(pscreen, tx_tex,
> - 0, 0, 0,
> -
> pipe_transfer_buffer_flags(&tx->base));
> -
> - pipe_texture_reference(&tx_tex, NULL);
> -
> - if (!tx->surface)
> - {
> - pipe_surface_reference(&tx->surface, NULL);
> - FREE(tx);
> - return NULL;
> - }
> -
> - if (usage & PIPE_TRANSFER_READ) {
> - struct nvfx_screen *nvscreen = nvfx_screen(pscreen);
> - struct pipe_surface *src;
> -
> - src = pscreen->get_tex_surface(pscreen, pt,
> - face, level, zslice,
> - PIPE_BUFFER_USAGE_GPU_READ);
> -
> - /* TODO: Check if SIFM can deal with x,y,w,h when swizzling */
> - /* TODO: Check if SIFM can un-swizzle */
> - nvscreen->eng2d->copy(nvscreen->eng2d,
> - tx->surface, 0, 0,
> - src, x, y,
> - w, h);
> -
> - pipe_surface_reference(&src, NULL);
> - }
> -
> - return &tx->base;
> -}
> -
> -static void
> -nv40_transfer_del(struct pipe_context *pcontext, struct pipe_transfer *ptx)
> -{
> - struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
>
Re: [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification
On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri wrote: > Currently the nv30 and nv40 Gallium drivers are very similar, and > contain about 5000 lines of essentially duplicate code. > > I prepared a patchset (which can be found at > http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) > which gradually unifies the drivers, one file per the commit. > > A new "nvfx" directory is created, and unified files are put there one by one. > After all patches are applied, the nv30 and nv40 directories are > removed and the only the new nvfx directory remains. > > The first patches unify the engine naming (s/curie/eng3d/g; > s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. > Initial versions of this work changed renouveau.xml to create a new > "NVFXTCL" object, but the current version doesn't need any > renouveau.xml modification at all. > > The "unification+fixes" branch referenced above is the one that should > be tested. > The "unification" branch contains just the unification, with no > behavior changes, while "unification+fixes" also fixes swtnl and quad > rendering, allowing to better test the unification. Some cleanups on > top of the unfication are also included. > > That same repository also contains other branches with significant > improvements on top of the unification, but I'm still not proposing > them for inclusion as they need more testing and some fixes. > > While there are some branches in the Mesa repository that would > conflict with this, such branches seem to be popping up continuously > (and this is good!), so waiting until they are merged probably won't > really work. > > The conflicts are minimal anyway and the driver fixes can be very > easily reconstructed over the unified codebase. > > How about merging this? > Any objections? Any comments? Pushed. Thanks. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Interrupt setting
On Sat, Mar 13, 2010 at 11:47 AM, Shinpei KATO
wrote:
> Just one more thing.
> If two commands, (1) simple DMA data copies and (2) fencing, are executed in
> this order, it is possible to have the fence value written before completing
> DMA
> data copies, since DMA and GPU are independent, isn't is?
No, the fence value will be written after the DMA completes. There is
no independent DMA controller on the GPU, all memory copies are done
by the GPU and are no different than the drawing commands.
Here is a quick example, I copied them from
src/gallium/drivers/nouveau/nv04_surface_2d.c and edited them slightly
in case you want to look at it yourself:
/* Set up a 2D blit operation to copy an image with dimensions w,h
from src_bo at sx,sy to dst_bo at dx,dy */
MARK_RING (chan, 12, 4);
BEGIN_RING(chan, surf2d, NV04_CONTEXT_SURFACES_2D_DMA_IMAGE_SOURCE, 2);
OUT_RELOCo(chan, src_bo, NOUVEAU_BO_VRAM | NOUVEAU_BO_RD);
OUT_RELOCo(chan, dst_bo, NOUVEAU_BO_VRAM | NOUVEAU_BO_WR);
BEGIN_RING(chan, surf2d, NV04_CONTEXT_SURFACES_2D_FORMAT, 4);
OUT_RING (chan, format);
OUT_RING (chan, (dst_pitch << 16) | src_pitch);
OUT_RELOCl(chan, src_bo, src->offset, NOUVEAU_BO_VRAM | NOUVEAU_BO_RD);
OUT_RELOCl(chan, dst_bo, dst->offset, NOUVEAU_BO_VRAM | NOUVEAU_BO_WR);
BEGIN_RING(chan, blit, 0x0300, 3);
OUT_RING (chan, (sy << 16) | sx);
OUT_RING (chan, (dy << 16) | dx);
OUT_RING (chan, ( h << 16) | w);
/* Set up a general memory-to-memory operation to copy w*h*blocksize
bytes from src_bo + src_offset to dst_bo + dst_offset */
MARK_RING (chan, 3 + ((h / 2047) + 1) * 9, 2 + ((h / 2047) + 1) * 2);
BEGIN_RING(chan, m2mf, NV04_MEMORY_TO_MEMORY_FORMAT_DMA_BUFFER_IN, 2);
OUT_RELOCo(chan, src_bo, NOUVEAU_BO_GART | NOUVEAU_BO_VRAM | NOUVEAU_BO_RD);
OUT_RELOCo(chan, dst_bo, NOUVEAU_BO_GART | NOUVEAU_BO_VRAM | NOUVEAU_BO_WR);
BEGIN_RING(chan, m2mf, NV04_MEMORY_TO_MEMORY_FORMAT_OFFSET_IN, 8);
OUT_RELOCl(chan, src_bo, src_offset, NOUVEAU_BO_VRAM | NOUVEAU_BO_GART
| NOUVEAU_BO_RD);
OUT_RELOCl(chan, dst_bo, dst_offset, NOUVEAU_BO_VRAM | NOUVEAU_BO_GART
| NOUVEAU_BO_WR);
OUT_RING (chan, src_pitch);
OUT_RING (chan, dst_pitch);
OUT_RING (chan, w * util_format_get_blocksize(src->texture->format));
OUT_RING (chan, h);
OUT_RING (chan, 0x0101);
OUT_RING (chan, 0);
/* Set up a fill operation to fill a rectangle in dst_bo with
coordinates dx,dy,w,h with some solid color */
MARK_RING (chan, 16, 4);
BEGIN_RING(chan, surf2d, NV04_CONTEXT_SURFACES_2D_DMA_IMAGE_SOURCE, 2);
OUT_RELOCo(chan, dst_bo, NOUVEAU_BO_VRAM | NOUVEAU_BO_WR);
OUT_RELOCo(chan, dst_bo, NOUVEAU_BO_VRAM | NOUVEAU_BO_WR);
BEGIN_RING(chan, surf2d, NV04_CONTEXT_SURFACES_2D_FORMAT, 4);
OUT_RING (chan, cs2d_format);
OUT_RING (chan, (dst_pitch << 16) | dst_pitch);
OUT_RELOCl(chan, dst_bo, dst->offset, NOUVEAU_BO_VRAM | NOUVEAU_BO_WR);
OUT_RELOCl(chan, dst_bo, dst->offset, NOUVEAU_BO_VRAM | NOUVEAU_BO_WR);
BEGIN_RING(chan, rect, NV04_GDI_RECTANGLE_TEXT_COLOR_FORMAT, 1);
OUT_RING (chan, gdirect_format);
BEGIN_RING(chan, rect, NV04_GDI_RECTANGLE_TEXT_COLOR1_A, 1);
OUT_RING (chan, value);
BEGIN_RING(chan, rect, NV04_GDI_RECTANGLE_TEXT_UNCLIPPED_RECTANGLE_POINT(0), 2);
OUT_RING (chan, (dx << 16) | dy);
OUT_RING (chan, ( w << 16) | h);
/* Tell the GPU to execute all of the commands in the pushbuffer */
/* This will cause the kernel to emit a fence with some value X after
the last command in the pushbuffer */
FIRE_RING(chan)
while (nvchan_rd32(chan, 0x48) != X)
{
/* wait... */
}
/* At this point we are guaranteed that all 3 operations are complete
because the GPU will only write X into the register after it has seen
the fence command created by FIRE_RING() and it will only see that
command after it has seen and executed all other commands. */
___
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 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
On Fri, Mar 12, 2010 at 4:14 PM, Shinpei KATO 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
On Thu, Mar 11, 2010 at 2:40 PM, Uwe Bugla wrote: > Am Donnerstag, den 11.03.2010, 13:23 -0500 schrieb Younes Manton: >> On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla wrote: >> > Hi, >> > >> > I use two nv34 cards and I would like to test / try out / use the >> > Gallium driver without drawbacks. >> > >> > Unfortunately this has not been working since I decided to install / >> > compile nouveau 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). >> > >> > 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. >> > >> > Could it please be possible to modify this driver file so that it does >> > NOT continue to break existing applications?? >> > >> > Would be a pleasure! >> > >> > Cheers >> > >> > Uwe >> >> 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. > > Cheers I don't understand. What does udev have to do with nouveau_dri.so? If you don't install nouveau_dri.so globally it won't be used for either direct or indirect rendering by default. When you want to try it make sure libGL can find it by pointing the driver path to it and it should be used in that instance and that instance only. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium driver and compatibility issues
On Thu, Mar 11, 2010 at 12:42 PM, Uwe Bugla wrote: > Hi, > > I use two nv34 cards and I would like to test / try out / use the > Gallium driver without drawbacks. > > Unfortunately this has not been working since I decided to install / > compile nouveau 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). > > 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. > > Could it please be possible to modify this driver file so that it does > NOT continue to break existing applications?? > > Would be a pleasure! > > Cheers > > Uwe 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. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] making 0.0.16 into 1.0.0
On Thu, Mar 4, 2010 at 8:23 PM, Dave Airlie wrote: > So with all this ongoing Linus crap I'm going to be brave and ask for > reasons why > 0.0.16 kernel API can't become 1.0.0. > > Pros: > All old userspace compatibility is gone. > No more UMS cruft to support. > Something can be shipped on distros at last, people get to use the driver. > 3D drivers exist and use the interface, there is an investment in these > already. > > Reasons against: (I'm making these up, feel free ack/nack/flesh > out/add more etc). > We haven't finished 3D drivers yet so the interface may still need changes? > TTM sucks? > Userspace command-submission for ever? > I don't like versioning anything ever? > > So my current answers to my list of cons is: > > Adding new faster interfaces for 3D drivers shouldn't be a major problem, if > its > just a matter of making the current APIs saner. > > If you are going to write a UCS/non-TTM driver you are going to have to do > major changes all over the stack, in theory a kernel CONFIG option to enable > version 2 of the interface and drop version 1 would be an option at that time. > Or even a boot option to select between which one you want. I would > forsee a UCS/non-TTM driver needing to rewrite quite a lot of userspace, > in fact probably all of it. I haven't seen anyone actually start or > commit to working > on such a beast, and I'd reckon its probably a 1-2 year job, GEM took over a > year and it was arguably simpler. I'm not seeing the point of sitting > in a holding > pattern for that length of time just in case its better. The future is > always going > to be better. > > As for the I don't like versioning argument, well that really doesn't > need addressing, > you have to do version stuff to ship it, if the project as a whole > decides they don't > see a need to ever ship the code, then so be it. > > Dave. Whatever the decision is I suggest it not be made too hastily because of a Linus rant. We already know roughly where that leads. :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] texture dimension limits in ddx
On Wed, Feb 10, 2010 at 2:03 PM, Xavier Chantry
wrote:
> On Tue, Feb 9, 2010 at 8:44 PM, Xavier Chantry
> wrote:
>> in nv10_exa.c :
>> check_texture does :
>> if (w > 2046 || h > 2046)
>>NOUVEAU_FALLBACK("picture too large, %dx%d\n", w, h);
>> check_render_target does :
>>if (w > 4096 || h > 4096)
>>return FALSE;
>>
>> So we have different size limits for the source and the destination ?
>>
>> Another thing is that nv20 uses nv10_exa.c code, and the limit in
>> check_texture could be increased for nv20 according to curro :
>> 01:03 < curro_> shining: btw, about the 2048x2048 fallback, i'm quite
>> sure it's wrong for nv2x
>> 01:05 < curro_> shining: it can do 4096x4096 with no problems, IIRC
>>
>> And finally I saw that nouveau_exa_init does this :
>> if (pNv->Architecture >= NV_ARCH_50) {
>>exa->maxX = 8192;
>>exa->maxY = 8192;
>>} else
>>if (pNv->Architecture >= NV_ARCH_20) {
>>exa->maxX = 4096;
>>exa->maxY = 4096;
>>} else {
>>exa->maxX = 2048;
>>exa->maxY = 2048;
>>}
>>
>> But these 3 values are hardcoded everywhere in the code.
>> It might not be possible to use exa->maxX/Y directly as some functions
>> like check_texture / check_render_target above don't seem to have
>> access to them.
>> Maybe some constants could be defined instead and used everywhere ?
>> #define NV04_MAX 2048
>> #define NV20_MAX 4096
>> #define NV50_MAX 8192
>> or something.
>>
>
> Or to put this another way, I would like to give a name to all the values
> below.
> Actually nouveau_xv.c already defines some constants, but I have no
> idea if it would make any sense to use them in the other source files.
>
> src/nouveau_exa.c: exa->maxX = 8192;
> src/nouveau_exa.c: exa->maxY = 8192;
> src/nouveau_exa.c: exa->maxX = 4096;
> src/nouveau_exa.c: exa->maxY = 4096;
> src/nouveau_exa.c: exa->maxX = 2048;
> src/nouveau_exa.c: exa->maxY = 2048;
> src/nouveau_xv.c:#define IMAGE_MAX_W 2046
> src/nouveau_xv.c:#define IMAGE_MAX_H 2046
> src/nouveau_xv.c:#define TEX_IMAGE_MAX_W 4096
> src/nouveau_xv.c:#define TEX_IMAGE_MAX_H 4096
> src/nv10_exa.c: if (w > 2046 || h > 2046)
> src/nv10_exa.c: if (w > 4096 || h > 4096)
> src/nv30_exa.c: if ((w > 4096) || (h > 4096))
> src/nv30_exa.c: int w=4096;
> src/nv30_exa.c: int h=4096;
> src/nv30_exa.c: int pitch=4096*4;
> src/nv30_xv_tex.c: if (drw_w > 4096 || drw_h > 4096) {
> src/nv40_exa.c: if ((w > 4096) || (h > 4096))
> src/nv40_xv_tex.c: if (drw_w > 4096 || drw_h > 4096) {
> src/nv50_exa.c: if (ppict->pDrawable->width > 8192 ||
> src/nv50_exa.c: ppict->pDrawable->height > 8192)
> src/nv50_exa.c: if (ppict->pDrawable->width > 8192 ||
> src/nv50_exa.c: ppict->pDrawable->height > 8192)
> src/vl_hwmc.c: 2048,
> src/vl_hwmc.c: 2048,
> src/vl_hwmc.c: 2048,
> src/vl_hwmc.c: 2048,
It makes sense to clean this up if you're up to it. Some are max
texture sizes and others are max render target sizes like you said. If
you can figure out the limits of the various HW classes you can
substitute them into the code. Just remember, if a surface is both a
texture and a render target you'll have to use the smaller of the two
limits.
Maybe it makes sense to add it to nouveau_class.h if it's not already
there in some form so it can be used everywhere.
The value in vl_hwmc.c is for XvMC surfaces, which are used both as
textures and RTs and I just chose the a small reasonable value, it's
not based on any HW limits.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Syncing to vblank for interlaced video modes
On Tue, Feb 9, 2010 at 12:50 PM, Alistair Buxton wrote: > On 15 June 2009 14:14, Jamie Smith wrote: >> Hi Again, >> >> It seems I've triggered off much more discussion than I originally thought I >> would provoke. I forgot to actually state what I was proposing to do, but >> it appears that people have worked it out. >> >>> >> > On Sun, Jun 14, 2009 at 11:56:45PM +0100, Alistair Buxton wrote: >>> >> >> Stupid question: Given the presence of a register which indicates the >>> >> >> current field, why can't NVWaitVSync simply wait until the end of the >>> >> >> second field, by doing whatever it does twice iff it is called during >>> >> >> the first field? >> >> Yes, this is what I'm proposing. A server option that modifies the >> behaviour of the sync code so that if a) the option is set and b) the >> current video mode is interlaced, then wait until after the second field has >> been drawn before flipping pages/updating buffers etc. > > [snip debate about whether this is a good idea] > > I have been thinking about this problem recently and I have come to > the conclusion that it isn't necessary to change the vblank interrupt > frequency or add any special hooks to let the player know which field > is being shown. No drivers changes should be needed at all. It only > requires that players are more smart about how they display interlaced > content to the screen. > > At the moment, every player I know of, when interlacing is disabled, > just does simple weaving. This is bad as when you display it on an > interlaced screen there is no way to know which field will get > displayed first. But there is a better way. If, each time the player > receives a vblank interrupt, it draws the next field into the display > (ie updating every other line on the framebuffer, and leaving the > other lines alone) then each field is in the framebuffer for 1 whole > frame, and no matter which framebuffer field is currently shown, the > next one will always contain the correct next field. > > Effectively it is weaving, but instead of weaving each frame's field > pair, the frame rate is doubled by weaving every sequential field pair > even if they belong to different frames. So, assuming lower-field > first, it would produce frames composed like: > (1L,nothing),(1L,1U),(2L,1U),(2L,2U),(3L,2U),(3L,3U)... > > Why it works is kind of hard to explain without a diagram so I have made one: > > http://al.robotfuzz.com/~al/nouveau/path7109.png > > Anyway, since no driver changes are needed, this is now offtopic. But > does anyone know a player that can do what I am describing? Or maybe > this method of playback has a special name I am not aware of? The problem with that is that the player is typically not copying to the actual frame buffer, or even the same buffer that was copied to in previous frames. It's copying to some buffer that's not guaranteed to contain anything specific, let alone the previously copied content. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium - remove DRI1 support
On Mon, Jan 18, 2010 at 1:36 PM, okias wrote: > I read on Nouveau Wiki page, "Nouveau drops UMS support, huge clean-up in DDX. > Roughly 15k lines were deleted from the DDX when the user > mode-setting, DRI1 support (DRI2 is still there), ..." > so I just thought it's leftover. > > David > > 2010/1/18 Younes Manton : >> On Mon, Jan 18, 2010 at 5:14 AM, okias wrote: >>> Compilation tested. >>> >>> -- >> >> I still use DRI1 :) Any reason to remove it if it still works and >> doesn't require much maintenance? >> I didn't realize DRI1 went away with UMS as well in the DDX. I have no problem with it then, I'll just keep those paths around in my private tree until I move to a newer xserver. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium - remove DRI1 support
On Mon, Jan 18, 2010 at 5:14 AM, okias wrote: > Compilation tested. > > -- I still use DRI1 :) Any reason to remove it if it still works and doesn't require much maintenance? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv40 mpeg2 video decode
On Tue, Jan 12, 2010 at 10:02 PM, Jimmy Rentz wrote: > Hello, > > I have been working on a kernel and a user layer for the nv40 mpeg2 video > decoding hardware: > * The decode hw accepts commands written to a fifo along with a set of > registers for firing (put) and queries (get). > * The fifo can be mapped in vram or agp (though, agp isn't working right now). > * The fifo does not support dma jumps and such like the 3d fifo. > > Well, I have some questions about how to implement this in nouveau: > > * Mapping decode fifo in user-space versus kernel-space - My current version > has the fifo being mapped from the kernel (I copied the 3d fifo simple > version pretty much). I could do this in the kernel or userspace but it > would probably be faster in the kernel. If it's faster in kernel that would probably be best. > * Fencing - Each decode cmd sequence can emit a fence in a similar fashion to > the 3d fifo. So, you set the fence sequence number after a set of cmds. You > then check a register to see when the hw is done with a set of cmds. I just > don't see an easy of implementing this since the current fence mechanism only > works for the 3d fifo. We don't do anything for userspace fencing anymore so whatever you do in the kernel doesn't need to reach gallium yet. It can always be cleaned up later. Although I forgot to ask, how does the blob handle XvMCPutSurface? If it uses pfifo/pgraph to do CSC we would need the fencing to be accessible in gallium to coordinate that. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 3/3] nouveau: rewrite nouveau_stateobj to use BEGIN_RING properly
On Wed, Dec 30, 2009 at 4:36 PM, Maarten Maathuis wrote: > - The previous solution was hacky and didn't do subchannel autobinding. > - The beheaviour should match what libdrm_nouveau does closely. > - There appears to be a minor performance loss, probably due to having > multiple > memcpy's instead of one. > - The solution remains statically sized, but when debugging is on it will > check > for abuse. > - The values for nv30/nv40 may be off, but this should be easily caught with > DEBUG on. Tried a few levels of xmoto, worked fine. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [MESA PATCH] Fix nv40_miptree_layout pitch
On Sat, Dec 26, 2009 at 10:04 PM, Luca Barbieri wrote: > On Sun, Dec 27, 2009 at 2:25 AM, Younes Manton wrote: >> On Sat, Dec 26, 2009 at 1:22 AM, Luca Barbieri >> wrote: >>> I just coded a patch that does this and seems to work fine. It must be >>> fixed since it breaks OpenGL (or the state tracker can be changed, but >>> it seems better to do it in the driver). >>> >>> The patch also fixes NV20 and NV30 in the same way. They compile but >>> are untested. >>> >>> I would guess that using the 3D engine is faster for the larger >>> levels, but the 2D engine is faster for the smaller ones (and lacks >>> this issue). >> >> Hi, this patch and the other swizzle related one seem to have been >> mangled, they're wrapped with hard line breaks so I can't apply them. >> Can you resend? The cmp/scs one applied fine. >> > > Sorry, I hoped gmail wouldn't mangle it, but apparently was wrong. > > Attached the patch, will test once I get the message back. > > I'll post the other patch in reply to the other message. > Pushed. Thanks. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/2] libdrm: Unreference pushbuf objects on channel destruction
On Sun, Dec 27, 2009 at 5:02 AM, Krzysztof Smiechowicz wrote:
> (resending as git patch)
>
> - unreference pushbuf objects on channel destruction
>
>
> diff --git a/nouveau/nouveau_channel.c b/nouveau/nouveau_channel.c
> index 674c5c3..6f71f89 100644
> --- a/nouveau/nouveau_channel.c
> +++ b/nouveau/nouveau_channel.c
> @@ -111,6 +111,8 @@ nouveau_channel_free(struct nouveau_channel **chan)
>
> FIRE_RING(&nvchan->base);
>
> + nouveau_pushbuf_fini(&nvchan->base);
> +
> nouveau_bo_unmap(nvchan->notifier_bo);
> nouveau_bo_ref(NULL, &nvchan->notifier_bo);
>
> diff --git a/nouveau/nouveau_private.h b/nouveau/nouveau_private.h
> index 784afc9..de21a6b 100644
> --- a/nouveau/nouveau_private.h
> +++ b/nouveau/nouveau_private.h
> @@ -65,6 +65,9 @@ struct nouveau_pushbuf_priv {
> int
> nouveau_pushbuf_init(struct nouveau_channel *);
>
> +void
> +nouveau_pushbuf_fini(struct nouveau_channel *);
> +
> struct nouveau_channel_priv {
> struct nouveau_channel base;
>
> diff --git a/nouveau/nouveau_pushbuf.c b/nouveau/nouveau_pushbuf.c
> index b90e923..c4053ed 100644
> --- a/nouveau/nouveau_pushbuf.c
> +++ b/nouveau/nouveau_pushbuf.c
> @@ -170,6 +170,12 @@ nouveau_pushbuf_init(struct nouveau_channel *chan)
> return 0;
> }
>
> +void
> +nouveau_pushbuf_fini(struct nouveau_channel *chan)
> +{
> + nouveau_pushbuf_fini_call(chan);
> +}
> +
> int
> nouveau_pushbuf_flush(struct nouveau_channel *chan, unsigned min)
> {
Pushed both. I had to apply them by hand along with a few minor
additions since they would still not apply cleanly. They probably
needed a rebase. Thanks.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Synchronization mostly missing?
On Mon, Dec 28, 2009 at 1:55 AM, Luca Barbieri wrote: >> Can you reproduce this with your vertex buffers in VRAM instead of GART? >> (to rule out that it's a fencing issue). > > Putting the vertex buffers in VRAM makes things almost perfect, but > still with rare artifacts. > In particular, the yellow arrow in dinoshade sometimes becames a > yellow polygon on the floor, which happens almost every frame if I > move the window around. > It does fix demos/engine, blender and etracer is almost perfect. > > Using my sync patch fixes demos/engine and demos/dinoshade, but still > leaves artifacts in blender when moving the rectangle and artifacts in > etracer. > > Putting the vertex buffers in VRAM _AND_ adding my sync patch makes > things perfect on my system. > > Using sync + a delay loop before drawing makes things better but still > problematic. > > Also note that both adding wbinvd in the kernel at the start of push > buffer submission, running with "nopat" and synchronizing with the > current fence in the kernel had no effect on demos/engine artifacts. > > Preventing loading of intel_agp did not seem to have any effect either > (but strangely, it still listed the aperture size, not sure what's up > there). > > The last test I tried was, all together: > 1. My nv40_sync patch > 2. 3 wbinvd followed by spinning 1 times in the kernel at the > start of pushbuffer validation > 3. Adding > BEGIN_RING(curie, NV40TCL_VTX_CACHE_INVALIDATE, 1); > OUT_RING(0); > before and after draw_elements and draw_arrays > 4. Removing intel_agp > > The logo on etracer's splash screen still, on some frames, flickered. > Only putting vertex buffers in VRAM fixed that. > > I'm not really sure what is happening there. > > It seems that there is the lack of synchronization plus some other problem. > > Maybe there is indeed an on-GPU cache for AGP/PCI memory which isn't > getting flushed. > Maybe NV40TCL_VTX_CACHE_INVALIDATE should be used but not in the way I did. > I couldn't find it in renouveau traces, who did reverse engineer that? > What does that do? > > Also, what happens when I remove intel_agp? Does it use PCI DMA? > > BTW, it seems to me that adding the fencing mechanism I described is > necessary even if the vertices are read before the FIFO continues, > since rendering is not completed and currently I don't see anything > preventing TTM from, for instance, evicting the render buffer while it > is being rendered to. It's my understanding that once the FIFO get reg is past a certain point all previous commands are guaranteed to be finished, which is what our fencing is based on. I think we would all have corruption issues if this wasn't the case. You can see that the FIFO get ptr stops advancing after long running draw commands are submitted, and the video decoder FIFO works similarly as well when the HW is lagging. Anyhow, another person with a GF7 had the same problem and putting vertex buffers in VRAM also improved things for him, so it could be a hardware bug/quirk for some/all GF7s. We don't do it in general because it's slower, but as a temporary workaround we can do that for GF7 NV40s I guess. It likely also doesn't happen with immediate mode vertex submission, which will be implemented sooner or later. I can't reproduce it on my GF6 and I don't think anyone else has either. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 1/2] Unreference state/buffer objects on context/screen destruction
On Thu, Dec 24, 2009 at 3:23 AM, Krzysztof Smiechowicz wrote: > Hi, > > Any feedback on those patches? If they are ok, please commit them as I > don't have access to either of repositories. > > Best regards, > Krzysztof HI, can you resend both patches as git patches? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [MESA PATCH] Fix nv40_miptree_layout pitch
On Sat, Dec 26, 2009 at 1:22 AM, Luca Barbieri wrote: > I just coded a patch that does this and seems to work fine. It must be > fixed since it breaks OpenGL (or the state tracker can be changed, but > it seems better to do it in the driver). > > The patch also fixes NV20 and NV30 in the same way. They compile but > are untested. > > I would guess that using the 3D engine is faster for the larger > levels, but the 2D engine is faster for the smaller ones (and lacks > this issue). Hi, this patch and the other swizzle related one seem to have been mangled, they're wrapped with hard line breaks so I can't apply them. Can you resend? The cmp/scs one applied fine. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [MESA PATCH] Fix nv40_miptree_layout pitch
On Fri, Dec 25, 2009 at 10:37 PM, Luca Barbieri wrote: > You are right. The patch is wrong. Both changes fix my program, but do > break OpenGL (e.g. redbook/mipmap). > > I managed to reproduce the problem with perf/genmipmap. > > When run, it causes several instances of one of these 3 errors (using > swizzled textures): > [12949.125732] [drm] nouveau :01:00.0: PGRAPH_ERROR - nSource: > DATA_ERROR, nStatus: BAD_ARGUMENT > [12949.125738] [drm] nouveau :01:00.0: PGRAPH_ERROR - Ch 3/7 Class > 0x4097 Mthd 0x020c Data 0x:0x0008 > [12949.214750] [drm] nouveau :01:00.0: PGRAPH_ERROR - nSource: > DATA_ERROR, nStatus: BAD_ARGUMENT > [12949.214757] [drm] nouveau :01:00.0: PGRAPH_ERROR - Ch 3/7 Class > 0x4097 Mthd 0x020c Data 0x:0x0010 > [12951.752081] [drm] nouveau :01:00.0: PGRAPH_ERROR - nSource: > DATA_ERROR, nStatus: BAD_ARGUMENT > [12951.752088] [drm] nouveau :01:00.0: PGRAPH_ERROR - Ch 3/7 Class > 0x4097 Mthd 0x020c Data 0x:0x0020 > > It seems they are due to PGRAPH not liking an 8/16/32 pitch. > In my program I got these as well and narrowed it down to doing mipmap > generation on the small levels that have pitch set that way. > > This patch does make them go away but breaks progs/mipmap (both > changes are wrong). > > Apparently the miptree layout is correct, but the lowest mipmap levels > cannot be rendered to with the current code (that however tries to, > resulting in the errors), possibly due to an hardware limitation. > > I guess a possible solution could be to modify > nv40_miptree_surface_new to allocate temporary surfaces for pitch <64 > levels (i.e. 8x, 4x and 1x mipmap levels for RGBA) and then do a copy > with the 2D engine in nv40_miptree_surface_del. > > Alternatively, for square Pot textures, it may be possible to map the > 8x8, 4x4, 2x2 and 1x1 mipmaps as a single 16x16 pitch 64 swizzled > texture in which they should appear as rectangles, and then restrict > drawing to the rectangle by adjusting the viewport (and finding a way > to make bypass work too). Not sure if this works and whether it can be > generalized to non-square-pot textures. > > How does the nVidia driver implement glGenerateMipmap? > Hi, Yes this is a known problem. The hardware has two incompatible constraints; the layout of swizzled mipmaps makes rendering directly to the last few levels impossible as you saw. Personally I think the first approach is cleaner; in nv40_miptree_surface_new() if the PIPE_BUFFER_USAGE_GPU_WRITE flag is set but the offset & pitch of the surface doesn't allow it to be used as a render target create a temp. I have an old patch that does this that I will try to dig up if you have a program that suffers from this limitation. The Nvidia driver uses the 2D engine to generate the mipmap chain IIRC. For us this is handled by shared code in Mesa, which tries to generate the mipmap chain by using the 3D engine to render each level. This works fine for linear textures, not so well for swizzled, and currently the driver framework does not let us generate the mipmap chain using the 2D engine (at least without ugly hacks). ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [MESA PATCH] Fix nv40_miptree_layout pitch
On Fri, Dec 25, 2009 at 7:59 PM, Luca Barbieri wrote:
> This patch fixes two issues in nv40_miptree_layout.
>
> First, pt->width0 is used, which is the size of the whole texture,
> while width, which is the size of the mipmap level, should be used.
>
> Second, the current code does not 64-byte align the pitch of swizzled
> textures. However, on my NV40 this causes a pgraph error regarding the
> pitch register (and sometimes a system lockup too), which is fixed by
> this patch.
> I'm not sure how small mipmaps could have worked with the previous code.
>
> Also the offset code below may need some review.
> And furthermore, wide_pitch is set for any kind of texture usage, so
> maybe it should be made unconditional (what's the point of allocating
> a texture that the GPU can't use in any way?).
>
> diff --git a/src/gallium/drivers/nv40/nv40_miptree.c
> b/src/gallium/drivers/nv40/nv40_miptree.c
> index b974e68..9f54187 100644
> --- a/src/gallium/drivers/nv40/nv40_miptree.c
> +++ b/src/gallium/drivers/nv40/nv40_miptree.c
> @@ -31,8 +31,8 @@ nv40_miptree_layout(struct nv40_miptree *mt)
> }
>
> for (l = 0; l <= pt->last_level; l++) {
> - if (wide_pitch && (pt->tex_usage &
> NOUVEAU_TEXTURE_USAGE_LINEAR))
> - mt->level[l].pitch =
> align(util_format_get_stride(pt->format,
> pt->width0), 64);
> + if (wide_pitch)
> + mt->level[l].pitch =
> align(util_format_get_stride(pt->format, width), 64);
> else
> mt->level[l].pitch =
> util_format_get_stride(pt->format, width);
Hi,
Width0 is actually the correct value as far as I know. All mip levels
of a linear texture are padded out to the pitch of the base level so
they can be used by the 3D engine. I haven't run into the 64-byte
pitch error for swizzled textures myself, if you can reproduce it and
have a patch for it it would be appreciated.
The wide_pitch flag is set for textures the 3D engine will sample from
or render to, but for temporary textures that are used to do swizzled
texture transfers the 2D engine doesn't care (or will complain, I
don't remember), so it saves a bit of memory.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] nv50: remove vtxbuf stateobject after a referenced vtxbuf is mapped
On Mon, Dec 21, 2009 at 8:48 AM, Maarten Maathuis wrote:
> On Mon, Dec 21, 2009 at 11:25 AM, Christoph Bumiller
> wrote:
>> On 12/20/2009 04:46 PM, Maarten Maathuis wrote:
>>> - This avoids problematic "reloc'ed while mapped" messages and
>>> some associated corruption as well.
>>> - Also add one nouveau_bo_unmap() in the vbo code that wasn't present.
>> I didn't think nouveau_bo_unmap was necessary if the map failed.
>> As far as I can see, map will be NULL, and unmap will do nothing.
>> I don't know what our API doc says about that though ...
>> But the DDX seems to not unmap after failure.
>>>
>>> Signed-off-by: Maarten Maathuis
>>> ---
>>> src/gallium/drivers/nouveau/nouveau_screen.c | 21 +
>>> src/gallium/drivers/nouveau/nouveau_screen.h |3 +++
>>> src/gallium/drivers/nouveau/nouveau_stateobj.h | 13 +
>>> src/gallium/drivers/nv50/nv50_screen.c | 23
>>> +++
>>> src/gallium/drivers/nv50/nv50_screen.h |2 ++
>>> src/gallium/drivers/nv50/nv50_state_validate.c |2 ++
>>> src/gallium/drivers/nv50/nv50_vbo.c|4 +++-
>>> 7 files changed, 67 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
>>> b/src/gallium/drivers/nouveau/nouveau_screen.c
>>> index e4cf91c..c85057a 100644
>>> --- a/src/gallium/drivers/nouveau/nouveau_screen.c
>>> +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
>>> @@ -127,8 +127,18 @@ nouveau_screen_bo_map(struct pipe_screen *pscreen,
>>> struct pipe_buffer *pb,
>>> unsigned usage)
>> ...
>>> +static int
>>> +nv50_pre_pipebuffer_map(struct pipe_screen *pscreen, struct pipe_buffer
>>> *pb,
>>> + unsigned usage)
>>> +{
>>> + struct nv50_screen *screen = nv50_screen(pscreen);
>>> + struct nv50_context *ctx = screen->cur_ctx;
>>> +
>>> + if (!(pb->usage & PIPE_BUFFER_USAGE_VERTEX))
>>> + return 0;
>>> +
>>> + /* Our vtxbuf got mapped, it can no longer be considered part of
>>> current
>>> + * state, remove it to avoid emitting reloc markers.
>>> + */
>>> + if (ctx && ctx->state.vtxbuf && so_bo_is_reloc(ctx->state.vtxbuf,
>>> + nouveau_bo(pb))) {
>>> + so_ref(NULL, &ctx->state.vtxbuf);
>>> + ctx->state.dirty |= NV50_NEW_ARRAYS;
>> Hm ... I know I suggested it but I'm not completely sure it works now.
>> ctx->state.dirty will be checked in nv50_state_emit as far as I
>> can see, and then state stateobj better not be NULL.
>> (at least if I do this regardless of so_bo_is_reloc, I get a segfault)
>>
>> Since we're operating on the current context here, we should probably
>> set ctx->(no state.)dirty which is used in nv50_state_validate (no
>> segfault on emit then).
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> struct pipe_screen *
>>> nv50_screen_create(struct pipe_winsys *ws, struct nouveau_device *dev)
>>> {
>>> @@ -201,6 +223,7 @@ nv50_screen_create(struct pipe_winsys *ws, struct
>>> nouveau_device *dev)
>>> pscreen->get_param = nv50_screen_get_param;
>>> pscreen->get_paramf = nv50_screen_get_paramf;
>>> pscreen->is_format_supported = nv50_screen_is_format_supported;
>>> + screen->base.pre_pipebuffer_map_callback = nv50_pre_pipebuffer_map;
>>>
>>> nv50_screen_init_miptree_functions(pscreen);
>>> nv50_transfer_init_screen_functions(pscreen);
>>> diff --git a/src/gallium/drivers/nv50/nv50_screen.h
>>> b/src/gallium/drivers/nv50/nv50_screen.h
>>> index 61e24a5..a038a4e 100644
>>> --- a/src/gallium/drivers/nv50/nv50_screen.h
>>> +++ b/src/gallium/drivers/nv50/nv50_screen.h
>>> @@ -2,6 +2,7 @@
>>> #define __NV50_SCREEN_H__
>>>
>>> #include "nouveau/nouveau_screen.h"
>>> +#include "nv50_context.h"
>>>
>>> struct nv50_screen {
>>> struct nouveau_screen base;
>>> @@ -9,6 +10,7 @@ struct nv50_screen {
>>> struct nouveau_winsys *nvws;
>>>
>>> unsigned cur_pctx;
>>> + struct nv50_context *cur_ctx;
>>>
>> Using struct pipe_context **nouveau_winsys::pcxt would work too ...
>
> Is this a C++ feature?
>
nv50_screen->nvws->pctx[nv50_screen->cur_pctx] == pipe_context*
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Reporting Bugs in the 3D driver
On Fri, Dec 18, 2009 at 4:15 PM, Johannes Obermayr wrote: > Hi, > > the wiki page tells us that reporting bugs in the 3D driver is not allowed at > this time. > > The status page tells us that there are some chipset families with basic (or > more) 3D functionality. > > My question is whether this is the current status or are there some chipsets > for which bug reports in the 3D driver are allowed or even wished? > > If there are only some special bug reports in the 3D driver wanted and you > tell me which they are I will create a bug reporting matrix and edit the > frontpage... > > Thanks. > Johannes Hi, Personally I don't think it's worth accepting bugs for 3D for any driver until it passes all of the Mesa and piglit tests (or at least the ones that excercise the most common functions). In the current state I imagine we would get something like 500 bugs for what amounts to 50 actual problems that the Mesa or piglit could just as easily tell us about. Not sure about nv50, but no one has seriously tackled nv30 or nv40 in this area. Thanks for the offer however. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] GPU Temperature?
On Sun, Dec 13, 2009 at 12:15 PM, Ancoron Luciferis wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi there, > > I just wondered if there is an open-source way of getting information > about the temperatures provided by the internal sensors. I've read that > nvclock is providing such information but only if the binary driver is > installed and used. > > When I run 'sensors-detect' is see three adapters provided through nouveau: > > ... > Next adapter: nouveau-:01:00.0-2 (i2c-0) > ... > Next adapter: nouveau-:01:00.0-0 (i2c-1) > ... > Next adapter: nouveau-:01:00.0-1 (i2c-2) > ... > > This is on an old Dell Inspiron 8600 notebook with an nVidia GeforceFX > Go 5200 64M. > > > Thanx for info on this and please keep up the good work on this driver, > > Ancoron Matthew Garrett has some code for this, although I don't know if it's been committed yet. I think it's still limited to some cards anyway. Eventually we will be able to do this I hope. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] 8-bit swizzled textures
13:28 < pmdata> ymanton> We have a bit more work to do for 8 bits texture.
13:28 < pmdata> Swizzling works by halving dimensions, and using a8r8g8b8 as
format as seen in dumps for test_texture_format.
13:28 < pmdata> I nearly got text in progs/demos/texenv:
http://people.freedesktop.org/~pmandin/20091011.png
13:28 < pmdata> My current patch:
http://people.freedesktop.org/~pmandin/8bit_texture.diff
13:51 < pmdata> ymanton> it appears there is an extra copy done with m2mf when
dealing with 8 bits texture
Sorry, was not around earlier.
Did you try NV04_SCALED_IMAGE_FROM_MEMORY_COLOR_FORMAT_Y8 instead and
not changing the dimensions? I've seen the blob do strange things
before for swizzling that don't seem necessary, so we might be better
off trying the simplest approach first. I suspect it would work.
...Unless you already tried it and it didn't work, in which case I'd
be interested to see what the PGRAPH errors are.
@@ -51,6 +53,10 @@ static INLINE int
nv04_scaled_image_format(enum pipe_format format)
{
switch (format) {
+ case PIPE_FORMAT_A8_UNORM:
+ case PIPE_FORMAT_L8_UNORM:
+ case PIPE_FORMAT_I8_UNORM:
- return NV04_GDI_RECTANGLE_TEXT_COLOR_FORMAT_A8R8G8B8;
+ return NV04_SCALED_IMAGE_FROM_MEMORY_COLOR_FORMAT_Y8;
case PIPE_FORMAT_A1R5G5B5_UNORM:
return NV04_SCALED_IMAGE_FROM_MEMORY_COLOR_FORMAT_A1R5G5B5;
case PIPE_FORMAT_A8R8G8B8_UNORM:
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Fwd: Hardware Donation: PNY GeForce 7300 GS
On Fri, Oct 2, 2009 at 5:08 AM, Henrik Treadup wrote: > Hi > > I have a graphics card that I'm no longer using and I want to donate it to > the Nouveau project. > The card is a PNY Technologies Europe GeForce 7300 GS DDR2 256MB PCI-E > > Where should I send the card? I think everybody who works regularly on Nouveau has probably built up a collection of cards by now. Thanks for the offer however. :) ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [RFC] drm/nouveau: optimize code emission of inline functions
On Mon, Aug 10, 2009 at 1:40 PM, Pekka Paalanen wrote: > Before this patch: > > $ objdump -t nouveau.ko --section=.text | cut -f2 | sort -k2 | uniq -d -c > 4 > 9 0010 BEGIN_RING > 5 0051 FIRE_RING > 2 00b3 NVLockVgaCrtcs > 4 008b NVReadVgaCrtc > 2 008c NVReadVgaCrtc > 2 0011 NVVgaSeqReset > 2 006b NVWriteCRTC > 2 0066 NVWriteRAMDAC > 4 0081 NVWriteVgaCrtc > 3 0082 NVWriteVgaCrtc > 11 001a OUT_RING > 9 0028 RING_SPACE > 2 0019 crtc_wr_cio_state > 3 0012 drm_gem_object_unreference > 2 0005 kmalloc > 3 000b kzalloc > 4 0051 nouveau_bo_ref > 2 0050 nvReadMC > 2 0052 nvWriteMC > 3 0029 nv_gf4_disp_arch > 4 001b nv_rd08 > 3 001c nv_rd08 > 29 0012 nv_rd32 > 2 0012 nv_ri32 > 5 001c nv_ro32 > 4 008b nv_two_heads > 11 0022 nv_wo32 > 8 0015 nv_wr08 > 29 0014 nv_wr32 > 2 0013 pci_read_config_dword > > After this patch: > > $ objdump -t nouveau.ko --section=.text | cut -f2 | sort -k2 | uniq -d -c > 4 > 9 0010 BEGIN_RING > 5 0051 FIRE_RING > 2 00b3 NVLockVgaCrtcs > 5 00a7 NVReadVgaCrtc > 2 0011 NVVgaSeqReset > 2 0073 NVWriteCRTC > 3 0072 NVWriteRAMDAC > 4 0091 NVWriteVgaCrtc > 3 0092 NVWriteVgaCrtc > 11 001a OUT_RING > 9 0028 RING_SPACE > 2 0019 crtc_wr_cio_state > 3 0012 drm_gem_object_unreference > 2 0005 kmalloc > 3 000b kzalloc > 3 0051 nouveau_bo_ref > 2 0052 nouveau_bo_ref > 3 005d nvReadMC > 2 005c nvWriteMC > 3 0029 nv_gf4_disp_arch > 4 008b nv_two_heads > 2 0013 pci_read_config_dword > > As you can see, the static inline functions changed to extern > inline functions no longer appear many times in the final kernel > module. But, at the same time nouveau.ko file size > before: 583683 B (.text size 0x000312c8) > after: 681075 B (.text size 0x00039474) > That's .text size increase by 32 kB. > > So something is definitely inlined a lot more. This was tested on > x86_64, gcc 4.1.2, CONFIG_OPTIMIZE_INLINING=y, > CONFIG_CC_OPTIMIZE_FOR_SIZE=y. > > Now, I'm not sure if this patch would be a good thing or not. > Comments? Well if the goal is a small module then I guess it's not a good idea, but then we should be disabling some other optimizations that excessively bloat the module. I don't think it's a bad idea, but I'd be curious where all the extra text comes from. I'm guessing more inlining and/or loop unrolling. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] External monitor is blank with nouveau driver
On Tue, Jun 23, 2009 at 9:58 PM, Andriy Bakay wrote: > Sorry, I am sending configuration and log files. > > Younes Manton wrote: >> >> On Sat, Jun 20, 2009 at 12:25 PM, Andriy Bakay wrote: >>> >>> Hi Nouveau Team, >>> >>> I have the following hardware/software spec: >>> >>> ThinkPad T61 >>> FreeBSD 7.1-RELEASE-p5 amd64 >>> NVIDIA Quadro NVS 140M >>> X driver nouveau >>> External monitor NEC MultiSync 90GX2 >>> >>> I am connecting external monitor through VGA interface. I was able to >>> detect it using command 'xrandr -q' and even turn it on: >>> >>> $ xrandr --output VGA-0 --auto --below LVDS-0 >>> >>> the geometry of my desktop changed, but monitor remain blank. >>> >>> Please, advise. 1) Is that log from an instance where you tried to enable the 2nd monitor? I don't see anything in there about attempting to output to the VGA port. 2) Can you try a minimal xorg.conf file? You don't need a lot of those options for the display portion. Try something like this and let the driver do the rest: Section "Device" Identifier "card0" Driver "nouveau" EndSection Section "Screen" Identifier "screen0" Device "card0" EndSection ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] External monitor is blank with nouveau driver
On Sat, Jun 20, 2009 at 12:25 PM, Andriy Bakay wrote: > Hi Nouveau Team, > > I have the following hardware/software spec: > > ThinkPad T61 > FreeBSD 7.1-RELEASE-p5 amd64 > NVIDIA Quadro NVS 140M > X driver nouveau > External monitor NEC MultiSync 90GX2 > > I am connecting external monitor through VGA interface. I was able to > detect it using command 'xrandr -q' and even turn it on: > > $ xrandr --output VGA-0 --auto --below LVDS-0 > > the geometry of my desktop changed, but monitor remain blank. > > Please, advise. > > Thanks, > Andriy Why don't you show us what's in your xorg log? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Syncing to vblank for interlaced video modes
On Sun, Jun 14, 2009 at 8:32 AM, Jamie Smith wrote: > Hello, > > I wish to make a change to the nouveau source. You might say I am > considering becoming a nouveau developer. I am one of those crazy nutters > who connects my nvidia card directly to a television via a vga2scart cable > using interlaced video modes. As you are probably aware, interlaced video > signals generate two alternating half frames or 'fields', which the > interlaced display cleverly weaves together to form a full picture. > > DVD playing software typically works by generating a progressive video stream > by combining two consecutive (first and second) fields to produce a full > progressive frame. For the purpose of displaying true interlaced video (e.g. > DVD) to an interlaced television, without using deinterlacing, the full video > frames need to be written to the linear video buffer during the retrace after > the second frame is drawn, so that both fields are ready to be output in > correct order to the display. > > The current proprietary drivers from nVidia synchronise buffer updates to the > retrace after each single half frame is drawn, which for the most part is not > satisfactory. The symptoms of this are explained very well in this post -> > http://www.nvnews.net/vbulletin/showthread.php?t=95836 > > If I understand, the nouveau drivers currently use the standard vga crtc > registers to detect video retrace, and this results in the same behaviour. > According to specifications I have seen from AMD, at least one Radeon series > has registers which tell which field(first or second) is currently being > drawn, and which field will be next. I'm going to assume the nVidia cards > have something similar, and I'm hoping someone may either a) know this > information already so I can make a pretty simple change or b) suggest a way > that I might find out this information. Hi, >From my understanding, for textured video we stick a commands in the fifo that basically sleep the channel until the start of the next vblank. Look for NVWaitVSync. We call it in the various NV*PutTexturedImage functions. I think the overlay is (probably) automatically locked to the vblank. If I understand you correctly you want the same image to be displayed for two frames, i.e. when the tv is showing the first and second fields. There's no parameter for that in Xv to know which field a particular XvPutImage corresponds to as far as I know. In fact I'm not even sure if Xv knows anything about interlaced video, seems we just get full frames from the player and display them. XvMC seems a little better, XvMCPutSurface has first and second field params, so you would then sync only after the 2nd field is drawn I take it? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NV40 Cubic Texture HW Mip Map Generation
On Sat, Apr 18, 2009 at 9:29 PM, jb17bsome wrote: > Try progs/demos/cubemap.c. You just have to enable hw gen of > mipmaps: Ok I gave it a try, I get strange pink corruption on the sphere with both gluBuildMipmaps and HW mipmap gen. It seems to happen around the seems of the cube map faces and is related to the shading of the individual tris that make up the sphere, since I can kind of see them when they're pink. Is that what you're seeing too? Couldn't check what the software renderer does because it brought down the server when I ran the demo. I would say that cubemap+mipmap rendering is broken, not specifically HW mipmap gen, at least for me. No clue what the problem is though, probably need to look at what the blob does. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] NV40 Cubic Texture HW Mip Map Generation
On Fri, Apr 17, 2009 at 1:59 AM, jb17bsome wrote: > Hello, > I have been looking at cubic texture mapping for a bit, and I > have found that hw mipmap generation doesn't work at all or > the textures are all messed up (normal 2d work fine). This is > with linear textures. Also of note is that software mipmap > generation works fine. > > I have done sanity checks for the miptree pitches, offsets, etc > and everything seems to match up fine for both the hw and sw > paths. > > Any thoughts on what could be wrong? > > jb17bsome I was going to take a look, but apparently we don't have the cube_map extensions hooked up, and I'm not sure how to do that with Mesa and Gallium, and also there are no cube map tests in progs. Do you have a patch and some test code? I don't know why it wouldn't work, cube maps should work with the auto mipmap generation method they're using in Mesa currently. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Strange behavior on kde4
On Wed, Apr 15, 2009 at 1:27 PM, Luiz Angelo Daros de Luca wrote: > Hello, > > I filled a bug in kde (4.2.2) for some drawing problems. However, as it > occurs also with virtualbox, I think this might be related to nouveau. > I use updated nouveau git + drm git without 3d. Alfter some time, plasma and > virtualbox, independently, stops to draw some parts randomly. For example, > when I pass the mouse over icons, they disapear and reapear. > If I kill plasma or vbox and open it again, it works for some time before > the same problem reocurs. This happens also with other kde aplications like > kterminal. > > For plasma I got this error: > > QPainter::end: Painter not active, aborted > QPainter::begin: Paint device returned engine == 0, type: 3 > QPainter::setCompositionMode: Painter not active > > > > I also reported this in: > https://bugs.kde.org/show_bug.cgi?id=189059 > > Does anyone has a clue where is the problem? You tried it with nvidia, nv, vesa, etc and it works I assume? ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] nv50: wfb patches
2009/3/29 Maarten Maathuis : > The whole thing works fine, but XSHM is an issue > (http://stillunknown.livejournal.com/928.html). With it disabled most > apps are fine, although a few issues remain. Just out of curiousity, why can't you alloc a pixmap you can accelerate and just keep it sync'd with the xshm pixmap, track dirty rects, etc? Also why can't you allocate a linear pixmap on software fallbacks, copy+untile the original to the linear, let the fallback complete, and copy+tile back to the original? Might be cheaper than having to trap and transform every pixel access. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] running x.org on powerpc64 with nvidia6200
On Tue, Feb 17, 2009 at 9:47 AM, aik wrote: > Younes Manton wrote: >> >> You need various X dev packages installed... you are missing something >> related to randr. I install xserver-xorg-dev, x11proto-randr-dev, etc >> for example on Ubuntu and that usually solves my problems. Try finding >> randr related dev packages for Fedora. >> >> > > Found, installed. Fails different now. As I understand, it builds the > "intel" lib only. You need the --enable-nouveau-experimental-api flag when configuring, e.g.: ./configure --enable-nouveau-experimental-api ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] running x.org on powerpc64 with nvidia6200
On Mon, Feb 16, 2009 at 8:32 AM, aik wrote:
> Then, I made a try to move the card to domain #0. Having the BIOS source
> code, it was easy.
> But it keeps failing with the same error -
> (EE) NOUVEAU(0): wrong DRM version
> (EE) NOUVEAU(0): 1365:
>
> What does it mean?
> I'm also a little confused by a try loading something called "int10h"
> which does not exist in any form on my server.
>
>
> Linux Fedora 10, DRI/DRM has been taken from GIT less than week ago.
It means your DRM kernel module and X driver don't match. That is
strange, since it should fail to compile first I think. Somehow you
had the right DRM module at compile time but not at runtime? Try
getting the latest for both and recompiling.
/* temporary lock step versioning */
#if NOUVEAU_DRM_HEADER_PATCHLEVEL != 12
#error nouveau_drm.h does not match expected patchlevel, update libdrm.
#endif
if (pNv->pKernelDRMVersion->version_patchlevel !=
NOUVEAU_DRM_HEADER_PATCHLEVEL) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"wrong DRM version\n");
return FALSE;
}
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Gallium NV40 Textures
On Sun, Jan 25, 2009 at 10:58 AM, Jimmy Rentz wrote: > Hello, >I was playing around with the OpenGlSuperBible samples and >noticed some odd issues around textures. Yes, I know it won't >be perfect right now (and not supported)...I am just curious >if you see the same issues. >Well, I am seeing some issues around swizzled textures with the >sphereworld sample (chapter 08). The problems don't occur once >I force the textures to be linear. >NOTE: I modified the sample a bit so it only draws the ground. >pics: >swizzle.png - Current result with swizzled textures. >linear.png - Mod that turns off swizzled textures. > >I read something in the backlog about how mipmaps aren't >handled entirely correctly, but I don't know if this is related. > >Another thing, I do see some drm irq errors when the 1x1 mipmap >is generated. It might be related: >[drm] PGRAPH_ERROR - nSource: DATA_ERROR, nStatus: BAD_ARGUMENT >[drm] PGRAPH_ERROR - Ch 2/4 Class 0x309e Mthd 0x0300 Data >0x:0x000a [drm] PGRAPH_ERROR - nSource: DATA_ERROR, >nStatus: BAD_ARGUMENT [drm] PGRAPH_ERROR - Ch 2/5 Class 0x3089 >Mthd 0x0400 Data 0x:0x00010001 > >0x300 is for the texture format(A8R8G8B8) and 0x400 is for the >size (1x1). For some reason the hw doesn't like 1x1 swizzled >textures? Yeah I know what this is about. Swizzling is broken for mip maps. The first few levels swizzle fine, but after that something screws up. I think the swizzler has some limitations for the dest surface. dest must be aligned to some boundary (64 bytes? 128?) i think, so that means each mip level must be aligned, and we probably aren't obeying that at the moment. probably the hw won't handle 1xN or Nx1 either. Try the progs/tests/mipmap_view, IIRC 8x8 and below is broken. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Winsys changes in mesa/gallium-0.2
I made some changes to the Nouveau drm winsys so it could be shared between Mesa and VL. Mostly this involved moving all the common stuff into common/ and adding dri/. Compiles and runs the stuff in progs/ like before as far as I know, but if anyone actually uses the Mesa driver for anything non-trivial I'd appreciate knowing if this broke anything for you. :) * The code in common/ compiles to libnouveaudrm.a and the code in dri/ compiles to nouveau_dri.so and links with common. * Structs nouveau_screen and nouveau_context are now in common and only contain generic DRM stuff. * Structs nouveau_screen_dri and nouveau_screen_dri in dri/ contain the DRI/Mesa specific bits and use nouveau_screen and nouveau_context as base. * The dri/ dir also contains nouveau_swapbuffers.c which has all the swapping functions plus nouveau_contended_lock and nouveau_flush_frontbuffer. These are DRI/Mesa specific so I couldn't keep them generic. * The vl winsys contains the same 3 files, nouveau_screen_vl, nouveau_context_vl, and nouveau_swapbuffers which basically do the same as the dri/ dir if anyone is interested. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] (EE) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed
On Mon, Dec 29, 2008 at 9:51 PM, Leandro Lucarella wrote: > Hi. I'm trying nouveau and I'm having some troubles. I filled a bug[1] > a while ago about a problem I had (and I'm still experimenting), but > I found another issue that I suspect is normal. I get this in my Xorg.log: > [...] > (II) Initializing built-in extension COMPOSITE > (II) Initializing built-in extension DAMAGE > (II) Initializing built-in extension XEVIE > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci::02:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci::02:00.0 > (EE) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed > (/usr/lib/dri/nou veau_dri.so: cannot open shared object file: No such file > or directory) > (EE) AIGLX: reverting to software rendering > (II) Loading sub module "GLcore" > (II) LoadModule: "GLcore" > [...] > > Is this expected or I have some installation problems? I'm using > Debian/Ubuntu packages at http://ppa.launchpad.net/raof/ubuntu (I build > the kernel module using drm-modules-source and I install > xserver-xorg-video-nouveau too). > > TIA. Yes that's normal, it just means that the Mesa hardware driver is not found and AIGLX will use software rendering instead. > > [1] http://bugs.freedesktop.org/show_bug.cgi?id=16327 > You should try a newer xserver (1.5 or later) if possible, that might help this problem. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Interested in helping Nouveau
Hi, The first thing you might want to do is build and run the driver with your current machine. The driver is made up of three parts: the DDX driver (xf86-video-nouveau), the DRM driver (nouveau.ko), and the Mesa driver (nouveau_dri.so). The minimum you need for X is the DDX and DRM, the Mesa driver is for 3D. I suggest you start with the DDX driver and make yourself familiar with that, since not many people will be able to help you with the 3D stuff. You might find the XRender parts of DDX of interest, since it makes use of the 3D engine to do 2D. Useful stuff: DDX source: git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau DRM source: git://anongit.freedesktop.org/git/mesa/drm You can drop by #nouveau on Freenode and hang around there also for general info. From what I understand the Nouveau project has some recent experience in mentoring people who are interested in contributing. On Tue, Aug 19, 2008 at 1:37 PM, Branan Riley <[EMAIL PROTECTED]> wrote: > Hi everyone, > > I know there's a TODO page on the wiki, but it's kind of old (may), > and it doesn't really indicate priorities. So I thought I'd list my > skillset and interests here, and let those who are experienced with > nouveau development point me to a good place to start. > > I'm currently running a P4 (presler) with a GeForce 6600. The family > gaming macine is being upgraded soon (hopefully before the end of the > month, it keeps getting put off). When that happens, I'll have a Core > 2 Quad (Kentsfield), and I've bought myself a GeForce 8600 (though I > haven't set it up in my P4 system - waiting for the kentsfield). > > I'm self-taught in OpenGL, mostly in the programmable area rather than > the old fixed-function pipeline. I can do FBOs, VBOs, and all three > shader types with a certain amount of skill, and I understand the > basics of instancing and transform feedback (though I've never used > them except in experiments). > > I'm very interested in how low-level hardware programming works (I > wrote a bootloader that set up protected-mode and created a scrollable > text buffer, but never added enough to make it a real OS - got > absorbed in graphics stuff). > > Ideally, I'd like to work on the lower-level stuff, if there are any > good "get my feet wet" sort of tasks there, and if those of you who > are familiar with the code are willing to put up with helping me > figure out how it all works. If not, I'd love to contribute by writing > OpenGL test cases, and by contributing MMIO traces and renouveau > dumps. > > Branan > ___ > 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
