Home Phoronix Phoronix Forums X.Org Videos From FOSDEM 2008

Radeon IRC Logs For 2009-6-20

Search This Log:


phobeus: Hi, I am trying for a while to get the experimentell 3D support for a F11 system running a 2.6.29 kernel, mesa 7.5 (compiled with r600) support and a libdrm from the 6xx-7xx rewrite. /usr/lib/dri/r600_dri.so exist, however the x-server complaints about (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to software rendering ... I am running out of ideas, what exactly might prevent it from loading it. Any ideas?
nanonyme: Do you have new enough X driver, libdrm, kernel modules and compiled the Mesa against the newer libdrm?
stikonas: phobeys: you are using wrong drm: http://cgit.freedesktop.org/~agd5f/drm/
stikonas: phobeus: ^^, checkout r6xx-r7xx-3d branch
nanonyme: stikonas: Iirc a too old radeon driver can cause that.
phobeus: thanks for answers. drm shouldd be okay. I checkout using this http://wiki.x.org/wiki/radeonhd%3Aexperimental_3D. so it should work. x-server is 6.12.2 ... and mesa should be compiled against the new libdrm. Else I won't have a r600_dri.so, will i?
phobeus: Do I need to checkout r6xx-branch for mesa also? I thought I read that it went to master a week ago?
nanonyme: I'm not sure if a released version of ddx is enough, unsure if the r600 codepath call got in.
nanonyme: And Mesa r6xx-rewrite, yes.
nanonyme: Only older cards got rewrite merged to master afaik.
zhasha: the driver entry point doesn't have anything to do with the DDX with the exception of getting the name of the file
phobeus: just checked... indeed I am also using the r6xx-r7xx-support for mesa-
zhasha: X asks the DDX for the 3D driver name, that's it
nanonyme: Right.
phobeus: Is there any way to get more details for the reason, it is not able to load the dri? Maybe this might help to find a reason? Just a "driver entry point failed" doesn't help that much
zhasha: so unless the DDX is reporting something other than r600, you're good to go on that part
stikonas: nanonyme: does graphics (tux logo, or plymouth or any other program) work for you under radeondrmfb, I have some problems with it.
nanonyme: Right. He you're right. He left too much of xorg conf out for conclusions.
nanonyme: Er, log even.
nanonyme: Still asleep apparently.
nanonyme: (As in, the last so call before swrast should tell if ddx is new enough)
phobeus: sorry, ... how can I check what ddx actually is reporting. The driver identifies the card as an 0x9442, what seems rather okay
nanonyme: stikonas: I've only rv670 and ppc r300, still some time until I get to start playing with a useful KMS. :)
nanonyme: If it's trying to load r600_dri.so instead of r300_dri.so or whatever, it's fine. ^^
DanaG: oh yeah, last time I tried the xorg-edgers PPA livecd, it didn't have KMS for R600.
phobeus: I am actually not sure, how I can verify this ;) He doesn't say anything about what he actually tries to load. However, the r600_dri.so exist, so I think he should be able to load it... but definitly does not. I am not sure how to locate the orgin of this problem, cause I am not enough in it to say what components are actually involved at exactly that point.
nanonyme: Xorg log does say that.
nanonyme: Root of solution: get whole log, not snippets.
phobeus: Thats the log from the last startup http://www.floriansievert.de/linux/tmp/Xorg.0.log
DanaG: http://www.dapreview.net/p/content/content.php?content.348
DanaG: er
DanaG: wrong tab in pidgin.
nanonyme: Right, apparently more to find out before even noticing if ddx is right. What zhasha said then.
zhasha: nanonyme: LIBGL_DEBUG=verbose glxginfo >/dev/null should tell you what dri driver it's trying to load
zhasha: glxinfo*
nanonyme: Btw, the system needs to be started with KMS explicitly disabled and in runlevel 3 to make sure it won't try to load DRM and radeon modules automatically.
phobeus: Ah ... that's nice to know. libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so
phobeus: drmOpenDevice: node name is /dev/dri/card0
phobeus: drmOpenDevice: open result is 4, (OK)
phobeus: drmOpenByBusid: Searching for BusID pci:0000:01:00.0
phobeus: drmOpenDevice: node name is /dev/dri/card0
phobeus: drmOpenDevice: open result is 4, (OK)
phobeus: drmOpenByBusid: drmOpenMinor returns 4
phobeus: drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
phobeus: libGL error:
phobeus: r600DrmMap: drmMap(regs) failed
phobeus: libGL error: Calling driver entry point failedlibGL error: reverting to software direct rendering
phobeus: libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
phobeus: so looks like it works form that side as expected. Guess, it might be not a problem with mesa/dri/drm ... but with the driver then?
nanonyme: Driver is probably fine. As zhasha said, it only needs to pass the name and it's doing that, right?
phobeus: yes, that looks fine.
zhasha: what libdrm branch are you using?
phobeus: git://anongit.freedesktop.org/~agd5f/drm with branch r6xx-r7xx-3d
nanonyme: The system has a KMS-aware from package managent though.
nanonyme: So likely a hybrid between those two unless better separation was used than I managed to make. :)
zhasha: I have a feeling you need r600-rewrite
zhasha: (mesa branch)
nanonyme: He does, yes.
nanonyme: It's possible it won't compile as is though.
zhasha: why is that?
nanonyme: Because of the hybrid libdrm. :)
nanonyme: Configure detects libdrm-radeon, r6xx-r7xx-3d doesn't have all necessary symbols.
nanonyme: Can be circumvented by toggling detection of libdrm-radeon off from configure.ac.
phobeus: Moment, just to clearify ... I just checking my mesa build ... r6xx-r7xx-support != r600-rewrite? Then it might be really the problem. I am just using the support
zhasha: they're not the same, no
zhasha: nanonyme: good point. I don't see any libdrm-radeon in agd5f's tree
nanonyme: Yeah, r6xx-r7xx-support is deprecated.
nanonyme: zhasha: It's mostly a pkg-config file.
phobeus: Allright, that might give an idea, what went wrong. thanks so far!
zhasha: nanonyme: for r300 it's the entire cs library
nanonyme: An environment with r6xx-r7xx-3d should not have the file.
nanonyme: The file implies certain capabilities from the libdrm.
zhasha: not talking about the pkg-config file
zhasha: http://cgit.freedesktop.org/mesa/drm/tree/libdrm/radeon
nanonyme: Well, yeah...
zhasha: all these functions that expose cs to userspace, they're not there
nanonyme: I was mostly talking what you need to do.
nanonyme: The pkg-config test either has to be made to fail or result has to be overridden.
nanonyme: But yeah, the developed branch is r6xx-rewrite.
nanonyme: (of Mesa)
phobeus: okay, then I have something to work on. thanks for the pointing.
mcgreg: sry for the stupid question, but why can a application like wine crash X?
osiris_: mcgreg: wine is using indirect rendering, and dri driver for indirect rendering is loaded by X. so when wine manages somehow to crash the driver it also crashes X
osiris_: there could be also other reasons
mcgreg: and is this suposed to work like this?
mcgreg: I mean, I dont think it is acceptable that a application can crash X/x drivers
airlied: nanonyme: ppc r300 should mostly work with kms (might need to disable agp)
airlied: nanonyme: MrCooper has been working o nit
osiris_: mcgreg: I don't think we can do anything about it, besides fixing the bugs that causes crashes
mcgreg: hmmm ok.
nanonyme: airlied: Should I expect DRI2?
airlied: nanonyme: well KMS doesn't do anything else
airlied: glisse: RS690 inits okay if I limit to DMA32 pages :(
nanonyme: Right, then it didn't work properly. Will have to look into disabling agp on Tuesday.
glisse: airlied: hhhmm :*
airlied: might have to install fglrx :O
glisse: uint64 for add is enough but maybe i should use dma_addr ?
mcgreg: airlied: for fglrx please use #ati :P
glisse: also i will need to buy a null-modem to debug late_init when module built in
mcgreg: :)
nanonyme: What's the keyword, agpmode=0?
glisse: spend the afternoon on it yesterday and can't find what is the reason of failure
airlied: nanonyme: radeon.agpmode=-1
airlied: glisse: yeah I think dma_addr_t is safest
glisse: airlied: do you know if intel got problem when builtin ?
airlied: also for the mmio pointers we need to use resource_size_t
airlied: glisse: no I think it works okay as Linus runs it builtin
airlied: he doesn't do modules
glisse: :)
airlied: (not mmio pointer mmio base/size)
glisse: i hope he doesn't have radeon hw so he doesn't flame us ;)
airlied: not sure what GPU his G5 has :)
airlied: but I don't think he siwtches it on much
suokko: hmm. Why would PPC agp support be any more problematic that pci?
suokko: Anyway. My card works now very well in agp mode :) Fixing the vram size detection helped also for agp mode
airlied: suokko: because its AGP and AGP is always more problematic than pci
airlied: and apple agp bridges are more "special" in how broken they are
suokko: yeah. I noticed that same bug caused 2 times worse problems with agp in my system :)
osiris_: airlied: to test the kms on radeon, I should get 2.6.30 and merge for-linus branch, right?
airlied: osiris_: get linus tree and merge my tree :)
airlied: or get my tree
airlied: my drm-linus branch is now the latest patchsets
osiris_: airlied: what GPUs have been tested so far?
airlied: osiris_: I've booted it on everything I own at this point, rs690 is the only bad one I've hit so far
airlied: oh I'm sure my rs480 needs some work
airlied: also 4GB RAM is a sore point )
glisse: yeah i also pretty much use all gpu i had
glisse: except rs480
osiris_: I have rv535, rv380 and rs690
osiris_: will test on these during this weekend
nanonyme: airlied: Right, thanks. Will try that.
zhasha: airlied: it would be really nice if we could get some tiling under kms soon :/
airlied: zhasha: yeah the colortiling code just need porting on my laptop
airlied: but I'll get to features once it boots all my hw
airlied: I actually have most of the code written for the rawhide tree
airlied: so it shouldn't be that hard to port over
zhasha: so are we going auto-tiling? :D
zhasha: it's a pain in the arse to not have tiling under kms and thus be forced to reboot to play some simple games
airlied: thats the plan for colorbufers anyways
airlied: I doubt its missing tiling that makes it that much slower
airlied: we have some other overheads that would make a bigger difference
glisse: zhasha: tilling won't gives a big boost, at least i don't expect so
zhasha: what would you say is the source then?
glisse: too much small cs
glisse: too much useless bo movement
airlied: too much page alloc overhead
glisse: ttm always trying to put things in vram
airlied: glisse: where do we do that?
zhasha: I'm using the same 3d driver in both scenarios. the only difference is no dri2 and no kms
glisse: airlied: ttm pref list
airlied: glisse: oh I thought the gem layer specified actual domains
glisse: airlied: also userspace right now doesn't always set gtt as possible place
glisse: where it could be gtt
glisse: i want to do benchmark with setting gtt as prefered placement
glisse: see if it makes any difference
airlied: glisse: it should set GTT for any reads
airlied: I didn't want to do writes to GTT
airlied: because its not always reliable
glisse: on agp it's not :)
zhasha: another little thing, what are the plans for sync to vblank under kms?
airlied: zhasha: wait for DRI2 sync to vbl to work on Intel first
airlied: glisse: where do you convert GEM to TTM domains?
airlied: ah I see it
airlied: ah that code is a bit naive
glisse: yes :)
airlied: the code in rawhide is a lot better tested in a lot more scenarios
airlied: glisse: btw also when clearing gart entries you still | 0xc
airlied: so you end up with valid enties pointing at the zero paeg
airlied: which isn't very nice
zhasha: doesn't radeon-rewrite use ttm the same under KMS as non-KMS?
airlied: either use a dummy page or make them all invalid
airlied: zhasha: there is no TTM under non-kms
airlied: radeon has only two options, old world (DRI1/no-kms), newworld (TTM/DRI2/KMS)
zhasha: oh.. right...
zhasha: I'm just confusing myself, thinking I had all the memory manager requiring extensions to GL under ye olde non-kms
zhasha: man.. so much stuff that still needs a ton of work...
rah: how is it that the radeon code uses TTM but exposes a GEM API, but there is no TTM wrapper?
rah: why can't there be a generic TTM wrapper?
rah: and if there can, why isn't there? :)
airlied: there was a generic TTM API before
airlied: but it wasn't generic
airlied: the problem is GPU memory layout isn't really generic except for the really simple cases
airlied: like I want a buffer I can scanout and draw stuff to.
airlied: the other problem with the generic TTM API, is that it exposes all of the TTM internals to userspace
airlied: this makes it nearly impossible to change any of it
genady12lap: hey
genady12lap: can someone help me setting 1920x1080 with my radeon 7500?
AStorm: uhm
AStorm: it should be available
genady12lap: I know
AStorm: unless 7500 doesn't support it at all
AStorm: which I think is possible
genady12lap: works on windows
AStorm: mhm
AStorm: tried xrandr? what does it tell?
genady12lap: $ xrandr --output VGA-0 --mode 1920x1080
genady12lap: xrandr: cannot find mode 1920x1080
AStorm: here it's e.g.
AStorm: Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 1920
AStorm: Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 1920
AStorm: (whoops)
AStorm: just plain xrandr
AStorm: (but I'm running with 3850)
genady12lap: how can I force it?
AStorm: actually, pastebin the output
AStorm: then, pastebin /var/log/Xorg.0.log
genady12lap: http://ubuntu.pastebin.com/m14c70109
AStorm: it is probable that the monitor doesn't advertise the resolution
AStorm: now, /var/log/Xorg.0.log
genady12lap: http://pastebin.ca/1467625
AStorm: Option "NoDDC" "true" - did you set that? :P
genady12lap: yes
AStorm: what happens w/o it?
genady12lap: the same
AStorm: mhm
AStorm: #
AStorm: (II) RADEON(0): Adding Screen mode: 1920x1080
AStorm: so it is adding the mode
AStorm: do you happen to have Modes option in xorg.conf?
genady12lap: but how to set it?
AStorm: (in the screen section)
AStorm: if so, drop it
genady12lap: yes I added the 1920x1080
AStorm: or fix it
genady12lap: and what about Option "NoDDC" "true"?
genady12lap: AStorm, ?
AStorm: remove, and retest
AStorm: I don't know now if the monitor has invalid DDC info, because you disabled that
genady12lap: both?
genady12lap: ok
AStorm: I recommend disabling NoDDC and commenting out Modes
AStorm: let's see what the monitor advertises
genady12lap: ok ill be back soon
genady12lap: the monitor connected to vga-out of the laptop
genady12lap: bbs
AStorm: yeah, noticed
genady12lap: im back
genady12lap: AStorm, http://pastebin.com/m69469ff6
AStorm: modelines are correct
AStorm: hmm
AStorm: what does xrandr say now? does it list the mode?
genady12lap: the same
genady12lap: VGA-0 connected 1024x768+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
genady12lap: 1600x1200 60.0
genady12lap: ...
AStorm: hmm
AStorm: interesting
AStorm: sounds like the card says it can't do more... w/o more debug info, I say prod some actual dev here
genady12lap: :(
AStorm: maybe the driver doesn't register additional video modes at all... that'd be a major bug
genady12lap: what can I try?
AStorm: genady12lap, no idea myself, I'd have to check the code and have no time for that right now :-(
AStorm: grab some dev here - they're probably asleep or sth
genady12lap: Ok, Thanks
nanonyme: Usually bug reports or posting for help on the newsletter tend to be surefire ways to get their attention, I guess. ^^
AStorm: yeah
AStorm: I suspect it is a bug
nanonyme: (IRC is a bit tentative except for people who read the whole backlog when they come back, like bridgman ;)
AStorm: so do report it
AStorm: hm, I'm getting a funky X hang sometimes
AStorm: semi-reproducible
AStorm: now will check vs latest driver, as there are some PLL fixes (and I suspect it to be this)
AStorm: as in, X freezes
AStorm: but VT switch still works (vesafb)
AStorm: though... hm
AStorm: no, it's 100% not GPU-related
AStorm: or at least, not everything is dead, because mouse pointer still works
nanonyme: What's visible on screen during the hang?
nanonyme: As in, is there still an X session there or black screen? :)
AStorm: nanonyme, X session
AStorm: but hanged
AStorm: after vt switch, it doesn't redraw completely (only title bars)
AStorm: so, something fishy is on
AStorm: like it hangs on some specific drawing op
AStorm: doesn't consume 100% CPU
nanonyme: And this is without KMS?
AStorm: yes
AStorm: that's why I'm able to VT-switch, kill X session and it works
AStorm: hd3850 doesn't have kms yet, you know ;>
AStorm: I mean, r6xx
nanonyme: Oh, right. :) Missed that point of the description.
AStorm: the trigger here is usually Xarchiver
AStorm: as in, I haven't been able to trigger it w/ another app
AStorm: it's similar to the earlier hang that happened w/ XChat
AStorm: same result
AStorm: I thought that got fixed...
AStorm: but it might be that the same crash is still there, just less likely to happen
nanonyme: And none of this WIP 3D code is in use?
AStorm: no
AStorm: I'm running master branch of radeon driver
nanonyme: Interesting. :)
AStorm: it doesn't sound like a full-on GPU crash though
AStorm: probably some shader gets an infinite loop
AStorm: because *parts* of the screen redraw after vt switch
AStorm: to be exact, xfwm4 titlebars (with fonts)
AStorm: I probably could get a picture of the screen when it fails
nanonyme: Well, afaik VT switch to framebuffer should suspend the 3d engine (which is used for all accel) but I thought the codepath to resume it was mostly fine. Agh, I'm no main dev and I don't atm have access to a computer. Shouldn't guess, I guess...
AStorm: the codepath to resume is fine
AStorm: it works
nanonyme: Right.
AStorm: the trick is it doesn't restart the engine, so it's still hanged
AStorm: but parts of the screen redraw (different thread/shader?)
suokko: Quite expenive cash flush in agp mode: http://pastebin.com/m6e253e2c (glxgears running only at 180 fps, PCI mode makes it 800fps)
suokko: cache flush :)
nanonyme: AStorm: Right, got it.
nanonyme: (that is, not the answer but the scenario)
AStorm: now, I don't know which shader fails - any way I could find out?
AStorm: some special option to dump state on vt switch or sth
AStorm: or on some other action
mimikry: how far is 3D support for R600? :)
AStorm: as in, time? far enough.
chithead: see channel topic
AStorm: now, all the work is on KMS I think
mimikry: yeah, i know it's not completely ready yet. but thanks for answer :)
AStorm: (I'd prefer that working, need the "WIP" memory manager written for r6/7xx
AStorm: but not really nagging the devs)
nanonyme: 'Small step for the end-user, a giant leap for the developer community'? :3
nanonyme: AStorm: Not really, there are afaik some paid AMD/ATi guys working on the r6xx-rewrite and so. :)
nanonyme: Just takes a little time.
AStorm: yeah, I've lost the repo link, again
AStorm: do you have it?
nanonyme: ("little" being a quantifies determined by difficulty of the coding)
nanonyme: Quantifier even.
nanonyme: It's a branch in fdo Mesa.
nanonyme: Just google for "git mesa".
AStorm: ah, right
AStorm: anyway, the brokenness is unrelated to 3d or xv
AStorm: I'll check if enabling composite circumvents the bug
AStorm: looks like it does
AStorm: oh, WAIT WAIT.
AStorm: the bug is 100% not in radeon, but in the stupid xarchiver
AStorm: this broken piece of software hangs the X server on stdin or sth
nanonyme: Oh?
AStorm: if a password is missing
nanonyme: Hope they have a bug tracker then. =^_^=
AStorm: ok, so 100% not radeon bug
AStorm: still, why would X server hang if someone hijacks the stdin?
AStorm: bonus, as I actually can't write to that stdin
AStorm: (yes, tried vt switch)
AStorm: how would an app hang an X server
AStorm: if I run it in a terminal, it works...
AStorm: (actually, hangs, but not the whole X server)
AStorm: (waits on terminal input
nanonyme: Maybe it gets the X server's stdin and blocks on it?
AStorm: how would it get an already open stdin?
AStorm: uh, no
AStorm: X server should close its stdin
nanonyme: Then X server would end up having to wait until it stops blocking if it wants to use its stdin.
AStorm: still, why would X server block then?
AStorm: why X server would use stdin?
AStorm: does it read anything or what?
nanonyme: No idea, that's just the only stdin-related hang that came to mind. :p
AStorm: I'll ask on #xorg
nanonyme: Blocking on filehandles isn't always neat with shared filehandles.
nanonyme: Yeah, good idea.
XenoPL: Hi all, is font corruption after playing with xrand rotate known issue?
XenoPL: I'm on F11 with latest radeon bits (kernel-PAE-2.6.29.5-186.fc11.i686, xorg-x11-server-Xorg-1.6.1.901-5.fc11.i586, xorg-x11-drv-ati-6.12.2-17)
XenoPL: GFX card is RV 350 (Radeon 9550)
suokko1: XenoPL: Does your drm module detect vram size correctly for your card? Just in case it is same corruption what I had. (There is a patch for it)
XenoPL: IIRC yes (128 MB) but i'll have a look again, it should be somwhere in dmesg?
XenoPL: Line from Xorg0.log
XenoPL: --) PCI:*(0@1:0:0) ATI Technologies Inc RV350 AS [Radeon 9550] rev 0, Mem @ 0xe0000000/134217728, [...]
XenoPL: so it's detected ok.
phercek: I have kind of corruption after xrandr rotate too: you can see how it looks like here: http://www.hck.sk/users/peter/pub/xorg/bug.jpg
phercek: though it is probably not a font corruption but some temporary rendering damage
XenoPL: Dunno, I had to restart X server to get rid of it
XenoPL: Mine looked like this: http://img44.imageshack.us/img44/1104/fontcorrptng.png
[Enrico]: XenoPL: nice settings :D
XenoPL: THNX Enrico. Sometimes it's just notifications and clock plazmoid. But sometimes all new apps had fonts unreadable
XenoPL: Including menus, icon names etc...
[Enrico]: no clue sorry
phercek: ok; looks different; in my case it looks like objects are rendered sometimes correctly and sometimes by one pixel off; I do not have yet the latest drm module though; I'll check again when I update
XenoPL: no prob, it's not that important. But if I found it i thought it would be nice to see if devs are aware of the problem
_Groo_: hi/2 all
_Groo_: airlied: ping
_Groo_: glisse: ping
_Groo_: MostAwesomeDude: ping
nanonyme: is not sure how productive idle pinging is
bridgman: apparently not very productive right now
nanonyme: Hey, bridgman. ^^
bridgman: hi
_Groo_: hi bridgman
_Groo_: bridgman: do you know if the devs fixed fbo for rs485 yet?
bridgman: don't know, sorry
octoploid: phercek: Ceck out the workaround here: http://bugs.freedesktop.org/show_bug.cgi?id=21963
nanonyme: bridgman: What's today's interesting issue with r6xx-rewrite? :3
octoploid: phercek: I had the same issue as in your screenshot and the workaround fixed it.
_Groo_: nanonyme: not idle pinging.. i want to summon some of main devs since im doing regression tests and want to know where should i send my findings
phercek: octoploid: thanks, it looks like my problem :) I'll try it
nanonyme: Bug tracker? ;)
bridgman: ahh... summoning is OK ;)
nanonyme: If it's a breakage found with regression testing, it's a bug and belongs to fdo bugzilla, me thinks.
_Groo_: nanonyme: actually bug tracker might be excessive. since i plan to doing this regressions tests once a week, i want to send the findings directly to them
nanonyme: *shrug*
bridgman: re: 6xx-rewrite, I guess current news is that (a) Richard tracked down the "damn thing ain't rendering" problem to an issue in bufmgr; hacking the driver to plunk the shader programs and vertex buffers directly in vram made things start drawing the way he expected
bridgman: no fix for that yet
XenoPL: suokko: what was the fix? I grabbed my packages from koji
bridgman: presumably it's related to porting the bufmgr/cs stuff to 6xx/7xx - current thinking is a mesa issue since agd5f tested the new drm ioctls with a modified version of radeon that used the new ioctls for 2D acceleration
bridgman: the other issue was that Cooper found some of the semantic mapping registers that route VS output to PS input weren't being initialized properly
bridgman: we have a fix for that but it's not pushed yet
nanonyme: _Groo_: If you file a bug, the issue gets automatically permanently documented and all respective devs get to know of it. :)
_Groo_: nanonyme: ok ok.. but will be a lot of bugs :D
_Groo_: anyway.. how can i deactivate a branch in git? im not using one branch from mesa master anymore.. to activate i use git branch name origin/name, and to remove?
nanonyme: branch -d iirc
nanonyme: man git-branch
octoploid: Yep, git branch -D
_Groo_: thanks guys, it worked :)
nanonyme: Iirc -D is force delete but unsure.
octoploid: nanonyme: Delete a branch irrespective of its merged status.
yangman: `git branch -d` aborts if removing that reference will orphan commits. -D forces the removal
XenoPL: BTW anyone with R3x0 and Fedora 11? My system freezes when KMS is disabled and 3D applications more complex than glxgears are used.
XenoPL: I guess it's X that hangs but I have no second mahine to ssh into my main box
XenoPL: sometimes it kicks me back to login screen but usualy screen goes blank, sound is looped and input devices locked.
AbortRetryFail: if sound is looped it's probably locking up hard.
AbortRetryFail: XenoPL: do any of the alt-sysrq keys work?
XenoPL: if it drop me to kdm, not keyboard is locked and doesnt respond even to *lock keys
XenoPL: ie even diodes don't flash when numlock or caps is pressed
XenoPL: although it happends that after few minutes X server restarts and I regain control
AbortRetryFail: XenoPL: Did you have the proprietary ATI catalyst drivers installed before?
AbortRetryFail: I had all kind of uglies going on before i figured out how to clean up the libs that fglrx replaced
XenoPL: looping sound might be due to pulseadio and 100% CPU usage.
XenoPL: Nope,
XenoPL: Fresh install
AbortRetryFail: wine?
XenoPL: Nope, native apps, like Glaxium, GL-117.
XenoPL: IIRC I've tried with Q3 too
AbortRetryFail: ouch
XenoPL: With KMS on it's ok. I guess there must be something wron with rendering path in drivers
XenoPL: I had the same problem in F10 regardless of KMS
AbortRetryFail: i've never tried using KMS with anything other than intels.
XenoPL: It seems to be working with latest KMS bits, but then 3D is painfully slow
suokko1: XenoPL: If your vram size is detected correctly vram detection patch won't help but it is in Arlied's kernel tree (and in the latet pull request for linus)
XenoPL: Thanks Suokko1, so I guess I have it. -191 kernel is from yesterday.
nanonyme: bridgman: Right, thanks for update. :)
suokko1: I don't use Fedora so I can't comment about that. But I have noticed also DRI1 r300 driver freezing in Xserver if anything more complex than glxgears is using opengl. But upgradeing to git version of ddx/libdrm/mesa did help but didn't fix it complitly. (That x1400 machine isn't mine. I just tried to help fixing the problem)
XenoPL: Another reason for old DRI1 way to die :D
XenoPL: Airlied: Quick question, should I fill new bug for font corruption problem?
nanonyme: expects DRI1 to rather gracefully pass away than just go die :)
XenoPL: Or rather slowly decay
nanonyme: Gracefully pass away as in it will be alive still as long as it takes for the enterprise distros and such to migrate to the newer kernels... :)
nanonyme: Will take its time. ^^
XenoPL: Yup, but with DRI2 and Gallium goodness in sight each new bug makes it closer
nanonyme: Well, it probably still means years. :p
nanonyme: That is, if you only count it dead only after no one uses it anymore. :)
XenoPL: I'm thinking about the point when bug-fixing won't make any sense.
XenoPL: anymore ^^
nanonyme: Oh, but it does?
nanonyme: Just maybe not on fdo bug tracker.
XenoPL: I think it does for now, but it's up to devs
AbortRetryFail: suokko1: I was using r300 with DRI1 yesterday and it wasn't freezing things.
AbortRetryFail: it wasn't -git versions though.
nanonyme: It does for as long as paying customers haven't migrated to DRI2 world. ;)
XenoPL: AbortRetryFail: what was the MESA ver. if I can ask?
suokko: &drm&ddx? :)
AbortRetryFail: rather old :) 7.0.2, then 7.0.4
XenoPL: For me problems started with Fedora 10, when MESA 7.3 was introduced along with 2.6.27 KMS enalbed kernel
AbortRetryFail: xf86-video-ati-6.12.2 and 2.6.24.5
XenoPL: Up to MESA 7.1 I had no problem
AbortRetryFail: it was actually running pretty good.
AbortRetryFail: got like ~11000fps in glxgears with my X800
suokko: So old mea and new ddx works nicely
AbortRetryFail: not nicely
AbortRetryFail: weird artifacts sometimes.
AbortRetryFail: segfaults from wine (when does wine NOT segfault...)
AbortRetryFail: things like xscreensaver's hypertorus rendering only in red
XenoPL: Yup for me 2.6.25, 6.8 and MESA 7.1 was killer combo
AbortRetryFail: the bouncing amiga ball had no checkerboard.
AbortRetryFail: really weird stuff.
XenoPL: yeah thet's true (about wine)
AbortRetryFail: I still hold the stance that wine is unintentionally vendor-specific.
XenoPL: I had some artifacts with KWin composite too
AbortRetryFail: it only runs worth a damn using nvidia's proprietary driver.
suokko: Maybe some git bisect between 7.1 and 7.4 could help to locate the buggy commit
AbortRetryFail: 7.1?
AbortRetryFail: oh for mesa?
AbortRetryFail: i haven't tried 7.1 yet.
XenoPL: yup
XenoPL: It was defult for F9 iirc
AbortRetryFail: i switched to fglrx because xrandr dualhead just doesnt' work for me
AbortRetryFail: tremulous would render half-offscreen
AbortRetryFail: stupid stuff.
suokko: hmm. xrandr dualhead works quite well out of boxs for me
AbortRetryFail: <3 zaphod mode.
XenoPL: Single screen here so I preffered foss ones
suokko: But sometime 2nd screen has wrong viewport so I have to reconfigure it and restart X
DanaG: zaphod?
DanaG: I won't use a secondary screen unless I can get one that matches my 147DPI main screen.
AbortRetryFail: DanaG: dual head, dual screen
XenoPL: FGLRX made my sytem crawl after wakeup from suspend to ram
AbortRetryFail: they're completely separate to X apps
AbortRetryFail: one shows up as display :0.0 the other as
AbortRetryFail: :0.1 etc.
AbortRetryFail: i like it because fullscreen apps won't screw up window placement all over every screen.
AbortRetryFail: eventually i want to get my 3rd and 4th monitors working.
suokko: I did use projectors with r200 and r500 cards 2 weeks ago for 3 days. With R200 there was no problems but r500 card had that vierd problem sometime that I could only move windows half way to 2nd screen
DanaG: How do you move apps between them?
AbortRetryFail: DanaG: you can't
AbortRetryFail: and it doesn't matter to me.
DanaG: How do you choose which display to start one on? Different mouse and keyboard?
suokko: DISPLAY=:0.1 firefox
AbortRetryFail: i use fluxbox
DanaG: Hmm, can you at least mouse between them... or do you need synergy?
AbortRetryFail: window-r is bound to a run dialog
AbortRetryFail: the mouse moves between them like normal multihead.
AbortRetryFail: you just cant drag windows
AbortRetryFail: also you have 1 WM
AbortRetryFail: it handles both screens
AbortRetryFail: different sets of workspaces too
AbortRetryFail: so switching desktops switches only one screen.
AbortRetryFail: fluxbox handles it well, so does xfce
DanaG: How about metacity and compiz?
suokko: thinks that bug messing up window positions should be fixed instead of requireing that kind of workarounds
AbortRetryFail: i don't use those so i couldn't tell you.
AbortRetryFail: suokko: it's not a workaround.
AbortRetryFail: i like it this way
suokko: ok :)
XenoPL: the only problem is lack of DRI, am I right?
AbortRetryFail: dri works
AbortRetryFail: oh with the r300 driver?
AbortRetryFail: no that doesnt
suokko: btw, Is your window positions changing only after fullscreen application puts screen to smaller resolution than you use for desktop?
AbortRetryFail: fglrx has dri and zaphod mode, but no rotation
AbortRetryFail: suokko: i have that problem with xrandr multihead using my radeon and on my laptop's intel card.
XenoPL: and problems with Xv :p
suokko: I was just trying to think what was causing the problem. That was just my guess for cause of bug :)
AbortRetryFail: dunno
AbortRetryFail: i don't like the way xrandr does multihead anyways.
suokko: ie. Screenresolution changes so windows are forced to move to fit nito new resolution
AbortRetryFail: with the 'virtual' area that has to be set.
AbortRetryFail: two decently high resolution screens and you have a pretty big virtual area.
AbortRetryFail: and on intel cards that means no bigger than 1600x1600 or something.
AbortRetryFail: or you lose DRI
AbortRetryFail: which SUCKS
suokko: It is possible to hack that limit in source code
AbortRetryFail: why the heck did they put it in there then!?
suokko: That is just harcoded limit in ddx driver initialisation
suokko: Just to save memory
AbortRetryFail: ugh
AbortRetryFail: lame
AbortRetryFail: it only uses what you tell it to
suokko: Because large virtual desktop takes huge amount of video memory
AbortRetryFail: yeah i know.
AbortRetryFail: that's why i don't like how xrandr does multihead
AbortRetryFail: i don't even want to think about how that would work with 4 displays
suokko: But I think that virtual desktop should be made dynamic so you can allocate and free framebuffers on the fly if you plug a new monitor
AbortRetryFail: wouldnt that be nice :)
suokko: And maybe that is possible with KMS&DRI2 :)
suokko: I don't know hw details so can't comment
AbortRetryFail: and maybe not leave 'holes' offscreen for odd-sized displays?
AbortRetryFail: yeah i'm kind of oblivious to how the whole thing really works on the inside, i'm sure there's a reason for why it works the way it does.
AbortRetryFail: i just learned the distinction between the 3d drives and the ddx earlier this week.
AbortRetryFail: s/drives/drivers/
mjr: (IIRC XAA assumed unchanging virtual width, I'm not sure though if moving to EXA will eradicate most of the obstacles of dynamic framebuffer resizing or not)
AbortRetryFail: oh cool
suokko: What about GPU internals? Do they support dynamic framebuffer location?
AbortRetryFail: windows does it somehow.
suokko: Maybe that is in amd documentation :)
mjr: yes they do
suokko: One solution is to just make reinit the card with different sized framebuffer but then all memory objects in new larger framebuffer area would have to be moved but even that could be possible with memory manager
AbortRetryFail: i'm actually going to have to switch back from fglrx
AbortRetryFail: i got better performance and less crashes with the r300 driver (!!!)
suokko: 2D performace is nice with oos drivers :) Too bad KMS&DRI2 still got a lot of overhead
AbortRetryFail: is there a big readme on this memory manager thing? I keep seeing people talk about it but i'm not familair with what it's supposed to do
AbortRetryFail: suokko: actually i'm getting better 2d with fglrx right now. but NOTHING works with 3d except a few native apps.
AbortRetryFail: wine crashes right out of the bat and unrealtournament doesn't work at all.
AbortRetryFail: plus they arent updating it anymore for the old cards like mine (radeon x800)
AbortRetryFail: i've got a radeon x1050 in the other slot just doing nothing right now too.
suokko: Memory manager is residing inside kernel and all graphic operations have to request memory from it. Then kernel can know what memory is in use and by what program
XenoPL: and FGLRX + composite is always a problem.
AbortRetryFail: suokko: like how normal memory is handled
AbortRetryFail: how is video memory managed with DRI1?
suokko: Then that can be used to make persitent memory locations to vram for opengl aplications (FBOs)
suokko: In DRI1 memory allocation is handled by dri driver so there isn't any common knowledge about data in memory
suokko: So dri driver can't allocate large persistent objects in video memory
suokko: Too bad that means 75 % of CPU usage of glxgears is going for memory management in my system
mekius: anyone know the state of r600/700 3d?
AbortRetryFail: yikes
suokko: (Most of that seems like going for cache flushing in agp mode) PCI mode performs better
AbortRetryFail: do pcie cards still use agp stuff?
suokko: But I don't have hard data because oprofile doesn't give sensible callgraph with default kernel compiler parameters
AbortRetryFail: hrm
suokko: pcie has replaced agp stuff and sounds like easier to code for
suokko: But PCI mode has bottlenecks too. XV is a lot faster in agp mode so I'm now using agp mode (and not using 3D stuff that is slow)
AbortRetryFail: how much does your xserver version matter with mesa, DRI and the ddx?
suokko1: And that was my kernel hard locking :(
AbortRetryFail: :/
suokko1: Xorg: page allocation failure. order:4, mode:0xc0d0
bridgman: suokko; dynamic framebuffer location with XAA is a limitation of the API AFAIK; EXA allows it, XAA does not
bridgman: nothing to do with hardware
AbortRetryFail: bridgman: do you still have to set the virtual size if you're using EXA then?
suokko1: good. So we might see dynamic framebuffer with kms :)
bridgman: mekius; I summarized the 6xx 3d status about 2 hours ago, check backlog ;)
airlied: XenoPL: you the 7.6 mesa pacakge?
bridgman: AbortRetryFail; I think you do with radeon, not sure about radeonhd
bridgman: different defaults
XenoPL: Yup, that's right all the lates bits form koji
XenoPL: MESA 7.6.0-2
AbortRetryFail: about the xorg version versus mesa/ddx/kernel versions: How far apart is too far apart? Building new packages for mesa/ddx/kernel is a piece of cake without breaking lots of other things. (slackware does have some redeeming qualities!)
suokko1: Xorg.log: RADEON DRM CS failure - corruptions/glitches may occur -12
AbortRetryFail: well that's encouraging
suokko1: Sounds like my hard lock was caused by DRM. But no logs from crash survived because I couldn't force sync before reboot
Rosse: Hey guys, which AGP chipset is best supported?
EruditeHermit: hey, with kms, is software rendering the default?
XenoPL: EruditeHermit: what card?
EruditeHermit: XenoPL: rv350
XenoPL: Nope, hw rendering should work ok
EruditeHermit: weird
EruditeHermit: let me try again
EruditeHermit: brb
suokko1: http://pastebin.com/m174b4c3f There is a few kernel backtraces from failures in ttm page allocation
suokko1: This was caused by kernel compilation that was adding high latency to everything becaue of heavy disk IO
EruditeHermit: XenoPL: hi
EruditeHermit: XenoPL: so I don't understand
EruditeHermit: glxinfo gives Direct Rendering: yes
bridgman: reemmber you can get direct rendering with the software renderer these days
EruditeHermit: and then lower down, OpenGL renderer: Software Rasterizer
EruditeHermit: oh?
bridgman: yep, that option got added maybe 6 months ago
bridgman: confused the hell out of everyone because overnight all the "here's how to tell if HW rendering works" instructions on the web became obsolete ;)
DanaG: What does direct-rendering even mean, for software renderer?
DanaG: People should grep for renderer, not direct.
bridgman: same as hardware - application calls the GL driver directly rather than going through the GLX wire protocol to the X server and having the X server call the GL driver
EruditeHermit: so does that mean its using mesa and its not hardware accelerated?
XenoPL: EruditeHermit: What kernel, mesa packages you have?
EruditeHermit: stuff from here
EruditeHermit: https://launchpad.net/~xorg-edgers/+archive/radeon-kms
bridgman: 3D always uses mesa, whether it's software or hardware rendering
bridgman: mesa just uses sw render rather than a hw driver
bridgman: same with gallium3d; you still use mesa but mesa uses gallium3d framework & drivers rather than "classic" mesa hw drivers
bridgman: mesa is about a million lines of code, hardware drivers are maybe 20K-30K lines each
XenoPL: EruditeHermit: any warnings or errors in Xorg log?
DanaG: I'm curious what there is for a 3dfx Voodoo3.
EruditeHermit: (EE) AIGLX error: Calling driver entry point failed
EruditeHermit: (EE) AIGLX: reverting to software rendering
bridgman: dri driver : http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/tdfx
bridgman: glide driver : http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/glide
suokko: EruditeHermit: Does dmesg tell you that initialization of KMS worked any error there?
suokko: EruditeHermit: Have you upgraded to Karmic?
EruditeHermit: [ 27.880631] [drm:radeon_cp_start_kms] *ERROR* invalid ioctl with kms radeon_cp_start_kms
EruditeHermit: suokko: does it require karmic to work?
bridgman: seems like they're both being maintained, which impresses the hell out of me
suokko: yes.
EruditeHermit: suokko: I just upgraded those packages using jaunty. What other parts changed?
suokko: I don't know what is minimum set of package but easiest might be upgrading to Karmic
suokko: Something like newer xserver than what Jaunty has is at least required
suokko: It might also be enought to read this: "If you install these packages on Jaunty (nobody said you should try that), add Driver "ati" to your xorg.conf."
EruditeHermit: yeah I did that
EruditeHermit: i'll just try the live cd I guess
suokko: EruditeHermit: You could install livecd to USB stick and use newer system from there
EruditeHermit: yeah that is what I was planning to do
mekius: anyone know of any instructions newer then these http://www.x.org/wiki/radeonhd%3Aexperimental_3D?
bridgman: I think those are pretty current, although don't think I used all those autogen.sh parameters for drm
mekius: k
mekius: so his repo is still the best source for the most up to date stuff?
DanaG: bridgman: ah, I see the drivers; now I just want to see what you can do with it. =þ
EruditeHermit: bridgman: any idea how gallium radeon driver is going?
bridgman: I think MostAwesomeDude had glxgears running a month or so ago, and is making good progress on shaders
EruditeHermit: so how long before we have something feature complete?
bridgman: DanaG; no idea; build em and see what blows up ?
EruditeHermit: something to test
DanaG: biggest thing I want from radeon: compiz+KMS
bridgman: hard to say; MAD is going to be working on "shatter" or something like it over the summer so he probably won't have a lot of time for Gallium3D; I'm going to switch our guys over to working on Gallium3D once we get the classic mesa 6xx/7xx 3d up to roughly 5xx level
bridgman: so if I had to guess I would say end of summer
EruditeHermit: how close to classic mesa parity are you now?
bridgman: DanaG; that's cheating; KMS needs memory management, so you're asking for pretty much everything ;)
bridgman: well, classic mesa works and 6xx/7xx doesn't ;)
bridgman: but we think we know what's wrong with it
bridgman: I was aiming for May-ish before realizing we needed to port onto radeon-rewrite, so guessing late July or early Aug
bridgman: we lost two weeks on one bug so it's really hard to tell
DanaG: Here's something odd: for one version of the radeon driver, I DID have working kms!
DanaG: I think it was drm-rawhide a while ago.
DanaG: But it wouldn't run Xorg accelerated, if I used it.
suokko1: slaps him self with mesa debugging capalities
bridgman: suokko1; I haven't tried that, does it help ?
suokko1: I never learn that it isn't good idea to use only one computer when trying to see real time debug output
suokko1: hmm. Maybe I should write a wrapper program to buffer the stderr so no hard lock from there
spstarr: hello bridgman
spstarr: waits for his pizza to cook
mekius: bridgman: So by the end of Aug r6xx/7xx should be about as good at r300?
mekius: :)
bridgman: better than 3xx, more like 5xx
bridgman: in terms of driver features
bridgman: performance will be more a function of the hardware itself
bridgman: but afaik there's not that much difference between 3xx and 5xx today
bridgman: those differences should start to appear as the driver picks up support for higher GL functions
suokko: r500 still had missing features in mesa 7.4 which resulted in wine that some games did run with r200 but not with r500 ;)
mekius: bridgman: well sure, the hardware is more advanced so it should be faster of course :)
mekius: I'm just more wondering if the same level of gl support will exist at that point so one could play 3D games and such :)
mekius: guess i'm not even sure how good the r300/500 drivers are at this point though
DanaG: nice: "Upon its announcement, Nvidia’s GeForce GTS 250 came in for more than a little bit of stick when it emerged that the card would be, initially at least, little more than a rebadged GeForce 9800 GTX+ - a card that was only mild overclocked over the original GeForce 9800 GTX, which was originally known as the GeForce 8800 GTS 512MB."
bridgman: basically the spiffiest Linux games and most modern Windows games over Wine need GLSL, and only fglrx has that today
DanaG: Oh yeah, so I should expect August-ish for compiz? If so, sweet.
mekius: bridgman: Ah, wasn't aware of that :)
mcgreg: I just hope that by the time out heros in here finish to make a let's say young stable 3d driver , there wont be another generation of gfx card to support .. so they would be distracted again ;)
mekius: bridgman: So probably going to be waiting awhile for that type of support eh? :)
mekius: bridgman: aware of the lack of any shader support that is, I knew most newer games use shaders :)
bridgman: it's not the lack of shader support; the current open source drivers support arb_vertex_program and arb_fragment_program
bridgman: it's just that more recent games tend to use the GLSL shader language instead, which is more powerful
bridgman: mcgreg; we want to have basic 3d working before the next generation parts come out
bridgman: otherwise things get confusing ;)
mcgreg: sure. but ... I wold like to have more than just basic things... thats why my post was about ;) I would like to be able to play wow with my 4670 with decent quality and speed
bridgman: ask me again about schedule in a week or so; a lot of the driver work has been done, but right now I don't know how much of it will work once we get the porting issues fixed
bridgman: I guess it depends on what you mean by decent quality and speed
mcgreg: lets say ... 80% of fglrx would be enough at first ;)
bridgman: the games that work on the open source drivers today look pretty good on an rv570 or r580
mcgreg: ok... I mean of course speed. quality depends on speed. when I use high quality settings in a game/application .. high resolution things look prettier
mcgreg: thoigh I know I shouldnt expect miracles :)
bridgman: um... a lot of the high quality settings you are thinking about probably don't even exist in the open source stack today
bridgman: 10 years ago there was a nice correspondence between driver features and hardware features; you want fog, you turn on the fog bit, you want AA you turn on the AA bit
bridgman: those days are long gone
bridgman: all this stuff is done with big chunks of driver code
bridgman: and a lot of that code hasn't even been thought about, let alone written
bridgman: the good news is that once memory management stabilizes some of these things become worth thinking about, like MSAA
bridgman: so don't be lookin' for that AA button for a while ;)
mcgreg: well, AA has never been important to me :)
bridgman: oh good; you might be happy then
mcgreg: but playing game in 1680x1050 is cool ... with my texture filtering .. :)
DanaG: I have a 147DPI display... so running HL2DM at 1920x1200 with 0xAA but good texture filtering and vsync... nice.
bridgman: ok, that should be doable
DanaG: I don't like Wine, though... no surround sound. So, I boot native for games.
mcgreg: well, I am speaking of WOW and that game is that new and that much hungry for any special hardware. it runs even on old intel gfx onboard hardware
mcgreg: *is=isn't
mcgreg: well, slowly wine is annoying me too. they contacts: get nvidia hardware, is so much better stuff is lame.
mcgreg: omg
mcgreg: I should read what I write before I send it
mcgreg: *the constant: "get nvidia hardware, is so much better stuff" is lame. it should be
bridgman: I think that's changing; they're identifying specific opengl things that aren't working the way they expect, our driver team either agrees it's a driver bug and fixes it or points out that the way Wine uses the driver needs to change, in which case the Wine devs fix it
bridgman: it seems to be working pretty well
bridgman: between Cat 9.6 and Wine 1.24 there seems to have been a good lurch forward
mcgreg: hmm I've recently heard the "teams" dont work together. or they didnt used to .. at least. that chanmged recently?
bridgman: yeah, I think that's changing
bridgman: once we started talking about specific opengl issues rather than general suckage things improved a lot ;)
suokko: At leat soeone from amd sent message to wine mailing list asking for help debugging because hooking debuger to wine had changed :)
mcgreg: well.. I hope next fglrx releasse will support .30, so I can test it. but probbaly when next fglrx will be out, IÄll be using .31rc* already ;)
bridgman: if you want to stay with bleeding edge kernels you might want to think about moving to the open source drivers
mcgreg: I do :)
suokko: But anyway. Has anyone tried to run the wine test suit on opensource drivers?
DanaG: I like compiz too much for me to do that. =þ
DanaG: I tried the tests... and they all just segfaulted.
mcgreg: well, I only want eyecandy for games :)
DanaG: Or at least, I seem to remember them doing that.
suokko: That segfault is usually pointing bug in driver :)
bridgman: don't know; I remember some discussion about the test suite but don't remember if the context was fglrx or the open drivers
mcgreg: hmm I would like to see xorg being able to use differetn drivers for different VTs ;)
bridgman: not always; a surprising number of the segfaults come from app asking if an extension is available, being told it is not available, then using it anyways
mcgreg: lol
suokko: That is different bug: missing feature :)
bridgman: if you were on different GPUs that would be doable once the framework evolves a bit more
bridgman: having two different kernel drivers on the same hardware might be... exciting
mcgreg: hehe
mcgreg: well, it's just a funny fantasy :)
bridgman: virtualization will probably allow that kind of thing eventually
suokko: But wine test suit shouldn't try to use missing opengl extensions (or if it doe then it is bug in wine test suit)
bridgman: albeit with a performance hit for flipping GPU state each time you switch drivers
mcgreg: a friend of me "hacked" qemu so windows could access pci and real windows drivers worked with 3d :)
DanaG: bridgman: reminds me of the time tomshardware.com tested a dual core opteron with a single core opteron.
DanaG: They matched clock frequencies... but not instruction set availability.
DanaG: Illegal Instruction. =þ
bridgman: things are improving there; you can bounce a virtual machine with a running app onto a different CPU these days and it usually works, pretty impressive
DanaG: ugh, damn wine... can't handle Steam directsound.
DanaG: err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource temporarily unavailable
mcgreg: but what I currectly like a lot about the open drivers is .. I can take my usb stick with 4gb and use it on almost every hardware ot there (if it has radeon) and everything will work :) (well, almost) :)
mcgreg: oh I should include, the usb stick had debian unstable onboard, just like my system is :)
mcgreg: and I love xorg autodetection for video hardware :)
bridgman: yep, but part of that is because the drivers are open and can be tweaked for more hardware, but part of it is that the drivers are much smaller and simpler
mcgreg: yeah, thats why I love open drivers. they make user life a lot easier.
bridgman: if you want fglrx performance and features then you're going to be getting into fglrx size and complexity, with all the bad things that come along with that
bridgman: memory management is really the line in the sand; once you cross that you're starting to work on the complex, finicky stuff that works great on Fred's system and locks up wierd on Bob's system
mcgreg: well, I suppose it's all a matter of time you put into the development of the driver :)
bridgman: yeah, but the time invested in the driver is a function of the market size, and that's where things get tricky
mcgreg: hehe well ... I wasnt talking about money :) I was just talking about theory and time :)
bridgman: sure, but once you start dealing with sufficiently large projects you outstrip volunteer availability then all your time starts costing you money
DanaG: mcgreg: yeah, that thing about USB... also reminds me of why binaries suck. Can't do that with nvidia or fglrx.
DanaG: And nouveau and nv both suck.
bridgman: the good news is that the roadmap for the open source stack looks pretty good, particularly Gallium3D
bridgman: as long as memory management comes together (it's a lot harder than it looks) the rest of the initiatives seem to be fairly small and modular
mcgreg: DanaG: yeah the point is, I could preinstall the binary driver on the usb stiock, but then, xorg autodetect might be confused
bridgman: the downside is that because you can't do big-bang changes in this world everything tends to take a long time
bridgman: we're going to be carrying three different 3D stacks for a few years
DanaG: mcgreg: yeah, but then it'd break all of the other GL drivers.
mcgreg: exactly
mcgreg: bridgman: uhh sounds a little fishy :)
DanaG: what are the three?
EruditeHermit: what would have been nice is if mesa allowed fallbacks to software extensions so that whatever the driver accelerated was fine and whatever was not was done in software so that OpenGL 2.1 was supported
bridgman: radeon-rewrite over legacy memory management
bridgman: radeon-rewrite over GEM/TTM, with a bunch of extra features possible
bridgman: (substitute legacy mesa hardware drivers for radeon-rewrite if you like)
bridgman: gallium3d over GEM/TTM
suokko: hmm. Git master lightning with r200 works in DRI1 mode but fails in DRI2 mode (but not with everything)
bridgman: there's enough shared code to make it doable, but each of these is a significantly different set of code paths with different test requirements and different bugs
suokko: So something buggy in state changes in DRI2 mode maybe
mcgreg: might be a stupid question.. but why no simply kick "radeon-rewrite over legacy memory management" ?
bridgman: because the customers who pay for all this development (enterprise distros) aren't going to be picking up new kernels for another year or three
mcgreg: or is the newqere stuff still faaar from being stable?
mcgreg: ohh
mcgreg: ok
bridgman: the new stuff certainly isn't sufficiently stable for enterprise customers yet, but it will be
EruditeHermit: bridgman: was any thought given to just starting on gallium3d and not bothering with classic mesa style 3d on r6/7xx
EruditeHermit: oh
bridgman: one of the distro challenges will be convincing enterprise customers to move to new kernels more quickly than before, but that involves a much higher testing bar
bridgman: EruditeHermite; that's what everyone wanted to do, except there would have been no solution for... (repeat after me) the enterprise distros who pay all the bills
rah: I have an idea
rah: a crazy one, I realise
suokko: Linux kernel could use regression test suit so enterprises distros would just have to check everything passes there
rah: why not write the software
suokko: But then hardware emulation to test drivers would be tricky part :)
rah: and let the companies with SLAs worry about their customers?
bridgman: the companies with SLAs are the ones funding most of the development
EruditeHermit: bridgman: what I don't get is if they are not going to pick up new kernels, won't they stick with EXACTLY the same stack as before
EruditeHermit: so if it worked a year ago, it will still work a year from now
bridgman: nope, historically you get moderate changes to userspace and a lot of backporting in the kernel
bridgman: and kms/mm is too big to backport
suokko: rah: Do you know who is paying for KMS development? :)
bridgman: (hint) they have a lot of SLAs ;)
rah: bridgman: that doesn't conflict with what I said
bridgman: maybe I don't understand what you were trying to say then ;)
rah: they're funding development
rah: so develop
EruditeHermit: i trust you made the best decision given the information
EruditeHermit: its just we don't have access to all that information
EruditeHermit: so it makes us wonder
EruditeHermit: =p
bridgman: and when it is available nobody likes it ;)
rah: "development" does not mean "whatever is best for the people funding development"
mcgreg: heh
rah: instead, it means "development"
bridgman: sure, but the people funding development get to decide what development will mean ;)
suokko: rah: What if you have contract with Redhat and they just happen to assign you work in driver development but main focus is of course to improve redhat products!
bridgman: rah, what do you think should be done differently ?
mcgreg: bed time. have fun, good night ;)
rah: bridgman: then by "funding development" you're actually talking about funding the distro
bridgman: no, the developers mostly work for distros or hardware companies
suokko: Is it possible that some fragment shader is broken DRI2 mode but sam shader works in DRI1 (driver internal shader for per pixel lightning)
bridgman: "mostly" in terms of hours, not individuals
rah: bridgman: who they work *for* is irrelevant; it's what they work *on* that matters
EruditeHermit: nice I got kms working
bridgman: but what they work on is determined by the people they work for
rah: bridgman: then by "funding development" you're actually talking about funding the distro
bridgman: no.. the distro funds development
rah: of the distro
bridgman: by hiring developers and having them work on new features
bridgman: for the distro, but the work is done in public code
bridgman: so other distros can pick it up as well
rah: sure
rah: but it's for the purpose of their distro, not others'
EruditeHermit: with kms enabled and latest mesa, kernel, DDX bits, do I get dri2?
bridgman: a bit of both
suokko: EruditeHermit: yes. glxinfo hould say DRI2
bridgman: but yeah, the primary reason for doing development is to let them deliver a better product
suokko: In renderer string
EruditeHermit: nice it does
rah: there seems to be something wrong here
suokko: Then you just have to hope it doesn't hard lock in high IO load like mine does ;)
DanaG: It does suck that they say: "hey, give us new features, but don't change the kernel!"
DanaG: ... if that's what they do.
rah: to do with "enterprise customers" controlling the shape of free software development
DanaG: But it would be business suicide to say "you want old kernel, you get old graphics stack!"
EruditeHermit: suokko: I have visual oddities and resume from suspend fails
EruditeHermit: and its marginally slower
EruditeHermit: well maybe 50% slower
DanaG: er, old mesa.
suokko: EruditeHermit: http://antin.net/wesnoth/xmoto.html like this?
EruditeHermit: no
EruditeHermit: I get lines small 1cm long horizontal lines that appear sometimes
EruditeHermit: small ones that make you think your eyes are playing tricks
EruditeHermit: but they are there
rah: it used to be that distributions with enterprise customers maintained their own sets of patches which got contributed back to the independent developers
suokko: How long they are visible and what card you have?
EruditeHermit: they are visible for tenths of a second
EruditeHermit: and rv350
suokko: And is it possible you to get screenshot from them? :) (or video)
rah: now it seems the developers are all owned by the distributions with enterprise customers and the sets of patches are software releases
EruditeHermit: well
rah: I'm not sure this is good
EruditeHermit: I can try I guess
chithead: EruditeHermit: I had this too on my rv530, solution was to plug my monitor in the other output. also reducing refresh rate from 75 to 60 hz helped
suokko: rah: Ithink that is a lot better than having 1/10th of development happening compared that what is now possible
chithead: EruditeHermit: what I saw were black horizontal lines
EruditeHermit: they are white here
EruditeHermit: its a laptop
suokko: There is just so much limit what people can do as hobby
rah: "independent" doesn't necessarily mean "hobbyist"
suokko: rah: But if none pays you that is hobby most likely
EruditeHermit: hmm
suokko: Becaue it is hard to live without making money with your best skills
rah: I can see a scenario where interests who wish free software to fail can use the power gained by enterprise customers to dictate strategically weak directions in development
EruditeHermit: I wish they would sync the master DDX with the gem-cs3 branch
EruditeHermit: or kms-support is what its called now
rah: this is about money becoming the predominant force behind the development of free software
rah: to allow money to usurp the ethical ideals behind free software is to weaken the cause
bridgman: rah, the problem is that peoples expectations from Linux have grown, so the amount of development work required has grown as well
bridgman: it's not tht the distros have "taken over development", it's that someone had to poney up a lot more developers and the distros stepped up
rah: why did they have to poney a lot more developers?
bridgman: because everyone wanted a lot more features
rah: what would the consequences have been of not poneying up a lot more developers?
bridgman: and more performance, and more hardware support, and more maintainability, and more fault tolerance, and...
bridgman: everything would move much more slowly
suokko: rah: Also problem is that there is limited number of people who can afford to be idealistic full time and still have required skill level to write the code. Basically FOSS has been always about money.
rah: and what would the consequences of moving more slowly have been?
bridgman: more companies would use Windows
bridgman: fewer would use open source
suokko: bridgman: lol :)
suokko: For me it would mean working composite desktop in year 2015 ;)
rah: bridgman: you think companies that used free software would have switch from free software to proprietary software?
rah: bridgman: when?
rah: bridgman: why?
suokko: Now I hope it will be working next xmas :)
rah: bridgman: when did this watershed occur?
bridgman: because proprietary software would have had relatively more capabilities, and allow them to run their systems for less overall cost
rah: proprietary software has always had relatively more capabilities
bridgman: not in the server world, and that's where Linux has traditionally succeeded
bridgman: remember Unix and mainframe OSes ruled the datacenters
bridgman: Linux knocked out Unix and took over its spot and its customers
bridgman: Windows became a serious datacenter OS later (only a few years ago really)
bridgman: so far Linux is more or less holding onto market share, but if it hadn't moved as quickly I think Windows would be pushing it out of the datacenters more quickly
rah: and you think proprietary OSes would have knocked out Linux if distributions with enterprise customers hadn't poneyed up a lot more developers?
bridgman: probably - not completely, but right now I think Linux is holding onto maybe 30% market share in the server space and that wouldn't have happened without big investments from the distros
bridgman: that's my read anyways, could be wrong
rah: my concern really is not the server market but the desktop market, which dwarfs it
_Groo_: hi/2 all
rah: and there, linux only just past the 1% mark
_Groo_: ppl, im having problems with xf86-video-ati kms-support branch.. it gives merge conflicts, can anyone help me?
rah: but right now we seem to have a fifth column within the community, where the interests of money have come to power
bridgman: another way to look at it would be that if Linux is ever going to have more than a 1% market share then the desktop aspects are going to have to get a lot better
bridgman: and most of that work is being done by distros
rah: I wonder how this power will be wielded when that desktop market share starts seriously threatening the interests of proprietary software
_Groo_: bridgman: can you help me? :)
bridgman: Groo; I'm just lookin' around to see what kms-support is these days ;)
bridgman: remember I'm on dial-up, so I look more slowly than most ;)
_Groo_: bridgman: it gives merge erros with several radeon_ files
suokko: _Groo_: I don't have any conflicts
EruditeHermit: kms/dri2 is definitely a little slower
suokko: Do yo uhave some local modifications?
EruditeHermit: but its looking impressive
_Groo_: suokko: i first cloned xf86-video-ati, then i did a git branch kms-support origin/kms-support, and when i do a git pull i get several merge conflicts
_Groo_: suokko: none
_Groo_: suokko: im gonna clone the brnach directly to see if that helps
suokko: Doesn't work
_Groo_: with git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-ati kms-support
suokko: You have to checkout it
rah: I think it would be better for the market share to reach 30% in 40 years than reach 30% in 10 years with a fifth column in the community which uses its power to bring the market share back down to 1% in 20 years
suokko: yo uhave to clone the repository with git
suokko: Then you move from branch to branch with git checkout
suokko: and you can use -b switch with checkout to create new local branch that tracks remote branch for easier updates
_Groo_: suokko: ok, im cloning it
suokko: (Git is not same as cvs or svn so you have to learn new way of working with verion control)
bridgman: rah, the point is that without the commercial investment it wouldn't reach 30% in a million billion years
DanaG: fifth column? huh?
_Groo_: suokko: i cloned xf86, did a git branch, now what? git pull?
suokko: git checkout -b kms-support origin/kms-support
rah: bridgman: I disagree
airlied: git fetch
bridgman: go on
suokko: And after clone you don't have to do fetch or pull
suokko: Becaue you alreadyhave all remote data in local repository
_Groo_: hi airlied
_Groo_: suokko: thanks :) compiling now
suokko: Late you need git fetch/git pull to update your local repository
_Groo_: airlied: do you have any eta for fbo support in rs485? and auto modesetting?
_Groo_: suokko: whats the diference between fetch and pull?
_Groo_: airlied: btw im starting to do some regression testing, can i send a weekly report to you?
_Groo_: airlied: im gonna use mesa tests , some games and some apps, like blender.. to check for regression in dri2
suokko: in terms of svn: svn checkout=git clone, svn switch=git checkout, svn update=git pull (or git fetch && git rebase)
_Groo_: suokko: ah ok :)
_Groo_: airlied: also is there any diferences between the code you are sending to linus and the drm-next glisses branch?
suokko: git fetch is underlying command to get the new object from remote repository. After fetch you have to either merge remote stuff to local stuff or rebase local stuff to remote stuff
rah: I only hope the community is able to spot shifts if and when this fifth column starts to steer free software aside
rah: (and forks accordingly)
suokko: git pull dose git fetch & git merge automaticaly if no merge conflict
_Groo_: suokko: i just want to always have the latest remote stuff.. that would be a pull correct?
suokko: yes
rah: DanaG: fifth column == money
_Groo_: ok, just installed latest code, gonna restart x, brb
suokko: If you don't have any local changes git merge will just make your copy look same as remote is
bridgman: rah, not so simple; money also = lifeblood of development
suokko: :)
bridgman: fifth column = a small hypothetical subset of the money
rah: bridgman: erm.. not really
rah: bridgman: which is kind of the point I'm making
bridgman: maybe fifth column is a bad choice of words then
rah: bridgman: interest in writing free software == lifeblood of development
bridgman: that implies a group working on the inside against the wishes of the rest
rah: indeed
suokko: rah: Just tell me one high profile oss developer who does all this without getting payed for it :)
rah: suokko: RMS?
bridgman: honestly, there are a bunch of them, and they're extremely good
rah: Linus? :)
rah: who was a student when Linux started?
bridgman: MostAwesomeDude, glisse until recently, nha, agd5f until we hired him...
bridgman: there just aren't enough to deliver on all the features users are asking for
suokko: yes. And it was hobby for him and many others helping but it turned to work very soon when linux was usable
rah: thomas bushnell
kylem: most people who are paid to work on it spend far more time working on it than they're paid to.
rah: mcgrath
rah: many others
suokko: rah: Ok. There is people working or studding in universities are able to do more for oss but that is very limited work force
rah: actually, it's not "very limited"
suokko: and also still only part-time so we wouldn't get any new GPU drivers with that work ;)
rah: it's, in fact "very very capable"
rah: anyway as I say, I just hope the community can deal with the consequences of allowing money to gain influence
suokko: rah: Just tell me how you get them helping in oss development unless they happen to have intrest?
_Groo_: crashed and burned
rah: suokko: who?
rah: suokko: which "them" are you referring to?
suokko: rah: Academics
_Groo_: airlied: latest xf86 kms-support gives me beautiful stripes when trying to start X, then it restarts three times and dies.. really dies.. no maig keys no nothing.. only finger power
rah: I don't think the free software community really needs to "get" anyone helping in free software development except users
suokko: It is only minority who are ready to contribute to oss development
rah: and it doesn't have to "get" them to help, it just has to "enable" them to help
DanaG: oh yeah, that reminds me... is there any way to make VESA not totally kill KMS?
DanaG: If I try to use a KMS kernel, and Xorg fails to start... Ubuntu oh-so-helpfully tramples it with VESA.
suokko: DanaG: That is failsafe settings in GDM
suokko: So you have to look at gdm configuration
suokko: (or xdm or kdm)
_Groo_: airlied: backtrace from x http://pastebin.ca/1468255
suokko: But for me VESA at least saved me from restarting computer when I had forgot to add fbcon to /etc/modules
suokko: _Groo_: Can you install debug symbols?
_Groo_: suokko: not right now :(
_Groo_: adding modes in kms is not in the code yet, correct?
_Groo_: auto adding i mean
suokko: I think xrandr should work
_Groo_: suokko: xrandr only brings me the maximum resolution (fortunatelly)
_Groo_: suokko: what im saying is for kms to detect and set all modesets for my card, like x/xf86 used to do
suokko: It does detect mine
[Enrico]: mine too
suokko: _Groo_: http://wiki.debian.org/XStrikeForce/HowToRandR12
suokko: You could also try to add modes with xrandr
bridgman: rah, most users have zero interest in OS development
bridgman: attracting developers to the free software movement seems like more of a winning strategy than trying to convert users into developers
_Groo_: this is my xorg, could anyone take a look http://pastebin.ca/1468266
_Groo_: is the subsection in monitor needed? it wasnt in dri1
rah: bridgman: I'd agree with that, I just think there are dangers involved in attracting them with money
DanaG: Too bad vesa UN-modesets the consoles!
airlied: i'd love if we had money to attract developers
bridgman: rah; agreed, there are always dangers when you mix commerce and causes
bridgman: when it's done right commerce lets the cause prosper
suokko: DanaG: But at least you can get rid of that failsafe gdm launch
airlied: we barely have enough money to hire the developers we've already attracted.
rah: bridgman: also, the word "need" keeps being used, as if there's been some sudden change which necessitates the rapid expansion of the number of free software developers, at any cost
rah: bridgman: but I don't think there is such a need
airlied: rah: there is a need, as there are commerical interests at play
bridgman: maybe expectation is a better word; you expect a growth in adoption, that needs growth in features
airlied: they might not be the needs you want, but they do exist
bridgman: and growth in features need growth in developers
_Groo_: airlied: does kms/dri2 exposes all modesets or not? is it a problem with my xorg.conf or it just not there yet?
suokko: rah: Hardware is getting many tiems more complex so software is getting many times more complex too (or no support for new hardware)
airlied: _Groo_: its just LCD panel, you can add modes by hand for now I think
bridgman: and in the dumb questions department, does kms even look at xorg.conf ?
airlied: we need to fix it at some point
airlied: bridgman: yes
rah: airlied: those needs are not the needs of the cause of free software
airlied: once X starts
airlied: rah: free software doesn't care if devs are paid or not
_Groo_: airlied: so no automatic modeset for now.. oh joy ¬¬
rah: airlied: that's my point
airlied: but paid devs can do more work, and if the money is there I'd rather pay them
bridgman: and is the ddx that actually looks at xorg.conf then calls down to kms, or does kms go look itself ?
airlied: bridgman: still on ly X
airlied: bridgman: before X starts it doesn't get looked at
bridgman: thanks
airlied: X still does all the mode selection like it always did
airlied: we give it the EDID
rah: airlied: money isn't free
_Groo_: airlied: fbos are still broken in rs485 right?
airlied: rah: "if the money is there"
bridgman: rah, I think money meets RMS's four freedoms ;)
airlied: _Groo_: no iae haven't tested them, my rs480 is in a cardboard box
suokko: rah: and food isn't free :)
rah: bridgman: hah!
airlied: RMS gets money
_Groo_: airlied: i tested it, with some games and mesa tests.. its broken unfortunatelly
airlied: he's not exactly living hand to mouth
rah: airlied: RMS won an award, which allows him to live
_Groo_: guys its pointless trying to overcome the desktop world confronting both apple and MS.. money talks unfortunatelly, the netbooks proven that once again
rah: airlied: but assuming he was paid a salary by a company, what do you think he would do if they asked him to damage the interests of free software?
airlied: rah: well consider the pay devs get an award.
_Groo_: the only way linux can get market share is by doing what we are already doing.. developing great features and products and doing viral marketing and word to mouth
rah: airlied: compare that to what the average career developer would do if his employer asked him to damage the interests of free software
bridgman: rah, I don't know any dev working in this field who would do something they felt was destructive to the common good
airlied: rah: lots of developers get paid to damage the interests of free software
bridgman: all the devs I know are OK with "whoever does the work gets first dibs", but that's about it
airlied: rah: they all have jobs in Apple and Microsoft
rah: airlied: this conversation started because bridgman was talking about the influence of enterprise customers
_Groo_: linux in the enterprise is another story.. there we have voice and weight... like i said, money talks big
airlied: I think you can't take it as a generic "enterprise customers"
rah: airlied: if all free software developers' pay was considered an award, enterprise customers would have no influence
airlied: each case needs to be examined
bridgman: airlied; context was "why don't we just junk user modesetting and switch everyone over to KMS and Gallium3D today"
airlied: bridgman: because I get paid not to :)
bridgman: yeah, that's kinda what I was trying to explain ;)
airlied: but they 2 hrs a week I spend on keeping the old codebases going is outweighed by 4x+ hrs a week I get to spend on other stuff
_Groo_: might try a diferent approach to lure radeon devs to fix is poor rs485 , PROSTITUTION :D
rah: hmm
airlied: its an rs485, a bin is an improvement
rah: money is trouble enough
airlied: and I also get to feed my family.
_Groo_: airlied: dont be cruel, i dont have the money to change my poor old trusty notebook
rah: prostitution? I don't think that's going to help the cause :)
DanaG: grr, I wish somebody would make a cheap expresscard-to-PCIe breakout box that doesn't come with a friggin' video card already in it.
_Groo_: rah: im interested in helping me :D and all that are cursed with rs4XX cards..
DanaG: And didn't cost boatloads of money.
rah: not that I don't know of instances where sex has been used to influence people within the community
suokko: _Groo_: I remember some talk about r385 being problematic ...
_Groo_: rah: there are only two forces in the world.. sex and money.. all the rest are pocket change
_Groo_: suokko: rs485 is a evil card! evil i tell you!
DanaG: argh, I wish somebody would make an expresscard sound card with the C-Media chip in it.
rah: _Groo_: I disagree
_Groo_: curses the rs485 devels and engineers, may they children bare no fruit, and they swan be swept from the earth!!!
bridgman: I think there are four influences; sex, money, showing you're smarter than everyone else, and making that new laptop you were given work properly
airlied: _Groo_: it was probably designed 8 years ago
suokko: lol :)
airlied: they've all forgotten it
_Groo_: bridgman: thats in geek work.. i was talking outside geek world
bridgman: ok, so forget about the laptop then
_Groo_: bridgman: :D
rah: I disagree with that, too
bridgman: and maybe move sex closer to the end of the list
suokko: is trying to make my old laptop to work better than before
suokko: :)
_Groo_: is trying to make is rs485 work like it was suposed to.. but is starting to discover it was suposed to work at all :(
_Groo_: wasnt
DanaG: I'd agree with that... move 'it' to the very end.
rah: there is more at work within human beings that just money, sex and prestige
_Groo_: rah: true, there us greed, petty vengeance and oprah
_Groo_: is
chithead: and ofc making that new laptop you were given work properly
soreau: bridgman: heh
rah: _Groo_: I would say you have a disproportionately negative view of human beings
_Groo_: airlied: tell you what.. you fix rs485 suspend to ram, modesetting and fbo and ill send you a cake!
suokko: Like question how to play K8x vs AJ9xx ;) Who wouldn't love bridge problems? Really anyone? :)
DanaG: doesn't know what K8x and AJ9xx are.
DanaG: =þ
rah: anyway
_Groo_: rah: you should live in brasil then.. then youll see what mankind is all about
rah: I need to sleep
rah: 'night
rah: -> zzz
bridgman: bye
bridgman: Groo; tell you what, I
_Groo_: rah: here they will kill you in a heartbeat for $5 or a pair of sneakers
suokko: DanaG: apt-cache search bridge :)
bridgman: I'll try to get agd5f another machine for admin stuff so he can use the rs485 laptop we gave him for Linux work
DanaG: Bridge as in that thing with cards and pegs?
bridgman: pegs ?
DanaG: oh wait, that's cribbage.
_Groo_: lol
DanaG: or something.
suokko: yep :)
suokko: biding boxes etc :)
_Groo_: bridgman: send me a laptop with a working ati card and ill happily ship mine to airlied
bridgman: ooh, I have an old thinkpad with an M9 or something ;)
bridgman: it's... um... very clean
DanaG: I like being able to play neverball with my laptop. =þ
DanaG: Not on..... with.
suokko: wow. something new in repository. dds :)
_Groo_: btw how can i list all modesets my card supports?
DanaG: er, "not "On" my laptop, but "With" it.
airlied: _Groo_: it can support nearly any mode
chithead: _Groo_: if you use a digital panel, some chipsets do not support higher resolutions than native though
_Groo_: airlied: ok, new question, dri1 showed me at least 10 modes, i supose they where the default ones
_Groo_: airlied: how can i dump them so i can add them to xorg
suokko: xrandr
suokko: only that in console
_Groo_: xrandr only shows whats configured or manually added.. not the ones you can use
suokko: (If you did boot with radeon.modeset=0)
_Groo_: suokko: without :D rebooting
DanaG: Now all I need is a disk-protection daemon. =þ
mekius: sigh, I really need to figure out where this mem leak is coming from
_Groo_: bridgman: thinkpad??? THINKPADDD!!!! aaaaaaaaaahhhhhhhhhhhhhhhhhhhhh
DanaG: uses "£€€T" instead of "1337".
DanaG: yeah, that's random. I went from thinking: Thinkpad -> EliteBook -> Leet.
_Groo_: bridgman: why dont yo send me a zune instead :D shitty stuff per shitty stuff
bridgman: 'cause I don't know what kind of GPU it has, but I'm pretty sure it's not one of ours ;)
bridgman: how about a Wii ;)
_Groo_: bridgman: huuu a wii.. nice oO
bridgman: I know we did *that* GPU
_Groo_: wants a wii
suokko: Can anyone send a PS3 for me? I could test Gallium with it :)
_Groo_: is almost switching for the green side ¬¬
_Groo_: suokko: nice try :D
_Groo_: to, not for
DanaG: Ironically, with my laptop, I had to pay the "customize to order" fee because I specifically wanted ATI.
suokko: To obad I don't have any TV or display for it
_Groo_: master is the green side more powerfull? no, not more powerfull, easier, quicker...
DanaG: None of the preconfigured models had ATI with WUXGA (1920x1200).
DanaG: For this laptop, the ATI card uses less power than the nvidia one would have.
_Groo_: DanaG: im paying with sweat and tears ever since i bought this )(*@()#*@(# with rs485 ;(
DanaG: That's the xpress200?
DanaG: goes off to dinner.
_Groo_: DanaG: dont say the green word in here!!! the devs start throwing kitties around!!!!
_Groo_: DanaG: yep, the evil one
suokko: Radeon 9200 has been extreme lucky investment from me :) It has always worked very well
_Groo_: suokko: give it up, he wont send you a ps3 :D
suokko: Except now with KMS when I volunteered to beta test
_Groo_: suokko: im testing it since glisse posted how to bake it
_Groo_: suokko: and being beaten every step of the way
suokko: I know ;) But PS3 with some ATI GPU would be nice linux hardware ;)
_Groo_: sets himself with a wii
bridgman: actually we're kinda green now as well
bridgman: it's really wierd
_Groo_: bridgman: hu? oO
arggg: I can't get a Radeon 9000 to work with current git drivers :/
bridgman: AMD green is fairly close to NVidia green
arggg: sadly scrapped his low-power using RV250 for a monsterous R400....
_Groo_: bridgman: ah..
bridgman: I assumed they would keep the logo but change the colour to ATI red
arggg: bridgman: the thing about nvidia that isn't green is using nearly twice the electricity in the same performance envelope
_Groo_: bridgman: ehehehehe
suokko: arggg: It was problematic for me too. And till a bit buggy
suokko: But I think it is possible with 9000 too
_Groo_: all r4xx are evil...
bridgman: arggh; yeah, it's funny really - we start working on new chips 3 or 4 years before they come out, so there's a lot of guessing about what the market priorities will be
bridgman: I'm always amazed how close the products are when they come out 4 years later
suokko: airlied: Do you know what TTM memory allocation can fail if there is very heavy disk IO?
arggg: bridgman: so at what point will the cards be full developed in AMD?
_Groo_: bridgman: thats true
suokko: (ext3 causing some in kernel latency)
bridgman: arggg, don't understand the question
arggg: bridgman: well if your pipeline is 3-4 years long that means much of what has come out now started at ATi.
arggg: When will this cease to be so?
airlied: suokko: we do some order 4 allocs in radeon I Think
airlied: need to change them.
bridgman: I guess the next generation probably started around the time we joined AMD
bridgman: but it's all the same people still designing and planning the GPUs so other than the logo on the design docs I don't think it makes much difference
_Groo_: bridgman: you didnt join, you were bought.. much like oracle isnt "joining" sun
arggg: right but AMD doesn't bring any more resources to the table to help out? :)
suokko: airlied: I did post backtrace from failed allocation earlier today if you want to see it :)
_Groo_: bridgman: true.. that would be stupid of amd, to split the team
airlied: suokko: oh yeah that might help
suokko: (Kernel backtrace) Xorg log didn't have anything
suokko: http://pastebin.com/m174b4c3f
bridgman: yes and no; the main difference is that we are now working a lot more closely with the CPU folks on Fusion parts
suokko: Also my system had hard lock a bit after that last error
bridgman: it wouldn't be practical to do that as two independent companies
arggg: bridgman: I've been waiting to see that for a while -- since the aquisition
suokko: (a bit=about 3 minutes judging from syslog)
arggg: I sencerely hope that I won't have to wait until 2011
_Groo_: bets MS will buy nvidia soon
_Groo_: thinks nvidia already acts like a MS subsidiary anyway,...
arggg: _Groo_: why is that AMD tends to beat them recently on having new D3D specs implemented?
arggg: one would think the "subsidiary" would be there first ;P
bridgman: we're smarter and better looking ?
_Groo_: arggg: thats irrelevant... the new zune hd is using nvidia, xbox uses nvidia... its only natural for ms to buy them eventually.. intel cant and amd wouldnt.. so...
arggg: _Groo_: xbox uses nvidia?
arggg: since when?
suokko: I think nvidia is more like uing same marketing tactics that MS is using (trying to make as many independent developers to ue teir products in development)
_Groo_: arggg: it doesnt? let me check
arggg: the later xbox 1's use ATi cards, and the 360 uses a pre-R600 chip
chithead: if ms wanted to buy nvidia, they would screw them badly first. so that stock price falls
_Groo_: arggg: ati xenos..
_Groo_: arggg: i thought they used nvidia
chithead: of the current-gen consoles, only the sony ps3 uses nvidia
_Groo_: chithead: ahh its the ps3! i was confusing them
_Groo_: bridgman: so are you sending me a wii for my ahrd work beta testing and annoying you guys?
arggg: bridgman: I note the speculation on using z-ram for cache in AMD cpus -- may that happen to give us really really fast framebuffer space on say R8/9/whatever00? :P
suokko: btw, IS it possible to install linux&get oss driver support with Wii? :)
_Groo_: suokko: ive seen some demos of wii with compiz in youtube
chithead: the answer to this question is found by a simple google search
_Groo_: chithead: just use bing! ehehehehhe
_Groo_: what is the other command besides gtf to show modelines?
bridgman: arggg; if we were I couldn't tell you anyways ;)
bridgman: Groo; no ;)
_Groo_: is thinking in taking amd to court for all the pain rs485 gives him
_Groo_: the crying, the shouting, the name calling..
_Groo_: no .. wait.. thats my marriage :D
bridgman: Groo; works real nice under Windows, which is all we ever sold that with ;)
bridgman: seriously, guilt works much better than the legal system here ;)
bridgman: that's kinda how I got involved; I was watching the Avivo devs working and kept wanting to yell out "no, that's not how it works, you need to set *that* register !!!"
bridgman: but I couldn't
suokko: Seems like ATI won't publish specification for Hollywood
bridgman: it's not ours to publish
bridgman: we're *very* careful about that kind of IP
bridgman: it's even firewalled inside the company
_Groo_: bridgman: nahh altough rs4xx is really evil, i kinda enjoy helping out and learning something in the process. i sure as hell wouldnt waste so much time helping nouveau for ex
DanaG: I'd imagine you have separate teams entirely.
bridgman: Groo; there sure is a heck of a lot to learn, isn't there
DanaG: But once that project is "done", how do you not let the ideas leak into other projects?
bridgman: DanaG; separate cities and everything
_Groo_: bridgman: and dri2/kms + 3d desktop is awesome... i like being in the cutting edge... but i got a lot of cuts :P
DanaG: Hollywood -- is that Wii, or XBox360?
bridgman: only a very small team knows all the secrets, and they know not to talk
bridgman: Wii
suokko: Wii
bridgman: XBox360 is Xenos
DanaG: oh yeah, so was R600 derived from the "pre-R600" chip in the 360?
DanaG: The biggest thing that bugged me about the AMD-ATI acquisition was that they had changed the ATI site from red... to green.
DanaG: So it changed from red versus green, to .... green... versus green.
bridgman: yes, although development for the two happened in parallel to a certain extent
bridgman: agreed; it's a lot harder to find us at trade shows now
bridgman: it used to be easy; Intel was blue, NVidia was green, and we were red
_Groo_: bridgman: just follow the smoke... heheh old sun joke
DanaG: They really should change it back to red.
bridgman: ;)
suokko: bridgman: You just have to use Ruby ;)
bridgman: nah, the Ruby girls kinda wander around; half the time they're walking away from the booth
_Groo_: for those two young to remember... sun had/has a reputation for their servers bursting into beautiful flames
bridgman: but there's usually a crowd following them
DanaG: If I had to get a desktop, I'd honestly get AMD CPU and chipset, even if the performance didn't quite match Intel.
DanaG: I liked the fact that ATI implemented standard AHCI before nvidia did, for example.
DanaG: and nforce ethernet.... data corruption. hah.
DanaG: hmm, does ATI have good contacts with Asus? I really wish they'd make an ExpressCard sound card!
DanaG: USB audio sucks.
bridgman: we definitely have contacts but probably not on the audio side
suokko: _Groo_: Sun's old hardware is still running in my school :) (Sun OS with motif X)
DanaG: hmm, just a random product idea, that's all.
DanaG: Graphics in laptops can be pretty badass... but audio generally sucks.
chithead: creative produces expresscard sound adapters
DanaG: Ugh, Creative is scum.
chithead: but their linux support is not so great, yet. although it is improving
suokko: Now there is going on move freebsd in CS building ;) All others unixs workstation hs been changed to run ubuntu
DanaG: What else do you call it when they deliberately break functions, call it "not supported, because of Vista", and then go behind everybody's back to give Dell drivers that had the feature working?
chithead: "market segmentation"
DanaG: But they were features that had worked before in the beta drivers, that expired a week before the replacement drivers.
_Groo_: suokko: they tend to burn in high level sparc servers.. but that was in the days...
DanaG: So, people were left without working audio for a week.
bridgman: honestly, it usually means they were struggling to get the support running, had a separate bug fix branch for Dell, ran out of time and had to make the feature work in the Dell branch in order to meet schedules
DanaG: But the thing was, that they actively removed the feature, and then LIED about it, saying it was "a fundamental limitation of Vista".
bridgman: ahh, I wasn't following that
DanaG: anyway, if you want an example of how NOT to treat customers... go to their forums about Vista.
DanaG: =þ
_Groo_: DanaG: or buy a rs485 (couldnt resist) lol
DanaG: Different sort of issue entirely.
_Groo_: DanaG: i was joooookiiiiingggggggg
_Groo_: bridgman: remember of the garbled screen bug? you promised to port vbetool to 386 so i could debug the darn thing
_Groo_: dri2/kms will launch and all the millions rs485 costumers wont have suspend to ram!!! magine that!! the riots!
airlied: _Groo_: didn't we figure out it was just your laptop?
chithead: I doubt that there are millions of rs485 users on linux
_Groo_: chithead: shhh he doesnt know that
bridgman: I think there are 27
bridgman: 26 if Groo drops his laptop
_Groo_: airlied: how so? if i remember correctly thete was at least one more bug report
bridgman: 28 if agd5f gets fed up with Windows
airlied: but i dont think it was all rs4xx
_Groo_: bridgman: now that is srarting to look good? dri2/kms and you want me to drop it? over my cold dead hands
DanaG: mood swings?
DanaG: =þ
_Groo_: airlied: so, since it just my laptop, leave groo to rot?
_Groo_: rott? rot?
bridgman: rot
bridgman: airlied, do you need an Xpress200 laptop ?
bridgman: ;)
_Groo_: airlied: bridgman: the ironic thing is that it used to worked till somewhere between november/dec 2008 and now... some update to xf86 in dri1 break it
_Groo_: bridgman: you.. you...
bridgman: somehow the open source development model (lots of independent components, rolling releases, no "big bang" release that syncs all the components) seems in direct conflict with the variant of Murphy's law that says "if you mess with something long enough, it'll break"
_Groo_: bridgman: preferably an acer 5102 with the bios ver 3.13
suokko: _Groo_ If you know working combination you could use git bisect to find which commit broke everything. That simplifies fixing a lot usually
_Groo_: bridgman: but it does break, but since its open source, the ppl who get the breakages can do something to fix it before a oficial release or short after
_Groo_: suokko: i tried that,., do you know how many combinations there are in such a time frame?
bridgman: Groo, agreed, but the code is really freakin' big
_Groo_: suokko: but bridgeman might have hit the nail, since he told me that most probably it where the acpi changes...
_Groo_: bridgman: so does the annoyed ppl :) many eyes make the bugs shallow
bridgman: I have to go chop vegetables for a while, if you hear a scream it was the scotch bonnet peppers getting into my eyes
_Groo_: bridgman: use protective glasses
arggg: bridgman: how warm does it get up there in the summer?
DanaG: where was "there", anyway?
_Groo_: DanaG: valhalla
bridgman: "there" is about 50 miles northeast of Toronto
bridgman: it's getting up to about 80F during the day
_Groo_: bridgman: degrees pelase
bridgman: 27-ish
_Groo_: bridgman: cold
bridgman: although F is degrees as well, just degrees F instead of degrees C ;)
bridgman: but it's been raining non stop, outside is supposed to be pine forest but it looks like tropical rain forest
DanaG: =þ
bridgman: all kinds of ferns and things I never imagined seeing in Canada
_Groo_: bridgman: i know
bridgman: and that slightly lighter green that tells you everything is growing insantely fast
bridgman: insanely
_Groo_: bridgman: ahh the wonders of global warming..
bridgman: why do they call it global warming if everything is cold and rainy ?
_Groo_: bridgman: do a simple experiment
bridgman: and 10F colder in winter than ever before ?
bridgman: not hot water in the freezer
_Groo_: bridgman: boil some water.. wait a little and drop some ice cubes.. but keep the water boiling.. what happens?
_Groo_: bridgman: it gets cold before it gets hot.. global warming is melting the ice capes.. which melt and make the sea colder... ence changing the climate in less predictable ways
_Groo_: bridgman: also, if you are in a forest area the tendency is the get cold because of the water condensation in the atmosphere
chithead: an interesting theory
_Groo_: bridgman: ironically and cruelly for poor countries, cold countries will get colder and with more precipitation, hotter countries will get hotter and dryer... horrible to africa :(
bridgman: Groo; wouldn't colder oceans result in less evaporation and less precipitation ?
_Groo_: so many will die... :(
bridgman: I really think the name has to change; right now nobody takes it seriously
bridgman: which is bad
suokko: Also one theory says that there will be more snowing noth and south pole so warming will cause deeper ice in poles :)
_Groo_: bridgman: but thats the problem.. the carbon dioxide in the atmosphere dont let the planet to cool down.. so you get more water condensation but no cooling device.. ence the hurricanes, strong rains etc etc
DanaG: how about "climate randomization"
DanaG: or something.
_Groo_: suokko: that has to do with what i said
_Groo_: DanaG: no, not randomization..
DanaG: Something to imply that it does crazy screwed-up weather things.
chithead: _Groo_: many misconceptions exist on climate change, I suggest that you read the ipcc report, they have a condensed version for policy makers
_Groo_: DanaG: just read latest national geographics and nature site
DanaG: well, the weather in my area seems rather random, in recent years.
_Groo_: chithead: thats for bureucrats... and north american ones
DanaG: One day it'll be 80, and the next it'll be cold and gloomy/.
_Groo_: DanaG: if you live in a cold area with temperate weather, you will see more rain and hotter summers
_Groo_: DanaG: because the air humidity gets caught in the forests
suokko: is more interested what happens to the large current in Atlantic. It might turn very cold in north Europe if warm current stops coming this north
_Groo_: DanaG: if you live in a hot zone you will see even more rain followed by incredible temperature rise and dry air.. because the humidity isnt trapped anywhere
_Groo_: suokko: my problem isnt the currents but the salinization break point.. which we are close to achieve!
_Groo_: suokko: now.. THAT will be a world catastrophe
_Groo_: anyway, i need my rs485 working by then so i can trade it for food!
_Groo_: thats my master plan
_Groo_: brb... smoke time..
suokko: _Groo_: I think there is very well know solution to degradation problems. But they make it harder to harvest&less production in short term so not very popular
suokko: Just don't make very large continue fields and don't try to get 150% production from fields like current trend is.
DanaG: here's one thing that could save a hell of a lot of energy worldwide: make all P4s simultaneously disappear from the face of the earth, magically.
DanaG: Well, except for those where people wouldn't be able to recover (i.e. don't have another computer).
DanaG: Or if you feel like being funny, you can call it a "PIV", which I keep wanting to pronounce as... piv
suokko: bridgman: What has happened for your astro-picture(s)? :)
_Groo_: suokko: ehehehe
_Groo_: DanaG: lets go crazy, ban all intel chips from the face of the earth
DanaG: No, the newer ones are fine.
_Groo_: DanaG: or lets go galactica style.. lets abandon technology all together
DanaG: P4 is the only "EVIL" one.
bridgman: suokko; they're on that laptop with the M9, or at least they were until I nuked XP
_Groo_: i gotta go ppl,
_Groo_: bridgman: one last idea for my bug...
_Groo_: bridgman: is it possible to tell radeon not to post the bios for rs485?
suokko: So you have broken link in your website because of nuked machine
bridgman: no, I have broken link in my website because I forgot I had a website ;)
_Groo_: bridgman: and just let the bios do her thing.. maybe that fixes the suspend
bridgman: possibly, but that would really be an agd5f question
bridgman: I think there are some options already; every system seems to take slightly different voodoo to resume properly
bridgman: although maybe if everyone did it the same way things would get easy, who knows ;)
DanaG: OOoooh, fglrx 9.6 fixes the screwed-up colors in xv under compiz!
DanaG: Oddly enough, though, 2X scaling in mplayer is still cpu-intensive.
DanaG: How does mplayer do its video scaling, anyway?
suokko: DanaG: I think mplayer tells it in console
bridgman: depends on the output -x11 is CPU, -xV and gl have the GPU do most of the work
DanaG: It's on xv, but under compiz.
DanaG: oh, I see.. it was ntfs-3g eating CPU that was making it slow.
DanaG: Stupid ntfs-3g.
_Groo_: DanaG: same thing... xv used 2d which is actually some special 3d calls
_Groo_: DanaG: gl2 might give better cpu usage dependes on the gpu and the radeon implementation of the calls
DanaG: Right now I'm using fglrx, actually. radeon on r600 == no compiz. =þ
DanaG: But the mplayer-specific part is/was still relevant.
bridgman: there's a specific mplayour output option for gl that I can never remember which apparently works best
bridgman: I really should write it down some time
DanaG: hah, zoomdesktop works better than mplayer's own scaling.
_Groo_: DanaG: what are you talking about? latest fglrx have dri2
_Groo_: DanaG: so. compiz.. even older fglrx had composite support, just no dri2
suokko: -vo gl or -vo gl2 both not very nice
suokko: -vo sdl?
bridgman: DanaG means "open source on r600 = no compiz"
bridgman: -vo gl2 with something else on the end, I think
_Groo_: bridgman: ah ok.. because he said he was on fglrx no compiz
bridgman: maybe a certain colour format
bridgman: ahh, I missed that
DanaG: yuv12?
[Enrico]: <_Groo_> latest fglrx have dri2 <--- O_O since when?
DanaG: or something like that?
_Groo_: bridgman: btw was it your call to release dri2 in last fglrx for older cards?
_Groo_: [Enrico]: inside the driver.. ask bridgman
_Groo_: [Enrico]: dri2 alike.. not dri2 code per se..
[Enrico]: _Groo_: oh that's makes more sense :D
_Groo_: [Enrico]: so you can now enjoy fglrx without the fighting/tilting windows we have when we use composite and some opengl app
bridgman: Groo; I asked the devs to "try real hard"
[Enrico]: btw on r6xx composite works with kde4 and xrender backend (but slower than with opengl but for that fglrx is needed atm)
bridgman: and crossed my fingers
_Groo_: bridgman: that was cruel... releasing dri2 with last support.. like giving a candy and taking it away
_Groo_: bridgman: i was so pissed :D
_Groo_: bridgman: i was already using oss radeon but i was pissed nonetheless
DanaG: ah, just gl2 is fine now.
_Groo_: world of goo works very well with dri2/kms :) i love it
_Groo_: the stupid little goos are so adictive :)
bridgman: really ? would you rather not have had RDR at all ? serious question
bridgman: we worked real hard to get RDR out before the cutoff
bridgman: "we" in a figurative sense; I didn't do anything ;)
_Groo_: bridgman: i didnt had it.. you guys release it days before xorg changed. if you had add 1.6 support.. yeah it would be sweet , but it was born dead :(
_Groo_: bridgman: im not bitching just saying
_Groo_: bridgman: i much prefer radeon anyway :)
_Groo_: bridgman: since every modern distro changed to 1.6 short after... ubuntu/fedora/suse
_Groo_: bridgman: so i would be stuck.. stay in 1.5 forever or loose fglrx.. well.. i just used radeon :) and its amazing how well it works :)
bridgman: got it... yeah, we tried to get 1.6 in but there was just no way it was going to happen
bridgman: we didn't control the schedule; those GPUs were dropped for all the other OSes as well
[Enrico]: don't forget the missing >= .29 kernel support
_Groo_: bridgman: like i said, i dont blame you devs... you dont control release schedules or features.. those are the evil pointy haired bosses
_Groo_: bridgman: but even green empire supports new kernels/xorg when they get out for the legacy drivers
_Groo_: bridgman: true that the gren open source drivers dont even get near the radeon ones in terms of quality or features
_Groo_: bridgman: and amd did release the specs.. so...
_Groo_: bridgman: overall a temporary inconvenience :)
mekius_: bridgman: So will we ever see the open source driver reach the level of performance of fglrx, or is that just never going to happen?
_Groo_: mekius_: never say never but it will take a while
suokko: Is same GPU state initialization code used with DRI1 and DRI2?
_Groo_: mekius_: i just hope the generic optimizations arent too far away... but i believe dri2/kms will reach its tipping point (stop adding basic features and add optimizations and more features) by the end of 2009
mekius_: _Groo_: For sure it will take awhile, of course AMD could be really generous :)
_Groo_: mekius_: how so?
mekius_: _Groo_: That would be really spectacular
[Enrico]: mekius: probably never, but with llvm it can be very close. i've said never becouse llvm is a general pourpose compiler, not a radeon specific one
bridgman: mekius; I think the performance will get close enough that hardly anyone will care
mekius_: _Groo_: Open code form fglrx (given it's even possible)
mekius_: err useful that is
_Groo_: mekius_: not possible... they have a lot of proprietary code in there.. patents and such... im amazed they could publish the specs!!
mekius_: Well the specs they've released are mostly hardware level no?
_Groo_: mekius_: and we are in better shape then the windows world.. they dont have a radeon driver to support the old cards...
bridgman: I don't think the devs want the code; it's shared code across multiple operating systems (so it's big and not easy to maintain)
mekius_: _Groo_: That's true :)
mekius_: bridgman: I can imagine it's not pretty :)
mekius_: But I'd imagine all the customized optimizations are pretty much the same no?
bridgman: it's quite clean, but it's *big*
mekius_: yeah
bridgman: there's just a lot of optimizations, and very few of them are simple
_Groo_: bridgman: will the power management and multiple cores spechs ever see the light od day?
mekius_: I'm sure
[Enrico]: amd has donated some piece of code too, but not the fglrx one
bridgman: and very few of them are specific to our hardware
mekius_: [Enrico]: Yeah
bridgman: power management there will definitely be more
bridgman: multple cores, you mean crossfire ?
_Groo_: bridgman: yes, i forgot the oficial name
bridgman: that's about 99% software
_Groo_: bridgman: exactly ¬¬
mekius_: I'm kinda new around here, is anyone from AMD committing code to radeon/radeonhd as part of their daily job?
[Enrico]: anyway gallium3d and llmv should (and i say should couse it can be a dead end) provide a level of performance really near to the windows driver, and this will be a great steap forward
bridgman: the only hardware is a couple of special pipe-mapping modes (which we published) and the dedicated link to squirt data between the cards rather than having to go over PCIE (which I haven't found yet)
_Groo_: mekius_: bridgman and ajax?
mekius_: _Groo_: I'm new so I really don't have any idea :)
[Enrico]: mekius: 3 amd guys are working completly on radeon driver atm
_Groo_: [Enrico]: dont forget airlied and fglisse
[Enrico]: airlied is from redhat if i remeber well not from amd :D
_Groo_: and groo whos the rs485 test smuck
mekius_: I have used intel for the past few years, had an ati card before, but at that time I generally used fglrx and it was a bit messed up back then ;)
_Groo_: [Enrico]: exactly, im talking about devs not amd only devs
_Groo_: mekius_: it was very messed up.. is better now
[Enrico]: _Groo_: oh well mekius has asked for amd devs if i have understood well :D
mekius_: Yeah I've heard airlied's name before
bridgman: mekius; Alex Deucher, Richard Li and Cooper Yuan
bridgman: http://cgit.freedesktop.org/mesa/mesa/log/src/mesa/drivers/dri/r600?h=r6xx-rewrite
[Enrico]: mekius: airlied (David Airlie) is a smart guy :D
mekius_: _Groo_: Better, but seemed to still give me some headaches when I tried it recently
mekius_: I have a CRT monitor and had a hell of a time getting it to take my modelines heh
[Enrico]: and glisse too, they are mentioned on phoronix quite frequently
mekius_: [Enrico]: I got that impression when reading his posts :)
mekius_: Someone telling me decent 3D support is likely before the end of the year makes me happy :)
_Groo_: mekius_: i said the beginning of the work by years end.. not finished optimizations!!
_Groo_: mekius_: and im just guessing based on what ive seen so far and the pace of the develiopment
mekius_: oh, thought basic optimizations would be done by the end of the year :D
mekius_: misread it :)
bridgman: honestly, everyone is worrying *way* too much about optimizations and nowhere near enough about making the program run in the first place
bridgman: there are only two milestones that matter IMO :
mekius_: oh I am certainly more worried about it working at all :)
mekius_: Want to get something out of this $150 card :)
bridgman: - getting current level of 3D functionality running on 6xx, since (a) it's pretty useful for a lot of people, and (b) once it works in one stack it can be chopped up and moved to another stack much more easily
bridgman: - getting GLSL and vbo/fbo etc running, so that pretty much all the apps out there can run - this will probably need Gallium3D and definitely need KMS/GEM/TTM
mekius_: so essentially kms/gem/ttm and gallium should be ready to rock starting next year? :)
bridgman: yeah, kms/gem/ttm is the big focus right now, and once it's in broad use it becomes possible to start switching end-user drivers over to gallium3d
mekius_: bridgman: nice :)
bridgman: just to be clear, those Gallium3D drivers have generally not yet been written. AFAIK the only complete ones today are for the Intel 915 and the Cell chip
bridgman: but MostAwesomeDude has made a lot of progress on a Gallium3D driver for 3xx-5xx, and once we have a Gallium3D driver for 3xx-5xx and a classic mesa driver for 6xx-7xx it can't be *that* hard to put the two together ;)
[Enrico]: agree totally :D