--- Log opened Пнд Июл 03 00:00:41 2006
00:40 -!- Unbeliever [n=hazel@212.145.81.31] has quit [Remote closed the connection]
00:57 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
01:34 < darktama_> marcheu: do you know the purpose of the DMA object pointed to by 0x322C?  it seems to point to the command buffer for the first FIFO, but what about the other FIFOs?
01:37 < darktama_> there's no regs around the 0x322C area that point to the others, so maybe I've misunderstood what 0x322C is for.. haiku calls it NVACC_PF_CACH1_DMAI
01:41 < marcheu> darktama_: nv10reg.h says NV_PFIFO_CACHE1_DMA_INSTANCE
01:41 < marcheu> and NV_PFIFO_CACHE1_DMA_INSTANCE_ADDRESS
01:42 < darktama_> yup
01:42 < marcheu> so ?
01:42 < darktama_> what's CACHE1?
01:43 < darktama_> I assumed it was the dma object for FIFO0, but I'm not certain.. if it is, we need to find the regs for the other FIFOs
01:44 < marcheu> hmm, I'm not sure why it's called cache, but I think it's just the fifo fetching system
01:44 < marcheu> since it owns the fifo pointers
01:49 < marcheu> oh yeah, so I didn't answer your question
01:49 < marcheu> all the PFIFO regs are duplicated for each fifo :)
01:49 < darktama_> :)
01:50 < marcheu> it's as simple as that
01:50 < darktama_> ahh
01:50  * darktama_ slaps himself
01:50 < darktama_> :)
01:50 < marcheu> that's what I' mapping in the drm
01:51 < marcheu> NV03_FIFO_REGS(i)
01:52 < darktama_> hmm, hangon.. PFIFO and FIFO are different things in the ddx.. FIFO seems to be the regs mapped by drm, PFIFO is where the CACHE_* regs are
01:54 < marcheu> hmm, did I get it wrong ? let me see
01:55 < marcheu> well, the ddx maps PFIFO as FIFO...
01:55 < marcheu> look at WRITE_PUT from nv_local.h for example
01:55 < marcheu> (pNv)->FIFO[0x0010] = (data) << 2;
01:56 < marcheu> (pNv)->FIFO is 0x00800000
01:56 < darktama_> yup, I saw that.. but check nv_hw.c in LoadStateExt, it uses the PFIFO pointer to setup the dma object
01:56 < darktama_> PFIFO is 0x00002000
01:58 < marcheu> the mysterious hardcoded stuff ?
01:58 < darktama_> yup
01:58 < darktama_>     pNv->PFIFO[0x048B] = 0x000011fe;
01:58 < darktama_> that's the instance address
01:59 < darktama_> oh, an interesting point is that I can find that object just fine in RAMIN..
01:59 < marcheu> you mean it exists out of nowhere ?
01:59 < darktama_> eh?
01:59 < marcheu> the object in RAMIN, where is it setup ?
02:00 < darktama_>     /* setup DMA object for command buffer */
02:00 < darktama_>     pNv->PRAMIN[0x07f8] = 0x00003002;
02:00 < darktama_>     pNv->PRAMIN[0x07f9] = 0x00007FFF;
02:00 < darktama_>     pNv->PRAMIN[0x07fa] = pNv->FbUsableSize | 0x00000002;
02:00 < darktama_>     pNv->PRAMIN[0x07fb] = 0x00000002;
02:00 < marcheu> yeah, just got there after I asked...
02:02 < marcheu> so is that stuff duplicated ?
02:02 < darktama_> not as far as I could tell, at least, not +-0x1000 from that area
02:02 < marcheu> no, I mean the fifo 0, it's at 0x00800000 and 0x00002000 ?
02:03 < darktama_> ah
02:03 < darktama_> it seems that way
02:04 < darktama_> I just noticed that the value in 0x322c changes with nvidia running, it's been alternating between 0xbdaf (I can find this object) and 0x11401 (can't find that one - all 0s)
02:12 < darktama_> ok.. I just dumped from 0x00800000 to 0x00800400.. only 0x40 and 0x44 contain values other that 0x00
02:12 < darktama_> which are PUT and GET iirc
02:14 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:18 < marcheu> yup
02:18 < marcheu> the DDX even writes those regs, so I'm almost sure they work
02:18 < darktama_> yup
02:19 < darktama_> so, that leaves the question of where to put the instance address for the other fifos
02:22 < marcheu> I don't think it's separate
02:22 < marcheu> it just inherits another object
02:25 < darktama_> objects can inherit other objects?  I've seen how the ioctl interface has a "parent" object, where's this done on the hw?
02:26 < marcheu> it's not really inheritance, it's just that there seems to be some kind of "master" object which I think enforces a given fifo and other things (dma are IIRC)
02:27 < marcheu> with the free driver, there is only one master, which is 0x80000000
02:34 -!- shavengerAway is now known as sahvenger
02:35 -!- sahvenger is now known as shavenger
02:59 -!- Duke` [n=gnu@ANantes-251-1-140-59.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
03:37 -!- shavenger is now known as shavangerAway
03:37 -!- shavangerAway is now known as shavengerAway
04:36 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
07:32 < ddl> hi!
07:33 < ddl> finally ended up at a place with DSL
07:33 < ddl> alot of things seems to have happened over the last couple of weeks :)
12:20 -!- Duke` [n=gnu@ANantes-251-1-137-182.w86-210.abo.wanadoo.fr] has joined #nouveau
12:30 < marcheu> hi ddl 
14:25 -!- EdB [n=EdB@ARennes-251-1-35-15.w81-250.abo.wanadoo.fr] has joined #nouveau
15:38 -!- EdB [n=EdB@ARennes-251-1-35-15.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:05 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:46 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
16:50 -!- ness [n=ness@212.80.253.90] has joined #nouveau
16:53 < ness> is this project still active?
16:57 < EdB|w_> yes
17:01 < ness> cool.
17:04 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:05 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
17:19 -!- ness [n=ness@212.80.253.90] has quit [Remote closed the connection]
17:22 -!- ness [n=ness@212.80.253.90] has joined #nouveau
17:29 < ness> what is renouveau/cmds.[ch] supposed to do?
17:30 < darktama_> it's left-over from the way we used to interpret the FIFO
17:42 < ness> I try to get started to the reverse engineering process. I tried "dump_before ();glBegin (GL_POINTS);dump_after ();tri (); glEnd();". But I don't really understand the output. Could someone explain what it means (relevant output at http://rafb.net/paste/results/SyckqD24.html)?
17:43 < darktama_> try: dump_before(); <GL instructions here>; dump_after()
17:44 < ness> didn't I do that?
17:44 < darktama_> nope, you need to call tri() between before/after
17:46 < ness> I want to find out how glBegin(GL_POINTS) works, i.e. basically redo http://nouveau.freedesktop.org/wiki/NV30VertexFormat (I have a 5900zt -> nv35 iirc)
17:47 < darktama_> yup, then you'd need dump_before(); glBegin(GL_POINTS); glVertex...; glEnd(); dump_after().. so *all* GL commands you issue need to be between before/after
17:48 < ness> OK, the new output is at http://rafb.net/paste/results/POywWa15.html.
17:49 < ness> is the "mapped subchannel ..." part relevant?
17:51 < darktama_> yup, each FIFO has 8 subchannels to which objects can be bound.. the object defines what commands are available on that channel
17:52 < darktama_> the 3D commands on NV30 belong to object NV30_TCL_PRIMITIVE_3D, that's the output you're seeing at the bottom of the dump
17:54 < ness> so what exactly are these "objects"? (It looks like I'm missing some basic knowledge. Can you point me to something?)
17:56 < darktama_> nv_dma.c in the 2D driver has some info
17:56 < ness> the "nv" driver?
17:56 < darktama_> yup
17:57 < darktama_> actually, you need to look at our version of it.. the Xorg one doesn't have the EXA patch
17:57 < ness> I checked out nv from your cvs
17:57 < ness> is that the right one?
17:57 < darktama_> yup
17:58 < ness> _no_ _docs_ _nowhere_... Graphic driver world is crazy
17:59 < darktama_> :)
17:59 < Duke`> objects are groups of commands
18:11 < ness> To be honest, I do not really understand it :). Isn't there something (a lot) more basic? How does the interface to the (nvidia) grafic cards look like _in general_?
18:14 < Duke`> do you know OpenGL ?
18:14 < ness> yes
18:15 < Duke`> so you send OpenGL instructions to the card
18:15 < ness> who does that? the kernel or the userspace?
18:15 < Duke`> these instructions are transformed as commands, which are put in a FIFO
18:16 < Duke`> and sent to the graphic card
18:16 < Duke`> the driver "transform" the OpenGL instructions into commands (and put them into FIFO)
18:17 < ness> OK
18:19 < ness> so what does "mapped subchannel 0 to beef4901" mean? I suppose it relates to "object creation: beef4901, type 357c, parent beef000b".
18:24 < Duke`> I don't know, I'm not a renouveau guru at all :(
18:24 < ness> who is?
18:24 < Duke`> darktama_ :)
18:24 < Duke`> marcheu
18:24 < Duke`> lumag
18:24 < Duke`> pmdata
18:26 < darktama_> 0xbeef4901 is a "name" given to an object of type 0x357C.. from what we understand, 0x35 is like a "version" of an object, the object itself is 0x7C
18:27 < ness> so these names are just for me to distinguish them and created by renouveau?
18:28 < darktama_> the names are used by the FIFO commands to reference a particular object
18:28 < ness> OK. And what means 0x7C?
18:28 < ness> and the parent?
18:29 < darktama_> 7C is the object type (defines what commands a FIFO subchannel can use), I'm not entirely certain how the parent stuff works.. marcheu and Lumag know more about that
18:30 < darktama_> on nv30/nv40/G70 the main 3D object has type 0x97, which we've called NV30_TCL_PRIMITIVE_3D
18:32 < ness> do drawing commands cause kernel mode entering?
18:33 < darktama_> no, OpenGL state->HW commands is done in userspace
18:34 < ness> OK. So what does it mean that subchannels are mapped to multiple objects?
18:34 < darktama_> there are multiple FIFOs, each graphics context has it's own FIFO
18:34 < darktama_> they're not, the driver would have bound an object to the subchannel, issued some commands, bound another object.. etc.
18:35 < ness> So if a program wants to do stuff from userspace, it asks the kernel for a graphics context and gets a fifo to write stuff in?
18:35 < darktama_> yup
18:36 < ness> so I can ignore all the mapping to subchannels except the last (in my case, as all happen before the commands)?
18:36 < darktama_> the other mappings/commands are done at context creation time (SDL_SetVideoMode), and renouveau ignores them by default
18:37 < ness> that's what I guessed
18:37 < darktama_> to find out how a GL feature is implemented you can ignore it, if you want to know how to setup a context it's useful to see
18:37 < ness> what are registers?
18:38 < ness> (OK, words in memory, but what are they used for and how does the program get access to them?)
18:39 < darktama_> well, the ones userspace should be able to access are mapped by the kernel module (FIFO control regs)
18:39 < darktama_> the FIFO control regs are used to tell the GPU there's commands ready to be processed in the FIFO
18:39 < marcheu> ness: did you read http://nouveau.cvs.sourceforge.net/nouveau/renouveau/README?revision=1.3&view=markup ?
18:39 < ness> marcheu: yes
18:41 < marcheu> basically, the registers are not available to all applications, the kernel module maps the regs into the user space app when it creates the OpenGL context
18:41 < marcheu> once the regs are mapped, it's just about accessing the right fields in memory
18:50 < ness> "44b   0x00000000   0x00043dac             {size: 0x1   channel: 0x1   obj: beef3097}" and "object creation: beef3097, type 3597, parent beef000b" mean type is 3597, but if I interpret "0x00043dac" like shown in the readme, type should be 0x1dac?
18:51 < marcheu> it is command 0x1dac from the object 0x3597
18:54 < ness> I think I begin understanding (though there're lots of open questions): the fifo "entry" 44f means we do glBegin, it's argument (the next entry) means we want GL_POINTS. entry 45b means glBegin with argument STOP, i.e. glEnd. correct?
18:55 < marcheu> I can't say, I don't know what's at adress 44f/45b on your card :)
18:55 < marcheu> the fifo is filled with commands dynamically, so one can't expect stuff to be at a given place
18:56 < ness> I posted a dump: http://rafb.net/paste/results/POywWa15.html. That's the only thing I'm interpreting.
18:56 < marcheu> so yes, that's it
18:57 < marcheu> also it's not clear from the current dump but stuff at 40001818 and further is vertex data as ieee floating point
18:57 < marcheu> do you really have a PCI card btw ?
18:57 < marcheu> old-school pci card ?
18:58 < ness> agp
18:58 < marcheu> alright, then there's a bug in renouveau
18:58 < ness> I have two other pci cards, maybye that's confusing it.
18:59 < marcheu> ah yes
18:59 < marcheu> multiple nvidia cards are not handled very well (if at all)~
18:59 < ness> yes, running the test on another display doesn't work at all
19:00 < ness> so the library stuffs commands in the fifo and than writes a register to start execution, right?
19:00 < marcheu> yes
19:01 < ness> if there are more applications that want to use the card than contexts, is the graphic card multiplexed like the cpu?
19:01 < marcheu> nope, the nvidia is good enough to have multiple contexts
19:02 < ness> yes, but if there are not enough contexts?
19:02 < marcheu> which are handled in hardware. some kind of hyperthreading if you want to push the CPU comparison
19:02 < ness> so limited number of contexts?
19:02 < marcheu> no idea, and when there are 16 contexts available on plain nv10 you don't really care
19:03 < marcheu> I suppose the last ones get to share a single fifo. or maybe a more elegant solution is to have a context dedicated to indirect GL rendering and have apps use indirect rendering when too many contexts are already open
19:03 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
19:05 < ness> 30 times glxgears on a geforce2 (iirc) at least doesn't crash anything or report errors
19:06 < ness> gtg
19:06 -!- ness [n=ness@212.80.253.90] has quit [Remote closed the connection]
19:08 < marcheu> it's interesting that he has 1740 in his dump
19:14  * marcheu makes a mental note to document vertex attribs on nv30
19:26 -!- shavengerAway is now known as shavenger
19:49 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:02 -!- EdB [n=EdB@ARennes-251-1-15-162.w83-195.abo.wanadoo.fr] has joined #nouveau
20:09 -!- EdB [n=EdB@ARennes-251-1-15-162.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
22:12 -!- shavenger is now known as __sha__
22:27 -!- ness [n=ness@212.80.253.90] has joined #nouveau
23:19 -!- pmdata [i=patrice@ANantes-154-1-85-61.w81-48.abo.wanadoo.fr] has joined #nouveau
23:52 -!- __sha__ is now known as shavenger
23:54 -!- ness [n=ness@212.80.253.90] has quit [Remote closed the connection]
23:58 -!- shavenger is now known as shavengerAway
--- Log closed Втр Июл 04 00:00:42 2006
