--- Log opened Чтв Июл 13 00:00:49 2006
00:07 -!- EdB [n=EdB@ARennes-251-1-72-239.w86-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
01:40 -!- pmdata [i=patrice@ANantes-154-1-11-121.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:26 < marcheu> ddl: http://icps.u-strasbg.fr/~marchesin/nvdri/10de_0281_bios.rom
03:05 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:49 -!- Duke` [n=gnu@ANantes-251-1-154-177.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
03:50 -!- _Demo_ [n=Demo@modemcable038.138-201-24.mc.videotron.ca] has joined #nouveau
04:16 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:53 < darktama_> Lumag: ok, at least part of the RAMIN2 entries are a hardware mirror of the "normal" RAMIN
04:55 < darktama_> http://rafb.net/paste/results/5bXXVb51.html
05:14 < darktama_> ok, and RAMHT is also mirrored by the hardware
05:25 < ddl> hi!
05:26 < darktama_> hey ddl
05:29 < ddl> hi darktama
05:29 < ddl> hows things going?
05:31 < darktama_> not too bad, trying to figure out what's going on with RAMIN/RAMHT on 256MB cards.. it seems they also exist in the framebuffer
05:33 < ddl> okey
05:33 < ddl> well, i have no idea about that stuff.. what is hashed by the ht?
05:33 < ddl> objects?
05:34 < darktama_> yup, the object handles (ie. 0xBEEF3097) are hashed to give a pointer into the hash table.. from there you can find a pointer to the object itself
05:35 < ddl> okey.. and the objects themselves are stored in RAMIN?
05:35 < darktama_> yup
05:35 < darktama_> well, RAMHT is actually also in RAMIN :)
05:36 < ddl> ok :)
05:36 < ddl> and they are usually the size of the amount of memory on your card?
05:37 < darktama_> nope, RAMIN is usually 0x007xxxxx in the card's registers.. but, on 256MB cards it seems part of it is still there.. and the entire RAMIN is in video ram
05:38 < ddl> ok, so its split up on those cards
05:38 < darktama_> mm, seems that way.. but I really have no real clue yet :)
05:39 < ddl> ok, just ask if you want me to test something
05:39 < darktama_> hmm, you have a 256MB card?
05:40 < ddl> actually no :)
05:40 < darktama_> hehe, damn ;)
05:40 < ddl> i think this card has 32mb onboard
05:41 < ddl> 6200 GO with TC
05:41 < ddl> PCI-E on my laptop
05:41 < darktama_> TC == TurboCache?
05:42 < ddl> yep
05:45 < airlied> quick q for a bystander: RAMIN?
05:45 < darktama_> instance ram
05:48 < airlied> has anyone written a what we know about nvidia cards wiki page yet?
05:49 < darktama_> hmm, not that I know of.. most of the info is scattered around cvs/renouveau/ and cvs/doc/.. and the object stuff (RAMIN etc) is documented in the EXA code
05:51 < airlied> I'm just doing a talk at OLS next week on open source driver efforts and I'm wondering if I can expand my nvidia section :-)
05:53 < airlied> bah CVS is still down will look later..
05:54 < darktama_> I can make tarballs if you like, cvs is working for me
05:55 < airlied> ah cvs is on sf? I thought fd..
05:55 < darktama_> yup, still on sf
06:21 < darktama_> mm, looks like there's going to be some great presentations at OLS.  I have to get to one of those events one day :)
06:26 < ddl> have you managed to compile the ddx lately?
06:27 < darktama_> yeah
06:27 < ddl> anything i need to know? :)
06:27 < darktama_> hmm, what's the error?
06:28 < ddl> looks like its depending on include files from the drm now
06:28 < ddl> hold, maybe i should just checkout a new version.. i might have been messing around with stuff
06:29 < darktama_> oh, yes.. nouveau_drm.h.. I didn't commit it when I made the ddx dependant on the drm
06:29 < darktama_> checkout the latest drm and copy it over
06:30 < ddl> it whines about the uintXX_t types, which are used in nouveau_drm.h
06:30 < ddl> i just made a quick hack and included netinet/in.h
06:31 < darktama_> stdint.h should do the trick, wonder why it doesn't complain here though..
06:32 < ddl> now i get errors on conflicting types for xf86dev_t
06:32 < ddl> sys/types.h
06:32 < ddl> i guess my system is pretty out-of-date now :)
06:32 < ddl> havent done any upgrades for approx 2 months
06:34 < darktama_> hmm, the only change I need is to copy nouveau_drm.h.. just did a fresh checkout.. I'm not running anything too recent Xorg-wise
06:35 < ddl> okey, ill try with a fresh copy
06:35 < darktama_> it's quite weird actually, I usually have to revert nv_exa.c to rev 1.1 before it'll compile.. didn't this time
06:37 < darktama_> oh wait, it helps if I compile in the correct dir :)
06:37 < ddl> heh
06:39 < ddl> ah, works now
06:58 < ddl> grr, i hate SF:s cvs
06:59 < ddl> its just telling me "permission denied", even though im sure i didnt type the wrong password 10 times in a row
07:21 -!- _Demo_ [n=Demo@modemcable038.138-201-24.mc.videotron.ca] has quit ["Leaving"]
08:45 -!- Colbert [n=colby@adsl-69-211-17-113.dsl.chcgil.ameritech.net] has joined #nouveau
08:47 < Colbert> Hi all, I'm back
08:47 < Colbert>  Tried a stereo context, failed as I expected
08:51 < Colbert> not surprising, since glxinfo dosn't report a stereo context
08:56 < Colbert> the more i think about the color buffers the more questions I get
09:00 < Colbert> Also I need to change my code, I am not getting consistant results on the first dump
09:11 < Colbert> should have picked less juicy low lying fruit, ;}
09:16 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
11:12 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has joined #nouveau
11:38 -!- colbert_ [n=colby@adsl-69-211-15-114.dsl.chcgil.ameritech.net] has joined #nouveau
11:38 -!- colbert_ [n=colby@adsl-69-211-15-114.dsl.chcgil.ameritech.net] has quit [Client Quit]
11:42 -!- colbert-dslcrash [n=colby@adsl-69-211-15-114.dsl.chcgil.ameritech.net] has joined #nouveau
11:43 -!- Colbert [n=colby@adsl-69-211-17-113.dsl.chcgil.ameritech.net] has quit [Read error: 110 (Connection timed out)]
11:43 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
11:44 < colbert-dslcrash> HI lumag
11:44 -!- Duke` [n=gnu@ANantes-251-1-144-96.w86-210.abo.wanadoo.fr] has joined #nouveau
11:45 -!- colbert-dslcrash is now known as Colbert
11:46 < marcheu> Colbert: did you try the softquadro nvclock ? that might enable stereo visuals
11:46 < Colbert> no, where is it, didnt see anything new in cvs?
11:46 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/nvclock-softquadro.tgz
11:47 < Colbert> cool thanks
11:47 < Colbert> been thinking more than programming.
11:48 < marcheu> I don't know if it actually does anything yet, I plan to benchamrk the difference today
11:48 < marcheu> but at least it fools glxinfo & friends
11:49 < Colbert> I'll have to stop kdm from starting, dont think nvidia.ko loads at startup
11:50 < Colbert> I'v been trying to get alist of questions that need to be answered about the color buffers.
11:52 < Colbert> 1:) Are the openGL Buffers created at boot, at the load of the driver,or at the creation of the openGL context? the third 
11:52 < Colbert> seems most  likely, but is it true or are all the buffers created at boot or driver load to maximum posible depth 
11:53 < Colbert> and resolution?
11:53 < Colbert> 2:) Are the GL_FRONT & GL_BACK buffers a sub section of the normal GLX (2d)framebuffer? If not, how is the transfer made?
11:53 < Colbert> 3:) what happens when there is more than one openGL program running, are the buffers recreated including the GL_AUXi buffers?
11:53 < Colbert> How is the context switch between programs done. DO they share the buffers, how is the state saved? what happens if the
11:53 < Colbert> sizes are different? If the AUXi buffers can be clobbered on context switches, how big are they and when are they made?
11:54 < Colbert> 4:) How is stereo context different from normal mono mode? How does it work if Q2 is true?
11:54 < Colbert> 5:) what happens if you try to write past the end of any buffer?
11:54 < Colbert> 6:) how does write work
11:54 < Colbert> 7:) How does read work?
11:54 < Colbert> 8:) How does clear work?
11:54 < Colbert> 6:) How does swap buffers work?
11:55 < Colbert> 7:) How does a copy from one of the GL_AUXi buffers to front or back work?
11:55 < Colbert> 8:) Are the buffers really RGBA or are they compressed?
11:55 < Colbert> 9:) Where are the buffers located in the cards memory?
11:55 < Colbert> If any one can think of stuff to add please do!
12:02 < Colbert> Right now I was just about to write some error handling code, in case the hardware actually reports errors, and not just the driver, since i plan on doing some thing that will trigger errors
12:02 < marcheu> hmm, that's a lot of questions
12:03 < marcheu> 1. the buffers are created at opengl context, except if you use the "UBB" quadro-only feature
12:03 < marcheu> in which case it's created at X startup
12:03 < marcheu> 2. transfers between back & front is made during glxSwapBuffers
12:04 < marcheu> 3. yup, each program has his own set of buffers
12:04 < marcheu> 4. what's Q2 ?
12:04 < Colbert> Im trying not to make assumptions? I guess i dont need to write test for all of them then
12:04 < marcheu> 5. you don't, hopefully. there's no memory protection on graphics hardware
12:04 < Colbert>  Are the GL_FRONT & GL_BACK buffers a sub section of the normal GLX (2d)framebuffer? If not, how is the transfer made?
12:05 < Colbert> thart was Q2
12:05 < Colbert> that
12:06 < Colbert> acually I wasnt expecting answers to this list, I was expecting more questions to ask
12:08 < marcheu> the write, reads and swap buffers all usually work using a blit copy
12:09 < marcheu> from/to a place in either video or system memory
12:10 < Colbert> do you think that the buffers wrap? Re: your answer to Q5
12:11 < marcheu> no, but the card can be programmed to do clipping so you usually don't write past your buffers
12:11 < Colbert> Ah, wasnt sure.
12:17 < Colbert> on the test code i pasted to you the other day, I dont get the same dump on consecutive runs at the dump of first  tested buffer, any sugguestion? add an addtional tri() before dump_before?
15:13 -!- Lumag [n=c2544702@hosting.cwn.ru] has left #nouveau []
16:28 < darktama_> what differs in the dump? I usually find only the buffer offsets change occasionally
16:30 -!- darktama_ is now known as darktama
17:39 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
18:03 -!- littlesniper [n=guillaum@195.99.98-84.rev.gaoland.net] has joined #nouveau
19:41 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:50 -!- littlesniper [n=guillaum@195.99.98-84.rev.gaoland.net] has left #nouveau []
20:14 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has joined #nouveau
20:15 -!- Gloubi [n=Gloubi@ABordeaux-253-1-46-7.w82-125.abo.wanadoo.fr] has joined #nouveau
21:18 -!- pmdata [i=patrice@ANantes-154-1-46-30.w81-53.abo.wanadoo.fr] has joined #nouveau
21:48 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
22:01 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Read error: 110 (Connection timed out)]
22:02 -!- stringfellow_ is now known as stringfellow
22:17 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
22:17 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has joined #nouveau
22:22 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
22:22 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has joined #nouveau
22:35 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
22:35 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has joined #nouveau
22:38 -!- Gloubi [n=Gloubi@ABordeaux-253-1-46-7.w82-125.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
22:58 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
22:58 -!- EdB [n=EdB@ARennes-251-1-14-81.w83-195.abo.wanadoo.fr] has joined #nouveau
23:59 -!- blx [n=x@h132n1c1o1028.bredband.skanova.com] has joined #nouveau
23:59 < blx> you are so great for doing this ;)
--- Log closed Птн Июл 14 00:00:49 2006
