King_InuYasha: tpocra, check the patches that Debian applies to the kernel if that is possible
King_InuYasha: if there is a set of patches for DRI, then it is likely that the patches break Radeon's DRI
agd5f: King_InuYasha: radeon tv-out on r1xx-r3xx cards only supports 800x600 over S-video
agd5f: it's hardcoded in the driver
agd5f: even so, the card is outputing native NTSC or PAL signalling. the image is just downscaled
agd5f: the hw supports downscaling other modes, but it's not supported yet
hifi: agd5f: umm, you sure about 800x600?
hifi: I think I tried 1024x768 with r2xx
hifi: or is it just downscaled to 800x600?
hifi: which kind of explains why the image quality is really crappy with 1024x768
Zajec: agd5f: thanks for you reply about KLDSCP_LVTMA, let me test this today/tomorrow
airlied: glisse: I pushed a kms-rewrite branch to my DDX repo, its not actually running yet, was sick today so mostly couch hacking
airlied: its moves towards using the libdrm_radeon for most things
airlied: the only extra optimisations the DDX needs are a check if something is in vram and a bit that always forces something into GTT
MrCooper: agd5f, airlied, glisse: I can't seem to get any effect out of the R300_COLORPITCH/TXOFFSET byte swapping bits :(
airlied: MrCooper: which ones did we notice were broken before?
MrCooper: the 3D engine ones didn't seem to work for me either last time I tried them, but that was R200 if not R100
MrCooper: maybe they never worked...
airlied: I remember paulus finding some that didn't work on r300
MrCooper: probably the 2D engine ones?
MrCooper: hopefully at least the DMA transfer ones work
airlied: MrCooper: I think it was the RBBM ones
airlied: RADEONHostDataBlit has a comment in the DDX
MrCooper: oh right, forgot about that
pvh: heya... i got ubuntu 9.04 here with a Radeon 9550 - the radeon driver doesn't seem to pick up my card when I got Xorg -configure - any hints?
glisse: airlied: will take a look
glisse: i want to finish some clock related rework in drm today
airlied: glisse: yeah no worries just warning you in case you were going to go looking at it :)
glisse: i think i will get back to mesa bugs too
glisse: thing like cubemap
airlied: yeah my r200 fix didn't work for some reason
airlied: glisse: btw say we have VBPNTR emit, followed by lots of INDX_BUFFER emit and we flush the CS
airlied: don't we have to reemit gthe VBPNTR?
airlied: or does CS catch this at all?
glisse: yes need to reemit, i think it catch it
pvh: ah, my radeon problem is the same as reported by david faure on kubuntu - red dots at the top of the machine and a system freeze - is this a known problem?
airlied: I've no idea why my r200 change breaks it
airlied: unless I just miscalculate some offset
airlied: glisse: btw is there an easy hack to make the kms driver stayt loaded if the accel init fails
airlied: glisse: i.e. if the ring or ib etc fail to setup, don't tear everything down.
glisse: airlied: yeah we could do that
glisse: we need ddx to figure that it should disable accel
glisse: like always fallback if csemit fail
airlied: glisse: it would be handy for debugging, at the moment if th edriver doesn't load it tears down everything :(
airlied: so when my ring setup fails as its doing on two systems now, I have to jump through hoops
airlied: I wonder if there is a nice reg we can use to read memory from the GPU perspective.
glisse: airlied: i think reg 0 can do that
glisse: maybe only starting from r5xx
airlied: glisse: btw were you going to revise the prealloc patch to reduce the memory hit?
airlied: or can you at least work out the memory hit.
glisse: airlied: well idea was to shrink the dma pool
glisse: to somethings like 4
glisse: so it should shrink the memory hit quite a lot
glisse: it's only about changing the const in radeon.h
glisse: could save little memory by avoiding the ptr table too
glisse: but would likely lead to slower cs
airlied: probably need some nums, but preallocing ~8mb unlockde main ram is also pretty bad
airlied: the vmalloc hit was quite large?
glisse: is reading process memory expensive ?
airlied: well you have to fault to do it possibly.
airlied: though get_user_pages is probably the safest way
glisse: maybe we can parse cs from userspace memory and copy into ib as we parse
airlied: I thought about doing 1k at a time
airlied: my only worry was locking and faulting
airlied: or 8k at a time even
glisse: maybe a page at a time is better :)
airlied: hehe.. yeah I'm not fully awake today.
glisse: well i could look into reworking that, i will also put some counter to actually have the right number for memory usage
glisse: but it should be: dmapoolsize * 64k * 2
glisse: ~4M with ibpoolsize = 32
airlied: the radeon_cs_reloc struct isn't really small though
glisse: yeah that one is taking memory
tball: Hello. What is the status of r600/r700 3d acceleration?
tball: Yeah, but a more precise status :) Does it run anything yet?
chithead: tball: http://wiki.x.org/wiki/RadeonFeature little more than mesa opengl demos run at this time
tball: Not bad :)
tball: That means glxgears etc I guess. What about the opengl extensions needed for compositing?
chithead: tball: xrender based compositing (kwin/metacity) works. opengl based (compiz) does not.
tball: chithead: Thx for the update
chithead: update? this is nothing new
tball: Do we have an estimated time for opengl 2.1 to fully work?
tball: or even just 1.3
airlied: not really, stuff happens when it happens around here.
tball: Fair enough :) Though it would be nice with a guess or an estimate :)
nanonyme: chithead: Oh, Mesa demos run for you already?
nanonyme: They don't for me.
nanonyme: tball: No, it excludes glxgears. That's a bit more advanced already.
chithead: tball: http://www.phoronix.com/forums/showthread.php?t=17603 if you want to see the current state of affairs yourself
tball: Thanks everybody
tball: And keep up the good work, thus of you writing this driver
tball: Can't wait trowing fglrx out in the trash'
chithead: nanonyme: last time I tried, it was all very crashy. but some users reported limited success
nanonyme: tball: Atm the r600/r700 3D code seems to be (at least on my 2.6.29) on a pretty volatile state which runs some test programs half-properly but if you do something more complicated like resizing window, it lockups.
nanonyme: (That is, the OpenGL windows)
nanonyme: Best to just wait at this point. ;)
mjt: there was no r600/r700 3D code on 2.6.29
mjt: but the r6xx-7xx-support branch compiled on 2.6.29 worked for me quite stable
nanonyme: mjt: Yeah but 2.6.29 is the latest kernel for which agd5f's DRM code likes.
nanonyme: r6xx-r7xx-support branch of Mesa is obsolete.
nanonyme: You should be using r6xx-rewrite.
mjt: i mean drm - the kernel part
nanonyme: That's r6xx-r7xx-3d. ;)
tball: I guess I'll just wait. Running 2.6.30, soo.
mjt: by the way, what's needed for power management support?
nanonyme: And yeah, the necessary kernel bits aren't in any kernel and won't be in 2.6.31 either.
tball: It won't?
tball: You mean for kms ?
nanonyme: I mean for r6xx/r7xx 3D.
tball: ohh ok
nanonyme: (At least afaik)
nanonyme: Eg agd5f or airlied could give a bit more creditable verifications on this if you need to know. ;)
nanonyme: mjt: Hmm, in KMS land?
nanonyme: I got the impression power management altogether needs to get ported to kernel DRM there.
mjt: nanonyme: in... any land. ;) Basically I just want to turn OFF the built-in AMD740 graphics on a headless machine.
mjt: or 780 for that matter.
nanonyme: Can't do that from BIOS?
mjt: the northbridge consumes about 2x more energy than the CPU :)
nanonyme: I dunno how to completely turn it off and I don't think pre-KMS power saving works without X...
mjt: in bios there's usually a choice of a "primary display search path" - where to find the console, -- pci, pci-e, agp or built-in.
mjt: but even if an additional card is "in use", the built-in one still works at full
nanonyme: Hmm, silly.
mjt: very simple test: summary power consumption grows a bit when using an old PCI graphics card.
mjt: (i've two matrox cards still ;)
mjt: but ok, i see where it is going to. "kms" :)
nanonyme: Myeah... Considering without power management and folks junked into kernel radeon driver handles power management which means you have to start X to get radeon driver which would in term reduce power consumption. :p
mjt: well, not really: starting X does not change anything.
nanonyme: Did you configure the power management options in xorg.conf?
mjt: are there any? :P
mjt: never heard of them.
mjt: re-read X and Xorg and xorg.conf radeon and radeonhd manpages several times :)
nanonyme: It's relatively new.
nanonyme: How new are your X display drivers?
mjt: i'll definitely try it
mjt: the system i'm talking about does not have any X stuff installed now
nanonyme: Some of the power management options should reduce performance due to not being dynamic but that shouldn't bother you...
mjt: but since about Nov-2008 i'm using all-git-bleeding-edge-stuff for radeon :)
mjt: (that was the time when - finally - i was able to ditch fglrx)
nanonyme: I'm also unsure whether you can start X headless as is or if you need some hackery there.
mjt: lol. installing X server, maybe xdm too, on a headless server JUST to turn off the graphics card :)
mjt: it starts
mjt: i mean, i tried it already, -- with monitor turned off.
mjt: it picks up some "default" resolution and pretends the monitor is here
nanonyme: Well, with the stuff in kernel you shouldn't be needing that anymore. :) Dunno how the developers exactly have planned it to work, I'd expect you to be able to at least write a userspace command line tool for requesting power management and so.
mjt: and it looks like parallel X sessions also needs kms, right?
mjt: (now it's not possible to open /dev/drm/card0 more than once)
nanonyme: Yeah, true. You could run the other X session with shadowfb though, I guess.
mjt: but very slow
mjt: and esp. fun for xv :)
nanonyme: Well, yeah.
nanonyme: No idea how far on priority list the stuff that allows multiple users to use DRM on the same card are though.
nanonyme: (It might even work, I've no idea. Haven't yet had a working KMS system)
nanonyme: The sucky part of owning only new or less common hardware. :)
airlied: mjt: its well possible ot open /dev/drm/card0 more than once
airlied: its how DRI has always worked
airlied: the multi-master changes allowed multiple X servers finally
airlied: if the drvier supports it.
airlied: which really only KMS drivers can
airlied: without a lot of work
airlied: so kms driver can already do it.
nanonyme: Hmm, where are the multi-master changes exactly? (as in, what does one have to upgrade and how far?)
airlied: you need kms for it
nanonyme: Right. Only that? No eg required X server versions or anything?
airlied: I never added the ioctls to the non-kms driver because I didn't want to bother
airlied: nope, I used to have it working with DRI1, DRI2 just makes it easier.
nanonyme: Will keep that explanation in mind.
airlied: generally if you aren't running git, you are running a distro
airlied: and then you are better off talking to them :)
mjt: airlied: re your first comment (i's well possible to open card0 more than once) -- no it is not with radeon.ko <= 2.6.30 :)
airlied: mjt: well actually dri always opens card0 more than once
airlied: mjt: having two X servers open it is the problem
mjt: seriously, it gets nothing to the user, -- the underlying mechanics. the end result is that second X session reports "dri: device busy"
mjt: or anything else really - does not matter either
airlied: mjt: I'm fine with what the user sees, my problem is with people badly explaining what the user sees.
airlied: because other people repeat that
airlied: then I hear it back in some phoronix post
mjt: oh ok
mjt: that makes perfect sense
airlied: but yes multi-server 3D on radeon will require kms
Zajec: we still can't have acceleration on 2 X sessions using KMS?
airlied: on intel for example it works since 2.6.29
airlied: Zajec: you can
mjt: so the proper terms is 'multi-master does not work with current radeon from mainline kernel'
Zajec: oh, ok, that's great :)
airlied: mjt: yes, now that kms is in Linus tree, you also can say except when using KMS :)
nanonyme: Can we also expect the Spanish Inquisition? :o
mjt: is kms useable already?
mjt: for radeon anyway
adamk_: It works fine here... Has a few minor issues.
tball: What about kms for r600/r700?
nanonyme: Memory management not done afaik.
tball: How many money should I donate to radeon developers, to get this work done within two weeks? :P
tball: afaik it might be impossible
mimikry: i would also like to have a possibility for donating for a special feature :)
muep: maybe you could hire someone to work on a specific feature :-p
hifi: will buy moar fps o/
nanonyme: muep: Yeah, probably wouldn't cost nearly anything to hire someone full-time for likely months on a feature. ;) (let alone the fact that he would in the beginning slow down other developers since he'd have to find out what the vision for the unwritten stuff exactly is)
muep: I know it'd take more than loose pocket money :-)
muep: for most of us anyway
Kano: hi, when can we expect a new official release?
zhasha: Kano: of?
Kano: in which channel do you think i am?
Kano: ati driver of course
zhasha: the 2d driver or the 3d driver
nanonyme: Kano: Aren't you going to be in for lots of fun if you keep asking that in KMS-only world. ;) Will have to direct it kernel release peeps. :)
Kano: i dont need kms
nanonyme: I suspect you missed my point.
nanonyme: As in, afaik new card support will be gotten with new kernel releases in the long run, not with ddx releases.
nanonyme: So assuming you only use released versions, you'll have to wait through kernel release cycles then. :p
Kano: i create a snapshot if needed, but last stable is several month old
stuckey: I just installed a new ati card; how do I test it to make sure it's working properly?
adamk_: stuckey, What model ATI card?
masa-: i still have the same problem as yesterday: 3D is not working (with hw accel..) on my X600
masa-: glxgears gives "Error: couldn't get an RGB, Double-buffered visual"
masa-: what does that mean and what have i messed up?
masa-: using 2.6.30-gentoo-r1, xorg-server 1.5.3-r6 and xf86-video-ati-6.12.2
stuckey: adamk_: x1300
adamk_: stuckey, What's the output of 'glxinfo | grep -i renderer' ?
stuckey: adamk_: http://paste.debian.net/40554/
adamk_: stuckey, Then, no, it's not working properly.
adamk_: stuckey, Looks like your version of Mesa is too old for your video card. What distribution are you using?
stuckey: adamk_: debian stable
adamk_: D'oh, sorry about that.
adamk_: Debian stable is amazingly old.
zhasha: stuckey: what version of mesa/r300?
jcristau: stable has mesa 7.0.something
stuckey: zhasha: 7.0.3
zhasha: should really update that
jcristau: sorry about that.. i couldn't get a new mesa in without a new server, and that only got released after we froze for release.
stuckey: zhasha: which version do I need?
zhasha: I'm not exactly sure.
zhasha: 7.4 probably
zhasha: not sure when X1300 entered
jcristau: >= 7.2 should work iirc
zhasha: 7.2 needs newer Xserver?
adamk_: For AIGLX, yes.
adamk_: It needs 1.5 or higher, iirc. I'm guessing debian stable comes with 1.4.*
jcristau: adamk_: right
stuckey: What does the x1950 need?
zhasha: probably the same
agd5f: Kano: 6.12-branch is stable tree, so you can get the latest stable updates from that branch
agd5f: hifi: yes, 800x600 is all that is supported on tv-out for r1xx-r3xx. I wrote the code :)
masa-: can someone take a quick peek at this: http://pena2.dy.fi/temp/ati/
chainsawbike: masa-, dri peoblems?
masa-: i guess so
masa-: glxgears gives "Error: couldn't get an RGB, Double-buffered visual"
masa-: gotta go, bbl ->
nanonyme: bridgman: Yo.
bridgman: thppth !
nanonyme: gets critically hit by the confusion spell by bridgman and loses 5 points of sanity
bridgman: your greeting came in at the same time as an email from someone else, and that email reminded me of a bloom county comic, which resulted in the classic Bill the Cat greeting... Ack ! Thphht !
bridgman: except I was in a hurry
bridgman: and my spelling was a bit off, apparently
nanonyme: Neat. Never heard of that comic.
bridgman: I think you'd like it
stuckey: How would I upgrade my radeon version?
nanonyme: I think that nowdays depends on at least which distro you're using and how adventurous you're feeling. :)
stuckey: We only have 1.6 in the experimental section
stuckey: I have a x1300 so I need at least 1.7 (so I've been told).
nanonyme: Hmm, sounds like you're talking about the X server version.
stuckey: xserver-xorg-video-radeon 1:6.9.0-1+lenny4
stuckey: That's what I have for radeon
nanonyme: What's the feature you're not getting with your current driver version but you would wish to get? :)
stuckey: 3d accell
bridgman: ok, so you're running 6.9.0 plus some patches, current version is at 6.12.2-ish
agd5f: stuckey: you'll need newer mesa as well
nanonyme: Mesa upgrades is the most likely path then.
stuckey: what's mesa?
bridgman: 3d is mostly handled by the mesa and drm drivers, not the radeon driver
bridgman: the 3d driver
stuckey: what's the radeon driver then?
suokko: stuckey: Probably the easiest route is to upgrade to squeeze
bridgman: there are three drivers that work together; the X driver (radeon/radeonhd), the kernel driver (drm), and the 3d driver (mesa)
agd5f: stuckey: debian provides newer drivers in some repo
bridgman: the radeon driver handles modesetting, 2d and video acceleration
nanonyme: bridgman: Not to forget power management? ;)
bridgman: with the help of the kernel driver (drm)
bridgman: temporarily, yes ;)
nanonyme: Well, you could say that's the case with modsetting, 2D and video acceleration too. ;)
nanonyme: Modesetting even.
stuckey: agd5f: which repo?
bridgman: modesetting at least; no plans to move acceleration APIs although those APIs may make use of Gallium3D functions
agd5f: stuckey: you'd have to ask a debian dev
stuckey: So which version of mesa would I need?
stuckey: or, libgl1-mesa-dri
nanonyme: bridgman: I've also been hearing hopes that after Gallium3D starts handling those, we could move to xf86-video-modesetting.
nanonyme: We'll see though.
agd5f: stuckey: the latter
stuckey: agd5f: I don't need to upgrade allof them?
agd5f: stuckey: likely you do
stuckey: Right now I have version 7.0.3
agd5f: stuckey: you'll need mesa 7.2 for 3d for 3d on your chip
stuckey: I can get 7.4.4
agd5f: and probably a newer xserver if you want to try compiz
bridgman: nanonyme; yep, I was thinking more of "the X driver" than "radeon"
bridgman: I agree that with Gallium3D plus KMS there's a decent chance of moving to a generic X driver
tormod: stuckey: you can get 7.5rc4 from experimental
stuckey: tormod: awesome
stuckey: Are there any distributions which keep more recent device driver versions in their stable?
stuckey: Everyone tells me that the verions I have---not just with drivers but with everything---is ancient.
muep: Fedora has X stuff quite up to date
tormod: debian is... ancient :) you have to use Debian experimental
jcristau: tormod: sid should be good enough.
nanonyme: jcristau: Doesn't sid equal unstable? :)
conso: just wanted to let you know that there is an issue with running cairo-dock in opengl-mode with the free radeon driver. the background is black. Works like a charm with nvidia-card
jcristau: nanonyme: yes
conso: it's possible to run cairo-dock in cairo-mode without openGL, but then you loose some nice eyecandy ^^
tormod: Debian unstable = stable but not tested enough years
stuckey: any big benefit to running something above 7.2 with an x1300?
nanonyme: bridgman: Would be nice since it would make this radeon vs radeonhd "problem" disappear by itself. :) Complete end of discussion. ;)
muep: Woudln't call sid stable
jcristau: muep: i'm not sure i'd call fedora stable ;)
jcristau: but then i'm biased
conso: nanonyme: what did dridgman say? I just entered
tormod: conso: www.radeonhd.org has archives
muep: To me, sid has been quite inconsistent, with occasionally quite severe breakage, and sometimes frozen for months due to debian trying to get their stable release out
nanonyme: conso: We were talking of 2D and video accel moving to Gallium3D and modesetting moving to KMS so there's not much more that the radeon/radeonhd drivers are needed for in distant future and a move to xf86-video-modesetting is possible.
nanonyme: Note the "distant future" part. ;)
muep: what's distant in the mind of radeon driver developers?
conso: yay, but sounds good :)
bridgman: I think the radeon vs radeonhd "problem" went away almost a year ago; devs on both sides talked and reached the same conclusion, that eventually both would be replaced by a generic driver and that in the meantime we might as well keep both going
nanonyme: muep: Mostly trying not to give optimisting ETA's since it's not my call anyway what happens with the drivers. ;)
bridgman: most of the work is in mesa and drm these days anyways
nanonyme: Optimistic even.
muep: I was mainly after an order of magnitude, not an eta, but I understand that these are hard things to predict :-)
nanonyme: I stuck words "eventually" and "possibility" to the idea in my personal Universe. :)
bridgman: muep; the main thing to understand is that there are two milestones not one; the first milestone is when the new thing starts to be useable, the second milestone is when the need for the old thing goes away
bridgman: in the case of generic X drivers the two may be 1-2 years apart
nanonyme: The second one determined a lot by how long it takes for the slower distros to pick up *all* necessary changes?
conso: i just wished the radeon-driver would give me less strange artifacts in the near future ^^
bridgman: the first prototype generic X driver is kinda running today AFAIK, but there will probably be an ongoing need for usermode drivers (and new hardware support in those drivers) for at least a couple of years
bridgman: nanonyme; yes, particularly enterprise distros
nanonyme: (Hrm, maybe "conservative on updates" might be fairer than "slower")
bridgman: or any distro whose top priority is stability and predictability over "newness"
bridgman: yeah, we need a language where each word only has one meaning
bridgman: it would make the free software discourse a lot easier too ;)
muep: no one dared say anything anymore...
muep: *would dare
bridgman: too many people get excited then lose interest when they realize that it is *not* about free beer after all
bridgman: imagine how disappointed I was
conso: i'm on arch-linux and damn, it's stable :P
nanonyme: bridgman: I always understood the "free as in beer" like that some student collegue of mine donates me beer and then I'll code something for them. ;)
nanonyme: Sounds fair to me.
nanonyme: (Of course, the idea doesn't scale well for bigger projects since main developers would quickly become alcoholics...)
stuckey: So I just need to upgrade mesa, and not the radeon driver? Is that correct?
nanonyme: It's a good first course of action, yes.
stuckey: first course?
muep: hmm... where are the radeon specifications hosted? ( I don't understand much about them, but wanted to take a look anyway :-)
bridgman: try it first, and if that doesn't work then update more things
bridgman: muep; for the chips or the drivers ? chips are at www.x.org/docs/AMD/
bridgman: also on amd.com
muep: bridgman: thanks, exactly those
bridgman: the 5xx 3d doc might be the best place to start
muep: a link at http://www.x.org/wiki/radeon would be nice
bridgman: sorry, 5xx accel
nanonyme: muep: Isn't it a Wiki? ;)
conso: i recently switched to the open radeon driver from fglrx and while performance is quite ok, I realize glitches here and there. Am I supposed to write bug reports for each one of them or are those smaller glitches to be accepted for the near future?
muep: nanonyme: true, but I usually don't want to write into a wiki without knowing the 'culture' around the wiki in question a bit better :-)
bridgman: depends a bit on whether you are using bleeding edge code or code from master which is generally expected to be stable
bridgman: for master, check the existing bug tickets to see if something similar exists; if so add your info; if not, start a new ticket
bridgman: for code on a branch, might make sense to ask here first to see if the devs want bug reports yet
conso: i'm running a recent mesa-build atm, as that was told me in the channel ^^
conso: mesa-svn from about half a week ago
nanonyme: muep: Well, I doubt putting a link to www.x.org/docs/AMD in the "Documentation and Support" section of radeon wiki and a short explanation that hardware specs can be found here would be frowned upon.
muep: nanonyme: quite probable
conso: the radeon-driver itself is stable, i suppose
conso: anyway, i had the same issues with stable mesa
bridgman: again, yes and no; the code in master is stable, but there are branches with huge changes, eg support for modesetting and memory management in the kernel
Kano: then go for nv ;)
conso: ok.... I'm not running a branch, so I guess I'm supposed to report.
conso: kano: hard to switch the graphics-card in a laptop ^^
Kano: conso: mxm
mjg59: Almost nobody ships mxm hardware
muep: bridgman: want to elaborate a bit on why R500 is the place to start? is the R500 architecture a lot simpler?
bridgman: I guess it's more representative of the graphics cards out there, in the sense that it includes a 2D engine as well as a 3D engine, and that vertex & fragment shaders are handled with separate hardware
bridgman: it does have a good explanation of the command processor / ring buffer, while that section is quite a bit shorter in the 6xx/7xx 3d guide
bridgman: the 6xx/7xx is probably simpler, actually, but it's only really representative of the most recent generation of GPUs from anyone
nanonyme: Hmm, does the vertex & fragment shader handling differ a lot in 6xx/7xx?
nanonyme: (As in, from r5xx)
Kano: bridgman: will there be a driver this year for r600 which is able to play videos without extreme tearing AND 3d incl. glsl?
bridgman: from a programmer standpoint not that much, but from a hardware and low-level driver POV it's quite different since the same hardware handles both vertex and fragment shader processing
bridgman: Kano; open source ?
Kano: bridgman: does not matter for me
Kano: fglrx is unusable on my 3450 for watching a dvd
muep: R600 (and later probably also R700) is what I have, which makes it a bit more interesting to me...but maybe I'll have a peek at the R500 docs too
bridgman: I think so; fglrx with gl video output is tear-free for most but not all users, and we're still improving the regular video paths
nanonyme: ponders whether the answer regarding open drivers would change from doubtful to possible if someone was nice enough to write the r6xx/r7xx memory manager :)
Kano: well definitely not here
Kano: also gl output is no option, xv is it
bridgman: glsl on 6xx and higher open drivers is iffy since practically it will need gallium3d solid
bridgman: why is gl not an option - player limitation ?
conso: kano: why is gl-output not an option?
Kano: xine does not use opengl even if i select it. only mplayer would support opengl output correctly. but i need xine as vdr frontend
conso: ahm... there is another vdr-soft-frontend
bridgman: muep; if you already have a 6xx or higher card then by all means start with the 6xx 3d doc
nanonyme: Kano: Sounds like a Xine bug.
Kano: conso: i use oss driver for video, but if i want to play the simplest 3d game i have to switch. the card is really slow so i do not play games that much
muep: bridgman: well, thanks for the pointers
Kano: conso: i only use that card for testing fglrx and for watching tv/dvd
Kano: fglrx is uninstalled after i know that it would run
Kano: tearing is EXTREME
conso: kano: iirc, the vdr-softdec (not xine) can output via openGL and if fglrx supports dri2, there should be no problem with that
Kano: conso: i prefer using xine, just with the other driver using xv. thats for video output and not opengl
conso: i wished I had a card still supported by fglrx. The radeon-driver isn't a very good experience to me for now
Kano: conso: r500?
Kano: well you could use my distro, 9-3 still runs with it
Kano: if you like fglrx so much
conso: no, I definatly want to use archlinux, as games and eyecandy are a bonus, but what I need is a responsive system for university
conso: my laptop is pretty old and arch-linux is by far the fastest distribution I tested with it
Kano: not that i laugh
Kano: i see no reason why arch should be faster in any way
muep: the most important reason probably is that it runs very little stuff as default
Kano: and thats only on arch?
muep: and if the user adds there only what he/she wants, the system is usually left quite lean
muep: it's not only arch
conso: well, I tested a dozen of distributions and arch gave me a big boost. dependencies are flat and binaries are optimised for i686
muep: but the more mainstream distros (excluding maybe Debian) tend to install quite a few services as default
Kano: my distro is debian based, ubuntu based kernel
Kano: kde 3.5
Kano: ext4 support
conso: hehe, i didn't realize I talk to THAT kano till now ^^ hi :D
Kano: nobody condered it slow till now
conso: it might be rocket fast, I'll stay with arch anyway. I like anything about it but the radeon-driver's-small-glitches-here-and-there and all my other computers run it quite fine.
conso: (and I don't like kde, sorry)
conso: I guess it's ati to blame for stopping support for more cards then they add on a regular basis :P
bridgman: how can we do that ? wouldn't we end up supporting no cards ?
conso: <-just realizes he might make some enemies here.
bridgman: nah, other people say much worse things ;)
bridgman: in a sense you're right though... the 3xx architecture was very successful and lasted longer than is normal, so when we dropped support for that architecture we took out 3 generations of hw rather than the normal 1 or 2
conso: you know, just when fglrx added support for cool features like dri2 it stopped supporting a big bunch of legacy cards (like mine) that's UNFAIR :P
bridgman: actually we made a point of getting dri2 (actually rdr, not dri2) into the last release before we dropped support
bridgman: 9.3 has rdr
bridgman: and supports your card
conso: didn't know that...
conso: cool, I might check out some options now ^^
bridgman: you also need to remember that those GPU generations were dropped for all OSes, not just Linux
muep: The only fundamental problem I have with catalyst is that the development process seems slow to react to new releases of the components of the Linux graphics stack
conso: I know, read some bad words about it on windows-forums when googling ^^
muep: But I've kind of accepted that by now, and just multiboot to a different distro when I want to do some 3D stuff
bridgman: muep; it's not a process thing, it's that far more of our Linux customers use really old kernels & x servers than use bleeding edge ones
bridgman: we just added support for RHEL 4.8, which uses the 2.9 kernel
bridgman: and there's a lot of customers there
bridgman: sorry, 2.6.9
muep: I know it's hard to please anyone, but in my opinion, after AMD released the specifications, there's a lot less to complain
muep: *hard to please everyone
muep: anyone's usually possible
bridgman: well, now everyone wants us to write the damn drivers too ;)
glisse: yeah compagny doesn't upgrade their os every 6month but rather every 3years at best
conso: aye, that was a wise decision
conso: bridgman: hehe
jcristau: bridgman: i thought glisse, airlied and MostAwesomeDude were doing that for you? ;)
bridgman: not fast enough, apparently ;)
bridgman: patience is not a common thing these days ;)
bridgman: most people were willing to wait a few weeks for new drivers if absolutely necessary ;)
conso: I guess the reason why I'm a little dissappointed with the open drivers is that they were praised for my architecture (r300) and now there are small glitches almost everywhere. It's the mass of small glitches that reduce the fun.
conso: anyway, a lot of things work very good with them
bridgman: where are you seeing the glitches; 2d or 3d ?
conso: more 3d
bridgman: remember that the glitches may not be in the driver code, ie the other parts of the stack don't necessarily follow what the drivers support either
glisse: conso: bug report are welcome with simpletestcase and good description
glisse: we don't have time to play everygame or use every 3d app out there
conso: but sometimes even 2d. really small things like seeing the borders of background-tiles in teewars, missing transparency in cairo-dock (openGL), black textures in games like trackballs.
glisse: conso: bugs
glisse: conso: i can't track irc for bug
glisse: i keep forgeting
conso: I registered a bugzilla-account 15 min ago and am waiting for the email ;)
glisse: bugzilla keep remembering bugs for mee
conso: Aye, I'll try to report bugs as good as possible.
conso: btw: wich acceleration am I supposed to use (r300)
glisse: yeah likely r300
nanonyme: conso: Check antispam filters?
nanonyme: Checking doesn't cost much and then you don't have to risk not getting the message at all. ;)
conso: aye ^^
conso: problem is: thunderbird is remembering the password for me ^^
conso: where am I supposed to submit the bugs? xorg? mesa?
glisse: likely mesa
glisse: bugzilla need rework to make things easier
adamk_: I have yet to see a bugzilla for any project that wasn't very out-of-date.
nanonyme: glisse: Maybe a wizard in bug reporting?
conso: is that report ok?
nanonyme: conso: That's just a submit form, we don't see anything until you submit the actual bug.
nanonyme: (Actually I only see a login screen but I'd assume there's a submit form behind it ;)
conso: how am I supposed to do that?
nanonyme: glisse: That is, you'd get to input card name (most probably can figure out which card they computer has) and select tags (eg video playback, OpenGL, compositing) and the actual party who the bug belongs to would be determined by those. ;)
bridgman: there should be a "submit" button that will actually record the bug in the database
bridgman: then you can post the bug # here
nanonyme: Some fuzzy logic would be used for figuring out the driver from the card name.
nanonyme: (Just an idea)
bridgman: might not be worth it; now that compositing through the 3d driver is so common it's getting increasingly hard to find the right intial category for bugs
nanonyme: bridgman: How about the bugs first getting lumped to a generic radeon category if you get a graphics card hit with the detection (no tags), then developers get to reassign it to eg Mesa, X driver or DRM accordingly?
bridgman: yep; the other option is to stay with the current categories and publish some brief pop-up guidelines for where to file based on what you are doing at the time, accept that a percentage will be filed wrongly, but at least have most bugs put in the right category without developer time being spent
conso: is there something wrong with my bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=22532 or can I start adding additional reports in that style?
conso: I know it's quite untechnical ^^
conso: also, it's remarkable, that the cairo-dock devs write on their wiki, that the black background is a radeon-driver issue, but seem to not have filed a bug-report to you.
conso: bridgman: as far as I understand their wiki, the same bug appears with fglrx
otaylor: conso: might be fixed in radeon-rewrite (or has that been merged to trunk?)
conso: never heared of radeon-rewrite
otaylor: conso: Actually, wait, I looked into cairo-dock issues
nanonyme: otaylor: Gods, it's git, not svn. ;)
otaylor: conso: it's a weird nastiness with cairo-dock using multiple X displays and sharing textures between them
nanonyme: Saying "trunk" refers to svn, really.
otaylor: conso: which is allowed by the GL spec but nobody does
conso: seems like they do. but I guess it's meaning fixing that bug is rather unlikely?
otaylor: nanonyme: a pet peeve of yours?
otaylor: nanonyme: "trunk" is just terminology that was adopted by svn in the conventional directory structure
nanonyme: Yeah and the terminology used in git for the equivalent is master branch. :)
otaylor: nanonyme: sure, it does imply a single central thing things branch from, but that's pretty much implied by "master" as well
otaylor: nanonyme: hmm, you know, I did a large chunk of the migration to git.gnome.org and wrote the hook scripts, and my own git/bugzilla tool. So, please chalk up any miuse of git terminology to ingrained habit rather than ignorance or malice :-)
nanonyme: Fine. And yes, you were right about the merge.
conso: another little bugreport
MrCooper: conso, otaylor: the version of cairo-dock I have doesn't seem to use GL at all, but if the current version uses GL rendering to a 32 bit visual for translucency, it can only work properly with DRI2
stuckey: okay so I upgarded mesa to 7.4; how do I test to make sure it works properly?
nha: glisse: any idea why linus' kernel would fail with KMS enabled, even though I used to be able to run KMS-enabled kernels just fine? I compiled linus tree as early as possible after the big fat KMS commit, and even there it fails, so the problem seems not to have been introduced *after* that big fat commit
nha: exact error is:
nha: [ 16.010759] [drm:radeon_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
nha: [ 16.010765] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
nha: on an R500
glisse: nha: how much ram ?
MrCooper: nha: AGP?
glisse: few fixes went in since kms merge
glisse: today Dave pushed more fixe to gart
stuckey: adamk: I've upgraded to 7.4---how do I test it?
nha: and 1 GB RAM
suokko: stuckey: glxinfo |grep OpenGL
nha: I explicitly checked that CONFIG_DMAR is disabled, after that discussion I had two days ago with somebody else
stuckey: OpenGL vendor string: DRI R300 Project
stuckey: OpenGL renderer string: Mesa DRI R300 20060815 TCL
stuckey: OpenGL version string: 1.3 Mesa 7.4.4
nha: also for the record, I get no ring buffer failures with an R300
MrCooper: nha: does it work with radeon.agpmode=-1?
nha: Unknown boot option?
MrCooper: do you build it as a module?
MrCooper: if so that message is harmless
stuckey: suokko: "
nha: silly me
nha: and yes, it's looking good now :)
nha: yep, working fine, thank you
suokko: stuckey: That is telling you mesa 7.4.4 is used for opngl so it should work. But some 2D stuff might not work if you don't upgrade xf86-video-ati too
nha: MrCooper: any idea on what to do now to get this really fixed?
MrCooper: nha: np, though that uses PCI(e) GART so performance will suffer
MrCooper: nha: if I knew, I'd have fixed it for my own setup :}
nha: I see :}
stuckey: suokko: oh, I upgraded the entire distribution
glisse: maybe apgbase2 is at different place on r5xx
glisse: need to check that
glisse: doesn't have a r5xx agp card
stuckey: I have 6.12 on the xserver-xorg-video-ati
suokko: stuckey: Then everything should work :)
MrCooper: glisse: I thought AGP KMS was known to be flaky across the board?
glisse: MrCooper: it works for me on r1xx,r2xx,r3xx cards i have
nha: I didn't use to have this problem with earlier versions of KMS (pre-merge), though maybe with those earlier versions it was just disabling AGP automatically or something?
glisse: yeah i think agp was disabled at some point
MrCooper: I suspect a lot of it may be down to the AGP bridge (driver)
glisse: MrCooper: yeah sadly, i only have sis,intel agp bridges
MrCooper: as KMS is exercising them much more dynamically than before
glisse: most of bridge gart flush code looks misterious with mdelay in them
bridgman: IIRC the problem was that you could never tell if flushing had actually completed so you had to "wait a while and hope"
bridgman: we even have a "wait a while and hope
bridgman: register in CP ;(
glisse: i think it would have cost a lot less to hire few people to kidnap AGP engineer before they finished their monster
bridgman: in hindsight, yes
bridgman: at the time, the thinking was more "oh cool, yet another AGP standard, let's support it before everyone else"
agd5f: glisse: agp_base = MMReg 0x170 and agp_base_2 = MMreg 0x15c on r3xx/r4xx,
agd5f: glisse: r520 variants (r520, r580, rv53x, etc.) agp_base = MCIND 0x6, agp_base_2 = MCIND 0x7
agd5f: glisse: rv515 variants (rv515, rv550, etc.) agp_base = MCIND 0x3, agp_base_2 = MCIND 0x4
mjt: ghrm. So, running X on my headless AMD740G-based mobo and enabling DynamicPM option and forcing dpms standby mode using xset actually reduces power consumption by about 14W. Which is *awesome*.
agd5f: glisse: the legacy drm paths should have all that, not sure if it all made it over to the kms paths
glisse: agd5f: yeah i need to double check this
agd5f: glisse: agp_base = MMReg 0x170 and agp_base_2 = MMreg 0x15c on r2xx as well
glisse: working on bandwidth stuff
nha: glisse: are you aware of this problem: http://cgit.freedesktop.org/piglit/tree/tests/bugs/r300-readcache.c
nha: glisse: oldschool code had a workaround by simply reading from an arbitrary place in the framebuffer before anything software-fallback-related was done
nha: apparently, this workaround has disappeared with KMS
agd5f: nha: I think you can also force a hdp read cache flush by hitting one of the hdp regs
glisse: agd5f: yup there is a flush bit in host_path_cntl
agd5f: bit 27 of HOST_PATH_CNTL
nha: that might be the saner solution :)
glisse: we need to flush on setdomain cpu
glisse: but we also need to make userspace call setdomaincpu when accessing with the cpu
nha: it's quite possible that the old userspace used the somewhat weird workaround because you can't write to registers from userspace
suokko: glisse: I have via agp with r200 so that combination works too
bridgman: just checking, are you talking about flushing to vram or system ram ?
glisse: bridgman: more about invalidating the host path cache
bridgman: so vram ?
agd5f: bridgman: cpu access to vram
bridgman: ok, that one's more straightforward
bridgman: maybe a dumb question, how does agp gart driver fit into that ?
bridgman: or did the subject change and I missed it ?
agd5f: bridgman: it doesn't
glisse: subjected changed _
bridgman: ah... well, carry on ;)
MrCooper: airlied: FYI your DRM cache flush consolidation patch breaks the powerpc build
MrCooper: anyway off for tonight, bbl
wiwar: Hello, how to setup gentoo for card "ATI Technology Inc Device 9443" in lspci ? When I run startx it gives me "(EE) No devices detected"...
agd5f: wiwar: you may need a newer version of the driver
wiwar: agd5f: I build kernel module from 2.6.30-gentoo-r1. I found a blog post which says, that this is enough - http://ubuntuforums.org/archive/index.php/t-1012451.html
wiwar: sorry - http://my.opera.com/Sterkrig/blog/2009/03/28/gentoo-drm-radeon-radeonhd-ati-r6xx-r7xx
wiwar: quote from the post: "if you're running kernel 2.6.30 and later. Just compile DRM-modules and have fun."
wiwar: Is it true or not?
agd5f: wiwar: you need a newer radeon ddx. not part of the kernel
agd5f: if you are using fglrx, I'm not sure wha the problem is
wiwar: agd5f: I am trying not to use fglrx, because i have x86_64 system, but as far as I understand, fglrx requires 32-bit components (which is inappropriate for my religion)
agd5f: wiwar: ok. then, if the radeon driver doesn't find your chip you need a newer version of the radeon driver
wiwar: http://wiki.x.org/wiki/radeon:r6xx_r7xx_branch - this page says "The driver is supported automatically in Linux kernel 2.6.30 and newer, in which case the instructions on this page are not needed.". Which version do i need and how to install it?
agd5f: wiwar: your distro may provide updated packages, if not, http://www.botchco.com/agd5f/?page_id=2
wiwar: How to obtain version of an already installed driver ?
bridgman: easiest is probably to look in the xorg log
osiris_: agd5f or bridgman: chapter 6.5.2 of r500 accel guide says that setting too low num_cntlrs and num_slots is permitted, but what about too high values? e.g. will setting num_cntrls too high result in vector engines overwriting each others memory?
stuckey: Is there any tool to measure the tempetature of a x1300?
agd5f: osiris_: I think so. bad rendering IIRC
wiwar: I compiled xf86-video-ati from git and able to use "radeon" driver. What I need to do to use "radeonhd"? If I just change xorg.config - driver not found...
suokko: wiwar: correct driver should be autodetected so you don't have to set it
chithead: wiwar: for radeonhd, you need to compile xf86-video-radeonhd
michat: Please radeon's what is the version of r000 for hd4870x2?
michat: Thanks chithead for you Knoleg, how about r700 for gnu/linux no drivers for?
mcgreg: R770 even
mcgreg: I suppose it should work wirk "radeon" just no 3d yet
chithead: michat: your card is supported by the open source drivers (2d and video acceleration) and the proprietary fglrx driver (3d acceleration too)
michat: thank mcgreg latest i think r770, anybody has hd4870x2 on Gnu linux
chithead: you will find some people in phoronix forums which have 4850x2 and 4870x2, however they often don't seem very happy
michat: Chithead I know fglrx propietary , I get blank screen, I will check open source
mcgreg: yes, your 4870x2 will work fine but NO 3d. with current kernel (2.6.30) you will have video and 2d acceleration
michat: I have great performances in windows, macgreg and chithead. roger your last tx thanks for you help. I give you a screenshoot
michat: http://www.dcascreenshots.net/dcaforum/viewtopic.php?f=23&t=10539 thanks for you help radeons, could you telm me about 4550, do you know what is the most stable for GNU/linux
chithead: at the moment the best supported cards with open source drivers are r500 (x1300/x1600/x1900 series)
chithead: anything newer only has 2d/video acceleration, although this is expected to change in an ubuntu release or two
michat: roger that chithead famous r500 I see in many places, now I know more, tahnks for helping
michat: hope you like screenshoot I just going over.. tk
mcgreg: chithead: sry , do you understand the link he ppsted?
mcgreg: hmm almost if this is a cheap try to show some advertising .. dunno . strange
froggles: im using the free radeon driver. my card is supported.
froggles: quake wars doesent start, but i can play DVD.
froggles: im assuming im lacking 3D Acceleration ?
chithead: glxinfo will tell
froggles: well i have the radeon module loaded, glxinfo says Error: unable to open display
froggles: what program conifigures xorg.conf
suokko: Do you have right to access /dev/video0?
suokko: (Your user might need to be in group video)
froggles: in Debian ?
froggles: there is a video group
soreau: froggles: You are running glxinfo from within an x session, yes?
froggles: i rand glxinfo form the Konsole
soreau: I'm not part of the video group here and 3D works fine
froggles: i am in the video group
soreau: Why are you running as root?
soreau: more specifically, running glxinfo as root
froggles: im not on the laptop im trying to fix
froggles: direct rendering: No (if you want to find out why, try setting LIBGL_DEBUG=verbose) <--- as my user
soreau: froggles: Can you pastebin the X log?
soreau: And why are you loading the radeon module manually?
froggles: soreau: yeah i modprobed it
froggles: im going to reboot
froggles: do you want to see my xorg.conf ?
froggles: well i rebooted, and the radon kernel module didn't automatically load. i guess i'll have to modprobe it manually
agd5f: froggles: the ddx will load the drm automatically
froggles: the drm didn't load manually. whats the ddx
froggles: err i mean i loaded it manually
soreau: Is that the latest version of X debian has packaged?
froggles: drm and radeon only load when i run modprobe radeon
soreau: And it is an x3100?
froggles: i'll show you my lspci
agd5f: froggles: the radeon xorg driver is the ddx
froggles: how do i get 3D Acceleration
soreau: I would recommend upgrading X to at least 1.5
soreau: that card is pretty new afaict
suokko: I think fglrx is only one providing 3D support for HD 3100
suokko: (Unless experimental r600 support in mesa can be counted)
froggles: how do i upgrade x ?
soreau: very carefully
soreau: froggles: I believe suokko is correct in that r6xx aren't quite supported for 3D acceleration yet
suokko: froggles: Probably the easiest solution would be upgrading to debian testing
suokko: But if you want to use fglrx debian stable is best for it.
froggles: no fglrx is preventing me form compiling my kernel
suokko: fglrx is binary driver from amd/ati
froggles: testing? i don't want faulty software
chithead: fglrx does not support kernel >=2.6.29, some unofficial patches exist though
|niko|: join #rockbox
suokko: froggles: debian testing=squeeze. That means quite a stable system in fact
soreau: Yea, I wouldn't worry with some 'testing' label. Should work just fine
suokko: Debian testing gets all the testing from Ubuntu users ;)
chithead: squeeze is not that far removed from lenny still
suokko: froggles: http://www.phoronix.com/forums/showthread.php?t=17603 There is some conversation about how to get 3D acceleration to work with newer ati cards
froggles: thanx pal.
froggles: i may just try out testing.
lesshaste: what is the status of 3d support in radeon?
lesshaste: specifically the rs480
lesshaste: for the
soreau: Wasn't that the card airlied was considering incinerating? ;)
lesshaste: he told me to go away :)
lesshaste: so I came here :)
airlied: lesshaste: no I'm here as well :)
lesshaste: airlied: aha :)
airlied: lesshaste: but it should work with most distros
lesshaste: so. what is the status of 3d acceleration?
lesshaste: I am going for it in any case...
lesshaste: I see "# 2D: accelerated (EXA), stable
lesshaste: XVideo: accelerated and tear free, stable
lesshaste: # 3D: accelerated, stable " which at least looks promising
lesshaste: but I find the numbering mysterious
lesshaste: is the rs480 an r400 class chip?
airlied: lesshaste: it should jus twork, with any modern distro (except maybe F11)
lesshaste: airlied: ok.. I am upgrading from intrepid to jaunty
lesshaste: so it is warning me
lesshaste: in fact I am not upgrading as I now discover it needs 2.2GB in the / partition free :)
lesshaste: time to go to bed I think
lesshaste: thanks all
airlied: agd5f: so
airlied: I get to install fglrx on my rs690 then :-)
bridgman: I can read it now
bridgman: top open source programmer gives in to the dark side
airlied: bridgman: grep -r __GFP_DMA32 :-)
bridgman: "we'll never write a driver that good", says Aussie developer
bridgman: or that...
chithead: fglrx dropped support for rs690 and rs740, didn't it?
airlied: still has his F8 + fglrx disk somewhere.
airlied: the old version still support the hw just fine
airlied: whiny users wanting to run new distros on old hw.
chithead: which is kind of confusing due to rs740 being marketed as "radeon 2100" yet current fglrx not working with it
scarabeus: chithead: yup they should not support it
scarabeus: but up to the 9.3 it should work :]
agd5f: airlied: I take it the PT format doesn't work for 40 bit addresses?
airlied: agd5f: doesn't appear to with my testing so far
airlied: I'm not discounting stupidity on my end yet
spstarr: turns on quad core box
airlied: agd5f: btw are those read/write bits different order to the PCIE table?
airlied: granted I don't think its the snoop bit killing me herer
airlied: woot my DDX runs my sessions again
Veerappan: agd5f, thanks for the Xv fix commited to git earlier. It's working like a charm on my x300.
agd5f: airlied: success?
agd5f: airlied: looks like the only difference between PCIE gart and IGP gart is the address low and high field order.
airlied: agd5f: not with rs690 :( yeah it all looks the same otherwise from what I can see
airlied: I'm just cleaning up the DDX so it got a chance of merging to master and not looking like ass
DanaG: Hello again.
DanaG: Any of you figure out why the "benchmark" plugin makes Compiz work so much more smoothly on RV200?
soreau: DanaG: Benchmark runs some glx frame update command every frame so it seems to kick the card into high gear. Do you know if your card has any kind of power saving 'feature'?
DanaG: This one is a desktop Radeon 7500... I don't believe that one has power-saving features.
soreau: I guess you could make your own clone of the benchmark plugin attempting to isolate whatever it's doing exactly, not sure what else to tell you really though
DanaG: oh yeah, and I also get this odd high CPU usage by Xorg, just drawing the desktop.
DanaG: hmm, how would I figure out what's causing that issue?
DanaG: hmm, would having page-flipping enabled do that?
DanaG: Should I try using XAA, perhaps?
DanaG: It's currently set to EXA.