--- Log opened Сбт Июн 10 01:28:48 2006
01:29 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
01:29 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards
01:29 -!- Topic set by marcheu [] [Wed Jun  7 23:50:47 2006]
01:29 [Users #nouveau]
01:29 [@ChanServ] [ Duke`        ] [ krejler      ] [ ohsix       ] 
01:29 [ ag      ] [ gajownik1away] [ Lumag        ] [ pmdata      ] 
01:29 [ darktama] [ jkolb        ] [ lumag_offline] [ stringfellow] 
01:29 [ ddl     ] [ katakombi    ] [ marcheu      ] [ svu         ] 
01:29 -!- Irssi: #nouveau: Total of 16 nicks [1 ops, 0 halfops, 0 voices, 15 normal]
01:29 -!- Channel #nouveau created Wed Apr 19 04:19:50 2006
01:29 -!- Irssi: Join to #nouveau was synced in 1 secs
01:29 < pmdata> then maybe it's in the unknown commands that set the opengl state
01:37 < pmdata> I made a diff between depth and depth|stencil, and did not found any difference, except depth is done in 8 passes
01:41 < pmdata> clearing depth should not clear stencil in all cases, I should check that, maybe the driver does not bother till something is drawn in stencil buffer?
01:43 < marcheu> hmm, that's possible but unlikely
01:43 < marcheu> although something like that might make a nice doom 3 optimization :)
01:46 < Lumag> I was experimenting with FIFO channels... It seems that 0 and 1 are used internally and after that each X server gets a spare channel.
01:47 < Lumag> BTW: does anybody know the number of FIFO channels in nv cards?
01:47 < marcheu> yes, and also each X app
01:47 < marcheu> s/X app/3D app/
01:47 < marcheu> 8 on NV03, I think 32 on NV10+
01:47 < marcheu> possibly 16 on NV04
01:47 < Lumag> marcheu: no. Two gl applications run on single server use the same channel
01:47 < marcheu> Lumag: not here. what card ?
01:48 < Lumag> nv06 (vanta)
01:48 < marcheu> Lumag: that means you see the other app's commands in the fifo, right ?
01:49 < Lumag> Hmm... Didn't thought about that. Have to check. I meant that I get the same channel number from decoding context.
01:49 < marcheu> that's possible, I never tried multiple apps on <nv10
01:50 < marcheu> but you just have to see if the physical addresses are the same or not
01:56 < Lumag> Checked. No the fifo's are at separate AGP places.
01:57 < marcheu> wrong decoding then ?
01:58 < Lumag> The register mappings also have different start addresses
01:58 < Lumag> dunno :)
01:58 < marcheu> yes, there are different fifo control registers for each fifo
01:58 < marcheu> so that each process can map it's own fifo & control registers
01:59 < marcheu> the nvidia driver doesn't map the whole register range by default
01:59 < Lumag> Yes. But objects are shared between processes on the single server
01:59 < marcheu> yes
02:00 < marcheu> but each fifo can bind different objects
02:02 < Lumag> Then fifo channel != object channel... Strange
02:03 < Lumag> Or it's not a channel in object hashing and contexts :(
02:05 < marcheu> no idea, I didn't look at object hashing too closely yet
02:05 < marcheu> now some docs use the word channel, where some others say subchannel
02:05 < marcheu> that might introduce confusion
02:05 < Lumag> well... From rivatv docs, there are channels and subchannels. :)
02:06 < darktama> from what I understood, there's multiple FIFOs (channels?), each of which has a number of subchannels that you can bind objects to
02:06 < Lumag> IIUC, different fifo's are channels, each fifo has 8 subchannels.
02:07 < Lumag> :)
02:07 < marcheu> I understand it like darktama too, but...
02:07 < marcheu> if you put aside the hash/object stuff and just think of object names
02:08 < marcheu> you have 8 (or more depending on the hardware) fifos which are at separate memory places
02:08 < marcheu> and each fifo can use 8 objects, which are bound using a fifo command
02:08 < darktama> the SET_CHANNEL command?
02:08 < marcheu> yup
02:09 < darktama> ah, good.  I wondered what that was
02:09 < Lumag> :)
02:09 -!- Myrizio [n=Myrizio@Linuz.sns.it] has joined #nouveau
02:09 < Lumag> marcheu: and?
02:09 < marcheu> darktama: and that command is fed an object name, basically. and that object name comes from the RAMIN stuff
02:09 < marcheu> Lumag: I think htat's about it, really
02:10 < darktama> it's used to lookup an entry in RAMHT isn't it, which then points to the actual object?
02:10 < marcheu> darktama: yup, that's the complex stuff from nv_dma.c
02:12 < darktama> soo.. to render simple tris, do we only need to find one object or is there other objects that need to be setup aswell
02:12 < marcheu> one object is enough, see the haiky driver
02:12 < Lumag> Not so complex. the name and a some index, that rivatv calls chid are used to lookup an object context from the RAMHT. the context determines if the object is valid, the type of the object and the address of instance memory location (think as constructor arguments).
02:12 < marcheu> although you might want to do clears with another object (2D)
02:13 < Lumag> marcheu: I don't think so. Every object is created as a child of some other one :(
02:13 < marcheu> Lumag: yup, that's something I don't quite understand, number have to follow somehow
02:16 < Lumag> marcheu: in your case is that chid (it's (context & 0x0f000000) >> 24) the same for objects on the same screen?
02:17 < marcheu> I didn't look at that
02:18 -!- Duke` [n=gnu@ANantes-251-1-83-53.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:20 < Lumag> could you please check that?
02:21 < marcheu> not really, I'm using the free driver right now
02:22 < marcheu> (for the few times I can get it to start without crashes, that is)
02:23 < Lumag> :)
02:23 < darktama> I think I might stay away from it for a couple of days, do some more work on fragment shaders instead :)
02:25 < marcheu> pmdata: level1/level2 = ?
02:26 < pmdata> well, in the color/depth/stencil buffer you define a level1 block, and in this one, you define a level2 block, which is to be cleared
02:26 < marcheu> hmm ?
02:26 < marcheu> is this hierarchical ?
02:27 < pmdata> maybe
02:27 < marcheu> hehe... so nvidia was using hierarchichal clears on nv15 already...
02:27 < pmdata> I really don't know, as glClear() always clear an entire framebuffer
02:28 < marcheu> the good thing with this is that it doesn't clear the depth/stencil buffers, but instead a hierachical representation of the zbuffer (like hyperz really)
02:28 < marcheu> we have to figure out precisely which cards work like that
02:28 < marcheu> it's a very nice speed boost usually
02:28 < pmdata> nv20+ seems to have hyperz
02:29 < marcheu> well nv17 has something similar too according to the docs
02:29 < marcheu> but hyperz actually contains hierarchical z clears
02:30 < marcheu> anyway that information is very nice to have
02:30 < marcheu> I'll see what happens on my nv11 & nv18
02:30 < marcheu> "ASAP" :)
02:31 -!- Myrizio [n=Myrizio@Linuz.sns.it] has quit [Remote closed the connection]
02:50 < pmdata> yeah, the LMA, as you wrote on the card features page
02:53 -!- jkolb [n=jkolb@130.57.22.69] has quit ["Leaving"]
03:05 -!- pmdata [n=patrice@ANantes-154-1-111-232.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
03:10 -!- ohsix [i=ohsix@bc111222.bendcable.com] has left #nouveau []
04:33 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
05:27 -!- kombrisn [n=kombrisn@p5080902B.dip0.t-ipconnect.de] has joined #nouveau
05:40 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
05:41 -!- katakombi [n=kombrisn@p50808E49.dip0.t-ipconnect.de] has quit [Connection timed out]
09:46 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
11:15 -!- pmdata [i=patrice@81.53.79.109] has joined #nouveau
11:16 -!- Duke` [n=gnu@ANantes-251-1-155-73.w86-203.abo.wanadoo.fr] has joined #nouveau
12:09 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
12:12 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
12:29 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
12:54 -!- pmdata [i=patrice@81.53.79.109] has quit [Remote closed the connection]
13:55 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has quit [Remote closed the connection]
14:00 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
14:37 -!- pedro_ [n=pedro@c906e04c.virtua.com.br] has joined #nouveau
14:38 -!- kombrisn is now known as katakombi
14:39 < katakombi> every time I log off freenode and relogin my nick name is not logged off. What to do about that?
14:39 < Duke`> freenode has a big timeout...
14:40 < marcheu> katakombi: register your nick : "/msg nickserv help" and then use the ghost functionality
14:40 < katakombi> yeah, it's registered already
14:40 < marcheu> then use the ghost functionality
14:40 < marcheu> maybe with /msg nickserv help ghost
14:42 < katakombi> thanks, that's exactly what I need
14:59 -!- katakombi [n=kombrisn@p5080902B.dip0.t-ipconnect.de] has quit [Remote closed the connection]
15:03 < marcheu> anyone here ? what value do you have for the 0x200 reg ?
15:03 < marcheu> (NV_PMC_ENABLE)
15:04 < darktama> that's the reg that powers up parts of the card?
15:04 < marcheu> yup
15:04 < marcheu> haiku writes 0x13111111
15:04 < darktama> PWRUPCTL: 0x17111113
15:04 < marcheu> I have 0x17111113
15:05 < marcheu> so, 2 unknown bits
15:05 < darktama> no, haiku knows them.. one sec
15:06 < darktama> oh, wait.. maybe it doesn't..
15:06 < darktama> sorry :)
15:07 < darktama> I was thinking about the bits that change from a coldboot -> after starting nvidia's driver..
15:07 < marcheu> according to the layout, that unknown 0x04000000 is crtc-related
15:08 < marcheu> I need values on more cards... maybe it's the dvi out
15:09  * marcheu feels a card swapping rampage coming
15:09 < darktama> hehe, have you got any dual-dvi cards at all btw?
15:09 < marcheu> nope
15:09 < marcheu> hmm, actually
15:09 < marcheu> we have one at the university
15:09 < marcheu> but I'm not root on that machine
15:10 < darktama> hmm, I should get myself one.. it could be useful in figuring out panel setup without the BIOS's help
15:10 < darktama> I'm fairly certain I know the reg that says a panel is connected already
15:10 < marcheu> I can do some tests on that card
15:11 < darktama> cool :)
15:11 -!- pmdata [i=patrice@ANantes-154-1-28-109.w81-53.abo.wanadoo.fr] has joined #nouveau
15:13 < marcheu> darktama: did you try playing with that reg btw ? it didn't work
15:13 < marcheu> ?
15:13 < darktama> which reg?
15:14 < marcheu> NV_PMC_ENABLE
15:14 < darktama> nope, not as yet
15:14 < marcheu> ok, I'll ad that to the mix
15:15 < marcheu> I got bios code to parse without crashes, but it resulted in the card reporting 0kb of ram and X bailing out
15:15 < marcheu> I think that's because you need to power up all the units after the bios parse
15:16 < darktama> mm, that's a possibility
15:17 < marcheu> it's also 0x17111113 on the dual dvi G70
15:18 < darktama> so perhaps not the dvi hardware then..
15:19 < marcheu> btw did you see haiku's unlock_card() ?
15:19 < darktama> yup
15:20 < marcheu> "enable access to secondary head" looks interesting
15:20 < darktama> that does the write to crtc indexed 0x44
15:20 < pmdata> hi all
15:21 < darktama> I modified NVSelectHeadRegisters to also do that in the ddx
15:21 < marcheu> hi pmdata
15:21 < marcheu> darktama: alright, I'm not sure how to put it
15:21 < marcheu> s/how/where
15:22 < darktama> also, when at a console, that reg contains 0x04.. I'm really not sure what that indicates, it's 0x00 for crtc0 0x03 crtc1 usually
15:23 < darktama> if you leave it as 0x00 or 0x03 when you VT switch, the other head doesn't update properly (ie, no cursor, scrolling acts oddly)
15:23 < marcheu> which reg ?
15:24 < darktama> crtc indexed 0x44
15:24 < marcheu> btw did you see the haiku warning about that reg and some gf2mx ?
15:24 < marcheu> it says to write it twice
15:24 < marcheu> please think about it when you write code :)
15:24 < darktama> yes, I noted that.. it's odd that the xorg driver doesn't do that
15:25 < marcheu> the xorg driver doesn't do multihead
15:25 < marcheu> so it doesn't need to work around bugs in the head selection reg
15:25 < darktama> yes, but it still uses that reg when doing display detection
15:25 < marcheu> maybe people with those cards are forced to use the first output
15:26 < darktama> well, It refuses to work on CRTC1 for me anyway.. so I suspect something's missing
16:21 -!- pmdata [i=patrice@ANantes-154-1-28-109.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
16:33 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:44 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
17:00 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:00 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
17:12 -!- EdB|l [n=EdB@212.234.68.206] has joined #nouveau
17:13 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:21 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
17:33 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:36 -!- EdB|w_ [n=EdB@212.234.68.206] has quit ["Parti"]
17:36 -!- EdB|l [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
19:00 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
19:00 -!- EdB [n=EdB@ARennes-251-1-8-250.w83-195.abo.wanadoo.fr] has joined #nouveau
20:38 -!- pmdata [n=patrice@ANantes-154-1-54-97.w81-53.abo.wanadoo.fr] has joined #nouveau
21:59 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
22:17 -!- svu [n=svu@host-194-46-252-242.dsl-ie.utvinternet.net] has quit [Read error: 113 (No route to host)]
22:17 -!- svu [n=svu@194.46.163.190] has joined #nouveau
22:22 < Lumag> marcheu: today I was able to test mmtrace with valgrind 3.2.0. After applying patches, defining Iop_ReinterpF32asI32, and adapting mt_instrument to new instrumentation prototype, everything was working.
22:24 < marcheu> hmm, my valgrind still crashes
22:24 < marcheu> I think I'll install another system soon anyway, so that I can break stuff as I like
22:25 < pmdata> ah, nice progress in commands, with a simple glClear(color_buffer), 64 commands are triggered, still 21 to find what they are
22:26 < marcheu> cool, btw I've setup a page about me (actually, about what hardware I have and my todo list)
22:26 < marcheu> feel free to add stuff I should test there
22:27 -!- pedro_ [n=pedro@c906e04c.virtua.com.br] has quit [Remote closed the connection]
22:31 < pmdata> there are so much stuff I added to cmds.* I did not wrote some corresponding test functions
22:34 < pmdata> I just added the vertex commands matthieu found
22:34 < marcheu> yup, btw I don't know why he didn't commit those
22:34 < pmdata> does he have cvs write access? maybe he has not enough free time
22:35 < marcheu> yup, he's mat-c
23:03 < pmdata> marcheu> so what are you trying to achieve with valgrind?
23:04 < marcheu> pmdata: Lumag has a valgrind tool that traps all memory writes to a given adress range. we could use it to trace the full xorg and see how init is done, for example (provided that is done in user space, that is)
23:14 < pmdata> ok
--- Log closed Вск Июн 11 00:00:24 2006