--- Log opened Вск Июн 25 00:00:35 2006
00:20 -!- Duke` [n=gnu@ANantes-251-1-124-60.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
00:21 -!- Duke` [n=gnu@ANantes-251-1-156-160.w86-203.abo.wanadoo.fr] has joined #nouveau
01:19 -!- ChanServ [ChanServ@services.] has quit [ACK! SIGSEGV!]
01:21 -!- ChanServ [ChanServ@services.] has joined #nouveau
01:21 -!- ServerMode/#nouveau [+o ChanServ] by irc.freenode.net
01:32 -!- Duke_ [n=gnu@86.72.5.161] has joined #nouveau
01:42 -!- Duke_ [n=gnu@86.72.5.161] has quit ["Segmentation fault"]
01:44 -!- `Duke` [n=gnu@86.72.5.78] has quit [Success]
04:20 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
07:47 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: marcheu
07:48 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: airlied, krejler
07:48 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: darktama, ag, svu
07:52 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: Duke`, @ChanServ, stringfellow, ddl
08:13 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
08:13 [Users #nouveau]
08:13 [@ChanServ] [ airlied] [ ddl] [ lumag_offline] [ shavenger] [ stringfellow] 
08:13 -!- Irssi: #nouveau: Total of 6 nicks [1 ops, 0 halfops, 0 voices, 5 normal]
08:13 -!- Channel #nouveau created Sun Jun 25 08:11:37 2006
08:13 -!- Irssi: Join to #nouveau was synced in 1 secs
08:19 -!- krejler [n=krjlr@83.221.138.208] has joined #nouveau
08:23 -!- drs [n=devin@69-160-156-38.ontrca.adelphia.net] has joined #nouveau
08:23 < drs> hi guys
08:27 -!- marcheu [n=marcheu@lattice.u-strasbg.fr] has joined #nouveau
08:34 -!- ChanServ [ChanServ@services.] has quit [Shutting Down]
08:42 < drs> hey does nouveau work with NV15 cards? any support planned?
08:52 -!- drs [n=devin@69-160-156-38.ontrca.adelphia.net] has quit ["Read error: 2004 (10 years of BitchX isn't nearly enough)"]
08:56 -!- shenki [n=shenki@d220-238-116-23.dsl.vic.optusnet.com.au] has joined #nouveau
09:02 -!- ChanServ [ChanServ@services.] has joined #nouveau
09:02 -!- ServerMode/#nouveau [+o ChanServ] by irc.freenode.net
09:03 !niven.freenode.net *** Notice -- TS for #nouveau changed from 1151208697 to 1151207576
09:03 -!- ServerMode/#nouveau [-o ChanServ] by irc.freenode.net
09:03 -!- Duke` [n=gnu@86.203.15.160] has joined #nouveau
09:03 -!- svu [n=svu@194.46.176.245] has joined #nouveau
09:03 -!- darktama [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
09:03 -!- ag [i=ag@82.238.123.217] has joined #nouveau
09:03 -!- ChanServ [ChanServ@services.] has left #nouveau []
09:03 -!- ChanServ [ChanServ@services.] has joined #nouveau
09:03 -!- ServerMode/#nouveau [+o ChanServ] by irc.freenode.net
09:25 -!- darktama [n=darktama@124-168-238-39.dyn.iinet.net.au] has quit [Remote closed the connection]
09:25 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
09:47 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: ag, Duke`, svu
09:47 -!- Netsplit over, joins: ag, svu
09:48 -!- Duke` [n=gnu@ANantes-251-1-156-160.w86-203.abo.wanadoo.fr] has joined #nouveau
10:43 -!- shenki [n=shenki@d220-238-116-23.dsl.vic.optusnet.com.au] has quit ["bye bye"]
12:09 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
12:31 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has joined #nouveau
12:44 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
12:46 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
12:49 -!- `Duke` [n=gnu@86.72.5.9] has joined #nouveau
13:35 -!- ag [i=ag@82.238.123.217] has quit ["BRB"]
13:35 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
13:56 < Lumag> I have a question... How the DMA is done over plain PCI bus? Does the card contain page table or something like that? I'm asking because host offsets for my PCI card look a bit weird.
13:58 < Lumag> I.e. for transfer from 0b948c80 (pys address) the offset is 0x203c80. the mem is mapped starting from 0x0b946000.
13:59 < darktama> where does that offset value come from?
13:59 < Lumag> it's writtien by the nvGL to the FIFO
14:00 < Lumag> for AGP it's the offset of the texture from the start of AGP aperture.
14:00 < darktama> I think that offset is an offset relative to a base address in a DMA object
14:03 < darktama> in AGP's case, my guess is the DMA object use covers the entire AGP aperture
14:03 < darktama> but I don't know for certain
14:03 < darktama> s/use/used/
14:05 < Lumag> Hmm... maybe. I found the ioctl to the nvRM that returns the offset, but ioctl params aren't easily guessable.
14:14 < Lumag> It seems you are right. From os-agp.c:  "This will allow a client to create a DMA context for the entire aperture without mapping the entire aperture."
14:15 < darktama> ah, just when I was about to try and get renouveau to interpret DMA objects :)
14:17 < Lumag> :)
14:32 -!- pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
14:36 -!- pmdata [i=patrice@ANantes-154-1-79-163.w86-199.abo.wanadoo.fr] has joined #nouveau
15:53 -!- pmdata [i=patrice@ANantes-154-1-79-163.w86-199.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
15:56 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
15:56 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has joined #nouveau
16:05 < Lumag> darktama: any progress on DMA objects?
16:11 < darktama> oh, no.. once you said about os-agp.c I stopped :)
16:15 < darktama> I'm not even entirely sure whether I'd be able to find the object in RAMIN.. still need to look at why renouveau can't find context objects on my card
16:30 < Lumag> :)
16:30 < Lumag> does you card have some internal bridges?
16:31 < darktama> ?
16:32 < Lumag> IIRC, some early PCI-E cards had AGP->PCI-E bridges on board
16:32 < darktama> my card is AGP
16:36 < Lumag> Another strange thing is that the start of your RAMIN dumps look similar to mine dumps. So reading from start of RAMIN works
16:40 < darktama> hmm, I just checked marcheu's nv40 dump.. and it seems borked there too
16:40 < darktama> http://icps.u-strasbg.fr/~marchesin/nvdri/all_nv40.txt
16:40 < darktama> but I recall him saying it worked on NV44
16:46 < Lumag> yes... All instance memory readings are zero :(
16:47 < darktama> if you look through dumps of RAMIN, you can find what looks like the correct object, but at a completely different place than expected
16:49 < Lumag> can you give samples (name, context, RAMIN address)?
16:51 < darktama> one sec, I'll try and find the dump I made a while ago
16:56 < darktama> there's a couple of possibilities.. but http://rafb.net/paste/results/dZp5rC51.html
17:02 < Lumag> and 4097 is the beef3097 type?
17:03 < darktama> yup, I think that's what we decided.. marcheu gets 0x4497 on his nv44
17:07 < Lumag> well... e8fe8 has the same bitpattern as the part of context :) I have some your RAMIN dumps. I'll check it later :)
17:08 < darktama> cool, thanks :)
17:33 < Lumag> Hmm... no, nothing
18:36 < Lumag> darktama: I have committed a code to trace ioctl sideeffects. Could you please uncomment two top lines at ioctl.c and provide a new log:)
19:31 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
19:37 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
19:46 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
19:46 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has joined #nouveau
20:18 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
20:18 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has joined #nouveau
20:34 -!- `Duke` [n=gnu@86.72.5.9] has quit ["Segmentation fault"]
20:50 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
21:51 -!- _Demo_ [n=Demo@modemcable031.147-200-24.mc.videotron.ca] has joined #nouveau
22:07 -!- `Duke` [n=gnu@ANantes-251-1-90-129.w86-203.abo.wanadoo.fr] has joined #nouveau
22:21 -!- Duke` [n=gnu@ANantes-251-1-156-160.w86-203.abo.wanadoo.fr] has quit [Connection timed out]
22:35 < marcheu> Lumag: did you look at rivatv ? it does dma over PCI by giving a list of pages
22:36 < Lumag> no, I didn't look at that part yet.
22:36 < marcheu> so, that's how it's done. you basically give a list of pages to the object
22:37 < Lumag> marcheu: btw, IIRC, one of your cards also gave zero readings from RAMIN. could you please provide a log of renoveau with two top lines of ioctl.c uncommented?
22:38 < Lumag> Hmm. I'll look into rivatv later.
22:38 < marcheu> which one ? if it's not the nv28 I can't do it now
22:38 < marcheu> but you can add it to my todo list
22:39 < Lumag> no I'm interested in nv44 dump
22:39 < marcheu> ok, add it then
22:40 < Lumag> Added. Thanks :)
22:47 -!- EdB [n=EdB@ARennes-251-1-19-107.w81-250.abo.wanadoo.fr] has joined #nouveau
23:00 < darktama> Lumag: http://members.iinet.net.au/~darktama/ren.log (sorry for the long response!)
23:01 < Lumag> Thanks :)
23:03 < darktama> btw, I no longer get a FIFO dump after your last commit
23:03 < Lumag> hmm... strange.
23:08 < darktama> ah, it's the call to init_re() before SetVideoMode.. 
23:09 < marcheu> yeah, it shouldn't happen before the video context exists
23:09 < marcheu> that's why it was where I put it in the first place
23:11 < darktama> hmm, I think Lumag just needs the regs mapped before then to catch RAMIN changes when the context is created
23:11 < darktama> perhaps just do that part before SetVideoMode..
23:13 -!- pmdata [i=patrice@ANantes-154-1-34-54.w81-53.abo.wanadoo.fr] has joined #nouveau
23:16 < pmdata> hello
23:38 < Lumag> hello
23:46 < pmdata> I was reading opengl doc about imaging subset, and specially convolution filters, wondering if they may be hardware accelerated
23:46 < pmdata> I also read there is a color matrix
23:53 < Lumag> FIFO dumping restored
23:59 < Lumag> darktama: I examined your dump. Looks like there are no writes to the RAMIN during objects creation. When you'll have time, could you please generate another dump right after system power-up, please.
--- Log closed Пнд Июн 26 00:00:19 2006
