--- Log opened Пнд Сен 04 00:00:29 2006
00:14 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
00:19 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings move in the drift of time (sung by Ian Anderson)."]
00:20 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
00:24 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Client Quit]
00:25 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
00:29 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Client Quit]
00:30 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
00:31 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Client Quit]
00:31 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
00:34 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Client Quit]
00:34 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
00:35 -!- svu [n=svu@83.167.239.56] has quit [Read error: 54 (Connection reset by peer)]
00:35 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
00:35 -!- svu [n=svu@83.167.239.56] has joined #nouveau
00:36 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Client Quit]
00:37 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
00:37 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Client Quit]
00:40 -!- marteus [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
00:43 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit ["Quitte"]
00:50 -!- pmdata [n=patrice@ANantes-154-1-38-18.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:36 -!- hanno [i=Re38aiC5@nat-wh-1.rz.uni-karlsruhe.de] has joined #nouveau
02:18 -!- Duke` [n=gnu@ANantes-251-1-129-16.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:31 -!- EdB [n=EdB@ARennes-251-1-89-157.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
02:41 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:42 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
03:07 -!- hanno [i=Re38aiC5@nat-wh-1.rz.uni-karlsruhe.de] has quit ["Verlassend"]
03:36 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
04:23 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
04:37 -!- pfoetchen [n=johannes@p54AAA83A.dip0.t-ipconnect.de] has quit ["Verlassend"]
04:55 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has joined #nouveau
05:04 -!- Hinrik [n=bla@194-144-99-91.du.xdsl.is] has joined #nouveau
05:10 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
05:44 -!- Myrizio [n=Myrizio@host150-102.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
05:46 -!- Myrizio [n=Myrizio@host150-102.pool80104.interbusiness.it] has joined #nouveau
07:15 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit ["Konversation terminated!"]
09:59 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
10:15 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit [Remote closed the connection]
10:28 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
10:40 -!- Myrizio [n=Myrizio@host150-102.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
11:14 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
11:31 -!- EdB [n=EdB@ARennes-251-1-10-234.w83-195.abo.wanadoo.fr] has joined #nouveau
12:14 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
12:39 -!- Netsplit zelazny.freenode.net <-> irc.freenode.net quits: Hinrik, darktama, marcheu, fatal__
12:41 -!- Netsplit over, joins: fatal__
12:41 -!- Netsplit over, joins: darktama
12:42 -!- Duke` [n=gnu@ANantes-251-1-142-49.w86-210.abo.wanadoo.fr] has joined #nouveau
12:43 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings change in the drift of time. (sung by Ian Anderson)"]
12:44 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
12:44 -!- ddl [i=erikw@montezuma.acc.umu.se] has quit [Remote closed the connection]
12:48 -!- Hinrik [n=bla@194-144-99-91.du.xdsl.is] has joined #nouveau
12:48 -!- marcheu [n=marcheu@lattice.u-strasbg.fr] has joined #nouveau
12:49 -!- marcheu [n=marcheu@lattice.u-strasbg.fr] has quit [Read error: 104 (Connection reset by peer)]
12:50 -!- marcheu [n=marcheu@lattice.u-strasbg.fr] has joined #nouveau
13:15 -!- hiyuh [n=hiyuh@KD222013063041.ppp.dion.ne.jp] has joined #nouveau
13:16 -!- erikw [i=erikw@montezuma.acc.umu.se] has joined #nouveau
13:17 -!- erikw is now known as ddl
13:19 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
13:23 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has quit [Read error: 60 (Operation timed out)]
13:33 -!- leroutier [n=leroutie@home.leroutier.net] has joined #nouveau
13:33 < leroutier> hello
13:35 < leroutier> it seems the "ioctl.c" compilation breakage is gcc 4.1 specific
13:35 < leroutier> at least, this error message was introduced in 4.1
13:36 < EdB> leroutier, no pb for me ...
13:37 < EdB> on 4.1.1
13:37 < leroutier> hum, that's strange
13:37 < EdB> may depend on linux headers ?
13:37 < leroutier> after a make clean ; make ?
13:37 < leroutier> on x86 ?
13:37 < EdB> yes
13:40 < leroutier> what is this "_syscall3"  on line 19 supposed to be ? a macro ?
13:40 < leroutier> i don't have it in any header
13:41 < EdB> don't know
13:45 < leroutier> ok, I see
13:46 < leroutier> _syscall3 is defined in : /usr/src/linux-headers-2.6.17-6/include/asm-i386/unistd.h
13:46 < leroutier> but not on installed /usr/include/asm-i386/unistd.h
13:46 < leroutier> simply because in the first file (real kernel headers), it is in a "#ifdef __KERNEL__" ... "#endif" block
13:47 < leroutier> so, it's not supposed to be used from userspace
13:48 < leroutier> so, ubuntu devs  did sanitise the kernel headers before shipping them
13:48 < leroutier> that's why it's impossible to compile renouveau under edgy (and perhaps dapper)
13:51 -!- maybeunknown [n=maybeunk@82-168-177-167.dsl.ip.tiscali.nl] has quit [Remote closed the connection]
14:04 < leroutier> ok, patch on the way
14:07 < leroutier> anyone with write access to renouveau CVS around ?
14:09 < EdB> yes
14:11 < leroutier> sorry, patch already sent to darktama
14:11 < leroutier> what's your mail ?
14:12 < EdB> leroutier, no pb :o)
14:12 < EdB> see with darktama
14:12 < leroutier> k
14:45 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 110 (Connection timed out)]
14:54 < marcheu> the ioctl issue is due to ubuntu having trimmed kernel headers
14:56 < leroutier> marcheu, yep, i saw it. they removed all code enclosed in __KERNEL__" ifdef blocks
14:57 < leroutier> so I added a trick to make renouveau use the stock ioctl instead of custom one in case where header are stripped
14:57 < mjg59> Well, userspace isn't supposed to be using anything in __KERNEL__ defines
14:57 < mjg59> If there's a need, then that suggests that the defines are wrong
14:58 < marcheu> well, the need is to hook the ioctl function and trap the calls... it's really just for RE
14:58 < leroutier> well, it's to intercept official nvidia driver ioctls AFAIK
14:59 < mjg59> Oh, I see
14:59 < mjg59> That makes sense
15:00 < leroutier> marcheu, I dumped my NV20 and NV44 register states with renouveau 2 days ago. (using stock ioctl as I'm under Ubuntu Edgy with stripped headers), are the dumps good for you ?
15:01 < marcheu> I've got a nv44 already
15:01 < marcheu> but the dumps might be outdated, yes
15:01 < leroutier> oh, k. I did not see a nv44 dump on http://nouveau.sourceforge.net/tests/?M=A before mine
15:02 < marcheu> hmm, maybe I didn't upload it
15:02 < leroutier> there's a problem with current renouveau .... let me explain
15:03 < leroutier> lets say you dump today your G70 card. 2 days after, you find what XXXX register does, and what YYYY register does ...
15:04 < leroutier> if you redump your G70 card after that, the dump content would have changed (well, same data but more register meaning)
15:04 < leroutier> so it makes it hard to compare dumps made with different versions of renouveau
15:04 < leroutier> couldn't it be changed to :
15:04 < leroutier> 1) always dump only raw data
15:05 < leroutier> 2) a post-processing takes raw data and translates it into actual readable format
15:05 < marcheu> ok, how do you handle, say, fragment programs that way ?
15:06 < leroutier> so, you wouldn't have to make 1) every time new registers' meaning are discovered
15:06 < leroutier> i'd say shader desassembly should be done in 2)
15:07 < marcheu> look at the code :)
15:07 < leroutier> but well, I don't know enough of renouveau internals for now
15:12 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
15:16 < leroutier> marcheu, un mail plus approprié que <marchesin@icps.u-strasbg.fr> pour ce qui concerne nouveau ?
15:18 < marcheu> no, we use irc instead
15:19 < leroutier> marcheu, k, was just ot send a patch for renouveau
15:19 < marcheu> paste a url here if you're not sure
15:20 < leroutier> ok
15:27 < leroutier> http://www.leroutier.net/renouveau.diff
15:27 < leroutier> here it is
15:28 < marcheu> can't you inline the _syscall3 prototype instead ?
15:29 < marcheu> we really need that ioctl stuff to understand some of what's going on
15:30 < leroutier> well, it's definition is different in x86 and x86-64
15:30 < marcheu> yes
15:30 < marcheu> and ? :)
15:31 < leroutier> I just find it a bit ugly
15:31 < leroutier> but well, as you wish
15:31 < marcheu> I didn't do it because I can't test it (I don't have the issue) but otherwise I would
15:31 < marcheu> we don't care if renouveau has ugly code, really
15:31 < leroutier> yes, I saw already ;)
15:32 < marcheu> the only thing that should be kept clean is the object defines, because these will be exported. the rest we don't care about
15:34 -!- shenki [n=shenki@ppp68-132.lns3.adl2.internode.on.net] has joined #nouveau
15:36 < leroutier> marcheu, can you apply the other changes (outside ioctl.c) for now. I'll rework ioctl in an hour or so
15:42 -!- EdB [n=EdB@ARennes-251-1-10-234.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:43 < marcheu> leroutier: you should commit that yourself once you're done
15:43 < leroutier> ok, as you wish
15:44 < marcheu> do you have a sf.net id ?
15:45 < leroutier> leroutier
15:45 < leroutier> "LeRoutier"
15:45 < leroutier> wish caps
15:45 < leroutier> with caps
15:46 < leroutier> looks like sf.net doesn't mind if its lowercase or uppercase
15:48 < marcheu> should be ok
15:48 < leroutier> I've been added, thx
15:48 < leroutier> yep, i see "nouveau" in my project list now
15:50 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
15:52 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit ["Quitte"]
15:53 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 104 (Connection reset by peer)]
15:54 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
16:18 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:37 < leroutier> anyone got x86-64 arch ?
16:38 < FauxFaux> Yes. ¬_¬
16:38 < leroutier> can you grep /usr/include for  '_syscall3' please ?
16:39 < ajmitch> ah, that fun 
16:39  * ajmitch guesses that leroutier is running edgy :)
16:39 < leroutier> yes
16:39 < leroutier> so I'm fixing it the ugly way
16:40 < ajmitch> grep shows nothing
16:40 < leroutier> ajmitch, which is normal as ubuntu sanitize their headers
16:40 < leroutier> ajmitch, using renouveau CVS ?
16:40 < ajmitch> yes, quite normal
16:41 < ajmitch> I am, however I've been building renouveau in a dapper chroot to run on edgy
16:41 < ajmitch> since I've been too lazy to fix anything with it
16:41 < leroutier> ajmitch, ok, commiting a patch now. should be available in anon CVS shortly after
16:42 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
16:45 < leroutier> ajmitch, "now" means once sf.net CVS works a little better
16:46 < ajmitch> so in ~2-3 days :)
16:48 < leroutier> commited
16:48 < ajmitch> SF hasn't been known for fast, reliable service lately
16:49 < leroutier> well, SF has never been known for beeing fast or reliable
16:49 < leroutier> but well, it's free, we shouldn't ask too much
16:50 < EdB|w_> gna s free and seem better
16:56 -!- EdB|l [n=EdB@212.234.68.206] has joined #nouveau
17:00 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:10 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:18 < darktama> marcheu: is latest drm/ddx git working for you? I seen someone was having FIFO hangs in the log
17:18 < darktama> on nv44
17:19 < marcheu> darktama: didn't test it recently... I've been pretty busy recently 
17:19 < marcheu> are you having issues ?
17:19 < darktama> no, it's working fine here
17:19 < marcheu> the persone having the issues had a Go card, maybe that matters
17:20 < darktama> hmm, that could be the case
17:20 < marcheu> not sure if the bare "nv" works for him
17:20 < darktama> I guess I'll wait and see if he reappears here and ask :)
17:20 < marcheu> could you get something to work on the irq front ?
17:21 < marcheu> I've been toying with it a bit, to no avail
17:21 < darktama> hang?
17:21 < marcheu> I don't think I even get context switch irqs
17:22 < darktama> no, I've never seen one of them before - the ddx doesn't enable the bit in one of the PGRAPH debug regs either
17:22 < darktama> btw, you did change the #if 0 in nv_dri.c so interrupts get enabled?
17:22 < marcheu> yeah
17:23 < marcheu> I changed more than just that :)
17:23 < marcheu> I don't have the code at hand right now, but I tried a number of other things
17:23 < darktama> ah
17:24 < marcheu> did you ever get  context switch irq in your setup ?
17:24 < darktama> I've had notify intr + hang before.. I have no idea how I managed that, because now I can't seem to trigger it
17:24 < darktama> nope
17:25 < leroutier> ajmitch, did it work for you ? (ioctl.c from CVS )
17:26 < marcheu> you did set the enable bit right ?
17:26 < darktama> yeah
17:26 < marcheu> not sure what else we have to do there...
17:26 < ajmitch> leroutier: haven't tried yet
17:26 < marcheu> that said, I didn't try everything I could, there's a couple of reasons our irq could be failing
17:27 < leroutier> ajmitch, which card do you have ?
17:27 < ajmitch> NV43
17:28 < darktama> marcheu: such as?
17:28 < ajmitch> ioctl.c: In function ?sys_ioctl?:
17:28 < ajmitch> ioctl.c:86: error: expected string literal before ?__syscall?
17:28 < marcheu> darktama: did you look at NV_CONFIG_PCI_NV_15 ?
17:28 < ajmitch> looks like it doesn't work here
17:28 < leroutier> ajmitch, you've got x86-64 arch, right ?
17:28 < ajmitch> yes
17:29 < darktama> marcheu: no
17:29  * darktama looks
17:29 < leroutier> ajmitch,  I only tested it under i386 as I don't have your hardware
17:29 < leroutier> ajmitch, let me check
17:30 < darktama> marcheu: if something was wrong there we wouldn't get *any* interrupts would we?
17:31 < marcheu> darktama: hah. interrupts are so weird it could be something incorrectly routed
17:32 < leroutier> ajmitch, could you add this line after line 45  : #define __syscall "syscall"
17:33 < ajmitch> works for me
17:34 < leroutier> ajmitch, so it compiles. could you run ./renouveau to see if it works well?
17:34 < ajmitch> yes, it's running & working
17:35 < leroutier> ok, thx, commiting the fix
17:35 < darktama> marcheu: have you looked at RAMFC at all?  I have a suspicion it's needed to get the GPU to switch FIFOs.. at least, nvosdk saves/restores stuff from it
17:36 < ajmitch> leroutier: thanks
17:36 < darktama> and, it *is (F)ifo (C)ontext
17:36  * ajmitch goes & sleeps
17:37 < leroutier> bye ajmitch 
17:37 < marcheu> darktama: nope, I didn't
17:39 < darktama> mm, I'd really like to know what FC/RO are.. there's hardly any info on them
17:39 < marcheu> yep
17:41 < marcheu> hmm where do you see RAMFC stored/restored ?
17:41 < darktama> ah, one sec.. I need to look
17:41 < marcheu> ah
17:41 < marcheu> fbChangeState ?
17:41 < darktama> nope, don't think that was it
17:42 < darktama> fifo.c::S2fifoFlushContext
17:42 < darktama> ctxtPtr is a pointer to the FIFO's RAMFC space
17:43 < darktama> it looks like a backup of what PFIFO contains for a specific FIFO
17:43 < darktama> I have no idea if/how the hardware uses that though
17:43 < marcheu> hmm seems used as scratch space
17:44 < darktama> yup, I thought that could be a possibility too.. I have no idea if the hardware uses it, but it does have a reg that points to RAMFC...
17:44 < darktama> nvxref.h has some defines for RAMFC
17:47 < marcheu> also, what about RAMRO ?
17:47 < marcheu> (while we are looking at unknown stuff)
17:48 < darktama> I have no idea.. it's RunOut.. but that's as much as I know really
17:49 < darktama> hehe
17:49 < darktama> #define NV_RAMRO_REASON_CAUGHT_LYING                     0x00000004 /* ...-V */
17:50 < marcheu> well, at first I though it was when user space tried to get the PUT past the end of the fifo
17:50 < marcheu> now I'm not so sur
17:58 < darktama> hm, it's not triggered when a non-active FIFO has ran out of space?
17:58 < darktama> at least, one of the reasons anywa
17:58 < darktama> anyway*
18:02 < darktama> on, NO_CACHE_AVAILABLE and CACHE_RAN_OUT it looks like it does a context-switch
18:02 < darktama> the rest, it just logs an error
18:04 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
18:11 < marcheu> I thought that was handled by the interrupt 
18:11 < darktama> yeah, bit 4 is the runout interrupt isn't it?
18:11 < marcheu> yes
18:12 < darktama> so, my guess is RAMRO is just where the GPU logs info on the runout event
18:12 < marcheu> ah, makes sense
18:12 < darktama> there's GET/PUT pointers for RAMRO aswell, which is weird
18:13 < marcheu> so similarly could RAMFC be the state of the interrupted context ?
18:13 < darktama> hmm, I guess so
18:13 < marcheu> where do you see GET/PUT in RAMRO ?
18:13 < darktama> it's a PFIFO reg
18:13 < darktama> 0x2410/0x2420
18:14 < marcheu> ah
18:14 < marcheu> now the number of shadow PUT/GET regs I was seeing with renouveau start to make sense
18:15 < darktama> hm, I don't think those runout ones are the same as the shadow ones.. nvidia uses completely different FIFO control regs than we do
18:16 < darktama> the runout get pointer is used by nvosdk as a pointer into RAMRO
18:40 < darktama> marcheu: btw, is there any way to make X tell you if it's doing a sw-fallback instead of accelerating?
18:41 < marcheu> hah, no
18:41 < darktama> damn
18:41 < marcheu> usually a profile will say it spends a lot of time in fb*MMX* functions
18:41 < darktama> ahh, that might be a good idea
18:41  * darktama wonders if he gave his kernel profiling support
18:42 < darktama> yes, I did
18:43  * darktama emerges oprofile
18:49 -!- Myrizio [n=Myrizio@host141-98.pool80104.interbusiness.it] has joined #nouveau
18:58 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has joined #nouveau
18:59 -!- EdB|l [n=EdB@212.234.68.206] has quit ["Parti"]
19:01 < darktama> marcheu: so.. I think I have the NV30_TCL working.. not well, but I get black quads of the correct size and in the correct position
19:08 -!- Hinrik [n=bla@194-144-99-91.du.xdsl.is] has quit ["Leaving"]
19:16 -!- lonn [n=sam@fla93-1-81-57-168-33.fbx.proxad.net] has joined #nouveau
19:28 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:29 -!- shenki [n=shenki@ppp68-132.lns3.adl2.internode.on.net] has quit ["http://xkcd.com/comics/fourier.jpg"]
19:36 < marcheu> darktama: so, when do we party ?
19:37 < darktama> when I get it to render in colour :)
19:37 < darktama> I didn't think it was working at all.. but if I modify my EXACopy implementation to render width/2,height/2, I get half-sized black quads
19:38 < darktama> so, that counts as working in my book
19:42 < darktama> I don't know why it's working at all.. I switched to my nv30_exa_3d branch so I could trigger a FIFO error interrupt.. and see if the drm gave me a pretty error message saying where
19:43 < darktama> but, for some reason it half-works now.. I have nfi why
19:43 < marcheu> did you run the proprietary driver before ?
19:43 < darktama> yes, but I always did when working on it before that
19:49 -!- hiyuh [n=hiyuh@KD222013063041.ppp.dion.ne.jp] has quit ["Leaving"]
19:56 < darktama> ok, I'm convinced.. it's working.. it does triangles too :)
19:56  * darktama jumps around
19:57 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:11 < stillunknown> darktama: don't forget to save the code somewhere safe :-)
20:11 < darktama> does my git tree count?
20:11 < stillunknown> you have your own git tree on fd?
20:12 < darktama> no, just my local tree
20:12 < darktama> if I can get this to work properly, I'll give you textured video along with DMA'd Xv :P
20:13 < stillunknown> i thought you mostly did nv40 stuff?
20:13 < darktama> yeah, what card are you using?
20:13 < stillunknown> nv43
20:13 < darktama> yeah, same thing
20:14 < darktama> it'll probably work on nv30 too, as long as the card is in vertex program mode
20:15 < stillunknown> what's the advantage of textured video?
20:16 < darktama> we can probably support a lot more formats on hardware
20:16 < marcheu> all newer cards only do textured video
20:16 < darktama> ahh
20:17 < darktama> so >G70?
20:18 < stillunknown> any major (expected) problems before us mortals can try?
20:19 < marcheu> darktama: well, all nv40 (except the very first 6800) have lost the overlay, and the free driver uses a blit with on the fly conversion right now
20:19 < darktama> stillunknown: well, the whole "everything is black" issue may be a problem.. the code works quite well outside of the X server
20:19 < marcheu> darktama: so technically, the best thing to do is use textured video everywhere
20:19 < darktama> hmm, makes sense
20:20 < stillunknown> what makes sense?
20:20 < darktama> what marcheu was saying
20:21 < marcheu> with composite, we can't have overlays any more either (because of redirected video) so we need textured video for all cards as well
20:22 < mjg59> And Intel already has it
20:22 < darktama> marcheu: the blit adaptor will work there too
20:23 < marcheu> darktama: yup, but has a meager list of formats, as you said
20:23 < darktama> indeed
20:23 < darktama> another immediate benefit of getting 3D going is that we can do a kick-ass RENDER implementation
20:23 < marcheu> that, and exercise the 3d engine of the card :)
20:23 < b33fc0d3> so are you guys reverse engineering anything?
20:24 < darktama> that too :)
20:24 < b33fc0d3> like some asm or from scratch?
20:24 < stillunknown> there are some people that prefer color on their screen :-)
20:24 < darktama> stillunknown: there's colour.. but only from the bits that are software-rendered :)
20:24 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit [Remote closed the connection]
20:24 < darktama> b33fc0d3: we're reverse-engineering by looking at the commands the driver sends to the card.
20:25 < darktama> b33fc0d3: but not "dirty" reverse engineering, like disasm
20:25 < b33fc0d3> interesting
20:25 < b33fc0d3> so you guys aren't dirty
20:25 < b33fc0d3> =)
20:25 < darktama> well.. I didn't say that exactly :)
20:25 < b33fc0d3> at least there's no extra washing
20:26 < b33fc0d3> darktama: i'd love to help
20:26 < b33fc0d3> but i'd need someone to teach me the ropes
20:26 < b33fc0d3> cos i'm only used to dirty dissasm.
20:26 < b33fc0d3> and not much of that mind you =)
20:27 < darktama> it's easy!  grab renouveau, write some GL code and make dumps with small changes between dumps, compare dumps.. and decide what various commands do :)
20:27 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
20:28 < b33fc0d3> "make dumps"
20:28 < b33fc0d3> of what ?
20:28 < b33fc0d3> card registers status?
20:28 < darktama> the commands that are sent to the GPU, renouveau will do that part for you
20:29 < b33fc0d3> ah
20:29 < b33fc0d3> would running xgl suffice as my GL prog =) ?
20:29 < darktama> nope, in fact, renouveau wont work inside Xgl
20:29 < b33fc0d3> fun and games
20:29 < b33fc0d3> so a seperate server
20:29 < b33fc0d3> so the GL code
20:29 < darktama> your GL prog would has to be inside renouveau
20:30 < darktama> see tests.c
20:30 < b33fc0d3> k
20:30 < b33fc0d3> i'll poke around the code later, thanks for the info
20:30 < darktama> np, if you have questions we're glad to help out :)
20:31 < stillunknown> darktama: do you expect to regain color at some point or is that just as mysterious as the fact it's partially working?
20:31 < darktama> I'm poking around with renouveau now to see what I've missed
20:35 -!- EdB [n=EdB@ARennes-251-1-75-6.w86-195.abo.wanadoo.fr] has joined #nouveau
20:42 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
20:46 -!- shenki [n=shenki@ppp68-132.lns3.adl2.internode.on.net] has joined #nouveau
20:46 -!- marteus [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
21:00 -!- lonn [n=sam@fla93-1-81-57-168-33.fbx.proxad.net] has left #nouveau []
21:05 < darktama> ok, now it renders colours.. but it's not correct, I guess the texture for EXACopy is setup wrong
21:05 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit ["Mike Patton"]
21:11 < phh> darktama, what do you talk about ? You're working on still accelerating 2D ?
21:11 < darktama> I'm playing with the 3D engine
21:12 < phh> with EXA ?
21:13 < darktama> yeah, I've replaced EXA in my local tree with one that's done with the 3D engine
21:13 < darktama> we can't do multiple GPU contexts yet, so this was the only good way to play with it
21:14 < phh> darktama, you do something like Xgl but staticaly ?
21:14 < darktama> more or less
21:14 < phh> is it funny ? :)
21:15 < darktama> well, the current output is funny :)
21:20 < stillunknown> i hope you will get sad output too :-)
21:20 < phh> darktama, screenshot like ? :)
21:20 < darktama> ok, one sec
21:21 < marcheu> oh yeah, maybe we should communicate on that
21:21 < marcheu> "first triangle through the nv30 engine" or something
21:21 < phh> marcheu, yep :p
21:21 -!- mat__ [n=mat@cac94-1-81-57-151-96.fbx.proxad.net] has joined #nouveau
21:23 < EdB> what not on nv28
21:23 < EdB> !!!
21:24 < EdB> marcheu, you will lose user if you don't make it run on my nv28 :o)
21:24 < darktama> http://members.iinet.net.au/~darktama/bleh.png
21:24 < darktama> marcheu: well, wont work on nv30 yet anyway.. the vertex program formats are different
21:25 < marcheu> yeah, stupid object naming :)
21:25 < darktama> hehe
21:25 < darktama> I'm not sure what's wrong now, either I've messed up the texture setup.. or the texcoord transform is done wrong
21:26 < phh> darktama, i don't see any 3D on it
21:26 < phh> just some bugs :)
21:26 < darktama> you wouldn't see 3D, it's 2D done with the 3D engine
21:26 < phh> ah ok
21:27 < phh> i thaught you would add somethink like a point a view different than front
21:27 < marcheu> I wonder how some DE would look right now with all the missing stuff :)
21:27 < darktama> hmm, I could try e17
21:27 < phh> E17 is 100% soft by default so it will works without any problem
21:28 < phh> i won't be some optimistic with KDE :p
21:28 < marcheu> phh: no it was not last time I tried
21:28 < marcheu> and then went back to e16 :)
21:29 < phh> marcheu, it doesn't use by default not xrender neither OpenGL, i don't see what it can use other..
21:32 -!- nael [n=nael@ras75-1-81-57-62-96.fbx.proxad.net] has quit [Connection timed out]
21:33 < darktama> http://members.iinet.net.au/~darktama/bleh_e17.png
21:33 < darktama> http://members.iinet.net.au/~darktama/bleh_triangles.png
21:34 < Duke`> wow, impressive :)
21:34 < darktama> haha
21:35 < darktama> I'm relieved that it actually renders at all!
21:35 < darktama> who needs it to look correct!!!
21:35 < stillunknown> it would be prefered, that it can be read :-)
21:39 < Myrizio> darktama: is this screenshot done using the nouveau driver that uses the 3d engine? it *IS* impressive!
21:40 < darktama> :P  the bits that actually look correct are software rendered.. it looks like the first render of everything is done in software for some reason
21:41 < marcheu> I think because the pixmap migrates to VRAM when it gets displayed
21:41 < darktama> yeah, that's what I figured must be happening
21:46 -!- marteus_ [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
21:53 -!- marteus [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
21:53 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings change in the drift of time. (sung by Ian Anderson)"]
21:57 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
22:08 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
22:27 < darktama> ok, it's almost working decently now
22:27 < darktama> I forget to fill the NPOT_PITCH field in the texture unit setup :)
22:27 < darktama> forgot*
22:33 -!- silverpower [i=shrike@adsl-153-133-123.cha.bellsouth.net] has quit ["Leaving"]
22:49 < stillunknown> darktama: it's readable now?
22:49 < darktama> yup
22:51 < stillunknown> and the problem is?
22:51 < darktama> windows "melt" when you move them..
22:53 < stillunknown> you mean the old windows stay and you get a stripe of windows?
22:54 < darktama> no, the edges of the windows slowly melt away..
22:54 < darktama> it looks quite cool actually
22:54 < stillunknown> screenshot?
22:54 < marcheu> accuracy issues ?
22:54 < darktama> marcheu: yeah, I think so, the fluxbox menu "wobbles" slightly too
22:55 < darktama> stillunknown: I'll grab one in a sec
22:55 < marcheu> so, seeing that nvidia cards are opengl from top to bottom, maybe you can apply the old +0.375 trick ?
22:55 < darktama> to the viewport transform?
22:55 < marcheu> to the coords
22:55 < darktama> ah
22:56 < darktama> I'll try that soon too
22:56 < marcheu> add 0.375 to both x & y coords, that's in the spec
22:57 < stillunknown> spec of what?
22:57 < darktama> it could also be because I'm passing texcoords as (x,y)->(x+width,y+height) - instead of (x+width-1, y+width-1)
22:57 < marcheu> ah, yeah
22:57 < marcheu> stillunknown: opengl spec
22:57 < marcheu> stillunknown: google 0.375 and opengl
22:57 < marcheu> darktama: actually, I think you can apply it to the transform, that will work as well
22:57 < darktama> yeah, nvidia has a small adjustment on the transform
22:58 < marcheu> yeah, I think that's a possible explanation
23:10 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
23:13 < stillunknown> darktama: your second ends in about a minute :-)
23:16 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
23:24 < darktama> stillunknown: ahh, I got slightly distracted..
23:24  * darktama switches back to nouveau
23:26 < darktama> stillunknown: hmm, I can't seem to get a screeny of the melt.. as soon as I let go of the window it doesn't look "melty"
23:27 < stillunknown> gimp offers a delayed screenshot, with will shoot when you click the window
23:27 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
23:27 < stillunknown> but if it's too difficult, focus on the driver making :-)
23:27 < darktama> ah, good point.. or I could just use sleep&&import like I was before..
23:29 < darktama> http://members.iinet.net.au/~darktama/bleh_melty.png
23:29 < darktama> the more you move, the less of the window is there
23:30 < stillunknown> definately strange
23:30 < stillunknown> did marcheu's suggestion help?
23:30 < darktama> I'm about to try that
23:31 -!- EdB [n=EdB@ARennes-251-1-75-6.w86-195.abo.wanadoo.fr] has quit [Remote closed the connection]
23:31 -!- EdB [n=EdB@ARennes-251-1-75-6.w86-195.abo.wanadoo.fr] has joined #nouveau
23:38 -!- EdB [n=EdB@ARennes-251-1-75-6.w86-195.abo.wanadoo.fr] has quit [Remote closed the connection]
23:38 -!- EdB [n=EdB@ARennes-251-1-75-6.w86-195.abo.wanadoo.fr] has joined #nouveau
23:42 -!- hanno [i=SvLJuSSV@nat-wh-1.rz.uni-karlsruhe.de] has joined #nouveau
--- Log closed Втр Сен 05 00:00:30 2006
