--- Log opened Птн Июл 07 00:00:44 2006
00:27 -!- ness [n=ness@212.80.253.90] has quit [Remote closed the connection]
00:39 < pmdata> marcheu> just try some stuff that uses polygon stipple, found something about the clip planes
00:39 < marcheu> found what ?
00:39 < pmdata> you were right, 620 and 630 seems to be the 2 missing clip planes
00:40 < pmdata> when rendering a polygon with stipple enabled, it uses clip planes to render it, and the four clip planes from 600,610,620,630 are used and enabled
00:41 < marcheu> I don't see the link between polygon stipplke and clip planes
00:42 < pmdata> but 620 and 630 seems to be filled with some dummy value (0.0,0.0,1.0,0.0) and (0.0,0.0,0.0,1.0)
00:42 < pmdata> maybe the stipple is applied first, using clip planes to clip it, then render the final polygon above it
00:43 < marcheu> god
00:44 < pmdata> it could also means nv10 has 8 clip planes (also 660 and 670)
00:44 < pmdata> maybe they are only used by the driver on quadro ("pro") cards
00:45 < pmdata> it means the test_clip_plane() function is not written correctly to show all clip planes
00:46 < pmdata> so should I patch renouveau for 8 or 6 clip planes?
00:48 < Lumag> pmdata: and what happens if you try enabling 8 clip planes?
00:49 < marcheu> you gen an opengl error, because the nvidia opengl only support 6 clip planes on gf2
00:49 < marcheu> s/gen/get
00:50 < pmdata> glgetintegerv(gl_clip_planes) return 6 on my gf2
00:50 < marcheu> yup
00:50 < pmdata> but it does not mean the hardware does not support it, it only means the nv driver does not show the 8 planes to the apps
00:50 < pmdata> or maybe the 2 extra planes are buggy
00:51 < Lumag> :(
00:51 < marcheu> we'd have to get a quadro card, or get the driver to work in quadro mode
00:51 < pmdata> I will put the 8 in renouveau, till we know more
00:51 < marcheu> actually
00:52 < marcheu> we can look on delphi3d.net 
00:52 < marcheu> ... which says 6 as well
00:53 < pmdata> even for quadros?
00:53 < marcheu> yes, for quadro & quadro 2
00:53 < marcheu> http://delphi3d.net/hardware/viewreport.php?report=114
00:53 < marcheu> http://delphi3d.net/hardware/viewreport.php?report=1244
00:54 < Lumag> Then is looks like the driver underloads the card. I.e. in my case (nv06) there should be 16 verteces for triangle objects, but the driver only uses first 6.
00:54 < pmdata> are there some nv cards with more than 6 clip planes?
00:54 < marcheu> it'd be interesting to have some kind of softquadro for linux, and compare resuilts in renouveau
00:55 < marcheu> Lumag: might be a performance reason
00:55 < marcheu> pmdata: maybe soe 3dlabs cards
00:56 < pmdata> or maybe the hardware can not eat it without bugging
00:56 < Lumag> i think that there should be performance gain if more verteces are available, because we don't have to reload them each time.
00:56 < marcheu> or maybe the nv06 doesn't have the extra 10 vertices, and only nv05 can use it...
00:57 < Lumag> Maybe... Can't compare with plain tnt2 currently.
00:59 < Lumag> Probably we'll be able to test such possibilities, when we'll have working nv_object_alloc :)
01:09 < darktama_> hmm, marcheu - what you've named NV03_FIFO_ENABLE, nv10reg.h and haiku indicate that it's the PIO/DMA bits for each fifo
01:14 < marcheu> yep
01:25 < pmdata> lumag> do you still log this chan?
01:29  * pmdata have to sleep now
01:29 -!- pmdata [i=patrice@ANantes-154-1-51-52.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:47 < marcheu> darktama_: so you can change it if you like, don't look at me like that
01:48 < darktama_> :)
01:49 < darktama_> sorry, I just managed to lockup my machine while moving the magic PFIFO setup into drm
01:51 < darktama_> oops, and I know how I did that now too :S
01:52 < marcheu> what stuff ? the NVLoadStateExt ?
01:53 < darktama_> yup
01:54 < marcheu> the trouble is it's called at each mode switch
01:55 < darktama_> yeah, I don't think it's necessary though.. I'm fairly sure haiku doesn't do it
01:55 < marcheu> and I'm not sure where it should be cut to separate fifo setup from things necessary to mode switches
01:56 < darktama_> actually, it does do it on mode switch..
02:00 < darktama_> problem is, if the drm is going to be responsible for setting up the FIFOs we can't really have the ddx trampling the FIFO setup and the hash table on a mode switch..
02:01 < marcheu> yes, that's my point
02:03 < marcheu> maybe just moving the PFIFO things will work...
02:04 < darktama_> perhaps, I'm getting stuck in UploadToScreen with the current changes I have.. double-checking the drm-side of things again to make sure I got it all
02:04 < marcheu> does it work in xaa mode ?
02:05 < darktama_> I didn't try that yet.. it's actually WaitForNotifier that's getting stuck, called by UTS
02:05 < marcheu> when do you do the dma command setup in the drm ?
02:06 < marcheu> did you add an ioctl, or on startup ?
02:06 < darktama_> in firstopen()
02:09 < marcheu> so you moved the whole NVInitDma as well ? 
02:09 < marcheu> it's the one responsible for creating the notifier
02:11 < darktama_> no not yet, I've left everything intact except the PFIFO stuff in LoadStateEXT.. the drm init's it exactly the same way as the ddx.. once I get that much working I'll make the ddx call drm for object setup
02:12 < darktama_> ah, there we go :)
02:12 < darktama_> I missed the FIFO_ENABLE line somehow.. :S
02:13 < darktama_> that's important I imagine!
02:13 < marcheu> I'm concerned about NVInitDma because it's setup _before_ the PFIFO stuff
02:18 < darktama_> hmm, it basically just (re)creates all the objects that the EXA path uses
02:18 < darktama_> and kills RAMIN and RAMHT
02:27 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
02:27 < marcheu> so does it work if you setup FIFO_ENABLE_OR_WHATEVER_THE_NAME ?
02:28 < darktama_> yup, it does.. things get a little weird after calling randr though
02:29 < darktama_> things slow down heaps, and theres messages in the Xorg log saying the DMA queue has hung
02:29 < marcheu> hmm
02:29 < marcheu> btw there's one thing about those timeoute
02:29 < marcheu> timeouts
02:29 < marcheu> the Xorg exa timeout is particularly stupid
02:30 < marcheu> NVSync()
02:30 < marcheu> it's cpu-speed dependent, basically
02:30 < darktama_> hmm, why was it done like that?
02:31 < marcheu> it comes from the exa patch, so it's unfinished
02:32 < darktama_> ah, I see.. it through me off a bit being in nv_xaa.c..
02:32 < marcheu> yeah, that too
02:33 < darktama_> threw*
02:38 < marcheu> so, some of the PFIFO stuff would be needed on mode switch... interesting
02:41 < darktama_> I'd still like to know what the relationship between the GET/PUT in PFIFO is to the ones in the per-FIFO regs
03:06 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:07 < marcheu> hmmm, what are their values ?
03:07 < marcheu> I can see if they are the same, which I think is probably the case
03:11 < darktama_> one sec
03:12 < marcheu> so, 0x00800040
03:12 < marcheu> (PUT
03:12 < marcheu> and 0x00800044
03:12 < marcheu> (GET)
03:17 < marcheu> and, 3240 and 3244
03:18 < darktama_> yup, got them.. ok this is with glxgears running too.. there's something interesting
03:18 < darktama_> http://rafb.net/paste/results/666Ai340.html
03:18 < marcheu> yay, so it's just a copy
03:19 < marcheu> the GET difference is not relevant I think
03:20 < darktama_> some other dumps show CACHE1_PUT==FIFO2_PUT also
03:21 < marcheu> is it reproducible ? 
03:21 < marcheu> what if you dump in another order ?
03:22 < darktama_> yes, just start a GL app along with Xorg.. when there's more than 1 FIFO enabled the values change that PFIFO shadows changes often
03:24 < darktama_> ah, also.. the DMA instance in PFIFO changes when PUT/GET shadow FIFO2
03:24 < marcheu> hu ?
03:25 < darktama_> 0x322C contains a pointer into RAMIN for the DMA command buffer, it changes to another value when PUT/GET == FIFO2's PUT/GET regs
03:26 < marcheu> hmm, you mean that's some kind of context switching  ?
03:26 < darktama_> yup, seems that way..
03:27 < darktama_> I don't know if it's driver-controlled, or done by the hardware
03:28 < darktama_> one of the docs on rivatv's site mentions that the other FIFO's can't be used until context-switching code is written.. perhaps that's what it is
03:29 < marcheu> yeah, well at the same time the rivatv docs don't know anything about that mysterious "context switching" code
03:29 < darktama_> hehe, that's true
03:30 < marcheu> I got started with that somehow, I could finish up
03:30 < marcheu> it looks like the fifo creation only does write to 0x00002504
03:31 < marcheu> maybe it's as simple for fifo switch
03:33 < darktama_> my guess is that you fill DMAI/GET/PUT with the values for the FIFO you want to use, but there's probably more to it than that
03:39 < darktama_> ok, in addition to the DMAI/PUT/GET.. PSH1 changes from 0x00010000 to 0x00010002 when FIFO2 is being used
03:41 < darktama_> and 0x00010003 when it's FIFO3..
03:42 < darktama_> ah, nv10reg already knows about that
03:42 < marcheu> PSH1 ?
03:42 < darktama_> 0x3204
03:42 < darktama_> I was using haiku's name for it, it's CACHE1_PUSH1 according to nv10reg
03:43 < marcheu> so, it looks like you have to push a fifo through a cache to make it work
03:44 < marcheu> the cache being the fetching engine, really
03:44 < darktama_> yup
03:45 < darktama_> so.. where would we put context switching code.. in the drm obviously, but how do we decide when to switch contexts..
03:46 < marcheu> well...
03:46 < marcheu> a long time ago...
03:46 < marcheu> there was context switching in the drm
03:46 < marcheu> drm_context.c holds this code
03:47 < marcheu> but since no supported hardware has hw contexts anymore, I don't know what state it's in
03:48 < marcheu> otherwise, we could probably hack it into the lock code
03:49 < darktama_> hmm, found it (drm_context.h) - will take a look soon
03:49 < marcheu> well drm_context.h is from the old "linux" branch, since the code split, it's drm_context.c in linux-core
03:50 < marcheu> s/code/core/
03:50 < darktama_> whoops :)  my bad
03:50 < marcheu> that code is overkill anyway
03:55 < darktama_> ok, I have a really stupid question.. how do we call the drm ioctls? :)
03:56 < marcheu> from ?
03:56 < darktama_> the ddx
03:57 < marcheu> use drmCommandWrite
03:57 < marcheu> it is wrapping libdrm somewhere in X, don't remember where
03:59 < marcheu> oh, and if it has 2-way communication, use drmCommandWriteRead
03:59 < darktama_> so, for FIFO_INIT it'd be WriteRead because it returns a FIFO number?
03:59 < marcheu> (and if it doesn't need parameameters, drmCommandNone)
03:59 < marcheu> yes
04:01 < darktama_> cool, that makes sense
04:09 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
10:04 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
10:12 < Lumag> A few notes about context switching. Sometimes nvidia driver does this: http://rafb.net/paste/results/U7pTej33.html
10:12 < Lumag> Hope it helps :)
10:34 < darktama_> the writes to DA8200xx are the driver doing the equivilant of NvDmaKickoff()
10:36 < darktama_> ... s/xx/40/ :)
10:37 < darktama_> what's the "init stop"/"start" referring to?
10:53 < Lumag> those are just output from my prg.
10:53 < Lumag> There is a glFlust() just before "init stop"
10:54 < Lumag> glFlush()
10:54 < Lumag> and a glClear() right after "start"
10:55 < Lumag> And so nvglx issues two fifo flushes
12:59 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
13:00 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
13:05 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
14:45 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
14:58 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
14:58 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
15:31 -!- ness [n=ness@212.80.253.90] has joined #nouveau
15:54 -!- shavengerAway [n=sha@swarm.ulb.ac.be] has quit [Read error: 110 (Connection timed out)]
16:05 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
17:55 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
18:17 -!- ness [n=ness@212.80.253.90] has quit [Remote closed the connection]
19:39 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:50 -!- pmdata [i=patrice@ANantes-154-1-28-203.w81-53.abo.wanadoo.fr] has joined #nouveau
20:04 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
20:32 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
21:30 -!- pmdata [i=patrice@ANantes-154-1-28-203.w81-53.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
21:39 -!- Duke` [n=gnu@ANantes-251-1-130-12.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
21:40 -!- ness [n=ness@212.80.253.90] has joined #nouveau
21:40 -!- Duke` [n=gnu@ANantes-251-1-83-139.w86-203.abo.wanadoo.fr] has joined #nouveau
21:51 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
22:54 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
23:15 -!- pmdata [n=patrice@ANantes-154-1-21-151.w81-53.abo.wanadoo.fr] has joined #nouveau
23:19 -!- EdB [n=EdB@ARennes-251-1-57-23.w81-53.abo.wanadoo.fr] has joined #nouveau
23:21 < pmdata> hello
23:22 < EdB> hi
23:22 < EdB> back from rmll, what new ?
23:23  * pmdata can't tell, maybe you'd better have a look to cvs commits :)
23:23 < EdB> yeah :o)
23:28 < marcheu> btw I think I'll try to do a kind of softquadro for linux
23:29 < marcheu> so that we can do RE on "quadro" cards
23:42 < Lumag> pmdada: yes, all logs are kept at the same location
23:54 -!- EdB [n=EdB@ARennes-251-1-57-23.w81-53.abo.wanadoo.fr] has quit [Read error: 113 (No route to host)]
23:55 < pmdata> lumag> could you remind me the irc logs?
23:57 < Lumag> http://lumag.spb.ru/nouveau/irclogs
23:59 < pmdata> thanks, /me bookmark it this time :)
--- Log closed Сбт Июл 08 00:00:35 2006
