--- Log opened Вск Сен 17 00:00:40 2006
00:20 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has quit ["gone"]
00:28 -!- shenki [n=shenki@ppp129-67.lns3.adl2.internode.on.net] has quit [Read error: 60 (Operation timed out)]
00:28 -!- `Duke` [n=gnu@86.72.170.217] has quit [Remote closed the connection]
00:30 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
00:33 -!- anders__ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
00:34 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
00:40 -!- shenki [n=shenki@ppp98-246.lns4.adl2.internode.on.net] has joined #nouveau
00:46 -!- Myrizio [n=Myrizio@host171-101-static.104-80-b.business.telecomitalia.it] has joined #nouveau
00:48 -!- EdB [n=EdB@ARennes-251-1-79-37.w86-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:50 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
01:00 -!- shenki [n=shenki@ppp98-246.lns4.adl2.internode.on.net] has quit [Read error: 60 (Operation timed out)]
01:10 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
01:11 -!- shenki [n=shenki@ppp98-246.lns4.adl2.internode.on.net] has joined #nouveau
01:12 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
01:15 -!- `Duke` [n=gnu@86.72.170.217] has joined #nouveau
01:50 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
01:51 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
02:02 -!- `Duke` [n=gnu@86.72.170.217] has quit ["Segmentation fault"]
02:08 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Client Quit]
02:20 -!- predatorfreak [n=predator@adsl-69-212-52-66.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
02:26 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
02:26 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
03:03 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 113 (No route to host)]
03:08 -!- marteus [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
03:08 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
03:37 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 113 (No route to host)]
03:39 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
04:14 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
04:19 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
04:27 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
04:35 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Read error: 110 (Connection timed out)]
04:47 -!- dfryer [n=dfryer@d207-216-29-18.bchsia.telus.net] has quit [Remote closed the connection]
04:47 -!- dfryer [n=dfryer@d207-216-29-18.bchsia.telus.net] has joined #nouveau
04:50 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 113 (No route to host)]
04:51 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
04:51 -!- cetrox [i=cetrox@214-244-222-201.adsl.terra.cl] has quit [Remote closed the connection]
04:51 -!- cetrox [i=cetrox@214-244-222-201.adsl.terra.cl] has joined #nouveau
04:56 -!- darktama [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
04:57 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has quit [Read error: 110 (Connection timed out)]
04:58 -!- dfryer [n=dfryer@d207-216-29-18.bchsia.telus.net] has quit [Remote closed the connection]
05:23 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
05:27 -!- ag [i=ag@caladan.roxor.cx] has quit [Read error: 110 (Connection timed out)]
05:27 -!- shenki_ [n=shenki@ppp98-246.lns4.adl2.internode.on.net] has joined #nouveau
05:29 -!- ag [n=ag@caladan.roxor.cx] has joined #nouveau
05:29 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
05:34 -!- ag [n=ag@caladan.roxor.cx] has quit [Remote closed the connection]
05:40 -!- ag [n=ag@caladan.roxor.cx] has joined #nouveau
05:55 -!- anders__ [i=andersg@0x63.nu] has joined #nouveau
05:57 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 113 (No route to host)]
06:38 -!- monocle [n=glass@dsl092-185-225.sfo1.dsl.speakeasy.net] has joined #nouveau
06:48 -!- ag [n=ag@caladan.roxor.cx] has quit [Remote closed the connection]
06:50 -!- ag [n=ag@caladan.roxor.cx] has joined #nouveau
06:54 -!- dfryer [n=dfryer@d207-216-29-18.bchsia.telus.net] has joined #nouveau
07:00 -!- qfire_away is now known as qfire
07:01 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
07:01 -!- anders__ [i=andersg@0x63.nu] has quit [Read error: 104 (Connection reset by peer)]
07:10 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit ["leaving"]
07:35 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 104 (Connection reset by peer)]
07:36 -!- Myrizio [n=Myrizio@host171-101-static.104-80-b.business.telecomitalia.it] has quit [Read error: 113 (No route to host)]
07:36 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
08:06 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
08:06 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
09:23 -!- cetrox_ [i=cetrox@12-240-222-201.adsl.terra.cl] has joined #nouveau
09:26 -!- cetrox [i=cetrox@214-244-222-201.adsl.terra.cl] has quit [Read error: 60 (Operation timed out)]
09:51 -!- shenki_ [n=shenki@ppp98-246.lns4.adl2.internode.on.net] has quit ["Leaving"]
10:22 -!- dfryer is now known as dfryer|away
12:26 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
12:46 -!- `Duke` [n=gnu@86.72.170.214] has joined #nouveau
12:59 -!- EdB [n=EdB@ARennes-251-1-85-249.w86-199.abo.wanadoo.fr] has joined #nouveau
13:52 -!- pmdata [i=patrice@ANantes-154-1-3-151.w81-53.abo.wanadoo.fr] has joined #nouveau
14:01 -!- predatorfreak [n=predator@adsl-69-212-44-252.dsl.sfldmi.ameritech.net] has joined #nouveau
14:15 -!- Duke` [n=gnu@ANantes-251-1-136-49.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
14:16 -!- Duke` [n=gnu@ANantes-251-1-141-105.w86-210.abo.wanadoo.fr] has joined #nouveau
14:22 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
14:33 -!- pmdata [i=patrice@ANantes-154-1-3-151.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
14:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
14:36 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
14:58 -!- rem [i=rem@ALyon-252-1-55-192.w83-197.abo.wanadoo.fr] has joined #nouveau
14:58 < rem> hello
14:59 -!- caro [n=vincent@alf94-3-82-66-248-160.fbx.proxad.net] has joined #nouveau
15:00 < caro> any news on exa ? is it fixed ?
15:01 < stillunknown> was it broken?
15:02 < stillunknown> (it's been a while since i've used nouveau, since there hasn't been much to test)
15:02 < caro> according to the news 10 days ago
15:03 < caro> http://nouveau.freedesktop.org/wiki/NouveauCompanion_3a <-- this one. It is said that exa is broken
15:07 < stillunknown> what you do not realize is that darktama was testing 3d acceleration through exa, because code that was needed to get multiple "apps" to interact with the card isn't there yet
15:07 < stillunknown> that code is (personal) testing code
15:07 < stillunknown> not what you can grab fro git
15:08 < caro> strange to test 3d through a interface that is supposed to manage 2d :)
15:09 < stillunknown> he wanted to test basic 2d rendering with the 2d engine to see if the actual engine was working
15:09 < stillunknown> *with the 3d engine
15:29 < marcheu> hmm can nv10 do specular color ?
15:32 -!- `Duke` [n=gnu@86.72.170.214] has quit [Remote closed the connection]
15:41 -!- `Duke` [n=gnu@86.72.170.214] has joined #nouveau
15:52 < marcheu> anything against me merging the memory testing code in drm ?
16:07 < marcheu> hahaha nouveau_dri.so complies
16:07 < marcheu> compiles
16:08 -!- kylem_ [n=kyle@cabal.ca] has joined #nouveau
16:09 -!- kylem [n=kyle@cabal.ca] has quit [Read error: 104 (Connection reset by peer)]
16:26 -!- predatorfreak [n=predator@adsl-69-212-44-252.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
16:33 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 104 (Connection reset by peer)]
16:33 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
16:43 -!- profy [n=zef@seg75-5-82-234-115-82.fbx.proxad.net] has joined #nouveau
16:45 -!- Myrizio [n=Myrizio@host93-102-static.104-80-b.business.telecomitalia.it] has joined #nouveau
16:47 -!- Myrizio [n=Myrizio@host93-102-static.104-80-b.business.telecomitalia.it] has quit [Client Quit]
16:47 -!- Myrizio [n=Myrizio@host93-102-static.104-80-b.business.telecomitalia.it] has joined #nouveau
16:49 -!- Gusar [n=Gusar@cpe1-23-67.cable.triera.net] has quit ["leaving"]
16:54 < rem> re
17:10 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 110 (Connection timed out)]
17:14 -!- marteus [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
17:17 < marcheu> koala, are you around ?
17:17 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
17:50 -!- anders_ [i=andersg@0x63.nu] has quit [Read error: 113 (No route to host)]
17:55 -!- ag [n=ag@caladan.roxor.cx] has quit [Remote closed the connection]
17:56 -!- ag [n=ag@caladan.roxor.cx] has joined #nouveau
18:07 -!- profy [n=zef@seg75-5-82-234-115-82.fbx.proxad.net] has quit [Read error: 113 (No route to host)]
18:07 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
18:08 -!- profy [n=zef@seg75-5-82-234-115-82.fbx.proxad.net] has joined #nouveau
18:26 -!- ag [n=ag@caladan.roxor.cx] has quit [Remote closed the connection]
18:27 -!- ag [n=ag@caladan.roxor.cx] has joined #nouveau
18:45 -!- ag [n=ag@caladan.roxor.cx] has quit [Read error: 104 (Connection reset by peer)]
18:47 < caro> I have a geforce 2 GTS
18:47 < caro> is there some data that you (the devs) don't have and want ?
18:47 < caro> (about that card)
18:48 < marcheu> I don't think so. pmdata has one, and he's been trying pretty much everything that was possible with that card
18:49 -!- ag [n=ag@caladan.roxor.cx] has joined #nouveau
18:54 < phh> mm nouveau compile, means there is something useable for 3D ?
18:54 < marcheu> no, only that it compiles
18:55 < marcheu> that's a required step, though
18:55 < EdB> any progress on bios init ,
18:55 < phh> ok
18:55 < EdB> ?
18:56 < marcheu> not from me
18:56 < marcheu> airlied: btw it would be nice if you could fix #8109, the sitewranglers don't seem to care
19:09 < caro> marcheu: ok
19:36 -!- profyy [n=zef@seg75-5-82-234-115-82.fbx.proxad.net] has joined #nouveau
19:36 -!- profy [n=zef@seg75-5-82-234-115-82.fbx.proxad.net] has quit [Read error: 110 (Connection timed out)]
19:43 -!- `Duke` [n=gnu@86.72.170.214] has quit ["Segmentation fault"]
20:16 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
20:25 < marcheu> darktama: ping
20:25 < marcheu> darktama: I think we should push the flags from NVDmaCreateContextObject into the drm instead of having the code in the DDX
20:26 < rem> I'm really surprised to see so much differences for only clearing depth buffer on nv3x cards and it's worse when compared to a nv28 (by example)
20:27 -!- pmdata [i=patrice@ANantes-154-1-42-167.w81-53.abo.wanadoo.fr] has joined #nouveau
20:28 < phh> rem, we say for instance or for example but never by example (saloperie de francais.)
20:28 < rem> oups =)
20:30 < marcheu> rem: that's why we need you as a developer !
20:30 < rem> :)
20:32 < rem> marcheu: why not, what for ?
20:33 < marcheu> whatever you feel like, that's how open source projects work :)
20:33 < marcheu> do you have a particular goal ?
20:34 < marcheu> if it's too big, maybe I can break it into pieces for you
20:35 < rem> marcheu: personaly, i write visualization tools with OpenGL and have few knownledge on how hardware works
20:37 < marcheu> good, I write visualization tools with OpenGL as well
20:37 < rem> so I get the features matrix on nouveau..fd.org and get the first "yes" for my nv34 and start reading the dumps
20:37 < marcheu> I'm into volume visualization, more specifically
20:37 < rem> 'k
20:38 < marcheu> so you probably have a good grasp of the opengl API, and you can code. I think that's more than enough
20:38 < darktama> marcheu: so, from the ddx point of view you want just to do CreateContextObject(pNv, class)?
20:39 < marcheu> darktama: well, I was adding object creation to the DRI
20:39 < marcheu> darktama: and I almost cut & pasted the DDX object code
20:39 < marcheu> but then I thought that was just plain wrong
20:40 < darktama> well, I think the whole context object creation is wrong :)  even if it is moved into the ddx
20:40 < marcheu> in particular, the flags handled by NVDmaCreateContextObject should beau into the drm I think
20:40 < marcheu> s/beau/go
20:40 < darktama> I started removing the flags and dma_in/dma_out/dma_notify last week sometime, and replacing them with FIFO commands instead
20:41 < marcheu> ok, I'll let you stabilize the interface then
20:41 < marcheu> just pointing out that it will be used from the DRI as well
20:43 < marcheu> darktama: also, do you think it will be feasible to use the object stuff to handle memory moves transparently ?
20:43 < darktama> I hadn't even considered the DRI yet :)
20:43 < marcheu> I absolutely want to avoid all fifo rewrites by the drm, because that basically kills the advantages of having multiple hw contexts
20:44 < darktama> well, I don't know.. I have my doubts that the object system is granular enough to have say, an object for *each* texture image unit
20:44 < darktama> I don't want to rewrite the FIFO either, the drm shouldn't touch it at all imho
20:44 < marcheu> yup
20:44 -!- ag [n=ag@caladan.roxor.cx] has quit [Read error: 104 (Connection reset by peer)]
20:45 < marcheu> I think we have to act pretty fast on that one, because the memory manager desing will get frozen real soon
20:45 < marcheu> if we have strong concerns about it, we should voice them
20:45 -!- ag [n=ag@caladan.roxor.cx] has joined #nouveau
20:45 < marcheu> (or we will end up having our own memory manager)
20:45 < darktama> I guess we should find out if we have an individual object for every place we can stick an address
20:48 < darktama> also, is there any performance issues with changing object entries that often? does the GPU cache them somewhere?
20:48 < marcheu> it's probably negligible compared to the cost of moving the memory chunk itself
20:49 < darktama> hm, true
20:50 -!- phh [n=phh@moi.phhusson.info] has quit [Remote closed the connection]
20:50 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
20:53 < darktama> marcheu: I'm still not sure if it's possible to replace all the flags with FIFO commands.. on nv40, the RAMIN entries after the FIFO-based setup are quite different to what we currently do
20:54 < darktama> but, it does *seem* to work
20:54 < marcheu> hmm, you don't have to move the flags into fifo commands... what I'm wanting is that the NVDmaCreateContextObject doesn't end up being duplicated in DDX & DRI
20:56 < darktama> yup, I think for now we could just move it to the DRM then.  I like the FIFO way better if it's possible however, but it's not too important yet
20:57 < marcheu> yeah, they don't hurt anyway, unless I'm missing something
20:58 < marcheu> but anyway, in your opinion the object way is not feasible ?
20:59 < marcheu> (object way of handling movable memory chunks)
21:00 < darktama> if we have an individual object that covers each output buffer, vertex buffer, texture unit (etc) - then I think it would be.. but if we only have one object that covers all texture units we may have a problem
21:01 < marcheu> yeah, but can we do that ? I mean, I'm not even sure taht'd work with, say, vertex buffers
21:01 < darktama> eh?
21:01 < marcheu> IIRC the vertex buffers have the offset in AGP area put directly
21:03 < darktama> I think 0x19C/0x1A0 are related to vertex buffers in NV30_TCL - I haven't tested them yet though
21:03 -!- phh [n=phh@moi.phhusson.info] has quit ["Quitte"]
21:03 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
21:10 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
21:10 < marcheu> hmm, I hope it's the same on nv10/20/whatever then
21:12 < darktama> yup, if it is - then I think modifying the objects should work
21:12 < darktama> I'm about to write a test using all 16 texture image units and see if I get a lot more object refs in the fifo
21:13 < marcheu> when looking at the proprietary driver, I used to see a lot of objects, so I hope that's how it works
21:13 < marcheu> if that's the case, we have our silver bullet
21:13 < darktama> nvidia just seems to use a blanket object covering the entire FB (0xbeef0201) and the entire AGP (0xbeef0202) - I wonder how they handle moving memory around
21:14 < marcheu> that doesn't prevent overlapping objects
21:26 -!- nael_ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
21:33 -!- kylem_ [n=kyle@cabal.ca] has quit ["leaving"]
21:37 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Success]
21:37 -!- nael__ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
21:38 -!- nael_ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Connection reset by peer]
21:42 -!- Myrizio [n=Myrizio@host93-102-static.104-80-b.business.telecomitalia.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
21:43 -!- Gusar [n=Gusar@cpe1-23-67.cable.triera.net] has joined #nouveau
21:55 < darktama> hmm, there doesn't seem to be an object for each texunit.. but, I think I forced some of the textures into AGP - just no idea how that works exactly..
21:56 < marcheu> what do you mean "forced" ?
21:56 < darktama> made massive textures so that 16 of them won't fit into vram
21:56 < marcheu> ah
21:57 < rem> sorry but is there a way to send to the GPU its own "command" while using nvidia's driver ?
21:58 < marcheu> also, I was wondering how 2D drivers will handle the new memory allocator when stuff moves underneath
21:58 < marcheu> rem: yeah, darktama has a tool for just that
21:58 < phh> rem, it's what libGL does
21:58 < rem> :)
21:59 < rem> phh: i want to mix nvidia's call and mine
21:59 < darktama> rem: http://members.iinet.net.au/~darktama/nvtest.tar.bz2
21:59 < phh> rem, just need to get the /dev/nvidia0 fd and that's it
22:00 < darktama> you probably won't be able to make GL calls after you've sent your own commands
22:00 < darktama> but you can beforehand
22:00 < rem> according to dumps, nv34 don't work like nv31m and nv38 (maybe add nvidia some dummy call to slow down the card)
22:01 < rem> darktama: thx
22:01 < marcheu> yeah, nv34 has slight differences
22:01 < phh> to slow down card ?
22:01 < phh> huhu
22:02 < marcheu> http://en.wikipedia.org/wiki/Comparison_of_NVIDIA_Graphics_Processing_Units
22:02 < marcheu> * = NV31, NV34 and NV36 are 2x2 pipeline designs if running pixel shaders, otherwise they are 4x1.
22:02 < rem> 7 SRCCOPY (and 1 which only 2 commands (instead of 4)), it's really strange
22:03 < rem> -which+with
22:04 < rem> wikipedia seems to be really usefull :P
22:05 < phh> hum... where to find nv40_reg.h ?
22:05 < phh> generate ?
22:05 < darktama> hm, it doesn't exist anymore :S
22:05 < darktama> actually, it might still be in the DRI sources
22:10 < darktama> marcheu: so.. if we can't easily do the object modification idea, what are our options?
22:11 < darktama> not including FIFO modification :)
22:14 -!- pmdata [i=patrice@ANantes-154-1-42-167.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
22:15 -!- marteus_ [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
22:15 < marcheu> darktama: no idea
22:16 < marcheu> darktama: that's the issue
22:16 < marcheu> right now the options are :
22:16 < marcheu> - object modification
22:16 < marcheu> - fifo touchup (boo)
22:16 < marcheu> - our own memory manager
22:16 < marcheu> that's it
22:19 < marcheu> (- request changes in the TTM manager real quick, asking for an alternate interface without handles and with locking)
22:20 -!- marteus [n=marteus@0x50c475bf.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
22:20 < marcheu> maybe that's worth a post to dri-devel@
22:22 < darktama> yeah, that's probably a good idea
22:23 < marcheu> you see, we could probably move forward with our own memory manager, but I expect the TTM one to become the standard EXA memory manager
22:32 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
22:44 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Connection timed out]
22:45 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit ["Les choses que l'on possède, finissent par nous posséder"]
22:54 < marcheu> ok, mail sent
22:55  * darktama_ reads
22:56 < marcheu> I hope my mail is clear enough
22:56 < marcheu> I'm still not a native speaker :)
22:56 < marcheu> "does can not" <- ahem
22:57 < darktama_> hehe :)
22:58 < darktama_> hmm, can we do a "pin" operation on handles?  and just add pin/unpin around the commands that need the buffers.  the unpin would probably have to be triggered by a notifier
22:59 < marcheu> yeah, that's what we thought at first, but airlied for example was against the idea of letting arbitrary processes pin arbitrary regions
22:59 < marcheu> I'm letting other people suggesting the idea though :)
22:59 < darktama_> yeah, I think I will too :) memory management isn't something I know much (anything?) about
23:00 < marcheu> well, given how I phrased the email, that solution will probably come out as ibvious
23:00 < marcheu> obvious
23:01  * darktama_ wonders how many people won't see the PS bit
23:01 < marcheu> hehe
23:01 -!- darktama_ is now known as darktama
23:02 < marcheu> yeah, I'm trying to make the discussion constructive
23:02 < marcheu> instead of 10 posts saying "crappy model !"
23:06 -!- nael__ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Remote closed the connection]
23:06 -!- nael__ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
23:35 -!- nael_ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
23:35 -!- nael__ [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Read error: 104 (Connection reset by peer)]
23:43 -!- phh [n=phh@moi.phhusson.info] has quit [Remote closed the connection]
23:44 -!- Myrizio [n=Myrizio@host93-102-static.104-80-b.business.telecomitalia.it] has joined #nouveau
23:52 -!- cetrox_ [i=cetrox@12-240-222-201.adsl.terra.cl] has quit [Remote closed the connection]
23:52 -!- cetrox [i=cetrox@12-240-222-201.adsl.terra.cl] has joined #nouveau
23:58 -!- cetrox [i=cetrox@12-240-222-201.adsl.terra.cl] has quit [Remote closed the connection]
23:59 -!- cetrox [i=cetrox@12-240-222-201.adsl.terra.cl] has joined #nouveau
--- Log closed Пнд Сен 18 00:00:40 2006
