--- Log opened Пнд Авг 21 00:00:18 2006
00:25 < marcheu> darktama: ok, when libdri crashes on mandriva, FC5 and Rawhide, I call that a bug
00:28 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
00:37 < marcheu> hehe if I understand the code correctly, I actually wonder how it ever worked :)
00:38 < pmdata> so you find the bug, nice :)
00:38 < marcheu> not sure yet, but I found very weird stuff
00:38 < pmdata> "if (variable = 0)" ?
00:38 < marcheu> :)
00:38 < marcheu> not that much
00:38 < marcheu> but we're only filling half the fields in pDRIInfo
00:39 < marcheu> no wonder it crashes
00:46  * K Fear Factory - Archetype
01:06 -!- shawn_home [n=spstarr@CPEdeadbeef0000-CM000039d4cc6a.cpe.net.cable.rogers.com] has joined #nouveau
01:06 < shawn_home> you mean this one ;-)
01:06 < marcheu> yeah, because we've already been thrown out of dri-devel :)
01:06 < shawn_home> how come +s ?
01:07 < marcheu> don't want to start a riot on #freedesktop
01:07 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has quit [Read error: 60 (Operation timed out)]
01:07 < marcheu> +s is one of the default modes :)
01:07 < shawn_home> oh
01:07 < shawn_home> ok let me get renouveau
01:07 < shawn_home> bah
01:07 < shawn_home> the wiki is dead
01:07 < marcheu> not even sure what +s does
01:07 < shawn_home> got a direct url for the code?
01:08 < shawn_home> secret = +s
01:08 < marcheu> ah, that's stupid
01:08 < shawn_home> if you want more users then remove -s ;)
01:08 < marcheu> yup
01:08 -!- mode/#nouveau [+o marcheu] by ChanServ
01:08 < shawn_home> got code for renouveau? since wiki is down?
01:08 <@marcheu> I can do a tarball
01:09 < shawn_home> I have a GeForce 7300 GS
01:09 < shawn_home> is this dumped already?
01:09 < shawn_home> PCIe
01:09 <@marcheu> nope
01:09 <@marcheu> it's g72
01:09 <@marcheu> nouveau.sf.net/renouveau-daily.tgz
01:09 < shawn_home> so one of the newer ones
01:11 < shawn_home> oh I need sdl-dev
01:11 -!- mode/#nouveau [-s] by ChanServ
01:11 <@marcheu> yup
01:11 -!- mode/#nouveau [-o maxtoo] by marcheu
01:11 <@marcheu> stupid nick completion
01:11 < gabrielg> how come you were thrown out of dri-devel? :)
01:11 -!- mode/#nouveau [-o marcheu] by marcheu
01:11 < gabrielg> too high traffic?
01:12 < marcheu> yup
01:12 < gabrielg> k
01:12 < gabrielg> makes sence
01:12 < shawn_home> wow, i didn't uncomment anything except one multiple lines and it built
01:12 < gabrielg> it's cosy in here anyway, who would wanna be anywhere else
01:12 < shawn_home> where are the tests located that need to be uncommented?
01:12 < gabrielg> main.c
01:12 < marcheu> shawn_home: in main.c, they're //tests_stuff()
01:12 < shawn_home> ok
01:12 < gabrielg> time for sleep
01:12 < marcheu> gabrielg: yeah, people in here are not taking themselves too seriously
01:13 < gabrielg> marcheu: :)
01:13 < marcheu> gabrielg: 'night
01:13 < gabrielg> night
01:13 -!- gabrielg [n=gabriel@c-a6df72d5.011-178-73746f44.cust.bredbandsbolaget.se] has quit ["zzz"]
01:13 < shawn_home> if it's in #if 0 leave that commented?
01:13 < marcheu> yup
01:14 < marcheu> only change stuff in main.c
01:14 < shawn_home> yeah im in there, but you have a lot of #if 0 
01:14 -!- KoalaBR [n=KoalaBR@port-83-236-13-12.dynamic.qsc.de] has joined #nouveau
01:14 < shawn_home> and then test functions below that 
01:14 < marcheu> yup, only uncomment single lines that go //test_this()
01:15 < KoalaBR> Hi, just one question before I go to bed, but this bothers me:
01:16 < KoalaBR> I created a small script that looks through all my tests (did multiiple files) and found 93 unknown commands for nv40 (=NV30_TCL_PRIMITIVE_3D)
01:16 < shawn_home> so far, most of your test_ functions compile
01:16 < KoalaBR> 93 unique that is
01:16 < shawn_home> im not concerned of the implicit declaration warnings
01:17 < marcheu> shonope, no problem
01:17 < KoalaBR> started to check it part by part
01:17 < marcheu> shawn_home: nope, no problem
01:17 < shawn_home> still compiling one at a time to see
01:17 < marcheu> KoalaBR: and ? 
01:17 < KoalaBR> now I see this:   NV20_SWIZZLED_SURFACE      [0x0110/4] = 0x00000000           (more)
01:18 < KoalaBR> NvType0000      [0x0110/4] = 0x00000000
01:18 < KoalaBR> TCL_PRIMITIVE_3D      [0x0110/4] = 0x00000000
01:18 < KoalaBR> NV04_IMAGE_PATTERN      [0x0110/4] = 0x00000000
01:18 < KoalaBR> and  NV10_UNK0072      [0x0110/4] = 0x00000000
01:18 < marcheu> yeah, the first offset from different objects often havethe same meaning
01:18 < marcheu> offsets*
01:19 < KoalaBR> How can it be that the same command has different command names?
01:19 < marcheu> ah
01:19 < marcheu> it's not the same command
01:19 < KoalaBR> Ok, obviously I understood something wrong...
01:19 < marcheu> each command is linked to an object. the object can be NV20_SWIZZLED_SURFACE, NV30_TCL_PRIMITIVE_3D, NV04_IMAGE_PATTERN or whatever
01:19 < marcheu> and each of these objects owns a different 0x0110 command
01:20 < KoalaBR> Aaah
01:20 < marcheu> so as long as you do only 3D, you don't care because all you see is NV30_TCL_PRIMITIVE_3D anyway
01:20 < marcheu> but yes, for 2D/other stuff, you meet other objects
01:21 < KoalaBR> Well I did a grep through all tests for TCL_PRIMITIVE_3D
01:21 < shawn_home> all tests compiled 
01:21 < shawn_home> ok, how do I run this thing
01:21 < KoalaBR> and than searched where I could find this command, that's why I was irritated
01:21 < shawn_home> just renouveau?
01:21 < Duke`> yep
01:21 < KoalaBR> Thanks, will look into this and be back on tuesday. Bye
01:22 < shawn_home> heh it's drawing in NX machine
01:22 < shawn_home> error
01:22 < shawn_home> xorg blew up with a GLX error
01:22 < Duke`> huhu
01:22 < marcheu> KoalaBR: bye
01:22 < shawn_home> BadRequest GLX
01:22 < marcheu> shawn_home: hmm nouveau machine...
01:22 < marcheu> hmm NX machine
01:22 < marcheu> sounds like a bad idea
01:22 -!- KoalaBR [n=KoalaBR@port-83-236-13-12.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
01:22 < shawn_home> NX can't do GL ext i think
01:22 < shawn_home> what text file will it create?
01:23 < marcheu> you have to display to a local display
01:23 < pmdata> glxinfo should say direct rendering: yes
01:23 < marcheu> or the output is uselss
01:23 < shawn_home> if i can't run it, then i'll do it tomorrow @ work
01:23 < shawn_home> Direct rendering is no
01:23 < shawn_home> using indirect
01:23 < marcheu> yup, you'll have to
01:23 < shawn_home> (software) thats fine
01:23 < shawn_home> ok tomorrow morning when I get to work i'll run this :)
01:23 < marcheu> cool
01:31 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:09 -!- Duke` [n=gnu@ANantes-251-1-140-109.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:22 -!- lumag_of1line [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
02:22 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | card dumps at http://nouveau.sourceforge.net/tests/ | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
02:22 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
02:22 [Users #nouveau]
02:22 [@ChanServ] [ ajmitch ] [ ddl          ] [ lumag_offline] [ predatorfreak] [ swany    ] 
02:22 [ Aexoden ] [ cptn    ] [ etzel        ] [ marcheu      ] [ qfire        ] [ tibbs    ] 
02:22 [ ag      ] [ dagb    ] [ K            ] [ Myrizio      ] [ shawn_home   ] [ zoeloelip] 
02:22 [ airlied ] [ darktama] [ lumag_of1line] [ nano-        ] [ stillunknown ] 
02:22 -!- Irssi: #nouveau: Total of 23 nicks [1 ops, 0 halfops, 0 voices, 22 normal]
02:22 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
02:22 -!- Irssi: Join to #nouveau was synced in 7 secs
02:28 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has quit [Read error: 113 (No route to host)]
05:17 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
05:17 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | card dumps at http://nouveau.sourceforge.net/tests/ | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
05:17 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
05:17 [Users #nouveau]
05:17 [@ChanServ] [ ajmitch ] [ ddl          ] [ marcheu      ] [ qfire       ] [ zoeloelip] 
05:17 [ Aexoden ] [ cptn    ] [ etzel        ] [ Myrizio      ] [ snez        ] 
05:17 [ ag      ] [ dagb    ] [ hiyuh        ] [ nano-        ] [ stillunknown] 
05:17 [ airlied ] [ darktama] [ lumag_offline] [ predatorfreak] [ tibbs       ] 
05:17 -!- Irssi: #nouveau: Total of 21 nicks [1 ops, 0 halfops, 0 voices, 20 normal]
05:17 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
05:17 -!- [freenode-info] help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
05:17 -!- Irssi: Join to #nouveau was synced in 1 secs
06:49 -!- Myrizio [n=Myrizio@host182-98.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
09:55 -!- Tester_ [i=tester@gentoo/developer/tester] has joined #nouveau
09:57 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has quit [Remote closed the connection]
09:57 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has joined #nouveau
10:07 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
10:35 -!- Tester_ [i=tester@gentoo/developer/tester] has left #nouveau ["Client exiting"]
10:52 -!- EdB [n=EdB@ARennes-251-1-25-35.w81-250.abo.wanadoo.fr] has joined #nouveau
11:38 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
11:58 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
11:58 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | card dumps at http://nouveau.sourceforge.net/tests/ | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
11:58 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
11:58 [Users #nouveau]
11:58 [@ChanServ] [ airlied ] [ dagb] [ etzel        ] [ marcheu] [ snez     ] 
11:58 [ Aexoden ] [ b33fc0d3] [ ddl ] [ hiyuh        ] [ nano-  ] [ tibbs    ] 
11:58 [ ag      ] [ cptn    ] [ EdB_] [ lumag_offline] [ qfire  ] [ zoeloelip] 
11:58 -!- Irssi: #nouveau: Total of 18 nicks [1 ops, 0 halfops, 0 voices, 17 normal]
11:58 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
11:58 -!- Irssi: Join to #nouveau was synced in 1 secs
11:59 -!- Duke` [n=gnu@ANantes-251-1-140-109.w86-210.abo.wanadoo.fr] has joined #nouveau
12:03 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
12:05 -!- Unavowed [n=silent@host81-151-27-213.range81-151.btcentralplus.com] has joined #nouveau
12:06 -!- pmdata [i=patrice@ANantes-154-1-60-83.w81-53.abo.wanadoo.fr] has joined #nouveau
12:17 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #nouveau
12:23 -!- pmdata [i=patrice@ANantes-154-1-60-83.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
12:31 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
12:34 < Duke`> what are those "nx" cards?
12:39 < marcheu> NX ?
12:52 < Duke`> I've seen on the unofficial nvidia forum people with "nx7800" or "nx6200"
12:54 < cptn> isn't that just MSI's model name?
12:57 < cptn> mmmh, it looks like others use it too
13:24 -!- shenki [n=shenki@ppp225-88.lns2.adl4.internode.on.net] has joined #nouveau
14:00 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
14:49 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
14:50 < Lumag> hi all
14:52 -!- Duke` [n=gnu@ANantes-251-1-140-109.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
14:53 -!- Duke` [n=gnu@ANantes-251-1-87-207.w86-203.abo.wanadoo.fr] has joined #nouveau
15:35 -!- barnaby [n=barnaby@mailgate.echelonl.com] has joined #nouveau
15:36 < barnaby> Hi all, trying to update my renouveau test and have a couple of issues. First renouveau is reporting my NV18GL Quadro4 NVS as a NV15, is this a problem?
15:38 < marcheu> no
15:38 < barnaby> second, renouveau hands at 100% cpu if I enable BOTH test_clip_plane_after_vertex and test_arb_vertex_buffer_object, disabling either meens it runs normally - I am guessing the tests are ment to be totaly independent?
15:38 < barnaby> hands=hangs
15:38 < marcheu> yeah, I don't think test_clip_plane_after_vertex cleans up stuff properly, you can disable it anyway
15:39 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Remote closed the connection]
15:39 < barnaby> Okay - I will upload my results with test_clip_plane_after_vertex disabled, thanks for the help
15:42 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
16:08 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
16:09 -!- barnaby [n=barnaby@mailgate.echelonl.com] has left #nouveau []
16:12 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
16:55 -!- Myrizio [n=Myrizio@host135-98.pool80104.interbusiness.it] has joined #nouveau
16:59 -!- Unavowed [n=silent@host81-151-27-213.range81-151.btcentralplus.com] has quit [Nick collision from services.]
16:59 -!- Unavowed [n=silent@host81-151-27-213.range81-151.btcentralplus.com] has joined #nouveau
16:59 -!- Unavowed_ [n=silent@host81-151-27-213.range81-151.btcentralplus.com] has joined #nouveau
17:15 -!- keltor [n=root@unaffiliated/keltor] has joined #nouveau
17:16 -!- Myrizio [n=Myrizio@host135-98.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
17:22 < darktama> marcheu: should we modify the memory manager so that we can alloc memory (for the cmdbuf) in firstopen(), or add an INIT_CARD ioctl that the ddx calls instead?
17:22 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
17:23 < marcheu> darktama: well, I'm not sure yet
17:23 < marcheu> darktama: maybe letting user space hand a chunk of mem to the drm init fifo
17:23 < darktama> the second option could be useful anyway, the ddx could tell the drm about things like how many heads the card has (for CRTC interrupt enable)
17:24 < marcheu> actually, modify the memory manager sounds better
17:24 < marcheu> hmm
17:24 < darktama> it'd also let us control some drm stuff from xorg.conf
17:24 < darktama> like cmdbuf size, sync vblank to a certain crtc etc.
17:25 < marcheu> yes, having the ability to change the cmdbuf would be nice
17:25 < darktama> yup
17:26 < marcheu> the issue with an INIT_CARD is that you start to add code to the ddx like if (firstinstance) ... else ...
17:27 < darktama> I was thinking we'd do INIT_CARD right before the ddx grabs a FIFO
17:29 < marcheu> yeah, we have to change the allocator anyway
17:29 < marcheu> at least have an alloc() function and a matching ioctl to wrap it
17:29 < marcheu> instead of only a combined function
17:30 < darktama> yeah
17:30 < marcheu> but anyway, I still have to chase that libdri issue
17:30 < darktama> ah, I figured you'd solved that after your last commit :)
17:31 < marcheu> nope
17:31 < marcheu> btw do you have some /var/log/Xorg.0.log handy ?
17:31 < darktama> hmm, my .old is from nvidia's driver.. one sec and I'll grab one from ours
17:34 < darktama> http://members.iinet.net.au/~darktama/Xorg.0.log
17:35 < marcheu> cool thanks
17:35 < marcheu> at least I fixed the busid "(null)"
17:36 < b33fc0d3> looking through that
17:37 < b33fc0d3> does the driver work with aixgl ?
17:37 < darktama> no :)
17:37 < b33fc0d3> only 2d works ?
17:37 < darktama> yup, for now
17:39 < stillunknown> nv driver fork?
17:40 < darktama> yup, more or less.. it's been cleaned up a fair bit compared to the Xorg one, and is dependant on a kernel module
17:40 < keltor> I just wish mv/nouveau would work with any of my cards
17:41 < darktama> what doesn't work with it?
17:41 < keltor> G71
17:41 < keltor> in fact
17:41 < keltor> all but 1 desktop in the house has G71
17:42 < darktama> what model is it?
17:42 < darktama> by name, I have nfi what G71 is
17:42 < marcheu> 7900
17:42 < darktama> ah, according to the list in the driver it *should* be supported
17:42 < keltor> they are all pci-e
17:43 < marcheu> yeah, it works on a g70, so I expect it works on g71
17:43 < keltor> no when i had a G70 it worked once i got some experimental pci-e patches
17:43 < keltor> but none of my G71s work
17:43 < keltor> notably my desktops are 7900GT
17:43 < keltor> and 7950GX2
17:43 < marcheu> hmm, do you remember what patch ?
17:44 < marcheu> I had "nv" working on a pci-e 7800, I'm %100 positive
17:44 < keltor> this was just pre the 7.1 release
17:44 < keltor> i think the patch is in the driver that was released then
17:44 < marcheu> ah, ok. yeah g71 requires a fairly recent driver, but works
17:44 < marcheu> oops g70
17:44 < keltor> i've tested wth svn as of a few days ago
17:45 < marcheu> svn ?
17:45 < keltor> or cvs
17:45 < darktama> try git
17:45 < keltor> well the current release
17:45 < keltor> is the most current code
17:45 < keltor> but it JUST came out
17:46 < darktama> hm, does it lockup or something else?
17:46 < keltor> 1.3 i think
17:46 < keltor> yeah
17:46 < keltor> and the fonts are goofy
17:46 < keltor> xinit alone
17:47 < keltor> locks up
17:47 < stillunknown> 1.3 of what?
17:47 < keltor> the xf86-video-nv-1.3
17:47 < keltor> that's the release that happend last
17:47 < darktama> marcheu: oh that reminds me, when I updated to xorg-server git I lost a lot of fonts.. they just weren't rendered..
17:48 < b33fc0d3> so this stuff is part of xorg-server git ?
17:48 < marcheu> there's not xf86-video-nv-1.3
17:48 < marcheu> there's no xf86-video-nv-1.3
17:48 < marcheu> 1.2 is the last one AFAIK
17:49 < darktama> b33fc0d3: no, you don't need xorg-server git.. I just tried updating because.. well.. I could :)
17:49 < marcheu> darktama: well, if it's compiled differently, that happens
17:49 < b33fc0d3> darktama: do you need 7.1 ?
17:49 < marcheu> like builtin fonts vs xfs
17:50 < keltor> maybe it is the 1.2
17:50 < keltor> when did 1.2 come out?
17:50 < darktama> hm, the only thing I recompiled was the ddx..
17:50 < darktama> according to xorg-commit, 1st July
17:50 < keltor> yeah sorry 1.2
17:51 < keltor> there's been 1 update since then
17:51 < keltor> a relatively small change
17:51 < marcheu> "nv" only sees small changes
17:52 < keltor> i'm going to patc
17:52 < keltor> patch with it and see
17:52 < keltor> honestly i don't expect the 7950gx2 to work
17:53 < marcheu> neither do I... but a 7900 non-sli should be ok
17:53 < b33fc0d3> keltor: have you made ebuilds ?
17:53 < b33fc0d3> or has anyone ?
17:53 < keltor> yeah the 7900gt doesn't
17:53 < keltor> b33fc0d3: ebuilds of what?
17:53 < b33fc0d3> for this code
17:53 < darktama> b33fc0d3: yes, you need 7.1 unless you want to revert a couple of files
17:53 < keltor> for nouveau?
17:53 < b33fc0d3> yes
17:53 < darktama> the xf86-video-nv ebuild should work if you modify it a bit
17:53 < keltor> yeah i made a quick and dirty
17:54 < keltor> with a patch to make it work with 7.0 :)
17:54 < b33fc0d3> darktama: what about the dri ddx stuff ?
17:54 < b33fc0d3> keltor: can you post that please ?
17:54 < darktama> eh?
17:54 < b33fc0d3> the patch
17:54 < keltor> yeah when i get home i'll try it
17:55 < keltor> s/try/post
17:55 < b33fc0d3> cool
17:55 < b33fc0d3> http://nouveau.freedesktop.org/wiki/
17:55 < b33fc0d3> shows 3 links to cvs's
17:55 < b33fc0d3> dri/drm and ddx
17:55 < keltor> actually if you guys had your driver building for both automagically
17:55 < darktama> you'll need the drm module and the ddx one (the ddx is xf86-video-nv)
17:55 < keltor> that'd be awesome
17:56 < b33fc0d3> darktama: what about dri ?
17:56 < darktama> it doesn't compile yet
17:56 < b33fc0d3> darktama: and how do you build the drm ?
17:56 < keltor> the font weirdness in 7.1 just isn't very nice
17:56 < darktama> check it out of cvs, cd into drm/linux-core and run make nouveau.o
17:56 < keltor> i had to make a little patch for drm too
17:57 < keltor> but that was because of my kernel
17:57 < b33fc0d3> keltor: oh?
17:57 < marcheu> keltor: the font weirdness is with the proprietary driver usually ;)
17:57 < keltor> probably isn't related to mainline
17:57 < darktama> keltor: ati_pcigart.c? if so, marcheu fixed it yesterday
17:57 < keltor> marcheu: nah ... ati/i740/i810/gma950
17:57 < b33fc0d3> i'm using some patched kernel so i'm interested keltor
17:58 < keltor> marcheu: some people seem to get it .. some don't
17:58 < marcheu> weird
17:58 < keltor> it's been fixed as well
17:58 < keltor> there were fixes related to it with the current versions
17:59 < keltor> was just happy that my laptop is working finally
18:00 < keltor> with 7.1
18:01 < darktama> marcheu: so you're ok with the CARD_INIT ioctl?  if so, I'll work on it in the morning while I fix a windows machine (lots of boring waiting involved)
18:05 < darktama> b33fc0d3: you still an AT?
18:05 < b33fc0d3> darktama: ya
18:06 < b33fc0d3> darktama: waiting for my dev recruitment process
18:06 < darktama> oh nice :) congrats
18:06 < b33fc0d3> why aren't you an AT?
18:07 < b33fc0d3> thanks
18:07 < darktama> I stopped after I got involved with nouveau actually.. this is *much* more interesting than testing ebuilds :)
18:07 < b33fc0d3> yeah i don't do that much "testing"
18:07 < keltor> interesting is not all it's cracked up to be ...
18:07 < b33fc0d3> but still, try to give something back to the community
18:08 < darktama> keltor: interesting is great :)  I missed working with 3D drivers after I swapped out my r300 for an nvidia card.. this project was a great way back into it
18:09 < keltor> we'll have to see
18:09 < keltor> it's mildly interesting
18:09 < keltor> but by year end i think there may be some changes
18:09 < darktama> why's that?
18:09 < keltor> i know some people at via
18:10 < keltor> and likely there's stuff working that would allow any of the s3 patents
18:10 < keltor> to be used in OSS
18:10 < keltor> that'd pretty much open the door for OSS ati/nvidia drivers
18:10 < darktama> hm, do VIA have the S3TC patent? or someone else?
18:10 < keltor> yes
18:11 < keltor> they have the S3 IP
18:11 < keltor> it's that patent and the surrounding ones that are really the only hold up
18:11 < stillunknown> i don't think nvidia is very inclined to open source their drivers (but that's only impression)
18:11 < darktama> I doubt ATI/Nvidia care much about whether or not VIA release stuff.. they don't seem to be phased about Intel..
18:12 < keltor> i believe the intel drivers avoid the s3tc patent
18:12 < keltor> by just not doing it
18:12 < keltor> but then the drivers don't work for a bunch of things
18:13 < keltor> and amd has said they will release ati drivers
18:13 < keltor> so obviously it slightly phased them
18:13 < keltor> nvidia doesn't talk about that sorta stuff
18:13 < stillunknown> that's not true
18:14 < keltor> but the developers have said that the reason they are not OSS is directly related to various s3 patents
18:14 < stillunknown> they said they would open source in markets where it was needed, that doesn't include graphic 3d drivers
18:14 < stillunknown> (can't remember source, sorry)
18:14 < darktama> hm, the i915 Mesa driver seems to support S3TC.. so it'd work if you have the external DXTn library
18:17 < keltor> i would assume they would not actually release their drivers
18:17 < keltor> instead they would provide developers
18:17 < keltor> with a nda document describing the interfaces
18:17 < keltor> ie you cannot show the specs
18:17 < keltor> but you can write a driver
18:18 < keltor> but that's pretty typical now a days
18:18 < darktama> hell, I'd be happy to get a couple-hour Q&A session with the nvidia devs.. where they could answer questions :)
18:20 < keltor> i assume there's nothing useful in their binary block wrapper code?
18:20 < darktama> not really, no
18:21 < zoeloelip> do you guys know this project? http://utah-glx.sourceforge.net
18:21 < keltor> isn't that the "old" dri project page?
18:22 < b33fc0d3> it sure looks old
18:22 < keltor> i believe that's just the dri.sf.net page
18:22 < b33fc0d3> Latest news - Mesa5 migration plan  now under way (June, 2003)
18:22 < zoeloelip> it's pretty old but they have glx support for the first geforce cards
18:22 < keltor> or at least that's the page for "some" of the drivers
18:24 < keltor> hmm seems that there used to be a drm driver for nvidia
18:24 < keltor> but wouldn't matter
18:24 < keltor> it only worked up to like geforce2
18:25 < keltor> geforce3+ was a total wall
18:25 < keltor> believe same situation with haiku driver
18:25 < keltor> except haiku has great 2d acceleration
18:26 < keltor> better than nv does
18:27 < darktama> what does haiku support 2d-wise that nv doesn't? apart from dual-head
18:28 < keltor> dualhead and additional acceleration
18:28 < keltor> i don't know what there is with the accel
18:28 < keltor> but it's quite a bit faster
18:29 < keltor> before i upgraded from my 6800gt
18:29 < keltor> i'd get typically 2x speed overall to graphics operations
18:29 < keltor> i was going to wade through the code
18:30 < keltor> but if you download it
18:30 < keltor> and look
18:30 < keltor> you'll see why i stopped :)
18:30 < darktama> yeah, I've got the haiku code here.. much easier to understand than nv is :)
18:38 < marcheu> darktama: why would CARD_INIT be needed exactly ? enumerate heads ?
18:38 -!- shawn_work [n=spstarr@192.219.104.10] has joined #nouveau
18:39 < shawn_work> marcheu: ping
18:39 < marcheu> shawn_work: pong
18:39 < shawn_work> going to run dump nwo
18:39 < shawn_work> now
18:39 < darktama> marcheu: tell DRM the number of heads, the desired cmdbuf size.. what crtc to use for sync-to-vblank.. etc.
18:40 < shawn_work> ouch
18:40 < shawn_work> FIFO channel couldn't be detected. PLEASE REPORT (0x2504 is 4000000f/4000000f)
18:40 < shawn_work> map 0   from 0x2aaaaab21000 to 0x2aaaabb21000 size 0x1000000 (physical 0xcf000000)      => no dump
18:40 < shawn_work> map 1   from 0x2aaaabb21000 to 0x2aaabbb21000 size 0x10000000 (physical 0xd0000000)     => no dump
18:40 < shawn_work> Fatal signal: Segmentation Fault (SDL Parachute Deployed)
18:40 < shawn_work> Card has id 0x10de01df (G70) bus is PCI-E (256 Mb video ram) <- wrong
18:40 < shawn_work> 512MB
18:40 < marcheu> darktama: the cmdbuf size I'd like to have it in the FIFO_INIT ioctl
18:40 < shawn_work> (--) NVIDIA(0): VideoRAM: 524288 kBytes
18:40 < marcheu> darktama: for the rest, a setparam could do I think
18:41 < marcheu> shawn_work: hang on
18:41 < stillunknown> will nouveau also optimise 2d acceleration? (eventually)
18:41 < shawn_work> ok, i can wait in queue :)
18:41 < darktama> marcheu: yes, but from what I can tell all the FIFOs cmdbufs have to be in the same area.. nvidia seems to alloc a large chunk, and then give each FIFO a piece of it.. the GET/PUT pointers are also one large block
18:43 < marcheu> shawn_work: your card is 7300 GS, which supports 256MB max, so it seems right to me
18:43 < marcheu> shawn_work: now, since it's PCI-E, the nvidia guys like to lie about the "turbo cache memory"
18:44 < marcheu> shawn_work: and actually report to you the amount of vram PLUS the amount of used system ram, which coudl be 512
18:44 < shawn_work> er
18:44 < shawn_work> this box has 4GB of system ram
18:44 < keltor> MSI and eVGA both make 7300GS boards with 512MB
18:44 < keltor> i own the evga board
18:45 < shawn_work> 000:03:00.0 VGA compatible controller: nVidia Corporation: Unknown device 01df (rev a1) (prog-if 00 [VGA])
18:45 < shawn_work>         Subsystem: XFX Pine Group Inc.: Unknown device 2200
18:45 < shawn_work> XFX Pine Group Inc
18:45 < marcheu> we'd have to look at the ram chips to be sure, but I'd say its' just marketting
18:46 < keltor> yep xfx's has 512MB
18:46 < keltor> least
18:46 < keltor> according to their website
18:46 < keltor> i dunno honestly
18:46 < keltor> my evga has 512MB though
18:46 < marcheu> well, if you can look at the card's ram chips you can know for sure
18:47 < shawn_work> I can after, but for now renouveau is coredumping :)
18:47 < shawn_work> what to do? which test is doing it?
18:48 < marcheu> keltor: I'd love a link to that. usually they say "256/512 TC" which means 256MB of vram
18:48 < keltor> i went to xfxforce.com
18:48 < keltor> and looked up their 7300gs
18:48 < marcheu> shawn_work: it shouldn't crash that early, can you run it through gdb ?
18:49 < marcheu> darktama: hmm, could we do the following : let the first fifos have large chunks, and give smaller chunks to other apps ?
18:49 < shawn_work> sure
18:49 < marcheu> darktama: makes sense to me anyway, since you don't run many apps at the same time usually
18:49 < marcheu> darktama: but the first ones would really benefit from bigger fifos
18:50 < keltor> oh wait
18:50 < shawn_work> Program received signal SIGSEGV, Segmentation fault.
18:50 < shawn_work> [Switching to Thread 47275484999840 (LWP 24215)]
18:50 < shawn_work> 0x00002aff2ef09876 in _nv000228gl () from /usr/lib/libGLcore.so.1
18:50 < keltor> my board is a 7300gt
18:50 < shawn_work> how nice every function is _nv######gl what asses
18:50 < keltor> so my board has 512 for real :)
18:50 < keltor> positively
18:51 < shawn_work> keltor: likely same one
18:51 < keltor> shawn_work: no the GT has a different setup than the GS
18:51 < shawn_work> this is a 7300 GS
18:52 < marcheu> shawn_work: hmm, what does bt say ?
18:52 < shawn_work> thats the crash point #0
18:52 < darktama> as long as the FIFOs are next to each other, I don't think it matters how big each one is.. but I'm not sure.  nvidia allocs each FIFO at (cmdbuf_base+(fifo_num * fifo_size)) and the base GET/PUT for each is (fifo_num*fifo_size).. so I guess we can have unevenly-sized FIFOs.
18:52 < shawn_work> we start with test_startup() 
18:52 < marcheu> darktama: hmm, we should look at quadros, they have bigger fifos
18:53 < marcheu> shawn_work: is any .txt fils out yet ?
18:53 < darktama> I'm not sure there's a hardware limit actually
18:53 < shawn_work> none
18:53 < shawn_work> start commenting out tests? :)
18:53 < marcheu> darktama: but really, it'd make sense to have the first couple of apps have the ability to allocate bigger fifos (as memory permits)
18:54 < shawn_work> commented out lots of tests let's see...
18:54 < marcheu> shawn_work: yeah, maybe comment test_startup, it might be crash prone
18:54 < shawn_work> ok one moment, i have to do work :)
18:55 < darktama> sure, I'm all for that idea.  we still need to reserve a certain amount of space for them though :)
18:55 < marcheu> keltor: if you could report on what renouveau says on your 7300GT says under renouveau, that'd be nice
18:55 < keltor> i could do so
18:55 < keltor> does that need X?
18:56 < marcheu> keltor: yes, with the proprietary driver running
18:56 < keltor> ahh
18:56 < keltor> that box has no X
18:56 < keltor> but i am sure i can get it running at some point and run renouveau
18:57 < keltor> i've a 7800gt i can run it against
18:57 < keltor> hey
18:57 < marcheu> yeah, I'd like to know if we have issues with 512MB cards 
18:57 < keltor> that's a G70 card
18:57 < keltor> doesn't work with nv driver either
18:57 < marcheu> but that one has 256 IIRC
18:57 < marcheu> at least I've access to a 256MB 7800GT
18:58 < marcheu> darktama: hmmm. so we could do something different
18:58 < marcheu> darktama: have a setparam, and have the card_init code be called on the first fifo_init
18:59 < marcheu> but maybe that wouldn't be possible at that point in the initialization
18:59 < keltor> well i am trying it against my 7950gx2
18:59 < keltor> and it locked :(
19:00 < keltor> buut
19:00 < keltor> i have my l33t in kernel debugger on that box
19:00 < keltor> so i'll try to see if serial is still working
19:00 < marcheu> does the 7950gx2 come up as 2 pci devices ?
19:02 < darktama> marcheu: hm, that should be fine actually
19:02 < marcheu> it sounds like the mostly clean way of doing it to me
19:03 < marcheu> just have a default size, and have the ability to override it through setparam
19:03 < darktama> and, it deos look like we can have unevenly-sized FIFOs.. nvidia has given Xorg an 0x10000 sized one, and GL clients appear to have 0x200000
19:03 < keltor> yes it does
19:03 < keltor> i can initalize two in kernel frame buffer drivers against it
19:03 < marcheu> hehe
19:03 < keltor> using some fun stuff
19:03 < marcheu> yeah, so I don't think renouveau could work on that correctly
19:04 < shawn_work> round #3..fight!
19:04 < shawn_work> you do not need to be root to run this program right?
19:04 < marcheu> no
19:04 < shawn_work> crashed with no startup() functio
19:05 < shawn_work> hack does it even work with any tests.. im commenting them ALL out
19:05 < marcheu> yeah, good idea
19:05 < shawn_work> yes it does
19:06 < marcheu> what if you uncomment only test_default ?
19:09 < marcheu> darktama: so, do we settle for that approach ?
19:10 < marcheu> darktama: btw I think fifo size accounts for some non-zero amount of speedup on quadro
19:11 < darktama> yes, I saw a bit of a speedup when I experimented with it a while back (according to x11perf that is)
19:11 < darktama> An AGP cmdbuf helps *a lot* too
19:11 < marcheu> yeah, although once again, not on PPC :)
19:11 < darktama> true :)
19:13 < darktama> so, the ddx will do drmOpen().. then setparam for the config stuff.. then FIFO_INIT?
19:13 < marcheu> yeah.. I'm still pondering wether that's a good idea
19:13 < darktama> the setparam?
19:13 < marcheu> yeah that approach
19:15 < darktama> any other ideas? :)
19:15 -!- EdB_ [n=EdB@ARennes-251-1-25-35.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
19:15 -!- EdB_ [n=EdB@ARennes-251-1-25-35.w81-250.abo.wanadoo.fr] has joined #nouveau
19:15 < marcheu> well, there's the alternative of adding a CARD_INIT
19:16 -!- EdB_ is now known as EdB
19:17 < marcheu> I guess it doesn't really matter much
19:17 < shawn_work> ok scissor worked
19:17 < shawn_work> one by one..
19:18 < shawn_work> Enabled scissor 1
19:18 < shawn_work> Disabled scissor 0
19:18 < shawn_work> :)
19:18 < marcheu> what did it output about the mappings ?
19:18 < shawn_work> map 0   from 0x2aaaaab21000 to 0x2aaaabb21000 size 0x1000000 (physical 0xcf000000)      => no dump
19:18 < shawn_work> map 1   from 0x2aaaabb21000 to 0x2aaabbb21000 size 0x10000000 (physical 0xd0000000)     => no dump
19:18 < marcheu> only 2 mappings... sounds flawed
19:18 < marcheu> what does glxinfo say ?
19:18 < shawn_work> uh oh.. it seems any SDL test will break
19:18 < shawn_work> test_alpha() crashes
19:19 < shawn_work> which info do you need from glxinfo?
19:19 < shawn_work> NVIDIA: could not open the device file /dev/nvidiactl (No such file or directory).
19:19 < shawn_work> NVIDIA: could not open the device file /dev/nvidiactl (No such file or directory).
19:19 < marcheu> Renderer ?
19:19 < shawn_work> OpenGL renderer string: unknown board/PCI/forceSW
19:20 < marcheu> ok
19:20 < shawn_work> the kernel driver is loaded 
19:20 < shawn_work> nvidia               5437976  16
19:20 < marcheu> so, forceSW is a special mode of nvidia drivers
19:20 < marcheu> in which software rendering is used for OpenGL
19:20 < shawn_work> not hw?
19:20 < marcheu> nope
19:20 < shawn_work> is that bad?
19:20 < shawn_work> or thats by design
19:20 < marcheu> don't ask me why, maybe you need a newer driver
19:20 < shawn_work> that is the newest one? :)
19:20 < marcheu> usually that's a bug in their drivers, yeah
19:20 < shawn_work> NVIDIA-Linux-x86_64-1.0-8762-pkg2.run
19:21 < shawn_work> running --update
19:21 < shawn_work> The latest NVIDIA Accelerated Graphics Driver for Linux-x86_64 (version 1.0-8762) is alread
19:21 < shawn_work> thats the newest
19:21 < marcheu> so, you need to wait for a newer driver
19:21 < darktama> marcheu: ok, I'm fine with any way of doing it.. so long as we can get that info the the drm somehow :)
19:21 < shawn_work> so i can't run your tests for now?
19:22 < darktama> s/the the/to the/
19:22 < marcheu> nope, because our tests look at the commands sent to the hardware... which aren't used with software rendering
19:22 < shawn_work> ugh ok
19:22 < shawn_work> i'll abort for now
19:22 < shawn_work> that might be a while
19:22 < marcheu> yeah, well, we can't fix nvidia's drivers
19:22 < darktama> 8774 is supposed to be out already.. so, hopefully soon
19:22 < marcheu> we already have enough issues with ours :)
19:23 < shawn_work> Version: 1.0-8762
19:23 < shawn_work>  Operating System: Linux AMD64/EM64T
19:23 < shawn_work>  Release Date: May 22, 2006
19:23 < shawn_work> hmm
19:23 < shawn_work> it could be for several months
19:24 < marcheu> well, there's a trick to know when a release is imminent
19:24 < marcheu> there's a sudden flux of nvidia people joining #nvidia :)
19:24 < darktama> there was a rumour going around that it'd be monday this week.. it's tuesday here now, so I guess it's monday in nvidia-land
19:26 < keltor> yes it's rather early monday
19:26 < keltor> 825am in Pacific time
19:26 < keltor> they usually pop it around what
19:26 < keltor> 3pm their time i think
19:27 < shawn_work> hehe
19:27 < darktama> I have no idea, but I'm choosing to ignore the rumours.. since I don't think any of them came from an "official" source
19:27 < shawn_work> ' Next release? No idea, and don't ask'
19:27  * darktama ignored that and asked AaronP anyway a couple of days ago
19:27 < shawn_work> remind me why i hate binary crap
19:27 < darktama> he didn't answer me :)
19:28 < marcheu> darktama: a setparam is better, because we can have easy back/foreward compat as we add parameters
19:28 < shawn_work> we must put an end to this maddness 
19:28 < shawn_work> madness 
19:28 < darktama> marcheu: cool, I'll go with that idea then :)
19:28 < marcheu> darktama: if we add params to some nouveau_card_init_t we break binary compat
19:28 < marcheu> darktama: OTOH, unknown setparams can probably be cafely ignored
19:29 < darktama> makes sense
19:31 < darktama> anything in particular you think should be configurable? aside from the cmdbuf size/location?
19:31 < marcheu> hmm no
19:32 < marcheu> by location you mean vram or agp ?
19:32 < marcheu> not specifying an adress
19:32 < darktama> yeah vram/agp
19:32 < marcheu> yup
19:32 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:38 -!- Aexoden [n=Aexoden@207.118.82.54] has quit ["WeeChat 0.2.0"]
19:38 -!- Aexoden [n=Aexoden@207-118-82-54.dyn.centurytel.net] has joined #nouveau
19:41 -!- jkolb [n=jkolb@wsi-131-153.wsi.com] has joined #nouveau
19:56 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:57 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
19:59 -!- Unavowed [n=silent@host81-151-27-213.range81-151.btcentralplus.com] has quit ["leaving"]
19:59 -!- Unavowed_ [n=silent@host81-151-27-213.range81-151.btcentralplus.com] has quit [Remote closed the connection]
20:23 -!- K [i=hazel@tor/session/external/x-12ddeee900c7fb31] has joined #nouveau
20:24 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has quit [Read error: 104 (Connection reset by peer)]
20:24 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has joined #nouveau
20:34 -!- pmdata [i=patrice@ANantes-154-1-60-83.w81-53.abo.wanadoo.fr] has joined #nouveau
20:34 -!- atcl [n=Universe@L8726.l.pppool.de] has joined #nouveau
21:02 < pmdata> hum, renouveau crashes in test_default (after test_startup) if OUTPUT_MULTIPLE_FILES is defined, something has been broken
21:05 < marcheu> yeah, it's the 2nd report of that today
21:06 < marcheu> I suppose it's one of the recent changes
21:13 < marcheu> pmdata: so what if you revert a couple of renouveau versions ?
21:14 < pmdata> I guess the break happened today or yesterday
21:14 < marcheu> so cvs -D is your friend :)
21:14 < marcheu> cvs -D "1 day ago" update
21:21 < pmdata> 1 day ago segfault, will go further
21:23 < pmdata> 2 days ago segfault, will go further
21:25 < pmdata> 7 days ago segfault, maybe it is something else
21:25 < marcheu> let me test latest CVS
21:26 < darktama> hm, works for me..
21:27 < marcheu> seems to work here as well (on the testbox)
21:28 < pmdata> hum this is something else on my system
21:30 -!- zoeloelip [n=bart@d54C0400B.access.telenet.be] has quit [Read error: 110 (Connection timed out)]
21:32 -!- zoeloelip [n=bart@d54C0400B.access.telenet.be] has joined #nouveau
21:33 < pmdata> backtrace:
21:33 < pmdata> #0  0xb7d25f14 in fgets () from /lib/tls/libc.so.6
21:33 < pmdata> #1  0x0804b14e in redirect_output (name=0x8061b36 "test_scissor") at re.c:780
21:36 < pmdata> Ah, can not open regtmp.txt
21:37 < pmdata> fopen() result is not tested, f==NULL
21:38 < pmdata> the grep is correct
21:41 < marcheu> untested results in my code ? I caaaan't believe it :)
21:42 < marcheu> btw we should generate those tmp filenames
21:43 < marcheu> for example with tmpnam
21:45 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
21:48 < pmdata> regtmp file seems to be deleted
21:49 < pmdata> system("rm -f "TMPFILE);
21:49 < pmdata> why recreate it each time?
21:49 < pmdata> missing TEST_PROLOGUE or TEST_EPILOGUE somewhere ?
21:50 < marcheu> because if you don't delete it, people send me "renouveau results" which is that file
21:55 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Remote closed the connection]
21:55 < pmdata> TEST_PROLOGUE open/create/delete regtmp.txt
21:55 < pmdata> dump_before() open/read it the first time it is called
21:56 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
21:56 < pmdata> TESTPROLOGUE on next test will delete it
21:56 < pmdata> dump_before() does not find it any more, can not mmap
21:57 < marcheu> dump_before only does it the first time
21:57 < marcheu> it constructs a global structure with the mappings
21:57 < pmdata> ah, yes
21:57 < marcheu> and then reads from it
21:58 < pmdata> but why testprologue fails to create it the second time it is called?
21:59 < marcheu> except obvious reasons like "disk full" ? no idea
22:00 < pmdata> I have 1.2 GB avail
22:02 < marcheu> does the file exist at the time it fails ?
22:04 < pmdata> I have something strange, I added a printf() for the scratch value done with grep, and a check for fopen():
22:04 < pmdata> (cat /proc/bus/pci/devices |grep "[[:space:]]nvidia" | head -1 > regtmp.txt)
22:04 < pmdata> Can not open regtmp.txt
22:04 < pmdata> Can not open regtmp.txt
22:04 < pmdata> Can not open regtmp.txt
22:04 < pmdata> Can not open regtmp.txt
22:05 < pmdata> It means the grep is done only once -> wtf???
22:08 < pmdata> I moved system("rm -f "TMPFILE); to close_output(), now it works -> more wtkfff???
22:08  * shawn_work feels so left out :-(
22:10 < pmdata> I think I may have an explanation
22:10 < pmdata> man system
22:10 < pmdata> then ask yourself when the command will be executed
22:10 < shawn_work> pmdata: what does glxinfo show? for Render engine
22:11 < marcheu> system() waits for command termination
22:11 < pmdata> shawn> what exactly do you want to know?
22:11 < shawn_work> if it shows forceSW
22:11 < shawn_work> then you might as well stop :)
22:17 < pmdata> I never saw forceSW in my glxinfo output
22:18 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
22:19 < shawn_work> then ignore me ;)
22:20 < pmdata> did you properly installed the nvidia driver?
22:20 < marcheu> yeah, his card is too recent and now supported for 3D yet
22:22 < marcheu> s/now/not
22:23 < pmdata> what is the pci device id?
22:23 -!- Myrizio [n=Myrizio@host199-102.pool80104.interbusiness.it] has joined #nouveau
22:24 < Duke`> huhu nvidia releases hardware before having drivers with full support? (or at least, 90% support?)
22:24 < marcheu> Duke`: I think they bail out in a couple of corner cases, which are fixed later
22:25 < marcheu> pmdata: 10de:01df
22:26 < pmdata> geforce 7300 gs, shouldn't it be supported?
22:27 < marcheu> corner case...
22:28 < pmdata> according to nv site, it should be
22:28 < marcheu> yeah, we're not in charge of debugging it, you know
22:29 < pmdata> yep, shawn should bother nvidia http://download.nvidia.com/XFree86/Linux-x86/1.0-8762/README/appendix-a.html
22:30 < marcheu> I think there were a couple of people on misc forums with forceSW issues...
22:33 < pmdata> "omg, there is A bug in nvidia driver" :)
22:36 < keltor> for the nvidia driver
22:36 < keltor> or the nv driver?
22:36 < keltor> 7300gs probably doesn't work with the nv driver
22:37 -!- keltor [n=root@unaffiliated/keltor] has quit ["Lost terminal"]
22:54 -!- Myrizio_ [n=Myrizio@host36-96.pool80104.interbusiness.it] has joined #nouveau
22:56 -!- Myrizio [n=Myrizio@host199-102.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)]
22:57 -!- Myrizio [n=Myrizio@host36-96.pool80104.interbusiness.it] has joined #nouveau
23:01 -!- Myrizio_ [n=Myrizio@host36-96.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
23:06 -!- jkolb [n=jkolb@wsi-131-153.wsi.com] has quit [Remote closed the connection]
23:06 < pmdata> oops, I wrongly imported a personnal project in nouveau cvs
23:06 < pmdata> I should have checked CVSROOT
23:09 < Duke`> lol?
23:11  * Duke` suspects a disguised way to distribute his software :p
23:12 < pmdata> cvs release should work
23:19 < pmdata> damn can't delete it from cvs
23:22 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit []
23:23 < pmdata> ah, deleted all files, directories remaining
23:26 < nano-> cvs \o/
23:27 -!- simonpca [n=simonpca@c207.134.117-157.clta.globetrotter.net] has joined #nouveau
23:28 -!- simonpca [n=simonpca@c207.134.117-157.clta.globetrotter.net] has left #nouveau ["Leaving"]
23:29 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
23:33 < pmdata> boulette presque rpare, peut rien faire pour les repertoires
23:35 < EdB> svn roxor :o)
23:35 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
23:39 < pmdata> "que celui qui n'a jamais fait une fausse manip me jette un gros caillou"
23:48 < pmdata> anyway disabling the system("rm -rf" TMPFILE); seems to fix my problem in renouveau
23:48 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
23:49 < pmdata> hum, I upgrade to a recent 2.6.16.x kernel, so maybe the system() task is done at a wrong time
23:49 < pmdata> I upgraded
23:56 < marcheu> argh an atari project in my cvs, do you want to kill me ?
23:56  * marcheu will import some amstrad cpc projects for good measure :)
23:57 < pmdata> this is gpl sources, and is available on my site, /me just forgot to set CVSROOT to the proper destination :(
23:57  * pmdata will try to be more careful
23:57 < marcheu> I don't care, that was just a joke:)
23:57 < marcheu> except for the atari part, that is :)
23:58 < marcheu> maybe I should program on the CPC instead. no crashing libdri there...
23:58 < pmdata> you are lucky I did not import doom heretic and hexen sources I worked on all the weekend :)
23:59 < marcheu> doom on atari ?
--- Log closed Втр Авг 22 00:00:12 2006
