--- Log opened Птн Июл 14 00:00:50 2006
00:12 < marcheu> <hint> so if you help us, you'll be great as well </hint>
00:14 < blx> marcheu, i don't know if i know enough about this to be of much help tho
00:15 < airlied> marcheu: do you have a few mins? I just want to ask some qs on nouveau for an OLS presentation next week..
00:15 < pmdata> hello
00:15 < marcheu> blx: well, you could hang in here until you start understanding stuff. that's what I did at first (I hung on #dri-devel for ~6 months before understanding enough for a first patch)
00:16 < marcheu> airlied: hmm, about what ?
00:16 < pmdata> just one question: is a value like 0xbeefxxxx always an object?
00:16 < marcheu> pmdata: hey
00:16 < marcheu> pmdata: usually, yes
00:16 < pmdata> ok
00:16 < marcheu> pmdata: it inherits from the 0xbeef0000 one
00:16 < blx> marcheu, well. i do own a nvidia card
00:16 < airlied> marcheu: just general status.. presentation is about open source driver...
00:16 < marcheu> other "master" objects exist, though, but it seems they are only used for 2D
00:16 < blx> i guess it wouldnt hurt to try.
00:16 < marcheu> airlied: sure. go ahead
00:17 < airlied> so have you any ideas on a hopeful timeline? i.e. first triangle or simple Mesa drawing?
00:18 < airlied> or what is left to RE before an attempt can be made..
00:18 < marcheu> god I hate that question. I said 1 to 2 years 6 months ago, I'd stand on that estimate (so that's 6 months to 1 year and a half now)
00:18 < marcheu> about the info we have, it's mostly there : http://nouveau.cvs.sourceforge.net/nouveau/renouveau/nv_objects.h?revision=1.47&view=markup
00:18 < marcheu> and there http://nouveau.cvs.sourceforge.net/nouveau/doc/
00:19 < marcheu> note that nv30 stuff applies to nv40/g70 as well...
00:20 -!- EdB_ [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has joined #nouveau
00:20 < pmdata> it's better to list missing stuff needed to properly render a triangle
00:20 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has quit [Read error: 113 (No route to host)]
00:20 < marcheu> yup
00:21 < marcheu> so we need some DDX support, notably 3D buffer allocation. things like swapbuffers
00:21 < airlied> cool.. are you tackling other non DRI DDX features?
00:22 < airlied> or at least intending to tackle?
00:22 < marcheu> yes, at least what's needed
00:22 < airlied> like mergedfb or plain clone mode..
00:22 < marcheu> for example, the nv XAA is not worth keeping, so working EXA makes things easier
00:23 < marcheu> (with memory allocation for example)
00:23 < marcheu> darktama has been looking at dual head a bit, I don't think he put anything about that in CVS though
00:24 < marcheu> also, we need to do some bios parsing as well, which will have a number of side effects
00:25 < marcheu> the nvidia bios holds information about setting up tv out, or the correct card clock frequencies
00:25 < airlied> how much do we know about the BIOS? or is it all reverse engineer?
00:25 < marcheu> ddl is working on that
00:25 < marcheu> we know bioses up to nv30 (it's used in the beos/haiku driver already) and ddl has been working on nv40+ bios support (which is different, really)
00:26 < marcheu> nvidia never released information about their bioses, AFAIK
00:26 < airlied> cool how much of the code from the old utah-glx days from nvidia is of uses?
00:26 < marcheu> hah. approximately none, except on TNT
00:27 < marcheu> the issue is that the utah glx uses the non-TCL accelerated path on nv10 -> nv18
00:27 < marcheu> so it's only useful on <nv10 (which have no hw tcl support anyway)
00:27 < airlied> ah lovely...
00:27 < marcheu> if you look at nv_objects.h
00:28 < marcheu> NV04_DX5_TEXTURED_TRIANGLE is what utah glx/the haiku driver use
00:28 < airlied> are you just using Linux driver for RE or do you use the other OS?
00:28 < marcheu> NV10_TCL_PRIMITIVE_3D is the RE'd one for NV10 which uses hw TCL
00:29 < marcheu> just the linux driver. their support is good enough that we don't need other OSes :)
00:29 < marcheu> (so obviously, NV10 cards have a NV04 compatibility mode which the haiku & utah 3D driver use)
00:30 < marcheu> (and NV10_TCL_PRIMITIVE_3D RE was for a good part done by pmdata :)
00:31 < airlied> okay so how many of you are there actively committing RE info?
00:31 < marcheu> people come and go...
00:31 < pmdata> \o/ /me done a commit tonight
00:32 < marcheu> the number of active people right now must be around 5 maybe ?
00:33 < marcheu> pmdata darktama ddl lumag_offline marcheu 
00:33 < marcheu> am I forgetting anyone ?
00:33 < pmdata> so other people logged here are just reading? :)
00:33 < marcheu> well, EdB_ used to commit for example
00:34 < marcheu> looks like he's been busy
00:34 < EdB_> no enought time yes :o)
00:34 < marcheu> heh, np. nv20 is waiting for you :)
00:34 < EdB_> ans you've made many change 
00:35 < marcheu> (I think I fried my nv20, so you'll have to work twice as hard :)
00:35 < EdB_> arg :o)
00:36 < pmdata> the hard part is to find which gl commands to use to see differences in command parameters
00:36 < EdB_> was renouveau that fried your nv20 card ? :o)
00:36 < marcheu> EdB_: nope, but I was running SPECviewperf to benchmark my card before/after softquadro
00:37 < marcheu> EdB_: and.. you know the weather in alsace is quite hot :)
00:37 < EdB_> hehe in bretagne it's always rainning :o)
00:40 < marcheu> airlied: so, it's a team work, and it's going along very nicely for that reason I think. we're not stalled or anything
00:41 < airlied> marcheu: well I just want to mention it at OLS as part of my why I dislike closed source graphics drivers :-)
00:41 < marcheu> btw we should start writing some AUTHORS list before it's too late
00:41 < marcheu> maybe on the wiki
00:42 < airlied> oh and when are you moving to git :-)
00:42 < marcheu> heh, I think no one (including me) knows git :)
00:44 < blx> wich license is or will nouveau use?
00:45 < marcheu> depends on the parts. but we're not using anything strange
00:45 < airlied> actually is nv under MIT?
00:45 < marcheu> yup
00:45 < marcheu> we're keeping the same license for everything
00:45 < marcheu> blending into the flow :)
00:45 < blx> marcheu, i'd like to know wich licenses
00:45 < airlied> blx: MIT
00:46 < blx> ok, for all parts?
00:46 < marcheu> airlied: the DRI is different IIRC, but has similar implications
00:46 < marcheu> lemme dig
00:46 < airlied> DRI is MIT as well..
00:46 < airlied> the DRM is BSD/GPL dual..
00:47 < marcheu> yup, DDX is MIT, DRI is MIT, and DRM is BSD/GPL
00:47 < marcheu> (actually, DDX has one glitch, which is the stange nvidia license)
00:47 < blx> marcheu, nice.
00:47 -!- EdB_ [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:47 < blx> glitch?
00:48 < airlied> marcheu: that's what I wondered about..
00:48 < marcheu> yeah, glitch. the nvidia license is MIT-compatible, but it's not MIT
00:49 < marcheu> see the header of nv_setup.c for example
00:51 < blx> marcheu, it is free software still tho? i'm not an expert on licensing
00:52 < marcheu> blx: well, the "nv" DDX is distributed as free software and that license comes from it. I'm no lawyer either, but I trust other lawyers :)
00:54 < blx> marcheu, sounds good enough for me too then ;)
01:05 < Colbert> Hi. I'm back, was frustrated, just meant to sit back and think about sime stuipd programming error i made and fell asleep. there went thewhole day
01:17 < Colbert> and with typing like mine, no wonder I have errors
01:19 < Colbert> darktama, are you here?
01:19 < darktama> yup, just.. just woke up :)
01:20 < Colbert> (going to paste output) is this the chane in offset you meant?
01:20 < Colbert> http://rafb.net/paste/results/USMRBc22.html
01:21 < Colbert> dont know if I should be concerned with this, but dont understand it
01:21 < darktama> yup, the map addresses usually change between runs.. no need to be concerned really
01:22 < marcheu> although the physical adress alawys remains the same
01:22 < Colbert> ah, thanks. writing to the other buffers produced consistant results
01:22 < marcheu> so that's the thing to look at
01:23 < Colbert> and only the first buffer tested changed
01:24 < darktama> btw marcheu, nvidia doesn't put the command buffers in the fb here..
01:25 < marcheu> darktama: yeah, we have to decide if we follow that...
01:26 < marcheu> the advantage is that having the fifo in the fb is much more friendlier with exotic setups 
01:26 < marcheu> having the fifo in AGP/whatever area might be faster...
01:26 < darktama> hmm, it also means that the extra RAMHT and RAMIN aren't conveniently sitting just after the fifos
01:27 < marcheu> how is that an issue ?
01:28 < darktama> well, now we need to find out how that is setup :)
01:28 < marcheu> ah. yeah :)
01:28 < marcheu> we would have had to otherwise, too :)
01:28 < marcheu> that might be part of the nv_setup magic
01:29 < darktama> yeah, I'd expect as much.. or perhaps it's just disabled in the available code
01:30 < marcheu> I think some AGP users on buggy MAC chipsets will be happy if we put the fifo in video ram
01:30 < marcheu> or maybe we just don't decide, and let it as a kernel-tunable
01:30 < marcheu> yeah, I realize it's not much more complicated to have both
01:30 < marcheu> we can even add it as an afterthought if the interfaces are cleanly designed
01:40 < marcheu> which seems to be the case right now :)
01:40 < darktama> hm?
01:40 < marcheu> yeah, the ioctl creates a mapping. we don't care if it's located in video or AGP area
01:41 < marcheu> so we can later change the DRM to have the fifo in AGP area for example
01:41 < darktama> ah, hm.. did I merge that change yet or is it the command buffer address still hardcoded in the ddx?
01:42 < marcheu> well, I'm thinking about the drm interface right now
01:42 < marcheu> that's something that's hard to change later on
01:42 < marcheu> while DDX internals are easy to change
01:42 < marcheu> but maybe it would be easier to return a physical adress..
01:43 < darktama> indeed, though we don't have to worry about breaking the drm interface too much yet
01:44 < marcheu> of course ! but we have to think it well right now, because later will be too late for changes :)
01:44 < darktama> hehe, yeah
01:44 < marcheu> you know, the point where you say "oh, I wish I had done that" :)
01:44 < pmdata> you know most programming projects have a complete rewrite after a while ? :)
01:45 < darktama> currently I'm returning a drm_handle_t/size for both the FIFO buffer and regs in tho fifo_init ioctl
01:45 < darktama> I know that well :)
01:45 < darktama> s/tho/the/
01:45 < pmdata> then don't bother about current version, the latter will be better :)
01:46 < marcheu> well, we can look at the radeon driver and see all possible mistakes, and learn from it :)
01:48 < darktama> !
01:50 < pmdata> anyway, a complete rewrite can wait after the work is completed and almost in a working state...
01:54 -!- pmdata [i=patrice@ANantes-154-1-46-30.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:09 < ddl> hey!
02:11 < marcheu> ddl: yeh ddl, did you see I put the nv28 & nv34 bioses online ?
02:12 < ddl> nice, didnt see that.. thanks!
02:13 < ddl> been trying to figure out what the other bit entrys are used for
02:13 < ddl> since there are like ... 10 entries or so
02:13 < ddl> the 'P' entry seems to contain performance tables
02:14 < ddl> and i think i read in nvclock that 'S' was some kind of signon messages
02:15 < marcheu> yes, but if it's like for <nv40, it might be NULL
02:15 < ddl> have to find the RAM tables
02:15 < marcheu> so we better not rely on these
02:15 < marcheu> btw I also put a g70 bios, in case you're intersted
02:15 < ddl> nice
02:15 < ddl> every bios we can get will probably help
02:16 < marcheu> ok, I'll keep dumping those as I go
02:16 < ddl> you could make a note on how much memory, memory type and memory width too
02:16 < ddl> if you have the possibility to check
02:16 < ddl> and clocks also
02:16 < blx> i have a geforce 3 :)
02:16 < marcheu> hmm, clocks I don't know
02:17 < ddl> memory would be fine for now.. kind of focused on finding the ram tables
02:17 < darktama> ddl: I can get you a dump for 256MB NV40.. if you tell me how :)
02:17 < marcheu> the nv28 is (was) 128MB DDR
02:18 < ddl> the haiku-way of doing init_compute_mem might still be the right way to do it
02:18 < marcheu> the nv34 is 128MB and that's all I know
02:18 < ddl> if only we could find the ram tables
02:18 < marcheu> ddl: yeah, reading the regs ?
02:18 < ddl> mmm
02:18 < marcheu> ddl: reading the regs works 100% (except with nforce, but there we know how as well)
02:18 < ddl> 0x00101000
02:18 < marcheu> yeah, I can also get you a 256MB 6800 Ultra bios is you like
02:19 < ddl> darktama: nice, you could probably modify nvclock to dump the ROM
02:19 < ddl> i think that was what i used to do before
02:19 < marcheu> ddl: actually, nvclock dumps the rom in ~/.nvclock/bios.rom in first use
02:19 < ddl> havent made any dumps for over a year now, so i kind of forgot how :)
02:20 < ddl> ah, thats true
02:20 < darktama> oh, so it does :) nice
02:20 < ddl> i think you need to set some bit in a register to be able to read the ROM
02:20 < ddl> that should be documented in nvclock
02:21 < marcheu> that's in nv_bios.c actually
02:21 < marcheu> ok, 10de_0040_bios.rom is a geforce 6800 ultra with 256MB clocks 425/1100 mhz
02:23 < darktama> http://members.iinet.net.au/~darktama/bios_10de_0045_256MB_GDDR3.rom (6800GT 350/1000MHz)
02:25 < ddl> thanks! got all of them now
02:25 < ddl> do you know memory type and width also?
02:26 < ddl> nvclock -i should tell
02:26 < marcheu> ddl: all I know is from nvclock
02:26 < marcheu> ok, I can check then
02:26 < darktama> 256bit GDDR3 here
02:26 < marcheu> same here
02:26 < ddl> actually, maybe i could use the bioses to check
02:26 < ddl> thanks
02:26 < marcheu> yeah, I think nvclock reads that in the bioses, like the clocks
02:26 < blx> how does one check what kind and size of memory the card has?
02:27 < marcheu> if you need the info I can add it to my wikipage as I figure it though
02:27 < darktama> nvclock -i
02:31 < Colbert> marcheu. your nv20 died during the benchmarks?
02:32 < marcheu> yup
02:32 < marcheu> it's just a graphics card though
02:33 < Colbert> bummer, think it was the softQ in nvclock or just bad luck?
02:33 < blx> nVidia Geforce 3 Titanium 200  64 MB  128 bit DDR @  756.000 MHz
02:33 < marcheu> bad luck, I was benchmarking it in standard geforce mode.
02:33 < marcheu> bad luck and heat :)
02:34 < ddl> its usually the heat that is the issue :)
02:37 < Colbert> blx- your running yours at 756mhz? 
02:37 < blx> Colbert, that is the memory freq
02:37 < blx> according to nvclock
02:37 < blx> i have not overclocked anything
02:38 < Colbert> i seem to remember somthing about some ddr reporting the wrong speed. 
02:39 < ddl> have to go grab some food.. be back in an hour or so
02:41 < blx> http://pastebin.ca/87400
02:41 < blx> thats my nvclock
02:41 < blx> nvclock -i
02:45 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:46 -!- Duke` [n=gnu@ANantes-251-1-144-96.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
04:32 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
05:15 -!- _Demo_ [n=Demo@modemcable038.138-201-24.mc.videotron.ca] has joined #nouveau
05:28 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has quit ["Au revoir."]
05:59 < ddl> back
06:07 -!- Aexoden [n=Aexoden@207-118-77-189.dyn.centurytel.net] has quit [Remote closed the connection]
06:07 < Colbert> Wrote a error handling function that does a register dump, might be useful on something, doesnt do much on my colorbuffer code though.
06:07 < Colbert> http://rafb.net/paste/results/sG3CSD23.html
06:09 -!- Aexoden [n=Aexoden@207-118-77-189.dyn.centurytel.net] has joined #nouveau
06:55 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
06:55 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards
06:55 -!- Topic set by marcheu [] [Wed Jun 28 22:26:54 2006]
06:55 [Users #nouveau]
06:55 [@ChanServ] [ ag     ] [ blx    ] [ darktama] [ hiyuh        ] [ marcheu] 
06:55 [ Aexoden ] [ airlied] [ Colbert] [ ddl     ] [ lumag_offline] [ qfire  ] 
06:55 -!- Irssi: #nouveau: Total of 12 nicks [1 ops, 0 halfops, 0 voices, 11 normal]
06:55 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
06:55 -!- Irssi: Join to #nouveau was synced in 2 secs
06:57 -!- Aexoden [n=Aexoden@207-118-77-189.dyn.centurytel.net] has quit ["Leaving"]
07:03 -!- [freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
07:53 -!- Aexoden [n=Aexoden@207-118-77-189.dyn.centurytel.net] has joined #nouveau
10:18 -!- Colbert [n=colby@adsl-69-211-15-114.dsl.chcgil.ameritech.net] has quit [Remote closed the connection]
11:00 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has joined #nouveau
11:32 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
11:41 < Lumag> hi all
11:47 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (Ping timeout)"]
11:51 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
12:19 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
12:20 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has joined #nouveau
12:31 -!- pmdata [i=patrice@ANantes-154-1-85-45.w81-48.abo.wanadoo.fr] has joined #nouveau
12:32 < pmdata> hello
12:34 < pmdata> I started playing with nv_register_combiners, it seems everything start from command 0x260
12:35 < marcheu> hey
12:35 < marcheu> so UNK0260 is the combining mode ?
12:55 < pmdata> I think so
13:18 < pmdata> first try, find input mapping in bits 31-29 of 0x268
13:19 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
13:19 < pmdata> hum, if all goes this way, register combiners should be found easily
13:33 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has joined #nouveau
13:34 -!- Duke` [n=gnu@ANantes-251-1-133-139.w86-210.abo.wanadoo.fr] has joined #nouveau
13:35 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (EOF)"]
13:38 < pmdata> I will have problems writing very long define names for register combiners :)
13:44 < pmdata> does PRINT_BITFIELD support printing a single bit ?
13:57 < pmdata> I think I will commit what I found before losing my memory
14:00 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has quit ["quit"]
14:07 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
14:14 < pmdata> hi lumag
14:17 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
14:18 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has joined #nouveau
14:21 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/"]
14:21 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
14:22 < Lumag> hi
14:25 < Duke`> hi
14:27 < Lumag> pmdata: yes, just specify something like 12:12 --- that would be a single bit #12
14:28 < pmdata> yeah, I saw it was working
14:28 < pmdata> register combiner stuff is easy to find
14:31 < Lumag> :)
14:34 < pmdata> ok found everything related to input combiner
14:34 < pmdata> it would be nice to add some '\n' in the output :)
14:40 < Lumag> well... You can if you want, but I don't think it would make reading logs easier
14:41 < pmdata> for a single register combiner command, the output line can go to 200 characters
15:27 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
16:46 < darktama> pmdata: yeah, I split the output up for shader disasm
16:50 < pmdata> any macro to print a 32bit ARGB value in a8r8g8b8 format?
16:52 < pmdata> or I use print_bitfield?
16:53 < darktama> looks like you need to use bitfield
16:53 < darktama> could always make a new macro though
16:54 < pmdata> yes
16:57 < pmdata> any problem with  cvs? can not log to it
16:59 < darktama> hmm, I think ddl was having problems with it yesterday
16:59 < darktama> it eventually let him login
16:59 < pmdata> grr, just found constant_color for reg comb
17:58 -!- pmdata [i=patrice@ANantes-154-1-85-45.w81-48.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
18:00 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["Glory to ForestNet! / http://gate.forestnet.org/"]
18:10 -!- pmdata [i=patrice@ANantes-154-1-85-45.w81-48.abo.wanadoo.fr] has joined #nouveau
18:10  * pmdata had to reboot
18:17 < pmdata> ah, nearly finished register combiners
18:17 < pmdata> \o/
18:36 < pmdata> finished nv_register_combiners
18:36 -!- EdB [n=EdB@ARennes-251-1-59-100.w81-53.abo.wanadoo.fr] has quit ["Konversation terminated!"]
18:39 < pmdata> there is one command 284 which always has unknown bits set however
18:40 < marcheu>       Note the existance of an "speclit" input complement bit supported
18:40 < marcheu>       by NV10 (but not accessible through the NV_register_combiners
18:40 < marcheu>       extensions).
18:41 < marcheu> (from the register combiners spec)
18:54 < pmdata> I think I should  try nv_texture_env_combine4 (or even ext_texture_combine)
18:55 < pmdata> if you look at nv10_rc_input[] in objects.c, you'll see 2 values missing (6 and 7)
18:55 < marcheu> possibly. the spec seems to imply it uses the same stuff for both nv_texture_env_combine4 & NV_register_combiners
19:13 < pmdata> there is also this in the doc:
19:13 < pmdata>     Should we expose the full register combiners mechanism?
19:13 < pmdata>       RESOLUTION:  NO.  We ignore small bits of NV10 hardware
19:13 < pmdata>       functionality.  The texture LOD input is ignored.  We also ignore
19:13 < pmdata>       the inverts on input to the EF product.
19:19 < pmdata> what is OLS that airlied was talking about?
19:21 < pmdata> ah, found it http://www.linuxsymposium.org/2006/schedule.php
19:31 < pmdata> http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg :-)
19:32 < marcheu> hehe :)
19:33 < marcheu> actually, there's free room in the topic
19:33 -!- marcheu changed the topic of #nouveau to: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
19:39 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:19 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
20:43 -!- EdB|w [n=EdB@ARennes-251-1-149-58.w86-214.abo.wanadoo.fr] has joined #nouveau
22:03 < EdB|w> pmdata, i not real ! nvidia don't kill kitten ! do they ?
22:03 < EdB|w> :o)
22:06 < Duke`> nvidia doesn't, but god does!
22:07 < EdB|w> yes you're true nvidia is not god
23:07 < pmdata> I am trying to find the nv10 texture format (glteximage2d) it seems it is different for each nv class chip
23:08 < pmdata> what I found so far, trying the 38 texture formats:
23:08 < pmdata> 0	luminance
23:08 < pmdata> 1	alpha,intensity
23:08 < pmdata> 2	rgba8 (R8G8B8A8)
23:08 < pmdata> 3	?
23:08 < pmdata> 4	rgba2 (R2G2B2A2), rgb5_a1 (R5G5B5A1)
23:08 < pmdata> 5	r3g3b2 (R3G3B2), rgb4 (R4G4B4), rgb5 (R5G5B5)
23:08 < pmdata> 6	luminance_alpha,rgba,rgb10_a2,rgba12,rgba16
23:09 < pmdata> 7	rgb,rgb8,rgb10,rgb12,rgb16
23:09 < pmdata> now I must know how many bytes are used by each format
23:10 < pmdata> taking into account the fact that the hardware may not support all formats
23:10 < pmdata> any other texture format I could try?
23:12 < pmdata> or how can I find the format supported by the hardware?
23:13 < pmdata> http://www.flipcode.com/articles/internaltable.html
23:13 < pmdata> a good start
23:53 < pmdata> ok, found them
--- Log closed Сбт Июл 15 00:00:50 2006
