--- Log opened Срд Июн 14 00:00:27 2006
00:02 < pmdata> at last, there is no more confusion between commands like I saw 2 days ago (i.e. same command for polygon stipple and clip planes)
00:05 < Lumag> Hmm... I saw you defined 'unk' offsets. You can simply ommit them and still have resonable output (at least I hope so).
00:05 < pmdata> yep, I put them because I think they are unknown commands
00:07 < Lumag> They are, but thay are /unknown/. Imho it's not resonable to define something unknown :)
00:08 < pmdata> I think it could help to have them listed, so we could find them from the previous/next ones that are known
00:10 < pmdata> for example 318 and 328 are surely some ENABLE_STUFF
00:11 -!- Duke` [n=gnu@ANantes-251-1-104-109.w86-203.abo.wanadoo.fr] has quit [Connection timed out]
00:11 < Lumag> Hmm... Maybe. I just thought about big 'reserved' blobs in nv03/04 objects. It seems to be a good idea to document them.
00:21 < Lumag> pmdata: BTW: by that '16 fp32 variables' you meant 0x61:0x0400?
00:23 < pmdata> 0x0061:0x0400 has a variable length (drawing horizontal line), a better example is 0x0056:0x0500 (load matrix)
00:25 < Lumag> ok... I'll think about it.
00:26 < Lumag> WTF??? beef6101 creation gets 0x65 argument, but registers itself as a 0x61 object...
00:27  * Lumag tries to keep himself from disassembling nv-kernel.o :(
00:32 < Lumag> I wander whether nv-glx knows that it's fooled by nv-kernel or not.
00:35  * pmdata can not help you :)
01:25 -!- pmdata [i=patrice@ANantes-154-1-91-252.w86-210.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:30 -!- jkolb [n=jkolb@130.57.22.69] has quit ["Leaving"]
01:52 -!- `Duke` [n=gnu@ANantes-251-1-135-15.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:03 -!- EdB_ [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
02:16 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
02:21 < marcheu> hmm, the object ioctl doesn't work here
02:21 < marcheu> I hope to have time to look into it tomorrow, for now I have to sleep
02:21 -!- hub [n=hub@storm-gw.xandros.com] has quit [Read error: 110 (Connection timed out)]
02:28 < Lumag> strange...
02:29 < marcheu> well, I can put up a log, but I don't have time for more right now
02:31 < marcheu> http://icps.u-strasbg.fr/~marchesin/log.txt
02:35 < Lumag> Will look now.
02:35 < Lumag> night!
02:35 < Lumag> BTW: what driver version do you have?
02:36 < marcheu> looks like it's jjust a mask
02:36 < marcheu> 8762
02:37 < marcheu> I get 4497 instead of 97, and so on...
02:39 < Lumag> Hmm... but RAMIN will contain 4497, not 97
02:40 < marcheu> yes, but the object type is 97
02:40 < Lumag> Why are you so shure?
02:40 < Lumag> s/shure/sure
02:40 < marcheu> because the object for 3D is 97 :)
02:41 < marcheu> I'm 100 sure about that, I've tested it numerous times
02:41 < marcheu> and found the same result with different methos
02:41 < Lumag> ok. Then results shoud be masked with 0xff :)
02:41 < marcheu> yes
02:42 < marcheu> I'll let you fix that
02:42 < marcheu> I really have to sleep
02:42 < Lumag> :)
02:45 < Lumag> fixed.
02:52 < Lumag> have to sleep too...
02:53 < Lumag> night all!
02:53 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
03:09 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
10:11 -!- kombrisn [n=kombrisn@dslb-084-056-155-067.pools.arcor-ip.net] has joined #nouveau
10:24 -!- katakombi [n=kombrisn@dslb-084-056-156-058.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
10:31 -!- Duke` [n=gnu@ANantes-251-1-135-15.w86-210.abo.wanadoo.fr] has joined #nouveau
11:01 -!- EdB [n=EdB@ARennes-251-1-27-17.w81-250.abo.wanadoo.fr] has joined #nouveau
11:24 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
11:35 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
11:51 < marcheu> darktama: so renouveau works again for you now ?
12:03 < darktama> yes, with the ioctl code
12:04 < darktama> I should still find out why it doesn't work by parsing RAMIN also.. it could be important
12:04 -!- EdB [n=EdB@ARennes-251-1-27-17.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
12:04 -!- EdB [n=EdB@ARennes-251-1-27-17.w81-250.abo.wanadoo.fr] has joined #nouveau
12:04 < marcheu> yes, we'll need to understand why ramin is different for you
12:04 < marcheu> and how it works
12:04 < marcheu> unless it just works if we do the same as nv_dma.c, that is
12:05 < darktama> well, EXA works.. so I assume it can also work the usual way
12:05 < marcheu> I hope so
12:06 < darktama> I made a start on porting the shader code to the new layout, but it's quite awkward having to printf into a buffer
12:06 < darktama> I'll finish it off soon, got distracted by e17 and conky
12:23 < darktama> btw, you mentioned that nv30 vtxprogs were different than nv40.. how different?
12:24 < marcheu> there are other instructions
12:24 < marcheu> if you look at the opcodes, there's a hole in the table right now
12:24 < darktama> the layout of the instructions are the same though?
12:24 < marcheu> it looks like it, yes
12:25 < marcheu> I'm not at work now so I can't tell for sure
12:25 < marcheu> but you see, there are 2 kind of VP insts
12:25 < darktama> ok, I'll leave all the defines as NV40_* for now
12:26 < darktama> the scalar ones, and the vector ones?
12:26 < marcheu> the ones that end with 0 (starting at 0x40) and the other ones
12:26 < marcheu> IIRC the NV30 insts sit in between
12:26 < darktama> ahh
12:27 < darktama> yeah, I'm fairly certain I'm missing something important about the opcode IDs
12:28 < darktama> the way the vector ops and scalar/branching ops are numbered currently seems to suggest they're two separate fields
12:29 < marcheu> well, I think the scalar/branching ops are simply not supported on nv30
12:29 < marcheu> so that's just that they use a new nv40-specific encoding
12:30 < darktama> hmm, I'd think the scalar ones should be.. a lot of them are required by both early DX shaders, and ARB_v_p
12:30 < marcheu> or... "format"
12:31 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/nv30_alltests.txt
12:31 < marcheu> it's a full log of renouveau tests on nv30
12:32 < marcheu> it's all I have for now
12:32 < marcheu> it has the unfinished prog issue so it's quite big
12:32 < darktama> ah, thanks
12:33 < darktama> hmm, that's interesting
12:33 < darktama> 124e   0x00000000   0x000428e4   {size: 0x1   channel: 0x1   cmd: NV30_FP_ACTIVE_PROGRAM}
12:33 < darktama> 124f   0x00000000   0x07c71f41
12:33 < darktama>  -- found program upload
12:33 < darktama>  -- program at 0x0xb6b35020 - 114020
12:33 < darktama> 	0x00000001: 	END
12:34 < marcheu> yup, there's a couple empty programs. I don't think that's the program terminators we need though
12:35 < marcheu> if you look at the offset is always aligned
12:35 < marcheu> s/is/it is/
12:37 < marcheu> hmm, or maybe it is
12:37 < marcheu> anyway I have to go
12:37 < darktama> catch ya
13:01 -!- kombrisn is now known as katakombi
15:05 -!- EdB [n=EdB@ARennes-251-1-27-17.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:04 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:37 -!- Myrizio [n=Myrizio@Linuz.sns.it] has joined #nouveau
17:47 -!- Myrizio [n=Myrizio@Linuz.sns.it] has quit ["I like core dumps"]
18:23 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
19:07 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
19:10 -!- jkolb [n=jkolb@130.57.22.69] has joined #nouveau
19:24 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
19:34 -!- EdB|l [n=EdB@212.234.68.206] has joined #nouveau
19:39 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
19:40 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
19:45 -!- EdB|w is now known as EdB
19:46 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
19:48 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:03 -!- EdB|l [n=EdB@212.234.68.206] has quit [Connection timed out]
20:13 -!- EdB [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
20:25 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
20:26 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
21:00 -!- pmdata [i=patrice@ANantes-154-1-39-201.w81-53.abo.wanadoo.fr] has joined #nouveau
21:00 < pmdata> lo
21:06 < pmdata> I just read on http://rivatv.sourceforge.net/stuff/riva128.txt that object types 42,43,44 are known (at least for riva128)
21:06 < pmdata> however I added them to renouveau as unknown for nv1x, I don't know what to do to check if they are the same or not as riva128
21:09 < pmdata> would it be possible to make a patch for some video player (xine lib, mplayer, etc...), to check if XVideo stuff uses gpu or not (zoom, colorspace, idct, mc)?
21:11 < marcheu> AFAIK nvidia never re-used objects
21:13 < marcheu> pmdata: is 44 available on riva128
21:14 < pmdata> ah, but as 42,43,44 are used for gldrawpixels, and they are resp: raster op, color key, plane then maybe they are the same
21:14 < marcheu> yes, but I though those were nv04-only
21:15 < marcheu> are you sure they work on riva128 ?
21:15 < pmdata> I don't know, they are listed in riva128.txt
21:21 < marcheu> according to the nvidia docs, 43 is NV03_CONTEXT_ROP, 42 and 44 are not available on nv03
21:21 < marcheu> see nvhw32.h
21:23 < marcheu> hmm riva128.txt says 0x57 is textured triangle, nvhw32.h says 0x48 is
21:25 < marcheu> what is the object for nv10 triangles ? 0x94 ?
21:25 < marcheu> hmm 61
21:26 < marcheu> ermm 56 but it's still not matching
21:27 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
21:27 < pmdata> 61 is for draw pixels, 2d stuff from what I think
21:27 < marcheu> yup
21:27 < marcheu> I wouldn't trust riva128.txt, but rather the header from nvidia
21:28 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
21:32 < pmdata> hm, I see what you mean, it will be hard to find what the object type is for each value/chip
21:33 < marcheu> why ?
21:33 < marcheu> it's actually easier for us
21:34 < marcheu> because if a given card features a given object, we can generalize all the object fields at once instead of checking them separately
21:34 < pmdata> ah, I did not see this way
21:52 < pmdata> just checked out cvs, it seems everything has changed, reading object type was previously buggy?
21:58 -!- `Duke` [n=gnu@ANantes-251-1-102-3.w86-203.abo.wanadoo.fr] has joined #nouveau
22:11 -!- Duke` [n=gnu@ANantes-251-1-135-15.w86-210.abo.wanadoo.fr] has quit [Connection timed out]
22:12 -!- `Duke` is now known as Duke`
22:17 -!- svu [n=svu@194.46.163.190] has quit [Read error: 113 (No route to host)]
22:18 -!- svu [n=svu@host-194-46-249-196.dsl-ie.utvinternet.net] has joined #nouveau
23:00 -!- EdB|w [n=EdB@212.234.68.206] has quit ["Parti"]
--- Log closed Чтв Июн 15 00:00:27 2006
