--- Log opened Срд Сен 20 00:00:42 2006
00:02 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Remote closed the connection]
00:02 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
00:17 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
00:19 -!- johnnybuoy [n=Void@195.56.6.14] has quit ["Gone..."]
00:40 -!- marteus [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
00:41 -!- johnnybuoy [n=void@nilus-268.adsl.datanet.hu] has joined #nouveau
00:44 -!- johnny110011 [n=Void@nilus-268.adsl.datanet.hu] has joined #nouveau
00:45 -!- johnny110011 [n=Void@nilus-268.adsl.datanet.hu] has quit [Remote closed the connection]
00:56 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has joined #nouveau
01:01 -!- KoalaBR [n=KoalaBR@port-83-236-13-201.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
01:33 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has quit ["<blank>"]
01:35 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has joined #nouveau
01:42 -!- caro [n=vincent@alf94-3-82-66-248-160.fbx.proxad.net] has quit ["My taylor is rich"]
01:56 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
02:09 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
02:27 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
02:31 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has quit [Connection timed out]
02:39 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has joined #nouveau
02:43 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
02:58 < darktama_> marcheu: well, you managed to get some constructive discussion going :)
02:58 < marcheu> ah, nice to see you darktama_ 
02:58 < marcheu> I'm creating/deleting objects with the proprietary driver
02:58 < marcheu> and can't get the RAMIN to change
02:59 < darktama_> hmm, what ioctl are you using? one of them changes RAMIN for sure, because I used it to find my vram RAMIN
03:00 < marcheu> I'm dumping the whole ramin
03:00 < marcheu> basically I'm dumping regs+0x700000
03:00 < darktama_> pushd ~
03:00 < darktama_> oops
03:01 < marcheu> pushd ~ sounds like something useless, because popd is 4 letters, but cd only 2 :)
03:01 < darktama_> yeah, there was meant to be more of a path there too :)
03:01 < marcheu> more seriously, do you see dma objects in RAMIN change when running the proprietary driver ?
03:02 < darktama_> yes, they appear in RAMIN after the object creation ioctl call
03:07 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit ["Konversation terminated!"]
03:07 < darktama_> do you see that happening if you enable PRINT_RAMIN_CHANGES in ioctl.c?
03:08 < marcheu> yep, I don't think I'm looking far enough now
03:08 < marcheu> I wonder what area it spans
03:09 < darktama_> I have no idea, I've got a /*FIXME*/ in the drm about that
03:09 < darktama_> my guess is 0x07xxxxxx
03:09 < darktama_> oops 0x007xxxxx
03:10 < marcheu> btw are you making sense out of the two frames ?
03:11 < darktama_> for RAMIN?
03:11 < marcheu> yes
03:11 < darktama_> no, I still haven't looked at that much yet.. it's always in the same place here, so I'm at a loss as to how to find it
03:12 < marcheu> yeah, I thought I'd use it as a heuristic to find valid entries...
03:23 < darktama_> hm, I'm not sure there's any good way to find them
03:25 < darktama_> for the entries that also have a hash table entry (should be most of them), you can use that to decide if a part of RAMIN is an object or not
03:25 < marcheu> yeah, what I'm trying to find are RAMIN entries that migrate
03:26 < marcheu> but I suspect these do exist
03:28 -!- `Duke` [n=gnu@ANantes-251-1-174-213.w90-12.abo.wanadoo.fr] has joined #nouveau
03:30 < darktama_> that migrate?
03:30 < marcheu> that move from VRAM to AGP, or the other way
03:31 < darktama_> ah
03:31 < marcheu> right now there are two things that hold back further development :
03:31 < marcheu> - memory management (which needs understanding the object stuff fully)
03:32 < marcheu> - context switching (I think it fails because fifo #2 is actually not correctly setup, some of the magic values should probably be understood reused for that fifo)
03:34 < darktama_> on memory management, I was thinking that we might be able to abuse the PTE present bit in DMA objects (thats assuming we get some kind of fault when it's not set)
03:35 < darktama_> actually no, that gives us the same problem as modifying the offsets in the dma object..
03:36 < marcheu> hmm what problem do you think it is ?
03:37 < darktama_> it's the (seemingly) lack of a dedicated object for each texture unit
03:37 < marcheu> ah, only that ?
03:37 < marcheu> we don't have evidence of that for now, right ?
03:38 < darktama_> well, I haven't seen evidence of them existing
03:39 < darktama_> if we were to move, say, the texture image for unit 3 - then adjust the object offset we'd still need to fixup the texture offsets (in the FIFO) for the other textures in use
03:39 < darktama_> I don't think that came out clearly..
03:40 < marcheu> yeah, or move everything as a single chunk
03:40 < darktama_> yes, which could be quite costly if you have a lot of big textures
03:41 < darktama_> and there's no guarantee you'd find a large enough free chunk
03:41 < marcheu> It'd be really weird that there is such a limitation
03:41 < darktama_> yes, if that's the case, it's quite a bad design compared to the rest of the GPU
03:44 -!- Duke` [n=gnu@ANantes-251-1-173-50.w90-12.abo.wanadoo.fr] has quit [Success]
03:44 -!- `Duke` is now known as Duke`
03:48 < darktama_> about context switching, is there a FIFO enable reg that needs to be set?  the reg we're using chooses between PIO/DMA mode for a FIFO
03:49 < marcheu> well, I caught that one using a diff of register state...
03:49 < marcheu> there were a couple of other suspects
03:50 < marcheu> basically, I did a reg dump, launched glxgears, did another dump, looked for the needle in the haystack
03:50 < marcheu> there are probably a couple other needles around
03:50 < darktama_> hmm, might be worth looking.. but, I don't recall nvosdk doing anything like that
03:50 < marcheu> well, at least you can't deny the PIO/DMA reg was needed
03:51 < darktama_> indeed
03:51 < marcheu> I don't think nvosdk did it either
03:51 < darktama_> hmm, I'll try and take another look at context switching soonish, I've been too busy playing with EXA and some shader stuff lately
03:52 < marcheu> hmm nvosdk touches it
03:52 < darktama_> PFIFO_MODE?
03:52 < marcheu> yes
03:53 < darktama_> yeah, nv04setupdma (or whatever) should set the channel's bit to 1.. nv03setuppio should clear it
03:53 < marcheu> that's what it does right now
03:53 < marcheu> it also setups a couple of other stuff
03:54 < marcheu> which I think we lack
03:54 < darktama_> our code for that is really not correct in any way (my bad) :)
03:59 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has quit ["<blank>"]
04:05 -!- Duke` [n=gnu@ANantes-251-1-174-213.w90-12.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
04:08 < darktama_> marcheu: so, nouveau compiles now.. does it work (as in software fallbacks for everything)?
04:09 < marcheu> darktama_: no, I didn't even try it, the DRI common init code is probably lacking all around
04:09 < marcheu> also, the locking has to be redone, and we need to figure out how to handle cliprects
04:09 < marcheu> we don't need locking for anything else than cliprects
04:09 < marcheu> that'll probably require a per-context lock in the sarea
04:10 < darktama_> I see
04:10 < marcheu> yeah, also, if we do a lock-free driver we have one huge advantage : we can run it under gdb
04:11 < marcheu> recall all those times where you'd have killed to gdb radeon_dri.so ? :)
04:13 < darktama_> hehe, yes :) fun times
04:14 < darktama_> btw, I really like the idea of a "debugging mode" where everything is printed to the console instead of put in the FIFO
04:19 < marcheu> also, I don't think falling back to software will help us much (except for testing the buffer swap code)
04:19 < marcheu> (and the span code)
04:19 < marcheu> ok, that's 2 things already
04:19 < darktama_> and for testing the shader assembly
04:20 < marcheu> hmm ?
04:21 < darktama_> well, not testing as in "works on the hardware".. but as in I could write shaders, dump the output, and disasm with renouveau to see if it looks ok
04:21 < marcheu> ah, you're talking about the debugging mode
04:22 < marcheu> I was talking about falling back to software for everything
04:28 < marcheu> ok, at least I get a texture-sized object
04:29 < marcheu> not sure about multitexturing yet
04:29 < darktama_> hm, really? nice
04:29 < darktama_> is it referenced in the 3D object command stream?
04:30 < marcheu> I didn't dump the stream
04:30 < marcheu> I wrote yet another stand alone tool
04:30 < marcheu> (ahem)
04:31 < darktama_> ahh, I use nvclock quite a bit.. I think I now have more #if 0 <some_test> #endif's than the rest of the nvclock code :)
04:33 -!- johnnybuoy [n=void@nilus-268.adsl.datanet.hu] has quit ["Leaving"]
04:41 < darktama_> hm, that's interesting if there are dedicated objects for textures.. I use multitexture in my EXA code
04:41 < darktama_> might be one of the reasons it doesn't work without using nvidia first
04:42 < marcheu> not sure yet, it doesnt' look like it works all the time
04:50 < marcheu> yeah, it looks like the 4MB object I saw for my texture was a single-use dma
04:53 < marcheu> hmm what's a "rankine object" (#nvidia) ?
05:03 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 113 (No route to host)]
05:26 -!- kjaqo829 [n=kjaqo829@ip68-4-255-242.oc.oc.cox.net] has joined #nouveau
05:29 -!- kjaqo829 [n=kjaqo829@ip68-4-255-242.oc.oc.cox.net] has left #nouveau ["Leaving"]
05:51 -!- b33fc0d3 [n=bifter@never.sm0ke.me.uk] has joined #nouveau
06:21 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has joined #nouveau
06:35 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has left #nouveau ["If someone tries to kill you, you just try and kill 'em right back."]
06:38 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
06:47 -!- hiyuh_work [n=hiyuh@Y041248.ppp.dion.ne.jp] has joined #nouveau
06:50 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has quit [Read error: 110 (Connection timed out)]
07:06 -!- tibbs|h is now known as tibbs
08:13 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has quit ["<blank>"]
09:31 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
09:46 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
10:24 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
10:31 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
11:19 -!- Duke` [n=gnu@ANantes-251-1-174-213.w90-12.abo.wanadoo.fr] has joined #nouveau
11:24 -!- EdB [n=EdB@ARennes-251-1-50-99.w81-53.abo.wanadoo.fr] has joined #nouveau
12:00 -!- hiyuh_work [n=hiyuh@Y041248.ppp.dion.ne.jp] has quit [Read error: 54 (Connection reset by peer)]
12:01 -!- hiyuh_work [n=hiyuh@Y041248.ppp.dion.ne.jp] has joined #nouveau
13:31 -!- rem [i=rem@ALyon-252-1-31-162.w82-122.abo.wanadoo.fr] has joined #nouveau
13:31 < rem> 'lo
13:51 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
14:22 -!- Ash_Crow [n=Ash_Crow@ARennes-351-1-23-252.w82-126.abo.wanadoo.fr] has joined #nouveau
14:23 -!- Ash_Crow [n=Ash_Crow@ARennes-351-1-23-252.w82-126.abo.wanadoo.fr] has left #nouveau ["Leaving"]
14:23 -!- Maduser [n=maduser@d170206.adsl.hansenet.de] has joined #nouveau
14:24 < Maduser> Hello, I have made dumps with my GeForce FX 5600 (NV31)
14:24 < Maduser> I put then under http://stud.fh-wedel.de/~winf2163/
14:27 < Maduser> It is good to upload or should I mail the dumps to someone?
14:28 < Duke`> upload is good
14:31 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
14:35 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
14:44 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has left #nouveau []
14:45 < EdB> mmm
14:46 < EdB> nv_dma.c:357: error: 'NOUVEAU_SETPARAM_CMDBUF_LOCATION' undeclared (first use in this function)
14:46 < EdB> with xfree-nouveau driver
14:56 -!- EdB [n=EdB@ARennes-251-1-50-99.w81-53.abo.wanadoo.fr] has quit ["Konversation terminated!"]
14:58 -!- glisse [n=glisse@lpnp78.in2p3.fr] has joined #nouveau
15:24 < marcheu> EdB: you forgot to install the drm header first
15:40 -!- Maduser [n=maduser@d170206.adsl.hansenet.de] has quit ["Leaving."]
16:04 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:04 -!- airlied [n=airlied@skynet.skynet.ie] has quit [Read error: 104 (Connection reset by peer)]
16:05 -!- airlied [n=airlied@skynet.skynet.ie] has joined #nouveau
16:12 -!- johnnybuoy [n=void@nilus-268.adsl.datanet.hu] has joined #nouveau
16:40 -!- airlied [n=airlied@skynet.skynet.ie] has quit [Read error: 104 (Connection reset by peer)]
16:40 -!- airlied [n=airlied@skynet.skynet.ie] has joined #nouveau
16:57 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit ["Leaving"]
17:27 -!- jkolb [n=jkolb@wsi-128-213.wsi.com] has joined #nouveau
17:33 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
17:45 -!- rem [i=rem@ALyon-252-1-31-162.w82-122.abo.wanadoo.fr] has quit ["reboot"]
17:49 -!- rem [i=rem@ALyon-252-1-31-162.w82-122.abo.wanadoo.fr] has joined #nouveau
18:20 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
18:42 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
19:09 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit ["Leaving"]
19:12 -!- hiyuh_work is now known as hiyuh
19:30 -!- EdB|l [n=EdB@212.234.68.206] has joined #nouveau
19:40 -!- hiyuh [n=hiyuh@Y041248.ppp.dion.ne.jp] has quit ["Leaving"]
19:44 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:47 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
19:53 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
20:10 -!- predatorfreak [n=predator@adsl-75-46-41-247.dsl.sfldmi.sbcglobal.net] has joined #nouveau
20:16 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has joined #nouveau
20:30 -!- phh [n=phh@moi.phhusson.info] has quit [Remote closed the connection]
20:38 -!- phh [n=phh@2001:6f8:372:cafe:20c:76ff:fe96:8bb0] has joined #nouveau
20:44 -!- phh [n=phh@2001:6f8:372:cafe:20c:76ff:fe96:8bb0] has quit [Remote closed the connection]
20:46 -!- elsewhereunknown [n=elsewher@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
20:50 -!- rem [i=rem@ALyon-252-1-31-162.w82-122.abo.wanadoo.fr] has quit ["out"]
20:51 -!- elsewhereunknown [n=elsewher@82-168-177-167.dsl.ip.tiscali.nl] has quit [Remote closed the connection]
20:52 -!- jkolb [n=jkolb@wsi-128-213.wsi.com] has quit ["Leaving"]
20:54 -!- elsewhereunknown [n=elsewher@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
20:55 -!- phh [n=phh@2001:6f8:372:cafe:20c:76ff:fe96:8bb0] has joined #nouveau
21:01 -!- pmdata [i=patrice@ANantes-154-1-69-26.w86-195.abo.wanadoo.fr] has joined #nouveau
21:02 -!- elsewhereunknown [n=elsewher@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Bye"]
21:18 -!- johnnybuoy [n=void@unaffiliated/johnnybuoy] has quit ["Leaving"]
21:18 -!- jkolb [n=jkolb@wsi-128-213.wsi.com] has joined #nouveau
21:47 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
22:22 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
22:31 -!- jkolb [n=jkolb@wsi-128-213.wsi.com] has quit ["Leaving"]
22:38 < marcheu> pmdata: did you see my commit ? my nv11 has the same object as the nv15 and nv17/18
22:38 < marcheu> pmdata: I think all nv10 have that one, but I have no (and know of no one who has) a real geforce 1
22:40 < pmdata> mat has a nv10, the dumps are from him for nv10
22:41 < pmdata> I remember a friend has a gf1, I could ask him
22:41 < marcheu> hmm, and what object does it use ?
22:41 < marcheu> the nv10
22:44 < marcheu> ah, 0x56
22:44 < marcheu> so 0x56 is used on original geforces only it seems
22:45 < pmdata> nv11 = nv17 without lma?
22:45 < pmdata> maybe that's why they are called gf2mx
22:46 < marcheu> not sure
22:46 < marcheu> my gf2mx has the 0x1196 variant
22:46 < marcheu> what do other cards have ?
22:46 < pmdata> could you remake dumps for nv11?
22:46 < marcheu> yes, I even have the proprietary driver right now
22:47 < pmdata> or nv11 always use object 96?
22:47 < marcheu> what do you mean "always" ?
22:47 < pmdata> it use object 96 in your dumps
22:47 < marcheu> it uses 1196, yes
22:47 < marcheu> yup
22:47 < pmdata> I listed in nv_objects.h the stuff missing on the nv10, object 56
22:49 < pmdata> 120-128, and 3f0
22:49 < pmdata> but I think 3f0 is triggered only when fsaa enabled
22:49 < marcheu> pmdata: btw what crashed your card in test_interesting_regs ?
22:49 < pmdata> I wonder what 120-128 could be, related to nv_image_blit object
22:49 < marcheu> I'd like to have it on...
22:50 < marcheu> I need this data
22:50 < pmdata> I don't know, there is some stuff listed as nv40 there
22:50 < marcheu> ok, I'll make it card-dependent and see if it crashes for you
22:51 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
22:53 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
22:54 < marcheu> pmdata: also, did you see I updated the TODO about what wan be done in the DRI
22:54 < marcheu> or maybe I told you before..
22:55 < pmdata> yep, I see that
22:55 < pmdata> should be easy using dumps for swap buffers
23:00 -!- EdB|l [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
23:05 < marcheu> hmm
23:06 < marcheu> it depends how we implement it
23:06 < pmdata> just updated nvobjecttypes with the new found ones
23:06 < marcheu> either we go with the DMA queue idea, and say that swap buffers require working DMA queue which in turn requires working context switches
23:07 < marcheu> or we implement a swap buffers ioctl or even a user space hack
23:07 < pmdata> I want page flipping :)
23:08 < marcheu> yeah, you still need buffer copies when >1 window
23:08 < marcheu> so if you want page flipping, you can add an option to the DDX
23:08 < marcheu> it means :
23:08 < marcheu> - create two video buffers
23:08 < marcheu> - duplicate 2D operations on both buffers
23:09 < marcheu> - program the CRTC to switch between the two
23:09 < pmdata> the nvidia driver only uses page flipping in the case of a fullscreen app
23:09 < marcheu> well, except on quadro cards
23:09 < pmdata> ah?
23:09 < marcheu> which have UBB which is exactly what I described
23:10 < marcheu> but yeah, we could limit page flipping to full screen situations
23:10 < marcheu> that would prevent the ugly 2D duplication code
23:11 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
23:14 < pmdata> does the planned memory manager would use a slab allocator? for big chunks (framebuffer), medium (textures), low (display lists, vertex array)?
23:16 < marcheu> not sure it would be useful, slab allocators are nice when you have lots of objects whose size is known in advance
23:16 < pmdata> I read you talk about fragmentation earlier, which is a problem for video memory
23:17 < marcheu> I'm not even sure if we will use our own memory manager or switch to the DRM one
23:17 < marcheu> well, for fragmentation, one easy workaround to limit it is putting small objects at the end, and big at the beggining
23:17 < pmdata> yep
23:17 < marcheu> failing that, we could always move stuff that sits in vram, we will have to anyway at some point
23:18 < stillunknown> anything interresting happen lately?
23:18 < marcheu> stillunknown: if something happened, I'm not guilty ! :)
23:18 < pmdata> "look, it's a bird!"
23:20 < pmdata> if you need vertex output the quadro way, look at nv10/test_default dump
23:20 < pmdata> it just fills the _VERTEX_POS_ commands in fifo
23:20 < marcheu> well I don't think we'll be able to use it
23:20 < marcheu> because mesa will change the vertex format when the gl*f commands differ
23:21 < pmdata> ah
23:21 < marcheu> so that we actually end up in a situation where it recreates a new buffer anyway
23:21 < marcheu> which is really the "geforce way"
23:22 < marcheu> anyway, that's not where performance comes from
23:26 -!- phh [n=phh@2001:6f8:372:cafe:20c:76ff:fe96:8bb0] has quit [Remote closed the connection]
23:27 < stillunknown> i kind of stopped using nouveau for the moment, because i need nvidia's better xrender implementation and my mailbox has been pretty quiet about nouveau
23:27 < marcheu> stillunknown: well, there is the context switch roadblock right now
23:27 < marcheu> which I'm investigating
23:27 < marcheu> but only with a few time in my hands
23:28 < stillunknown> maybe you should write a request to your government to make days longer :-)
23:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit ["Les choses que l'on possède, finissent par nous posséder"]
23:36 < pmdata> nah, they will tax longer days because people are more productive
23:47 -!- __sha__ [n=Sha@stern.ulb.ac.be] has joined #nouveau
--- Log closed Чтв Сен 21 00:00:43 2006
