matteo: hi all
matteo: when I use the radeonhd driver all is black
matteo: if I log in via SSH there are no errors in the logs
matteo: just the screen is black
matteo: weird
matteo: it works with the ubuntu package
matteo: i'll keep it then
matteo: I was using a self compiled from git
udovdh: maybe get a version in between the ubuntu package and the git version?
udovdh: then you could get closer to the patch that makes it fail at your system
udovdh: another thing would be to do the `X -logverbose 7` thing with both the ubuntu and git version
udovdh: and compare the logs for differences
cbalint: hello
cbalint: anyone can tell in how is the state of RS680 (HD3200) ?
cbalint: saw mails on suse freedesktop that some work are in progress
cbalint: another Q, since i unpatient can anyone tell if i buy radeonhd compatible card will opengl work smooth on it ?
dmb: opengl doesn't work at all yet with radeonhd
dmb: work in progress
tulcod: cbalint: there's a chance it works fine with fglrx...
tulcod: cbalint: but I wouldn't put my money on it
cbalint: dmb, may i ask when is excpected some opengl support ?
dmb: nope, i'm not a developer
cbalint: tulcod, rs680 is so new that i need very latest kernel for SATA wich doesnt compile fine with ATI's proprietary blobs
cbalint: at last i wasnt able do it agains newer kernels
tulcod: cbalint: if you need opengl support within 3 montsh, forget it
tulcod: 2d acceleration doesn't even work for all cards (at least not in a release :P)
cbalint: thanks for the info anyway, i'll wait.
tulcod: cbalint: in that case, well, they're working on it
tulcod: cbalint: 2d acceleration support is in git
the-me: hmm
the-me: exa was the newer 2d rendering method, or not?
the-me: (and faster)
libv: usually not faster :)
the-me: (**) RADEONHD(0): Selected XAA 2D acceleration.
libv: which is the default, because when the card is not agp it is actually not too bad
tulcod: the-me: not *yet* faster, but it's supposed to become faster
the-me: would I save battery power if I force exa (like at scrolling with firefox)
tulcod: the-me: eh, I don't think so
the-me: tulcod, I rember the phoronix benchmarks, there it was multuiple times faster
tulcod: the-me: wasn't it multiple times slower?
the-me: hmp, I'll search the thread..
tulcod: the-me: http://www.phoronix.com/scan.php?page=article&item=981&num=1
tulcod: it's on page 4 or something
tulcod: oh lol, there is no page 4 :p
tulcod: 3
the-me: libv, can't I use with my mobility x1250 exa yet?
the-me: tulcod, thanks
libv: the-me: you can
libv: the-me: but i doubt it is worth it already
the-me: hmm okay
the-me: at switching between screens I still get this uninitialized vram issue
the-me: also if I switch to my terminal
matteo: hi all
matteo: 1.1.0 works fine for me
matteo: but latest GIT doesn't
matteo: how many chance I have that the next tag won't work either?
tulcod: matteo: depends on what goes wrong, but what's on git can't be considered stable
matteo: tulcod: I'm thinking about bisecting the tree
matteo: actually i'm using the ubuntu package
matteo: http://packages.ubuntu.com/hardy/xserver-xorg-video-radeonhd
matteo: this is the package
matteo: tulcod: how can I know on what git commit it matches?
tulcod: matteo: there will probably be a branches dir in git, check it's revision number
matteo: I remember that the 1.1.0 tag won't work either
matteo: maybe some ubuntu patch fixes it
matteo: i'll check
matteo: xserver-xorg-video-radeonhd-1.1.0/debian/patches/01_gen_pci_ids.diff
matteo: the only patch is this
tulcod: tag, branches, whatever :p
matteo: src/git_version.h
matteo: wow
matteo: #define GIT_SHAID "f213db06"
matteo: that seems the git commit
matteo: right?
matteo: and that's 1.1.0: http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-radeonhd;a=commit;h=f213db06140226c843c9649cfaaea4b3d130ba16
tulcod: matteo: the thing with git is, just try it for a week or so. once you find a revision that works for you, stick with it until there's a reason to move
matteo: well, if there is a commit that breaks it I want the devs to know
matteo: my notebook is uncommon (macbookpro) so the bug could be still in the next tag
matteo: isn't it?
metalth: trying to compile latest git radeonhd source under freebsd: http://rafb.net/p/Gjwoqd36.html - what causes that problem?
ndim: Yay. A segfault.
tulcod: metalth: up-to-date build env?
ndim: metalth: RTFM (README)
metalth: ouch, yes, this problem is mentioned in README, sorry..
matteo: how to checkout a stable tag?
matteo: git checkout 1.1.0?
tulcod: matteo: close: git checkout v1.1.0
tulcod: ...
tulcod: iirc
tulcod: not responsible for damage
tulcod: so yeah, I gtg :p
matteo: it worked without the v
matteo: git checkout 1.1.0
tulcod: k :)
matteo: 'git checkout master' resync with latest tree?
matteo: with HEAD?
matteo: I've found the commit with the bug
matteo: commit af0c64d897f7f2288419b6e43468850e1037bb59
matteo: Author: Luc Verhaegen
matteo: R5xx accel: Add XAA support.
matteo: how to disable XAA?
airlied: matteo: Option "AccelMethod" "shadowfb"
matteo: isn't shadowfb better?
matteo: commit 7e9b6ef0917932964d2be2cadd450525e9f08512
matteo: R5xx: Implement EXA.
matteo: doesn't EXA needs DRM?
airlied: matteo: nope..
matteo: (WW) RADEONHD(0): Unknown AccelMethod "EXA".
matteo: (**) RADEONHD(0): Selected XAA 2D acceleration.
airlied: matteo: making stuff not chew CPU though does require a drm.
matteo: so it's a DMA stuff?
airlied: matteo: its more of an offload engine, you can hand bunches of commands to the GPU and it processes them
airlied: matteo: instead of banging each register with the CPU.
matteo: seems good stuff
matteo: is shadowfb a compatibility option, a legacy one or a better than XAA?
airlied: matteo: shadowfb only works if you aren't doing any GPU accel at all..
airlied: matteo: XAA with XAANoOffscreenPixmaps is probably fastest for most people.
airlied: at the moment..
airlied: but really thats doing a lot of stuff with the CPU as well.
matteo: EXA should be the best thing right?
airlied: but it all dpeends on wwhat apps you run etc..
airlied: matteo: a complete EXA implementation like radeon has is probably the best.
airlied: esp if you run compositing stuff.
marcheu: airlied: fastest in _all_ case is shadowfb
marcheu: I've yet to see a driver that's faster with any accel than shadowfb
airlied: marcheu: shadowfb isn't fastest if you have a slow CPU :)
airlied: marcheu: or are doing movie playing
marcheu: we're talking 2D accel here...
airlied: marcheu: I believe he is taking general case
marcheu: and that was true on all systems I tried that on
marcheu: I don't think we should brag until one, single, 2D driver becomes faster than shadowfb
matteo: radeonhd doesn't supports Xv yet?
matteo: mplayer -vo xv fails
airlied: marcheu: you make shadowfb work with Xv and compositing :)
marcheu: airlied: compositing is on the cpu, Xv would be trivial with it
airlied: marcheu: telling users you can't play movies because you can scroll in firefox faster doesn't work for me :)
airlied: marcheu: XAA with no offscreen pixmaps is pretty close though
matteo: xvideo doesn't wrks ere
matteo: *here
matteo: checking if XV is defined... yes
marcheu: matteo: it's not implemented
matteo: ah, ok
matteo: I use -vo gl in mplayer then
matteo: it's faster than x11
matteo: even without OpenGL
matteo: maybe the mesa routines are faster than the software ffmpeg ones
matteo: --disable-atombios
matteo: is this a bad thing?
agd5f: matteo: you probably want atombios support, unless you know what you are doing
matteo: i read some comment fro novell devs sayng that atombios is evil
matteo: that it's a way to exec proprietary code like ndiswrapper does and so
werdz: for the moment it's the easiest way to get things to actually *work* though
matteo: so a replacement is planned?
matteo: replacement/workaround
airlied: matteo: yes don't believe everything you read :)
matteo: usually I don't, but novell devs aren't monkeys IMHO
agd5f: matteo: it's required for the data tables needed to properly set up your card at the very least. some would even argue it's not evil :)
matteo: if it's an API for all cards seems fine to me
matteo: (**) RADEONHD(0): Selected EXA 2D acceleration.
matteo: now should be better
werdz: if your card jumps out of your computer and starts beating you with a stick, then maybe consider it evil.. until then it's just as evil as using VESA drivers (which really just call another BIOS)
airlied: werdz: its not even near as bad as vesa drivers.
airlied: werdz: its not like it executes 16-bit code.
agd5f: werdz: but it's not a black box like vbe. you can actually see what the scripts are doing, even write your own if you are so inclined
matteo: what's teh highets VESA resolution? 1024x768?
airlied: matteo: vbe can do any res the BIOS supports
werdz: airlied: i meant in terms of "Yargh! Evil code! Die microsoft die!" :)
matteo: if the development keeps on going so we'll have the only one 100% OSS driver for a decent card
matteo: nvidia are good card with a good non-OSS driver
werdz: it wouldn't take much to be technically superior to VESA
matteo: and intel has GPL drivers for shitty cards
matteo: well according to render_bench shadowfb is way faster than EXA
matteo: by a factor of ~20
matteo: I don't know how close to real usage it is
matteo: but a 20x factor is relevant
matteo: i'll stick with shadowfb
werdz: what's the difference in terms of CPU usage?
agd5f: matteo: well, currently all radeonhd accelerates is fills and blits, once the composite code from radeon is ported performance should improve
matteo: compositing?
agd5f: matteo: support for render acceleration
matteo: what has compositing to do with EXA nad stuff?
matteo: isn't compositing for useless graph effects?
agd5f: matteo: the hooks are just called composite, but they accelerate render which composite uses
matteo: is that thing that draws in an offscreen buffer?
agd5f: composite does
matteo: Option "Composite" "Off"
matteo: this won't disable the hooks right?
agd5f: matteo: nope. just the extension
matteo: ok tnx
matteo: is a DRM module development started'
dmb: atombios is evil :D
agd5f: matteo: the drm already has support for r5xx chips. that part if done
dmb: but isn't the parser open sourced or something?
agd5f: s/if/is/
agd5f: dmb: yes, the parser is part of the radeon and radeonhd drivers
dmb: agd5f: convince amd to open source the atom bios :D
dmb: atombios*
matteo: (--) RADEONHD(0): Detected an M56 on a Macbook Pro
matteo: what core do I have?
agd5f: r500, rv530 IIRC
matteo: so there is the DRM support for my card
agd5f: yes
matteo: I have to checkout the DRM tree?
dmb: matteo: mesa may not work that well with your card yet
agd5f: yes. but radeonhd doesn't currently support the drm
dmb: agd5f: does drm/mesa make any use of the atombios?
agd5f: no
dmb: oh
agd5f: it's just used for modesetting
dmb: thinks that radeon and radeonhd should find a way to combine :/
dmb: buts that just my opinion
dmb: agd5f: so radeonhd are going to share the same mesa and drm base?
dmb: radeonhd and radeon i mean
agd5f: dmb: yes
dmb: oh :/
airlied: dmb: the kernel won't be growing a radeonhd drm module.
airlied: dmb: radeonhd will just port more code from radeon to deal with it.
matteo: dmb: a separate radoenhd module will be better?
dmb: no, i think they should combine, when i here porting from one driver to the other, it seems like a waste
matteo: [drm] Initialized radeon 1.28.0 20060524 on minor 0
matteo: indeed the module supports it
matteo: dmb: if the two drivers are so close that you can backport code from one to the other then a merge is good
dmb: matteo: well, splitting things up == splitting up of developers
dmb: so slower development on both sides
airlied: dmb: radeon hasn't slowed down much.. :)
matteo: why don't just merge?
dmb: matteo: the issue with atombios
matteo: if all devs agree do it
matteo: ah, it is only on new cards
rx__: i would be more concerned about the splitting of amd resources than the splittof developers
dmb: airlied: btw, i'm sure you probably know, but your mesa stuff causes x1400 mobility to crash atm :D (just so you know)
rx__: bridgman is pretty much doing double duty i think
matteo: what card started to use atombios? x700?
rx__: yes
Remosi: hrm
Remosi: atom bios doesn't look too invasive
matteo: and what card the radeon driver starts to support to? 8500?
airlied: matteo: it supports from radeon 7000
Honk: man radeon
Honk: :]
airlied: and we are thinking about making it support r128
matteo: ok
matteo: so you could do this
dmb: airlied: if you need me to give any information, just shout :D
matteo: drop all support >= than x700 in radeon
matteo: and merge all x700 => code in radeonhd
airlied: dmb: wierd but I need to do a lot more testing :), and of course lots of actualy code to make it work yet.
rx__: could drop.. but doesn't make sense since most of it is common
airlied: matteo: makes no sense..
airlied: matteo: the GPU family trees don't have clear lines of change
airlied: matteo: they are more like an evolution.
matteo: why? radeonhd can handle x700 too for what I'm understanding
airlied: matteo: no it can't..
matteo: it has atombios
airlied: matteo: radeonhd dones't use atombios to set modes.
airlied: matteo: and x700 modesetting is the same as old radeons
airlied: and we don't use atombios for modeseting on x700
airlied: as it was experimental back then.
airlied: we use it for certain functions like external DVI stuff
matteo: so atombios has nothng to do with 3D
matteo: it's just for DVI and modesettings
airlied: matteo: its just for modesetting and card initialisation
airlied: and powerplay type things
matteo: it's not evil at all then
matteo: initialisation si done once
agd5f: plus atombios on r4xx was not a full implementation
matteo: who care if you use atombios or direct registers?
matteo: ah, does radeons have microcode too?
agd5f: matteo: atom makes new asic support MUCH easier as the atom API says pretty consistent while the hw changes a lot
dmb: agd5f: is atombios guaranteed to exist in the later generation cards?
dmb: like future cards?
bosele: on that note, does radeonhd already support setting of power states?
airlied: dmb: it will evolve with cards.
matteo: stick with it then
airlied: dmb: but really even if AMD scrapped it we wouldn't be in any worse position..
rx__: i believe setting power states should be something that goes in randr?
airlied: as you would still have to do the work to bring up a new card..
dmb: well, in my opinion, i just thinks its silly having 2 drivers that are aiming to do the same exact thing
airlied: dmb: the future is having modesetting in the kernel.
dmb: for all cards?
airlied: dmb: X.org drivers will become accel only
dmb: nice
airlied: dmb: for at least Intel/AMD/Nouveau
airlied: dmb: and maybe others will port tyheir drivers
dmb: i'm guessing this is happening way in the future?
dmb: modesetting should be in the kernel
dmb: x should be a userspace daemon
marcheu: way = a couple of months
airlied: dmb: well F9 Beta already has a test off the intel driver in-kernel
dmb: it would be nice to have an actual fb driver that set modes correctly :/
airlied: just need to get the infrastructure into place and better tested..
airlied: wonders if marcheu has nouveau highlights in irc client :)
marcheu: I was watching the trolling actually
airlied: marcheu: hehe. :-P
marcheu: but yeah, I do :)
dmb: any of you know who works on the radeonfb driver?
airlied: dmb: nobody..
dmb: oh
airlied: dmb: benh rarely touches it anymore..
dmb: seems like that with all the framebuffer drivers
dmb: am i the only one that still uses the vts?
rx__: i think everyone just assumes mode setting is coming ;)
dmb: i wonder if the mode setting can work with the console/vt stuff
dmb: like a fbcon driver
airlied: dmb: it does already.. you get an dbcon
airlied: fbcon
airlied: and an fbdev
yangman: I use uvesafb for my mobility x1300. I can drive it at native res, so that's good enough
dmb: airlied: thats in the future, or now?
airlied: dmb: the intel code in Fedora does it all now
dmb: oh :/
dmb: maybe someday it will come to debian/ubuntu
airlied: dmb: once I've finished writing it..
dmb: oh :)
dmb: good luck then
freawn: I had read a thread about HD2600 agp cards not working with fglrx, are there any options for 3d?
freawn: is gone, autoaway/10m (l!on)
dmb: freawn: afraid not, wait for next months fglrx release
dmb: which should be coming out soon i think
tim__: hi
tim__: how is progress doing ?