--- Log opened Втр Авг 22 00:00:12 2006
--- Day changed Втр Авг 22 2006
00:00 < pmdata> yep
00:00 < pmdata> I used it as a test bed for the sdl atari port
00:00 < marcheu> on the weak 68k ?
00:00 < pmdata> it depends on the m68k
00:00 < marcheu> ah ok :)
00:01 < pmdata> with a 060, it is quite fast
00:01 < marcheu> because, if you can get it on 68000, CPC guys can probably get it better on z80 :P
00:01  * marcheu loves the old-school disputes
00:02 < pmdata> there are some nice pci extensions for amiga and atari
00:02 < pmdata> I wonder if a nv card could be used on it
00:02 < pmdata> ^- hop, on topic
00:02 < marcheu> :)
00:03 < marcheu> I think some had a 3DFX on their amiga
00:08 < pmdata> yep, but they are quite old
00:08 < pmdata> ppc pegasos have some radeon driver
00:24 < shawn_work> marcheu: the Nvidia guit ool shows Video Memory: 512MB
00:24 < shawn_work> PCI Express 16X channel
00:26 < marcheu> I suppose we'll have to see someone with a card that has for sure 512MB if the register also caps at 256
00:26 < marcheu> but really, it's marketting you know
00:26 < shawn_work> heh
00:26 < marcheu> now if the memory size register caps at 256, that's annoying because we have to find another source for the vram size
00:27 < pmdata> the bios maybe
00:28 < marcheu> well, there's room for 0xfff MB of ram in that reg
00:28 < pmdata> hum, with current renouveau, the dumps are filled with much zeroed stuff
00:28 < marcheu> which is 4095MB of vram, which I think is enough. for now.
00:29 < marcheu> pmdata: I think lumag_offline removed the zero code
00:29 < pmdata> ah
00:29 < pmdata> how about a 2048x2048x2048 3d 32 bits texture?
00:29 < marcheu> I play with that at work, and it requires a cluster usually :)
00:29 < pmdata> this is 11+11+11+4=37 bits
00:30 < pmdata> put r,g,b,a components as floats, and it makes it 41 bits
00:30 < marcheu> no, no floats at work :)
00:30 < pmdata> does it run quake3?
00:31 < marcheu> heh, no
00:31 < marcheu> but it runs volume visualization, which is very nice as well
00:35 < pmdata> what is required to test/run the current drm/dri/nouveau stuff?
00:36 < marcheu> hmm I think Xorg 7.1 or more, and kernel 2.6
00:36 < marcheu> do not ever try to build Xorg yourself, get it from your distro
00:38 < stillunknown> unless you're a gentoo user, but then you do "get" something from your distro :-)
00:43 < stillunknown> does nouveau offer any advantage (2d perhaps) over the plain nv driver?
00:43 < stillunknown> (atm)
00:44 -!- EdB [n=EdB@ARennes-251-1-25-35.w81-250.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
00:47 < marcheu> hmm, EXA ?
00:48 < shawn_work> heh, building Xorg from git is ok, its getting easier slowly
00:50 < marcheu> it was easier with monolith, once you had the config setup, you could let everything build at once
00:51 < marcheu> here I spend an incredible amount of time installing separate packages
00:53 < pmdata> is there any plan to make a simple 2d nv driver (unobfucsated) from nouveau, or do you want a single full featured driver?
00:53 < marcheu> pmdata: what do you mean ?
00:53 < marcheu> I don't think we want two separate drivers, if that's what you ask
00:54 < pmdata> well, isn't the current x11 nv driver obfuscasted?
00:54 < shawn_work> pmdata: it would be nice to have the nouveau eventually do 2D properly with accel
00:54 < shawn_work> the current nv driver is a complete joke afaik
00:54 < marcheu> pmdata: yeah, it is. nouveau deobfuscates it a bit, but it takes a loooot of time to do
00:54 < airlied> I'm thinking brand new driver from scratch..
00:54 < marcheu> pmdata: but that's a good janitor project, yes, deobfuscate a bit
00:55 < airlied> I've got a name and .05 of a PreInit function..
00:56 < marcheu> airlied: not sure if that's a good idea... we've got something that works and it can always be cleaned up, even if that a lot of work
00:57 < marcheu> moving from "working state" to another "working state" is one of my favorite ways of doing development
00:57 < airlied> marcheu: it really really would be hard to make it do dualhead properly..
00:57 < marcheu> airlied: hmm, do you have a precise reason ?
00:58 < airlied> it's called nv_hw.c
00:58 < airlied> I'm not saying you couldn't do it I'm saying it would take a lot of work to do..
00:59 < airlied> I'd much rather restructure the code to look like an X driver and then pull in the pieces from nv..
00:59 < airlied> like xaa/cursor/xv stuff is reusable..
00:59 < airlied> just the modesetting is a bit nightmarishs..
01:00 < marcheu> well, nv_hw is getting slimmer
01:00 < marcheu> of course not as fast as we'd like, but I think everyone agrees that the ultimate plan is to have it empty
01:00 < airlied> actually nv_dac.c also contains some lovely stuff..
01:01 < marcheu> since we don't know anything for sure about the hw, hoping that we'll be able to pull a driver from scratch sound very hard
01:02 < airlied> marcheu: that nv10reg.h is good enough..
01:02 < airlied> for modesetting.. and if there is one thing I know how to do it is reverse engineer modesetting..
01:02 < airlied> nvidia will be the third chip I do it on..
01:03 < marcheu> they do it in the kernel
01:03 < marcheu> good luck with that :)
01:03 < airlied> marcheu: they also do it in the BIOS :-)
01:03 < airlied> RE'ing the BIOS mode paths is really simple..
01:03 < marcheu> I don't think the bios does all the modes
01:04 < airlied> marcheu: it doesn't have to, you just build up a picture from it..
01:04 < airlied> enough to figure out where all the info is going, I got a fully useable r520 and i915 driver doing it this way..
01:04 < airlied> intel even took my code as a starting point for their own driver :-)
01:05 < marcheu> well, if you can do it, that's cool
01:05 < pmdata> airlied> speaking of ati, no answer for your x1?00 driver?
01:06 < airlied> pmdata: I don't expect one until AMD/ATI settles sdown at least ..
01:06 < marcheu> but anyway, we're heading at emptying nv_hw.c, and I think that's the easiest way
01:08 < airlied> marcheu: for dualhead you still need to restrucutre the code though..
01:08 < marcheu> yeah, I don't fear restructuring stuff, I just prefer moving from one working piece of code to another
01:08 < airlied> and mergedfb wil also be of interest..
01:09 < marcheu> anyway, 4 different nvidia drivers will surely be full of interesting times :)
01:11 < airlied> well I figure you guys have sorted 3D so I may as well see if I can fix up 2D :-P
01:11 < marcheu> we're sorting 2D right now, we need EXA to become our friend for stuff like memory allocation
01:12 < airlied> I'm also hoping to be  able to use nv to write some ttm code for managing vram..
01:13 < marcheu> yeah, we'll have to replace that q'n'd memory manager at some point :)
01:18 < zoeloelip> some redhat dev refered to this project today on the fedore dev list: https://www.redhat.com/archives/fedora-devel-list/2006-August/msg00786.html
01:21 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
01:25 < pmdata> should we start to document how the various objects are used (for example to clear a buffer, or upload a texture in some format)?
01:31 < marcheu> yup
01:33 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
01:36 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
01:41 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit [Remote closed the connection]
01:41 -!- K [i=hazel@tor/session/external/x-12ddeee900c7fb31] has quit [Remote closed the connection]
01:43 < stillunknown> i hope you guys will let us know when the driver becomes more useable than nv (from a 2d point of view) :-)
01:45 < stillunknown> because nvidia is being awfully slow with xorg 7.1 drivers
01:46 -!- atcl [n=Universe@L8726.l.pppool.de] has quit [Read error: 104 (Connection reset by peer)]
01:51 -!- pmdata [i=patrice@ANantes-154-1-60-83.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:51 < Duke`> no, we'll keep it secret forever
01:51 < Duke`> :p
01:54 < stillunknown> you're being mean :-(
01:55 < stillunknown> but seriously, improved 2d behavior is not one of the main goals
01:56 < stillunknown> but it's interesting
01:57 < stillunknown> because the nvidia driver is not always good for near-realtime behavior
01:58 < stillunknown> will the driver actually run atm?
02:00 < marcheu> yeah, it runs and uses EXA
02:01 < marcheu> to the end user there's no difference from "nv"
02:01 < stillunknown> what is the exact purpose of the drm module?
02:01 < marcheu> it's controlling access to the card
02:02 < marcheu> in partiular, it enforces security and separation between graphical processes
02:03 < stillunknown> is the dri module actually needed atm?
02:03 < marcheu> no
02:03 < marcheu> it's for 3D, and it doesnt compile ATM
02:08 < Duke`> DRI, DRM, DDX, kernel module... a lot of things for a driver
02:09 < stillunknown> i thought it was going to be easy to try it, but it seems gentoo has an eclass to deal with modular xorg and i can't easily squeeze a cvs source into it
02:12 < Myrizio> linux architecture for 3d is very complicated...
02:15 < stillunknown> i'm just referring to easy intergration into a package manager, which is usually quite easy, but it seems that for modular xorg a lot was moved into a special eclass to simplify ebuilds
02:16 < stillunknown> (at least for the drivers)
02:19 < marcheu> Duke`: kernel module == DRM
02:20 < Duke`> oh, ok
02:20 < Duke`> so only 3 things left ;p
02:20 < marcheu> yeah
02:21 < b33fc0d3> stillunknown: it's easu
02:21 < b33fc0d3> easy
02:22 < b33fc0d3> use the SNAPSHOT variable.
02:22 < stillunknown> you forget one thing, the eclass assumes the files are at a specific place on the freedesktop server
02:23 < b33fc0d3> no
02:23 < stillunknown> or did you just make a new src_unpack?
02:24 < stillunknown> x-modular_unpack_source() i mean
02:25 < stillunknown> b33fc0d3: trigger
02:25 < b33fc0d3> devmanual.gentoo.org
02:25 < stillunknown> that's an url i've never seen
02:26 < b33fc0d3> now you have =)
02:27 < stillunknown> but, this still leaves the question, did you redefine x-modular_unpack_source() ?
02:28 < stillunknown> or can i just define a cvs server and the usual info and will portage deal with it?
02:28 < b33fc0d3> If you wait a few days i'll make some ebuilds
02:28 < b33fc0d3> just need some patches from Keltor first
02:30 < stillunknown> ok, patches for what if i may ask?
02:30 < b33fc0d3> xorg7.0
02:31 < stillunknown> i thought this whole thing was only intended to run on 7.1 and higher?
02:31 < b33fc0d3> i've been told otherwise
02:32 < stillunknown> ok, doesn't matter much to me since i have been running 7.1 for a while now
02:32 < b33fc0d3> i can make the patches optional
02:33 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
02:34 < stillunknown> i'll be awaiting the ebuilds, hopefully nvidia will release those drivers once, so i can try out renouveau and see if i can make sense of dumps
03:02 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
03:11 -!- Duke` [n=gnu@ANantes-251-1-87-207.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
03:32 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has joined #nouveau
03:33 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
03:54 -!- shenki [n=shenki@ppp225-88.lns2.adl4.internode.on.net] has quit [Read error: 113 (No route to host)]
03:55 -!- shenki [n=shenki@121.44.128.190] has joined #nouveau
04:33  * marcheu w00t
04:46 < airlied> libdri fixed?
04:47 < marcheu> yeah, was stupid drm code making sarea mapping crash
04:47 < marcheu> I'm going to upgrade everything to drm git while I'm there
04:48 < marcheu> our current version doesn't even compile the radeon module, I did a checkout at a time when radeon was broken
04:48 < marcheu> that's not too serious :)
04:49 < airlied> marcheu: radeon + broken never :-)
04:50 < airlied> marcheu: you guys should seriously think about moving to git.. for merging that stuff back in later it will be invaluable..
04:50 < airlied> and also for pulling changes from mainline as you need them..
04:50 < marcheu> ^until now, things were surprisingly easy WRT merging
04:51 < marcheu> mostly because we're working on separate files
04:51 < marcheu> and merging from "nv" is trivial, since so little happens there
04:52 < marcheu> I suppose huge commit means I have to go to bed just afterwards
04:52 < airlied> yeah when we get Mesa moved to git it will be the most useful..
04:53 < marcheu> yeah for mesa you even want to be mainline
04:53 < marcheu> seeing as they change their internal interfaces
04:53 < airlied> well with git you dfon't need that..
04:53 < airlied> distributed version control is a whole different world than CVS..
04:53 < marcheu> you don't need it if you're in the main tree, that is
04:53 < airlied> you don't need it full stop..
04:53 < airlied> there is no "main" tree with distrib..
04:54 < airlied> as long as you can pull changes from the main tree easily it never matters..
04:54 < marcheu> well, take the revent vertex prog parameter changes
04:54 < marcheu> that would not have been automagically ported to nouveau
04:54 < airlied> marcheu: well for mesa core developers making global changes being in the tree is useful..
04:54 < marcheu> I mean, the advantage of being in the main tree is that the one who breaks an internal stuff cares about fixing all the drivers :)
04:55 < airlied> marcheu: that doesn't always happen in Mesa :-)
04:55 < marcheu> yeah I know
04:55 < marcheu> *cough* t_vertex :)
04:56 < airlied> well I'll let you sleep I've got to get back to an x86 BIOS and IDA pro...
04:56 < marcheu> actually I now feel like coding a bit, now that the stuff is working
04:56 < marcheu> :)
04:58 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Remote closed the connection]
04:58 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
05:16 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Remote closed the connection]
05:18 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
05:41 -!- shenki_ [n=shenki@121.44.128.190] has joined #nouveau
05:43 -!- shenki [n=shenki@121.44.128.190] has quit [Read error: 110 (Connection timed out)]
06:09 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Remote closed the connection]
06:10 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
06:27 < darktama> hmm, I'm all for moving to git.. I know the basics (I use it for a few things locally), it seems quite powerful
06:40 -!- Myrizio [n=Myrizio@host36-96.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
06:43  * ajmitch thinks it'd make future maintenance of branches much easier
08:02 -!- tibbs is now known as tibbs|h
08:57 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
10:43 -!- predatorhawk [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
10:53 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has joined #nouveau
10:55 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
10:55 -!- predatorhawk [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
11:16 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
11:16 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
11:18 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has joined #nouveau
12:08 -!- Unavowed [n=silent@host81-158-183-48.range81-158.btcentralplus.com] has joined #nouveau
12:12 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has joined #nouveau
12:38 -!- shenki [n=shenki@121.44.128.190] has joined #nouveau
12:43 -!- Duke` [n=gnu@ANantes-251-1-87-38.w86-203.abo.wanadoo.fr] has joined #nouveau
12:54 -!- phh [n=phh@moi.phhusson.info] has joined #nouveau
12:54 < phh> Hi
13:08 < Duke`> ah nan pas lui /o\
13:08 < phh> Duke`, merci
13:09 < phh> Duke`, tu connais bien le projet ou t'es la juste pour trouver des amis ? :p
13:10 < phh> (bon pour savoir si y a quelque chose d'utilisable ou pas
13:10 < phh> (j'ai cru voir que y avait un support de l'overlay?)
13:10 < Duke`> utilisable heu, ben un peu mais ça te donnera rien de plus que nv pour le moment
13:11 < phh> ah bon ?
13:11 < phh> pourtant de ce que j'ai vu des commits
13:11 < phh> ca y va
13:11 < Duke`> sinon y'a renouveau, pour dumper les commandes nvidia, qui marche lui :)
13:11 < phh> oui ca j'ai vu
13:11 < phh> ca y va encore plus :p
13:12 < Duke`> il y a le memory manager qui est prêt (normalement)
13:12 < phh> modulo les bogues je penses qd meme
13:12 < Duke`> voilà
13:13 < Duke`> t'as les logs du channel qui sont online si tu veux tout savoir :-)
13:14 < EdB> phh, tu ne sais plus quoi faire ? :o)
13:15 < phh> EdB, t'inquiete c'est juste pour tester, pas pour coder dessus :p
13:15 < phh> (putain mais le monde est vraiment riquiqui)
13:15 < Duke`> quoique ça serait marrant qu'un lycéen recode les drivers nvidia sans doc officielle :P
13:15 < phh> y en a un qui a russi  casser CSS
13:16 < EdB> Duke`, arrete, tu sais bien que l'open source, c'est des con, il sont pas capable de faire de bon driver 3d
13:16 < EdB> :o)
13:16 < phh> c'est ou que je l'avais lu ce troll l dj
13:17 < EdB> c'est nvidia qui l'a dit
13:17 < Duke`> Andrew Fear, nvidia product manager
13:17 < phh> ah
13:17 < Duke`> http://lwn.net/Articles/180633/
13:18 < phh> au fait le driver nv tait en PCI non ?
13:19 < Duke`> PCI ?
13:19 < phh> Duke`, ben il accedait au device comme si c'etait du pci pas del 'agp
13:19 < phh> (sans agpgart quoi)
13:19 < Duke`> ah ça je ne sais pas
13:20 < phh> (m'enfin pour la 2D le dbit PCI devrait suffir)
13:21 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
13:22 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has joined #nouveau
13:35 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
13:35 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has joined #nouveau
13:49 -!- Duke` [n=gnu@ANantes-251-1-87-38.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
13:52 -!- Duke` [n=gnu@ANantes-251-1-87-38.w86-203.abo.wanadoo.fr] has joined #nouveau
14:15 < marcheu> ouais on utilise l'agpgart
14:15 < marcheu> quand a marche
14:17 < phh> hum
14:19 < phh> c'est  dire que ca marche rarement ou ?
14:29 < marcheu> c'est--dire que je m'énerve sur des bugs
14:30 < marcheu> darktama: so, it fails to create the DMA notifiers here. is there an usual suspect for that ?
14:30 < marcheu> also, I get those dma timeouts again, so I'll be able to investigate on that front
14:30 < darktama> it'll fail if it can't alloc AGP.. I think that's the only way it can fail currently
14:31 < darktama> oh, or if it can't drmMap() the alloc'd space
14:31 < marcheu> btw did you see any issue with the large update to drm git I did yesterday ?
14:31 < marcheu> it was ok for me, but it was so large...
14:32 < darktama> I haven't tried it yet, I've only just finished with that windows machine.. :S
14:32 < marcheu> hehe
14:32 -!- scandium [n=scandium@pD9EE9E44.dip0.t-ipconnect.de] has joined #nouveau
14:47 < darktama> marcheu: did you forget a file in that commit?
14:47 < darktama> In file included from /home/darktama/cvs/drm/linux-core/drm_auth.c:36:
14:47 < darktama> /home/darktama/cvs/drm/linux-core/drmP.h:92:25: error: drm_hashtab.h: No such file or directory
14:50 < marcheu> hmm
14:51 < marcheu> a couple even
14:51 < darktama> hehe, oops :)
14:52  * airlied pops up git again ;-) you'd avoid that :-P
14:53 < marcheu> airlied: yeah, if we're in the official drm git
14:54 < marcheu> airlied: would you host our drm in your git repo ?
14:54 < airlied> marcheu: no problem at all..
14:54 < airlied> marcheu: you can put it straight in drm HEAD as the official one is the kernel one..
14:55 < marcheu> ok, that's something we'll need to do then
14:56 < marcheu> although I don't think I'm in the drm group
14:57 < airlied> marcheu: it's the mesa group I think..
14:57 < airlied> yeah mesa group..
14:57 < marcheu> hehe I don't have my fd.o key handy but I think I'm not either
14:58 < airlied> wow I thought you'd be in mesa .. I'll get you added..
14:58 < darktama> marcheu: ok, it's all good now.. and still works even :)
14:58 < marcheu> darktama: are you in mesa as well ?
14:58 < darktama> nope
14:59 < marcheu> airlied: so, darktama needs too
14:59 < airlied> has he fd.o a/c if not get him to follow the instructions on the wiki..
14:59 < airlied> the great thing about git, is you don't really need access to the main repo..
15:00 < airlied> someone can easily filter in patches using git-formatpatch and git-am, but I don't think we've any probs with nouveau ppl getting access to mesa/drm..
15:01 < airlied> marcheu: you are in drm group it might take 5-10 mins to propogate..
15:01 < marcheu> it'll take more than that to get may ssh key to fd.o back anyway :)
15:01 < marcheu> s/may/my
15:02 < airlied> feel free to git clone the drm anon, add your files to it in one commit, and do git-formatpatch and send it and I can drop it in..
15:06 < phh> why are main of commits, "Oops" ? :)
15:08 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Read error: 113 (No route to host)]
15:10 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
15:15 < darktama> airlied: ok, submitted the request
15:29 -!- predatorfreak [n=predator@adsl-69-212-32-15.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
15:49 < marcheu> darktama: btw you should request to be in "nouveau" while you're at it
15:50 < darktama> ok, I'll add that to the bug
15:52 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
16:13 < phh> darktama, that's not an answer :p
16:13 < darktama> hehe
16:52 -!- scandium [n=scandium@pD9EE9E44.dip0.t-ipconnect.de] has quit ["using sirc version 2.211+KSIRC/1.3.12"]
17:03 -!- Keltor [n=Keltor@unaffiliated/keltor] has joined #nouveau
17:06 < marcheu> darktama: we need a setparam for agp mode/fw/sba :)
17:06 < darktama> ok :)  I have no idea how to control that stuff though
17:06 < Keltor> how should i build nouveau against xorg 7.0?
17:06 < marcheu> [still answering your question from the other day]
17:07 < marcheu> darktama: easy, it's drm_agp_enable
17:07 < darktama> I just started working on it 10 mins ago actually :)
17:07 < darktama> ahh, ok
17:07 < marcheu> which right now puts my card in 8x/SBA/FW which it doesn't like too much I think
17:08 < marcheu> Keltor: you have to downgrade nv_exa.c to rev 1.1
17:08 < marcheu> rev 1.2 follows the API from Xorg 7.1
17:09 < stillunknown> exa is working ok now?
17:13 < darktama> it works ok for me, Xv is broken - but that's known, and relatively easy to fix
17:16 < stillunknown> be sure to yell when xv is fixed, because i'd use the drivers if only for the warm fuzzy feeling :-)
17:16  * darktama needs something mergedfb-like before he can comfortably use it
17:16  * darktama looks at airlied :)
17:19 -!- Myrizio [n=Myrizio@host83-101.pool80104.interbusiness.it] has joined #nouveau
17:50 -!- hiyuh [n=hiyuh@ZL050248.ppp.dion.ne.jp] has quit ["Leaving"]
18:03 -!- Netsplit brown.freenode.net <-> irc.freenode.net quits: @ChanServ
18:06 -!- K [i=hazel@tor/session/external/x-a6735853caf66aee] has joined #nouveau
18:07 -!- Netsplit over, joins: @ChanServ
18:33 -!- K [i=hazel@tor/session/external/x-a6735853caf66aee] has quit [K-lined]
18:33 -!- K [i=hazel@tor/session/external/x-c0e41c052a37459c] has joined #nouveau
18:35 -!- K [i=hazel@tor/session/external/x-c0e41c052a37459c] has quit [K-lined]
18:35 -!- K [i=hazel@tor/session/external/x-6fb3c18268c31076] has joined #nouveau
18:36 -!- K [i=hazel@tor/session/external/x-6fb3c18268c31076] has quit [Remote closed the connection]
18:39 -!- K [i=hazel@tor/session/external/x-a45a78e16d9dbd39] has joined #nouveau
18:44 < marcheu> darktama: nv34 tests updated
18:48 -!- K [i=hazel@tor/session/external/x-a45a78e16d9dbd39] has quit [Remote closed the connection]
18:50 -!- K [i=hazel@tor/session/external/x-b09dd1dce9ea8a81] has joined #nouveau
19:02 -!- K [i=hazel@tor/session/external/x-b09dd1dce9ea8a81] has quit [K-lined]
19:02 -!- K [i=hazel@tor/session/external/x-c389297bc01df497] has joined #nouveau
19:03 -!- K [i=hazel@tor/session/external/x-c389297bc01df497] has quit [Remote closed the connection]
19:09 -!- Duke` [n=gnu@ANantes-251-1-87-38.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
19:11 -!- Duke` [n=gnu@ANantes-251-1-87-38.w86-203.abo.wanadoo.fr] has joined #nouveau
19:12 < darktama> marcheu: thanks :)
19:13 < darktama> btw, any timeframe on your ddx modifications? (using the memory manager)
19:29 < marcheu> I'm chasing the dma timemouts now
19:29 < marcheu> that'll probably be a small change anyway
19:30 -!- Myrizio [n=Myrizio@host83-101.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)]
19:33 < darktama> ok, I'll tackle that soon then unless you beat me to it.  but for now, sleep :)
19:33 < darktama> night
19:37 < marcheu> yeah, I think it'll take some time to figure out those timeouts, they were already here with the first exa patch
19:37 < marcheu> good night !
19:43 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:55 -!- Unavowed [n=silent@host81-158-183-48.range81-158.btcentralplus.com] has quit [Remote closed the connection]
19:57 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
20:10 -!- Myrizio [n=Myrizio@host79-102.pool80104.interbusiness.it] has joined #nouveau
20:30 -!- pmdata [i=patrice@ANantes-154-1-70-87.w86-195.abo.wanadoo.fr] has joined #nouveau
21:01 < pmdata> I just checked my gf2ti tv out is 9 pin mini din
21:01 < pmdata> grr
21:02 < stillunknown> why the grr?
21:02 < phh> stillunknown, he only have rca cables
21:02 < pmdata> should it work with standard 4pin svideo cable, if I remove the small plastic part?
21:02 < stillunknown> i think 9 pin means you just need seperator extension
21:03 < pmdata> it's not easy to find a 9pin cable
21:03 < stillunknown> it should have been included with the card\
21:03 < pmdata> hum it wasn't
21:03 < phh> i think as stillunknown 
21:03 < phh> pmdata, you're sure it's tv out ?
21:03 < pmdata> I bought it used, so I don't know where the cable is
21:03 < pmdata> I did not got it 
21:04 < pmdata> this is a gf2, so according to the doc there is tvout
21:05 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has joined #nouveau
21:06 < pmdata> I did not remember where, but I read in some log file the tvchip was chrontel 7007
21:07  * stillunknown has never used his tv-out breakout box
21:09 < stillunknown> doesn't the tv-out come intergrated into the main chip?
21:09 < stillunknown> or was that only later on?
21:10 < pmdata> it was added later (the 'twinview' feature)
21:10 < pmdata> nv15 don't support 2 output
21:10 < pmdata> it's either vga or tvout
21:10 < stillunknown> that's bad
21:11 < pmdata> I want to know if my tvout works, that's why I have 'cable' problems
21:11 < phh> is twinview support began ?
21:11 < phh> (i will maybe make a try)
21:25 -!- pmdata [i=patrice@ANantes-154-1-70-87.w86-195.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
21:44 -!- KoalaBR [n=KoalaBR@port-83-236-14-219.dynamic.qsc.de] has joined #nouveau
21:51 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Remote closed the connection]
21:56 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has quit [Remote closed the connection]
21:56 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has joined #nouveau
21:56 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
21:59 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Client Quit]
21:59 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
22:01 -!- Myrizio_ [n=Myrizio@host74-96.pool80104.interbusiness.it] has joined #nouveau
22:04 -!- EdB_ [n=EdB@ARennes-251-1-66-177.w86-195.abo.wanadoo.fr] has joined #nouveau
22:07 -!- Keltor [n=Keltor@unaffiliated/keltor] has quit ["meetings"]
22:10 -!- Anne_ [n=EdB@ARennes-251-1-66-177.w86-195.abo.wanadoo.fr] has joined #nouveau
22:11 -!- shenki [n=shenki@121.44.128.190] has quit [Read error: 110 (Connection timed out)]
22:11 -!- EdB_ [n=EdB@ARennes-251-1-66-177.w86-195.abo.wanadoo.fr] has quit [Read error: 104 (Connection reset by peer)]
22:14 -!- Myrizio [n=Myrizio@host79-102.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)]
22:18 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit ["Mike Patton"]
22:18 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
22:19 -!- EdB [n=EdB@ARennes-251-1-8-65.w83-195.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
22:20 -!- Anne_ [n=EdB@ARennes-251-1-66-177.w86-195.abo.wanadoo.fr] has quit [Remote closed the connection]
22:20 -!- Anne_ [n=EdB@ARennes-251-1-66-177.w86-195.abo.wanadoo.fr] has joined #nouveau
22:25 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit [Remote closed the connection]
22:25 -!- Anne_ [n=EdB@ARennes-251-1-66-177.w86-195.abo.wanadoo.fr] has quit [Remote closed the connection]
22:26 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
22:27 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit [Remote closed the connection]
22:36 -!- KoalaBR [n=KoalaBR@port-83-236-14-219.dynamic.qsc.de] has quit [Remote closed the connection]
22:41 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
22:41 -!- KoalaBR [n=KoalaBR@port-83-236-14-219.dynamic.qsc.de] has joined #nouveau
22:42 < KoalaBR> Hello
22:47 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has quit [Read error: 104 (Connection reset by peer)]
22:47 -!- Myrizio_ is now known as Myrizio
22:47 -!- b33fc0d3_ [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
22:47 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 113 (No route to host)]
22:48 -!- b33fc0d3_ is now known as b33fc0d3
22:49 -!- K [i=hazel@85-57-135-18.gij1.adsl.uni2.es] has joined #nouveau
22:55 < KoalaBR> pmdata, marcheu: For NV40 is see that 0x0200 and 0x0204 is setup nearly the same way as NV30_TCL_PRIMITIVE_3D_VIEWPORT_DIMS(0/1) - only difference, this seems to be the size of the SDL_Window. 
22:55 -!- K is now known as Unbeliever
22:56 -!- Gloubi [n=Gloubi@ABordeaux-253-1-101-88.w86-196.abo.wanadoo.fr] has joined #nouveau
22:59 < KoalaBR> I have seen this during test_startup(), a random test I wrote to try out accumulation buffers (Probably wrong) and in test_draw_buffer() - but the values may change to 0x0fff0000 during startup
22:59 < KoalaBR> Any idea of what this might be? We already found the VIEWPORT commands
22:59 < marcheu> backbuffer setup ?
23:00 < marcheu> just a shot in the dark, no real idea
23:01 < KoalaBR> Hm, best guess sofar
23:01 < KoalaBR> It doesn't make sense to have 2 different commands for the same functionality...
23:03 -!- stillunknown [n=madman20@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
23:04 < KoalaBR> Furthermore, there are 0x02c0 and 0x02c4 which are related to the values of 0x200 and 0x0204, but slightly different, still investigating this...
23:05 -!- pmdata [i=patrice@ANantes-154-1-70-87.w86-195.abo.wanadoo.fr] has joined #nouveau
23:05 < pmdata> hello again
23:05 < pmdata> I managed to get a picture on tvout, albeit all b&w, no color
23:05 < marcheu> hey pmdata 
23:05 < KoalaBR> Hi, pmdata. Didn't notice you was not online
23:05 < pmdata> I did not try all TVStandard options
23:06 < KoalaBR> Wrong Tv-Standard..... oh well :)
23:06 < pmdata> maybe Creative thought it was a good idea to put the C signal on another pin
23:06 < pmdata> I tried 3 different ones, same result
23:07 < KoalaBR> pmdata:I just asked marcheu, perhaps you have an idea..
23:07 < pmdata> koala> /me hides after the wrong cvs import yesterday
23:07 < KoalaBR> So what? All the others are perfect coders, aren't they?
23:07 < pmdata> of course :)
23:08 < pmdata> so what did you want to ask?
23:08 < KoalaBR> Although I wondered how to use my mouse on the NV43 when I first read the commits :)
23:08 < KoalaBR> For NV40 i see that 0x0200 and 0x0204 is setup nearly the same way as NV30_TCL_PRIMITIVE_3D_VIEWPORT_DIMS(0/1) - only difference, this seems to be the size of the SDL_Window. 
23:08 < KoalaBR> Furthermore, there are 0x02c0 and 0x02c4 which are related to the values of 0x200 and 0x0204, but slightly different, still investigating this...
23:09 < KoalaBR> any idea of what 0x200/0x204 might be? Marcheu thought, it could have something to do with the back buffer setup
23:09 < pmdata> I thought 2c0/2c4 are the viewport clipping values for the 3d rendering
23:10 < pmdata> 200/204 holds width and height in 16 higher bits of the 32bits value, like on nv10, no?
23:10 < KoalaBR> Yes to both
23:10 < KoalaBR> lower 16 bit have an offset
23:10 < pmdata> and maybe the lower part is where to start rendering in the viewport (x,y in the color buffer)
23:11 < KoalaBR> the offset calculates the same way as for 8c0 8c4 (all on NV40)
23:12 < pmdata> I wrote a little doc about object usage on nv10 (in cvs/doc dir), would be nice to check that also on other gpus
23:12 < marcheu> pmdata: I can plug the nv20 if you want to play with it
23:12 < KoalaBR> Well, I just wondered what that could be, as I had already checked for Viewport
23:12 < marcheu> I'm busy with fixing all the bugs that pop up in the DDX here
23:13 < KoalaBR> But that was 2d, marcheu told me at that time :)
23:13 < KoalaBR> So may be you are right
23:13 < KoalaBR> pmdata: What's the name of the doc?
23:13 < stillunknown> can i ask why you fix ddx when you want to use exa?
23:13 < pmdata> nv10_objects.txt
23:13 < KoalaBR> Ok, will do
23:14 < marcheu> stillunknown: the ddx is the name of the whole 2D driver
23:14 < marcheu> stillunknown: what we don't want to fix is XAA
23:14 < pmdata> marcheu> yes, I would like, seems we have other nv1x if needed
23:14 < marcheu> which isn't broken, btw
23:15 < marcheu> ok, as long as the AGP slot on my 2nd machine works, I'm ok with that :)
23:15 < marcheu> (my main machine's AGP slot has suffered a lot from my recent card switches)
23:15 < stillunknown> the slot is broken?
23:16 < marcheu> not yet, but I sometimes have to move the car in it to boot up
23:16 < marcheu> card
23:16 < marcheu> otherwise the machine does some beep of death
23:16 < pmdata> maybe someone will send me a gf3ti near the end of the year
23:17 < marcheu> cool
23:17 < stillunknown> maybe the clip securing the card is worn out?
23:17 < marcheu> stillunknown: nope
23:17 < marcheu> pmdata: nv20 is a bit different from nv25/28
23:17 < marcheu> I'd say subtly different
23:19 < pmdata> did we get dumps from nv20, or only nv25/28?
23:19 < marcheu> pmdata: looooong ago there were a couple of people with real nv20, yes
23:19 < pmdata> hum, none in nouveau.sf.net/tests
23:20 < marcheu> no, that test repo is way more recent
23:21 < pmdata> hum, if it seems it only support agp4x, I have it DLC
23:22 < pmdata> hum, boards I see are 2x/4x, ouf, it could work if I am lucky
23:23 -!- EdB [n=EdB@ARennes-251-1-87-78.w86-199.abo.wanadoo.fr] has joined #nouveau
23:23 < pmdata> koala> I think the 2 dma objects for each texture unit maybe wrong
23:23 < pmdata> they could be used to read 2 textures (for mipmapping) for same unit
23:24 < marcheu> geforce 3 with only agp4x ?
23:24 < pmdata> according to beyond3d, cards supports 2x/4x, gf3 supports 4x, will dig it
23:24 < pmdata> my motherboard is only 1x/2x
23:24 < marcheu> wow
23:25 < marcheu> even I don't have that
23:26 < marcheu> anyway, time to bissect between the original nv and the crashing exa. the night will be long..
23:26 < KoalaBR> pmdata: VIEWPORT_DIMS_(0/1) and 0x0200/ 0x0204 both belong to object beef3097 an object your doc doesn't describe
23:26 < marcheu> (I have to bissect by hand, since there's no repo of what happened between :( )
23:26 < stillunknown> marcheu: maybe you can use some kind of contact spray
23:27 < stillunknown> (and stop swapping cards so much)
23:27 < marcheu> stillunknown: yeah, now that it seems to work on each boot, I won't swap it any more
23:28 < stillunknown> they make wear out extenders appearantly for heavy swappers
23:28 < stillunknown> but i doubt you'll find one at your local computer shop :-)
23:29 < pmdata> time to build a kvm switch for agp boards then :)
23:30 < phh> bwarf
23:30 < stillunknown> it's not that funny, marcheu mainbord is permanently damaged, hopefully not too much
23:30 < stillunknown> *marcheu's
23:31 < KoalaBR> pmdata: marcheu suggested a wild guess: back buffer setup perhaps?
23:37 < pmdata> koala> maybe you could try the test_swap_buffers(), in fullscreen double buffer, with size = your desk size
23:40 < KoalaBR> Ok, will do that too, what do you expect?
23:41 < pmdata> you should see the object 7c used to change the video pointer, along with the color buffer offset changed between the 2 buffers
23:41 -!- Gloubi [n=Gloubi@ABordeaux-253-1-101-88.w86-196.abo.wanadoo.fr] has left #nouveau ["I'll be back"]
23:43 < KoalaBR> NV30_TCL_PRIMITIVE_3D      [0x0200/4] = 0x05000000
23:43 < KoalaBR> NV30_TCL_PRIMITIVE_3D      [0x0204/4] = 0x04000000
23:44 < KoalaBR> 1280x1024
23:45 < KoalaBR> I'm working with the accumulation buffer here (possibly totally wrong, was a just a try)
23:46 < KoalaBR> I can paste the test code as well as the complete dump 
23:48 < pmdata> so these values seem ok: w=1280 | x=0, h=1024| y = 0
23:49 < KoalaBR> Yes
23:49 -!- EdB [n=EdB@ARennes-251-1-87-78.w86-199.abo.wanadoo.fr] has quit ["Konversation terminated!"]
23:50 < KoalaBR> I see only 3097 object commands
23:50 < KoalaBR> nothing with 7v
23:50 < KoalaBR> nothing with 7c
23:50 < pmdata> could you post the dump somewhere?
23:50 < KoalaBR> Wait
23:52 -!- Myrizio_ [n=Myrizio@host28-98.pool80104.interbusiness.it] has joined #nouveau
23:53 < KoalaBR> Grr rafb stalls, will put it on my page
23:57 < KoalaBR> Arrgg
23:57 < KoalaBR> My upload doesn't like simple text files :/
--- Log closed Срд Авг 23 00:00:20 2006
