--- Log opened Чтв Июл 20 00:00:54 2006
00:10 < Lumag> Just a thought about z-buffer. Try looking for the offset by clearing the depth buffer :)
00:13 < pmdata> I just found depth range values, with 394 and 398
00:18 < Lumag> nVidia had something strange on their mind. Nearly every object has it's own encoding for color format, but some params are unchanged from nv04 (and maybe nv03) till nv30 and later.
00:32 < pmdata> ah I swapped the depth and color offset
00:32 < pmdata> I found this when adding some glClear() commands for each buffer
00:35 < pmdata> the more commands are found, the easier it is to find the remaining ones :)
00:38 < Lumag> yup :)
01:23 < pmdata> seems there is a 4x4 matrix for fog maths (command 400)
01:45 < pmdata> hum, 2a0 seems to be distance_mode and coordinate_src, will make something better later
01:45 -!- pmdata [i=patrice@ANantes-154-1-48-21.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:59 -!- lumag_of1line [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
01:59 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
01:59 -!- Topic set by marcheu [] [Fri Jul 14 19:33:43 2006]
01:59 [Users #nouveau]
01:59 [@ChanServ] [ airlied ] [ ddl  ] [ lumag_of1line] [ philv       ] [ xaid|work] 
01:59 [ Aexoden ] [ blx     ] [ Duke`] [ lumag_offline] [ qfire_away  ] 
01:59 [ ag      ] [ darktama] [ Lumag] [ marcheu      ] [ stringfellow] 
01:59 -!- Irssi: #nouveau: Total of 16 nicks [1 ops, 0 halfops, 0 voices, 15 normal]
01:59 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
01:59 -!- [freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup
01:59 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has quit [Read error: 131 (Connection reset by peer)]
01:59 -!- Irssi: Join to #nouveau was synced in 6 secs
02:22 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:36 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:42 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
03:42 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
03:42 -!- Topic set by marcheu [] [Fri Jul 14 19:33:43 2006]
03:42 [Users #nouveau]
03:42 [@ChanServ] [ airlied ] [ ddl  ] [ lumag_of1line] [ philv     ] 
03:42 [ Aexoden ] [ blx     ] [ etzel] [ lumag_offline] [ qfire_away] 
03:42 [ ag      ] [ darktama] [ Lumag] [ marcheu      ] [ xaid|work ] 
03:42 -!- Irssi: #nouveau: Total of 15 nicks [1 ops, 0 halfops, 0 voices, 14 normal]
03:42 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
03:42 -!- Irssi: Join to #nouveau was synced in 1 secs
03:46 -!- lumag_of1line [n=mitya@chimpanzee.school.ioffe.ru] has quit [Read error: 110 (Connection timed out)]
03:47 < ddl> hey!
03:47 < marcheu> ho !
03:47 < ddl> marcheu! whats up? :)
03:47 < marcheu> almost 2am, just came back
03:48 < ddl> ah
03:48 < marcheu> and pmdata has been on a commit frenzy once again
03:48 < marcheu> so I'm reading the cvs messages
03:48 < ddl> hehe, i noticed yesterday
03:49 < marcheu> any bios news ?
03:49 < ddl> still working on it.. hopefully there will be some good news one of these days
03:49 < ddl> :)
03:50 < marcheu> heh, did you merge <nv40 support ?
03:53 < ddl> no, not yet
04:17 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:17 < marcheu> anyway, bedtime now
04:17 < marcheu> night
04:18 < ddl> good night!
04:18 < Lumag> night
06:55 -!- xaid [n=Xaid@d199-126-153-40.abhsia.telus.net] has joined #nouveau
07:15 -!- Shipon [n=Aexoden@207-118-72-211.dyn.centurytel.net] has joined #nouveau
07:15 -!- Aexoden [n=Aexoden@207-118-66-169.dyn.centurytel.net] has quit [Nick collision from services.]
07:15 -!- Shipon is now known as Aexoden
08:05 -!- Netsplit brown.freenode.net <-> irc.freenode.net quits: ag, xaid, Lumag, blx, xaid|work
08:53 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
08:53 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
08:53 -!- Topic set by marcheu [] [Fri Jul 14 19:33:43 2006]
08:53 [Users #nouveau]
08:53 [@ChanServ] [ ag     ] [ blx] [ etzel] [ lumag_offline] [ xaid     ] 
08:53 [ Aexoden ] [ airlied] [ ddl] [ hiyuh] [ marcheu      ] [ xaid|work] 
08:53 -!- Irssi: #nouveau: Total of 12 nicks [1 ops, 0 halfops, 0 voices, 11 normal]
08:53 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
08:53 -!- Irssi: Join to #nouveau was synced in 2 secs
08:55 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
09:01 -!- qfire_away [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
09:22 -!- xaid [n=Xaid@d199-126-153-40.abhsia.telus.net] has quit ["leaving"]
10:12 -!- qfire_aw1y [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
10:12 -!- qfire_away [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has quit [Read error: 104 (Connection reset by peer)]
11:28 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has joined #nouveau
12:05 -!- EdB [n=EdB@ARennes-251-1-58-194.w81-53.abo.wanadoo.fr] has joined #nouveau
12:28 -!- EdB [n=EdB@ARennes-251-1-58-194.w81-53.abo.wanadoo.fr] has quit [Read error: 104 (Connection reset by peer)]
12:28 -!- EdB [n=EdB@ARennes-251-1-58-194.w81-53.abo.wanadoo.fr] has joined #nouveau
14:49 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
17:07 -!- hiyuh [n=hiyuh@222.7.50.248] has quit ["Leaving"]
17:39 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
18:44 -!- blx [n=x@217.208.244.132] has quit [Success]
18:57 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has joined #nouveau
19:39 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has quit [Connection timed out]
19:41 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has joined #nouveau
19:49 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:11 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has quit [Read error: 104 (Connection reset by peer)]
20:15 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has joined #nouveau
20:16 -!- johill [n=johannes@p5487E56D.dip.t-dialin.net] has joined #nouveau
20:21 < johill> I note that the gforce 6600 is nv43, but that's missing from the list. does that mean it's similar to nv40, or does that mean nothing is known?
20:26 < johill> oh, osx loads NV40
20:28 < marcheu> missing in what list ?
20:29 < marcheu> basically, all NV4x cards are very similar (and really all cards in a given family work mostly the same)
20:29 < johill> well I couldn't find any reference to NV43
20:29 < johill> makes sense
20:29 < marcheu> for the record, I have a nv44. I don't think you'll find a reference to NV44 :)
20:30 < johill> heh
20:30 < johill> ok, well
20:30 < johill> I only have experience with bcm43xx
20:31 < johill> how are you gathering your information?
20:31 < marcheu> we've got some tools (renouveau, mmtrace...) to look at the commands that are sent to the card
20:32 < marcheu> we trigger small tasks using small opengl programs, and deduce features taht way
20:32 < johill> ok so you only observe; with bcm43xx we did a lot of assembly staring
20:33 < marcheu> no, looking at disassembly for a video driver would take too much time. it's really easier that way
20:33 < johill> but how can you do this if you don't understand the dma format?
20:33 < marcheu> well, we do :)
20:33 < marcheu> the available nvidia driver source code uses it, so...
20:34 < johill> hm, ok, the feature matrix says 'yes', not 'done' :)
20:34 < marcheu> wait, what dma are you talking about ?
20:34 < johill> "How to make use of the cards DMA functionality. In particular, how to upload textures, and how to do back->front blits. Some information about that can be gathered from the EXA patch, and from the nv DDX."
20:34 < marcheu> ah, that "dma" is about blitting data around using dma
20:34 < johill> ah ok
20:34 < marcheu> not about controlling the card
20:36 < johill> here's an NV44 specific function ;)
20:37 < marcheu> hmm ?
20:37 < johill> a bunch, really
20:37 < johill> _dacConstructCRTC_NV44
20:37 < marcheu> oh yeah, note that we also don't want to disassemble the driver for obvious legal reasons
20:37 < johill> yeah, we did two teams for that
20:38 < marcheu> well, the nvidia EULA says no disassembly at all
20:38 < johill> heh. I didn't see any nvidia eula with my osx
20:38 < marcheu> kay :)
20:39 < marcheu> but seriously, I don't want to get that project in trouble
20:39 < johill> no, I understand that
20:39 < johill> but wait, what drivers are you actually running then?
20:39 < marcheu> the proprietary linux drivers
20:39 < johill> that is, observing
20:40 < johill> ah ok
20:40 < johill> then I guess I can't do anything, they don't exist for ppc64 afaik
20:40 < marcheu> well, you could use a tool similar to renouveau on osX
20:40 < marcheu> or port it to osx
20:41 < marcheu> it's just a matter of mapping the fifo in the process space
20:41 < johill> oh yeah, that might work
20:41 < marcheu> plus having dumps from a big endian machine will be very interesting
20:41 < johill> I only have a ppc64 though with an nvidia card
20:42 < marcheu> why would that be an issue ?
20:43 < johill> no idea if it would be
20:43 < marcheu> porting renouveau to osx would just be a matter of finding the fifo memory map I think
20:44 < johill> I just need to call someone, back in a bit
20:44 < marcheu> actually, I have to go
20:44 < johill> ok
20:44 < marcheu> but there are many other helpful people in there :)
20:44 < johill> I'll look at renouveau later
20:50 -!- johill [n=johannes@p5487E56D.dip.t-dialin.net] has quit [Remote closed the connection]
20:50 -!- johill [n=johannes@p5487E56D.dip.t-dialin.net] has joined #nouveau
21:02 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
21:04 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has quit [Read error: 110 (Connection timed out)]
21:08 < johill> do you mprotect() the mmio area so you can see when accesses happen?
21:12 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has quit [Read error: 104 (Connection reset by peer)]
21:12 < johill> huh
21:12 < johill> this is a pure userspace program?
21:13 < marcheu> yeah, and it runs with user privileges :)
21:13 < marcheu> we don't need mprotect
21:13 -!- philv [n=bleep@cowpig.ca] has joined #nouveau
21:15 < johill> can someone explain how the communication with /dev/nvidia0 works?
21:15 < johill> is that used by the X driver?
21:15 < johill> and why don't you mprotect it? that way you'd get all changes right away, no?
21:15 < johill> (plus it should be a fairly easy kernel hack)
21:15 < marcheu> because we don't need to
21:16 < marcheu> really, why have a kernel-based tool when you can run in userspace without root privs ?
21:17 < johill> dunno, maybe video cards don't have such sequence issues
21:17 < johill> we always had problems with mmio registers on the wireless chip, it all has to happen in the right order
21:17 < marcheu> yeah, it's not using mmio like  most other drivers
21:17 < marcheu> init is done with mmio...
21:17 < marcheu> the rest goes through a fifo
21:17 < marcheu> and parsing that fifo doesn't really need mprotect
21:17 < johill> yeah
21:18 < johill> which code creates /dev/nvidia0?
21:18 < marcheu> the nvidia kernel module
21:19 < johill> and then the x driver communicates through that. hmm
21:19 < marcheu> no
21:19 < marcheu> the device /dev/nvidia0 exposes a number of areas
21:19 < johill> why else is it created then?
21:19 < marcheu> among those are some mmio regs, and the fifo
21:19 < marcheu> most of the rest is the node from user space
21:20 < marcheu> is then done
21:20 < johill> do you have any document explaining how this works? it's most likely totally different on osx and I'll need to understand this to see why re.c is written that way
21:20 < marcheu> I don't think it would be really different on osx. the hw still exposes the fifos
21:21 < marcheu> and I think the driver takes advantage of that
21:21 < johill> to userspace?
21:21 < marcheu> yeah
21:21 < marcheu> can you list a process's mappings on osx ?
21:21 < johill> I don't have the osx box here
21:21 < johill> at least not  the one with the nv card
21:21 < marcheu> most probably you'll find one maping which holds the fifo
21:22 < johill> ah
21:22 < marcheu> or else, you'll have to map it yourself (does osx feature something like /dev/mem ?)
21:22 -!- pmdata [i=patrice@ANantes-154-1-108-209.w86-214.abo.wanadoo.fr] has joined #nouveau
21:22 < johill> yeah
21:23 < marcheu> hey pmdata, u running for the biggest number of commits this week ?
21:24 < pmdata> yes
21:24 < pmdata> :)
21:25 < pmdata> I wonder if I could finish the nv10 tcl stuff
21:25 < pmdata> I am comparing 16 and 32 bits color and depth buffer values
21:25 < johill> oh and then there's vmmap under osx that lists the virtual mappings for a process
21:26 < johill> but I don't know off hand if it lists any mmapped stuff
21:27 < marcheu> vmmaps are probably ok
21:27 < marcheu> (again, I don't know OSX so...)
21:27 < johill> me neither, really
21:28 < marcheu> in any case, you'll probably only have to touch re.c
21:28 < marcheu> and also comment out other stuff like nvctl
21:28 < marcheu> but for re.c, look at init_card()
21:28 < johill> I'll probably want to paste it into a new file
21:29 < marcheu> yeah, do as you like. the code is hacky anyway
21:29 < marcheu> bbl
21:29 < johill> and I know mine is pci-e too
21:29 < johill> later
21:29 < pmdata> I notice something in nv10 tcl stuff, commands 300-32c are alphabetically listed
21:30 < pmdata> so command 318 is some L*-P* stuff to enable
21:30 < pmdata> and command 328 is between SM*-ST* enable
21:35 < johill>         pid_t pid=getpid();
21:35 < johill>         sprintf(s,"cat /proc/%d/maps | grep " NV_DEV " > "MAPFILE, pid);
21:35 < johill> eh
21:36 < johill> /proc/self/maps would do just fine ;)
21:48 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has joined #nouveau
21:49 -!- pmdata is now known as pmdata_miam
21:52 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has joined #nouveau
21:54 < Lumag> pmdata: could you please check whether values for nv04_scaled_image_from_mem suit to the nv10_scaled... offsets 0x300, 0x304 ?
22:06 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has quit ["Leaving"]
22:06 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has joined #nouveau
22:13 -!- pmdata_miam is now known as pmdata
22:14 < pmdata> lumag> which gl command should I use?
22:14 < Lumag> hmm... As for me, the scaled image is used for textures loading.
22:15 < pmdata> so which are your values?
22:16 < pmdata> here is a dump for a 64x64 texture:
22:17 < pmdata> 29e   0x00000000   0x00400040   NV10_SCALED_IMAGE_FROM_MEMORY_SIZE            = width = 64 | height = 64
22:17 < pmdata> 29f   0x00000000   0x00010080   NV10_SCALED_IMAGE_FROM_MEMORY_FORMAT          = pitch = 128 | UNKNOWN = 00010000
22:17 < pmdata> 2a0   0x00000000   0x00313000   NV10_SCALED_IMAGE_FROM_MEMORY_OFFSET          = 0x00313000
22:17 < pmdata> 2a1   0x00000000   0x00000000   NV10_SCALED_IMAGE_FROM_MEMORY_POINT           = u_int = 0 | u_frac*0x10 = 0 | v_int = 0 | v_frac*0x10 = 0
22:17 < pmdata> 2a2   0x00000000   0x00040050             {size: 0x1   channel: 0x0   obj: beef7702 opcode: METHOD }
22:17 < pmdata> 2a3   0x00000000   0x00000001    NV10_SCALED_IMAGE_FROM_MEMORY      [0x0050/4] = 0x00000001 | UNKNOWN = 00000001
22:19 < pmdata> oops I copied the wrong lines
22:19 < pmdata> 16 bits texture:
22:19 < pmdata> NV10_SCALED_IMAGE_FROM_MEMORY      [0x0300/4] = 0x00000007
22:19 < pmdata> NV10_SCALED_IMAGE_FROM_MEMORY      [0x0304/4] = 0x00000003
22:19 < pmdata> 32 bits texture:
22:20 < pmdata> NvType0089      [0x0300/4] = 0x00000003
22:20 < pmdata> NvType0089      [0x0304/4] = 0x00000003
22:20 < Lumag> 16-bit tex is GL_RGB and 32-bit GL_RGBA? 
22:21 < pmdata> both are gl_rgba, so maybe a1r5g5b5 and a8r8g8b8
22:22 < pmdata> yep, this is it
22:24 < Lumag> I would highly believe that 0x304 is a PRINT_MACRO(nv04_operations).
22:27 < pmdata> I did not try defining a palette texture, tnt and gf1-2 supports it
22:27 < pmdata> paletted
22:30 < pmdata> http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf has dave airlie's paper about open source graphics driver, page 19, nothing technical
22:31 < pmdata> just current state of various drivers
22:31 < pmdata> plus a nice mispelling for 'renoveau'
22:31 < Lumag> :)
22:35 < pmdata> edb> are you at home? could you make me some dumps for register combiners on nv20?
22:50 < pmdata> hum, 20c for nv10 seems to hold the depth and color buffer pitches, but as they are always the same, I don't which is which
22:51 < pmdata> I don't know where is each
23:13 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has quit ["leaving"]
23:14 -!- Aexoden [n=Aexoden@207-118-72-211.dyn.centurytel.net] has joined #nouveau
23:15 < pmdata> what is a context surface for nv?
23:15 < airlied> pmdata: the slides are also up at http://www.skynet.ie/~airlied/talks/ols06/ols2006.odp
23:16 < pmdata> how many kittens killed?
23:16 < airlied> about 4 :-)
23:18 < marcheu> pmdata: what test do you need ?
23:18 < pmdata> ah you're back, I just wanted to have more dumps to do the nv20 register combiners
23:19 < marcheu> anything in particular ? do you have extensive testing loops available already ?
23:19 < pmdata> the test_nv_register_combiners fonction should suffice, you just have to change one param at a time
23:22 < marcheu> ok, I'll make it a loop nest
23:22 -!- xaid [n=Xaid@d199-126-153-40.abhsia.telus.net] has joined #nouveau
23:23 < pmdata> don't forget to tell me what you changed
23:23 < marcheu> I'll add printfs :)
23:24 < marcheu> hmm, that's a lot of combinations
23:25 < pmdata> yep, just get back to the cvs version, and change the first gl_rgb in the input combiner to gl_alpha, and do a dump
23:26 < EdB> pmdata, i'm back
23:28 < pmdata> woot, 2 nv20 avail for dumps!
23:28 < marcheu> we should rather get you an nv20
23:28 < pmdata> I wonder where I could get one
23:29 < pmdata> with sufficient dumps, rc stuff could be done in 1 day
23:29 < marcheu> well, a couple of people proposed hw IIRC
23:29 < marcheu> next time someone does, we'll ask for a nv20 :)
23:30 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/nv28_rc.txt is the vanilla test
23:30 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/nv28_rc_alpha.txt is the one with GL_RGB changed into GL_ALPHA
23:30 < marcheu> but really it'd be more convenient if you could wipe up an extensive loop for the parameters you need
23:31 < pmdata> hum, I will try to think about it
23:32 < Lumag> airlied: I like the last slide :)
23:34 < EdB> edb_@nouveau.cvs.sourceforge.net's password:
23:34 < EdB> Permission denied, please try again.
23:34 < EdB> ???
23:34 < marcheu> is edb_ your login ?
23:35 < marcheu> what's in CVS/Root ?
23:35 < marcheu> you have to be using ext: not pserver:
23:35 < Lumag> EdB: IIRC authentication for cvs is possible only with ssh keys.
23:36 < EdB> marcheu, yes edb_ it's my login
23:36 < EdB> and i use ext
23:36 < pmdata> oops, marcheu, you must change both gl_rgb to gl_alpha
23:36 < EdB> Lumag, that work before 
23:36 < marcheu> pmdata: yeah, I more or less expected it :)
23:37 < marcheu> pmdata: file updated
23:37 < pmdata> yep, I just remember the rc doc
23:37 < marcheu> anyway I'll write that loop now
23:37 < marcheu> that'll be useful for nv30 rc :p
23:38 < pmdata> ok, 260 is input combiner 0 portion alpha, and ac0 is input combiner 0 portion rgb
23:39 < marcheu> feel free to fill up the nv20 stuff with a "to be checked" comment
23:39 < ddl> hey!
23:39 < airlied> Lumag: yeah yet again google and the internet produced the goods...
23:39 < pmdata> yep, now go back to gl_rgb, and use gl_combiner1_nv instead of 0
23:39 < pmdata> do a dump, and do the same for alpha
23:40 < marcheu> pmdata: no, now I'll do all the tests at once :)
23:40 < marcheu> hey ddl 
23:41 < pmdata> you have 8 combiners on nv20, so you can go to gl_combiner7_nv
23:42 < EdB> Your SourceForge.net password has expired - You must now choose a new password before logging into the site
23:42 < EdB> ...
23:42 < EdB> arg :o)
23:43 < marcheu> sf.net passwds can expire !
23:44 < EdB> it's seem
23:44 < marcheu> mine's the same since 2001
23:44 < marcheu> I'm concerned :)
23:46 < EdB> ok pwd is update
23:46 < marcheu> pmdata: there are only 7 GL_VARIABLE_A_NV ?
23:46 < marcheu> pmdata: A to j'ai
23:47 < marcheu> pmdata: A to "G"
23:47 < marcheu> stupid replacement
23:47 < EdB> marcheu, may it's because i don't log in sf web sire :o)
23:47 < marcheu> or maybe there's a setting "dont ever expire my 3-letter password" :)
23:47 < pmdata> yep, you have 4 for input and output combiners, and 7 for the final combiner
23:48 < pmdata> you don't need to parse all variables, as they are stored in 8 bits in each command
23:49 < pmdata> just parsing combiners and gl_rgb/gl_alpha should suffice
23:49 < marcheu> argh too late :)
23:49 < pmdata> anyway, it will show if they are the same as nv10
23:49 < marcheu> just let me 2 more minutes
23:50 < marcheu> so I don't change GL_PRIMARY_COLOR_NV either ?
23:51 < pmdata> this is a parameter, like and input mapping stored in the 8 bits for a variable
23:51 < pmdata> but you can change it if you want one more loop :)
--- Log closed Птн Июл 21 00:00:55 2006
