flo`: hi
zhick: do i need xf86-video-ati master for kms-powermanagement to work?
chithead: I think you don't even need to be running X
flo`: (how) can i get direct rendering without intel_agp? my laptop (thinkpad x31) has a "Intel Corporation 82855PM Processor to AGP Controller" and a radeon mobility m6 ly
flo`: with intel_agp loaded, it works, however s2ram doesn't work then. without it, s2ram works, but direct rendering doesn't :(
zhick: chithead: that was my understanding as well, but i somehow i can't get powermanagement working and i thought that might be the cause
dileX_: zhick: which kernel?
chithead: flo`: is it the presence of the intel agp module which makes it fail, or tha actual agpmode (try with -1)?
chithead: s/tha/the/
flo`: chithead, what should i try with -1?
chithead: the agpmode
flo`: where do i set this? in Xorg.conf or somewhere else?
chithead: for ums, in xorg.conf, see man radeon. for kms as kernel parameter
zhick: dileX: 2.6.35_rc3
flo`: btw, it's not X-related. it even occurs when i boot with init=/bin/bash
zhick: dileX: but i think i might've been wrong about pm not working.
flo`: but i'll try.
zhick: i assumed it's not working because there was no flickering going (and there was no change in power-consumption) when switching between the low, default and high profiles
zhick: but interestingly power-consumption does change when i switch to the auto profile: it goes up!?
zhick: ain't that weird or did i misunderstand the purpose of the auto-profile?
dileX_: zhick: http://nopaste.snit.ch/21210
zhick: dileX_: that script displays the same clocks for every profile
zhick: still power-consumption actually goes up when using auto?
DanaG: try method=dynpm
dileX_: power-profile... low
dileX_: current engine clock: 128250 kHz
dileX_: current memory clock: 135000 kHz
DanaG: er, echo dynpm into method.
zhick: DanaG: then the power-consumption is the same as when using low, default or high profile
dileX_: echo dynpm > $POWER_METHOD
DanaG: oh yeaH, THat patch to allow forcing low....
DanaG: it'd be nice to be able to choose what are upper and lower bounds of dynpm.
dileX_: zhick: which gpu?
zhick: dileX_: r500
zhick: dileX_: x1900xt to be exact
dileX_: here its rv515 (x1300)
dileX_: you started with kms enabled?
zhick: dileX_: yea
zhick: actually power-consumptions remains high when switching to the dynpm power_method from the auto-profile, and stays low when switching from any other profile to dynpm
dileX_: zhick: then you should report a bug and add your vbios to it
dileX_: http://nopaste.snit.ch/21211
zhick: dileX_: ya, will do. thanks. :)
bricky: hey
bricky: sorry but I got a question, is there any possible way to get ATI to use SVideo on my x200 mobile
flo`: chithead, it seems to have helped
flo`: i got about 15 successful cycles in a row.
flo`: however, there still is that strange error message (that vanishes when i remove the whole module)
flo`: pm_op(): pci_pm_resume+0x0/0x7f returns -16 and PM: Device 0000:00:00.0 failed to resume async: error -16
chithead: flo`: you may want to report a bug, including dmesg and the error message. so that your chipset/gpu combination could be added to a blacklist
flo`: chithead, blacklist for what? that suspend isn't allowed at all?
flo`: btw, error 16 is EBUSY (Device or resource busy)
chithead: either prevent suspend with agpmode not disabled, or defaulting to not use agp
flo`: not use agp -> no direct rendering, right?
chithead: operate in pci mode
flo`: is direct rendering then still possible?
flo`: in pci mode? or is it not possible or slower?
flo`: chithead, is direct rendering still possible in pci mode?
chithead: yes
flo`: slower or in same speed?
chithead: slower
flo`: ok. how can i set it into pci mode?
chithead: agpmode=-1
flo`: ah.
flo`: oops... and wtf
flo`: i set it to 1.
flo`: and it seems to work. can this be possible?
flo`: or did i only have luck that i got 10 successful suspend cycles?
chithead: can also be possible, that higher agp modes (2 and 4) don't work
flo`: well, actually they work. but only resuming _sometimes_ fail...
flo`: how is agpmode set when booting without X?
flo`: is it disabled, or is it set to some standard value (which?)
chithead: dmesg might tell
flo`: chithead, it doesn't
flo`: it only tells me that it is set to 1x when x is started
flo`: but not how it's set before
flo`: man radeon told me that default for AGPMode is "leave it untouched". and when i don't specify that option, glxinfo tells me that agpmode is 4x. is it correct then that agpmode is 4x also in text mode?
dileX_: $ find /sys/bus/pci/devices/0000:00:01.0/ -name rom
dileX_: /sys/bus/pci/devices/0000:00:01.0/0000:01:00.0/rom
dileX_: location of rom changed in 2.6.35-rcX
flo`: [trying something...]
bricky: hey
bricky: how do I back up my xorg.conf and restore it easily?
bricky: in ubuntu
bricky: I would like to try something out to get my svideo working :)
dileX_: bricky: location is normally /etx/X11/xorg.conf. if you have no xorg.conf you have to edit at your own. see also man xorg.conf.
flo`: chithead, i didn't do much testing, but putting the card into pci mode seems to help. at least, the strange message disappears. this message had served as a sure indicator for problems so far
flo`: is there a way to do this as a pm-suspend quirk?
flo`: because i actually need agpmode for certain games ;)
flo`: i didn't test this, but [gaming: agp4x], [close lid] [set to pci] [suspend] should work, right?
flo`: then, i have a much heavier problem: i just noticed that direct rendering in kernel 2.6.34 is broken -_-. in 2.6.26, glxgears shows nice rendered gears. 2.6.34 shows a black window with sometimes parts of a (wire-framed??) gear.
flo`: what's wrong there?
flo`: hi
flo`: after an upgrade from kernel 2.6.26 to 2.6.32, 3d graphic doesn't work
flo`: the output of glxinfo didn't change, but glxgears doesn't show the gears correctly
flo`: what's wrong there ._.?
mikkoc: this looks bad, with 2.6.35-rc3: http://pastebin.ca/1882181
mikkoc: let me know if i should report it
edwin: mikkoc: it doesn't hurt reporting
rhodan: What is the equivalent to "Quartz Extreme" on Linux?
rhodan: I would assume that it's AIGLX, but that doesn't seem to make things any faster ;)
Daekdroom: AIGLX was deprecated, I think
rhodan: Really? I thought XGL was.
Daekdroom: Huh, they all were, pretty much xD
rhodan: Let me guess.
rhodan: The new one is called...
rhodan: AccelKit
Daekdroom: DRI2?
mjr: AIGLX does exist. I don't know if the compositors generally use it anymore on DRI2 though.
rhodan: OK.
rhodan: kwin uses DRI2, then?
mjr: it uses what's available through libGL, one would think
rhodan: Moving windows with Quartz is really sweet.
rhodan: No tearing and 60fps constantly.
mjr: doesn't really know what Quartz Extreme is.
mjr: anyway, "moving windows" should be a relatively happy experience with any GL compositing window manager such as compiz or I suppose kwin
Daekdroom: Sometimes it's not o.o
rhodan: Is Compiz much faster than kwin=
rhodan: I would guess so, but its window manager sucks ;)
flo`: hi
flo`: is there any way to switch between AGP mode and PCI mode "on the fly" (having a radeon card, using radeon driver)?
flo`: in agp mode, my card is fast but failing to wake up from standby
flo`: in pci mode it's slower, but works.
flo`: i'd like it to be fast, and when going to sleep/waking up, it's set into pcimode. is that possible?
PeterNL: When is https://bugs.freedesktop.org/show_bug.cgi?id=28165 going to be fixed? I still have the same problems with debian testing
PhoenixSTF: Hello, i have a bit of an issue with a HD4670 can anyone give me a hint?
svenstaro: PhoenixSTF: just ask
PhoenixSTF: ok then! i got ubuntu lucid, and I just found out radeon got a bit of an issue with some games in wine, the text get all squared and unreadable! is there any update or driver i can use that performs better?
svenstaro: PhoenixSTF: which games?
PhoenixSTF: Cod mw2
PhoenixSTF: monkey island
svenstaro: You're using radeon for that? radeon can hardly handle nexuiz.
PhoenixSTF: so i read in wine cugzilla
PhoenixSTF: sorry radeon waht?
svenstaro: If you want to use wine, I'm afraid proprietary drivers may be a better choice.
svenstaro: radeon really isn't for gaming right now.
PhoenixSTF: HD 4670 1gb ddr3 it handles nexuiz like a xarm
svenstaro: Yes, but the free driver wont.
PhoenixSTF: ok proprietary driver, ok i got a new version of ATI but install the pacages is a issue
PeterNL: radeon is the name of the free driver. fglrx is the name of the closed driver
PhoenixSTF: i know
svenstaro: PhoenixSTF: Ubuntu should have it for you
PhoenixSTF: yes and it has the 7.23 fglrx
PhoenixSTF: but on ati there is a new one 7.32
svenstaro: ? 10.5 is newest.
PhoenixSTF: yes
PhoenixSTF: it is
svenstaro: 7.23 catalyst will not work at all and ubuntu isnt offering it.
PhoenixSTF: well thats what i am working on right know from ubuntu rep
PhoenixSTF: thats waht ubuntu is offering
PeterNL: 7.23? I thought the version numbers were year.month
svenstaro: They are
svenstaro: But PhoenixSTF is right, the versions are different
PhoenixSTF: ok got the 10.5
svenstaro: PhoenixSTF: is there any problem with the driver offered by ubuntu?
PeterNL: But how'd you put 23 (or even 32) months in 2007?
svenstaro: http://packages.ubuntu.com/lucid/fglrx
svenstaro: No idea PeterNL
PhoenixSTF: petter is not the catalist version is the driver package
PhoenixSTF: 8.723 is the one ubuntu has
PhoenixSTF: and i think that 8.732 is the one ati has
Daekdroom: version naming scheme fail
Daekdroom: xD
PhoenixSTF: this is the driver version on ubuntu 8.723.1-100408a-098580C-ATI
PeterNL: lost it... But I'm using the open drivers, which are in the kernel, so I could just say 2.6.32
PhoenixSTF: so i leave it alone and wait for another driver?
svenstaro: PeterNL: yeah, but you dont expect modern games to work with it over wine :/
Ke: ubuntu has 2.6.33 drm on 2.6.32
svenstaro: PhoenixSTF: probably
Daekdroom: Huh..
Daekdroom: The open drivers aren't in the kernel
Daekdroom: Only the DRM part o.o
PhoenixSTF: anyone got any workaround on the unreadable text in wine?
PeterNL: I'm installing nexuiz right now, just to see if it works ok. Supertuxkart works fine :O
svenstaro: PeterNL: it works, but benchmark against the proprietary drivers.
PhoenixSTF: will if you whant a game to pull for it try savage 2
PeterNL: If it works at 80% of the fglrx framerate with the same settings...
Daekdroom: That's dreamy
svenstaro: PeterNL: now try a source game
PhoenixSTF: Oh and i cant play TF2 correctly, it always very very slow
PeterNL: 80% is too much?
Daekdroom: Definitely yes
svenstaro: PhoenixSTF: start it with -dxlevel 80 -console -novid
Zaba: I wonder, how did they manage to do such scary things to QW?
PhoenixSTF: how do i do that?
svenstaro: PhoenixSTF: in steam, right click the game and go to launch options or what it is called
PhoenixSTF: oh right, dummy me!
PhoenixSTF: any of you play in wine?
svenstaro: Yes
PhoenixSTF: what games?
Zaba: For me, no opengl/directx game works well with wine.
Zaba: using r600
svenstaro: We played through Portal lots of times the last few days on LinuxTag 2010 in Berlin
Zaba: native is quite.. good, though. Well, darkplaces tends to be slow at some more heavy things.
svenstaro: Some TF2, some VVVVVV, some others.
PhoenixSTF: vvvvVV?
PhoenixSTF: ??
svenstaro: google it :)
Zaba: native Q3 runs fine.
Zaba: sauerbraten runs fine. So, I'm happy.
PhoenixSTF: sauerbraten on mine the crosshair is squary and blurry
PeterNL: Ok, I get 5~30 fps where I'd expect 50~150 fps...
PeterNL: But fglrx has all kinds of other problems...
svenstaro: Yes, use NVIDIA :P
svenstaro: Seriously though, I have two laptops using free radeon but for gaming they just suck.
Ke: did someone say flamewar?
svenstaro: YES
Daekdroom: Get your torches and pitchforks ready!
svenstaro: Actually no, I gotta learn for a maths exam but I'm procrastinating.
PhoenixSTF: ok i check vvvvvv
PhoenixSTF: is that simple game for real?
svenstaro: Yes of cours
svenstaro: Lots of fun if you're feeling masochistic.
PhoenixSTF: oh god...
PhoenixSTF: lol
svenstaro: Hah, any problems?
PeterNL: As soon as the open drivers are more complete, then nvidia is definately behind. But for now... Closed drivers suck from both ati/amd and nvidia, so I'd use intel, which only has low-end onboard stuff.
PhoenixSTF: sauberden is very low grafic imo, and whre do you get wuake wars?
PeterNL: So there's no solution atm
svenstaro: NVIDIA gives me same FPS and no trouble on either platform so I wouldnt say they suck.
Zaba: "As soon as the open drivers are more complete, [...]"---how soon is that?
Zaba: PhoenixSTF, what wars?
PeterNL: Meybe another year? I've been waiting since september 2007, so why not?
PeterNL: maybe*
Zaba: I don't need high graphics in games, as long as they provide decent gameplay.
Ke: would be way awesome to have fglrx closed source parts to work on radeon drm and xf86-video-ati
PhoenixSTF: Quake wars!
PeterNL: Ke: should we ask amd to make fglrx modular? I'm not an expert, so don't ask me
Zaba: PhoenixSTF, I was referring to the fact Source very distantly originates from quakeworld.
Ke: PeterNL: well I guess probably won't happen anyways
svenstaro: Just get fucking working and make some better free drivers :D
svenstaro: Seriously, if you see a slow down, use sysprof and provide a report.
svenstaro: Improve components that suck the most time out of each frame.
PhoenixSTF: Zaba: sorry to many conversations got confused!
Zaba: PhoenixSTF, I have quake itself running on a r600 card with free drivers, however. Well, that is, darkplaces with original game data.
PhoenixSTF: ok but i was talking about the game
PhoenixSTF: where do you get quake wars? like you have to pay for it?
Zaba: no idea, probably yes
Zaba: and I believe quake4 is not (yet?..) opensourced
PhoenixSTF: darn!
PhoenixSTF: anymore games you guys play in linux that are something good?
Zaba: I wonder, why did they rewrite id tech 4 in C++
Zaba: I mean, seriously..
svenstaro: PhoenixSTF: May I recommend http://live.linux-gamers.net/
PhoenixSTF: thanks guys
ripps: My computer completely locks up from time to time, and I'm unable to suspend. I've heard that it might be because the radeon drivers in Maverick have agp issues. Is this true?
boris64: Hey folks, is there any ETA for 2D/EXA/xv acceleration on evergreen cards?
ripps: would adding radeon.agpmode=-1 help?
MostAwesomeDude: ripps: More likely, *your* setup has issues. If a certain agpmode fixes things, let us know and we'll add a quirk for you.
MostAwesomeDude: agpmode can be -1 (disabled), 1, 2, 4, or 8.
ripps: MostAwesomeDude: I'm using a radeon 9600 Pro rv350
MostAwesomeDude: boris64: When It's Ready. I think they're reviewing it right now.
MostAwesomeDude: ripps: You could have a buggy motherboard. AGP bugs are a combination of southbridge, motherboard, GPU board, etc.
ripps: It's a MSI K7N2-GL nforce 2 mobo
MostAwesomeDude: Ugh, nForce. Well, I can't predict things for sure. It would be *really* useful if you could confirm that certain agpmodes do/don't work.
ripps: MostAwesomeDude: well, these issues seem to come and go. Pure lucid was working pretty well. Almost never froze and suspend worked. Now, with the new kernel and xserver in maverick, things seem faster, but I can't suspend and anywhere from 2-5 hours I get a complete system lockup.
MostAwesomeDude: ripps: Hm. Feel free to file a bug. Be aware that we will probably ask for agpmode testing. :3
ripps: I'll play around with agpmode. I have it set to disable (-1), if that works out well, I'll play around with some different speeds
ripps: I need to reboot first (or I could just wait for the next freeze)
ripps: On the other hand, I might be having other kernel/libc issues. I've been having a few apps crashing/behaving strangely lately... so this might just be related to those
ripps: Around alpha-4, I plan to do a complete wipe of my ubuntu system, perhaps starting fresh might be good
ripps: okay, system froze, and I've rebooted with radeon.agpmode=-1, let's see how long I last this time.
ripps: It seems the reason I can't use Ubuntu Unity interface is because r300 mesa doesn't support non_power_of_two extension. But it seems gallium will softpipe for this, so now I can't wait for gallium to come out.
zhasha: ripps: it's because r500 and older AMD hardware doesn't support real NPOT textures
zhasha: the r300g driver does however try to emulate it as best it can
ripps: Actually, according to what I've been reading, the hardware on the r300 should support it, but for some reason ati never exposed it.
zhasha: it doesn't
zhasha: it supports texture rectangles
BioTube: ripps: the hardware supports NPOT, but not with all operations
BioTube: therefore, to expose the extension, the driver's got to do a lot of backflips to support everything
zhasha: BioTube: no, it supports texture rectangles, which is in its own right a very limited subset of npot, but it's not npot
zhasha: most notably it can't do mipmaps
BioTube: zhasha: all I remember is MAD saying the operation limitations were the important parts
zhasha: and of course wrap modes, which essentially makes it useless - however r300g will emulate as much as possible
zhasha: I think the latest news on the subject was that it can pretty much all be achieved
zhasha: also, there's no such thing as a softpipe fallback
zhasha: first of all, softpipe, llvmpipe and cell, are all software rasterizers that work entirely on their own. The real fallbacks pretty much have to be emulated in the drivers
zhasha: we do have helper modules (like draw for software vp), but it has to be invoked from the driver
mattst88: zhasha, why don't we create a MESA_rectangle_texture extension or something that better matches what r300-r500 support?
ripps: been doing some tests for #ubuntu-x, just realized how fast mplayer XV is with dri1. It's too bad that dri2-kms radeon is still not as good as it was in the past.
ripps: it's probably because XV doesn't use overlay in kms anymore, right?
zhasha: mattst88: GL_{ARB,EXT,NV}_texture_rectangle
mattst88: ah. are all these use cases of NPOT texture actually needing the features of the extension that r300 doesn't have?
zhasha: but it doesn't matter, because apps want npot, including different modes and mipmaps
mattst88: gotcha.
ripps: how exactly does gallium work around the lack of NPOT?
ripps: is it software, or is it some clever trick?
zhasha: ripps: currently, r300g cheats
zhasha: mipmaps are allocated, drawn to and then subsequently never used (i.e. wasted memory)
zhasha: and the different modes are supposedly accommodated for in the shader compiler
zhasha: but I'm pretty sure it's only for 2D textures so far
MostAwesomeDude: There are three things missing from rects that we need for NPOT.
MostAwesomeDude: 1) Normalized coords. We do a mere re-normalization for r300; r500 can do normalized rects.
MostAwesomeDude: 2) Mipmaps. Frankly, no. Not happening.
MostAwesomeDude: 3) Wrap modes. We can and do emulate all these in the shader compiler.
MostAwesomeDude: So yeah. It's good enough; the only thing left is maybe not allocating full miptrees for NPOT. Otherwise, it's there and working.
zhasha: MostAwesomeDude: 3D textures and cubemaps are missing too, right?
MostAwesomeDude: zhasha: Ish. NPOT 3D is rare, and NPOT cubemaps require an additional extension IIRC. Also I think cubemaps work just fine as long as they are square.
svenstaro: Is gallium currently speedier than pure KMS?
MostAwesomeDude: Uh? KMS has no innate acceleration of any kind.
BioTube: svenstaro: gallium is solely 3d
svenstaro: Ok, are drivers with gallium faster or slower than without?
svenstaro: ie is r300g likely faster than r300?
MostAwesomeDude: Oh, compared to the classic drivers?
MostAwesomeDude: It's back-and-forth. We're slowly getting better.
svenstaro: Well, classic in my book is UMS so if classic means KMS for you, yes.
BioTube: most are worse than their classic counterparts, but r300g's nearly production-quality
airlied: finally switched rawhide to r300g
svenstaro: Sounds good. Can we expect the whole bundle of xorg 1.8, gallium drivers and KMS to be rather "final" in the sense that no other major overhauls (like KMS or gallium) need to be made?
svenstaro: So that they can be constantly improved without big changes that UMS -> KMS were?
MostAwesomeDude: airlied: DRI only, or DDX too? I still don't think it's ready as a DDX.
chithead: xorg 1.8 is final in the sense that only one last point release is planned
Daekdroom: svenstaro, don't worry, there'll always be something that needs to be redone. It's a coding law
airlied: MostAwesomeDude: ddx is pointless
airlied: never going to happen
svenstaro: Daekdroom: Of course, but currently we are seeing a gigantic reordering of all this tuff.
airlied: when I say r300g I never mean the DDX
Daekdroom: svenstaro, well, as far as I know the only thing that could happen would be a X.org replacement..
Daekdroom: and I think that's very unlikely
svenstaro: I mean, is there already something planned after KMS or gallium respectively?
MostAwesomeDude: Alrighty.
svenstaro: Daekdroom: But then given the new architecture we wouldnt care about the X server anymore as much, right? All drivers and graphics stuff would be out of it.
MostAwesomeDude: svenstaro: Meh. Things are always subject to change, but there's nothing planned.
svenstaro: MostAwesomeDude: Sounds good :)
Daekdroom: svenstaro, yeah. They might even try to port Gallium to Windows, but I doubt anyone would xD
airlied: gallium is already ported to windows
MostAwesomeDude: Daekdroom: Already done.
Daekdroom: Already done as in usable?
MostAwesomeDude: Gallium has WGL targets.
svenstaro: Free drivers on windows?
svenstaro: Or at least a free graphics interface.
airlied: gallium doesn't imply free
airlied: oropen
MostAwesomeDude: I haven't done the legwork to make r300g use Win32 fglrx, and I don't plan on writing a completely new Win32 kernel module.
Daekdroom: Yeah, look at the GMA500 driver..
airlied: the poulsbo windows driver is gallium based afaik
MostAwesomeDude: But other than that, yeah.
svenstaro: So r300g is pretty good, yeah? If I do graphics development, is it at all a good idea for me to switch to it now?
MostAwesomeDude: Yes. I accept bugs on r300g. I sometimes even fix them.
svenstaro: Is r300 still being worked on at all?
MostAwesomeDude: Oh, that should have had a smiley. Because it was a joke. Yeah. Totally.
MostAwesomeDude: But yeah, r300g bugs may be filed, so that's kind of an indicator of release readiness. Also Fedora will be shipping it.
svenstaro: Will it enter mainline this year?
MostAwesomeDude: It's already in the master branch. I'm not sure how much more mainline it could get.
svenstaro: Well, "default"? :P
Daekdroom: MostAwesomeDude, become the default option for compiling Mesa?
MostAwesomeDude: Ah. That would largely depend on demand, I think. If all the distros downstream are doing --enable-gallium, then I suppose it might make sense to build it by default.
svenstaro: What are the specific requirements for me to be able to try it out?
svenstaro: Xorg 1.8, mesa git?
Daekdroom: Uh.. KMS, DRM and Mesa git?
MostAwesomeDude: KMS and a libdrm_radeon built with support for it.
svenstaro: You better had made mipmapping hardware accelerated by the time I try it out not software based like last time.
MostAwesomeDude: You mean, mipmap generation?
svenstaro: Yes
MostAwesomeDude: That is entirely not up to me.
svenstaro: :(
MostAwesomeDude: *Entirely*.
svenstaro: I know it is mesa stuff but still.
MostAwesomeDude: The state tracker handles that, and it should support it.
svenstaro: Last time I tried KMS it was slow as fuck
MostAwesomeDude: Missing accelerated mipmap generation would not be a cause of extreme slowdowns.
MostAwesomeDude: What, specifically, was slow?
svenstaro: sysprof told me it was
svenstaro: The call to the mipmap generation function that I do not remember the exact name of
svenstaro: it took almost all of the init time of my app
svenstaro: UMS is 1 sec, KMS was 2 min
MostAwesomeDude: What are you doing in that app, exactly?
svenstaro: Loading models and putting textures on them, then displaying a scene.
MostAwesomeDude: Could you get those sysprof traces up on a bug? Also, the app in question, or a test case?
MostAwesomeDude: This was with classic, or Gallium? I'm not interested in classic bugs TBH./
svenstaro: It's pretty isolated but it runs on top of ogre. However, I could probably make a small app on pure opengl to reproduce it. I could also give you a call trace.
svenstaro: Alright then, I'll try gallium as I have nothing to lose, right? :P
svenstaro: Out of these arch packages that make up my current graphics stack, which do need to be rebuild against git with awesome special options for gallium? mesa, libdrm, xf86-video-ati, libgl, ati-dri?
svenstaro: xorg?
MostAwesomeDude: Mesa.
MostAwesomeDude: You also need KMS support in libdrm and xf86-video-ati.
svenstaro: It is there but they are not git-version.
svenstaro: That okay?
svenstaro: How about ati-dri?
svenstaro: Also, do I *need* xorg 1.8?
airlied: 1.7 o r 1.8
svenstaro: So I really only need to build mesa from git with --enable-gallium? thats it?
svenstaro: even hough ati-dri also has a --enable-gallium option, no changes there?
airlied: --enable-gallium-radeon
svenstaro: MostAwesomeDude: Do I need to screw with ati-dri?
ripps: Why is there no XV Overlay with KMS radeon? XV Textured is nowhere near as fast or smooth it seems.
airlied: ripps: because nobody wrote it, and it doesn't work composited
airlied: try turning off bicubic maybe with xvattr
ripps: airlied: Actually, I get better performance using gl than with xv these days.
ripps: I use gl:yuv=4:scaled-osd:rectangle=1:swapinterval=0:ati-hack. I came up with that after an exaustive amount of testing.
ripps: it's still not quite as smooth as XV overlay was in dri1 though
svenstaro: I'm compiling mesa now and it is all your guys fault if my X doesnt start up again.
Daekdroom: It WILL start
mjr: come to think of it, I'll try the r300g from https://launchpad.net/~xorg-edgers/+archive/radeon on for size on my x800xl
Daekdroom: Wether it'll have direct rendering or not? :P
svenstaro: so do I need ati-dri or not?
svenstaro: with gallium that is
MostAwesomeDude: I have no idea what's in ati-dri.
airlied: not an upstream package,
svenstaro: http://aur.archlinux.org/packages/ati-dri-git/ati-dri-git/PKGBUILD
svenstaro: basically mesa
MostAwesomeDude: Is there a reason for it to be separate from Mesa?
svenstaro: I don't know
MostAwesomeDude: Well, I don't know Arch.
ripps: Actually, speed isn't my biggest gripe with Textured XV, it's the clipping I get. And yes, XV_VSYNC 0 doesn't help
ripps: s/clipping/tearing
svenstaro: recompiling my graphics stack is scary :(
svenstaro: and mesa is a big mofo
svenstaro: can't we be awesome like nouveau and remove all classic stuff so that my shallow clone becomes smaller? :D
MostAwesomeDude: Git clones are never shallow.
Daekdroom: SVN and Git give me heebiejeebies
MostAwesomeDude: Additionally, I'm not sure what you're talking about. Nouveau has classic drivers. nv10, nv20.
svenstaro: Wasn't UMS removed from their drivers?
svenstaro: also I think --depth 1 does at least a bit to save MBs
MostAwesomeDude: For the DDX, sure. However, they could only do that because they never really released anything that they had to maintain backwards compatibility for.
svenstaro: mh fine.
svenstaro: For compiling mesa, do I need --enable-gallium-radeon only along with my driver options?
mjr: nice, gallium plays violetland fine when classic did not ;)
MostAwesomeDude: Yes.
svenstaro: ALAS! It takes long.
svenstaro: Do I also want to recompile glut and glu?
MostAwesomeDude: No.
svenstaro: Goodie.
toresbe: Ooooh, activity. Just asking: 576i out from the DVI port of a Radeon 7200 (iirc) isn't impossible, right?
svenstaro: What happens if I run a gallium enabled driver in UMS?
Daekdroom: It doesn't
Daekdroom: Gallium depends on KMS
svenstaro: So a kitten will die in my laptop?
svenstaro: Is KMS currently any better/worse in terms or power management?
MostAwesomeDude: No, Gallium will simply say that it doesn't like your kernel module version, and quit.
svenstaro: 90° is a fine temperature for compiling packages I guess
leio: hugely depends on the CPU and its thermal specification...
svenstaro: Well, I mean my radeon of course, the GPU. I was hinting that my CPU got really busy compiling mesa just now.
Droste: and if it's F or C
svenstaro: 91°C as of right now.
leio: eh, ok
svenstaro: So what can I expect in terms of GPU power management?
Droste: since compiling packages doesn't use your gpu 91°C is pretty much
leio: see above on what it hugely depends on :P
leio: per some chatter I have observed, you can expect some power management when DPMS kicks in, and better power management in 2.6.35 kernel
svenstaro: I mean GPU power management, I already power manage the CPU quite well
leio: but not sure about that radeon GPU family that was for :)
leio: s/that/what/
Droste: there is pm in 2.6.34 for all gpus with more than one power state
svenstaro: Rebooting now, it better be working afterwads :P
svenstaro: Well whaddayaknow, X is running
svenstaro: shitty resolution but it is running
svenstaro: damnit, doesnt recognize my screen resolution at all
svenstaro: Woah, everything just became badly corrupted.
svenstaro: Compositor won't start either :(
Daekdroom: glxinfo | grep OpenGL
Daekdroom: We need to do some diagnosys!
svenstaro: glxinfo : command not found. Oh oh.
Daekdroom: ....
svenstaro: Which repo is it in?
Daekdroom: Uhh. Which distro?
svenstaro: Arch, I mean which upstream repo.
svenstaro: I'm getting LSD graphics
Daekdroom: I don't use Arch..
svenstaro: Which upstream repo is glxinfo in?
Droste: mesa/demos
svenstaro: The demos were moved right?
Jonimus: svenstaro: yeah
Jonimus: I have a pkgbuild that will install the needed ones if you want it?
svenstaro: It's in aur, isnt it?
svenstaro: mesa-demos-git?
Jonimus: oh nvm
svenstaro: Sadly I can't read vim right now
Jonimus: I guess I'm not the only one who made one :P
svenstaro: I installed it :/ but not glxinfo
Droste: glxgears?
Jonimus: hmm, well my pkgbuild installs that.
svenstaro: sadly my vts aren't working.
Jonimus: you need toe xdemos, I'd assume the pkgbuild doesn't install them since they'd conflict with the official mesa package.
svenstaro: Uh?
svenstaro: What exactly do I need now?
svenstaro: http://aur.archlinux.org/packages/mesa-demos-git/mesa-demos-git/PKGBUILD wont do?
Jonimus: that pkgbuild for w/e reason is not isntalling all of the xdemos for w/e reason
svenstaro: Hurry as long as I can still read my screen :P
svenstaro: what do I want to add to it?
Jonimus: add a cd src/xdemos after the ./autogen.sh
svenstaro: btw, gears runs fine
Droste: glxgears -info
Droste: prints the renderer
Jonimus: hmm then IDK why glxinfo isn't there
svenstaro: softawre rasterizer :((
Daekdroom: Aw naw D:
Droste: pastebin dmesg | grep -E "drm|radeon"
svenstaro: http://paste.pocoo.org/show/225085/
svenstaro: It loaded r300 in classic btw :P
Droste: do you have vga=XXX in your kernel command line?
svenstaro: no
Droste: pastebin Xorg.log
svenstaro: Hang on, needing reboot. Getting the fanciest of colors.
svenstaro: This would probably be an awesome driver on drugs.
svenstaro: http://paste.pocoo.org/show/225087/
svenstaro: module ati does not exist
svenstaro: not good
Droste: yes, that's the problem
svenstaro: What did I break
Daekdroom: Everything!
svenstaro: oh shit :(
Daekdroom: grinlies
Daekdroom: Or however you spell that
svenstaro: How do I fix!
MostAwesomeDude: Install xf86-video-ati. Or even xf86-video-fbdev.
Daekdroom: MostAwesomeDude, that is a handcompiled gallium mesa
svenstaro: drm loads r500 but my system only has r300 and r600 in xorg modules, that the problem?
MostAwesomeDude: Daekdroom: I was talking about the Xorg log.
Daekdroom: R500 is part of r300
MostAwesomeDude: Okay, let's try this again.
MostAwesomeDude: The xorg drivers are *not* the DRI drivers.
svenstaro: Do I need fancy option for xf86-video-ati?
Daekdroom: So they're completely independent?
MostAwesomeDude: You *must* have xf86-video-ati installed. You have neither that nor xf86-video-fbdev, so instead vesa took over, and is fighting with the kernel, causing horrible graphics corruption.
MostAwesomeDude: Independent enough. They come from different trees./
svenstaro: --enable-dri?
MostAwesomeDude: No fancy options. At the end of configure, it will say whether it will build KMS support, based on whether you built libdrm with it.
Droste: no nothing "fancy"
svenstaro: KMS: yes, yay!
svenstaro: Let's try this again. Sounds like the whole base stack under x is happy though.
svenstaro: Resolution is alright now :D
svenstaro: No LSD colors for now as well
svenstaro: Compositing
svenstaro: gears runs
svenstaro: mipmap generation is NOT slow as fuck and I get UMS-like FPS
svenstaro: you people are all awesome
Daekdroom: So yeah, we dragged you from classic mesa + Dri1 + UMS to Gallium + DRI2 + KMS so you could have the same performance
Daekdroom: How awesome xD
svenstaro: KMS + non-gallium was a horrible peace of crap :(
svenstaro: So now where does it say gallium?
Droste: + a LSD trip
Daekdroom: glxinfo | grep OpenGl ,which doesn't work for you?
Daekdroom: Or glxgears -info
svenstaro: gears doesnt say gallium anyway, and I don't have info for some reason
svenstaro: Jonimus: mind sharing your pkgbuild?
Droste: you had it 20min ago... what happend?
svenstaro: I didn't, just gears :(
Droste: yeah glxgears -info prints the renderer and driver
svenstaro: No gallium there
Daekdroom: so it doesn't say Gallium 0.4 on (insert your videochard chip here) anywhere?
svenstaro: grep -i gal doesnt
Droste: what's the output of "ls /usr/lib/dri/radeong_dri.so"?
svenstaro: There we go, I have glxinfo now
svenstaro: I have no /usr/lib/dri to begin with
Droste: lib/dri?
Droste: /lib/dri
svenstaro: neiher
svenstaro: I wonder how this all works right now
svenstaro: I have /usr/lib/xorg/modules/dri/radeong_dri.so
svenstaro: as well as regular radeon_dri in there
Droste: ok run: cd /usr/lib/xorg/modules/dri && mkdir gallium && cd gallium && ln -s ../radeong_dri.so r300_dri.so
Droste: then run: LIBGL_DRIVERS_DIR=/usr/lib/xorg/modules/dri/gallium glxinfo
svenstaro: This looks better
svenstaro: glxgears even runs
svenstaro: How do I make it standard in a non-ugly manner?
Droste: glxgears needs the same prefix: LIBGL_DRIVERS_DIR=/usr/lib/xorg/modules/dri/gallium glxgears
svenstaro: yeah, I figured t hat much
Droste: replace r300_dri.so in /usr/lib/xorg/modules/dri
Droste: but: it's in development
Droste: I would just use it for the programs that actually run faster with it
svenstaro: bring on some nexuiz, YEAAAHH
svenstaro: This isnt even half bad
svenstaro: All my shit runs actually pretty well. I didnt expect that at all.
svenstaro: Gallium as faster for all the crap I tried so far :D
Droste: are you using kwin?
svenstaro: Yes but obviously compositing is off so it doesnt matter.
Droste: last time I checked I had problems with kwin compositing
svenstaro: Compositing worked awesome until I went for some gaming and I turned it off.
Droste: ok, replace r300_dri.so with radeong_dri.so in /usr/lib/xorg/modules/dri
Droste: (make a backup of the original. just in case)
svenstaro: Cubemapping isnt fuckslow now :D
svenstaro: no MRT support though :(
svenstaro: no geometry shaders either
svenstaro: Instancing works but corrups geometry
svenstaro: cg shaders work
svenstaro: GLSL FFPLib_Texturing_VS seems not to be implemented
MostAwesomeDude: I don't know what "FFPLib_Texturing_VS" is.
MostAwesomeDude: Sounds custom.
MostAwesomeDude: MRTs are supported.
MostAwesomeDude: Instancing isn't quite implemented.
svenstaro: Well yeah but it doesnt render anything for me
MostAwesomeDude: Geometry shaders *don't exist* on that hardware.
svenstaro: Oh alright
svenstaro: One thing I noticed is that "movement" appears jerky while FPS are steady.
svenstaro: This isnt happening withou gallium.
svenstaro: It's like time randomly skips during rendering while FPS are okay.
Droste: vsync
Droste: oh no wait you're using 2.6.33?
svenstaro: It's disabled in my application. Is it enforced?
svenstaro: Yes.
svenstaro: Texture based shadows work without gallium, with it they appear in random places.
svenstaro: Stencil shadows work okay.
svenstaro: whats the issue with kernel 2.6.33ß
Droste: I'm not sure but as far as i remember vsnyc is only supported for kernel >=2.6.34
svenstaro: This isnt vsync trouble as far as I can tell. Vsync off with quick movement looks like the screen is splitting. This isnt that.
svenstaro: It's like random little time jerks.
Droste: compositing off?
svenstaro: Anyhow, I conclude my testing. Awesome work with gallium and KMS and such.
svenstaro: Thank you MostAwesomeDude and all you other random internet hackers.
morfic: looks like the HD4200 in the AMD785G chipset is well supported by radeon driver, correct? and there is nothing that prevents the 128MB sideport memory to work in "sideport ram only" mode in linux? (haven't really kept up with gfx cards at all lately, so i'd like to make sure i didn't just read all the wrong reviews and comments while googling)
ripps: Awesome, it seems the -radeon driver in the Xorg-edgers ppa no longer has XV tearing