--- Log opened Вск Авг 20 00:00:18 2006
00:29 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
00:29 -!- Topic for #nouveau: 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
00:29 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
00:29 [Users #nouveau]
00:29 [@ChanServ] [ cptn    ] [ gabrielg] [ lumag_offline] [ pmdata      ] [ swany] 
00:29 [ Aexoden ] [ dagb    ] [ jkolb   ] [ marcheu      ] [ qfire       ] [ tibbs] 
00:29 [ ag      ] [ darktama] [ K       ] [ maxtoo       ] [ Seg         ] 
00:29 [ airlied ] [ ddl     ] [ KoalaBR_] [ Myrizio      ] [ stillunknown] 
00:29 [ ajmitch ] [ EdB     ] [ lumag   ] [ nano-        ] [ stringfellow] 
00:29 -!- Irssi: #nouveau: Total of 27 nicks [1 ops, 0 halfops, 0 voices, 26 normal]
00:29 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
00:29 -!- Irssi: Join to #nouveau was synced in 3 secs
00:38 -!- Duke` [n=gnu@ANantes-251-1-133-118.w86-210.abo.wanadoo.fr] has joined #nouveau
00:39 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has joined #nouveau
00:57 -!- pmdata [i=patrice@ANantes-154-1-91-245.w86-210.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:17 -!- gabrielg [n=gabriel@c-a6df72d5.011-178-73746f44.cust.bredbandsbolaget.se] has quit ["zzz"]
02:00 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
02:00 -!- Topic for #nouveau: 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
02:00 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
02:00 [Users #nouveau]
02:00 [@ChanServ] [ ajmitch ] [ ddl          ] [ marcheu  ] [ predatorfreak] [ stringfellow] 
02:00 [ Aexoden ] [ cptn    ] [ jkolb        ] [ maxtoo   ] [ qfire        ] [ swany       ] 
02:00 [ ag      ] [ dagb    ] [ K            ] [ Myrizio__] [ Seg          ] [ tibbs       ] 
02:00 [ airlied ] [ darktama] [ lumag_offline] [ nano-    ] [ stillunknown ] 
02:00 -!- Irssi: #nouveau: Total of 23 nicks [1 ops, 0 halfops, 0 voices, 22 normal]
02:00 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
02:00 -!- Irssi: Join to #nouveau was synced in 1 secs
02:02 -!- swany_ [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
02:11 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Read error: 60 (Operation timed out)]
02:19 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
02:41 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
02:41 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:50 -!- jkolb [n=jkolb@209-6-112-224.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has quit ["Client exiting"]
03:01 -!- swany_ [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
03:04 -!- Myrizio__ [n=Myrizio@host132-98.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
03:07 -!- Myrizio [n=Myrizio@host132-98.pool80104.interbusiness.it] has joined #nouveau
03:30 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
03:59 -!- K [i=hazel@tor/session/external/x-d7fc4db7a5d75efb] has quit [Remote closed the connection]
04:20 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has joined #nouveau
04:49 -!- Seg [n=seg@fedora/Seg] has quit [Read error: 113 (No route to host)]
05:22 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
06:12 -!- Myrizio [n=Myrizio@host132-98.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
06:43 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has joined #nouveau
06:54 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has joined #nouveau
07:00 -!- Netsplit niven.freenode.net <-> irc.freenode.net quits: darktama
07:02 -!- Netsplit over, joins: darktama
09:00 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
09:38 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
09:41 < darktama> KoalaBR: I've been playing around with 0x1ff0/0x1ff4.. it doesn't behave how I was expecting it to :(
09:43 < darktama> the only thing I know for sure is that they have to be set in a certain way to get the correct results (dependant on what regs the vtx/fragprog accesses)
10:11 < darktama> umm, btw.. the test_clip_plane_after_vertex() test.. what is that supposed to achieve?  user-defined clip planes are ignored when a vtxprog is active..
10:46 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
10:46 -!- Topic for #nouveau: 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
10:46 -!- Topic set by sturmflut [] [Sun Aug 13 17:02:24 2006]
10:46 [Users #nouveau]
10:46 [@ChanServ] [ airlied] [ dagb    ] [ etzel        ] [ nano-        ] [ stillunknown] 
10:46 [ Aexoden ] [ ajmitch] [ darktama] [ lumag_offline] [ predatorfreak] [ swany       ] 
10:46 [ ag      ] [ cptn   ] [ ddl     ] [ marcheu      ] [ qfire        ] [ tibbs       ] 
10:46 -!- Irssi: #nouveau: Total of 18 nicks [1 ops, 0 halfops, 0 voices, 17 normal]
10:46 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
10:46 -!- Irssi: Join to #nouveau was synced in 1 secs
11:15 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit [Read error: 110 (Connection timed out)]
11:30 -!- EdB [n=EdB@ARennes-251-1-57-57.w81-53.abo.wanadoo.fr] has joined #nouveau
11:33 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
11:38 -!- KoalaBR [n=KoalaBR@port-83-236-12-196.dynamic.qsc.de] has joined #nouveau
11:39 < KoalaBR> darktama: Hi
11:44 < KoalaBR> the test_clip_plane_after_vertex() is for the NV30. They behave differently in test_clip_plane() and test_cp_after_vertext(). Only in case 2 they issue the same commands as a NV40 would always do, so for our cards, test_cp_after_vertex and test_cp do exactly the same (
11:44 < KoalaBR> regarding the commands for the clip planes). The NV30 does not.
11:44 < darktama> yes, but the clip planes will have no effect with a vertex program enabled
11:45 < KoalaBR> Ah ok
11:46 < KoalaBR> Well, I tried to make sense out of those clip planes for the NV30 and couldn't. Marcheu suggested that I coud try that. And my OpenGL knowledge is to small to know that the cp doen't work in that case
11:47 < KoalaBR> could
11:48 < KoalaBR> But back to the 1ff0/ 1ff4 case...
11:50 < KoalaBR> You are right in sofar that in all the tests I did, there wasn't exactly one OpenGL function which lead to the manipulation of that registers. Normally there would be a sequence of at least 2 or 3 OpenGL commands which would lead to that
11:51 < darktama> afaict, 0x1ff0 is set according to what ATTRIB regs are valid in a vertex program.. and 0x1ff4 is set depending on the RESULT regs a vertex program writes
11:54 < KoalaBR> Hm, clip planes do write results into registers? I naively thought, that they "simply" discard some parts of the generated picture...
11:54 -!- gabrielg [n=gabriel@c-a6df72d5.011-178-73746f44.cust.bredbandsbolaget.se] has joined #nouveau
11:54 < gabrielg> morning
11:54 < darktama> yes, I was a bit shocked to see that aswell
11:54 < KoalaBR> Hi
11:54  * gabrielg updated tests/c51
11:54 < gabrielg> fyi
11:55 < darktama> the DP4 insns that write the clip regs access the consts that the clip planes are written to
11:55 < darktama> KoalaBR: this is how I see 0x1ff0/0x1ff4: http://sh.nu/p/2807
11:57 -!- swany_ [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
11:58 < KoalaBR> COLx is color buffer?
11:58 < KoalaBR> Or it's attribute?
11:58 < darktama> color.primary and color.secondary
11:58 < darktama> attribute
11:58 < KoalaBR> Ok
11:58 < KoalaBR> And POS?
11:58 < darktama> vertex.position
11:59 < KoalaBR> So, some more tests like test_nv_texture_env_combine4?
12:00 < KoalaBR> Or a completely new one?
12:03 < darktama> I just wrote a vtxprog that reads attrib.{position,color} but writes {position,texcoord[0]}.. and I see
12:03 < darktama> 5e2   0x00000000   0x00000009            NV30_TCL_PRIMITIVE_3D      [0x1ff0/4] = 0x00000009 | UNKNOWN = 00000009
12:03 < KoalaBR> gabrielg: If you see marcheu later today, please tell him this once again - just to be sure. Thanks for your help :)
12:03 < darktama> 5e3   0x00000000   0x00004000            NV30_TCL_PRIMITIVE_3D      [0x1ff4/4] = 0x00004000 | UNKNOWN = 00004000
12:03 < darktama> so it looks like I'm right about 0x1ff4
12:03 < darktama> possible 0x1ff0 also
12:03 < darktama> possibly*
12:03 < KoalaBR> Well, I don't object
12:04 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
12:04 < gabrielg> KoalaBR: sure :)
12:04 < KoalaBR> Let me run this test too, just for verification
12:04 < darktama> yup, and for "MOV pos, pos; MOV tc0, tc0;" I see
12:04 < darktama> 5e2   0x00000000   0x00000101            NV30_TCL_PRIMITIVE_3D      [0x1ff0/4] = 0x00000101 | UNKNOWN = 00000101
12:04 < darktama> 5e3   0x00000000   0x00004000            NV30_TCL_PRIMITIVE_3D      [0x1ff4/4] = 0x00004000 | UNKNOWN = 00004000
12:05 < KoalaBR> Good, let's mark this as "solved" :)
12:06 < Lumag> hi all
12:06 < KoalaBR> But perhaps I should really try your new test(s) too, just to be sure
12:06 < KoalaBR> Hi
12:06 < darktama> not quite, we know how it works in the NV40 case.. but how about NV30 in non-shader mode?
12:06 < darktama> hey Lumag
12:06 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Read error: 60 (Operation timed out)]
12:06 < gabrielg> Lumag: hey
12:07 < darktama> oh, I made a mistake in the sh.nu paste.. texcoord bits start at 14, not 12
12:08 < KoalaBR> Well, don't worry. My first suggestion was full of errors because I was tired when I wrote it down and decoded hexvalues into nonsense 
12:08 < KoalaBR> Happens
12:09 < KoalaBR> gabrielg: Your card is identified as what type (NV30, NV40)?
12:10 < darktama> hmm, I don't see 0x1ff[04] used in the NV30 dumps I got when working on vertex programs
12:11 < KoalaBR> Well, I have to fetch those dumps before i can grep
12:12 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
12:13 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
12:15 < gabrielg> KoalaBR: NV40
12:16 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
12:16 < darktama> Lumag: looked at ctx switching any more?
12:17 < Lumag> just now :)
12:17 < darktama> ahh, nice :)
12:17 < KoalaBR> gabrielg: Ok, currently looking for NV30 :)
12:18 < darktama> any progress?
12:18 < KoalaBR> darktama: Haven't seen one 1ff0/1ff4 in the NV34 dumps
12:18 < KoalaBR> Anyone here with a NV30 card?
12:18 < darktama> no, me neither.. guess it's NV40-only
12:19 < KoalaBR> Yes, I think too
12:19 < Lumag> nearly nothing.
12:19 < Lumag> and on your side?
12:19 < darktama> I've managed to lock the card a couple of times, but that's it
12:20 < Lumag> yes, me too...
12:21 < KoalaBR> darktama: Shall I add 1ff0 / 1ff4 as NV40 only commands?
12:21 < darktama> yup, we may aswell
12:22 < darktama> I'm thinking NV30_TCL_PRMITIVE_3D_VP_IN_REG and NV30_TCL_PRIMITIVE_3D_VP_OUT_REG ?
12:22 < KoalaBR> Ok, will do and add a small text to doc/ too
12:22 < KoalaBR> Fine
12:23 < KoalaBR> Oh. not NV40_...?
12:23 < darktama> nah, it's still the NV30 object.. we can mark the individual command as NV40-only anyway
12:24 < KoalaBR> Ok, will do
12:25 < darktama> Lumag: how are you doing the switch?
12:29 < Lumag> I was experimenting with interrupts generation.
12:29 < darktama> hmm, you may need to call irq_postinstall from the PFIFO_REINIT ioctl aswell.. NVLoadStateExt() clobbers IRQ enables somehow
12:37 -!- Duke` [n=gnu@ANantes-251-1-133-118.w86-210.abo.wanadoo.fr] has joined #nouveau
12:46 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
12:57 -!- johane [n=johan@84-217-5-94.tn.glocalnet.net] has joined #nouveau
13:14 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has quit ["leaving"]
13:17 < darktama> KoalaBR: I think it'd be safe to extend the texcoord bits right up to texcoord[7]
13:18 < KoalaBR> darktama: Ok
13:19 < KoalaBR> For both 1ff0 and 1ff4 of course, I think?
13:19 < darktama> yup
13:19 < darktama> I just confirmed texcoord[7] is in the expected places, so I guess 2-6 are also
13:20 < KoalaBR> Ok. Do you need anything else tested? My todo list is empty :)
13:20 < darktama> mine isn't :)
13:20 < darktama> feel free to work on any of it!
13:24 < KoalaBR> Hm, I will look for some unknown commands and try to find out what they do, then
13:29 < KoalaBR> darktama: What about the textures? You said you stopped working on that? Any hints / suggestions on where / how to start there?
13:30 < darktama> well, the info we have works (I've tested it).. but we still need to find out how the textures are layed out in vram (ie. cube faces), and how the different texture formats look in vram
13:33 -!- maxtoo_ [n=maxtoo@berryx.homedns.org] has joined #nouveau
13:33 -!- maxtoo_ [n=maxtoo@berryx.homedns.org] has quit [Read error: 54 (Connection reset by peer)]
13:33 < KoalaBR> So first thing we need to find is the texture in mapped ram?
13:33 < darktama> yes, that *should* be easy.. the FB address is in TX_OFFSET
13:34 < KoalaBR> darktama: BTW Good shot at    NV30_TCL_PRIMITIVE_3D_VP_OUT_REG = primary color = TRUE | secondary color = TRUE | clip plane 0 = TRUE | clip plane 1 = TRUE | clip plane 2 = TRUE | clip plane 3 = TRUE | clip plane 4 = TRUE | clip plane 5 = TRUE | texture coords 0 = TRUE | texture coords 1 = TRUE | texture coords 2 = TRUE | texture coords 3 = TRUE | texture coords 4 = TRUE | texture coords 5 = TRUE | texture coords 6 = TRUE | texture coor
13:34 < KoalaBR> is during init and reduces quite a bunch of UNKNOWN bits :)
13:35 < KoalaBR> Anything else regarding textures?
13:35 < darktama> hmm, not that I can recall at the moment
13:37 -!- zoeloelip [n=bart@d54C0400B.access.telenet.be] has joined #nouveau
13:38 < KoalaBR> Ok, will start testing and poking later today. 
13:43 -!- scandium [n=scandium@pD9EE9DF5.dip0.t-ipconnect.de] has joined #nouveau
13:44 -!- swany__ [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
13:44 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
13:50 < marcheu> hello
13:50 < darktama> hey marcheu
13:50 < marcheu> so, I was sleeping
13:51 < marcheu> and it came to me that 1ff4 enables vertex value interpolator
13:51 < darktama> I thought it was an interpolator, but if you don't write it you just get {0.0, 0.0, 0.0, 0.0} and not a constant color as I'd expect without the value being interpolated
13:52 < marcheu> ah, so much for that idea then
13:53 < gabrielg> marcheu: morning
13:53 < gabrielg> marcheu: fyi, i updated tests/c51
13:53 < Duke`> you dream about renouveau? :o)
13:53 < gabrielg> that's dedication :)
13:53 < marcheu> Duke`: sometimes I fix bugs in my sleep, yeah
13:54 < Duke`> your brain is connected to cvs? :P
13:54 < marcheu> yeah, directly
13:55 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
13:56 < KoalaBR> Bye, will be back either later today or on tuesday evening. Will read logs though, so if you need something, just post
13:56 < Duke`> bye
13:56 < darktama> cya
13:56 -!- KoalaBR [n=KoalaBR@port-83-236-12-196.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
13:57 < scandium> hello. freedesktop.org wiki for nouveau doesnt work atm. because of some python error, so I have to bug here :) does anything work yet? I thought about replacing my 7800GT with an x850xt (friend of mine sells cheap). this all still in the beginnings?
13:58 < darktama> nope, nothing works yet :)
13:59 < scandium> ok. from what I read on dri-devel etc. the r300/r400 cards seem to work more or less well meanwhile and I really dont want to use a proprietary driver any longer but without fully losing 3d capability (some small games etc.). sounds like I'll get the ati card then...at least for now... :)
13:59 < Duke`> system freezing works well :P
13:59 < darktama> yeah, the r300 driver should work for most things
14:00 -!- swany_ [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Read error: 110 (Connection timed out)]
14:02 < darktama> marcheu: hmm, does drmAgpAcquire() work for you?  it's failing here for some reason..
14:02 < darktama> I was wondering why UTS/DFS weren't being hit
14:03 < marcheu> hmm, I can't get that far yet, because my libdri.so still crashes on startup
14:03 < darktama> ouch :S
14:03 < darktama> any idea why yet?
14:03 < marcheu> no, I installed FC5 to see if it was distro-related
14:05 < marcheu> so, you have the message about no AGP transfers ?
14:05 < darktama> yup, it used to work
14:06 < darktama> I was about to start working on a WaitForNotifier() that doesn't poll for completion
14:08 -!- pmdata [i=patrice@ANantes-154-1-74-92.w86-199.abo.wanadoo.fr] has joined #nouveau
14:08 < pmdata> hello
14:09 < marcheu> hey pmdata 
14:09 < marcheu> darktama: that's supposed to be done at the drm level...
14:09 < darktama> yes, but the UTS/DTS hooks are the only thing we have that use the notifiers
14:09 < marcheu> darktama: DRIVER_USE_AGP is enough to make it work usually
14:10 < marcheu> no, I'm talking about acquiring AGP
14:10 < Lumag> hi, pmdata
14:12 < Lumag> pmdata: are you sure about NV10_VIDEO_DISPLAY_SIZE ? I'm getting really weird values here.
14:12  * Duke` is reading a big troll on the OGP mailing list moaning that linux sucks, linux video drivers sucks, and that we should provide a stable API for closed source video drivers...
14:14 < Lumag> another note. IIUC, beef03* objects are used for notifiers.
14:14 < darktama> yup, that seems to be the case
14:15 < pmdata> lumag> width and height should be ok, don't know exactly about x,y
14:15 < pmdata> and I have a problem with your matrix define
14:15 < pmdata> INVERSE_MODELVIEWn_MATRIX is a 3x4 one, not 4x4
14:16 < Lumag> uhm. Feel free to correct it.
14:16 < Lumag> during test_startup I get: NV10_VIDEO_DISPLAY_SIZE = height = 767 | width = 765
14:16 < Lumag> that's for 512x512 window.
14:17 < Lumag> and for beef4902 I got: NV10_VIDEO_DISPLAY_SIZE = height = 65535 | width = 65533
14:17 < darktama> marcheu: so the ddx shouldn't be aquiring AGP then?
14:18 < darktama> acquiring*
14:18 < marcheu> yes it should
14:19 < marcheu> but that plus the DRIVER_USE_AGP flag should make it work
14:19 < marcheu> do you get any dmesg ?
14:19 < darktama> nothing interesting, I see agpgart messages.. but that's about it
14:20 < marcheu> ok, I'll checkout everything here and try to get it to work
14:21 < darktama> actually, the agpgart messages are from when nvidia's driver did it's init.. nothing from ours
14:21 < pmdata> lumag> I did not bother checking it better
14:21 < pmdata> I will add a M12 define then
14:22 < Lumag> :)))
14:23 < darktama> marcheu: the drm also acquires AGP.. won't the ddx get -EBUSY if it's already acquired?
14:25 < pmdata> lumag, hum, there is room for 16 values, so it's ok to keep it this way, even if only 
14:25 < pmdata> 3x4 is used
14:25 < pmdata> strange that renouveau lock up for me now in some ext test
14:25 < marcheu> darktama: hmm, right, that AGP area should be allocated instead
14:26 < marcheu> so it's time to make use of that memory manager now :)
14:26 < darktama> ok :)  do you want to do it?
14:26  * marcheu says it'll work fine and runs away
14:27 < marcheu> I can, I just have to setup that FC5 first
14:27 < darktama> ok.  I might make an attempt also, to get a feel for the mm
14:28 < marcheu> well, it should just be a drmcommandwriteread
14:28 < pmdata> hum I disabled all non extension tests, and now it runs extension tests ok
14:29 < marcheu> darktama: btw can you make sense out of pci resource #2 ?
14:29 < pmdata> lumag> which test triggers video_display_size?
14:30 < Lumag> test_startup 
14:30 < darktama> marcheu: the one that's reg_aperture+0x01000000?
14:30 -!- scandium [n=scandium@pD9EE9DF5.dip0.t-ipconnect.de] has quit ["using sirc version 2.211+KSIRC/1.3.12"]
14:30 < marcheu> yes
14:30 < pmdata> well, only setup once
14:30 < darktama> nope, I have nfi what it's for :)
14:31 < marcheu> I was thinking it was some regs for something else, maybe things like external encoders
14:32 < Lumag> strange. I setup for two objects (beef4901 and beef4902) and I posted results here.
14:33 < darktama> I was thinking it might be a workaround for some windows braindamage, like how radeons show up as two PCI devices (for each head)
14:33 < marcheu> hmm, what kind of braindamage ?
14:35 < darktama> I recall something about radeons having a second PCIID because of some windows flaw to do with dual-head.. I don't know any details though.. probably talking crap actually :)
14:35 < marcheu> yes, on radeon that's known
14:35 < marcheu> but what would it be on nvidia ?
14:36 < pmdata> lumag> I marked it as video_display_size because of this: (testing w,h.txt in fullscreen):
14:36 < pmdata> 100-100.txt:3c   0x02ff02fd   0x00ae00ac                         NV10_VIDEO_DISPLAY_SIZE = height = 174 | width = 172
14:36 < pmdata> 200-200.txt:3c   0x02ff02fd   0x00c700c5                         NV10_VIDEO_DISPLAY_SIZE = height = 199 | width = 197
14:36 < pmdata> 300-300.txt:3c   0x02ff02fd   0x012b0129                         NV10_VIDEO_DISPLAY_SIZE = height = 299 | width = 297
14:36 < pmdata> 512-512.txt:3c   0x02ff02fd   0x01ff01fd                         NV10_VIDEO_DISPLAY_SIZE = height = 511 | width = 509
14:36 < pmdata> oops, cut?
14:36 < pmdata> 100-100.txt:3c   0x02ff02fd   0x00ae00ac                         NV10_VIDEO_DISPLAY_SIZE = height = 174 | width = 172
14:36 < pmdata> 200-200.txt:3c   0x02ff02fd   0x00c700c5                         NV10_VIDEO_DISPLAY_SIZE = height = 199 | width = 197
14:36 < pmdata> 300-300.txt:3c   0x02ff02fd   0x012b0129                         NV10_VIDEO_DISPLAY_SIZE = height = 299 | width = 297
14:36 < pmdata> 512-512.txt:3c   0x02ff02fd   0x01ff01fd                         NV10_VIDEO_DISPLAY_SIZE = height = 511 | width = 509
14:36 < pmdata> should be ok
14:37 < Lumag> strange
14:37 < pmdata> height-1, width-3
14:37 < darktama> marcheu: a mirror of the regs resource so that two instances of the driver can grab the regs?
14:37 < darktama> I don't know really :)
14:39 < Lumag> then for me it will be 768x768. makes a bit of sense.
14:44 < darktama> marcheu: so, what about the other drmAgp calls the ddx makes (enable/alloc/bind)?
14:44 < Lumag> it doesn't depend on window size. let's keep it as is, but it's really strange.
14:47 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has joined #nouveau
14:47 < cptn> hey
14:48 < marcheu> darktama: they're needed in the drm as well...
14:48 < marcheu> darktama: cut & paste some from mga_dma.c
14:48 < darktama> yup, I figured as much :)
14:49 < marcheu> but I really really prefer that this be done in the drm
14:49 < marcheu> btw I'm installing gcc right nopw, so not quite ready for action :)
14:50 < darktama> yup, why don't the other drivers do this in the drm?  only mga does from what I can tell
14:50 < cptn> pmdata: http://jw.tks6.net/files/nouveau/nvs280/
14:50 < marcheu> mga has a lot of nice feats like that
14:50 < marcheu> other drivers just carrtheir heritage like that
14:50 < darktama> marcheu: lucky you're not using gentoo.. gcc takes quite a while to compile :D
14:51 < darktama> oh, except.. if you're compiling gcc then you already have gcc installed.. nvm :S
14:51 < marcheu> yeah, I tried gentoo at one point, but don't like having the computer on when I sleep... so it was a no-go for me :)
14:51 < darktama> hehe, both of my gentoo machines are always-on.. the noise is soothing.. somehow
14:53 < stillunknown> a little "woosh" sound can be nice
14:53 < stillunknown> but bearing noise can be annoying
14:53 -!- swany__ is now known as swany
14:54 < swany> hmm... the wiki gives me a syntax error
14:54 < Lumag> I wonder what's the point of pinging some objects while having size=0.
14:55 < marcheu> swany: I think it gives it to everyone
15:00 < pmdata> cptn> strange that some tests are empty
15:01 < cptn> pmdata: mmmh, seems to be an upload problem
15:02 < pmdata> did you run each test separately, or all at once?
15:02 < cptn> all at once
15:02 < cptn> like you told me yesterday
15:02 < cptn> :-)
15:03 < marcheu> hah
15:03 < marcheu> quadro support is a hack
15:03 < pmdata> ok, your tar.gz seems to lack some stuff, I got some corrupted file
15:03 < cptn> yeah, it looks like I hit the disk quota
15:03 < cptn> just a second
15:04 < marcheu> hehe
15:04 < marcheu> NVS doesn't have a bigger FIFO, like the other quadros
15:04 < pmdata> then just put the tar.gz with all the tests, I will put them on nouveau.sf.net
15:05 < marcheu> so, it's not using the hackish code anyway
15:05 < pmdata> cptn> did you enabled the test_startup? i don't see it
15:05 < cptn> ah, no, sorry
15:06 < pmdata> marcheu> I have a big problem with the nouveau project
15:06 < marcheu> pmdata: ?
15:07 < pmdata> I mostly stopped working on my other software projects :)
15:07 < marcheu> so did I
15:08 < stillunknown> also some of you are not sleeping enough
15:08 < stillunknown> :-)
15:08  * darktama hides
15:09  * marcheu hides behind darktama 
15:10 < stillunknown> just be honest, how many hours ago did you sleep?
15:10 < darktama> well, I slept for about 12 hours last night actually
15:10 < darktama> but only because I skipped sleep completely the night before :S
15:11 < stillunknown> how do you except to keep doing that, we do need people to continue development and not go crazy or something :-)
15:11 < cptn> pmdata: okay, new results @ http://jw.tks6.net/files/nouveau/nvs280/nvs280.tar.gz
15:11 < stillunknown> but who am i to say anything about that
15:11 < cptn> inlcuding test_startup, and no empty ones anymore
15:12 < darktama> stillunknown: I'm already crazy :)
15:12  * darktama twitches
15:13 < darktama> marcheu: we need drm_addmap for the alloced areas also don't we?
15:14 < marcheu> darktama: the NOUVEAU_MEM_MAPPED flag is supposed to do that
15:15 < marcheu> I mean, if it works
15:15 < pmdata> hum, I still get corrupted file for this tar.gz, could you try bz2?
15:15 < darktama> ah, it helps if I update drm so I have the MEM_MAPPED flag :)
15:15 < pmdata> oops, sorry, I was depacking old file, it's ok
15:16 < pmdata> this is a real quadro, not softquadroed one?
15:16 < cptn> it's a real one
15:16 < darktama> :q
15:17 < darktama> oops
15:17 < cptn> http://www.pny.com/products/quadro/nvs/280Nvsagp.asp
15:17 < marcheu> I think I saw a real quadro once, but some say quadros are just a legend
15:19 < pmdata> marcheu> could you chmod the nv18gl dir in tests on sf, so I can update?
15:20 < marcheu> I don't own it
15:20 < marcheu> so, no
15:21 < pmdata> so I must create a new dir?
15:21 < marcheu> yeah
15:22 < marcheu> maybe nv18ngl
15:22 < marcheu> so we could have nv18sgl, nv18xgl and nv18ngl for softquadro, quadro xgl and quadro nvs
15:22 -!- Myrizio [n=Myrizio@host24-98.pool80104.interbusiness.it] has joined #nouveau
15:23 < marcheu> or si 18a already a nvs
15:23 < marcheu> ah yes it's one too
15:30 < pmdata> nv18gl1 added
15:31 < pmdata> I chgrped it to group 'nouveau'
15:31 -!- K [i=hazel@tor/session/external/x-bf761fa9ba40ee99] has joined #nouveau
15:44 -!- K [i=hazel@tor/session/external/x-bf761fa9ba40ee99] has quit [K-lined]
15:49 < darktama> marcheu: the drm_addmap fails
15:49 < darktama> Aug 20 21:42:58 araqiel [15023.755295] [drm:drm_ioctl] pid=17660, cmd=0xc0186444, nr=0x44, dev 0xe200, auth=1
15:49 < darktama> Aug 20 21:42:58 araqiel [15023.755300] [drm:drm_addmap_core] offset = 0xf0000000, size = 0x01000000, type = 3
15:50 < darktama> Aug 20 21:42:58 araqiel [15023.755303] [drm:drm_ioctl] ret = ffffffff
15:50 -!- Myrizio_ [n=Myrizio@host70-98.pool80104.interbusiness.it] has joined #nouveau
15:51 < marcheu> darktama: did you add the agp bind stuff ?
15:52 < darktama> http://sh.nu/p/2808
15:52 -!- Myrizio [n=Myrizio@host24-98.pool80104.interbusiness.it] has quit [Success]
15:55 < darktama> brb
15:56 < marcheu> yeah, addmap takes an offset in agp space
15:56 < marcheu> you have to subtract the agp base
15:57 -!- Myrizio_ is now known as Myrizio
15:58 < marcheu> bbl too
16:10 < pmdata> cptn> could you post a link to a glxinfo on your nv18gl?
16:16 < pmdata> anyone> does reading/writing in video mem requires a dma object? i.e. when reading from/writing to depth buffer?
16:16 < darktama> yes, it does
16:16 < pmdata> same question for lma depth buffer and color buffer of course (and maybe other buffers)
16:17 < darktama> I think that *any* memory access the card does needs a dma object which says what areas it's allowed to touch
16:17 < pmdata> then I think 0x180-0x1c0 in tcl are for these dma objects, 2 for each buffer (one for read, one for write)
16:18 < cptn> pmdata: http://sh.nu/p/2809
16:18 < darktama> 0x180 is usually a notifier
16:21 < pmdata> 0x18c is used for display lists, it leaves me 4 (and there are 2 extra for nv17 -> lma depth)
16:21 < pmdata> I just have to find which is depth/stencil, which is color
16:22 < pmdata> does DMA_IN_MEMORY can be used for writing?
16:36 < pmdata> does the dma page address in a object should match a buffer offset?
16:37 -!- johane [n=johan@84-217-5-94.tn.glocalnet.net] has quit ["Leaving"]
16:41 < darktama> the dma page address in an object is added to any offset vals that appear in the fifo
16:43 -!- Duke` [n=gnu@ANantes-251-1-133-118.w86-210.abo.wanadoo.fr] has quit [Read error: 60 (Operation timed out)]
16:44 < pmdata> I think the 4 dma objects are color, depth, tx0, tx1
16:45 < pmdata> I will check what happens on texture upload
16:45 < pmdata> and usage
16:51 < pmdata> hum, the DMA_[IN|TO]_MEM was confusing me
16:52 < pmdata> I see the dma_target is either pci (vid ram->ram I think), nv mem (gpu<->vid ram), or agp (ram->vid ram)
16:52 < pmdata> so these 0x180 objects are used for each target
16:52 -!- Duke` [n=gnu@ANantes-251-1-140-109.w86-210.abo.wanadoo.fr] has joined #nouveau
16:53 < pmdata> or it just means that the gpu supports n simultaneous dma transfers, and we can use each one for a different usage
16:53 < pmdata> so not much point in saying that 0x188 is to transfer object x data
16:54 < darktama> in MEMORY_TO_MEMORY_FORMAT, 0x180 is a notifier object which says what piece of RAM to write the status of a DMA transfer into
16:55 < pmdata> it does not mean 0x180 can only be used for this usage
16:56 < darktama> true, but from looking at nv10reg.h it seems to hold true for most objects
16:59 < marcheu> darktama: does addmap work ?
16:59 < darktama> yup
16:59 < marcheu> cool
17:00 < marcheu> and does the memory allocator work ?
17:01 < darktama> it seems to, at least, it gives me a 16MB chunk of AGP to use :)
17:01 < marcheu> double cool
17:01 < darktama> indeed
17:03 < darktama> hm, the card doesn't like me setting MEMFORMAT_NOTIFY to LE_AWAKEN (0x01)..
17:04 < darktama> that's the bit that says to send an interrupt on completion
17:08 < marcheu> LE_AWAKEN ? where does that come from ? 
17:08 < marcheu> (I don't have the docs handy right now)
17:09 < marcheu> ah, nv_dma.c
17:09 < marcheu> I'm not sure that this information is reliable, since it wasn't tested as far as I know
17:12 < darktama> rivatv uses it
17:12 < Lumag> darkatama: what happens if you set MEMFORMAT_NOTIFY?
17:13 < darktama> the FIFO stalls, but not on that command.. the log I have shows it stalling on RECT_FORMAT...
17:15 < Lumag> do you get an interrupt?
17:15 < darktama> apparently not.. though I've had it giving me interrupts ages ago
17:16 < Lumag> did you set DMA_NOTIFY object?
17:16 < darktama> yes, it's setup when the object is created
17:16 < darktama> oh, wait.. 
17:17 < darktama> I wonder if the allocator allocated the chunk of AGP in the same place the notifier is.. 
17:17 < marcheu> heh
17:17 < darktama> I forgot that was in AGP
17:17 < pmdata> cptn> can you checkout renouveau and post a dump for test_startup, please?
17:17 < marcheu> allocate the notifier :)
17:17 < darktama> yup, doing that now :)
17:18 < Lumag> Also do you set the notifier in the RAMIN?
17:18 < darktama> the drm should do it, yes
17:18 < marcheu> darktama: btw if you do that, can you please put a #ifdef __powerpc__ NOUVEAU_MEM_FB #else NOUVEAU_MEM_AGP ?
17:18 < darktama> sure
17:19 < marcheu> some (most) ppc crash when notifiers are in agp
17:19 < cptn> pmdata: sure
17:20 < Lumag> darktama: are you sure, that target memory objects are correct in terms of page tables?
17:21 < marcheu> hmm what a waste a full page for a couple of notifier bytes...
17:21 < darktama> marcheu: we can handle that in the drm later :)
17:21 < marcheu> darktama: nope, all allocations are page aligned so that they can be mapped into the user processes
17:21 < darktama> ah
17:21 < marcheu> because it's not possible to map half pages :)
17:22 < darktama> Lumag: they should be, they're created the same way as DMA objects are
17:22 < cptn> pmdata: http://sh.nu/p/2810
17:23 < Lumag> marcheu: it's possible to use page + offset for notifiers.
17:23 < marcheu> Lumag: sure, but the memory manager still allocates page-aligned chunks
17:24 < marcheu> which might be a waste. or maybe not
17:24 < marcheu> but yeah, one page could be used for all the notifiers
17:25 < darktama> per-client, so other clients can't do dodgy stuff :)
17:25 < marcheu> darktama: well, the client allocates a page, and does handle placing notifiers in there as it wants
17:25 < Lumag> I'm still not sure, that page tables are setup correctly.
17:26 < Lumag> I'll try looking into it later.
17:28 < darktama> marcheu: so, where is a safe place to stick the notifier in the FB.. we can't allocate it yet
17:28 < marcheu> yeah... I suppose we can add a comment that this is broken for now :)
17:53 < darktama> marcheu: we also need to make the size passed to addmap be a multiple of the page size
17:53 < pmdata> hum http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=1 according to this page, nv17/18 has 'partial' vertex shader capabilities, whatever it means
17:54 < marcheu> well, that'd be cleaner, but it's not strictly needed, since alignment actually enforces that
17:54 < marcheu> but yeah, I'm all for it
17:54 < darktama> [22644.055621] [drm:drm_ioctl] pid=1311, cmd=0xc0186444, nr=0x44, dev 0xe200, auth=1
17:54 < darktama> [22644.055626] [drm:drm_addmap_core] offset = 0x01000000, size = 0x00000100, type = 3
17:54 < darktama> [22644.055630] [drm:drm_ioctl] ret = ffffffea
17:54 < darktama> it fails because of it now :)
17:55 < pmdata> hou, geforce pcx 4300 is nv19 ??
17:56 < marcheu> pmdata: pcx 4300 is a nv18 with a pci express bridge
17:56 < marcheu> darktama: hmm
17:57 < marcheu> darktama: so be it
17:58 < pmdata> aaah
17:58 < pmdata> I wonder why nvidia bothered making a pcie versoin of such a lowend chip
17:58 < marcheu> it's part of the "bastard" pci id card range
17:58 < pmdata> I also see that nv18/nv28 are agp8x versions of nv17/nv28
17:59 < pmdata>  nv17/nv25
17:59 < marcheu> all 10de:00fx chips are bastard ones
18:00 < pmdata> I still don't get how the nv10 tcl objects are used, they seem to point to the same object
18:00 < pmdata> tcl dma objects
18:00 < Lumag> maybe that's leftover from PCI?
18:01 < Lumag> or maybe it marks the possibility to have textures in system mem?
18:01 < pmdata> besides 0x180 (dma notify according to darktama), and 1 for display list...
18:02 < darktama> pmdata: most of them on NV40 point to 0xbeef0201 which is an object covering all of vram
18:02 < pmdata> I have 3 setup to same object for nvmem transfer, and 1 for agp transfer
18:02 < pmdata> yep, the three for beef0201
18:03 < Lumag> well. depth buffer, color buffer.
18:03 < pmdata> are they just different dma channels to read or write video ram?
18:03 < pmdata> test_tex show that the agp one is used for texture upload
18:03 < marcheu> maybe one does the swizzling needed for textures
18:04 < Lumag> IIRC, the texture is uploaded to vidmem, isn't it?
18:05 < Lumag> uploaded to AGP and then transferred to FB mem via scaled_image transfer?
18:05 < pmdata> it uses beef0202 (agp transfer in nv10 tcl) for NV10_SCALED_IMAGE_FROM_MEMORY
18:06 < pmdata> yep, seems to be agp -> vram -> render
18:06 < Lumag> the one thing that bugs me is that there are dma notifier & objects instances in RAMIN and then object handles in FIFO.
18:07 < Lumag> seems like information duplication.
18:07 < pmdata> hum, test_tex uses same texture for the 2 texture units, should rewrite it to use a different one
18:08 < pmdata> if the nv10_tcl has a dma object for agp transfer, does it means it can read texture from system ram (provided it is in a good format) ?
18:10 < marcheu> pmdata: what do you mean ?
18:10 < pmdata> if this is the case, maybe some unknown bits in texture unit tell which dma object to use to read texture from
18:11 < pmdata> marcheu> I just wonder if we can have agp texture -> gpu -> color buffer without having to store texture in vram
18:11 < marcheu> pmdata: yeah, all AGP chips can do that
18:12 < marcheu> well, all that aren't just a PCI device slapped on an AGP card...
18:13 < pmdata> then TX_FORMAT(n) should hold which dma object to read the texture from (or in some other TX related command)
18:13  * pmdata will add more tests for that
18:13 < pmdata> uploading many big textures?
18:13 < marcheu> yeah, or using the extensions
18:14 < marcheu> there's an extension whose name I don't remember right now which does that
18:18 < marcheu> ah
18:18 < marcheu> nv_pixel_data_range
18:19 < marcheu> actually, that one lets you allocate chunks of AGP but doesn't texture from it directly
18:20 < pmdata> hum, from what I see with test_arb_multitexture, it uploads all textures to vram, then render from it without using a dma object
18:21 < pmdata> or maybe using an already configured one?
18:22 < marcheu> yes, but when there's no more VRAM, or when the app requests it, you can end up with textures in AGP
18:23 < marcheu> I think glXAllocateMemoryNV with the right frequency parameters will place it in AGP
18:23 < marcheu> probably 1.0, 1.0, 0.0 will do to get AGP
18:24 < marcheu> but yeah, won't texture directly from it..
18:25 < marcheu> darktama: do you still have the old exa version of nv_exa.c ?
18:26 < marcheu> or am I in for some sed fighting ?
18:26 < darktama> for the old ABI?
18:26 < marcheu> yup
18:26 < darktama> cvs up -r 1.1 nv_exa.c
18:26 < marcheu> oh, it was in cvs ?
18:26 < marcheu> nice
18:26 < darktama> yup
18:52 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
19:09 -!- shenki [n=shenki@ppp225-88.lns2.adl4.internode.on.net] has joined #nouveau
19:10 -!- Myrizio [n=Myrizio@host70-98.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
19:11 < pmdata> http://nouveau.freedesktop.org/wiki/ syntax error?
19:14 < darktama> yeah, we're all getting it
19:26 < darktama> so marcheu, do you have a working libdri now?
19:27 -!- pmdata [i=patrice@ANantes-154-1-74-92.w86-199.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
19:28 < marcheu> no
19:29 < darktama> damn, still broken or just not that far with setting up FC5 yet?
19:29 < marcheu> heh, broken with mandrake and FC5
19:30 < marcheu> plus when you break Xorg in FC5 it's a headache anyway, because it's started on early boot
19:30 < darktama> :(
19:30 < zoeloelip> marcheu: just remove rhgb from the kernel commandline
19:30 < marcheu> darktama: what Xorg version do you have precisely ?
19:30 < marcheu> zoeloelip: oh thanks, sounts good
19:31 < marcheu> sound
19:31 < darktama> X Window System Version 7.1.1
19:31 < darktama> Release Date: 12 May 2006
19:31 < darktama> X Protocol Version 11, Revision 0, Release 7.1.1
19:31 < marcheu> yeah, I'd have to upgrade it to rawhide anyway
19:31 < marcheu> I'd rather fix my libdri issues than workaround
19:32 < marcheu> darktama: do you have load "dri" in xorg.conf ?
19:33 < darktama> nope
19:34 < darktama> it gets loaded anyway for some reason
19:35 -!- pmdata [i=patrice@ANantes-154-1-74-92.w86-199.abo.wanadoo.fr] has joined #nouveau
19:37 < marcheu> well, given that my issues are with it seemingly not correctly loaded, I was thinking that could solve it
19:37 < pmdata> marcheu> next time I reboot I will try your nvclock-quadro (before the nv kernel module is loaded this time)
19:40 < pmdata> hum, what is c51 in tests?
19:40 < marcheu> it's 6150, a nv44 integrated derivative
19:40 < marcheu> some kind of successor to the nforce
19:45 -!- shenki [n=shenki@ppp225-88.lns2.adl4.internode.on.net] has quit ["Leaving"]
19:46 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has quit ["leaving"]
19:47 < lumag_offline> marcheu: for my tests I installed a chroot with compiled-from-source Xorg 7.1 Maybe creating such simple chroot will soulve your problems?
19:50 < marcheu> yeah, maybe going back to 7.1 is a solution
19:50 < marcheu> it used to work with 7.1
19:50 < stillunknown> problems with 7.1.1?
19:51 < marcheu> mine is a git checkout... there can be problems at any time
19:51 < darktama> hmm, git bisect could help track down the issue
19:52 < darktama> if it occurred sometime after 7.1.1
19:54 < pmdata> ah, find some difference in unknown bits in register combiners on nv10
19:54 < pmdata> http://nouveau.sourceforge.net/tests/nv15/card_10de-0151_test_arb_multitexture.txt line 110fa
19:54 < pmdata> unknown is 0x28000000 instead of 0x18000000
19:56 < pmdata> it is also set in texture_env_comb4 test in some cases
20:01 -!- Netsplit over, joins: pmdata
20:09 < pmdata> it seems this is txn_combiner enable
20:17 -!- Myrizio [n=Myrizio@host192-102.pool80104.interbusiness.it] has joined #nouveau
20:18 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has joined #nouveau
20:25 < darktama> marcheu: I'm building xorg from git to see if I get the same problem
20:26 < marcheu> darktama: don't bother
20:26 < marcheu> do some real work instead :)
20:26 < marcheu> I'll upgrade that fedora to rawhide and see
20:26 < darktama> haha, I'll update anyway because I can't help myself :)  should be sleeping really
20:27 < darktama> but, I might find some food while I wait
20:50  * pmdata wonder if the remaining unknown bit in rc_out_rgb(1) is register_combiner_enable
21:01 < pmdata> I put it as is
21:02 < pmdata> we'll have to wait for the moment we can send commands ourselves to check this
21:02 < darktama> pmdata: use nvtest to check it
21:11 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
21:11 < pmdata> darktama> could you point me a url? I have one I got a while ago
21:12 < darktama> it's the same url as you had before
21:12 < pmdata> which is... ?
21:13 < darktama> oh sorry, I thought you meant you had the url :S
21:13 < darktama> one sec
21:13 < darktama> members.iinet.net.au/~darktama/nvtest.tar.bz2
21:14 < darktama> just kill off all the NV30/40 stuff, and it should work ok on other cards
21:17 < darktama> anyway, sleep time
21:22 < pmdata> I will retry softquadro now
21:23 -!- pmdata [i=patrice@ANantes-154-1-74-92.w86-199.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
21:40 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has joined #nouveau
21:59 -!- pmdata [i=patrice@ANantes-154-1-74-92.w86-199.abo.wanadoo.fr] has joined #nouveau
22:00 < pmdata> PEXTDEV[0] goes from 0x800054ff to 0x800074ff, but no change, still no quadro
22:04 < Duke`> I have the same problem
22:06 < pmdata> marcheu> could you check how this value change on yours next time?
22:06 -!- Myrizio [n=Myrizio@host192-102.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
22:06 < marcheu> the value change is ok
22:07 < marcheu> but for some reason, the pci id doesn't change on some cards. that's the case on the nv34
22:07 < pmdata> the device id in lspci does not change
22:07 < marcheu> yeah, that should change as soon as the EXTDEV is changed
22:07 < marcheu> you don't need to start X or anything for this
22:07 -!- K [i=hazel@85-57-135-226.gij1.adsl.uni2.es] has joined #nouveau
22:09 < pmdata> I did it on fresh reboot (recovery mode)
22:44 -!- EdB [n=EdB@ARennes-251-1-57-57.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
22:44 -!- EdB [n=EdB@ARennes-251-1-57-57.w81-53.abo.wanadoo.fr] has joined #nouveau
22:55 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
23:11 < lumag_offline> when in softquadro, lspci doesn't change for me. But the lspci -H 1 shows new pci id
23:11 < Duke`> 0000:01:00.0 VGA compatible controller: nVidia Corporation NV11GL [Quadro2 MXR/EX/Go] (rev a1)
23:11 < Duke`> o_O
23:15 < Duke`> but the GL renderer string still says "GeForce2 MX/AGP/3DNOW!"
23:20 < pmdata> lspci -H 1 \o/ 0000:01:00.0 VGA compatible controller: nVidia Corporation NV15GL [Quadro2 Pro](rev a4)
23:20 < pmdata> but lspci -n and glxinfo still says non quadro
23:21 < Duke`> yup ;_;
23:29 -!- EdB [n=EdB@ARennes-251-1-57-57.w81-53.abo.wanadoo.fr] has quit ["Konversation terminated!"]
23:38 -!- Myrizio [n=Myrizio@host182-98.pool80104.interbusiness.it] has joined #nouveau
23:44 -!- zvin [n=zvin@ram94-2-81-56-27-78.fbx.proxad.net] has joined #nouveau
23:44 < zvin> hi there
23:57 -!- zvin [n=zvin@ram94-2-81-56-27-78.fbx.proxad.net] has quit ["Leaving"]
--- Log closed Пнд Авг 21 00:00:18 2006
