moeSizlak: so: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
MostAwesomeDude: moeSizlak: Do you already have a kernel cloned?
moeSizlak: would this be an acceptable next step: git checkout -b drm-rawhide origin/drm-rawhide
moeSizlak: no
MostAwesomeDude: Yeah, then that should work.
airlied: moeSizlak: pretty much that
moeSizlak: and that would get me all of the newest patchres?
airlied: should do.
moeSizlak: cus i see theres been quite a few
airlied: it just got rebased
moeSizlak: so what version of the kernel is that based on?
airlied: haven't really added any features
airlied: its based on my drm-next which is around 2.6.29-rc6
MostAwesomeDude: glisse: Any plans to fix the single-buffer DRI2 setup? Should I just get it myself?
MostAwesomeDude: airlied: Not sure what you changed, but current combination of X, Plymouth, and kernel boots without mess.
airlied: MostAwesomeDude: its called fixin shit :)
EruditeHermit: MostAwesomeDude: how is the gallium stuff going?
vehemens: airlied: what was the reason for the r600 gart memset_io (i.e. why did you need to clear it)?
airlied: its VRAM
airlied: we need to make sure its empty
vehemens: what happens if it's not empty?
airlied: chances that the GPU corrupts RAM.
airlied: if the garbage makes sense as a page table entry
vehemens: got it. you clear the whole table as you may only use part of it.
airlied: yup we also only use part of it at the moment
airlied: with TTM we can use moer
vehemens: has the newttm code been merged into gem (lost track of the different branches)?
airlied: nope notyet
vehemens: i take it dri2 doesn't care at this point?
vehemens: i.e. it's more of a performance improvement
airlied: its all above the GEM API which I don't intend on changing
airlied: newttm probably won't even chane perf
airlied: its more of a need to do for upsteram
ma3x: hello
ma3x: im using debian lenny
ma3x: i want to enable support for xv in xorg
ma3x: i currently use the ati driver but it doesnt provide xv support
ma3x: what driver should i install/use
ma3x: i was told to ask about r6xx support
ma3x: can you explain how it goes
osiris_: ma3x: you need current git ati driver and r6xx-r7xx-support branch of drm
ma3x: and how do i get that? what sorces should i add to /etc/apt/sources.list
airlied: there aren't any debian packages for it yet
ma3x: so i can't use it on debian?
osiris_: ma3x: you have to build it by yourself
da1l6: have a look at the wiki page: http://wiki.x.org/wiki/radeonhd:r6xx_r7xx_branch
ma3x: and how do i check which xx i have
da1l6: you mean the exact card? lspci should help here. but it should not matter as long as its r6xx or r7xx based.
ma3x: well it's hd3400 series
da1l6: then Xv is suported by that branch.
da1l6: (except possible bugs)
glisse: MostAwesomeDude: there are change ongoing in the dri2 area about flushing
glisse: we need those for a proper fixing of single buffering
vehemens: today's ati merge seems to of dropped the RV710 9592 id that was in the r6xx-r7xx-support branch
da1l6: oops, missed it was merged to master. cool
da1l6: ma3x: just use git master for your card.
da1l6: I assume the r6xx brach of drm is still needed?
ma3x: da1l6: im following the wiki, what's git master?
da1l6: the branch you start in. (before you do the git checkout command)
da1l6: the wiki is about radeonhd BTW, if you want to use the radeon driver replace "radeonhd" with "ati"
da1l6: both drivers should work on your card, though
davem1: Does mesa run-time generate asm code to emit the CP vertices in the non-gallium tree?
ma3x: i get this warning, cannot find a kernel config file. stop
da1l6: ma3x: kernel headers installed?
ma3x: i get linux-kbuild-2.6.28 has no installation candiddate
da1l6: the package you need should be named linux-headers
ma3x: yes but it depends on kbuild
glisse: davem1: their are some optimized path for x86
glisse: and ppc iirc
glisse: but it's for software fallback
davem1: there used to be a whole bunch of stuff in the radeon driver
davem1: but Keith removed it
davem1: "remove vtxfmt code, switch over to vbo"
glisse: yup code was messy and i think the perf boost was way to small
davem1: that's the change that removes all of the foo_vtxtmp_x86.S code
davem1: from radeon
glisse: oh this when mesa moved to vbo scheme :)
glisse: which is lot cleaner
da1l6: ma3x: maybe its a distro specific issue or misconfigured package sources
glisse: and simpler for driver
davem1: well filling in the vertixes is now top of my ioquake3 profile with RV100 :-)
glisse: really forget about the previous code
davem1: insert_4ub_4f_abgr_4() is the hottest function
davem1: it eclipses everything else
glisse: it's about converting to proper format
ma3x: da1l6: well i use 2.6.28 got it from kernel-archive.buildserver.net
davem1: right and in pre-vbo it was done in optimized assembler wasn't it?
glisse: maybe adding abgr to driver will help
glisse: davem1: hhhmm it was lot more complex and it wasn't always accelerated through asm, in fact very few path were iirc
davem1: ok
davem1: I remember learning a long time ago that Nvidia's internal driver would do run-time code generation for filling in the rendering descriptors
davem1: so once you setup a vertex-array or similar all of this pre-generated code would be ready to do all the submission to the chip
glisse: do you got the profile handy ?
davem1: http://vger.kernel.org/~davem/x.log
davem1: that "zero (deleted)" is the ioquake3 JIT
glisse: which mesa version is it ?
davem1: current GIT
davem1: with those sparc ASM patches I just posted
davem1: it's looked like that for the past week or so :-)
glisse: strange can't grep radeon_render_triangles_elts
davem1: macros TNL
davem1: makes diagnosing mesa issues so much fun
davem1: It's all of that tnl_dd/t_dd_dmatmp*.h tom-foolery
davem1: #define THIS, #define THAT, #include tnl_dd/t_dd_dmatmp.h
davem1: it's all magic
davem1: radeon/radeon_swctl.c:#define TAG(x) radeon_##x
davem1: look for that if you haven't figured it out yet
glisse: davem1: that what's strange
davem1: why?
glisse: which card are you on ?
davem1: RV100
davem1: no T&L
glisse: oh
davem1: jesus
glisse: well then you are vertex limited
glisse: :)
davem1: that's why I need all the CPU I can get :-)
davem1: The norms/cliptest/xform stuff was showing up before I got the sparc asm working again
davem1: so that helped a bit
glisse: well you would need to accel vert transformation but you don't want to do such things in mesa stacks
glisse: well i am just biased and only think in gallium perspective where we will have one day JIT for this kind of stuff
davem1: right
glisse: out of curiosity what is the fps you got ?
davem1: glxgears is ~435
glisse: in ioquake i was asking :)
davem1: one sec...
davem1: is it \com_showfps 1
davem1: it doesn't like that
glisse: don't know i pretty much never run games
davem1: I'll google it, one sec
taiu: maybe cg_drawfps
davem1: yep that's it
davem1: I get mid-50s with a lot of settings turned way down
davem1: it I walk right up to a wall it ~85 :-)
pmitros: How mature is the ATI driver these days, as compared to the Intel free software drivers? My prof is looking to buy a new laptop, and we're trying to choose graphics card. Does the free software driver have stablity issues or issues with suspend?
chithead_: pmitros: lenovo has notebooks with switchable graphics where you can use what works better
pmitros: Really? Wow. Which ones? I didn't see that in their specs.
pmitros: googles
mjr: Intel seems to be somewhat ahead in features and stability, which is no wonder, since they're more actively directly involved for ages. Slower, of course...
pmitros: So what would the limitations of the ATI be? I'm not too concerned about features (TV-out, dual-head, or stuff like that). I just want it to do 2d reliably, and not interfere with things like suspend/hibernate, and preferably, to be supported in Ubuntu/Intrepid or even Ubuntu/Jaunty
mharris: pmitros: The radeon driver has experienced a degredation in both stability and performance on my systems in the last couple years. I'm using an AGP Radeon 9600 Pro.
pmitros: Okay. In that case, I need Intel.
pmitros: Thanks.
adamk_: Odd... My experience is the exact opposite.
MrCooper: mharris: do you mean the Mesa r300 driver?
mharris: I believe it is simply due to the more modern hardware getting the development resources, and the AGP hardware now being considered legacy now.
mharris: MrCooper: naw, just 2D
MrCooper: XAA or EXA?
chithead_: I think this is due to ubuntu
mharris: EXA in particular
chithead_: I have been using an x700 (rv410) on gentoo for two years and it has gotten better with each release of xf86-video-ati and the x server
mharris: XV also seems to be useless
MrCooper: some XAA core stuff had to be disabled by default because it's too broken for modern desktop environments
mharris: I can't watch full screen video at all, it is a slideshow
MrCooper: mharris: that is really unexpected
chithead_: mharris: worksforme
mharris: I switched back to an older release
MrCooper: something must be wrong there, maybe your video player falls back to X11 for some reason
adamk_: Yeah, I have no issues with an AGP 9800 under FreeBSD with the 6.10.0 driver and fullscreen video.
mharris: chithead_: works for you on an AGP Radeon 9600 Pro?
mharris: In particular the bad experience was on Fedora 10
MrCooper: mharris: Mobility 9700 here, and things have been improving steadily
mharris: Now using CentOS 5.2 and the 9600Pro works like a charm again.
chithead_: mharris: I had a radeon 9600xt in my old box but it died last year. I could watch dvb-t fine in fullscreen though
mharris: xorg-x11-server-Xorg-1.1.1
MrCooper: mharris: so, do you have any evidence that this is an upstream issue?
chithead_: mharris: 1.1.1? this is very old
mharris: MrCooper: nope, could be Fedora issue, never tried to narrow it down
mharris: chithead_: yup, old and functional. :)
chithead_: mharris: but dog slow when it comes to exa and stuff. only since x server 1.5 exa works well for me
mharris: Had numerous probs with F10 so I ditched it entirely. Might try newer upstream bits in roll-my-owns down the line tho
chithead_: mharris: I think your performance issues are in part or entirely due to mixing current and obsolete xorg stuff
mharris: chithead_: yeah, super slow with EXA.. XAA was working better for me, but still a lot of slowness on the desktop. I could visibly watch the desktop paint from top to bottom on a minimize-all
chithead_: mharris: use x server 1.5 for exa
mharris: I wasn't mixing anything, just using stock OS stuff
chithead_: [13:08:50]
mharris: chithead_: yeah, I switched from Fedora 10 to CentOS 5.2
mharris: CentOS 5.2 has older X server and drivers than F10 does.
chithead_: ah ok, I misunderstood that
mharris: ;)
MrCooper: actually, use xserver 1.6 for EXA :)
MrCooper: glyph cache goodness
mharris: I find firefox to be super slow under any distro release with any X server and driver. I've recompiled firefox without pango support and a few other things and gotten some marginal performance improvements.
mharris: (not using that currently though)
mharris: firefox running on Windows XP running on the same box runs super smooth/fast tho, which is disappointing as it'd be nice to have the same perf on the same hardware with a better OS. :)
mharris: That's partly due to firefox optimization on 'doze likely
MrCooper: Firefox traditionally wasn't exactly famous for its efficient use of X
mharris: Wonder if that glyph cache goodness would help me :)
mharris: yeah, it stalls for long times, sometimes just a few seconds, sometimes half a minute or more
MrCooper: it should speed up non-core font rendering by 5-10x
mharris: Usually get a "buy better hardware" solution when discussing it publically... lame. ;o)
mharris: MrCooper: oooh, that sounds nice
mharris: xorg-x11-drv-ati-6.6.3 is what I've got currently
MrCooper: that didn't even support RENDER acceleration yet on R300
mharris: seems stable so far tho
mharris: I had 2 other probs with the F10 driver too.. Transiently during system startup, or when resuming from DPMS, the entire screen would flicker random pixels all over like a bad modeline was being used, and/or the screen would randomly blank every 1-4 seconds or so, then come back in a few seconds.
mharris: Tried numerous things including EXA/XAA, disable DRI, disabling AGP and attempting PCI DRI, various other bits.
mharris: When I get another secondary box set up I can throw F10 on, I'll probably try to debug some of those issues more.
mharris: Just needed a stable system desperately tho, so had to ditch F10.
agd5f: mharris: F10 enabled kernel modesetting and memory management, which isn't quited fully baked yet
mharris: agd5f: on R300?
agd5f: mharris: IIRC yes r3xx-r5xx
mharris: ah, I thought it was r5xx+
agd5f: airlied: would know better
mharris: It worked probably 95% of the time or so. Only once in a while did it come up wonky, or resume from DPMS wonky. No visible trigger.
MrCooper: mharris: let me guess, DVI at 1920x1200 (or some other mode approaching 165 Mhz pixel clock)?
mharris: MrCooper: bingo!
mharris: Good guess. :)
mharris: Dell 2405FPW
MrCooper: driving a DVI link near the maximum clock seems about as reliable as driving an AGP card :}
MrCooper: try a reduced blanking mode or lowering the refresh rate
mharris: I've been using 1920x1200 over DVI on the 2405 for about 5 years now... only had a problem with F10. ;)
mharris: I'm on CentOS 5 now tho, and haven't seen the problem as of yet... hopefully wont :)
MrCooper: mharris: https://bugs.freedesktop.org/show_bug.cgi?id=2859 is the infamous bug report, reported almost four years ago... it's the kind of problem which can disappear and reappear more or less randomly
davem1: I'm using a Dell 2405fpw on my DVI head too
davem1: Sony 24" LCD on the VGA output and Dell 2405fpw on the DVI output of an R300
davem1: both running at 1920x1200, works great for me
agd5f: those 1920x1200 DVI panels seem real picky about the dot clock
agd5f: I picked one up hoping to reproduce some of the problems that have been reported, but, of course, it runs perfectly on every card I own :/
rhodan: hi, how long until DRI2?
mharris: davem1: which OS release?
mharris: agd5f: that's weird because I've used DVI on my Dell 2405's since I got them, but only had the problem described in that bug report occur since January only on Fedora 10. ;o/
mharris: I'll have to compare the modelines and X server logs from Fedora 1, F10, and CentOS to see if there is anything different going on.
fpoibaf: What about "radeon planar textured video" patch: http://lists.freedesktop.org/archives/xorg/2009-February/043932.html ?
fpoibaf: Someone tried it (not supportd on my RV530)?
fat_chris: hi guys, im having some trouble with getting kms to work with the latest drm-rawhide kernels
fat_chris: it doesnt output any signal whatsoever to the screen, but it seems to boot up fine
fat_chris: my /var/log/messages for the relevant boot is at http://pastebin.com/d2f899806
adamk_: After so many questions here and on the mailing lists about the every missing r600_dri.so file, I'm not sure I'd be as patient as you, agd5f :-)
agd5f: :)
spstarr_work: new DDX
spstarr_work: but this doesnt turn on DRI2 support does it?
spstarr_work: 6.11.0
MostAwesomeDude: Hm. There's a radeon-gem-cs3? Should I be using that?
DanaG: hmm, I read here that EXA X-Video has been merged to master... yet, I just downloaded and installed the git version, and it didn't give me any xv adapters.
DanaG: http://www.phoronix.com/scan.php?page=news_item&px=NzA5NQ
agd5f: DanaG: if you are using an r6xx/r7xx card you'll need an updated drm
DanaG: I did this git clone: git clone git://anongit.freedesktop.org/git/mesa/drm
DanaG: the /dev/dri dir is empty.
chithead: I think it has only been merged to radeon and radeonhd master, not to drm master
DanaG: Ah.
DanaG: That would do it.
DanaG: Hmm, compiled and installed r600_r700_support branch of drm, but still nothing in /dev/dri after unloading and reloading radeon (and drm).
da1l6: did you install the drm and radeon kernel modules and removed the old ones?
DanaG: Hmm, I'll have to check.
DanaG: ah, I see.. the kernel module is still the old version.
DanaG: ah, have to manually run Make in linux-core.
DanaG: Oh yeah, will Radeon likely have KMS for R600 in 2.6.30? I sure hope so.
DanaG: Cool, thanks!
DanaG: [drm] Used old pci detect: framebuffer loaded
MostAwesomeDude: Hm. Good question. I kind of doubt it.
MostAwesomeDude: I think that KMS for Radeon is planned tenatively for 2.6.31...
DanaG: Bummer.
MostAwesomeDude: ...but I'm not the maintainer or Linus.
DanaG: Something odd on my laptop: if I use 1600x1200 vesafb (on 1920x1200 LCD), I get vertical bands that seem to repeat a bit of each other. Happens even in Windows, if using Generic VGA.
DanaG: So, I'm hoping to be able to get native-res framebuffer through KMS some day, without that glitch.
MostAwesomeDude: Hm.
MostAwesomeDude: Could just be the LCD changing the res.
MostAwesomeDude: Internal monitor issues..
MostAwesomeDude: Does 1920x1200 not work?
DanaG: 1920x1200 is not in the VESA modes.
fat_chris: i cant get any non 4:3 resolutions with vesafb without kms either, and kms no longer works for me
DanaG: I usually use framebuffer at 1024x768, because even 1280x960 uvesafb mode makes text too small.
DanaG: 147 DPI display + Xorg == win. 147 DPI display + Console == lose.
DanaG: I also wish Radeon would get power management support.
chithead: DanaG: have you verified with hwinfo --vbe? sometimes notebook manufacturers are considerate enough to add the laptop panel's native resolution to vesa modes
MostAwesomeDude: DanaG: Typically the native modes are added to the BIOS later, unless it's intel HW.
DanaG: http://pastebin.com/f168580e9
MostAwesomeDude: So you could -- oh, yeah, chithead got it.
MostAwesomeDude: Also what kind of power management are you thinking of?
DanaG: Not sucking 30 watts on battery, that's what. =þ
DanaG: Idle on battery in Windows: about 17-20 watts. Idle on battery on Linux with fglrx (when it worked): 16 or so. Idle on battery with radeon: 30 watts.
MostAwesomeDude: Well, there's the dynamicclocks setting... But really, we need some more infrastructure before we can enable the power management.
DanaG: I'm on Ubuntu Jaunty, with an on-the-side 2.6.29 kernel.
DanaG: I just wish it would be possible to, say, tell the GPU to go to low speed mode and then leave it there. I'd be willing to accept slowness if I could say, "for this boot, always be low-power".
MostAwesomeDude: DanaG: Ah, well if you want that, we have that.
MostAwesomeDude: We have powerplay, but it's not in mainline because people will gripe no matter what we set it to.
DanaG: Ah.
DanaG: Does the branch still include the drm support?
MostAwesomeDude: The correct solution would be to adjust the GPU speed based on load, but we don't have the infrastructure for that.
MostAwesomeDude: Hm, not for your card, no.
DanaG: ah. Perhaps I'll check back in a while, then. A few weeks, or so, perhaps.
DanaG: Thanks!
DanaG: hits ctrl-alt-backspace...
DanaG: Hmm, what video formats is it supposed to accelerate?
DanaG: Right now, wmv and h.264, for example, seem to still be CPU-bound.
DanaG: That's with mplayer xv output.
fat_chris: i didnt think there was any decode acceleration?
agd5f: DanaG: there's no decode, only rendering
DanaG: Ah, just the final drawing to screen, then.
agd5f: yuv->rgb and scaling
DanaG: has to depart now.
DanaG: Thanks for the help.
airlied: fat_chris: can you boot with drm.debug=1 on the command line
airlied: and get the dmesg not /var/log/messages
airlied: fat_chris: aolso no vesafb
airlied: or vgafb please
airlied: turn that shit off
MostAwesomeDude: XFD
fat_chris: not compiled in at all?
airlied: yup off. don't compile it
fat_chris: i take it i need fb_radeon_debug too yes?
airlied: don't enable radeonfb either
airlied: but that shouldnt matter
fat_chris: well i just booted up with those options and kms worked! but then rebooted to make sure it wasnt a fluke, and it was
fat_chris: http://pastebin.com/m48caa194
fat_chris: thats dmesg
tahorg: hi, I've a X700 mobility and I'm using xserver 1.6, trying to enable the video output
tahorg: xrandr does not even list the S-Video as deconnected
airlied: tahorg: it lists the s-video at all?
tahorg: nope
agd5f: tahorg: not supported yet
airlied: I'm not sure x700 x-video works.
chithead: tahorg: http://wiki.x.org/wiki/RadeonFeature no r400 tv-out support
tahorg: well, the rest worked so well since the update
tahorg: I had to try this last missing feature
tahorg: compiz runs _so_ smooth on this 4 years old laptop, thanks to the developers
legume: 1a7db3fc2a0277d724d60d028064d8ef75019c28 means that my -retro xorg background doesn't get drawn. Bisect was fun once you hit a working you don't get a bad without a power cycle :-)
spstarr: no stipple for you
legume: spstarr: I guess most people want rid of it anyway
spstarr: heh
legume: spstarr: How will they tweak their monitor moir without it though.
spstarr: nobody's dropping the stipple
legume: spstarr: it's not default anymore with xserver without -retro
spstarr: thats ok
DanaG: hmm, how would I go about getting the radeon version that supports the more-than-just-dynamicclocks powerplay support?
DanaG: er, "supports ... support" -- redundant. =þ
DanaG: got dc'd some time in the past.
DanaG: Anyone know how to get the GPU power management (static PowerPlay state) support in radeon?
DanaG: I'd be willing to go back to unaccelerated video, if need be -- as long as the driver will at least compile and run.
bridgman: DanaG; in principle it shouldn't take a lot of code, the atombios calls are already there for setting engine and memory clock
bridgman: taking memory clock down is non-trivial because you need to consider display bandwidth, driver activity etc, but taking engine clock down is less complicated
DanaG: Hmm, is that (static power management, not yet dynamic power management) on the roadmap for the near future?
bridgman: once we get basic 3D running then power management will be next on the list
DanaG: Ah. For myself, those priorities are the other way around -- I'd rather save power while waiting for 3D support. =þ
bridgman: the bigger issue is that power management really needs to be in the kernel and wired into all the different parts of GPU activity, and nobody is doing that yet
bridgman: you can do static in the ddx but dynamic really needs to be in the kernel
bridgman: re: priorities, we'll kinda split the difference; enough 3D to run things like Compiz, then power management, then the rest of 3D
DanaG: Are either of those planned for the reasonably near (as in, before end of calendar year) future?
DanaG: cool.
DanaG: Compiz is about the only 3D thing I use in Linux... though now with VirtualBox, that may begin to change.
bridgman: static should be real soon; dynamic, harder to say
bridgman: yeah, the problem is that everyone needs "just a bit of 3D, but 3D isn't important as long as my bit works"
DanaG: Static is good enough for me.
bridgman: emmes was doing some testing with clock changes, let me see if I can find his slides
DanaG: I just don't like having the thing sitting there sucking 30 watts on battery -- compared to 16-19 when on fglrx, when it was with old X server.
DanaG: Oddly enough, I can't use fglrx newer than 8.543, even on Ubuntu Intrepid (now I'm on Jaunty).
bridgman: yep, it gets toasty
yangman: it's surprising how many laptop vendors don't have the BIOS enable automatic power management for the GPU
DanaG: Mine has boot mode set to highest power mode.
bridgman: that is odd; what happens if you enable the version of fglrx that shipped with Intrepid ?
DanaG: I've opened it in "RaBit" (Radeon Bios Editor).
DanaG: https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/314600
DanaG: AMT serial console == win.
bridgman: I don't really know why we boot in high power mode; maybe there's a reason but if I were king I would boot in slow & stingy mode
DanaG: Or middle-of-the-road mode.
yangman: my thinkpad has always booted with dynamic clock gating by default, and downlocking made almost no difference
bridgman: nah, nobody likes middle of the road ;)
DanaG: Another oddity: even Windows, if using VESA driver, gets display screwed up when running 1600x1200 VESA mode on the 1920x1200 display.
DanaG: Also affects usplash. Doesn't affect real GPU drivers.
bridgman: Windows has a VESA driver ? I thought it just had VGA...
DanaG: Vista and Win7 can do higher VESA modes.
DanaG: They just call it "Standard VGA"