--- Log opened Птн Июл 28 00:00:00 2006
00:00 < pmdata> http://developer.nvidia.com/object/Guard_Band_Clipping.html they say it is a hardware feature
00:01 < marcheu> lemme read
00:02 < marcheu> yeah, that's what I though
00:03 < marcheu> guard band means that the rasterizer accepts coordinates that are outside the screen, to avoid having the CPU do the clipping
00:03 < marcheu> but when the chip does hw TCL anyway, what's the point ?
00:05 < pmdata> I don't know, but internally maybe the chip does fixed point math for some stuff
00:06 < pmdata> 2048 = 2^11, there is 5 bits left (16 bits) or 21 (32 bits)
00:06 < pmdata> I forget the sign, so 4 or 20 bits left
00:07 < marcheu> well, if it's guardband parameters what's that 16777215 doing here ? that one looks more like a z value
00:08 < marcheu> or maybe there's internal guardband inside the TCL for some reason (maybe the ability to bypass the TCL unit can speed up thing a little)
00:11 < pmdata> on nv15, depth is 24 bits (with 8 bits stencil)
00:12 < pmdata> so the depth value is in the range 0..2^24-1
00:12 < marcheu> yeah, so what's the link with a potential guardband implementation ?
00:12  * pmdata should test in 16 bits mode
00:12 < marcheu> which really doesn't care about z values
00:12 < pmdata> I don't know
00:18 < marcheu> btw what are NV10_TCL_PRIMITIVE_3D_SET_OBJECT0 & friends for ?
00:21 < pmdata> I don't know, they are set in your big dump
00:21 < marcheu> yeah
00:21 < marcheu> it's an object, but no idea what
00:22 < pmdata> regarding previous stuff, it's like there is a: 3d space -> 2048x2048 space -> screen space
00:22 < marcheu> yes, because things like the hierachical zbuffer can only operate on a 2048^2 region
00:22 < marcheu> so you have to place it correctly
00:23 < Lumag> marcheu: as for me nearly all objects get other objects as params (e.g. surfaces for drawing, ROP's, etc.)
00:23 < marcheu> Lumag: yeah, but that doesn't tell us what interaction it has with other objects
00:24 -!- johill [n=johannes@p5487F308.dip.t-dialin.net] has quit [Read error: 113 (No route to host)]
00:24 < pmdata> this is strange I don't see those objects set on nv15, only on nv15gl dump
00:24 < Lumag> pmdata: try examing the start of fifo :)
00:24 < pmdata> yep, I will have to find which test function triggered them
00:25 < marcheu> it might be related to the UBB stuff again
00:26 < Lumag> what's the type of referenced object?
00:27 < pmdata> I don't know, marcheu should redo the dump
00:27 < pmdata> and he should try to make it smaller :)
00:27 < Lumag> in most cases 0x180 offset is dma_notify .
00:28 < pmdata> hum, calling display list test I think
00:29 < pmdata> lumag> do you have nv_register_combiners extension? could you make me a dump?
00:29 < Lumag> no, don't have it.
00:29 < pmdata> ok
00:29 < marcheu> he has texture_env_combine4 though :)
00:30 < pmdata> hum, yeah, he could dump that
00:30 < marcheu> I'll fix renouveau and redo those dumps
00:30 < pmdata> we should add a printf("test_machin\n"); at the start of each test function
00:30 < Lumag> I've already tested ext_texture_env_combine and nv_texture_env_combine4.
00:30 < marcheu> yeah, I added one to most of those
00:31 < Lumag> They are done via multitexturing triangles.
00:31 < marcheu> that's very useful when running all the tests
01:29 < pmdata> will you fix renouveau and make a dump tonight?
01:30 < marcheu> hmm, what timeframe ?
01:30 < marcheu> ok, let's see
01:31 < pmdata> 30mn till 00:00
01:31 < marcheu> sounds like a challenge
01:31 < pmdata> :), if I can't look at it tonight, I will do it tomorrow, no problem
01:36 -!- EdB_ [n=EdB@ARennes-251-1-23-117.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
01:56  * pmdata have to leave
01:56 -!- pmdata [i=patrice@ANantes-154-1-71-242.w86-195.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:56 < marcheu> hey, I have 4 minutes left you cheater !!
01:57 < Lumag> :)
01:58 < marcheu> but really, /dev/nvidia0 is refusing me mapping the fifo. that's pretty strange
01:58 < marcheu> while I can map all_regs without problems
02:01 < Lumag> Use /dev/mem :)
02:02 < Lumag> There can be some session restrictions...
02:02 < marcheu> it's bad, requires root privs
02:02 < marcheu> I don't have root privs on the G70, or the quadro FX at university
02:03 < marcheu> so I'd rather keep renouveau usable by any user
02:16 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:16 -!- _Anarchy_ [n=alan@81.2.110.250] has joined #nouveau
02:17 -!- haypo [n=haypo@82.247.156.212] has joined #nouveau
02:17 < haypo> hi! i'm new :-)
02:17 < marcheu> hey haypo 
02:18 < marcheu> _Anarchy_: hmm, are you who I think you are ?
02:18 < _Anarchy_> marcheu: possibly
02:18 < marcheu> I'm impressed
02:18 < Lumag> we can use /dev/mem as a fallback.
02:18 < _Anarchy_> marcheu: long ago I wrote some deobfuscators for the original Nvidia 'obfuscated' source driver
02:18 < haypo> are you able to give a date for first "working" nouveau driver release?
02:18 < haypo> working means: able to display Xorg for example
02:18 < marcheu> haypo: not really, I usually say 1 year
02:19 < haypo> 1 year! that's too much for me :-)
02:19 < marcheu> _Anarchy_: yeah, airlied told me
02:19 < _Anarchy_> and I was wondering whow ants the bits
02:19 < marcheu> _Anarchy_: got any intersting stuff I might not have ?
02:19 < _Anarchy_> marcheu: dunno, but I can at least read my source tree ;)
02:20 < haypo> _Anarchy_: i never understand, Nvidia give a big binary... does the binary contains the source code,
02:20 < haypo> ?
02:20 < _Anarchy_> haypo: early on their code was an obfuscated C mess
02:20 < marcheu> _Anarchy_: well, if you've got docs, I'm always interested
02:20 < _Anarchy_> then they went binary
02:20 < marcheu> I have some form of the nvsdk/nvosdk
02:21 < _Anarchy_> marcheu: thats the one.. 
02:21 < haypo> _Anarchy_: but, if "precompiled module" doesn't exist, driver calls gcc. so the installer download/uncipher source code!?
02:22 < marcheu> _Anarchy_: well, if you have a link, I'm all ears. or you can mail something to me at marchesin@icps.u-strasbg.fr
02:24 < darktama> hm, I have a fairly readable form of nvosdk.. using the scripts in nvsrc
02:24 < Lumag> marcheu: what do you get in kernel logs from the failing mmap?
02:24 < marcheu> darktama: did that stuff ended up working ? I thougt it needed a 3rd package we don't have
02:24 < _Anarchy_> marcheu: I'll send you the bits of decode stuff I wrote back then
02:24 < _Anarchy_> its pretty ugly but it knows how to put register names in and the like
02:25 < marcheu> _Anarchy_: ok, basically all we have is there : http://nouveau.cvs.sourceforge.net/nouveau/renouveau/nv_objects.h?revision=1.147&view=markup
02:25 < darktama> yeah, it worked well enough.. I just copied the other dirs into nvsrc/.. and hacked out a couple of pieces in the script
02:26 < marcheu> darktama: ah, nice. didn't know you did that
02:26 < darktama> hm, I assumed that's what everyone did :)
02:26 < marcheu> too lazy :)
02:26 < marcheu> (and I was focusing on nv40 at the time)
02:28 < Lumag> and IIRC the pblished code didn't even work for nv04 properly...
02:28 < darktama> http://members.iinet.net.au/~darktama/nvosdk-unscrambled.tbz2
02:28 < _Anarchy_> darktama; cool good someone already also did that work
02:29 < darktama> marcheu: btw, what did you intend by "pNv->PMC[0]=0x17111113;" in nv_setup.c? isn't power control 0x00000200?
02:30 < marcheu> darktama: each bit is a card unit. that is supposed to power all known units
02:30 < marcheu> darktama: I think it's documented in nv10reg.h
02:30 < marcheu> the issue is the card doesn't completely come out of a shutdown/powerup cycle
02:30 < marcheu> and starts acting weird
02:30 < darktama> yes, but PMC is mapping regs+0x00000000 and the power control is regs+0x00000200 isn't it?
02:31 < marcheu> hmm, lemme see, that might explain issues
02:32 < marcheu> argh
02:32 < Lumag> yeah. PMC[0] is a BOOT_ID :)
02:32 < _Anarchy_> if its like NV04 the driver brings up bits in specific orders
02:32 < marcheu> darktama: yeah, that's supposed to be 200 :(
02:32 < marcheu> darktama: so maybe the bios code works after all
02:32 < darktama> hehe
02:33 < marcheu> _Anarchy_: the haiku driver brings up everything at once and works fine, so..
02:33 < darktama> well, nv_hw.c writes the reg at the very top of LoadState anyway
02:33 < _Anarchy_> NV04 carefully sets PMC_ENABLE to 0x01010100
02:34 < _Anarchy_> then sets 1<< 20
02:34 < _Anarchy_> then looks at boot 0 and decides if its doing 04/05 init
02:34 < Lumag> bit 20 is PFB
02:35 < _Anarchy_> would make sense as it goes dac whacking after that
02:36 < Lumag> and 01010100 is PCRTC, PPMI, PFIFO
02:36 < Lumag> IIUC :)
02:40 -!- `Duke` [n=gnu@ANantes-251-1-132-51.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:42 < Lumag> marcheu: from which memory is FIFO on quadro's allocated?
02:42 < marcheu> Lumag: which as in ?
02:42 < marcheu> Lumag: system memory, if that's what you mean
02:42 < Lumag> yeah.
02:43 < marcheu> just like geforce (on my softquadro at least)
02:43 < marcheu> yeah we should support that at some point. moving the fifo to system ram
02:43 < marcheu> but we have keep support for it in vid ram as well
02:44 < Lumag> strange. It's allocated from AGP mem on nv06
02:44 < darktama> hm, I've been meaning to see if I can move the FIFO into AGP.. I'll add it to my list, I keep forgetting
02:45 < marcheu> Lumag: yeah, system agp mem
02:45 < darktama> it's AGP on NV40 aswell with nvidia's driver
02:45 < marcheu> Lumag: but still system, as opposed to the nv's vid mem
02:45 < marcheu> not sure if I'm being clear
02:45 < Lumag> yes.
02:46 < Lumag> Do you have anything in kernel logs from failed mmaps?
02:46 < marcheu> Lumag: yeah, the proprietary driver complains
02:46 < marcheu> Lumag: I'll work around that and do it differently, after all the stuff is already mapped
02:46 < Lumag> :)
02:47 < Lumag> It's strange... There seems to be nothing quadro-specific in nv mmap interface.
02:48 < marcheu> Lumag: I think it's just refusing me to map overlaping areas twice
02:50 < Lumag> marcheu: maybe, but I don't see anything relaed to such checks.
03:01 -!- _Anarchy_ [n=alan@81.2.110.250] has quit ["ircII EPIC4-2.2 -- Are we there yet?"]
03:06 < marcheu> ok, I'll commit the insane quadro hack
03:08 < marcheu> only 1 hour late :)
03:10 < marcheu> I'll make a dump for pmdata now, because I won't be there this week end :)
03:13 < marcheu> ah, too bad he's gone, I'd have asked him why /proc/self/maps refuses to work :)
03:14 < marcheu> hmm, because system() forks another process
03:14 -!- shaAway [n=Sha@stern.ulb.ac.be] has joined #nouveau
03:14 < marcheu> and /proc/self/maps is different then
03:24 < marcheu> ok, I updated nv15gl_alltests.txt (pmdata if you read irclogs, that one's for you)
03:24 < darktama> hm, how much memory would the cursor need (at a maximum)?
03:24 < marcheu> hmm, 64^2 RGBA ?
03:25 < darktama> ah, so it's a fixed size. cool
03:25 < marcheu> we have to _allocate_ this anyway :)
03:25 < darktama> yes, this is just a hack for the moment :) I don't much like having the cmdbuf clobbered by pretty images :P
03:25 < marcheu> ok :)
03:26 < marcheu> beware though, I say that from memory
03:27 < darktama> I'll leave 64kb for it.. that should be plenty of room for error.. I hope
03:28 < marcheu> in what order are you putting things ?
03:29 < darktama> [vidmem]....[cursor][scratch][fifo cmdbufs]
03:29 < marcheu> ok, just like now
03:29 < darktama> now it's [vidmem]..[scratch][fifo 0][cursor]
03:29 < marcheu> just let a little room after vidmem (what you materialize by "...." )
03:30 < marcheu> like a couple of scanlines
03:34 < darktama> hehe, life would be so much easier with a vidmem allocator :)
03:34 < darktama> and AGP for that matter..
03:34 < marcheu> did I promise I'd do that at some point ?
03:34 < darktama> hmm, I don't think so.. we did agree we needed *someone* to do it
03:35 < marcheu> or why are you looking at me like that ? :)
03:35  * darktama glares at marcheu :)
03:35 -!- haypo [n=haypo@82.247.156.212] has quit [Remote closed the connection]
03:35 < marcheu> ok, sounds like an idea if you're already playing with the fifo
03:36 < darktama> I'm still trying to wrap my head around how multiple contexts works.. it looks like nvidia uses one massive command buffer, and gives each fifo a part of it
03:36 < marcheu> yup
03:36 < marcheu> btw it looks the "part" is bigger on quadros
03:37 < marcheu> looks like*
03:37 < darktama> yeah, I think we can make it any size we want actually
03:37 < marcheu> so, what are the prerequistes for a usable memry manager ?
03:39 < darktama> well, not really an area where I have any sort of valuable knowledge.. I'd be happy if I could just malloc()/free().. but, I guess we need a bit more than that
03:39 < marcheu> well, for example :
03:39 < darktama> like being able to kick things out of video memory
03:39 < marcheu> - do we need to allocate single-use scratch buffers ? or do we prefer to reuse by hand from user space
03:40 < marcheu> yeah, kicking things out gets complicated real quick
03:40 < marcheu> because when process A's memory gets kicked for use by process B, where do you put process A's stuff ?
03:41 < darktama> single-use buffers could be useful, but we could do it from userspace easily enough
03:42 < marcheu> well, single-use buffers are a common use of the kicking mechanism
03:42 < marcheu> while if you attach them to some notifier, you are able to say when you can actually drop the contents
03:42 < marcheu> or maybe abstract the whole notifier concept from the kernel and hide everything
03:43 < marcheu> yeah, single-use buffers might be easily implemented as an afterthought
03:46 < marcheu> maybe I'll just write a simple non-kicking allocator at first
03:47 < marcheu> with a fake "don't kick this area bit"
03:47 < darktama> it's probably easiest, we can just deny allocs for now.. if we run out of ram, tough luck :)
03:47 < darktama> just like with the FIFO situation
03:48 < marcheu> well, there are enough fifos that this will not happen under common usage circumstances
03:48 < darktama> indeed
03:48 < marcheu> OTOH there is never enough vram
03:48 < marcheu> but yeah, let's make it fail :)
03:48 < marcheu> for now
03:54 < marcheu> sounds quite easy actually
03:55 < marcheu> plus I already have memory size code stuck in the drm
03:59 < marcheu> ok, http://nouveau.freedesktop.org/wiki/MemoryManager
03:59 < marcheu> feel free to add stuff you want
03:59 < darktama> cool :)
04:00 < marcheu> I was thinking if that'd be useful to make all sizes page-aligned
04:00 < marcheu> or aligned on any kind of boundary
04:01 < marcheu> the hope with page-aligned allocations is that you can map it into a given process using a simple page-based mapping
04:01 < marcheu> and thus enforce process-exclusive memory areas
04:03 < darktama> I'm all for anything that keeps it simple
04:04 < marcheu> which means ?
04:04 < marcheu> page-aligned allocations sound simpler to me
04:04 < darktama> yeah, that's what I was meaning :)
04:04 < marcheu> but they might only be interesting if we start selectively mapping areas into the processes adress space
04:08 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
04:08 < marcheu> I'm thinking we could do a lot of stuff with a simple kernel allocator and a user space layer that would handle more complex stuff
04:09 < marcheu> but then where do we put that layer... both DDX & DRI will need it and I don't feel like starting to touch libdrm for that
04:13 < darktama> no idea, the kernel and libdrm are the only parts that both the DDX and DRI touch aren't they?
04:13 < marcheu> well, there's the sarea but you can't put code in it :)
04:13 < marcheu> and I don't want to add stuff there anyway
04:14 < marcheu> well, maybe it's not too big to have in kernel
04:20 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has left #nouveau []
04:31 < airlied> maybe you guys really want to use the ttm memory manager :-)
04:31 < airlied> for now I'd just go with the sis or via one..
04:31 < airlied> memory management is hard, lets get triangles :-)
04:32 < marcheu> is ttm anywhere near ready ?
04:32 < airlied> marcheu: it works for certain values of work..
04:32 < airlied> marcheu: it doesn't yet do VRAM stuff..
04:32 < airlied> but you'd be much better making ttm do VRAM than writing YAMM
04:33 < marcheu> yeah, but I start by laying which constraints we have, and then I'll see if existing stuff fits
04:34 < marcheu> I don't think it'd be an issue to have a throwable on anyway
04:34 < marcheu> memory managers are so easy to replace
04:34 < airlied> well I'd just re-use the sis or via one..
04:36 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
04:38 < marcheu> yeah, the via one is simple enough that I will probably reuse it as a base
05:35 -!- erikw [i=erikw@montezuma.acc.umu.se] has joined #nouveau
05:52 < erikw> hey
05:52 -!- erikw is now known as ddl
06:00 -!- gamma [n=gamma@192.237.33.65.cfl.res.rr.com] has joined #nouveau
06:21 < gamma> how long has this project been going on for? it's cool to see that somebody is working on an opensource nvidia solution
06:47 -!- ChanServ [ChanServ@services.] has quit [Shutting Down]
06:48 -!- ChanServ [ChanServ@services.] has joined #nouveau
06:48 -!- ServerMode/#nouveau [+o ChanServ] by irc.freenode.net
07:29 -!- ChanServ [ChanServ@services.] has quit [Shutting Down]
07:29 -!- ChanServ [ChanServ@services.] has joined #nouveau
07:29 -!- ServerMode/#nouveau [+o ChanServ] by irc.freenode.net
07:33 -!- ChanServ [ChanServ@services.] has quit [Shutting Down]
07:34 -!- ChanServ [ChanServ@services.] has joined #nouveau
07:34 -!- ServerMode/#nouveau [+o ChanServ] by irc.freenode.net
08:18 -!- gamma [n=gamma@192.237.33.65.cfl.res.rr.com] has quit ["Ex-Chat"]
08:28 -!- tibbs is now known as tibbs|h
09:00 -!- johill [n=johannes@p5487E86D.dip.t-dialin.net] has joined #nouveau
11:35 < marcheu> hey ddl, did you see I added two links to page with bios dumps. I think these are pre-init bios dumps, though
11:36 < marcheu> on the wiki I mean
11:44 < marcheu> not sure if that'll be useful to you...
13:00 -!- EdB [n=EdB@ARennes-251-1-81-47.w86-199.abo.wanadoo.fr] has joined #nouveau
13:21 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
13:26 -!- Duke` [n=gnu@ANantes-251-1-132-51.w86-210.abo.wanadoo.fr] has joined #nouveau
13:27 -!- shenki [n=shenki@ppp153-94.lns3.adl2.internode.on.net] has joined #nouveau
13:33 -!- shenki [n=shenki@ppp153-94.lns3.adl2.internode.on.net] has quit ["Leaving"]
13:56 -!- shenki [n=shenki@ppp153-94.lns3.adl2.internode.on.net] has joined #nouveau
14:51 -!- Lumag [n=c2544702@hosting.cwn.ru] has joined #nouveau
14:52 < Lumag> hi
15:09 -!- EdB [n=EdB@ARennes-251-1-81-47.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:02 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
19:11 -!- Lumag [n=c2544702@hosting.cwn.ru] has quit ["/ http://gate.forestnet.org/ (Ping timeout)"]
19:11 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:42 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:57 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
20:51 -!- Duke` [n=gnu@ANantes-251-1-132-51.w86-210.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
20:52 -!- Duke` [n=gnu@ANantes-251-1-155-251.w86-203.abo.wanadoo.fr] has joined #nouveau
21:17 -!- pmdata [i=patrice@ANantes-154-1-39-180.w81-53.abo.wanadoo.fr] has joined #nouveau
21:17 < pmdata> hello
21:18 < arachnist> hi
21:23  * pmdata with 2.4 kernel and non-nvidia x11 driver
21:23 < pmdata> 2d is not slower :)
21:23 < pmdata> but I can't compile old 1.0-3xxx nv driver for 2.4.27, any help?
21:24 < arachnist> what do you need old 3xxx driver for?
21:24 < pmdata> to test ext_vertex_weighting that nvidia removed since 1.0-4xxx
21:25 < pmdata> nvidia always add 'fixed..., improved... or added...' in their readme_changelog, but do not list the stuff they remove
21:33 -!- svu [n=svu@host-194-46-251-124.dsl-ie.utvinternet.net] has quit ["Ex-Chat"]
21:54 -!- svu [n=svu@host-194-46-251-124.dsl-ie.utvinternet.net] has joined #nouveau
21:59 -!- pmdata [i=patrice@ANantes-154-1-39-180.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
22:11 -!- pmdata [i=patrice@ANantes-154-1-39-180.w81-53.abo.wanadoo.fr] has joined #nouveau
22:12 < pmdata> \o/ running 1.0-3123
22:14 < pmdata> EXT_vertex_weighting is present, time to test it
22:24 -!- johill [n=johannes@p5487E86D.dip.t-dialin.net] has quit [Read error: 113 (No route to host)]
22:25 < arachnist> would be nice to get 3d working on nvidia cards. i'm wondering if you guys would make something that works fairly well, nvidia would ditch their drivers and help you out, just like they did with forcedeath
22:28 < pmdata> it will be a long time before a driver is in even alpha testable state
22:29 < pmdata> arachnist> what is your nv hw?
22:29 < arachnist> gf4mx440
22:29 < arachnist> 64mb of ddr mem
22:30 < arachnist> leadtek winfast a170 ddr-t, still have the box somewhere around
22:30 < pmdata> nv17 then
22:30 < pmdata> according to nv docs, nv17 has nearly complete mpeg2 decoder
22:31 < pmdata> can you use under linux their libxvmc ?
22:31 < arachnist> nvidias? dunno, i don't watch video'son this box
22:32 < arachnist> s/son/s on/
22:46 < pmdata> http://nouveau.freedesktop.org/wiki/Nv15Extensions hum, not only EXT_vertex_weighting has been removed
22:47 < pmdata> should try 4xxx, 5xxx and 6xxx nv driver releases and previous 2xxx and 1xxx
22:47 < arachnist> that'll make you use ancient kernel (and probably xfree) releases
22:48 < arachnist> especially the 2xxx and 1xxx part
22:49 < pmdata> some extensions have been promoted from nv to ext, or from ext to arb or to the core
22:51 < pmdata> the funny thing is to have some new extensions listed, when the hardware does not support it (like ext_cg_shader for nv15)
22:53 < arachnist> nv15 was gf4mx420?
22:53 < arachnist> or gf3?
22:53 < pmdata> gf2
22:53 < pmdata> gf3 is nv20
22:53 < arachnist> huh
22:54 < pmdata> http://oss.sgi.com/projects/ogl-sample/registry/EXT/vertex_weighting.txt this is when reading this that I got the idea to try old driver
22:57 -!- EdB|w [n=EdB@212.234.68.206] has quit ["Parti"]
23:02 < pmdata> renouveau does not work with 1.0-3123, someone could help me?
23:03 < pmdata> mmap fails in init_card, invalid argument
23:15 < pmdata> regtmp.txt is empty, what should be in /proc/bus/pci/devices with nvidia line?
23:18 < pmdata> hum fill the missing value, but still invalid argument
23:20 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
23:24 < pmdata> was /dev/nvidia<n> used in older drivers?
23:24 < pmdata> I can't mmap the mmio registers region
23:26 < arachnist> yes
23:26 < arachnist> still remember having to chmod or chown it on some old polish redhat clone
23:29 < pmdata> I don't think it is a problem, they are 666 on my system, and it works with 7174 driver
23:30 < arachnist> well, it was an old redhat clone
23:41 < pmdata> anyone know if I can read if some address is already mmaped?
23:42 < pmdata> hm, NV_texgen_emboss should also be tested with 3xxx
23:51 -!- Lumag [n=Lumag@chimpanzee.school.ioffe.ru] has joined #nouveau
23:51 < pmdata> marcheu is out for the week-end, so I hope someone else could help
23:52 < pmdata> hi lumag
23:52 < Lumag> hi pmdata.
23:52 < Lumag> I read about your problems. Could you please post an strace glxinfo log?
23:53 < pmdata> yep, my problem is that renouveau can not mmap /dev/nvidia0
23:55 < pmdata> http://pmandin.atari.org/download/glxinfo2-trace.txt
23:57 < Lumag> strange... I don't see anything special...
23:58 < Lumag> And with what error is mmap failing?
23:58 < pmdata> invalid argument
23:58 < pmdata> first it could not find nvidia in /proc/bus/pci/devices
23:58 < pmdata> then line for my card starts with 0100    10de0151        b       e0000000 ...
23:59 < pmdata> so I used them as dum, card_id, dum and phys_addr
23:59 < pmdata> then the mmap fails now
--- Log closed Сбт Июл 29 00:00:01 2006
