Radeon IRC Logs For 2008-12-30

EruditeHermit: airlied: what timezone are you in?
airlied: EruditeHermit: brisbane
EruditeHermit: ah
EruditeHermit: aussie
airlied: nope, but living here.
EruditeHermit: I thought rh was in boston
EruditeHermit: didn’t know they had a brisbane office
airlied: we have offices all over the world.
EruditeHermit: i didn’t think you had that many employees
EruditeHermit: from what you intimated before
airlied: 2,000 or so I think
airlied: the X team is 7-8 ppl, with soon to be 3 in brissbane
EruditeHermit: well, useful to know
EruditeHermit: i mistakenly told someone you were probably in US east
EruditeHermit: as a guess
EruditeHermit: pretty far off
EruditeHermit: assumed you’d be in boston
EruditeHermit: which I think is the headquarters?
airlied: HQ is North Carolina, most of engineering is in Westford (outside Boston)
EruditeHermit: well, good to know
EruditeHermit: btw, what I tried to ssh into my machine when it locked up, but it wouldn’t connect
EruditeHermit: but I figured out that the problem is probably somewhere in the render accel code
EruditeHermit: or atleast it stopped crashing with render accel disabled
EruditeHermit: any further tips to debug?
maddash: has anything ever came of the r300 3d register guide that amd released 9 months ago (http://www.phoronix.com/scan.php?page=article&item=amd_r300_guide&num=1)?
MrCooper: sure, all the unknowns in the Mesa r300 driver have been eliminated
maddash: but why does the open-source radeon driver run so much slower than fglrx?
EruditeHermit: its not feature complete
maddash: what does ‘feature complete’ mean?
EruditeHermit: it didn’t have a memory manager until recently
EruditeHermit: that paves the way for more development
EruditeHermit: hopefully the next year will bring improvements
maddash: so the slowness is a problem on the side of radeon developers, not AMD/ATI
maddash: ?
EruditeHermit: for example, the hardware is capable of openGL 2.0 compliance, but the driver is only openGL 1.3 compliant
MrCooper: mostly lack of time / manpower
EruditeHermit: there are not enough people who know how to work on it and those that do are overwhelmed
MrCooper: EruditeHermit: a Gallium based driver would take care of that, among other things 🙂
EruditeHermit: yes
EruditeHermit: that is what I am waiting for
EruditeHermit: =)
bobbens: we all are 🙂
EruditeHermit: maddash: now that there is a memory manager, openGL 2.0 compliance is easier
EruditeHermit: atleast that was what my non technical understanding is
bobbens: I’m really looking forward to GLSL to play with that
maddash: EruditeHermit: ‘now’ meaning 2.6.28?
EruditeHermit: no
EruditeHermit: in the coming months
maddash: EruditeHermit: kernel version, I meant
EruditeHermit: to a year
EruditeHermit: the memory manager has not been merged yet
EruditeHermit: it is still under development
maddash: you mean, GEM?
EruditeHermit: but nearing completion
EruditeHermit: yes
bobbens: GEM was merged into 2.6.28 no?
EruditeHermit: yes
EruditeHermit: oh yes
maddash: it only works with intel drivers
EruditeHermit: yeah
bobbens: yes, that I know 🙂
bobbens: and the latter intel chipsets, not affecting my poor i815
EruditeHermit: the radeon GEMified TTM hasn’t been completed yet as far as I know
EruditeHermit: or not been merged
EruditeHermit: but I could be wrong
EruditeHermit: MrCooper knows better
bobbens: overall it’s moving pretty well
bobbens: and driver is pretty stable
maddash: here’s what I don’t understand: on the one hand, amd has opened up the r300 architecture, so you’d expect at least some sort of improvement on the OSS radeon driver side (there doesn’t seem to be any since the release date). on the other hand, why doesn’t ati just merge the r300 aspects of the fglrx driver with OSS radeon, so that the progress of r300 on linux as a whole can move faster?
MrCooper: yeah, it’s still on branches
bobbens: only issue i ever get is hardlocks in kernelspace when valgrinding opengl apps 🙂
arekm: tried modesetting on radeon and got just oops and black screen
bobbens: which i still have to debug someday
EruditeHermit: maddash: the code for fglrx is encumbered with NDA from other parties
MrCooper: maddash: again, there have been lots of improvements, though most of them may have been under the hood
EruditeHermit: maddash: they couldn’t just release fglrx code
EruditeHermit: maddash: there are only 5ish developers working on radeon. Most of them are part time
bobbens: I certainly have felt those improvements
maddash: this is frustrating to no end, because even AFTER the release date, I still have to sacrifice performance for functionality: standby still hiccups with fglrx just like before, and the radeon driver is a turtle versus fglrx.
bobbens: if you stick to opengl 1.3 and earlier, radeon is fine
EruditeHermit: maddash: radeon does a better job with suspend/resume, video playback, 2D
bobbens: and i’m getting pretty good performance, but I have an x550
bobbens: pretty much the only difference between radeon and fglrx for me is stability and extensions
EruditeHermit: maddash: the main slowdown is 3D, everything else is fast
bobbens: radeon is more stable, fglrx has more extensions
maddash: EruditeHermit: video playback/2d? do you have some numbers?
EruditeHermit: maddash: nope, but I have 2 r300 cards and my experience is that video playback is slower with fglrx
EruditeHermit: as is 2D window drawing
EruditeHermit: basic window drawing etc
maddash: as in Xv?
EruditeHermit: you could try gtkperf
EruditeHermit: to test that
EruditeHermit: for yourself
buggs: maddash, as in fglrx still crashes machines
buggs: with video
EruditeHermit: maddash: one big slowdown with radeon is if you need OpenGL > 1.3, it hits software fallbacks
maddash: buggs: on my machine? never. it’s just the damn gcc4.3 incompatibility and the s2ram hiccups that are a problem
EruditeHermit: maddash: by christmas next year, things should be better
EruditeHermit: maddash: the same people that do r300 have to ensure r600/700 is working which is what their focus is now
EruditeHermit: maddash: to make them reach parity with r300 in terms of features, and then improve upon that
EruditeHermit: r300-r500 is somewhat similar feature wise
maddash: EruditeHermit: ‘gtkperf’ — that tests 2d performance?
maddash: EruditeHermit: what about glxgears?
EruditeHermit: maddash: glxgears is a pseudo 3D test
EruditeHermit: it isn’t a good test for 3D performance
maddash: why not?
EruditeHermit: gtkperf tests how fast GTK widgets are drawn
EruditeHermit: so yes, a 2D test
maddash: so, what is a (full)-3d test?
EruditeHermit: maddash: try the phoronix test suite
EruditeHermit: maddash: they have all kinds of tests for you
EruditeHermit: http://www.phoronix-test-suite.com/
EruditeHermit: you can find out for yourself
EruditeHermit: with numbers
EruditeHermit: what is faster than what
maddash: good.
EruditeHermit: glxgears isn’t good because it doesn’t test all 3D functions
EruditeHermit: its not a realistic enough test
EruditeHermit: a better test would be the average fps in a game of your choice
EruditeHermit: and doing that test with a few games that may stress real world scenarios
EruditeHermit: but even those tests would be dependent on your other hardware too
maddash: EruditeHermit: i don’t play games. I work on blender3d. and it’s way slower on radeon compared to fglrx.
maddash: http://www.mojang.com/notch/j4k/l4kd/ looks pretty 2d. it’s way faster on fglrx. why?
EruditeHermit: what is it
EruditeHermit: java?
EruditeHermit: maddash: blender3D is slow on radeon because it doesn’t fully implement hardware accelerated openGL 2.0 or 2.1 which blender uses
EruditeHermit: maddash: so you are hitting software fallbacks that use the CPU
EruditeHermit: when a gallium 3D driver comes about, that will be alleviated
maddash: sorry, got distracted by left 4k dead
maddash: EruditeHermit: java. yes. the whole game is 4K . and it’s in 2d.
damentz: gn8
EruditeHermit: no idea
peterz: agd5f: congrats on getting the r600/r700 stuff out
maddash: so, the results from the gtkperf tests on my system are in. http://pastebin.com/m21ba207 . I’m impressed.
quicksilver: nice.
quicksilver: big speedup on text and pixmaps vs fglrx
quicksilver: I wonder why that is.
maddash: notice the –count=1000
EruditeHermit: maddash: now you have numbers for what I feel is true anecdotally
EruditeHermit: I think phoronix test suite has some Xv tests
EruditeHermit: so you can test video if you like
EruditeHermit: i’m off
maddash: no, the xv performance gap was something i noticed a long time ago
EruditeHermit: gnight
maddash: gnite.
kkuno: wow
kkuno: quicksilver, what card do you have?
quicksilver: it was maddash’s figures, not mine.
quicksilver: he has some kind of X300 mobility, it says
maddash: ati x300 mobility on a thinkpad t43
kkuno: ah
kkuno: with my x1600 + catalyst I get: http://rafb.net/p/PBcngp30.html
kkuno: :O
maddash: kkuno: i ran these test right after after a cold boot.
maddash: kkuno: perhaps you’re running some other application that’s competing with gtkperf for processing time
kkuno: uhm
kkuno: I will try with an empty de
maddash: kkuno: also, in xorg.conf, I’ve got composite disabled (not sure if that means anything), and I’m running a relatively light de: icewm+rox-filer
kkuno: ok
MadMerlin: my radeon 7500 is still way faster on 2d than my x1400
MadMerlin: both fglrx and radeon
mlankhorst: I think that’s what exa is for 🙂
benh: 2d is sooooo has been 🙂
maleadt: Does compiz affects gtkperf results?
mlankhorst: just try running gtkperf with and without compiz and you find out..
maleadt: aight, just asked it first as “metacity –replace” – “compiz –replace” sometimes messes up my session
maleadt: Oh my, huge difference. Even completely idling, with a minimal set of Compiz plugins enabled (wobbly, cube, expo) gtkperf needs 100 seconds more, totalling at 236 (gtkperf –count=1000 –automatic).
mlankhorst: Did you really have to ask that question then? 😉
maleadt: apart from general laziness, not 🙂
maleadt: brb, rebooting X to get compiz working again
Kano: hi, is mesa 7.0.3 to use 3d with r600?
Kano: err r500
mikkoc: afaik you need 7.1 at least
Kano: is that compatible with xserver 1.4.2
agd5f: you need mesa 7.2 for r5xx 3D
Kano: ok, compiling that now, but will have got only xserver 1.4.2
hifi: what distribution are you on
Kano: target is debian lenny
agd5f: direct rendering will work, indirect requires a newer xserver
Kano: not good
Kano: any small patch to xserver 1.4.2 possible?
hifi: Kano: pull xorg from experimental
Kano: hifi: i dont want to update xorg
Kano: only some drivers + mesa
hifi: why?
Kano: i want to be able to support is as addon to lenny
hifi: it’d be much easier to just use experimental xorg and mesa
Kano: then i have to complile all drivers
hifi: uhh, why?
Kano: or not?
hifi: just pull the whole xorg and mesa stuff from experimental and be happy with your R5xx 🙂
rnoland: agd5f: those patches look ok?
Kano: hifi: i do not own it
hifi: umm, r6xx
Kano: until somebody send me one, which did not happen so far
Kano: only rv410 here
agd5f: rnoland: yeah, I had to fix the _unused, but looks good otherwise
hifi: did I miss something or why you need r500 acceleration without r500?
rnoland: agd5f: ah, what was wrong with it?
Kano: but it try to find the minimum required addons
agd5f: doesn’t seem to work everywhere
Kano: hifi: i have got my own distro
rnoland: agd5f: ah, i initially just removed the variable, but figured it would be needed soon… so…
hifi: alright
agd5f: yeah, I just commented it out
Kano: agd5f: when will we see r600+ in radeon driver?
rnoland: airlied: baby time?
MostAwesomeDude: Hey, does anybody have “merge r600 EXA and Xv into radeon” on their plate?
MostAwesomeDude: If not, I can get it in a few days…
spstarr_work: that’s our MAD 🙂
MostAwesomeDude: spstarr_work: Not gonna let RHD get ahead of radeon :3
spstarr_work: nope 😉
mlankhorst: lol
mlankhorst: Doesn’tsound too har
mlankhorst: hard*
MostAwesomeDude: It never *sounds* hard.
mlankhorst: I’d do it 😛
mlankhorst: But then I’d have to do the future efforts too
mlankhorst: not sure if I would have time for that 🙂
mlankhorst: I’d love to though
zhasha_netbook: MAD|dentistry, external harddisk get!
chlue: Hello, I ordered a R730 based video card. I know there is nearly no support for that card with the radeon driver, but i wonder if the card will at least clock down? According to http://wiki.x.org/wiki/RadeonFeature powersaving is marked as unknown.
zhasha_netbook: chlue, as you can see in the title, there’s no 3d acceleration on it
zhasha_netbook: but I should think modesetting works
chlue: the questin is: will it se 10 watt and stay quiet or burn 60W and kill my ears…
zhasha_netbook: but you’re in luck, yesterday ATI released the r6xx/r7xx documents so the good people in here are working on it 🙂
zhasha_netbook: and that would depend on how the card acts. I’d think it’ll stay low if not in use but I don’t know
chlue: zhasha_netbook: Ok I will see. thanks.
zhasha_netbook: your CPU fan might kill your ears though if you try doing well.. anything 😛
zhasha_netbook: for the time being you can always use fglrx
mjr: Soo, on an X800XL/R430, using Ubuntu 8.10 with stock radeon driver (yes the free one, package version 1:6.9.0+git20081003.f9826a56-0ubuntu2 if that says much), eventually during the course of an X session the good ol’ overlay Xvideo resource seems to get stuck and unusable (that is, programs won’t be able to use it). Programs will apparently then automatically use the textured video Xv ports. Which would be fine except for tearing (which I saw is getting …
mjr: … some attention on the mailing list, so let’s skip that), and the rather more annoying fact that it won’t display anything going over ~2900 pixels on the desktop x axis (I got a 3840×1200 desktop here, with the video wanting to be on the right-hand side…). Which probably has to do with the limitations on the rendering area that the chip’s 3d engine can support, but couldn’t the offset for that move around with the textured video at least if there’s …
mjr: … nothing else going on? Also, has the Xv overlay getting borked once in a while been noted and maybe even fixed nowadays, ’cause I’d be quite happy with that… It does work again for a number of video player starts after an X server restart, but that’s not really very nice.
MostAwesomeDude: mjr: Not sure why Xv would be wonky.
MostAwesomeDude: Yeah, there’s texture limits. Some work is going on in compiz to make it work, but for now, gotta stay within the 2048×2048 limit.
mjr: not using compiz
mjr: mostly because of its own limitations in handling >texture size wide desktops properly, good if they’re working on that…
MostAwesomeDude: I should have rephrased.
MostAwesomeDude: 2048×2048 is the limit.
MostAwesomeDude: Not sure why it’s not properly drawing past that limit, since it *should* work.
MostAwesomeDude: compiz is working to eliminate that limit on their end, but in the drivers, there’s not much we can do without a *massive* overhaul.
mjr: (I thought it was 2560×2560 for this generation of cards, and anyway, as said, the weird thing is the textured video drops out at somewhere around 2918, which is kind of a weird place for it to do so
mjr: oh wait yeah, 2048×2048 was the max texture size, the rendering buffer was 2560×2560
MostAwesomeDude: Hm.
mjr: or something like that
mjr: anyway… for now I’d just be happy with the damn old overlay working reliably
MostAwesomeDude: No compositor -> should work.
mjr: well as said, it does until it doesn’t
mjr: I had this problem before on earlier versions of the driver even, but it went away for a while. At that time I reported it to ubuntu who may or may have pushed it upwards… anyway, it got fixed for a while methinks. Now it’s back, the only difference being that nowadays there’s the textured video ports to fall back to.
mjr: …which fail to work
mjr: (in this case in the described manner)
MostAwesomeDude: Ubuntu is often made of upstream fail. Is there an fd.o bug?
mjr: don’t find one easily. The old Ubuntu bug (which is closed at this point cause the problem was away for a while) is here, btw; https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/108894
mjr: Should I file on fd.o?
mjr: basically I just want to make sure that the bug’s on the radar, if not fixed. Some may not even notice it, if textured video works for their situations…
MostAwesomeDude: fd.o is better than Ubuntu. AFAIK none of us are Ubuntu devs.
mjr: ah, I see the old bug was even more severe, composite Xvideo would be locked down after one use. This time around I can often start video players a couple of times before it dies!
agd5f: mjr: sounds like some app isn’t giving up the port or something
agd5f: rather than a driver bug
mjr: it would sound like that, if there was any video app running
mjr: I’ve checked, they’re dead
airlied: flash
mjr: don’t have it
airlied: mjr: swfdec?
mjr: no gnash either
agd5f: mjr: what do you mean by “programs aren’t able to use it”?
agd5f: it doesn’t work or the port is in use?
mjr: they can’t get at the port
mjr: [VO_XV] Could not grab port 57.
mjr: that’s from mplayer, for instance
mjr: but there really shouldn’t be anything keeping it
agd5f: mjr: sounds like something desktop side rather than driver side
mjr: hmm, bugger me, I killed just about everything on the desktop and sure enough, _something_ had seen it proper to reserve it for its own nefarious purposes
mjr: ’cause now it’s free. Sorry about that, mates, then. Suggestions on how to track the bugger down, though?
mjr: Hmh, totem plugin. It wasn’t actively used to my knowledge, but it might probably well be the culprit…
agd5f: sounds likely
mjr: well, dumped that for now
mjr: see if it goes away
mjr: yeah sorry for the bother, I should’ve thought of that
arrenlex: I have an X300SE using the r300 driver. I am using the git trunk. When I rotate my screen, everything becomes really slow.
arrenlex: Switching windows takes several seconds while the desktop repaints. Dragging windows makes snakes which take a second each to disappear. Is this a known problem? Can I make it fast?
mjr: just that I didn’t to my knowledge _use_ the plugin for anything actually, but maybe some pages got it initialized and boom it takes away the port…
agd5f: arrenlex: switch to EXA
agd5f: Option “AccelMethod” “EXA”
arrenlex: agd5f: em@sam:~$ cat /var/log/Xorg.0.log | grep -i EXA
arrenlex: (**) RADEON(0): Option “AccelMethod” “EXA”
arrenlex: (**) RADEON(0): Using EXA acceleration architecture
agd5f: arrenlex: how big is your desktop?
arrenlex: agd5f: 2960×1050
agd5f: that’s the problem
arrenlex: agd5f: But I only want to rotate one of those monitors.
agd5f: right, but right now we treat the entire desktop as one big surface
arrenlex: agd5f: So in rotated state, my desktop would be (1680+1024)xmax(1050+1280) = 2704×1280 ? And that’s too big to accelerate?
agd5f: arrenlex: max texture size is 2048×2048
arrenlex: agd5f: How come my current desktop, which is also wider than that, is accelerated?
arrenlex: agd5f: I mean, I don’t know if I have full 3d acceleration everywhere across it, but I can certainly drag windows everywhere across it without leaving snakes, and there is no visible slowness.
agd5f: arrenlex: 2D engine limits are 8192×8192
agd5f: you need to the 3D engine to rotate
arrenlex: agd5f: Really? That seems strange… why do you need 3D to rotate?
agd5f: arrenlex: how else you you do it?
agd5f: point a texture at the desktop, rotate the coordintes draw to a new buffer
agd5f: 2d engine doesn’t support rotated blits
arrenlex: agd5f: I’m not a graphics programmer, I don’t know what everything does, but it seems to me you can just apply a simple rotation to everything going to the screen.
MostAwesomeDude: arrenlex: Rotation takes forever.
MostAwesomeDude: Well, when not accelerated.
zhasha_netbook: arrenlex, it’s a heavy operation
agd5f: arrenlex: that simple rotation is what takes so long when the surface sizes are beyond the 3d engine’s limits
MostAwesomeDude: The 3D engine does blits with the texture engine, so a rotation is just a free shuffle of the verts.
arrenlex: Ah, I see.
arrenlex: That’s cool, I had no idea how this stuff worked. Anyway, I am in fact trying to rotate the monitor which is fully 3d accelerated. Testing by dragging glxgears around, I have an unaccelerated stripe down the right edge of my screens, which is on the edge of the monitor that is not touched.
arrenlex: Am I still misunderstanding how it works then?
zhasha_netbook: are you using the radeon driver or the fglrx driver/
zhasha_netbook: ?*
arrenlex: zhasha_netbook: radeon driver — r300. fglrx doesn’t support any rotation at all afaik.
zhasha_netbook: it supports XRandR 1.2 so yeah it does 😛
agd5f: arrenlex: I’m not following. 2704 > 2560 which is the max render target size so you only get 3D on part of the screen
arrenlex: agd5f: That is correct. I am testing by dragging glxgears around and the part that does not get 3D is on the right edge.
arrenlex: agd5f: But I am trying to rotate the monitor on the left, which has 3D acceleration everywhere. It is 1280×1024.
agd5f: arrenlex: sounds like maybe a issue with damage tracking in the xserver
arrenlex: agd5f: I have no idea what that means or if it’s something I can fix on my end, sorry… can you explain a bit more?
mjr: hmh, do you need the compositor to actually do the rotation or does the driver do it itself?
agd5f: arrenlex: rotation works by creating a shadow buffer in offscreen memory and pointing the display at that shadow buffer. appls then render to the “real” framebuffer and changes “damage” gets tracked so only parts of the image that cahnged get updated on the shadow copy
agd5f: arrenlex: you might try an updated driver snapshot or xserver. I’ve not heard of this bug before, but I don’t use rotation much myself
arrenlex: agd5f: I have the most current driver; I’m compiling it from git. I’m cautious of installing the X server though, since I haven’t done it and it probably has a lot of dependencies. I’m willing to try though.
arrenlex: agd5f: I also notice this line in my Xorg log — (II) RADEON(0): EXA: Disabling Composite operation (RENDER acceleration)
arrenlex: agd5f: Is it important?
agd5f: arrenlex: yes. rotation uses render to accelerate the rotation
arrenlex: agd5f: Would that be the problem, then? Is there a configuration option I can use for that?
arrenlex: agd5f: The context is: (**) RADEON(0): Option “MigrationHeuristic” “greedy”
arrenlex: (**) RADEON(0): Option “EXANoComposite” “false”
arrenlex: (II) RADEON(0): EXA: Disabling Composite operation (RENDER acceleration)
adamk: Errr..
agd5f: arrenlex: turn off greedy, IIRC, it’s broken
agd5f: also, you’ll want to turn on composite
arrenlex: agd5f: Doesn’t “EXANoComposite” “false” turn on composite?
agd5f: it’s on by default
agd5f: just remove the option
agd5f: it might be getting parsed wrong since the “No” is parsed as off
arrenlex: agd5f: Okay, I removed those two options from the conf file. Should I restart X and try again or is there something else I should do?
agd5f: arrenlex: yeah, just restart X
arrenlex: k, brb then. Thank you very much for all your help. 🙂
arrenlex: agd5f: I’m back. Even worse now — still slow as ever, but the bottom of the display is corrupted too now.
agd5f: arrenlex: not sure what’s up with that. is the rotated screen corrupt or the non-rotated or both?
arrenlex: agd5f: The bottom of the rotated screen is corrupt. If you want I took a photograph.
arrenlex: agd5f: It’s corrupted where the kde panel sits, regardless of whether the orientation is left or right.
arrenlex: agd5f: Interestingly, when I turned off the large monitor and just had the small one, it rotated perfectly, and was accelerated.
arrenlex: agd5f: By turned off I mean xrandr –output DVI-0 –off
arrenlex: agd5f: http://arrenlex.aa.am/dsc00832.jpg — sorry if the download is a little slow. Tell me if I should put it on imageshack or something instead.
arrenlex: agd5f: If I rotate it the other way, the corruption is on the inner edge rather than the outer, again where the panel is.
agd5f: arrenlex: what xserver version are you running?
arrenlex: agd5f: X -version says X.Org X Server 1.4.2
arekm: hm, what’s the case with ati vs radeonhd now, after r{6,7}xx acceleration support released? ati will be for older, radeonhd for newer cards?
chithead: radeonhd is for newer cards and ati for newer and older cards
arekm: so now r{4,7}xx accel support will be merged to ati??
airlied: arekm: most likely.
airlied: arekm: its just development code so far.
agd5f: arrenlex: not sure what’s up with that. I’ll take a look next time I get a chance
arekm: airlied: uhm, I was always wondering why the duplication isn’t killed by merging things/efforts
airlied: arekm: keep wondering, there is no good answer
arrenlex: agd5f: Should I file a bug somewhere?
agd5f: arrenlex: bugs.freedesktop.org
spstarr: hullo
arrenlex: agd5f: What’s the product? I can’t find radeon or ati in the list…
airlied: xorg, Drivers/radeon I assume
arrenlex: The version numbers are different. What does 1.4.2 map to in this bugzilla’s scheme?
soreau: arrenlex: Have you tried XAA rendering method since you’re using X 1.4.x or upgrading to X 1.5.x since EXA should be much faster on it?
arrenlex: soreau: I am told XAA doesn’t support rotation at all.
soreau: Then upgrade your X 😉
arrenlex: soreau: But then apt-get wouldn’t be able to do it for me. 🙁
arrenlex: soreau: 1.5.x isn’t even in debian unstable yet, only experimental. I would have to find it and compile it myself.
soreau: As a test, I would try at smaller resolutions, so the total does not exceed the max tex limit for your card in either direction
arrenlex: soreau: I did. Put both monitors 800×600. Rotation was still unaccelerated.
soreau: Well if all that is true, I would try with X 1.5.x
arrenlex: soreau: Ah, ubuntu intrepid ships with 1.5.2. I will boot from a liveCD and give it a try. 🙂
soreau: Indeed, debian is under manned and often ‘behind the times’
arrenlex: soreau: Not really, they are just frozen in preparation for release.
arrenlex: soreau: Any major rotation changes in git since 2008-10-03? That’s what’s in the intrepid repos right now.
soreau: They’re at a partial freeze, because of lack of man power
soreau: In any event, that’s irrelevant to this particular problem
arrenlex: alright, will try in ubuntu… brb then
agd5f: soreau: xaa doesn’t accelerate transforms
soreau: agd5f: He mentioned that, now I know 😉
soreau: But, I think Intrepid uses XAA by default even though it uses X1.5 (so you have to create an xorg.conf and specify exa)
arrenlex: Hey, all. I was compiling the latest git version on a livecd and I wanted to mention that the build failed when it couldn’t find GL/gl.h. configure should probably check for this — I had to install libgl1-mesa-dev to fix it.
arrenlex: agd5f, soreau: Reporting from ibex livecd. With the git driver, rotation IS accelerated, but only up to a point.
arrenlex: When my rotated monitor is 1280×1024 and my other one is 800×600 it isn’t. When I bump my other monitor down to 640×480, it is.
agd5f: arrenlex: right. 2080 (1280 + 800) > 2048
arrenlex: agd5f: Not when it’s rotated… when it’s rotated you are using the short edge of the monitor as the width, so it should be 1024 + 800, no?
arrenlex: agd5f: Also, why does it just stop being accelerated everywhere? Why doesn’t it just keep a stripe on the right like usual, except a bigger stripe?
agd5f: arrenlex: the source image is 1280 + 800. that source image is rotated
arrenlex: agd5f: Ah, alright. So, a) why not keep a stripe on the right? b) is there a technical reason for the 2048 limit? Is there a config option for it like there is for virtual desktop size? c) should I file a bug about it or does it work as expected? d) can I ever get the rotation I would like?
agd5f: arrenlex: 2048 is the hw limit for texture coordinates
agd5f: on your chip.
agd5f: r5xx supportys 4096
arrenlex: Ah. Wonderful.
agd5f: arrenlex: eventually we can work around it by using separate buffers for each head
agd5f: but right now we are limited by the way the current dri, etc. work
agd5f: then each head could be accelerated up to 2048×2048
arrenlex: agd5f: Ah, alright. So that answers b and d. Should I still file a bug describing this buffer for each head proposal? And, why can’t it keep a stripe on the right which is not 3d accelerated, like before, anymore?
arrenlex: agd5f: The right monitor is still 2d accelerated even when the other one is rotated and slow, so it’s not like the whole desktop falls back to software rendering… it just cancels all acceleration on the rotated head. Why does it do that?
agd5f: arrenlex: because when you rotate, each head using using a separate buffer
agd5f: the non-rotated head is still scanning out of the non-rotated buffer, while the rotated head is scanning out of the shadow buffer
arrenlex: agd5f: Now I’m confused. (10:15:20 PM) agd5f: arrenlex: eventually we can work around it by using separate buffers for each head // (10:19:39 PM) agd5f: arrenlex: because when you rotate, each head using using a separate buffer
arrenlex: agd5f: If they are using separate buffers when I rotate, why is there a problem? Wasn’t that your suggestion for how it can be fixed?
arrenlex: agd5f: Or do you mean there are two duplicate buffers which each contain the whole desktop, and each head takes what it needs out of their portion of the respective complete buffer?
agd5f: arrenlex: you have a large buffer that spans the entire non-rotated desktop
agd5f: arrenlex: exactly!
arrenlex: agd5f: Ah, okay.
agd5f: when you rotate the entire non-rotated buffer gets copied and rotated to a new buffer
agd5f: the display and and drawing parts of the engine are not coupled
agd5f: so you can scan out of one part of memory and draw to another
agd5f: so all operations happen on the non-rotated buffer and then the rotated one is subsequently updated when there is a change
rnoland: i find the tfp size limitation very annoying…
_ds_: A few slight problems noticed with textured video (compared to overlay)…
_ds_: Test program: gxine.
rnoland: if i stack my displays vertically, 2048×2048 is adequate, if they are horizontal it isn’t…
arrenlex: agd5f: That makes sense, thanks. I think I understand now. So it’s impossible to get the rotation I want with the current framework, eh? Should I still file a bug about this or is it not something that is likely to be fixed?
arrenlex: agd5f: Also, thank you very much for all the help and explanations. You are extremely knowledgeable and patient. 🙂
agd5f: arrenlex: no need to file a bug, we do plan to fix this eventually
_ds_: Using full-screen, zooming in (vo_zoom.v=133, for example) does not quite work as expected: the horizontal offset is ignored, and some odd clipping will occur if the video is interlaced.
arrenlex: agd5f: Is there a timeframe I can look forward to? Months? Years?
agd5f: ajax’ shatter xserver stuff and drm memory management should pave the way
agd5f: arrenlex: next year hopefully
arrenlex: agd5f: Alright. Well, I have to go, but thanks again. 🙂
_ds_: (Otherwise, nice to see nice fast textured video on rv370!)
agd5f: arrenlex: no problem 🙂
_ds_: Hmm, curious. The clipping of the left edge of an interlaced image appears to correspond exactly to how much of it should be off the left edge of the display area.
_ds_: … BTW, xf86-video-ati 6.9.0.91.
ajax: speaking of which.
ajax: i really do need to make that work sometime in like the next three weeks, don’t i.
mjg59: ajax: Yup
bridgman: ajax; if you don’t do it soon everyone will upgrade to newer GPUs with bigger texture limits, then you wno’t have to bother
bridgman: oh wait, that’s bad motivation 😉
bridgman: so +1 for what mjg59 said
ajax: bridgman: it’s never a game you can win
ajax: eventually someone will try to daisy chain four 30″ displays horizontally on displayport and then you’re boned again
ajax: don’t think anyone can do 16k wide textures yet.
rx__: how many 30″ displays are you at?
ajax: and even if they can, your crtc certainly can’t.
ajax: rx__: only two on my desk, sadly.
rx__: you’re half way there
bridgman: yeah, true; I have to stop looking at my lonely ol’ 17″ CRT when talking about the need for multimon support 😉
soreau: I think if 2048×2048 could be the limit for each screen, it would satisfy most users in these respects and be a one up on the other driver 🙂
spstarr: hmm
spstarr: that worked
rnoland_: airlied: was that a new 6.9.0.91?
spstarr: looks at code changes
soreau: looks at spstarr
spstarr: eh?
spstarr: im just a lone KDE developer, but i was looking at cgit.freedesktop.org/xorg/drivers/xf86-video-ati 😉
zhasha_netbook: hey guys, can someone point me in the right direction of enabling kms on an r5xx?
zhasha_netbook: i’m on fedora rawhide
felipec: zhasha_netbook: it’s enabled by default isn’t it?
zhasha_netbook: not here it isnt
zhasha_netbook: well, at the very least i am not seeing it
zhasha_netbook: i think ill just reinstall this thing seeing as how it didnt seem to go so well the first time around
felipec: zhasha_netbook: you have the fedora kernel and radeon driver?
zhasha_netbook: yes
zhasha_netbook: but i had to mess with /boot/grub/menu.lst because the first time around, fedora didnt install grub
zhasha_netbook: so it might be my fault
felipec: zhasha_netbook: unless you have nomodeinit in there I think it should work
felipec: er, nomodeset
zhasha_netbook: i dont have that on, but after i updated fc10 to rawhide, it really got screwed
zhasha_netbook: im just going to reinstall it now, see if i can clear up this mess i made
maddash: hi, is there any documentation on R300’s “GARTSize” xorg.conf option? I can’t find it in radeon(4)
randomdude: Can’t find anything on that specific to the radeon driver, maddash… What do you need to know?
maddash: randomdude: well, blender3d crashes when GARTSize is left untouched in xorg.conf, so I set it to “256”. After reboot, blender works fine, but my system refuses to hibernate any more because it runs out of memory
randomdude: Blender3d crash due to running out of texture memory, you think?
maddash: wasn’t using any textures, just playing with IPO animation curves
randomdude: Just peeking at the driver source – Can’t see any code which would indicate a default gart size,. Unless the kernel part does that.
randomdude: TBH, I can’t really suggest anything smart beyond just experimenting with smaller settings (but still set something)
maddash: randomdude: hm, can you show me where to find the driver source? is it included in the kernel sources?
randomdude: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.9.0.91.tar.bz2 is what I’m looking at.. The bit to interpret the GARTsize option is in the radeon_driver.c file, line 2225 onward
maddash: randomdude: thanks. I just had an idea: my video card has 64 MB of ram, so perhaps setting GARTSize to 256 was too ambitious, and changing it back to 64 will patch things up. brb, rebooting.
MostAwesomeDude: Who’s gonna tell him that GARTSize isn’t the size of the aperture, but only the size of the tables?
randomdude: MostAwesomeDude: I vote you do that.
arrenlex: has also had things magically fixed by setting GARTSize and will not speak ill of this magical and all-powerful option.
maddash: haha, filled up my memory with openoffice instances, now attempting to hibernate
maddash: yes, it works!
maddash: am I even disconnected?
randomdude: Nope
maddash: cool, I just hibernated and rebooted
maddash: “back in a flash” — literally
maddash: blender3d is slow as heck now 🙁
randomdude: Can anyone suggest why I might not be getting RENDER acceleration despite the driver apparently registering the capability (xorg.log shows exa composite support enabled)?
arrenlex: randomdude: Can you pastebin the whole /var/log/Xorg.0.log file ?
randomdude: http://pastebin.com/m866bbc5
randomdude: Sometime before, on Xserver 1.4 and xf86-video-ati6.9.0 I would get about 150FPS on the cairogears TRAP test with the xrender backend. I’m on 1.5.3 now, with the same driver, and getting 5fps at the same test.
randomdude: That and general perception leads me to think cairo’s xrender pathway isn’t being accelerated as it should be?
EH: airlied: do you remember you asked me to ssh into a hanging Xorg session and run sudo strace -o xorg.out -p `pidof Xorg`
EH: what was I supposed to look for once I did that
EH: I have Process 5025 attached – interrupt to quit
EH: but no other messages
EH: to refresh your memory, our conversation was on http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2008-12-17&channel=radeon&show_html=true&highlight_names=EruditeHermit&date=2008-12-18
moeSizlak: soooo, kms was added to mainline kernel?
randomdude: moeSizlak: Believe it’s slated for 2.6.29.
moeSizlak: i see it in 2.6.28-git2
moeSizlak: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f453ba0460742ad027ae0c4c7d61e62817b3e7ef

Radeon IRC Logs For 2008-12-30

Rig Lab Hardware

You Might Also Like

RadeonHD.org | Radeon IRC Logs For 2008-11-03

RadeonHD.org | Radeon IRC Logs For 2008-6-06

RadeonHD.org | Radeon IRC Logs For 2008-11-24