--- Log opened Чтв Июн 15 00:00:28 2006
00:09 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has joined #nouveau
00:17 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
00:17 < pmdata> hi lumag
00:18 < Lumag> hi
00:19 < pmdata> was the object type wrongly calculated? using today's cvs values were different
00:24 < Lumag> Maybe, or may be not. Now the types are the ones, that we glx component submits to kernel (or so I think). Reading object types from RAMIN caused problems for some cards.
00:24 < Lumag> BTW: what object types changed? 0x61 -> 0x65 or something else?
00:26 < pmdata> most nv1x object types I did yesterday, I updated nv_objects.h today
00:26 < pmdata> for example nv10 primitive 3d: 56 -> 96
00:26 < Lumag> Huh, strange.
00:27 < pmdata> or 42 -> 62 (unknown object type)
00:29 < Lumag> and what object handles are used for those objects BEEFwhat?
00:32 < pmdata> hum, beef4201 gives nvtype0062
00:33 < pmdata> 287   0x00000000   0x00106300             {size: 0x4   channel: 0x3   obj: beef4201}
00:33 < pmdata> 288   0x00000000   0x0000000b                       NvType0062      [0x0300/4] = 0x0000000b
00:33 < pmdata> 289   0x00000000   0x10001000                       NvType0062      [0x0304/4] = 0x10001000
00:33 < pmdata> 28a   0x00000000   0x000ce000                       NvType0062      [0x0308/4] = 0x000ce000
00:33 < pmdata> 28b   0x00000000   0x000ce000                       NvType0062      [0x030c/4] = 0x000ce000
00:34 < Lumag> as I thought...
00:36 < pmdata> yes?
00:37 < Lumag> Yes. I have beef6101, RAMIN read gives 0x61, ioctl passes 0x65
00:38 < pmdata> I also have some beef6101 object, what should I check?
00:39 < pmdata> "object creation: beef6101, type 8a, parent beef000b" ?
00:40 < Lumag> Well... 0x62 seems to be the NV10_CONTEXT_SURFACES_2D, 0x42 is some type of NV4 SURFACE,
00:41 < Lumag> and what do you get for beef6101 if you reenable RAMIN readings (just comment new find_object_type and uncomment old one in objects.c)?
00:42 < pmdata> funny, I did not see the size of objects.o when compiled (32MB)
00:44 < pmdata> I have nvtype0061 stuff displayed
00:45 < pmdata> before:
00:45 < pmdata> 298   0x00000000   0xbeef6101
00:45 < pmdata> 299   0x00000000   0x000802fc             {size: 0x2   channel: 0x0   obj: beef6101}
00:45 < pmdata> 29a   0x00000000   0x00000001                NV10_PRIMITIVE_2D      [0x02fc/4] = 0x00000001
00:45 < pmdata> 29b   0x00000000   0x00000004                NV10_PRIMITIVE_2D      [0x0300/4] = 0x00000004
00:45 < pmdata> after:
00:45 < pmdata> 298   0x00000000   0xbeef6101
00:45 < pmdata> 299   0x00000000   0x000802fc             {size: 0x2   channel: 0x0   obj: beef6101}
00:45 < pmdata> 29a   0x00000000   0x00000001                       NvType0061      [0x02fc/4] = 0x00000001
00:45 < pmdata> 29b   0x00000000   0x00000004                       NvType0061      [0x0300/4] = 0x00000004
00:47 < Lumag> Well... 0x61, 0x65 and 0x8a seems to be IMAGE_FROM_CPU for nv03, nv05, and nv10. Looks like nv-glx asks for updated object, but kernel module instantiates old one instead.
00:49 < Lumag> BTW: could you please display RAMIN readings (those mentioning instanceMem) from you log corresponding to the beef6101?
00:50 < pmdata> the ones just before the logged dumped? here they are:
00:50 < pmdata> mapped subchannel 0 to beef6101
00:50 < pmdata> Searching for object beef6101
00:50 < pmdata> Object hash is 000030b0
00:50 < pmdata> Channel is 2
00:50 < pmdata> Object found at 000038b0, 00000800
00:50 < pmdata> Context is 82011503
00:50 < pmdata> Can't decode objects with this context!
00:50 < pmdata> InstanceMem[0] = 1a00a08a
00:50 < pmdata> InstanceMem[1] = 15100d00
00:50 < pmdata> InstanceMem[2] = 00000000
00:50 < pmdata> InstanceMem[3] = 00000000
00:51 < Lumag> whow! it's really 0x8a object :)
00:52 < pmdata> shouldn't it?
00:53 < Lumag> Well... As for me, it isn't :)
00:53 < Lumag> The ioctl passes 0x65 and RAMIN reads
00:53 < Lumag> InstanceMem[0] = 1a00a061
00:53 < Lumag> InstanceMem[1] = 14ad0d00
00:53 < Lumag> InstanceMem[2] = 00000000
00:53 < Lumag> InstanceMem[3] = 80c50a1c
00:54 < pmdata> what is your gpu?
00:54 < Lumag> TNT2 Vanta
00:54 < Lumag> I'll check for plain TNT2 in a moment.
00:55 < pmdata> hardware bug? or maybe gpu translated 0x65 to 0x61?
00:55 < Lumag> I think it's a kernel, who did the thing.
00:56 < pmdata> ah, the nv kernel module
00:58 < pmdata> so maybe nvglx has same values whatever the chip is, and the nvkernel translates it then?
00:58 < pmdata> s/has/use/
00:59 < Lumag> It seems, that object handles are common for all object types, but the type passed via ioctl is chip-specific.
00:59 < Lumag> E.g. in your case it is 0x8a, in mine it's 0x65
01:02 < pmdata> marcheu told earlier that object types where different for all chips or at least class of chips, so here it is
01:03 < marcheu> I didn't say that excatly, I said that if a card features an object, it features all fields from the object
01:04 < marcheu> some cards feature objects that are reused from the previous generation(s)
01:05 < marcheu> and some card feature two different objects to achieve the same thing (for example NV10 can use NV04_DX5_TEXTURED_TRIANGLE as well as the other, TCL-enabled, object)
01:05 < pmdata> ah yes, reread it, undertood it the wrong way :)
01:06 < marcheu> now I'm not sure I understand what's happening there ?
01:06 < marcheu> the kernel would return another object ?
01:07 < marcheu> pmdata: what's the real object that's used for you ?
01:07 < Lumag> yes, sometimes.
01:08 < marcheu> it's strange
01:08 < Lumag> pmdata: could you please check, what do you get from RAMIN in case of beef4201 object?
01:08 < marcheu> 0x00000056 vs 0x00000096
01:08 < marcheu> Lumag: what was your objecty difference again ?
01:08 < Lumag> asked for 0x65, got 0x61
01:09 < marcheu> hmm, 0x00000056 vs 0x00000096 is just one bit
01:09 < marcheu> 0x65 vs 0x00000096 is just one bit too
01:09 < marcheu> 0x65 vs 0x00000061 is just one bit too
01:09 < Lumag> confirmed on plain TNT2
01:09 < Lumag> 56 vs 96 is two bits difference
01:10 < marcheu> Lumag: ?
01:10 < pmdata> mapped subchannel 3 to beef4201
01:10 < pmdata> Searching for object beef4201
01:10 < pmdata> Object hash is 00002890
01:10 < pmdata> Channel is 2
01:10 < pmdata> Object found at 00002090, 00000800
01:10 < pmdata> Context is 82011501
01:10 < pmdata> Can't decode objects with this context!
01:10 < marcheu> 9-5 is 4 IIRC and 5 is 1 bit
01:10 < pmdata> InstanceMem[0] = 00000062
01:10 < pmdata> InstanceMem[1] = 15100000
01:10 < pmdata> InstanceMem[2] = 00000000
01:10 < marcheu> armmm
01:10 < pmdata> InstanceMem[3] = 00000000
01:10 < marcheu> 9-5 is 4 IIRC and 4 is 1 bit
01:11 < Lumag> 9 = 1001, 5 = 0101, or did I get you wrong?
01:11 < marcheu> Lumag: hmm, right
01:11 < marcheu> ah well
01:12 < Lumag> pmdata: thanks it really seems to be 0x62. and the card is NV10?
01:12 < pmdata> nv15
01:13 < marcheu> Lumag: btw did you see differences between your TNT & TNT vanta cards ?
01:13 < pmdata> should I now replace all nv10_* stuff with nv15_* in nv_objects.h ? :)
01:14 < Lumag> marcheu: didn't have time to check. Also currently it's PITA to use both cards, because I lack the second monitor. I'll get one next week, and I hope I'll have more time to do it.
01:15 < Lumag> pmdata: don't rush :)
01:16 < marcheu> Lumag: but you didn't notice any difference until now ?
01:16 < marcheu> I'm not asking for an extensive answer, just wether you saw something :)
01:16 < Lumag> btw: it's strange, that you get 'Can't decode...' for that objects. 82011501 seems to be plain ENGINE_GRAPHICS object.
01:18 < Lumag> marcheu: no
01:21 < pmdata> lumag> I think this is caused by the switch(card_family)
01:21 < Lumag> yup. found it too :)
01:22 < pmdata> ah yes, NV15 missing, will add it
01:22 -!- jkolb [n=jkolb@130.57.22.69] has quit ["Leaving"]
01:22 < pmdata> do you want a redump?
01:23 < Lumag> no, it's ok.
01:23 < Lumag> That's why before the change you got 0x61 and 0x8a.
01:24 < pmdata> hm, yes, a bit useless
01:24 < pmdata> so what values are right? yesterday's or today's?
01:24 < Lumag> for you the right value is 0x8a.
01:25 < pmdata> ok, this is what I updated in cvs today: #define NV10_PRIMITIVE_2D 0x0000008a
01:27 < Lumag> I think, that sometimes kernel changes the object type, but the glx cannot know about that. We should keep that in mind, when writing drivers, but (probably) use the type from ioctl for re stuff.
01:28 < Lumag> pmdata: ok. And (just for reference) 0x61 family of types is called IMAGE_FROM_CPU in most sources
01:29 < pmdata> hum, I don't have 61 stuff atm, which opengl stuff will trigger it?
01:32 < marcheu> pmdata: if 8a replaces 61, that probably means 61 has become useless
01:32 < Lumag> _family_ of types. it's 0x61(nv03), 0x65(nv04). And seems that 0x8a belongs to that family.
01:32 < Lumag> Well, just joking. PRIMITIVE_2D is ok :)
01:33 < marcheu> we might want to put that family information explicitly
01:33 < marcheu> sometimes objects are buggy, and drivers fallback to another version (which might explain some of what we see)
01:33 < pmdata> yes, because 2D stuff means many things
01:34 < pmdata> I should try writing a sample XVideo app, to see if gpu is used
01:34 < Lumag> BTW: IIRC, under woe32 it's possible to force drivers to emulate the behaviour of earlier cards. I wonder whether it's possible in our case.
01:34 -!- Myrizio [n=Myrizio@Linuz.sns.it] has joined #nouveau
01:35 < pmdata> lumag> it should be, as long as previous object types are still supported on new chips
01:35 < pmdata> or do you mean for example not using the tcl engine?
01:35 < Lumag> Yes.
01:36 < marcheu> pmdata: yes, you can run your nv10 in nv04 mode (what haiku/utah-glx do) or your nv20 in nv10 (there used to be a windows option)
01:36 < pmdata> would be nice to check if the cpu is faster than tcl engine on some cards
01:36 < marcheu> pmdata: you lose more than just TCL
01:36 < pmdata> if you have a fast cpu
01:37 < marcheu> for example multitexturing or shaders...
01:37 < pmdata> wouldn't it be easier to change the pci id of the card when the nv driver reads it ? :)
01:37 < marcheu> maybe it's enough, we could fool one of the first ioctls maybe
01:38 < marcheu> the one that sends the id
01:38 < marcheu> we'd have a softquadro for linux, then :)
01:41 < pmdata> it seems it is the first ioctl():
01:41 < pmdata> ioctl: 6, c14046c8, @0x400a1740
01:41 < pmdata> arg: 00000001 00000001 00000000 000010de 00000151 0000000b e0000000 01000000
01:41 < marcheu> you get to try first :)
01:43 < pmdata> would be nice to test which features are done using gpu or cpu
01:43 < Lumag> :)
01:43 < Lumag> You can change the returned array in ioctl.c as you wish :)
01:44 < Lumag> And then ioctl.c can wrapped in the same way as e.g. libaoss and similar libs :)
01:45 < pmdata> cool, no need to buy an expensive g70 then
01:46 -!- Duke` [n=gnu@ANantes-251-1-102-3.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
01:47  * pmdata will downgrade nv15 to nv10, prepare to crash
01:47 < pmdata> no crashed box, but program segfaults
01:48 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
01:48 < Lumag> backtrace?
01:49 < pmdata> did not run gdb, but it seems the chip value is always sent on each ioctl()
01:50 < pmdata> tried changing 0x10de:0x151 to 0x10de:0x150, no problem
01:53 < pmdata> rerun it with nv10, does not crash, but no command output, and very different beefxxxx stuff
01:54 < Lumag> strange...
01:55 < pmdata> oops, I made a bug, I always set ptr[4] to 0x100, whatever the ioctl
01:55 < Lumag> :)
01:57 < pmdata> ok, it works, no crash, from what I see, I got same gpu commands as for nv15
01:57 < pmdata> I need to make a special nv15 stuff, dot3 bumpmapping maybe
01:58 < marcheu> how is dot3 nv15-specific ?
01:58 < Lumag> Yup. Tried to make nv10 from nv06, no change. It seems, libGL uses some other ways to determine the chip.
01:58 < pmdata> marcheu> this is what nvidia says in there pr stuff
01:59 < pmdata> don't tell me they lie :)
02:00 < pmdata> nv15 http://www.beyond3d.com/misc/chipcomp/?view=chipdetails&id=38
02:00 < pmdata> arg, nv10 also has it, shame on me
02:01 < pmdata> I need to find something else
02:01 < marcheu> good luck
02:01 < marcheu> (I have both nv11 & nv15 :)
02:01 < marcheu> (and no differences in sight)
02:02 < pmdata> hum, "filtering per texture unit" can be trilinear on nv15
02:03 < pmdata> I hope nv15 is not just a faster nv10
02:04 < pmdata> per pixel lighting perhaps?
02:04 < marcheu> alright, you can lookup for yourself there : http://delphi3d.net/hardware/allexts.php
02:05 < marcheu> take a nv1X and a nv1Y, and the same driver version for both, and try to find one single difference
02:06 < marcheu> hmm do we ever get NV4_DX6_MULTI_TEXTURE_TRIANGLE ?
02:08 < pmdata> I also have fsaa, and cube env mapping, and go to sleep now :)
02:08 -!- pmdata [i=patrice@ANantes-154-1-39-201.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
02:11 < Lumag> marcheu: it's created, but unused.
02:12 < marcheu> well, it probably needs opengl multitexturing to be triggered
02:12 < marcheu> but if it's created that means it probably works
02:13 < marcheu> I'm wondering about importing all nv10reg.h objects into renouveau
02:14 < Lumag> Well... It may be a good start, but I think there is no use in importing objects that are unused.
02:14 < marcheu> it's just so that we know they're documented if we end up seeing them
02:15 < Lumag> well... Maybe it's worth importing class names and leaving fields for later.
02:17 < marcheu> I'll let it as-is for now
02:28 < Lumag> marcheu: test_tex triggers NvType0055
02:33 < marcheu> ah good, so it works
02:33 < marcheu> we probably need a way to tell similar objects
02:33 < marcheu> 54 & 55 are probably very close
02:57 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:07 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
06:41 -!- Myrizio [n=Myrizio@Linuz.sns.it] has quit ["I like core dumps"]
10:11 -!- katakombi [n=kombrisn@dslb-084-056-155-067.pools.arcor-ip.net] has quit [Read error: 104 (Connection reset by peer)]
10:12 -!- katakombi [n=kombrisn@dslb-084-056-154-083.pools.arcor-ip.net] has joined #nouveau
10:35 -!- Duke` [n=gnu@ANantes-251-1-102-3.w86-203.abo.wanadoo.fr] has joined #nouveau
11:04 -!- EdB [n=EdB@ARennes-251-1-89-80.w86-199.abo.wanadoo.fr] has joined #nouveau
11:18 -!- EdB [n=EdB@ARennes-251-1-89-80.w86-199.abo.wanadoo.fr] has quit [Remote closed the connection]
11:18 -!- EdB [n=EdB@ARennes-251-1-89-80.w86-199.abo.wanadoo.fr] has joined #nouveau
11:40 -!- Duke__ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
12:19 -!- EdB [n=EdB@ARennes-251-1-89-80.w86-199.abo.wanadoo.fr] has quit [Remote closed the connection]
12:19 -!- EdB [n=EdB@ARennes-251-1-89-80.w86-199.abo.wanadoo.fr] has joined #nouveau
12:58 -!- gnarlin [n=gnarlin@194-144-217-11.du.xdsl.is] has quit ["leaving"]
18:18 -!- EdB [n=EdB@ARennes-251-1-89-80.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
18:23 -!- jkolb [n=jkolb@130.57.22.69] has joined #nouveau
19:20 -!- Duke___ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
19:23 -!- Duke__ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
20:10 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:12 -!- Duke` [n=gnu@ANantes-251-1-102-3.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
20:12 -!- Duke` [n=gnu@ANantes-251-1-83-91.w86-203.abo.wanadoo.fr] has joined #nouveau
20:16 -!- jkolb [n=jkolb@130.57.22.69] has quit [Remote closed the connection]
20:22 -!- Duke___ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
21:08 -!- pmdata [i=patrice@ANantes-154-1-39-222.w81-53.abo.wanadoo.fr] has joined #nouveau
22:00 < pmdata> hello
22:11 < |pedro> hi pmdata
22:16 -!- jkolb [n=jkolb@130.57.22.69] has joined #nouveau
22:37 -!- katakombi [n=kombrisn@dslb-084-056-154-083.pools.arcor-ip.net] has quit [Remote closed the connection]
22:54 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
22:54 < pmdata> hi lumag
22:55 < Lumag> hi!
22:57 < Duke`> hi
22:58 < pmdata> just found raster op (43) logic op (300)
23:02 < Lumag> :)
23:04 < pmdata> commited to cvs
23:28 < pmdata> found something with gldrawpixels():
23:28 < marcheu> hmm, what's that special char ?
23:28 < pmdata> when glrasterpos2i(x,y) is used, if x==0 and y==0, then 2D primitives are used, else, if x<>0 or y<>0 then 3D primitives are used
23:29 < pmdata> but what I gldrawpixels() is a constant value
23:29 < pmdata> will try with some random pattern
23:31 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has quit ["KVIrc 3.2.0 'Realia'"]
23:39 < pmdata> ah, I was doing a 2x2 blit, using a 5x7 blit
23:39 < pmdata> it seems doing a 2^n * 2^n gldrawpixels operation is done using 3d engine
23:47 < pmdata> not much talk here atm, I must find something more interesting :)
23:48 < marcheu> heh :) I suppose no one else tried 2D ops
23:49 < pmdata> I would like to try xvideo stuff
23:49 < marcheu> it's not really high priority, except for writing a back to front blit, which is a #1 must have
23:49 < marcheu> hmm, xvideo might be nice, yes. currently support is minimal
23:49 < pmdata> I should try glcopypixels(), this is a gpu ram <-> gpu ram copy
23:49 < marcheu> however there are issues on nv40+, some of which use the 3D engine to do that...
23:49 < marcheu> for xvideo what you want is YUV conversion, nut sure what more the NV10 can do
23:50 < pmdata> yep, from what I read, it does not seem to do motion comp or idct
23:50 < marcheu> and IIRC the number of YUV formats supported by the free DDX is too small to be userful in real world apps
23:51 < pmdata> does sdl uses xvideo stuff?
23:52 < marcheu> also the xvmc pipeline forces you to implement a wide portion of mpeg-style acceleration, which is not always available in hw
23:52 < marcheu> yes, with SDL_Overlays
23:52 < marcheu> SDL overlays are really just wrappers around xv overlays
23:53 < darktama> marcheu: btw, have you played with EXT_fbo on NV40 at all?
23:53 < marcheu> darktama: nope, would be a good idea for mem management stuff
23:53 < marcheu> darktama: I'm still trying to figure out bios parsing :(
23:54 < darktama> hmm, I'm wondering how well the hardware handles using the currently bound framebuffer as a texture at the same time
23:54 < darktama> how's that going btw?
23:54 < marcheu> at least it stopped crashing but doesn't lead to usable display...
23:54 < marcheu> I suspect I must reinit more than the DDX does already
23:54 < darktama> that wouldn't surprise me, does haiku touch anything the ddx doesn't?
23:54  * pmdata will try sdl overlay then
23:55 < marcheu> pmdata: doesn't the atari port have overlays ? :)
23:55 < pmdata> of course no, only software
23:57 < pmdata> speaking of other arch, I guess nouveau should be welcomed by non x86 linux arch, like ppc for example, is nouveau endianness-independent?
23:57 < darktama> I imagine it will be in the end
23:58 < marcheu> well, I tried to write endian-clean code, but...
23:58 < marcheu> probably if everyone does the same
23:58 < marcheu> and if some PPC machines fall from the sky upon us devs..
23:58 < darktama> I have no idea of the issues, I've never been anywhere near a big-endian system before :S
23:59 < marcheu> well, it's down to a small number of things, really. stuff like don't cast an array if ints to an array of chars...
23:59 < marcheu> but when it's hidden within a largeer codebase, it becomes difficult
--- Log closed Птн Июн 16 00:00:06 2006
