--- Log opened Срд Июл 19 00:00:54 2006
00:18 < pmdata> I created a page on wiki for object types: http://nouveau.freedesktop.org/wiki/NvObjectTypes
00:19 < pmdata> It needs a description for what each object is used for (I don't know all of them)
00:19 < pmdata> And a chip where this object is present/used
00:42 < pmdata> is someone there?
00:42 < marcheu> not that I know of
00:42 < marcheu> I think chip support is already in objects.c
00:43 < marcheu> but yeah, what it's used for is useful
00:43 -!- EdB [n=EdB@ARennes-251-1-22-42.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
01:16 < pmdata> are the nv20 and nv30 tcl engine (using same object type number) really different?
01:16 < marcheu> well, yes
01:16 < marcheu> nv20 still has fixed function stuff
01:16 < marcheu> nv30 doesn't
01:17 -!- _Demo_ [n=Demo@modemcable206.154-131-66.mc.videotron.ca] has joined #nouveau
01:25 < pmdata> does nv20 still have register combiners or is it all shader stuff from there?
01:25 < marcheu> I think it's using the shader stuff, I'm not sur I remember correctly
01:26 < marcheu> we don't have nv20 shader stuff documented anyway
01:26 < marcheu> but nv30+ has prescaling which make it possible to match register combiners IIRC
01:26 < marcheu> without having to issue an extra mul instruction, that is
01:28 < pmdata> you should find it easily using the test_nv_register_combiners on nv20
01:28 < marcheu> yeah, I'm even using the nv28 right now
01:30 < marcheu> the issue is, we don't know where the texture_shader stuff is on nv20
01:31 < pmdata> that's why I think testing for rc would be useful, or does it trigger so many unknown commands?
01:32 < marcheu> yeah, a couple :)
01:36 < pmdata> can you make me a dump?
01:36 < marcheu> one sec
01:37 < marcheu> I'm wiping a texture_shader quick test to see if the same offsets are touched
01:37 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/nv28_rc.txt
01:39 < pmdata> ah, 8 max register combiners
01:40 < marcheu> yeah, stuff looks similar to texture_shader
01:40 < marcheu> so it's probably reusing functionality from that extension
01:40 < pmdata> 1b0c command is triggers 9 times
01:41 < marcheu> yes. and ?
01:41 < pmdata> 1 for default context, then 8 for each combiner
01:42 < pmdata> see the ac0 command
01:42 < pmdata> maybe this is were the combiner is selected
01:42 < pmdata> top 3 bits
01:42 < marcheu> yeah, sam ac0
01:42 < marcheu> so there's a default context ?
01:42 < marcheu> s/sam/saw
01:42 < pmdata> I mean, there are always default values when setting up the opengl context
01:43 < marcheu> ah right, there's one "tri" befure the 8 combiners
01:43 < pmdata> you must read the opengl spec, for example for nv_register_combiners, default values are always printed
01:43 < marcheu> I just looked at the code
01:43 < pmdata> yep
01:44 < pmdata> hum, if you did not change my code, we always set the output combiner 0
01:44 < marcheu> I didn't
01:44 < marcheu> ah, so that's not even the combiners but the inputs
01:44 < pmdata> try using GL_COMBINER<n>_NV, with n from 1 to 7, and make a dump for each
01:45 < pmdata> there are input combiners, output combiners and final combiner
01:45 < marcheu> yeah, I know. I programmed nv_texture_shader and it's similrarly braindead
01:46 < pmdata> ah, the only parameter that change is the input_param[], so command ac0 holds it
01:47 < pmdata> no, input_mapping[]
01:48 < pmdata> and this is for the input combiner 0
01:48 < pmdata> (I was confused cause I made some tests with rc, and was different from cvs)
01:49 < pmdata> instead of changing the combiner number, you can try changing the combiner variable GL_VARIABLE_<l>_NV to B,C,D
01:49 < pmdata> input and output combiners have 4 variables
01:49 < pmdata> final combiner has 7
01:50 < pmdata> could you make me a new dump with one parameter changed?
01:50 < marcheu> ok
01:52 < pmdata> something tells me 0ac0 is same format as nv10 RC_C0_IN_P[A|R]
01:53 < marcheu> hmm, what do you want changed ?
01:54 < pmdata> GL_VARIABLE, set it to B
01:54 < marcheu> I'll loop over from A to j'ai
01:54 < marcheu> if you don't mind
01:54 < pmdata> A to D will suffice
01:55 < pmdata> is there anyone else with a nv2x card?
01:55 < marcheu> edb I think
01:55 < marcheu> ddl has one but it's like 10000km away from him
01:56 < marcheu> so.. only me, sorry :)
01:58 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/nv28_rc2.txt should be ti
01:58 < marcheu> s/ti/it
02:00 < pmdata> ok ac0 is same as RC_C0_IN_PR
02:00 < marcheu> well, register combiners & texture_shader have some similarities
02:02 < pmdata> 260 is same as nv10 260
02:02 < marcheu> ah, cool
02:03 < pmdata> aa0 seems to be RC_C0_OUT
02:03 < marcheu> we have to get people to give hw to nouveau, and get you a nv20
02:04 < pmdata> a60 and a80 could be the rc constant color, but it's just a guess
02:04 < pmdata> I don't know if my motherboard could support it
02:04 < pmdata> I may try to find one
02:05 < marcheu> why wouldn't it ?
02:05 < pmdata> 0288 is the final combiner
02:05 < marcheu> til then if you need some tests, just ask me
02:06 < pmdata> hum, it seems they are the same as for nv10
02:06 < marcheu> I think I'll take some vacation to push nouveau forward a bit
02:06 < marcheu> it is probably very similar, at least the opengl extension design is the same
02:06 < pmdata> try copy/pasting the nv10 objects for register combiners to the nv20 tcl
02:06 < pmdata> I must go to sleep
02:06 < pmdata> I think the output should be ok
02:06 < marcheu> yeah, I should as well
02:07 < marcheu> but I'll test that stuff first I guess :)
02:07 < pmdata> http://oss.sgi.com/projects/ogl-sample/registry/NV/register_combiners.txt read that for the default values
02:07 < pmdata> happy code
02:07 -!- pmdata [i=patrice@ANantes-154-1-83-70.w81-48.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:08 < darktama> so.. speaking of moving forward.. is it possible to come up with some hack to get the Mesa driver to create the context with nvidia's libGL, and then take over the FIFO? I can do it in a test app
02:09 < marcheu> I thought about it...
02:09 < marcheu> it's possible, I'm not sure it's worth it
02:09 < marcheu> since we will probably have a different setup
02:10 < marcheu> and really, once the setup is done, it's the easy part...
02:10 < darktama> yeah, I've been trying to convince the ddx to draw a quad for a couple of days.. even copying the nvidia command stream (with offsets etc modified) doesn't give me any output
02:11 < darktama> so, I thought if we did a quick hack we could work on parts of the 3D driver still until someone figures out the setup
02:11 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:12 < _Demo_> setup is evil
02:12 < marcheu> yeah, but my fear is that a different setup might lead to significant differences in the fifo commands
02:12 < _Demo_> I've been trying to do it on nv2a without luck
02:13 < marcheu> _Demo_: the ddx for xbox works fine there IIRC, so you might just need a copy & paste from it
02:13 < _Demo_> where can I find that?
02:14 < darktama> hm, I don't think the FIFO commands would be too different.. but it's possible
02:14 < marcheu> _Demo_: http://xbox-linux.cvs.sourceforge.net/xbox-linux/xf86-video-nvxbox/
02:15 < marcheu> _Demo_: there's a couple of changes in there, but not too manu IIRC
02:15 < marcheu> darktama: yeah, but I suspect the "glue" code would be too much work
02:15 < _Demo_> interesting, who worked on the xbox version?
02:15 < marcheu> darktama: so what did you try with the ddx that failed ?
02:15 < marcheu> _Demo_: no
02:15 < marcheu> _Demo_: the xbox guys I think
02:16 < marcheu> ermm the xbox linux guys
02:16 < _Demo_> I'll need to look at that, thanks
02:16 < darktama> basically, create a object with class 0x4097.. then replace the EXASolid funcs with one that'd just draw a red quad using the 3D engine
02:17 < marcheu> was the 3d engine up ?
02:17 < marcheu> in the PMC bits ?
02:17 < marcheu> NV_PMC_ENABLE
02:18 < darktama> hm, the FIFO was proccessing the commands so I assume so.. doesn't the ddx enable all the engine components?
02:18 < marcheu> hmm, I don't remember
02:19 < marcheu> yeah it does
02:19 < marcheu> pNv->PMC[0x0200/4] = 0xFFFFFFFF;
02:19 < marcheu> violently
02:21 < marcheu> did you setup the pitch/offset stuff ?
02:21 < marcheu> do we even know where it is on nv40 ?
02:21 < darktama> well, that's where I think the problem is.. I'm not certain at all about any of that.. but yes, I *think* I know where they are
02:22 < marcheu> ah, nice
02:22 < marcheu> so where are those ?
02:23 < darktama> 0x200-0x300, but I'm not too certain about the exact function of them yet.. a lot of width/height/offset vals are duplicated in that area
02:23 < marcheu> remember I can do some nv40/nv44/g70 testing if needed
02:24 < marcheu> yeah, that could be because it needs color/depth info
02:24 < marcheu> and also maybe other buffers
02:24 < darktama> yup, 0x208 seems to be the format.. actually, one sec
02:26 < darktama> http://rafb.net/paste/results/7zieEv88.html << my very incomplete notes :)
02:27 < marcheu> maybe it will not be the same with supersampling
02:27 < marcheu> since supersmapling needs a bigger color buffer than depth buffer
02:27 < marcheu> so that might tell us which is what
02:32 < marcheu> (not sure if I made myself clear, I was talking about the pitches here)
02:35 < darktama> yup, well the setup definitely changes a lot with __GL_FSAA_MODE=6.. taking a look at the results now
03:01 < darktama> hmm, looks like it renders into larger buffer.. then sets up a texture (1152x2048), points to the destination drawable, then renders the texture into it
03:01 < marcheu> yes
03:01 < darktama> but, it's not using 0x1818 between BEGIN/END which is odd
03:01 < marcheu> but the depth buffer pitch should stay the same
03:02 < marcheu> we are chasing the pitch here, right ?
03:03 < darktama> yes, just thought I'd point that out.. I haven't noticed any vals that could be the pitch staying the same.. I'll make sure I actually have a depth buffer..
03:03 < marcheu> hmm maybe it uses a bigger zbuffer as well
03:03 < darktama> I had SDL_GL_DEPTH_SIZE=0 :S
03:05 < marcheu> yeah, I still think it uses a bigger zbuffer
03:06 < darktama> yeah, it is looking that way
03:07 < darktama> but, at least with a depth buffer 0x214 contains a different offset val than the others
03:22 -!- `Duke` [n=gnu@ANantes-251-1-142-247.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
04:34 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
05:05 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
05:39 -!- xaid [n=Xaid@d199-126-153-40.abhsia.telus.net] has joined #nouveau
06:02 < ddl> hey!
06:18 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has quit ["Au revoir."]
06:42 -!- _Demo_ [n=Demo@modemcable206.154-131-66.mc.videotron.ca] has quit ["Leaving"]
06:58 -!- bluesterror [i=bob@ip68-98-189-153.dc.dc.cox.net] has joined #nouveau
07:16 -!- bluesterror [i=bob@ip68-98-189-153.dc.dc.cox.net] has quit ["."]
08:32 -!- Aexoden [n=Aexoden@207-118-66-169.dyn.centurytel.net] has quit ["Leaving"]
08:59 -!- Aexoden [n=Aexoden@207-118-66-169.dyn.centurytel.net] has joined #nouveau
10:26 -!- darktama_ [n=darktama@124-168-238-39.dyn.iinet.net.au] has joined #nouveau
10:29 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Nick collision from services.]
10:29 -!- darktama_ is now known as darktama
10:29 -!- Aexoden [n=Aexoden@207-118-66-169.dyn.centurytel.net] has quit ["Leaving"]
10:36 -!- Aexoden [n=Aexoden@207-118-66-169.dyn.centurytel.net] has joined #nouveau
10:54 -!- xaid [n=Xaid@d199-126-153-40.abhsia.telus.net] has quit ["leaving"]
11:39 -!- EdB [n=EdB@ARennes-251-1-28-65.w81-250.abo.wanadoo.fr] has joined #nouveau
11:47 -!- EdB [n=EdB@ARennes-251-1-28-65.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
11:47 -!- EdB [n=EdB@ARennes-251-1-28-65.w81-250.abo.wanadoo.fr] has joined #nouveau
12:00 -!- Unavowed [n=silent@host81-151-26-23.range81-151.btcentralplus.com] has joined #nouveau
12:37 -!- EdB_ [n=EdB@ARennes-251-1-28-65.w81-250.abo.wanadoo.fr] has joined #nouveau
12:37 -!- EdB [n=EdB@ARennes-251-1-28-65.w81-250.abo.wanadoo.fr] has quit [Read error: 104 (Connection reset by peer)]
12:54 -!- Duke` [n=gnu@ANantes-251-1-142-247.w86-210.abo.wanadoo.fr] has joined #nouveau
13:22 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
13:26 -!- Duke` [n=gnu@ANantes-251-1-142-247.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
13:30 -!- Duke` [n=gnu@ANantes-251-1-142-247.w86-210.abo.wanadoo.fr] has joined #nouveau
14:08 -!- EdB_ [n=EdB@ARennes-251-1-28-65.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
14:27 -!- EdB [n=EdB@ARennes-251-1-28-65.w81-250.abo.wanadoo.fr] has joined #nouveau
15:43 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
15:43 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
15:43 -!- Topic set by marcheu [] [Fri Jul 14 19:33:43 2006]
15:43 [Users #nouveau]
15:43 [@ChanServ] [ airlied ] [ ddl  ] [ lumag_offline] [ Unavowed] 
15:43 [ Aexoden ] [ blx     ] [ Duke`] [ marcheu      ] 
15:43 [ ag      ] [ darktama] [ hiyuh] [ qfire_away   ] 
15:43 -!- Irssi: #nouveau: Total of 13 nicks [1 ops, 0 halfops, 0 voices, 12 normal]
15:43 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
15:43 -!- [freenode-info] if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
15:43 -!- Irssi: Join to #nouveau was synced in 1 secs
16:17 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:36 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
17:50 -!- Duke` [n=gnu@ANantes-251-1-142-247.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
18:14 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has joined #nouveau
18:29 -!- Unavowed [n=silent@host81-151-26-23.range81-151.btcentralplus.com] has quit [Remote closed the connection]
19:41 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has quit [Read error: 104 (Connection reset by peer)]
19:44 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has joined #nouveau
19:48 -!- lumag_offline [n=mitya@chimpanzee.school.ioffe.ru] has joined #nouveau
19:48 -!- Topic for #nouveau: http://nouveau.freedesktop.org | open source 3D acceleration for nvidia cards | http://perso.orange.fr/patrice.mandin/images/nv-kitten.jpg
19:48 -!- Topic set by marcheu [] [Fri Jul 14 19:33:43 2006]
19:48 [Users #nouveau]
19:48 [@ChanServ] [ airlied ] [ ddl          ] [ marcheu   ] [ stringfellow] 
19:48 [ Aexoden ] [ blx     ] [ EdB|w        ] [ philv     ] 
19:48 [ ag      ] [ darktama] [ lumag_offline] [ qfire_away] 
19:48 -!- Irssi: #nouveau: Total of 13 nicks [1 ops, 0 halfops, 0 voices, 12 normal]
19:48 -!- Channel #nouveau created Sun Jun 25 07:52:56 2006
19:48 -!- Irssi: Join to #nouveau was synced in 27 secs
19:53 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has joined #nouveau
20:34 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
20:47 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
20:57 -!- pmdata [i=patrice@ANantes-154-1-48-21.w81-53.abo.wanadoo.fr] has joined #nouveau
20:57 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
20:59 -!- Duke` [n=gnu@ANantes-251-1-97-247.w86-203.abo.wanadoo.fr] has joined #nouveau
20:59 < pmdata> hello
21:10 < pmdata> anyone with a nv20 or should I wait for marcheu?
21:13 < EdB|w_> pmdata, i'm not at home soory
21:36 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has joined #nouveau
21:48 -!- pmdata is now known as pm_miam
21:50 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has quit ["Au revoir."]
22:15 -!- pm_miam is now known as pmdata
22:45 -!- xaid|work [n=zaid@d150-132-196.home.cgocable.net] has joined #nouveau
23:03 < pmdata> when using multitexture, does each texture get its own texture matrix?
23:03 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
23:06 < pmdata> ah, answer is yes, then this is maybe command 400
23:18 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
23:18 < Lumag> hi all
23:18 < Lumag> Now I lack arrays in objects.c too: 1792-field array in NV5_IMAGE_FROM_CPU :(
23:19 < Lumag> Also there is something strange with IMAGE_FROM_CPU. nvGLX passes type=065, but the hardware gets type=0x61 (the generic image_from_cpu), but the object works like 0x065.
23:20 < Lumag> BTW: Does anybody know, what FOH and ZOH mean? 
23:34 < pmdata> hi lumag
23:34 < pmdata> foh/zoh: where?
23:36 < Lumag> triangles setup. Still examining old docs :)
23:36 < Lumag> origin_foh_center, origin_foh_corner, etc.
23:36 < philv> Which docs?
23:39 < Lumag> nv4ref.h/nvxref.h
23:42 < pmdata> lumag> I have this:
23:42 < pmdata> map 6	from 0x41f37000 to 0x41f5f000 size 0x28000 (physical 0xdbfa4000)	=> registers
23:42 < pmdata> NV10_TCL_PRIMITIVE_3D      [0x0214/4] = 0.000000 | UNKNOWN = 03fa4000
23:42 < pmdata> I think 214 is the offset to color buffer in video ram
23:45 < Lumag> it seems so.
23:46 < pmdata> this is the only remaining unknown command with such a value being an address or an offset in mem
23:46 < pmdata> what would be a good name? buffer_address, buffer_offset, buffer_ptr ?
23:46 < Lumag> COLOR_OFFSET
23:47 < Lumag> NV04_CONTEXT_SURFACES_3D_OFFSET_COLOR
23:47 < Lumag> --- that's what I have for nv04 :)
23:47 < pmdata> does the zbuffer should be an offset from this one, or its own offset?
23:48 < Lumag> For me Z-buffer is totally separate.
23:48 < Lumag> I mean in terms of offsets :)
23:49 < pmdata> yep, so there must be a command that set it
23:54 < Lumag> pmdata: could you please provide the decoded dump of the whole FIFO (from the beginning of it).
23:55 < pmdata> ah, sdl_gl_swapbuffers() is done using raster copy
23:55 < Lumag> and what about glutSwapBuffers() ?
23:57 < pmdata> they both use glx to swap buffers, glx which in turn calls glfinish or glflush
23:59 < pmdata> http://pmandin.atari.org/download/nv10_draw_pixels.txt
--- Log closed Чтв Июл 20 00:00:54 2006