--- Log opened Сбт Июл 08 00:00:35 2006
--- Day changed Сбт Июл 08 2006
00:00 -!- EdB [n=EdB@ARennes-251-1-57-23.w81-53.abo.wanadoo.fr] has joined #nouveau
00:15 < Lumag> I'll put the link in the wiki
00:28 -!- EdB [n=EdB@ARennes-251-1-57-23.w81-53.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:53 -!- ness [n=ness@212.80.253.90] has quit [Remote closed the connection]
02:01 -!- pmdata [n=patrice@ANantes-154-1-21-151.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
02:22 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
04:22 < ddl> hey!
04:22 < marcheu> ho!
04:22 < ddl> :)
04:22 < ddl> long time no see
04:22 < marcheu> hey, you were supposed to say "let's go !"
04:23 < ddl> heh :)
04:23 < marcheu> (if you're into punk rock, that is)
04:23 < marcheu> so how's US ?
04:23 < ddl> the only punk rock i enjoy listening to is bad religion :)
04:24 < ddl> its very nice here, perfect weather and ive spent quite alot of time outside
04:24 < ddl> which is nice since i hardly ever do it during the years
04:24 < ddl> :)
04:24 < marcheu> where are you more precisely ?
04:25 < ddl> right now im outside of traverse city, michigan
04:26 < ddl> ive been down in pensylvania for a couple of weeks, from where i hardly had any access to the internet
04:28 < ddl> so, you have any ideas of any parts for me to dig into?
04:29 < ddl> im staying here for another month and most nights i have a spare couple of hours :)
04:29 < marcheu> hmm, right now darktama_ is working on porting the DDX fifo init code to the DRM
04:30 < marcheu> lumag works on renouveau
04:31 < ddl> ok, still alot of RE:ing to be done on >nv30?
04:31 < marcheu> the bios code is still not my friend
04:31 < marcheu> and I'm working on hacking a softquadro for linux right now
04:31 < ddl> softquadro?
04:31 < marcheu> I think most 3D stuff is known on >nv30
04:31 < marcheu> yup, the software modification to turn a geforce into a quadro
04:32 < marcheu> I though if we do RE, we might as well do it on quadros
04:32 < ddl> kind of what i figured from reading the code of renouveau the other day
04:32 < ddl> ah
04:32 < ddl> ok
04:32 < ddl> so what issues have you experienced with the bios code?
04:32 < marcheu> the cards are the same, but the driver basically disables features on geforce
04:32 < marcheu> well, it works without crashes, but leaves the card in an unusable state
04:33 < marcheu> if I power down & up the engines, register will start reporting strange values, like if I have 64Mb of video ram (I have 128) and such
04:34 < ddl> i never really figured out that init-memory-routine
04:34 < marcheu> well, the beos driver does a card reset as well after bios parsing
04:34 < ddl> how is that done?
04:35 < marcheu> well, it has some routines for that
04:35 < marcheu> one of those is called "unlock_card()"
04:36 < marcheu> it's quite complicated, do you have the haiku code at hand ?
04:36 < ddl> ah, i there is something similar in nvclock
04:37 < ddl> no, ill grab the code, hold
04:37 < marcheu> nvclock unlocks the card after reading the bios ?
04:37 < marcheu> ISTR it only reads stuff from there, but doesn't execute
04:38 < ddl> i think he has some routine called something similar, but nvclock hardly parses anything of the bios
04:38 < ddl> i think its just some reg writes that will allow some other regs to be written
04:39 < marcheu> ah, yes I see what you mean
04:39 < marcheu> haiku has that as well
04:39 < marcheu> nv_card->PMC[0x1850/4] = 0x0;
04:39 < ddl> i think he mainly parses the bios to get the performance tables (which are accessed the same way as the init tables from the bit/bmp structs)
04:39 < marcheu> but it's just about being able to access the bios, not about resetting the card afterwards
04:39 < ddl> ok
04:40 < marcheu> I do that in the ddx as well, btw
04:41 < ddl> ok, browsing the haiku svn now
04:41 < ddl> any particular file?
04:41 < marcheu> you want me to upload a checkout tarball for you ?
04:42 < marcheu> nv_info.c does bios parsing, and nv_general.c calls the bios parsing from nv_info.c and resets the card afterwards
04:42 < ddl> sure, why not :=
04:43 < marcheu> ok, only the nvidia driver : http://icps.u-strasbg.fr/~marchesin/nvdri/nvidia-haiku.tgz
04:44 < ddl> thanks
04:44 < marcheu> hmm you might need the headers as well
04:45 < marcheu> headers : http://icps.u-strasbg.fr/~marchesin/nvdri/nvidia/
04:46 < ddl> got em
04:46 < marcheu> so you have nvxx_general_powerup() in nv_general.c
04:47 < ddl> looking at it right now
04:47 < marcheu> parse_pins() parses the bios
04:47 < marcheu> the rest of the function just makes sure everything works afterwards
04:47 < darktama_> so, do we want to keep the current code FIFO code in the ddx for non-drm systems?  If not, the documentation is still very useful so we should do something with it
04:48 < marcheu> darktama_: which documentation ?
04:48 < darktama_> in nv_dma.c
04:49 < marcheu> what about moving it to the drm as the related code moves ?
04:49 < darktama_> yeah, that's probably the best
04:50 < marcheu> so, what are the differences between a geforce and a quadro ?
04:50 < ddl> so reg 0x00000200 is used to "power-up" stuff after the bios has been parsed
04:51 < marcheu> I'd like to fire up a relevant benchmark...
04:51 < ddl> among other things...
04:51 < marcheu> ddl: yes, but not only that
04:52 < marcheu> ddl: oh, and I'm sure that it's not sufficient to do it btw :)
04:52 < marcheu> if you don't do it, nothing works, and most regs are 0x0
04:53 < marcheu> if you do that, regs have values again but these don't always look correct (this leads to the memory size issue I described previously , for example)
04:55 < ddl> like if i write x to register y and fail to do the "unlock_card"-stuff... might x not contain y after that?
04:56 < ddl> during a cold start
04:56 < marcheu> well, it really looks like everything is lost
04:56 < marcheu> this is a cold start, after all
05:00 < ddl> dont you think this might be because of a invalid init_compute_mem-routine?
05:03 < ddl> i have two additional bits set in 0x200 (over those set by the haiku driver)
05:05 < marcheu> yup, same here. it's the 2 other engines
05:05 < marcheu> the DDX sets them btw
05:05 < ddl> do you know what engines those bits control?
05:05 < ddl> ok
05:06 < marcheu> only one of those. it's documented in nv10reg.h
05:06 < ddl> ok
05:07 < marcheu> the other one is probably something output-related (but it's neither crtc, nor tv-out... we were thinking maybe it was DVI the other day)
05:07 < ddl> ok
05:08 < ddl> NV_REG8(NV8_MISCW) = 0xcb;
05:08 < ddl> 0x000c03c2
05:08 < darktama_> that's the VGA misc reg iirc
05:09 < ddl> okey
05:09 < ddl> avtully that line had a comment :)=
05:09 < ddl>     /* select colormode CRTC registers base adresses */
05:10 < darktama_> hmm I was thinking, does the nvidia X driver work at all without the kernel module present?
05:10 < ddl> i think so
05:11 < ddl> but dont take my word on it :)
05:11 < marcheu> darktama_: no
05:11 < darktama_> ah, damn.. I thought I remembered it working, which would be odd because they do modesetting in the kernel
05:12 < marcheu> nope, no chance
05:14 < darktama_> hmm, interesting commit to xorj just then "Restore the ABI for DrawableRec..... Based on patch from Andy Ritger".  wonder if that's what nvidia are waiting for with their 7.1 driver
05:14 < darktama_> xorg*
05:16 < marcheu> I don't remember, but there was some discussion going on like "let's break it - no undo it - no break it after release"
05:16 < marcheu> not sure how that ended
05:16 < ddl> what is this "panel startup" that they are talking about in the haiku driver?
05:17 < ddl>     /* get RAM size, detect TV encoder and do fake panel startup (panel init code
05:17 < ddl>      *  is still missing). */
05:17 < darktama_> I'm not certain, but it's related to the comments in the nv manpage about the BIOS having to setup the panel
05:17 < ddl>     fake_panel_start();
05:18 < marcheu> yes, I think it does what the bios does to startup the panel
05:20 < darktama_> right now, the ddx/haiku can't actually detect panels.. it has to look for a CRTC that's been slaved to a TMDS by the BIOS (at least, I think that's what it's doing - modesetting is a little out of my league still)
05:20 < ddl> "panel" being the physical device connected to the one of the cards heads?
05:20 < darktama_> panel being a TMDS/LVDS flatpanel
05:21 < marcheu> ah, if haiku can't do it that's annoying
05:23 < darktama_> actually, I think panel also means TV in the haiku case.. you detect that in much the same way as you do a flatpanel
05:23 < ddl> the "fake_panel_start2
05:24 < ddl> " in haiku also seems to do other stuff 
05:25 < ddl> like detecting BT chips
05:25 < ddl> (brooktree)
05:25 < ddl> those are tv-in chips, right?
05:25 < marcheu> brooktree are tv encoders
05:25 < marcheu> so tv out
05:26 < ddl> ok
10:29 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
10:48 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
11:53 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
12:02 -!- pmdata [n=patrice@ANantes-154-1-112-76.w86-214.abo.wanadoo.fr] has joined #nouveau
12:10 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
13:09 -!- pmdata [n=patrice@ANantes-154-1-112-76.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
14:01 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
14:24 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has joined #nouveau
14:26 -!- pmdata [i=patrice@ANantes-154-1-112-76.w86-214.abo.wanadoo.fr] has joined #nouveau
14:55 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has quit [Remote closed the connection]
15:00 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has joined #nouveau
15:43 -!- pmdata [i=patrice@ANantes-154-1-112-76.w86-214.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
15:48 -!- stringfellow [n=stringfe@a80-100-96-220.adsl.xs4all.nl] has joined #nouveau
16:11 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:34 < darktama_> hmm, it seems EXA is broken.. the driver gets stuck in NVDmaWait if you try to start e17.. XAA is fine though
16:38 < darktama_> it's the composite hook from the looks of it
16:42 < Lumag> The drm doesn't work for me. NVDriScreenInit is called many times. Each call tries to load module "dri". And that fail (module already loaded).
16:44 < darktama_> yup, I've changed that locally.. it's only called once in ScreenInit here
16:44 < Lumag> darktama_: maybe you can commit you changes to some branch? So that others can look & hack code too...
16:45 < darktama_> I intend to commit it soon (a couple of hours hopefully), it's part of moving the object code into drm.. a couple of bugs to squash first
16:46 < darktama_> one of which doesn't appear to be my fault (the e17 thing) - it fails with the vanilla ddx from nouveau cvs
16:50 < darktama_> may not be the composite hook actually, disabling it just gets me stuck elsewhere :(
16:53 < Lumag> Are DMA notifiers working at all?
16:53 < darktama_> this particular crash seems to be the FIFO stalling
16:58 < Lumag> Do you get any interrupts at that time?
16:58 < darktama_> hmm, no idea
16:58 < darktama_> I didn't think we used the gpu interrupts
16:59 < Lumag> IIRC the interrupt is asserted at some DMA events.
17:00 < Lumag> at least IIRC rivatv uses interrupts.
17:01 < Lumag> Don't have the code at hand.
17:01 < darktama_> yeah, the ddx just polls AGP space to see if a notifier has changed
17:05 < Lumag> Another two dumb ideas:
17:05 < Lumag> 1) After FIFO flushes, nvglx puts 17 NOPS before issuing new commands. Maybe it's necessary?
17:05 < Lumag> 2) Are you sure that you use only one codepath? That you don't mix drm and non-drm codepaths?
17:09 < marcheu> no, interrupts aren't used
17:10 < marcheu> might be better than the current polling approach, though. although we'll have to wrap that into some kernel interface anyway
17:14 < darktama_> Lumag: 1: not sure, it's worth a try though. 2: there's only 1 EXA codepath. also, in the cvs ddx the drm is hardly used. I'm not even sure what for actually
17:16 < marcheu> the drm is used to allocate agpMemory, which in turn is used for DMA to/from video memory
17:17 < Lumag> What about removing all resource/objects/FIFO management from DDX. I think it should help isolating bugs.
17:18 < darktama_> yup, that's what I'm doing at the moment
17:18 < marcheu> we have to anyway, because most resources have to be shared with the dri
17:19 < Lumag> :)
17:19 < marcheu> and resource sharing should not happen in the ddx
17:21 < darktama_> ok, I'll commit the changes now if everyone is ok with it.. the ddx will then be dependant on the drm to function at all
17:22 < darktama_> it's basically an exact replica of what the ddx does, so it'll need a lot of changes still before it's good enough
17:28 < Lumag> imho commit to a branch, it the code isn't mature enough.
17:29 < marcheu> I don't think we can afford branches, given how few people are working here
17:30 < marcheu> plus I don't care about fixing potential issues, and such issues will probably pop up on different cards
17:31 < marcheu> so comitting to head gives some field testing
17:38 < darktama_> ok, I'll commit then?
17:39 < marcheu> I'm ok with that, if X fires up that's enough testing for me
17:40 < darktama_> yup, everything still seems to work as well as it did before.. it's just e17 that kills both versions
17:40 < marcheu> but e17 uses composite, right ?
17:40 < darktama_> nope
17:40 < marcheu> hmm, where does it die ?
17:41 < darktama_> oh, it hits the EXA composite hooks yes.. but not the composite extension
17:42 < darktama_> there's a couple of hangs in NVDmaWait, not sure of exactly when it happens yet. will investigate it more soon
17:42 < marcheu> in the wait for notifier stuff ?
17:42 < marcheu> IIRC benh told me his PPC needed the notifiers to be put in video ram and not agp space
17:43 < marcheu> so if moving them fixes it for you, that's a second reason to do it
17:43 < darktama_> nope, not the notifier wait, the code in nv_xaa.c
17:43 < marcheu> ok, the notifier thing still shoudl be done I think :)
17:44 < marcheu> NVDmaWait is a terse function, but the haiku driver has a 2-page version with comments
17:44 < darktama_> ok, we're going to move that into DRM eventually aren't we (when we have a memory manager)?  should do it then
17:45 < marcheu> NVDmaWait in the drm ? what for ?
17:45 < darktama_> no, the notifier handling
17:45 < marcheu> ah
17:46 < marcheu> well, as I said, we need an interface around the notifier stuff. sure notifiers can use irqs internally, but what kernel interface should be chosen ? I don't like polling, but I'm not sure how to expose it otherwise...
17:47 < marcheu> if we have to poll from user space anyway, we can have the ioctl look at the notifier status from the notifier area, it's not any different than tracking occured interrupts (and probably simpler to implement)
17:48 < Lumag> well... There can be something as simple as poll() syscall.
17:50 < marcheu> remember we have to use the drm interface...
17:51 < marcheu> hmm actually, there is some polling support
17:58 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has joined #nouveau
18:09 < darktama_> hmm, I think I'm going to have to merge at least the code to turn off the screen on the second head.. it's annoying looking at flashing blocks :S
18:19 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
19:40 -!- Duke` [n=gnu@ANantes-251-1-83-139.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
19:41 -!- Duke` [n=gnu@ANantes-251-1-133-108.w86-210.abo.wanadoo.fr] has joined #nouveau
19:58 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
19:59 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
20:32 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has joined #nouveau
20:39 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has quit [Remote closed the connection]
20:39 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has joined #nouveau
20:47 -!- EdB_ [n=EdB@ARennes-251-1-93-167.w86-199.abo.wanadoo.fr] has joined #nouveau
20:59 -!- EdB [n=EdB@ARennes-251-1-76-79.w86-195.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
21:14 -!- pmdata [i=patrice@ANantes-154-1-62-57.w81-53.abo.wanadoo.fr] has joined #nouveau
21:16 < darktama_> whee, I just got xorg to start using the second FIFO
21:19 < darktama_> I won't commit it yet though, there's a bug which makes things render incorrectly (even on FIFO 0) with the code that's #if 0'd out in fifo_init()
21:29 < marcheu> sounds good !
21:30 < darktama_> no context switching though :)
21:30 < marcheu> well, if you can feed commands, that means you know how to setup fifo 1
21:32 < darktama_> yup, all that was needed was to add the channel field into the second part of a RAMHT entry.. that and filling PFIFO with the info for FIFO1
21:32 < darktama_> we have to move the DDX's cursor somewhere else though, it's taking up FIFO 1's command buffer at the moment
21:33 < marcheu> yay, I know... the notifiers will have to move as well
21:33 < marcheu> (i.e. the patch that's floating around to put notifiers in vidmem puts them over one of the fifos)
21:34 < darktama_> ahh, hmm.. memory management :P
22:19 < darktama_> marcheu: btw, to map the FIFO (and regs) setup by the drm, do we have to parse all the maps looking for a match and then drmMap or is there a better way?
22:24 < marcheu> we should return map information in the fifo_init ioctl
22:24 < darktama_> ah, makes sense
22:27 < darktama_> on that note, I should sleep! night
22:30 -!- pmdata [i=patrice@ANantes-154-1-62-57.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
22:40 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has quit ["Au revoir."]
22:43 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has joined #nouveau
22:51 -!- _Demo_ [n=Demo@modemcable038.138-201-24.mc.videotron.ca] has joined #nouveau
--- Log closed Вск Июл 09 00:00:46 2006
