--- Log opened Чтв Авг 31 00:00:26 2006
00:02 < KoalaBR> Bye
00:02 -!- KoalaBR [n=KoalaBR@port-83-236-13-123.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
00:10 -!- pmdata [i=patrice@ANantes-154-1-25-179.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
00:17 -!- Myrizio [n=Myrizio@host29-96.pool80104.interbusiness.it] has joined #nouveau
00:18 -!- pmdata [i=patrice@ANantes-154-1-25-179.w81-53.abo.wanadoo.fr] has joined #nouveau
00:21 < pmdata> mat> do you have nv11/17/18 ?
00:25 < phh> pmdata, I have nv18 (nforce2)
00:25 < marcheu> pmdata: I have a nv18 in right now :)
00:25 < pmdata> mat = phh?
00:25 < marcheu> no :)
00:26 < pmdata> it's just that I saw nv10_tcl[0xd74/4] which is nv17/18 only
00:26 < phh> ah.
00:26 < phh> d'accord.
00:26 < marcheu> ah, we still don't know what it is
00:26 < marcheu> does it pop up on nv11 too ?
00:26 < marcheu> or did you mention nv11 for tsome other reason
00:27 < pmdata> no I just forgot nv11 don't have lma
00:27 < pmdata> I don't know who made nv11sgl dumps, but they are all empty
00:28 < marcheu> I did, the fifo is not at the expcte place
00:28 < marcheu> expected*
00:28 < phh> what's the state of reverse engineering ?
00:28 < marcheu> and thus the dumps are empty
00:28 < pmdata> ah, same for nv11 ones, useless then
00:29 < marcheu> yeah, I'd have to fix renouveau for it
00:30 < pmdata> ? nv10/11 are so much different from others?
00:30 < marcheu> well we could never test a real nv10
00:30 < marcheu> and for nv11 I think it's just the fifo which is not where we expect it
00:32 < pmdata> hum, I have much lag trying to read nouveau.sf.net/tests subdirs
00:33 < marcheu> hmm makes me think I should upload marteus's dumps
00:34 < mat__> pmdata> a nv17
00:34 -!- svu [n=svu@83.167.239.56] has joined #nouveau
00:34 < pmdata> aaahhhh
00:36 -!- svu [n=svu@83.167.239.56] has quit [Read error: 54 (Connection reset by peer)]
00:36 -!- svu [n=svu@83.167.239.56] has joined #nouveau
00:36 < mat__> I have got a real nv10, but I need to upgrade the machine and isntall nvidia driver
00:37 < phh> mat__, this isn't the problem
00:37 < pmdata> we need to know if there is a difference between nv10/11 and nv15/17/18
00:37 < phh> nv10 is geforce 2MX ?
00:38 < pmdata> nv10=gf1, nv11=gf2mx
00:38 -!- clemux [i=clemux@lithium.quarante-d.eu] has joined #nouveau
00:38 < phh> ok i know someone which have it
00:38 < phh> pmdata, clemux is your men.
00:38 < clemux> hi
00:38 < clemux> man
00:39 < phh> blah.
00:39  * pmdata waits for nv10/11 dumps
00:39 < phh> pmdata, what's the url for explaining how to get dumps ?
00:39 < phh> (flegme de lui expliquer  ce boulet.)
00:39 < pmdata> read the README in renouveau dir
00:39 < phh> first he needs to cvs co :)
00:40 < clemux> and I'm very lazy
00:40 < phh> cvs -d:pserver:anonymous@nouveau.cvs.sourceforge.net:/cvsroot/nouveau co renouveau
00:41 < clemux> then?
00:41 < phh> cd renouveau ; vim README
00:41 < clemux> hm less README
00:41 < clemux> okay
00:41 < phh> :p
00:42 < clemux> euh...
00:42 < marcheu> pmdata: instead, we shoudl define MULTIPLE_FILES and uncomment all the tests I think
00:42 < marcheu> pmdata: that'd make everyone's life easier
00:44 < marcheu> marteus: hmm, would you mind running the tests again, but this time define OUTPUT_MULTIPLE_FILES on top of re.c ?
00:44 < pmdata> yep do it, and also the DONT_DUMP_*
00:44 < marcheu> so by default we want :
00:44 < marcheu> #define OUTPUT_MULTIPLE_FILES
00:44 < marcheu> #define DONT_DUMP_CHANGED_REGS
00:44 < marcheu> #define DONT_DUMP_ABOVE_40000
00:44 < marcheu> alright ?
00:44 < pmdata> yep
00:44 < marcheu> I'm comitting that now
00:44 < marcheu> and enabling all the tests
00:45 < marcheu> I'm tired of repeating the same instructions :)
00:45 < pmdata> mitou
00:46 < marcheu> done
00:47 -!- shawn_work [n=spstarr@192.219.104.10] has quit ["move desks"]
00:47 < clemux> sorry, I have to go... I'll give you this tomorrow
01:02 -!- pmdata [i=patrice@ANantes-154-1-25-179.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
01:04 < marteus> marcheu: yup comin up in a few moments
01:07 -!- swany_ [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
01:07 < marcheu> marteus: cool thanks a lot. btw if you update from CVS all the right ptions fall into place :)
01:09 < marteus> hmm. DON'T do _anything_ like moving the window... my screen just locked up, and locked me out of ssh :/
01:12 < marcheu> hmm, weird. that said I never moved the window
01:12 < marcheu> I was too afraid of changing the results :)
01:13 < marteus> ^^
01:13 -!- hanno [n=hanno@p54A4D3D9.dip.t-dialin.net] has joined #nouveau
01:13 < marteus> well my laptop has a funny implementation of acpi so that is kinda expected :/ 
01:14 < marteus> it hasn't happen while booting with noapic before though 
01:17 -!- svu [n=svu@83.167.239.56] has quit [Read error: 54 (Connection reset by peer)]
01:19 -!- svu [n=svu@83.167.239.56] has joined #nouveau
01:20 -!- jkolb [n=jkolb@wsi-128-248.wsi.com] has quit ["Leaving"]
01:22 < marteus> gogo, marteus.dyndns.org/~marteus/gf7600go-renouveau.tar.bz2
01:26 -!- swany_ [n=swany@81-234-181-143-o1108.tbon.telia.com] has left #nouveau []
01:28 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
01:56 -!- hanno [n=hanno@p54A4D3D9.dip.t-dialin.net] has quit [Read error: 54 (Connection reset by peer)]
02:00 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has joined #nouveau
02:07 -!- mat__ [n=mat@cac94-1-81-57-151-96.fbx.proxad.net] has quit ["Leaving"]
02:08 < marcheu> marteus: 404 :)
02:08 -!- shenki [n=shenki@ppp131-204.lns3.adl2.internode.on.net] has quit [Read error: 60 (Operation timed out)]
02:08 < stillunknown> works here
02:08 < marcheu> hmm wait
02:08 < marcheu> yeah
02:09 < marcheu> I cut the "2
02:09 < marteus> ^^
02:09 < marcheu> stupid me
02:09 < marcheu> actually, tired me
02:10 < marteus> does the driver has working 2d for g70 yet?
02:10 < marcheu> it should
02:11 < marteus> thats a improvement to nv :)
02:11 < marcheu> well, feel free to report if it doesn't work
02:12 < marteus> oh, well it wouldn't be that reliable considering the bios 
02:12 < marcheu> the bios ?
02:12 < marteus> yeah my bios is buggy
02:12 < marcheu> oh ? and ?
02:13 < marteus> it crashes the video driver often 
02:14 < marcheu> buggy as in what ?
02:14 < marcheu> contents is bad ?
02:14 < marcheu> flaky rom ?
02:14 < marteus> it has 2 madt tables
02:16 < marteus> the windows driver has weird issues with corrupted geometry too.
02:17 < marcheu> anyway, we're interested in knowing it it works or not. and your bios dump might be of interest to some people in here too :)
02:18 < phh> marcheu, you plan remaking bioses too ? :)
02:19 < marcheu> phh: the bios holds enough information to cold start a card, or get it out of suspend state. we need to understand it and use it correctly, though
02:19 < phh> ah
02:19 -!- hanno [n=hanno@p54A4D3D9.dip.t-dialin.net] has joined #nouveau
02:19 < marteus> alright then i'll give it a try
02:20 < marteus> but damn i hate cvs -_-
02:21 < Gentle> just to ask, how many people do you know of that run nouveau already?
02:22 < marcheu> marteus: well, no problem, the code is in git anyway :)
02:22 < marcheu> marteus: and we have snapshots
02:22 < marteus> it's just renouveau that's in cvs?
02:23 < phh> yep
02:26 < airlied> marcheu: on the memory manager you really should talk to Thomas before doing very much, considering he's done the via dmablit and the TTM code..
02:28 < marcheu> airlied: agreed. but I'm waiting for things to settle a bit :)
02:28 < marcheu> or maybe I should do the opposite, and push for design decisions we could take advantage of...
02:32 < airlied> marcheu: well it would be nice to add to the general memory manager pool than create YAMM..
02:32 < marcheu> yeah, I'm just afraid that we can't push design decisions that are interesting for us into a memory manager that's aimed at i915/via
02:34 < marteus> alright i am lost at git O_o 
02:35 < airlied> marcheu: oh we can push, Thomas is quite open to discussion, or at least we can make sure we can hook into the struture..
02:35 < marcheu> because nvidia hardware is really better than other stuff around
02:36 < marcheu> so we don't have the same requirements
02:36 < marcheu> marteus: let me dig the snapshot url
02:36 < marteus> yeah sure
02:36 < marteus> hm isn
02:37 < marteus> isn't a git:// path supposed to end with .git?
02:37 < phh> no
02:38 < marcheu> it should be nouveau.sf.net/xf86-video-nouveau-daily.tgz
02:38 < marcheu> and nouveau.sf.net/drm-daily.tgz
02:40 < airlied> marcheu: that's true.. but our requirements overlap quite a bit.. and the interfaces should at least cope with that..
02:41 < marcheu> yeah, and now is just the right time to change those interfaces the right way
02:43 < airlied> nvidia chip have a complete scatter-gather DMA engine on them don't they?
02:43 < marcheu> yeah, you put a list of pages in the object, and there you go
02:44 < airlied> how does it distinguish between AGP and PCI?
02:44 < marcheu> ok, you either unset a flag and put a list of PCI pages, or set the flag and specify a AGP area
02:44 < marcheu> more precisely :)
02:44 < marcheu> and I think the PCI version works on AGP cards as well
02:45 < airlied> how about VRAM another flag?
02:45 < phh> ho little question, in PCI Express there is no more agp aperture ?
02:45 < marcheu> not the same object IIRC
02:45 < phh> (equivalent of at least)
02:45 < airlied> phh: no agp aperture.. no ..
02:45 < phh> it's a regression
02:46 < marcheu> the nvtv code does this, the code is quite clear
02:46 < marcheu> phh: I consider it an improvement
02:46 < phh> ah.
02:46 < phh> why that ?
02:46 < airlied> phh: no need for one.. AGP is a dirty hack..
02:46 < phh> right
02:46 < airlied> marcheu: cool... I'm just trying to tie this in with my knowledge of the TTM code...
02:47 < marcheu> I know squat about the TTM code, I'm looking at it now
02:47 < airlied> marcheu: I've only be reviewing it as I try to wedge it into the kernel..
02:50 < marcheu> for example, 32 bit handles sounds like a bad design decision to me
02:51 < marcheu> I'd go for everything 64 bit (which is what I did for nouveau_mem)
02:51 < marcheu> that might bite in the future
02:52 < airlied> marcheu: well the 64-bit ones broke a lot of stuff in the past... i.e. the current userspace interface is 32-bit..
02:52 < marcheu> well nouveau's interface is 64bit :)
02:53 < airlied> I can't see how 32-bit isn't going to big enough though... lots of 1x1 textures :-)
02:53 < airlied> there are some slides on the whole TTM thing somewhere..
02:53 < marcheu> well, I'm always nervous about hashing stuff and doing handles
02:54 < airlied> http://www.tungstengraphics.com/xdevconf2006.pdf
02:54 < airlied> marcheu: actually hashing should happen anywsys.. the whole idea of passing memory address to userspace was wrong..
02:55 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit [Remote closed the connection]
02:55 < marcheu> why ?
02:55 < airlied> because if he keeps a reference to it, you can't move it easily..
02:55 < airlied> with the hashes you force a lookup inside the kernel and can reject it..
02:55 < airlied> I know you can keep a lists of valid handles..
02:55 < marcheu> well, in our model, user space programs the fifo, and thus has to know the real adress
02:56 < airlied> but ppl started using those handles in all kinds of unusual ways..
02:56 < airlied> marcheu: can they not just map it?
02:56 < marcheu> yes you can map it, but the card still wants to have the real adress to operate
02:56 -!- Duke` [n=gnu@ANantes-251-1-132-160.w86-210.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:56 < airlied> marcheu: so you have a map per FIFO, and each userspsace program gets a handle and writes to th emap.
02:57 < airlied> why does it need real addresses?
02:57 < marcheu> say the TTM moves stuff in vram. how does the user space process know that its dma target has moved ?
02:59 < airlied> it doesn't, my belief is that you fixup the data stream before submitting ito the card..
02:59 < airlied> so that when you process the command stream the memory manager pulls in the things it needs, and fixes up the stream to point to them..
03:00 < marteus> baah, make fails (xf86-video-nouveau) on the man pages O_o
03:00 < marcheu> remember again, the user space fills and runs the fifo. what if it's interrupted, and the TTM moves stuff in between ? we'll need an efficient way to lockdown objects then...
03:02 < marteus> make[2]: *** No rule to make target `nv.@DRIVER_MAN_SUFFIX@', needed by `all-am'.  Stop.
03:02 < airlied> does usersspace trigger FIFO execution? or does the fifo execute as syou put stuff into it?
03:02 < marcheu> marteus: man pages are for the weak :)
03:02 < marcheu> airlied: yes, the userspace triggers the fifo
03:02 < marcheu> marteus: seriously, we know it's broken
03:03 < marteus> marcheu: alright, the fix is?
03:04 < marcheu> marteus: no fix, go to src and copy the driver to your xorg location
03:04 < airlied> marcheu: I wonder if we should leave it to the drm to trigger the fifos? do you have any idea how the binary does it?
03:04 < marcheu> airlied: and the issue will be the same with Xorg & radeon for example, radeon ddx triggers fifo writes with offets in vram that might be moving targets with the introduction of TTM
03:05 < marcheu> well I'm not sure I want a tip to the kernel every 5 bytes written in the fifo..
03:05 < marcheu> I'd rather have a lockdown command of some sort to ensure some targets don't move until I unlock
03:06 < airlied> yeah some sort of temporary pin might be necessary..
03:07 < airlied> well the drm lock does it but it is too heavy weight..
03:07 < marcheu> as for the binary driver, it doesn't call the kernel to achieve fifo triggers
03:07 < airlied> how do you deal with cliprects
03:07 < marcheu> well we're probably not going to have the drm lock either. we don't need it
03:07 < marcheu> cliprects will have a per-context lock
03:07 < marcheu> hmm make that dri lock
03:08 < marcheu> did you read nvidia's presentation ad xdc I think ? they explained their locking, and why it's only needed for cliprects
03:08 < marcheu> or maybe you attended it..
03:09 < airlied> marcheu: I was there alright.. but my memory has hazed up a bit..
03:09 < marcheu> http://developer.nvidia.com/object/xdevconf_2006_presentations.html
03:10 -!- K [i=hazel@85.57.132.92] has quit [Remote closed the connection]
03:10 < marteus> marcheu: all of them? (*.lo, there are no .so)
03:11 < marcheu> marteus: in .libs/ I think
03:11 < marcheu> marteus: in src/.libs/ I think
03:11 < marteus> marcheu: that's sneaky :/
03:11 < marcheu> and copy it to (probably) /usr/lib/xorg/modules/drivers/
03:12 < marteus> yup i figured that
03:13 < marteus> and i just ignore the .la files (in .lib)
03:13 < marcheu> yeah
03:14 < marteus> and the name of the driver in xorg.conf is neuveau?
03:14 < marcheu> no, "nv"
03:14 < airlied> the synchronisation section of that paper is interesting..
03:14 < marcheu> actually, enlightening is the word :)
03:19 < airlied> I gotta go pack some stuff, I'll mull it over on my holiday :-), you might have it solved when I get back :-P
03:20 < marcheu> I don't think I'll solve this, I'd rather get context switching to work :)
03:22 < airlied> my big problem with your pinning is that one client can then take over the whole GPU by constantly scheduling usage of sosme very large textures..
03:23 < airlied> as if one-clent controls its own FIFO we have no way to influcence its memory usage patterns..
03:25 -!- Gentle [n=DasTier@HSI-KBW-085-216-054-105.hsi.kabelbw.de] has quit [Remote closed the connection]
03:28 < marcheu> hmm, the fifo gets scheduled by an interrupt
03:28 < marcheu> so when that interrupt is triggered, we have the drm in control
03:28 < marcheu> so we can do whatever we like
03:31 < airlied> marcheu: what triggers the interrupt?
03:31 < marcheu> well, the hw gives timeslices to the fifos
03:31 < marcheu> when the timeslice is over, the interrupt is triggered
03:32 < marcheu> then something still a bit mysterious happens in the kernel which does context switching
03:32 < marcheu> and then the next process goes on
03:32 < airlied> ah can we re-write the FIFO contents at the stage?
03:32 < marcheu> sounds tricy
03:32 < marcheu> tricky
03:33 < airlied> is the FIFO just a circular piece of VRAM we can read/write? or it is an actual FIFO, like one memory location, push stuff in..
03:34 < marcheu> yeah it's a piece of ram, although writing where the hw is reading results in weird behaviour from the card
03:34 < marcheu> it's either VRAM or AGP ram
03:34 < airlied> so I think it would still be possible to do fixups in-kernel when you are scheduling the FIFO..
03:34 < marcheu> not always, because you don't control everything
03:35 < marteus> marcheu: it went well until xorg tried to load dri, (though there is no LoadModule "DRI" in xorg.conf)
03:35 < marcheu> the fifo could wrap, or something
03:35 < marcheu> marteus: you have the kernel module installed correctly ?
03:35 < marteus> perhaps not ^^
03:35 < airlied> marcheu: surely the hw isn't touch the FIFO until we schedule it, and wse know usersspace isns't..
03:36 < marteus> marcheu: did you link to that?
03:36 < marcheu> marteus: yes
03:36 < airlied> I'm pushed to see another way to do it, as some point you have to sync all the memory contents.. and you can't just sync by pinning..
03:36 < marcheu> airlied: well the user space can make the fifo pointer jump around, even overwrite stiff
03:37 < marcheu> airlied: and still not expire its timeslice when doing that
03:37 < airlied> marcheu: I think userspace will not be doing anything at this stage though...
03:37 < airlied> it fills the FIFO however it wants, and if it fills up I assume it blocks waiting..
03:38 < marcheu> yes but what if TTM moves stuff that is being read/written to/from by the card ?
03:38 < marcheu> typical case :
03:38 < airlied> marcheu: that is where you need fencing...
03:38 < marcheu> - user space initiates drawing to some area
03:38 < airlied> marcheu: of super-fencgin our case..
03:38 < airlied> or super-fencing even.. typing not good..
03:38 < marcheu> - TTM moves the are, touches the fifo and thinks that's ok since it changed the offsets
03:39 < marcheu> not really, against that all you can do is wait for idle, OR do pinning
03:39 < marcheu> and I don't want to wait for idle all the time
03:39 < airlied> what is the card doing with the RAM area?
03:39 < marcheu> reading from a texture ? rendering to a surface ?
03:40 < airlied> if it is scanout it is pinned, if it is rendering you stick a fence emission after using it in the fifo stream..
03:40 < airlied> I assume the fifo stream has some fencing mechanism.. 
03:40 < airlied> so when that fence expires you can move the buffer again..
03:40 < marcheu> what if it's a texture ?
03:40 < marteus> marcheu: then I can't find it, it's in neither of the two packages (unless it is a special make target?)
03:40 < marcheu> we have to pin it then...
03:41 < marcheu> marteus: in drm, cd linux-core ; make 
03:41 < airlied> nope, you just say 'm using this texture, I'll be finished with it after this point, don't move it until then..
03:41 < marteus> ah
03:41 < airlied> then when the fence is emitted the memory manager can move it..
03:42 < marcheu> airlied: which is pretty much the equivalent of pinning/unpinning I say :)
03:42 < airlied> it may move it straight back when youo get scheduled..
03:42 < airlied> no pinning is way worse, you cannot move pinned buffers..
03:42 < airlied> you can move textures in between use..
03:42 < marcheu> ok, so we have to have each process maintain a set of currently in use buffers
03:43 < marcheu> how do you tell the kernel ? or we use sarea ?
03:43 < airlied> marcheu: yes I think they are called buffer list in TTM..
03:44 < airlied> marcheu: you need to submit a list of buffers you are using to the memory manager..
03:44 < airlied> and when you are ssscheduled it uses that to decide what to do and fixes up the fifo..
03:45 < marcheu> so, an application can cheat, and exhaust vidram by saying it's using everything... same issue is back
03:45 < airlied> marcheu: no because it I schdule another app, it will wait for the first apps fences to  expire and dump all its buffers..
03:46 < marcheu> hmm right that sounds good
03:47 < marcheu> is that impemented already ?
03:47 < airlied> marcheu: nope that is what keithw'ss DMA scheduler mail was about for the future.. after we have the first level which is TTM type stuff..
03:48 < airlied> http://lists.freedesktop.org/archives/xorg/2006-March/013860.html
03:48 < airlied> in case you missed it..
03:48 < marcheu> yeah, I want a DMA scheduler as well
03:49 < airlied> he gets most of the problem in that mail, but i'm sure the multiple fifo h/w adds to it..
03:50 < marteus> marcheu: that gave me unknown sympols when modprobing nouveau (drm_calloc, etc). I'm using xorg7.1 btw
03:50 < airlied> in fact we are the same really, we just need to fixup in-fifo as  opposed to concatenate multiple dma streams..
03:50 < airlied> marteus: install the drm.ko as well.
03:51 < marteus> i'm beginning to fathon why it takes so long ... :)
03:51 < marcheu> airlied: well I don't like fixup in-fifo, it'll be slow and crash-prone (reading from the fifo in VRAM is surely not something to be done lightly) but I guess it doesn't happen too often
03:52 < airlied> marcheu: hmm I'm just wondering how else to do it, if the userspace runs the FIFOs.. also how nvidia might do it..
03:52 < marcheu> airlied: well, maybe there is another way, with using the nvidia hw again
03:53 < marcheu> everything is an object, and most offsets sit in kernel-only reachable areas. so we might move the object and the associated instance ram with it
03:53 < marcheu> but I'm not sure if that'll work all the time
03:53 < airlied> marcheu: that's true.. they do a lot of neat stuff in their hw..
03:53 < marcheu> that would be really great
03:54 < marcheu> no fifo fixup or anything, just touch the object offsets
03:54 < marcheu> and I think that's possible actually
03:54 < airlied> so in the FIFO you only put object references?
03:54 < marcheu> yes
03:54 < airlied> so the objects are stored elsewhere?
03:54 < marcheu> that's frigging complicated :)
03:54 < marcheu> yes :)
03:54 < marcheu> in instance ram
03:54 < marcheu> they have parameters and such there
03:55 < airlied> ahh.. that is smore interesting..
03:55 < marcheu> and quite often these parameters are offsets, which might be the reason for that in the first place
03:55 < airlied> so you most like sould just need to fixups the instance ram..
03:55 < marcheu> yes, except we've never done that
03:56 < airlied> marcheu: that actually sound like it might be the "correct" way to do it..
03:56 < airlied> marcheu: granted I'm not sure how to get there from here, a full blown DMA scheduler might take a while to knock together :-)
03:57 < marcheu> well, probably darktama knows more about this object fixup we could do
03:58 < airlied> right I really gotta go pack, do you log this channel perchance?
03:58 < marcheu> yeah, lumag_offline does
03:58 < airlied> cool I might grab the logs post-holiday and skim for interesting bits :-)
03:58 < marcheu> http://lumag.spb.ru/nouveau/irclogs/ it is
03:59 < airlied> excellent..
04:00 -!- hanno [n=hanno@p54A4D3D9.dip.t-dialin.net] has quit [Read error: 60 (Operation timed out)]
04:01 < marteus> marcheu: the module loads, but xorg still fails at dri
04:01 < marcheu> marteus: /var/log/Xorg.0.log  says ?
04:02 < marteus> (II) NV(0): Loaded DRI module
04:02 < marteus> drmOpenDevice: node name is /dev/dri/card0
04:02 < marteus> drmOpenDevice: open result is -1, (No such device)
04:02 < marteus> drmOpenDevice: open result is -1, (No such device)
04:02 < marteus> drmOpenDevice: Open failed
04:02 < marcheu> that's not a fatal error
04:02 < marcheu> can you put the full log online ?
04:03 < marteus> yup
04:05 < marteus> marteus.dyndns.org/~marteus/xorg.log
04:06 < marcheu> do you have both drm.ko and nouveau.ko loaded ?
04:06 < marteus> lsmod | grep drm
04:06 < marteus> drm                    63256  1 nouveau
04:06 < marteus> agpgart                24012  3 drm,intel_agp,nvidia
04:06 < marcheu> god you have nvidia loaded at the same time
04:06 < marteus> yeah noticed
04:06 < marteus> :/
04:07 < marcheu> you're lucky it didn't crash
04:07 < marteus> when you're playing with fire...
04:07 < marcheu> maybe we should issue some warning when nvidia.ko is in there
04:09 < marteus> it make no difference after a rmmod nvidia
04:09 -!- hanno [n=hanno@p54A4CF08.dip.t-dialin.net] has joined #nouveau
04:09 < marteus> *made
04:09 < marcheu> marteus: yeah I think nouveau can't initialize when nvidia is loaded
04:11 -!- hiyuh [n=hiyuh@ZL050133.ppp.dion.ne.jp] has joined #nouveau
04:11 < marteus> marcheu: hm it doesn't complain
04:12 < marteus> and i have no luck after rmmodding them all and loading them agaim (not nvidia though ;))
04:25 -!- hanno [n=hanno@p54A4CF08.dip.t-dialin.net] has quit ["Verlassend"]
04:43 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
04:50 < marteus> now it will have to wait to tomorrow
04:50 -!- marteus [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has quit ["leaving"]
04:53 -!- Myrizio [n=Myrizio@host29-96.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
05:03 -!- airlied [n=airlied@193.1.99.74] has quit ["leaving"]
05:12 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has joined #nouveau
06:07 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has joined #nouveau
06:24 -!- hiyuh [n=hiyuh@ZL050133.ppp.dion.ne.jp] has quit [Read error: 110 (Connection timed out)]
06:28 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
06:30 -!- Myrizio [n=Myrizio@host29-96.pool80104.interbusiness.it] has joined #nouveau
06:38 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has quit ["Leaving"]
06:39 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has joined #nouveau
06:42 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has joined #nouveau
06:52 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has quit ["Leaving"]
06:52 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has joined #nouveau
07:41 -!- Myrizio [n=Myrizio@host29-96.pool80104.interbusiness.it] has quit [Remote closed the connection]
09:33 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
11:14 < darktama> marcheu: memory locations are used, but the address you put in the command stream is relative to an object's base
11:15 < darktama> as for fixing up DMA object offsets, it depends on how granular the objects are..  it's likely that not every place you can put an offset has it's own object too
11:15 < darktama> anyway, I'm away for a few hours :)
11:40 -!- EdB [n=EdB@ARennes-251-1-4-226.w83-195.abo.wanadoo.fr] has joined #nouveau
11:42 -!- Duke` [n=gnu@ANantes-251-1-132-160.w86-210.abo.wanadoo.fr] has joined #nouveau
11:43 < EdB> mmm
11:44 < EdB> i made a git pull, build and install and -> unable to start nouveau driver this morning :o)
12:00 < EdB> oh nv is rename to nouveau
12:00 < EdB> ok
12:00 -!- EdB [n=EdB@ARennes-251-1-4-226.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
12:02 -!- EdB [n=EdB@ARennes-251-1-4-226.w83-195.abo.wanadoo.fr] has joined #nouveau
12:02 < EdB> that work
12:19  * Duke` finds strange that there is still "xf86Func()" named functions into xorg... why haven't they changed this when forking xfree86?
12:32 < hiyuh_work> It's just for backward compat?
12:35 < EdB> Duke`, i guess it's not the main goal of xorg :o)
12:43 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
12:45 -!- marteus [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has joined #nouveau
12:49 -!- kylem [n=kyle@cabal.ca] has quit [Read error: 110 (Connection timed out)]
13:43 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit [Remote closed the connection]
13:49 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
15:31 -!- Duke` [n=gnu@ANantes-251-1-132-160.w86-210.abo.wanadoo.fr] has quit [Connection timed out]
15:32 -!- Duke` [n=gnu@ANantes-251-1-88-32.w86-203.abo.wanadoo.fr] has joined #nouveau
15:48 -!- pmdata [i=patrice@ANantes-154-1-62-16.w81-53.abo.wanadoo.fr] has joined #nouveau
15:53 < pmdata> marcheu> just read your chat with airlied this night, maybe a test for NV_fence extension would be useful?
15:58 -!- kylem [n=kyle@cabal.ca] has joined #nouveau
16:01 < marcheu> pmdata: it might possibly reveal interesting information. but I think we'd have to dump more than just the fifo
16:04 < pmdata> that's what I also thought, fifo won't be enough, if it is like overlay
16:04 < pmdata> well, need to try to see if there is anything
16:06 < marteus> marcheu: got a new video bios today :), go for new data?
16:37 -!- EdB [n=EdB@ARennes-251-1-4-226.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:45 -!- Myrizio [n=Myrizio@host131-101.pool80104.interbusiness.it] has joined #nouveau
17:11 -!- pmdata [i=patrice@ANantes-154-1-62-16.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
17:30 -!- tezem [n=tezem@80.109.173.112] has joined #nouveau
17:30 -!- Myrizio [n=Myrizio@host131-101.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
17:37 -!- jkolb [n=jkolb@wsi-128-248.wsi.com] has joined #nouveau
17:40  * b33fc0d3 does the cancelled meeting dance
17:48 -!- Myrizio [n=Myrizio@host43-96.pool80104.interbusiness.it] has joined #nouveau
18:33 -!- Myrizio [n=Myrizio@host43-96.pool80104.interbusiness.it] has quit [Remote closed the connection]
18:35 -!- Duke` [n=gnu@ANantes-251-1-88-32.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
18:38 -!- Duke` [n=gnu@ANantes-251-1-88-32.w86-203.abo.wanadoo.fr] has joined #nouveau
19:12 -!- pmdata [i=patrice@ANantes-154-1-71-166.w86-195.abo.wanadoo.fr] has joined #nouveau
19:13  * pmdata was reading first log files, impressive the work done in 2 months
19:14 < phh> still no beginning of 3D driver to try ?
19:16 < pmdata> I think the needed foundations are not there atm
19:16 < phh> ok
19:17 < pmdata> well, I don't know really, but this is my thought
19:17 < pmdata> or marcheu would have told: 'go for 3d now!'
19:18 < stillunknown> as far as i understand there is still major issues/choices over memory storage and dma issues
19:18 < phh> i thaught marcheu wanted to begin asap
19:21 < pmdata> well, we could try simple stuff, i.e. without texturing for example or anything that requires more than telling the gpu 'draw this'
19:21 < pmdata> are we far enough to draw a triangle?
19:21 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has joined #nouveau
19:22 < darktama> textures and such are simple to implement after you get triangles
19:23 < darktama> we should be able to do tris on cards that support DX5_TEXTURED_TRIANGLE.. haiku can already do it
19:40 < phh> DX5 Oo ?
19:40 < darktama> it's the name of the 3D object on some of the older cards
19:45 < pmdata> phh> there is also GDI_RECTANGLE_TEXT, for your win32 pleasure
19:49 < phh> ergh
19:56 -!- Myrizio [n=Myrizio@host68-101.pool80104.interbusiness.it] has joined #nouveau
19:59 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:02 -!- hiyuh_work [n=hiyuh@L011078.ppp.dion.ne.jp] has quit ["Leaving"]
20:14 < stillunknown> phh: i think marcheu wanrts to begin too, but he also seems intend on doing a good implementation for things like dma
20:14 < phh> so "just" wait ...
20:15 < phh> (i hope i will be able to make tests crashes before rebeginning of school (comment on doit dire rentre en anglais?))
20:15 < stillunknown> the last thing anyone needs i a poor hackjob of a driver
20:15 < stillunknown> i am not really good at french
20:15 < phh> i agree
20:18 < zoeloelip> phh: the start?
20:18 < zoeloelip> It doesn't have a specific word like in french I guess
20:18 < phh> zoeloelip, not really better
20:19 < zoeloelip> rentrée doesn't have a direct translation, I think
20:20 < stillunknown> you probably want something like: start of the next year of school
20:21 < phh> yep
20:21 < zoeloelip> that's about the closest translation from french to english
20:21 < phh> erf
20:21 < phh> english sucks.
20:22 < zoeloelip> dutch doesn't have a direct translation either
20:22 < stillunknown> i'm surprised you speak english this well, but i suppose you are a younger generation than the typical french man/woman
20:22 < phh> 17 years old is young ? :D
20:22 < stillunknown> yes
20:23 < phh> stillunknown, say to my english teachers that i speak english well, they will laugh
20:23 < zoeloelip> hehe
20:24 < stillunknown> i've seen/heard/read worse
20:25 < stillunknown> i was lucky english interested me early in life, otherwise it would been a complete disaster, just like other foreign languages
20:25 -!- tezem [n=tezem@80.109.173.112] has quit ["Kyle quit the band"]
20:25 -!- Myrizio_ [n=Myrizio@host19-98.pool80104.interbusiness.it] has joined #nouveau
20:25 < stillunknown> french is a complete disaster for me
20:26 < phh> french is a hard language
20:26 < zoeloelip> hmm, for me german is harder then french
20:27 < stillunknown> i can only remember one sentence very well and i'm not even sure if it's correct
20:27 < stillunknown> german is slightly better for me, but mostly a passive language
20:27 < phh> zoeloelip, it's pretty same i think
20:27 < phh> passive ?
20:27 < phh> what you mean by passive ?
20:27 < stillunknown> listening, not speaking
20:27 < phh> ah
20:28 < phh> stillunknown, as me for english
20:28 < zoeloelip> french is getting more and more passive for me, I really don't use it enough
20:28 < phh> it's even more reading than listening
20:29 < stillunknown> i live very close to the german border, so that's explains why i understand basic german
20:29 < stillunknown> but english i really like
20:31 < stillunknown> most of my english is reading and writing, but i can speak it if i get used to it a while
20:31 < stillunknown> a lot of my school books are english and the internet is mostly english too
20:33 < stillunknown> phh: just keep using english and it will be ok
20:33 < stillunknown> otherwise not :-)
20:33 < phh> stillunknown, i need to speak it...
20:34 < stillunknown> i force myself to write everything correctly, so i continue to have a sense of the language as it should be
20:34 < phh> i try to but as i have no reference to compare to i'm not able to be sure
20:35 < stillunknown> speaking doesn't happen a lot and last year there was a project which involved speaking to a foreign phd student and that was ackward
20:36 < stillunknown> phh: i can't be sure
20:36 < stillunknown> is better
20:36 < phh> ah yes
20:36 < stillunknown> i try to, but i have no reference, so i can't be sure
20:38 < stillunknown> the problem is that a lot of native speakers speak a dialect
20:38 < stillunknown> so on the internet, it can be difficult to learn it properly
20:39 < phh> or simply doesn't write correctly
20:39 < stillunknown> that too
20:39 < zoeloelip> at least in Belgium and the Netherlands movies and series aren't dubbed
20:39 < zoeloelip> that makes a real difference in learning english
20:40 < stillunknown> i wanted to watch star trek when i was 13-14 and bbc 2 broadcasted it a lot in those days
20:40 < stillunknown> so i was got some feeling for english
20:40 < phh> i should do the same
20:40 < stillunknown> later i had to unlearn some things (mostly things from the US and not the UK)
20:41 < stillunknown> but at least i had a "feeling" for the language
20:41 < zoeloelip> just don't read subtitles, most translations aren't very good anyway
20:41 < stillunknown> it's annoying when they are not sync
20:41 < zoeloelip> a lot of jokes aren't translated at all
20:42 -!- atcl [n=Universe@Lb111.l.pppool.de] has joined #nouveau
20:42 < stillunknown> Where are you from?
20:42 < zoeloelip> Belgium
20:43 < stillunknown> The place of annoying data transfer limits :-)
20:43 < phh> hehe
20:43 -!- Myrizio [n=Myrizio@host68-101.pool80104.interbusiness.it] has quit [Success]
20:43 < zoeloelip> indeed
20:43 -!- Myrizio_ is now known as Myrizio
20:43 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has quit [Read error: 104 (Connection reset by peer)]
20:44  * phh has 15Mbits unlimited
20:44 < stillunknown> who is pmandin?
20:44 < zoeloelip> for the price we pay here for 10GB, you get a flatrate in france
20:44 < phh> zoeloelip, how many do you pay ?
20:45 < zoeloelip> 41euro for 10Mbit and 10Gig download limit
20:45 < phh> it could be worse
20:45 < phh> (and better)
20:45 < stillunknown> also an upload limit?
20:46 < zoeloelip> yeah, 2gig
20:46 < zoeloelip> but I don't care about upload
20:47 < stillunknown> i wish there were decent connections with equal download and upload speed
20:47 < phh> yeah :/
20:47 < zoeloelip> stillunknown: that's technicly to hard with cable or dsl technologies
20:48 < stillunknown> vdsl (which they will start to use in belgium) can do 25/25
20:48 < phh> stillunknown, max distance is how many ?
20:49 < zoeloelip> 1 mile or something like that
20:49 < stillunknown> not sure, but not a lot
20:49 < stillunknown> maybe a km
20:49 < phh> no way in france 
20:50 < stillunknown> i'm pretty happy atm
20:50 < phh> i too in fact
20:50 < stillunknown> i can download at a few hundred KiB/s
20:50 < stillunknown> and upload at 70-80
20:50 < phh> upload at 100  dl at around a MB
20:50 < phh> (depending of the server in fact)
20:50 < atcl> in DE you actually can buy something that is called synchronous DSL 6/6 for example but it costs
20:51 < phh> atcl, it's called "ligne spcialise" in france
20:51 < stillunknown> business lines
20:51 < phh> but it costs many too
20:51 < atcl> yep
20:51 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
20:51 < stillunknown> phh: it costs too much
20:51 < phh> oula
20:51 < phh> yes
20:51 < stillunknown> or: it costs a lot
20:52 < atcl> but from my poit of view, me having 2Mbit, the servers are to slow, not me as the client. 
20:53 < stillunknown> i can usually download updates at 400-450, which is my max
20:53 < stillunknown> ofcource the downloading costs much less time than the compile :-)
20:53 < phh> :)
20:53 < zoeloelip> hmm, for me the full 10Mbit, so 1.25Mbyte
20:53 < zoeloelip> thats really fast but with a limit of 10Gig not very usefull
20:53 < phh> zoeloelip, i don't have such a bitrate oft :/
20:54 < phh> (no server handle it)
20:55 -!- clemux [i=clemux@lithium.quarante-d.eu] has quit [Connection reset by peer]
20:58 -!- clemux [i=clemux@lithium.quarante-d.eu] has joined #nouveau
20:58 < stillunknown> kde stuff takes long to compile :-( (i need some of it for a few apps)
20:58 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
21:04 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
21:08 < pmdata> stillunknown> pmandin = pmdata = me
21:17 < pmdata> http://www.nvidia.com/object/7_series_techspecs.html gf7 features compared
21:18 < pmdata> hum, well not much difference :)
21:22 < pmdata> noone with nv10/11 to make some dumps?
21:23 < pmdata> anyone with p0rn urls?
21:23 < Duke`> o/
21:23 < pmdata> :)
21:23 < Duke`> wait, I'll check my mails I'll have some fresh urls =)
21:24  * pmdata just wanted to make people talk 
21:24 < pmdata> we need nouveau driver to display open source 3d p0rn
21:26 < Duke`> and Xv working for accelerated pr0n movies
21:27 < zoeloelip> it wouldn't be the first time pr0n influences some technical evolutions :)
21:27 < Duke`> or regressions (Digital Right Management...)
21:28 < zoeloelip> yeah
21:28 < zoeloelip> I'm pretty sure that pr0n will once again decide for blue-ray <-> hd-dvd
21:47 -!- KoalaBR_ [n=KoalaBR@port-83-236-12-202.dynamic.qsc.de] has joined #nouveau
22:13 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
23:08 -!- zoeloeli1 [n=bart@d54C0400B.access.telenet.be] has joined #nouveau
23:14 -!- zoeloelip [n=bart@d54C0400B.access.telenet.be] has quit [Read error: 110 (Connection timed out)]
23:26 < KoalaBR_> marcheu, pmdata, darktama: I have put the current nouveau_reg.h from my program on http://sh.nu/p/2971  Please have look (especially the matrix and array defines) and tell me what you think
23:34 -!- predatorfreak [n=predator@ppp-70-236-146-53.dsl.sfldmi.ameritech.net] has joined #nouveau
23:35 -!- Gloubi [n=Gloubi@ABordeaux-253-1-98-159.w86-196.abo.wanadoo.fr] has joined #nouveau
23:49 < KoalaBR_> marcheu, darktama, pmdata: Any reason, why nv_objects[] is static? I use objects.o in my generator and the linker can't find nv_objects if it is static
23:51 -!- Gloubi [n=Gloubi@ABordeaux-253-1-98-159.w86-196.abo.wanadoo.fr] has left #nouveau ["I'll be back"]
--- Log closed Птн Сен 01 00:00:27 2006
