--- Log opened Срд Авг 23 00:00:20 2006 00:00 < KoalaBR> Any other paste service except for rafb? 00:00 < pmdata> pastebin 00:01 < cptn> or sh.nu/p 00:01 < KoalaBR> Thanks 00:06 < KoalaBR> pmdata: Sorry, my fault it took so long. Here it is http://pastebin.com/773453 00:06 < phh> or pastebin.ca or pastebin.debian.org 00:07 -!- Myrizio [n=Myrizio@host74-96.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)] 00:07 < KoalaBR> if you have a better accumulation buffer test, just let me know.... 00:08 -!- Myrizio_ is now known as Myrizio 00:08 < pmdata> isn't it the test_swap_buffers() test? 00:10 < KoalaBR> THis one? No, I just tried to create one for myself after some code snippets I found on the Net which tried to explain the accum buffer concept / functionality 00:10 < KoalaBR> This was my first try 00:11 < pmdata> then maybe you could look around lines 512-522, it setup the color0 buffer differently 00:11 < KoalaBR> And at the time I wrote it, i didn't find anything regarding accum buffer in test.c 00:11 < KoalaBR> tests.c of course 00:12 < pmdata> test_swap_buffers() is the last one 00:12 < pmdata> try it 00:13 < KoalaBR> Ok, just a moment 00:14 < KoalaBR> http://pastebin.com/773460 (run as fullscreen 1280x1024) 00:17 < KoalaBR> Want a dump run in window mode too? 00:18 < pmdata> no, only fullscreen double buffer 00:19 < pmdata> I see the extra objects created for nv30 (or nv40) you have 00:21 < KoalaBR> Compared to those mention in your nv10_object doc? 00:21 < pmdata> yep 00:22 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [] 00:22 < pmdata> you have object type 66 that holds many objects (lines 453-460) 00:23 < pmdata> hum I think the dump is not complete 00:23 < pmdata> enable output to multiple files, uncomment test_startup and test_default along with test_swap_buffers 00:23 < pmdata> and redump 00:23 < KoalaBR> Just a moment 00:24 < pmdata> hum 66 is an unknown nv40 object 00:26 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau 00:27 < KoalaBR> http://pastebin.com/773473 (startup) 00:27 < KoalaBR> http://pastebin.com/773474 (default) 00:28 < KoalaBR> http://pastebin.com/773475 (swap_buffers) 00:34 < KoalaBR> 0x0200 only during startup 00:34 < KoalaBR> DIdn't see them anywhere else 00:35 < pmdata> hum it seems your nv40 uses its clear buffer command instead of swapping video pointers 00:38 < KoalaBR> I can / will run any tests you want me to and if you give me a pointer to what I should be looking for, I'll try to analyse the results. But for today I need to go to bed. 00:39 < KoalaBR> As I read the logs, just post what you want me to do and I will report back tomorrow :) 00:40 < pmdata> I think I will add the object 66, so we can see what objects it uses 00:42 < KoalaBR> Ok, will try it out tomorrow evening and report back... 00:43 < KoalaBR> Still wondering about 0x0200 though... 00:43 < KoalaBR> Good night all 00:43 -!- KoalaBR [n=KoalaBR@port-83-236-14-219.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"] 00:44 < pmdata> ah, seems I forgot Option "TVOutFormat" and Option "TVOverScan" 00:45 < airlied> darktama: your fd.o a/c should be working btw.. 00:56 -!- Gloubi [n=Gloubi@ABordeaux-253-1-101-88.w86-196.abo.wanadoo.fr] has joined #nouveau 00:57 -!- Gloubi [n=Gloubi@ABordeaux-253-1-101-88.w86-196.abo.wanadoo.fr] has left #nouveau ["I'll be back"] 01:05 < pmdata> hup object 66 seems to be the one used to clear a buffer for nv40 tcl 'clear buffer' command 01:08 < pmdata> nv30 also has it 01:10 < pmdata> ... and g70 01:26 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau 01:27 < pmdata> many objects still not marked for g70 though 01:27 < pmdata> will fix that 01:40 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection] 01:41 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection] 01:43 < pmdata> marcheu> I think you could remove the NV15 bitmask in renouveau 01:46 < marcheu> yup 01:46 < marcheu> you can do it as well :) 01:47 < marcheu> but it's really amazing to see that the geforce4 mx is nothing more than a faster geforce 1 :) 01:50 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Remote closed the connection] 01:50 < stillunknown> geforce4 mx is more likely based on a geforce2 mx or gts 01:50 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit [""] 01:50 < marcheu> well, all cards have the same level of functionatity 01:50 < pmdata> gf2mx = gf1 + lma, gf4mx = gf2 + lma 01:50 < marcheu> pmdata: btw did you see lma in some nv11 dumps ? 01:50 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau 01:50 < pmdata> I forgot also the second crtc for 'twinview' 01:50 < marcheu> pmdata: from what I saw on the net, lma is only nv17+ 01:51 < pmdata> do we have nv11 dumps? 01:51 < marcheu> well, I have a nv11 on my desk at least 01:51 < marcheu> so we potentially have nv11 dumps 01:52 < pmdata> you're right, no lma on nv11 01:52 < pmdata> I even marked it as NV17, so :) 01:52 < stillunknown> maybe an idea to focus effort on a few cards across the spectrum and fill holes later? 01:52 < pmdata> gf2mx = gf1 + 2v, gf4mx = gf2 + lma + 2v 01:53 < Duke`> lma = ? 01:53 < marcheu> 2v = ? 01:53 < pmdata> 2v = twinview 01:53 < marcheu> ah :) 01:53 < pmdata> lma = light memory architecture 01:53 < marcheu> lightspeed ! you have to talk the buzzword language correctly ! :) 01:54 < marcheu> lma basically consists in leveraging ati's hyperz :) 01:54 < pmdata> I noticed the latest ati driver as the 'pairmode' feature, guess what it is 01:55 < marcheu> pmdata: btw when lma is used, did you notice some additional allocations ? 01:55 < marcheu> I'm wondering where the lma buffer is sitting... on ati it was on-chip, on nvidia it seems to ve in vram 01:55 < pmdata> hum there is the lma depth buffer (a different offset from depth/stencil is used) 01:55 < marcheu> ok, so it is in vram 01:55 < pmdata> it is not on chip, at least not on nv17 01:55 < marcheu> that's nice, because we can play with it directly if we want 01:56 < pmdata> what features could we use it for? 01:56 < stillunknown> are you guys documenting things properly? 01:56 < pmdata> of course not, we don't have nvidia doc 01:56 < pmdata> but what is currently documented seems to match what we see 01:57 < marcheu> pmdata: hmm, maybe we could play with hierachical occlusions or such 01:57 < stillunknown> i mean, are you documenting all the functions that are being created and such 01:58 < pmdata> well, we try to document the various chip features 02:01 < stillunknown> good luck and good night 02:05 < marcheu> 'night 02:05 < marcheu> pmdata: btw don't you want to write code with us now ? 02:05 < marcheu> I mean, you pretty much have nv10 inside out 02:06 < marcheu> where "code" means "driver code" of course... 02:08 < pmdata> I am afraid of working on it :) 02:09 < pmdata> I don't know much about kernel and X organization, when writing a driver 02:09 < marcheu> I suppose you could ask questions... 02:10 < marcheu> and I suppose we might answer 02:12 < pmdata> writing code demand much more time and dedication than reading dumps and saying 'this is feature x' 02:12 < b33fc0d3> this is feature x 02:12 < b33fc0d3> i win =) 02:12 < phh> this should be in fact feature y. 02:13 < pmdata> but feature x would need feature y setup in the z way 02:14 < phh> yeah but the a projet use de u way, which (what they say) looks better 02:23 -!- pmdata [i=patrice@ANantes-154-1-70-87.w86-195.abo.wanadoo.fr] has quit [Remote closed the connection] 02:46 -!- Duke` [n=gnu@ANantes-251-1-87-38.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"] 02:49 -!- phh [n=phh@moi.phhusson.info] has quit ["Quitte"] 02:55 -!- Unbeliever [i=hazel@85-57-135-18.gij1.adsl.uni2.es] has quit [Remote closed the connection] 03:03 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [] 03:17 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau 03:19 < marcheu> so, I suspect there's a kind of race after object creation 03:20 < marcheu> I added some debug information that reads PRAMIN from the card to check it, and my timeouts disappeared 03:20 < marcheu> so either the time it takes or the fact that I rean PRAMIN does something 03:20 < marcheu> read 04:15 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit [""] 04:17 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau 05:11 -!- b33fc0d3 is now known as b33fc0d3_ 05:33 -!- Myrizio [n=Myrizio@host28-98.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"] 06:24 -!- etzel_ [n=thisnuke@west-193.rcn.NMT.EDU] has joined #nouveau 06:24 -!- etzel [n=thisnuke@west-193.rcn.nmt.edu] has quit [Read error: 104 (Connection reset by peer)] 06:26 -!- etzel_ is now known as etzel 06:39 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau 07:05 -!- shenki [n=shenki@121.44.128.190] has joined #nouveau 07:05 -!- shenki_ [n=shenki@121.44.128.190] has quit [Read error: 110 (Connection timed out)] 07:52 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit [""] 10:09 < darktama> pmdata: according to nv10reg, 0x66 is NV4_IMAGE_SRCCOPY_PREMULT 11:39 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau 12:02 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau 12:08 -!- Unavowed [n=silent@host81-158-96-24.range81-158.btcentralplus.com] has joined #nouveau 12:38 -!- EdB [n=EdB@ARennes-251-1-151-200.w86-214.abo.wanadoo.fr] has joined #nouveau 13:01 -!- Duke` [n=gnu@ANantes-251-1-141-157.w86-210.abo.wanadoo.fr] has joined #nouveau 13:17 -!- shenki [n=shenki@121.44.128.190] has quit [Read error: 110 (Connection timed out)] 13:18 -!- shenki [n=shenki@121.44.69.112] has joined #nouveau 13:22 -!- EdB [n=EdB@ARennes-251-1-151-200.w86-214.abo.wanadoo.fr] has quit ["Konversation terminated!"] 14:50 -!- b33fc0d3_ is now known as b33fc0d3 15:07 -!- Myrizio [n=Myrizio@host65-102.pool80104.interbusiness.it] has joined #nouveau 15:15 -!- abhijit [n=abhijit@61.95.198.26] has joined #nouveau 15:16 -!- abhijit [n=abhijit@61.95.198.26] has quit [Remote closed the connection] 15:25 -!- abhijit [n=abhijit@61.95.198.26] has joined #nouveau 15:26 -!- abhijit [n=abhijit@61.95.198.26] has left #nouveau [] 15:44 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau 15:56 -!- b33fc0d3_ [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau 15:57 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 54 (Connection reset by peer)] 15:58 -!- Myrizio [n=Myrizio@host65-102.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)] 15:59 -!- Myrizio [n=Myrizio@host225-96.pool80104.interbusiness.it] has joined #nouveau 16:06 -!- pmdata [i=patrice@ANantes-154-1-103-218.w86-214.abo.wanadoo.fr] has joined #nouveau 16:07 < pmdata> ping darktama 16:08 -!- b33fc0d3_ is now known as b33fc0d3 16:10 < darktama> pmdata: pong 16:11 < Duke`> 4 packets transmitted, 3 received, 25% packet loss, time 2min 57sec 16:11 < pmdata> I read your remark about object 0x66, the fact is that all nv1x and nv2x dumps I have don't show this object in test_startup 16:11 < pmdata> so there is an object 0x66 for nv0x and a different one for nv3x 16:12 < pmdata> the dumps in nouveau.sf.net for nv0x don't show it also 16:12 < darktama> yes, that's possible.. like the 0x97 overlap on NV20 and NV30/40/G70\ 16:12 < pmdata> which test trigger this object on nv0x? 16:12 < darktama> I don't know, I just remembered seeing the object in nv10reg.h 16:13 < pmdata> I think this is lumag who posted the nv0x dumps, maybe he should update them 16:13 < pmdata> or marcheu has one on his test machine, I should check it myself 16:17 < darktama> argh 16:18 * darktama gets annoyed with people who think AIGLX == GLX_EXT_texture_from_pixmap 16:19 < phh> darktama, ho if it's only that there is no prob... 16:19 < phh> me it's with people who think 3D Deslkop = Xgl 16:20 < darktama> yes, that shits me aswell :) 16:20 < phh> darktama, does aiglx adds api ? 16:20 < phh> or it's simply little modification in drivers ? 16:21 < darktama> AIGLX is support for accelerating indirect GL contexts (where the X server renders on behalf of the X client) 16:21 < phh> yep i know 16:21 < phh> but how is it done ? 16:22 < darktama> no idea, I guess the Xserver creates a direct context.. and just forwards the GLX requests on.. but I have no idea 16:30 < marcheu> pmdata: the object varians usually have a card prefix, like 3097 for nv30's 97 and 2097 for nv20's 97 16:31 < pmdata> marcheu> is your test machine down? 16:31 < marcheu> yeah, in theory, AIGLX doens't need driver changes. in practice, bugs pop up 16:31 < marcheu> pmdata: no 16:32 < phh> i hope nouveau with aiglx will works :p 16:32 < marcheu> pmdata: let me guess... new ip ? :) 16:32 < phh> (at least have texture_from_pixmap would be nice) 16:32 < pmdata> yep for ip, where do I see the card prefix in the object 16:33 < marcheu> it's shown when the object is created IIRC 16:34 < phh> is there many code in the Xorg driver? I wonder if using OpenGL directly without Xorg (with DirectFB or Xegl for instance) is hard or not 16:35 < pmdata> unfortunately, the object creation list is not dumped, so I need someone with nv30/nv40/g70 to tell me more about beef6601 16:35 < marcheu> some open source drivers support miniglx, which is opengl over FB 16:36 < marcheu> pmdata: if you add support for it in renouveau, I can dump it on nv30 & g70 16:39 < pmdata> renouveau already has it, so you can check this 16:40 < pmdata> your 10de:002c don't show object 66 16:43 < Duke`> after having sent my laptop (with nv6200) to Acer Support, and after they lost it and sent me a new one but with an i915, Acer proposes me a new laptop with an ATI X700... what do you think? is X700 well supported with FOSS drivers? 16:44 < Duke`> hum the guy sent me the pdf with the new laptopt with i915 too... with i915 that could be interesting :P 16:44 < phh> Duke`, alle. 16:44 < phh> ol* 16:45 < phh> Duke`, c'est pas tout fait les meme perf 16:45 < Duke`> ah non c'est un i915M, pas GM :( 16:46 < Duke`> phh : par rapport à la nv6200 ? 16:46 < phh> ah 6200 16:46 < phh> mm 16:47 < Duke`> m'enfin à la limite je m'en moque des perfs, je veux un bon support par des pilotes libres 16:57 < pmdata> marcheu> can renouveau works without the nvctrl stuff? 16:58 < phh> Duke`, soit l'ati soit l'intel 16:58 < phh> m'enfin l'intel c'est un support oficiel 16:58 < phh> ati pas 16:58 < pmdata> ou, ati+ portable = forte odeur d'ours 16:59 < phh> ah bon ? 16:59 < phh> je connais qqu que si 16:59 < Duke`> ça chauffe ? 16:59 < phh> (pourtant il rale des qu'il perd 1m d'autonomie) 16:59 < phh> ha mais il a les drivers proprio 17:00 < phh> Duke`, oui en fait les drivers libres n'ont pas "l'idle" du ventilo 17:00 < Duke`> mauvais ça 17:02 < Duke`> ça a l'air un peu pénible au niveau de la carte graphique ce qu'il me propose justement... https://wiki.ubuntu.com/LaptopTestingTeam/AcerAspire1692WLMi 17:04 < Duke`> si c'est pour se tapper du vesa... 17:04 < phh> if it can help i have a NVIDIA 5700LE (NV36) and a NForce2 integrated able to make some tests 17:09 < pmdata> hum, maybe nf2 dumps would be interesting, is it equivalent to a gf2, 3 or else? 17:10 < pmdata> hum, nf2 = nv1x 17:10 < pmdata> is there some difference against a classic gf2? 17:11 < pmdata> maybe using a part of system ram as video ram? 17:12 < phh> pmdata, a gf4mx iirc 17:12 < phh> and yes it use system ram 17:12 < phh> there is no video ram 17:12 < pmdata> ah, maybe it would show different objects used instead of the ones related to vram 17:13 < phh> it's a NV18 (gf4mx) says lspci 17:15 < pmdata> then you can try renouveau, and post a url about the object list created (first thing renouveau output) 17:15 < marcheu> pmdata: probably, nvctrl only used to detect the bus type 17:15 < marcheu> yeah, that'd be interesting to see how things work on nforce 17:16 < pmdata> marcheu> could you make a patch to disable nvctrl stuff if needed, please? 17:18 < phh> Card has id 0x10de01f0 (NV15) bus is AGP (0 Mb video ram) 17:18 < marcheu> yup, 0MB is normal 17:19 * phh se gratte la tte 17:19 < phh> boum. 17:19 < phh> right 17:19 < phh> on a KDM it isn't really right... 17:20 < phh> X Error of failed request: BadWindow (invalid Window parameter) 17:20 < phh> Major opcode of failed request: 145 (NV-GLX) 17:20 < phh> Minor opcode of failed request: 4 () 17:20 < phh> Resource id in failed request: 0x320000f 17:20 < phh> Serial number of failed request: 24 17:20 < phh> Current serial number in output stream: 24 17:20 < phh> hum... 17:21 < pmdata> you should check your var/log/X*.log file 17:22 < phh> segfault \o/ 17:22 < pmdata> did you installed the nvidia drivers? 17:22 < phh> yeye 17:22 < phh> and xmoto works fine 17:22 < pmdata> 7182 or older? 17:22 < phh> there is chances yes 17:23 < phh> 8762.. 17:23 < pmdata> hum, maybe there are even still supported and recent drivers 17:23 < phh> NVRM: loading NVIDIA Linux x86 Kernel Module 1.0-8762 Mon May 15 13:06:38 PDT 2006 17:23 -!- Koala_BR [n=KoalaBR|@195.227.227.59] has joined #nouveau 17:23 < marcheu> pmdata: what's wrong with using NV_OLD ? 17:23 < phh> pmdata, hu ? 17:23 < phh> pmdata, it's still the "main tree" not legacy one 17:24 < phh> (if it's what you mean) 17:25 < Koala_BR> pmdata: Just to let you know: Will test current renouveau later this evening on my NV43. What do you need? test_startup() dump? 17:25 < phh> so ? 17:26 < phh> ok forget ... 17:26 < pmdata> yep, I just checked it is still supported in 8762 17:26 < phh> (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X 17:26 * phh don't understand that 17:26 < phh> 3D works .. 17:26 < phh> or worked some time ago at least 17:26 < pmdata> does glxinfo works? 17:27 < phh> no.. 17:27 < phh> why my sister does complain about everything but not about it 17:27 < pmdata> try to reinstall the driver then 17:28 < pmdata> maybe the kernel driver is missing? 17:28 < phh> nop the kernel driver is ok 17:28 < phh> it's only glx part which doesn't works ... 17:28 < phh> 2D works 17:29 < marcheu> usually it's one of libGL/libGLCore*.so which come from mesa, and a driver reinstall fixes that 17:29 < marcheu> pmdata: so, NV_OLD works ? 17:30 < pmdata> marcheu> wasn't it only for old drivers? 17:31 < marcheu> old driver which don't have nvctrl. isn't that what you want ? 17:32 < pmdata> not exactly, I want to try to compile renouveau for win32 :) 17:32 < marcheu> oh 17:32 < marcheu> god 17:32 < phh> hhu 17:32 < pmdata> there is a demo prog on nvidia site that lists the pci devices 17:32 < pmdata> so the missing part is hoping that cygwin has a working mmap() 17:33 < marcheu> what do you mean "lists the pci devices" ? 17:33 < pmdata> well, it enumerates pci devices on the system 17:33 < marcheu> and how is that useful to porting renouveau to win32 ?. 17:33 < pmdata> and display only the vendor_id = 0x10de ones 17:34 < pmdata> I hope to trigger new commands or objects 17:34 < marcheu> yes, I understand that 17:34 < marcheu> but my point is that pci device enumerator + mmap is not enough for a port 17:34 < phh> pmdata, and why not begin rewriting Direct3D but for linux ? :p 17:35 < marcheu> under linux, we have /dev/nvidia0 which is quite easy to use : open ; mmap ; access the regs. Under windows you'll have to figure out how to do that 17:35 < pmdata> I do some win32 code at work, (besides some linux and java) 17:36 < darktama> do windows graphics drivers even run in userspace? I recall something about Vista having them in userspace, and assumed that meant pmdata: maybe if you're lucky, /dev/mem works with cygwin 17:37 < phh> darktama, same as you 17:37 < Koala_BR> Grafics are done in kernel mode since NT 4.0. Nt3,.51 had it in user space (or a lower "ring" than the kernel itself 17:37 < marcheu> pmdata: then you'd be able to map physical adresses. I suppose that'd work 17:38 < marcheu> pmdata: but you'd have to create all the mappings yourself, including one for the fifo 17:38 < phh> Koala_BR, now they only know ring 0 and ring 3 :/ 17:38 < marcheu> actually, the r300 guys have a win32 analyzer, because the fglrx driver weren't good enough 17:39 < phh> http://pastebin.ca/146255 for the nForce2 card 17:39 < darktama> marcheu: hmm, how new is that? I only recall using glxtest 17:39 < Koala_BR> phh: Yes .. 17:39 < marcheu> darktama: aet has one, I'm not sure if he distributed it too far 17:39 < darktama> ah 17:39 < marcheu> darktama: but it's on that unplugged harddrive I have next to me 17:39 < marcheu> of that, I'm sure 17:40 < phh> pmdata, you saw the created objects ? 17:42 < pmdata> only one more: object creation: beef0381, type 89, parent beef000b 17:42 < pmdata> apart from that, I see 177c and 1796 instead of 7c and 96 on my nv15 (so they are the nv17 version of it) 17:43 < phh> lspci says NV18, renouveau says NV15 and it's in fact NV17 ? 17:43 < phh> huhu :) 17:43 < pmdata> nv18 = nv17 with agp8x support 17:44 < pmdata> nv17 = nv15 + twinview + lma 17:44 < phh> i don't remember this mainboard supports agp 8x 17:44 < pmdata> the chip supports it, but you can have a 4x or less motherboard 17:44 < phh> it's intelligent to make in the same chips, not the same :p 17:45 < pmdata> this is "upgrade" 17:46 < pmdata> so could you try the test_swap_buffers() (the last one in renouveau, it requires fullscreen, double buffer, and the desktop size for video mode) 17:47 < phh> and i past what ? 17:48 < phh> the whole output ? 17:48 < marcheu> darktama: so, yesterday's fix didn't work. but there's something fishy with the RECT_SOLID setup 17:48 < marcheu> I think it's not setup properly. since the exa patch 17:49 < phh> pmdata, http://zonelibre.ath.cx/~phh/nforce.log 17:49 < darktama> hmm, interesting.. the crashes I had when looking at notifier irqs were in RECT_FORMAT.. 17:49 < marcheu> yeah 17:50 < marcheu> I suppose there's a bit unset in the object context 17:50 < marcheu> since that also affects xaa 17:52 < marcheu> anyway, I put so many debug changes in the DDX that it doesn't even startup now :) have to go back from a clean state 17:52 < pmdata> phh> did you set double buffer? 17:52 < phh> pmdata, SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER,1); 17:52 < phh> ? 17:53 < pmdata> yes 17:53 < phh> so yes 17:53 < phh> why ? 17:53 < phh> hum 17:53 < phh> different bpp maybe 17:53 < pmdata> because it does not use object 7c to change video pointer, it does a blitcopy from back to from instead 17:53 < phh> (between desktop and SDL) 17:54 < darktama> marcheu: nope, the objects are the same (for NV40 at least) 17:54 < marcheu> darktama: when comparing "nouveau" to "nv" ? hmm 17:54 < darktama> http://sh.nu/p/2847 17:54 < marcheu> can't click, console mode 17:54 < darktama> ah, 17:55 < marcheu> actually, I hve links 17:55 < darktama> from nv: rest are 0x00000000 17:55 < darktama> 1030 pNv->PRAMIN[0x0838] = 0x0208004A; 17:55 < darktama> 1031 pNv->PRAMIN[0x0839] = 0x02000000; 17:55 < darktama> from nouveau: rest are 0x00000000 17:55 < darktama> Aug 21 00:51:57 araqiel [ 2234.875152] [drm:nouveau_object_instance_free] Instance entry for 0x80000016(engine 1, class 0x4a) before destroy: 17:55 < darktama> Aug 21 00:51:57 araqiel [ 2234.875218] [drm:nouveau_object_instance_free] +0x00: 0x0208004a 17:55 < darktama> Aug 21 00:51:57 araqiel [ 2234.875268] [drm:nouveau_object_instance_free] +0x04: 0x02000000 17:55 < pmdata> phh> I did not read the dump carefully, it does it, ouf 17:56 < phh> ok 17:56 < marcheu> darktama: hmm, that is starting to suck 17:56 < phh> (i admit it's really long to read :p) 17:58 < pmdata> just grep for nv10_video_display_offset 17:58 < darktama> marcheu: indeed, and it's present with nv+original EXA patch? 17:58 < marcheu> darktama: yup. even when using XAA 17:58 < darktama> ok.. 17:59 * darktama tries to find original patch 17:59 < marcheu> actually I should confirm that, but I pretty much remember it is 17:59 < marcheu> because the original EXA was always doing timeouts on me 17:59 < marcheu> nv-exa-3.patch it's called 17:59 < marcheu> it's @ p.fd.o/ãjax IIRC 18:00 < darktama> yup 18:00 < marcheu> of course, doesn't compile cleanly :) 18:00 < darktama> I was just going to look at it and hopefully see something obvious missing from nv_hw.c :) 18:01 < pmdata> marcheu> do you sleep sometimes? you are nearly always here 18:01 < marcheu> pmdata: hehe 18:04 < phh> pmdata, some other tests to do ? 18:05 < marcheu> actually, I wan't here this morning, I was on my VTT (whatever the name in english) 18:05 < phh> marcheu, montainbike :p 18:07 < darktama> marcheu: btw, what are the GET/PUT pointers when it hangs? 18:09 < darktama> haiku has some notes on the engine crashing under load when the engine is fetching 'in front' of where commands are being placed 18:09 < darktama> haiku leaves a much larger gap than we do 18:12 < marcheu> the 8-GAP ? 18:12 < darktama> yup, I think the ddx calls it SKIPS 18:12 < marcheu> yeah I tried with 16, no luck 18:13 < marcheu> how many has haiku ? 18:13 < darktama> 256, but I think they count in bytes.. so it'd be 64 for us 18:14 -!- K [i=hazel@85-57-135-18.gij1.adsl.uni2.es] has joined #nouveau 18:15 < pmdata> phh> the test_startup dump (uncomment DONT_DUMP_ABOVE_40000 in re.c) 18:15 < darktama> hmm, actually maybe they dont.. 18:16 < phh> pmdata, drop fullscreen & doublebuffer ? 18:17 < phh> http://zonelibre.ath.cx/~phh/nforce.2.log 18:19 < darktama> marcheu: any way to reproduce the crash reliably? 18:20 < marcheu> darktama: oh yeah, no problem 18:20 < marcheu> btw I think I'll commit a change that dumps the fifo on timeout 18:20 < darktama> hmm, might be a good idea.. NV_DMA_DEBUG=1 slows things down too much :) 18:21 < phh> pmdata, do i rerun with the last commit ? 18:22 < darktama> marcheu: I ran x11perf for quite a long time a few weeks back without problems. The only crashes I can reproduce are with the composite hook enabled 18:22 < marcheu> darktama: yeah, 6 months ago I spoke with lars, who said he experienced no crashes on his 6600. I guess it has to do with the fact that I run different hw 18:24 < darktama> hmm, actually.. I'm not getting crashes with the composite hook at the moment either.. was immediate before.. 18:25 < pmdata> phh no it's ok 18:25 < pmdata> it seems the 0a55 object is the one use to read the memory to be displayed by crtc (or dac) 18:26 < pmdata> on my nv15, the dma target is nvmem, and it is pci on nf2 18:26 < marcheu> will try 256 SKIPS 18:27 -!- shenki [n=shenki@121.44.69.112] has quit ["http://xkcd.com/comics/fourier.jpg"] 18:30 < pmdata> hum, nv10tcl[0x3fc] is set to 0xff on your first dump 18:30 < phh> it's bda ? 18:30 < phh> bad* 18:31 < pmdata> well, I only seen it before set to 0 18:31 < phh> hum 18:31 < pmdata> the question now is: what can it be? 18:32 < pmdata> this is a nv17 only stuff 18:32 -!- tibbs|h is now known as tibbs 18:32 < phh> pmdata, and on the second dump it's set to 0xff or 0x0 ? 18:32 < marcheu> darktama: nope, no improvemen 18:32 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit [""] 18:32 < pmdata> on the second, it is 0, as usual 18:32 < darktama> marcheu: :( 18:32 < pmdata> so try to run all the tests in a row (uncomment output_to_multiple_files in re.c) 18:33 < pmdata> then grep for 0x03fc/4 in the card_10de* dumps to see where it is changed 18:33 < marcheu> darktama: that wouldn't have explained why it works with "nv" 18:33 < darktama> true 18:33 < marcheu> darktama: I think I'll port parts of "nouveau" to "nv" until it works 18:34 < darktama> ouch, that's not going to be fun :S 18:34 < darktama> what hardware btw? 18:34 < marcheu> nv44 18:35 < phh> pmdata, *all* tests? 18:36 < pmdata> yes 18:36 < phh> it's long to uncomment 18:36 < marcheu> use vim ! 18:37 < phh> i use 18:37 < phh> but i don't use shortcuts :D 18:37 < phh> marcheu, how do you scritp that ? 18:37 < marcheu> ctrl-v is rectangular selection, then d 18:37 < phh> ah. 18:37 < phh> i never used visual mode 18:39 < phh> running..... zzzzzz 18:42 < phh> pmdata, it happen only with test_swap_buffers.txt 18:44 < phh> marcheu, when i set DOUBLEBUFFER to 0 it's 00 18:44 < phh> i check i reproduct it 18:44 < phh> it is 18:46 < phh> pmdata, ok so with both test_default and test_swap_buffers it is set to ff when DOUBLEBUFFER setted 18:48 < marcheu> phh: hu ? 18:48 < phh> marcheu, ben de ce que je comprends c'est quand je mets DOUBLE BUFFER 1 que NV10_TCL_PRIMITIVE_3D se met ff 18:49 < phh> euh 18:49 < phh> c'est sens tre un truc qui gere les lumieres ? 18:49 < marcheu> qu'est-ce qui gere les lumieres ? 18:49 < phh> NV10_TCL_PRIMITIVE_3D 18:49 < marcheu> oui, a fait toute la 3D 18:49 < marcheu> d'ailleurs, TCL = Transform, Lighting, Clipping 18:52 < phh> so any idea ? 19:02 < pmdata> this is hard to guess what it could be 19:03 < pmdata> anyway, I will add in nv_objects that it is set to 0xff if double buffer 19:03 < phh> but it's strange it's only for me 19:04 < marcheu> darktama: ok, now XAA doesn't crash with nouveau 19:04 < marcheu> things are getting too complex for me, it seems 19:05 < pmdata> phh> could you also grep for 0x0d84/4 in all tests? 19:06 < pmdata> phh> 3f8/3fc is only used on nv17 gpu 19:06 < marcheu> is that some LMA parameter ? 19:06 < darktama> marcheu: hmm, odd.. I guess that means the objects are setup OK though 19:07 < marcheu> darktama: yup 19:07 < marcheu> it looks like things stopped making sense, though 19:07 < pmdata> marcheu> maybe, I think all unknown nv17 stuff in tcl object is related to lma 19:08 < shawn_work> might as well /part, i can't help for now :/ 19:08 < marcheu> shawn_work: I know how to find you anyway :D 19:08 < shawn_work> hehe 19:08 < marcheu> I say "GLINT" 3 times 19:08 < shawn_work> the magic words 19:09 < shawn_work> ok :) 19:10 -!- shawn_work [n=spstarr@192.219.104.10] has left #nouveau ["a demain :)"] 19:10 < darktama> marcheu: EXASolid and XAASolidFill are quite different, but perform the same task, perhaps you could look at some differences there 19:10 < darktama> EXASolid being the only place NvRectangle is used in EXA 19:11 < marcheu> yeah, but commenting out the full EXASolid funcs is not enough to stop crashes 19:11 < marcheu> but right now the fifo is stuck at 0x0 19:11 < marcheu> yeah, you read right, 0 19:11 < marcheu> it used to stick at around 0x2a0 19:12 < phh> pmdata, only test_startup have it Oo 19:12 < darktama> hmm, after a rewind? or after the very first WRITE_PUT() ? 19:12 < marcheu> darktama: the very first, it doesn't work 19:12 < darktama> ok.. that's weird 19:12 < pmdata> phh> so you have d84? 19:12 < marcheu> yeah, totally 19:12 < phh> pmdata, card_10de-01f0_test_startup.txt:e3 0x00000003 0x00000003 NV10_TCL_PRIMITIVE_3D [0x0d84/4] = 0x00000003 | UNKNOWN = 00000003 19:12 < marcheu> I wonder if the hw is still ok... 19:12 < darktama> considering the first part of the FIFO is filled with NOPs.. 19:13 < marcheu> well, its 0 -> 2a 19:13 < marcheu> so not only nops 19:13 < marcheu> but it's the very very first command 19:13 < pmdata> ok then, it was the only remaining one that I got still marked as maybe nv17gl only 19:14 < darktama> if nvidia's driver can still function I'd say the hw is fine 19:14 < marcheu> actually, nvidia's OSS driver works 19:14 < marcheu> but the proprietary one.. I didn't test it 19:14 < pmdata> phh> could you grep for 258 and 25c? 19:14 -!- jkolb [n=jkolb@wsi-130-16.wsi.com] has joined #nouveau 19:14 < phh> card_10de-01f0_test_startup.txt:de 0x00000001 0x00000001 NV10_TCL_PRIMITIVE_3D [0x0258/4] = 0x00000001 | UNKNOWN = 00000001 19:15 < phh> card_10de-01f0_test_startup.txt:df 0x00000001 0x00000001 NV10_TCL_PRIMITIVE_3D [0x025c/4] = 0x00000001 | UNKNOWN = 00000001 19:15 < pmdata> ok, so we have 258/25c, 3f8/3fc and d74/d84 still unknown for nv17 19:16 < phh> everything else is known Oo 19:17 < Koala_BR> pmdata: I grep for NV30_TCL_PRIMITIVE_3D yesterday and found 93 unique ones (and 3f8 3fc was there too IIRC) 19:18 < pmdata> of course, since >=nv17 have lma 19:18 < pmdata> phh> not exactly, all the other unknown stuff are also for nv10 19:19 < phh> ah 19:19 < Koala_BR> Well, I settled for the 200/204 and 2c0 2c4 ones first, that's where I was stuck and pestered you yesterday :) 19:19 < pmdata> phh> I marked all unknown stuff in nv_objects.h, just before NV10_TCL_PRIMITIVE_3D defines 19:21 < Koala_BR> Ok, I'm away for the next ~2 hours. Will try all tests with newest renouveau and report back. Perhaps we can figure some more commands out 19:21 < Koala_BR> See you later 19:21 -!- Koala_BR [n=KoalaBR|@195.227.227.59] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.12/20050920]"] 19:23 < pmdata> phh> could you try to enable depth test in the test_swap_buffers() ? 19:23 < phh> pmdata, where that ? 19:24 < pmdata> let me add it in the test 19:24 < phh> ok 19:26 < pmdata> checkout renouveau, and look in tests.c, test_swap_buffers() function, uncomment the 2 lines with GL_DEPTH_TEST 19:28 < phh> pourquoi je l'ai pas 19:28 < phh> j'ai refais un co j'ai pas les 2 lignes 19:28 < phh> bon je les rajoute la main 19:34 < phh> pmdata, ok done, what do i look for in the log ? 19:34 < pmdata> 258/25c, 3f8/3fc and d74/d84 19:35 < phh> for 258 and 25c there are only in test_startup 19:36 < phh> ./card_10de-01f0_test_swap_buffers.txt:22c 0x00000000 0x00000000 NV10_TCL_PRIMITIVE_3D [0x03f8/4] = 0x00000000 19:36 < phh> ./card_10de-01f0_test_swap_buffers.txt:22d 0x000000ff 0x000000ff NV10_TCL_PRIMITIVE_3D [0x03fc/4] = 0x000000ff | UNKNOWN = 000000ff 19:36 < phh> ./card_10de-01f0_test_swap_buffers.txt:2ea 0x00000000 0x00000000 NV10_TCL_PRIMITIVE_3D [0x03f8/4] = 0x00000000 19:36 < phh> ./card_10de-01f0_test_swap_buffers.txt:2eb 0x00000000 0x000000ff NV10_TCL_PRIMITIVE_3D [0x03fc/4] = 0x000000ff | UNKNOWN = 000000ff 19:37 < pmdata> I think you'll have to enable the depth test at start, and disable any Disable(GL_DEPTH_TEST), run all tests, to see more 19:37 < phh> and d74 and d84 aren't in test_swap_buffers 19:37 < pmdata> these unknown values are for lma, lma is used with depth test -> enable depth test for all 19:38 < phh> not sure to understand 19:38 < phh> i put regl.Enable(GL_DEPTH_TEST); 19:38 < phh> before calling the test 19:39 < phh> and disable after ? 19:40 < phh> ou alors tu le dis en francais ca marche aussi 19:43 -!- Unavowed [n=silent@host81-158-96-24.range81-158.btcentralplus.com] has quit [Read error: 110 (Connection timed out)] 19:45 < pmdata> disons que tu mets le Enable avant test_default() dans main.c et Disable avant le SDL_Quit() a la fin 19:45 < pmdata> et supprimer/commenter tous les enable(gl_depth_test) et disable(gl_depth_test) dans tests.c 19:47 < phh> et je fais quels tests ? 19:47 < phh> tous sauf overlay & swap_buffers ? 19:48 < phh> zut ma soeur vient de prendre l'ordi :/ 19:49 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau 19:51 < pmdata> oui tous 19:51 < pmdata> fout lui une claque 19:51 -!- jkolb [n=jkolb@wsi-130-16.wsi.com] has left #nouveau ["Leaving"] 19:51 < pmdata> sauf overlay et swapbuffers 19:51 < phh> dj que j'ai un ordi moi tout seul, si en plus j'en prend un 2 c'est moi qui vais m'en prendre 19:53 < phh> pmdata, sans double_buffer en 512x512 en fentre ? 19:55 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"] 19:56 < pmdata> oui, en normal 20:01 < marcheu> so :) 20:01 < marcheu> on driver init 20:02 < marcheu> we write the first 0x2a bytes of the fifo 20:02 < marcheu> kickoff dma 20:02 < marcheu> re-write those bytes again 20:02 < marcheu> and kickoff again 20:02 < phh> did you look at glucose ? 20:02 < marcheu> why you I ? 20:02 < marcheu> why would I ? 20:03 < phh> marcheu, it isn't about your speak :p 20:03 < phh> it's from the author of Xgl 20:03 < marcheu> no, the author of glucose is zack 20:04 < phh> marcheu, ho i thaught 20:04 < phh> marcheu, so you know so i have nothing to say more about it 20:04 < phh> but i thaught that it would be easier to code for it than for exa 20:05 < marcheu> well, both are from the same guy ;) 20:06 < marcheu> darktama: so, do you see that too ? 20:06 < marcheu> darktama: by adding some debugging statements in NVDmaNext ? 20:06 < marcheu> darktama: isn't life wonderful ? 20:07 < darktama> marcheu: that's NVResetGraphics() isn't it? 20:08 < marcheu> yeah, I think so 20:08 < marcheu> I think it's the one wedging the fifo on init 20:08 < darktama> yes, I wondered if that would be a problem but ignored it since it worked here 20:09 < darktama> iirc, the first time we write it the FIFO hasn't even been setup.. 20:09 < marcheu> very nice, so where is it written ? 20:09 < darktama> no, that's not right actually 20:09 < marcheu> if the fifo is not allocated, we guess the adress ? :) 20:10 < marcheu> and if you make a wrong guess, boom 20:10 < darktama> we do NVInitDma(); then NVResetGraphics() in NVModeInit(); then NVExaInit(); then NVResetGraphics() again 20:11 < marcheu> yup, I'd say kill the 1sr ResetGraphics 20:11 < marcheu> 1st 20:11 < marcheu> let's see 20:11 < darktama> is PUT written between the two ResetGraphics() ? if not, it's probably not a problem 20:12 < marcheu> yeah, it is 20:12 < marcheu> as I said, life is so wonderful 20:12 < darktama> hmm, well without a rewind that could trigger that fetching hang issue.. 20:12 < marcheu> *cough* it does here :) 20:12 < darktama> hehe 20:12 < marcheu> but really, can't we slash the first ResetGraphics you think ? 20:13 < darktama> well.. it needs to be done after modeinit() since NVLoadStateExt() clobbers a heap of stuff somehow 20:14 < darktama> clobbering the second should be ok 20:14 < marcheu> hmm, removing the 2nd you think ? 20:14 < darktama> yeah, the second is only called once.. and we need it done after every mode change 20:16 < marcheu> I really wonder what's the reason for calling ResetGraphics twice... 20:17 < marcheu> guess it'll crash some different way now 20:19 < darktama> I can't see any good reason for the second one to be there at all actually 20:19 < marcheu> ok, it still crashes for me 20:19 < marcheu> but I'd advocate removing the 2nd one 20:19 < darktama> after a mode switch? 20:20 < marcheu> still crashes on startup 20:20 < darktama> that's going to be a problem, because the engine GET/PUT pointers reset back to 0 after a mode change.. 20:20 < marcheu> yeah, that the stupidity of that function 20:20 < marcheu> reset everything, don't try to think 20:21 < darktama> or rather, after LoadStateExt().. but I think that's only because we power-down/power-up some card units 20:21 < darktama> probably PFIFO and PGRAPH in there 20:21 < darktama> I actually wonder if we can do it once, at startup.. and just leave the modesetting bits in LoadStateExt.. 20:22 < marcheu> mmmkay 20:22 < marcheu> if I 20:23 < marcheu> 1. Remove the 2nd ResetGraphics 20:23 < marcheu> 2. Don't have it kickoff but let that kickoff be triggered later (i.e. when the engine is ready) 20:23 < marcheu> things work fine here 20:23 < marcheu> wooo stochastic bugfixing 20:23 < darktama> hm, interesting.. still doesn't explain why it works with XAA though :) 20:25 < darktama> can you still switch video modes now? 20:27 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau 20:28 < marcheu> hmm didn't try that 20:28 < marcheu> I only have 1 mode setup 20:29 < marcheu> anyway, now that we understand the issue, we can see how to fix that properly 20:29 < marcheu> I don't like the idea of writing the fifo contents twice, even if that'd work because the kickoff is removed 20:30 < darktama> nv_hw.c needs to die.. badly 20:31 < stillunknown> several people mentioned that "evil" file, what is so bad about it? 20:31 < marcheu> well, maybe it's the right occasion to cut another piece from it :) 20:31 < darktama> stillunknown: have a look at it, especially the "official" one 20:31 < marcheu> stillunknown: documenting the file is left as an exercise for the reader 20:32 < darktama> hopefully airlied's work will get rid of the modesetting bits of it, which is quite a large chunk 20:32 < marcheu> darktama: so, I think it'll work if I remove the kickoff from ResetGraphics. do we do that for now ? 20:32 < darktama> I still don't like resetting the entire engine on a mode change either 20:32 < marcheu> I really would like to tackle te init problem 20:32 < darktama> marcheu: yup, sounds good for me 20:33 < darktama> s/for/to/ 20:33 < marcheu> ok, I'll commit the 1-line fix to my nightmares and look at making nv_hw.c slimmer 20:34 < stillunknown> darktama: it looks like a complete mess of abbreviations to me 20:36 < darktama> yup, and magic values 20:37 < stillunknown> but i'm not a programmer, so i'm not used to all the jibberish 20:38 < stillunknown> but i've seen better code :-) 20:38 < darktama> me too, even mine is better.. and that's saying something :P 20:38 < darktama> but nv_hw.c is deliberately that way, to make it hard to figure out 20:41 < stillunknown> maybe the 2d part of the driver should be put into the "official" nv module once it's done 20:42 < darktama> it'd be hard, our version is dependant on a kernel module.. even for 2D 20:45 < stillunknown> is Xv unbroken yet? 20:46 < darktama> ah, no :) if you want it urgently I can handle that tomorrow depending on what time I wake up 20:46 < marcheu> I guess we'll have to fix it ourselves :) 20:46 < darktama> it's almost 3am now.. so I may be waking up rather late :) 20:46 < stillunknown> go to bed, you people are crazy 20:47 < darktama> haha, I'm used to my weird-arse sleeping patterns now! 20:47 < stillunknown> no job/school/etc? 20:48 -!- flupp [n=dirk@dialin-212-144-136-227.pools.arcor-ip.net] has joined #nouveau 20:48 < darktama> I have a job, but it's at night :) 20:56 -!- flupp [n=dirk@dialin-212-144-136-227.pools.arcor-ip.net] has quit ["using sirc version 2.211+ssfe"] 21:23 < Duke`> is your job "crazy coder from hell"? ;p 21:24 < darktama> unfortunately not :( 21:25 < marcheu> darktama: he's right, you really shoudl try to have a regular sleep schedule 21:25 -!- KoalaBR [n=KoalaBR@port-83-236-14-45.dynamic.qsc.de] has joined #nouveau 21:25 < marcheu> darktama: you don't want to become like me, do you ? 21:27 < darktama> hehe :) well, the way I sleep now fits in well with my friends, who are equally as strange 21:29 < KoalaBR> pmdata: ready for testing, what do you need? 3f8 3fc occur only with parameter value 0x00000000 and are always identified as NV04_IMAGE_PATTERN 21:31 < darktama> on that note, I should sleep now :) 21:31 < darktama> night 21:31 < pmdata> koala> which test? 21:31 < KoalaBR> all :) 21:32 < pmdata> you see nv30 tcl [0x3f8/4] (or 0x3fc) in all tests? 21:32 < KoalaBR> I grepped all and if it appears, I see the values from above 21:32 < KoalaBR> No, wait I'll tell you 21:33 < KoalaBR> pmdata: for 03f8 I see this value always identified as NV04_IMAGE_PATTERN. Nothing with NV30 21:34 < KoalaBR> But wait, I should redo all tests... 21:34 < pmdata> NV04_IMAGE_PATTERN has 0x3f8 command, so it's ok to see it 21:35 < KoalaBR> Yes, but I did the test yesterday 21:35 < KoalaBR> haven't redone them with the new changes... 21:36 < KoalaBR> Use SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER,1); and fullscreen? 21:36 < pmdata> I don't know, see line 22c,22d in http://nouveau.sourceforge.net/tests/nv18gl1/card_10de-018a_test_startup.txt 21:37 < pmdata> try to find a similar list of commands in your test_startup 21:37 < pmdata> I must eat 21:37 -!- pmdata is now known as pmdata_dinner 21:37 < KoalaBR> Ok 21:54 < KoalaBR> pmdata: No, I don't see this really used. It always looks like this:http://sh.nu/p/2855 I see it only at the end of the dump, exactly once. The objects differ though: 21:55 < KoalaBR> pmdata: card_10de-0140_test_draw_pixels.txt -> NV_MEMORY_TO_MEMORY_FORMAT 21:56 < KoalaBR> card_10de-0140_test_logic_op.txt -> NV20_SWIZZLED_SURFACE 21:57 < KoalaBR> card_10de-0140_test_scissor.txt -> NV_MEMORY_TO_MEMORY_FORMAT 21:58 < KoalaBR> card_10de-0140_test_startup.txt -> NV10_UNK0072 21:59 < KoalaBR> See from line 400 in the posted dump. The name of ALL those commands / addresses change to the name noted above 22:21 -!- flupp [n=flupp@dialin-212-144-132-238.pools.arcor-ip.net] has joined #nouveau 22:21 < marcheu> hmm, I think I'll add a new test to renouveau 22:21 < marcheu> someting like "dump_interesting_regs" :) 22:27 < KoalaBR> Interesting is defined as "..."? 22:28 < marcheu> as "I need to gather values from different cards in order to understand what it is" :) 22:29 < KoalaBR> So tell me if you need a dump from me 22:32 < KoalaBR> So you and darktama are trying to change the X11/xorg driver to be able to init and later drive the 3D Engine correctly? Where does the kernel module fit into this picture? 22:33 < marcheu> well, right now we're getting 2D to work using EXA 22:33 < marcheu> let's put it this way : you have a 2D driver (DDX) and a 3D driver (DRI) which both need to access the same card 22:34 < marcheu> in order to do that without those stepping on each other's toes, some arbitration is needed 22:34 < marcheu> and that's the job of the kernel module (DRMà 22:34 < KoalaBR> Understood 22:35 < marcheu> and right now, we are adapting the 2D driver to make its allocations/init stuff go through the kernel 22:35 < marcheu> so that the driver will be able to share the card with an upcoming 3D driver 22:35 < stillunknown> and it's expected that you can make the drm+ddx work? 22:36 < marcheu> what do you mean, "it's expected" ? 22:36 < marcheu> that's what I'm running right now :) 22:36 < stillunknown> i mean, there are no obstacles in it's way? 22:36 < stillunknown> but you already ansered it 22:37 < KoalaBR> Say would you be interested in a kind of Status page like the weekly newletters of other projects? I could do something like that but on a irregular basis. So that something happens on our homepage. 22:38 < KoalaBR> I'm asking so many stupid / basic questions, I could write something up, you all could review it and if you like it, I could put it on the web 22:38 < marcheu> yeah, maybe we should do that when we have usable 2D code 22:38 < marcheu> which is, when Xv is fixed as far as I'm concerned 22:39 -!- Myrizio [n=Myrizio@host225-96.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)] 22:39 < KoalaBR> My other offer still stands: If you want me to test the code, I will write a small "howto" and put this on the webpage too 22:40 < stillunknown> an user wiki will give non-coders a feeling of progress and a place were information can be put, which will help testing probably 22:40 < KoalaBR> our homepage on fd.o is a Wiki :) 22:40 < marcheu> sure, there's just no point of giving updates without code that can be user-tested 22:40 < KoalaBR> Correct 22:41 < KoalaBR> You know, I was long contemplating whether I could help or not. I did recheck the homepage once a week, but nearly never saw progress. So I was afraid, that the project was dead ... 22:41 < stillunknown> this wiki seems to be completely locked to outside changes 22:42 < marcheu> stillunknown: it's not, you need to create an accound 22:55 < KoalaBR> Need to change X11 Server setup, will be back in a second 22:55 -!- KoalaBR [n=KoalaBR@port-83-236-14-45.dynamic.qsc.de] has quit [Remote closed the connection] 22:57 -!- pmdata_dinner is now known as pmdata 22:57 -!- KoalaBR [n=KoalaBR@port-83-236-14-45.dynamic.qsc.de] has joined #nouveau 22:59 -!- flupp [n=flupp@dialin-212-144-132-238.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)] 22:59 < pmdata> if you want info about any progress, look at the cvs commits 23:05 -!- Myrizio [n=Myrizio@host54-101.pool80104.interbusiness.it] has joined #nouveau 23:05 < KoalaBR> Ok, retest? 23:07 < KoalaBR> pmdata: I wrapping up my findings on 0x0200, 0x0204, 0x02C0 and 0x02C4. I can tell you how the values are calculated, but I still don't know what they are doing :/ 23:07 < pmdata> isn't it the same as for nv10? 23:07 < pmdata> viewport dimensions, and viewport clipping 23:09 < KoalaBR> We have these already on NV30_TCL_PRIMITIVE_3D_VIEWPORT_DIMS_(0/1) and offset calculation 23:11 < KoalaBR> 0x0a00 and 0x0a04 23:11 < KoalaBR> this is set by glViewport() 23:12 < pmdata> yep, but on nv10, 200,204 are also used for it, and this is what I see in nv40 dumps 23:12 < pmdata> so they both hold viewport size, but for a different usage 23:14 < KoalaBR> Yes that's what i think. I'm currently summing up a list, what values I saw and how the values can be calculated. Need to compare those to my earlier finding regarding the Viewport parameters 23:15 < KoalaBR> Need about 15min I guess. Will ping you with an URL, where you can have a look 23:17 < pmdata> ah, think I have find my missing nv10 stuff, I wrote a test for arb_point_parameters 23:19 < pmdata> I'm feeling happy :) 23:21 < KoalaBR> Grats :) 23:21 < KoalaBR> Progress is always good. 23:23 < KoalaBR> pmdata: Please have a look here http://sh.nu/p/2859 Calculation is nearly the same 23:24 < pmdata> I think I can trust you on this 23:26 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has quit ["leaving"] 23:28 < KoalaBR> Thanks, but how do we name it? I have no good idea of what this does. Is there by any chance something like a 3d viewport and a 2d viewport? (Wild guess, don't laugh) 23:29 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has joined #nouveau 23:30 < pmdata> 200,204 for nv10 defines the viewport in the color buffer, at least from my pov (i.e. where the gpu will render stuff in the color buffer) 23:30 < KoalaBR> pmdata: If it helps, data was gathered using test_draw_pixels() 23:30 < phh> ho little question, what is "agp aperture size"? 23:30 < pmdata> a zone in system ram used for agp transfers 23:30 < KoalaBR> you beat me to it ;) 23:30 < phh> so we need to set it to the size of the VRAM ? 23:31 < pmdata> no 23:31 < phh> ah. 23:31 < KoalaBR> Ok, I will name it VIEWPORT_COLOR_BUFFER_xxxx 23:31 < pmdata> usually it is set up to half of available system ram (at least on mine) 23:31 < phh> Oo 23:32 < pmdata> if you have many big textures that can't reside all in video ram, you can put some in agp, and the gpu will render stuff using agp transfers from system ram 23:32 < pmdata> you can think of the video ram as a cache in that case 23:33 < phh> Oo 23:33 < phh> pmdata, but comparing the the size of the VRAM, is there anything ? 23:33 < pmdata> or maybe you can put more prioritarized stuff in vram 23:33 < phh> for instance at least the size of the vram 23:33 < phh> or maximum 23:33 < pmdata> my gf2ti has 64MB onboard, and I have 256MB agp aperture 23:34 < pmdata> for example, a 2048x2048x32 bits texture is 16MB 23:34 < phh> ho can this works with linux, while it owns for himself the whole memory not? 23:34 < pmdata> so you can only put 3 of them in vram (the rest is used for the various stuff and buffers) 23:34 < phh> mmm 23:35 < pmdata> of course it is used on linux 23:35 < pmdata> there is the kernel agpgart driver that have the task of managing it 23:36 < phh> and in free -m it's declared as cache ? 23:45 < pmdata> I don't know, anyone want to answer? :) 23:45 < phh> bah i think looking at source code will easily answer 23:50 < phh> Region 0: Memory at d9000000 (32-bit, non-prefetchable) [size=16M] 23:50 < phh> Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M] 23:50 < phh> [virtual] Expansion ROM at da000000 [disabled] [size=128K] 23:50 < phh> (from lspci) 23:50 < phh> it means that i have 144Mo of VRAM Oo 23:50 < phh> and the bios is 128k ? 23:50 < phh> i find that pretty strange 23:53 < pmdata> Memory at e0000000 (32-bit, non-prefetchable) [size=16M] 23:53 < pmdata> Memory at d8000000 (32-bit, prefetchable) [size=128M] 23:53 < pmdata> Expansion ROM at e1000000 [disabled] [size=64K] 23:53 < pmdata> my board only have 64MB, so it may be shadowed for the in the upper 64MB 23:54 < pmdata> the 16M region is the register region, so it's not ram 23:54 < pmdata> this is in this 16M region that renouveau peek the fifo stuff 23:55 < phh> pmdata, and textures are sent to the 128M region ? 23:55 < pmdata> this is the vram 23:56 < pmdata> so it holds the video memory, 3d objects, textures, etc 23:56 < phh> pmdata, but of the 16M only a very few is used ? 23:56 < pmdata> yep, but marcheu or darktama could talk more about this region --- Log closed Чтв Авг 24 00:00:20 2006