--- Log opened Втр Июн 13 00:00:26 2006
00:07 -!- pmdata [i=patrice@ANantes-154-1-35-125.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
00:15 < marcheu> Lumag: what lack of versioning ?
00:17 < Lumag> pNv->EXADriverPtr->exa_major, pNv->EXADriverPtr->exa_minor should be filled.
00:18 < marcheu> ah, that one
00:18 < marcheu> was that a showstopper for you ?
00:19 < Lumag> no. Just a few seconds of find&edit&recompile :)
00:19 < marcheu> ah well, it wasn't for me, but yes go ahead and commit that
00:23 < Lumag> Commited.
00:23 < Lumag> BTW: I encountered another problem with the driver. NVInitDma tries to load dri module. And so I have 'NV: Failed to load module "dri" (already loaded, 0)' in logs.
00:24 < Lumag> And so drm isn't used.
00:24 < marcheu> did you compile/install the drm module ?
00:24 < Lumag> Yes.
00:24 < marcheu> hmm, again, this works here
00:25 < marcheu> anyway the driver can operate without dri as well
00:25 < marcheu> (for now)
00:26 < marcheu> and did exa work on your card ?
00:26 < Lumag> How should I check that?
00:26 < marcheu> well, just enable EXA in the xorg.fonc
00:26 < marcheu> xorg.conf
00:26 < marcheu> and it should display everything "just as usual"
00:27 < marcheu> albeit probably slower
00:27 < Lumag> In that manner, it worked. But I also have 'EXA(0): No offscreen pixmaps' in log. Is it normal?
00:27 < marcheu> hmm no
00:27 < marcheu> it doesn't help testing it
00:54 -!- EdB [n=EdB@ARennes-251-1-42-245.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
00:58 -!- pmdata [i=patrice@81.53.174.125] has joined #nouveau
01:03 < marcheu> pmdata: littlesniper was working on nv10 texturing, I don't know how far he went though
01:03 < Lumag> marcheu: if you don't object, I'll commit my changes to renoveau.
01:05 < marcheu> ok, just let me test it
01:07 < marcheu> looks good (RAMIN works here). how hard will it be to fix the frag prog disasm ?
01:10 < marcheu> there's just one thing, I'm not sure if it's worth keeping a separate objects.c/nv_objects.h structure
01:10 < marcheu> we could as well do everything in objects.c
01:11 < marcheu> and have a function genereate the header with this array later on
01:11 < pmdata> marcheu> I tried to look at the test_tex() function and outputted commands, but could not find something
01:12 < marcheu> pmdata: IIRC littlesniper said that the texture data was put in the DMA area and sent using a DMA
01:13 < Lumag> marcheu: I think it's only a matter of finding type+offset representations of MEMFORMAT_OFFSET_IN and NV30_FP_ACTIVE_PROGRAM
01:14 < pmdata> yes, it is not send via a command, but what I'm interested in, is how the texture parameters are sent (size, format, filtering, etc...)
01:14 < marcheu> Lumag: ok, go ahead then. we'll port commands then. it won't take much time I think
01:15 < marcheu> pmdata: I think you have to trigger the upload for the parameters to have an effect. i.e. call glTexImage2D
01:16 < Lumag> commited
01:18 < marcheu> cool. I think having the object system in place will help working faster
01:19 < marcheu> since when we know a field for a given object, we can generalize it to all the cards supporting this object
01:20 < marcheu> although we should add a field for each object saying precisely which cards are supported
01:21 < pmdata> I saw something strange: polygon stipple is defined using same commands as clip planes on nv10, would lumag changes take care of something like this?
01:22 < Lumag> pmdata: yes.
01:22 < pmdata> ah nice
01:23 < marcheu> Lumag: yeah, I'll add a field to object_store right now. we really need to keed the card information
01:23 < Lumag> marcheu: Well... probably that would be mostly useful for writing the driver afterwards. the renv should work w/o that field :)
01:23 < marcheu> yes, it's definitely useful for writing the driver
01:23 < marcheu> we've been discussing this previously already, and concluded we needed to know precisely what objects use on what cards
01:24 < marcheu> because the cards might not support it, or because some objects might be buggy (yup, happens with some nv03 objects for example)
01:24 < Lumag> yes, yes...
01:24 < Lumag> I missed that issue.
01:35 < marcheu> ok, I can't resist porting commands :)
01:39 < marcheu> hmm, naming objects requires inspiration...
01:39 < Lumag> :)
01:39 < marcheu> yay, or having the name already available :)
01:40 < Lumag> That's why I based my example on dx5TexTri ;)
01:40 < Lumag> BTW: You can name objects later, when all functionality is known
01:42 < Lumag> Just pust some dummy name like NvType00xx there
01:44 < marcheu> hmm, nv30 uses object 97 already
01:44 < marcheu> I wonder what all the objects do...
01:45 < marcheu> Lumag: btw I wouldn't worry too much about nv03 support in renouveau, since nv03 doesn't have proprietary linux drivers
01:46 < Lumag> Yup. I did that simply for 'documentation'. You can remove that.
01:47 < marcheu> I'll let it in, maybe I'll add the nv03 types at some point (by copying from the documentation directly)
01:48 < Lumag> and NV03 in nv_hw.c, objects.c is probably necessary to document objects.
01:48 < Lumag> yup.
01:49 < Lumag> btw: it seems strange, that nVidia didn't support nv03 in their glx drivers. I don't think that the difference between nv03 and nv04 is really that big.
01:50 < marcheu> it's not too big, but nv03 has numerous hw bugs that make it complicated to program
01:50 < marcheu> nv04 only has a few hw bugs, and nv05 has none that I know opf
01:52 -!- pmdata [i=patrice@81.53.174.125] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:53 < Lumag> oh... then it makes some sense.
02:09 -!- Duke` [n=gnu@ANantes-251-1-92-251.w86-203.abo.wanadoo.fr] has quit [Connection timed out]
02:10 -!- Duke` [n=gnu@ANantes-251-1-104-109.w86-203.abo.wanadoo.fr] has joined #nouveau
02:11 < Lumag> marcheu: could you please commit your changes object_store today?
02:12 < marcheu> Lumag: you mean adding the card type ?
02:12 < Lumag> yes
02:12 < marcheu> ok, after I'm dont with the nv30 triangle in ~30 min I think
02:12 < marcheu> s/dont/done/
02:12 < marcheu> is that ok ?
02:30 -!- Duke` [n=gnu@ANantes-251-1-104-109.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:32 < Lumag> yes, perfectly. Just don't want to work on 'flying' code too ;)
02:41 < marcheu> hmm, I'll probably need the gl data interpreter as well
02:45 < Lumag> What do you mean by it?
02:45 < Lumag> what do you want to be interpreted?
02:45 < marcheu> the GL_AND
02:45 < marcheu> for example
02:46 < marcheu> there are like 30 lines of that in cmds.c
02:48 < Lumag> There is a data_store left in objects.c. So you can create a simple print_func that will search the value in provided data_store array (passed via generic pointer).
02:54 < marcheu> hmm, do you have a sample output ?
02:54 < marcheu> from your renouveau ?
02:54 < marcheu> it doesn't look right here
02:55 < marcheu> it prints the object type and not the field type
02:57 < Lumag> http://lumag.spb.ru/nouveau/dumps/sample_renoveau
02:57 < marcheu> yours looks right
03:00 < Lumag> can you provide your dump?
03:01 < marcheu> http://icps.u-strasbg.fr/~marchesin/dump.txt
03:01 < marcheu> at the bottom
03:01 < marcheu> 6e6   0x00000000   0x00000005                           NV30_TCL_PRIMITIVE_3D = 0x5
03:01 < marcheu> I expected
03:01 < marcheu> 6e6   0x00000000   0x00000005                           NV30_TCL_PRIMITIVE_3D_BEGIN_END = 0x5
03:04 < Lumag> strange... can you post your objects.c ?
03:04 < Lumag> or maybe just commit it, so I can look?
03:04 < marcheu> well, I just added that :
03:04 < marcheu>         [NV30_TCL_PRIMITIVE_3D] = {__(NV30_TCL_PRIMITIVE_3D), NV30|NV40, {
03:04 < marcheu>                 {__(NV30_TCL_PRIMITIVE_3D_BEGIN_END),           {PRINT_X32,     {}} },
03:04 < marcheu>                 {__(NV30_TCL_PRIMITIVE_3D_CLEAR_VALUES),        {PRINT_X32,     {}} },
03:04 < marcheu>                 {__(NV30_TCL_PRIMITIVE_3D_ALPHA_FUNC),          {PRINT_X32,     {}} },
03:04 < marcheu>                 {}},
03:04 < marcheu> 
03:05 < marcheu> I think I'll write print_gl and then commit it
03:07 < Lumag> update from cvs please.
03:08 < marcheu> ok :)
03:10 < darktama> hmm, that's interesting
03:10 < darktama> marcheu: what card are you testing with?
03:10 < marcheu> darktama: nv44
03:11 < Lumag> marcheu: I don't think you need print_gl. A generic print_macro should be better :)
03:11 < marcheu> hmm
03:11 < marcheu> Lumag: what do you mean ?
03:12 < Lumag> I hope you don't write a function that simply prints GL_* values?
03:12 < darktama> :S I wonder why the instance ram code doesn't work for me then.. I'd have thought NV40 and NV44 would be similar
03:12 < marcheu> heh, I was going to :)
03:13 < Lumag> then wait five minutes please :)
03:13 < marcheu> you're writing something similar ?
03:14 < Lumag> yes, but generic one.
03:14 < marcheu> yup, was my plan as well :)
03:14 < marcheu> I wanted to handle the primitive types :)
03:14 < Lumag> oh. then do as you please.
03:15 < marcheu> well, if yours can handle primitives & GL_* , that's ok for me
03:15 < marcheu> I'll cut & paste as much NV30 commands as I can in between
03:15 < marcheu> darktama: it's really strange what you have with instance ram, yes
03:16 < darktama> I just tried compiling renouveau 32-bit to rule out 64-bit issues, and no change
03:16 < darktama> I'm gramming a RAMIN dump for Lumag (as I forgot to do yesterday)
03:16 < Lumag> marcheu: btw: I still don't know what to do with highest bits of FIFO writes.
03:16 < darktama> grabbing*
03:17 < Lumag> darktama: thanks.
03:17 < marcheu> darktama: maybe RAMIN is not readable on your card
03:17 < darktama> Lumag: where does RAMIN end? its 0x00700000->0x????????
03:17 < darktama> marcheu: the hash table seems fine though..
03:18 < Lumag> darktama: 0x007fffff
03:19 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:20 < darktama> http://members.iinet.net.au/~darktama/renouveau.dump.bz2
03:20 < marcheu> is there non-0 stuff in there ?
03:20 < darktama> yup
03:20 < marcheu> does it look like 8-byte objects ?
03:20 < Lumag> :q
03:20 < marcheu> hello vim users :)
03:21 < Lumag> :)
03:21  * darktama pets vim
03:21 < marcheu> alright, are we only vim users in there ?
03:21 < darktama> marcheu: honestly, I'm not sure :) there's a lot of data to look through
03:21 < marcheu> darktama: did you look at the reg header ? there's a number of PRAMIN config regs, your PRAMIN might be at a different place
03:22 < marcheu> wait, what's wrong ? RAMIN or RAMHT ?
03:22 < darktama> RAMIN, it appears to decode RAMHT fine
03:22 < marcheu> hmm, my theory only stood with RAMHT
03:23 < darktama> it's the same area isn't it?
03:23 < marcheu> RAMHT is "somewhere" inside RAMIN
03:23 < darktama> RAMHT is just an offset within RAMIN?
03:23 < darktama> beat me :)
03:23 < marcheu> see NV_PFIFO_RAMHT
03:24 < marcheu> darktama: did the brute force object dumper found anything ?
03:24 < darktama> the brute force is for the HT isn't it?
03:24 < marcheu> grrrr
03:25 < marcheu> it would be so easy if you have RAMHT troubles
03:25 < marcheu> s/have/had
03:25 < darktama> haha!
03:28 < Lumag> darktama: can you please recreate a dump till 0x008fffff ?
03:28 < darktama> sure
03:29 < Lumag> marcheu: print_macro is in the cvs. just use PRINT_MACRO(gl_datas)
03:30 < darktama> Lumag: uploaded, same url
03:30 < Lumag> thanks
03:38 < darktama> Lumag: you said that you originally got the number from an nvidia ioctl call?
03:38 < Lumag> yes.
03:39 < darktama> how did you do that? if I can find where it is in RAMIN, it'll be easier to work out how to find it properly
03:39 < Lumag> using mmtrace module from cvs
03:40 < marcheu> there's some kind of allocator I think
03:40 < Lumag> the type seems to be equal (in most cases) to (object_name >> 16) && 0xff. E.g. beef5401 is 0x54.
03:40 < darktama> ah, I forgot that was there.. I meant to play with it yesterday
03:42 -!- jkolb [n=jkolb@130.57.22.69] has quit [Remote closed the connection]
03:42 < marcheu> we should brute force it, I think
03:42 -!- jkolb [n=jkolb@209-6-112-224.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has joined #nouveau
03:43 < jkolb> that call to mmap in init_card bombs on my machine
03:43 < jkolb> invalid argument. but strace says INVALID_SEEK
03:43 < marcheu> jkolb: the one that brutally mapps all the regs ?
03:43 < darktama> Lumag: is there anything special I need to do to build it?
03:43 < jkolb> marcheu: yeah
03:44 < darktama> mt_main.c:418: error: expected declaration specifiers or '...' before 'SyscallArgs'
03:44 < marcheu> jkolb: too big mapping ?
03:44 < Lumag> darktama: did you apply patches from the patches/ subdir?
03:45 < darktama> to valgrind? or mmtrace?
03:45 < marcheu> jkolb: the size was determined empirically. btw you're sure it doesn't try to read all that area ? that would surely crash
03:45 < Lumag> To valgrind.
03:45 < Lumag> Also I don't think you need it.
03:45 < jkolb> marcheu: well, i'm confused because i can't find the ALL_REGS_SIZE being passed the mmap. looks like it's giving a different value
03:46 < marcheu> it's on top of the file, 0x1000000
03:46 < marcheu> what card is it again ?
03:46 < jkolb> marcheu: correct, but i don't see the value in strace's output
03:47 < jkolb> marcheu: nv35 i think. 5900 ultra i think
03:48 < marcheu> open("/dev/nvidia0", O_RDWR)            = 10
03:48 < marcheu> mmap2(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0xde000) = 0xa5acf000
03:48 < marcheu> you don't see something like that ?
03:49 < jkolb> open("/dev/nvidia0", O_RDWR)            = 10
03:49 < jkolb> dup(2)                                  = 11
03:49 < jkolb> fcntl64(11, F_GETFL)                    = 0x2 (flags O_RDWR)
03:49 < jkolb> fstat64(11, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
03:49 < jkolb> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6b09000
03:49 < jkolb> _llseek(11, 0, 0xbfae7f20, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
03:49 < jkolb> write(11, "mmap: Invalid argument\n", 23mmap: Invalid argument
03:49 < marcheu> hmmm, wrong phys address
03:49 < marcheu> ?
03:50 < jkolb> perhaps
03:50 < marcheu> what does cat /proc/bus/pci/devices |grep nvidia |head -1 say ?
03:50 < jkolb> 0000    10de01e0        0       d0000008        00000000        00000000       00000000 00000000        00000000        00000000        08000000        000000000000000 00000000        00000000        00000000        00000000        agpgart-nvidia
03:50 < marcheu> haha
03:51 < marcheu> what does cat /proc/bus/pci/devices |grep nvidia |tail -1 say ?
03:51 < marcheu> Lumag: anything agains reverting to the "tail" version ?
03:51 < darktama> lol, I knew that issue would come up eventually :)
03:51 < marcheu> or maybe we should use a better grep
03:51 < jkolb> 0200    10de0332        13      e0000000        d8000008        00000000       00000000 00000000        00000000        e1000002        01000000        080000000000000 00000000        00000000        00000000        00020000        nvidia
03:51 < marcheu> darktama: hack'n'slash job :)
03:51 < jkolb> excellent
03:51 < Lumag> we need a better grep.
03:51 < darktama> ehehe
03:52 < marcheu> Lumag: why did you change it btw ?
03:52 < Lumag> it tried to map the memory for my second card :)
03:52 < jkolb> changing to tail made my card happy
03:52 < Lumag> sorry :)
03:52 < marcheu> Lumag: well, I'm trying to figure out what's better
03:52 < jkolb> aw. output is greater than terminal width
03:53 < marcheu> in any case we need a better grep regexp
03:55 < Lumag> grep "[[:space:]]nvidia" | head -1 ?
03:55 < jkolb> marcheu: looks like you found the object stuff
03:56 < Lumag> or even grep "[[:space:]]nvidia$" | head -1
03:56 < marcheu> jkolb: nope, I got someone else to do it :D
03:56 < jkolb> haha who?
03:57 < marcheu> jkolb: well, I can't tell you, but his nick begins with "Lu" and ends with "mag"
03:58 < jkolb> Lumag: nice ;)
03:58 < Lumag> :)
04:07 < Lumag> darktama: what card are you using?
04:07 < darktama> 6800GT (NV40)
04:07 < marcheu> so, I was suggesting the other day that everyone fills his nouveau.fd.o page with his hardware
04:08 < marcheu> that would help when targetting some specific cards
04:09 < darktama> hmm, that's not a bad idea..
04:12 < Lumag> Hmm... Either I miss something, or I can't login to wiki: there is login page, but there is no login button...
04:15 < marcheu> Lumag: on the top right ? I see I'm logged in there
04:16 < marcheu> maybe pressing enter works ?
04:16 < marcheu> I don't remember
04:16 < marcheu> it auto-logins
04:22 < Lumag> Strange...
04:38 < marcheu> Lumag: does it work ?
04:38 < Lumag> no
04:39 < marcheu> hmm
04:39 < marcheu> so if I go to login, I have a page with a "create profile "button
04:40 < marcheu> you don't have that ?
04:40 < Lumag> I have it. I registered on it, but then I'm not autologined.
04:40 < Lumag> oh... found the login page
04:41 < Lumag> maybe I missed the ?action=login somewhere
04:45 < marcheu> heh
04:45 < marcheu> Object hash is 00000a48
04:45 < marcheu> Object not found at expected place. bruteforcing the table. PLEASE REPORT!
04:45 < marcheu> Object found at 00001a58, 00001010
04:45 < marcheu> looks like the has algorithm varied slightly
04:45 < marcheu> hash
04:48 < marcheu> Lumag: did you commit the grep change ?
04:48 < Lumag> bi
04:48 < Lumag> no
04:48 < marcheu> I think we should apply it
04:49 -!- ag [i=ag@caladan.roxor.cx] has quit [Read error: 110 (Connection timed out)]
04:52 < marcheu> ok, I'll fix it if no one cares :)
05:12 < Lumag> good night to all!
05:12 < darktama> nite
05:12 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
05:18 < marcheu> darktama: do you want to port the remainng nv30 commands now ? or should I do it ?
05:18 < darktama> marcheu: I don't mind either way, but I currently have no way of testing it :)
05:19 < marcheu> oh, because of the broken RAMIN ?
05:19 < marcheu> we have to fix that ASAP
05:19 < darktama> yup, I'm staring at the dump atm
05:20 < darktama> I don't see anything obviously wrong in the code.. and the ddx works fine.. so I'm not sure what's happening
05:20 < marcheu> I still think we could brute force it
05:21 < darktama> how?
05:21 < marcheu> by looking for the object class
05:21 < marcheu> see nv_dma.c
05:21 < marcheu> pNv->PRAMIN[pramin_offset] = class | nv_flags0;
05:21 < marcheu> we could hunt for that
05:21 < darktama> yes, but we don't know the class to look for for all the objects :)
05:22 < marcheu> yes, but the class might be the same as on my nv44
05:22 < marcheu> so I tell you "the class is 0x97" and you can bootstrap it using that
05:23 < marcheu> we might be able to figure out where objects go if we find one
05:23 < darktama> hmm
05:25 < marcheu> hmm ?
05:25 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
05:27 < darktama> just a hmm in general :)
05:36 < marcheu> so, anything ?
05:37 < darktama> well, there's a lot of places where 0x97 shows up in the bottom 8 bits
05:37 < darktama> none of them have a similar layout to yours
05:37 < marcheu> except nv_flags0 is 0, 0x02080000 or 0x00020000
05:41 < marcheu> actually, it's only the case in the ddx
05:41 < marcheu> still, mine is always 00004497 it seems
05:41 < darktama> I have a number of 0x00004097's
05:53 -!- ag [i=ag@caladan.roxor.cx] has quit [Read error: 104 (Connection reset by peer)]
05:54 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
05:54 < marcheu> what's your value of context ?
05:54 < marcheu>         if (engine != ENGINE_GRAPHICS) {
05:54 < marcheu>                 message("Can't decode objects with this context!");
05:54 < marcheu> what's your value of engine, I mean ?
05:55 < darktama> for 0xbeef3097 it's 0x01113F57
05:56 < marcheu> and engine ends up being ?
05:56 < darktama> 1
05:56 < marcheu> ah, it doesn't print the warning there
05:57 < darktama> nope
05:58 < darktama> this is probably going to be something really obvious in the end
05:59  * darktama goes to fetch more coffee (haven't slept yet)
06:07 < marcheu> hmm
06:07 < marcheu> in your PRAMIN
06:08 < marcheu> I see a repeating pattern of 1s every 6 dwords, not every 8 dwords
06:08 < marcheu> woudl that mean your objects have a size 6 and not 8 ?
06:08 < marcheu> so that you need to multiply by 6 and not 4 the index
06:09 < darktama> and change <<4 to *6 I assume?
06:09 < marcheu> <<4 means *16, but some similar change
06:13 < marcheu> did you have NVRM errors in dmesg already ?
06:14 < darktama> nope, only the NVRM: loading NVIDIA...
06:14 < marcheu> some people say they get some playing doom 3
06:15 < marcheu> that error seems to dump an object handle and the corresponding object
06:16 < marcheu> http://www.nvnews.net/vbulletin/printthread.php?t=49117&page=4&pp=15
06:17 < marcheu> so 4097 seems to be it
06:18 < darktama> hmm, that definitely seems to be it then
06:19 < darktama> btw, are you sure the results are correct for you? if objects on >=NV40 are supposed to be 8 dwords (from nv_dma.c), the shift would have to be <<5 wouldn't it?
06:19 < marcheu> yup, it seems ok
06:20 < marcheu> anyway it all depends on what allocator is used
06:20 < marcheu> the DDX puts everything linearly
06:27 < marcheu> maybe you need more channels
06:27 < marcheu> ah, no
06:28 < darktama> ?
06:28 < marcheu>         // FIXME: I really dunno the number of channels
06:28 < marcheu>         for (chan = 0; chan < 32; chan++) {
06:29 < marcheu> but, no. it's for figuring out the hash
06:29 < marcheu> unless it's duplicated, and we end up on a wrong instance
06:36 < marcheu> so, staring at instance ram for too long can make your head hurt
06:37 < darktama> hehe, yes, I'm starting to figure that out!
06:37 < darktama> I'm honestly not sure.. I'm starting to wonder if there's an offset reg
06:38 < darktama> though, I doubt it
06:39 < marcheu> maybe your card doesn't draw with 3097...
06:40 < darktama> it seems to, according to the rest of the output
06:40 < marcheu> yup
06:42 -!- ag [i=ag@caladan.roxor.cx] has quit [Read error: 104 (Connection reset by peer)]
06:42 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
06:45 < marcheu>         instanceMem = context & 0xffff;
06:45 < marcheu> that mask seems wrong
06:46 < darktama> nv_dma.c says that it may be 19:0 on nv40, but that gives me offsets that are massively out of the 0x700000 range
06:46 < marcheu> even with just one bit more ?
06:47 < marcheu> maybe it wraps
06:47 < darktama> with 1 extra bit I get (for 3097):
06:47 < darktama> Context is 01113f3e
06:47 < darktama> InstanceMem[0x83F3E0] = 00000000
06:47 < darktama> InstanceMem[0x83F3E4] = 00000000
06:47 < darktama> InstanceMem[0x83F3E8] = 00000000
06:47 < darktama> InstanceMem[0x83F3EC] = 00000000
06:51 < marcheu> or maybe
07:06 < marcheu> well, it's getting late
07:06 < marcheu> however, it might be 0x0s
07:07 < marcheu> except for the first one that is
07:07 < darktama> how would that work?
07:07 < darktama> +
07:07 < darktama> oops
07:08 < marcheu> the haiky driver seems to init some to 0x0
07:16 < marcheu> ah well I have to sleep now
07:16 < marcheu> hopefully sort that out tomorrow
07:16 < darktama> yes, it'd be nice!
07:16 < darktama> night
07:17 -!- ag [i=ag@caladan.roxor.cx] has quit [Remote closed the connection]
07:18 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
07:42 -!- pedro [n=kvirc@c906e04c.virtua.com.br] has quit [Remote closed the connection]
07:48 -!- ag [i=ag@caladan.roxor.cx] has quit [Remote closed the connection]
07:48 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
07:54 -!- jkolb [n=jkolb@209-6-112-224.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has quit ["Client exiting"]
08:25 -!- ag [i=ag@caladan.roxor.cx] has quit [Nick collision from services.]
08:25 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
08:54 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
09:12 -!- ag [i=ag@caladan.roxor.cx] has quit [Nick collision from services.]
09:13 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
09:51 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
10:01 -!- ag [i=ag@caladan.roxor.cx] has quit [Remote closed the connection]
10:02 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
10:11 -!- ag [i=ag@caladan.roxor.cx] has quit [Remote closed the connection]
10:12 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
10:18 -!- Duke` [n=gnu@ANantes-251-1-104-109.w86-203.abo.wanadoo.fr] has joined #nouveau
10:45 -!- ag [i=ag@caladan.roxor.cx] has quit [Remote closed the connection]
10:45 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
10:58 -!- ag [i=ag@caladan.roxor.cx] has quit [Nick collision from services.]
10:59 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
11:01 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has joined #nouveau
11:02 -!- ag [i=ag@caladan.roxor.cx] has quit [Read error: 104 (Connection reset by peer)]
11:32 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
11:51 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
12:03 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
12:30 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
15:13 < Lumag> darktama: if you still don't have success with finiding objects, could you please provide buffer dumps from ioctl simply by modifying nv_ioctl in the kernel?
15:18 < Lumag> I'm interested in dump from start of the renv till it's end.
15:24 < darktama> ok, I'll try and get to that in a sec.. haven't slept in over 24-hours though!
15:25 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
15:25 < Lumag> :(
15:25 < Lumag> thank you
15:26 < darktama> no, thank you for looking at it
15:28 < darktama> ok, what info do you want from nv_kern_ioctl?
15:29 < Lumag> marcheu: could you please the name of the object that triggered HT bruteforcing?
15:29 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has joined #nouveau
15:29 < Lumag> marcheu: also a RAMHT dump from that program would help :)
15:31 < darktama> http://rivatv.sourceforge.net/stuff/rules.tar.gz << lots of regs documented here, and it seems there's quite a bit of 3D info for <=NV10
15:32 < Lumag> :)
15:32 < Lumag> I think it's linked from the nouveau FrontPage :)
15:33 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
15:33 < darktama> hmm, not that I can see
15:33 < darktama> I'll add it :)
15:33 < darktama> it's not very descriptive though, unfortunately
15:35 < Lumag> Yes, I thought that the file at Anholt's page contains rules.xml. Sorry
15:37 < marcheu> Lumag: I might have time to do that this evening
15:38 < Lumag> marcheu: thank you.
15:40 < marcheu> I think it's just one bit more that is used
15:40 < marcheu> for hashing
15:44 < Lumag> Maybe. I think that all HT places between 1a48 and 1a58 were already occupied by other objects :)
15:44 < Lumag> That's why I asked for HT dump
15:57 -!- darktama_ [n=darktama@124-168-242-114.dyn.iinet.net.au] has joined #nouveau
15:58 < darktama_> argh
15:59 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Read error: 113 (No route to host)]
15:59 -!- darktama_ is now known as darktama
16:15 < darktama> Lumag: how do you want arg_copy printed? in bytes or uints?
16:16 < Lumag> darktama: yes, in uints please.
16:28 < darktama> Lumag: http://members.iinet.net.au/~darktama/dumps.tbz2
16:34 < Lumag> darktama: thanks
16:35 < darktama> np, bbiaf
16:50 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
16:56 < Lumag> darktama: still no clues :(
16:57 < darktama> it's quite frustrating hehe :)
17:02 < darktama> ah well, time for sleep
17:02 < darktama> night all
17:05 < Lumag> night!
17:06 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
17:30 < Duke_> hey I just read the NVIDIA license for the first time (*cough*) and it is written: "No Reverse Engineering. Customer may not reverse engineer, decompile, or disassemble the SOFTWARE"
17:30 < Duke_> aren't we reverse engineering their driver?
17:42 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
17:51 < |pedro> Duke_: hey!
17:51 < |pedro> Duke_: I think the same...
17:51 < |pedro> Duke_: but... for ex... I'm using Debian's NVIDIA packages...
17:52 < |pedro> Duke_: and I didn't say "accept" any time...
17:52 < |pedro> Duke_: so... what can I do? :P
18:04 < Duke_> the packager said "I accept", so its his problem now :o)
18:07 < |pedro> yeah... :P
18:08 < Duke_> btw, french law tolerates reverse engineering for interroperability purpose, so french contributors can claim that it's for having 3D acceleration for a system where nvidia's driver doesn't exist (BSD ARM or GNU/Hurd :p), and that an Open Source driver for others platform is just a consequence :D
18:09 < |pedro> hm... that's a good point...
18:09 < |pedro> and here in Brazil nobody knows anything about re and stuff... all we know is soccer... then it's okay for brazilian contributors too... :P
18:10 < |pedro> (we don't have laws for such things here I think)
18:11 < |pedro> I think that your claim was used on the dvdcss thing, didn't it?
18:11 < |pedro> :P
18:13 < Duke_> I'm not sure, Jon Lech Johansen is not french, it seems to be a different reason
18:14 < Duke_> (according to wikipedia)
18:15 < |pedro> hm...
18:15  * |pedro reading about it...
18:15 < |pedro> *is
18:36 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has joined #nouveau
19:42 -!- jkolb [n=jkolb@130.57.22.69] has joined #nouveau
19:42 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:12 < Lumag> Seems that I'll be able to stop depending on RAMIN reading at all :)
20:26 < marcheu> hmm, how ?
20:27 < Lumag> by overwriting ioctl() and getting the type from arguments.
20:27 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
20:27 < marcheu> ah, nice
20:27 < marcheu> ptrace ?
20:27 < Lumag> nope. dynamic linking :)
20:33 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
20:36 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has joined #nouveau
20:56 -!- EdB_ [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has joined #nouveau
20:56 -!- EdB [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
20:59 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has quit ["KVIrc 3.2.0 'Realia'"]
21:01 -!- pmdata [i=patrice@ANantes-154-1-91-252.w86-210.abo.wanadoo.fr] has joined #nouveau
21:03 < pmdata> hello
21:04 -!- EdB_ [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
21:11 < pmdata> I want to port nv1x commands to new stuff
21:12 < marcheu> good :)
21:12 < pmdata> does NvType00xx means xx is the global type, and then commands in previous cmd.h sub type/command?
21:12 < marcheu> yes
21:12 < marcheu> it's as simple as that. that and some cut & paste
21:12 < marcheu> one thing though, multi fields have to get a name each
21:14 < pmdata> I found this with google: http://www.csee.umbc.edu/~olano/s2005c37/ch11.pdf
21:15 < pmdata> Mark Olano made many pdf from siggraph courses: http://www.csee.umbc.edu/~olano/
21:15 < marcheu> you can probably find similar stuff on developer.nvidia.com
21:15 < marcheu> at least some of the tables/figure look the same
21:17 < pmdata> the syntax of objects.c is a bit weird :)
21:17 < marcheu> why ?
21:17 < marcheu> each object holds a number of fields/commands, and that's all
21:18 < pmdata> the [macro] = {}, I am not used to this C style of array init
21:18 -!- EdB_ [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has joined #nouveau
21:18 < marcheu> although I'd like some generic "data from here to here is float and has do be treated as such", because the vertex area on nv30 is not 6 entries like on nv04 but rather 4000 or so :)
21:19 < marcheu> gtg
21:25 < Lumag> marcheu: well... maybe offsets sould be implemented like offset+mask...
21:26 -!- pedro_ [n=pedro@c906e04c.virtua.com.br] has joined #nouveau
21:32 -!- pedro_ [n=pedro@c906e04c.virtua.com.br] has quit [Remote closed the connection]
21:37 -!- katakombi [n=kombrisn@dslb-084-056-156-058.pools.arcor-ip.net] has joined #nouveau
21:37 < Lumag> also according to nv drivers, nv04 has 16 vertex entries not 6 :)
21:41 < Lumag> Well... I have commited the ioctl wrapper and disabled RAMHT/RAMIN parsing. So now the dumper should work for all cards and bjects.
21:42 < Lumag> objects
22:11 < marcheu> yeah, the problem remains that I can't describe the entries extensively :)
22:13 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
22:18 < Lumag> well... I think I have an idea, how to implement arrays. Will try to implement it this evening.
22:21 < pmdata> I hope to finish nv1x stuff before you break everything :)
22:29 < Lumag> :)
23:07 < pmdata> I have nearly finished, I just put print_x32 everywhere first
23:08 -!- hub [n=hub@storm-gw.xandros.com] has joined #nouveau
23:08 < hub> hi
23:14 < Lumag> pmdata: if there is complex format (e.g. bitfield, etc.) you shouldn't claim it's X32!
23:18 < pmdata> yep, I know, but I must first convert all nv1x cmds.h defines
23:41 < pmdata> pfiou, commited first step, now time to replace some print_x32
23:44 < |pedro> goal! :P
23:46 < pmdata> which team?
23:47 < |pedro> Brazil...
23:47 < |pedro> halftime now...
23:48 < Lumag> :)
23:50 < |pedro> hm... there is something really simple that I still didn't get it...
23:50 < |pedro> what are objects?
23:50 -!- EdB_ [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has quit [Read error: 104 (Connection reset by peer)]
23:52 -!- EdB_ [n=EdB@ARennes-251-1-19-98.w81-250.abo.wanadoo.fr] has joined #nouveau
23:52 < pmdata> lumag> is there something special to do, to define a fixed array command, there are some __(nv04_xxx(3)) I can't do the same
23:53 < Lumag> pmdata: what do you mean by 'fixed array command'?
23:53 < pmdata> for example for a matrix, which always has 16 fp32 values
23:56 -!- `Duke` [n=gnu@ANantes-251-1-135-15.w86-210.abo.wanadoo.fr] has joined #nouveau
23:56 < Lumag> oh... currently you can only define it as 16 fp32 variables.
23:57 < pmdata> something like 	{PRINT_FP32, PRINT_FP32, ... } ?
23:58 < Lumag> no. 16 distinct commands :(
23:58 < Lumag> and a commentary, that they should come in a single write.
23:59 < Lumag> I'll try to hack support for 'array of structures' but currently there is no such thing.
--- Log closed Срд Июн 14 00:00:27 2006
