--- Log opened Чтв Сен 07 00:00:32 2006
00:02 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has quit []
00:03 -!- hanno_ [n=hanno@p54A4D2CF.dip.t-dialin.net] has quit ["Verlassend"]
00:11 < pmdata> ah, it is from nouveau_state.c that generates this call
00:17 < pmdata> "dev_priv->cmdbuf_ch_size = cb->size / nouveau_fifo_number(dev);" is the only division I see, and is done with cpu, so wtf??
00:23 < pmdata> http://www.captain.at/howto-udivdi3-umoddi3.php
00:23 < pmdata> seems a little fix is needed
00:24 -!- b33fc0d3 [n=bifter@gentoo/contributor/b33fc0d3] has joined #nouveau
00:27 < pmdata> cb is struct memblock, and field size is uint64_t, so we have a 64/32 division there
00:27 < pmdata> can someone fix it?
00:28 < pmdata> should I wait for the end of the football match? :)
00:33 < pmdata> .o0O0o.
00:34 < stillunknown> instant fixes are not likely to happen, be patient like everyone else :-)
00:34 -!- svu [n=svu@83.167.239.56] has quit [Read error: 104 (Connection reset by peer)]
00:34 < pmdata> yep, I know, but I won't test it till tomorrow
00:34 -!- svu [n=svu@83.167.239.56] has joined #nouveau
00:37 -!- mat__ [n=mat@cac94-1-81-57-151-96.fbx.proxad.net] has joined #nouveau
00:39 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has joined #nouveau
00:39 < marcheu> pmdata: I never watch football :)
00:40 < marcheu> ah, right, divs on 64 bit quatities is bad in the kernel
00:41 < marcheu> pmdata: maybe it's time to do your first drm fix ? :)
00:42 -!- mat__ [n=mat@cac94-1-81-57-151-96.fbx.proxad.net] has quit [Client Quit]
00:44 < pmdata> I leave that as an exercise for the maintainer :)
00:45 < marcheu> a bit tricky, since the maintainer should not use do_div which is not portable :)
00:46 < pmdata> yep, I wonder if the kernel has not a internal __udivdi3() because noone else noticed this
00:46 < pmdata> and my kernel would not be compiled with it
00:46 < marcheu> I'm still using my old drm, and darktama is running 64 bit
00:53 < pmdata> so is cb->size really need to be 64bit?
01:04 -!- jkolb [n=jkolb@wsi-128-132.wsi.com] has quit ["Leaving"]
01:05 -!- flex [n=flex@194.23.101.92] has joined #nouveau
01:15 < ddl> hi there!
01:17 < marcheu> hey ddl 
01:17 < marcheu> pmdata: I'll fix it
01:17 < ddl> i wonder if theres been any progress with my account request :)
01:17 < marcheu> pmdata: yes cb-> size can be 32bit, or we're somewhere 20 years ahead
01:18 < marcheu> ddl: was there ? I don't remember the bug #
01:19 < ddl> 8109 ... no replies after the two replies you did
01:19 < marcheu> I'll let the a couple of days and bug the wranglers. do you have any code waiting for that ?
01:20 < ddl> no hurry... 
01:20 < ddl> no :/
01:20 < ddl> ive been kind of busy with school.. been looking at some stuff from time to time, but no progress that has yielded any code :/
01:28 -!- sturmflut [n=sturmflu@2001:6f8:992:1337:213:d4ff:feaa:8a9f] has quit [Remote closed the connection]
01:31 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
01:37 -!- Duke` [n=gnu@ANantes-251-1-85-95.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
01:38 -!- Duke` [n=gnu@ANantes-251-1-86-16.w86-203.abo.wanadoo.fr] has joined #nouveau
01:42 -!- pmdata [i=patrice@ANantes-154-1-16-166.w81-53.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
01:54 -!- Duke` [n=gnu@ANantes-251-1-86-16.w86-203.abo.wanadoo.fr] has quit ["Fatal signal: Segmentation Fault"]
01:56 -!- tibbs|h is now known as tibbs
02:09 < marcheu> hmm there's something we don't do right on restore, I can only start X once, the second time it timeouts
02:09 < darktama> that's odd..
02:10 < marcheu> was anythin like that changed recently ?
02:10 < darktama> hmm, nothing that I think could cause that
02:11 < marcheu> recently means 2 weeks, it's with the nv18
02:11 < darktama> you could bisect and find the bad patch
02:12 < marcheu> I'm not even sure it didn't happen before...
02:12 < darktama> ah, well that doesn't help there :)
02:14 < marcheu> let me try again, maybe that was some remains from a previous lockup
02:15 -!- EdB [n=EdB@ARennes-251-1-28-73.w81-250.abo.wanadoo.fr] has quit [Remote closed the connection]
02:15 -!- EdB [n=EdB@ARennes-251-1-28-73.w81-250.abo.wanadoo.fr] has joined #nouveau
02:16 < stillunknown> marcheu: i have experiences similar things
02:16 < stillunknown> but in my case if doesn't unrender the menu's and some  windows are not rendered properly at all
02:17 < stillunknown> r/experiences/experienced
02:17 -!- Unbeliever [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
02:18 < marcheu> yep, fails each time
02:19 < marcheu> stillunknown: it works the first time for you ?
02:19 < stillunknown> yes
02:19 < marcheu> what card ?
02:19 < stillunknown> nv43
02:19 < marcheu> since when does it do that ?
02:20 < stillunknown> this is a guesstimate
02:20 < stillunknown> 1 week, maybe 1.5
02:20 < marcheu> ok, I suppose a bissection is in order, then
02:21 < stillunknown> i didn't really "notice" it the first, said something in in irc a day or two ago if anyone had noticed anything like it
02:21 < stillunknown> i also have a hint
02:22 < stillunknown> rmmod nouveau drm && modprobe nouveau fixes it
02:22 < stillunknown> which hints at the drm
02:22 < marcheu> ah, cool, thanks
02:22 < marcheu> I think that'll wait tomorrow though
02:23 < darktama> ah, that's probably why I don't see the bug
02:23 < stillunknown> why?
02:23 < darktama> my "nouveau" script to start X, unloads nouveau.ko/nvidia.ko then insmod's nouveau.ko before startx
02:24 < stillunknown> as long as either marcheu or you can reproduce it, it will get fixed, since it's a regression somewhere
02:25 < darktama> ok, I can definitely reproduce
02:25 < darktama> no lockup, but very bad rendering
02:26 < stillunknown> stripe menu's :-)
02:26 < darktama> it looks like the hw-accelerated bits never get drawn, only X sw rendering gets through
02:34 < darktama> marcheu: when/if is memory allocated by the drm itself freed?
02:35 < marcheu> darktama: hahaha
02:35 < marcheu> *cough*
02:35 < darktama> heheh, I guess it's not then :P
02:36 < marcheu> but I'm sure the though crossed my ming when I wrote it !
02:36 < marcheu> hmm, so if we want to be clean, we have to wait for eveyrthing to idle before freeing the fifo ramù
02:38 < marcheu> darktama: btw I still don't see your name on top of the files, with the copyright
02:38 < marcheu> darktama: we have to have them, or we might have issues later
02:39 < darktama> ok, I'll add them at the same time I fix this problem.. I could hack around it for now since we don't use multiple FIFOs, but I'd rather do it properly
02:39 < marcheu> you mean the wait for idle ?
02:40 < marcheu> or what do you want to hack ?
02:40 < darktama> no, I think that on a second startx - the memory assigned to the cmdbuf is allocated again for something else
02:41 < darktama> basically, hacking out the if (dev_priv->cmdbuf_alloc) in fifo_init() so dma_init() is called every time
02:42 < marcheu> hmm
02:42 < stillunknown> out of curiosity, isn't it possible to implement multiple fifo's atm?
02:42 < marcheu> no, we need the fifo switching code
02:42 < marcheu> which I'm working on atm
02:42 < darktama> if someone figures out context switching :)
02:42 < darktama> any luck getting CTX_SWITCH intr?
02:42 < marcheu> I just started :)
02:43 < darktama> started working on it? or started getting them?
02:43 < marcheu> working
02:43 < darktama> ah, I'd prefer if you answered the other option :P
02:47 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has quit [Remote closed the connection]
02:55 < marcheu> hmm the irq code isn't even called
02:56 < marcheu> wasn't nouveau_irq.c stuff hooked ?
02:59 < darktama> the call to init it is #if 0'd out in nv_dri.c
03:01 < marcheu> what does the stuff in nv_hw.c do with the irq ?
03:02 < darktama> nv_dri.c calls drmCtlInstHandler(), which tells the drm to use the IRQ hooks
03:03 < darktama> irq_preinst/irq_postinst get called sometime during that call
03:03 < darktama> or do you mean the if (pNv->IRQ) stuff in nv_hw.c?
03:04 < marcheu> yup, that stuff
03:05 < marcheu> this is the obfuscated one :)
03:05 < darktama> it's there to stop the ddx touching the various IRQ enable/status regs
03:05 < marcheu> ah ok
03:05 < darktama> probably useless to have those checks anyway, they get clobbered by (I think) the powerdown/powerup of PGRAPH and PFIFO
03:07 < marcheu> so, what were you trying to trigger the interrupt ?
03:07 < marcheu> do you have some code handy ?
03:08 < marcheu> ok, I'll write a hack then :)
03:09 < darktama> nope, but you should be able to confirm interrupts are working by enabling the VBLANK ones (commented out in the drm)
03:14 < marcheu> hey, I want context switching interrupts :)
03:15 < darktama> hehe, yeah.. there's quite a few missing from the list
03:16 < darktama> we probably want a few more of the FIFO ones too, like runout
03:16 < marcheu> I was thinking we could hack around the proprietary driver 
03:16 < marcheu> the irq handler has to go through the kernel at some point, where we can catch it
03:17 < marcheu> anyway, time to setup a second fifo and have it run
03:19 < darktama> there's probably some drm bugs relating to that.. it's unlikely Xorg will survive a second process doing FIFO_INIT
03:19 < marcheu> the unused drm_nouveau_fifo_init_t fifo; is surely interesting
03:20 < darktama> hm?
03:20 < marcheu> well, we have to
03:20 < marcheu> in NVInintDma
03:20 < marcheu> any idea why it should crash ?
03:20 < darktama> ah, I moved that into pNv->fifo at some point
03:21 < darktama> it'll crash because the drm will automatically do PFIFO_INIT with values for the second FIFO
03:21 < darktama> and I think, it wont set FIFO 0 active again after the second FIFO is closed
03:21 < marcheu> hmm, so I have to init the 2nd fifo first :)
03:21 < marcheu> (and the first fifo second)
03:22 < darktama> the entire nouveau_pfifo_init() is dodgy really..
03:22 < darktama> it's the Xorg code hacked enough so I could start Xorg using channel!=0
03:23 < darktama> s/Xorg/nv ddx/
03:23 < marcheu> to me it looks like it only setups the fifo 0 as defaut
03:23 < marcheu> or whatever fifo comes last
03:24 < darktama> it sets up whatever FIFO is in dev_priv->cur_fifo.. perhaps you should hardcode that to 0
03:25 < marcheu> well, it should work as is
03:26 < marcheu> I'll have the ddx call FIFO_INIT twice in a row, and use the result from the 2nd one
03:26 < marcheu> that might work
03:27 < marcheu> and then some user space hack to write fifo0 regs
03:27 < marcheu> and see if that triggers anything
03:27 < darktama> oh, I have a dodgy userspace app that allocs a fifo btw
03:27 < marcheu> oh, good
03:28 < darktama> one sec, I'll find it
03:28 < marcheu> maybe we shoudl have some test_apps module incvs
03:31 < marcheu> yupà, got a PFIFO interrupt
03:31 < marcheu> and then of course a lockup
03:31 -!- ag [i=ag@caladan.roxor.cx] has quit ["BRB"]
03:31 < marcheu> so you can get interrupts by simply having a second fifo
03:32 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
03:32 < darktama> what interrupt was it?
03:32 < marcheu> PFIFO
03:32 < darktama> yeah, which PFIFO one
03:32 < marcheu> hmm error :(
03:33 < darktama> ah, that doesn't surprise me..
03:33 < marcheu> did you get that as well ?
03:34 < darktama> I can't recall, last time I looked at multiple contexts was ages ago
03:38 -!- EdB [n=EdB@ARennes-251-1-28-73.w81-250.abo.wanadoo.fr] has quit ["Konversation terminated!"]
03:39 < marcheu> but why would it happen after something like 5 seconds ?
03:40 < darktama> no idea
03:40 < darktama> http://members.iinet.net.au/~darktama/nouveau_demo.tbz2
03:41 < marcheu> nv10reg.h says cache_error
03:41 < darktama> yup, I'd blame pfifo_init() when it does the setup for the second FIFO..
03:42 < marcheu> but you said you could setup the second fifo for the ddx, right ?
03:42 < marcheu> does that work with the current setup ?
03:42 < darktama> I haven't tried, but it should work fine.. it just fails when there are more than one FIFO
03:44 < darktama> yup, it still works
03:55 -!- ag [i=ag@caladan.roxor.cx] has quit []
03:57 -!- ag [i=ag@caladan.roxor.cx] has joined #nouveau
04:00 < darktama> oh wow, luckily the PFIFO_RAMHT val that the drm sets up never actually took effect.. it was wrong
04:11 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has joined #nouveau
04:57 -!- hiyuh_work [n=hiyuh@ZK138220.ppp.dion.ne.jp] has joined #nouveau
07:56 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
09:11 -!- tibbs is now known as tibbs|h
09:27 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has joined #nouveau
09:29 -!- Myrizio [n=Myrizio@host180-101.pool80104.interbusiness.it] has quit [Read error: 113 (No route to host)]
10:03 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
11:28 -!- EdB [n=EdB@ARennes-251-1-148-232.w86-214.abo.wanadoo.fr] has joined #nouveau
12:01 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
12:08 -!- Duke` [n=gnu@ANantes-251-1-86-16.w86-203.abo.wanadoo.fr] has joined #nouveau
12:41 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has quit [Read error: 60 (Operation timed out)]
14:22 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
15:32 -!- blx [n=x@h19n7c1o1028.bredband.skanova.com] has joined #nouveau
17:06 -!- shaAway is now known as __sha__
17:09 -!- jkolb [n=jkolb@wsi-128-132.wsi.com] has joined #nouveau
17:44 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
18:00 < darktama> stillunknown: ok, the fix for the "second start of X" issue is in drm
18:00 < darktama> marcheu: when you get a chance, could you check if this also fixes your lockup problem
18:04 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has quit [Remote closed the connection]
18:15 -!- etzel [n=thisnuke@west-193.rcn.NMT.EDU] has joined #nouveau
18:20 -!- Myrizio [n=Myrizio@host17-102.pool80104.interbusiness.it] has joined #nouveau
18:48 < jkolb> how hard would it be to add egl support to nouveau?  Does it require a 3d driver or is it just initialization stuff?
18:48 < darktama> you need a 3D driver
18:49 -!- hiyuh_work is now known as hiyuh
18:50 < jkolb> ah ok
18:54 -!- Gusar [n=uros@e-4.vc-graz.ac.at] has joined #nouveau
18:55 < Gusar> hello
18:55 < Gusar> I compiled nouveau today...and X crashes after a few seconds
18:55 < Gusar> with: DMA queue hang: dmaPut=30, current=0, status=0
18:58 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings change in the drift of time. (sung by Ian Anderson)"]
19:00 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has joined #nouveau
19:02 < stillunknown> darktama: fix works for me
19:09 < darktama> ah good :)
19:09 < darktama> Gusar: what card?
19:09 < Gusar> Geforce go 6600 (nv43)
19:10 < darktama> ok, this is the second report I know of where a GO card doesn't work properly :(
19:10 < darktama> does xf86-video-nv work?
19:11 < Gusar> yes
19:12 < stillunknown> it never worked for you?
19:23 < darktama> Gusar: is it just EXA that doesn't work, or XAA too?
19:24 < Gusar> didn't try xaa, will do now
19:28 < Gusar> same error, just different number - dmaPut=42
19:29 < darktama> thanks
19:29 < darktama> I'll try and get around to looking at what we do differently to nv on those cards, unless someone with hw beats me to it
19:30 -!- Unavowed [n=silent@13.t6.ds.pwr.wroc.pl] has joined #nouveau
19:38 -!- swany [n=swany@81-234-181-143-o1108.tbon.telia.com] has joined #nouveau
19:49 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
20:15 -!- maxtoo [n=maxtoo@berryx.homedns.org] has joined #nouveau
20:44 < marcheu> jkolb: you need both a 3D driver and a mini 2D driver 
20:44 -!- K [n=hazel@84-16-252-194.internetserviceteam.com] has joined #nouveau
21:03 < jkolb> marcheu: thanks
21:04 < marcheu> the 2D driver is the thing in dri/radeon/server/*
21:04 < marcheu> it's a kind of a mini DDX
21:04 < phh> radeon ?
21:04 < marcheu> which does mode setting, and such
21:04 < phh> something "working" for 3D on nouveau ?
21:05 < marcheu> hhmm actually that's for miniglx, not sure where it lies for EGL, but it's the same code really
21:05 < jkolb> marcheu: interesting.  could the mini 2d driver be started now then? I wouldn't mind taking a crack at it now that i have time... still waiting on an internet connection for home though
21:05 < marcheu> we need a 3D driver for it to be of any usefulness...
21:06 < marcheu> usually that mini 2D driver is done from the DDX code minus the 2D acceleration
21:07 < marcheu> all that sounds like an excuse to get a Go card  :)
21:09 < jkolb> marcheu: ahhh. okay
21:13 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit [Remote closed the connection]
21:15 < jkolb> it looks like the egl move is pretty much dead anyway
21:15 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has joined #nouveau
21:24 -!- stringfellow [n=stringfe@ip56503c9f.direct-adsl.nl] has joined #nouveau
21:30 -!- pmdata [n=patrice@ANantes-154-1-77-57.w86-199.abo.wanadoo.fr] has joined #nouveau
21:31 < pmdata> hello
21:31 -!- hiyuh [n=hiyuh@ZK138220.ppp.dion.ne.jp] has quit ["Leaving"]
21:32  * pmdata running nouveau xorg driver \o/
21:32 < pmdata> now, dri module missing: (EE) AIGLX error: dlopen of /usr/lib/dri/nouveau_dri.so failed
21:33 < EdB> pmdata, i run it since 1 week at least :o)
21:33 < EdB> pmdata, that is "normal"
21:33 < marcheu> pmdata: you have to write it, that's why :)
21:33 < pmdata> this is the 3d module missing, I guess?
21:33 < marcheu> yes
21:34 < pmdata> before doing that, is there anything I should do to test the current 2d driver?
21:35 < pmdata> playing video using xv and mplayer?
21:36 < marcheu> well, it should work, but yes
21:41 < pmdata> hum I should try another video, I see garbage on the one I tried
21:56 -!- mjg59 [n=mjg59@cavan.codon.org.uk] has quit []
21:57 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has joined #nouveau
21:58 < pmdata> ok, seems to work
21:59 < phh> pmdata, it works for everyone who tried it so why not you ? :)
21:59 -!- mjg59 [n=mjg59@cavan.codon.org.uk] has joined #nouveau
22:00 < pmdata> maybe I would trigger a bug/crash
22:00 < pmdata> glxgears is so slow
22:00 < phh> pmdata, bah it's 100% soft render
22:01 < pmdata> it should be much faster, even if running in software
22:01 < phh> much faster than what ?
22:01 < phh> on vesa ?
22:02 < pmdata> faster using mesa on a 2d accelerated driver
22:02 < phh> yes it should
22:06 -!- pmdata [n=patrice@ANantes-154-1-77-57.w86-199.abo.wanadoo.fr] has quit ["Parti"]
22:16 -!- pmdata [n=patrice@ANantes-154-1-77-57.w86-199.abo.wanadoo.fr] has joined #nouveau
22:19 < pmdata> back to stable sarge
22:19 < pmdata> glxgears works normally only for 1-2 seconds, just after X server has been started
22:19 < pmdata> then it crawls, like it did after I played a video
22:24 < pmdata> hum, back to nvidia driver, glxgears barely does 1000 fps (should be ~1500) and my cpu still has a high load
22:24 < pmdata> there is something else in nouveau driver that does not suit gpu
22:24 < pmdata> time to switch off
22:24 -!- pmdata [n=patrice@ANantes-154-1-77-57.w86-199.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.11"]
22:35 -!- pmdata [i=patrice@ANantes-154-1-77-57.w86-199.abo.wanadoo.fr] has joined #nouveau
22:36 < pmdata> after a power off, system is back to normal speed
22:36 < pmdata> maybe bios boots the card with safe/slow clocks for gpu and mem
22:36 < pmdata> then the nvidia driver set them to higher speeds
22:36 < pmdata> I should have tried nvclock -i with nouveau driver
22:51 -!- predatorfreak [n=predator@ppp-70-227-206-52.dsl.sfldmi.ameritech.net] has quit ["<blank>"]
22:54 < marcheu> pmdata: the clocks might be different, but what is your point when provinng that ?
22:59 < marcheu> darktama: I don't understand why git shows your changes when I do git status -v
22:59 < marcheu> any idea ?
23:00 < marcheu> ah well, I'll repull a full repo
23:00 < marcheu> and sit on my changes
23:04 -!- maxtoo [n=maxtoo@berryx.homedns.org] has quit [Remote closed the connection]
23:08 -!- stillunknown [n=stillunk@82-168-177-167.dsl.ip.tiscali.nl] has quit ["Words get written, words get twisted, old meanings change in the drift of time. (sung by Ian Anderson)"]
23:26 -!- jkolb [n=jkolb@wsi-128-132.wsi.com] has quit ["Leaving"]
23:34 < pmdata> marcheu> that nouveau driver could set the clocks faster
23:34 < pmdata> and it survives a reset
23:34 < pmdata> besides booting the card using bios, nouveau does not change any clock setting, right?
23:39 -!- Duke` [n=gnu@ANantes-251-1-86-16.w86-203.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
23:39 -!- Duke` [n=gnu@ANantes-251-1-94-170.w86-203.abo.wanadoo.fr] has joined #nouveau
23:41 < marcheu> no it doesn't
23:41 < marcheu> but clocks don't really matter for now
23:41 < marcheu> sure in the long run, we'd like to have the at the right frequency
23:41 < marcheu> but what I was saying, is that clock changes don't explain the speed difference you saw
23:42 < marcheu> the nvidia driver does 1500 fps at glxgears because it's hw accelerated, that's all
23:42 < marcheu> clock speed only accounts for a fraction of that
23:43 -!- KoalaBR_ [n=KoalaBR@port-83-236-12-201.dynamic.qsc.de] has joined #nouveau
23:45 < pmdata> and it does barely 1000 after a reboot and having the nouveau driver used
23:45 < KoalaBR_> marcheu: renouveau fails with "FIFO channel couldn't be detected. PLEASE REPORT (0x2504 is 40000003/40000003)" in 8 bit mode. Is that a problem?
23:46 < KoalaBR_> Setting the video mode fails too, I guess I can only test in 16 and 24 bpp
23:47 < KoalaBR_> Bah, I need to go back to a saner bpp
23:48 -!- KoalaBR_ [n=KoalaBR@port-83-236-12-201.dynamic.qsc.de] has quit [Remote closed the connection]
23:48 < marcheu> yeah, there's no opengl in 8 bit mode :)
23:48 < marcheu> no opengl -> no need for a fifo :)
23:49 < marcheu> bbl
23:50 -!- KoalaBR [n=KoalaBR@port-83-236-12-201.dynamic.qsc.de] has joined #nouveau
23:51 < KoalaBR> marcheu: Understood. Nvidia blob fails to set a depth of 32 however
23:53 < pmdata> this is 24 (for a 32bits color buffer)
23:55 < KoalaBR> So all I can report to darktama are to modes for 0x0208:
23:56 < KoalaBR> darktama:  NV30_TCL_PRIMITIVE_3D      [0x0208/4] = 0x00000145 (for depth 24)   and    NV30_TCL_PRIMITIVE_3D      [0x0208/4] = 0x00000143 (Depth 16) size of the desktop doesn't matter (as expected)
23:57 < KoalaBR> Will be back this weekend and try to upgrade to Xorg 7.1. If you need anything else, let me know.
23:58 -!- KoalaBR [n=KoalaBR@port-83-236-12-201.dynamic.qsc.de] has quit ["ChatZilla 0.9.61 [Mozilla rv:1.7.13/20060417]"]
23:58 -!- phh [n=phh@4be54-3-82-228-187-43.fbx.proxad.net] has quit ["Quitte"]
--- Log closed Птн Сен 08 00:00:33 2006
