--- Log opened Сбт Авг 19 00:00:17 2006
00:05 < pmdata> single_vertex still use vertex array for pos? damn
00:17 < KoalaBR> pmdata: Are you looking for something specil in test_single_vertex() Most of the commands decode nicely, only 5 commands are unknown from which 2 are constant through all NV40 dumps on SF
00:22 < KoalaBR> special
00:23 -!- Netsplit sterling.freenode.net <-> irc.freenode.net quits: Duke`, maxtoo, predatorfreak, nano-, ajmitch, philv
00:23 -!- nano- [i=nano@83.140.162.43] has joined #nouveau
00:23 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has joined #nouveau
00:24 -!- maxtoo [n=maxtoo@82.246.200.161] has joined #nouveau
00:24 -!- Duke` [n=gnu@86.203.125.30] has joined #nouveau
00:28 -!- Netsplit over, joins: philv
00:31 < pmdata> I just wonder if there is a VERTEX_POS_[3F|4F] like on nv10 and nv20
00:34 < KoalaBR> pmdata: Except for this line. nothing with VERTEX_POS at all:  NV30_TCL_PRIMITIVE_3D_VERTEX_ATTR0_POS = stride = 0 | fields = 4 | type = FLOAT
00:37 < pmdata> I know VERTEX_POS was used in old drivers (3x or 4x) instead of vertex array, I also saw them on real quadro dumps
00:40 < KoalaBR> l'm using 8762
00:42 < pmdata> I don't know if nv40 is supported below driver 5x or 6x
00:48 < KoalaBR> I don't think so
00:49 < marcheu> I have to use a 8xxx driver with my nv44
00:50 < marcheu> pmdata: so, is the Quadro4 380 XGL useless ?
00:51 < KoalaBR> Well, I had a 6629 version first (gentoo), this did work
00:54 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has joined #nouveau
00:55 < pmdata> marcheu> I will run the whole tests suite, to check for some unknown stuff, but I think I listed them all in nv_objects.h
00:59 -!- EdB [n=EdB@83.195.175.116] has quit ["Konversation terminated!"]
01:06 < KoalaBR> Well, bed calls. Will be back tomorrow afternoon
01:06 < KoalaBR> Bye
01:06 -!- KoalaBR [n=KoalaBR@port-83-236-13-53.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
01:07 -!- K [i=hazel@tor/session/external/x-af289f06fb22fbd1] has joined #nouveau
01:10 -!- K [i=hazel@tor/session/external/x-af289f06fb22fbd1] has quit [Remote closed the connection]
01:10 < pmdata> ah, found something in nv18sgl dump, what I defined as nv10 color_material_back is wrong
01:10 < pmdata> usually it is set to 6
01:11 < pmdata> but I have a dump where it is set to 7, and it send the modelview1 matrix
01:11 < pmdata> (the second one)
01:16 < pmdata> marcheu> how do I update dumps on nouveau.sf.net, can not remember the command (I hope I have permission to overwrite the old ones)
01:17 < marcheu> it's on shell.sf.net:/home/groups/n/no/nouveau/htdocs/tests/
01:17 < marcheu> easy, huh ?
01:17 < pmdata> ssh?
01:17 < marcheu> yes
01:22 < pmdata> uploading....
01:27 < pmdata> done
01:32 < pmdata> Hum, I think I'm wrong with 3e8 being projection/modelview0/modelview1 matrix enable
01:32 < pmdata> bit 0 seems to be arb_point_sprite enable
01:33 < pmdata> it is also changed in polygon mode test
01:34 < marcheu> hmm, with what polygon mode ?
01:38 < pmdata> regl.PolygonMode(GL_FRONT, GL_POINT);
01:39 < marcheu> ah, makes sense :)
01:39 < pmdata> and it uses vertex_pos_4f just for the previous test, nice, what I was looking for
01:42 < pmdata> polygon_mode is the only test that triggers VERTEX_POS_4F
01:42 < marcheu> probably point size fed through the 4th vertex coord ?
01:43 < pmdata> hum, no, W is always 1.0
01:43 < pmdata> there is already a point size command in nv10 tcl
01:45 < pmdata> I think 3e8 = projection/modelview0/modelview1 matrix enable, after much reflection
01:46 < pmdata> I never saw modelview0 set before 3e8 = 6, but maybe it is only uploaded when it is changed, and it only happens when running a gl program
01:46 < pmdata> so, bit 0 = modelview1, bit1 = modelview0 (or projection), bit2 = projection (or modelview0)
01:47 < pmdata> color_material_back was not making sense in my dumps
01:49 < pmdata> I like this idea, will commit
01:52 < pmdata> I will have to test this idea with ext_vertex_weighting (and an old driver)
01:53 < marcheu> I'm not sure how I could build it on my 2.6
01:53 < marcheu> I'm already fighting to build that stupid modular, no scripts work
01:53 < marcheu> I'm pretty pissed with building stuff for today
01:56 < pmdata> why not run a 2.4 kernel then?
01:56 < marcheu> because that machine is used for, you know, reall stuff like connecting me to the internet
01:56 < marcheu> and the 2.6 kernel I used has patches all over
01:57 < pmdata> just ran polygon_mode on my nv15 nongl, it always uses vertex array, never VERTEX_POS
01:57 < pmdata> And I like that new line:
01:57 < pmdata> NV10_TCL_PRIMITIVE_3D_VIEW_MATRIX_ENABLE = projection = TRUE | modelview0 = TRUE | modelview1 = TRUE
01:57 < marcheu> well, my nv1sgl used to be an NVS, I just decided to choose another id and made it an XGL, maybe that matters
02:09 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
02:17 -!- maxtoo [n=maxtoo@82.246.200.161] has quit [Remote closed the connection]
02:35 -!- Duke` [n=gnu@86.203.125.30] has quit ["Fatal signal: Segmentation Fault"]
02:39 < pmdata> hum, I was thinking that nv10[0xcf0] could be do_vertices, like on nv20 or nv30
02:39 < pmdata> but in fact, it is triggered each time the vertex array format is changed
02:40 < pmdata> validate_vertex_array_format?
02:40 < darktama> marcheu: I like the commit message :)
02:40 < marcheu> darktama: I'm such a loser
02:41 < marcheu> oh, and my libdri actually crashes
02:41 < marcheu> so I can't move forward with that mem manager stuff
02:41 < marcheu> I think I'll focus my frustration on slashing XAA
02:41 < darktama> haha, I think nearly all my big-ish commits are followed by an "oops" commit
02:42 < marcheu> pmdata: I don't think it's do_vertices on nv30 either
02:42 < marcheu> pmdata: it's a name I gave it back when I understood very very few about the card
02:43 < marcheu> I think it's the 2nd command I named after vertex_data
02:43 < pmdata> don't forget to write a doc about all this started :)
02:43 < pmdata> about how all this started
02:44 < marcheu> I won't, that leaves a chance of hiding all my mistakes 
02:44 < marcheu> when I was working alone, no one could see "Oopses"
02:45 < marcheu> heh, maybe I'll write about it one day though
02:46 < marcheu> it's pretty complicated :)
02:46 < darktama> hrm, almost everything is too complicated for me at the moment :) /me fetches more coffee
02:47 < marcheu> well, it has to do with real life more than computers... I started that project to have a way of using up all my time instead of sitting there doing nothing
02:48 < marcheu> I chose something impossible on purpose, so that I could have a long-lasting effect
02:54 < darktama> I think it's amazing how many people have gotten involved so quickly
02:58 < pmdata> I think this is because there are many people that would like to have such a driver
02:59 < darktama> Indeed, and this recent lack of Xorg 7.1 drivers is showing exactly why we *need* it
02:59 < marcheu> it's a bit annoying that you guys are making my impossible pet-project come true
02:59 < darktama> :)
02:59 < darktama> pmdata is doing his best to make it possible!
03:02 < pmdata> it is not enough to find what each command do, there is also the context that makes this command working
03:03 < pmdata> I think I will redo the light doc, to show how each parameter is computed
03:04 < pmdata> I need new batteries for my fx850p calculator
03:04 < pmdata> I did not use it for years
03:06  * pmdata should try new mania drive 1.1, and check for xmoto updates :)
03:07 < marcheu> xmoto... that games makes me crazy after 30 seconds
03:12  * pmdata too, but I finished some levels
03:12 -!- pmdata [i=patrice@ANantes-154-1-58-15.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
03:16 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
03:27 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has joined #nouveau
04:08 -!- swany [n=swany@81.234.181.143] has quit []
04:16 -!- philv [n=bleep@cowpig.ca] has left #nouveau ["goodbye."]
04:21 < marcheu> darktama: hmm, Xv is borked with EXA
04:22 < marcheu> this is the broken thing that needs fixing before it's usable
04:23 < darktama> hmm, broken in what way?
04:24 < marcheu> here mplayer says X11 error: BadAlloc (insufficient resources for operation)
04:24 < marcheu> doesn't happen to you ?
04:24 < darktama> not sure, I don't think so but I'll double-check anyway
04:26 < darktama> yup, broken here too :(
04:34 < darktama> hm, is it because of the xf86*OffscreenLinear() calls?
04:35 < darktama> do they work with EXA or should OffscreenAlloc() etc be used
04:35 < darktama> EXAOffscreenAlloc() that is
04:42 < marcheu> yeah, linear shoudln't work with EXA
04:49 < marcheu> hmm time for some sleep
04:50 < marcheu> hope I get that libdri.so to work tomorrow :(
04:50 < darktama> hehe, night
05:41 -!- shenki [n=shenki@ppp162-193.lns3.adl4.internode.on.net] has joined #nouveau
06:07 -!- Myrizio [n=Myrizio@host180-101.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
06:16 -!- Myrizio [n=Myrizio@host180-101.pool80104.interbusiness.it] has joined #nouveau
07:00 -!- Myrizio [n=Myrizio@host180-101.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
07:01 -!- predatorfreak [n=predator@adsl-69-213-80-253.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
07:34 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #nouveau
08:54 -!- shenki [n=shenki@ppp162-193.lns3.adl4.internode.on.net] has quit [Read error: 110 (Connection timed out)]
11:08 -!- EdB [n=EdB@ARennes-251-1-7-200.w83-195.abo.wanadoo.fr] has joined #nouveau
12:21 -!- pmdata [i=patrice@ANantes-154-1-51-32.w81-53.abo.wanadoo.fr] has joined #nouveau
12:23 < pmdata> hello
12:25 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
12:26 < Lumag> hi all
12:30 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
12:56 < darktama> hey Lumag, how's things?
12:59 < Lumag> nothing particulary new :(
13:00 < darktama> me neither
13:02 -!- Duke` [n=gnu@ANantes-251-1-153-56.w86-203.abo.wanadoo.fr] has joined #nouveau
13:23 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
13:26 < Duke`> hi
13:28 < Lumag> hi
13:30 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
13:37 -!- pmdata [i=patrice@ANantes-154-1-51-32.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
13:41 < lumag_offline> I wonder, where I can get softquadro nvclock patches? :)
13:42 < darktama> it's in nvclock cvs I think
13:46 < lumag_offline> darktama: on nvclock.sf.net? Strange I don't see it there...
13:46 < lumag_offline> oh, found it.
13:55 < lumag_offline> Strange. I reinstalled my old 0x110 (GF2MX400) but I can't softquadro it :( And marcheu can softquadro his 0x110 to 0x113...
13:55 < Duke`> the latest official nvclock can enable softquadro
13:55 < Duke`> lumag_offline : I failed too (same card)
13:55 < Duke`> but maybe the nvidia kernel module was already loaded and interfering?
13:55 < lumag_offline> no.
13:56 < lumag_offline> is 0.8b2 last enough?
13:56 < Duke`> I have this one, there is the -Q option for softquadro
13:57 < lumag_offline> yeah. IIUC -Q 3 should do the trick for me. But it doesn't :( Strange...
14:08 < Duke`> same here :[
14:47 -!- Duke` [n=gnu@ANantes-251-1-153-56.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
15:09 -!- Duke` [n=gnu@ANantes-251-1-153-56.w86-203.abo.wanadoo.fr] has joined #nouveau
15:15 -!- K [i=hazel@tor/session/external/x-d7fc4db7a5d75efb] has joined #nouveau
15:16 < marcheu> lumag_offline: really weird I'm the only one who gets it to work
15:17 < marcheu> lumag_offline: did you do it as root ? just after a fresh boot ?
15:26 < marcheu> hmm
15:26 < marcheu> maybe it matters that I still use my version of sotfquadro
15:29 < Duke`> I retryed but it still refuses to change the pci id
15:29 < marcheu> I'll upload my version somewhere
15:30 < Duke`> I uninstalled the driver, halted and booted, didn't run Xorg
15:30 < Duke`> but it failed
15:34 < marcheu> http://icps.u-strasbg.fr/~marchesin/nvdri/nvclock-softquadro.tgz
15:34 < marcheu> my version is a bit different, you only have to say nvclock -Q
15:35 < marcheu> it determines a matching quadro card itself (although that doesn't work with cards I don't have)
15:37 < Duke`> does the nvidia kernel module have to be not loaded for this?
15:38 < marcheu> yes, nothing loaded, fresh boot, run as root
15:38 < marcheu> I even put it in /etc/rc.local
15:38 < marcheu> I suppose having some kind of fbdev module would interfere as well
15:38 < marcheu> like, for graphical bootup
15:39 < Duke`> I tried without usplash, but I'm note sure usplash uses fb
15:39 < marcheu> well, I think that as soon as you switch to a non-text mode, the card might be initialized too far for the ID change
15:40 < Duke`> ok, but when booting ubuntu in recovery mode there is no graphical bootup
15:40 < marcheu> ok, so try my version on it..
15:40 < marcheu> it's really really weird that this works only for me
15:40 < Duke`> ok
15:41 < Duke`> how does the /etc/rc.local work?
15:41 < marcheu> it's a shell script
15:41 < marcheu> it's executed at the very end of the boot
15:42 < Duke`> hum but the nividia kernel module will be already loaded at this time, no?
15:42 < marcheu> not for me, the X driver loads it usually
15:43 < Duke`> there is something that loads it for me, before X starts :(
15:43 < marcheu> yes, but it's not mandatory to do that
15:43 < marcheu> usually /etc/modules.*
15:44 < Duke`> I will uninstall the driver before, so I'll be sure :p
15:44 < marcheu> violent :)
15:45 < marcheu> also, I use some 7xxx version of the driver usually
15:45 < marcheu> not sure if that matters either, I don't think so but..
15:45 < Duke`> ubuntu with its packages "restricted drivers" puts things everywhere...
15:45 < Duke`> it should not matter, if it changes the pci id before the driver is loaded
15:45 -!- littlesniper [n=guillaum@56.174.97-84.rev.gaoland.net] has joined #nouveau
15:46 < Duke`> ok, going to try your nvclock, brb
15:46 -!- Duke` [n=gnu@ANantes-251-1-153-56.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
15:46 < marcheu> hope it works, or people will start to say I'm some kind of liar :p
15:58 -!- Duke` [n=gnu@ANantes-251-1-153-56.w86-203.abo.wanadoo.fr] has joined #nouveau
15:59 < Duke`> hum
15:59 < Duke`> nvclock output is:
15:59 < Duke`> PEXTDEV[0] is 80004483
15:59 < Duke`> PEXTDEV[0] is 80007483
15:59 < Duke`> but lspci -n still shows 0x110
15:59 < Duke`> and glxinfo gives "OpenGL renderer string: GeForce2 MX/AGP/3DNOW!"
16:04 -!- jkolb [n=jkolb@209-6-112-224.c3-0.wth-ubr1.sbo-wth.ma.cable.rcn.com] has joined #nouveau
16:06 < Duke`> Card has id 0x10de0110 (NV10) bus is AGP (32 Mb video ram)
16:06 < Duke`> :(
16:22 < Duke`> herm, there's a fly stuck into my keyboard...
16:22 -!- Myrizio [n=Myrizio@host186-96.pool80104.interbusiness.it] has joined #nouveau
16:30 < Duke`> I killed it with the "^" key
16:40 < jkolb> a gruesome death
16:43 < marcheu> hey jkolb, what's new ?
16:44 < jkolb> marcheu: oh man, been really busy.  new job, moving etc.
16:44 < jkolb> marcheu: how about yourself?
16:44 < marcheu> quite busy as well..
16:46 < jkolb> i noticed some new commits to drm :)
16:47 < marcheu> yeah, nothing major though... thinkg I've been meaning to do for months
16:47 < marcheu> things*
16:48 < marcheu> darktama: did you try to fix Xv with EXA? otherwise I'll put it in the TODO list
16:48 < darktama> oh, I thought you were doing that so I didn't bother :)  I'll take a look at it in an hour or so
16:49 < marcheu> well, maybe it could be an easy ToDo for some newcomer
16:49 < jkolb> ugh. sf cvs sucks
16:50 < darktama> that'd work aswell.. so you're going to kill off XAA soon then?
16:50 < marcheu> (as opposed to our current list made of big TODOs)
16:50 < marcheu> darktama: if we can't figure any regression with EXA compared to XAA, we might make it the default first
16:51 < darktama> good idea, I'll take a look at fixing composite instead then
16:51 < marcheu> jkolb: I think it's working now
16:51 < marcheu> it's been working pretty well for a couple of weeks
16:51 < marcheu> after the switch to the new system
16:52 < jkolb> hm i just get a hang on update. anything i have to switch?
16:52 < marcheu> hmm, what's your Root ?
16:52 < marcheu> maybe something like find . -name Root -exec sed -i -e s/cvs.sourceforge.net/nouveau.cvs.sourceforge.net/ {} \;
16:52 < jkolb> OH. nouveau.cvs.sourceforge.net? i'll try that
16:53 < marcheu> yeah, that came with the cvs changes at sf.net
16:53 < jkolb> there we go. thanks
16:57 < marcheu> darktama: now I remember, the EXA crashes I had were after running a compmgr
16:58 < darktama> hm, that'd hit the composite hook..
16:58 < marcheu> I think it does even without, because that stresses the DMA routines
18:08 -!- Myrizio_ [n=Myrizio@host48-98.pool80104.interbusiness.it] has joined #nouveau
18:13 -!- littlesniper [n=guillaum@56.174.97-84.rev.gaoland.net] has left #nouveau []
18:22 -!- Myrizio [n=Myrizio@host186-96.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
18:28 -!- KoalaBR_ [n=KoalaBR@port-83-236-14-212.dynamic.qsc.de] has joined #nouveau
18:36 -!- Myrizio_ is now known as Myrizio
18:37 -!- `Duke` [n=gnu@ANantes-251-1-133-118.w86-210.abo.wanadoo.fr] has joined #nouveau
18:51 -!- Duke` [n=gnu@ANantes-251-1-153-56.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
18:52 < KoalaBR_> Has anyone seen a 0x11f4 command and has some vague ideas about it? 
18:53 < KoalaBR_> sorry 0x1ff4 
18:53 < darktama> on NV40?
18:54 < KoalaBR_> Yes, or perhaps NV30
18:54 < darktama> then, I do :)
18:54 < KoalaBR_> I think it is an ENABLE  (manythings) register
18:55 < KoalaBR_> for color logic ops, clip planes, GL_REGISTER_COMBINERS_NV and GL_FOG
18:55 < KoalaBR_> What's your take?
18:56 < darktama> hmm, it has bits that have something to do with vertex attributes
18:56 < darktama> 0x1ff0 seems to be (1 << attrib_nr) to say the attrib is present in VERTEX_DATA
18:57 < darktama> 0x1ff4 seems to have the same bits, except the texcoord ones are in a different place than you'd expect
18:57 < marcheu> I think it could route some vertex program data
18:58 < lumag_offline> marcheu: your softquadro worked for me :)
18:59 < marcheu> lumag_offline: ah, good new s on that front finally :)
18:59 < lumag_offline> got gf2mx400 -> NV11GL [Quadro2 MXR/EX/Go] :)
18:59 < lumag_offline> time to start Xorg
19:00 < KoalaBR_> http://sh.nu/p/2785 there you'll find a list, where I did encounter 0x1ff4
19:00 < lumag_offline> damn. It seems, Xorg didn't like it
19:00  * darktama gets a blank page
19:01 < darktama> well, not blank.. it's sh.nu/p/ but there's no paste
19:01 < KoalaBR_> Strange me too,. wait
19:01 < marcheu> lumag_offline: hmm ? any error message ?
19:02 < KoalaBR_> All posts I do there are empty
19:03 < KoalaBR_> Try this please: http://rafb.net/paste/results/IAUyxI32.html
19:04 < darktama> can you post the 0x1ff0 that's above those 0x1ff4's aswell please?
19:04 < marcheu> you're right, looks like the vertex program unit's misc enable regiter..
19:04 < lumag_offline> no. What do you get from /proc/driver/nvidia/cards/* in case of softwuadroed card? 
19:04 < lumag_offline> I still got GF2MX400
19:04 < KoalaBR_> cool :)
19:04 -!- qfire [n=qfire@dsl093-010-213.cle1.dsl.speakeasy.net] has joined #nouveau
19:05 < darktama> I think 0x1ff4 might be routing actually, it could explain the weirdness I saw in vertex programs when I was looking at the clip_plane dumps
19:05 < marcheu> lumag_offline: yes, I still get that
19:05 < marcheu> lumag_offline: that stuff is initialized using the early pci data from the kernel, which the softquadro doesn't change
19:05 < KoalaBR_> darktama: Dumps on which card?
19:05 < marcheu> lumag_offline: what does glxinfo say ? can you enable stuff like UBB in xorg.conf ? if so, it works
19:06 < lumag_offline> well. Then that's probably ok :)
19:06 < darktama> KoalaBR_: whichever card the 0x1ff4 bits in that paste was from
19:06 < lumag_offline> I'll try in a minute...
19:06 < KoalaBR_> the clips are from a NV43, all others from the sf NV40 dumps
19:06 < darktama> marcheu: with nvclock, the glxinfo renderer string changes for me.. but the 2D driver refuses to enable stereo
19:07 < lumag_offline> from glxinfo I got quadro2
19:07 < KoalaBR_> clip planes that it
19:07 < KoalaBR_> clip planes that is
19:07 < darktama> ok, those dumps are from my card so I'll just grep them myself :)
19:07 < marcheu> darktama:yeah, I can't get it to work on nv30/nv40 either. those cards are really locked somewhere at the hw level
19:07 < KoalaBR_> :)
19:08 < marcheu> darktama: although I didn't try the stuff at the top of softquadro.c... that might work
19:08 < KoalaBR_> Wait, I will have a look for 1ff0 for the clip planes
19:08 < darktama> 0x1ff0 stays at 0x9, as I was expecting
19:09 < KoalaBR_> Yes except for the arb_texture
19:09 < KoalaBR_> there it is 0x0209
19:09 < darktama> yes, that's texcoord 1 enabled aswell
19:10 < KoalaBR_> Ok
19:10 < marcheu> to me, it really looks like a "fixed function in the programmable vertex unit" enable reg
19:11 < KoalaBR_> So - what do we do with that 0x1ff4? Name it ENABLE_VERTEX_ATTRIBUTES?
19:12 < marcheu> we really need more testing before...
19:12 < marcheu> card_10de-0045_test_logic_op.txt has it set a couple of times
19:12 < darktama> marcheu: I figured it was a reg saying what parts of VERTEX_ATTR (0x1740 and friends) are valid, but yes, more testing
19:12 < KoalaBR_> Ok, will do so
19:12 < KoalaBR_> I did grep through all your dumps, darktama
19:13 < KoalaBR_> I'll be back in about 30 min
19:17 < marcheu> hmm, I'm looking at 1ff4 in the 3d texture dumps on g70/g71 and it comes up different
19:18 < marcheu> so it's not a misc enable reg, unless the hw changed between g70 and g71, which I doubt
19:21 < darktama> hm, which dump?
19:22 < marcheu> g70/card_10de-0092_test_texture_3d.txt
19:22 < marcheu> g71/card_10de-0291_test_texture_3d.txt
19:23 < darktama> yup, that's where I was looking.. according to firefox's search 1ff0/1ff4 doesn't appear at all..
19:23 < marcheu> I'm looking at the local copies...
19:23 < marcheu> maybe they differ
19:23 < darktama> ah
19:25 < marcheu> hmmm it's not the same
19:28 < marcheu> weir, my 3D texture dump hase VP in it
19:30 < marcheu> so I uploaded both files at http://icps.u-strasbg.fr/~marchesin/nvdri/
19:32 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
19:35 < darktama> I wonder why there's such a difference between those dumps.. 
19:36 < darktama> the 0x1ff[04] values are what I'd expect though
19:37 < qfire> hmm... the dumps on the website for g71 I did last using 'OUTPUT_MULTIPLE_FILES' that doesn't show the 1ff4, but if I disable that and run just test_texture_3d it shows 1ff0/1ff4
19:37 < qfire> which way should I be running renouveau to upload the dumps?
19:38 < marcheu> yeah, same here for the g70 dumps
19:40 < darktama> I really should sleep now.. since it's almost 2am and I didn't sleep last night :)
19:40 < darktama> night
19:41 < marcheu> hehe... good night
19:41 < Lumag> night!
19:41 < qfire> g'night
19:55 < KoalaBR_> back
20:00 < Lumag> btw: I see vertex programs stuff under glxinfo on nv11. Has anybody looked into it? Is it done in hw or is it sw emulated?
20:00 < marcheu> most probably sw emulated
20:12 < KoalaBR_> marcheu: test_texture_3d on NV43 gives my this: NV30_TCL_PRIMITIVE_3D      [0x1ff0/4] = 0x00000109
20:13 < KoalaBR_> NV30_TCL_PRIMITIVE_3D      [0x1ff4/4] = 0x00004001
20:13 < KoalaBR_> First time, I see 109 for 1ff0
20:15 < Lumag> I've added M_() that should be used for matrices. Another macro with dumb name,I know :)
20:34 -!- gabrielg [n=gabriel@c-a6df72d5.011-178-73746f44.cust.bredbandsbolaget.se] has joined #nouveau
20:34 < gabrielg> 'evening
20:35 < KoalaBR_> Hi
20:36 < gabrielg> i've got a GeForce 6150 (codename is alegedly C51-PV) here. is there something special you want me to test?
20:36 < gabrielg> or just iterate all test_* in main.c?
20:45 < KoalaBR_> get newest renouveau and test all. It is not a quadro by chance?
20:46 < gabrielg> unfortunately no quadro
20:47 < KoalaBR_> Bad luck...
20:47 < gabrielg> mm, i was in here a couple of days ago
20:47 < gabrielg> and marcheu asked me the same thing :)
20:48 < KoalaBR_> Yes, fuzzy memory on my part :)
20:48 < gabrielg> i know how it is :)
20:49 < KoalaBR_> Well, that is the only card missing. And some developer would die to know how certain tests work on that kind of card
20:50 < gabrielg> then we better find one before something awful happens :)
20:50 < KoalaBR_> Yes
20:52 < gabrielg> but i've seen some quadro-stuff in the cvs-commits mails
20:52 < `Duke`> we should post on a newspaper "looking for a linux user with quadro nv40 o/"
20:52 < gabrielg> i guess there's different quadros
20:52 < KoalaBR_> ;)
20:52 < gabrielg> `Duke`: haha
20:52 < KoalaBR_> Currently, we take any quadro
20:55 < KoalaBR_> gabrielg: You could run the test_clip_plane() and post your result somewhere
20:55 < gabrielg> sure
20:55 < gabrielg> i'm running the tests from the top right now
20:56 < KoalaBR_> Fine
20:59 < gabrielg> oh, enabling OUTPUT_MULTIPLE_FILES and uncommenting all tests is a good thing
21:03 < gabrielg> a bit simpler than enabling each test by hand :D
21:03 < marcheu> yeah, isn't it ? :)
21:04 < marcheu> oh, 6150
21:04 < marcheu> I guess standard tests won't be different, but the initialization is probably a whole different story with that card
21:05 < gabrielg> i'm glad to hear that it'll be useful :)
21:05 < marcheu> don't forget test_startup :)
21:06 < gabrielg> Card has id 0x10de0240 (NV40) unknown bus type (32 Mb video ram)
21:06 < gabrielg> FIFO channel couldn't be detected. PLEASE REPORT
21:06 < gabrielg> ah, right, i'll run it now :)
21:06 < marcheu> hmm, things are getting interesting
21:09 < Lumag> marcheu: another note about softquadro. I still get 10de:0110 from NVRM ioctl :)
21:11 < gabrielg> shall i send these files to someone?
21:11 < marcheu> gabrielg: nope, I'll update renouveau in a moment
21:11 < marcheu> it looks like some changes are needed
21:11 < marcheu> more than I though
21:11 < gabrielg> marcheu: i mean the logs for all the tests
21:11 < gabrielg> ok
21:12 < marcheu> no need for tests when the 2nd line is wrong already :)
21:12 < gabrielg> i think all tests finished fine, except when i uncommented the checks around SDL_SetVideoMode
21:12 < gabrielg> but what do i know :)
21:12 < gabrielg> do your thing, and i'll re-run the tests :)
21:13 < marcheu> they might, but I'd like to understand the FIFO enable reg on that card
21:13 < gabrielg> got ya
21:16 < marcheu> ok, could you update please ?
21:17 < gabrielg> yep
21:17 < gabrielg> test_startup first, or SDL_SetVideoMode?
21:18 < marcheu> for now, I'm interested in the PLEASE REPORT line :)
21:18 < gabrielg> ok :)
21:19 < gabrielg> Using FIFO channel 2
21:19 < gabrielg> is that the corresponding line?
21:19 < marcheu> hmm, you don't have PLEASE REPORT anymore ?
21:19 < gabrielg> i don't get any PLEASE REPORT anyway
21:19 < gabrielg> nope
21:19 < marcheu> hmmm
21:20 < marcheu> maybe it was simply a reg caching issue
21:20 < gabrielg> but, let me stress that i really think that i only saw that line for one test
21:20 < marcheu> ah
21:22 < marcheu> so which one fails for you ?
21:22 < gabrielg> i believe it was the SDL_SetVideoMode one
21:22 < marcheu> I mean, this is done on init
21:22 < gabrielg> ah, so it's really before any test?
21:22 < marcheu> so, it says that when you uncomment dump_regs before/after SDL_SetVideoMode ?
21:23 < gabrielg> then i guess it's just purely coincidental
21:23 < gabrielg> marcheu: it did, once
21:23 < marcheu> ok, that might very well be a caching issue
21:23  * marcheu is relieved
21:23 < gabrielg> good :)
21:23 < marcheu> I really didn't feel like hunting for a 2nd fifo register
21:23 < gabrielg> heh
21:24 < marcheu> so yeah, if you've got all the tests as files, you can either send them my way, or I can add you to sf.net so that you upload them yourself
21:25 < gabrielg> i did get myself a sf.net account awhile back, for nouveau
21:25 < gabrielg> one moment and i
21:25 < gabrielg> 'll try to find the details
21:27 < gabrielg> hmm, that mail is on a harddrive lying on the desk beside me.. i think i better mail these files to you :)
21:28 < marcheu> as you like
21:30 < gabrielg> marcheu: hey
21:31 < marcheu> ?
21:31 < gabrielg> marcheu: my old university account is still working
21:31 < gabrielg> www.cs.umu.se/~dva99ggn/card_10de-0240_tests_2006-08-19.tar.gz
21:31 < gabrielg> i put them there
21:31 < marcheu> ok, thanks :)
21:34 < Lumag> another interesting note: via mmtrace I see 2-byte writes to the FIFO. Strange.
21:34 < marcheu> Lumag: hmm ? where ?
21:38 < Lumag> offset 0xe00 of nv10tcl is...  NV10_TCL_PRIMITIVE_3D_INDEX_DATA
21:38 < marcheu> ah, makes sense then
21:39 < Lumag> good :)
21:39 < marcheu> although I'm not sure how that would behave on exotic architectures, we're better of building 32 bit values and writing them in sequential order to be on the same side WRT bus weirdness
21:39 < marcheu> s/same/safe/
21:41 < Lumag> I think endianness is handled by GPU. At least there are some bits which correspond to arch endianness.
21:41 -!- pmdata [i=patrice@ANantes-154-1-91-245.w86-210.abo.wanadoo.fr] has joined #nouveau
21:41 < marcheu> yes, but I'm talking about the chipset here
21:42 < marcheu> weird chipsets don't like when you don't write in sequential order, or mix write sizes
21:42 < marcheu> and you get a nice performance improvement on serious chipsets doing that anyway
21:43 < marcheu> now if the fifo sits in AGP, granted, it's not an issue
21:43 < Lumag> hmm... maybe. Just wanted to note this fact :)
21:43 < marcheu> but we have to support it in VRAM as well
21:44 < marcheu> yeah, the DDX sets some of those bits. it's really makes their obfuscation ridiculous :)
21:46 -!- Myrizio [n=Myrizio@host48-98.pool80104.interbusiness.it] has quit [Read error: 110 (Connection timed out)]
21:48 < KoalaBR_> marcheu: Did some more test regarding 1ff4, these are my results: http://rafb.net/paste/results/Vqsvwa11.html
21:49 < KoalaBR_> Had this 1ff0 -> 0x0209 only twice at the beginning of the test this afternoon. Later I always got 0x0109
21:49 -!- Myrizio [n=Myrizio@host55-98.pool80104.interbusiness.it] has joined #nouveau
21:51 < Lumag> marcheu: another note. sometimes I get 16-byte writes to FIFO :)
21:51 < marcheu> oh ? SSE ?
21:51 < Lumag> yup.
21:52 < Lumag> looks like some fast-window-restore path.
21:52 < Lumag> at least I got this only on some expose events.
21:52 < gabrielg> mmtrace, what's that? trapping writes with mmu tricks?
21:52 < marcheu> KoalaBR_: that's really weird. but I think you should talk about that with darktama, he already has done most of the VP stuff...
21:53 < KoalaBR_> Ok
21:53 < gabrielg> sounds interesting indeed
21:53 < marcheu> KoalaBR_: I think he seemed to have some idea of what it could be, seeing that it changes over time, I have to say I have no idea
21:53 < cptn> KoalaBR_: I have a "budget" quadro, an nvs 280
21:53 < cptn> KoalaBR_: would that help?
21:54 < KoalaBR_> Certainly :)
21:54 < cptn> okay, I'll have to read up on renouveau first though
21:54 < KoalaBR_> Ok
21:55 < cptn> are the tests in main.c potentially dangerous, or why are they commented out?
21:55 < KoalaBR_> pmdata: Here is a quadro owner, wake up :)
21:55 < pmdata> \o/
21:55 < pmdata> no tests are dangerous
21:55 < `Duke`> cptn : there is no dangerous test
21:55 < KoalaBR_> No, they are commented out, because the produce a lot of data
21:55 < cptn> heh, no need to hurry, I have plans for tonight already ;-)
21:55 < gabrielg> cptn: people just like to run then one-by-one
21:56 < gabrielg> them
21:56 < KoalaBR_> normally we concentrate on one or two test and so the rest is commented out
21:56 < cptn> so how about having an array of structs char* -> test function
21:56 < cptn> so one could run ./renouveau <test>?
21:56 < cptn> without recompiling
21:56 < KoalaBR_> Recompiling is not much of a problem
21:57 < pmdata> let me post what I sent to someone else
21:57 < KoalaBR_> at least I do look at the first result of a test and then start changing the code (Parameter values, comment out some call etc)
21:57 < marcheu> yeah, it'd be nice to generate some test_all() automatically
21:57 < KoalaBR_> and compare the result to the first one
21:58 < pmdata> Uncomment OUTPUT_MULTIPLE_FILES and DONT_DUMP_CHANGED_REGS in re.c
21:58 < pmdata> uncomment all tests (startings with test_startup), except the test_overlay and test_swapbuffers (at the end)
21:58 < pmdata> run 'renouveau -f' to get unknown values as floats
21:58 < pmdata> voila
21:59 < cptn> okay
21:59 < gabrielg> then perhaps i should re-run my tests also
21:59 < pmdata> if you have a quadro, then rerun the same tests by enabling the stereo context (before sdl_setvideomode)
22:00 < cptn> okay,
22:00 < pmdata> if you can have a stereo setup of course (2 video output devices, properly configured)
22:00 < cptn> no, it only has a single DVI out
22:00 < cptn> it's an nvs 280 only, one of the cheaper quadros...
22:01 < cptn> marcheu: so if I prepared a patch to run all or individual tests without recompilation, that wouldn't be wasted? :-)
22:01 < KoalaBR_> Of course not :)
22:01 < marcheu> cptn: actually, I'd like to have an automated system
22:02 < marcheu> so that tests_all() would update itself automatically, probably through some Makefile+sed/grep magic
22:02 < cptn> okay, good
22:02 < marcheu> but I'd like to have it generated on the fly, so that tests are added to it at compile time, without the dev having to add each test by hand
22:03 < cptn> okay, sounds reasonable
22:03 < marcheu> well, if you can do that, the better
22:04 < cptn> I'll probably ask a bit more tomorrow, but I'd really like to help
22:04 < marcheu> cool
22:04 < cptn> and it seems like a good tasks to get familiar with the code base
22:06 -!- eLShaman [n=elshaman@pac33-1-82-235-249-217.fbx.proxad.net] has quit ["Au revoir."]
22:07 < pmdata> at last you learn some opengl stuff
22:07 < marcheu> that C51 sure looks nice
22:08 < marcheu> I wonder how fast it is
22:08 < pmdata> quadro dumps are needed even if not stereo
22:08 < pmdata> to compare against standard gpu
22:08 < gabrielg> marcheu: aha!
22:08 < gabrielg> Card has id 0x10de0240 (NV40) bus is integrated (32 Mb video ram)
22:08 < gabrielg> FIFO channel couldn't be detected. PLEASE REPORT (0x2504 is 3/3)
22:09 < cptn> pmdata: okay, I'll have a look at it tomorrow
22:09 < gabrielg> that was for test_overlay 
22:09 < marcheu> gabrielg: ah, test overlay doesn't go through the 3D engine, so it doesn't need a fifo
22:10 < gabrielg> so that's expected, or ok?
22:10 < gabrielg> oh, it never used it, check
22:11 < Lumag> marcheu: I think FIFO channel check can be moved to ioctl.c
22:11 < KoalaBR_> darktama: I know you are asleep, but when you are awake, please have a look here (results for command 1ff0 / 1ff4) and let me know what you think (I will read the logs).
22:12 < KoalaBR_> darktama:  That's from all test, where I found a reference to 1ff0 on your dumps. I did the test on my card for comparison
22:12 < KoalaBR_> So, does anyone need my help regarding unknown commands?
22:15 < gabrielg> marcheu: www.cs.umu.se/~dva99ggn/card_10de-0240_tests_2006-08-19_2.tar.gz
22:15 < gabrielg> marcheu: run according to pmdata's instructions
22:24 < marcheu> gabrielg: are you sure you don't want sf.net access ? :)
22:24 < Lumag> tested vtxprogs on nv10. They are done in s/w :(
22:24 < marcheu> Lumag: did you see how they do it ?
22:25 < marcheu> in mesa, there is experimental code that compiles the shader to SSE, which works pretty well for sw
22:25 < Lumag> no. There are simply no writes to the card other than known writes to FIFO.
22:25 < marcheu> well, I guess we could trap mprotect
22:25 < marcheu> for EXEC
22:25 < pmdata> lumag> of course, if it was hw accelerated on nv10, I would have found it :)
22:25 < marcheu> that'd probably cut it
22:28 < Lumag> pmdata: is there anything that you would like me to look on nv10?
22:30 < gabrielg> marcheu: actually, let me connect that harddrive and i'll get back here in a while
22:30 < gabrielg> it would be nice yeah
22:30 < marcheu> anyway, I'll install that FC5 and see if I still have a crashing libdri here
22:31 < marcheu> bbl
22:31 < gabrielg> yeah, later
22:31 -!- gabrielg [n=gabriel@c-a6df72d5.011-178-73746f44.cust.bredbandsbolaget.se] has quit ["leaving"]
22:31 -!- Seg [n=seg@fedora/Seg] has joined #nouveau
22:31 < pmdata> lumag> maybe the unknown stuff I listed in nv_objects.h? or you can check that I got everything ok
22:31 < marcheu> heh, mention of FC5 makes fedora people pop up :)
22:31 < Seg> ...
22:31 < Lumag> ok, will look into it.
22:32 < Seg> 'sup?
22:32 < pmdata> debian gentoo ubuntu
22:32 < marcheu> pmdata: :)
22:32 < marcheu> pmdata: good idea, we need more people to help
22:32 < `Duke`> o/
22:33 < Seg> I was just kinda wondering when I can dump the damn binary drivers off my system. Heh.
22:33 < marcheu> Seg: depends what level of functionality you need, heh
22:33 < marcheu> Seg: for 3D I usually say I year, which is about reasonable
22:34 < Seg> Playing second life on a multi-seat system. Its horrible, yes.
22:34 < Seg> Right now I have a Geforce2 AGP card and a PCI Geforce4 in there.
22:35 < marcheu> well, if RE people need some dumps, they'll ask you I guess
22:35 < marcheu> anyway, I was going to do that FC5 install
22:35 < Seg> I have a Radeon 9800 SE waiting, but as the nvidia drivers take over the system I don't think I can mix brands. ;P
22:35 < KoalaBR_> marcheu: You don't think it is impossible anymore? :)
22:36 < marcheu> KoalaBR_: next time I'll plan something harder, like climb mont everest
22:36 < KoalaBR_> Has already been done :)
22:36 < Seg> If I could find me a PCI radeon... They're terribly overpriced. Like twice what I paid for the 9800. ;P
22:38 < Seg> I'm up to my ears in old nvidia cards.
22:41 < Seg> Also OpenGL has stopped working on my HTPC which has a GF2.
22:42 < Seg> I dunno WTF is with that card. Open source drivers will lock the system up when X starts, with TV out enabled.
22:43 < Seg> It works with the binary drivers but 3D has stopped working with the last few kernel updates, bleh.
22:44 < Seg> All the other nvidia cards I have don't have these problems. 
22:48 -!- pmdata is now known as pmdata_tv
22:52 -!- gabrielg [n=gabriel@c-a6df72d5.011-178-73746f44.cust.bredbandsbolaget.se] has joined #nouveau
22:53 < gabrielg> marcheu: sourceforge account: gerhardsson
--- Log closed Вск Авг 20 00:00:17 2006