--- Log opened Срд Сен 06 00:00:31 2006
00:08 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has joined #nouveau
00:30 -!- mat__ [n=mat@cac94-1-81-57-151-96.fbx.proxad.net] has joined #nouveau
00:30 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has quit ["leaving"]
00:31 < mat__> pmdata: could could try experimental repo of debian : there is xorg 7.1 but may be there are too much dependency on unstable...
00:31 < mat__> s/could could/you could
00:33 -!- cptn [n=jw@217-162-119-116.dclient.hispeed.ch] has joined #nouveau
00:34 < pmdata> mat> will try, I don't care much if it's broken, I kept my sarge
00:34 -!- svu [n=svu@83.167.239.56] has quit [Read error: 54 (Connection reset by peer)]
00:35 -!- svu [n=svu@83.167.239.56] has joined #nouveau
00:42 -!- Myrizio [n=Myrizio@host204-101.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)]
00:50 < fatal__> pmdata: google for "apt pinning", add unstable and experimental (as well as testing) in /etc/apt/sources.list ... now you default to installing testing packages, but can pull stuff from experimental by using "apt-get -t experimental ..." and all dependencies (from experimental/unstable) should be pulled in automagically...
00:52 < pmdata> will do that tomorrow
00:52 -!- Myrizio [n=Myrizio@host50-96.pool80104.interbusiness.it] has joined #nouveau
00:53 -!- marteus [n=marteus@0x503fbab3.albnxx8.adsl-dhcp.tele.dk] has quit [Read error: 110 (Connection timed out)]
01:08 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
01:12 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
01:12 -!- jkolb [n=jkolb@wsi-128-168.wsi.com] has quit ["Leaving"]
01:20 -!- pmdata [i=patrice@ANantes-154-1-62-24.w81-53.abo.wanadoo.fr] has quit [Remote closed the connection]
01:20 -!- KoalaBR [n=KoalaBR@port-83-236-12-26.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
01:27 -!- Myrizio [n=Myrizio@host50-96.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
01:40 -!- Duke` [n=gnu@ANantes-251-1-154-93.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
02:04 -!- EdB [n=EdB@ARennes-251-1-60-28.w81-53.abo.wanadoo.fr] has quit ["Konversation terminated!"]
02:07 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
02:10 -!- mat__ [n=mat@cac94-1-81-57-151-96.fbx.proxad.net] has quit ["Leaving"]
02:19 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit ["Mike Patton"]
02:32 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:47 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
02:53 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has quit [Connection timed out]
03:06 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
03:10 -!- l4in [n=user@ppp138-195.adsl.forthnet.gr] has quit [Client Quit]
03:20 -!- Myrizio [n=Myrizio@host224-98.pool80104.interbusiness.it] has joined #nouveau
03:29 -!- darktama [n=darktama@gentoo/contributor/darktama] has quit [Read error: 60 (Operation timed out)]
04:31 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has joined #nouveau
04:59 -!- hiyuh_work [n=hiyuh@KD222013063041.ppp.dion.ne.jp] has joined #nouveau
05:24 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
05:38 -!- b33fc0d3_ [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
05:38 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 113 (No route to host)]
05:46 -!- b33fc0d3\null [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
05:46 -!- b33fc0d3_ [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 113 (No route to host)]
05:48 -!- b33fc0d3\null is now known as b33fc0d3
06:05 -!- b33fc0d3_ [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
06:05 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 113 (No route to host)]
06:22 -!- b33fc0d3\null [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
06:23 -!- b33fc0d3_ [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 113 (No route to host)]
06:23 -!- b33fc0d3\null is now known as b33fc0d3
07:04 -!- ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #nouveau
07:08 -!- tibbs is now known as tibbs|h
07:21 -!- darktama [n=darktama@gentoo/contributor/darktama] has joined #nouveau
08:48 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
08:57 -!- fatal__ [i=gem@gamezone.fjortis.info] has quit [Read error: 110 (Connection timed out)]
09:20 -!- Myrizio [n=Myrizio@host224-98.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)]
10:19 -!- fatal__ [i=gem@gamezone.fjortis.info] has joined #nouveau
11:33 -!- EdB [n=EdB@ARennes-251-1-11-150.w83-195.abo.wanadoo.fr] has joined #nouveau
11:44 -!- Duke` [n=gnu@ANantes-251-1-85-95.w86-203.abo.wanadoo.fr] has joined #nouveau
12:41 -!- Unavowed [n=silent@host81-158-97-241.range81-158.btcentralplus.com] has joined #nouveau
13:27 -!- leroutier [n=leroutie@home.leroutier.net] has joined #nouveau
13:27 < leroutier> hello
13:31 < leroutier> darktama, are you around ?
13:37 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
13:38 < leroutier> hi phh
13:38 < phh> hi
13:38 < leroutier> anyone could tell me if there is a repository for docs about Nvidia cards or their OpenGL implementation ?
13:39 < leroutier> I saw darktama refenrencing an internal nvidia paper in one of its latest commits
13:39 < EdB> i gues nvidia got some on is site
13:41 < leroutier> I think so, but I was wondering if we had a central repo for those in/for the projet, to have them centralised
13:42 < Duke`> no we don't have
13:42 < Duke`> just some links on the front page
14:21 -!- Netsplit zelazny.freenode.net <-> irc.freenode.net quits: FauxFaux
14:22 -!- Netsplit over, joins: FauxFaux
14:28 -!- Netsplit zelazny.freenode.net <-> irc.freenode.net quits: FauxFaux
14:29 -!- Netsplit over, joins: FauxFaux
14:43 -!- FauxFaux [n=faux@compsoc.sunion.warwick.ac.uk] has quit [Read error: 60 (Operation timed out)]
14:43 -!- FauxFaux [n=faux@compsoc.sunion.warwick.ac.uk] has joined #nouveau
14:51 -!- Netsplit zelazny.freenode.net <-> irc.freenode.net quits: FauxFaux
14:53 -!- Netsplit over, joins: FauxFaux
14:53 -!- FauxFaux [n=faux@compsoc.sunion.warwick.ac.uk] has quit [Connection reset by peer]
14:54 -!- FauxFaux [n=faux@compsoc.sunion.warwick.ac.uk] has joined #nouveau
14:58 -!- FauxFaux [n=faux@compsoc.sunion.warwick.ac.uk] has quit [Client Quit]
14:58 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
15:37 -!- EdB [n=EdB@ARennes-251-1-11-150.w83-195.abo.wanadoo.fr] has quit ["Konversation terminated!"]
15:47 -!- Unavowed [n=silent@host81-158-97-241.range81-158.btcentralplus.com] has quit ["leaving"]
15:55 -!- Unavowed [n=silent@host81-158-97-241.range81-158.btcentralplus.com] has joined #nouveau
16:02 -!- EdB|w [n=EdB@212.234.68.206] has joined #nouveau
16:34 < darktama> leroutier: I'm here now
16:35 < leroutier> hi darktama 
16:35 < leroutier> so, does such a repository exist ?
16:35 < darktama> not that I know of, developer.nvidia.com has a heap of links to presentations and such
16:41 < leroutier> yeah, I saw mainly siggraph & xdc ones
16:42 < marcheu> btw there was an interesting discussion going on yesteday on #xorg-devel. the nvidia guys are trying to synchronize operations from multiple fifos, it's kindof what we need
16:43 < marcheu> I suppose this will be discussed as well today
16:43 < darktama> nvidia cards support some of that in hardware don't they?
16:44 < darktama> at least, that's the impression I got from a presentation I saw somewhere.. not sure which
16:46 < darktama> marcheu: do you have logs?
16:51 -!- Myrizio [n=Myrizio@host121-98.pool80104.interbusiness.it] has joined #nouveau
16:54 < marcheu> yup
16:54 -!- EdB|w_ [n=EdB@212.234.68.206] has joined #nouveau
17:05 < marcheu> one second
17:07 < marcheu> http://icps.u-strasbg.fr/~marchesin/xorg-devel-nv
17:07 < darktama> marcheu: thanks
17:12 -!- EdB|w [n=EdB@212.234.68.206] has quit [Read error: 110 (Connection timed out)]
17:18 -!- jkolb [n=jkolb@wsi-128-132.wsi.com] has joined #nouveau
17:28 -!- shaAway is now known as __sha__
17:28 < darktama> hmm, that was certainly interesting.. and something that we'll have to tackle too
17:29 < marcheu> we won't have to, if they work it out themselves
17:30 < darktama> true, but we'll need to figure out how to implement the hardware-side of things.. do we have any info on the gpu's inter-fifo sync stuff?
17:30 < marcheu> there's none, otherwise they woudl't have to do that
17:30 < darktama> jamesjones mentioned that the GPU has semaphores
17:32 < darktama> no, it was aaronp
17:35 < darktama> hm, the FIFO regs have sem acquire/release regs
17:45 < jkolb> i like the 'companions'
17:48 < marcheu> looking at the log, it's not their main purpose, and they're not going to use them
17:51 < darktama> yes, it seems that the hw ipc may be insufficient to handle that particular case.. but, it could be useful elsewhere
17:52 < marcheu> well, I was thinking maybe we could track that ourselves in the irq handler
17:52 < marcheu> but it's probably subject to attacks from untrusted dri clients
17:53 < marcheu> which could start playing with the GET/PUT values
17:53 < darktama> yup, it looks like we can get notification after rendering has finished.. which makes sense, most objects seem to have a notifier
17:53 < darktama> hm, I wonder if I can convince NV30_TCL to give me notifications..
17:54 < darktama> oh btw, the 3D context seems to survive a reboot.. so I may have just missed something in the FIFO to get NV30_TCL to work without nvidia
17:56 < darktama> but, I wonder why 3D state is even setup on channel 0 with nvidia.. unless they've started using it in their X driver
17:56 < marcheu> yeah, they probably do
17:56 < marcheu> consider AIGLX for example
17:57 < darktama> they didn't in 8756 from what I recall, but I could be wrong.. I'm going to dump the hash table and RAMIN and see if they do in 8774
17:58 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
18:06 < darktama> 0x007138c0: 0x01019700
18:06 < darktama> 0x007138c4: 0x0010e8ee 0000 00000(chan 0) 0 01(engine 1) 0000 0xe8ee=RAMIN+0xe8ee0
18:06 < darktama> 0x007e8ee0: 0x00004097
18:06 < darktama> 0x007e8ee4: 0x0000e8d0
18:06 < darktama> yup, they do
18:07 < darktama> interesting that 0xBEEFxxxx handles aren't used in the X driver
18:07 < marcheu> yeah, X uses the 10 handles
18:07 < marcheu> BEEF are for 3D
18:08 < marcheu> and PI ones are for kernel IIRC
18:08 < darktama> I wouldn't mind renaming our handles to reflect what object they refer to actually, like.. 0x80004097
18:08 < marcheu> well, if you get it to work, I'm all for it
18:09 < marcheu> you have to care about the hashing, though
18:09 -!- hiyuh [n=hiyuh@ZK138220.ppp.dion.ne.jp] has joined #nouveau
18:09 < darktama> true
18:10 < darktama> well, renaming the objects are easy enough.. just need to change nv_dma.h and that should be it.. I was originally using 0xBEEF3097 in my NV30_TCL exa, but have changed it to match the other handles now
18:13 < darktama> marcheu: do you know where the context for a channel(or rather, a channel's subchannel?) lives?
18:14 < darktama> perhaps it's not even accesible to the CPU.. who knows
18:14 < marcheu> hmm, not sure
18:15 < darktama> I was thinking IGRAPH, but I'm not sure.. either you can't read it, or it's not used on nv40
18:23 -!- anders_ [i=andersg@0x63.nu] has joined #nouveau
18:27 -!- hiyuh_work [n=hiyuh@KD222013063041.ppp.dion.ne.jp] has quit [Read error: 110 (Connection timed out)]
18:35 -!- K is now known as Unbeliever
19:01 -!- hiyuh [n=hiyuh@ZK138220.ppp.dion.ne.jp] has quit ["Leaving"]
19:12 -!- Unbeliever_ [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
19:14 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Nick collision from services.]
19:14 -!- Unbeliever_ is now known as Unbeliever
19:41 -!- shenki [n=shenki@ppp110-122.lns4.adl4.internode.on.net] has joined #nouveau
19:52 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:53 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
19:55 < stillunknown> hello new friends
19:56 -!- shenki [n=shenki@ppp110-122.lns4.adl4.internode.on.net] has quit [Read error: 54 (Connection reset by peer)]
19:56 -!- shenki [n=shenki@ppp110-122.lns4.adl4.internode.on.net] has joined #nouveau
19:57 -!- Unavowed [n=silent@host81-158-97-241.range81-158.btcentralplus.com] has quit ["leaving"]
20:40 < darktama> hmm, the three object entries in class 0x4097's instance entry are different from most
20:41 < darktama> the first appears to be a notifier, the second I have nfi, the third appears to be a block containing multiple notifiers
20:47 -!- hanno [n=hanno@p54A4F850.dip.t-dialin.net] has joined #nouveau
20:52 -!- leroutier [n=leroutie@home.leroutier.net] has quit ["Ex-Chat"]
21:08 -!- Myrizio [n=Myrizio@host121-98.pool80104.interbusiness.it] has quit [Read error: 104 (Connection reset by peer)]
21:14 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has joined #nouveau
21:25 -!- pmdata [n=patrice@ANantes-154-1-16-166.w81-53.abo.wanadoo.fr] has joined #nouveau
21:26 < pmdata> hello
21:26 < pmdata> finished setting up etch with xorg 7.1 from experimental
21:27 < pmdata> also got current git and nouveau.sf stuff
21:27 < pmdata> time to compile the bouzin
21:28 < phh> :)
21:28 < phh> pmdata, it's your first time ?
21:29 < pmdata> yep
21:29 < pmdata> don't know where to start
21:29 < marcheu> drm
21:29 < phh> grilled
21:34 < pmdata> drm build, just 'make install' it ?
21:34 -!- Myrizio [n=Myrizio@host84-98.pool80104.interbusiness.it] has joined #nouveau
21:35 < EdB|w_> yes
21:35 < EdB|w_> hope you set the good option :o)
21:35 < marcheu> pmdata: also, build libdrm, or at least copy nouveau_drm.h to /usr/include/drm/
21:37 < jkolb> was there a switch to git or am i just dreaming it?
21:37 < marcheu> yup
21:37 < marcheu> drm and ddx are in git
21:37 < pmdata> nouveau_drm.h is not in git mesa/drm?
21:37 < marcheu> drm is the nouveau-1 branch from official drm
21:37 < darktama> btw, are we switching renouveau over to git?
21:38 < marcheu> darktama: no, that would involve migrating too many accounts I think
21:38 < darktama> ahh, that's a good point
21:38 < marcheu> darktama: and there's no real need
21:38 < pmdata> I just git cloned mesa/drm and nouveau/xf86-video-nouveau
21:38 < marcheu> pmdata: it should be here in drm/linux-core/
21:39 < darktama> pmdata: git checkout nouveau-1
21:39 < marcheu> pmdata: so, you have to switch mesa/drm to the nouveau-1 branch with git checkout nouveau-1
21:39 < pmdata> ah
21:39 < EdB|w_> (erf too late :o)
21:40 < pmdata> just 'git checkout nouveau-1' in drm dir?
21:40 < marcheu> yes
21:40 < darktama> pmdata: once you find your way around the ddx a bit you should write a decent composite hook for the cards you know about :)
21:42 < pmdata> I guess the driver checks on which hw it runs? :)
21:45 -!- KoalaBR [n=KoalaBR@port-83-236-12-239.dynamic.qsc.de] has joined #nouveau
21:45 < darktama> yup, it sure does
21:46 < KoalaBR> Hi
21:46 < darktama> hey KoalaBR!
21:46 < KoalaBR> Anything I can help with?
21:47 < darktama> actually, I did think of something as I was reading the logs.. we don't know anything much about surface formats (for colour/depth buffers etc)
21:47 -!- hanno_ [n=hanno@p54A4D2CF.dip.t-dialin.net] has joined #nouveau
21:47 -!- hanno [n=hanno@p54A4F850.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]
21:47 < marcheu> darktama: btw we could do some composite with NV04_DX5_ I think
21:48 < darktama> marcheu: it supports blending then?
21:48 < KoalaBR> darktama: so, what do you need?
21:48 < marcheu> darktama: well, at least alpha blending, but it has other functions, and in particular UNDER I think
21:48 < marcheu> darktama: do you know what's needed for the average desktop acceleration today ?
21:49 < marcheu> darktama: we could use the same composite hooks with the 3D engine on NV04 -> NV18 I think, and possibly have interesting functions
21:50 < darktama> marcheu: really, all we need is blend modes for Src(ONE, ZERO) and Over(ONE, ONE-Sa) and to be able to use 2 textures (and do IN on them)
21:50 < darktama> other blend functions would be nice, but Src and Over are the most used
21:50 < marcheu> ah, IN, that's the issue
21:50 < marcheu> well, I think multitexture to the rescue
21:50 < marcheu> have to study it, though
21:50 < darktama> yup, I do it with a fragprog on nv40
21:50 < darktama>     /* (src IN mask)
21:50 < darktama>      * TXP t0  , fragment.texcoord[0].xy, texture[0], 2D
21:50 < darktama>      * TXP t1.w, fragment.texcoord[1].xy, texture[1], 2D
21:50 < darktama>      * MUL result.color, t0, t1.w
21:50 < darktama>      */
21:51 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit [Remote closed the connection]
21:51 < marcheu> yeah, TNT can do that
21:51 < darktama> awesome :)
21:52 < darktama> KoalaBR: well, testing different colour buffer depths (either by setting X to that depth, or by using FBOs)
21:52 < marcheu> btw the mask is what format ?
21:52 < darktama> it can be any of the RENDER formats afaik
21:52 < marcheu> we'll have to extend to RGBA I think
21:52 < marcheu> I don't think we can handle single channel textures
21:52 < marcheu> s/we/the NV04/
21:53 < marcheu> so, memory waste ahead
21:53 < marcheu> darktama: btw for RENDER check there is this nice tool called rendercheck
21:53 < darktama> KoalaBR: as a hint, I believe the surface format is 0x208 in NV30_TCL_PRIMITIVE_3D
21:54 < darktama> marcheu: yup, I found it.. it doesn't seem to catch all issues.. I hardcoded the wrong values on purpose in one spot and it didn't say the test failed
21:54 < marcheu> it's buggy all around
21:54 < marcheu> I think it got fixed very recently though
21:55 < darktama> I might do some better testing using e17's XRENDER engine, it only uses Src/Over but I believe it uses scaling and such.. which I'm not sure I have correct
21:57 < darktama> I'm not sure whether to bother writing the code for NV30 vertex programs, or to ignore NV30 for now and use fixed-function for it later
21:58 < KoalaBR> darktama: Sorry, I am a little bit dense here, do you need the value of 0x208 in different modes (as color buffer, when rendering objects like tri()s etc) or what else?
21:58 < marcheu> darktama: I'm not sure I understand that sentence
21:58 -!- __sha__ is now known as shaAway
21:58 < darktama> KoalaBR: yup, 0x208 in different modes.
21:59 < KoalaBR> Well, I will slave away :)
21:59 < darktama> marcheu: well, the exa code I have uses vertex/fragment programs (you have to on nv40)
21:59 < darktama> marcheu: on nv30, it might be faster to used fixed-function
21:59 < darktama> so, I'm not sure whether to bother writing the nv30 shader support for it or not
22:00 < marcheu> ah, well for EXA I'd say this doesn't matter, you're bus-limited and fillrate-limited but not vertex-limited
22:00 < marcheu> darktama: btw, I was thinkg instead of having separate hooks for EXA, that we should instead have a kind of minigl hiding the cruft from internal hw
22:00 < marcheu> darktama: have some "draw_quad" and "set_alpha_func" stuff, implement them for everything from NV04 to NV40 with the 3D engine, and then stack them up as we want to achieve EXA
22:01 < darktama> I considered that, my EXA-dependant code makes calls to NV30_InitSurface/NV30_InitROP etc, so it should be ok to do
22:01 < marcheu> because I'm guessing we'll have a lot of code duplication otherwise
22:02 < darktama> yeah, most likely
22:02 < darktama> EXACopy looks like (more or less):
22:02 < darktama>     if (!NV30_InitSurface   (pNv, pDstPixmap))
22:02 < darktama>         FALLBACK("pDstPixmap\n");
22:02 < darktama>     NV30_SetFragmentProg    (pNv, NV30_FP_TEX0_WR);
22:02 < darktama>     NV30_TextureFromDrawable(pNv, &pSrcPixmap->drawable, 0, RepeatNone, PictFilterNearest);
22:02 < darktama>     NV30_InitVertexProg     (pNv, pDstPixmap, VTX_TEX0|VTX_POSITION);
22:02 < darktama>     if (!NV30_SetROP        (pNv, alu, planemask))
22:02 < darktama>         FALLBACK("ROP\n");
22:02 < darktama> PrepareCopy() that is
22:03 < marcheu> I think I'd hive it at some even higher level, so as to hide everything from nv04 to g70 underneath
22:03 < darktama> yup
22:03 < marcheu> but maybe that's a bad idea
22:05 < pmdata> mesa/drm package installed, what next?
22:05 < marcheu> ddx
22:05 < darktama> we really need to look at what we need, and what each card can support.. also, we should think about leveraging some of the code for, say, textured video
22:05 < marcheu> darktama: point
22:06 < darktama> I really like the idea of using the 3D engine for everything.. we can get hw-accelerated rotation for free basically... but it does have problems
22:06 < pmdata> this is nouveau/xf86-video-nouveau, right?
22:06 < marcheu> yes
22:07 < darktama> 1. I have no idea how to implement planemask with the 3D engine (though, I've never seen that fallback yet anyway)
22:07 < darktama> 2. The card doesn't like having a texture as the rendering surface at the same time (EXACopy) - so we'd have to do blits to temporaries anyway
22:08 < marcheu> hmm, that or keep the 2D engine for that
22:08 < darktama> yes, then we don't get the "free" rotation :)  but, we can implement that in other ways
22:09 < marcheu> I don't think many apps use rotation
22:09 < mjg59> Both the tablets I have are nvidia, so accelerated rotation of the desktop would be nice
22:09 < mjg59> It's something that's not offered by the binary drivers either right now
22:09 < darktama> indeed, I wouldn't mind being able to rotate one of my screens as well
22:10 < marcheu> hmm, isn't there a bit in the 2D engine doing it then ?
22:11 < darktama> we can do rotation by doing X frontbuffer rendering to an offscreen buffer.. then when it needs updating (the Refresh hooks used by the current code, for example), we can render the X frontbuffer rotated into the real framebuffer
22:11 < darktama> I think the intel driver does that
22:11 < marcheu> yup, which a real hack
22:11 < darktama> indeed
22:12 < darktama> mjg59: nvidia support accelerated rotate don't they?
22:12 < darktama> in my case, I can't use it.. because it's not supported with twinview
22:12 < marcheu> right, 2D engine doesn't seem to be able to rotate anything
22:14 < mjg59> darktama: My recollection is that it disables acceleration
22:14 < KoalaBR> ddl: Are you still working on the BIOS parsing code? Anything coming up there? (Asking for the TiNDC, as I read about your git / cvs access, but didn't find the request for it)
22:15 < darktama> mjg59: I think it's accelerated now
22:15 < darktama> " This feature is supported on GeForce2 or better hardware using
22:15 < darktama>     depth 24."
22:15 < darktama> from nvidia's readme
22:15 < mjg59> Ah, ok
22:16 < darktama> KoalaBR: in case ddl's not here anytime soon - last time I spoke to him he was still working on it, but he's had exams so it's been slow going
22:16 < pmdata> a different feature between nv10 and nv15? will have to check that
22:17 < darktama> I don't see any reason why it can't be done on nv10.. or nv4 for that matter
22:17 < KoalaBR> darktama: Ok, just wondered, read about his exams too, but as he requested an account, I thought he might be onto something - thanks for the info
22:18 < pmdata> maybe the hw is too slow
22:19 < darktama> yeah, that's a possibility
22:28 < pmdata> slower than cpu?
22:29 < darktama> I doubt it.. but I don't really know
22:30 < darktama> if it's implemented the way I said above, all you need is to render a rotated quad really
22:30 < darktama> with a texture
22:36 -!- Myrizio [n=Myrizio@host84-98.pool80104.interbusiness.it] has quit ["Goodbye Ruby Tuesday (Perl Friday)"]
22:39 -!- jkolb [n=jkolb@wsi-128-132.wsi.com] has quit ["Leaving"]
22:40 < pmdata> ouh, many warnings compiling ddx
22:42 < pmdata> ddx compiled \o/
22:43 < pmdata> what next?
22:44 < marcheu> edit /etc/X11/xorg.conf change "nv" or "nvidia" to "nouveau"
22:44 < pmdata> shouldn't I install the ddx somewhere?
22:45 < marcheu> ah, yes if it's not done yet
22:45 < marcheu> install nouveau_drv.so in /usr/lib/xorg/modules/drivers/
22:47 < KoalaBR> Is there anything left, we need help for / in (simple tasks)? Still need quadro dumps etc? I would add these task to the companion
22:47 < marcheu> KoalaBR: we need people who are not afraid of digging in the DDX code :)
22:47 < pmdata> koala> mostly stereo dumps
22:48 < pmdata> if you look at nv30 tcl, you'll see color buffer 0,1,2,3 listed
22:48 < pmdata> we need to know which is front/back and left/right
22:48 < pmdata> time to restart xorg
22:48 -!- pmdata [n=patrice@ANantes-154-1-16-166.w81-53.abo.wanadoo.fr] has quit ["Parti"]
22:48 < KoalaBR> marcheu: Users or developers? :=) I will try my hands on that after updating to Xorg 7.1
22:49 < KoalaBR> Will try to upgrade this weekend, if Gentoo doesn't mark it stable
22:49 < marcheu> developers :)
22:50 < KoalaBR> Will add that request again :)
22:52 < EdB|w_> boucman did you compile turnk last ?
22:52 < EdB|w_> it's fail
22:53 < EdB|w_> and i guess branch to
22:53 < EdB|w_> too
22:53 < EdB|w_> oups ba d chan
22:53 < EdB|w_> sorry :o)
22:57 -!- pmdata [n=patrice@ANantes-154-1-16-166.w81-53.abo.wanadoo.fr] has joined #nouveau
22:57 < pmdata> well, not successful, still missing /dev/dri/card* device nodes
22:57 < pmdata> does the previously libdrm.so should be in xorg module subdir?
22:57 < marcheu> did you install the kernel modules ?
22:58 < pmdata> hum, no
22:58 < marcheu> we don't really care about libdrm.so, you probably have it already, and we use the same one
22:58 < pmdata> ah
22:58 < marcheu> but you need nouveau.ko and drm.ko in /lib/modules/whatever/
22:59 < pmdata> these are in nouveau cvs? nouveau subdir?
23:00 < pmdata> marcheu?
23:01 < marcheu> in drm
23:01 -!- EdB|w_ [n=EdB@212.234.68.206] has quit [Read error: 104 (Connection reset by peer)]
23:01 < marcheu> cd linux-core ; make
23:01 < pmdata> can't find a kernel config file :)
23:02 < marcheu> yeah, you need kernel sources around
23:02 < pmdata> yep, I know
23:03 < pmdata> installing package...
23:05 -!- shenki [n=shenki@ppp110-122.lns4.adl4.internode.on.net] has quit [Read error: 60 (Operation timed out)]
23:06 < pmdata> arg, current kernel compiled with gcc 4.0.4, and 4.1.1 installed
23:06 < pmdata> installing gcc 4.0
23:07 < KoalaBR> pmdata: Welcome to the party :) I just updated my system from 2.6.12 to 2.6.17 and from gcc 3.3.6 to 4.1.1. It went flawlessly (*ahem*), of course :)
23:09 < KoalaBR> Ok, will be back tomorrow, bye. Darktama: Will do some tests regarding x0208 and posts result as soon as I have some :)
23:09 -!- KoalaBR [n=KoalaBR@port-83-236-12-239.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
23:11 -!- Myrizio [n=Myrizio@host180-101.pool80104.interbusiness.it] has joined #nouveau
23:12 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
23:12 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
23:14 < pmdata> hum "include/linux/posix_types.h:37: warning: division by zero" can't build drm kernel modules
23:17 < stillunknown> pmdata: if you succeed, please write down how you installed it on the wiki
23:18 < pmdata> ouch
23:18 < stillunknown> why ouch?
23:18 < pmdata> because atm it does not work :)
23:19 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has quit [Read error: 104 (Connection reset by peer)]
23:20 < pmdata> reboot
23:20 -!- pmdata [n=patrice@ANantes-154-1-16-166.w81-53.abo.wanadoo.fr] has quit ["Parti"]
23:24 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has joined #nouveau
23:33 -!- jkolb [n=jkolb@wsi-128-132.wsi.com] has joined #nouveau
23:44 -!- pmdata [i=patrice@ANantes-154-1-16-166.w81-53.abo.wanadoo.fr] has joined #nouveau
23:45 < pmdata> back to stable sarge
23:46 < pmdata> there is a problem with nouveau.ko, missing "__udivdi3" symbol, does the module uses floating point somewhere?
23:57 -!- EdB [n=EdB@ARennes-251-1-28-73.w81-250.abo.wanadoo.fr] has joined #nouveau
--- Log closed Чтв Сен 07 00:00:32 2006
