--- Log opened Птн Июн 16 00:00:06 2006
--- Day changed Птн Июн 16 2006
00:00 < darktama> oh, well.. I generally try not to do stuff like that anyway :)
00:00 < marcheu> I read the commits list and try to monitor stiff for that kind of issues (also for 32/64 bit issues)
00:01 < marcheu> s/stiff/stuff
00:02 < darktama> well, you'll hear me start squealing if something breaks on amd64!
00:02 < marcheu> well, it might not always
00:03 < marcheu> some 32/64 bit issues might go unnoticed, for example, if you don't have more than 4gb of ram...
00:03 < marcheu> also some archs are more fragile than others
00:03 < marcheu> mostly because of chipset/cache combinations
00:04 < marcheu> typically, you don't want to memcpy or memset to AGP memory. this will work on x86 and sometimes ppc, but will hardlock ia64 randomly
00:04 < darktama> what do you do on those archs?
00:04 < marcheu> byte-by-byte copy/set
00:05 < marcheu> see kernel's memsetio and more generally *io
00:05 < marcheu> some archs also need memory barriers inserted after reg writes
00:06 < darktama> wow, I hear people complain that x86 is difficult..
00:07 < pmdata> just tried an overlay, no gpu commands :(
00:07 < marcheu> pmdata: the commands are emitted from inside the X server
00:07 < marcheu> pmdata: by the DDX
00:07 < marcheu> pmdata: you'd have to map the DDX's fifo
00:07 < pmdata> which one is it?
00:08 < pmdata> oh I guess I can't have it
00:08 < marcheu> read register 0x00002504
00:08 < marcheu> each bit means enabled/disabled fifo
00:09 < marcheu> it's one of the enabled ones  :)
00:11 < pmdata> I created the sdl video context without SDL_OPENGL, I don't know if sdl overlay work with it
00:11 < marcheu> under linux, it does. but that's unspecified behaviour
00:11 < marcheu> under linux/nvidia, it does. but that's unspecified behaviour
00:11 < marcheu> with windows it doesn't
00:11 < marcheu> you should get sdl's moose test. it does everything
00:12 < marcheu> testoverlay2 it's called
00:14 < pmdata> it's ok, I made similar stuff
00:14 < pmdata> I only have one map: map 0   from 0x40cca000 to 0x41cca000 size 0x1000000 (physical 0xe0000000)      => no dump
00:14 < marcheu>  yes, you have to look at another fifo
00:15 < marcheu> first read 0x00002504
00:15 < marcheu> I think you can add/remove the fifo size to the physical adress to point to the next/previous fifo
00:16 < marcheu> so I think you can map /dev/mem at that address and that's ok
00:16 < marcheu> I don't think /dev/nvidia0 will expose it
00:16 < marcheu> it might, you can try with it as well, it's better since it doesn't require root privs
00:18 < pmdata> could you add it yourself to renouveau? I will add the test overlay in tests
00:19 < marcheu> ok, I'll look at it
00:28 -!- jkolb [n=jkolb@130.57.22.69] has quit ["Leaving"]
01:03 -!- pmdata [i=patrice@ANantes-154-1-39-222.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:11 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has joined #nouveau
01:26 -!- |pedro [n=kvirc@c906e04c.virtua.com.br] has quit [Read error: 104 (Connection reset by peer)]
01:29 -!- jkolb [n=jkolb@209-6-112-224.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has joined #nouveau
02:07 -!- Duke` [n=gnu@ANantes-251-1-83-91.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:28 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
05:13 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
05:34 -!- jkolb [n=jkolb@209-6-112-224.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has quit ["Client exiting"]
09:17 -!- katakombi [n=kombrisn@dslb-084-056-151-119.pools.arcor-ip.net] has joined #nouveau
10:27 -!- Duke` [n=gnu@ANantes-251-1-83-91.w86-203.abo.wanadoo.fr] has joined #nouveau
11:07 -!- EdB [n=EdB@ARennes-251-1-12-186.w83-195.abo.wanadoo.fr] has joined #nouveau
11:35 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
11:36 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
14:53 -!- EdB [n=EdB@ARennes-251-1-12-186.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:10 < Lumag> darktama: how can I test for type 0x39?
15:10 < darktama> texture/fragprog uploads trigger it here
15:12 < Lumag> :) I see it's created for me too. Will try to trigger it's usage.
15:12 < darktama> it should be supported an most(all?) cards, the ddx's exa implementation uses it unconditionally
15:13 < marcheu> it's a DMA
15:13 < darktama> yes
15:13 < marcheu> so it covers everything that downloads/uploads stuff to the card
15:16 < darktama> marcheu: what actually triggers the DMA to start?
15:17 < marcheu> MEMFORMAT_OFFSET_IN does
15:18 < darktama> it does? wouldn't that start the DMA before OFFSET_OUT/PITCH_*/etc are written?
15:19 < marcheu> well, I mean the MEMFORMAT_OFFSET_IN command and it's parameters
15:19 < marcheu> the fifo is not read one word at a time but really one command at a time
15:19 < marcheu> conceptually, at least
15:20 < darktama> ah, and what about partial writes.. I see a lone OFFSET_OUT just after the full OFFSET_IN+params
15:20 < marcheu> where ?
15:21 < darktama> http://pastebin.com/712734
15:22 < marcheu> hmm, looks like it's resetting the offset
15:22 < marcheu> I don't think that would trigger anything
15:23 < darktama> yeah, that's what made me ask what write actually starts it
15:24 < marcheu> hmm I wonder where swapbuffers is simplemented
15:25 < darktama> hmm, that's something I haven't thought of looking at yet :)
15:26 < marcheu> I didn't either. I hope it's not in the kernel
15:26 < darktama> I played with FBOs earlier, it seems that the hardware doesn't like using the same area as a texture and the color buffer at the same time
15:26 < darktama> not that I expected it to, but it'd be nice
15:27 < marcheu> the same as source & dest ? it's not supported by opengl IIRC
15:27 < darktama> the FBO spec allows it, but says the result could be undefined on some hardware
15:29 < darktama> if it did work, it'd make implementing all xrender ops in one pass *really* easy
15:29 < darktama> :)
15:39 < Lumag> Currently I'm examining objects.c. I would really ask a favor: please, don't define unkown fields to PRINT_X32, leaving them empty would provide nearly the same result, but it's much easier to detect them later.
16:01 < marcheu> talking about unknown, why don't we replace unkown objects with stuff from nv10reg ?
16:03 < darktama> that's not a bad idea
16:03 < darktama> is everything from cmds.c ported yet btw?
16:03 < marcheu> nope, nv20 stuff needs love
16:04 < marcheu> possibly others as well
16:04 < marcheu> with edb disappeared on ddl away from his nv20, I'm like the only nv20 owner left I think
16:04 < marcheu> s/on/and/
16:05 < darktama> :/
16:05 < darktama> I just ported the fragprog disasm (though, the output won't quite match the rest of the output) - will check the rest of the nv40 stuff is ported after I commit
16:06 < marcheu> ok, I've got a hacky renouveau at home that dumps a fifo, which I think is the DDX fifo
16:06 < marcheu> so we could look at xv/2D operations that way
16:07 < darktama> nice :) the ddx is too slow atm for my liking!
16:07 < marcheu> that's mostly because the DMA ops are synchronous. we need a DMA command queue in kernel that wraps the notifier system
16:08 < marcheu> I'm not too sure how to get it to notify user spaces processes, however. I don't want to have polling
16:09 < darktama> me neither, the kernel side of things is still voodoo to me
16:10 < marcheu> heh, that's my favorite :)
16:10 < darktama> haha, I'll stick with nice (relatively) safe userspace for now!
16:12 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:19 < marcheu> darktama: 39 exists since NV04, and possibly NV03
16:21 < darktama> should I just add all arch's to now then?
16:23 < marcheu> at least all since nv04
16:26 < darktama> ok, done
16:27 < marcheu> I wonder if nv03 has it as well. would be useful
16:27 < darktama> does anyone have nv03?
16:28 < marcheu> you mean nv03 hw ?
16:28 < darktama> yeah
16:28 < marcheu> I do have one
16:29 < marcheu> old AGP 3.3v bus, though, so it requires finding an old AGP mobo
17:33 < marcheu> what about removing ported commands from cmds.c ?
17:34 < darktama> mm, not a bad idea
17:36 < marcheu> ok, I'll remove the NV10 stuff first
17:37 < marcheu> actually, I propose removing stuff from cmds.h
17:37 < marcheu> it makes more sense
17:37 < darktama> well, I *think* I've gotten everything from NV30_TCL_PRIMITIVE_3D now, you may want to double-check
17:38 < EdB|w> soory, i did have a look for long time, but why are you removing stuff  ?
17:38 < EdB|w> didn't
17:38 < marcheu> darktama: well, I'll do everyting, and port what remains
17:38 < darktama> EdB|w: renouveau interprets based on objects now, rather than commands
17:38 < marcheu> EdB|w: we are switching from the command-based scheme (where each object offset was described by a command) to an object-based scheme
17:39 < EdB|w> ok
17:39 < EdB|w> seem to be great
17:39 < marcheu> that's how nvidia hardware works, and it matches the existing documentation
17:39 < marcheu> it's great, except we have to port all the stuff
17:39 < EdB|w> :o)
17:45 -!- pmdata [i=patrice@ANantes-154-1-64-220.w81-53.abo.wanadoo.fr] has joined #nouveau
17:46 < marcheu> hmm, do we want NV30_TCL_PRIMITIVE_3D_STUFF_ENABLE or NV30_TCL_PRIMITIVE_3D_ENABLE_STUFF ?
17:50 < darktama> I prefer the former, but I don't really care :)
17:50 < pmdata> the most important is to know what STUFF is ENABLEd :)
17:50 < marcheu> well, we have to decide before I end that command rampage
17:50 < darktama> also, I just reproduced the NV30 fragprog issue here..
17:50 < marcheu> I prever the former as well
17:51 < pmdata> also, we should use same names between different chips
17:51 < marcheu> darktama: the infinite program issue ?
17:51 < marcheu> pmdata: if you see differences, just tell me. I'm reworking it right now
17:51 < darktama> yup, but in this case the entire program is 0x00000000 - there's no real commands
17:52 < darktama> it's while I'm messing with FBOs, my guess is the AGP memory is reused before we get a chance to interpret it
17:52 < marcheu> yeah, possibly
17:53 < marcheu> I think that was our "let's hope it's the right explanation or else we don't understand squat about what's happening" last time
17:53 < darktama> yup
17:55 < Lumag> darktama: you can check memory writes with mmtrace.
17:56 < marcheu> pmdata: btw did you notice the hole between nv10 clip planes 0,1 and 2,3 ? it looks like the last 2 clip planes are in there. that might mean the hardware is buggy
18:00 < darktama> marcheu: yup, that's what seems to be happening (in this case anyway).. when I bind the next renderbuffer, I'm seeing a DMA which overlaps the AGP area the fragprog was DMA'd from
18:01 < darktama> but, in NV30's case you said the 0x00000001 was never DMA'd.. so probably not the same issue
18:02 < marcheu> hmm, I think I know a nice interface for the scratch dma buffer kind of use
18:03 < marcheu> the kernel exposes two functions : a scratch dma buffer memory allocation function and a dma start function
18:03 < marcheu> then the kernel queues the dma and can track notifiers to know when the chunk of ram can be reallocated
18:04 < pmdata> marcheu> did not notice this clip plane hole
18:05 < darktama> sounds good
18:06 < pmdata> I think all 6 clip planes should be different, maybe the driver "optimizes" clip planes if a new clip plane is useless
18:08 < pmdata> does the test_clip_plane show this hole?
18:09 < marcheu> no, look at that :
18:09 < marcheu> #define NV10_TCL_PRIMITIVE_3D_CLIP_PLANE1       0x00000610
18:09 < marcheu> #define NV10_TCL_PRIMITIVE_3D_CLIP_PLANE2       0x00000640
18:09 < marcheu> a clip plane is 0x10 bytes. where are 620 and 630 ?
18:13 < pmdata> I don't know, does test_clip_plane show you them?
18:15 < pmdata> hm, maybe they are 660,670 instead?
18:16 -!- Duke` [n=gnu@ANantes-251-1-83-91.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
18:16 -!- `Duke` [n=gnu@ANantes-251-1-142-41.w86-210.abo.wanadoo.fr] has joined #nouveau
18:17 < marcheu> well, where are the 0x20 bytes from 620 to 640 then ? :)
18:18 < pmdata> the truth is out there
18:29 < pmdata> just modified the test_clip_plane command, using different values for each clip planes
18:29 < pmdata> I still only have 4 clip planes sent to gpu
18:29 < marcheu> yes, it's possible that 620 and 630 are broken in hardware
18:30 < pmdata> hum, I will commit the new test_clip_plane for you to test on other chips
18:30 < marcheu> yup, maybe it's specific to nv15 (but I don't think so, at least IIRC nv11 would only have 4 clip planes)
18:35 < pmdata> ok done, I also display available clip planes at start, it defines 1 to 6 different clip planes in turn, so send the output to a file
18:36 < marcheu> pmdata: btw I have a modified renouveau at home for you :)
18:36 < marcheu> you'll have to wait until this evening, though
18:36 < pmdata> after reading many nv docs, it seems nv15 is only a faster chip. The only difference I spotted is for lighting, recalculated on each pixel instead of interpolated between each vertex
18:36 < pmdata> there is also the video output stuff
18:37 < marcheu> I don't think nv15 calculates per-pixel lightning by defautl, but only through extensions
18:37 < pmdata> but the difference with nv11 is twinview
18:37 < marcheu> well, some nv11 feature dual screen too
18:37 < pmdata> yeah, I would like to try specific nv15 stuff, but on delphi3d, extensions listed between nv10-nv15 are the same
18:38 < marcheu> yup, which is why I think it's the same from a 3D POV
18:38 < pmdata> yep, and maybe the per-pixel lighting is internal, and no extra coding is required
18:39 < marcheu> I don't think so. per-pixel lighting is basically a dot3
18:39 < marcheu> so since all nv1x have it, I'd say it's not nv15-specific
18:40 < marcheu> to be honest, we have yet to find differences between chips of a same family (the only one we found was about specifying line width on nv20 vs nv25, which was in different units)
18:40 < pmdata> ah
18:42 < marcheu> ok, all that's left for porting is :
18:42 < marcheu> - nv10 clears
18:42 < marcheu> - all nv20
18:43 < marcheu> - nv10 drawpixel stuff, which I think was some MEMFORMAT anyway
18:43 < marcheu> - a seemingly nv40-specific depth func command
18:44 < marcheu> I'll look at nv20 this evening I think
18:45 < pmdata> is gl[push|pop]attrib a gpu thing?
18:45 < marcheu> usually not. mesa handles it in sw anyway
18:46 < marcheu> now maybe nvidia implements it in hw, I don't know
18:48 < marcheu> darktama: could you look at what is NV40_DEPTH_FUNC             0x00000a60  exactly ?
18:49 < darktama> sure
18:49 < marcheu> it's strange that there's alreadu a depth func for standard 3D, I suspect it's a shader-only depth test
18:50 < marcheu> so, STUFF_ENABLE or ENABLE_STUFF ? last call...
18:51  * darktama votes for STUFF_ENABLE
18:53 < darktama> ahh, much better :)
18:53 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
18:54 < darktama> I added a quick hack to track DMA overlaps, and kill old records
18:54 < darktama> "Unable to determine address.." is much better than a screenful of crap
18:56 < pmdata> now that I read nv_objects.h, maybe listing stuff first, then substuff like enable or func is a better way
19:01 -!- pmdata is now known as pm_lawnmower
19:08 -!- jkolb [n=jkolb@130.57.22.69] has joined #nouveau
19:08 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
19:23 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
19:23 < marcheu> ok, I commited the cleanup
19:24 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has joined #nouveau
19:28 < darktama> ok, 0xA70 enables/disables writing to the depth buffer (glDepthMask)
19:40 < darktama> marcheu: have you ever seen 0xA60/A64/A68 change from 0x00000000?
19:41 < marcheu> IIRC A60 is the depth func on nv40
19:43 < darktama> the actual func is 0xA6C, but the others are undoubtedly related to depth somehow
19:44 < marcheu> well, according to cvs annotate I'm responsible for inserting this one. let's say I take the blame and you can remove it :)
19:44 < marcheu> (this one = 0xA60)
19:44 < darktama> a60's not in there is it?
19:44 < marcheu> in whet ?
19:44 < marcheu> what
19:44 < darktama> not in nv_objects.h
19:45 < marcheu> nope, it's in cmds.h
19:45 < darktama> ah
19:45 < marcheu> and I don't know what to do about it, since there's 0x00000a6c already
19:46 < darktama> eh?
19:47 < marcheu> yes, in cmds.h :
19:47 < marcheu> #define NV30_DEPTH_FUNC             0x00000a6c
19:47 < marcheu> #define NV40_DEPTH_FUNC             0x00000a60
19:47 < darktama> I'd get rid of the A60 one.. A6C definitely contains the depth func
19:48 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:48 < marcheu> you didn't see any A60 appearance ?
19:48 < darktama> nvidia does A60->A74 all at once
19:49 < marcheu> ah, ok
19:49 < marcheu> so, yeah remove it
19:49 < marcheu> (actually, I am the one who removes it)
19:49 < marcheu> (from my modified cmds.h)
19:58 -!- shenki [n=shenki@ppp173-99.lns3.adl4.internode.on.net] has joined #nouveau
20:21 -!- pm_lawnmower is now known as pmdata
20:25 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
20:27 < darktama> marcheu: it seems like swapbuffers uses NV10_CONTEXT_SURFACES_2D + NV12_IMAGE_BLIT
20:29 < pmdata> do you know what object type 4a could be? I have it when doing glClear(), and some commands with parameters being width and height of buffer to clear
20:30 < darktama> 4A is NV4_GDI_RECTANGLE_TEXT
20:30 < darktama> see nvreg.h in the Xorg driver
20:32 -!- Duke_ [n=gnu@LNeuilly-152-22-64-21.w80-14.abo.wanadoo.fr] has quit ["SIGKILL"]
20:32 < pmdata> then it uses it to clear color buffer on nv1x
20:33 < pmdata> or else it means some 2d operation
20:34 < pmdata> what sort of commands exist for  NV4_GDI_RECTANGLE_TEXT?
20:35 < darktama> hmm, I'm not sure.. it doesn't look like it's actually used in the ddx
20:35 < darktama> the object is created with NvRectangle as a handle, but I can't see it used
20:38 < Lumag> pmdata: what commands do you have? can you post a dump?
20:39 < darktama> pmdata: oh, wait.. I was grepping for the wrong thing.. check the RECT_* defines in nv_dma.h
20:43 < Lumag> Happy owners of >= nv30, could you please verify, that I wouldn't mess up things with http://lumag.spb.ru/nouveau/objects-cleanup-nv30-tx.diff
20:43 < pmdata> pmdata.wait(darktama);
20:44 < darktama> ?!?
20:47 < pmdata> so you want a dump?
20:47 < darktama> Lumag did
20:47 < Lumag> yes, please.
20:47 < Lumag> ?
20:48 < darktama> Lumag: that patch seems to be fine
20:48 < Lumag> ok. will commit after cleaning other bits.
20:50 < Lumag> thanks for checking
20:52 < darktama> np
20:52 < darktama> btw, how do you use bitfields in C?  I've never done it before :S
20:56 < pmdata> I commited NV4_GDI_RECTANGLE_TEXT along with value to use for fill
20:56 < Lumag> you mean that high:low? well... Just 1?high:low, 0?high:low :)
20:57 < darktama> I mean, is it possible to use those defines to say, fill those particular bits with a value
20:57 < pmdata> int field0:1; int field1:5;
20:58 < darktama> instead of "blah |= ((val << shift) & mask)"
21:01 -!- marcheu [n=marcheu@lattice.u-strasbg.fr] has quit [Read error: 101 (Network is unreachable)]
21:02 < Lumag> darktama: well... it gives a bit ugly code, but it's possible. blah |= (val & (0xffffffff >> (31 - 1?bf + 0:bf))) << (0?bf)
21:02 < darktama> oh, in that case I'll stick with my nice shift/mask combos :)
21:03 < darktama> and, I understand how that works now.. and feel really stupid for not noticing it..
21:03 < darktama> I use it all the time it's the quick if/else :)
21:06 < Lumag> well... the reason for removing nearly all code from texture.c was keeping all information in nearly single place (objects.c). Maybe that PRINT_BITFIELD should be reimplemented as mask + shift...
21:08 < darktama> imo, that's perfectly fine for renouveau's case.. I'd just rather not have it that way for the driver itself
21:08 < darktama> I'm trying to create the necessary headers for the driver as I go
21:09 < Lumag> I think that nv_objects.c should be shared with the driver.
21:10 < Lumag> There is no point in duplicating info...
21:10 < darktama> yup, I agree
21:10 < Lumag> I meant nv_objects.h
21:11 < darktama> So shift/mask would be easier to handle in the driver? or perhaps it'd be easier to use high:low and wrap setting/clearing bitfields in a macro?
21:12 < darktama> high:low certainly looks cleaner in the header...
21:47 < `Duke`> huhu now the output of renouveau cvs is 135 MB plain text with the fp bug for NV30 :O
21:47 < darktama> :S
21:48 < darktama> what was it before?
21:48 < `Duke`> 8 MB
21:49 < darktama> hmm, we really need to track that down
21:57 -!- marcheu [n=marcheu@lattice.u-strasbg.fr] has joined #nouveau
21:59 < Lumag> marcheu: I got your mail. Everything seems ok. I think I should remove that "REPORT".
22:00 < Lumag> hash seems to be "open hashing". the hash we get via bitstuffing seems to be only the starting point. I think, if all object are written lineary from the start of HT, everything would be ok. The hw would just waste time trying to find the right object.
22:01 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
22:17 -!- svu [n=svu@host-194-46-249-196.dsl-ie.utvinternet.net] has quit [No route to host]
22:18 -!- svu [n=svu@194.46.168.79] has joined #nouveau
22:38 -!- katakombi [n=kombrisn@dslb-084-056-151-119.pools.arcor-ip.net] has quit [Remote closed the connection]
22:49 < pmdata> does anyone has channel logs? I want to retrieve when clearing depth (or color buffer) was done in 8 passes
22:50 < Lumag> pmdata: logs since 10 Jun
22:52 < pmdata> maybe it is in
22:53 < pmdata> url?
22:53 < Lumag> one moment...
--- Log opened Птн Июн 16 22:54:24 2006
22:56 < Lumag> lumag.spb.ru/nouveau/irclogs/
23:00 < pmdata> from what I read there, it was before 10 jun
23:00 < pmdata> but it is nice read for this week log :)
23:00 < Lumag> :)
23:02 < marcheu> Lumag: which mail ?
23:04 < Lumag> marcheu: sorry, I confused names in from headers :)
23:04 < marcheu> is the nv30-tx stuff agreed by someone with a nv40 ?
23:04 < marcheu> I somehow lost connectivity
23:04 < marcheu> if it needs testing, I'll do it, just tell me
23:05 < Lumag> darktama said, that the patch is ok. Anyway it's in CVS now.
23:05 < marcheu> if it's tested that's ok
23:05 < marcheu> then I can switch cards and plug the nv28 :)
23:06 < darktama> it seems fine
23:06 < marcheu> Lumag: btw we should stick with the official naming I think
23:06 < darktama> marcheu: btw, those unknown instructions in the lighting vtx progs.. I think I know what's happening
23:07 < marcheu> Lumag: or is CONTEXT_CLIP_RECTANGLE the real naming somewhere else ?
23:08 < darktama> it seems you con co-issue the two "types" of instructions, there's a second location in the opcode for temp reg & writemask.. probably other things too
23:08 < marcheu> darktama: huh ?
23:08 < Lumag> marcheu: nvhw32.h
23:08 < Lumag> and what do you mean by 'the official' one?
23:08 < darktama> ie. you can pack a LIT and a MUL into one instruction
23:09 < marcheu> Lumag: one that comes from one of the exeisting source files
23:09 < Lumag> yup.
23:09 < marcheu> Lumag: ok, I prefer that one anyway
23:10 < marcheu> darktama: can you do that with all instructions ?
23:11 < darktama> not quite, there seem to be two different groupings of instructions
23:11 < pmdata> ah, refound it, clear in 8 passes if buffer is 2^n width
23:11 < marcheu> pmdata: cool, if you could port the remaining NV10 commands that'd be nice
23:11  * marcheu reboots with the nv28
23:12 < Lumag> BTW: it seems that some objects are even from the nv1 :) Do we want to write the driver for those 'Diamond Edge 3D'? :))
23:12 < marcheu> no, we don't wan't to support NV01. it's too different from other cards
23:13 < marcheu> like, it doesn't have textured triangles
23:13 < Lumag> Just joking
23:13 < marcheu> instead it has quadratic surfaces
23:14 < marcheu> well, supporting it might be an idea if it wasn't that strange
23:14 < marcheu> for example nv03 would perfectly fit within the current driver model
23:16 < pmdata> marcheu> this is what I was doing, adding stuff that was still in old cmd.h
23:16 < pmdata> isn't there a macro that prints 2 16 bits value (which are in a 32 bits word)?
23:16 < darktama> marcheu: I'm not entirely certain yet (I've never seen the driver combine instructions for user-specified programs), but a modified disasm_vp shows lighting progs that make much more sense
23:17 < darktama> if you look at the current disasm, you'll see reads from temps that are never written.. and things like that
23:18 < marcheu> pmdata: MACRO16
23:18 < marcheu> darktama: so these temps are actually used for the combined instructions ?
23:19 < darktama> the "second" instruction appears to write them, yes
23:20 < pmdata> marcheu> print_macro16() wants a parameter
23:20 < darktama> it also explains why some instructions use a different part of the opcode for the writemask
23:20 < marcheu> pmdata: ah, if you only want 16 bit hew, you have to do it yourself
23:20 < pmdata> :)
23:21 < Lumag> pmdata: just use PRINT_BITFIELD(15:0, .......)
23:22 < marcheu> heh, since when is there a PRINT_BITFIELD ?
23:24 -!- jkolb [n=jkolb@130.57.22.69] has quit ["Leaving"]
23:25 < pmdata> luma: can I use it to display 2 16bits values?
23:27 < pmdata> hum, yes, I should use the source
23:27 < Lumag> marcheu: since the 1.1 version
23:27 < Lumag> pmdata: yes
23:32 < pmdata> yes, and when a command use 2 parameters of this type?
23:33 < pmdata> should I defined an extra command?
23:33 < Lumag> yes.
23:37 < pmdata> hum, too bad I can't define a mask
23:39 < Lumag> pmdata: hmm. what exactly do you want to do?
23:41 < pmdata> see in cvs, for nv04_gdi_rectangle_text, for right/left values, bits 0-1 should be masked out, for example, for a 512x512 clear, I have (l,t,r,b) = (3,0,515,512)
23:43 < Lumag> strange...
23:44 < pmdata> it seems bits 0-1 are used for something else in the operation
--- Log closed Сбт Июн 17 00:00:29 2006
