--- Log opened Втр Июл 11 00:00:48 2006
00:07 -!- svu [n=svu@194.46.164.241] has joined #nouveau
00:20 < colbert> I did do something foolish. the default buffer is front_left so i should check right first or else there wont be a change.
00:20 < marcheu> did you create a stereo visual now ?
00:20 < colbert> still working on it
00:36 < colbert> Hmmm.. might have to rethink how i'm doing this. can call glGetBooleanv() but the driver will reoprt no stereo visuals(havnt tried yet) whether the hardware will do it or not. also i can call glGetIntegerv() to find how many aux buffers there are. mayby the streo buffers are hiding as aux buffers on geforce
00:56 < marcheu> Lumag: http://icps.u-strasbg.fr/~marchesin/nvdri/
00:56 < marcheu> Lumag: http://icps.u-strasbg.fr/~marchesin/nvdri/nv44_ioctl_lumag.txt
01:02 < Lumag> Yeah. Thanks. I already got nearly the same dumps from darktama_. There is one thing that bugs me: The objects aren't created from the RAMIN.
01:02 < marcheu> yeah, it took me some time to plug the nv44
01:02 < marcheu> and I'm going to unplug it soonish anyway
01:03 < Lumag> If you look for results of object creation, the RAMHT is filled with object name & context, but there are no more changes to RAMIN
01:03 < marcheu> hmm, for my card too ?
01:03 < marcheu> I didn't look at it actually
01:05 < Lumag> Hmm... Wait a minute, please. I think I misunderstood ioctls. First object is created and only then placed in HT...
01:05  * Lumag is searching for the dump from darktama_...
01:06 < marcheu> pmdata: also, there's that : http://icps.u-strasbg.fr/~marchesin/nvdri/nvclock-softquadro.tgz
01:07 < marcheu> pmdata: it "turns" your gf into a quadro, so that we can do RE on "quadro" and see if, for example, clip planes start to work
01:07 < marcheu> pmdata: build, then run nvclock -Q _before_ you start X. and that's it
01:08 < Lumag> marcheu: No, your dump looks ok. There is really something strange with the darktama's card :)
01:08 < marcheu> it works on my gf2 gts & on my gf4 ti
01:08 < marcheu> Lumag: yeah, I know
01:08 < marcheu> Lumag: I was thinking, maybe the reason was that he has 256mb while I have 128, and then RAMIN si in video ram ?
01:09 < marcheu> since he has lots of video ram, that could be the reason...
01:09 < Lumag> Maybe. Or maybe the reason lies somewhere near words x86_64 :)
01:09 < marcheu> yeah, that too
01:09 < marcheu> we'd need a lot more machines, and a lot more cards :)
01:10 < marcheu> actually
01:10 < marcheu> I can give it a shot on a x86_64 pci-e g70 if you like
01:14 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/g70_ioctl_lumag.txt
01:16  * Lumag is reading logs ...
01:16 < pmdata> marcheu> will try it later
01:17 < marcheu> try it when you like, it's just another tool :)
01:17 < Lumag> marcheu: Yes, there are no writings to RAMIN!
01:17 < marcheu> Lumag: yup, so maybe x86_64...
01:17 < marcheu> or maybe ramsize, since it's 256mb as well..
01:18 < marcheu> I have acces to an x86_32 machine with a 6800 at work, I'll try 
01:18 < Lumag> :)
01:18 < marcheu> anyway, this doesn't answer the question, where is RAMIN
01:19 < pmdata> anything I should know before running it?
01:19 < marcheu> pmdata: no, just disable qt/gtk in the configure, since it's failure prone
01:19 < marcheu> it should work without issues on your card, I have almost the same card
01:19 < pmdata> so I run it, then run renouveau?
01:20 < marcheu> yes; you run it before starting X
01:20 < marcheu> with -Q
01:20 < pmdata> ah
01:20 < marcheu> then start X and glxinfo et al. will beleive you have a quadro
01:20 < pmdata> do you know what extra features should be available on quadro?
01:20 < marcheu> then just act as if it was a quadro, and see how the nvidia driver does stuff differently (or maybe not, I didn't test it)
01:21 < marcheu> in X you can enable stuff like UBB, page flipping, stereo opengl
01:21 < marcheu> in 3D, smooth lines should be faster
01:21 < marcheu> I wanted to benchmark with specviewperf, but their website is at 8kb/second, and the whole benchmark is 400 megabytes...
01:22 < marcheu> it will also activate RGB overlays on some cards, don't remember if geforce 2 is one of those
01:26 < pmdata> hum, rgb overlays would be nice to have
01:27 < marcheu> yeah, provided they're not emulated in software..
01:27 < pmdata> of course
01:28 < pmdata> There is also a thread on nvnews, where some people say nv 2d perf is slower than via unichrome, don't know if it is truth or not
01:28 < marcheu> with the free driver ? it's quite possible, yes
01:29 < marcheu> there a lot of work to bring it up to speed, including for 2D support
01:29 < marcheu> unichrome can accelerate xvmc for example
01:29 -!- EdB_ [n=EdB@ARennes-251-1-76-43.w86-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
01:31 < pmdata> people were talking about the nvidia proprietary driver
01:31 < marcheu> hmm, I'd like to see the thread then
01:34 < pmdata> http://www.nvnews.net/vbulletin/showthread.php?t=72858
01:44 < marcheu> I think that's exagerated
01:44 < marcheu> or he has encountered a driver bug maybe
01:45 < marcheu> in my experience, 2D with nvidia is no faster/slower than ati or open source ati
01:45 < marcheu> he probably met some corner case
01:46 < colbert> or has all the eyecandy turned on
01:46 < marcheu> yep
01:46 < pmdata> that was what I was also thinking
01:46 < pmdata> nobody talked about slow 2d before
01:49 < colbert> kde feels slower than say Enlightenment. this new install feels a little slower than my old install. but there are a LOT more convenience librarys now than there used to be.
01:52 < pmdata> that's why it's important to have open 3d support, so that we can have 3d engine rendering gui stuff (I'm not talking about xgl/compiz/whatever)
01:54 < colbert> for some reason i thought ther was talk in that thread about imlib and rasterman's bench. must have been another thread
01:55 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit ["leaving"]
01:55 < pmdata> is e17 officially out ? :)
01:56 < pmdata> I started reading nv_register_combiners doc, I think I will try to make a test prog, so I can find if there is any extra command in nv10 tcl engine that use it
01:57 < colbert> e17 not yet :(
01:58 < colbert> and cvs dosnt like to build on debian etch
01:58 < pmdata> do you think it will be out before duke nukem forever?
01:59 < marcheu> 12:26 < nakee> is e17 officialy out?                                                                                 e1f       
01:59 < marcheu> 12:26 < raster> no                                                                                                   egbert    
01:59 < colbert> wouldnt be forever then
01:59 < marcheu> 12:26 < raster> as its not announced on enlightenment.org                                                            eikke     
01:59 < marcheu> 12:27 < raster> when its out                                                                                         etzel     
01:59 < marcheu> 12:27 < raster> u'll know
01:59 < marcheu> that's from today :)
01:59 < pmdata> :))
01:59 < marcheu> from the horse's mouth
01:59 < pmdata> ah, 00:00 coming, will have to sleep now
02:00 -!- pmdata [i=patrice@ANantes-154-1-30-123.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:10 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
02:18 < colbert> raeding the posts on nvnews make me think, mabye it would be better not to write this driver. LOL
02:31 < colbert> found the link i was thinking of
02:31 < colbert> http://www.nvnews.net/vbulletin/showthread.php?t=42677
02:36 < marcheu> hehe there's someone named "d4rk74m4" :)
02:36 < darktama_> :S that would be me..
02:36 < marcheu> :)
02:37 -!- Duke` [n=gnu@ANantes-251-1-156-41.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:38 < marcheu> hmm, so r200 outperforms 6800 for RENDER. interesting
02:39 < darktama_> yeah nvidia only accelerate non-scaled OVER ops
02:39 < marcheu> hmm I wonder how
02:40 < marcheu> lars complained that alpha blending used premultiplied alpha and was thus unsuitable for RENDER
02:41 < darktama_> mm, not sure.. perhaps they're using the 3D engine, it'd be more flexible
02:42  * darktama_ doesn't actually know the difference between premul and non-premul :)
02:43 < marcheu> instead of having data in the form r,g,b,a, you have it in the form r*a, g*a, b*a, a
02:43 < marcheu> therefore the name
02:44 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:44 < marcheu> and of course, when you blend, you don't have to multiply r,g,b by a
02:44 < darktama_> oh, that's simple.. sounded more complicated from what I'd read about it!
02:50 < colbert> walking the dogs bbl
03:06 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
03:14 < darktama_> ok, so.. the objects aren't in the FB
03:20  * marcheu curses
04:11 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
09:53 -!- Netsplit clarke.freenode.net <-> irc.freenode.net quits: darktama_, hiyuh
09:54 -!- Netsplit over, joins: hiyuh, darktama_
10:54 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has joined #nouveau
10:56 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has quit [Client Quit]
10:57 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has joined #nouveau
11:49 -!- Duke` [n=gnu@ANantes-251-1-156-41.w86-203.abo.wanadoo.fr] has joined #nouveau
12:09 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has quit [Remote closed the connection]
12:09 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has joined #nouveau
12:09 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has quit [Remote closed the connection]
12:09 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has joined #nouveau
12:12 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has quit [Remote closed the connection]
12:15 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has joined #nouveau
12:15 -!- svu [n=svu@194.46.164.241] has quit ["Ex-Chat"]
12:26 -!- ag [i=ag@caladan.roxor.cx] has quit ["BRB"]
12:26 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
12:31 -!- ag [i=ag@caladan.roxor.cx] has quit [Client Quit]
12:31 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
12:32 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
12:32 < Lumag> hi all!
12:37 < Duke`> hi
12:37 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/"]
12:38 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
12:52 -!- ag is now known as ag-
12:53 -!- ag- is now known as ag
13:34 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has quit [Read error: 104 (Connection reset by peer)]
13:43 -!- `Duke` [n=gnu@ANantes-251-1-97-155.w86-203.abo.wanadoo.fr] has joined #nouveau
13:43 -!- Duke` [n=gnu@ANantes-251-1-156-41.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
13:47 -!- `Duke` is now known as Duke`
14:29 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has joined #nouveau
15:48 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (Ping timeout)"]
15:50 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
15:52 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit [Client Quit]
15:52 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
16:40 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (Ping timeout)"]
17:06 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
17:12 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has quit [Remote closed the connection]
17:17 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has joined #nouveau
17:28 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
17:45 < marcheu> Lumag: http://icps.u-strasbg.fr/~marchesin/nvdri/nv40_ioctl_lumag.txt 
17:46 < marcheu> this is a geforce 6800 w/ 256mb
17:46 < marcheu> (ia32)
17:51 < Lumag> Thanks :)
17:52 < Lumag> Yeah! It seems, that the source of the problem really lies in the mem size.
17:54  * Lumag thinks that diffing 256Mb of vid mem would be a nightmare.
17:58 < marcheu> Lumag: darktama_ said yesterday he couldn't find the objects in video mem
18:02 < Lumag> Strange. Where they are going then?
18:02 < Lumag> I'll try porting libVEX into the kernel this weekend to have in-kernel valgrind.
18:03 < Lumag> Or maybe we should really try to hook into VM?
18:03 < Lumag> gtg now
18:04 < marcheu> no idea where they are
18:07 < marcheu> I'm not sure we could use libvex in the kernel...
18:15 -!- EdB [n=EdB@ARennes-251-1-151-223.w86-214.abo.wanadoo.fr] has quit ["Konversation terminated!"]
20:02 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
21:03 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
21:17 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Read error: 110 (Connection timed out)]
21:21 -!- pmdata [i=patrice@ANantes-154-1-86-75.w81-48.abo.wanadoo.fr] has joined #nouveau
21:38 -!- stringfellow_ is now known as stringfellow
23:04 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (Session timeout)"]
--- Log closed Срд Июл 12 00:00:48 2006
