--- Log opened Thu Jan 14 00:00:02 2010
--- Day changed Thu Jan 14 2010
00:00 -!- rhodan [n=quassel@81.62.94.77] has quit [Read error: 60 (Operation timed out)]
00:00 -!- MacSlow [n=mirco@unaffiliated/macslow] has joined #nouveau
00:01 -!- michup86 [n=michup86@106-158.echostar.pl] has joined #radeon
00:01 -!- scottfang [i=de42ee45@gateway/web/freenode/x-bmpafqkhxuwocyts] has quit []
00:02 -!- scottfang [i=de42ee45@gateway/web/freenode/x-lhpwwikdgzivcxzo] has joined #dri-devel
00:02 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] has quit ["Ex-Chat"]
00:06 -!- GNU_D [n=GNU_D@77.28.197.12] has joined #Radeon
00:07 -!- desti [n=desti@TL-224-192.fernuni-hagen.de] has quit [Read error: 113 (No route to host)]
00:08 -!- Eddi|zuHause3 [n=johekr@84.183.118.222] has joined #radeon
00:08 -!- Eddi|zuHause2 [n=johekr@p54B776DE.dip.t-dialin.net] has quit [Remote closed the connection]
00:08 -!- xming [n=xming@gentoo/user/xming] has quit [Read error: 60 (Operation timed out)]
00:08 -!- xming [n=xming@gentoo/user/xming] has joined #radeon
00:08 -!- desti [n=desti@TL-224-192.fernuni-hagen.de] has joined #radeonhd
00:08 #radeon: < michup86> what did i missed to enable kms?kernel 6.31-r6,  created /etc/modpobe.d/radeon.conf  with option radeon modset=1, in grub.conf zapped vesafb related staff
00:09 #radeon: < michup86> do i need to disable vesafb in kernel as well to make it go?
00:09 #radeon: <@airlied> michup86: something loads radeon?
00:10 #radeon: < GNU_D> Hi, I still have system lock down, when I leave the computer on for a while (like overnight) in the morning or several hours later it's frozen, I think is the power control or something, it's overburning the card so it locks or something, how can I set the power option to safe energy or something, I can see /var/run/acpid.socket is missing in Xorg.0.log, I really need to fix this, cause I keep losing any unsaved codes :(.
00:10 -!- zhasha [n=zhasha@0xbcb1575f.virnqu1.dynamic.dsl.tele.dk] has quit [Read error: 113 (No route to host)]
00:10 -!- zhasha [n=zhasha@0xbcb1575f.virnqu1.dynamic.dsl.tele.dk] has quit [Read error: 113 (No route to host)]
00:10 #radeon: < GNU_D> (for my radeon 9200SE)
00:11 #radeon: < hifi> GNU_D: if it's AGP, try forcing PCI mode
00:11 #radeon: < michup86> youre saying that i have to load radeon module just after grub start? that make sense how can i do that?
00:11 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has joined #radeon
00:11 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has joined #radeonhd
00:12 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has quit [Read error: 113 (No route to host)]
00:13 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Read error: 54 (Connection reset by peer)]
00:13 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
00:13 -!- jedahan [n=jedahan@ool-45714877.dyn.optonline.net] has quit [Read error: 113 (No route to host)]
00:16 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] has joined #radeon
00:16 #radeon: < GNU_D> michup86: you have to add the module in the kernel startup modules
00:16 -!- mo3sizlak [n=m0eSizla@pool-98-117-162-201.bflony.fios.verizon.net] has quit ["Leaving"]
00:16 -!- keltor is now known as keltor|sleep
00:17 #radeon: < GNU_D> hifi: I forgot, pci mode was when I comment the Option "AGPMode" "8" in xorg.conf ?
00:18 #radeon: < hifi> GNU_D: no, Option "BusType" "PCI"
00:19 #radeon: < GNU_D> hifi: so no 3D acceleration will be available ?
00:19 #radeon: < chithead> Jonimus: 2.6.32.3 is ok. 2.6.32.2 suffers from http://marc.info/?l=dri-devel&m=126137027403059&w=2
00:19 #radeon: < hifi> GNU_D: it will, it's just a bit slower maybe
00:20 #radeon: < GNU_D> hifi: slower than slow, now it's slow
00:21 #radeon: < GNU_D> hifi: which Options are not compatible with BusType PCI ?
00:22 #radeon: < xming> from my subjective guestimate it's about 1/4th of the bustype AGP speed
00:22 -!- lumi [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
00:22 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
00:23 #radeon: <@airlied> for a 4x AGP that wold be correct ;-)
00:24 #radeon: < GNU_D> in Bios I switched it to 8x
00:25 -!- cornair [i=d9534d71@gateway/web/freenode/x-zvthwvabnthaszdi] has joined #radeon
00:25 #radeon: < GNU_D> ok, got to to test it.
00:25 -!- GNU_D [n=GNU_D@77.28.197.12] has quit ["leaving"]
00:26 -!- papegaaij [i=hidden-u@wcoe-60.r-195-35-227.atwork.nl] has joined #nouveau
00:26 #radeon: < xming> airlied: yeap, my card was running @ 4x and with PCI mode it was way slower (about 1/4th)
00:27 #radeon: < xming> which is strange because the card and chipset can do 8x
00:27 -!- lumi [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Read error: 104 (Connection reset by peer)]
00:29 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
00:29 #radeon: <@airlied> xming: its AGP cards and chipsets lie
00:33 -!- spuddweb [n=spuddweb@c-24-147-245-45.hsd1.ma.comcast.net] has quit [Remote closed the connection]
00:33 -!- GNU_D [n=GNU_D@77.28.197.12] has joined #Radeon
00:33 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
00:34 #radeon: < GNU_D> hifi: it was so slow that Blender didn't even start properly, I could see the window manager decoration on top and traparent window and than it lock down everything.
00:36 #radeon: < GNU_D> transparent*
00:36 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has quit ["Leaving."]
00:36 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has quit ["Leaving."]
00:37 #radeon:  * GNU_D sorry, my keyboard is full of sun flower waste, and the keys are sticked together :D.
00:37 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
00:38 #radeon: < xming> airlied: I forced both kms and X to 8x now, disabled fastwrite, seems stable, is it recommend?
00:39 -!- stikonas [n=and@wesnoth/translator/stikonas] has joined #radeon
00:41 -!- Gusar [n=Gusar@m-162.vc-graz.ac.at] has quit ["leaving"]
00:42 -!- scottfang [i=de42ee45@gateway/web/freenode/x-lhpwwikdgzivcxzo] has left #dri-devel []
00:42 -!- zhasha_ [n=zhasha@0xbcb1575f.virnqu1.dynamic.dsl.tele.dk] has quit [Remote closed the connection]
00:42 -!- zhasha_ [n=zhasha@0xbcb1575f.virnqu1.dynamic.dsl.tele.dk] has quit [Remote closed the connection]
00:46 -!- twnqx [n=charlie@109.82.55.179] has joined #radeon
00:46 #radeon: < Tommeh> GNU_D: Sunflower waste? Did you spill oil on your keyboard? %)
00:52 #radeon: < GNU_D> Tommeh: no, sun flower, how do you call the outer layer of the sunflower, the black one thing ?
00:52 #radeon: < GNU_D> I got it, shell
00:52 -!- nolan [n=nolan@71.198.47.97] has quit [Read error: 113 (No route to host)]
00:52 -!- nolan [n=nolan@71.198.47.97] has quit [Read error: 113 (No route to host)]
00:53 #radeon: < GNU_D> Tommeh: so, sunflower shells all over the keyboard, do you understand now :D ?
00:54 -!- ossman [n=drzeus@alcatraz.cendio.se] has joined #radeon
00:55 #radeon: < xming> you live under a sun flower plant?
00:56 -!- michup86 [n=michup86@106-158.echostar.pl] has quit [Remote closed the connection]
00:57 -!- tavl_ [n=tavl@189.70.204.57] has quit [Remote closed the connection]
00:57 #radeon: < Tommeh> GNU_D: seeds, I think :)
00:57 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
00:57 #radeon: < Tommeh> But yes, I see what you mean :)
00:58 #radeon: < Tommeh> Do you eat seeds or do you have a plant? :P
00:58 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
00:58 #radeon: < lkro> MostAwesomeDude: yes, it works fine now. Thanks.
00:58 -!- farbing [n=farbing@141.18.176.98] has joined #radeon
00:58 -!- farbing [n=farbing@141.18.176.98] has joined #dri-devel
01:00 -!- farbing [n=farbing@141.18.176.98] has quit [Remote closed the connection]
01:00 -!- farbing [n=farbing@141.18.176.98] has quit [Remote closed the connection]
01:00 #radeon: < hnsr> anyone else still getting a strange dark screen gamma/brightness when running ioquake3?
01:00 -!- Toksyuryel [n=toksybox@c-71-231-52-36.hsd1.wa.comcast.net] has quit ["And the ship's captain learned that faith is not enough, for faith is blind by nature. Life needs insight. It is the dead, an]
01:00 #radeon: < hnsr> ive been getting this on my r700 card for a while
01:01 #radeon: < hnsr> ioquake3 has some gamma/brightness console settings but none of those seem to have any effect
01:02 #radeon: < lkro> MostAwesomeDude: wait a sec. Wrong test. No, it's not. It's slow like my first try. let mi take a look...
01:05 -!- Lutz__Ifer [i=Lutz@p549DC5B5.dip.t-dialin.net] has joined #radeon
01:05 -!- Zajec3 [n=opera@77-253-200-80.ip.netia.com.pl] has joined #radeon
01:05 -!- Zajec3 [n=opera@77-253-200-80.ip.netia.com.pl] has joined #nouveau
01:06 #radeon: < Zajec3> taiu: wow, that last patch made something pretengind to be letters being displayed :)
01:06 -!- stikonas [n=and@wesnoth/translator/stikonas] has quit ["Konversation terminated!"]
01:06 -!- stikonas_ [n=and@wesnoth/translator/stikonas] has joined #radeon
01:07 #radeon: < Zajec3> taiu: before last patch I just got empty space
01:08 -!- Lutz_Ifer [i=Lutz@p549DC9F1.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]
01:08 #radeon: < lkro> MostAwesomeDude: fixed -> http://pastebin.com/d1bf15014
01:08 -!- Welsh_Dwarf [n=quassel@ip-11.net-82-216-143.rev.numericable.fr] has joined #nouveau
01:10 -!- stikonas_ is now known as stikonas
01:12 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
01:12 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
01:13 #radeon: < GNU_D> Tommeh: no, I just eat "seeds" a lot :D.
01:14 -!- amarks [n=quassel@124-168-147-98.dyn.iinet.net.au] has quit [Remote closed the connection]
01:15 -!- drago01 [n=linux@chello062178124135.3.13.univie.teleweb.at] has joined #nouveau
01:16 -!- mokoloko [n=zxczx@dsl-hkimmlgw8-fe15f800-197.dhcp.inet.fi] has joined #radeon
01:22 -!- lkro [n=lkro@16-mo6-4.acn.waw.pl] has quit ["WeeChat 0.2.6.1"]
01:22 -!- lkro [n=lkro@16-mo6-4.acn.waw.pl] has joined #radeon
01:22 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
01:22 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
01:22 -!- vital [n=vital@c-8490e655.024-3-73766c1.cust.bredbandsbolaget.se] has quit [Remote closed the connection]
01:25 -!- fab [n=bellet@monkey.creatis.insa-lyon.fr] has joined #dri-devel
01:27 -!- fmarl [n=francesc@151.62.20.220] has joined #nouveau
01:27 -!- ssvb [n=ssvb___@viktor.cosmicparrot.net] has joined #radeon
01:30 -!- ttlogic [n=timl@disc-vdh12.disc.utwente.nl] has joined #nouveau
01:31 -!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
01:32 -!- lb__3 [n=lb__3@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 110 (Connection timed out)]
01:32 -!- lb__3 [n=lb__3@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 110 (Connection timed out)]
01:34 -!- vital [n=vital@c-8490e655.024-3-73766c1.cust.bredbandsbolaget.se] has joined #nouveau
01:35 -!- molgrum [n=molgrum@h-188-194.A189.priv.bahnhof.se] has joined #nouveau
01:36 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-uzvypjvgnutjixsc] has quit [Ping timeout: 180 seconds]
01:36 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-uzvypjvgnutjixsc] has quit [Ping timeout: 180 seconds]
01:37 -!- maligor [n=maligor@a85-156-209-40.elisa-laajakaista.fi] has quit [Remote closed the connection]
01:38 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
01:39 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
01:41 -!- rib [n=bob@cpc1-hem13-0-0-cust634.lutn.cable.ntl.com] has joined #dri-devel
01:41 -!- rib1 [n=bob@cpc1-hem13-0-0-cust634.lutn.cable.ntl.com] has joined #dri-devel
01:41 -!- rib1 [n=bob@cpc1-hem13-0-0-cust634.lutn.cable.ntl.com] has quit [Remote closed the connection]
01:45 -!- idletask [n=fg@pas75-3-82-235-191-170.fbx.proxad.net] has joined #nouveau
01:45 #nouveau: < idletask> Hello
01:47 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
01:48 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
01:51 #radeon: < adamk> soreau: Sorry.  http://68.45.22.62/output.png
01:52 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
01:52 -!- fmarl [n=francesc@151.62.20.220] has quit ["Sto andando via"]
01:54 -!- fredrikh [n=fredrik@kde/fredrik] has quit [Excess Flood]
01:54 -!- fredrikh [n=fredrik@kde/fredrik] has joined #radeon
01:54 -!- erghezi [n=quassel@213.207.221.97] has quit ["No Ping reply in 180 seconds."]
01:55 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
01:55 -!- erghezi [n=quassel@213.207.221.97] has joined #nouveau
01:55 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
02:00 #radeon: < dileX_> MostAwesomeDude: thx for "radeong: Change DRI driver name to radeong."
02:00 -!- idletask [n=fg@pas75-3-82-235-191-170.fbx.proxad.net] has quit [Read error: 60 (Operation timed out)]
02:01 -!- alanward [n=Alan@c-24-9-70-113.hsd1.co.comcast.net] has joined #dri-devel
02:02 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
02:03 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
02:05 -!- dmb [n=Dmb@unaffiliated/dmb] has quit [Connection timed out]
02:05 -!- dmb [n=Dmb@unaffiliated/dmb] has quit [Connection timed out]
02:10 -!- factor [n=factor@ip70-189-85-183.ok.ok.cox.net] has joined #radeon
02:11 -!- drago01 [n=linux@chello062178124135.3.13.univie.teleweb.at] has quit [Remote closed the connection]
02:12 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Read error: 104 (Connection reset by peer)]
02:12 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #nouveau
02:12 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #radeon
02:14 -!- rib1 [n=bob@92.40.33.239.sub.mbb.three.co.uk] has joined #dri-devel
02:15 -!- fmarl [n=francesc@151.62.20.220] has joined #nouveau
02:15 -!- rib [n=bob@cpc1-hem13-0-0-cust634.lutn.cable.ntl.com] has quit [Read error: 110 (Connection timed out)]
02:19 -!- alanward [n=Alan@c-24-9-70-113.hsd1.co.comcast.net] has quit [Read error: 104 (Connection reset by peer)]
02:22 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
02:22 -!- GNU_D_ [n=GNU_D@77.28.196.142] has joined #Radeon
02:22 -!- mart_ [n=mart@125-238-22-88.jetstream.xtra.co.nz] has joined #radeon
02:22 -!- mart_ [n=mart@125-238-22-88.jetstream.xtra.co.nz] has joined #radeonhd
02:22 -!- mart_ [n=mart@125-238-22-88.jetstream.xtra.co.nz] has left #radeon ["Leaving"]
02:23 -!- GNU_D [n=GNU_D@77.28.197.12] has quit [Nick collision from services.]
02:23 -!- GNU_D_ is now known as GNU_D
02:24 -!- rib1 [n=bob@92.40.33.239.sub.mbb.three.co.uk] has quit ["Leaving."]
02:24 -!- rib [n=bob@92.40.33.239.sub.mbb.three.co.uk] has joined #dri-devel
02:25 -!- rib [n=bob@92.40.33.239.sub.mbb.three.co.uk] has quit [Client Quit]
02:25 -!- rib [n=bob@92.40.33.239.sub.mbb.three.co.uk] has joined #dri-devel
02:26 -!- RSpliet [n=roy@53537511.cable.casema.nl] has joined #nouveau
02:30 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has joined #radeon
02:32 -!- SunTzuTech [n=bent@ip68-100-74-234.dc.dc.cox.net] has joined #radeonhd
02:33 -!- Sarvatt [n=Sarvatt@ubuntu/member/sarvatt] has joined #radeon
02:33 -!- Sarvatt [n=Sarvatt@ubuntu/member/sarvatt] has joined #dri-devel
02:33 -!- SunTzuTech1 [n=bent@ip68-100-74-234.dc.dc.cox.net] has joined #radeonhd
02:34 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has left #radeon ["Konversation terminated!"]
02:35 -!- Nille021 [n=Niels@p4FC67EBB.dip.t-dialin.net] has joined #radeon
02:35 -!- Nille02 [n=Niels@reactos/tester/Nille02] has quit [Nick collision from services.]
02:35 -!- Nille021 is now known as Nille02
02:50 -!- Gusar [n=Gusar@j-97.vc-graz.ac.at] has joined #nouveau
02:53 -!- fufler [n=lx@80.250.160.20] has quit [Remote closed the connection]
02:53 -!- fufler [n=lx@80.250.160.20] has quit [Remote closed the connection]
02:54 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has quit [Remote closed the connection]
02:58 -!- rsleza [n=radek@wireless-244.sci.muni.cz] has joined #radeon
02:58 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
02:58 -!- er0x [n=root@client-87-247-122-156.inturbo.lt] has joined #radeon
03:02 #radeon: < adamk> adamk
03:02 #radeon: < adamk> D'oh.
03:02 -!- amarks [n=quassel@124-168-147-98.dyn.iinet.net.au] has joined #radeon
03:05 -!- riri [n=riri@anc44-1-78-224-226-187.fbx.proxad.net] has quit ["o_/"]
03:07 -!- geo27_ [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
03:07 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has quit [Read error: 113 (No route to host)]
03:09 -!- dileX_ [n=sd@p5B2ED0E5.dip.t-dialin.net] has quit [Remote closed the connection]
03:10 -!- dwmw2 is now known as dwmw2_gone
03:10 -!- dileX [n=sd@vpn-eu2.unidsl.de] has joined #radeon
03:11 -!- Shuren [n=Devilman@host200-237-dynamic.6-79-r.retail.telecomitalia.it] has joined #radeon
03:11 #nouveau: < papegaaij> hi all
03:11 -!- orzel [n=orzel@berlioz.ethernet.freehackers.org] has joined #radeon
03:12 #nouveau: < papegaaij> i've updated the driver to the latest snapshot and most artifacts seem to be gone
03:12 #nouveau: < papegaaij> only some small issues left
03:12 -!- SunTzuTech1 [n=bent@ip68-100-74-234.dc.dc.cox.net] has left #radeonhd []
03:13 #nouveau: < papegaaij> one of my project icons in eclipse is wrong
03:13 #nouveau: < papegaaij> and in directory views image thumbnails are wrong
03:13 #nouveau: < papegaaij> ow, and i just noticed that the eclipse icon in the taskbar is wrong
03:14 -!- devh [n=devh@85-127-114-229.dynamic.xdsl-line.inode.at] has joined #radeon
03:14 -!- Toksyuryel [n=toksybox@c-71-231-52-36.hsd1.wa.comcast.net] has joined #radeonhd
03:16 -!- mroconnor [n=MarcO@pool-98-110-38-192.cmdnnj.fios.verizon.net] has joined #radeon
03:18 -!- geo27_ [n=quassel@wallia27.ac-rouen.fr] has quit [Read error: 113 (No route to host)]
03:18 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-tfbsrjeihgfyfsfm] has joined #radeon
03:19 -!- RSpliet [n=roy@53537511.cable.casema.nl] has quit ["Leaving."]
03:19 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
03:21 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has joined #radeon
03:22 #nouveau: < papegaaij> here's a 'screenshot': http://82.74.121.31/screencorrupt2.png
03:23 -!- da1l6 [n=da1l6@port-92-192-68-185.dynamic.qsc.de] has joined #radeon
03:25 -!- edman007 [n=edman007@pdpc/supporter/active/edman007] has joined #radeonhd
03:26 #nouveau: < shining^> wtf is that ?
03:26 #nouveau: < papegaaij> parts of screenshots
03:27 #nouveau: < papegaaij> showing some corruption
03:27 #nouveau: < shining^> aah its 3 parts ?
03:27 #nouveau: < papegaaij> yes
03:27 #nouveau: < shining^> lol ok
03:27 #nouveau: < shining^> well. the thumbnail one, I think I have just seen here yesterday
03:27 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has quit [Remote closed the connection]
03:27 #nouveau: < shining^> maybe from idletask ?
03:28 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has quit [Read error: 113 (No route to host)]
03:28 #nouveau: < shining^> btw are you using any desktop effects ? do you have composite manager running ?
03:29 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
03:29 #nouveau: < shining^> thats kde, right ? do you also have corruptions without kde ?
03:29 #nouveau: < shining^> 15:17 < idletask> mwk: http://imagebin.ca/view/5m4MYRK.html
03:30 #nouveau: < papegaaij> i'm not using the desktop effects
03:30 #nouveau: < papegaaij> yup, that's the same kind of corruption as i'm seeing in the folder views
03:30 #nouveau: < papegaaij> it's just the thumbnails, not the svg icons
03:31 #nouveau: < papegaaij> i don't about not using kde at all, but eclipse uses gtk as far as i know
03:33 -!- adamk_ [n=adamk@unaffiliated/adamk] has joined #radeon
03:33 -!- adamk_ [n=adamk@unaffiliated/adamk] has joined #radeonhd
03:33 -!- adamk_ [n=adamk@unaffiliated/adamk] has joined #dri-devel
03:34 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has quit ["Leaving"]
03:34 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has quit ["Leaving"]
03:34 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has quit ["Leaving"]
03:35 -!- sunmoon1997_ [n=sunmoon1@116.231.37.204] has quit [Read error: 60 (Operation timed out)]
03:35 -!- sunmoon1997_ [n=sunmoon1@116.231.37.204] has quit [Read error: 60 (Operation timed out)]
03:41 -!- RSpliet [n=roy@53537511.cable.casema.nl] has joined #nouveau
03:44 #nouveau: < shining^> papegaaij: ok, I just thought it would be good to know if kde4 is needed to reproduce these glitches
03:45 -!- ssp [n=ssp@nat/redhat/x-cyinkjjuhanfufsh] has joined #dri-devel
03:45 -!- ssp [n=ssp@nat/redhat/x-cyinkjjuhanfufsh] has joined #nouveau
03:47 -!- sunmoon1997 [n=sunmoon1@116.231.37.204] has quit [Read error: 110 (Connection timed out)]
03:47 -!- sunmoon1997 [n=sunmoon1@116.231.37.204] has quit [Read error: 110 (Connection timed out)]
03:47 #nouveau: < shining^> kernel drm still has the non kms path, right ? how long will that stay ? 
03:48 #nouveau: < shining^> and about suspend and tv-out requiring kms , is that only valid inside X ?
03:54 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has quit [Remote closed the connection]
03:54 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has joined #radeon
03:54 #radeon: < RiotingPacifist> hey is this the right place for r128 problems?
03:55 -!- RSpliet [n=roy@53537511.cable.casema.nl] has quit ["Leaving."]
03:55 -!- antrik [n=olaf@port-92-195-81-26.dynamic.qsc.de] has joined #dri-devel
03:55 -!- RSpliet [n=roy@53537511.cable.casema.nl] has joined #nouveau
03:56 -!- and1bm [n=andi@dslb-088-064-073-186.pools.arcor-ip.net] has joined #nouveau
04:01 #radeon: < Zajec3> try :)
04:01 -!- Zajec3 is now known as Zajec
04:01 -!- Zajec3 is now known as Zajec
04:01 -!- SparFux [n=raoul@e182025046.adsl.alicedsl.de] has joined #nouveau
04:02 #nouveau: < SparFux> Yay, I could start hedgewars with Nouveau. It uses OpenGL. :-)
04:02 #radeon: < RiotingPacifist> It's not for me, just want to send somebody to the right place as they cant seam to get r128 driver working.
04:02 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has joined #radeon
04:03 -!- mvo_ [n=egon@p5B09DEA3.dip.t-dialin.net] has joined #dri-devel
04:03 -!- _ [n=olaf@port-92-195-173-176.dynamic.qsc.de] has joined #dri-devel
04:04 -!- mart_ [n=mart@125-238-22-88.jetstream.xtra.co.nz] has quit ["Leaving"]
04:04 -!- _ is now known as Guest59414
04:04 -!- Guest59414 [n=olaf@port-92-195-173-176.dynamic.qsc.de] has quit [Remote closed the connection]
04:04 #radeon: < glisse> right thing is to trash r128, and move to the 21century
04:05 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
04:05 -!- silverthorn [n=silverth@78-72-71-195-no33.tbcn.telia.com] has joined #radeon
04:07 #radeon: < RiotingPacifist> think hes on PPC, so moving to x86 would be the step backwards :P
04:08 -!- MacSlow is now known as MacSlow|lunch
04:09 -!- Fuddl [n=fuddl@faui40o.informatik.uni-erlangen.de] has joined #radeon
04:11 #nouveau: < SparFux> hi
04:12 -!- mvo [n=egon@p5B09DEA3.dip.t-dialin.net] has quit [Read error: 113 (No route to host)]
04:13 -!- Jonno [n=jon@c-4a1fe353.028-32-6c6b7010.cust.bredbandsbolaget.se] has joined #radeon
04:13 -!- dileX_ [n=sd@p5B2ED0E5.dip.t-dialin.net] has joined #radeon
04:15 -!- antrik [n=olaf@port-92-195-81-26.dynamic.qsc.de] has quit [Read error: 113 (No route to host)]
04:18 -!- Fuddl [n=fuddl@faui40o.informatik.uni-erlangen.de] has quit ["Leaving."]
04:18 -!- SparFux [n=raoul@e182025046.adsl.alicedsl.de] has quit ["Leaving."]
04:20 #nouveau: < shining^> sure hedgewars works great
04:20 -!- antrik [n=olaf@port-92-195-173-176.dynamic.qsc.de] has joined #dri-devel
04:20 -!- Fuddl [n=fuddl@faui40o.informatik.uni-erlangen.de] has joined #radeon
04:22 -!- prg [n=prg@unaffiliated/prg] has joined #nouveau
04:22 -!- antrik [n=olaf@port-92-195-173-176.dynamic.qsc.de] has quit [Client Quit]
04:22 -!- antrik [n=olaf@port-92-195-173-176.dynamic.qsc.de] has joined #dri-devel
04:24 #radeon: < MrCooper> RiotingPacifist: there's plenty of PPC machines with Radeons :) the r128 drivers have been bitrotting for years
04:24 -!- MAbeeTT [n=MAbeeTT@190.179.194.97] has joined #radeon
04:24 -!- MAbeeTT [n=MAbeeTT@190.179.194.97] has joined #radeonhd
04:25 -!- sunmoon1997 [n=sunmoon1@58.33.135.45] has joined #dri-devel
04:25 -!- sunmoon1997 [n=sunmoon1@58.33.135.45] has joined #nouveau
04:27 -!- edt [n=Ed@130-77.162.dsl.aei.ca] has quit ["Leaving"]
04:27 #radeon: < RiotingPacifist> Still i'd assume there is a better solution that get a new PC, it's not like he wants to install vista or something
04:27 -!- Zetbo [n=zetbo@cs181068010.pp.htv.fi] has quit [Remote closed the connection]
04:27 -!- dileX [n=sd@vpn-eu2.unidsl.de] has quit [Read error: 110 (Connection timed out)]
04:28 -!- LordBurrito [n=jseymour@jimsun.linxnet.com] has joined #radeon
04:28 -!- LordBurrito [n=jseymour@jimsun.linxnet.com] has quit [Client Quit]
04:28 -!- LordBurrito [n=jseymour@jimsun.linxnet.com] has joined #radeon
04:30 -!- Zetbo [n=zetbo@cs181068010.pp.htv.fi] has joined #radeon
04:31 -!- silverthorn [n=silverth@78-72-71-195-no33.tbcn.telia.com] has quit ["Lämnar"]
04:34 -!- silverthorn [n=silverth@78-72-71-195-no33.tbcn.telia.com] has joined #radeon
04:34 -!- rib [n=bob@92.40.33.239.sub.mbb.three.co.uk] has quit [Read error: 60 (Operation timed out)]
04:36 -!- sunmoon1997_ [n=sunmoon1@58.33.135.45] has joined #dri-devel
04:36 -!- sunmoon1997_ [n=sunmoon1@58.33.135.45] has joined #nouveau
04:37 -!- jsgf [n=jeremy@dsl-203-33-163-122.NSW.netspace.net.au] has joined #dri-devel
04:37 -!- edt [n=Ed@130-77.162.dsl.aei.ca] has joined #radeon
04:37 #nouveau: < Unhelpful> if 4fps is great... i can't seem to get accel to work with it at all
04:38 -!- manitu [n=werner@p578b0cfb.dip0.t-ipconnect.de] has quit ["Verlassend"]
04:39 -!- SparFux [n=raoul@e182017125.adsl.alicedsl.de] has joined #nouveau
04:39 -!- SparFux [n=raoul@e182017125.adsl.alicedsl.de] has quit [Client Quit]
04:40 -!- stikonas [n=and@wesnoth/translator/stikonas] has joined #radeon
04:41 -!- manitu [n=werner@p578b0cfb.dip0.t-ipconnect.de] has joined #radeonhd
04:43 #nouveau: < shining^> Unhelpful: do you get accel with anything ?
04:44 #nouveau: < papegaaij> hmmm, now even some of my mouse cursors are corrupted :)
04:44 #nouveau: < papegaaij> the drop cursor is all messed up
04:45 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has quit ["No Ping reply in 180 seconds."]
04:45 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
04:45 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit [Read error: 60 (Operation timed out)]
04:45 -!- sunmoon1997_ [n=sunmoon1@58.33.135.45] has quit ["Ex-Chat"]
04:45 -!- sunmoon1997_ [n=sunmoon1@58.33.135.45] has quit ["Ex-Chat"]
04:46 -!- _Groo_ [n=Paulo@200-161-0-143.dsl.telesp.net.br] has joined #radeon
04:46 -!- mvo_ [n=egon@p5B09DEA3.dip.t-dialin.net] has quit [Connection timed out]
04:47 -!- mvo_ [n=egon@p5B09DEA3.dip.t-dialin.net] has joined #dri-devel
04:47 -!- fmarl [n=francesc@151.62.20.220] has quit [Read error: 104 (Connection reset by peer)]
04:58 -!- illissius [n=illissiu@lg.vezer.elte.hu] has joined #dri-devel
05:05 -!- fmarl [n=francesc@151.62.20.220] has joined #nouveau
05:12 -!- MacSlow|lunch is now known as MacSlow
05:14 -!- BioTube [n=biotube@adsl-71-145-166-154.dsl.austtx.sbcglobal.net] has joined #radeon
05:22 -!- AStorm [n=astralst@unaffiliated/astralstorm] has joined #radeon
05:24 -!- Curan [n=kai@drsd-4dbd8db4.pool.mediaWays.net] has joined #radeon
05:25 -!- RSpliet [n=roy@53537511.cable.casema.nl] has quit [Nick collision from services.]
05:25 -!- RSpliet [n=roy@53537511.cable.casema.nl] has joined #nouveau
05:26 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has quit [Remote closed the connection]
05:27 #radeon: < Curan> a question out of curiosity: the free driver doesn't support the UVD, does it?
05:30 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has quit ["Lost terminal"]
05:30 -!- MacSlow [n=mirco@unaffiliated/macslow] has quit [Read error: 104 (Connection reset by peer)]
05:31 -!- Eddi|zuHause3 is now known as Eddi|zuHause
05:31 -!- MacSlow [n=mirco@unaffiliated/macslow] has joined #nouveau
05:33 -!- MacSlow [n=mirco@unaffiliated/macslow] has quit [Client Quit]
05:34 #radeon: < Zajec> їoesn't
05:34 #radeon: < Zajec> doesn't
05:35 -!- AstralSt [n=astralst@unaffiliated/astralstorm] has joined #radeon
05:35 -!- papillon81 [n=papillon@f053144200.adsl.alicedsl.de] has joined #radeon
05:36 -!- beyecixramd [n=beyecixr@34.Red-88-19-252.staticIP.rima-tde.net] has joined #nouveau
05:36 -!- AstralStorm [n=astralst@unaffiliated/astralstorm] has quit [Read error: 110 (Connection timed out)]
05:36 #radeon: < Curan> Zajec: thx
05:36 -!- kdekorte_ [n=kdekorte@64-187-77-49.iprev.kci.net] has joined #radeon
05:37 -!- red_hell_ita [n=rosso@host159-93-dynamic.14-87-r.retail.telecomitalia.it] has joined #radeon
05:38 #nouveau: < curro_> shining^: hey, your patch looks good to me but
05:39 #nouveau: < curro_> don't you think it would be nicer if you did kfree(nv_connector->edid) just once, at the beginning of nouveau_connector_detect instead of 4 times?
05:39 -!- m03sizlak [n=x1001011@pool-98-117-162-201.bflony.fios.verizon.net] has quit [Read error: 113 (No route to host)]
05:40 -!- brbrbr [n=Basiley@unaffiliated/brbrbr] has joined #radeonhd
05:41 #nouveau: < curro_> shining^: actually, not at the beginning, i'd do it after the LVDS check
05:41 -!- AStorm [n=astralst@unaffiliated/astralstorm] has quit [Read error: 104 (Connection reset by peer)]
05:46 -!- erghezi [n=quassel@213.207.221.97] has quit [Remote closed the connection]
05:46 -!- adamk_ [n=adamk@unaffiliated/adamk] has quit ["Leaving"]
05:46 -!- adamk_ [n=adamk@unaffiliated/adamk] has quit ["Leaving"]
05:46 -!- adamk_ [n=adamk@unaffiliated/adamk] has quit ["Leaving"]
05:47 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has quit [Remote closed the connection]
05:47 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has joined #radeon
05:49 -!- Gu1ll4um3r0m41b [n=Gu1ll4um@AReims-157-1-134-76.w90-18.abo.wanadoo.fr] has joined #radeon
05:51 -!- crimsonflame123 [n=chatzill@122.167.115.153] has joined #radeon
05:51 -!- crimsonflame123 [n=chatzill@122.167.115.153] has joined #nouveau
05:53 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has joined #radeon
05:53 -!- kdekorte [n=kdekorte@64-187-77-49.iprev.kci.net] has quit [Read error: 110 (Connection timed out)]
05:58 -!- KoH [n=kane@port-92-193-93-100.dynamic.qsc.de] has quit ["freeing unimportant sockets, needed for DoS"]
05:58 -!- RSpliet [n=roy@53537511.cable.casema.nl] has quit [Read error: 54 (Connection reset by peer)]
05:58 #nouveau: < shining^> curro_: tbh, I didnt really understand what is going on. its already done once in the beginning, before calling drm_edid
05:59 #nouveau: < shining^> but then its done in all cases where it returns disconnected. I just used radeon code as a guideline, that could very well be wrong
05:59 -!- sroland [n=sroland@84-75-151-199.dclient.hispeed.ch] has joined #dri-devel
06:02 #radeon: < adamk> soreau: FYI, gaussian blur is crashing compiz here with the latest mesa and libdrm from git on an x850: http://pastebin.com/m24374b3e
06:02 -!- gnubien [n=e@unaffiliated/gnubien] has joined #radeonhd
06:02 #nouveau: < curro_> shining^: you want to do it at nouveau_connector.c:239, there's no need to free it when we return disconnected, it won't leak anywhere.
06:02 #radeon: < adamk> soreau: I'm heaing out to a clients office for a bit, but I'll be back later.
06:03 -!- brbrbr [n=Basiley@unaffiliated/brbrbr] has quit ["Leaving"]
06:03 -!- MacSlow [n=mirco@unaffiliated/macslow] has joined #nouveau
06:04 -!- mroconnor [n=MarcO@37.sub-75-198-169.myvzw.com] has joined #radeon
06:04 -!- Toksyuryel [n=toksybox@c-71-231-52-36.hsd1.wa.comcast.net] has quit [Remote closed the connection]
06:05 -!- Gu1ll4um3r0m41n [n=Gu1ll4um@AReims-157-1-94-225.w90-7.abo.wanadoo.fr] has quit [Read error: 110 (Connection timed out)]
06:06 -!- PsyMan [n=NONE@ppp-94-65-154-96.home.otenet.gr] has joined #radeon
06:07 -!- dmb [n=Dmb@unaffiliated/dmb] has joined #radeon
06:07 -!- dmb [n=Dmb@unaffiliated/dmb] has joined #radeonhd
06:07 -!- rib [n=bob@92.40.115.135.sub.mbb.three.co.uk] has joined #dri-devel
06:07 -!- Toksyuryel [n=toksybox@c-71-231-52-36.hsd1.wa.comcast.net] has joined #radeonhd
06:09 -!- AndreasD [n=andreas@1407ds1-ns.0.fullrate.dk] has joined #radeon
06:09 -!- AndreasD [n=andreas@1407ds1-ns.0.fullrate.dk] has joined #radeonhd
06:10 -!- rib [n=bob@92.40.115.135.sub.mbb.three.co.uk] has quit [Client Quit]
06:11 -!- kdekorte__ [n=kdekorte@68-240-152-144.pools.spcsdns.net] has joined #radeon
06:11 #nouveau: < shining^> curro_: hm you dont want to write the patch ? it might be easier :)
06:12 #nouveau: < curro_> shining^: nah :)
06:13 #nouveau: < shining^> well its not clear to me. for example what difference does it make if its outside the i2c block, as opposed to inside ?
06:15 #nouveau: < shining^> and I dont know what happens either in the disconnected case. destroy will be called anyway ?
06:17 #nouveau: < curro_> shining^: edid should be NULL for the cases it isn't LVDS and it doesn't support I2C, because there's no way it could have gotten a valid EDID block.
06:17 -!- twnqx [n=charlie@109.82.55.179] has quit [Read error: 60 (Operation timed out)]
06:18 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has quit ["Konversation terminated!"]
06:18 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has joined #radeon
06:20 #nouveau: < shining^> edid should be NULL = we should make it null or it should already be null so there is no need to free/null it ?
06:22 -!- zackr [n=zack@c-68-82-27-85.hsd1.pa.comcast.net] has joined #dri-devel
06:22 -!- Gu1ll4um3r0m41b is now known as Gu1ll4um3r0m41n
06:22 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has quit [Remote closed the connection]
06:22 -!- bertrik [n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl] has joined #radeonhd
06:23 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Read error: 60 (Operation timed out)]
06:23 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Read error: 60 (Operation timed out)]
06:27 -!- kdekorte_ [n=kdekorte@64-187-77-49.iprev.kci.net] has quit [Read error: 110 (Connection timed out)]
06:27 #nouveau: < curro_> shining^: you should make it null
06:28 #nouveau: < curro_> shining^: and, in the disconnected case, nothing special happens, it just stays unused
06:29 -!- AstralSt [n=astralst@unaffiliated/astralstorm] has quit [Read error: 110 (Connection timed out)]
06:29 -!- hydraglyph [n=hydragly@24-247-203-137.dhcp.bycy.mi.charter.com] has quit [Read error: 110 (Connection timed out)]
06:31 -!- AstralSt [n=astralst@unaffiliated/astralstorm] has joined #radeon
06:31 #nouveau: < shining^> http://pastebin.ca/1750999 ?
06:32 -!- kernelpnc [n=quassel@port-9715.pppoe.wtnet.de] has joined #radeon
06:34 #nouveau: < curro_> shining^: looks fine to me, but: error: patch failed: drivers/gpu/drm/nouveau/nouveau_connector.c:83
06:37 -!- beyecixramd [n=beyecixr@34.Red-88-19-252.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)]
06:37 #nouveau: < curro_> shining^: oh wait, that pastebin has a "download raw" link, that seems to work
06:38 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has joined #radeon
06:39 -!- beyecixramd [n=beyecixr@113.Red-83-49-180.dynamicIP.rima-tde.net] has joined #nouveau
06:43 -!- ahmedammar [n=b33fc0d3@gentoo/developer/b33fc0d3] has joined #nouveau
06:43 #radeon: < mwk> say, how is textureGrad done on radeons? something sane?
06:43 -!- AstralSt is now known as AstralStorm
06:44 -!- jmho_ [n=quassel@port-87-193-192-142.static.qsc.de] has joined #radeon
06:44 #RadeonHD: < Toksyuryel> Hm, strange
06:45 -!- _KAMI_1 [n=kami@host-50-018.comunique.hu] has joined #radeon
06:45 #RadeonHD: < Toksyuryel> I seem to be experiencing what appears to be a regression, possibly in this driver
06:45 -!- beyecixramd [n=beyecixr@113.Red-83-49-180.dynamicIP.rima-tde.net] has quit [Remote closed the connection]
06:45 -!- andi- [n=andi@2001:470:1f0a:61f:0:0:0:2] has quit [Remote closed the connection]
06:46 #RadeonHD: < Toksyuryel> When attempting to run EVE Online in Wine, it no longer believes that my card supports Shader Model 2. The people in the Wine channel seem convinced that the problem is with this drvier, but their attitude makes me less inclined to believe they know what they're talking about.
06:46 #RadeonHD: < Toksyuryel> Any idea how to proceed and isolate where the problem lies?
06:46 -!- Novum [n=Miranda@e180031254.adsl.alicedsl.de] has joined #nouveau
06:48 -!- kernelpanic_ [n=quassel@port-1662.pppoe.wtnet.de] has quit [Read error: 110 (Connection timed out)]
06:50 -!- rib [n=bob@158.43.2.102] has joined #dri-devel
06:51 #RadeonHD: < udovdh> hmmm
06:51 #RadeonHD: < udovdh> can't help you, I think
06:53 #nouveau: < curro_> shining^: i'll push your patch in a minute, with a couple of fixes more for connector_detect.
06:53 -!- andi- [n=andi@2001:470:1f0a:61f:0:0:0:2] has joined #nouveau
06:54 -!- _KAMI_ [n=kami@81.183.228.239] has quit [Read error: 110 (Connection timed out)]
06:55 -!- jsgf [n=jeremy@dsl-203-33-163-122.NSW.netspace.net.au] has quit [Read error: 113 (No route to host)]
06:58 -!- phoenix64 [n=phoenix@p5B21B1B2.dip0.t-ipconnect.de] has joined #nouveau
06:58 -!- phoenix64 [n=phoenix@p5B21B1B2.dip0.t-ipconnect.de] has joined #radeon
06:59 -!- Anssi [i=hannulaa@mozart.cc.tut.fi] has quit ["kernel upgrade"]
06:59 -!- er0x [n=root@client-87-247-122-156.inturbo.lt] has quit [Connection timed out]
07:02 -!- lokomoko [n=zxczx@dsl-hkimmlgw8-fe15f800-197.dhcp.inet.fi] has joined #radeon
07:03 #RadeonHD: < udovdh> http://www.phoronix.com/forums/showthread.php?p=107829
07:03 #RadeonHD: < udovdh> any ideas?
07:05 -!- BigBrain [n=BigBrain@p57AFF3F5.dip.t-dialin.net] has joined #radeon
07:05 -!- BigBrain [n=BigBrain@p57AFF3F5.dip.t-dialin.net] has joined #radeonhd
07:05 -!- BigBrain [n=BigBrain@p57AFF3F5.dip.t-dialin.net] has joined #nouveau
07:06 #nouveau: < curro_> shining^: done
07:07 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has joined #nouveau
07:10 -!- _KAMI_1 [n=kami@host-50-018.comunique.hu] has quit ["Leaving."]
07:12 -!- Ghworg- [n=nnnnnnnn@82-33-168-195.cable.ubr06.wiga.blueyonder.co.uk] has joined #radeon
07:13 -!- Jonno_ [n=jon@c-4a1fe353.028-32-6c6b7010.cust.bredbandsbolaget.se] has joined #radeon
07:13 -!- Ghworg [n=nnnnnnnn@82-33-168-195.cable.ubr06.wiga.blueyonder.co.uk] has quit ["Getting off stoned server - dircproxy 1.0.5"]
07:13 -!- ssvb [n=ssvb___@viktor.cosmicparrot.net] has quit [Read error: 60 (Operation timed out)]
07:13 -!- EisNerd [n=eisnerd@ccc2.rbg.informatik.tu-darmstadt.de] has quit [Read error: 60 (Operation timed out)]
07:13 -!- awjb [i=awjb@zoidberg.org] has quit [Read error: 60 (Operation timed out)]
07:13 -!- deavid [n=deavid@sedice.dnssw.net] has quit [Read error: 60 (Operation timed out)]
07:13 -!- bragon_ [n=Alexandr@tmwrox.bragon.info] has quit [Read error: 60 (Operation timed out)]
07:13 -!- Eythan [n=Eythan@AMontpellier-554-1-82-48.w92-145.abo.wanadoo.fr] has quit [Read error: 60 (Operation timed out)]
07:13 -!- Eythan [n=Eythan@AMontpellier-554-1-82-48.w92-145.abo.wanadoo.fr] has quit [Read error: 60 (Operation timed out)]
07:13 -!- Limoto_ [n=quassel@94.23.37.43] has quit [Read error: 60 (Operation timed out)]
07:13 -!- artoj [i=ajonsson@xob.kapsi.fi] has quit [Read error: 60 (Operation timed out)]
07:13 -!- refic [i=refic@psimerion.org] has quit [Read error: 60 (Operation timed out)]
07:13 -!- Kai__ [i=kai@nohostname.de] has quit [Read error: 60 (Operation timed out)]
07:13 -!- Bluehorn [n=torsten@static.88-198-15-165.clients.your-server.de] has quit [Read error: 60 (Operation timed out)]
07:13 -!- Limoto [n=quassel@94.23.37.43] has joined #nouveau
07:13 -!- Zzeiss1 [n=wsy@dsl092-078-219.bos1.dsl.speakeasy.net] has quit ["Leaving."]
07:13 -!- ssvb [n=ssvb___@viktor.cosmicparrot.net] has joined #radeon
07:13 -!- artoj [i=ajonsson@xob.kapsi.fi] has joined #radeon
07:14 -!- EisNerd [i=1009@ccc2.rbg.informatik.tu-darmstadt.de] has joined #radeon
07:14 -!- bragon_ [n=Alexandr@tmwrox.bragon.info] has joined #radeon
07:14 -!- awjb [i=awjb@zoidberg.org] has joined #nouveau
07:14 -!- deavid [n=deavid@sedice.dnssw.net] has joined #radeon
07:14 -!- refic [i=refic@psimerion.org] has joined #nouveau
07:14 -!- Kai__ [i=kai@nohostname.de] has joined #radeon
07:14 -!- Eythan [n=Eythan@AMontpellier-554-1-82-48.w92-145.abo.wanadoo.fr] has joined #radeon
07:14 -!- Ghworg- is now known as Ghworg
07:14 -!- Bluehorn [n=torsten@static.88-198-15-165.clients.your-server.de] has joined #radeon
07:14 -!- Eythan [n=Eythan@AMontpellier-554-1-82-48.w92-145.abo.wanadoo.fr] has joined #radeonhd
07:15 #radeon: < Jonno_> I recently had some time to spare and decided to try to hunt down why sauerbraten stopped working between mesa 7.6 and 7.7.
07:15 #radeon: < Jonno_> As I know nothing about gpu programing, it was mostly an exersice in learning git, but I did managed to create a patch that solves the problem for me.
07:15 #radeon: < Jonno_> If you want to try it out I've uploaded it to http://jon.severinsson.net/mesa/ (mesa_7_7-r600-sauerbraten.patch applies cleanly to the mesa 7.7 release while mesa_7_7_branch-r600-sauerbraten.patch applies cleanly to today's mesa_7_7_branch)
07:16 #radeon: < Jonno_> It's not realy a fix, more of a workaround, as it replaces 96 lines of new code with 206 lines of old code from the git history, rather than fixing the new code, but it works for me, and perhaps it can serve as a starting point for someone more knowledgeable to fix it for real.
07:16 #radeon: < Jonno_> If someone does create a better fix I'll gladly help test it.
07:16 -!- mokoloko [n=zxczx@dsl-hkimmlgw8-fe15f800-197.dhcp.inet.fi] has quit [Read error: 113 (No route to host)]
07:18 -!- Eddi|zuHause2 [n=johekr@p54B776DE.dip.t-dialin.net] has joined #radeon
07:19 -!- Eddi|zuHause [n=johekr@84.183.118.222] has quit [Remote closed the connection]
07:21 -!- lokomoko is now known as mokoloko
07:22 #radeon: < agd5f> Jonno_: file a bug https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa and include a description of the problem and your patches
07:23 -!- keltor|sleep is now known as keltor
07:25 -!- Sonne [n=suntzu@host-84-222-52-178.cust-adsl.tiscali.it] has quit [Remote closed the connection]
07:26 -!- darkbasic_ [n=quassel@static-217-133-76-61.clienti.tiscali.it] has joined #radeon
07:26 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has quit [Read error: 104 (Connection reset by peer)]
07:28 -!- Eddi|zuHause2 is now known as Eddi|zuHause
07:30 -!- wirry [n=wirry@88.130.221.171] has joined #radeon
07:30 -!- wirry [n=wirry@88.130.221.171] has joined #radeonhd
07:31 #radeon: < Zajec> Jonno_: nice work :) please fill bug report :)
07:32 #radeon: < Zajec> Jonno_: yeah, patch isn't too nice... but is great hint :)
07:32 #radeon: < Jonno_> Working on the bugreport, thx for the feedback
07:34 #radeon: < Zajec> thanks for bisecting :)
07:36 #radeon: < Jonno_> If you want to, I can supply a list of all commits from which the "new" code comes, but it's not whole commits that can be reverted...
07:37 -!- bmaass [n=bmaass@188.96.83.220] has joined #nouveau
07:38 -!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Read error: 104 (Connection reset by peer)]
07:39 -!- soreau [n=soreau@unaffiliated/soreau] has quit [Read error: 110 (Connection timed out)]
07:40 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has quit [Read error: 60 (Operation timed out)]
07:40 -!- stikonas [n=and@wesnoth/translator/stikonas] has joined #radeon
07:40 -!- markinfo [n=marek@dhcp27.dmg.tuwien.ac.at] has joined #radeon
07:41 -!- mjr [i=mjr@aulis.sange.fi] has quit []
07:41 -!- mjr [i=mjr@aulis.sange.fi] has joined #radeon
07:42 -!- illissius [n=illissiu@lg.vezer.elte.hu] has quit [Read error: 110 (Connection timed out)]
07:44 -!- stroyan [n=mike@97-122-228-141.hlrn.qwest.net] has quit ["Leaving"]
07:44 -!- stroyan [n=mike@97-122-228-141.hlrn.qwest.net] has quit ["Leaving"]
07:45 #radeon: < glisse> agd5f: i am not sure why X/ddx reject the mode in https://bugzilla.redhat.com/show_bug.cgi?id=540024
07:45 -!- RAOF_ [n=RAOF@ppp121-44-59-228.lns20.syd6.internode.on.net] has joined #nouveau
07:46 #radeon: < glisse> seems that xserver report MODE_CLOCK_RANGE
07:46 #radeon: < glisse> could it be that kernel report somethings wrong about clock ?
07:46 -!- idletask [n=fg@pas75-3-82-235-191-170.fbx.proxad.net] has joined #nouveau
07:46 #nouveau: < idletask> Hello again
07:47 #radeon: < ajax> glisse: that's... bizarre.
07:47 #radeon: < ajax> [drm:drm_mode_debug_printmodeline], Modeline 39:"1920x1080" 60 172780 1920 2040 2248 2576 1080 1081 1084 1118 0x0 0x6
07:48 #radeon: < ajax> 172780 is the mode clock in khz; dvi single link is 165MHz
07:48 -!- otaylor [n=otaylor@nat/redhat/x-unczewcxpjeelyse] has joined #radeon
07:48 #radeon: < glisse> it's connected through vga iirc
07:48 #radeon: < ajax> hey, so it is.
07:48 #radeon: < glisse> somehow UMS accept this mode
07:48 #nouveau: < idletask> I am seeing image corruption which appears to be not that random but I'm not sure how to diagnose it
07:49 #nouveau: < idletask> Any hints?
07:49 #radeon: < glisse> maybe it tweak it
07:49 -!- Anssi_ [i=hannulaa@mozart.cc.tut.fi] has joined #nouveau
07:49 #nouveau: < idletask> (this is a g86)
07:49 #radeon: < ajax> it doesn't.
07:49 #radeon: < ajax> UMS is getting this out of EDID:
07:49 #radeon: < ajax> (II) RADEON(0): h_active: 1920  h_sync: 1968  h_sync_end 2000 h_blank_end 2080 h_border: 0
07:49 #radeon: < agd5f> UMS gets a 138 Mhz mode
07:49 #radeon: < ajax> (II) RADEON(0): v_active: 1080  v_sync: 1083  v_sync_end 1088 v_blanking: 1110 v_border: 0
07:49 -!- stikonas [n=and@wesnoth/translator/stikonas] has quit ["Konversation terminated!"]
07:49 -!- Anssi_ is now known as Anssi
07:49 -!- stikonas [n=and@wesnoth/translator/stikonas] has joined #radeon
07:49 #radeon: < glisse> KMS also has the 138M mode
07:49 #radeon: < ajax> which is the cvt-r timings
07:50 #nouveau: < idletask> Also, my card has a VGA output and a DVI output, I'd like the DVI output to be the primary output... Even on boot. Is there a way to do that?
07:50 #radeon: < ajax> glisse: i don't see that in the kms dmesg at the end
07:50 #radeon: < glisse> oh true
07:50 #radeon: < glisse> weird the kms xorg log has it
07:51 #radeon: < glisse> i guess than i can blame kms edid :)
07:51 #radeon: < ajax> oh, god, right.
07:51 #nouveau: < pq> idletask, doesn't the output get cloned to all connected monitors on boot?
07:51 #radeon: < ajax> so here's what's happening:
07:52 #radeon: < ajax> (i think)
07:52 #radeon: < ajax> the "Printing DDC gathered Modelines" bit is what X's mode generator comes up with
07:52 #radeon: < ajax> but the "Printing probed modes for output" bit is the list we get from the DRM device, ie from KMS's mode generator
07:53 #radeon: < ajax> so i think what's happening is somewhere in KMS we're seeing the 1920x1080 mode in the standard timing block, and generating a timing for that that _isn't_ rb
07:53 #radeon: < ajax> which then doesn't work, since the ranges section says the clock limit is 170MHz and that's 172MHz
07:54 #nouveau: < idletask> pq: I don't know at all stages, but when the PC boots, the pre-OS screen only shows on the VGA output
07:54 #radeon: < ajax> but then we're not adding the 1920x1080RB mode because we think there's already a 1920x1080 mode in the list
07:54 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-tfbsrjeihgfyfsfm] has quit [Ping timeout: 180 seconds]
07:54 #radeon: < kdekorte__> Is opengl 2.0 for r6xx only supported in mesa 7.8 (git) and not 7.7?
07:54 #radeon: < glisse> i love this theory, it shows how simple is the path a mode takes ;)
07:54 -!- soreau [n=soreau@unaffiliated/soreau] has joined #radeon
07:54 #radeon: < agd5f> kdekorte__: yes, I think so
07:54 #nouveau: < pq> what is "pre-OS" screen?
07:55 -!- bmaass [n=bmaass@188.96.83.220] has quit [Read error: 110 (Connection timed out)]
07:55 #nouveau: < pq> the one that BIOS draws, before Linux even loads?
07:55 #nouveau: < idletask> ie, at boot, before and up to the grub screen
07:55 #nouveau: < idletask> Yes
07:55 #nouveau: < pq> aha. We cannot help with that.
07:55 #radeon: < ajax> that's my guess anyway, although i didn't think kms's mode list construction was that stupid
07:56 #radeon: < kdekorte__> agd5f: ok thanks due to 7.8 (git) now requiring a new dri2proto, and assuming a new Xserver I'm not sure I want to get that deep into it.
07:56 #radeon: < glisse> will look at it, i have been looking at ddx enough to think that the issue is not there
07:56 #nouveau: < pq> you'd need to tweak the BIOS somehow, probably impossible in practise. Or impractical.
07:56 #nouveau: < pq> or have only the dvi connected
07:56 -!- rib [n=bob@158.43.2.102] has quit [Read error: 60 (Operation timed out)]
07:58 -!- RAOF [n=RAOF@ppp121-44-108-216.lns20.syd6.internode.on.net] has quit [Read error: 110 (Connection timed out)]
07:58 #radeon: < taiu> Jonno_: better fix is to to type 't' for console in sauerbraten and then /floatvtx 1 :)
07:58 -!- twnqx [n=charlie@109.82.77.88] has joined #radeon
07:59 #nouveau: < pq> impractical here means, that it might be doable, with a great effort and a risk of bricking the card - VBIOS editing.
08:00 -!- papegaaij [i=hidden-u@wcoe-60.r-195-35-227.atwork.nl] has quit [Read error: 110 (Connection timed out)]
08:00 -!- johanbr [n=j@blk-222-216-252.eastlink.ca] has joined #nouveau
08:01 #nouveau: < pq> the easiest solution is to plug in vga only after the BIOS has inited.
08:01 -!- Anssi [i=hannulaa@mozart.cc.tut.fi] has quit ["client restart"]
08:01 -!- Anssi [i=hannulaa@mozart.cc.tut.fi] has joined #nouveau
08:01 -!- soreau [n=soreau@unaffiliated/soreau] has quit [Read error: 60 (Operation timed out)]
08:02 -!- stroyan [n=mike@97-122-228-141.hlrn.qwest.net] has joined #dri-devel
08:02 -!- stroyan [n=mike@97-122-228-141.hlrn.qwest.net] has joined #radeonhd
08:02 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] has quit ["Ex-Chat"]
08:02 #radeon: < taiu> Jonno_: it tries to upload vertex data as SHORT otherwise and we'r not handling that too well, or maybe it's their code as it enables floatvtx for most of the world
08:03 -!- andyrtr [n=andyrtr@archlinux/developer/andyrtr] has joined #nouveau
08:03 -!- soreau [n=soreau@unaffiliated/soreau] has joined #radeon
08:03 -!- ivanich|wrk [n=ivanich@office.TeNeT.Odessa.UA] has quit [Read error: 104 (Connection reset by peer)]
08:04 #radeon: < MrCooper> so, who's working on a Gallium driver for R600 and above?
08:04 #radeon: < glisse> MrCooper: i am pondering on the design :)
08:05 #radeon: < glisse> it's the topic of my fosdem talk
08:06 #radeon: < Tommeh> Ooh, nice.
08:06 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] has joined #radeon
08:07 #nouveau: < idletask> Well, that's what I'm currently doing
08:07 #nouveau: < idletask> I haven't even configured xrandr, meh
08:07 #radeon: < taiu> else if(strstr(vendor, "Tungsten") || strstr(vendor, "Mesa") || strstr(vendor, "DRI") || strstr(vendor, "Microsoft") || strstr(vendor, "S3 Graphics"))
08:07 #radeon: < taiu> well that doesnt catch 'Advanced Micro Devices, Inc'  :)
08:09 #nouveau: < idletask> On a more casual note, all image thumbnails with KDE4 are screwed, and all screwages follow the same pattern, it seems
08:10 #radeon: < soreau> adamk: Looks like you're crashing in swrast frag prog too.. are you sure you didn't have focus blur, bicubic filter or motion blur enabled? because I believe those cause the same kind of crash here too
08:10 #radeon: < kdekorte__> glisse: for some reason I thought that someone was half done with the r600g driver but was just working on it in private. So by saying "pondering design" it sounds like you haven't done any code.
08:11 #radeon: < glisse> kdekorte__: i do have code, but it's standalone design test
08:11 #radeon: < glisse> i think MostAwesomeDude started skeleton but nothings is really plugged in
08:11 #radeon: < glisse> bbl
08:12 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has joined #nouveau
08:12 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has joined #dri-devel
08:13 -!- darkbasic_ [n=quassel@static-217-133-76-61.clienti.tiscali.it] has quit [Remote closed the connection]
08:13 -!- taiu [n=andrem@88.196.5.82] has quit ["Leaving."]
08:13 -!- taiu [n=andrem@88.196.5.82] has quit ["Leaving."]
08:13 -!- taiu [n=andrem@88.196.5.82] has quit ["Leaving."]
08:14 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has joined #radeon
08:16 #radeon: < Jonno_> taiu: Thx, much better workaround, but not really a fix either.
08:17 #radeon: < Jonno_> agd5f: Bug is filed at https://bugs.freedesktop.org/show_bug.cgi?id=26043
08:17 -!- otaylor [n=otaylor@nat/redhat/x-unczewcxpjeelyse] has quit [Read error: 110 (Connection timed out)]
08:19 #radeon: < MostAwesomeDude> lkro: Thanks for the patch, you're totally right. Guess I need to lay off the late-night coding. :3
08:19 #radeon: < MostAwesomeDude> lkro: Applied.
08:20 #radeon: < MostAwesomeDude> glisse, kdekorte__ : I've gotten started, but I'm not that far. One of the things that stopped me almost immediately was a desire to do the state emit right.
08:20 #radeon: < soreau> MostAwesomeDude: You just need more mountain dew and coffee! ;)
08:20 #radeon: < MostAwesomeDude> So I've been doing this atomized emit on r300g to make sure it's the Right Thing.
08:20 -!- otaylor [n=otaylor@66.187.234.199] has joined #radeon
08:20 -!- Nightwulf|work [n=tevers@p5099a8da.dip0.t-ipconnect.de] has quit []
08:20 -!- Nightwulf|work [n=tevers@p5099a8da.dip0.t-ipconnect.de] has quit []
08:20 #radeon: < MostAwesomeDude> soreau: More sleep. Also maybe less work.
08:20 #radeon: < glisse> MostAwesomeDude: i want to take a completely different approach than what we did before
08:21 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
08:21 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
08:22 #radeon: < MostAwesomeDude> glisse: Please fill me in. I'm not a fan of the r600c design.
08:22 -!- bmaass [n=bmaass@188.96.75.171] has joined #nouveau
08:22 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] has quit ["Ex-Chat"]
08:23 #radeon: < MostAwesomeDude> I realize that r600c was rushed, and in that rush, a lot of bad calls seem to have been made. Some of those are avoidable (file names) and some of those are unavoidable (CSO atoms) when moving to Gallium.
08:23 -!- fab [n=bellet@monkey.creatis.insa-lyon.fr] has quit ["Leaving"]
08:23 -!- rhodan_ [n=quassel@81.62.143.187] has quit [Remote closed the connection]
08:23 -!- Zajec [n=opera@77-253-200-80.ip.netia.com.pl] has quit [Remote closed the connection]
08:23 -!- Zajec [n=opera@77-253-200-80.ip.netia.com.pl] has quit [Remote closed the connection]
08:23 #radeon:  * Obscene_CNN gives MostAwesomeDude a jolt cola and a nine volt battery to touch to his tounge :P
08:23 -!- Zajec [n=opera@77-253-200-80.ip.netia.com.pl] has joined #radeon
08:23 -!- Zajec [n=opera@77-253-200-80.ip.netia.com.pl] has joined #nouveau
08:23 #radeon: < glisse> MostAwesomeDude: basicly the idea is to use the object stuff i was talking about on dri-devel ml few month ago and do it in user space so i can switch btw cs ioctl and a new set of ioctl to play with state emission optimization in the kernel
08:24 -!- tmerriam_ [n=quassel@c-67-173-170-177.hsd1.il.comcast.net] has joined #radeon
08:24 -!- rib [n=bob@158.43.2.102] has joined #dri-devel
08:25 -!- darkbasic_ [n=quassel@static-217-133-76-61.clienti.tiscali.it] has joined #radeon
08:25 #radeon: < MrCooper> what's r600c?
08:25 #radeon: < jcristau> classic?
08:25 #radeon: < jcristau> as opposed to gallium
08:26 #radeon: < Tommeh> That would make sense. :)
08:26 #radeon:  * Tommeh did wonder also
08:26 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has quit [Read error: 104 (Connection reset by peer)]
08:26 #radeon: < Tommeh> But I like to listen and learn.. Helps me understand Phoronix's cryptic news articles :)
08:26 #radeon: < jcristau> not reading them works, too
08:27 #radeon: < MostAwesomeDude> glisse: But that would only entail changing the emit, right? The actual state tracking and generation wouldn't be that different.
08:27 #radeon: < Tommeh> It's keeps me vaguely up to date! :)
08:27 #radeon: < glisse> MostAwesomeDude: no the state track/generation will be different
08:27 -!- beyecixramd [n=beyecixr@113.Red-83-49-180.dynamicIP.rima-tde.net] has joined #nouveau
08:27 #radeon: < glisse> in fact it should be a lot simpler
08:28 #radeon: < glisse> you won't try to build packet in the state generation
08:28 #radeon: < MostAwesomeDude> glisse: Well, in current r300g, only thing that would need changing is r300_emit.c, right?
08:28 #radeon: < MostAwesomeDude> Oh.
08:28 #radeon: < MostAwesomeDude> Wait, what.
08:28 #radeon: < MostAwesomeDude> What's wrong with building packets and filling out registers?
08:28 -!- rhodan [n=quassel@81.62.143.187] has joined #radeon
08:28 -!- Welsh_Dwarf [n=quassel@ip-11.net-82-216-143.rev.numericable.fr] has quit [Remote closed the connection]
08:29 -!- ssvb [n=ssvb___@viktor.cosmicparrot.net] has quit ["Leaving"]
08:29 #radeon: < glisse> it doesn't allow to experiment with other API in an efficient way while doing the other way allow you to switch btw cs or other API more easily and also taking advantage of possible optimization
08:31 #radeon: < MostAwesomeDude> Well, I *like* CS, but that's just me.
08:31 -!- bmaass [n=bmaass@188.96.75.171] has quit [Read error: 60 (Operation timed out)]
08:31 -!- ahmedammar [n=b33fc0d3@gentoo/developer/b33fc0d3] has quit [Read error: 54 (Connection reset by peer)]
08:32 #radeon: < MostAwesomeDude> I'd be more interested in a priveleged kernel toggle to disable the CS checker.
08:32 #radeon: < glisse> doesn't allow optimization like resource balancing or avoiding state reemission
08:33 #radeon: < MostAwesomeDude> Well, in a 64k CS, how much state needs to be re-emitted? The experiments so far with atom sizes show that a full re-emit of 2/3rds of the state is only a handful of dwords at most.
08:34 #radeon: < MostAwesomeDude> And that's only once, at the beginning of the CS.
08:34 -!- ttlogic [n=timl@disc-vdh12.disc.utwente.nl] has quit [Remote closed the connection]
08:34 #radeon: < MostAwesomeDude> Maybe if the shaders are bulky... I haven't converted those yet...
08:35 #radeon: < glisse> thing is we flush often and last i check we barely have 64k at all
08:35 #radeon: < MostAwesomeDude> I dunno. I mean, go for it. I'm just not sure that it's worth trying out, but OTOH I'm going to be picky because I don't have the time to spend doing lots of new code.
08:35 #radeon: < glisse> and cs can't allow resource balancing
08:35 #radeon: < glisse> which is i believe one of the thing that might improve perf
08:36 #radeon: < MrCooper> glisse: what do you mean by 'resource balancing'?
08:36 #radeon: < glisse> MrCooper: resource are one of the r6xx family thingy, things as texture of vertex buffer, try to balance allocation btw all the resource should help to avoid changing them and do costly flush
08:37 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
08:37 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
08:38 -!- Hedge|Hog [n=cronic@c83-254-163-45.bredband.comhem.se] has joined #radeon
08:38 #radeon: < MrCooper> glisse: k thanks
08:39 -!- stillunknown [n=stillunk@82-136-228-38.ip.telfort.nl] has joined #nouveau
08:39 -!- stillunknown [n=stillunk@82-136-228-38.ip.telfort.nl] has joined #dri-devel
08:39 #radeon: < MostAwesomeDude> Well, that's really one more level up, isn't it? Gallium should be responsible for avoiding touching BOs once they're out on VRAM.
08:39 -!- mokoloko [n=zxczx@dsl-hkimmlgw8-fe15f800-197.dhcp.inet.fi] has quit [Remote closed the connection]
08:41 -!- luc_ [n=luc@89-115-128-35.cl.ipv4ilink.net] has joined #radeon
08:41 -!- luc_ [n=luc@89-115-128-35.cl.ipv4ilink.net] has joined #radeonhd
08:41 #radeon: < glisse> MostAwesomeDude: it's not only that, it mostly avoiding adding gpu flush
08:41 #radeon: < glisse> but it could be that this won't matter that much
08:41 -!- RAOF [n=RAOF@ppp121-44-229-79.lns20.syd7.internode.on.net] has joined #nouveau
08:42 #radeon: < glisse> once i got my slides ready for fosdem i will make them available, as they are more advantage to the design i am thinking than only some gpu optimization that could be worth it or not
08:42 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has joined #radeon
08:42 #radeon: < MostAwesomeDude> Well, I *know* that being able to disable the kernel CS checker would provide speedups, and I know that RH doesn't want it off by default, so it will require a runtime switch.
08:43 #radeon: < MostAwesomeDude> But I agree that we should look into other things first.
08:43 #radeon: < glisse> MostAwesomeDude: upstream don't want that by default :)
08:43 #radeon: < MostAwesomeDude> glisse: Some upstreams don't want that by default, maybe.
08:43 #radeon: < glisse> also cs checker allow to catch driver ill formated cs :)
08:43 #radeon: < MostAwesomeDude> I'm paid by people that just got shiny new r700s in all their workstations and would be very interested in using them for LAN parties.
08:43 #radeon: < glisse> MostAwesomeDude: i would expect that any distribution do want cs checking for security purpose
08:44 #radeon: < MostAwesomeDude> glisse: Sure, but a way for root to switch that off would be a big speedup.
08:44 #radeon: < MostAwesomeDude> At any rate, I can't go to FOSDEM, sadly, but I am interested in other ways to speed things up.
08:45 #radeon: < glisse> i don't think the speedup would be that big, i did some experiment and i was quite surprise that it didn't seem to get me that much more fps
08:45 #radeon: < MostAwesomeDude> I just want to avoid the kernel being too limiting in what I can do from userspace, and things like the CS checker and legacy packet emit make it tougher.
08:45 #radeon: < MostAwesomeDude> MSPOS is an example.
08:46 #radeon: < glisse> messing with mspos will break ddx rendering if you not carefull :)
08:46 -!- paulez_ [n=paul@ezvan.fr] has joined #radeon
08:46 #radeon: < MostAwesomeDude> I can think of a couple ways to handle it:
08:46 #radeon: < MostAwesomeDude> - make DDX re-emit MSPOS
08:46 #radeon: < _Groo_> hi/2 all
08:46 #radeon: < jcristau> by big speedup you mean big punition for any mesa bug? :)
08:46 #radeon: < _Groo_> im having a nasty pointer bug with latest dri2/mesa/ddx
08:47 -!- phoenix64 [n=phoenix@reactos/tester/phoenix64] has quit [Remote closed the connection]
08:47 -!- phoenix64 [n=phoenix@reactos/tester/phoenix64] has quit [Remote closed the connection]
08:47 -!- otaylor [n=otaylor@66.187.234.199] has quit [Read error: 110 (Connection timed out)]
08:47 #radeon: < _Groo_> in dual head the moise pointer turns into a black/white square whenever i lock the screen
08:47 #radeon: < MostAwesomeDude> - make the MSPOS value something like 6, 5, 7, 4, 8, 2, 9 so GB_AA_CONFIG, already set by DDX, works as expected
08:47 #radeon: < _Groo_> to make it come back in need to force refresh the entire screen with a xrandr rotate for ex
08:47 #radeon: < glisse> MostAwesomeDude: this will need kernel radeon drm version bump
08:47 #radeon: < MostAwesomeDude> glisse: Oh, of course.
08:47 #radeon: < _Groo_> usual rs485 evil card
08:48 #radeon: < _Groo_> is there any way to only force a fresh of the mouse pointer?
08:53 -!- KoH [n=kane@port-92-193-93-100.dynamic.qsc.de] has joined #radeonhd
08:54 -!- RAOF_ [n=RAOF@ppp121-44-59-228.lns20.syd6.internode.on.net] has quit [Read error: 110 (Connection timed out)]
08:56 -!- marvin24 [n=quassel@egonalter-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has joined #dri-devel
08:56 -!- marvin24 [n=quassel@egonalter-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has joined #radeon
08:56 -!- marvin24 [n=quassel@egonalter-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has joined #radeonhd
08:56 -!- Krazubu [n=Krazubu@83-154-8-237.rev.libertysurf.net] has joined #nouveau
08:56 -!- WelshDragon [n=richie@unaffiliated/welshdragon] has joined #nouveau
08:57 #radeon: < DanaG>  phail: http://bugs.freedesktop.org/show_bug.cgi?id=23705#c6
08:57 #radeon: < DanaG> It's a "feature" that xorg LIES.
08:57 #radeon: < DanaG> http://cgit.freedesktop.org/xorg/xserver/commit/?id=fff00df94d7ebd18a8e24537ec96073717375a3f
08:57 #radeon: < DanaG> argh, whoever decided to make this change, should be condemned to forever use a 200 DPI display with OS set to 147 DPI.
08:57 #radeon: < agd5f> MostAwesomeDude: you'll have to fix the ddx to emit mspos for kms
08:58 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has quit ["Leaving."]
08:58 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has quit ["Leaving."]
09:00 #radeon: < lkro> MostAwesomeDude: thanks.
09:02 -!- taiu [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #radeonhd
09:02 -!- taiu [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #dri-devel
09:02 -!- taiu [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #radeon
09:02 -!- anholt [i=anholt@66-233-52-37.war.clearwire-wmx.net] has quit [Remote closed the connection]
09:02 -!- seb__ [n=seb@78.114.208.133] has joined #radeon
09:02 #radeon: < MostAwesomeDude> lkro: No problem. Pushed.
09:02 -!- seb__ [n=seb@78.114.208.133] has joined #dri-devel
09:04 -!- Duke` [n=henry@AVelizy-551-1-45-242.w90-35.abo.wanadoo.fr] has joined #dri-devel
09:07 -!- thansen [n=thansen@c-76-27-110-194.hsd1.ut.comcast.net] has joined #radeon
09:07 -!- Krazubu [n=Krazubu@83-154-8-237.rev.libertysurf.net] has quit [Remote closed the connection]
09:07 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
09:07 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
09:07 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
09:07 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
09:08 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #dri-devel
09:08 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #radeon
09:08 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #radeonhd
09:08 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #nouveau
09:09 -!- otaylor [n=otaylor@nat/redhat/x-xmxdgtptcdnihljk] has joined #radeon
09:09 -!- RSpliet [n=roy@53537511.cable.casema.nl] has joined #nouveau
09:10 -!- bonbons [n=bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d] has joined #dri-devel
09:10 -!- bonbons [n=bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d] has joined #nouveau
09:10 -!- bonbons [n=bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d] has joined #radeon
09:12 -!- Richie [n=richie@87.115.145.235] has quit [Success]
09:15 -!- jpritikin [n=jpritiki@67.51.67.62] has joined #nouveau
09:15 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has quit [Remote closed the connection]
09:15 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has joined #nouveau
09:15 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has joined #radeon
09:15 #radeon: < eosie> glisse: why don't we allow command streams of arbitrary size? the kernel could partition them to several 64k buffers emitted in the given order
09:16 #radeon: < MostAwesomeDude> eosie: Most apps don't actually go all the way up before flushing.
09:16 #radeon: < otaylor> eosie: can the kernel actually partition?
09:16 #radeon: < otaylor> eosie: last I knew each buffer had to have state setup at the front
09:17 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has quit [Remote closed the connection]
09:17 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has quit [Remote closed the connection]
09:17 #radeon: < MostAwesomeDude> otaylor: Only if you allow other buffers in-between.
09:18 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has joined #nouveau
09:18 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has joined #dri-devel
09:19 #radeon: < otaylor> MostAwesomeDude: Yeah, well, then you want to be careful about how many buffers you allow to be queued up from one app (though 64k buffers are a poor proxy for running time once you have shaders, etc.)
09:19 #radeon: < glisse> this is also one of the bonus of objdesign, it easy to split rendering
09:19 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has joined #radeon
09:19 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
09:19 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
09:21 #radeon: < eosie> MostAwesomeDude: BTW if all states are dirty, r300_emit.c might emit about 6500 dwords, most of it are constant buffers and shader instructions
09:21 -!- ossman [n=drzeus@alcatraz.cendio.se] has quit [Remote closed the connection]
09:21 -!- fab [n=bellet@bellet.info] has joined #dri-devel
09:21 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has quit [Remote closed the connection]
09:24 -!- pH5 [n=ph5@e178209060.adsl.alicedsl.de] has joined #radeon
09:24 -!- manitu [n=werner@p578b0cfb.dip0.t-ipconnect.de] has quit ["Verlassend"]
09:25 -!- ralesk [n=ralesk@drangolin.net] has quit [Read error: 60 (Operation timed out)]
09:25 -!- ralesk [n=ralesk@drangolin.net] has joined #radeon
09:26 #radeon: < roysjosh> glisse, ajax, hypothesis: that 1920x1080/138.5M modeline from rhbz 540024 gets dropped because of drivers/gpu/drm/drm_edid.c#636 (printk(KERN_WARNING "integrated sync not supported\n"); return (NULL);).  the monitor sets the 1920x1080/172M one anyway, somehow ([drm:radeon_compute_pll], PLL freq 172780 2 1023, set pll, ...).  those modelines (*without* the 1920x1080/138M one, but with the /172M one) get passed to userspace.  X drops the inva
09:26 #radeon: < roysjosh> lid one.  no 1920x1080.
09:27 -!- cornair [i=d9534d71@gateway/web/freenode/x-zvthwvabnthaszdi] has quit [Ping timeout: 180 seconds]
09:27 #radeon: < roysjosh> in UMS, drm_edid.c#636 -> xserver/hw/xfree86/modes/xf86EdidModes.c#581 which only prints a warning but then adds the mode anyway
09:27 -!- SuperHeron [n=pierre@ip-62-235-197-14.dsl.scarlet.be] has joined #nouveau
09:28 -!- nolan [n=nolan@71.198.47.97] has joined #dri-devel
09:28 -!- nolan [n=nolan@71.198.47.97] has joined #nouveau
09:30 #radeon: < glisse> roysjosh: i think it's a good catch
09:32 #radeon:  * glisse wonders what separate syncs means
09:32 -!- rsleza [n=radek@wireless-244.sci.muni.cz] has quit ["Leaving."]
09:32 -!- gnubien [n=e@unaffiliated/gnubien] has quit ["leaving"]
09:34 -!- aneas [n=aneas@63.wh-keltern.uni-ulm.de] has joined #radeon
09:34 -!- aneas [n=aneas@63.wh-keltern.uni-ulm.de] has joined #radeonhd
09:35 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has joined #radeon
09:36 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
09:36 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
09:37 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has joined #radeon
09:37 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has joined #radeonhd
09:40 #radeon: < _Groo_> could anyone take a look at the mouse pointer corruption with dual head?
09:40 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has joined #radeon
09:40 #radeon: < DanaG> hmm, with radeon UMS, my cursor (and window borders, too) are corrupt.
09:40 #radeon: < DanaG> And I'm on single-head.
09:41 #radeon: < _Groo_> DanaG: ums?
09:42 -!- rouhiai [i=rouhiai2@mustatilhi.cs.tut.fi] has quit [Read error: 60 (Operation timed out)]
09:42 -!- rhodan_ [n=quassel@223-150.3-85.cust.bluewin.ch] has joined #radeon
09:43 #radeon: < _Groo_> DanaG: anyway, corruption only occurs with dual head AND after i activate kde lockscreen (he tries to stretch the screensaver across monitors), when i unlock it, mouse corruption..
09:43 #radeon: < DanaG> hmm, mine is single-head.
09:43 #radeon: < _Groo_> DanaG: i kinda can make it come back after i do some rotates and force the screen to refresh
09:44 #radeon: < _Groo_> DanaG: can you try to enable SWcursor to see if helps?
09:44 #radeon: < glisse> r6xx/r7xx both of you ?
09:44 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has joined #nouveau
09:44 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has joined #radeon
09:45 #radeon: < DanaG> hmm, I'll try swcursor.
09:45 #radeon: < adamk> soreau: FYI, I got alpha blur working on the x850. I had to reset everything in the plugin to it's defaults, except for the Blur Filter (which I left on Gaussian).  And I X can't exceed the maximum texture size.
09:46 #radeon: < DanaG> Right now I'm just griping about this stupidity: http://bugs.freedesktop.org/show_bug.cgi?id=23705 http://cgit.freedesktop.org/xorg/xserver/commit/?id=fff00df94d7ebd18a8e24537ec96073717375a3f
09:46 #radeon: < adamk> soreau: Which sucks because the x850 has a 2048 limit.  Compiz works fine beyond that limit, just not hte blur plugin :-)
09:46 -!- mvo_ [n=egon@p5B09DEA3.dip.t-dialin.net] has quit ["Ex-Chat"]
09:47 #radeon: < soreau> adamk: MostAwesomeDude said it definitely shouldn't be crashing in swrast. I'm not sure if the MTS has any relevancy here
09:47 #radeon: < adamk> If I exceed the MTS, it does not crash using the default settings.  There was something in my specific settings (which I'm not sure I have any more) that caused it to crash.
09:48 #radeon: < soreau> adamk: Obviously it does because you were able to get it working. but I mean what is considered a bug
09:48 #radeon: < adamk> If I exceed the MTS, the blur plugin gives some "invalid framebuffer" error.
09:48 #radeon: < soreau> Oh really...
09:48 #radeon: < soreau> adamk: Framebuffer Incomplete?
09:49 #radeon: < DanaG> REgression on purpose.  bleh.
09:49 #radeon: < adamk> soreau: give me a second,...  I'll see exactly what it says.
09:50 #radeon: < adamk> soreau: Yep...  That was it exactly.
09:50 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has quit [Remote closed the connection]
09:50 #radeon: < adamk> This makes me wonder if it would, in fact, work on r600 with taiu's blit tree with the default settings.
09:51 #radeon: < soreau> adamk: Hmm.. I wonder what's going on here then.. because this is the message I got with 0.9 and I commented out the check in the source where it throws this error and it worked
09:52 -!- leio [n=leio@gentoo/developer/leio] has quit [Read error: 110 (Connection timed out)]
09:52 -!- leio [n=leio@gentoo/developer/leio] has quit [Read error: 110 (Connection timed out)]
09:52 #radeon: < soreau> adamk: I haven't been able to talk to onestone about it but it's possible the difference was if I had S-video out enabled which gives me a total of 2080 and MTS here is 2048..
09:52 #radeon: < soreau> I will have to test this
09:52 -!- idr [n=idr@c-24-21-207-78.hsd1.or.comcast.net] has quit [Read error: 113 (No route to host)]
09:52 #radeon: < rehabdoll> second time X crashed and input froze with the newest rc-kernel
09:52 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has joined #radeon
09:52 -!- MacSlow [n=mirco@unaffiliated/macslow] has quit [Read error: 110 (Connection timed out)]
09:53 #radeon: < glisse> .win 24
09:53 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
09:53 #radeon: < DanaG> hmm, no change with swcursor.
09:53 #radeon: < soreau> adamk: I have to disable S-video to play games or else I get a lock up
09:53 #radeon: < soreau> Well at least et..
09:53 #radeon: < DanaG> ANd I need to get going now.
09:53 #radeon: < adamk> soreau: Here's something for you to test :-)  Enable focus blur.  That seems to be the option that caused the compiz crash.
09:53 #radeon: < soreau> adamk: TBH I haven't thoroughly investigated and I'm horrible about getting around to filing bugs..
09:54 #radeon: < soreau> adamk: I already know focus blur causes a crash
09:54 #radeon: < adamk> Ahhhh.
09:54 #radeon: < adamk> Oh well :-)   Thought I found something new.
09:54 -!- Jonno_ [n=jon@c-4a1fe353.028-32-6c6b7010.cust.bredbandsbolaget.se] has quit [Remote closed the connection]
09:54 #radeon:  * adamk goes and slinks back to the corner, playing with blur.
09:54 #radeon: < soreau> <soreau> adamk: Looks like you're crashing in swrast frag prog too.. are you sure you didn't have focus blur, bicubic filter or motion blur enabled? because I believe those cause the same kind of crash here too
09:55 #radeon: < soreau> not sure if you saw that or not :)
09:55 #radeon: < adamk> No, I didn't.
09:55 #radeon: < adamk> But bicubic filtering does work here, btw.
09:55 #radeon: < soreau> adamk: I think I got a crash on bicubic only when compiz was starting
09:55 #radeon: < adamk> Hmmm.
09:56 -!- mimikry [n=mimikry-@dsl-217-172-250.pool.bitel.net] has joined #radeon
09:56 #radeon: < soreau> I really need to do some more thorough testing and prepare a bug report
09:56 -!- charlie__ [n=charlie@109.82.53.127] has joined #radeon
09:56 -!- andyrtr [n=andyrtr@archlinux/developer/andyrtr] has quit ["Ex-Chat"]
09:57 -!- EdB [n=edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has joined #dri-devel
09:57 #radeon: < adamk> Heh...  Yeah, if I enable the second monitor after starting compiz with alpha blur enabled, the blurred areas are all screwed up.
09:57 -!- charlie__ is now known as twnqx`
09:57 -!- EdB [n=edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has quit [Read error: 104 (Connection reset by peer)]
09:57 -!- EdB [n=edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has joined #dri-devel
09:57 #radeon: < soreau> adamk: Alright, well thanks for the feedback
09:58 #radeon: < adamk> No problem.
09:58 #radeon: < soreau> adamk: Can you say what happens with motion blur btw?
09:58 #radeon: < adamk> That's what I'm here for.  Just took me a little longer to get to than usual :-)
09:58 #radeon: < adamk> Give me a second.
09:58 #radeon: < eosie> glisse: in r300g, every flush costs 1/3 (~6500 dwords) of the CS space in the worst case scenario (the cost of re-emitting all the states), so it might be worth adding support for CS of size e.g. 256kB (splitted in 4 buffers which should be emitted in the given order), significantly reducing wasted CS space
09:58 -!- markinfo [n=marek@dhcp27.dmg.tuwien.ac.at] has quit [Remote closed the connection]
09:59 -!- work|philipp64 [n=chatzill@63.224.43.239] has joined #radeon
09:59 #radeon: < adamk> soreau: Nothing, as far as I can tell.
09:59 #radeon: < _Groo_> hmm confirmed if i do some locks back and forth the mouse input eventually come back...
09:59 #radeon: < soreau> adamk: No output and no effect?
09:59 #radeon: < adamk> Didn't check for output.  Sorry, let's seem
09:59 #radeon: < adamk> see.
09:59 -!- nekschot [i=nekschot@82-171-143-27.ip.telfort.nl] has quit []
10:00 -!- rhodan [n=quassel@81.62.143.187] has quit [Read error: 110 (Connection timed out)]
10:00 #radeon: < work|philipp64> hi. I've got an ASUS M3A78-CM m/b, with a Radeon 3100 controller on it.  I'm having issues getting the displayport working. I RTFM'd, but it didn't have anything on selecting the outputs.
10:00 #radeon: < adamk> soreau: Nope, no output from the motion blur plugin, and no noticable effect.
10:01 -!- trofi [n=slyfox@93.84.110.191] has joined #nouveau
10:01 #radeon: < soreau> adamk: I just checked the source and there's nothing that would output anything in mblur anyway so that's not surprising ;)
10:01 -!- hbbs [i=Hobbes@gateway/gpg-tor/key-0x465B87A8] has joined #radeon
10:01 -!- hbbs [i=Hobbes@gateway/gpg-tor/key-0x465B87A8] has joined #radeonhd
10:01 #radeon: < adamk> Does the plugin actually work for you?
10:02 #radeon: < soreau> adamk: Well.. I tested when I installed 0.8 then I uninstalled it and using 0.9 now which doesn't have mblur ported yet. I will have to install 0.9 to a nonstandard prefix and 0.8 to the main one like I should have it set up anyway :P
10:03 #radeon: < soreau> Best I can recall motion blur either didn't work and didn't do anything or crashed compiz, I'll have to test
10:03 #radeon: < soreau> but this time I will pay attention to the second monitor too
10:03 #radeon: < xming> motion blur was so slow here that the pc almost came to a halt
10:04 #radeon: < xming> and took me few minutes to turn it off
10:04 #radeon: < glisse> eosie: you can test if it helps by increasing the size in kms and libdrm i think this are the only place where there is a check
10:04 #radeon: < work|philipp64> I'm running FC11 updated, which has xorg-x11-drv-ati-6.12.2-14...
10:04 #radeon: < soreau> That means it was falling back to swrast routines but at least it didn't crash compiz obviously ;)
10:04 #radeon: < soreau> xming: ^^
10:04 -!- erghezi [n=quassel@213.207.221.238] has joined #nouveau
10:05 #radeon: < glisse> but 6500 is quite a lot, and there isn't much space left after for a 64K buffer
10:05 #radeon: < work|philipp64> not sure if Option "DefaultConnectorTable" is applicable here.
10:06 #radeon: < MostAwesomeDude> 6500 sounds a bit high.
10:06 #radeon: < soreau> adamk: At least when exceeding MTS with compiz++, I see a lot of artifacts in alpha blurred regions too
10:07 -!- ferr [n=ferr@fibhost-66-64-71.fibernet.hu] has quit [Read error: 113 (No route to host)]
10:07 #radeon: < adamk> Yeah, I think that's to be expected, unfortunately.
10:07 #RadeonHD: < udovdh> http://www.phoronix.com/forums/showthread.php?t=21421&page=2
10:07 #radeon: < glisse> last time i checked one frame of gears needed 920 dwords on r200
10:07 #RadeonHD: < udovdh> mesa builds again
10:08 #radeon: < soreau> adamk: I'm more curious to know if it can be fixed in compiz or if it's a driver bug..
10:08 #radeon: < glisse> iirc i picked the size of ib according to such number
10:08 #radeon: < soreau> adamk: Do you have corruption beyond the MTS on your second screen?
10:08 -!- curro_ [n=z3BxQ@25.104.220.87.dynamic.jazztel.es] has quit [Read error: 104 (Connection reset by peer)]
10:08 -!- curro_ [n=z3BxQ@25.104.220.87.dynamic.jazztel.es] has quit [Read error: 104 (Connection reset by peer)]
10:08 -!- TCW__ [n=TCW@p4FE8F46E.dip.t-dialin.net] has joined #radeon
10:09 -!- andyrtr_laptop [n=andyrtr@f053200058.adsl.alicedsl.de] has joined #nouveau
10:09 -!- mokoloko [n=zxczx@dsl-hkimmlgw8-fe15f800-197.dhcp.inet.fi] has joined #radeon
10:10 #radeon: < adamk> soreau: No, I do not, but I never have with KDE4.  Plasma seems to treat each monitor's background separately, so that they are separate textures.
10:10 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has quit [Read error: 110 (Connection timed out)]
10:10 -!- TCW [n=TCW@unaffiliated/tcw] has quit [Read error: 110 (Connection timed out)]
10:10 -!- curro_ [n=z3BxQ@253.104.220.87.dynamic.jazztel.es] has joined #nouveau
10:10 -!- curro_ [n=z3BxQ@253.104.220.87.dynamic.jazztel.es] has joined #dri-devel
10:10 -!- twnqx [n=charlie@109.82.77.88] has quit [Connection timed out]
10:12 -!- ossman [n=drzeus@82-117-125-11.tcdsl.calypso.net] has joined #radeon
10:12 -!- twnqx` [n=charlie@109.82.53.127] has quit [Read error: 104 (Connection reset by peer)]
10:13 #radeon: < work|philipp64> is there a way to get a list of the names of outputs that the controller supports with xrandr?
10:14 #radeon: < adamk> work|philipp64: Just 'xrandr' should show you all available outputs.
10:14 #radeon: < work|philipp64> ok, so it's only showing me VGA-0 and DVI-0, not the display-port output.  BIOS?
10:14 #radeon: < adamk> As I recall, display port support is brand spankin' new.
10:14 #radeon: < adamk> Well, within the last couple of weeks.
10:14 -!- darkbasic_ is now known as darkbasi
10:14 -!- darkbasi is now known as darkbasic
10:15 #radeon: < _Groo_> could anyone with enough time on their hands why recordmydesktop doesnt work smoothly with radeon anymore
10:15 #radeon: < _Groo_> ?
10:15 #radeon: < work|philipp64> ruh-roh.
10:15 #radeon: < adamk> work|philipp64: Not sure if it requires KMS, but it wouldn't surprise me.
10:15 #radeon: < work|philipp64> sorry, I haven't hacked drivers in 3 years now.  KMS?
10:16 #radeon: < adamk> kernel modesetting.
10:16 -!- gunni_ [n=quassel@xdsl-213-196-229-18.netcologne.de] has joined #nouveau
10:16 -!- gunni [n=quassel@xdsl-81-173-235-170.netcologne.de] has quit [Read error: 60 (Operation timed out)]
10:16 #radeon: < adamk> Most new modesetting work for the radeon driver is now happening in the DRM kernel module.
10:17 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 54 (Connection reset by peer)]
10:17 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 54 (Connection reset by peer)]
10:17 #radeon: < glisse> work|philipp64: it should show display port if you have xf86-video-ati from git
10:18 #radeon: < glisse> display port was added few weeks ago
10:18 #radeon: < adamk> glisse:
10:18 #radeon: < adamk> KMS is not required?
10:18 -!- EdB [n=edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has quit [Remote closed the connection]
10:18 #radeon: < glisse> i think dp is in the ddx too, at least my brain remember a commit about that :)
10:19 #radeon: < MichaelLong> I've still no connection using DP with a DP->DVI-adaptor :/
10:20 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has quit [Read error: 60 (Operation timed out)]
10:20 -!- mschaal [n=Marcel@infedyn131.informatik.uni-stuttgart.de] has quit [Read error: 60 (Operation timed out)]
10:21 -!- MacSlow [n=mirco@unaffiliated/macslow] has joined #nouveau
10:22 -!- amarks_ [n=quassel@124-168-179-31.dyn.iinet.net.au] has joined #radeon
10:24 #radeon: < work|philipp64> glisse: so I'd need to go to the x.org git to get drivers with KMS?
10:24 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)]
10:24 #radeon: < adamk> work|philipp64: You do not need KMS, if his memory is correct.
10:25 #radeon: < adamk> work|philipp64: But you still need xf86-video-ati from git.
10:25 #radeon: < work|philipp64> so what do I need then? do I need to force the display-port on in BIOS?  I have a PCIe RAID controller, and I'm wondering if that might be disabling the displayport output.
10:26 #radeon: < adamk> Errr.. .  You need to compile xf86-video-ati from git and then see if display port works :-)
10:27 #radeon: < work|philipp64> how far behind is 6.12.2 anyway?
10:27 -!- amarks__ [n=quassel@124-171-3-17.dyn.iinet.net.au] has joined #radeon
10:27 #radeon: < work|philipp64> and I just need to rebuild the driver, right? the rest stays the same?
10:27 #radeon: < work|philipp64> or does drm also need to get rebuilt?
10:27 #radeon: < agd5f> work|philipp64: you need xf86-video-ati git master or 2.6.33 for kms
10:28 -!- anholt [i=anholt@66-233-52-37.war.clearwire-wmx.net] has joined #dri-devel
10:28 -!- mode/#dri-devel [+v anholt] by ChanServ
10:28 #radeon: < adamk> work|philipp64: Just the driver update should be fine.
10:28 #radeon: < adamk> (Unless you want to use KMS)
10:28 #radeon: < work|philipp64> I'm running 2.6.30...
10:28 #radeon: < agd5f> MichaelLong: airlied fixed that yesterday update your driver
10:29 #radeon: < MichaelLong> hm
10:29 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
10:29 -!- curro_ [n=z3BxQ@253.104.220.87.dynamic.jazztel.es] has quit [Read error: 104 (Connection reset by peer)]
10:29 -!- curro_ [n=z3BxQ@253.104.220.87.dynamic.jazztel.es] has quit [Read error: 104 (Connection reset by peer)]
10:29 -!- coucouf [n=quassel@seg75-7-88-164-181-178.fbx.proxad.net] has joined #radeon
10:29 #radeon: < agd5f> work|philipp64: you need xf86-video-ati from git master and you have to enable displayport in the bios since it uses pcie lanes
10:29 #radeon: < agd5f> you can't use it with a pcie x16 card
10:30 #radeon: < MichaelLong> tried it a few hours ago, no avail
10:30 #radeon: < agd5f> MichaelLong: file a bug then
10:30 #radeon: < work|philipp64> agd5f: sorry, so if I have a non-display pcie x16 card, displayport won't work?
10:30 #radeon: < agd5f> MichaelLong: if you are using kms, you need an updated drm
10:30 #radeon: < work|philipp64> that is, the RAID controller takes too many bus cycles?
10:30 #radeon: < agd5f> work|philipp64: correct
10:31 #radeon: < agd5f> work|philipp64: the displayport connector uses the pcie lines from the x16 slot
10:32 #radeon: < MichaelLong> xrandr lists the modes of the panel, but any switching does not work. booting with is strange too: the primary laptop panel uses a lower resolution, the external panel is not showing anything
10:32 #radeon: < agd5f> work|philipp64: nothing to do with bus cycles, the physical lines are shared
10:33 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
10:33 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
10:33 -!- curro_ [n=z3BxQ@49.104.220.87.dynamic.jazztel.es] has joined #nouveau
10:33 -!- curro_ [n=z3BxQ@49.104.220.87.dynamic.jazztel.es] has joined #dri-devel
10:33 -!- jedahan [n=jedahan@ool-45714877.dyn.optonline.net] has joined #nouveau
10:33 #radeon: < work|philipp64> ah.  it's a 3ware 9650SE-4LPML...
10:34 #radeon: < _Groo_> new update to the mouse corruption saga, i dont really need to lock the screen, if i stay working with dual channel the mouse will eventually become corrupted, and also eventually will come back to normal... and will switch between the twp states all day.... very strange
10:34 #radeon: < _Groo_> always using the evil rs485 card
10:34 #radeon: < MichaelLong> the strange think while booting is, the laptop is switching to its native resolution (1680x1050) but the console output using a certain resolution aligned to the upper left corner, I guess 1280x1024 or something
10:34 #radeon: < MichaelLong> *thing
10:34 -!- hbbs [i=Hobbes@gateway/gpg-tor/key-0x465B87A8] has quit [Remote closed the connection]
10:34 -!- hbbs [i=Hobbes@gateway/gpg-tor/key-0x465B87A8] has quit [Remote closed the connection]
10:34 #radeon: < agd5f> MichaelLong: kms does clone mode by default
10:34 #radeon: < agd5f> for the console
10:34 #radeon: < agd5f> due to limitations of the kernel fb interface
10:34 -!- Duke` [n=henry@AVelizy-551-1-45-242.w90-35.abo.wanadoo.fr] has quit [Remote closed the connection]
10:35 #radeon: < MichaelLong> yeah ok but the result is strange
10:35 #radeon: < adamk>  Any idea why one port on a radeon x850 would have washed out colors?
10:35 -!- MacSlow [n=mirco@unaffiliated/macslow] has quit ["So long and thanks for the fish!"]
10:35 #radeon: < work|philipp64> agd5f: it's a 4-disk controller, so I'm guessing it's a 4-lane device, right?
10:35 #radeon: < MichaelLong> I would expect either the external display to use the same as the primary, or if it wouldn't fit it shows the output scaled.
10:36 #radeon: < agd5f> work|philipp64: no idea
10:36 #radeon: < work|philipp64> ah, found the data sheet.  yup.  4 lanes.
10:36 -!- amarks [n=quassel@124-168-147-98.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
10:36 #radeon: < agd5f> work|philipp64: but tou can't use it in the pcie x16 slot if you want to use displayport
10:36 #radeon: < work|philipp64> so DP should work then.
10:36 #radeon: < MichaelLong> - it shows
10:36 -!- idr [n=idr@host-243-173.pubnet.pdx.edu] has joined #dri-devel
10:36 -!- mode/#dri-devel [+v idr] by ChanServ
10:36 -!- Duke` [n=henry@AVelizy-551-1-45-242.w90-35.abo.wanadoo.fr] has joined #dri-devel
10:36 #radeon: < work|philipp64> I'll crack the case and see which slot it's in...
10:39 -!- logari811 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
10:40 #radeon: < adamk> Hmmm... Yeah, even after resetting the blur plugin to its default, it doesn't work with the blit code in taiu's mesa branch.
10:40 #radeon: < work|philipp64> yup, it's in the blue slot, not the white one.
10:41 #radeon: < work|philipp64> so I'm SOL.
10:42 -!- amarks_ [n=quassel@124-168-179-31.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
10:42 #radeon: < work|philipp64> I suppose I could get an HDMI PCIe-1 card...
10:42 #radeon: < work|philipp64> any recommendations?
10:43 #radeon: < work|philipp64> (I could use the VGA, but I wanted the built-in speakers to work on my Samsung T240HD... hence the HDMI hook-up.)
10:43 #radeon: < work|philipp64> of course, then I'll probably have to bang my head some more to get sound to work over ALSA.
10:44 -!- rib [n=bob@158.43.2.102] has quit [Read error: 110 (Connection timed out)]
10:45 -!- logari811 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)]
10:45 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #nouveau
10:45 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #radeon
10:45 -!- phenriksson [n=phenriks@h-93-122.A193.priv.bahnhof.se] has joined #nouveau
10:46 -!- sunmoon1997 [n=sunmoon1@58.33.135.45] has quit [Read error: 110 (Connection timed out)]
10:46 -!- sunmoon1997 [n=sunmoon1@58.33.135.45] has quit [Read error: 110 (Connection timed out)]
10:49 #radeon: < work|philipp64> agd5f: I don't get how the architecture can have the bandwidth to drive the VGA at 1920x1200 @ 60Hz, but not have the bandwidth to drive the displayport.
10:49 -!- drago01 [n=linux@chello062178124135.3.13.univie.teleweb.at] has joined #nouveau
10:50 #radeon: < work|philipp64> all we're doing is switching the output encoding.  if we were running 3 channels simultaneously, I would understand.
10:51 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has quit [Remote closed the connection]
10:52 -!- Fuddl [n=fuddl@faui40o.informatik.uni-erlangen.de] has quit ["Leaving."]
10:52 -!- onestone [n=onestone@f048250087.adsl.alicedsl.de] has joined #dri-devel
10:52 -!- onestone [n=onestone@f048250087.adsl.alicedsl.de] has joined #radeon
10:52 -!- onestone [n=onestone@f048250087.adsl.alicedsl.de] has joined #radeonhd
10:53 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
10:54 #radeon: < work|philipp64> so, let me guess, a single-lane PCIe isn't going to have enough bandwidth for a video card.
10:54 -!- _KAMI_ [n=kami@4d6f520d.adsl.enternet.hu] has joined #radeon
10:55 -!- and1bm [n=andi@dslb-088-064-073-186.pools.arcor-ip.net] has quit [Remote closed the connection]
10:58 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Remote closed the connection]
10:58 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Remote closed the connection]
10:58 -!- work|philipp64 [n=chatzill@63.224.43.239] has quit [Remote closed the connection]
10:58 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)]
10:59 -!- bl1nk [i=bl1nk@unaffiliated/bl1nk] has left #nouveau []
11:02 -!- diverse_izzue [n=hunzikea@80.243.127.23] has joined #radeon
11:03 -!- Tureba [i=bb175094@gateway/web/freenode/x-lhcsdmlvbqaptqgy] has joined #nouveau
11:03 -!- rhodan [n=quassel@218-127.0-85.cust.bluewin.ch] has joined #radeon
11:03 #radeon: < wirry> for 2d/video it should be more then enough
11:04 #radeon: < adamk> Alright, these washed out colors are getting annoying.
11:05 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #nouveau
11:05 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #radeon
11:05 -!- logari811 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
11:05 -!- logari811 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit ["Leaving."]
11:05 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
11:05 -!- work|philipp64 [n=chatzill@63.224.43.239] has joined #radeon
11:06 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit [Client Quit]
11:06 -!- kdekorte_ [n=kdekorte@64-187-77-49.iprev.kci.net] has joined #radeon
11:07 -!- jedahan [n=jedahan@ool-45714877.dyn.optonline.net] has quit [Read error: 113 (No route to host)]
11:08 -!- drago01 [n=linux@chello062178124135.3.13.univie.teleweb.at] has quit [Connection timed out]
11:08 -!- maikmerten [n=maikmert@port-92-201-74-147.dynamic.qsc.de] has joined #nouveau
11:09 -!- MAbeeTT_ [n=MAbeeTT@190.179.201.28] has joined #radeon
11:09 -!- MAbeeTT_ [n=MAbeeTT@190.179.201.28] has joined #radeonhd
11:10 -!- MAbeeTT [n=MAbeeTT@190.179.194.97] has quit [Nick collision from services.]
11:10 -!- MAbeeTT [n=MAbeeTT@190.179.194.97] has quit [Nick collision from services.]
11:11 -!- drago01 [n=linux@chello062178124135.3.13.univie.teleweb.at] has joined #nouveau
11:11 #radeon: < adamk> I wonder how I can grab a picture of it.
11:11 #radeon: < soreau> adamk: What washed out colors?
11:12 #radeon: < adamk> One of the monitors is washed out.
11:12 #radeon: < soreau> huh
11:12 #radeon: < adamk> Buttons are indistinguisable from the rest of the window.
11:12 -!- kdekorte__ [n=kdekorte@68-240-152-144.pools.spcsdns.net] has quit [Read error: 60 (Operation timed out)]
11:12 -!- dwmw2_gone is now known as dwmw2_LHR
11:12 #radeon: < adamk> It's specific to the port, and not the monitor.
11:12 #radeon: < work|philipp64> ok, so setting up VGA and DVI outputs then, since I can't use DisplayPort... is there an equivalent to Option "ConnectedMonitor" on the radeon driver?
11:14 #radeon: < adamk> I might have to bring camera into work.
11:14 -!- sk1p [i=alex@p3E9D4255.dip.t-dialin.net] has joined #nouveau
11:14 #radeon: < soreau> adamk: Can't take a pic with your laptop somehow?
11:14 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
11:14 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
11:15 #radeon: < adamk> Hmmm..  Maybe.
11:16 #radeon: < glisse> adamk: maybe the connector or the cable
11:17 #radeon: < adamk> glisse: It only happens with KMS.
11:17 #radeon: < adamk> :-)
11:17 #radeon: < glisse> oh so it's a bug :)
11:17 -!- MAbeeTT_ is now known as MAbeeTT
11:17 -!- MAbeeTT_ is now known as MAbeeTT
11:18 -!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
11:19 -!- stikonas [n=and@bcm-131-111-247-5.girton.cam.ac.uk] has joined #radeon
11:19 #radeon: < adamk> Hopefully I'll have a shot in a second or two.
11:20 #radeon: < soreau> ;)
11:20 -!- andi- [n=andi@2001:470:1f0a:61f:0:0:0:2] has quit [Read error: 104 (Connection reset by peer)]
11:20 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
11:21 -!- wirry [n=wirry@88.130.221.171] has quit ["Lost terminal"]
11:21 -!- wirry [n=wirry@88.130.221.171] has quit ["Lost terminal"]
11:21 -!- markl_ [n=mark@tpsit.com] has joined #radeon
11:21 #radeon: < markl_> how is XvBA looking?
11:22 -!- Sirsurthur [n=julien@162.25.94-79.rev.gaoland.net] has joined #nouveau
11:22 -!- anholt [i=anholt@66-233-52-37.war.clearwire-wmx.net] has quit [Remote closed the connection]
11:22 -!- rhodan_ [n=quassel@223-150.3-85.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
11:23 #radeon: < MostAwesomeDude> Still looking like something we don't care about.
11:23 #radeon:  * Wizzup cares but understands it is not priority
11:23 #radeon: < MostAwesomeDude> Heh, no.
11:23 #radeon: < MostAwesomeDude> The open drivers will never have XvBA.
11:23 -!- andi- [n=andi@2001:470:1f0a:61f:0:0:0:2] has joined #nouveau
11:24 #radeon: < yangman> and no one ever said we would, either
11:24 #radeon: < yangman> no one that you should listen to, anyway >.>
11:24 #radeon: < Wizzup> MostAwesomeDude: Why?
11:24 #radeon: < adamk> glisse, soreau: http://thorn.visualtech.com/without-kms.png http://thorn.visualtech.com/with-kms.png
11:25 #radeon: < adamk> glisse, soreau: Perhaps hard to see, but notice how the color of the articles in liferea alternates on the monitor on the right on both shots, but only alternates on the monitor on the left in the shot without KMS?
11:25 #radeon: < MostAwesomeDude> Wizzup: Because we have no information on it, no interface for it, no way to test it, and no guarantee that it's useful.
11:25 #radeon: < Wizzup> MostAwesomeDude: I take it there is an alternative?
11:25 -!- phoenix64 [n=phoenix@reactos/tester/phoenix64] has joined #nouveau
11:25 -!- phoenix64 [n=phoenix@reactos/tester/phoenix64] has joined #radeon
11:26 #radeon: < yangman> adamk: buggerd LUT?
11:26 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit ["Konversation terminated!"]
11:26 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit ["Konversation terminated!"]
11:26 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #nouveau
11:26 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #radeon
11:26 #radeon: < MostAwesomeDude> Wizzup: At this point, most of us are ready to back VDPAU.
11:26 #radeon: < Wizzup> ok :)
11:26 #radeon: < adamk> I guess it's time to update my kernel.
11:27 -!- amarks [n=quassel@124-168-177-62.dyn.iinet.net.au] has joined #radeon
11:27 -!- GNU_D [n=GNU_D@77.28.196.142] has quit ["Lost terminal"]
11:27 -!- otaylor [n=otaylor@nat/redhat/x-xmxdgtptcdnihljk] has quit [Read error: 110 (Connection timed out)]
11:28 #radeon: < roysjosh> glisse, oops, you beat me to the patch :)
11:28 #radeon: < glisse> roysjosh: yeah i could resumit with you as a signof after all you spoted the bug :)
11:28 -!- EdB [n=edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has joined #dri-devel
11:29 -!- er0x [n=root@client-87-247-122-156.inturbo.lt] has joined #radeon
11:29 #radeon: < roysjosh> glisse, if you want to, I just sent one that looks almost identical to yours :p
11:29 -!- pmdata [i=patrice@ANantes-555-1-50-151.w92-158.abo.wanadoo.fr] has joined #nouveau
11:29 #radeon: < adamk> Bah...  fix conflicts...
11:29 -!- sk1p_ [i=alex@p3E9D4AC5.dip.t-dialin.net] has quit [Read error: 101 (Network is unreachable)]
11:30 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
11:30 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
11:30 #radeon: < adamk> I'll deal with this tomorrow and open up a report if updating the kernel doesn't fix it.
11:30 -!- MAbeeTT [n=MAbeeTT@190.179.201.28] has quit ["leaving"]
11:30 -!- MAbeeTT [n=MAbeeTT@190.179.201.28] has quit ["leaving"]
11:31 -!- MAbeeTT [n=MAbeeTT@190.179.201.28] has joined #radeon
11:31 -!- MAbeeTT [n=MAbeeTT@190.179.201.28] has joined #radeonhd
11:31 #radeon: <@airlied> MostAwesomeDude: lots of other speedups before disabling CS
11:31 #radeon: <@airlied> like hyper-z
11:31 #radeon: <@airlied> we don't do CS on r600/r700 properly yet
11:31 #radeon: < MostAwesomeDude> airlied: This is true.
11:31 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has joined #radeon
11:31 #radeon: < MostAwesomeDude> All true.
11:32 #radeon: < MostAwesomeDude> airlied: Speaking of which, got any new ideas on arbitrating HiZ access?
11:32 -!- gdm_ [n=gdm@190.173.104.128] has joined #nouveau
11:32 -!- amarks_ [n=quassel@124-168-153-183.dyn.iinet.net.au] has joined #radeon
11:32 -!- gdm_ [n=gdm@190.173.104.128] has joined #dri-devel
11:34 -!- rsleza [n=radek@91.143.broadband5.iol.cz] has joined #radeon
11:34 #radeon: < roysjosh> glisse, the /other/ bug that should maybe be fixed is that apparently kms doesn't currently validate modes?  the 172M mode should have been deleted, but instead it got used
11:34 -!- luc_ [n=luc@89-115-128-35.cl.ipv4ilink.net] has quit [Read error: 113 (No route to host)]
11:34 -!- luc_ [n=luc@89-115-128-35.cl.ipv4ilink.net] has quit [Read error: 113 (No route to host)]
11:34 #radeon: < work|philipp64> ouch. setting up a 2nd "device" section apparently caused a stack trace.
11:35 -!- luc_ [n=luc@89-115-128-35.cl.ipv4ilink.net] has joined #radeon
11:35 -!- luc_ [n=luc@89-115-128-35.cl.ipv4ilink.net] has joined #radeonhd
11:35 #radeon: < glisse> roysjosh: yup i was pondering on that
11:36 #radeon: <@airlied> MostAwesomeDude: first come first served that isn't compiz? ;-)
11:37 -!- logari81 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit ["Leaving."]
11:37 #radeon: <@airlied> was thinking we just add an ioctl to see if we can use hyperz, then let the dri driver go by app name to see if it should ask fo rit
11:37 -!- amarks___ [n=quassel@124-168-168-28.dyn.iinet.net.au] has joined #radeon
11:37 #radeon: <@airlied> and blacklist gnome-shell, kwin and compiz
11:37 #radeon: < glisse> airlied: we can do that in mesa
11:38 #radeon: < glisse> i like avoiding new ioctl ;)
11:38 #radeon: <@airlied> glisse: not the arbitration
11:38 -!- illissius [n=illissiu@lg.vezer.elte.hu] has joined #dri-devel
11:38 #radeon: <@airlied> we need to know if soemone else is already using hyper
11:38 #radeon: <@airlied> so we don't have two apps turn it on
11:38 #radeon: < glisse> airlied: my idea was to not ask for hyperz in mesa if we are any of the mentioned app
11:39 #radeon: < MostAwesomeDude> airlied: Sounds like a plan.
11:39 #radeon: <@airlied> glisse: what happens if we run two other apps though?
11:39 -!- calim [n=chr@93.83.4.186] has joined #nouveau
11:39 -!- calim [n=chr@93.83.4.186] has joined #dri-devel
11:39 #radeon: < glisse> i think it's doable
11:39 #radeon: < MostAwesomeDude> Two ioctls, then? One to ask if it's taken, and one to request it?
11:39 #radeon: < MostAwesomeDude> Or one to request, and a couple error codes?
11:39 #radeon: < glisse> well anyway this is an issue only for r1xx-r5xx
11:40 #radeon: <@airlied> MostAwesomeDude: I was just going to use one ioctl, a cmpxchg
11:40 #radeon: < _Groo_> glisse: oh joy more things to break my rs485 XD
11:40 #radeon: <@airlied> since you'd have a race otherwise
11:40 -!- lb__3 [n=lb__3@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
11:40 -!- lb__3 [n=lb__3@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
11:40 #radeon: < MostAwesomeDude> airlied: Good point.
11:40 #radeon: <@airlied> then the CS chcek could block hyper-z regs from other apps
11:41 #radeon: <@airlied> I've gotten hyper-z clears on r100 going again (trivially)
11:41 #radeon: <@airlied> it made gears go lots faster
11:41 -!- amarks__ [n=quassel@124-171-3-17.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
11:42 -!- logari811 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has joined #radeon
11:42 -!- Lutz__Ifer [i=Lutz@p549DC5B5.dip.t-dialin.net] has quit ["born stupid? try again!"]
11:43 -!- BigBrain [n=BigBrain@p57AFF3F5.dip.t-dialin.net] has quit [Remote closed the connection]
11:43 -!- BigBrain [n=BigBrain@p57AFF3F5.dip.t-dialin.net] has quit [Remote closed the connection]
11:43 -!- BigBrain [n=BigBrain@p57AFF3F5.dip.t-dialin.net] has quit [Remote closed the connection]
11:43 -!- flo|linux [n=flo@p54999523.dip0.t-ipconnect.de] has joined #radeon
11:43 #radeon: < glisse> airlied: for the arbitrator it only need to allow glxgears, all other app are useless
11:43 #radeon: <@airlied> glisse: well I want to do CB clears using Z
11:44 #radeon: <@airlied> also for gears ;-)
11:44 -!- amarks__ [n=quassel@124-171-5-109.dyn.iinet.net.au] has joined #radeon
11:44 #radeon: < glisse> everythings we do is for the greaterness of gears :)
11:45 #radeon: <@airlied> I think if we can get fast clears ppl will stop noticed slowdown from DRI1->DRI2
11:45 #radeon: <@airlied> since they only use gears to test
11:45 #radeon: < glisse> we need pageflip also
11:45 #radeon: < glisse> it will ~2 in openarena fullscreen
11:45 -!- amarks____ [n=quassel@124-168-159-224.dyn.iinet.net.au] has joined #radeon
11:45 #radeon: <@airlied> I started writing pageflip kernel stuff
11:45 #radeon: <@airlied> but realised I had real work to do
11:46 -!- rhodan_ [n=quassel@33-233.0-85.cust.bluewin.ch] has joined #radeon
11:46 -!- gdm__ [n=gdm@190.173.76.137] has quit [Read error: 110 (Connection timed out)]
11:46 -!- gdm__ [n=gdm@190.173.76.137] has quit [Read error: 110 (Connection timed out)]
11:46 -!- tigerchen [n=tigerche@ip-95-223-1-210.unitymediagroup.de] has joined #radeon
11:46 #radeon: < glisse> well it seems that beside lockups and beside edid we don't have much bugs left in the kernel
11:47 -!- tigerchen [n=tigerche@ip-95-223-1-210.unitymediagroup.de] has quit [Client Quit]
11:47 -!- amarks [n=quassel@124-168-177-62.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
11:47 #radeon: <@airlied> glisse: yeah I trawled the F12 bugs last night
11:47 #radeon: < MostAwesomeDude> Kernel needs to not refuse drawing when the scissors fully occlude the FB.
11:47 #radeon: <@airlied> not much happening, a couple of s/r fixes
11:47 -!- tigerchen [n=tigerche@ip-95-223-1-210.unitymediagroup.de] has joined #radeon
11:47 #radeon: < MostAwesomeDude> MSPOS needs to not be blocked, as well as any other registers, although I think those are the only ones left.
11:48 #radeon: < MostAwesomeDude> Did the S3TC patches get picked up?
11:48 #radeon: < tigerchen> hi i have a quite strange error message in mz xorg.log
11:48 #radeon: < tigerchen> (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
11:48 #radeon: < tigerchen> [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
11:48 #radeon: < tigerchen> does someone know how to fix this_
11:48 -!- a [i=18113e67@gateway/web/freenode/x-jbfvtjkmibdvdinn] has joined #dri-devel
11:48 #radeon: <@airlied> MostAwesomeDude: yes
11:49 #radeon: <@airlied> MostAwesomeDude: send patches
11:49 -!- flo|linux [n=flo@p54999523.dip0.t-ipconnect.de] has quit [Client Quit]
11:49 #radeon: < MostAwesomeDude> airlied: I've got a patch for the second, not yet for the first. Will send once classes are over.
11:49 #radeon: < tigerchen> i thought it might be a known problem with a simple fix
11:49 #radeon: < MostAwesomeDude> tigerchen: Yeah. Your kernel does KMS. Upgrade your libdrm and DDX.
11:49 -!- lb__3 [n=lb__3@93-34-50-117.ip48.fastwebnet.it] has quit []
11:49 -!- lb__3 [n=lb__3@93-34-50-117.ip48.fastwebnet.it] has quit []
11:50 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
11:50 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
11:51 #radeon: < tigerchen> which version of libdrm would be needed? 2.4.17 is installed here
11:51 -!- amarks_ [n=quassel@124-168-153-183.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
11:51 -!- beyecixramd [n=beyecixr@113.Red-83-49-180.dynamicIP.rima-tde.net] has quit [Remote closed the connection]
11:51 #radeon: < MostAwesomeDude> Did you build it with --enable-radeon-experimental-api?
11:51 -!- cybersphinx_ [n=co@p54A23D19.dip.t-dialin.net] has joined #radeon
11:51 -!- cybersphinx_ [n=co@p54A23D19.dip.t-dialin.net] has joined #radeonhd
11:51 -!- cybersphinx_ [n=co@p54A23D19.dip.t-dialin.net] has joined #dri-devel
11:51 -!- cybersphinx [n=co@p54A2278A.dip.t-dialin.net] has quit [Nick collision from services.]
11:51 -!- cybersphinx [n=co@p54A2278A.dip.t-dialin.net] has quit [Nick collision from services.]
11:51 -!- cybersphinx [n=co@p54A2278A.dip.t-dialin.net] has quit [Nick collision from services.]
11:51 -!- cybersphinx_ is now known as cybersphinx
11:51 -!- cybersphinx_ is now known as cybersphinx
11:51 -!- cybersphinx_ is now known as cybersphinx
11:51 #radeon: < tigerchen> i just emerged it
11:51 -!- anholt [i=anholt@66-233-52-37.war.clearwire-wmx.net] has joined #dri-devel
11:51 -!- mode/#dri-devel [+v anholt] by ChanServ
11:52 #radeon: < kdekorte_> airlied, any chance we'll see mesa 7.8 in F12 or will we probably have to wait for F13?
11:52 -!- aneas [n=aneas@63.wh-keltern.uni-ulm.de] has quit [Remote closed the connection]
11:52 -!- aneas [n=aneas@63.wh-keltern.uni-ulm.de] has quit [Remote closed the connection]
11:53 #radeon: < MostAwesomeDude> tigerchen: Uf. I don't feel like doing Gentoo bugs ATM; go check if --enable-radeon-experimental-api is in the ebuild.
11:53 #dri-devel: <+anholt> idr: oh, looks like we can do rgtc in hw
11:53 -!- shining^ [n=xav@unaffiliated/shining] has quit ["leaving"]
11:53 -!- shining^ [n=xav@unaffiliated/shining] has quit ["leaving"]
11:53 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has joined #dri-devel
11:53 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has joined #radeon
11:53 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has joined #nouveau
11:54 -!- mode/#dri-devel [+v benh] by ChanServ
11:54 #radeon: < tigerchen> MostAwesomeDude: yes, it is
11:55 -!- logari811 [n=kostas@52.Red-83-61-88.dynamicIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)]
11:55 #radeon: < agd5f> work|philipp64: it's not a bandwidth issue.  the tranmitter the displayport connector is tied to is connected to the pcie lines
11:55 -!- amarks___ [n=quassel@124-168-168-28.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
11:56 #radeon: <@airlied> kdekorte_: not in f12 too many depend upgrades for dri2
11:56 #radeon: < agd5f> the other transmitter is tied to the DVI and/or HDMI port
11:56 #radeon: <@airlied> kdekorte_: already in rawhide
11:56 -!- werns [n=hallo@84-74-158-96.dclient.hispeed.ch] has joined #radeon
11:56 #radeon: < kdekorte_> airlied: thanks that is what I expected since it seems like xserver 1.8 is needed to go along with mesa 7.8
11:57 #radeon: < MostAwesomeDude> tigerchen: Then re-emerge the DDX.
11:58 -!- DanaG [n=danag@129.65.40.151] has joined #radeon
11:58 #radeon: < kdekorte_> tigerchen: for some reason I think people had to clean up the libdrm and xorg-x11-drv-ati caches in gentoo to get things to build properly so make sure they are all clean
11:59 #radeon: < kdekorte_> tigerchen: when you build the DDX it should say that KMS is enabled
11:59 #radeon: < work|philipp64> anyone have a barebones xorg.conf for dual-head?
11:59 #radeon: < kdekorte_> work|philipp64: I have dual head an don't use one
11:59 #radeon: < work|philipp64> so... what do you do?
12:00 #radeon: < agd5f> work|philipp64: xrandr
12:00 -!- werns [n=hallo@84-74-158-96.dclient.hispeed.ch] has quit [Client Quit]
12:00 #radeon: < agd5f> work|philipp64: http://wiki.debian.org/XStrikeForce/HowToRandR12
12:00 #radeon: < kdekorte_> work|philipp64: for the most part it just worked, but xrandr or gnome-display-properties was useful
12:00 #radeon: < DanaG> grr, so, how do I set DisplaySize for LVDS in xorg.conf now?
12:01 #radeon: < DanaG> I tried the Monitor-LVDS option... it didn't work.
12:01 #radeon: < agd5f> DanaG: http://wiki.debian.org/XStrikeForce/HowToRandR12
12:01 #radeon: < Jonimus> Arandr is the best xrandr frontend imo
12:01 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has quit [Remote closed the connection]
12:01 #radeon: < DanaG> Since somebody decided it'd be smart to assume that, hey, some monitors have broken EDID... so let's act like they're ALL broken!
12:01 #radeon: < mjg59> DanaG: What?
12:01 -!- Novum [n=Miranda@e180031254.adsl.alicedsl.de] has quit []
12:02 #radeon: < DanaG> http://bugs.freedesktop.org/show_bug.cgi?id=23705
12:02 #radeon: < DanaG> Xorg 1.7.0 is ignoring the real size of the screen, and assuming that absolutely all displays are 96 DPI.
12:02 #radeon: < DanaG> ... which has me really, really angry.
12:02 -!- onestone_ [n=onestone@unaffiliated/onestone] has joined #dri-devel
12:02 -!- onestone_ [n=onestone@unaffiliated/onestone] has joined #radeon
12:02 -!- onestone_ [n=onestone@unaffiliated/onestone] has joined #radeonhd
12:03 -!- amarks__ [n=quassel@124-171-5-109.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
12:03 #radeon: < MostAwesomeDude> DanaG: Wrong channel.
12:03 -!- rhodan [n=quassel@218-127.0-85.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
12:03 #radeon: < MostAwesomeDude> Although ajax can probably snark you from here, too.
12:04 #radeon: < mjg59> DanaG: Oh, right. The core protocol assumes a single DPI, which is inherently broken in a not-insubstantial minority of cases today
12:04 -!- idr [n=idr@host-243-173.pubnet.pdx.edu] has quit [Read error: 110 (Connection timed out)]
12:04 #radeon: < DanaG> Still, it should assume that, at the very least, LVDS is correct.
12:04 #radeon: < mjg59> For your VGA device? Not really.
12:04 #radeon: < agd5f> DanaG: what do you you when you have multiple displays with different DPIs?
12:04 #radeon: < DanaG> Or have a defined, simple option: "IgnoreEDIDDPI"
12:05 #radeon: < DanaG> Beats me on that one -- that shouild be treated differently.
12:05 #radeon: < soreau> I just got compiz motion blur to work with texture copy blur mode
12:05 #radeon: < mjg59> How?
12:05 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has joined #radeon
12:05 #radeon: < soreau> :)
12:05 -!- _KAMI_ [n=kami@4d6f520d.adsl.enternet.hu] has quit [Remote closed the connection]
12:05 #radeon: < ajax> ha ha ha you think LVDS devices reliably tell you their DPI
12:05 #radeon: < DanaG> Not always... but we should at least have a boolean: "DPIIsCorrect" -- or such.
12:05 -!- Novum [n=Miranda@e180031254.adsl.alicedsl.de] has joined #nouveau
12:06 #radeon: < agd5f> DanaG: if you are going to add that option, you might as well just specify a displaysize
12:06 #radeon: < DanaG> Which is better: make the people with non-broken stuff have to override the assumption that things ARE broken... or vice versa?
12:06 #radeon: < mjg59> DanaG: What does the core protocol DPI mean when you have more than one display?
12:06 #radeon: < soreau> heh, using cube + motion blur puts a blue circular frame around the cube
12:07 #radeon: < DanaG> Anyway, what I got when I upgraded to the latest Xorg... is everything really, eye-bleed-inducingly tiny.
12:07 #radeon: < DanaG> And no obvious way to unbreak it.
12:07 #radeon: < kdekorte_> DanaG, why can't you set the DPI in the Gnome Appearance Dialog under the advanced font properties... I'm sure KDE has something similar
12:08 #radeon: < markl_> waaaah i want XvBA
12:08 -!- markl_ [n=mark@tpsit.com] has left #radeon []
12:08 #radeon: < agd5f> DanaG: both that bug and the debian xrandr link have examples to override it
12:08 #radeon: < DanaG> KDE allows 96 and 120, and nothing else.
12:08 -!- a [i=18113e67@gateway/web/freenode/x-jbfvtjkmibdvdinn] has joined #nouveau
12:08 #radeon: < DanaG> I tried that xrandr thing... didn't work.
12:08 #radeon: < DanaG> I'll pastebin xorg.conf and log later.
12:08 #radeon: < kdekorte_> DanaG: sounds like a KDE problem, in gnome I set it to 116 for my laptop
12:08 #radeon: < DanaG> hmm, here's one idea for what to do with multiple displays: assume somewhere in the middle.
12:09 #radeon: < DanaG> if one is 96 and one is 147... assume halfway between the two.
12:09 #radeon: < mjg59> DanaG: Awesome! Cutting the baby in half is always the best solution.
12:09 -!- maikmerten [n=maikmert@port-92-201-74-147.dynamic.qsc.de] has quit [Remote closed the connection]
12:09 #radeon:  * DanaG dares you to use an IBM T221 (200 DPI) with 96 DPI assumed.
12:10 #radeon: < Jonimus> actually the best solution is to assume the dpi of the first monitor
12:10 #radeon: < Jonimus> at least imo
12:10 #radeon: < DanaG> Or try to figure out what sort of monitor the secondary one is.
12:10 #radeon: < MostAwesomeDude> Excellent! Keeping the bigger baby and throwing the other baby out is always the best solution.
12:10 #radeon: < DanaG> if it's a projector, DPI is irrelavant -- you'll want things big.
12:10 #radeon: < ajax> if we could reliably determine that it was a projector, that'd be great
12:10 #radeon: < DanaG> As it is right now, if I have two high-dpi displays... it "throws both babies out", to use the same analogy.
12:10 #radeon: < DanaG> SO that's no better.
12:11 #radeon: < MostAwesomeDude> Well, the correct solution is to return each baby to his mom.
12:11 #radeon: < DanaG> =P
12:11 #radeon: < MostAwesomeDude> Make the DPI awareness one level higher, and leave it up to apps.
12:11 #radeon: < Jonimus> MostAwesomeDude: tahts how it works on my Laptop and it works great, at least its readable on both of them
12:11 #radeon: <@airlied> you need X12 really or a quite good enhancement to X11
12:12 #radeon: <@airlied> so that apps can get DPI for regions
12:12 #radeon: <@airlied> from the compositor if necessary
12:12 #radeon: < Jonimus> the useing the dpi of the first monitor
12:12 #radeon: <@airlied> Jonimus: whats the first monitor?
12:12 #radeon: < Jonimus> my laptop
12:12 #radeon: < Jonimus> or w/e the first detected monitor is
12:12 #radeon: < MostAwesomeDude> Whoo, X12. So all we've gotta do is close out the X11 bugs, and we'll be set.
12:12 #radeon: < DanaG> They should at least make single-monitor case work/
12:13 #radeon: <@airlied> Jonimus: I have ppl who's first monitor is the non-laptop screen
12:13 #radeon: <@airlied> its arbitary
12:13 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has quit [Read error: 104 (Connection reset by peer)]
12:13 #radeon: < DanaG> And the statement that "other environments assume 96" is also incorrect... Win7, out of the box, scaled to 145 (the nearest half-integer scaling).
12:13 #radeon: < ajax> airlied: remember that regions can overlap too
12:13 #radeon: < ajax> cloning loves you
12:14 #radeon: < glisse> only solution is vector rendering ;)
12:14 #radeon: < Jonimus> true which is why I said the first detected mon, in which case on desktops the dpi is useually close anyway
12:14 #radeon: < ajax> Jonimus: "first detected" is arbitrary too, you know.
12:14 #radeon: < ajax> that's entirely up to the scan order that the driver implements.
12:14 #radeon: < DanaG> so, for radeon, what do I set identifier of the "Monitor" section to?
12:14 #radeon: < DanaG> I tried matching "LVDS" -- didn't work.
12:15 #radeon: < DanaG> Option Monitor-LVDS also didn't work.
12:15 #radeon: < Jonimus> LVDS-0 maybe?
12:16 #radeon: < agd5f> DanaG: check your log.  it should say what randr connector is using what monitor section
12:16 -!- onestone [n=onestone@unaffiliated/onestone] has quit [Read error: 110 (Connection timed out)]
12:16 -!- onestone [n=onestone@unaffiliated/onestone] has quit [Read error: 110 (Connection timed out)]
12:16 -!- onestone [n=onestone@unaffiliated/onestone] has quit [Read error: 110 (Connection timed out)]
12:17 #radeon: < xming> tigerchen: emerge -av --oneshot x11-libs/libdrm media-libs/mesa xorg-server xf86-video-ati
12:17 #radeon: < xming> tigerchen: in that order
12:17 -!- shining [n=xav@unaffiliated/shining] has joined #nouveau
12:17 -!- shining [n=xav@unaffiliated/shining] has joined #dri-devel
12:17 #radeon: < DanaG> nvidia has a nicely-named option: UseEDIDDPI.
12:17 #radeon: < DanaG> Perhaps we could just adopt that?
12:17 #radeon: < DanaG> Make it a single boolean, defaulting to true for single-monitor situations.
12:17 -!- rhodan [n=quassel@77-87.203-62.cust.bluewin.ch] has joined #radeon
12:18 #radeon: < agd5f> DanaG: patches welcome
12:18 #radeon: < work|philipp64> agd5f: followed the directions on that web page, but I'm getting the same image on both heads with funky interlacing...
12:18 #radeon: < DanaG> Weirdest EDID I ever saw was a Toshiba laptop, claiming 966x768.
12:18 -!- hnsr [n=hnsr@infinidim.aphax.nl] has quit [Remote closed the connection]
12:18 -!- hnsr [n=hnsr@infinidim.aphax.nl] has quit [Remote closed the connection]
12:18 -!- hnsr [n=hnsr@2001:888:1004:0:0:0:0:1] has joined #radeon
12:18 -!- hnsr [n=hnsr@2001:888:1004:0:0:0:0:1] has joined #dri-devel
12:18 #radeon: < agd5f> work|philipp64: which two heads are you trying to use?
12:18 #radeon: < DanaG> Second weirdest is my CRT, that claims ideal resolution is 1280x1024 (wrong aspect ratio).
12:18 #radeon: < work|philipp64> DVI-D and VGA-0
12:18 #radeon: < mjg59> DanaG: Ha. Ha. Ha.
12:19 #radeon: < kdekorte_> DanaG: I have a CRT that uses that rez
12:19 #radeon: < DanaG> Oh, and that rectangular-pixel plasma monitor.
12:19 #radeon: < kdekorte_> really old sony
12:19 #radeon: < DanaG> Is the actual screen 5:4 ratio?
12:20 #radeon: < DanaG> Mine's 4:3 -- 1280x960 would be correct for it.
12:20 #radeon: < mjg59> Why would that matter?
12:20 #radeon: < mjg59> 1280x1024 was the resolution everyone used
12:20 #radeon: < kdekorte_> Unsure, been awhile since I looked at it
12:20 #radeon: < DanaG> well, either you get letterboxing, or you get squishing.
12:20 #nouveau: < shining> curro_: I updated my 3 box to git head just in case and they were all fine. and no other memleaks found
12:20 #radeon: < DanaG> Whoever designed 1280x1024, must've been on crack.
12:20 #radeon: < kdekorte_> it is a CRT, you can usually adjust some of that out
12:20 #radeon: < work|philipp64> agd5f: http://pastebin.ca/1751410
12:20 -!- jedahan [n=jedahan@ool-45714877.dyn.optonline.net] has joined #nouveau
12:20 -!- ssp [n=ssp@nat/redhat/x-cyinkjjuhanfufsh] has quit ["Passion is a type of fruit"]
12:20 -!- ssp [n=ssp@nat/redhat/x-cyinkjjuhanfufsh] has quit ["Passion is a type of fruit"]
12:21 #radeon: < DanaG> still... if screen is 4:3 and image is 5:4... you're stuck with letterboxing or squishing.
12:21 #radeon: < agd5f> work|philipp64: virtual is way too big
12:21 #nouveau: < shining> for some reasons, I can no longer reproduce the edid cut I had on the nv35 one, that seems gone. I also updated mesa there and it feels slower than before
12:22 #nouveau: < shining> btw is anyone still working on nv30 gallium ? pmdata from times to times ?
12:22 #nouveau: < pmdata> it has been a while since I last touched it, maybe it's broken with all recent mesa changes :)
12:24 #radeon: < agd5f> beyond the hw limits
12:24 #radeon: < work|philipp64> agd5f: I'm using 8 virtual desktops with gnome.
12:24 #radeon: < work|philipp64> are they not related?
12:24 #radeon: < agd5f> work|philipp64: nothing to do with virtual desktops
12:24 #radeon: < DanaG> hmm, another weird EDID I saw on a bug report: claimed some 2000 DPI.  /me wishes such a thing existed. =P
12:24 #radeon: < work|philipp64> ok, so how do I size it then?
12:24 #radeon: < agd5f> that's the size of the screen(s)
12:24 #radeon: < agd5f> themselves
12:24 #radeon: < mjr> (you aren't necessarily stuck, but it'd be a rare thing that all software managed to take into account a non-square pixel aspect ratio)
12:25 #radeon: < agd5f> so 2x 1920x1200 would be 3840 1200 for example
12:25 #radeon: < agd5f> for a left/right config
12:25 #radeon: < zhasha> DanaG: high-res projector + special lens :P
12:27 #radeon: < work|philipp64> agd5f: ok, updated... http://pastebin.ca/1751419
12:27 #radeon: < agd5f> work|philipp64: still doesn't work?
12:28 #nouveau: < pmdata> will need to update everything to check that
12:29 #radeon: < DanaG> hmm, what would one actually expect, for dual displays of different DPI?
12:29 -!- rtcm [n=jman@109.81.54.77.rev.vodafone.pt] has joined #nouveau
12:29 #radeon: < DanaG> That's one reason I can't use dual monitors very well... no external monitors of 147DPI exist!
12:30 #radeon: < kdekorte_> DanaG: yeah I have a 22" display and a 19" display one wide screen one not... consistent DPI between them is an issue
12:32 #radeon: < DanaG> I mean, would it kill the LCD manufacturers to offer a 15", 1920x1200 (or 1920x1080, since they're refusing to do anything but 16:9 nowadays) laptop LCD in a desktop form-factor?
12:32 #radeon: < DanaG> Even if it were a TN panel, it would be better than nothing.
12:33 -!- fmarl [n=francesc@151.62.20.220] has quit [Read error: 110 (Connection timed out)]
12:34 -!- otaylor [n=otaylor@nat/redhat/x-vbkurmibnucywfld] has joined #radeon
12:34 #radeon: < DanaG> Oh, and at least Radeon UMS powersavings is acceptable now.
12:35 #radeon: < DanaG> Though, my windows look like they've been torn out of spiral-bound notebooks... they have little "rippy bits" sort of glitches around the borders.
12:37 -!- bmaass [n=bmaass@188.96.90.16] has joined #nouveau
12:37 -!- maligor [n=maligor@a85-156-209-40.elisa-laajakaista.fi] has joined #radeon
12:37 -!- ajax_ [n=ajackson@nat/redhat/x-dufagrlcirofytgc] has joined #dri-devel
12:37 -!- ajax_ [n=ajackson@nat/redhat/x-dufagrlcirofytgc] has joined #radeon
12:37 -!- ajax_ [n=ajackson@nat/redhat/x-dufagrlcirofytgc] has joined #nouveau
12:37 -!- halfline_ [n=rstrode@nat/redhat/x-orzrcxfjwbumvjdj] has joined #dri-devel
12:37 -!- ajax__ [n=ajackson@nat/redhat/x-ciqdvigcdiekghja] has joined #dri-devel
12:37 -!- ajax__ [n=ajackson@nat/redhat/x-ciqdvigcdiekghja] has joined #radeon
12:37 -!- ajax__ [n=ajackson@nat/redhat/x-ciqdvigcdiekghja] has joined #nouveau
12:38 -!- rhodan_ [n=quassel@33-233.0-85.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
12:39 -!- adamk_ [n=adamk@unaffiliated/adamk] has joined #radeon
12:39 -!- adamk_ [n=adamk@unaffiliated/adamk] has joined #radeonhd
12:39 -!- adamk_ [n=adamk@unaffiliated/adamk] has joined #dri-devel
12:40 -!- halfline [n=rstrode@nat/redhat/x-bhhgxvexpbwoodqd] has quit [Read error: 60 (Operation timed out)]
12:40 #radeon: < DanaG> If some day we can get input redirection, and fancy smart toolkits... we could have everything be truly dpi-independent.
12:41 #radeon: < Jonimus> DanaG: UMS has powersave fuctions?
12:41 #radeon: < DanaG> Yes, basic ones.
12:41 #radeon: < adamk_> soreau, FYI, the x1900 I have has the same issues with alpha blur when using two monitors....  The transparent areas are all screwed up.
12:41 -!- philipp64 [n=chatzill@63.224.43.239] has joined #radeon
12:41 #radeon: < DanaG> Best case, magic scenario: window dangling between two different-dpi displays, would be the same size on both displays, with different-dpi rendering on each side.
12:41 #radeon: < philipp64> agd5f: how about that!
12:41 #radeon: < Jonimus> hmmm that would almost make it worth it to disable KMS on my laptop
12:41 #radeon: < adamk_> soreau, Which is really bizarre considering the x1900 has an MTS of 4096, and I'm nowhere near that.
12:41 -!- kf_ [n=kf@e-corporation.info] has joined #nouveau
12:42 -!- pmdata [i=patrice@ANantes-555-1-50-151.w92-158.abo.wanadoo.fr] has quit ["using sirc version 2.211+KSIRC/1.3.12"]
12:42 #radeon: < philipp64> agd5f: how about that!
12:43 #radeon: < DanaG> Still uses way more power than fglrx, though.
12:43 #radeon: < agd5f> philipp64: got it working?
12:44 #radeon: < philipp64> seem to have.
12:44 #radeon: < philipp64> God, the Dell 2405FPW has truly crappy colors compared to the Samsung.
12:44 #radeon: < philipp64> the "white" is more like eggshell.
12:44 #radeon: < DanaG> I only switched to Radeon with KMS, once I also applied some of that silver thermal paste.
12:44 #radeon: < philipp64> thanks for the help!
12:44 #radeon: < DanaG> s/silver/diamond/
12:44 -!- thaytan [n=jan@131.203.102.171] has quit [Read error: 113 (No route to host)]
12:45 #radeon: < Jonimus> DanaG: nice
12:45 -!- pmdata [i=patrice@ANantes-555-1-50-151.w92-158.abo.wanadoo.fr] has joined #nouveau
12:45 #radeon: < Jonimus> I still might have to switch to fglrx on my laptop for school, though I'd rather not :(
12:46 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has joined #radeon
12:46 -!- albert23 [n=albert@ip4daa4833.direct-adsl.nl] has joined #nouveau
12:46 #radeon: < Jonimus> but I need more than 1HRof battery life.
12:46 #radeon: < soreau> adamk: That's strange.. do you know the max gl size for it? btw, I see motion blur works here with Texture Copy method
12:46 -!- leio [n=leio@gentoo/developer/leio] has joined #dri-devel
12:46 -!- leio [n=leio@gentoo/developer/leio] has joined #radeon
12:48 #radeon: < DanaG> radeon KMS makes my whole system use DOUBLE the power it does with fglrx.
12:48 -!- ajax [n=ajackson@nat/redhat/x-doivlmfizynhhosw] has quit [Read error: 60 (Operation timed out)]
12:48 -!- ajax [n=ajackson@nat/redhat/x-doivlmfizynhhosw] has quit [Read error: 60 (Operation timed out)]
12:48 -!- ajax [n=ajackson@nat/redhat/x-doivlmfizynhhosw] has quit [Read error: 60 (Operation timed out)]
12:49 #radeon: < Wizzup> DanaG: KMS doesn't have power management yet
12:49 #nouveau: < joi> any bored developer who would like to review/apply/push my patches? :D
12:50 #nouveau: < curro_> shining: would you mind trying a small xserver patch for that slowness?
12:50 #radeon: < DanaG> righty-oh.
12:50 -!- LEW21 [n=lew21@zaba.kosson.com] has joined #Radeon
12:51 #radeon: < DanaG> Oh, and UMS is a bit glitchy, and compiz makes mesa exit().
12:51 #radeon: < DanaG> No backtrace, even. =P
12:51 #radeon:  * airlied played with kms pm on laptop, just gliche on gears
12:51 -!- DanaG [n=danag@129.65.40.151] has quit ["Java user signed off"]
12:53 -!- marvin_ [n=marvin@dslb-088-068-108-253.pools.arcor-ip.net] has joined #dri-devel
12:53 #radeon: < philipp64> some explain to me please what's the deal with PCIe16 and display port?  on a laptop, you have two GPU channels and 3 or 4 outputs (LVDS, DVI, VGA, and S-video). you simply choose the channel and match it to an encoder.
12:53 -!- marvin_ [n=marvin@dslb-088-068-108-253.pools.arcor-ip.net] has quit ["Bite my shiny metal ass"]
12:53 #radeon: < philipp64> why doesn't my ASUS desktop motherboard work the same way, were displayport is just another output encoder?
12:54 -!- ajax_ [n=ajackson@nat/redhat/x-dufagrlcirofytgc] has quit [Connection timed out]
12:54 -!- ajax_ [n=ajackson@nat/redhat/x-dufagrlcirofytgc] has quit [Connection timed out]
12:54 -!- ajax_ [n=ajackson@nat/redhat/x-dufagrlcirofytgc] has quit [Connection timed out]
12:55 -!- da1l6 [n=da1l6@port-92-192-68-185.dynamic.qsc.de] has quit [Remote closed the connection]
12:55 #radeon: < agd5f> philipp64: it's just the IGP chips
12:55 #radeon: < agd5f> the rs780
12:56 #radeon: < agd5f> the discrete chips don't use pcie lanes for displays
12:56 #radeon: < philipp64> they have a dedicated bus?
12:56 #radeon: < philipp64> ah. well that's braindead.
12:56 #radeon: < agd5f> philipp64: saves die space and costs.  IGP chips generally don't need two digital outputs
12:57 -!- rhodan_ [n=quassel@113-9.107-92.cust.bluewin.ch] has joined #radeon
12:58 -!- marvin_ [n=marvin@dslb-088-068-108-253.pools.arcor-ip.net] has joined #dri-devel
12:58 #radeon: < adamk_> soreau, Sorry, I don't know the max gl size.  But if MTS is 4096, the maximum gl size has to be at least that.
12:58 #radeon: < agd5f> philipp64: svideo and vga are driven by separate encoders than the digital ones
12:58 #radeon: < philipp64> well, if you're going to have 3 types of digital connection (DP, DVI, HDMI) it's not unreasonable to expect two to be hooked up.
12:58 #radeon: < agd5f> philipp64: most IGP systems don't have 3.  then generally have 1
12:58 #radeon: < agd5f> philipp64: and you can have two hooked up, you just can't use the pcie x16 slit
12:58 #radeon: < agd5f> slot
12:58 #radeon: < philipp64> IGP is integrated graphics processor?
12:58 #nouveau: < curro_> joi: i'll push them tomorrow, unless someone else beats me to it.
12:59 #radeon: < agd5f> philipp64: yes.
12:59 #nouveau: < calim> *sigh* ... I don't find the glArrayDivisor method :-(
12:59 #radeon: < philipp64> so if I've got a PCI and a PCIe-1 slot, can I get HDMI?
12:59 #radeon: < agd5f> philipp64: you can add a PCI or PCIE x1 card
12:59 #radeon: < philipp64> I'm not doing high-bandwidth stuff like video or gaming... I'm just running Firefox, TB, and gnome-terminal.
13:00 #radeon: < philipp64> any suggestions?
13:00 #radeon: < agd5f> philipp64: I think there are some PCI or pcie x1 cards available
13:00 #radeon: < philipp64> I couldn't find any on Amazon, but I only spent 2 minutes.
13:01 #radeon: < philipp64> was looking for a Radeon/ATI card...
13:01 #radeon: < MichaelLong> agd5f, unfortunately very rare
13:01 #radeon: < agd5f> philipp64: check newegg
13:01 #radeon: < philipp64> so I don't have to juggle drivers...
13:02 #radeon: < agd5f> philipp64: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010380048+1069620108&QksAutoSuggestion=&ShowDeactivatedMark=False&Configurator=&Subcategory=48&description=&Ntk=&CFG=&SpeTabStoreType=&srchInDesc=
13:02 #nouveau: < calim> remember I already pushed the 2 mesa-only patches; and I'm a bit against the zero-ioctl-structs just to quieten valgrind
13:02 #radeon: < philipp64> might be easier to find a new m/b that supports DP or HDMI *and* a RAID PCIe16 controller...
13:02 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has quit []
13:02 #radeon: < agd5f> or pci chips: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010380048+1305520549+1069609642&QksAutoSuggestion=&ShowDeactivatedMark=False&Configurator=&Subcategory=48&description=&Ntk=&CFG=&SpeTabStoreType=&srchInDesc=
13:02 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has joined #nouveau
13:03 -!- thaytan [n=jan@ip-210-185-20-158.internet.co.nz] has joined #nouveau
13:03 #radeon: < philipp64> I'll need to disable the onboard graphics, then, I take it?
13:03 #nouveau: < curro_> calim: so am i
13:03 #radeon: < agd5f> philipp64: you don't have to, but it's probably easier
13:04 -!- otaylor [n=otaylor@nat/redhat/x-vbkurmibnucywfld] has quit [Read error: 113 (No route to host)]
13:04 #radeon: < soreau> adamk: I get the same behavior here with alpha blur.. even if I use 1024x768+800x600 which 1824 is well under my MTS of 2048, I still get the alpha blur corruption. So it's not something to do with MTS but something to do with two outputs being enabled..
13:04 -!- marvin24 [n=quassel@egonalter-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has quit [Remote closed the connection]
13:04 -!- marvin24 [n=quassel@egonalter-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has quit [Remote closed the connection]
13:04 -!- marvin24 [n=quassel@egonalter-1-pt.tunnel.tserv6.fra1.ipv6.he.net] has quit [Remote closed the connection]
13:04 #radeon: < philipp64> doesn't say if the DVI is DVI-I or DVI-D
13:04 #radeon: < agd5f> since multi-card support in X is lacking at the moment
13:04 #nouveau: < joi> ok, that's why i put rfc in the subject
13:04 #radeon: < agd5f> philipp64: most discrete cards are DVI-I, most motherbaords are DVI-D
13:04 #radeon: < agd5f> with IGP chips
13:05 #radeon: < xming> or run 2 X :D
13:05 #radeon: < adamk_> soreau, Interesting...  I'd *guess* that it's not a driver issue, then, but a compiz one.
13:05 #radeon: < philipp64> except I have 1 slot.
13:05 #radeon: < adamk_> But who knows?
13:05 #nouveau: < lb1> I'd humbly ask to review/apply my patches too :)
13:05 #nouveau: < pmdata> good, debian sid has xorg 1.7
13:05 #radeon: < soreau> adamk_: It is somewhat perplexing indeed. All's you can do is file bugs and find out ;)
13:06 -!- ajax__ is now known as ajax
13:06 -!- ajax__ is now known as ajax
13:06 -!- ajax__ is now known as ajax
13:06 -!- mode/#dri-devel [+v ajax] by ChanServ
13:06 #nouveau: < lb1> "Correct zsa so_new size" and "nv20-nv40: Add support for two sided color"
13:06 #radeon: < glisse> airlied: wrong color for gears ?
13:06 -!- weechat3 [n=weechat@c83-254-95-123.bredband.comhem.se] has quit [Read error: 110 (Connection timed out)]
13:06 -!- weechat3 [n=weechat@c83-254-95-123.bredband.comhem.se] has quit [Read error: 110 (Connection timed out)]
13:06 #nouveau: < stillunknown> joi: any particalur reason for the resource destroy?
13:06 #radeon: < glisse> it's a material issue
13:06 -!- weechat3 [n=weechat@c83-254-95-123.bredband.comhem.se] has joined #dri-devel
13:06 -!- weechat3 [n=weechat@c83-254-95-123.bredband.comhem.se] has joined #nouveau
13:06 #nouveau: < joi> i wonder if alternatively proposing patchsets as git pulls would be easier for you guys
13:07 #radeon: < glisse> seems fixed upstream for r200
13:07 #radeon: < philipp64> says "dual-link DVI supported: yes".
13:07 #radeon: <@airlied> glisse: r100/r200 suffer that
13:07 #nouveau: < lb1> as well as the kernel fix
13:07 #nouveau: < lb1> darktama: ^
13:07 #nouveau: < Unhelpful> shining: i installed nouveau mesa separately and when i use it as the drivers path i get piles of nouveau driver messages and occasionally different rendering on mesa test programs. hedgewars outputs *no* libGL-related messages when run... with swrast or nouveau dri
13:07 #radeon: <@airlied> haven't had tieme to fix it yet, some state emission issue
13:07 #radeon: <@airlied> it doesn't seem consistent
13:08 #nouveau: < joi> stillunknown: it fixes a leak
13:08 #radeon: < xming> pretty expensive cards
13:08 #nouveau: < stillunknown> lb1: were you the guy who had "reloc while mappped" issues a while back?
13:08 #nouveau: < lb1> yes
13:08 #nouveau: < joi> there are a lot of them in gallium, but it's a start
13:08 #nouveau: < lb1> I think I fixed them
13:08 #nouveau: < lb1> in my local code
13:08 #nouveau: < ymanton> im not at my dev machine as often as id like, otherwise id push a little more often
13:08 #radeon: < glisse> airlied: i was looking at it today
13:08 #nouveau: < lb1> I'll send a patch once finished
13:08 #nouveau: < stillunknown> joi: i mean, why not check for non-NULL from the one case you added?
13:08 #radeon: < glisse> and it solved by itself somehow
13:08 -!- red_hell_ita [n=rosso@host159-93-dynamic.14-87-r.retail.telecomitalia.it] has quit [Remote closed the connection]
13:08 #radeon: <@airlied> glisse: yeah same thing happened me
13:09 #nouveau: < ymanton> push patches on the mailing list that is
13:09 #radeon: <@airlied> I thoughtg I'd fixe d it
13:09 #radeon: < soreau> adamk_: Hmm.. it's working now after I enabled detect outputs, restarted compiz and changed the resolution.. though now a portion of my first screen is duplicated on the second one with a lesser resolution
13:09 #radeon: < glisse> so i am not crazy :)
13:09 #radeon: < adamk_> soreau, Yeah, but what do *you* think? :-)  You're certainly more familiar with it than I am.  Open up a bug report in Freedesktop for radeon or one in the compiz bug tracker?
13:09 #radeon: < adamk_> Odd.
13:09 #radeon: < adamk_> I'll try that in a few.
13:09 #nouveau: < shining> curro_: sure, always :)
13:09 #radeon: < agd5f> airlied: IIRC, r200 has a quirk where you have to emit texture units in pairs even if you are only using an odd number
13:09 #nouveau: < stillunknown> it's a chicken and egg problem imo, i'd prefer feedback from others and others are (i guess) waiting for it too?
13:09 #radeon: < agd5f> otherwise you get hangs
13:09 #radeon: < soreau> adamk_: I think from what I'm experiencing it is more likely a compiz oddity
13:10 #radeon: <@airlied> agd5f: yeah I think the kernel messed up with that
13:10 #radeon: <@airlied> I need to plug in my 8500LE again
13:10 #radeon: <@airlied> the mesa driver does the right thing
13:10 #nouveau: < stillunknown> but i can pick up on one or two of the patches (the subchan leak and the flush notify one)
13:10 #nouveau: < joi> stillunknown: "one case"? there are 9 calls
13:10 #nouveau: < stillunknown> later this evening
13:11 #radeon: < agd5f> airlied: should probably commit this patch as well: http://bugs.freedesktop.org/show_bug.cgi?id=25544
13:11 #nouveau: < stillunknown> joi: 6 of those worked with _free
13:11 #nouveau: < joi> _free does not free the last resource
13:11 #nouveau: < curro_> shining: what X server commit are you on?
13:12 #nouveau: < stillunknown> lb1: so all those messages are gone for you?
13:12 #nouveau: < lb1> yes as far as I can see
13:12 #nouveau: < shining> curro_: 1.7.3.902
13:12 #nouveau: < lb1> basically the problem is that we emit relocations of flush
13:12 #nouveau: < lb1> and that may be a relocation of a mapped vertex buffer
13:12 #nouveau: < lb1> due to an unrelated surface_copy/fill
13:12 #nouveau: < stillunknown> that's the problem i was thinking of
13:13 #nouveau: < stillunknown> since nv50 had that issue too
13:13 #nouveau: < lb1> solution is to only set a flag on flush
13:13 -!- taiu [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
13:13 -!- taiu [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
13:13 -!- taiu [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
13:13 -!- marvin_ [n=marvin@dslb-088-068-108-253.pools.arcor-ip.net] has quit ["Bite my shiny metal ass"]
13:13 #nouveau: < lb1> and emit relocations in draw calls depending on flags set
13:13 #nouveau: < lb1> (actually, a bitmask of flags)
13:13 #nouveau: < lb1> however, in the process I also discovered that primitive splitting is totally broken
13:14 #nouveau: < lb1> so I'm fixing that too
13:14 #nouveau: < stillunknown> this was the solution for nv50 in case you're interested
13:14 #nouveau: < stillunknown> http://cgit.freedesktop.org/mesa/mesa/commit/?id=c306ef5e81da5456d39a6e98cfc1f5f00b9c77a7
13:14 #nouveau: < shining> lb1: btw I just noticed your "Print NOUVEAU_NO_SWIZZLE and NOUVEAU_NO_TRANSFER messages only once" patch was not applied either
13:14 #radeon: < soreau> adamk_: Here for now, enabling detect outputs allows it to work
13:14 #nouveau: < lb1> yes
13:14 #nouveau: < lb1> that also would be useful
13:14 #radeon: < philipp64> agd5f: oh, damnation.  when I click on the desktops in the taskbar on Gnome, it switches the displays on both monitors. I wanted to have one be fixed (for email and IRC), and have the other one switch between different server connections.
13:14 #nouveau: < lb1> as well as the vertex/index buffers in VRAM
13:15 #radeon: < philipp64> oh, well.
13:15 #nouveau: < lb1> that's a bit more problematic because we don't really know on which chipset/systems it should be turned off by default
13:15 #nouveau: < lb1> that nv50 fix  seems ugly
13:15 -!- Droste1 [n=droste@p57905EDA.dip.t-dialin.net] has quit [Remote closed the connection]
13:15 -!- _Groo_ [n=Paulo@200-161-0-143.dsl.telesp.net.br] has quit [Read error: 104 (Connection reset by peer)]
13:15 -!- Sirsurthur [n=julien@162.25.94-79.rev.gaoland.net] has quit [Client Quit]
13:16 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Remote closed the connection]
13:16 #nouveau: < lb1> I think the "only set flags on flush" is better
13:16 #nouveau: < lb1> as we also don't need to relocated framebuffer/textures if we are doing 2D
13:16 #nouveau: < stillunknown> lb1: what flags?
13:16 #nouveau: < calim> we should put STATIC_DRAW vbufs in VRAM, STREAM_DRAW ones in GART; and you'd also have to emit relocs on CLEAR (if RT did not change)
13:16 #nouveau: < lb1> a new need_relocs bitmask
13:17 -!- EdB [n=edb@tss37-1-89-84-18-220.dsl.club-internet.fr] has quit [Remote closed the connection]
13:17 #nouveau: < lb1> if, for a given state atom, the dirty flag is not set, but need_relocs is set, then we just emit relocations
13:17 #radeon: < agd5f> philipp64: that's a desktop environment config issue
13:17 -!- Droste [n=droste@p57905EDA.dip.t-dialin.net] has joined #radeon
13:17 #radeon: < adamk_> soreau, It's already enabled here.
13:17 #nouveau: < lb1> and on flush, I just set the need_relocs flags
13:17 #nouveau: < lb1> that's the modification I made in my code
13:17 #nouveau: < calim> and you cannot only emit relocs on draw call, if draw flushes multiple times ...
13:17 #radeon: < soreau> adamk: Well afaict, it's the way compiz is handling things because I see other parts of the screen in the alpha blur rendering (not what's actually under it)
13:17 #nouveau: < lb1> for each flush, I check that
13:18 #nouveau: < lb1> the flush only happen at controlled points
13:18 #nouveau: < stillunknown> flushed can happen in the middle of setup
13:18 #radeon: < adamk_> Right, same here.
13:18 #nouveau: < lb1> no
13:18 #nouveau: < lb1> we check the pushbuffer remaining value to determine how many primitives to send
13:19 #nouveau: < stillunknown> per stateobject yes
13:19 #nouveau: < stillunknown> but not for a whole state emit
13:19 #nouveau: < lb1> and before putting the vertices/elemets, relocations are emitted if necessary
13:19 #nouveau: < lb1> first I do the state emit
13:19 #nouveau: < lb1> then the relocation checking
13:19 #nouveau: < lb1> actually, I emit the state once
13:20 #nouveau: < stillunknown> are you using nouveau_stateobject?
13:20 #nouveau: < lb1> and then for each pushbuffer worth of vertices/elements, I emit relocations
13:20 #radeon: < adamk_> But at least it blurs :-)
13:20 #nouveau: < lb1> state objects are used like in the current code
13:21 #nouveau: < stillunknown> i still don't see how you are making sure that every state object is emitted without a flush somewhere
13:21 #nouveau: < lb1> well
13:21 #nouveau: < lb1> I check for emitting relocations after emitting dirty state objects
13:21 -!- rhodan [n=quassel@77-87.203-62.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
13:21 #nouveau: < lb1> and I think I check there is enough space to emit all possible relocations
13:22 #nouveau: < lb1> yes I do
13:22 -!- fab [n=bellet@bellet.info] has quit ["Leaving"]
13:22 #nouveau: < lb1> then, a BEGIN_END is emitted followed by vertex indices
13:22 #nouveau: < lb1> and the number of vertices is determined so that everything fits in the pushbuffer
13:22 #nouveau: < lb1> using nouveau_vbuf_split
13:22 -!- SiaCo [n=thorbjor@cm-84.211.172.13.getinternet.no] has quit []
13:22 #nouveau: < stillunknown> our vertex buffer (nv50) is in a so
13:22 #nouveau: < lb1> (actually, a fixed version of that function)
13:23 #nouveau: < lb1> ah ok
13:23 #nouveau: < lb1> nv30/nv40 is different
13:23 #radeon: < philipp64> click on title bar of window, select "always on visible workspace"
13:23 #nouveau: < lb1> btw, is nv50 ok with you switching the vertex buffer address in the middle of vertices?
13:23 #nouveau: < lb1> are you seem to be doing?
13:23 #nouveau: < lb1> on nv40 that doesn't work
13:23 #nouveau: < stillunknown> no, a stateobject (on it's own) will check for sufficient space
13:24 #nouveau: < stillunknown> but in between stateobjects you might have flushes
13:24 #nouveau: < lb1> what if all the vertices don't fit into a 16384 byte pushbuffer?
13:24 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has quit ["Leaving."]
13:24 -!- MarcOChapeau [n=MarcOCha@bgn92-4-82-238-213-101.fbx.proxad.net] has quit ["Leaving."]
13:24 #nouveau: < lb1> oh ok
13:24 #nouveau: < curro_> lb1: i would rather fix it for real instead of pushing the VBOs in VRAM workaround
13:24 #nouveau: < ymanton> calim: gallium needs stream/static_draw type flags, closest is texture_usage_dynamic atm
13:24 #nouveau: < kf_> hi all, I am rebuilding my kernel to do a mmiotrace for the power saving part of nouveau, I added the mmio tracer, anything else I might be missing?
13:24 #nouveau: < lb1> curro_: no fix is known unfortunately
13:24 #nouveau: < stillunknown> lb1: i think that would result in a reloc failure
13:25 #nouveau: < lb1> ?
13:25 #nouveau: < stillunknown> let me check the code, i don't look there every day
13:25 #nouveau: < lb1> stillunknown: on nv40, we split primitives to fit in a 16384 byte pushbuffer
13:25 #nouveau: < lb1> and that's necessary
13:25 #nouveau: < lb1> unless we want to allocate a new arbitrarily large pushbuffer on demand
13:26 -!- DanaG [n=dana@pcp038606pcs.dhcp.calpoly.edu] has joined #radeon
13:26 #nouveau: < lb1> or change the kernel to pin the vertex buffer across multiple pushbuffer calls
13:26 #radeon: < DanaG> http://pastebin.com/f44219873
13:26 #radeon: < DanaG> xorg log.
13:26 #nouveau: < lb1> I vaguely read the nv50 code
13:26 #nouveau: < stillunknown> for nv50 we have vertices in bo's it seems
13:26 #nouveau: < lb1> vbo code seems ok because it needs only one dword
13:26 #radeon: < DanaG> http://pastebin.com/f6b6adc06
13:26 #radeon: < DanaG> xorg.conf.
13:27 #nouveau: < lb1> what happens however if it tries to send millions of vertices in immediate mode?
13:27 #nouveau: < lb1> is having a flush in the middle ok?
13:27 #nouveau: < lb1> (flush -> possible change of vertex buffer/framebuffer due to TTM having moved it)
13:28 #nouveau: < lb1> curro_: the current workaround makes things work
13:28 -!- leio [n=leio@gentoo/developer/leio] has quit [Remote closed the connection]
13:28 -!- leio [n=leio@gentoo/developer/leio] has quit [Remote closed the connection]
13:28 #nouveau: < lb1> curro_: and I don't think it's so bad: it should just result in the vertices being moved to the card by M2MF instead of by the vertex fetcher
13:29 #nouveau: < lb1> curro_: and if the vertex buffer is reused, being in VRAM should be an advantage
13:29 #radeon: < agd5f> DanaG: [    0.039843] (II) RADEON(0): Output LVDS using monitor section Monitor-LVDS
13:29 #nouveau: < lb1> curro_: (shouldn't we set the NOUVEAU_BO_VRAM in addition to NOUVEAU_BO_GART anyway?)
13:29 #nouveau: < stillunknown> lb1: i don't know, i would suspect it's fine, why would it not?
13:30 #radeon: < agd5f> so looks like a kde issue.
13:30 #radeon: < agd5f> check xdpyinfo or xrandr for the display size
13:30 #nouveau: < lb1> yes, probably
13:30 #nouveau: < lb1> seems nv50 has no begin_end like pre-nv50
13:30 #radeon: < DanaG> gdm is also tiny.
13:30 #nouveau: < lb1> on pre-nv50, vertices must be sent between begin and end
13:31 #nouveau: < lb1> and if you change vertex buffers in between, the hardware reports an error
13:31 #radeon: < DanaG> oh. I tweaked it again (renamed my monitor section to just plain "lvds".
13:31 #radeon: < DanaG> Looks like it IS a kde issue now, after all.
13:31 #nouveau: < stillunknown> so guard it with a WAIT_RING and do it in chunks?
13:31 #nouveau: < lb1> oh
13:31 #nouveau: < lb1> yes
13:31 #radeon: < DanaG> thanks.
13:31 #nouveau: < lb1> nv50 has NV50TCL_VERTEX_BEGIN and NV50TCL_VERTEX_END
13:31 #nouveau: < stillunknown> just do BEGIN_RING a few times
13:31 #nouveau: < lb1> does a vertex buffer change in between work?
13:32 #nouveau: < lb1> on nv40, you get a pgraph error
13:32 -!- mroconnor [n=MarcO@unaffiliated/mroconnor] has quit ["leaving"]
13:32 #nouveau: < stillunknown> this is immediate mode
13:32 #nouveau: < curro_> lb1: that doesn't mean it doesn't exist, and this is not a production opengl driver, IMHO the odds that the right solution will be discovered are better if we leave it broken.
13:32 #nouveau: < stillunknown> why is a verte buffer involved?
13:32 #nouveau: < lb1> curro_: how about adding the patch, but not enabling by default anywhere?
13:32 #radeon: < DanaG> I do think it would be nice to have a simpler "UseEDIDDPI" option.
13:32 #radeon: < DanaG> hmm, what WOULD be expected behavior for multiple monitors of different DPI?
13:32 #nouveau: < lb1> stillunknown: ok, right
13:33 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has joined #nouveau
13:33 #nouveau: < lb1> stillunknown: but you can still have immediate indices with a vbo, right?
13:33 #nouveau: < stillunknown> a vertex buffer is state setup, but small
13:33 #radeon: < DanaG> Seems like a "damned if you do, damned if you don't" situation.
13:33 #nouveau: < lb1> stillunknown: and how about framebuffer/fragtex changes?
13:33 #nouveau: < stillunknown> immediate mode is a lot, but you split it up into chunks
13:33 #nouveau: < lb1> nv40 also rejects those within begin/end
13:33 #nouveau: < lb1> and do a begin/end around each chunk?
13:33 #nouveau: < curro_> lb1: IMHO if you're skilled enough to use nouveau 3d, you're skilled enough to move your VBOs to VRAM by yourself
13:34 #nouveau: < stillunknown> lb1: you have to WAIT_RING for how much you need and expect flushes anywhere else
13:34 #radeon: < DanaG> http://pastebin.com/f768de0f2
13:34 #radeon: < agd5f> DanaG: also, a lot of people think thinks look correct at 96 dpi and we get bug reports when we used the actual dpi
13:34 #radeon: < agd5f> s/thinks/things/
13:34 #radeon: < DanaG> A boolean option, then, would be good.
13:34 #nouveau: < lb1> curro_: well, it would help not having to manage having the patch in your git branches and not upstream :)
13:34 #radeon: < DanaG> hmm, weird... log still says 96, but xdpyinfo shows correct 147.
13:35 #nouveau: < lb1> stillunknown: yes I know
13:35 #radeon: < agd5f> DanaG: ignore the log
13:35 #radeon: < DanaG> Hmm, perhaps do what Windows does, and round to the nearest half-integer multiple?
13:35 #nouveau: < stillunknown> so yes, split it up in chunks of 2048 or 4096 bytes and close it with an END
13:35 #radeon: < DanaG> I can see why 108 should assume 96, though.  Good point there.
13:35 #nouveau: < lb1> stillunknown: reading the nv50 code, it seems it only uses a single begin/end pair
13:36 -!- lkro [n=lkro@16-mo6-4.acn.waw.pl] has quit ["WeeChat 0.2.6.1"]
13:36 -!- twnqx [n=charlie@188.132.21.13] has joined #radeon
13:36 #nouveau: < stillunknown> i meant 2048 or 4096 vertices
13:36 #nouveau: < lb1> stillunknown: the 2047 splitting is only because BEGIN_RING has a 2047 limit
13:36 #nouveau: < lb1> however, that means you can have flushes between NV50TCL_VERTEX_BEGIN
13:36 #nouveau: < lb1> and NV50TCL_VERTEX_END
13:36 #nouveau: < stillunknown> lb1: it hasn't blown up yet
13:36 #nouveau: < stillunknown> as far as i know
13:36 #nouveau: < lb1> thus your framebuffer and vertex buffer can change between NV50TCL_VERTEX_BEGIN and NV50TCL_VERTEX_END
13:37 #nouveau: < lb1> on nv40, it causes a pgraph error
13:37 #nouveau: < lb1> it triggers quite rarely
13:37 #nouveau: < lb1> the buffers will not usually be moved
13:37 #nouveau: < lb1> and thus the relocations may be nops
13:37 #nouveau: < lb1> the code may still be broken though
13:37 #nouveau: < lb1> it would be useful to remove NOUVEAU_BO_DUMMY from relocations
13:37 #nouveau: < lb1> then emit them manually in the draw calls
13:38 #nouveau: < lb1> and see if dmesg shows any error
13:38 #nouveau: < lb1> if that fails, you will need to either:
13:38 #radeon: < DanaG> Hmm, and when you change screen resolution on a fixed-size panel... should DPI change?
13:39 #nouveau: < lb1> 1. split primitives like nv30/nv40 does (the current is currently severely broken though, testing a fix now)
13:39 #nouveau: < lb1> 2. allocate on demand a new pushbuffer large enough to fit all immediate mode vertices
13:39 #nouveau: < curro_> shining: http://annarchy.freedesktop.org/~currojerez/dont_always_copy_from_front.patch
13:39 -!- SuperHeron [n=pierre@ip-62-235-197-14.dsl.scarlet.be] has quit ["Ex-Chat"]
13:39 #nouveau: < lb1> 3. change the kernel to keep buffers reserved across multiple pushes
13:39 #nouveau: < joi> just an idea: maybe it would be useful to add some "buffer move injection" to stress test nouveau?
13:39 #nouveau: < lb1> yes
13:39 #nouveau: < lb1> it would be useful
13:39 #nouveau: < lb1> maybe it can be done at the TTM level
13:40 -!- bmaass [n=bmaass@188.96.90.16] has quit [Remote closed the connection]
13:40 -!- mimikry [n=mimikry-@dsl-217-172-250.pool.bitel.net] has quit ["Verlassend"]
13:40 #nouveau: < lb1> move all buffers before each pushbuffer submission
13:40 #nouveau: < lb1> also maybe ping-pong between vram and gart
13:41 #nouveau: < curro_> joi: you can just force a smaller VRAM size to get a similar effect :P
13:41 #nouveau: < lb1> (with some way to turn it on/off per-process, so that the X server remains usably fast)
13:42 #nouveau: < stillunknown> lb1: i don't see why vertex splitting is so hard
13:42 #nouveau: < joi> curro_: i could if i would knew how :)
13:42 #nouveau: < lb1> stillunknown: you need to split primitives
13:42 #nouveau: < lb1> if you have a triangle fan, you need to re-emit the first vertex in each chunk
13:42 #nouveau: < lb1> if you have a line loop, you need to re-emit the first vertex in the last batch to close it
13:43 #nouveau: < lb1> and so on
13:43 #nouveau: < curro_> lb1: heh, even the core mesa splitting helpers are somewhat broken :)
13:43 #nouveau: < lb1> the current code is broken for everything except triangles and triangle strip
13:43 -!- diverse_izzue [n=hunzikea@80.243.127.23] has quit ["Ex-Chat"]
13:43 #nouveau: < lb1> the nouveau ones are almost totally broken
13:43 #nouveau: < curro_> yeah
13:43 #nouveau: < lb1> except for the triangles/triangle strip cases
13:43 -!- trofi [n=slyfox@93.84.110.191] has quit [Remote closed the connection]
13:43 #nouveau: < lb1> which is why you may not notice that
13:44 -!- trofi [n=slyfox@93.84.110.191] has joined #nouveau
13:44 #nouveau: < lb1> I'm testing a fixed implementation right now
13:44 #nouveau: < lb1> unless, of course, we want to got with the "allocate new pushbuffer which is big enough" route
13:44 #nouveau: < lb1> to go
13:44 #nouveau: < stillunknown> that won't scale
13:44 #nouveau: < lb1> primitive splitting is a bit tricky, but relatively simple anyway
13:45 #radeon: <@airlied> esp with panel scalers
13:45 #nouveau: < stillunknown> but it's not a high priority issue either, so i'll wait for the splitting code :-)
13:45 -!- moeSizlak [n=m0eSizla@pool-98-117-162-201.bflony.fios.verizon.net] has joined #radeon
13:45 #nouveau: < lb1> and possibly faster than buffer allocation
13:45 -!- bonbons [n=bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d] has quit ["Leaving"]
13:45 -!- bonbons [n=bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d] has quit ["Leaving"]
13:45 -!- bonbons [n=bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d] has quit ["Leaving"]
13:45 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
13:45 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
13:45 -!- Ronis_BR [n=Ronan@200-181-80-67.bsace705.dsl.brasiltelecom.net.br] has joined #radeon
13:45 #radeon: <@airlied> if you don't center vs full scalin gshould the DPI change
13:45 #nouveau: < curro_> joi: nouveau_mem.c:482
13:45 #radeon: < twnqx> but you don't know if the panel WILL scale :P
13:46 #nouveau: < stillunknown> lb1: mesa isn't my main thing, i just occasionally help here and there
13:46 #radeon: <@airlied> well you can tell the scaler to scale or not
13:47 #radeon: < twnqx> there usually are two scalers, the one in the GPU, and the one in the panel
13:47 #radeon: < Ronis_BR> airlied: hello fellow, can you tell me if you do any modifications that can make hibernation possible with KMS?
13:47 #radeon: < twnqx> i doubt the GPU can even read the scaler options from the panel
13:47 #radeon: < twnqx> Ronis_BR: it "works for me" with an older version
13:47 #nouveau: < lb1> maybe nv50 supports the changes between begin/end though
13:47 #radeon: < twnqx> any 2.6.32rc or newer will not correctly wake up, though
13:47 #radeon: < Ronis_BR> twnqx: I got ring test fail on every resume
13:48 #radeon: < DanaG> weird thing I saw on an intel gpu in Windows today: I told it to give 128x768 (apparently they've never heard of 1280x800), but the panel reported it was getting 1280x1024.
13:48 #nouveau: < stillunknown> there is one misterious case of disappearing textures randomly, so i will persue it eventually
13:48 #radeon: < twnqx> i'm on 2.6.31.6 + drm-next dated nov 17
13:48 #radeon: < twnqx> ddx from same day
13:48 #radeon: <@airlied> Ronis_BR: wierd it works for me, still using tuxonice? or not
13:48 #radeon: < Ronis_BR> airlied: no
13:48 #radeon: < Ronis_BR> airlied: and I got the same problem :(
13:48 #radeon: < twnqx> but i have to compile KMS as a module. won't work with static linkage
13:49 #radeon: < Ronis_BR> airlied: without KMS everything works
13:49 -!- Eythan [n=Eythan@AMontpellier-554-1-82-48.w92-145.abo.wanadoo.fr] has quit ["Leaving"]
13:49 -!- Eythan [n=Eythan@AMontpellier-554-1-82-48.w92-145.abo.wanadoo.fr] has quit ["Leaving"]
13:49 #nouveau: < lb1> curro_: where are the mesa/gallium primitive splitting helpers?
13:50 #radeon: < glisse> Ronis_BR: you are using somethings special for hibernation ? it does work here
13:50 #radeon: < glisse> well at least last time i tried
13:50 #radeon: < Ronis_BR> glisse: anything, just pm-utils
13:50 #radeon: < Ronis_BR> glisse: I'm using R700 (HD3200)
13:50 #nouveau: < lb1> currently my code should handle everything except POLYGON is wireframe mode
13:50 #radeon: < Ronis_BR> and I got ringtest fail
13:50 #radeon: < glisse> HD3200 IGP ?
13:50 #nouveau: < lb1> which needs to be able to set edgeflags
13:50 #radeon: < Ronis_BR> I have tested with many options
13:50 #radeon: < Ronis_BR> glisse: what?
13:50 #nouveau: < lb1> so that the split diagonals don't show up
13:50 #radeon: < glisse> motherboard integrated gpu
13:51 #radeon: < Ronis_BR> 01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics]
13:51 #radeon: < Ronis_BR> yes
13:51 #nouveau: < lb1> (it's a rather remote case tough)
13:51 #radeon: < Ronis_BR> it is a laptop
13:51 #nouveau: < stillunknown> calim fixed edgeflags on nv50 as far as i've heard
13:51 #nouveau: < curro_> lb1: src/mesa/vbo/vbo_split.c and friends
13:52 #nouveau: < lb1> they are mesa-specific though
13:52 #radeon: < glisse> yeah we got a bug on those
13:52 #nouveau: < lb1> and also seem to lack triangle fan and line loop support
13:53 #radeon: < glisse> it's on my check list but it might be tricky without the hw
13:53 #radeon: < Ronis_BR> hum, ok :)
13:53 #nouveau: < lb1> and they don't seem to handle wireframe polygon correctly
13:53 #radeon: < Ronis_BR> good it isn't just here
13:53 -!- farbing [n=farbing@141.18.176.98] has joined #radeon
13:53 -!- farbing [n=farbing@141.18.176.98] has joined #dri-devel
13:53 #nouveau: < curro_> lb1: ISTR they handled fans
13:53 #nouveau: < lb1> ah yes
13:54 #nouveau: < lb1> it's in vbo_split_copy
13:54 #radeon: < Ronis_BR> glisse: I can help in testing
13:54 #nouveau: < lb1> it works differently than what we want though
13:54 #nouveau: < lb1> but nouveau_vbuf_split may be moved in gallium/auxilliary
13:54 #nouveau: < lb1> there is nothing nouveau specific there
13:56 #nouveau: < lb1> (what we want is a zero-copy version of course)
13:57 -!- silverthorn [n=silverth@78-72-71-195-no33.tbcn.telia.com] has quit ["Lämnar"]
13:57 -!- danvet [n=daniel@cable-static-49-187.intergga.ch] has quit [Remote closed the connection]
13:57 -!- diverse_izzue [n=hunzikea@80.243.127.23] has joined #radeon
13:58 #radeon: < DanaG>      
13:58 #radeon: < DanaG> OpenGL version string: 2.0 Mesa 7.8-devel
13:58 #radeon: < DanaG> OpenGL shading language version string: 1.10
13:58 #radeon: < DanaG> er, sorry about the extra newline.
13:58 #radeon: < DanaG> finch doesn't deal as well with pastes as pidgin does.
13:58 -!- p_bp [n=p_v@peonia.teteny.elte.hu] has joined #radeon
13:58 -!- Ronis_BR [n=Ronan@200-181-80-67.bsace705.dsl.brasiltelecom.net.br] has quit [Remote closed the connection]
13:58 -!- p_bp [n=p_v@peonia.teteny.elte.hu] has joined #radeonhd
14:00 #radeon: < glisse> roysjosh:
14:00 #radeon: < glisse> oups Ronis is gone ..
14:00 #radeon: < glisse> sorry roysjosh
14:01 -!- LordBurrito [n=jseymour@jimsun.linxnet.com] has quit ["Leaving IRC - dircproxy 1.0.5"]
14:01 #nouveau: < curro_> lb1: btw, i've been thinking on adding a sequence number to DRI2 __DRIdrawableRec's that would be incremented each time the backing renderbuffers change, does that somehow affect that EGL stuff you've been doing?
14:01 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
14:01 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
14:02 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has joined #dri-devel
14:02 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has joined #radeon
14:02 -!- ThibG [n=ThibG@abo-58-5-68.ech.modulonet.fr] has quit ["http://thibg.dyndns.org/jabber-irc.xml"]
14:02 -!- mcgreg [n=mcgreg@mnsr-4db0b691.pool.mediaWays.net] has joined #radeon
14:02 #radeon: < mcgreg> hi
14:03 -!- Duke` [n=henry@AVelizy-551-1-45-242.w90-35.abo.wanadoo.fr] has quit ["Connexion reset by bear"]
14:04 #radeon: < mcgreg> since yesterday (or so) mesa doesnt compile here anymore -> http://pastebin.org/76422
14:04 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 60 (Operation timed out)]
14:04 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 60 (Operation timed out)]
14:04 -!- sequemis2 [n=detriage@d142-179-241-173.abhsia.telus.net] has quit [Connection timed out]
14:04 -!- terracon [n=greisky@CPE001cf097a750-CM0012254076d6.cpe.net.cable.rogers.com] has quit [Read error: 104 (Connection reset by peer)]
14:05 -!- KoH [n=kane@port-92-193-93-100.dynamic.qsc.de] has quit ["freeing unimportant sockets, needed for DoS"]
14:05 -!- mark_n [n=mark@nat/ibm/x-jsdainoxxuljshil] has joined #radeon
14:05 -!- trofi [n=slyfox@93.84.110.191] has quit [Read error: 60 (Operation timed out)]
14:06 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
14:06 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
14:06 -!- PsyMan [n=NONE@ppp-94-65-154-96.home.otenet.gr] has quit []
14:07 #nouveau: < lb1> __DRIdrawableRec is only used by the GLX/DRI code
14:07 #nouveau: < lb1> basically it would be the GLX/DRI stack version of what I proposed for the egl_g3d stack
14:07 #radeon: < glisse> mcgreg: make realclean, ./autogen.sh and update you dri2 proto
14:11 -!- idr [n=idr@host-250-218.pubnet.pdx.edu] has joined #dri-devel
14:11 -!- mode/#dri-devel [+v idr] by ChanServ
14:11 #radeon: < mcgreg> glisse, you were right, thank you
14:11 -!- mcgreg [n=mcgreg@mnsr-4db0b691.pool.mediaWays.net] has quit [Remote closed the connection]
14:13 #nouveau: < calim> in *immediate* mode we push vertices on the FIFO, and it is irrelevant if vbufs change location, we map and read them out
14:13 #nouveau: < calim> on nv50 I mean, we don't split vbufs
14:14 #nouveau: < calim> you can have a flush though if you use indices, but that is optimally solved by "call"ing index buffers
14:15 #nouveau: < lb1> what if you are doing immediate index submission?
14:16 #nouveau: < lb1> however, if you force an index buffer for large enough primitives, I think you can indeed avoid flushing inside primitives without having to do splitting
14:17 #nouveau: < lb1> that won't work for pre-nv50 though, as hw index buffers may not be supported, and vertex buffers can only be submitted in 256-vertex batches
14:17 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Remote closed the connection]
14:17 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Remote closed the connection]
14:17 #nouveau: < calim> for immediate index submission where indices are not GPU accessible, well, I almost suspect you *can* change VBO address on the fly, let me test
14:17 #nouveau: < lb1> on nv40, you can't
14:17 #nouveau: < lb1> if you change it between begin and end, you get a pgraph error
14:18 -!- phoenix64 [n=phoenix@reactos/tester/phoenix64] has quit [Remote closed the connection]
14:18 -!- phoenix64 [n=phoenix@reactos/tester/phoenix64] has quit [Remote closed the connection]
14:18 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #nouveau
14:18 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #radeon
14:18 #nouveau: < lb1> also check if other relocations work (framebuffers, fragtex, fragprog?)
14:18 #nouveau: < calim> but for nv50, *I really don't care*, because we shouldn't be emitting relocs at all
14:19 #nouveau: < calim> ok, I care in that I'm interested in whether it would work
14:19 #nouveau: < curro_> calim: how is the vm coming?
14:20 #nouveau: < curro_> lb1: but maybe you could still use a "your renderbuffers are no longer valid" event from the X server
14:20 -!- pmdata [i=patrice@ANantes-555-1-50-151.w92-158.abo.wanadoo.fr] has quit [Remote closed the connection]
14:20 #nouveau: < calim> curro_: well, keeping constant virtual VRAM addresses is easy, that I have working
14:20 #nouveau: < lb1> why? aren't they necessary for ttm buffer moves? or you are you using the on-GPU mmu for that?
14:21 #nouveau: < calim> for GART, and doing page allocation, I'm still fighting with TTM about how to do it, but I'm not putting too much time into it; I want to get geomprogs, instanced rendering, conditional render, the new compiler ... into mesa too
14:22 -!- farbing [n=farbing@141.18.176.98] has quit [Read error: 104 (Connection reset by peer)]
14:22 -!- farbing [n=farbing@141.18.176.98] has quit [Read error: 104 (Connection reset by peer)]
14:23 #nouveau: < calim> (although I expect I won't be content with the compiler and trash it)
14:24 #nouveau: < calim> all these nice new feature branches in gallium ... I
14:25 -!- rhodan [n=quassel@140-156.3-85.cust.bluewin.ch] has joined #radeon
14:25 #radeon: < tmerriam_> ddxSigGiveUp?
14:26 #nouveau: < calim> lb1: yes the GPU mmu should be used, although moves from VRAM to GART can't keep the same address, but that should be avoidable (blob btw. always copies vertex data to VRAM as faras I've seen)
14:27 #nouveau: < lb1> really?
14:27 #nouveau: < lb1> does it copy to vram on all hardware, even pre-nv50?
14:27 -!- haole [n=ivan@189.35.26.237] has joined #radeonhd
14:27 #nouveau: < lb1> because we don't, but on card not copying to vram causes corruption
14:27 #nouveau: < calim> I haven't looked at any pre-nv50 renouveau traces; except in immediate mode of course
14:28 #RadeonHD: < haole> hello there... can't get radeonhd's glx to work under gentoo... got this error in Xorg.0.log: (EE) GLX error: Can not get required symbols..... how can i debug and solve this?
14:28 #nouveau: < lb1> how do I tell if it's moving to vram?
14:29 #nouveau: < lb1> I se
14:29 #nouveau: < lb1> I see
14:29 #nouveau: < lb1> NV40TCL.DMA_VTXBUF0 = NV01_MEMORY_LOCAL_BANKED
14:29 #nouveau: < lb1> is this vram?
14:29 #nouveau: < calim> on nv50 you can tell because it uses a virtual address >= 0x40000000, which is a VRAM page directory; for pre-nv50 I don't know
14:29 -!- pmdata [i=patrice@ANantes-555-1-50-151.w92-158.abo.wanadoo.fr] has joined #nouveau
14:30 -!- gnubien [n=e@unaffiliated/gnubien] has joined #radeonhd
14:31 #nouveau: < lb1> curro_: maybe my vertex/index buffer in VRAM hack is actually the correct/optimal solution?
14:32 -!- guymann [n=charlie@69.182.31.199] has joined #nouveau
14:32 #nouveau: < pmdata> arg, need dri2 2.2 proto stuff
14:32 -!- paulez_ [n=paul@ezvan.fr] has quit [Read error: 60 (Operation timed out)]
14:33 -!- twnqx [n=charlie@188.132.21.13] has quit [Connection timed out]
14:33 #nouveau: < shining> 22:38 < curro_> lb1: IMHO if you're skilled enough to use nouveau 3d, you're skilled enough  to move your VBOs to VRAM by yourself
14:34 #nouveau: < lb1> yeah
14:34 #nouveau: < lb1> but according to calim the blob always moves to vram on nv50
14:34 -!- bertrik [n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl] has quit ["De groeten"]
14:34 #nouveau: < calim> lb1: I suppose it depends on the DMA object, NvObectTypes says DMA engine, nV FB -> nV FB; looks like VRAM; but I have the same name for nv50 dmaobjs too
14:34 #nouveau: < lb1> if that's the case on other cards too, maybe we should do too by default
14:34 #nouveau: < shining> using nouveau 3d is easy :) but I have no idea how to move vbos to vram . I dont use nv40 anyway
14:35 #nouveau: < shining> pmdata: yup
14:35 -!- itzamna [n=itzamna@i111060.upc-i.chello.nl] has joined #nouveau
14:35 #nouveau: < calim> lb1: it shouldn't be necessary, at least on nv50 you would have nothing in GART except for transfers if you'd have to copy them there
14:35 -!- itzamna [n=itzamna@i111060.upc-i.chello.nl] has joined #radeon
14:37 #nouveau: < lb1> why is that? if textures don't fit in VRAM, shoudn't they stay in GART memory?
14:37 #nouveau: < calim> nv50 can't texture from GART
14:37 #nouveau: < lb1> ah ok
14:38 #nouveau: < calim> at least not with tiled textures, we haven't tried to find out how to setup untiled ones yet, blob doesn't show us, except in CUDA
14:38 -!- drago01 [n=linux@chello062178124135.3.13.univie.teleweb.at] has quit ["Verlassend"]
14:38 #RadeonHD: < yangman> haole: all the libraries are up-to-date?
14:38 #RadeonHD: < haole> probably... i've just installed it... let me get you the versions, yangman
14:38 #nouveau: < calim> anyway, copying stuff to VRAM if it's not going to stay there a while will be slow I think
14:39 #RadeonHD: < yangman> pastebin your X log, actually. would be more useful
14:39 #RadeonHD: < haole> radeonhd is 1.3.0
14:39 #RadeonHD: < haole> ok
14:39 #RadeonHD: < yangman> and are you running KMS?
14:39 -!- spstarr [n=spstarr@kde/developer/spstarr] has joined #radeon
14:39 #nouveau: < pmdata> dri2 2.2 done, need updated glproto now
14:39 -!- spstarr [n=spstarr@kde/developer/spstarr] has quit [Client Quit]
14:40 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has quit []
14:40 #RadeonHD: < haole> don't know... how do i check?
14:40 #nouveau: < calim> lb1: btw, on nv50, if you reloc a user buffer (the kind that's discarded after draw) to GART or VRAM (kalloc, map, memcpy) you get a pile of garbage too
14:40 #RadeonHD: < haole> yangman, xorg.0.log: http://pastebin.com/d6a2b2976
14:40 #RadeonHD: < yangman> they you're not. don't worry about it
14:41 #RadeonHD: < yangman> *then
14:41 #nouveau: < lb1> is the reason of this known?
14:42 #nouveau: < calim> no ... and things like "wbinvd" before push buffer submission don't change anything (except cutting frame rate to 1/10)
14:42 #RadeonHD: < yangman> do you have the radeon kernel module installed?
14:43 #RadeonHD: < haole> don't know... i tried to uncheck things related to ati
14:43 #RadeonHD: < haole> is there an easy way to check?
14:43 #RadeonHD: < haole> i'm sorry, i'm a little noob with xorg stuff
14:43 #RadeonHD: < yangman> dmesg | grep radeon
14:43 #nouveau: < lb1> nv40 uses NV_DMA_IN_MEMORY for vbos
14:43 #nouveau: < calim> I eventually yielded and added immediate mode submission for user buffer vertices, which made things a lot faster too
14:43 #RadeonHD: < yangman> you need to have ATI Radeon support in your kernel, under Direct Rendering Manager
14:43 #RadeonHD: < yangman> compile it as a module
14:44 -!- rhodan_ [n=quassel@113-9.107-92.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
14:44 #nouveau: < curro_> lb1: IIRC VRAM VBOs were somewhat slower for most common use cases, i don't remember how much exactly
14:44 #nouveau: < lb1> is that vram or not?
14:44 #RadeonHD: < haole> i have CONFIG_DRM_RADEON=m... is that enough?
14:44 #RadeonHD: < yangman> should be
14:44 #RadeonHD: < yangman> is it loaded? check lsmod
14:45 #nouveau: < curro_> lb1: if it's vram, it will be the same handle as e.g. DMA_ZETA
14:45 #RadeonHD: < haole> what's the name of the module?
14:46 #RadeonHD: < yangman> lsmod is the command that outputs the list of loaded kernel modules
14:46 -!- erghezi [n=quassel@213.207.221.238] has quit [Read error: 110 (Connection timed out)]
14:46 #RadeonHD: < haole> i know, i just don't know what to look for :(
14:46 #RadeonHD: < haole> lsmod |grep drm shows no output
14:46 #RadeonHD: < yangman> 'radeon' is the name of the module
14:46 #RadeonHD: < haole> lsmod |grep radeon too
14:46 #RadeonHD: < yangman> load it manually
14:47 #nouveau: < lb1> NV40TCL.DMA_ZETA = NV01_MEMORY_LOCAL_BANKED
14:47 #RadeonHD: < haole> it loaded!! why doesn't my this do this automagically? :)
14:47 #nouveau: < lb1> so it's vram
14:47 #RadeonHD: < haole> well, gonna test... if it doesn't work i'll come back later... thanks, man
14:47 #RadeonHD: < yangman> it should, technically
14:47 #RadeonHD: < yangman> not really sure why it doesn't for some people
14:47 #nouveau: < pmdata> oh, I only have 550 fps now in gears :)
14:47 -!- haole [n=ivan@189.35.26.237] has quit ["Saindo"]
14:47 #nouveau: < curro_> lb1: look at the handles, not the classes
14:48 #nouveau: < joi> stillunknown: i don't understand your request, what's wrong with these patches?
14:48 #nouveau: < pmdata> no visible regression in xmoto
14:48 #nouveau: < lb1> beef0201    NV40TCL.DMA_ZETA = NV01_MEMORY_LOCAL_BANKED
14:48 #nouveau: < stillunknown> normally when you commit patches, you become author and there will be a few extra lines in the patch
14:48 #nouveau: < lb1> beef0202    NV40TCL.DMA_VTXBUF0 = NV01_MEMORY_LOCAL_BANKED
14:48 #nouveau: < lb1> beef0201    NV40TCL.DMA_VTXBUF1 = NV01_MEMORY_LOCAL_BANKED
14:48 #nouveau: < lb1> 8f6a5580    NV40TCL.VTXBUF_ADDRESS[0] = DMA1=TRUE | OFFSET=0x0f6a5580
14:49 #nouveau: < lb1> thus, vram, it seems
14:49 #nouveau: < lb1> correct?
14:49 #nouveau: < lb1> all have DMA1=TRUE
14:49 #nouveau: < shining> pmdata: no perf regression in xmoto ?
14:49 #nouveau: < lb1> in renouveau traces taken from my machine
14:49 #nouveau: < pmdata> still running perfectly :)
14:50 #nouveau: < lb1> and DMA_VTXBUF[0|1] is always set that way
14:50 #nouveau: < shining> pmdata: I need to benchmark it to be sure. will do so tomorrow
14:50 -!- leio [n=leio@gentoo/developer/leio] has joined #dri-devel
14:50 -!- leio [n=leio@gentoo/developer/leio] has joined #radeon
14:51 #nouveau: < joi> stillunknown: you want me to remove From and Subject from the body of message?
14:51 #nouveau: < curro_> lb1: yeah, it would also be nice if you benchmarked it
14:51 #nouveau: < pmdata> as long as it runs, it's ok for me, did not compare performance
14:51 #nouveau: < stillunknown> joi: no, there should be more
14:51 #dri-devel: < Wallbraker> There mesa_7_7_branch merged to master.
14:51 #nouveau: < lb1> the blob uses immediate submissions for non-VBO though
14:51 #dri-devel: < Wallbraker> Hopefully I didn't break anything
14:52 #nouveau: < ymanton> lb1: check the dumps of nv40s that dont have this problem
14:52 #nouveau: < joi> stillunknown: i still don't understand
14:52 #nouveau: < lb1> which ones are known to not have it?
14:52 #nouveau: < lb1> (i.e. which is yours if you don't have it?)
14:52 #nouveau: < ymanton> nv4a
14:52 #nouveau: < stillunknown> joi: maybe i'm confused
14:52 #nouveau: < ymanton> id check it myself if i was at home
14:53 #dri-devel: < Wallbraker> darktama: just FYI, the dri fake front buffer revert landed in master now.
14:53 #dri-devel: < Wallbraker> We are working on a more proper fix for 1.7 servers now
14:53 #nouveau: < pmdata> I have some strange/random texture corruption in ioquake3
14:53 #nouveau: < shining> pmdata: yeah it runs, it just felt a bit slower, and I am not even sure, so ignore it for now :) does oa complain with a lot of bad argument with TX_FORMAT ?
14:53 #dri-devel: < darktama> yes I noticed :)
14:53 #nouveau: < joi> stillunknown: i just saved one mail and applied it with git am
14:53 #nouveau: < stillunknown> joi: i hate whitespace issues, sorry for the trouble
14:53 #dri-devel: < Wallbraker> MostAwesomeDude: and finaly, I enabled r300g by default on master.
14:54 #dri-devel: < Wallbraker> darktama: ok good, just wanted to give you a heads up.
14:54 #nouveau: < stillunknown> i was convinced the author was explicitly listed
14:54 #nouveau: < pmdata> warsow fills the kernel log with many errors (and no window displayed)
14:54 #dri-devel: < Wallbraker> I think we figgured out a good way to solve it. We use your fix if buffersWithFormats is present.
14:54 -!- a [i=18113e67@gateway/web/freenode/x-jbfvtjkmibdvdinn] has quit ["Page closed"]
14:54 -!- a [i=18113e67@gateway/web/freenode/x-jbfvtjkmibdvdinn] has quit ["Page closed"]
14:54 #dri-devel: < Wallbraker> Just needs to get around to code it.
14:55 #nouveau: < curro_> lb1: so, if the blob itself doesn't use gart VBOs, IMO that's a point for your patch
14:55 #nouveau: < lb1> well, yes
14:55 #nouveau: < lb1> however, it may not do so because GL VBOs are usually reused and thus it makes sense to put them in varm
14:56 #nouveau: < lb1> while non-VBOs are put in pushbuffer
14:56 #nouveau: < pmdata> openarena, yes many nSource: DATA_ERROR, nStatus: BAD_ARGUMENT Class 0x0397 Mthd 0x1a04
14:56 #nouveau: < lb1> if this causes the blob to never use gart, it may actually be an hardware bug that nVidia didn't notice
14:57 -!- osiris [n=quassel@azt243.neoplus.adsl.tpnet.pl] has joined #dri-devel
14:57 -!- osiris [n=quassel@azt243.neoplus.adsl.tpnet.pl] has joined #radeon
14:57 -!- osiris [n=quassel@azt243.neoplus.adsl.tpnet.pl] has joined #radeonhd
14:59 #nouveau: < shining> pmdata: btw how does one usually investigate this ? can I simply grep where this method is used (nv30_fragtex_build ?) and make this part more verbose ?
15:00 #nouveau: < pmdata> I suppose yes
15:00 -!- jsgf [n=jeremy@dsl-203-33-163-122.NSW.netspace.net.au] has joined #dri-devel
15:01 #nouveau: < shining> what does that mean Data data2:data ? what are the two parts ?
15:01 #nouveau: < calim> lb1: I just tried, I can change VBO address between NV50TCL_VERTEX_BEGIN and END
15:01 #nouveau: < lb1> great
15:01 #nouveau: < lb1> you are lucky to have a sane architecture :)
15:02 -!- UnNamed [i=500@16.Red-80-32-164.staticIP.rima-tde.net] has joined #radeon
15:02 #nouveau: < pmdata> shining: they are the values sent in the fifo. Now need to check why 0x03392629 is an invalid value for NV30TCL_TX_FORMAT
15:03 #nouveau: < pmdata> must leave
15:03 -!- pmdata [i=patrice@ANantes-555-1-50-151.w92-158.abo.wanadoo.fr] has quit [Remote closed the connection]
15:03 #radeon: < UnNamed> hi, one doubt about shading, does r300 do it in hw? only one light supported? i ask because blender speed goes down for shaded mode, while wire or (flat) textured seem faster
15:04 -!- deavid [n=deavid@sedice.dnssw.net] has quit ["No Ping reply in 180 seconds."]
15:04 #nouveau: < calim> but I only checked with draw_arrays; you can even split primitives between NV50TCL_VERTEX_BUFFER_FIRST/COUNT pairs
15:04 -!- deavid [n=deavid@sedice.dnssw.net] has joined #radeon
15:06 #nouveau: < lb1> it seems all nv4x are the same
15:07 #nouveau: < lb1> nv3x too
15:07 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has joined #nouveau
15:07 -!- fredrikh [n=fredrik@kde/fredrik] has quit [Excess Flood]
15:07 -!- fredrikh [n=fredrik@kde/fredrik] has joined #radeon
15:08 #nouveau: < lb1> except nv46 display_list, which seems to be a corrupted trace (sends a lot of 0 values as vertices)
15:08 #nouveau: < curro_> lb1: some benchmarks would be interesting
15:08 #nouveau: < lb1> yes
15:08 #nouveau: < lb1> I don't have a benchmarking setup ready at the moment though
15:09 #nouveau: < lb1> (mesa compiled unoptimized)
15:09 -!- DanaG [n=dana@pcp038606pcs.dhcp.calpoly.edu] has quit [Read error: 60 (Operation timed out)]
15:11 #nouveau: < lb1> btw, what happens if you put vertex buffers in vram? how/where is the copy performed?
15:11 #nouveau: < lb1> does it directly write to vram with write combining, does it somehow directly upload from normal memory, does it write to gart with write memory combining and then upload with M2MF?
15:13 #nouveau: < lb1> seems it mmaps in nouveau_bo_emit_buffer and then memcpy's to vram with write combining
15:13 #nouveau: < calim> nv50 uses m2mf, or SIFC from a GART buffer for small amounts of data
15:13 #nouveau: < calim> oh, you meant us
15:13 #nouveau: < lb1> yes
15:13 #nouveau: < lb1> also it seems it does the same thing if writiing to GART memory
15:14 -!- fat_chris [n=chris@cpc2-leic15-2-0-cust566.8-1.cable.virginmedia.com] has quit [Read error: 110 (Connection timed out)]
15:14 #nouveau: < lb1> if write-combined writing to vram is as fast as local ram, then vram will actually be faster
15:15 #nouveau: < lb1> if not, vram will have more CPU latency, but possibly the same or lower CPU+GPU latency, as the GPU will have to read across the bus anyway
15:15 #nouveau: < lb1> unless the vertex buffer is partially used, where using GART would reduce bus traffic
15:17 #nouveau: < curro_> lb1: they're usually moved when you reloc them in VRAM
15:18 #nouveau: < calim> this is exactly the case where you get crappy performance, large non-VBO vertex arrays that are accessed by just a few glDrawElements indices
15:18 -!- paulez_ [n=paul@ezvan.fr] has joined #radeon
15:18 #nouveau: < calim> if you just blindly reloc them
15:18 #nouveau: < lb1> I think they *created* in vram
15:18 #nouveau: < lb1> I think they would be *created* in vram
15:18 #radeon: < zhasha> UnNamed: the r300 driver you're using doesn't support ARB_{vertex,fragment}_shader, only *_program
15:18 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has quit ["Leaving."]
15:18 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has quit ["Leaving."]
15:19 #nouveau: < curro_> lb1: yeah, i meant, as long as you're creating them in GART first
15:19 #nouveau: < lb1> and thus would be initialized from system memory with a memcpy
15:19 #nouveau: < lb1> so IMHO the work by the CPU should be the same in the GART and VRAM cases
15:19 #nouveau: < curro_> lb1: there's no memcpy involved
15:19 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has quit []
15:19 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has quit []
15:20 #nouveau: < lb1> in the gart case?
15:20 #nouveau: < lb1> are you sure?
15:20 #nouveau: < curro_> lb1: yeah
15:20 #nouveau: < lb1> gart memory has to be uncached
15:20 -!- JSeymour [n=jseymour@jimsun.linxnet.com] has joined #radeon
15:20 #radeon: < zhasha> the GPU itself does have very primitive shaders though
15:20 #nouveau: < lb1> I think you either need to directly construct the vertices in gart memory
15:20 #nouveau: < lb1> or memcpy them from a normal system memory area
15:20 #nouveau: < stillunknown> gart is cached iirc
15:20 #nouveau: < lb1> which is the same as the vram case
15:20 #nouveau: < lb1> ?
15:20 #nouveau: < stillunknown> pci gart at least
15:20 #nouveau: < lb1> no
15:21 #nouveau: < lb1> that's more possible
15:21 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #nouveau
15:21 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has joined #radeon
15:21 -!- regis [n=regis@regis.no-ip.com] has quit [Read error: 110 (Connection timed out)]
15:21 -!- Kurko_ [n=kurko@irkki.fi] has quit [Read error: 104 (Connection reset by peer)]
15:21 #nouveau: < lb1> I think that's also uncached (if you mean pci express at least)
15:21 -!- Kurko_ [i=kurko@irkki.fi] has joined #radeon
15:22 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Read error: 104 (Connection reset by peer)]
15:22 -!- mschaal [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Read error: 104 (Connection reset by peer)]
15:22 #nouveau: < lb1>                 case NOUVEAU_GART_AGP:
15:22 #nouveau: < lb1>                         man->available_caching = TTM_PL_FLAG_UNCACHED;
15:22 #nouveau: < lb1>                 case NOUVEAU_GART_SGDMA:
15:22 #nouveau: < lb1>                         man->available_caching = TTM_PL_MASK_CACHING;
15:22 #nouveau: < lb1>         case TTM_PL_VRAM:
15:23 #nouveau: < lb1>                 man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
15:23 #nouveau: < lb1> is sgdma pci or pcie too?
15:23 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has quit []
15:23 #radeon: < UnNamed> zhasha: it is plain phong or gourad, not glsl, just the normal blender view
15:23 #nouveau: < calim> there'll be a memcpy for vbufs if either the user fills them, or if they are user buffers
15:24 #nouveau: < calim> sgdma is pcie too
15:24 #nouveau: < lb1> pcie too it seems
15:24 #nouveau: < lb1> wow
15:24 #radeon: < zhasha> well in that case it should be hardware accelerated
15:24 #nouveau: < stillunknown> we set it up like a pci gart iirc
15:24 #nouveau: < calim> good night
15:24 #nouveau: < lb1> great
15:24 -!- calim [n=chr@93.83.4.186] has quit ["leaving"]
15:24 -!- calim [n=chr@93.83.4.186] has quit ["leaving"]
15:24 #nouveau: < stillunknown> anyway, night time here
15:25 #nouveau: < lb1> just wondering
15:25 -!- diverse_izzue [n=hunzikea@80.243.127.23] has quit ["Ex-Chat"]
15:25 #nouveau: < lb1> what if we set it uncached? that could cause the bug to go away
15:26 #nouveau: < curro_> lb1: if we set what?
15:26 #nouveau: < lb1> sgdma memory uncached
15:26 -!- idr [n=idr@host-250-218.pubnet.pdx.edu] has quit [Read error: 60 (Operation timed out)]
15:26 -!- stillunknown [n=stillunk@82-136-228-38.ip.telfort.nl] has quit [Read error: 60 (Operation timed out)]
15:26 -!- stillunknown [n=stillunk@82-136-228-38.ip.telfort.nl] has quit [Read error: 60 (Operation timed out)]
15:26 #nouveau: < curro_> lb1: i thought you weren't using sgdma
15:26 #nouveau: < lb1> just as an experiment to see if it goes away, not in all cases
15:26 #nouveau: < lb1> it's a pci express card
15:27 -!- phenriksson [n=phenriks@h-93-122.A193.priv.bahnhof.se] has quit []
15:27 #nouveau: < lb1> a mobile pci express card on Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port
15:27 -!- jsgf [n=jeremy@dsl-203-33-163-122.NSW.netspace.net.au] has quit [Read error: 110 (Connection timed out)]
15:28 #radeon: < soreau> adamk_: onestone just tested and he said alpha blur works with dual output on nvidia there so I guess we'll have to treat it like a driver bug
15:28 #nouveau: < curro_> lb1: oh, i was misremembering then :/
15:28 #nouveau: < lb1> is pci express really cache coherent?
15:28 #radeon: < adamk_> Damn :-)
15:29 #radeon: < soreau> adamk_: I feel the same way as you about it working at all though, glad to see it ;)
15:30 -!- Hedge|Hog [n=cronic@c83-254-163-45.bredband.comhem.se] has quit ["I was raided by the FBI and all I got to keep was this lousy quit message!"]
15:30 #radeon: < adamk_> True true.  And, in fact, I'm already back on r600 so it doesn't matter that much to me :-)
15:30 #radeon: < adamk_> Well, till it works on r600, that is.
15:30 #nouveau: < lb1> can't find a definite answer
15:30 #nouveau: < curro_> lb1: if that was the culprit, the wbinvd's you tried would have done the trick
15:30 #nouveau: < lb1> but I'm finding stuff like "The resulting improvements fall significantly short of creating a cache coherent version of PCI Express"
15:30 -!- beyecixramd [n=beyecixr@113.Red-83-49-180.dynamicIP.rima-tde.net] has joined #nouveau
15:31 #nouveau: < lb1> yes, probably
15:31 #radeon: < soreau> However there was a bug in 0.9 throwing the framebuffer incomplete message which is now fixed FWIW
15:33 -!- rhodan_ [n=quassel@120-88.107-92.cust.bluewin.ch] has joined #radeon
15:34 #nouveau: < lb1> according to microsoft "PCIe will support snooping. It will now be possible to map such shared memory as cacheable and still be able to maintain coherency between the CPU and the GPU"
15:34 #nouveau: < lb1> radeon also does that
15:35 #nouveau: < beyecixramd> in DX12? ^^
15:36 #nouveau: < airlied> lb1: pci is cache coherent onx86
15:37 #nouveau: < airlied> only some wierdass powerpc variants and alphas maybe have non-coherent PCI
15:37 #radeon: < papillon81> could it be that some FBO functionality is not yet implemented?
15:37 #nouveau: < lb1> pcie too? does that depend on the gpu too or only the bus?
15:37 #nouveau: < airlied> PCIE has optional coherency
15:37 #nouveau: < lb1> how is that enabled?
15:37 #radeon: < papillon81> i'm getting errors with openscenegraph when it comes to fb stuff
15:37 #nouveau: < lb1> with a card-specific mechanism or on the bus controller?
15:37 #nouveau: < airlied> no sure on nvidias, on radeon there is a bit in the PE
15:37 #nouveau: < airlied> PTE
15:37 #nouveau: < airlied> and a master bit somewhere else
15:37 #nouveau: < airlied> its per bus transaction
15:38 #nouveau: < shining> there are no tools that take data errors , renouveau.xml , do some magic and print an dev-friendly error ? :)
15:38 #nouveau: < lb1> anyone knows if/how nouveau is doing this?
15:38 -!- pyro_maniac [n=quassel@77-23-96-13-dynip.superkabel.de] has joined #nouveau
15:38 #nouveau: < airlied> lb1: I assume its using snooped transfers on PCI/PCIE.
15:38 #nouveau: < airlied> AGP is all unsnooped
15:38 -!- pyro_maniac [n=quassel@77-23-96-13-dynip.superkabel.de] has quit [Client Quit]
15:39 #nouveau: < airlied> darktama: do you know if the PTE's have snoop/not snoop bits?
15:39 #radeon: < papillon81> i try to debug it with gldb
15:39 #nouveau: < lb1> it should, but maybe nouveau is messing up this configuration at least on some cards?
15:39 #radeon: < UnNamed> zhasha: do you think 50K faces is too much for a r300?
15:39 #radeon: < agd5f> papillon81: you need kms for fbos
15:39 #nouveau: < airlied> it'll be the same on all cards
15:39 #radeon: < papillon81> agd5f: ah!
15:39 #radeon: < papillon81> :-)
15:39 -!- paulez_ [n=paul@ezvan.fr] has quit [Read error: 113 (No route to host)]
15:40 #radeon: < papillon81> well, last time i tried with KMS it lead to other problems i.e the program was not even starting. but i can see then what's going on...
15:40 #radeon: < papillon81> agd5f: 2.6.32 is sufficient?
15:40 #nouveau: < lb1> well, I'll try to make pcie uncached and see if that solves the vertex corruption
15:41 #radeon: < agd5f> papillon81: should be fine
15:41 -!- rhodan [n=quassel@140-156.3-85.cust.bluewin.ch] has quit [Read error: 60 (Operation timed out)]
15:41 #nouveau: < shining> airlied: I read your blog a few days ago, interesting stuff. so you darktama and whot were all together in the same office, and still are ?
15:42 #nouveau: < darktama> airlied: not a clue, I presume so and it's probably one of the unknown flags in the entries
15:43 #nouveau: < lb1> darktama: have you seen the pushbuffer bounds patch I sent?
15:43 #nouveau: < airlied> shining: yeah some days we are even all in at the same time
15:43 #nouveau: < darktama> shining: yeah we're still all there :)
15:43 #nouveau: < lb1> darktama: any issues?
15:44 -!- gnubien [n=e@unaffiliated/gnubien] has quit ["leaving"]
15:44 -!- LEW21 [n=lew21@zaba.kosson.com] has quit [Read error: 104 (Connection reset by peer)]
15:45 #nouveau: < darktama> the code looks fine, I just don't like the ||'s where they are and the really long lines :)
15:45 -!- papillon81 [n=papillon@f053144200.adsl.alicedsl.de] has quit [Read error: 104 (Connection reset by peer)]
15:45 -!- papillon81 [n=papillon@f053144200.adsl.alicedsl.de] has joined #radeon
15:46 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has quit ["Leaving"]
15:46 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has quit ["Leaving"]
15:46 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has quit ["Leaving"]
15:46 #nouveau: < darktama> i'll apply it and split them though if you like
15:46 #nouveau: < lb1> ok :)
15:47 #nouveau: < shining> airlied: ah, thats less usual ?
15:47 -!- mokoloko [n=zxczx@dsl-hkimmlgw8-fe15f800-197.dhcp.inet.fi] has quit [Remote closed the connection]
15:48 -!- RSpliet [n=roy@53537511.cable.casema.nl] has quit ["Leaving."]
15:49 -!- Novum367 [n=Miranda@vpn2751.extern.uni-tuebingen.de] has joined #nouveau
15:51 -!- andyrtr [n=andyrtr@archlinux/developer/andyrtr] has joined #nouveau
15:52 #nouveau: < darktama> lb1: switched error to -EINVAL, and added a missed drm_gem_object_unreferenced() too
15:53 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has joined #radeon
15:53 -!- osiris [n=quassel@azt243.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
15:53 -!- osiris [n=quassel@azt243.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
15:53 -!- osiris [n=quassel@azt243.neoplus.adsl.tpnet.pl] has quit [Remote closed the connection]
15:54 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has joined #nouveau
15:54 #nouveau: < DanaG> (EE) AIGLX error: dlopen of /usr/lib/dri/nouveau_vieux_dri.so failed (/usr/lib/dri/nouveau_vieux_dri.so: cannot open shared object file: No such file or directory)
15:54 #nouveau: < DanaG> hmm, is that a file that can even be compiled yet?
15:54 #nouveau: < DanaG> Building mesa doesn't create that file.
15:54 -!- Novum [n=Miranda@e180031254.adsl.alicedsl.de] has quit [Read error: 60 (Operation timed out)]
15:54 #nouveau: < lb1> darktama: sorry, missed tat
15:54 #nouveau: < darktama> yeah, curro_ hasn't merged to the mesa tree yet :)
15:55 #nouveau: < DanaG> ah.
15:55 #nouveau: < lb1> darktama: I can't see any drm_gem_object_unreference(gem) in the non-error exit path though; is that ok?
15:55 -!- Novum [n=Miranda@e180031254.adsl.alicedsl.de] has joined #nouveau
15:56 #nouveau: < DanaG> weird.... upon dpms suspend, the LCD on this old laptop "bleeds" to white.
15:56 #nouveau: < darktama> yeah, its fine, the push buffer gets added to the validated list and will be unreferenced when the other buffers are
15:57 #nouveau: < lb1> yes, right, thanks
15:57 -!- sunmoon1997 [n=sunmoon1@58.33.130.160] has joined #dri-devel
15:57 -!- sunmoon1997 [n=sunmoon1@58.33.130.160] has joined #nouveau
15:57 -!- gdm__ [n=gdm@190.173.66.165] has joined #nouveau
15:58 #nouveau: < DanaG> hmm, is there a given ETA for that 3D stuff yet?
15:58 -!- gdm__ [n=gdm@190.173.66.165] has joined #dri-devel
15:58 -!- gdm_ [n=gdm@190.173.104.128] has quit [Read error: 60 (Operation timed out)]
15:58 -!- gdm_ [n=gdm@190.173.104.128] has quit [Read error: 60 (Operation timed out)]
15:58 #nouveau: < DanaG> I'd love to be able to use at least the compiz cube feature, on that old laptop.
15:58 #nouveau: < DanaG> nvidia binary drivers aren't an option... they've been broken for like 2 or 3 years.
15:58 #nouveau: < DanaG> =þ
15:58 #nouveau: < darktama> when curro is ready :)
15:58 #nouveau: < DanaG> nouveau works pretty dang well at what it does now, though.  The first time I used it, it hammered both CPU and hard drive, oddly enough.
15:59 -!- m03sizlak [n=x1001011@pool-98-117-162-201.bflony.fios.verizon.net] has joined #radeon
16:00 -!- er0x [n=root@client-87-247-122-156.inturbo.lt] has quit [Connection timed out]
16:00 #nouveau: < curro_> darktama: right now i'm a bit too snowed under academic crap to bear the flames at mesa3d-dev@ :)
16:01 #nouveau: < airlied> curro_: nobody will notice classic mesa drivers anymore ;-)
16:01 -!- Curan [n=kai@drsd-4dbd8db4.pool.mediaWays.net] has quit ["Die Büchse der Zensursula ist geöffnet! R.I.P. Gewaltenteilung und Art. 5 GG."]
16:02 -!- Novum367 [n=Miranda@vpn2751.extern.uni-tuebingen.de] has quit [Read error: 60 (Operation timed out)]
16:03 #nouveau: < curro_> airlied: good to know, hopefully these C99 features i've been using are hidden well enough
16:03 -!- AndreasD [n=andreas@1407ds1-ns.0.fullrate.dk] has quit ["Ex-Chat"]
16:03 -!- AndreasD [n=andreas@1407ds1-ns.0.fullrate.dk] has quit ["Ex-Chat"]
16:03 #nouveau: < shining> ahah
16:05 #nouveau: < curro_> shining: btw, did that getbuffers patch help?
16:06 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:06 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:06 -!- anholt [i=anholt@66-233-52-37.war.clearwire-wmx.net] has quit [Remote closed the connection]
16:06 #nouveau: < shining> curro_: as I said to pmdata, I am not even sure there was a slowdown, I need to do real benchmarks.. tomorrow :)
16:06 -!- andyrtr_laptop [n=andyrtr@f053200058.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)]
16:06 #nouveau: < shining> did not notice much diff with or without the patch but I didnt run any benchmark for that either
16:06 #nouveau: < shining> does it help a lot for you ? in which situations ?
16:08 -!- stikonas [n=and@wesnoth/translator/stikonas] has quit [Remote closed the connection]
16:08 #nouveau: < curro_> shining: it should counteract the slowdown the dri2 glViewport hack caused
16:09 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
16:09 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
16:10 #nouveau: < shining> curro_: aaah, thats good to know , I will test on my other box too then if it can have the same effect there.
16:10 #radeon: < tigerchen> hez, it|s me again with still the same problem: missing dri because of a version mismatch error
16:10 #radeon: < tigerchen> (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
16:11 #radeon: < tigerchen> [dri] radeon kernel module version is 2.0.0 but version 1.17.0 or newer is needed.
16:11 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
16:11 -!- marcel_ [n=Marcel@dslb-084-057-178-035.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)]
16:11 #radeon: < tigerchen> re-merging libdrm xorg-server mesa and xf86-video-ati didn't work out to fix this
16:12 #nouveau: < shining> but thats the first thing I tried, reverting this hack, and I did not feel any differences (nv35 + xmoto and teeworlds). but all this is based on just a memory of how smooth it was last time I played , which could be completely off ..
16:12 #radeon: <@airlied> tigerchen: make sure radeon is loaded before X starts if you are using KMS
16:13 #radeon: < tigerchen> it is, radeon is not a module here ;)
16:13 #radeon: < DanaG> is radeon.modeset=1 set?
16:13 #radeon: < tigerchen> kms on console is so nice
16:14 #radeon: < DanaG> Needs DPI scaling.
16:14 #radeon: < DanaG> =þ
16:14 #radeon: < DanaG> And not sucking watts.
16:14 #nouveau: < shining> so.. my awesome inspection of the data error with oa/nv35 and the code points me to "txf |= (1<<13) /*FIXME: NV34TCL_TX_FORMAT_LINEAR ? */;" there was just one fixme in a small 100-lines file, I guess one could have figured it in 5 seconds :)
16:14 #radeon: < tigerchen> danag: where to check?
16:15 #radeon: < tigerchen> not sucking watts would be nice, but at least s2ram works atm
16:15 -!- pH5 [n=ph5@e178209060.adsl.alicedsl.de] has quit ["bye"]
16:15 #radeon: < DanaG> you can look around in dmesg, or 'dmesg | grep mode'
16:15 #radeon: < DanaG> (04:01:42 PM) ***DanaG wonders what ATI will do for product names once they reach 9000 again.
16:15 #radeon: < DanaG> (04:04:09 PM) [Enrico]: DanaG: they will call their products Feynman to contrast nvidia fermi :D   [well you have to be a physics to understand this joke]
16:15 #radeon: < DanaG> (04:05:09 PM) DanaG: If nvidia has Tesla, they must be like the Soviets.... time for AMD/ATI to get Einstein on their side.  (reference to Red Alert series games.)
16:15 #radeon: < DanaG> from #ati
16:15 #radeon: < tigerchen> [drm] radeon defaulting to kernel modesetting.
16:15 #radeon: < tigerchen> [drm] radeon kernel modesetting enabled.
16:15 #radeon: < tigerchen> [drm] radeon: Initializing kernel modesetting.
16:15 #radeon: < tigerchen> [drm] LVDS-10: set mode 1400x1050 1c
16:15 #radeon: < DanaG> gaack, don't directly paste... but looks like KMS is enabled.
16:16 #radeon: < DanaG> "1.7 is needed"... means userspace wasn't built with KMS support.
16:16 #radeon: <@airlied> tigerchen: make sure libdrm is build with --enablre-radeon-experimental-api
16:16 #radeon: < tigerchen> airlied: it is, checked before
16:17 #radeon: < DanaG> I've found things work best installed not in /usr/local -- too hard to get everything to build off /usr/local.
16:17 #radeon: < tigerchen> DanaG: nothing in /usr/local, just stock install via portage
16:17 #radeon: < DanaG> Though, that is going behind the package manager's back if you go with /usr.
16:19 -!- albert23 [n=albert@ip4daa4833.direct-adsl.nl] has left #nouveau []
16:25 -!- mentor [n=mentor@87.254.76.204] has joined #radeon
16:25 #radeon: < tigerchen> anz idea left?
16:27 #radeon: < papillon81> agd5f: that looks much better now with kms, but it's awfully slow compared to non-kms. any way to speed it up?
16:27 #radeon: <@airlied> tigerchen: it doesn't look like a git master ati driver
16:27 #radeon: <@airlied> I suspect you are using 6.12.4 or something
16:29 -!- darkbasic [n=quassel@static-217-133-76-61.clienti.tiscali.it] has quit [Remote closed the connection]
16:29 -!- rhodan_ is now known as rhodan
16:29 -!- beyecixramd [n=beyecixr@113.Red-83-49-180.dynamicIP.rima-tde.net] has quit [Remote closed the connection]
16:30 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has joined #nouveau
16:31 #radeon: < tigerchen> airlied: yes, is that too old?
16:31 -!- FoxBlitzz_ [n=blitzzyb@cpe-75-186-89-27.cinci.res.rr.com] has joined #radeon
16:31 #radeon: <@airlied> tigerchen: got KMS you need git master
16:31 #radeon: < tigerchen> airlied: ok, will install
16:32 #radeon: < tigerchen> anything else i need from git?
16:32 -!- Eddi|zuHause [n=johekr@p54B776DE.dip.t-dialin.net] has quit []
16:32 -!- Eddi|zuHause [n=johekr@p54B77AF3.dip.t-dialin.net] has joined #radeon
16:33 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 113 (No route to host)]
16:33 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 113 (No route to host)]
16:35 #radeon: < tigerchen> airlied: ok, seems like that was it, thanks
16:36 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
16:36 -!- benh [n=benh@nat/ibm/x-rionimkdczpkzmwf] has joined #dri-devel
16:36 -!- benh [n=benh@nat/ibm/x-rionimkdczpkzmwf] has joined #radeon
16:36 -!- benh [n=benh@nat/ibm/x-rionimkdczpkzmwf] has joined #nouveau
16:36 -!- mode/#dri-devel [+v benh] by ChanServ
16:36 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
16:36 #nouveau: < lb1> disabling pcie caching did not fix the gart vertex buffer issue on my card
16:38 #nouveau: < ymanton> you looked at an nv4a dump and vbufs were in vram there as well?
16:38 #nouveau: < lb1> all nv3x and nv4x dumps put the vbos in vram afaict
16:38 #nouveau: < lb1> I wonder if GL_NV_vertex_array_range might be implemented with gart vertex buffers
16:39 -!- KoH [n=kane@port-92-193-93-100.dynamic.qsc.de] has joined #radeonhd
16:39 -!- devh [n=devh@85-127-114-229.dynamic.xdsl-line.inode.at] has quit [Remote closed the connection]
16:39 #nouveau: < lb1> basically dma0 is set to gart and dma1 is set to vram
16:39 #nouveau: < lb1> and all the non-null vertex offsets use dma1
16:40 #nouveau: < lb1> except a probably corrupted nv46 display list trace
16:40 #nouveau: < lb1> for i in nv[34]*/*{display_list,vertex_buffer}*; do zgrep 'source = 0' "$i"; done
16:40 #nouveau: < lb1> they are all zero
16:40 #nouveau: < lb1> for i in nv[34]*/*{display_list,vertex_buffer}*; do zgrep PRIMITIVE_3D_SET_VB_SRC1_OBJECT "$i"; done
16:40 -!- KoH [n=kane@port-92-193-93-100.dynamic.qsc.de] has quit [Client Quit]
16:40 #nouveau: < lb1> all 0xbeef0201
16:41 #nouveau: < lb1> which is vram
16:42 #nouveau: < ymanton> i dont remember how the renouveau vbo test is set up, but it might be the usage flags that cause that
16:43 -!- rtcm [n=jman@109.81.54.77.rev.vodafone.pt] has quit ["Leaving."]
16:43 #nouveau: < lb1>         regl.BufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(vtxdata), vtxdata, GL_STATIC_DRAW);
16:43 #nouveau: < lb1> maybe GL_STATIC_DRAW is causing vram?
16:43 -!- KoH [n=kane@port-92-193-93-100.dynamic.qsc.de] has joined #radeonhd
16:44 #nouveau: < lb1> could try with GL_DYNAMIC_DRAW
16:44 #nouveau: < ymanton> likely. STREAM or DYNAMIC and/or READ might do something different
16:44 #nouveau: < lb1> also also try GL_NV_vertex_array_range
16:44 -!- haole [n=eskoria@189.35.26.237] has joined #radeonhd
16:44 -!- FoxBlitzz [n=blitzzyb@cpe-75-186-89-27.cinci.res.rr.com] has quit [Read error: 110 (Connection timed out)]
16:45 #RadeonHD: < haole> yangman, hello again... the trick that we did a while ago did not work... now, when i start X with radeonhd with the radeon module loaded, my laptop screen stays black, and then starts to get brighter and brighter until i get scared and reboot the pc! what can still be wrong?
16:45 #RadeonHD: < haole> my device: radeon x1250
16:49 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:49 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:49 -!- rib [n=bob@82.152.87.189] has joined #dri-devel
16:51 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
16:51 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
16:53 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:53 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:53 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
16:53 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
16:54 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:54 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
16:57 -!- amarks [n=quassel@124-171-4-214.dyn.iinet.net.au] has joined #radeon
16:58 -!- siimo [n=siimo@unaffiliated/siimo] has joined #radeon
16:58 #RadeonHD: < yangman> haole: try xf86-video-ati instead. will probably work better
16:59 #RadeonHD: < haole> yangman, i have a doubt... which one is still being developed? radeonhd or ati?
16:59 #RadeonHD: < yangman> both, but ati is way more active
17:00 -!- siimo [n=siimo@unaffiliated/siimo] has left #radeon []
17:00 #RadeonHD: < haole> yangman, does fglrx work better? i could try that too
17:01 #RadeonHD: < yangman> fglrx officially dropped support for that family a few releases back
17:02 -!- idr [n=idr@host-247-159.pubnet.pdx.edu] has joined #dri-devel
17:02 -!- mode/#dri-devel [+v idr] by ChanServ
17:02 #RadeonHD: < haole> yangman, humm... good to know... thanks for the great advices!
17:04 -!- haole [n=eskoria@189.35.26.237] has quit ["Saindo"]
17:07 -!- JSeymour [n=jseymour@jimsun.linxnet.com] has quit ["Leaving"]
17:08 -!- droid001 [n=g1@p4FDCA3D6.dip.t-dialin.net] has joined #radeon
17:08 -!- fat_chris [n=chris@cpc2-leic15-2-0-cust566.8-1.cable.virginmedia.com] has joined #radeon
17:13 -!- amarks____ [n=quassel@124-168-159-224.dyn.iinet.net.au] has quit [Read error: 101 (Network is unreachable)]
17:15 -!- antrik [n=olaf@port-92-195-173-176.dynamic.qsc.de] has quit ["bye"]
17:16 -!- keith_ [n=keith@pool-173-69-130-94.bltmmd.fios.verizon.net] has joined #nouveau
17:16 -!- Novum [n=Miranda@e180031254.adsl.alicedsl.de] has quit [Read error: 104 (Connection reset by peer)]
17:18 #nouveau: < keith_> I was reading an articale that nouveau would be included in the .33 kernel -- anyone know if its made it into one of the -rc kernels yet, or if we still need to manually patch it go get nouveau support?
17:18 #nouveau: < darktama> it's in the -rcs
17:18 #nouveau: < keith_> awesome -- thanks.
17:25 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has joined #nouveau
17:25 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has joined #dri-devel
17:27 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
17:27 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
17:31 -!- DrNick [n=Nick@c-98-247-100-230.hsd1.wa.comcast.net] has quit [Connection timed out]
17:32 -!- onestone_ [n=onestone@unaffiliated/onestone] has quit [Remote closed the connection]
17:32 -!- onestone_ [n=onestone@unaffiliated/onestone] has quit [Remote closed the connection]
17:32 -!- onestone_ [n=onestone@unaffiliated/onestone] has quit [Remote closed the connection]
17:37 -!- sunmoon1997 [n=sunmoon1@58.33.130.160] has quit [Read error: 110 (Connection timed out)]
17:37 -!- sunmoon1997 [n=sunmoon1@58.33.130.160] has quit [Read error: 110 (Connection timed out)]
17:38 #dri-devel: < Dr_Jakob> Hmm is either Luca or Chia-I online in here?
17:39 #dri-devel: <+airlied> lb1: <- Luca I think
17:39 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
17:39 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
17:39 #dri-devel: < Dr_Jakob> oh
17:39 #dri-devel: < Dr_Jakob> Oh come on... :-(
17:39 -!- sungami [n=sungami@unaffiliated/sungami] has quit [Remote closed the connection]
17:39 -!- sungami [n=sungami@cpc1-cbly4-0-0-cust824.glfd.cable.ntl.com] has joined #dri-devel
17:40 -!- fat_chris [n=chris@cpc2-leic15-2-0-cust566.8-1.cable.virginmedia.com] has quit [Remote closed the connection]
17:40 #dri-devel: <+airlied> lols
17:40 -!- fat_chris [n=chris@cpc2-leic15-2-0-cust566.8-1.cable.virginmedia.com] has joined #radeon
17:40 #dri-devel: < zhasha> airlied: laughing at other people's misfortune? nice
17:45 -!- Zajec [n=opera@77-253-200-80.ip.netia.com.pl] has left #radeon []
17:45 -!- Zajec [n=opera@77-253-200-80.ip.netia.com.pl] has left #nouveau []
17:46 -!- predatorfreak [n=predator@c-24-11-52-92.hsd1.mi.comcast.net] has quit []
17:52 #dri-devel: < zhasha> Dr_Jakob: so it's been decided that r300g is ready for actual use?
17:53 #dri-devel: < Dr_Jakob> zhasha: no its only the r300 pipe driver that builds by default
17:53 #dri-devel: < Dr_Jakob> radeong_dri.so doesn't get built.
17:53 -!- Tureba [i=bb175094@gateway/web/freenode/x-lhcsdmlvbqaptqgy] has quit ["Page closed"]
17:54 #dri-devel: < zhasha> but we don't have any other winsys that uses the r300 pipe
17:54 #dri-devel: < Dr_Jakob> its just to get wide build coverage of as many pipe drivers as possible
18:06 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has quit ["Leaving."]
18:06 -!- juan_arandaalvar [n=jaranda@201.143.50.226.dsl.dyn.telnor.net] has quit ["Leaving."]
18:07 -!- idr [n=idr@host-247-159.pubnet.pdx.edu] has quit [Read error: 110 (Connection timed out)]
18:08 -!- Droste1 [n=droste@p57905E39.dip.t-dialin.net] has joined #radeon
18:09 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
18:09 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
18:09 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
18:09 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has quit [Read error: 113 (No route to host)]
18:10 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #dri-devel
18:10 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #radeon
18:10 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #radeonhd
18:10 -!- agd5f [n=alex@c-68-50-242-96.hsd1.va.comcast.net] has joined #nouveau
18:12 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
18:12 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
18:14 #radeon: < dileX_> yeah, "r300g: Build driver by default"
18:14 #dri-devel: < lb1> yes
18:14 #dri-devel: < lb1> hi :)
18:15 #dri-devel: < MostAwesomeDude> Huh? I must have missed something.
18:15 #dri-devel: < MostAwesomeDude> Wallbraker: Thanks, I meant to do that and it kept slipping my mind.
18:17 #dri-devel: < lb1> Dr_Jakob: Hmm is either Luca or Chia-I online in here?   airlied: lb1: <- Luca I think
18:17 -!- rib [n=bob@82.152.87.189] has quit [Read error: 110 (Connection timed out)]
18:18 -!- AStorm [n=astralst@unaffiliated/astralstorm] has joined #radeon
18:18 #dri-devel: < MostAwesomeDude> I'm not getting the joke, but I could just be too tired.
18:18 -!- AstralStorm [n=astralst@unaffiliated/astralstorm] has quit [Read error: 110 (Connection timed out)]
18:20 -!- dileX [n=sd@p5B2ECC94.dip.t-dialin.net] has joined #radeon
18:21 -!- hugovs [n=hugovs@189.27.22.195.dynamic.adsl.gvt.net.br] has joined #nouveau
18:22 -!- egbert [n=eich@p5DCF0A6C.dip0.t-ipconnect.de] has quit [Nick collision from services.]
18:22 -!- egbert [n=eich@p5DCF0A6C.dip0.t-ipconnect.de] has quit [Nick collision from services.]
18:22 -!- egbert [n=eich@p5DCF0A6C.dip0.t-ipconnect.de] has quit [Nick collision from services.]
18:22 -!- rsleza [n=radek@91.143.broadband5.iol.cz] has quit ["Leaving."]
18:22 -!- RiotingPacifist [n=juan@cpc2-gran1-0-0-cust434.nott.cable.ntl.com] has quit [Read error: 110 (Connection timed out)]
18:23 -!- egbert [n=eich@p5DCF0BEA.dip0.t-ipconnect.de] has joined #radeonhd
18:23 -!- egbert [n=eich@p5DCF0BEA.dip0.t-ipconnect.de] has joined #dri-devel
18:23 -!- egbert [n=eich@p5DCF0BEA.dip0.t-ipconnect.de] has joined #radeon
18:24 -!- Droste [n=droste@p57905EDA.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]
18:25 -!- UnNamed [i=500@16.Red-80-32-164.staticIP.rima-tde.net] has quit ["sleep"]
18:26 -!- sunmoon1997 [n=sunmoon1@116.231.37.204] has joined #dri-devel
18:26 -!- sunmoon1997 [n=sunmoon1@116.231.37.204] has joined #nouveau
18:33 -!- rhodan_ [n=quassel@168-104.107-92.cust.bluewin.ch] has joined #radeon
18:36 -!- dileX_ [n=sd@p5B2ED0E5.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)]
18:37 -!- hugovs [n=hugovs@189.27.22.195.dynamic.adsl.gvt.net.br] has quit ["Leaving"]
18:38 #nouveau: < lb1> all usage flags on glBufferData seem to cause the blob to use vram
18:38 #nouveau: < lb1> however, the blob uses vertex arrays in gart memory if GL_NV_vertex_array_range is used
18:38 #dri-devel: < dberkholz> he was confirming that indeed he is luca.
18:39 -!- deavid [n=deavid@sedice.dnssw.net] has quit [Read error: 60 (Operation timed out)]
18:39 -!- deavid [n=deavid@sedice.dnssw.net] has joined #radeon
18:41 #dri-devel: < Dr_Jakob> lb1: Hi there
18:42 #dri-devel: < lb1> Dr_Jakob: hi
18:42 #nouveau: < ymanton> so it should work
18:43 #dri-devel: < Dr_Jakob> How hard would it be for you to resurect the MESA_screen_surface patch for egl_glx?
18:43 -!- sroland [n=sroland@84-75-151-199.dclient.hispeed.ch] has quit [Remote closed the connection]
18:44 #dri-devel: < Dr_Jakob> I want to be sure that doesn't get lost
18:44 #dri-devel: < lb1> I think the one I posted should still work
18:44 #dri-devel: < lb1> possibly with minor adjustments
18:44 #dri-devel: < lb1> doesn't it?
18:44 #dri-devel: < lb1> or do you mean doing something similar for egl_g3d?
18:45 #dri-devel: < Dr_Jakob> that would be nice as well
18:46 -!- dileX [n=sd@p5B2ECC94.dip.t-dialin.net] has quit [Remote closed the connection]
18:46 #dri-devel: < lb1> Chia-I is somewhat opposed to the idea
18:46 #dri-devel: < lb1> of MESA_screen_surface for an x11 window
18:46 -!- papillon81 [n=papillon@f053144200.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)]
18:47 #dri-devel: < lb1> anyway, it should be doable and the code in the egl_glx mostly reusable
18:47 -!- dileX [n=sd@vpn-eu1.unidsl.de] has joined #radeon
18:48 #dri-devel: < Dr_Jakob> hmm okay, I just would like it to be possible to test code against a MESA_screen_surface implementation that doesn't require stand alone KMS.
18:50 #nouveau: < lb1> maybe I discovered the magic incantation for vertex cache flushing
18:50 #nouveau: < lb1> the idea is to trace glFlushVertexArrayRangeNV
18:50 #nouveau: < lb1> which results in:
18:50 #nouveau: < lb1> 00043710  size 1, subchannel 1 (0xbeef3097),offset 0x1710,increment
18:50 #nouveau: < lb1> 00000000    NV40TCL[0x1710/4]
18:50 #nouveau: < lb1> 00043d6c  size 1, subchannel 1 (0xbeef3097),offset 0x1d6c,increment
18:50 #nouveau: < lb1> 00000580    NV40TCL[0x1d6c/4]
18:50 #nouveau: < lb1> 00043d70  size 1, subchannel 1 (0xbeef3097),offset 0x1d70,increment
18:50 #nouveau: < lb1> 00000009    NV40TCL[0x1d70/4]
18:50 #nouveau: < lb1> 00042104  size 1, subchannel 1 (0xbeef3097),offset 0x0104,increment
18:50 #nouveau: < lb1> 00000000    NV40TCL.NOTIFY
18:50 #nouveau: < lb1> 00042100  size 1, subchannel 1 (0xbeef3097),offset 0x0100,increment
18:50 #nouveau: < lb1> 00000000    NV40TCL.NOP
18:51 -!- rhodan [n=quassel@120-88.107-92.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
18:51 #nouveau: < lb1> trying to figure it out
18:53 #nouveau: < lb1> 1d6c/1d70 requests a 3D engine fence
18:56 #nouveau: < ymanton> looks like a full flush & block
18:57 #nouveau: < lb1> yes
18:57 #nouveau: < lb1> seems it does the 0x1710 and then waits for the GPU
18:58 #nouveau: < lb1> this happens before after setting up things and on every glFlushVertexArrayRangeNV call
18:58 #nouveau: < lb1> how do we wait for the GPU with the current framework though?
18:58 #nouveau: < lb1> it seems it would need a kernel patch
18:59 #dri-devel: < zhasha> Dr_Jakob: on the topic of inter-st communication, what becomes of the current dri state tracker and will it provide an interface for future state trackers to go the way of mesa and have 1 major tracker with bindings for different windowing systems?
18:59 #dri-devel: < Dr_Jakob> zhasha: st/dri still be around
18:59 #nouveau: < ymanton> waiting is in the kernel probably, iirc we used to wait on fences in userspace
18:59 #nouveau: < ymanton> before ttm
19:00 #dri-devel: < Dr_Jakob> I don't forsee it going away any time soon.
19:00 #nouveau: < lb1> yes but it only does it automatically afaik and there is no clean way to do that manually
19:00 #nouveau: < lb1> anyway
19:01 #dri-devel: < zhasha> no but I think it was you who talked about doing a couple of structural changes
19:01 #nouveau: < lb1> it's strange, why would we need to wait for the fence?
19:01 #dri-devel: < Dr_Jakob> Ah right it will mostly be the same
19:01 #nouveau: < lb1> 0x1710 alone doesn't help, and we already use it
19:01 #nouveau: < lb1> unless maybe it should be put *after* rendering
19:02 #dri-devel: < zhasha> and my memory being absolutely horrible, I can't remember if you're one of the people for splitting gallium into several libraries
19:02 #dri-devel: < Dr_Jakob> Ah you mean r300_gallium.so ?
19:02 #dri-devel: < zhasha> something like that
19:03 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
19:03 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Remote closed the connection]
19:03 #dri-devel: < zhasha> the general point being pipes, winsys and state trackers compiled into their own individual libraries
19:03 #dri-devel: < Dr_Jakob> Not realy, I'm more charmed to the idea of putting all the pipe drivers and winsys into a single large binary.
19:03 -!- [Enrico] [n=chiccoro@gentoo/contributor/Enrico] has quit [Read error: 104 (Connection reset by peer)]
19:04 #dri-devel: < zhasha> yeah but at least separating the state trackers
19:04 #nouveau: < Unhelpful> hrm, i'm not able to load glx because of an undefined symbol... but the symbol (_mesa_framebuffer_renderbuffer) is defined in the libdricore.so module.
19:04 #dri-devel: < zhasha> though that would require a well defined winsys<->st api that is more or less impossible to make
19:04 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #nouveau
19:04 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has joined #dri-devel
19:05 #dri-devel: < Dr_Jakob> well stable at least
19:05 #dri-devel: < Dr_Jakob> and a stable pipe interface as well.
19:06 #dri-devel: < Dr_Jakob> zhasha: A well defined winsys<->st api is what st_api.h is about btw.
19:06 #dri-devel: < zhasha> but the only reason I can come up with to do it is to avoid distros like Fedora shipping a 100MB+ binary to include all combinations of st/winsys
19:06 -!- dileX_ [n=sd@vpn-eu1.unidsl.de] has joined #radeon
19:06 -!- dileX [n=sd@vpn-eu1.unidsl.de] has quit [Read error: 104 (Connection reset by peer)]
19:07 -!- asdruv [n=chatzill@201.193.169.146] has joined #nouveau
19:07 #dri-devel: < zhasha> and make development marginally more convenient
19:08 #dri-devel: < Dr_Jakob> its only the rendering API's that are large, st/egl & st/dri + winsys is small compaired.
19:08 -!- Tureba [i=bb175094@gateway/web/freenode/x-gnbrnudqjuvzyzfd] has joined #nouveau
19:08 #nouveau: < airlied> Unhelpful: thats a distro patch
19:09 #nouveau: < airlied> libdricore isn't in mesa upstream
19:09 #dri-devel: < Dr_Jakob> So when you say winsys do you mean st/dri or src/gallium/winsys/*
19:09 #dri-devel: < zhasha> radeong_dri.so is roughly 13MB, now imagine we have 3 state trackers with that winsys, and for the sake of fun say they take the same space, and 10 different winsys
19:09 #dri-devel: < zhasha> I mean src/gallium/winsys
19:10 #nouveau: < Unhelpful> airlied: hrm... better see where it came from, my libgl is built from mesa git so that it matches the nouveau gallium version i have installed elsewhere
19:10 #dri-devel: < Dr_Jakob> so what comes out from src/winsys/ are A) the resource managment and B) the final driver.
19:11 #dri-devel: < Dr_Jakob> Now A) is small a couple of houndres of K's max
19:11 #nouveau: < Unhelpful> swrast_dri.so and libdricore.so are both from libgl-git. i don't *think* it patches the git sources after fetch but i'll check again
19:11 #dri-devel: < Dr_Jakob> B) is everything the about 2mb is the pipe driver plus the gallium run time (src/gallium/aux)
19:12 #dri-devel: < Dr_Jakob> err
19:12 #dri-devel: < Dr_Jakob> B) is everything, about 2mb of this is the pipe driver plus the gallium runtime (src/gallium/aux/*)
19:13 #dri-devel: < Dr_Jakob> I would guess another 1mb is src/mesa/state_tracker, while the rest is mesa/main and mesa/shader
19:13 #dri-devel: < curro_> Dr_Jakob: btw, the main reason calling dri2getbuffers on each glViewport sucks so much is the (often useless) blit the X server performs
19:13 -!- asdruv [n=chatzill@201.193.169.146] has left #nouveau []
19:14 #dri-devel: < curro_> Dr_Jakob: that's easy to fix, but the events might still be worth it, because doing it on glViewport is "incorrect"
19:14 #nouveau: < Unhelpful> looks like nouveau-dri-git doesn't, but libgl-git does. once i have that sorted i suppose i'll be able to go back to crashing my X server :)
19:14 #dri-devel: < Dr_Jakob> curro_: right, but there is no other way (as far as we know).
19:14 #dri-devel: < zhasha> Dr_Jakob: that still implies that the st is one huge son of a bltch
19:14 #dri-devel: < Dr_Jakob> zhasha: yes
19:14 #dri-devel: < Dr_Jakob> In Fedora the have a hack to seperate out src/mesa into a single seperate library.
19:14 #dri-devel: < curro_> Dr_Jakob: the blit can be avoided in many cases
19:15 #dri-devel: <+airlied> Dr_Jakob: not any more
19:15 #dri-devel: < zhasha> and the mesa-dri-drivers package in fedora ships 14 different drivers
19:15 #nouveau: < darktama> lb1: try using 0x1710 within draw_arrays/elements, *after* nv40_state_validate() however
19:15 #nouveau: < darktama> also play with 0x1714 maybe
19:15 -!- prg_ [n=prg@unaffiliated/prg] has joined #nouveau
19:15 #dri-devel: < Dr_Jakob> airlied: orly, FC12 would beg to differ?
19:15 #dri-devel: <+airlied> it was removed for F13
19:15 #dri-devel: < Dr_Jakob> Ah
19:15 #dri-devel: < Dr_Jakob> why?
19:15 #nouveau: < chithead> Unhelpful: libgl-git sound like archlinux. remove mesa-7.1-link-shared.patch
19:15 #dri-devel: <+airlied> symbol visiblity
19:15 -!- edman007 [n=edman007@pdpc/supporter/active/edman007] has quit [Remote closed the connection]
19:15 #dri-devel: < Dr_Jakob> Ah
19:15 #dri-devel: < zhasha> oh wait, only 13 different drivers, but still
19:15 #dri-devel: <+airlied> didn't feel like fixing all the mesa smybols
19:16 #dri-devel: < Dr_Jakob> The big problem is that who takes resposibilit when the API changes.
19:17 #dri-devel: < Dr_Jakob> If mesa releases everything as seperate drivers its our fault for when things break if users only install certain parts.
19:17 #dri-devel: < Dr_Jakob> If the distrobutions does it its thiers
19:18 #dri-devel: <+airlied> thats why we didn't ship it in parts
19:18 #nouveau: < ymanton> 0x1710 is odd, flushes vtx shader regs perhaps
19:19 #dri-devel: < Dr_Jakob> All things said and done, compiling all the gallium drivers into a single mega driver would only add about 500k-1mb per pipe
19:19 #dri-devel: < Dr_Jakob> to the final binaries
19:19 #dri-devel: < Dr_Jakob> binary*
19:19 #nouveau: < ymanton> did anyone ever check if a passthru vtx shader worked?
19:19 #dri-devel: < zhasha> alas, we have livecds that have very strict spatial requirements. Now imagine 170MB out of a total 700 has to go to simply have 3D drivers available
19:20 #dri-devel: < Dr_Jakob> Super binary?
19:20 #dri-devel: < zhasha> yeah didn't see that before I pressed enter :/
19:20 #nouveau: < darktama> why wouldn't it? we use one if we fallback to the draw module
19:20 #dri-devel: < Dr_Jakob> Hehe ok
19:20 #dri-devel: < zhasha> my internet connection is wonky today. http barely works and irc has a HUGE lag
19:20 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 60 (Operation timed out)]
19:20 -!- lb1 [n=lb1@93-34-50-117.ip48.fastwebnet.it] has quit [Read error: 60 (Operation timed out)]
19:20 -!- MAbeeTT [n=MAbeeTT@190.179.201.28] has quit [Read error: 113 (No route to host)]
19:20 -!- MAbeeTT [n=MAbeeTT@190.179.201.28] has quit [Read error: 113 (No route to host)]
19:21 #nouveau: < Unhelpful> chithead: i am using arch, and that's what i found in the AUR PKGBUILD. :)
19:21 -!- edman007 [n=edman007@pdpc/supporter/active/edman007] has joined #radeonhd
19:21 #dri-devel: < zhasha> super binary is a very good idea
19:21 #nouveau: < ymanton> i mean check if it fixed the corruption on some of these nv40s
19:21 #nouveau: < chithead> yes, that includes broken patches such as the one mentioned above
19:21 #nouveau: < darktama> ymanton: oh, lol right :)
19:22 #dri-devel: < zhasha> err well, that depends. will it drastically increase the memory footprint?
19:22 #dri-devel: < Dr_Jakob> well you will always have the unused pipe drivers in memory
19:23 #dri-devel: < zhasha> I suppose if you compile 1 super binary per state tracker it won't make much of a difference I guess
19:24 #dri-devel: < Dr_Jakob> it would, it would be 13 * 13 * X vs 25 * X, where X is the number of state trackers.
19:24 #dri-devel: < Dr_Jakob> given that a single dri driver is 13mb
19:24 #nouveau: < ymanton> although it doesnt make sense to have to invalidate the vtx reg file...
19:24 #dri-devel: < Dr_Jakob> and a super driver is 25mb
19:25 #dri-devel: < MostAwesomeDude> Perhaps we need an interface for dlopen()ing winsys/pipe drivers from st?
19:25 #dri-devel: < zhasha> I meant memory-footprint-wise
19:25 #dri-devel: < Dr_Jakob> ah
19:25 #dri-devel: < zhasha> in terms of filesize you unlocked the holy grail
19:26 #dri-devel: < zhasha> libr300 is 1MB and libradeongallium (winsys) is 100kB
19:27 #dri-devel: < Dr_Jakob> yeah winsys's are small, pipe sorta small.
19:27 #dri-devel: < Dr_Jakob> its the bloody shader compilers that are huge.
19:28 #dri-devel: < zhasha> even softpipe is only around 1MB
19:29 #dri-devel: < Dr_Jakob> its also the esiest to do... about 4 lines in st/dri, 1 line in each winsys, a array collecting all the winsys's and a Makefile linking it all.
19:29 #dri-devel: < ymanton> Dr_Jakob: why is this dri2/glViewport hack necessary?
19:30 #dri-devel: < ymanton> there's no way for a dri2 client to know that the fake front was resized?
19:30 #dri-devel: < Dr_Jakob> because we don't get any notification in DRI about window resize.
19:30 #dri-devel: < Dr_Jakob> well the notification is that the app calls glViewports.
19:30 #dri-devel: < Dr_Jakob> -s
19:30 #dri-devel: < ymanton> but glViewport is also called for a bunch of other things
19:31 #dri-devel: < Dr_Jakob> yeah, hence my hatered for this particular use.
19:31 #dri-devel: < ymanton> notification cant be added to dri2?
19:32 #dri-devel: < Dr_Jakob> Yes it can, but at least VMware needs to support old servers.
19:32 -!- prg [n=prg@unaffiliated/prg] has quit [Read error: 110 (Connection timed out)]
19:32 #dri-devel: < Dr_Jakob> Meh, strikes me that we could just backport the dri2 module for old servers...
19:33 #dri-devel: < ymanton> yeah, its a bad oversight
19:35 #dri-devel: < ymanton> what happens when you dont have something like glViewport to inform you?
19:36 #dri-devel: < Dr_Jakob> Please I don't want to think about that...
19:36 #dri-devel: <+airlied> GL will keep drawing to the old buffer
19:36 #dri-devel: <+airlied> since i thasn't be told about the resize
19:37 #dri-devel: < ymanton> i meant what if its not GL we're talking about and theres no glViewport-esque call
19:38 -!- rhodan [n=quassel@179-49.3-85.cust.bluewin.ch] has joined #radeon
19:38 #nouveau: < Unhelpful> chithead: thanks, seems swrast is back in good shape... though perhaps *everything* should have the "slow" caveat for swrast :)
19:38 #dri-devel: <+airlied> not sure what XvMC does, and we don't really have any other direct rendering interfaces I don't think
19:39 #dri-devel: < Dr_Jakob> VG, but I think it has vgViewport
19:40 #dri-devel: < ymanton> XvMC does XGetGeometry()
19:41 #dri-devel: < ymanton> but thats for dri1, it uses that to resize its private backbuffer to the window
19:44 #dri-devel: < ymanton> it would have to do dri_get_buffers for every XvMCPutPicture in the dri2 case, even worse than the glViewport hack
19:48 #dri-devel: < Dr_Jakob> airlied: when you ship binaries, do you use strip to make them smaller?
19:56 -!- rhodan_ [n=quassel@168-104.107-92.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
19:57 #dri-devel: <+airlied> Dr_Jakob: we ship debuginfo in a separte package
19:57 #dri-devel: < Dr_Jakob> ok, how do you do that?
19:57 -!- bgoglin [n=bgoglin@dalton.bordeaux.inria.fr] has quit [Remote closed the connection]
19:57 -!- bgoglin [n=bgoglin@dalton.bordeaux.inria.fr] has quit [Remote closed the connection]
19:57 #dri-devel: <+airlied> Dr_Jakob: magic
19:58 -!- bgoglin [n=bgoglin@dalton.bordeaux.inria.fr] has joined #dri-devel
19:58 -!- bgoglin [n=bgoglin@dalton.bordeaux.inria.fr] has joined #radeon
19:58 #dri-devel: < Dr_Jakob> apparantly...
19:58 #dri-devel: <+airlied> mesa debuginfo package for F13 is 34MB
19:58 #dri-devel: < Dr_Jakob> heh
19:59 #dri-devel: <+airlied> only 15MB for the old dricore hack
20:00 #dri-devel: < Dr_Jakob> hmm, a stip dri driver is only 2.4mb..
20:00 #dri-devel: < Dr_Jakob> stripped*
20:00 #dri-devel: <+airlied> see if it still loads ::-)
20:00 #dri-devel: <+airlied> strip -d might be nicer
20:02 #dri-devel: < Dr_Jakob> airlied: glxgears worked on i965...
20:04 -!- tmerriam_ [n=quassel@c-67-173-170-177.hsd1.il.comcast.net] has left #radeon ["http://quassel-irc.org - Chat comfortably. Anywhere."]
20:04 -!- crimsonflame123 [n=chatzill@122.167.115.153] has quit [Remote closed the connection]
20:04 -!- crimsonflame123 [n=chatzill@122.167.115.153] has quit [Remote closed the connection]
20:08 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Remote closed the connection]
20:08 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Remote closed the connection]
20:10 -!- dileX [n=sd@p5B2ECC94.dip.t-dialin.net] has joined #radeon
20:11 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
20:11 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
20:12 #dri-devel: < Dr_Jakob> Hmmm compiling the binaries without "-g" gives:
20:12 #dri-devel: < Dr_Jakob> -rwxr-xr-x 1 jakob jakob 2.6M 2010-01-15 04:04 lib/gallium/i965_dri.so
20:12 #dri-devel: < Dr_Jakob> -rwxr-xr-x 1 jakob jakob 3.1M 2010-01-15 04:04 lib/i965_dri.so
20:12 #dri-devel: < Dr_Jakob> clearly something must be wrong.
20:13 #dri-devel: < Dr_Jakob> And now for something completely different: depth/stencil buffers are shared under glx right?
20:16 -!- BioTube [n=biotube@adsl-71-145-166-154.dsl.austtx.sbcglobal.net] has quit [Remote closed the connection]
20:17 -!- anholt [i=anholt@97-120-77-117.ptld.qwest.net] has joined #dri-devel
20:17 -!- mode/#dri-devel [+v anholt] by ChanServ
20:17 #dri-devel: <+airlied> don't think GLX places any rules on that
20:17 #dri-devel: < Dr_Jakob> But they are shared under DRI2 at least...
20:18 #dri-devel: <+airlied> I think only the drivers do that
20:19 #dri-devel: < Dr_Jakob> Hmm okay...
20:19 #dri-devel: <+airlied> since the drivers know the hw and can do it
20:19 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has quit [Remote closed the connection]
20:19 -!- DanaG [n=dana@66-169-236-186.static.snlo.ca.charter.com] has quit [Remote closed the connection]
20:19 #dri-devel: < Dr_Jakob> I'm pretty sure that I have heard that they are shared...
20:19 #dri-devel: <+airlied> you heard wrong, at least I can't see anywhere in the DRI2 core it does it
20:19 #dri-devel: <+airlied> in the driver specifc code only
20:20 -!- zhasha_ [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #dri-devel
20:20 -!- zhasha_ [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has joined #radeon
20:20 -!- keith_ [n=keith@pool-173-69-130-94.bltmmd.fios.verizon.net] has quit [Read error: 110 (Connection timed out)]
20:20 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
20:20 -!- zhasha [n=zhasha@port468.ds1-hhl.adsl.cybercity.dk] has quit [Read error: 104 (Connection reset by peer)]
20:21 #dri-devel: < Dr_Jakob> Meh where is idr when you need him..
20:23 -!- zhasha_ is now known as zhasha
20:23 -!- zhasha_ is now known as zhasha
20:23 -!- dileX_ [n=sd@vpn-eu1.unidsl.de] has quit [Read error: 110 (Connection timed out)]
20:23 #dri-devel: < Dr_Jakob> ugh sleep now..
20:24 #dri-devel: < zhasha> so Dr_Jakob, are you in Sweden right now?
20:26 #dri-devel: < Dr_Jakob> London
20:30 #dri-devel: < zhasha> so it's 4:30 right now... yeah, you should probably not be on here
20:30 -!- MichaelLong [n=ML@p508C828F.dip0.t-ipconnect.de] has quit [Remote closed the connection]
20:30 -!- MichaelLong [n=ML@p508C828F.dip0.t-ipconnect.de] has quit [Remote closed the connection]
20:31 -!- MichaelLong [n=ML@p508C87D1.dip0.t-ipconnect.de] has joined #nouveau
20:31 -!- MichaelLong [n=ML@p508C87D1.dip0.t-ipconnect.de] has joined #radeon
20:32 -!- Ronis_BR [n=Ronan@200-181-80-67.bsace705.dsl.brasiltelecom.net.br] has joined #radeon
20:35 -!- thaytan [n=jan@ip-210-185-20-158.internet.co.nz] has quit [Read error: 60 (Operation timed out)]
20:36 -!- andyrtr [n=andyrtr@archlinux/developer/andyrtr] has quit ["Ex-Chat"]
20:46 -!- zed|merge [n=merge@dslb-092-072-006-029.pools.arcor-ip.net] has joined #radeonhd
20:46 -!- zed|merge [n=merge@dslb-092-072-006-029.pools.arcor-ip.net] has joined #radeon
20:46 -!- zed|merge [n=merge@dslb-092-072-006-029.pools.arcor-ip.net] has joined #nouveau
20:49 #radeon: <@airlied> benh: ping
20:53 -!- damentz [n=damentz@99.184.78.177] has quit [Read error: 104 (Connection reset by peer)]
20:54 -!- rhodan_ [n=quassel@183-20.106-92.cust.bluewin.ch] has joined #radeon
20:56 -!- jimenez [n=jimenez@200.88.213.133] has joined #radeon
20:56 -!- jimenez [n=jimenez@200.88.213.133] has joined #radeonhd
20:57 -!- damentz [n=damentz@99.184.78.177] has joined #radeon
20:59 -!- zackr [n=zack@c-68-82-27-85.hsd1.pa.comcast.net] has quit [Read error: 110 (Connection timed out)]
20:59 -!- taiu [n=andrem@20.146.191.90.dyn.estpak.ee] has joined #radeonhd
20:59 -!- taiu [n=andrem@20.146.191.90.dyn.estpak.ee] has joined #dri-devel
20:59 -!- taiu [n=andrem@20.146.191.90.dyn.estpak.ee] has joined #radeon
21:01 -!- Poly-C [n=Poly-C@gentoo/developer/Polynomial-C] has joined #radeonhd
21:01 -!- Poly-C [n=Poly-C@gentoo/developer/Polynomial-C] has joined #radeon
21:01 -!- Poly-C [n=Poly-C@gentoo/developer/Polynomial-C] has joined #nouveau
21:01 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] has quit [Read error: 60 (Operation timed out)]
21:01 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] has quit [Read error: 60 (Operation timed out)]
21:01 -!- Polynomial-C [n=Poly-C@gentoo/developer/Polynomial-C] has quit [Read error: 60 (Operation timed out)]
21:02 -!- zen|merge [n=merge@dslb-092-072-004-101.pools.arcor-ip.net] has quit [Read error: 113 (No route to host)]
21:02 -!- zen|merge [n=merge@dslb-092-072-004-101.pools.arcor-ip.net] has quit [Read error: 113 (No route to host)]
21:02 -!- zen|merge [n=merge@dslb-092-072-004-101.pools.arcor-ip.net] has quit [Read error: 113 (No route to host)]
21:04 -!- Ronis_BR [n=Ronan@200-181-80-67.bsace705.dsl.brasiltelecom.net.br] has quit [Remote closed the connection]
21:05 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #radeonhd
21:05 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #dri-devel
21:05 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #radeon
21:06 -!- Amorphous [i=jan@unaffiliated/amorphous] has quit [Read error: 110 (Connection timed out)]
21:09 -!- Amorphous [i=jan@unaffiliated/amorphous] has joined #nouveau
21:10 -!- prg_ is now known as prg
21:11 -!- rhodan [n=quassel@179-49.3-85.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
21:12 -!- turmlos [n=turmlos@c-24-91-77-221.hsd1.nh.comcast.net] has quit [Remote closed the connection]
21:12 -!- turmlos [n=turmlos@c-24-91-77-221.hsd1.nh.comcast.net] has quit [Remote closed the connection]
21:12 -!- turmlos [n=turmlos@c-24-91-77-221.hsd1.nh.comcast.net] has quit [Remote closed the connection]
21:14 -!- Lutz_Ifer [i=Lutz@p549DC5B5.dip.t-dialin.net] has joined #radeon
21:15 -!- Tureba [i=bb175094@gateway/web/freenode/x-gnbrnudqjuvzyzfd] has quit ["Page closed"]
21:15 -!- trofi [n=slyfox@93.84.110.191] has joined #nouveau
21:17 -!- mjl [n=mjl@binkley.secnet.net.au] has quit [Remote closed the connection]
21:18 #radeon: < benh> airlied: howdy
21:19 -!- wirry [n=wirry@88.130.198.228] has joined #radeon
21:19 -!- wirry [n=wirry@88.130.198.228] has joined #radeonhd
21:20 -!- droid0011 [n=g1@p4FDC951A.dip.t-dialin.net] has joined #radeon
21:20 -!- taiu [n=andrem@20.146.191.90.dyn.estpak.ee] has quit [Read error: 110 (Connection timed out)]
21:20 -!- taiu [n=andrem@20.146.191.90.dyn.estpak.ee] has quit [Read error: 110 (Connection timed out)]
21:20 -!- taiu [n=andrem@20.146.191.90.dyn.estpak.ee] has quit [Read error: 110 (Connection timed out)]
21:22 #radeon: <@airlied> benh: hey so just looking at radeonfb PM stuff, I notice they mostly used D2? any ideas why isntead of D3?
21:22 #radeon: < benh> airlied: older chips use D2
21:23 #radeon: < benh> airlied: r3xx use D3
21:23 #radeon: < benh> airlied: (D3 cold even)
21:23 #radeon: < benh> airlied: as for why D2 on the older ones, well, that's history ... that's what MacOS does and what the ATI contributed PM code does
21:23 #radeon: < benh> airlied: we don't have the code for full D3 on those
21:23 #radeon: < benh> airlied: in addition, on some machines (including thinkpads), the HW doesn't actually power down the chip
21:23 #radeon: < benh> airlied: so D2 is pretty much the best power saving you can get
21:24 -!- rhodan [n=quassel@81.62.126.197] has joined #radeon
21:24 #radeon: < benh> airlied: ie, the code in radeon_pm has stuff for dynamic clocks, D2 on M6, M7 and M9
21:24 -!- turmlos [n=turmlos@c-24-91-77-221.hsd1.nh.comcast.net] has joined #dri-devel
21:24 -!- turmlos [n=turmlos@c-24-91-77-221.hsd1.nh.comcast.net] has joined #radeon
21:24 -!- turmlos [n=turmlos@c-24-91-77-221.hsd1.nh.comcast.net] has joined #radeonhd
21:24 #radeon: < benh> airlied: and full POST for rv350
21:24 #radeon: <@airlied> I'm trying to D3 an M7 now and its not playing nice ;-)
21:24 #radeon: < benh> airlied: yeah, there's lots of subtle things in the power sequencer in the chip
21:25 #radeon: < benh> airlied: I'd rather stick to the ATI provided code :-)
21:25 -!- MrGrim [n=mrgrim@c-98-223-33-216.hsd1.in.comcast.net] has joined #nouveau
21:25 #radeon: < benh> airlied: unless the BIOS cuts power off the chip in which case it doesn't matter, it's going to come back cold :-)
21:25 #radeon: < benh> airlied: and you need POST
21:25 #radeon: <@airlied> well cold is easy
21:25 #radeon: <@airlied> since I just copy the BIOS
21:25 #radeon: < benh> airlied: yeah
21:25 #radeon: < benh> airlied: except on pmac where you need all my black magic for rv350
21:25 #radeon: <@airlied> its the half way between cold and running that screws me
21:25 #radeon: < benh> airlied: yeah, just stick to D2
21:26 #radeon: < benh> airlied: M7 has revisions also, it's possible that the code in there only works on whatever Apple uses and whatever SGRAM chips Apple uses, hard to tell
21:26 #radeon: < benh> airlied: I think it's been used on some thinkpads too though
21:26 #radeon: <@airlied> I've got a discrete M7 dev card I'm playing on
21:26 #radeon: < benh> ok
21:26 #radeon: < benh> airlied: you'll be at LCA next week ?
21:27 #radeon: <@airlied> benh: only for a couple of days, really just flying in to give my talk ;-)
21:27 #radeon: < benh> heh
21:27 #radeon: < benh> well, I'm there on monday PM
21:27 #radeon: < benh> til Sat.
21:27 #radeon: <@airlied> I think I get in Wed and out Fri, so I'm mostly there THur
21:27 #radeon: < benh> ok
21:29 #radeon: < benh> well, so maybe see you for a drink on Thu
21:30 #radeon: < benh> gotta run, ttyl
21:30 -!- benh [n=benh@nat/ibm/x-rionimkdczpkzmwf] has quit ["Leaving"]
21:30 -!- benh [n=benh@nat/ibm/x-rionimkdczpkzmwf] has quit ["Leaving"]
21:30 -!- benh [n=benh@nat/ibm/x-rionimkdczpkzmwf] has quit ["Leaving"]
21:33 -!- m03sizlak [n=x1001011@pool-98-117-162-201.bflony.fios.verizon.net] has quit [Read error: 113 (No route to host)]
21:36 -!- droid001 [n=g1@p4FDCA3D6.dip.t-dialin.net] has quit [Connection timed out]
21:39 -!- trofi [n=slyfox@93.84.110.191] has quit [Read error: 113 (No route to host)]
21:40 -!- wirry [n=wirry@88.130.198.228] has quit ["Lost terminal"]
21:40 -!- wirry [n=wirry@88.130.198.228] has quit ["Lost terminal"]
21:40 -!- thaytan [n=jan@131.203.102.171] has joined #nouveau
21:42 -!- rhodan_ [n=quassel@183-20.106-92.cust.bluewin.ch] has quit [Read error: 110 (Connection timed out)]
21:43 -!- mark_n [n=mark@nat/ibm/x-jsdainoxxuljshil] has quit [Remote closed the connection]
21:44 -!- illissius [n=illissiu@lg.vezer.elte.hu] has quit [Read error: 110 (Connection timed out)]
21:47 -!- paulez_ [n=paul@ezvan.fr] has joined #radeon
21:47 -!- acronica [n=michiel@5351EF59.cable.casema.nl] has quit ["Bye"]
21:48 -!- raevol [n=raevol@cpe-66-27-116-145.san.res.rr.com] has joined #radeon
21:49 -!- acronica [n=michiel@5351EF59.cable.casema.nl] has joined #radeonHD
21:54 -!- Duke` [n=henry@AVelizy-551-1-76-47.w90-2.abo.wanadoo.fr] has joined #dri-devel
22:01 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has joined #dri-devel
22:01 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has joined #radeon
22:01 -!- benh [n=benh@54.200.49.122-static.velocitynet.com.au] has joined #nouveau
22:02 -!- mode/#dri-devel [+v benh] by ChanServ
22:02 -!- work|philipp64 [n=chatzill@63.224.43.239] has quit [Read error: 113 (No route to host)]
22:02 -!- work|philipp64 [n=chatzill@63.224.43.239] has joined #radeon
22:04 #nouveau: < MostAwesomeDude> Heh, slow caveat.
22:04 #nouveau: < MostAwesomeDude> Wonder if that should still be there for accumbufs.
22:04 -!- kdekorte_ [n=kdekorte@64-187-77-49.iprev.kci.net] has quit [Read error: 60 (Operation timed out)]
22:05 -!- kdekorte_ [n=kdekorte@64-187-77-49.iprev.kci.net] has joined #radeon
22:15 -!- ScytheBlade1 [n=Death@about/pxe/ScytheBlade1] has quit [Remote closed the connection]
22:16 -!- ScytheBlade1 [n=Death@smtp.mail.averageurl.com] has joined #nouveau
22:19 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
22:19 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
22:19 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
22:20 -!- Sirsurthur [n=julien@162.25.94-79.rev.gaoland.net] has joined #nouveau
22:21 -!- seb__ [n=seb@78.114.208.133] has quit ["Lost terminal"]
22:21 -!- seb__ [n=seb@78.114.208.133] has quit ["Lost terminal"]
22:22 -!- taiu [n=andrem@88.196.5.89] has joined #radeonhd
22:22 -!- taiu [n=andrem@88.196.5.89] has joined #dri-devel
22:22 -!- taiu [n=andrem@88.196.5.89] has joined #radeon
22:24 -!- Thib_G [n=ThibG@abo-58-5-68.ech.modulonet.fr] has joined #nouveau
22:24 -!- Thib_G [n=ThibG@abo-58-5-68.ech.modulonet.fr] has quit [Read error: 104 (Connection reset by peer)]
22:24 -!- ThibG [n=ThibG@abo-58-5-68.ech.modulonet.fr] has joined #nouveau
22:25 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #radeonhd
22:25 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #dri-devel
22:25 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has joined #radeon
22:26 -!- Nightwulf|work [n=tevers@80.153.168.218] has joined #radeonhd
22:26 -!- Nightwulf|work [n=tevers@80.153.168.218] has joined #radeon
22:27 #RadeonHD: < Nightwulf|work> hi all
22:27 #radeon: < Nightwulf|work> hi all
22:28 -!- prg [n=prg@unaffiliated/prg] has quit []
22:29 -!- taiu [n=andrem@88.196.5.89] has quit [Read error: 60 (Operation timed out)]
22:29 -!- taiu [n=andrem@88.196.5.89] has quit [Read error: 60 (Operation timed out)]
22:29 -!- taiu [n=andrem@88.196.5.89] has quit [Read error: 60 (Operation timed out)]
22:29 -!- johanbr [n=j@blk-222-216-252.eastlink.ca] has quit ["Ex-Chat"]
22:30 -!- evil_core [i=evil@carme.pld-linux.org] has joined #radeon
22:30 #radeon: < evil_core> hi all
22:30 #radeon: < evil_core> gallium is still being broken by MAD?
22:31 #radeon: < MostAwesomeDude> It's less broken ATM.
22:31 #radeon: < evil_core> hmm...but quake3 main screen should still be broken?
22:31 #radeon: < MostAwesomeDude> Hm, don't think so. Lemme check.
22:32 #radeon: < evil_core> because it is for me. I wonder if I should restart xorg
22:32 #radeon: < MostAwesomeDude> OA works here.
22:32 #radeon: < MostAwesomeDude> Are you using ioquake3 or old quake3?
22:32 #radeon: < evil_core> yes
22:32 #radeon: < evil_core> ioquake3
22:33 #radeon: < evil_core> but I didnt rebooted machine/restarted xorg after rebuildinf libdrm/xorg
22:34 -!- SiaCo [n=thorbjor@cm-84.211.172.13.getinternet.no] has joined #radeonhd
22:35 -!- Duke` [n=henry@AVelizy-551-1-76-47.w90-2.abo.wanadoo.fr] has quit ["Connexion reset by bear"]
22:35 #nouveau: < Unhelpful> MostAwesomeDude: on swrast, or nouveau?
22:36 #nouveau: < MostAwesomeDude> Unhelpful: On Gallium DRI2 drivers.
22:37 #radeon: < evil_core> restarting xorg didnt helped
22:37 #radeon: < evil_core> still total mess in menu
22:37 #radeon: < MostAwesomeDude> OA, or original pak0?
22:38 #radeon: < MostAwesomeDude> None of us have the original pak0, so using OA would be way better.
22:39 -!- taiu [n=andrem@88.196.5.82] has joined #radeonhd
22:39 -!- taiu [n=andrem@88.196.5.82] has joined #dri-devel
22:39 -!- taiu [n=andrem@88.196.5.82] has joined #radeon
22:44 #radeon: < evil_core> OpenArena looks OK, but hangups kernel after few seconds
22:44 #radeon: < evil_core> in gallium mode
22:45 #radeon: < MostAwesomeDude> Yeah, I'm told that it causes hangs, but I have no idea why.
22:45 #radeon: < evil_core> but airlied claims it doesnt for his identcial T60p :/
22:45 #radeon: < evil_core> maybe because he is using 32bit?
22:46 #radeon: < evil_core> anyway quake3 menu and xmoto is broken
22:48 #radeon: < evil_core> you can always use pak0 from demo, but xmoto menu is nightmare for me
22:48 #radeon: < evil_core> its hard to close it from within
22:50 -!- amarks_ [n=quassel@124-171-58-9.dyn.iinet.net.au] has joined #radeon
22:51 #radeon: < evil_core> supertuxkarts also
22:51 -!- geo27 [n=quassel@wallia27.ac-rouen.fr] has joined #radeon
22:51 #radeon: < evil_core> I think that openarena is exception ;)
22:52 #radeon: < evil_core> OpenArena is packaged from  binaries in most distros
22:52 #radeon: < evil_core> ioquake3 doesnt like most other games
22:52 -!- _KAMI_ [n=kami@catv-89-132-121-128.catv.broadband.hu] has joined #radeon
22:53 -!- _KAMI_1 [n=kami@host-50-018.comunique.hu] has joined #radeon
22:53 #radeon: < evil_core> and maybe its build against some realy old libGL, because its strange thats not afected by most problems like multitexture s3tc(maybe its content doesnt got one), etc
22:56 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
22:56 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
22:56 -!- taiu1 [n=andrem@tln-yksik-paastekomp-gw.estpak.ee] has quit [Read error: 110 (Connection timed out)]
22:57 -!- cxo [n=cxo@unaffiliated/cruiseoveride] has joined #radeon
22:57 #radeon: < cxo> Nexuiz is still broken for me (r700)
22:58 #radeon: < Nightwulf|work> runs well here (rv790)
22:58 #radeon: < cxo> its been broken for the last week or so for me, i've noticed this on the console:
22:58 #radeon: < cxo>  Draw_CachePic: failed to load gfx/complete
22:58 #radeon: < cxo> Draw_CachePic: failed to load gfx/inter
22:59 -!- amarks__ [n=quassel@124-171-31-49.dyn.iinet.net.au] has joined #radeon
22:59 #radeon: < cxo> GL_RENDERER: Mesa DRI R600 (RV770 9440) 20090101  TCL DRI2
22:59 #radeon: < cxo> GL_VERSION: 2.0 Mesa 7.8-devel
22:59 -!- curro__ [n=z3BxQ@217.104.220.87.dynamic.jazztel.es] has joined #nouveau
22:59 -!- curro__ [n=z3BxQ@217.104.220.87.dynamic.jazztel.es] has joined #dri-devel
23:00 -!- amarks_ [n=quassel@124-171-58-9.dyn.iinet.net.au] has quit [Read error: 60 (Operation timed out)]
23:01 #radeon: < cxo> Is there a way to see gl errors? like an strace for mesa?
23:01 -!- Sirsurthur [n=julien@162.25.94-79.rev.gaoland.net] has quit [Client Quit]
23:02 #radeon: < MostAwesomeDude> Bugle...
23:03 -!- gunni [n=quassel@xdsl-213-196-229-207.netcologne.de] has joined #nouveau
23:03 #radeon: < Nightwulf|work> cxo: nothing like that here...runs smooth
23:03 #radeon: < MostAwesomeDude> IF you build your Mesa with --enable-debug, it should gripe on GL errors.
23:03 #radeon: < Nightwulf|work> cxo: OpenGL renderer string: Mesa DRI R600 (RV635 9598) 20090101 x86/MMX+/3DNow!+/SSE2 TCL
23:03 #radeon: < Nightwulf|work> (@work)
23:03 #radeon: < Nightwulf|work> but same string @home with rv790
23:04 #radeon: < cxo> at least half the textures are missing here
23:04 -!- amarks [n=quassel@124-171-4-214.dyn.iinet.net.au] has quit [Read error: 110 (Connection timed out)]
23:04 #radeon: < cxo> alien arena and open arena are fine
23:04 #radeon: < Nightwulf|work> xorg-server 1.7.3.902, mesa-7.7, kernel 2.6.32.3
23:06 #radeon: < cxo> 1.7.4.3+3ubuntu, mesa-git,drm-git,linux-git,xf86-video-ati-git
23:06 -!- taiu1 [n=andrem@88.196.5.82] has joined #radeonhd
23:06 -!- taiu1 [n=andrem@88.196.5.82] has joined #dri-devel
23:06 -!- taiu1 [n=andrem@88.196.5.82] has joined #radeon
23:06 #radeon: < Nightwulf|work> cxo: last one applies here too...radeon is git from approx. 5 days ago
23:07 #radeon: < cxo> everything seems normal apart for Nexuiz
23:07 -!- Obscene_CNN_ [n=chatzill@207-254-33-78.amerion.net] has joined #radeonhd
23:07 -!- Obscene_CNN_ [n=chatzill@207-254-33-78.amerion.net] has joined #radeon
23:08 #radeon: < cxo> i have about 20k fps on glxgears without compiz, about 10k with compiz, over 200fps on openarena (1280x1024)
23:08 -!- Obscene_CNN [n=chatzill@207-254-33-78.amerion.net] has quit [Read error: 104 (Connection reset by peer)]
23:08 -!- Obscene_CNN [n=chatzill@207-254-33-78.amerion.net] has quit [Read error: 104 (Connection reset by peer)]
23:08 -!- Obscene_CNN_ is now known as Obscene_CNN
23:08 -!- Obscene_CNN_ is now known as Obscene_CNN
23:08 #radeon:  * cxo should install some of those fancy gfx benchmarks from phoronix
23:09 #radeon: < cxo> Isnt there like a basic sanity test program for mesa that just calls every function and checks its return values?
23:09 #radeon: < Nightwulf|work> only thing not running ok here is blender...shows some severe redraw errors
23:11 -!- _KAMI_1 [n=kami@host-50-018.comunique.hu] has quit [Read error: 60 (Operation timed out)]
23:11 #radeon: < cxo> i know i'm on the edge, but people honestly need to do more regression testing
23:11 #radeon: < zhasha> cxo: try running piglit
23:12 #radeon: < cxo> is that a mesa demo?
23:13 #radeon: < Nightwulf|work> cxo: to be honest....i never encountered a project where i could use HEAD/MASTER revisions with so less doubts than this one...never had severe problems
23:13 #radeon: < MostAwesomeDude> Nightwulf|work: Well, all those other 3D driver projects must just be better off.
23:13 -!- _KAMI_ [n=kami@catv-89-132-121-128.catv.broadband.hu] has quit [Success]
23:13 #radeon: < MostAwesomeDude> Oh, wait.
23:14 -!- curro_ [n=z3BxQ@49.104.220.87.dynamic.jazztel.es] has quit [Read error: 110 (Connection timed out)]
23:14 -!- curro_ [n=z3BxQ@49.104.220.87.dynamic.jazztel.es] has quit [Read error: 110 (Connection timed out)]
23:14 #radeon: < Nightwulf|work> MostAwesomeDude: really? i doubt that...btw we talked about code quality in cutting edge code and i found it impressing to have so less trouble with this one
23:15 #radeon: < MostAwesomeDude> Nightwulf|work: I'm being sarcastic.
23:15 -!- boris64__ [n=boris64@p4FC6871C.dip0.t-ipconnect.de] has joined #radeon
23:15 -!- boris64__ [n=boris64@p4FC6871C.dip0.t-ipconnect.de] has joined #radeonhd
23:16 #radeon: < Nightwulf|work> MostAwesomeDude: yeah...i know...i tried to answer that way too...but i'm no native english speaking guy, so please forgive me if i didn't hit that point :-)
23:16 #radeon:  * cxo cant believe how ridiculous it is to run phoronix on ubuntu, forgets idea
23:17 -!- Erant [i=erant@plz.stfu.kthnx.org] has quit [Read error: 60 (Operation timed out)]
23:17 -!- gunni_ [n=quassel@xdsl-213-196-229-18.netcologne.de] has quit [Read error: 110 (Connection timed out)]
23:17 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has joined #dri-devel
23:17 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has joined #radeon
23:17 -!- ossman [n=drzeus@82-117-125-11.tcdsl.calypso.net] has quit [Remote closed the connection]
23:19 -!- Erant [i=erant@plz.stfu.kthnx.org] has joined #radeonhd
23:21 -!- dmb [n=Dmb@unaffiliated/dmb] has quit ["Leaving"]
23:21 -!- dmb [n=Dmb@unaffiliated/dmb] has quit ["Leaving"]
23:21 #radeon: < cxo> zhasha, what are the deps for piglit?
23:21 #radeon: < zhasha> X11 and GLX I presume
23:21 -!- _KAMI_ [n=kami@host-50-018.comunique.hu] has joined #radeon
23:21 #radeon: < zhasha> oh and cmake
23:22 #radeon: < cxo> it looks like its all in python?
23:22 #radeon: < zhasha> I think all the tests are in C
23:22 #radeon:  * cxo hates Make variants
23:23 #radeon: < zhasha> ccmake .
23:23 #radeon: < cxo> oh so i got to compile this first
23:23 #radeon: < zhasha> hammer random keys
23:23 #radeon: < zhasha> *pray*
23:23 #radeon: < zhasha> then make
23:23 #radeon: < cxo> did cmake .
23:23 #radeon: < zhasha> it's ccmake
23:23 -!- taiu [n=andrem@88.196.5.82] has quit [Read error: 110 (Connection timed out)]
23:23 -!- taiu [n=andrem@88.196.5.82] has quit [Read error: 110 (Connection timed out)]
23:23 -!- taiu [n=andrem@88.196.5.82] has quit [Read error: 110 (Connection timed out)]
23:24 #radeon: < cxo> cmake failed
23:24 #radeon: < cxo> oh ok
23:24 #radeon: < zhasha> yeah, I thought it was a type too the first time
23:24 #radeon: < zhasha> typo*
23:24 #radeon: < cxo> thats just a curses gui kinda of thing for cmake
23:24 -!- darktama [n=darktama@nat/redhat/x-fosuxmduogxpmcfg] has quit [Read error: 110 (Connection timed out)]
23:24 -!- darktama [n=darktama@nat/redhat/x-fosuxmduogxpmcfg] has quit [Read error: 110 (Connection timed out)]
23:25 #radeon: < cxo> my glew library cant be found or something
23:26 #radeon:  * cxo gives up
23:27 #radeon: < zhasha> seems to depend on GLEW then
23:27 #radeon: < cxo> 'make' that tries to do configure = fail
23:27 #radeon: < zhasha> it's the only test suite we got for conformance
23:27 #radeon: < zhasha> install glew, try again, hope
23:27 #radeon:  * cxo has no patience for cmake
23:28 #radeon: < zhasha> you wanted a conformance test suite, I gave you one. Stop complaining
23:29 #radeon: < cxo> you guys go to try mesa/progs/demos/tunnel
23:29 #radeon: < cxo> so cool
23:29 -!- JohnDoe_71Rus [n=JohnDoe@node-24-100.xdsl.tula.net] has joined #radeon
23:29 -!- JohnDoe_71Rus [n=JohnDoe@node-24-100.xdsl.tula.net] has joined #radeonhd
23:30 #radeon: < zhasha> how is that cool?
23:31 #radeon: < cxo> cos its so 3D
23:31 #radeon: < cxo> make it fullscreen, turn off the help message
23:31 -!- boris64_ [n=boris64@p4FC687B1.dip0.t-ipconnect.de] has quit [Read error: 110 (Connection timed out)]
23:31 -!- boris64_ [n=boris64@p4FC687B1.dip0.t-ipconnect.de] has quit [Read error: 110 (Connection timed out)]
23:32 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-gonvptvlnyjnafls] has joined #radeon
23:32 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-gonvptvlnyjnafls] has joined #dri-devel
23:32 -!- bertrik [n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl] has joined #radeonhd
23:34 -!- Obscene_CNN [n=chatzill@207-254-33-78.amerion.net] has quit [Read error: 110 (Connection timed out)]
23:34 -!- Obscene_CNN [n=chatzill@207-254-33-78.amerion.net] has quit [Read error: 110 (Connection timed out)]
23:36 -!- and1bm [n=andi@dslb-084-056-041-082.pools.arcor-ip.net] has joined #nouveau
23:41 -!- mvo [n=egon@p5B09D825.dip.t-dialin.net] has joined #dri-devel
23:45 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has quit []
23:45 -!- bjaglin [n=bjaglin@c83-254-159-149.bredband.comhem.se] has quit []
23:45 -!- sharky [n=sharky@c-66-177-111-89.hsd1.fl.comcast.net] has quit ["Ex-Chat"]
23:45 -!- sharky [n=sharky@c-66-177-111-89.hsd1.fl.comcast.net] has quit ["Ex-Chat"]
23:50 #radeon: < evil_core> (EE) AIGLX error: Calling driver entry point failed
23:50 #radeon: < evil_core> (EE) AIGLX: reverting to software rendering
23:50 #radeon: < evil_core> what I can do about that?
23:54 #radeon: < evil_core> it causes tearing for Xv
23:54 #radeon: < JohnDoe_71Rus> who can speak in Russian?
23:56 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-gonvptvlnyjnafls] has quit [Ping timeout: 180 seconds]
23:56 -!- seb__ [i=5a3a3f09@gateway/web/freenode/x-gonvptvlnyjnafls] has quit [Ping timeout: 180 seconds]
--- Log closed Fri Jan 15 00:00:14 2010