macr0s_: hi all
macr0s_: I've just updated radeonhd on my freebsd laptop, and now it is soooo slooooow
macr0s_: anyone with ideas :)?
dmb: are you using dri?
macr0s_: well, I commented that in xorg.conf but I'm not sure
dmb: make sure your using exa acceleration
macr0s_: Load "exa" :)?
macr0s_: sorry, I'm a little confused with all this stuff
dmb: macr0s_, take a look at the x log and see what accelmethod its using
macr0s_: ok found smth on wiki
dmb: i'v never used it on freebsd so i don't know the bsd particulars
macr0s_: laptop@/home/macros> grep -i accel /var/log/Xorg.0.log
macr0s_: (**) RADEONHD(0): Option "AccelMethod" "EXA"
macr0s_: (**) RADEONHD(0): Selected EXA 2D acceleration.
macr0s_: (WW) RADEONHD(0): Option "RenderAccel" is not used
dmb: looks fine :/
dmb: don't know
macr0s_: looks like the single solution is to downgrade :/
dmb: maybe file a bug?
dmb: could be a freebsd only problem, don't know
macr0s_: I don't think this is a bug, looks like I have to do smth
macr0s_: but, let;s try
macr0s_: let's downgrade, eh
macr0s_: fscking annoying nickservb
GNU\colossus: omg it's macros the black
GNU\colossus: why not just cast some uber-cool magic and in turn utterly destroy nickserv?
macr0s_: I can't collect manna cos my X is slow argh :)
macr0s_: the strange thing is that with radeonhd, as well as with radeon driver, situation is the same
macr0s_: felling like I'm working on an old p3 800 with 256 mb ram, and not dual core system :)
macr0s_: hehe, problem solved
macr0s_: the accell method should be shadowfb, not exa
macr0s_: dmb, you were wrong :)
TuomasT: Huh?: " RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. Using only 262144kB of the total 524288kB."
m-c: Hi - sorry to put down idle chatter - but this will be a watershed event for me. AMD is coming out with a brand new video card model, and I will be anxiously watching to see how the drivers are handled. (All-in-Wonder HD) http://www.legitreviews.com/news/4940/
Death_Syn: that could be fun
marcheu: non-standard features of recent all in wonder cards are not supported under linux
marcheu: that is, no tuner for you
m-c: All well and good (and appreciated) to provide linux drivers for existing gpu models, but if this is a serious long-term effort, then internal processes will have changed to provide drivers at launch.
m-c: marcheu: Hmm - glad for your insight. I am not aware how the tuners work with other all in wonder cards in linux. I am sure there is some work-around?
marcheu: m-c: simple: they don't work
marcheu: the older ones used to work though
m-c: Well, regardless of how it goes, you still have my lasting appreciation for the work AMD is doing now with these radeonHD drivers. You won over the most die-hard nvidia user you'd ever meet.
libv: m-c: we tried to provide for a driver at launch with the rv620/635 as we had the hardware already then
libv: m-c: we don't have hardware nor information for rv770.
m-c: Probably says something about the limits of my loyalty, though, hmm...
marcheu: m-c: you should buy the same card without all-in-wonder, the rest is a money waste
marcheu: m-c: they can't even playback video ATM, things are miles away from tuner
m-c: Just tossing it out there - not that I even have a tv or cable to connect to it - but couldn't the tuner API be released with open specifications, without revealing too much competitive information?
marcheu: they'll probably say it's "external IP blah blah blah"
m-c: okay - well - people buying into the encrypted cable signals for their computer probably do not care too much about free software solutions for the tuner, anyway. ;)
m-c: although - I have been interested lately about the digital HD signals that are transmitted unencrypted by local television stations (typically 10-50 based on size of market)
m-c: only because I like watching PBS ;) okay, I'll stop the OT chatter. :)
marcheu: well they don't even support the tuner with the binary drivers...
marcheu: so I guess this is kind of a windows-only card
agd5f: we don't own the IP on tuners and decoders, but most tuner datasheets are available from the vendor
yangman: m-c: you mean Over-the-air HD? you can buy a dedicated NTCS/ATSC tuner card. iirc, there are ones out there with linux support
m-c: yes, over the air - thanks for the tip!
rmh3093: whats the new regarding r600 3d
roadboy: hi all. can i use radeonhd with my r530 gpu (x1600 pro) ?
adamk: roadboy, Both radeonhd and radeon support 2D and 3D acceleration on that card with the latest drivers from git.
adamk: roadboy, At the moment, though, I believe that enabling DRI on radeonhd disables 2D acceleration, so the 'radeon' driver may be a better choice.
roadboy: hmm. it will be good to give a chance to both these drivers imho
rmh3093: roadboy, if u have a gnome enable the composite_manager
adamk: roadboy, Well they share the DRM and Mesa drivers. The only difference between the two is the 2D DDX. That makes it very easy to switch, but it also means that 3D performance is likely to be the exact same with both drivers.
rmh3093: and the 2d issue goes away
dmb: so that 2d quick and dirty branch, is that the command proc head?
libv: dmb: it's a copy of radeon code dumped on the radeonhd driver, and quickly ported to make it work
dmb: libv, and thats so 3d dri and 2d get along?
libv: dmb: more about adding exa and texturedvideo
adamk: So on that branch, does DRI still disable 2D acceleration?
libv: adamk: no, 2d is enabled as the radeon codepaths are currently used for all acceleration
libv: and these radeon codepaths sit on top of macros which in some way try to use the drm cp
dmb: sounds a little hackish :/
marcheu: dmb: how else would you do it ?
dmb: don't know :D
dmb: whatever works :P
marcheu: well submitting all accel commands to the DRM (including 2D) is the only way to properly share the card so ...
dmb: marcheu, sorry, i don't know much of anything about my topic, ignore what i said above
adamk: libv, Not to be difficult, but what's the purpose in having two DDX drivers that support r500 hardware if one of them simply duplicates the code of the other?
hdh0: I hear 8.6 comes with a new .so, could it be support for All-in-Wonder?
libv: adamk: don't ask me. radeonhd was there first.
adamk: Hmm... Well that's true.
BigBrain: hdh0: it's a started crossfire support dll afaik
BigBrain: at least they're working on that atm
hdh0: that makes more sense
BigBrain: It's just my guess that the new .so is for crossfire though, but it makes sense, as there is a "CF manager" in the xorg logs now
adamk: libv, Do you know, then, what the reasoning was behind AMD funding development of a new driver, rather than extending the current DDX?
adamk: Not that it really matters to me... I'm just curious :-)
mattst88: I'm definitely curious also.
mattst88: I think inevitably, one will cease to exist when the push to move graphics drivers into the kernel happens
mattst88: as I don't think the kernel developers will like having two drivers for the same hardware being continually developed.
libv: adamk: there is barely any modesetting code that is shared between r5xx and before
mattst88: how does the quantity of modesetting code compare with other things the DDX implements, for instance, EXA, texture video?
libv: mattst88: clean or dirty?
libv: mattst88: 3:1
mattst88: wow, I thought it would be the other way around. shows what I know about the topic at hand.
libv: mattst88: plus, the acceleration becomes completely useless with r6xx
marcheu: mattst88: if you use atombios, it's the other way around actually
mattst88: meaning, the current acceleration code?
marcheu: also the acceleration is very incomplete ATM
mattst88: marcheu, hmm, that is interesting.
libv: mattst88: the drm and dri, are already segmented away.
mattst88: marcheu, don't you know the owner of http://www.bitblit.org/gsoc/g3dvl/index.shtml ?
marcheu: yeah he's my SoC student
mattst88: thought so. tell him he needs to post another update, as we're anxiously waiting to see how he's progressing :)
marcheu: he was dealing with bugs last we talked
marcheu: anyway you radeon guys need to get gallium going first :)
gentoofu: bugs? as in the stuff he's supposed to work on by July or August?
gentoofu: wow, he's really far ahead :)
Temujin_: hello, i believe i have a bad card here because it wouldn't work on my roommate's computer with XP Pro/ Catalyst 8.6 nor on my box with Ubuntu 8.04 Catalyst 8-6 and the latest radeonhd driver. I don't want to try the ati(AtomBIOS) driver, not looking for 3D accel, just good 2D accel and video playback
Temujin_: it's an HIS Radeon 3450 PCI-e and I can only get VESA video modes in Ubuntu
Temujin_: i just want to confirm that you folks have the RV620 xrandr
Temujin_: code working
agd5f: Temujin_: should work fine with both radeonhd and radeon
agd5f: just no accel yet
Temujin_: thanks, that's what i thought
gentoofu: what's the Xorg log when trying radeonhd?
Temujin_: would you like me to e-mail it?
gentoofu: pastebin so the whole world can see it
Temujin_: could be X.org needs updating, i'm having problems with that though
gentoofu: not a single word has a radeon in it o_o;
Temujin_: err, hold on a sec
agd5f: just pushed r6xx drm. no 3d yet. still need mesa and ddx support.
gentoofu: for kernel 2.6.26?
muep_: how about xvideo?
muep_: or does it have anything to do with dri?
agd5f: just drm git
agd5f: it's the drm for r6xx cards, 3D and video accel use it to submit commands
z3ro: agd5f: nice. :) will the register docs be out soon, too?
airlied: z3ro: did you ever get revenge on r600?
z3ro: airlied: no, I could never figure out how fglrx did the MC setup... but then I didn't look that deeply into it.
z3ro: I guess the drm code will show how it's done now.
z3ro: assuming fglrx doesn't do something more complicated.
airlied: yeah the drm mostly sets up the memory controller now.
airlied: yeah hopefully not :)
agd5f: z3ro: should be soon
z3ro: agd5f: ok
MostAwesomeDude: Did somebody say..."docs"?!
agd5f: I know we've been saying that for ages, but we've made good progress this week
airlied: MostAwesomeDude: well r6xx drm code is in a branch now.
MostAwesomeDude: airlied: So I've heard.
z3ro: agd5f: so do you think we'll see a release of the docs and tcore/etc together? or they will be separate.
agd5f: z3ro: separate. docs probably first
MostAwesomeDude: ...I should add r7xx to the Wiki pages.
MostAwesomeDude: I should also unbreak fog coords.
z3ro: agd5f: I see. I just hope tcore isn't too far behind. :)
agd5f: z3ro: much of what's in tcore is now in the drm, at least for r6xx
z3ro: agd5f: well, I think I can take a lot of code from tcore for making my demo prog standalone, which is something I'd like to do...
airlied: z3ro: not really.
airlied: z3ro: tcore isn't magic, just use the drm..
airlied: you still need to do modesetting etc..
z3ro: airlied: right, but atombios makes that reasonably easy.
agd5f: tcore isn't really a program it;s more like a HAL. you have to write stuff that uses it
airlied: z3ro: its not like it has a GL stack either.
airlied: z3ro: is the demo prog sorta like r300_demo?
z3ro: airlied: yeah
airlied: you can probably just write something using indirect buffers on the drm easier.
z3ro: thats what I'm doing at the moment, but it would still be cool to have something indepentant of X.
airlied: tcore is a lot of example code but I haven't even tried to actually run it :)
airlied: z3ro: the drm is independent of X.
z3ro: airlied: ah right, just have my app do the modesetting and tell the DRM about it?
airlied: z3ro: you can init the drm with the same amount of code to interface to tcore I would expect.
airlied: z3ro: or wait for kernel modesetting in the drm :)
airlied: but initially oyu could just atom modeset and bring the drm up in bits.
airlied: granted I'd rather the drm does a lot more stuff itself.. and modesetting will fix that.
z3ro: yeah that might be the way to go.
airlied: having seen tcore I don't think its the answer to your particular prayers :)
airlied: I haven't even tried to compile it.. :)
z3ro: I see. I'm sure it will still be interesting to have a look at, but going through the DRM might be the better way.
airlied: well if you look at the r6xx branch of the drm it contains most of what tcore did on r6xx :)
airlied: except for submitting 2D CP packets
z3ro: I'm looking through those commits now.
z3ro: ok, so it looks like the RB stuff changed, and the page table/PTE stuff.
airlied: all the registers moved.
airlied: but a lot of the concepts stayed the same.
z3ro: guess it's time to find that r6xx card then. :P
z3ro: hopefully I have one... honestly I've lost track of which cards I've got. =|
mitsarionas: thanx for the good work guys :) keep it up!
mitsarionas: i just needed to say that
mitsarionas: i'll shut up now
z3ro: damn, I'm going to have to teach my lexer about context. =/