--- Log opened Срд Авг 09 00:00:09 2006
00:00 < KoalaBR> Sorry. don't know
00:18 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
00:18 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
00:18 < marcheu> pmdata: I don't think si
00:18 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Read error: 104 (Connection reset by peer)]
00:18 < marcheu> think so
00:25 < pmdata> this is strange I got different values when using it
00:25 < pmdata> for texture format
00:31 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
00:32 < Lumag> hi all
00:33 < KoalaBR> Hi
00:33 < marcheu> hi Lumag, what's new ?
00:33 < marcheu> Lumag: I've setup a machine here with a nv28 that people can access through ssh if you want
00:33 < Lumag> nothing :) We have milestone this friday, so working hard :)
00:33 < marcheu> ok :)
00:34 < Lumag> that may be interesting.
00:34 < marcheu> that explains the new pmdata nv20 commit crazyness :)
00:34 < Lumag> Probably I can give access to my nv06 box, but it isn't running 24x7.
00:35 < marcheu> I think I can add a PCI TNT2 on the same box, if needed
00:35 < KoalaBR> Is there any card already completely known?
00:36 < marcheu> yeah, it's a CT6950
00:36 < marcheu> KoalaBR: nope, and that will probably never happen :)
00:36 < Lumag> KoalaBR: about objects with type=0000. Can I see your logs somewhere?
00:36 < marcheu> KoalaBR: we don't need to figure out everything, just what we need
00:37 < marcheu> Lumag: anyway, ping me when work is over
00:37 < pmdata> marcheu> what about the tv encoder chips on the card? they're not from nvidia, but can they be accessed directly, without sending stuff to gpu?
00:37 < airlied> pmdata: via i2c I'd suspect..
00:37 < airlied> pmdata: but via the gpu i2c..
00:38 < pmdata> would it be an extra nv objecto on gpu?
00:38 < KoalaBR> Well, I have a problem here regarding the clip planes: my card works basically like that: Using NV30_TCL_PRIMITIVE_3D_VP_UPLOAD_CONST and a constant from 2d to 31
00:38 < Lumag> Also there is an object engine referenced as 'DVD'. dunno what it means:)
00:38 < airlied> pmdata: not sure how the i2c might work... it usually is just two bits in a register..
00:38 < marcheu> pmdata: not sure, the haiky driver can program tvout, did you look at its code ?
00:39 < KoalaBR> for each constant 4 Floats are written 
00:39 < KoalaBR> defining the clipping plane values
00:39 < KoalaBR> And then 1478 is sent in order to active certain clipping planes 
00:40 < pmdata> marcheu> no
00:41 < marcheu> yeah, it uses i2c
00:41 < pmdata> it's just that I planned buying a svideo cable to check if my tvout works
00:41 < marcheu> looks like that stuff is quite easy to get to work
00:41 < marcheu> it just requires one piece of code per type of TV encoder :)
00:42 < KoalaBR> Compared that to the dumps of the NV40 and NV34 on the webpage: Nv34 does it differently
00:42 < marcheu> KoalaBR: what's your card ?
00:42 < KoalaBR> NV43
00:43 < marcheu> what are the differences ?
00:43 < marcheu> I think I found 1478 in the NV40 dumps too
00:43 < KoalaBR> Lumag: Wait a second, I will post my last log via paste
00:44 < KoalaBR> Well the value following 1478 is always 0x00000000 on the NV34
00:44 < KoalaBR> NV28 sets only one plane at a time, no 1478
00:45 < marcheu> yeah, but nv20 is not relevant here, it doesn't have the NV30_TCL_PRIMITIVE_3D_VP_UPLOAD_CONST anyway
00:45 < KoalaBR> Ok
00:47 < KoalaBR> Lumag: http://rafb.net/paste/results/iTh37g80.html starting from line 130
00:48 < KoalaBR> Well, I will clean up the docs and patch tomorrow. Verify if anything changes in 24 bit depth and if everything is ok, I will commit it.
00:49 < Lumag> ok. known problem :) I thought it maybe something new :)
00:49 < KoalaBR> Lumag: If you need anything else, just ask, I read the IRC-Logs tomorrow in order to see if you need anything
00:49 < KoalaBR> For tonight is finish :)
00:50 < KoalaBR> Good night to you all
00:50 < Lumag> KoalaBR: probably nothing. I known only that darktama managed to overcome this problem for his card :)
00:50 < KoalaBR> Well, if I meet him, I will ask him about what he did...
00:50 < KoalaBR> See you
00:51 -!- KoalaBR [n=KoalaBR@port-83-236-14-30.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
00:57 -!- EdB [n=EdB@ARennes-251-1-72-74.w86-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:58 < pmdata> I would like other people to compare the texture_format output with texture_2d and texture_rectangle_nv, and tell what they think about it
01:01 < marcheu> on what card ?
01:03 < pmdata> any
01:04 < pmdata> I got strange results on my nv15 and your nv28 
01:04 < marcheu> I don't have anything else to test
01:04 < pmdata> this is why I put some _RECT in the nv10_tx_format array in objects.c
01:04 < marcheu> strange like ?
01:04 < pmdata> well, it's like using a different texture format when using a rectangle (npot) texture
01:05 < marcheu> yeah, maybe that's because textures have different layout
01:05 < pmdata> or maybe the texture format bitfield means something else in npot case
01:05 < marcheu> do you have dumps ?
01:05 < pmdata> there are some on your nv28 system
01:06 < pmdata> just grep TX0_FORMAT in files
01:08 < marcheu> it's pretty constistent
01:09 < pmdata> even for tx_rect.txt file?
01:10 < marcheu> well, each format from tx_rect matches one from tx-format
01:10 < marcheu> I would think these are just rectangle formats
01:10 < pmdata> I wonder why a different pixel format would be needed then
01:13 < marcheu> well, rectangle textures have a different memory layout on radeon
01:13 < marcheu> maybe it's something like that
01:13 < pmdata> hmm
01:14 < marcheu> but yeah, reusing the same value for L8A8 and not other values is strange
01:15 < marcheu> ah wait no it doesn't reuse it, my bad
01:19 -!- atcl [n=Universe@L9441.l.pppool.de] has quit ["Nobody needs a quit message :)"]
01:24 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
01:28 -!- `Duke` [n=gnu@86.72.5.75] has quit ["Segmentation fault"]
01:30 -!- K [n=hazel@212.145.81.31] has quit [Remote closed the connection]
01:50 -!- Duke` [n=gnu@ANantes-251-1-142-234.w86-210.abo.wanadoo.fr] has quit [Read error: 60 (Operation timed out)]
02:00 -!- Duke` [n=gnu@ANantes-251-1-144-35.w86-210.abo.wanadoo.fr] has joined #nouveau
02:04 -!- pmdata [i=patrice@ANantes-154-1-56-108.w81-53.abo.wanadoo.fr] has left #nouveau []
02:08 -!- Gloubi [n=Gloubi@ABordeaux-253-1-24-26.w82-125.abo.wanadoo.fr] has joined #nouveau
02:08 < Gloubi> hi
02:13 < marcheu> hi
02:19 < nano-> I think I've found something. Not sure what, but I can change UNKNOWNS by inputting diffrent glTranslatef(f,f,f) values.
02:20 < nano-> NV17
02:20 < marcheu> hmm ?
02:20 < marcheu> can you explain a bit more ? I'm not sure I follow you
02:21 < nano-> dhttp://exodus.xmms.se/~nano/tjo.txt
02:21 < nano-> 29b
02:21 -!- K [i=hazel@tor/session/external/x-356c0af7e70d2b6b] has joined #nouveau
02:22 < nano-> is related to the first parameter of glTranslatef, and 29f the last. 
02:22 < marcheu> yeah, the floats after NV10_TCL_PRIMITIVE_3D_PROJECTION_MATRIX are the matrix coefficients
02:23 < nano-> So why are they unknown?
02:23 < marcheu> they are unknown when treated as GL values
02:23 < nano-> So they are known :)
02:23 < marcheu> if you look at them as floats, they're very well know, since they are the homogenous matrix
02:23 < marcheu> try renouveau -f
02:23 < nano-> oh
02:52 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
02:55 -!- K [i=hazel@tor/session/external/x-356c0af7e70d2b6b] has quit [Remote closed the connection]
03:01 -!- Gloubi [n=Gloubi@ABordeaux-253-1-24-26.w82-125.abo.wanadoo.fr] has left #nouveau ["I'll be back"]
03:14 < Lumag> gtg
03:14 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
03:50 < qfire> I've uploaded all the g71 tests to sourceforge.
03:50 < qfire> pmadata: I've also included both texture_2d and texture_rectangle_nv for texture_format
04:03 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Read error: 104 (Connection reset by peer)]
04:18 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:49 -!- tibbs|h is now known as tibbs
04:57 -!- Myrizio_ [n=Myrizio@host189-101.pool80104.interbusiness.it] has quit ["Leaving"]
07:32 -!- shenki_ [n=shenki@ppp164-5.lns3.adl4.internode.on.net] has quit [Read error: 60 (Operation timed out)]
07:40 -!- shenki_ [n=shenki@ppp161-60.lns3.adl4.internode.on.net] has joined #nouveau
09:06 -!- shenki__ [n=shenki@ppp224-232.lns2.adl4.internode.on.net] has joined #nouveau
09:06 -!- shenki_ [n=shenki@ppp161-60.lns3.adl4.internode.on.net] has quit [Read error: 113 (No route to host)]
10:41 -!- `Duke` [n=gnu@86.72.5.237] has joined #nouveau
10:53 -!- shenki__ [n=shenki@ppp224-232.lns2.adl4.internode.on.net] has quit [Read error: 60 (Operation timed out)]
11:06 -!- shenki__ [n=shenki@ppp174-101.lns3.adl4.internode.on.net] has joined #nouveau
11:30 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
11:38 -!- EdB [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has joined #nouveau
11:40 -!- `Duke` [n=gnu@86.72.5.237] has quit ["Segmentation fault"]
11:48 -!- EdB_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has joined #nouveau
11:49 -!- EdB [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has quit [Read error: 113 (No route to host)]
12:10 -!- EdB_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
12:11 -!- EdB_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has joined #nouveau
12:12 -!- Koala_BR [n=KoalaBR|@195.227.227.59] has joined #nouveau
12:14 -!- EdB_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
12:26 -!- EdB_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has joined #nouveau
12:39 -!- Unavowed [n=silent@host81-151-25-104.range81-151.btcentralplus.com] has joined #nouveau
12:42 -!- Myrizio [n=Myrizio@host65-96.pool80104.interbusiness.it] has joined #nouveau
12:56 -!- Anne_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has joined #nouveau
13:00 -!- EdB_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
13:26 -!- Anne_ [n=EdB@ARennes-251-1-56-247.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
13:27 < marcheu> let's see if I can add the nv06 to the box as well
13:28 < darktama> marcheu: almost got NV20 vtx progs done.. just reworking the disassembler a bit before I finish it off
13:48 < marcheu> wow
13:57 < marcheu> I'm trying to get the nv28 to play nice with tne nv06 right now
13:57 < darktama> someone in #nvidia was having trouble getting two cards to play nice a couple of hours ago :)
13:58 < marcheu> well, it starts on both screens
13:58 < marcheu> but renouveau doesn't see the nv28 dump
13:59 < marcheu> wait, stupid me
13:59 < marcheu> you have to use re2 on the nv28 :)
13:59 < marcheu> so
13:59 < darktama> ahh, I wondered what re2 was
13:59 < marcheu> DISPLA=:0.0 is the nv06, usable with ./renouveau
13:59 < marcheu> DISPLAY=:0.0 is the nv06, usable with ./renouveau
13:59 < marcheu> DISPLAY=:0.1 is the nv28, usable with ./re2
14:03 < darktama> btw, I quickly looked at a nv30 dump.. and the vtxprogs look very similar to nv20's.. at least, closer than nv40
14:11 < marcheu> yeah, the more I look at it the more nv30 looks like a bastard card between nv20 & nv40
14:17 < Koala_BR> darktama: ping
14:17 < darktama> pong
14:18 < Koala_BR> Hi, just a short question: http://rafb.net/paste/results/iTh37g80.html I still get  errors, mracheu said you had those too?
14:18 < Koala_BR> (Line 130 in the dump)
14:20 < darktama> hmm, how much memory on that card?
14:20 < Koala_BR> 128 MB
14:21 < darktama> well, there goes the theory of the weird RAMIN being only on >=256MB cards..
14:21 < Koala_BR> Sorry :/
14:23 < darktama> ok, so I need to figure out how/where the use of the other RAMIN is setup then.. but it's not too high priority, as we can use the "normal" one anyway
14:24 < marcheu> we should display the memory amount in renouveau
14:24 < darktama> indeed
14:25 < Koala_BR> Currently I'm at the office (lunch break) but I can do tests later today if you'd like me to
14:25 < darktama> I'll add some code to ioctl.c to check FB changes before/after an ioctl().. for those people who are patient enough to wait a long time
14:25 < marcheu> darktama: did you try that yet ?
14:25 < marcheu> I don't think that'll work
14:26 < Koala_BR> long time = x minutes?
14:26 < darktama> yes, that's how I found where my second RAMIN was
14:26 < marcheu> maybe wait for the card to idle before doing that
14:27 < darktama> hmm, I didn't notice any lockups when I did it.. but better to be safe I suppose
14:27 < darktama> I'd have to wait for idle before reading every byte wouldn't I? in case X decides to draw something
14:28 < marcheu> you can't totally avoid that unless you own the proprietary driver's lock anyway
14:28 < darktama> true
14:29 < Koala_BR> Just add the code,let me know what to do and I will test it when I'm back home 
14:29 < darktama> ok, I might not get to it tonight though.. probably tomorrow mornig
14:29 < marcheu> darktama: about RAMIN, I think it's simply because it's getting to big for the register aperture
14:29 < darktama> morning*
14:29 < darktama> yes, that's what I figured aswell
14:30 < Koala_BR> It's ok, I still have other things to do regarding the clip planes
14:31 < Koala_BR> Just let me know, as I read the IRCLogs, just post with my name and tell me what you need :)
14:31 < darktama> ok :)
14:32 < Koala_BR> Ok, back to lurking mode, see you later
14:52 -!- EdB [n=EdB@ARennes-251-1-2-89.w83-195.abo.wanadoo.fr] has joined #nouveau
15:14 -!- Duke` [n=gnu@ANantes-251-1-144-35.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
15:14 -!- Duke` [n=gnu@ANantes-251-1-144-35.w86-210.abo.wanadoo.fr] has joined #nouveau
15:15 -!- EdB [n=EdB@ARennes-251-1-2-89.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:52 -!- Myrizio_ [n=Myrizio@host62-98.pool80104.interbusiness.it] has joined #nouveau
16:02 -!- Duke` [n=gnu@ANantes-251-1-144-35.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
16:06 -!- Myrizio [n=Myrizio@host65-96.pool80104.interbusiness.it] has quit [No route to host]
16:16 -!- Duke` [n=gnu@ANantes-251-1-144-35.w86-210.abo.wanadoo.fr] has joined #nouveau
16:23 -!- philv [n=bleep@cowpig.ca] has quit [Read error: 110 (Connection timed out)]
16:24 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:28 -!- tibbs is now known as tibbs|h
17:25 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit [Read error: 54 (Connection reset by peer)]
17:48 -!- philv [n=bleep@206.248.168.1] has joined #nouveau
17:48 -!- Duke` [n=gnu@ANantes-251-1-144-35.w86-210.abo.wanadoo.fr] has left #nouveau ["User commited suicide"]
17:48 -!- Duke` [n=gnu@ANantes-251-1-144-35.w86-210.abo.wanadoo.fr] has joined #nouveau
17:53 -!- philv_ [n=bleep@cowpig.ca] has joined #nouveau
17:54 -!- philv [n=bleep@206.248.168.1] has quit ["leaving"]
17:54 -!- philv_ is now known as philv
17:59 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
18:20 -!- shenki__ is now known as shenki
18:43 -!- Unbeliever [i=hazel@tor/session/external/x-f3cc3f8b6f0af394] has joined #nouveau
18:56 < marcheu> btw one thing that can be very interesting to figure out are occlusion queries
18:56 < marcheu> I think it's possible to abuse those to get some useful information
18:57 < marcheu> like the frequency of texture usage
18:57 < marcheu> and then feed that information to the memory manager
19:00  * philv sighs...
19:00 < philv> Anyone see that chain of emails on xorg mailing list ranting about ATI
19:01 < Duke`> philv : yep
19:01 < philv> My contacts at ATI saw that.
19:01 < philv> And now I'm back at square one.
19:01 < philv> @_@
19:02 < philv> And it wasn't the anti-binary driver sentimet... it was that moron who posted "might as well use windows"
19:02 < Duke`> arf..
19:02 < philv> If I ever meet him in real life I'm going to knock him out
19:04 < marcheu> philv: ?
19:04 < philv> marcheu: a lot of people at ATI and I'm sure nVidia read the xorg developer mailing list.
19:05 < marcheu> yeah, but why were you in contact with ATI, and what the link between you and that thread ?
19:05 < philv> And when you get morons making blanket statements like "might as well use windows" they think that people don't really care.
19:05 < philv> marcheu: I work for an MNC that has relationships with ATI, and I've gradually been trying to wrest documentation from them.
19:06 < philv> i.e. I've made contacts there.
19:06 < marcheu> MNC ? what's that TLA ? :)
19:06 < philv> Multinational Corporation ;)
19:06 < marcheu> ok 
19:06 < philv> I just would love to see an open source driver that doesn't suck or at least a closed source driver that doesn't suck
19:07 < philv> And what I know of r300 causes me pain when I go through the radeon open source driver, heh
19:07 < marcheu> r300 works pretty well
19:07 < philv> Works well enough, yeah
19:07 < philv> Underutilizes the hardware though
19:07 < philv> That said, I'm using it right now and it works flawlessly for my purposes.
19:08 < philv> And if I still had an nVidia card I'd be contributing to this project, heh.
19:08 < philv> Instead all I get to do is sit back and watch ;)
19:31 -!- shenki [n=shenki@ppp174-101.lns3.adl4.internode.on.net] has quit ["http://xkcd.com/comics/fourier.jpg"]
19:35 -!- Unavowed [n=silent@host81-151-25-104.range81-151.btcentralplus.com] has quit ["leaving"]
19:36 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
19:42 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:44 -!- Koala_BR [n=KoalaBR|@195.227.227.59] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.12/20050920]"]
19:52 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:42 -!- atcl [n=Universe@L994f.l.pppool.de] has joined #nouveau
20:49 -!- Gloubi [n=Gloubi@ABordeaux-253-1-7-69.w82-125.abo.wanadoo.fr] has joined #nouveau
20:51 -!- Gloubi [n=Gloubi@ABordeaux-253-1-7-69.w82-125.abo.wanadoo.fr] has left #nouveau ["I'll be back"]
21:17 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
21:26 -!- swany_ [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
21:35 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Read error: 60 (Operation timed out)]
21:57 -!- Unbeliever [i=hazel@tor/session/external/x-f3cc3f8b6f0af394] has quit [Remote closed the connection]
22:03 -!- KoalaBR [n=KoalaBR@port-83-236-15-176.dynamic.qsc.de] has joined #nouveau
22:14 < KoalaBR> Hi, anyone here?
22:18 < KoalaBR> marcheu: ping
22:21 < marcheu> hey
22:22 < KoalaBR> Hi, I have some smaller problems regarding clipping
22:23 < KoalaBR> 1. The command 1478 is defined as NV30_TCL_PRIMITIVE_3D but the definately work different on nv30 and nv40, so what to do?
22:23 < KoalaBR> 1478-> SetClippingPlanes
22:24 < marcheu> oh really ?
22:24 < marcheu> what's the difference between nv30 & nv40 for 1478 ?
22:24 < KoalaBR> Yes, I saw 1478 only twice in the dump for the nv34
22:24 < KoalaBR> and nv34 has always 0x00000000 as a parameter
22:25 < marcheu> so you didn't see it being used on nv30, that's what you mean ?
22:27 < KoalaBR> Well, I see it twice on the nv34 while i see it for every Enable(GL_CLIP_PLANE0+x) on NV43
22:28 < marcheu> maybe clip planes are broken on nv30
22:28 < KoalaBR> on NV43 the parameter following the 1478 is always a bitmap defining which planes of the 6 available are enabled / disabled
22:28 < KoalaBR> Could be, but there's more
22:28 < marcheu> or maybe that's quadro-only
22:28 < marcheu> what ?
22:28 < KoalaBR> The parameter for the clip plane are loaded up differently
22:29 < KoalaBR> First the way NV43 works:
22:29 -!- Unbeliever [n=hazel@212.145.81.31] has joined #nouveau
22:29 < KoalaBR> NV30_TCL_PRIMITIVE_3D_VP_UPLOAD_CONST         = 0x0000002c
22:30 < KoalaBR> NV30_TCL_PRIMITIVE_3D      [0x1f00/4] = 0x3d23d70a
22:30 < KoalaBR> NV30_TCL_PRIMITIVE_3D      [0x1f04/4] = 0x3d4ccccd
22:30 < KoalaBR> NV30_TCL_PRIMITIVE_3D      [0x1f08/4] = 0x3d75c28f 
22:30 < KoalaBR> NV30_TCL_PRIMITIVE_3D      [0x1f0c/4] = 0x3d8f5c29
22:31 < KoalaBR> the next plane then uses NV30_TCL_PRIMITIVE_3D_VP_UPLOAD_CONST = 0x0000002d followed by NV30_TCL_PRIMITIVE_3D_VP_UPLOAD_CONST = 0x0000002e  and so on
22:32 < marcheu> are the clip planes always constants starting 2c ?
22:32 < KoalaBR> all 6 planes (even if all 0x00000000 due to being unused) are uploaded up to 0x31
22:32 < KoalaBR> Finally 1478 -> 00000002 would enable the first clip plane
22:32 < KoalaBR> Yes
22:33 < marcheu> even when you have vertex progs running at the same tie ?
22:33 < KoalaBR> And always using  [0x1f00/4]
22:33 < marcheu> time*
22:33 < marcheu> yeah, 1f00 and friends are the constant uploading methods
22:33 < KoalaBR> Well not sure about that, that would exceed my OpenGL knowledge, just give me an test and I will have a look
22:34 < marcheu> just run a vertex program test before
22:34 < KoalaBR> Ok
22:34 < KoalaBR> Now regarding NV34
22:34 < marcheu> and remove the         regl.Disable(GL_VERTEX_PROGRAM_ARB);/regl.DeleteProgramsARB(1, &s); from it
22:34 < KoalaBR> Will do
22:35 < marcheu> so that its state remains
22:35 < KoalaBR> just after I have done my explanations
22:35 < KoalaBR> Not much I can say about the NV34 as I only had this one dump to look at
22:38 < KoalaBR> clip plane data is loaded always to NV30_TCL_PRIMITIVE_3D      [0x0e00/4] = ..... counting from  [0x0e00/4].[0x0e04/4], [0x0e08/4] .... to [0x0e3c/4]
22:39 < marcheu> there's one thing about nv30
22:39 < marcheu> it seems to work differently when vertex programs are enabled, but then shares a lot with nv40
22:39 < marcheu> and nv40 always works in the vertex program mode
22:40 < KoalaBR> followed by data from [0x0410/4] to [0x047c/4]
22:40 < marcheu> so maybe 0x1478 will actually get used if you enable vertex programs on nv30
22:41 < KoalaBR> Well I will enhance the test as suggested, will report back in a few minutes. But - what to do with 1478, It shows up on both but behaves differently. How do we configure something like that?
22:41 < marcheu> well, as I said, maybe it's not different
22:41 < marcheu> maybe a nv30 in vertex program mode will use 0x1478 for clip planes
22:42 < marcheu> but use the 0x0e?? stuff when not in vertex program mode
22:42 < KoalaBR> Is test_vtxprog() ok?
22:42 < marcheu> yeah, provided you don't disable its state afterwards like it does at the end
22:42 < KoalaBR> to add as a first test
22:42 < KoalaBR> Will change it
22:42 < marcheu> now we have to find a nv30 owner :)
22:44 < KoalaBR> I'm sorry that I have more questions than answer :/
22:48 < marcheu> ok, I'm pissed at both the via/sis & radeon/i915 memory managers
22:53 < KoalaBR> Strange things going on. Now only 2c gets real data loaded all others are zero
22:54 < KoalaBR> However, now it happens always, whether I did the vertex program test before or not
22:56 < KoalaBR> What are you hacking? Basics for the new driver?
22:59 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
23:03 < Myrizio_> marcheu: what is nv30? 5800 FX?
23:10 < marcheu> Myrizio_: all geforce FX (5x00) are some kind of nv30
23:10 < Myrizio_> ah, ok
23:10 < marcheu> KoalaBR: yeah, I'm trying to come up with a memory manager
23:11 < Myrizio_> if so, i will ask a friend of mine
23:11 < marcheu> Myrizio_: well, I can access my nv34 at work but only tomorrow
23:11 < Myrizio_> ah, ok :)
23:12 < Myrizio_> i have got 2 nv too, but i guess you do not need my dumps as they are very widespeed (GF2MX and 6800GT)
23:12 < KoalaBR> marcheu: I have restarted all my tests but I do not see any differences on NV43 between just test_clip_plane and a test with an added vertex test before clip_plane
23:12 < marcheu> KoalaBR: ok, that probably means that the 2c and friends are always the clip planes
23:13 < marcheu> KoalaBR: now the same test on nv30 would show wether there are 2 kind clip planes : with & without vertex program
23:13 < marcheu> I bet it'll be the case
23:14 < KoalaBR> Well...so what to do with 1478? and the 1f0x are missing too
23:15 < marcheu> KoalaBR: commit a second clip planes test, and let people upload dumps :)
23:16 < KoalaBR> So, you want me to write a new test? Or want me to upload my dump?
23:16 < KoalaBR> Not sure I understood correcty
23:16 < KoalaBR> Not sure I understood correctly
23:21 < marcheu> yeah, add a new test to tests.c which enables vertex progs and does clip planes
23:21 < marcheu> and also commit the nv40 clip plane info, just add comment like "nv40-only" next to the regs
23:26 < KoalaBR> Ok, will do that, but only tomorrow. To tired. BTW: I will have the more uptodate docs available for review on saturday
23:29 < KoalaBR> So good night:
23:29 -!- KoalaBR [n=KoalaBR@port-83-236-15-176.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
23:53 -!- pmdata [i=patrice@ANantes-154-1-41-159.w81-53.abo.wanadoo.fr] has joined #nouveau
23:59 -!- Myrizio_ [n=Myrizio@host62-98.pool80104.interbusiness.it] has quit ["Leaving"]
23:59 < pmdata> hello
--- Log closed Чтв Авг 10 00:00:10 2006
