--- Log opened Вск Авг 13 00:00:12 2006
00:20 -!- pmdata [i=patrice@ANantes-154-1-37-155.w81-53.abo.wanadoo.fr] has joined #nouveau
00:25 -!- KoalaBR_ [n=KoalaBR@port-83-236-14-27.dynamic.qsc.de] has joined #nouveau
00:36 -!- Myrizio [n=Myrizio@host32-98.pool80104.interbusiness.it] has quit ["Leaving"]
01:09 -!- K [i=hazel@tor/session/external/x-86085f0f424eafcf] has quit [Remote closed the connection]
01:14 < KoalaBR_> Hi. Has anyone seen a 0x1800/4 command?
01:14 -!- K [i=hazel@tor/session/external/x-9f35c570c3b4fabb] has joined #nouveau
01:15 < pmdata> which hw?
01:16 < KoalaBR_> Any hardware
01:16 -!- K [i=hazel@tor/session/external/x-9f35c570c3b4fabb] has quit [Remote closed the connection]
01:18 < pmdata> #define NV10_TCL_PRIMITIVE_3D_VERTEX_ARRAY_DATA		0x00001800
01:20 < KoalaBR_> I have written an occlusion test (well fleshed out a basic example found on the net), which outputs this command. I suspect, that the following parameter sets type of query and the query number
01:20 < KoalaBR_> and this is 1800 too
01:21 < pmdata> tcl engine is different between nv10,nv20 and nv30+
01:22 < KoalaBR_> 9db   0x00000000   0x01000080            NV30_TCL_PRIMITIVE_3D      [0x1800/4] = 0x01000080 | UNKNOWN = 01000080   could mean store GL_SAMPLES_PASSED_ARB for query 8 (counting from 0)
01:22 < KoalaBR_> Will do further checks
02:00 -!- pmdata [i=patrice@ANantes-154-1-37-155.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:03 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:06 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has joined #nouveau
02:16 -!- KoalaBR_ [n=KoalaBR@port-83-236-14-27.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
02:16 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:16 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:17 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:19 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:20 -!- Duke` [n=gnu@ANantes-251-1-100-16.w86-203.abo.wanadoo.fr] has quit ["Hello, Brain? Yeah, I miss you."]
02:21 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:22 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:24 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:25 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:28 -!- sturmflut changed the topic of #nouveau to: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | card dumps at http://nouveau.sourceforge.net/tests/ | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg | NV20/NV30 LIGHT and CLIP_PANE updates: http://www.lieberbiber.de/projects/files/sturmflut_CLIP_PLANE_and_LIGHTS.patch
02:30 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:31 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:31 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:32 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:32 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:33 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:33 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Read error: 104 (Connection reset by peer)]
02:34 -!- Myrizio [n=Myrizio@host212-101.pool80104.interbusiness.it] has joined #nouveau
02:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:35 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:36 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:36 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:37 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:37 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:38 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:40 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:40 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
02:42 -!- sturmflut changed the topic of #nouveau to: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | card dumps at http://nouveau.sourceforge.net/tests/ | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg | NV20/NV30 LIGHT and CLIP_PLANE updates: http://www.lieberbiber.de/projects/files/sturmflut_CLIP_PLANE_and_LIGHTS.patch
02:48 -!- svu [n=svu@194.46.173.108] has joined #nouveau
03:07 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
04:54 -!- stillunknown_ [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
04:56 -!- atcl [n=Universe@L9e9d.l.pppool.de] has joined #nouveau
04:57 < stillunknown_> i just wanted to say i admire the effort, my knowledge is too limited to help unfortunately
05:03 -!- atcl [n=Universe@L9e9d.l.pppool.de] has quit [Read error: 104 (Connection reset by peer)]
05:03 < stillunknown_> We are looking for some unknown command, often called NV30_TCL_PRIMITIVE_3D (Family name may change). If you compare the data from f97 to f9a with the data the test will send to the card, it becomes clear, that 0x00000000 = 0.0f, 0x3c23d70a = 0.01f, 0x3ca3d70a = 0.02f and 0x3cf5c28f = 0.03f, exactly the data, the program sent for plane 0. [0x1478/4] is still unclear, but could have something to do with the enabling of the clip pl
05:04 < stillunknown_> from the example page, i wonder where they get the 0.0f, 0.01f, etc from
05:35 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #nouveau
06:00 -!- Myrizio [n=Myrizio@host212-101.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
06:08 -!- _Demo_ [n=Demo@modemcable206.154-131-66.mc.videotron.ca] has quit ["Leaving"]
06:11 -!- TMM [n=hp@c51471f2c.cable.wanadoo.nl] has joined #nouveau
06:12 < TMM> hi
06:12 < TMM> nice picture :) poor kittens, see, that is why I never buy nvidia gear
06:15 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has joined #nouveau
07:15 < darktama> airlied: over in #nvidia AaronP mentioned he'd looked at adding dual-head to the Xorg driver, but it didn't look feasible.. he said apparently there's no reliable way to detect how to program the CRTCs properly
07:15 < darktama> and that's why Mark refuses to add support
11:34 -!- KoalaBR_ [n=KoalaBR@port-83-236-13-7.dynamic.qsc.de] has joined #nouveau
11:35 < KoalaBR_> stillunknown_: Found out, where the values for 0.01f etc. come frome?
11:58 -!- KoalaBR_ [n=KoalaBR@port-83-236-13-7.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
12:06 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
12:34 -!- EdB [n=EdB@ARennes-251-1-17-65.w81-250.abo.wanadoo.fr] has joined #nouveau
12:52 -!- EdB [n=EdB@ARennes-251-1-17-65.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
12:57 < stillunknown_> KoalaBR_: i know you're gone, but no, i was sleeping and i'm a newbie at reverse engineering
13:02 < stillunknown_> was just curious how the writer came to that conclusion
13:04 -!- Duke` [n=gnu@ANantes-251-1-100-16.w86-203.abo.wanadoo.fr] has joined #nouveau
13:07  * Duke` plugged his old GeForce2 MX
13:07  * Duke` love fanless cards
13:08  * ajmitch has a fanless 6600GT :)
13:08 < Duke`> hum and there even is a bug that no longer appear with GLUT
13:08 < Duke`> I should fill a bug report to nvidia
13:09 < Duke`> ajmitch : does it work well? no temperature problem?
13:09 < ajmitch> works quite well, but I don't use it much for games
13:10 < ajmitch> only when I feel like playing doom3 every so often :)
13:10 < stillunknown_> ajmitch: which one do you have?
13:10 < ajmitch> stillunknown_: sorry?
13:10 < stillunknown_> there are a few types of fanless 6600gt's
13:10  * ajmitch shrugs
13:10 < Duke`> I don't play a lot too, just make some opengl apps sometimes for fun
13:12 < stillunknown_> i have the first fanless 6600gt gigabyte made and it's really airflow dependent
13:13 < stillunknown_> on my old mainbord there was no temperature wall i could find
13:13 < ajmitch> I haven't really seen problems with this
13:13 < stillunknown_> last time i tried on the new mainbord (first slot instead of third) it became 110 degrees Celsius  under load
13:14 < Duke`> o_O
13:14  * Duke` have a very bad airflow inside his computer
13:15 < stillunknown_> on purpose or not?
13:16 < stillunknown_> i have a low airflow system on purpose
13:20 < Duke`> I want to reduce the noise the much I can
13:20 < Duke`> it looks like that: http://tfc.duke.free.fr/screens/inside-after.jpg :-)
13:27 < stillunknown_> the case seems to be the limitation
13:27 < stillunknown_> no place to mount (large) fans
13:28 < stillunknown_> what kind of system is it?
13:40 < Duke`> herm... Athlon T-bird at 900 Mhz ;o)
13:50 -!- Myrizio [n=Myrizio@host210-102.pool80104.interbusiness.it] has joined #nouveau
13:51 -!- KoalaBR [n=KoalaBR@port-83-236-13-7.dynamic.qsc.de] has joined #nouveau
13:59 < KoalaBR> stillunknown_: Hm, the source of the test changed somewhat. the test I was referring to, did look different. Have a look at test_clip_plane_after_vertex() and there at line after the #endif
14:00 < KoalaBR> stiilunknown_; That's how the test looked like when I wrote the docs, you'll see an array GLdouble planes[4*6]={ ...}  which contains exactly these values
14:02 < stillunknown_> is this reverse engineering effort done by feeding opengl commands into the card and seeing how it responds?
14:04 < KoalaBR> Yes exactly
14:04 < KoalaBR> I am currently adding some more text to the doc. will upload it later
14:05 < stillunknown_> so basicly action -> responce is documented?
14:06 < KoalaBR> Well, the tool does look at the state of the memory / fifo / registers before you try your mini OpenGL program and dumps the differences once you call dump_after()
14:06 < Myrizio> KoalaBR: is it necessary to have two machines for remote debugging to do renouveau tests like you do?
14:07 < KoalaBR> Why do you think, I do remote debugging? I run renouveau against my NVidia card :)
14:07 < Duke`> :)
14:08 < Duke`> you just need an nvidia card with nvidia's blob driver to run renouveau
14:08 < KoalaBR> Only thing you need is a computer with a working (in sense of 3d) NVidia card
14:08 < Myrizio> yes, but i was guessing you should avoid tmixing the commands to the card from different program...
14:08 < stillunknown_> so renouveau kills the user interface?
14:08 < Myrizio> if so i will try :)
14:09 < KoalaBR> Off course NOT!
14:09 < Myrizio> yup, i am surprised to know this...
14:09 < stillunknown_> what prevents you doing the tests on the same computer?
14:09 < Duke`> no, it reads the state of fifo/registers, then run the opengl test, then re-read the state of fifo/registers, and show what have changed
14:10 < Myrizio> great...
14:10 < KoalaBR> You can run more than one "program" on the gfx card, for example glxgears, Desktop, games... and still the cards distinguishes between all those programs and doesn't mix them up
14:11 < stillunknown_> what prevents you doing the tests on the same computer?
14:11 < Myrizio> but of course to do tests with the card i will need a remote ssh connection...
14:11 < KoalaBR> Each "program" has its own context which is switched when a new / other programs gets its execution time. Basically the same, like the kernel (Linux) makes sure the multitasking works
14:11 < Duke`> Myrizio : you aren't running an computer with an nvidia card?
14:12 < Myrizio> KoalaBR: i did not know that the card had such a good program (context?) handling, i was thinking that a software layer was putting things together...
14:12 < Myrizio> Duke`: yes i am!
14:12 < KoalaBR> Don't worry, just start your test and renouveau will dump only the changed data of your program :)
14:13 < Myrizio> KoalaBR: happy to now this :)
14:13 < KoalaBR> Myizio: Where the context switching is handled, we still don't know for sure. As far as I know pmdata, darktama and marcheu are trying to find that out
14:14 < KoalaBR> However, we need to know this only at the time where we start to write our own 3d enabled driver
14:15 < stillunknown_> do you think helping out is doable for someone with no reverse engineering knowledge, only a small amount of c knowledge and no opengl knowledge (in other words is there enough logic in the process)?
14:15 < Myrizio> ah, ok!
14:16 < KoalaBR> stillunknown_; Well, you can help in different ways:
14:17 < KoalaBR> 1. Try running all the tests on your card(s) and offer them here.
14:17 < KoalaBR> 2. We are looking especially for quadro card test
14:17 -!- pmdata [i=patrice@ANantes-154-1-108-70.w86-214.abo.wanadoo.fr] has joined #nouveau
14:17 < stillunknown_> i have a very common card unfortunately
14:18 < KoalaBR> 3. If you get a grip for reading the dumps, you could ask here for further dumps and try to find out differences
14:18 < KoalaBR> 4. Ask pmdata, Lumag, marcheu, darktama whether the could need help
14:19 < KoalaBR> So, I'm off for about an hour. Out to lunch :)
14:19 -!- KoalaBR [n=KoalaBR@port-83-236-13-7.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
14:19 < stillunknown_> i'll have a look at it and make some ebuilds for the tools first, i'd hate to manually update those things
14:20 < Myrizio> i have a very common card too, GF2MX (i have another one where i study, 6800GT, but it will be accessible only  at the and of august)
14:20 < stillunknown_> will have to wait for the 8774 drivers, using the nv driver atm
14:21 < Myrizio> why?
14:21 < Myrizio> bugs? :)
14:21 < stillunknown_> xorg 7.0 had strange memory behaviour at some point
14:21 < stillunknown_> so i upgraded to 7.1.1
14:22 < Myrizio> and it is not supported...?
14:22 < Duke`> some cards are soft-quadroable
14:23 < Duke`> so you can transform your card into a quadro with nvclock IIRC
14:23 < stillunknown_> xorg 7.1 introduced an ABI change, nvidia drivers are not compatible atm
14:23 < Myrizio> i know, i have been lurking on this IRC channel for some time :)
14:23 < Duke`> ubuntu edgy seems to be able to run nvidia's blob with xorg 7.1
14:23 < Myrizio> Duke`: i just need nvclock?!??
14:23 < stillunknown_> xgl perhaps?
14:24 < stillunknown_> since 3d rendering is not broken, just some 2d things
14:24 < Duke`> Myrizio : I don't know a lot about soft-quadro... and not all cards are soft-quadroable
14:24 < Duke`> stillunknown_ : no, 3D works
14:24 < Duke`> ah
14:25 < Myrizio> Duke`: ok, but nvclock is a graphic app, won't the nvidia binary blob get angry if the card suddenly become a quadro?
14:26 < Duke`> hu? nvclock is a command line app for me :)
14:27 < Duke`> but frankly I don't know how it works
14:27 < shenki> Duke`: you can run the drivers using -ignoreABI when starting X - but there's issues with text rendering
14:27 < Duke`> hum lol, just runned nvclock -s and my screen gone offline, then came back online...
14:28 < Myrizio> http://www.linuxhardware.org/nvclock/#screenshots
14:28 < Duke`> ah that's nvclock_gtk, the gtk frontend
14:28 < Myrizio> yup
14:28 < Duke`> but there is a command line frontend too
14:28 < Myrizio> ok, fair enough :)
14:29 < Duke`> but I'm not sure it's nvclock to use for softquadro...
14:29 < marcheu> darktama: hmm ? do you have a log of what AaronP said ?
14:30 < darktama> I do, one sec
14:30 < marcheu> Duke`: yeah, the first time you run nvclock it does that
14:31 < darktama> marcheu: http://sh.nu/p/2688
14:34 < marcheu> weird
14:34  * Duke` don't understand why it's not feasible
14:35 < marcheu> Duke`: for softquadro, you use nvclock -Q
14:35 < darktama> yup, I figure if the proprietary driver can do it.. there's no reason the OSS one cant
14:35 < marcheu> darktama: that's what I was thinking
14:35 < darktama> unless it'd require more info than AaronP's allowed to show to the public..
14:35 < Duke`> marcheu : ah, I don't have the re-nvclock, that's probably why I had a doubt about nvclock for enabling quadro mode
14:36 < marcheu> Duke`: the newer official nvclock does softquadro too, you just have to specify the last digit of the device ID you want
14:36 < Duke`> there's no doubt that world will enter nuclear war if this information is shown to the public
14:37 < marcheu> basically, do a lspci -n first
14:37 < marcheu> figure out the pciid of your card
14:37 < marcheu> go to http://pci-ids.ucw.cz/iii/?i=10de
14:37 < marcheu> and find your id there
14:37 < marcheu> then you can manipulate the last digit at your will
14:38 < marcheu> so for example I have a 10de:0150 (NV15 [GeForce2 GTS/Pro]) which I can run as a 10de:0153 (NV15GL [Quadro2 Pro])
14:38 < Duke`> 14af:7102	3D Prophet II MX
14:38 < marcheu> but you have to do that after a fresh boot, before starting X, and as root
14:38 < Duke`> I have this one
14:38 < marcheu> 14af ???
14:39 < Duke`> 10de:0110
14:39 < marcheu> ah
14:39 < Duke`> http://pci-ids.ucw.cz/iii/?i=10de0110
14:39 < marcheu> yeah, I have the same card, it's got a nice blue color :)
14:39 < Duke`> yes :)
14:40 < Duke`> is it softquadroable?
14:40 < marcheu> mine is
14:40 < Duke`> ok
14:40 < marcheu> into 10de:0113
14:40 < Duke`> you have the Dual-Display one?
14:40 < marcheu> nope
14:40 < marcheu> do you ?
14:40 < Duke`> no
14:40 < marcheu> it's quite rare
14:41 < marcheu> it's the earliest dual display card from nvidia
14:41 < Duke`> it was written Dual-Display when I bought my PC...
14:42 < Myrizio> wow, so maybe my card is softqadroable to...
14:42 < Myrizio> 10de:0110
14:42 < marcheu> Myrizio: most cards < nv30 are, just make sure you run the softquadroing before you start X on a fresh boot
14:42 < Myrizio> ok, i will try!
14:42 < Duke`> why a fresh boot?
14:43 < Duke`> can't I just stop X, run nvclock, and restart X? 
14:43 < marcheu> Duke`: because it has to be done before the card is fully initialized
14:43 < Duke`> ok
14:43 < pmdata> would be very interesting if you can use a stereo context with 2 displays
14:44 -!- K [i=hazel@tor/session/external/x-38350957c9b83493] has joined #nouveau
14:44 < Duke`> marcheu : but how can I know which digit to give to nvclock? I must try myselft some of them?
14:46 < marcheu> Duke`: it's the last digit of the pci id
14:46 < marcheu> Duke`: right now you have a 0, you want to turn that into a 3. so you give it a 3 :)
14:46 < Duke`> ok
14:46 < Duke`> 011x and I choose x?
14:46 < marcheu> yup
14:47 < marcheu> you can only change the last digit
14:47 < Duke`> ok
14:47 < marcheu> otherwise it would mean a different chip :)
14:47 < Duke`> :o)
14:48 < sturmflut> How does the behaviour of the card change when it is soft-Quadroed?
14:48 < Duke`> I'll try after the déjeuner, I have some blog entries to read before 
14:48 < pmdata> sturmflut> the driver uses more hw features
14:48 < pmdata> whereas non quadro use cpu stuff to do them
14:49 < Duke`> on Windows, is it possible to enable quadro mode too?
14:49  * Myrizio est en train de telecharger la CVS...
14:49 < sturmflut> Ah, so it would theoretically be better to put the card in Quadro mode all the time?
14:50 < marcheu> sturmflut: no, that'll probably speed up your CAD applications, but slow down your games
14:50 < pmdata> it also depends on the driver version
14:50 < sturmflut> Interesting
14:50 < marcheu> although it depends which applications/games of course
14:51 < pmdata> for example old drivers (3xxx or 4xxx) use cpu for clip planes, whereas later use hw (6xxx or 7xxx) -> feature promoted from the quadro part of the driver?
14:52 < pmdata> and it's easy for nvidia to say 'new driver Yxxx, with feature Z much much faster, don't buy ATI'
14:53 < Myrizio> lol :)
14:54 < sturmflut> Apropos clip planes, did anybody have a look at my patches?
14:54 < pmdata> I also wonder at which point the cpu is faster than gpu for some tasks
14:57 < pmdata> sturmflut> I did, nothing hard to read
14:58 < sturmflut> Sure, I just noticed that CVS had not changed 
15:00 < stillunknown_> if any of you had to estimate, how much of the work to get a basic driver is done once the feature matrix is completely green (and red)?
15:00 < pmdata> check the todo page on the wiki
15:00 < marcheu> sturmflut: why do you have only 7 nv20 lights ?
15:01 < pmdata> the problem is not sending commands, it is initializing the card to be in a usable state
15:01 < sturmflut> marcheu: light 0 to light 7, that makes 8 lights. Should I have more?
15:01 < marcheu> sturmflut: 1 to 7, that makes 7 lights
15:01 -!- pmdata is now known as pmdata_miam
15:03 < sturmflut> marcheu: I have definitions for light 0 to light 7 in my patch.
15:03 < marcheu> so, why don't you replace the patch in the topic ?
15:05 < sturmflut> I just re-downloaded it just to make sure it is the right one. I don't get the point. Please point me to a missing definition
15:06 < darktama> marcheu: can you send me NV30 output for http://sh.nu/p/2689 please :)
15:07 < sturmflut> "+#define NV20_TCL_PRIMITIVE_3D_LIGHT0_FRONT_SIDE_PRODUCT_AMBIENT_A ..." looks like I actually have light 0 on NV20
15:07 < marcheu> sturmflut: http://sh.nu/p/2690
15:07 < marcheu> darktama: no I can't, my nv30 is at work, and, hey, it's sunday ! :)
15:07 < darktama> ahhh, not to worry then :)
15:08 < marcheu> darktama: you can probably coersce another nv30 owner in here to run that :)
15:08 < Duke`> darktama: I can replug my nv34 if you want
15:08 < darktama> Duke`: sure, that'd be great if you have the time!
15:08 < Duke`> give me 15 mins
15:09 < darktama> k
15:09 < darktama> btw, NV20 is odd.. there are 3 separate writemasks in vertex programs
15:10 < sturmflut> marcheu: Ah, now I get it. That's because in the bitfield for NV20_TCL_PRIMITIVE_3D_ENABLED_LIGHTS there doesn't seem to be a bit for LIGHT0, maybe ist is active all the time
15:13 < sturmflut> At least I could not see a difference between glDisable(GL_LIGHTING) an glEnable(LIGHT0)
15:14  * Myrizio is trying to softquadro its card and will be back later...
15:14 < Myrizio> nvclock -Q x, is it right?
15:20 < Duke`> I'll now replug my nv34, brb
15:20 -!- Duke` [n=gnu@ANantes-251-1-100-16.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
15:25 -!- KoalaBR [n=KoalaBR@port-83-236-13-7.dynamic.qsc.de] has joined #nouveau
15:26 < KoalaBR> Hi again
15:29 < sturmflut> marcheu: Are you from Strasbourg?
15:30 -!- K [i=hazel@tor/session/external/x-38350957c9b83493] has quit [Remote closed the connection]
15:36 < KoalaBR> marcheu: What do we do, if the return value is stored in a register?
15:37 < KoalaBR> I'm working at the occlusion queries and I found out a few things
15:37 -!- Myrizio_ [n=Myrizio@host9-101.pool80104.interbusiness.it] has joined #nouveau
15:38 < Myrizio_> something went wrong...
15:39 -!- Duke` [n=aeris@ANantes-251-1-100-16.w86-203.abo.wanadoo.fr] has joined #nouveau
15:39 < Duke`> darktama : I'll be a bit late for nv34 (few minutes)
15:39 < Myrizio_> marcheu: how do i use nvclock to softquadro? -Q seem not to exist...
15:40 < darktama> no problem :)
15:40 < Duke`> an uncle have a pb with his windows... -_-
15:40 < marcheu> sturmflut: yes
15:40 < marcheu> sturmflut: so, the first light is not always enabled
15:40 < Duke`> just phoned when i shut down the computer
15:41 < marcheu> sturmflut: and there is actually a bit for light 0 in the nv20 enable reg
15:41 -!- Myrizio [n=Myrizio@host210-102.pool80104.interbusiness.it] has quit [Read error: 60 (Operation timed out)]
15:41 < darktama> mm, I love being asked to fix windows :S
15:41 < marcheu> KoalaBR: I guess we have to add some code to recognize registers and name them
15:41 < marcheu> Myrizio_: you have to use latest nvclock CVS, there is no official release with softquadro support yet
15:41 < darktama> KoalaBR: out of curiosity, which reg?
15:42 < marcheu> darktama: he's working on occlusion queries, so I guess it's a pixel pass counter
15:42 < darktama> yup, was wondering if it's a part of the 16MB aperture.. or somewhere else
15:42 < Myrizio_> marcheu: i am using it, i got it from :pserver:anonymous@nouveau.cvs.sourceforge.net:/cvsroot/nouveau, isn't it right?
15:42 < marcheu> Myrizio_: no, the real nvclock ! that one is deprecated
15:43 < Myrizio_> ah, ok :)
15:43 < marcheu> http://nvclock.cvs.sourceforge.net/nvclock/
15:43 < Myrizio_> thanks!
15:43 < sturmflut> marcheu: Strange, on my NV28 the register is 0x00000000 until it changes to 0x00000002 before LIGHT1 is enabled
15:43 < marcheu> I have a nv28 as well here
15:44 < sturmflut> Hm
15:44 < marcheu> and when I disable all lights, NV20_TCL_PRIMITIVE_3D_ENABLED_LIGHTS is 0
15:44 < Myrizio_> marcheu: may i write on the wiki that it is deprecated?
15:44 < marcheu> Myrizio_: sure
15:45 < Myrizio_> ok! just asking :)
15:45 < sturmflut> marcheu: I am using NVIDIA binaries 1.0.8762 on Ubuntu Efty with kernel 2.6.15-26-k7
15:45 < marcheu> Myrizio_: actually, we could just remove it and add mmtrace
15:45 < sturmflut> marcheu: So which bit is the one for LIGHT0?
15:46 < Myrizio_> ok, so maybe it's better doing both changes together
15:46 -!- Myrizio_ is now known as Myrizio
15:47 < KoalaBR> darktama: It's variable. Let's say you have 10 queries. then you will find the result for query x in the reg 0x02 + 4*x (x starts from 0)
15:47 < marcheu> KoalaBR: hmm, in what area is that ?
15:48 < marcheu> it's probably not a reg but rather some piece of agp mem
15:48 < KoalaBR> marcheu: I referred to renouveaus output:
15:48 -!- `DukeNukem` [n=aeris@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has joined #nouveau
15:48 < KoalaBR> Mapping 7 (regs)
15:48 < KoalaBR> Changed reg 0x0000002c from 0x00000000 to 0xa4b6dba0
15:48 < KoalaBR> Changed reg 0x0000002d from 0x00000000 to 0x180cbffc
15:48 < KoalaBR> Changed reg 0x0000002e from 0x00000000 to 0x0000c000
15:48 < marcheu> KoalaBR: yeah, renouveau names everything "regs" :)
15:49 < marcheu> when it doesn't know what it is
15:49 < KoalaBR> First two are always variable, although the 2. always starts with 180c
15:49 < KoalaBR> c000 are the number of pixels / units which were drawn for the tri()
15:49 < marcheu> strange, they have to use the whole 32bits to comply with the ARB accuracy
15:50 < marcheu> ah, ok I get you
15:50 < KoalaBR> Well the use 32 bit, I had a triangle with exactly 65536 pixels and got:
15:50 < KoalaBR> Changed reg 0x0000002e from 0x00000000 to 0x00010000
15:51 < darktama> at the top of the renouveau dump, what does the line say for map 7?
15:51 < KoalaBR> BTW: that's for query number 11 (as I said, starting from 0)
15:51 < KoalaBR> Wait a moment
15:52 < KoalaBR> darktama:  map 7	from 0xb7f2e000 to 0xb7f32000 size 0x4000 (physical 0x228b3000)	=> registers
15:52 < darktama> ok, so not in the register aperture then
15:52 < darktama> or AGP from the looks of that address
15:53 < KoalaBR> Got PCIe here
15:56 < KoalaBR> BTW: The driver disables almost everything or reduces it to the simplest value (Fog disabled, Logic OP, color mask disabled etc) then draws the tri() calls 1800/4 to store the value:
15:57 < KoalaBR> NV30_TCL_PRIMITIVE_3D      [0x1800/4] = 0x01000000      ---> Store the query result (that is the highest byte = 0x01) in the register for query nr (value & 0x00ffffff ) / 16
15:57 < KoalaBR> So here we store it in reg 0x02
15:58 < KoalaBR> Basically that's what I found out with the simple query test function
16:00 < `DukeNukem`> darktama : it seems that his windows is completly fucked :-)
16:00 < darktama> hehe, that's always the case :)
16:00 < `DukeNukem`> even the install process fail
16:00 < darktama> I had to do a reinstall for a friend of my mum's a week or so back.. that was.. fun..
16:01 -!- pmdata_miam is now known as pmdata
16:01 < `DukeNukem`> booting on the install cd fail
16:01 < `DukeNukem`> windows rlez :)
16:02 < `DukeNukem`> +u
16:02 < darktama> give him a linux distro instead :P
16:02 < `DukeNukem`> I'll had to help him with linux then...
16:02 < darktama> hmm, true
16:04 < marcheu> sturmflut: ok, if you add "PRINT_BITFIELD(3:3, print_macro, bool_data, "light 0"), I'm ok with your patch
16:04 < marcheu> sturmflut: what's your sf.net id ?
16:05 -!- Duke` [n=aeris@ANantes-251-1-100-16.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
16:05 < sturmflut> marcheu: Okay, I have to correct the patch and get an sf.net id
16:09 < sturmflut> marcheu: my sf.net id is sturmflut
16:10 < marcheu> added
16:11 < KoalaBR> welcome aboard, sturmflut  (if the name is a hint of what is to come, we will be drowning in patches :o)  )
16:12 < sturmflut> lol
16:14 < sturmflut> KoalaBR: If every day is as productive as yesterday that might even become true ;)
16:15 < sturmflut> marcheu: Thanks. Does that now alyo mean that I can make changes to the cvs?
16:16 < KoalaBR> Yes
16:16 < marcheu> sturmflut: well, I'm expecting you to commit your patch at least
16:16 < marcheu> but feel free to do more :)
16:17 < sturmflut> That's what I'm going to do now
16:26 < sturmflut> Okay, it's in.
16:26 < TMM> so, you guys do not RE the nvidia driver directly then?
16:26 < TMM> as in, binary RE?
16:28 -!- Myrizio_ [n=Myrizio@host29-96.pool80104.interbusiness.it] has joined #nouveau
16:31 < `DukeNukem`> finally the windows install started \o/ I can mount the nv34 card
16:31 < KoalaBR> TMM: No we don't...
16:32 < TMM> due to legal issues? or is it just not practical? I know a fair bit about binary RE, but, not so much about GL drivers
16:33 < pmdata> mostly not practical, the kernel module is 4MB and the libGL is 11MB
16:33 < TMM> presumably, a lot of the libGL stuff is mesa code, isn't it? :)
16:33 < darktama> no, nvidia don't use Mesa
16:33 < TMM> whaoh... they wrote their own GL implementation for linux?
16:34 < darktama> it's shared between Win/Mac/Linux
16:34 < TMM> ghe... quite impressive, really :)
16:34 < TMM> but, yeah, I can see how that isn't going to be a very nice thing to "binary RE"
16:34 < darktama> yes, nvidia seem to design things quite well imo
16:36 < TMM> so, do you guys use the utah tnt2 driver as a starting point? or is that not feasible? 
16:37 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has joined #nouveau
16:38 < Duke`> darktama : I'm ready
16:38 < Duke`> arg, noisy fan :(
16:38 < darktama> hehe
16:39 < darktama> ok, can you add http://sh.nu/p/2689 << those to the tests in test_vtxprog()
16:39 < darktama> you can #ifdef the rest out, I already have a dump of those
16:39 < pmdata> marcheu> to use renouveau on another os, we just need to mmap the mmio region, or something else is needed ?
16:40 < Duke`> ok
16:43 < pmdata> I also wonder if all these unknown commands in nv10 tcl are related to 3d, maybe they are just there to initialize tcl in a certain way
16:44 < Duke`> darktama : http://tfc.duke.free.fr/nouveau/nv34/card_10de-0326_test_vtxprog---darktama.txt
16:44 < TMM> if I dare ask: Where do you guys stand now, when it comes to a 3d driver? are you working on a driver? or 'just' on a datasheet?
16:45 < darktama> Duke`: thankyou :)
16:45 < Duke`> np
16:46 -!- johane [n=johan@84-217-89-131.tn.glocalnet.net] has joined #nouveau
16:46 < Duke`> btw, I lost my ubuntu boot splash screen when I switched from gf-2 to gf-fx, is it normal?
16:46 < KoalaBR> TMM: Read the doc on the homepage (Basically the matrix needs to be completely green (except for the NOs), then the only thing we can do is trying to write a driver
16:46 < Duke`> will it come back next boots?
16:46 < KoalaBR> However, some work is already under way (Memory manager)
16:47 < TMM> KoalaBR: ah, I wasn't entirely clear on that, because there are also links to drm/dri modules
16:47 < KoalaBR> Most dreaded thing currently: How can we power up / initialize the card
16:48 < TMM> this is maybe a strange suggestion, but, wouldn't it be possible to hack up xen to trap the pci/agp communications?
16:48 < TMM> it'd be slow as hell probably, if you need to emulate a full pci bridge, but, I wonder if it can be done like that
16:49 -!- `DukeNukem` [n=aeris@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has quit ["Away"]
16:49 < TMM> or poke a hole in the bocks pci bridge to tie it to the real hardware after it passes through it...
16:49 < KoalaBR> Hm, I seem to remember that this was not a good idea, but I am in no way an expert / guru in this channel. I slave away at the data which is thrown in my direction :)
16:49 < TMM> just thinking out loud, not entirely sure about that either :)
16:50 < TMM> probably get some nasty timing issues
16:50 -!- Myrizio [n=Myrizio@host9-101.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
16:50 < pmdata> then better use some pc emulator
16:51 -!- Myrizio_ is now known as Myrizio
16:52 < KoalaBR> Well, I think I figured occlusion queries out, coding :)
16:53 < johane> hello, I'm trying to build renouveau, but ioctl.c won't compile (cc -g -Wall `sdl-config --cflags`   -c -o ioctl.o ioctl.c
16:53 < johane> ioctl.c:19: error: expected declaration specifiers or ‘...’ before ‘sys_ioctl’) .. any ideas? the line _syscall3(int, sys_ioctl, int, fd, int, request, void*, pointer) does look a little strange to me
16:55 < KoalaBR> Which system?
16:58 < KoalaBR> johane: On which system / OS are you working, which compiler are you using?
16:58 < johane> I'm on ubuntu edgy, 2.6.17-6-386
16:58 < johane> gcc 4.1
16:58 < johane> gcc (GCC) 4.1.2 20060715 (prerelease) (Ubuntu 4.1.1-9ubuntu1)
17:00 < TMM> pmdata: bochs IS a complete PC emulator
17:00 < KoalaBR> Hm, I'm using gcc 3.3.6 and I don't get any warning at all
17:01 < TMM> johane: quite some stuff changed with the kernel headers lately. I had similar problems with the novell client for linux :)
17:01 < Myrizio> johane: try to add #include <asm/unistd.h>
17:02 -!- sturmflut changed the topic of #nouveau to: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | card dumps at http://nouveau.sourceforge.net/tests/ | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
17:02 < johane> ah, i suppose those includes pull in a few kernel headers(?)
17:02 < johane> Myrizio: it's already included
17:03 < Myrizio> ah :)
17:03 < Myrizio> do your asm/unistd.h define the syscall* macros?
17:06 < pmdata> tmm> /me was thinking about adding some emulated nvidia video device to bochs or qemu, would be a huge task
17:06 < johane> no mention of any syscall3 at least
17:07 < Duke`> (argg super, je demande à mon père de voir s'il peut retirer une fixation de ventilo en plastique sans le couper, et il trouve le moyen de le faire du côté circuit et de ripper avec son tournevis :(( grosse balafre sur le circuit imprimé...)
17:07 < johane> there's just a load of #define __NR_foo <number>
17:09 < Myrizio> johane: eh? there should be those definitions somewhere...
17:09 < TMM> pmdata: why not bridge the virtual pci bus from bochs to the 'real' nvidia card?
17:09 < johane> Myrizio: but that's the /usr/include/asm/unistd.h... /usr/src/linux-headers-2.6.17-6/include/asm-i386/unistd.h have: static inline _syscall3(int,execve,const char *,file,char **,argv,char **,envp)
17:10 < johane> still looks like a weird declaration to me though
17:10 < Myrizio> johane: that is defining a syscall
17:10 < Myrizio> johane: you need the macro definition
17:10 < johane> ah
17:12 < Myrizio> try grep -r "define _syscall3" /usr/include
17:12 < Myrizio> :)
17:14 < johane> nothing, there is in /usr/src/linux-headers-2.6.17-6/include/asm-i386/unistd.h though
17:14 < KoalaBR> Try commenting the line in iotcl.c (renouveau) out and retry...
17:14 < johane> gah, so many unistd.h's
17:15 < sturmflut> "FIFO channel couldn't be detected. PLEASE REPORT" <- I seem to have broken something, same binary worked some minutes ago
17:15 < TMM> pmdata: to reimplement a nvidia card in bochs, most things would already have to be known
17:15 < marcheu> pmdata: to use renouveau on another OS, you probably just have to map the fifo and register areas. the rest of the code can be shared
17:16 < marcheu> pmdata: but I don't think it's worth doing, except maybe macosX which uses a different driver
17:16 < johane> it compiles, but it doesn't link
17:16 < Duke`> rebooting, brb
17:16 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
17:17 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has quit ["Konversation terminated!"]
17:17 < pmdata> marcheu> I was thinking about win32 driver
17:18 < marcheu> pmdata: it's a unified driver for windows/linux, so I guess we'd just have the same output
17:18 -!- K [i=hazel@tor/session/external/x-a95f3af484b038de] has joined #nouveau
17:19 < marcheu> pmdata: but yeah, osX would be really interesting, as it's a different driver, which exposes different extensions
17:19 < marcheu> not to mention that it's big endian (most of the time)
17:19 < TMM> marcheu: 'most of the time'?
17:19 < johane> strange.. ioctl.c includes <linux/unistd.h> which says  * Include machine specific syscallX macros
17:19 < johane>  */
17:19 < johane> #include <asm/unistd.h>
17:19 < marcheu> TMM: think macintel :)
17:19 < KoalaBR> sturmflut: No problems here with most current version (NV43)
17:20 < KoalaBR> Which test are you using?
17:20 < TMM> marcheu: ah :) yes, I was thinking that :) I was wondering if mac did some O2 like big/small endian things internally or something
17:21 < Myrizio> johane: i you want i can send you my unistd.h so you can put it in renouveau directory and try
17:21 < marcheu> johane: could you past the full compile error ? on http://sh.nu/p/ ?
17:22 < johane> I have one in my kernel headers.. and it seems like linux/unistd.h tries to include that in turn, but it apparently only includes the gnu default one
17:23 < johane> (or maybe that would be s/gnu/posix/)
17:24 < TMM> johane: I'm running edgy as well, I'll give a whack at it
17:25 < TMM> has anyone got the cvs pserver command stuff for the module? :)
17:29 < johane> marcheu: there we go, http://sh.nu/p/2693
17:29 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has joined #nouveau
17:29 < johane> the problem seems to be that wrong header file is included from /usr/include/linux/unistd.h
17:30 < Duke`> hum it seems it failed to enable softquadro on my card... or maybe I did it too late (but X wasn't started yet)
17:31 < marcheu> Duke`: if you use nvidia fb, that could be an issue, yes
17:31 < TMM> lol, dependencies are broken in edgy, I can't install sdl-dev :)
17:31 < johane> ouch
17:31 < marcheu> Duke`: I do it as root, before I even start X
17:31 < marcheu> johane: what's in your /usr/include/asm/unistd.h ?
17:31 < TMM> sorry, can't look at it now
17:31 < johane> that's strange, i just did minutes ago
17:31 < Duke`> marcheu : I just disabled gdm from being run
17:32 < TMM> johane: wrong versions of libgl-mesa 
17:32 < TMM> for me anyway
17:32 < Duke`> marcheu : I'm using ubuntu, can the usplash be annoying?
17:32 < marcheu> Duke`: I suppose, I don't really know since I always disable all kind of fb on my systems though
17:32 < TMM> Duke`: the usplash is designed to not interfere with the graphics card too much, it is just a vga mode (640x480x8bit) shouldn't matter
17:33 < Duke`> ok
17:33 < Duke`> Myrizio have you been able to enable softwuadro?
17:33 < marcheu> Duke`: what card is it btw ?
17:33 < Duke`> ah my uncle phone... windows problem
17:33 < Duke`> gf2mx
17:34 < marcheu> yeah, should work with that
17:34 < marcheu> also, you should try some 7xxx driver, I think I only did it with that version
17:34 < marcheu> in any case, you have softquadro working is the output from lspci changes before/after
17:35 < Duke`> still 10de:0110
17:35 < johane> marcheu: http://sh.nu/p/2694, http://sh.nu/p/2695
17:36 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has joined #nouveau
17:36 < KoalaBR> sturmflut: No problems here with most current version (NV43)
17:36 < KoalaBR> Which test are you trying?
17:36 < sturmflut> It's okay, I messed up my X.Org setup
17:36 < KoalaBR> :)
17:36 < marcheu> johane: hmm, what does "grep -r _syscall3 /usr/include/*" say ?
17:37 < pmdata> duke> I have same problem with my nv15, can not change the device id with nvclock to softquadro it
17:37 < johane> marcheu: there is none
17:37 < TMM> what is a softquadro?
17:37 < johane> only under /usr/src/linux-headers-xxx/
17:38 < marcheu> pmdata: it's strange that it works on 4 of my cards and not for other people, though
17:38 < marcheu> johane: hmm, do you have kernel-headers installed ?
17:39 < Duke`> marcheu : I'm not sure with older drivers it would works, since nvclock says that it changed to 0x0110 when I ask for 3, even before loading Xorg and nvidia (or maybe the nvidia.ko is already interfering)
17:39 < KoalaBR> Softquadro: A normal GForce card modded by software to appear to the driver to be a quadro. Seems as if some of the functionality of a quadro is available on a GForce too but locked by the driver
17:39 < johane> marcheu: maybe i don't..
17:39 < marcheu> Duke`: it's really really weird, since it works here with what seems to be the same card
17:40 < johane> marcheu: yes, linux-kernel-headers is installed
17:40 < Duke`> I'll try to reboot in « recovery mode », and run nvclock, then continue the init script
17:40 < johane> goddamit
17:40 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
17:41  * pmdata should also try latest nvclock
17:42 < johane> should anything in /usr/include symlink to the kernel headers?
17:44 < marcheu> no, but the kernel headers used to build libc are in /usr/include/
17:44 < TMM> johane: there should be a link in /lib/modules/`uname -r`/build to /usr/src/linux-headers-`uname -r`/include
17:45 < marcheu> and it looks like your headers have been trommed down
17:45 < marcheu> trimmed*
17:45 < TMM> marcheu: ah, you link to the 'snapshot' linux headers? not the live ones?
17:45 < marcheu> TMM: yes, or you will break libc :)
17:45 < johane> marcheu: ok
17:45 < TMM> orcourse :)
17:46 < TMM> well, they will probably just no longer work with the new hax0r3d up ubuntu kernels
17:46 < TMM> I think there was some discussion on ubuntu-devel on that
17:46 < TMM> let me dig into my archive
17:47 < KoalaBR> marcheu: Regarding the occlusion query: I see a          NV30_TCL_PRIMITIVE_3D      [0x17c8/4] = 0x00000001    but 0x17c8 is also used when using the color buffer, then its value is 0x00000002  Any idea what name to choose?
17:47 < KoalaBR> This seems to be the "Activate Occlusion Query" thing
17:48 < marcheu> KoalaBR: just try to stay within the implicit naming convention used for the other regs :)
17:49 < KoalaBR>  NV30_TCL_ACTIVATE_SOMETHING  ? :)
17:49 < marcheu> well, we use ENABLE instead of ACTIVATE
17:49 < marcheu> maybe NV30_TCL_PRIMITIVE_3D_OCC_QUERY_ENABLE ?
17:50 < KoalaBR> Well, it occurs too, if you do something with the color buffers
17:50 < marcheu> or something like ?
17:50 < marcheu> s/or/do/
17:51 < TMM> hum, I was wrong
17:51 < marcheu> btw, it's quite possible that the driver has to manipulate occlusion query data internally
17:51 < TMM> I wonder why that still surprises me :)
17:51 < KoalaBR> Well, it can be seen on NV43 only if you run clear_buffer
17:51 -!- Duke` [n=gnu@ANantes-251-1-85-135.w86-203.abo.wanadoo.fr] has joined #nouveau
17:51 < marcheu> the radeon one has to disable queries when doing buffer clears for example
17:51 < KoalaBR> and only if this clear affects the color buffer
17:52 < TMM> anyway, is there anything someone with a background in binary RE can do for this project? I'd love to see open source nvidia drivers, I might actually start buying their hardware then :)
17:52 < marcheu> so, geforces are maybe some kind of radeons :)
17:52 < KoalaBR> I looked only through the NV40 results, nothing else
17:53 < Duke`> It still refuses to enable quadro
17:53 < KoalaBR> (results = The dumps on sf)
17:53 < marcheu> TMM: I'd prefer if you could learn "clear" RE, because binary disassembling is explicitly forbidden by the EULA of the driver (not that it applies everywhere in the world, but still)
17:53 < marcheu> s/clear/clean
17:53 < TMM> marcheu: doesn't apply to me :)
17:54 < marcheu> TMM: doesn't apply here as well, but you're better safe than sorry
17:54 < Myrizio> Duke`: no, i have not yet tried with the correct nvclock...
17:54 < Duke`> the idea of disassembling a big blob frighten me
17:56 < KoalaBR> working with x86 Assembler is a punishment. Only the most twisted minds don't go insane if they try to master it :)
17:57 < KoalaBR> Call it NV30_TCL_PRIMITIVE_3D_OCC_QUERY_OR_COLOR_BUFF_ENABLE perhaps?
17:58 < marcheu> KoalaBR: as I said, maybe it's just saved on buffer clears, for the same reason it is on radeon
17:58 < Duke`> those long names recall me the DirectX API :-))
17:58 < Duke`> made of plenty of long and ugly names (whithout "_")
17:58 < Myrizio> were talking about disassembling the 5Mb nvidia driver? :)
17:59 < Myrizio> ah, BTW, there are those NV30_ names coming from?
17:59 < Myrizio> s/there/where
18:00 < KoalaBR> Well, I chose this name, feel free to correct it, if you have sound reasons to
18:01 < marcheu> KoalaBR: yup, I guess we can rename it later on anyway
18:01 < KoalaBR> Yes, I don't mind
18:02 < Myrizio> ah, sorry, i was just curious, i was thinking names where coming from somethings else (ie nv, or open tokens)
18:02 < Myrizio> opengl tokens
18:02 < stillunknown_> what are renouveau dependencies?
18:03 < Myrizio> i think almost none... X11 headers?
18:03 < KoalaBR> basically SDL a working libGL.so (which results from a correctly installed nvidia driver)
18:03  * pmdata reboot to try nvclock again
18:03 -!- pmdata [i=patrice@ANantes-154-1-108-70.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
18:04 -!- maxtoo [n=maxtoo@berryx.homedns.org] has left #nouveau ["Les choses que l'on possède, finissent par nous posséder"]
18:11 -!- pmdata [i=patrice@ANantes-154-1-108-70.w86-214.abo.wanadoo.fr] has joined #nouveau
18:11 < pmdata> hum, nvclock want to set it to 0x150, whatever the value I give to '-Q x' parameter
18:14 < Duke`> it's your original pci id?
18:20 < pmdata> no, mine is 0x151 (gf2 ti)
18:22 < Duke`> so it only degrade your card? :p
18:27 < pmdata> yep
18:27 < pmdata> I read the nvclock source, it means get_gpu_pci_id() returns 0x150 when the program tries to modify the value
18:28 < pmdata> in set_gpu_pci_id()
18:31 < Duke`> so we can't do nothing?
18:32 -!- philv_ [n=bleep@cowpig.ca] has joined #nouveau
18:35 -!- philv [n=bleep@cowpig.ca] has quit [Read error: 104 (Connection reset by peer)]
18:36 < pmdata> maybe I have a real hw resistor that can't be changed on my card
18:36 < pmdata> I don't want to use soldering iron
18:38 < Duke`> arf
18:38 < Duke`> I used it to install my new CPU cooler on my mobo :)
18:39 < KoalaBR> marcheu: Current version added. Will have a look, whether I can make sense out of the other two changed regs when using occlusion queries. Anything else?
19:27 -!- philv_ is now known as philv
19:34 < marcheu> KoalaBR: maybe figure out texture uploads, in particular the texture pixel layout ?
19:34 < marcheu> KoalaBR: also, I don't think we know how to do compressed textures
19:35 < marcheu> KoalaBR: GL_NV_blend_square is probably esay to figure out
19:36 < marcheu> KoalaBR: I'd say just look at the extension string from glxinfo
19:36 < marcheu> on that note, gtg
19:42 < KoalaBR> Ok
20:07 -!- EdB [n=EdB@ARennes-251-1-51-103.w81-53.abo.wanadoo.fr] has joined #nouveau
20:18 -!- stringfellow [n=stringfe@a80-100-96-220.adsl.xs4all.nl] has quit [Remote closed the connection]
20:24 < sturmflut> I am doing something terribly wrong
20:25 < sturmflut> I extended test_lights (http://rafb.net/paste/results/IEVMGC85.html) and changed it so that every light has different values for GL_POSITION and GL_SPOT_DIRECTION but the code in the pastebin produces dumps where every Light is initialized with the same value
20:26 < sturmflut> http://rafb.net/paste/results/OcIjl677.html works
20:47 < sturmflut> Okay, works.
21:31 < KoalaBR> sturmflut: How good are your OpenGL skills?
21:33 -!- Myrizio [n=Myrizio@host29-96.pool80104.interbusiness.it] has quit ["Leaving"]
21:36 -!- atcl [n=Universe@L8b65.l.pppool.de] has joined #nouveau
21:40 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has quit ["Leaving"]
21:44 < sturmflut> KoalaBR: I tried to do some small things about two years ago but didn't have the time to finish anything.
21:45 < KoalaBR> Any demo on how to use GL_NV_blend_square() ? Or at least a link with a description? Can't seem to find anything beyond some theoretical specs
21:52 < pmdata> http://oss.sgi.com/projects/ogl-sample/registry/NV/blend_square.txt should be sufficient to make a test
21:54 < KoalaBR> Thanks :)
21:54 < pmdata> http://oss.sgi.com/projects/ogl-sample/registry/ for the complete list
21:56 < KoalaBR> pmdata: Hm, that's the spec again, which I don't understand, seems it expects some knowledge about OpenGL I don't have
21:56 < pmdata> this is just some extra mode for the glBlendFunc()
21:57 < KoalaBR> Grrr, ok that was a definately helpful info 
21:57 < pmdata> so copy/paste the test_blend, and try the extra modes
21:57 < KoalaBR> Thanks alot !
22:00 < KoalaBR> Probably I won't be able to test this before Tuesday
22:15 < pmdata> is the accum buffer accelerated on some hw?
22:16 < pmdata> quadro?
22:19 < pmdata> I added a test for draw buffer, so it should be easy to find which buffers are setup with a stereo context
22:56 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
22:57 -!- shenki [n=shenki@ppp175-149.lns3.adl4.internode.on.net] has joined #nouveau
22:59 -!- etzel [n=thisnuke@69-160-140-26.ontrca.adelphia.net] has quit [Read error: 54 (Connection reset by peer)]
22:59 -!- etzel [n=thisnuke@69-160-140-26.ontrca.adelphia.net] has joined #nouveau
23:09 -!- stringfellow_ [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
23:26 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Read error: 110 (Connection timed out)]
23:26 -!- stringfellow_ is now known as stringfellow
23:32 < KoalaBR> pmdata: Want me to run your new test (NV43 no quadro)?
23:33 < sturmflut> Hm does anybody know more about Macvidia?
23:35 < KoalaBR> Sorry, I don't have a Mac
23:36 < sturmflut> me neither
23:37 < sturmflut> I would like to know it is some work derived from an NDA with NVIDIA, a port of some other project or another Reverse Engineering effort
23:41 < KoalaBR> Hm...only statement there: Not open source
23:43 < sturmflut> The strange thing is that the binaries contain a lot of strings that have the same names as functions in the Linux kernel NVIDIA Framebuffer
23:45 < KoalaBR> Well, I have no idea. Wouldn't the authors of this fb be interested in that?
23:45 < sturmflut> Would be a strange coincidence if somebody chose names like "nvidia_delete_i2c_busses" and "nvidia_probe_i2c_connector" by "accident"
23:45 < sturmflut> yes, I think I'll send a mail
23:46 -!- EdB [n=EdB@ARennes-251-1-51-103.w81-53.abo.wanadoo.fr] has quit ["Konversation terminated!"]
23:55 < KoalaBR> That's the end for today. Will be back on tuesday.
23:56 -!- KoalaBR [n=KoalaBR@port-83-236-13-7.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
--- Log closed Пнд Авг 14 00:00:13 2006
