--- 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 ["<blank>"]
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 ["<blank>"]
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 ["<blank>"]
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 <Vista doesn't..
17:37 < marcheu> 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 ["<blank>"]
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
