--- Log opened Пнд Июн 19 00:00:31 2006
01:02 -!- pmdata [i=patrice@81.53.87.106] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:32 < marcheu> ok, I think I'll add a per-field card type
01:32 < marcheu> looks like the only sane thing to do
01:36 < Lumag> marcheu: with the default being 'object-defined'?
01:37 < marcheu> Lumag: I'll add the field to every offset
01:37 < Lumag> because for many objects there will be no difference.
01:37 < marcheu> well, we don't know
01:37 < marcheu> if I was sure we'll never see object revisions again, I'd do a quick hack
01:38 < marcheu> but it looks like starting with nv30 it's heavily used, and nv20 uses it too (didn't try with nv1x yet)
01:39 < Lumag> Hmm... I think, that the separate field is a good idea. But if it's left zero, is should mean 'all-possible-objects'.
01:39 < marcheu> my hope is that this is incremental, i.e. I can add a simple int
01:39 < marcheu> not a bitfield
01:39 < marcheu> well, I can add a special case 0, or I can add the stuff by hand
01:40 < marcheu> but we really need that information for writing the driver, even if I don't think renouveau will ever make use of it.
01:42 < Lumag> I would prefer the first. It's much cleaner solution imho.
01:42 < marcheu> Lumag: what first ?
01:43 < Lumag> the special case.
01:43 < marcheu> well, renouveau won't use it anyway
01:43 < marcheu> I only see this as a place to store that information in case we need it later
01:44 < Lumag> Those variable fields don't overlap?
01:44 < marcheu> not yet
01:44 < marcheu> *keeps fingers crossed*
01:44 < Lumag> :)
01:45 < marcheu> anyway, I'll fil in the information for all the packets, and yeah use 0 anyway because if I use an int, 0 means "work everywhere"
01:49 < marcheu> darktama: are you aware of any nv40-specific fields in NV30_TCL_PRIMITIVE_3D while I'm at it ?
01:56 < darktama> none that I know of, but I don't have a lot to compare with :)
01:57 < marcheu> heh, fair enough :)
02:02 -!- `Duke` [n=gnu@ANantes-251-1-135-154.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:07 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:07 < marcheu> btw we really need a sparse object table implementation
03:07 < marcheu> adding that field made the binary size jump from 32 to 40 mb :)
03:13 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has quit [Remote closed the connection]
03:13 < darktama> wow, I didn't realise it was so huge :S
03:14 < marcheu> hmm crap, it seems it overlaps
03:14 < darktama> it`s ~65mb here
03:14 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
03:14 < marcheu> darktama: I blame it on 64bit  !
03:14 < darktama> yup me too :)
03:15 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has quit [Remote closed the connection]
03:15 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
03:15 < marcheu> ah well
03:15 < marcheu> why did it have to overlap
03:16 < darktama> so.. overlaps..
03:16 < darktama> which means separate objects?
03:16 < marcheu> not sure, we could handle it with the current system using flags everywhere
03:16 < marcheu> but it's getting pretty complicated
03:17 < darktama> indeed
03:18 < marcheu> I think we need a sparse table before we add object 0x2597 :)
03:18 < darktama> haha, it might be an idea, yes!
03:19 < marcheu> also, there are a lot of variants, which might make it unpractical
03:19 < marcheu> like you have 4097, I have 4497, I've seen 3497...
03:19 < darktama> I'd be happy abusing the current system a bit.. just define object 97 a couple of times, and flag what cards can use it
03:21 < darktama> s/use it/use each different version of it/
03:21 < marcheu> except I'd like to share it
03:22 < marcheu> I think we need a field which can hold revisions
03:22 < marcheu> like {34,40,44}
03:22 < marcheu> or maybe {30} which means 30 and more
03:23 < darktama> yup, what about when a command is removed in a revision (does that happen?)
03:23 < marcheu> well, we create a new object in the table
03:23 < marcheu> which holds the new entry
03:23 < marcheu> no, sucks
03:52 < marcheu> I guess I'll continue with the per-offset card field
03:54 < |pedro> object creation: beef3097, type 3497, parent beef000b
03:54 < |pedro> NV34 have type 3497...
03:54 < |pedro> (read it now)
03:55 < |pedro> (I know this doesn't help much, but... :P)
03:55 < |pedro> *have = uses
03:58 < |pedro> hm... currently renouveau uses the (offset == 0) && (size > 0) to handle object submition to subchannels, right?
03:58 < |pedro> and what about the other conditions? we should ignore them or we don't know how it works?
03:59 < marcheu> what conditions ?
03:59 < |pedro> hm... I get a lot of other things that are ignored by this condition...
03:59 < |pedro> (offset == 0) && (size > 0)
04:00 < marcheu> well, if offset != 0 , that's not an object change
04:00 < marcheu> and if size=0, that's probably a stale 0x0
04:00 < |pedro> but there are beef's in there..
04:00 < marcheu> yes, because you setup the object using that one
04:01 < |pedro> but renouveau ignores all those stuff?
04:02 < marcheu> well, when offset!=0, that's not an object change but a command
04:03 < |pedro> for example... I get a 0x00040180... with the first argument being 0xbeef0320....
04:03 < |pedro> and renouveau doesn't see it because of that offset thing...
04:04 < Lumag> 0x180 is often used as a reference for the DMA object.
04:04 < |pedro> hm...
04:04 < Lumag> that's a field, not a subchannel allocation.
04:04 < |pedro> I see...
04:05 < |pedro> but is renouveau logging that?
04:05 < Lumag> yes, of course. You see that as NvType... [0x180/4] = beef0320, don't you?
04:06 < Lumag> there are 3 or 4 fields near 0x180 that are used as rerefences for notifiers, dma objects, etc. Think of them as pointers to other objects.
04:07 < |pedro> hm... I'm still getting it...
04:08 < |pedro> but I'm talking about the start of the FIFO...
04:08 < |pedro> I don't get this NvType...
04:08 < |pedro> I didn't get this field thing yet... :( have to study renouveau's code more... :)
04:09 < |pedro> (I meant I don't see this NvType because it is on the start of the FIFO)
04:12 < Lumag> At the start of FIFo lie comands issued during libGL initialization. renoveau nearly ignores them.
04:13 < |pedro> hm... sorry if you already discussed it earlier... didn't see it...
04:14 < |pedro> thanks...
04:18 < marcheu> ok, let's put it straight
04:18 < marcheu> we didn't see any difference between nv30 and nv40 yet, right ?
04:19 < marcheu> (except different VP/FP behaviour)
04:19 < marcheu> I think I'll create a NV20 object next to the NV30 one
04:19 < marcheu> duplicate the field
04:19 < marcheu> and be done with it
04:29 < Lumag> good luck with it :)
04:29 < Lumag> night!
04:30 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
04:33  * marcheu 's renouveau is 2mb :)
04:40 < marcheu> do we know what 0x9f is ?
04:42 < darktama> I haven't seen it documented anywhere..
04:45 < marcheu> hmm it looks like I didn't break too much stuff
04:48 < darktama> that's usually a good thing.
04:49 < marcheu> ok, I'll commit and let you figure out why everything's broken :)
04:50 < darktama> hehe, sounds fun!
04:50 < marcheu> seriously, it should work
04:50 < marcheu> I'll port the nv20 stuff now
04:51 < darktama> I could do the same with the ddx :) though, I'd rather not blow someone's monitor up by accident!
04:51 < marcheu> hey, I tested it on my own card, which is probably more than adequate testing :)
04:52 < darktama> it's a lot more than some people do...
04:53 < marcheu> anyway, it'll greatly reduce the binary size for you
04:54 < darktama> cool :)
04:56 < darktama> -rwxr-xr-x 1 darktama darktama 3930964 19. Jun 10:55 renouveau
04:56 < darktama> whee :)
04:56 < marcheu> does it even work ? :)
04:56 < darktama> yup, it seems to
04:57 < darktama> with the exception of my borked fragprogs, but that's my fault
04:58  * marcheu goes on to resolve nv20/nv30 conflicts
04:59 < marcheu> ddl: you around ? is travelling over ?
05:08 < marcheu> hmmm actually I was seeing those 0x9f because I was looking at the DDX fifo
05:12 < darktama> anything interesting with regard to nvidia's 2D-accel?
05:12 < marcheu> I didn't look at it closely. but there's a lot of data in the packet, so it's hard to read
05:13 < marcheu> if you want to see th 2D, fifo, it's just at (phys_addr_of_the_3D_fifo - 0x8000*2)
05:13 < marcheu> you can map it when opening /dev/nvidia0
05:13 < marcheu> or use that : http://icps.u-strasbg.fr/~marchesin/nvdri/xorg-fifo.txt
05:14 < darktama> that'll do :)
05:14 < marcheu> well, you'll notice some hardcoded phys addr in there though
05:15 < darktama> I'll just replace 0xe0011000 with my 3D FIFO's address?
05:15 < marcheu> yep
05:16 < darktama> ah, that code is already in re.c
05:16 < darktama> just commented
05:17 < marcheu> hmm ?
05:17 < marcheu> comitting it was not my plan
05:17 < darktama> hehe, oops :)
05:39 < marcheu> hmm, blend & alpha funcs had never been tested on nv20
05:41 < marcheu> ah well, I'll see tomorrow
06:46 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has quit [Read error: 104 (Connection reset by peer)]
07:00 -!- robw810 [n=rw@pdpc/supporter/sustaining/robw810] has joined #nouveau
07:06 < robw810> Hey guys, is there a need for hardware donations?
09:39 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
10:01 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
10:25 -!- Duke` [n=gnu@ANantes-251-1-135-154.w86-210.abo.wanadoo.fr] has joined #nouveau
11:20 -!- EdB [n=EdB@ARennes-251-1-32-143.w81-250.abo.wanadoo.fr] has joined #nouveau
11:27 -!- EdB [n=EdB@ARennes-251-1-32-143.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
11:28 -!- EdB [n=EdB@ARennes-251-1-32-143.w81-250.abo.wanadoo.fr] has joined #nouveau
11:32 -!- EdB [n=EdB@ARennes-251-1-32-143.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
11:32 -!- EdB [n=EdB@ARennes-251-1-32-143.w81-250.abo.wanadoo.fr] has joined #nouveau
11:35 -!- airlied [n=airlied@skynet.skynet.ie] has joined #nouveau
11:37 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
11:46 -!- katakombi [n=kombrisn@dslb-084-056-156-225.pools.arcor-ip.net] has joined #nouveau
12:15 -!- Duke` [n=gnu@ANantes-251-1-135-154.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
12:16 -!- Duke` [n=gnu@ANantes-251-1-132-225.w86-210.abo.wanadoo.fr] has joined #nouveau
13:06 -!- katakombi [n=kombrisn@dslb-084-056-156-225.pools.arcor-ip.net] has quit [Remote closed the connection]
14:28 -!- EdB [n=EdB@ARennes-251-1-32-143.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
14:28 -!- robw810_ [n=rw@host-208-60-231-18.bhm.bellsouth.net] has joined #nouveau
14:47 -!- robw810 [n=rw@pdpc/supporter/sustaining/robw810] has quit [Read error: 110 (Connection timed out)]
16:03 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:06 -!- katakombi [n=kombrisn@dslb-084-056-189-066.pools.arcor-ip.net] has joined #nouveau
17:22 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
17:35 -!- robw810_ is now known as robw810
17:36 -!- EdB|l [n=EdB@212.234.68.206] has joined #nouveau
17:37 < marcheu> robw810: I don't need stuff personnally, but you might want to ask others. the channel will probably be alive in a couple of hours
17:38 < robw810> Okay, well, I'll be at the university all day, so if you think about, please inquire - I'll check the buffer when I get back home
17:39 -!- EdB|w__ [n=EdB@212.234.68.206] has joined #nouveau
17:39 -!- EdB|w__ is now known as Anne
17:46 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:50 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 113 (No route to host)]
17:55 -!- EdB|l [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
18:10 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
18:42 -!- shenki [n=shenki@ppp172-43.lns3.adl4.internode.on.net] has quit ["Cya!"]
19:03 -!- Anne [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
19:23 -!- ChanServ [ChanServ@services.] has quit [Shutting Down]
19:24 -!- ChanServ [ChanServ@services.] has joined #nouveau
19:24 -!- ServerMode/#nouveau [+o ChanServ] by irc.freenode.net
19:36 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:13 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
20:17 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Read error: 110 (Connection timed out)]
20:19 -!- EdB [n=EdB@ARennes-251-1-25-123.w81-250.abo.wanadoo.fr] has joined #nouveau
20:20 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
20:37 -!- EdB_ [n=EdB@ARennes-251-1-89-194.w86-199.abo.wanadoo.fr] has joined #nouveau
20:51 -!- EdB [n=EdB@ARennes-251-1-25-123.w81-250.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
20:52 -!- pmdata [i=patrice@81.53.71.107] has joined #nouveau
21:03 -!- EdB_ is now known as EdB
21:06 -!- gajownik_away [i=gajownik@zspswidwin.pl] has joined #nouveau
22:11 -!- pmdata [i=patrice@81.53.71.107] has quit [Remote closed the connection]
22:21 -!- katakombi [n=kombrisn@dslb-084-056-189-066.pools.arcor-ip.net] has quit [Read error: 104 (Connection reset by peer)]
23:26 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
23:42 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Read error: 110 (Connection timed out)]
--- Log closed Втр Июн 20 00:00:32 2006
