bridgman: time for sleep; good night, morning, whatever ;)
MostAwesomeDude: bridgman: Good whatever. :3
rmh3093: airlied, ping
airlied: rmh3093: pong
rmh3093: so im trying to figure out why xorg 1.5 does not work with -rc5-mm3
rmh3093: i think i have tracked it down the lockless patches
rmh3093: which adds get_user_pages_fast
rmh3093: but i dont see get_user_pages in xorg anywhere
rmh3093: only in libdrm
rmh3093: and i tried making a patch to change it in the ttm code
rmh3093: but it still acts the same
rmh3093: is there a way to disable ttm
rmh3093: or do you have any ideas where else I could look for memory/page related code that -mm could have broken
airlied: rmh3093: ttm doesn't get used on radeon
airlied: rmh3093: so it won't be any of those paths.
rmh3093: hmm
airlied: whats the failure case?
Nightwulf|work: hi all
rmh3093: well X starts to start, but it stays at a black screen
rmh3093: and i cant switch back to another tty
airlied: rmh3093: have you got a latest pciacess?
rmh3093: and when i ctrl+alt+del the caps lock light starts to flash
airlied: rmh3093: hmm so it hasn't oopsed until you try and reboot
airlied: I'm not sure if thats a bug we fixed already, or if its a new bug in -mm trees.
rmh3093: well i cant check dmesg
rmh3093: well i took the lockless/get_user_pages_fast patches from -mm and applied them to the vanilla kernel and the same thing happens
airlied: does it work with DRI off?
airlied: rmh3093: oh interesting.
rmh3093: i havent tried it with dri off w/ radeon
rmh3093: but
rmh3093: on my other box
rmh3093: i used nv
rmh3093: and same thing happened
rmh3093: and i dont think nv uses dri
Nightwulf|work: it doesn't....it uses its own module
airlied: nv doesn't even touch the kernel..
airlied: rmh3093: so its just a bug in those patches, mail lkml and cc Nick Piggin.
airlied: I see a few people giving out about lockless causing problems
rmh3093: yeah lockless is a pita
rmh3093: which xorg commit added swrast_dri support?
MGrunde: Should I be using radeon or radeonhd with my ATI Radeon HD 3200?
dmb: so radeonhd is going to be using atombios now?
libv: dmb: we've always used some parts of atombios
libv: dmb: it's been requested by our technology partner, to lessen the burden on them with respect to providing deteregister specifications
dmb: oh
agd5f: libv, dmb: we don't have any detailed programming guides for the display engine, since we use atombios for everything internally. We will still be providing register specs, but just don't have the programming guides. If we had programming guides we'd release them
MGrunde: If anyone could look at my xorg.conf, I'd really appreciate it. It's not working, and I'm not sure what I've done wrong. It's at http://pastebin.com/d233cc1fe
eboettcher: agd5f: were there big changes for atombios on r700 at all?
agd5f: eboettcher: no, not really
agd5f: eboettcher: it just works on rv770
dmb: agd5f, oh
dmb: now, the question is, there is going to be 2 drivers doing very simular things, radeonhd and radeon
libv: dmb: this has pretty much been the situation since november
dmb: well, competition is good
dmb: shuts his mouth and goes to work
libv: depends.
fellacious: i just installed radeonhd per instructions on http://www.phoronix.com/forums/showthread.php?s=4265cc043182144fadeac3850413970d&t=9951
fellacious: and dri doesn't work. also, LIBGL_DEBUG glxinfo doesn't say anything more than just glxinfo
yangman: fellacious: please look at the URL in topic
MGrunde: I just ran autogen.sh and it chose not enable DRI support, is that because I'm missing some dev files or because my card doesn't support it yet?
Nille02: who d2kx
fjk98: hi, is it possible to get 2560x1600?
Saist: probably, yes
fjk98: what do I have to do?
Saist: you'd more than likely have to set the resolution manually in the x.org config file
mattst88: If both drivers are going to use atom bios in the near future, then what's the point in having two separate drivers?
mattst88: seems like unnecessary duplication of effort.
mattst88: especially if that effort involves copying code from one driver to the other.
bridgman: mattst88: we don't want two driver ;)
bridgman: drivers
mattst88: how the heck did you see my message if you just joined?
bridgman: I was browsing backlog
mattst88: lmao
bridgman: despite what MostAwesomeDude tells you, I don't read minds and I don't have
mattst88: so is there significant pressure to merge the drivers?
bridgman: alarms hooked up to IRC ;)
bridgman: it just makes sense if we can do it
bridgman: it takes time though
dmb: i wonder what its going to be, radeonhd sucks in radeon, or radeon sucks in radeonhd
bridgman: and if we're going to get to "one" we have to go through "two very similar" first
bridgman: not so simple; you have to think about kernel modesetting sucking in stuff too ;)
mattst88: I don't see why the three radeonhd developers don't dump radeonhd and begin working on radeon.
dmb: well, now is probably the time to merge before modesetting gets set
dmb: radeonhd works better on my card then radeon, for modesetting
mattst88: seems like a radeon bug that needs to be fixed to me, rather than a reason to keep radeonhd around :)
dmb: well, could say the same about radeon
bridgman: I'm still tempted to start a third driver and not look back ;)
dmb: just start a third driver that combines both efforts
bridgman: radeon-fusion or something
bridgman: that's kinda what we're trying to do in radeonhd
bridgman: try the quick & dirty 2d branch; fresh radeon accel code over radeonhd modesetting
bridgman: add in atombios support and should be a nice driver
mattst88: dmb, your problem pales in comparison to the amount of work it would require to get 2D acceleration in radeonhd to the point it is in a radeon
bridgman: yep, hence the quick & dirty 2d branch ;)
mattst88: bridgman, again, why spend time on that? Why not have the three rhd developers begin working on radeon
bridgman: there's a long story and a short story, and I don't feel like telling the long story ;)
bridgman: short story is that there are some things in radeonhd which are nice too, the
bridgman: challenge is picking the best from both and getting everyone comfortable
dmb: like mc stuff :D
bridgman: with the merge
bridgman: mc ?
mattst88: politics, philosophy, and developers with bad attitudes is the gist of the long story?
dmb: the change to vt really really fast thing
bridgman: I prefer to say "taking time to fully understand the driver requirements and
bridgman: developer professional beliefs"
bridgman: but what the heck, it's open source and in the end it's gonna be great !!
bridgman: seriously, part of the problem here was that I was new to the open source
mattst88: how so?
bridgman: world and didn't know all the swamps and mineshafts
mattst88: so if you had it to do over again, what would you do differently?
bridgman: mostly ask more questions
bridgman: there were possible interpretations of my project plan which I never imagined possible ;)
mattst88: would you have pushed for the novell developers working on radeon instead of a new driver?
mattst88: if you had it to do over, that is.
bridgman: in hindsight probably; the thing we all missed at first was how much of the
bridgman: acceleration code would be immmediately useful on 5xx
dmb: in many ways, the radeon driver seems to have existed for quite some time
bridgman: that said at the time even the radeon devs agreed the code was old
bridgman: problem was that the randr work in radeon resulted in all new code there
bridgman: as well
dmb: it would be nice if r6xx was the chipset that started the new driver instead of r5xx and r6xx
bridgman: that's kinda what we're thinking; we really need all the same code in radeon and radeonhd
bridgman: unless radeon handles up to 5xx
dmb: yeh, that sounds like a logical plan
bridgman: problem was that at the time we didn't know how well atombios would work; it seemed
mattst88: bridgman, what is your official position title at AMD?
bridgman: like a good idea but I was figuring two months to get the driver fully working
bridgman: I'm one of the architects in the GPG software group
bridgman: dave and alex took two weeks
bridgman: anyways, I think we're oozing towards a single code base now (crosses fingers)
dmb: its going to be hard :/
bridgman: yep, it will take time and lots of beer
mattst88: dmb, why do you think that?
dmb: mattst88, developers have put a lot of time and effort into both drivers
dmb: no one wants to be throwing away any of their code
bridgman: that's where the time comes in
bridgman: but if you think about kernel modesetting at the same time this all gets easier
bridgman: nothing goes away
dmb: well, either we use radeon's modesetting or radeonhd's
bridgman: or the kernel's modesetting via a ddx driver passing the requests through
bridgman: and we gradually lurch from one to the other over the next year or two
bridgman: we are coming into a really big, drawn out transition unless the last two years
bridgman: of work in the entire x community gets backported to... everything
bridgman: you're going to see all of these implementations have homes where they fit ideally
dmb: oh
bridgman: it's going to be really hard to explain to anyone; good news is that the distros will
bridgman: take care of most of it; only scary thing is that distros don't like to ship new
bridgman: x servers, and dri2 is forcing server upgrades to use new-ish driver code
dmb: yeh
bridgman: and the new GPUs keep showing up in the market
bridgman: I see backporting hell no matter what we do
bridgman: radeonhd supports the pre-randr servers pretty well AFAIK and for some distros
bridgman: that will be important for quite a while; SuSE being one of them
dmb: yes
bridgman: bottom line is that only the distros are going to be able to keep average users
bridgman: happy, and when we try to keep all the distros happy the requirements become
bridgman: a lot more clear -- and that helps cut through all the other issues
bridgman: but fingers remain crossed ;)
bridgman: that's another thing I would do different; last time the distros were so happy
bridgman: we were doing this that the details didn't matter; if I were doing it again
bridgman: I would have collected requirements & priorities from the major distros;
bridgman: every day I'm surprised by different some of the distro decisions were considering
bridgman: they're trying to support the same market
dmb: yes
dmb: its intimidating
bridgman: yeah; I can't help thinking that Linux would move faster if there was a bit
dmb: i kind of go by the 'let distros deal with it them self'
bridgman: more focus on common infrastructure and a bit less focus on distro-specific
bridgman: stuff; depends on whether you think your competitor is MS/Apple or other distros
bridgman: that's the biggest value of open source IMO; gives the distros a chance to
bridgman: make everything work together nicely
bridgman: but not all distros have the driver devs to make that happen
dmb: if i were amd with fglrx, i wouldn't worry about a installer generating packages for all the distros
dmb: and let the distros generate the packages them self
bridgman: problem is that all the distros require different installation or the driver borks
bridgman: and if the driver borks people think we suck not the distro
dmb: that is a big issue in the linux world, upstream vs distro
bridgman: yep, and as always honest men differ on what is best
dmb: for example, when someone finds a bug, should they be reporting it to the distro or the upstream?
dmb: i think the distro
dmb: but others disagree
bridgman: if you have a support contract distro; if not upstream cc: distro
dmb: i think it should be the distro that contact upstream with any issues, not the other way around
bridgman: it's not clear to me that we need 11,256 different bug tracking systems either
bridgman: but that's just me ;)
dmb: and source management systems
bridgman: problem is that "upstream" is mostly an aggregation of distro employees these days
bridgman: and don't get me started on package management ;)
dmb: well, in many ways, linux is still mature
dmb: as time progresses, things become more unified
dmb: 'survival of the fittest'
dmb: sorry, i mean immature*
bridgman: problem is that there are still conflicting views of what Linux is "all about"
bridgman: just look at the debate on binary drivers; everyone agrees there need to be
bridgman: open source drivers if only to make sure you can debug properly
bridgman: but one camp says "use binary drivers at your own risk; support open source drivers"
bridgman: and other says "we must prevent use of binary drivers to protect users"
bridgman: that's the big glass wall Linux is bouncing off right now
dmb: there are lots of stubborn people in the linux world as you can see
bridgman: not binary drivers specifically but the strongly conflicting views about "essence of Linux"
bridgman: yep, but that's not unusual when you get a bunch of smart people together
bridgman: problem is they don't all agree on why they're here ;)
dmb: that is an issue
dmb: but thats going to happen with all open source software
bridgman: I guess it's the "Linux is the Chosen Vehicle for delivering Holy Open Source"
bridgman: vs "Linux is the best damn operating system out there"
dmb: lots of people, from diff companies, different countries all have there own ideas
bridgman: there's an article in this month's Atlantic about "the Sorting of America", where
bridgman: like minded people are tending to live in the same area and not talk to people
bridgman: who hold opposing views
bridgman: so you get landslide elections for one party or the other rather than a good fight
dmb: yeh
bridgman: but when you add up the numbers it's still a wash, and the best man/woman typically
bridgman: didn't win
bridgman: it seems to be like that in open source world; people with strongly held, well founded
bridgman: beliefs don't talk enough to find the common ground
dmb: which is what results in millions of forks and/or distros
dmb: one project that has done it right though was firefox
bridgman: yep, and MacOS and Solaris
dmb: mozilla
bridgman: agreed; do you think that was better organization or tons of money poured in
bridgman: back in the Netscape days ?
dmb: not quite sure, but a lot of mozilla was corporate backed
bridgman: didn't know that
dmb: google is paying them lots of money right now
bridgman: nothing brings focus like a guy holding a bag of money and not letting go yet
bridgman: didn't know that either ;)
dmb: also, mozilla is a mature project
yangman: Firefox was multi-platform from the beginning. I think that helped
dmb: it has existed for quite a long time, and had evolved many times
yangman: and, the strictly "free software" guys still managed to muddle it up
bridgman: getting in early counts for a lot; if you're big enough or well recognized enough
yangman: see: Ice Weasle
bridgman: then web sites change to support you; otherwise you have to change to work with
bridgman: all the web sites
yangman: afaik, Debian's the only distro hell-bent on remaining completely free
bridgman: isn't iceweasel derived from firefox somehow ?
dmb: well, distros in the beginning were hardly free
yangman: it's not derived
yangman: it _is_ firefox
dmb: motif was the main linux toolkit i believe at some point
dmb: for x
yangman: Debian didn't like the fact that the name and logo are trademarked
yangman: basically, --with-branding=no at configure time
dmb: yangman, thats the short version of it :D
bridgman: trademarked you say, how evil (sorry I work for a big company ;))
bridgman: wow...
dmb: we all probably work at big companies :D
yangman: I work at a tiny company :p
bridgman: well if you work hard it will be a big company one day :D
dmb: they both have their advantages
bridgman: I like small companies; but big companies can do bigger things
bridgman: and I like doing big things
bridgman: ok, I see; the issue with iceweasel was that debian wanted to modify it but
yangman: I like the freedom I have in small companies
bridgman: still call it firefox; mozilla folks asked them to stop
bridgman: yangman: agreed; anything a small company *can* do is usually much better done
dmb: well, basically, thats the upstream vs distro thing
bridgman: in a small company and more fun for everyone as well
dmb: mozilla didn't want to get loads of support requests, and/or ruin there reputation for something debian changed
bridgman: that's fair, isn't it ?
yangman: yup. totally fair
bridgman: what went wrong ?
dmb: its like openssl telling debian not to use the openssl branding :D
yangman: debian wanted to do things its way, basically
dmb: the debian f* up messed up the openssl name
yangman: they're really patch-happy, or so I hear
dmb: yangman, i like to think iceweasle as a diff browser
dmb: because it is
yangman: there was the whole OpenSSL vulnerability due to debian's patching from a month back
dmb: the thing is, linux is bad for the end user
dmb: i have yet to find someone that is into linux, that has only used one linux distro
yangman: well, depends on the reason
yangman: I've basically never switched away from Gentoo :p
dmb: i used to be a big gentoo user
yangman: tried a few. none were good enough for what I wanted to do
dmb: but when i wanted to get into development, they were not very nice people
yangman: some nearly drove me insane
yangman: yeah, gentoo devs seems to be hit or miss...
dmb: that lead me to move to a different distro, because i want to give back
yangman: there's a few good ones, and then there's the ones that make you want to give up
bridgman: and presumably the good and bad change places every so often ?
dmb: yes
yangman: I basically gave up. if a version bump takes longer than a week, I roll my own ebuild
dmb: qaing is way to difficult with a gentoo-style distro
bridgman: is the issue that there are too many good developers and too few good diplomats and leaders ?
dmb: that really varries from project to project
yangman: yeah
bridgman: makes sense
bridgman: are there distros today which seem to have good leadership & everyone getting along ?
yangman: for me, the issue is that the few key players in charge of really important projects are either really slow or ass-hatish
dmb: i think the best thing to do right now is to right up standards for linux
yangman: can you believe we *still* haven't stabilized python-2.5?
bridgman: that's the part I don't understand; I don't see any unified plan other than at
bridgman: an individual component level, and even the conferences & mailing lists don't seem
bridgman: to be organized to bring everything together
dmb: there was lsb, but i don't think that is going too well
bridgman: lsb ?
dmb: linux standard base
bridgman: off to google ;)
dmb: if you really think about it, each distro is its own os
bridgman: bingo
yangman: LSB is... silly
dmb: someone should trademark some universal name, and have that name be passed on to compatible oses
bridgman: looks like it is trying to unify the "top" of Linux (application interface) but
dmb: like anything that follows the standard can be called linux
bridgman: that doesn't seem like the problem; it's the "bottom" (packages, drivers, frameworks)
dmb: anything not, can be called some other os
bridgman: where all the pain and inconsistency is happening
bridgman: how many of the distros are commercial entities vs pure volunteer efforts ?
yangman: well, at least Freedesktop is doing a pretty good job standarizing desktop components
dmb: as time passes, from what i observe, distros are getting more similar as time goes by
dmb: they all default to either gnome or kde as a desktop env
yangman: RedHat, Suse, Ubuntu vs everyone else?
yangman: I guess there's Linspire
yangman: but no one really cares about Linspire ;)
dmb: just got bought out i think
yangman: yeah
dmb: the successful distros are all corporate backed
dmb: which shows that a distro need corporate support for it to be successful
yangman: Debian was a big player until Ubuntu showed up
bridgman: Ubuntu still depends pretty heavily on Debian, doesn't it ?
bridgman: or has it kinda taken on a life of its own
dmb: yes, it does
dmb: ubuntu pulls upstream debian every release cycle
mattst88: gentoo isn't corporate, and I'd define it as quite successful
rbrett: bridgman: I don't see why radeon and radeonhd can't coexist. with radeon supporting r300-r500 and radeonhd supporting r500+
rbrett: bridgman: With both supporting r500 because it's difficult to draw the line
mattst88: r600 is a pretty easy line to draw.
bridgman: rbrett: I would say "with both supporting r500 because they already do" but yeah
dmb: that might work
bridgman: I have a slide I need to post up on www.x.org that shows how all the blocks evolve
bridgman: across GPU generations
bridgman: if you look at the top block 5xx is the obvious split (new display controller)
rbrett: r500 doesn't quite fit perfectly into radeon or radeonhd, and if support for r500 should be dropped it should be from radeonhd
bridgman: but if you look at the rest of the blocks 6xx makes more sense
rbrett: yeah
rbrett: keeping the radeon and radeonhd separate may also help with the "philosophical" issues.
dmb: code duplication is not a good thing
rbrett: I don't see where the duplication is? radeon and radeonhd both use the same radeon drm right?
bridgman: keeping them separate was a good short term solution but not long term
bridgman: rbrett: the duplicated areas are modesetting, 2d and video acceleration
bridgman: the acceleration relies on drm (at least for best performance) but the bulk
bridgman: of the accel code is in the X driver (radeon, radeonhd)
bridgman: drm and 3d acceleration are common
rbrett: which, correct me if I'm wrong, seem quite trivial, and with the r600+ not even including 2d acceleration anymore...
bridgman: problem is that the 2d acceleration code still has to be in the X driver even if
bridgman: there is no 2d engine, so you end up with a big heap of 3d engine code duplicated
rbrett: plus hdmi, displayport won't be features of r300-r500?
bridgman: same for Xv; it's all done on the 3d engine these days but is still
bridgman: in the x driver
bridgman: hdmi yes, displayport no
bridgman: if you just look at 5xx and up, maybe 60% of the code is duplicated
bridgman: 80% if you use atombios for modesetting
rbrett: but that duplicated 3d engine code for 2d would exist in radeon as well right?
bridgman: exactly
bridgman: same for video
rbrett: hmm... I think I'm beginning to see your way of thinking :P
bridgman: it's definitely tricky; depending on how you present it you can support
bridgman: pretty much any decision you want ;)
bridgman: MostAwesomeDude: you got a Name-ectomy
rbrett: I thought the 3d support would be the most significant, I did not think the 2d and video would be quite so...
bridgman: back when 2d was just XAA and Xv was just overlay it was exactly the way you
bridgman: picture it; add EXA (big, complex, 3d engine) and textured video (3d engine)
rbrett: I see
bridgman: making acceleration bigger, add atombios making modesetting smaller, you get
bridgman: a different picture
bridgman: but of course there are conflicting views (all with some validity) about
MostAwesomeDude: Whoo, lots of backlog.
bridgman: how important each of *these* changes are too, so you can legitimately
MostAwesomeDude: bridgman: I've decided that MAD|money is more accurate than MAD|work.\
bridgman: support a number of different views about how this should go
rbrett: well if we are to have one unified driver, a new code base seems like it will have short term problems but long term benefits
bridgman: MostAwesomeDude: we missed you; just kept typing until you showed up
bridgman: rbrett: yep, but as long as all (or at least most) of the devs are working
bridgman: on the common code base we should be able to get through the short term
bridgman: issues
dmb: we had some deep discussions :D
bridgman: solved most but not all of the problems of the open source world ;)
rbrett: yeah we pretty much sorted out all the driver problems by ourselves...
rbrett: :P
MostAwesomeDude: bridgman: Aw, that's sweet. Seriously, though, I remember that slide from FOSDEM videos, and I personally think that xf86-video-ati can still be useful for the r6xx/r7xx series.
MostAwesomeDude: Really, the big difference was where the modesetting was done, and how it was done, and if we get rid of that difference...
bridgman: MostAwesomeDude: take a look at the quick&dirty radeonhd branch; seem familiar ?
MostAwesomeDude: bridgman: Just a tiny bit. :3
bridgman: now look at the atombios support branch...
dmb: MostAwesomeDude, the thing is, it would be nice if that could be separated
rbrett: MostAwesomeDude: Wouldn't the radeon codebase benefit from a new start though, or at least overhaul?
MostAwesomeDude: bridgman: So I noticed that fglrx advertises OGL 2.1 on r5xx cards, but spec sheets say that r5xx are only OGL 2.0. Is there something I'm missing, or did you guys just happen to find that OGL 2.1 was workable on r5xx after you started making them?
bridgman: good question; my guess is that our marketing folks didn't know about 2.1 ;)
bridgman: 2.0 was "really good" ;)
MostAwesomeDude: dmb, rbrett: Kind of. TBH I really don't know/care much about modesetting, just whatever works. xf86-video-ati just looks like it can be ready for DRI/DRI2/ponies faster.
dmb: MostAwesomeDude, you seem more like a mesa guy :D
MostAwesomeDude: dmb: I resemble that remark. :3
bridgman: yep, he just needs to see the screen and have something light up the drm
dmb: we could always rewrite all of the drivers in asm :D
rbrett: I'm just a user, but as bridgman and others have said, x11-drv-radeon seems to have "some" rough spots
bridgman: I like assembler; everything I write in assembler works first time
bridgman: these newfangled languages piss me off
MostAwesomeDude: bridgman: I know what you mean. Stupid C++.
bridgman: I was thinking of C ;)
dmb: assembler is cool, unless you do ppc asm
dmb: or sparc asm
MostAwesomeDude: I've gotta go; I'll be back after I find my laptop charger. :3
bridgman: MostAwesomeDude: OpenGL 2.1 seems to correspond pretty well to DX9 in terms of chip
MostAwesomeDude: bridgman: Yeah. I plan to go as far as we can go.
bridgman: requirements so my guess is that 2.1 wasn't on the radar for whoever wrote the brochure
yangman: dmb: I hear ppc asm is much, much clearner than x86
dmb: yangman, i think i'm just used to x86
dmb: sparc definitly is the worst though
yangman: RISC is pretty awesome to write by hand
bridgman: I bet I would like PPC - grew up on S/370 assembler so probably not much
bridgman: different; I keep seeing the same instruction set show up in every generation
bridgman: of IBM processor
dmb: for some reason i like masm syntax better then gas syntax
mattst88: dmb, what's wrong with ppc/sparc assembly?
mattst88: I quite like alpha assembly, and I don't think it's terribly different from either of those.
bridgman: I think it just takes a lot of typing; if you start programming a RISC
bridgman: CPU you learn to type REALLY fast
mattst88: it definitely doesn't have the hacked-together thing going on like x86[-64]
dmb: mattst88, massive confusion
dmb: and too much thinking
mattst88: lmao
bridgman: I liked 68xxx but could never get comfortable with x86
mattst88: if you want the CPU doing the thinking, you shouldn't like assembly
bridgman: I want to wave my hand vaguely at what I want done
dmb: you have to carefully design asm programs also
bridgman: probably not assembly ?
dmb: better for engineers
mattst88: dmb, so from a technical aspect, you have no qualms with ppc/sparc assembly?
rbrett: bridgman: Just another thought before I go, If we unify radeon/radeonhd or start radeon-fusion, it should be gallium3d driver only
rbrett: or at least mainly gallium3d
yangman: so, back to radeon*: what's the difficulty with PowerPlay atm?
bridgman: rbrett: 3d is kind of orthogonal; they really just come together at drm
bridgman: until we have memory mgmt we can't really run gallium, so airlied is working
bridgman: on memory management while we get info and initial drivers out using classic mesa
bridgman: then hopefully both come together and gallium has settled down and then we
rbrett: seems though memory manager, for developer purposes at least isn't too much further away.
bridgman: switch over to gallium for everything else
bridgman: agreed; 1-2 months maybe
rbrett: I see
rbrett: time for me to go, thanks for the chat :)
bridgman: pleasure... see you later
bridgman: I should get going too... thanks for the interesting discussions