--- Log opened Сбт Июл 29 00:00:01 2006
00:02 < pmdata> renouveau strace:
00:02 < pmdata> open("/dev/nvidia0", O_RDWR)            = 6
00:02 < pmdata> old_mmap(NULL, 134217728, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0x10000000) = 0x408ed000
00:02 < pmdata> ok, another one
00:02 < pmdata> old_mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0x80000000) = 0x489ac000
00:02 < pmdata> then the renouveau one that fails:
00:02 < pmdata> old_mmap(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0xe0000000) = -1 EINVAL (Invalid argument)
00:03 < Lumag> As a temporary solution, you can use /dev/mem for mmaping and run renoveau as root.
00:04 < pmdata> same parameters for mmap, just changing /dev/nvidia0 to /dev/mem?
00:05 < pmdata> I wonder it mmap fails because I run a 2.4 kernel
00:06 < pmdata> "a horse, my kingdom for a horse"
00:07 < Lumag> yes, same params.
00:08 < pmdata> ok, I am ready for a reset then :)
00:09 < Lumag> :)
00:13 -!- pmdata [i=patrice@ANantes-154-1-39-180.w81-53.abo.wanadoo.fr] has quit [Read error: 54 (Connection reset by peer)]
00:14 -!- pmdata [i=patrice@ANantes-154-1-39-180.w81-53.abo.wanadoo.fr] has joined #nouveau
00:14 < pmdata> hello again
00:14 < pmdata> it crashed :)
00:17 < Lumag> :(
00:22 < pmdata> I tried mmap()ing the other addresses used by glxinfo, and it says 'ressource unavailable'
00:24 < pmdata> I wonder if e0000000 is the phys_addr I should use
00:25 < pmdata> lspci says:
00:25 < pmdata>         Memory at e0000000 (32-bit, non-prefetchable) [size=16M]
00:25 < pmdata>         Memory at d8000000 (32-bit, prefetchable) [size=128M]
00:26 < pmdata> tried d8<<24, also invalid argument
00:26 < pmdata> maybe it is the nv driver that 'refuses' to mmap() this memory space?
00:33 < pmdata> X maps:
00:33 < pmdata> 40614000-48614000 rw-s 10000000 03:03 8034       /dev/nvidia0
00:33 < pmdata> 48614000-48624000 rw-s 80000000 03:03 8034       /dev/nvidia0
00:33 < pmdata> 48624000-48634000 rw-s 00800000 03:03 8034       /dev/nvidia0
00:33 < pmdata> 48634000-48635000 rw-s 40000000 03:03 8034       /dev/nvidia0
00:33 < pmdata> 48635000-4863d000 rw-s 40000000 03:03 8034       /dev/nvidia0
00:33 < pmdata> 4863d000-48744000 rw-s 00000000 00:04 0          /SYSV00000000 (deleted)
00:33 < pmdata> 48744000-50744000 rw-s 10000000 03:03 8034       /dev/nvidia0
00:38 < pmdata> when trying to map e0/24, nvrm tells 'NVRM: unknown memory type'
00:39 < pmdata> it happens in nv.c, nv_kern_mmap
00:39 < pmdata> at least we have the source for it
00:42 < Lumag> :)
00:43 < pmdata> 10000000 is NV_MMAP_FB_OFFSET
00:44 < pmdata> and the regs are at NV_MMAP_REG_OFFSET = 0 ???
00:48 < Lumag> strange
00:52 < pmdata> I put the 'cat maplist.txt' at start:
00:52 < pmdata> 40024000-40025000 rw-s 40000000 03:03 8034       /dev/nvidia0
00:52 < pmdata> 408ed000-488ed000 rw-s 10000000 03:03 8034       /dev/nvidia0
00:52 < pmdata> 489ac000-48aae000 rw-s 80000000 03:03 8034       /dev/nvidia0
00:52 < pmdata> 48aae000-48abe000 rw-s 00810000 03:03 8034       /dev/nvidia0
00:52 < pmdata> I don't have e0000000 listed
00:55 < Lumag> What's the exact version of the driver you are using?
00:57 < pmdata> 1.0-3123, kernel 2.4.27
00:57 < pmdata> do you also use 1.0-7xxx even for your tnt cards?
00:59 < Lumag> 7182
01:01 < pmdata> I think I will install it when I have finished with 3xxx tests
01:01 < pmdata> 7174 till then
01:02 < pmdata> I will also try 4,5,6 series I think
01:02 < pmdata> they may do some stuff differently
01:05 < Lumag> Probably I should also install some older distro with 2.4 kernel and test various nvidia versions.
01:07 < pmdata> I was lucky debian 3.x still has 2.4 package
01:08 < pmdata> anyway, I saw that my system is much faster with 2.4, surely because I don't have a 2.6 optimized for my cpu
01:09 < Lumag> Also on debian (unstable), but I don't want to clobber my system with 2.4 packages. Also the setup is already pretty dependant on 2.6/udev/etc.
01:10 < Lumag> I must have woody disks somewhere.
01:12 < pmdata> ah, I forgot to compile the nv module with -DDEBUG, it adds some lines to dmesg 
01:20 < pmdata> I think I won't be able to find why renouveau does not work here, someone else will have to look at it
01:22 < pmdata> I will also retry softquadro with it
01:30 < pmdata> marcheu said yesterday that there are patches to compile the nv module for 2.6
01:30 < pmdata> but minion.de where some resided seems to be closed
01:31 < pmdata> I think that such an old module won't compile without huge changes
01:38 -!- pmdata [i=patrice@ANantes-154-1-39-180.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:58 -!- tibbs|h is now known as tibbs
02:16 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
02:25 < philv> Anyone have the SATA-IO spec?
02:25 < philv> (Off topic, but I can't find it anywhere)
02:46 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:51 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
04:00 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
05:15 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
05:38 < ddl> hey
06:03 -!- shenki [n=shenki@ppp153-94.lns3.adl2.internode.on.net] has quit [Read error: 60 (Operation timed out)]
06:14 -!- shenki [n=shenki@ppp161-240.lns3.adl4.internode.on.net] has joined #nouveau
06:18 < Lumag> hi
06:22 < ddl> hi lumag
06:22 < ddl> hows things going?
06:24 < Lumag> progress with r/e, no progress with real drawing
06:25 < Lumag> darktama got rendering working with nvidia kernel module, but not with drm.
06:27 < Lumag> pmdata tried using older drivers (1.0-4xxx) but had no success. The mmap interface changed somewhere in the middle.
06:27 < ddl> that still is progress :)
06:27 < Lumag> yup :)
06:27 < ddl> trying to figure out more about the initialization procedure 
06:28 < ddl> bios stuff
06:28 < Lumag> :)
06:28 < ddl> but i havent had that much time to work lately
06:28 < Lumag> same here
06:47 -!- arachnist [i=arachnis@hive.bsic.pl] has quit [Read error: 110 (Connection timed out)]
07:10 -!- shenki [n=shenki@ppp161-240.lns3.adl4.internode.on.net] has quit ["Leaving"]
09:45 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has quit [Read error: 104 (Connection reset by peer)]
12:01 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
12:06 -!- pmdata [i=patrice@ANantes-154-1-66-83.w86-195.abo.wanadoo.fr] has joined #nouveau
12:06 < pmdata> hello
12:06 < EdB|w> hi
12:07 < EdB|w> pmdata, i receive a lot of maill from you, to you want to tell me something ? :o)
12:12 < pmdata> what do you mean? renouveau cvs commits, or spam?
12:12  * pmdata running 1.0-4191 now
12:12 < EdB|w> yes i meen renouveau cvs commits :o)
12:20 < pmdata> ah
12:20 < pmdata> edb> what is your hw?
12:25 < EdB|w> nv28
12:26 < pmdata> could you make me a dump of test_nv_register_combiners?
12:28 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has joined #nouveau
12:28 < pmdata> ah, renouveau works with 1.0-4191, no 'invalid argument' for mmap
12:29 < EdB|w> pmdata, actually no, as i am at work
12:29 < EdB|w> only got an nv at home
12:30 < pmdata> ah, yes, did not see the |w in your nick :)
12:32 < pmdata> too bad, ext_vertex_weighting is not in 1.0-4191
12:32 < EdB|w> :o)
12:33 < EdB|w> you run 1.0-4191 because you are on 2.4 kernel and you've got on old card ?
12:37 < pmdata> I use 2.4 to run old drivers (especially when 2.6 was not even on the radar), and yes, my nv15 is supported since the first versions
12:41 < pmdata> but drivers 1xxx or 2xxx will require a gcc 2 compiled kernel, and an old xfree 4.0
12:49 < pmdata> I don't have a free partition to install an old linux
12:51 -!- johill [n=johannes@p5487E6AF.dip.t-dialin.net] has joined #nouveau
13:04 < pmdata> ah, nv17 (gf4mx) have both idct and motion compensation support, gf4 only have motion compensation support
13:05 < pmdata> someone should patch mplayer to do nv dumps with libxvmcnvidia enabled
13:12 < EdB|w> pmdata why did you test old realese driver ?
13:13 < pmdata> I wanted to check EXT_vertex_weighting to see if it was hardware supported or not (need 3121 or older, removed since 4xxx)
13:13 < EdB|w> ok
13:14 -!- johill [n=johannes@p5487E6AF.dip.t-dialin.net] has quit [Read error: 113 (No route to host)]
13:14 < pmdata> there is also NV_texgen_emboss which has been removed
13:15 < EdB|w> those are remove because of useless ?
13:26 < pmdata> yep, deprecated in favor of vertex_program (for the first), and texture_shader for the second I think (or register combiners)
13:27 < pmdata> it does not mean the hw does not support them
13:28 < pmdata> nv20 has a vertex weight attribute
13:28 < pmdata> so I think nv10 still has one
13:39 < pmdata> hum maplist with 4191:
13:39 < pmdata> Couldn't determine address of AGP aperture
13:39 < pmdata> map 0	from 0x40024000 to 0x40025000 size 0x1000 (physical 0x9cc1000)	=> registers
13:39 < pmdata> map 1	from 0x40a05000 to 0x48a05000 size 0x8000000 (physical 0xd8000000)	=> no dump
13:39 < pmdata> map 2	from 0x48ade000 to 0x48be0000 size 0x102000 (physical 0xc0010000)	=> fifo
13:39 < pmdata> map 3	from 0x48be0000 to 0x48bf0000 size 0x10000 (physical 0xe0810000)	=> registers
13:39 < pmdata> map 4	from 0x48d06000 to 0x49d06000 size 0x1000000 (physical 0xe0000000)	=> no dump
13:40 < pmdata> I wonder why the latest can not be mmaped with 3123
13:41 < pmdata> aaah, something interesting with 4191:
13:41 < pmdata> a22   0x00042ce4   0x00042ce4             {size: 0x1   channel: 0x1   obj: beef5601 opcode: METHOD }
13:41 < pmdata> a23   0x3f800000   0x3f800000            NV10_TCL_PRIMITIVE_3D      [0x0ce4/4] = 1.000000 | UNKNOWN = 3f800000
13:42 < pmdata> vertex weight?
13:45 < pmdata> definitely a good idea to make dumps using old drivers
13:54 < pmdata> hint: don't dump object that is not 0xbeefxxxx
13:54 < pmdata> in renouveau, don't know where to filter that
13:58 < pmdata> light stuff, a 4*3 matrix at 0x4c0
14:00 < pmdata> a second inverse matrix?
14:00 < pmdata> color matrix?
14:01 < lumag_offline> pmdata: actualy there are non-beef objects. E.g. X server uses 0200 and beff prefixes. I think there were other prefixes...
14:03 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
14:03  * lumag_offline is installing woody right now.
14:12 < pmdata> good news: vertexweight function still present in 4191
14:12 < pmdata> so I disabled the check for the extension, and it ran!
14:13 < pmdata> 0x400 is weight0 matrix, 0x440 is weight1 matrix
14:14 < pmdata> 0xce4 is vertex weight
14:15 < pmdata> 0x328 may be enable vertex weight?
14:17 < pmdata> yep, confirmed
14:17 < lumag_offline> :)
14:18 < pmdata> anyway lumag, I'm still interested for dumps with old drivers (3xxx or older)
14:19  * pmdata fill the need for a big renouveau cvs commit
14:19 < pmdata> I fill dirty
14:20 < pmdata> s/fill/feel/
14:20 < lumag_offline> btw: it may be a good idea to mark examined extensions. E.g. I've started the page with nv04 extensions :)
14:21 < lumag_offline> about 3xxx series, I think I'll try hacking the support
14:21 < lumag_offline> for that old versions
14:25 -!- EdB [n=EdB@ARennes-251-1-97-83.w86-199.abo.wanadoo.fr] has joined #nouveau
14:27 < lumag_offline> btw: why we have no tests for stencil buffer?
14:27 < EdB> pmdata, on my nv28 board
14:27 < EdB> what test do you want i made ?
14:30 < pmdata> nv_register_combiners
14:30 < pmdata> lumag it's too easy to find
14:31 < pmdata> ff, 207 00 ff, 1e00 1e00 1e00
14:31 < pmdata> this is stencil setup
14:33 -!- lumag [n=lumag@ptr65.lumag.pp.ru] has joined #nouveau
14:34 < EdB> mmm
14:34 < lumag> not for everyone :) I think that for nv04 stencil is supported only for dx6 triangles, not for dx5 ones.
14:34 < EdB> need some #ifdef
14:34 < EdB> tests.o: dans la fonction « test_ext_vertex_weighting »:
14:34 < EdB> /home/edb/Prog/nouveau/renouveau/tests.c:1484: référence indéfinie vers « glVertexWeightfEXT »
14:36 < pmdata> you have to comment the whole
14:36 < pmdata> I have to comment all vertex/shader stuff to compile for 4191
14:36 < pmdata> we should go dynamically loading the gl lib
14:37 < pmdata> lumag> ah, yes, no tcl engine for <nv10 :)
14:38 < EdB> pmdata, i have 1.5.6 NVIDIA 87.62
14:38 < EdB> you want me to downgrade ?
14:42 < EdB> pmdata, my log : http://www.rafb.net./paste/results/1Hyeb956.html
14:42 < pmdata> no I just want to see combiners constant colors
14:44 < pmdata> aah, a60,a80 and 1e20,1e24
14:45 < pmdata> hum, a60 = 1e20 = color 0
14:46 < pmdata> a80 = 1e24 = color 1
14:52 < EdB> where can GL_EXT_vertex_weighting be defined ? I don't find it on glx.h nor gl.h but my preprocessor say that it's defined
14:53 < pmdata> in GL/glext.h
14:53 < EdB> erf ...
14:57 < EdB> #ifndef GL_EXT_vertex_weighting
14:57 < EdB> #define GL_EXT_vertex_weighting 1
14:57 < EdB> ...
14:59 < pmdata> just comment out the test function
14:59 < EdB> pmdata, i've done that
14:59 < pmdata> so what is your problem?
14:59 < EdB> not a clean way
15:00 < EdB> i don't want to do that every time
15:00 < EdB> so try to find why :o)
15:00  * pmdata too, we must load libgl (not link to it), then retrieve gl function pointers 
15:23 < pmdata> lumag> you can test with ext_stencil_two_side, just comment the lines about the stencil side to use
15:33 -!- lumag [n=lumag@ptr65.lumag.pp.ru] has quit [Read error: 110 (Connection timed out)]
15:33 < pmdata> .
15:35 -!- EdB [n=EdB@ARennes-251-1-97-83.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:47 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
15:51 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
16:25 -!- pmdata [i=patrice@ANantes-154-1-66-83.w86-195.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
16:25 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
17:39 -!- lumag [n=lumag@ptr65.lumag.pp.ru] has joined #nouveau
17:39 < lumag> hi all
17:41 < lumag> I've checked the 3123 driver version. Two new extensions: EXT_vertex_weightening and NV_evaluations
17:51 -!- lumag [n=lumag@ptr65.lumag.pp.ru] has quit ["back to work"]
18:05 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has joined #nouveau
18:21 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
18:26 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has joined #nouveau
18:34 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
18:52 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has quit [Connection timed out]
18:53 -!- Duke` [n=gnu@ANantes-251-1-156-72.w86-203.abo.wanadoo.fr] has joined #nouveau
19:19 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has joined #nouveau
19:19 < sturmflut> re
19:21 < EdB|w> hi
19:21 < sturmflut> Does anybody know the data type used by *_3D_ALPHA_FUNC_REF? It's set to PRINT_X32 in objects.c but it must be some floating-point representation and I don't know much about that
19:23 < sturmflut> I found that 0.5f is 0x00000080, 10.0f is 0x000009f6 and -10.0f is 0x0000f60a. Maybe that helps
19:26 < sturmflut> It's not 32-Bit IEEE-754 as it seems
19:30 -!- greaterd [n=greaterd@modemcable189.26-56-74.mc.videotron.ca] has joined #nouveau
19:31 -!- greaterd [n=greaterd@modemcable189.26-56-74.mc.videotron.ca] has quit [Client Quit]
19:34 -!- jphenix [n=greaterd@modemcable189.26-56-74.mc.videotron.ca] has joined #nouveau
19:35 < jphenix> hi, I'm trying to make renouveau CVS work on my FC5 x86_64 system and I have a bunch of problems. I have one that I managed to fix, anyone interrested in the patch?
19:38 < Lumag> sturmflut: and 1.0 is near 0x100?
19:38 < sturmflut> Yes, 1.0f is 0x000000ff
19:39 < Lumag> so it's simply 0x100  * val :)
19:40 < Lumag> jphenix: what problems do you have?
19:41 < jphenix> a couple compilation problems, one related to the fact that _syscall3 is not defined
19:41 < jphenix> adding #include <linux/unistd.h> did fix it
19:42 < jphenix> I did a grep in /usr/include to see if a more generic include did include linux/unistd.h but nothing came up
19:44 < jphenix> ther eis also other issues I'm working on at the moment
19:47 < sturmflut> Lumag: Do we already have a Macro/PrintFunc for this storage format?
19:48 < Lumag> no
19:50 < sturmflut> Okay. I think I'm not capable of writing one, can I document my discovery somewhere so maybe somebody who knows how to do it has all the information?
19:51 < sturmflut> Maybe some Wiki page
19:52 < Lumag> There are some wiki pages, some doc files in CVS, but most documentation lies nowhere :)
19:54 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
19:58 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
20:02 -!- svu_ [n=svu@194.46.172.8] has joined #nouveau
20:05 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
20:10 -!- svu [n=svu@host-194-46-251-124.dsl-ie.utvinternet.net] has quit [Read error: 60 (Operation timed out)]
20:22 -!- EdB [n=EdB@ARennes-251-1-65-227.w86-195.abo.wanadoo.fr] has joined #nouveau
20:38 -!- johill [n=johannes@p5487E6AF.dip.t-dialin.net] has joined #nouveau
20:45 < jphenix> how can we apply a patch generated with cvs diff -u?
20:48 < johill> jphenix: patch should take it
20:49 < johill> so far I've only seen one patch version that didn't like unified diffs, and that was on a HP-UX 10 system =)
20:52 < jphenix> hmmm, doesn't work, patch is able to deal with that stuff? RCS file: /cvsroot/nouveau/renouveau/re.c,v
20:54 < jphenix> I'm tryung to apply a patch that I have generated to see if it actuallt works, trying with 'patch -p3 < file.patch', not sure if the p argument is correct however...
20:54 < Lumag> use -p0
20:54 < jphenix> thnaks, it worked! (with -p0)
20:56 < EdB> is that corect ? http://www.rafb.net./paste/results/GnVIYB39.html
20:59 < Lumag> I think yes.
21:00 -!- pmdata [i=patrice@ANantes-154-1-81-80.w81-48.abo.wanadoo.fr] has joined #nouveau
21:00 < jphenix> where I can send the patches?
21:01 < EdB> pmdata, can i get you mind on  http://www.rafb.net./paste/results/GnVIYB39.html
21:01 < jphenix> I'm not sure they are 100% right, but they show the source of the problem at least
21:02 < pmdata> edb> quite wrong
21:02 < EdB> ah ?
21:02 < pmdata> replace glXGetProcAddressARB with SDL_GL_GetProcAddress instead
21:02 < pmdata> and GL_EXT_vertex_weitghting is not the function name you look for
21:02 < EdB> (it's a firt try and i not familar with that)
21:03 < EdB> why SDL_GL_GetProcAddress ?
21:03 < pmdata> because we use SDL? this is the function to use
21:03 < pmdata> _glVertexWeightfEXT = (PFNGLVERTEXWEIGHTFEXTPROC)SDL_GL_GetProcAddress("glVertexWeightfEXT");
21:04 < EdB> ok
21:04 < pmdata> the libGL must be dynamically loaded also
21:05 < pmdata> SDL_GL_LoadLibrary("libGL.so.1")
21:05 < pmdata> before the setvideomode in main.c
21:06 < EdB> do i have to change compilation flag too ?
21:06 < pmdata> it also means all opengl functions must be queried through getprocaddress
21:06 < pmdata> ie glbegin, glend, etc...
21:06 < EdB> pmdata, sure ?
21:06 < pmdata> yep, no need to link to libGL, you can remove -lGL from LDFLAGS
21:07 < EdB> i see gl engine wich load some gl function dynamically but don't do it for all
21:08 < pmdata> http://www.libsdl.org/cgi/viewvc.cgi/branches/SDL-1.2/test/testdyngl.c?revision=2608&view=markup for an example
21:09 < Lumag> pmdata: I think I fixed the renv for older drivers. At least it worked for me with 3123 :)
21:11 < pmdata> can you explain what caused the problem?
21:13 < pmdata> do you need a stencil test function? I can write one
21:14 < EdB> pmdata, can you explain me why we need to load all gl fuction dynamically ?
21:16 < Lumag> The convention of mmaping changed around 4000. E.g. before regs were mapped from 0 offset, now they use real phys_addr.
21:16 < Lumag> no, already wrote it :)
21:16 < Lumag> the stencil and z-buffers seem to be packed inside the same address space. is it normal?
21:18 < jphenix> lumag: it seems that you have CVS commit access, I have a few patched to be reviewed before they can be commited to renouveau, tell me when/how you want them, etc...
21:20 < Lumag> jphenix: please use www.rafb.net/paste and tell us the url you get.
21:20 < pmdata> edb> with sdl_gl_loadlibrary you load a specific opengl lib, and sdl_gl_getprocaddress takes function pointer from this one
21:20 < pmdata> the libgl linked statically may be different
21:20 < pmdata> think of it as 2 different gl libs
21:21 < pmdata> it does not mean the data is shared even if the libs are the same
21:21 < jphenix> ok Lumag
21:23 < Lumag> pmdata: also driver 1.0.3123 had NV-CONTROL extension, but probably used different wire protocol, so I had to disable card type detection.
21:25 < pmdata> I also have dump problems when using glteximage2d, renouveau lose is mind with big textures
21:26 < jphenix> Lumag: check out http://www.rafb.net/paste/results/JdJJqm73.html
21:26 < pmdata> well, 32x32 or higher makes it mad
21:26 -!- svu_ is now known as svu
21:27 -!- svu [n=svu@194.46.172.8] has left #nouveau ["Ex-Chat"]
21:27 < Lumag> mad?
21:30 < Lumag> jphenix: I think second seems to be ok, I'll commit it. The first problem is known and will be fixed in another way. Currently you can just replace #ifndef GL_EXT_vertex_weighting with #if 1 :)
21:30 < Lumag> pmdata: what do you mean by 'mad'?
21:33 < Lumag> Huh. I think I've finished both triangle objects control fields. There are some bits left, but they are unchanged no matter what I do.
21:33 < pmdata> well, it dumps endlessly
21:33 < pmdata> and sometime even segfault
21:34 < pmdata> try test_mipmap 
21:37 < pmdata> lumag> you test for 0x10de in /proc/bus/pci/devices, but you must also test this is a video, vga pci device
21:37 < pmdata> nvidia does other hw than gpus
21:37 < Lumag> yes... Damn. 
21:41 < jphenix> Lumag: ok cool :) I will take a look at renouveau since it now compiles, I have the following device: 01:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600/GeForce 6600 GT] (rev a2), is it a part of a known category of NV chipsets?
21:42 < jphenix> Lumag: this is also the last patch about _syscall3 which you didn't comment on
21:43 < sturmflut> I am seeing strange things on my NV28, http://www.rafb.net./paste/results/tk721Z59.html
21:44 < sturmflut> It seems that every call to glVertex3i() is represented by at least two commands, but the opcodes are different every time.
21:45 < sturmflut> Tested it with test_alpha and test_blend, same thing for both
21:46 < Lumag> jphenix: Uhm. sorry, I missed the first patch. the glFlush() warning is ok, it shouldn't fail the compilation.
21:47 < Lumag> pmdata: it seems to be impossible to get device class from bus/pci/devices :( 
21:48 < jphenix> Lumag: ok
21:49 < pmdata> isn't it in the following bytes after the pci id?
21:49 < Lumag> no.
21:50 < Lumag> I called test_mipmap(). I had to disable GL_GENERATE_MIPMAP_SGIS :), but after long texture upload, I see FIFO dump.
21:50 < pmdata> just see that
21:51 < Lumag> will retry with 512x512 texture
22:02 < Lumag> pmdata: strange. It took long, but the dump with 512x512 bytes texture finished w/o errors.
22:03 < pmdata> when I dump to a file, I only see wrong stuff, and the tri() command is not outputted
22:04 < Lumag> really strange. it works for me w/o any problems.
22:11 -!- MrAsd [n=MrAsd@host145-231.pool8254.interbusiness.it] has joined #nouveau
22:12 < Lumag> I want to change tri()  to really draw a triangle. Is it ok?
22:15 < jphenix> I get the following while running renouveau by dump9ing tri(): Unknown bits in context: 00010000 PLEASE REPORT!   <---------- interresting or not?
22:17 < Lumag> yes. Could you please post the dump to rafb.net?
22:17 < pmdata> lumag> yes, do that
22:17 < jphenix> sure
22:21 -!- MrAsd [n=MrAsd@host145-231.pool8254.interbusiness.it] has quit [Remote closed the connection]
22:21 < jphenix> http://www.rafb.net/paste/results/yoNtES55.html
22:24 < sturmflut> Lumag: The device class (as specified by the PCI consortium) can be found in Byte 11 and 12 of /proc/bus/pci/*/*. VGA compatible cards will have a class ID of 0x0300. e.g. "hexdump -s 10 -n 2 /proc/bus/pci/01/00.0" should work on most machines with AGP as AGP is nearly always PCI Bus 01 and has only one device
22:26 < sturmflut> Things get even easier if the machine has sysfs
22:26 < jphenix> I see that there is a lot of "UNKNOWN" in the dump I posted, I guess no ones have the exact same chipset I guess, right?
22:31 < sturmflut> jphenix: NV40 offers lots of functionality. As you can see there are very few commands prefixed with NV40_ in objects.c
22:33 < jphenix> I guess I will have fun figuring how it works :) is there any guide which can help to get started to do such things? I mean, 5 commands resulted in soo much information generated...
22:34 < pmdata> edb> I made a dyn loader for renouveau (well, I already wrote one for another program), I can commit if you want
22:34 < pmdata> but the tests.c should be modified
22:38 < pmdata> hum, I like some vertex program stuff
22:38 < pmdata> can't commit
22:38 -!- pmdata is now known as pmdata_tv
22:44 < EdB> pmdata_tv, ok i lest you doing dyn loads
22:44 < EdB> and i go watching the tv too :o)
23:17 -!- jphenix is now known as jphenix_away
23:52 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
23:53 < sturmflut> I wrote a small Ruby script that takes a bunch of renouveau dumps, analyzes them and outputs a list of unknown command opcodes that only appear in a single dump. I think that makes it easier to distinguish "general" commands (those that are called by the driver, by SDL etc. regardless of what our tests do) from the opcodes triggered "on purpose" by a test
23:53 < sturmflut> It's far from perfect, you can get it at http://www.rafb.net./paste/results/4OzWvB23.html
--- Log closed Вск Июл 30 00:00:01 2006
