--- Log opened Срд Июл 12 00:00:48 2006
00:16 -!- colbert [n=colby@adsl-69-211-24-219.dsl.chcgil.ameritech.net] has quit [Read error: 104 (Connection reset by peer)]
00:27 -!- pmdata [i=patrice@ANantes-154-1-86-75.w81-48.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:15 < ddl> hi
01:36 < marcheu> hey
01:37 < ddl> hi there!
01:38 < ddl> do you have any bios dumps for cards <= nv30?
01:38 < ddl> other than those i already have
01:39 < marcheu> hmm, no but please point those you need among those : http://nouveau.freedesktop.org/wiki/StephaneMarchesin
02:02 < darktama_> hmm, what's the purpose of the 0x40000000 being OR'd with cmd 0x1818?
02:02 < darktama_> 0x1818 being the vertices
02:06 < darktama_> ah, nvm.. it's DMA_OPCODE_NONINC_METHOD
02:19 < marcheu> yay, we have to clean that
02:34 < darktama_> yup, we should probably handle JUMP/CALL also..
02:36 < marcheu> yay, I'm still trying to figure out interesting uses of CALL/JUMP for 3D, but it doesn't really fit
02:37 < marcheu> at some point I was imagining storing display lists within a CALL but... it would eat up the whole fifo quickly
02:39 < darktama_> yeah, I reckon it would.. btw, how does a CALL work.. well, specifically, returning from CALL
02:41 < marcheu> no idea
02:41 < marcheu> hmm actually
02:41 < marcheu> NV_FIFO_DMA_RETURN woul be it
02:41 < darktama_> ahh, note to self: scroll down in the header a bit :)
03:12 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:21 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
03:22 -!- Duke` [n=gnu@ANantes-251-1-97-155.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
03:40 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
04:14 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:21 -!- _Demo_ [n=Demo@modemcable038.138-201-24.mc.videotron.ca] has joined #nouveau
06:17 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has joined #nouveau
06:19 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has quit [Client Quit]
06:20 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has joined #nouveau
07:10 -!- _Demo_ [n=Demo@modemcable038.138-201-24.mc.videotron.ca] has quit ["Leaving"]
07:44 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has quit ["leaving"]
07:52 < ddl> marcheu: the haiku-way of parsing init table macros seems to work fine
07:53 < ddl> the macro index table is the table i previously thought was ram config stuff
07:56 < ddl> ill port the code to the ddx tomorrow.. it was more convenient to do the debugging with the parser i sent you
09:22 -!- EdB [n=EdB@ARennes-251-1-88-253.w86-199.abo.wanadoo.fr] has joined #nouveau
10:29 < darktama_> so.. I think I was wrong about the objects not being in the FB.  the code I was using was only comparing the first 64MB of it :S
10:29 < darktama_> butt.
10:29 < darktama_> object creation: beef7201, type 72, parent beef000b
10:29 < darktama_> Comparing FB to fb_before...
10:29 < darktama_> FrameBuffer[0x0febf4c0]: 0x00000000 -> 0x00000072
10:29 < darktama_> and similar results can be seen for the other objects
10:30 < darktama_> it also looks like the hash table is mirrored there..
10:32 < darktama_> marcheu: lumag_offline: if you're interested http://members.iinet.net.au/~darktama/fb_ramin.log
10:33 < darktama_> that's only dumping the last 6MB of the FB.. for now, work :(
10:34 < marcheu> hmm, so objects are in the FB ?
10:35 < darktama_> it appears that way, but I haven't had time to look at it closely yet.. will have to wait until tomorrow, have to go to work now
10:35 < darktama_> later :)
10:35 < marcheu> where ? in the end ?
10:36 < marcheu> in the area after the fifos ?
10:36 < marcheu> yay, looks like it
10:51 -!- EdB [n=EdB@ARennes-251-1-88-253.w86-199.abo.wanadoo.fr] has quit [Remote closed the connection]
10:51 -!- EdB [n=EdB@ARennes-251-1-88-253.w86-199.abo.wanadoo.fr] has joined #nouveau
11:40 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
11:53 < Lumag> hi all!
12:03 < Lumag> Yeah. It seems that the highest set bit of the context for >=nv40 cards means that the object is allocated in the FB mem and not in the regs...
12:05 < Lumag> bit#24
13:05 -!- Duke` [n=gnu@ANantes-251-1-154-177.w86-203.abo.wanadoo.fr] has joined #nouveau
14:27 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Remote closed the connection]
14:28 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
15:05 -!- EdB [n=EdB@ARennes-251-1-88-253.w86-199.abo.wanadoo.fr] has quit [Remote closed the connection]
15:07 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
15:07 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
15:35 -!- Duke` [n=gnu@ANantes-251-1-154-177.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
15:36 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (Ping timeout)"]
15:43 -!- Duke` [n=gnu@ANantes-251-1-154-177.w86-203.abo.wanadoo.fr] has joined #nouveau
16:01 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:05 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
16:06 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit [Client Quit]
16:06 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
16:07 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
16:11 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:36 < darktama_> Lumag: did you also notice the parts of the dump that look like hash-table entries?
16:58 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
16:58 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
16:59 < Lumag> darktama_: yes. And we have a problem: is it a hardware mirror, or a software one?
16:59 < darktama_> I'm not sure yet, was going to check that next
17:00 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
17:04 < darktama_> any ideas on how to find where the base of the "second RAMIN" is?
17:05 -!- EdB|l [n=EdB@212.234.68.206] has joined #nouveau
17:05 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
17:09 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
17:13 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:21 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
17:22 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:22 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
17:26 -!- EdB|l [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:44 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 110 (Connection timed out)]
17:57 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
17:59 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
18:02 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
18:10 < Lumag> darktama_: IIUC, the low bits of object context are (offset >> 4) even for second-ramin-objects.
18:11 < darktama_> yup, they are.. but what about the base of the second ramin itself.. the first is 0x00700000 in th card regs, on my card the second is at 0x0FE80000 in the FB
18:11 < darktama_> btw, bit 24 in the second part of the hash table entry is part of the channel id
18:12 < Lumag> Hmm... Could you please finding contexts and RAMIN bases for  second GLX client (e.g. try running renv with glxinfo running on the same screen) and for second X server?
18:13 < Lumag> s/finding/find/
18:19 < darktama_> it appears to be in the same location with glxgears running, will start a second X server now..
18:21 < darktama_> ok, same location on another X server too
18:24 < Lumag> And object contexts?
18:24 < darktama_> they have a different channel ID, but that's the only difference
18:25 < Lumag> I think that we can temporary hardcode the RAMIN base as 0x0fe80000 and deal with it in the future.
18:26 < darktama_> yup, sounds like an idea.. marcheu has a couple of other 256MB cards to test that on
18:31 < darktama_> the second hash table isn't at RAMIN2+ht_base either, it's quite a bit past that
18:31 < darktama_> but, I'll look into that more tomorrow - have to sleep now :)
18:34 < Lumag> :)
18:34 < Lumag> night
19:13 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
19:22 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
19:46 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (EOF)"]
19:51 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:00 -!- Aexoden [n=Aexoden@207-118-77-189.dyn.centurytel.net] has joined #nouveau
20:59 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
21:00 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
21:01 -!- pmdata [i=patrice@ANantes-154-1-11-121.w81-53.abo.wanadoo.fr] has joined #nouveau
21:01 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
21:07 < pmdata> small question about texture size: opengl requires hardware to support minimum 64x64 textures, but application can use smaller ones if needed, right?
21:11 < lumag_offline> pmdata: right
21:11 < lumag_offline> IIUC :)
21:30 < marcheu> pmdata: yup, that's it. and a texture has to be at least 2x2
21:32 < pmdata> yep, it reminds me I did not try texture rectangle
21:32 < pmdata> i.e. non power of two textures
22:35 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
22:37 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
22:38 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
22:53 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
22:57 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
23:40 -!- EdB [n=EdB@ARennes-251-1-72-239.w86-195.abo.wanadoo.fr] has joined #nouveau
--- Log closed Чтв Июл 13 00:00:49 2006
